AI 업무 활용

팀 공용 AI 요청문 만들기: 회의 메모 정리 기준을 버전으로 관리하기

팀 협업 AI를 개인별 요청문이 아니라 공동으로 검토하고 고치는 팀 자산으로 만드는 방법을 다룹니다. 하늘팀의 AI 회의록 정리 요청문을 v1.0에서 v1.1로 개선하고, 같은 테스트 입력으로 다시 확인하는 과정을 따라갑니다.

목차 보기

이런 분께여러 사람이 같은 종류의 회의 메모를 AI로 정리하면서 결과 형식과 검토 기준을 맞추고 싶은 비개발자 팀

준비사항
  • 텍스트를 입력할 수 있는 일반적인 AI 채팅 도구
  • 실제 기밀·고객정보가 아닌 가상 자료를 사용할 것
  • 팀원이 함께 확인할 수 있는 요청문 버전 기록을 남길 것
  • AI 결과를 원문 메모와 사람이 직접 대조할 것

01개인 요청문이 아니라 팀 공용 기준으로 만들기

같은 회의 메모를 정리해도 팀원마다 AI에게 주는 지시가 다르면 결과의 항목명, 출처 표시 방식, 미정 사항 처리 방식이 달라질 수 있습니다. 이 글의 목적은 '좋은 문장'을 만드는 데 있지 않습니다. 팀이 반복해서 사용할 입력 양식, 기대 출력, 금지사항, 검토 방법을 한 문서에 묶고 변경 이유를 기록하는 데 있습니다. 개인용 프롬프트 보관과 달리 누가 무엇을 바꿨는지 다른 팀원이 다시 확인할 수 있어야 합니다.

가상 하늘팀은 2026-11-14 14:00–16:00에 지역 주민 대상 「동네 디지털 기초 워크숍」을 준비합니다. 정원은 30명이고 참가비는 없습니다. 장소 확정 기한은 2026-10-24, 홍보물 최종본은 2026-10-28, 강사 확정은 2026-10-30입니다. 2026-10-23 기준 신청자는 22명입니다. 이 사실은 팀 공용 요청문이 바뀌어도 임의로 수정하면 안 됩니다.

공용 요청문에 넣을 요소팀에서 정할 기준이유
입력 양식메모 작성자와 항목 번호를 함께 제공출처를 다시 찾기 쉽게 함
출력 형식결정·할 일·미정·충돌을 분리합의된 내용과 확인할 내용을 섞지 않음
출처 표시각 항목 끝에 메모 태그 유지여러 사람의 기록을 추적 가능하게 함
금지사항담당자·기한·결정을 추측하지 않음원문에 없는 확정을 막음
변경 기록버전·날짜·변경자·이유 기록공동 소유 문서의 변경 근거를 남김

02같은 테스트 입력을 고정해 비교하기

버전을 고칠 때마다 테스트 입력까지 바꾸면 무엇 때문에 결과가 달라졌는지 구분하기 어렵습니다. 아래 자료는 2026-10-20 회의에 대한 세 사람의 가상 메모입니다. 서로 표현이 다르고, 홍보물 일정에는 한 사람의 상대적인 표현이 섞여 있습니다. 또한 팀 공용 요청문 자체의 버전 기록과 변경자도 함께 입력해, 이후 output에서 새 정보를 만들지 않도록 합니다.

입력 자료
하늘팀 공통 사실
- 행사: 동네 디지털 기초 워크숍
- 행사 날짜: 2026-11-14
- 행사 시간: 14:00–16:00
- 정원: 30명
- 대상: 지역 주민
- 참가비: 없음
- 장소 확정 기한: 2026-10-24
- 홍보물 최종본 기한: 2026-10-28
- 강사 확정 기한: 2026-10-30
- 신청 현황: 2026-10-23 기준 22명

팀원 역할
- 민서: 팀장·전체 일정
- 준호: 장소·물품
- 서연: 홍보·신청 접수
- 도윤: 프로그램·강사 섭외

테스트 회의: 2026-10-20

[메모-민서-1] 장소는 A안 시민센터 3층 세미나실을 우선 검토한다. 최종 결정은 2026-10-24까지 한다.
[메모-민서-2] 홍보물 최종본은 2026-10-28까지 준비한다.
[메모-준호-1] A안 시민센터 3층 세미나실은 수용 32명, 빔프로젝터 있음, 엘리베이터 있음, 대관 가능 확인됨.
[메모-준호-2] B안 구립도서관 강당은 수용 60명이고 대관 가능 여부는 아직 확인되지 않았다.
[메모-서연-1] 홍보물은 장소 확정 뒤 최종 수정이 필요하다.
[메모-준호-3] 홍보물은 '다음 주 중' 마무리한다고 들었다. 정확한 날짜는 다시 확인하고 싶다.
[메모-도윤-1] 강사 확정 기한은 2026-10-30이다.

공용 요청문 버전 기록
- v1.0: 2026-10-22, 변경자 민서, 최초 공용안 작성
- v1.1: 2026-10-23, 변경자 서연, 충돌 항목과 출처 표기 규칙을 명시하도록 수정

이 입력에는 실제 조직 정보나 고객 데이터가 없습니다. 실제 업무에서 공용 요청문을 만들 때도 기밀, 비밀번호, 인증정보, 개인식별자료를 그대로 붙이지 말고 조직의 정보보호 정책을 먼저 확인합니다.

03입력·출력·금지사항을 한 요청문에 고정하기

v1.1의 핵심은 더 길게 쓰는 것이 아니라 판단 규칙을 명시하는 것입니다. 특히 여러 사람이 남긴 기록이 충돌할 때 한쪽을 자동으로 선택하지 않고, 두 기록을 모두 남긴 뒤 확인 필요로 분리하도록 요구합니다. 또한 메모에 없는 담당자나 날짜는 그럴듯하게 채우지 않도록 금지합니다.

요청문
아래 여러 사람의 회의 메모를 팀 공유용으로 정리해 주세요.

입력 규칙
- 각 메모의 작성자와 항목 번호를 출처로 사용합니다.
- 공통 사실과 개별 메모를 구분합니다.

출력 형식
1) 결정된 내용
2) 할 일
3) 미정 사항
4) 서로 충돌하거나 표현이 다른 기록
각 항목 끝에 원문 출처 태그를 붙입니다.

금지사항
- 입력에 없는 담당자, 날짜, 시각, 숫자, 결정을 만들지 마세요.
- 상대적 날짜 표현을 임의의 YYYY-MM-DD로 바꾸지 마세요.
- 충돌하는 기록 중 하나를 임의로 채택하지 마세요.
- 확정 여부가 불분명하면 '확인 필요'라고 쓰세요.

마지막에 사람이 원문과 대조해야 할 항목을 짧게 적어 주세요.
버전변경 내용검토 포인트
v1.0최초 공용안항목 분류가 팀에서 쓰기 충분한지 확인
v1.1충돌 보존·출처 표기 규칙 추가소수 기록이나 다른 표현이 사라지지 않는지 확인

04좋은 결과는 정답처럼 보이기보다 근거를 남긴다

아래는 실제 AI 실행값이 아니라 요청문을 검토하기 위해 만든 편집 예시입니다. 중요한 점은 결정을 새로 만들어내지 않고, 서로 다른 기록을 원문 태그와 함께 보존한다는 것입니다.

예시 결과
[예시 결과 · 실제 AI 실행 결과 아님]
공용 요청문: v1.1
변경 기록: 2026-10-23, 변경자 서연

결정된 내용
- 행사 날짜는 2026-11-14, 시간은 14:00–16:00이다. 정원은 30명이다.
- 강사 확정 기한은 2026-10-30이다. [메모-도윤-1]

할 일
- 장소는 A안 시민센터 3층 세미나실을 우선 검토하고 2026-10-24까지 최종 결정한다. [메모-민서-1]
- 홍보물은 장소 확정 뒤 최종 수정이 필요하다. [메모-서연-1]

미정 사항
- B안 구립도서관 강당의 대관 가능 여부는 확인 필요다. [메모-준호-2]

서로 충돌하거나 표현이 다른 기록
- 민서는 홍보물 최종본 기한을 2026-10-28로 기록했다. [메모-민서-2]
- 준호는 홍보물을 '다음 주 중' 마무리한다고 들었다고 기록했고, 정확한 날짜를 다시 확인하고 싶다고 적었다. [메모-준호-3]
- 따라서 홍보물 기한 표현은 원문 확인이 필요하며 한쪽 기록을 임의로 삭제하지 않는다.

사람이 대조할 항목
- 민서와 준호의 홍보물 기한 기록을 함께 확인한다.
- 준호의 B안 대관 가능 여부 확인 결과가 새로 생겼는지 확인한다.

이 형식은 AI가 회의 결론을 대신 정하는 장치가 아니라, 팀원이 어디를 확인해야 하는지 드러내는 장치입니다. 특히 [메모-민서-2]와 [메모-준호-3]처럼 표현이 다른 경우 한쪽을 제거하면 검토해야 할 쟁점 자체가 사라집니다.

05공용 요청문이 실패하는 방식도 팀이 함께 기록하기

공용 요청문을 한 번 작성했다고 끝내면 반복 오류가 남습니다. 팀은 어떤 잘못된 출력이 나왔는지, 그 오류를 막기 위해 어떤 규칙을 추가했는지를 버전 변경 이유로 남기는 편이 좋습니다.

잘못된 결과
[잘못되기 쉬운 결과 예시 · 실제 AI 실행 결과 아님]
- 장소는 B안으로 확정했다.
- 준호가 홍보물을 완성한다.
- 홍보물 기한은 2026-10-27이다.
- B안은 대관 가능하다.

이 예시는 입력에 없는 결정을 만들고, 홍보 담당이 아닌 준호에게 새 업무를 배정했으며, 제공되지 않은 날짜와 B안 대관 가능 여부를 확정했습니다. 수정 방법은 문장을 매끄럽게 다듬는 것이 아니라 요청문에 '추측 금지', '충돌 보존', '출처 태그 유지' 규칙을 넣고 같은 테스트 입력으로 다시 확인하는 것입니다.

확인 목록
공용 요청문 검토 목록
- 입력 양식에 작성자와 원문 항목 번호가 남는가
- 결정·할 일·미정·충돌이 구분되는가
- 입력에 없는 담당자·날짜·시각·숫자를 만들지 않도록 금지했는가
- 서로 다른 기록을 한쪽으로 합쳐 버리지 않는가
- 변경 버전·날짜·변경자·이유를 팀원이 확인할 수 있는가
- 실제 업무 자료를 넣기 전 조직의 정보보호 정책을 확인했는가

06버전 변경은 같은 입력으로 재검토하기

팀 공용 프롬프트는 완성품이라기보다 작은 운영 규칙에 가깝습니다. 새 버전을 만들 때는 변경자가 이유를 기록하고, 다른 팀원이 같은 테스트 입력으로 결과 형식과 누락 여부를 확인한 뒤 공유합니다. 특정 AI 제품의 설정에 기대기보다 입력과 출력의 규칙을 텍스트로 남겨두면 도구가 바뀌어도 팀의 검토 기준을 유지하기 쉽습니다.

  • 요청문을 고친 사람과 검토한 사람이 무엇이 달라졌는지 함께 읽는다.
  • 테스트 입력은 그대로 두고 결정·할 일·미정·충돌 분류가 유지되는지 본다.
  • 새 버전에서 출처 태그가 빠지거나 미확인 정보가 확정으로 바뀌지 않았는지 확인한다.
  • 팀이 실제 사용하기로 한 버전만 공용 위치에 명확히 표시한다.

다음 글인 「AI 결과를 팀에서 검토하고 승인하는 방법: 주간 보고서 공유 전 점검」에서는 공용 요청문으로 만든 결과라도 공유 전에 사실, 누락, 민감정보, 담당자, 최종 승인 상태를 어떻게 나눠 확인할지 다룹니다.

직접 확인할 항목

가상 입력 자료와 편집 예시 · AI 실제 실행 없음 · 이름·날짜·수치 일치 검사

  • 모든 code 블록에 input·prompt·output·bad_output·checklist 중 하나의 role이 있는지 확인
  • output의 사람 이름·YYYY-MM-DD 날짜·HH:MM 시각·숫자가 같은 글 input에 존재하는지 확인
  • v1.0과 v1.1의 변경 기록이 입력 자료에 있는 버전·날짜·변경자와 일치하는지 확인
  • 충돌하는 홍보물 기한 기록이 output에서 한쪽으로 임의 통합되지 않았는지 확인
  • 장소·행사 일정·정원·주요 기한·신청 현황이 시리즈 공통 사실과 모순되지 않는지 확인
  • 시간 절감률이나 생산성 향상 수치 같은 효과 수치를 사용하지 않았는지 확인
검증 범위의 한계

실제 AI 도구에서 실행한 결과가 아니라 팀 협업 AI 사용법을 설명하기 위해 만든 가상 입력과 편집 예시입니다. 실제 팀 자료에는 기밀·개인정보가 포함될 수 있으므로 입력 전에 조직의 정보보호 정책과 원문 공개 범위를 확인해야 합니다.