회의록을 AI에 넣고 보고서 초안을 받았는데, 분명 메모에 없던 요청사항이나 기한이 슬쩍 들어가 있을 때가 있습니다. 이 순간부터 많은 사람이 “이 모델은 실무에 못 쓴다”고 느끼는데, 실제로는 모델 자체보다 입력 방식과 출력 규칙이 너무 열려 있었던 경우가 더 많습니다. 회의 메모는 원래 불완전하고 중복이 많고 맥락이 생략돼 있기 때문에, AI가 빈칸을 예쁘게 메우려 들수록 없는 내용이 섞일 가능성이 커집니다.
핵심은 단순합니다. 회의록을 잘 요약시키는 것보다, AI가 추측하지 못하게 출력 구조를 먼저 잠그는 편이 훨씬 안전합니다. 특히 확인 필요, 근거 문장, 메모에 없는 내용 추가 금지를 함께 걸어 두면, 초안 품질이 눈에 띄게 안정됩니다.
공식 OpenAI Structured Outputs 문서는 JSON Schema로 응답 형식을 고정하면 필요한 키 누락이나 잘못된 enum 같은 문제를 줄일 수 있다고 설명합니다. 공식 Claude Structured Outputs도 schema-compliant response를 보장해 downstream 처리와 검증을 쉽게 만든다고 말합니다. 중요한 점은 하나 더 있습니다. 형식을 고정한다고 해서 사실성이 자동 보장되지는 않지만, 어떤 항목이 추정인지와 무엇을 다시 확인해야 하는지는 훨씬 선명하게 분리할 수 있습니다.
안내: 본문은 생성형 AI를 활용해 초안을 정리했고, OpenAI·Anthropic 공식 structured outputs 문서와 실제 Office 프롬프트 테스트 흐름을 기준으로 다시 다듬었습니다.
flowchart LR A[문제 인지: 회의록 결과에 없는 내용이 섞임] --> B[요약 대신 보고서 구조 고정] B --> C[확인 필요 필드 추가] C --> D[근거 문장 함께 출력] D --> E[샘플 5~10행 먼저 검수] E --> F[전체 초안 확장]
칠판 치트시트
- 회의록은 원래 빈칸이 많아서 AI가 추측하기 쉽다
요약해줘보다근거 포함 구조화 출력이 안전하다확인 필요필드를 만들면 잘못된 단정이 줄어든다- 구조화 출력은 형식을 안정시키지, 사실을 자동 보장하지는 않는다
- 원본 전체 적용 전에 샘플 검수 루프를 넣어야 한다
이런 증상이면 이 문서가 바로 맞다
- 회의 메모를 넣었더니 AI가 없는 요청사항까지 써 넣는다.
- 날짜, 담당자, 지원 요청이 너무 그럴듯하게 보정돼서 오히려 위험하다.
- 보고서 초안은 빨리 나오는데 사실 확인이 더 오래 걸린다.
- 회의록 요약을 상사에게 바로 보내기 불안하다.
- 모델을 바꿔도 비슷하게 “그럴듯한 추가 문장”이 생긴다.
왜 이런 일이 생기는가
1) 회의록은 원래 문장보다 빈칸이 많다
회의 메모는 대개 아래 중 하나가 빠져 있습니다.
- 결정은 적혀 있는데 배경이 없음
- 액션은 있는데 기한이 없음
- 요청사항처럼 보이지만 실제론 논의만 된 상태
- 참석자는 있는데 누가 무엇을 맡았는지 분명하지 않음
이런 상태에서 “임원 보고서로 정리해줘”라고만 던지면, 모델은 빠진 연결고리를 매끈하게 이어 붙이려는 경향이 있습니다. 그래서 문장은 좋아 보여도, 실무에서는 오히려 위험해질 수 있습니다.
미니 사례 A:
- Before:
광고 예산 15% 증액 검토라는 메모만 있었는데, 초안에는광고 예산 15% 증액 요청처럼 단정형 문장이 들어감 - After:
결정/미결/확인 필요를 분리하도록 바꾸자, 해당 항목이목요일 재논의 예정으로 내려감
이 차이는 모델 성능보다 출력 구조가 얼마나 보수적으로 설계됐는가에서 갈립니다.
2) 자연어 보고서는 읽기 쉽지만 검수는 어렵다
긴 문단으로 잘 써 준 초안은 처음 보면 좋아 보입니다. 그런데 실무에서는 문장이 매끈할수록 검수가 더 어려울 때가 많습니다. 어떤 문장이 메모에서 온 사실이고, 어떤 문장이 모델이 채운 연결 문장인지 분리하기 어렵기 때문입니다.
공식 OpenAI 문서는 Structured Outputs가 schema adherence를 보장해 필드 누락과 잘못된 포맷 문제를 줄여 준다고 설명합니다. 이 말은 실무적으로 바꾸면, 문단 대신 구조화된 칸으로 받으면 검수가 쉬워진다는 뜻에 가깝습니다.
예를 들어 아래처럼 바꾸면 차이가 큽니다.
- 나쁜 예: “회의 내용을 임원용 보고서로 자연스럽게 정리해줘”
- 더 나은 예: “
핵심 3줄 / 결정된 내용 / 미결 이슈 / 다음 액션 / 확인 필요5개 섹션으로 나누고, 메모에 없는 사실은 쓰지 말아라” - 더 안전한 예: “각 항목마다
근거 문장을 같이 출력하고, 근거가 없으면확인 필요로 표시해라”
3) 구조화 출력은 거짓을 없애는 도구가 아니라, 거짓을 드러내는 도구다
이 지점이 가장 중요합니다. Structured Outputs는 형식을 강하게 고정해 줍니다. OpenAI는 required key 누락이나 invalid enum 문제를 줄일 수 있다고 말하고, Anthropic도 always valid, type-safe JSON을 강조합니다. 하지만 이것만으로 사실이 참이 되는 것은 아닙니다.
대신 실무에서는 아주 큰 도움이 됩니다.
support_needed: true/falsedeadline_confidence: confirmed/unclearevidence_quote: "원문 일부"needs_human_check: true/false
이런 필드를 넣으면, 모델이 단정적으로 문장을 예쁘게 만들어도 어디가 확정이고 어디가 추정인지를 다시 자를 수 있습니다.
즉 구조화 출력의 진짜 장점은 환각을 마법처럼 없애는 것이 아니라, 검수 가능한 모양으로 바꾸는 것입니다.
가장 빠른 10분 복구 순서
1) 요약 대신 구조 고정부터 건다
회의록 정리는 문장력 문제가 아니라 순서 문제인 경우가 많습니다. 먼저 아래처럼 출력 규칙을 잠가 둡니다.
너는 실무 보고서 편집자다.
아래 회의 메모를 보고 다음 구조로만 정리하라.
1) 핵심 3줄
2) 결정된 내용
3) 미결 이슈
4) 다음 액션(담당자/기한)
5) 확인 필요
메모에 없는 사실은 추가하지 말고, 불명확하면 반드시 '확인 필요'로 표시하라.이 단계만 해도 없는 요청사항이나 과한 결론이 꽤 줄어듭니다.
2) 근거 문장 필드를 함께 뽑는다
가장 효과적인 보정 중 하나는 각 핵심 항목 아래에 근거가 된 메모 원문을 같이 붙이게 하는 것입니다.
각 항목마다 원문 근거 문장 1개를 함께 출력하라.
근거가 없으면 내용을 만들지 말고 '근거 없음 / 확인 필요'로 표시하라.이렇게 하면 검수자가 훨씬 빨리 판단할 수 있습니다. 잘 쓴 문장보다, 어떤 메모에서 나온 내용인지 보이는 초안이 실무에서는 더 안전합니다.
3) 불확실한 항목은 아예 enum처럼 강제로 나눈다
공식 structured output 문서들이 공통으로 주는 힌트는 열린 서술보다 고정된 선택지가 낫다는 점입니다. 그래서 아래처럼 나누면 좋습니다.
status: confirmed | pending | uncleardeadline: exact | missingsupport_request: explicit | inferred | none
미니 사례 B:
- Before:
디자인 지원 요청 필요라고 단정적으로 써서 실제 요청 여부가 흐려짐 - After:
support_request: inferred와확인 필요로 내려가며 검수 포인트가 또렷해짐
4) 샘플 5개만 먼저 돌린다
회의록이 길수록 처음부터 전체 초안을 만들고 싶어지지만, 가장 안전한 방식은 샘플 검수입니다.
- 메모 5개만 넣어 테스트
- 근거 문장과 확인 필요 표기가 제대로 되는지 확인
- 그다음 전체 회의록 확장
- 마지막으로 사람 검수 3개 항목만 다시 체크
이 루프가 있으면, 모델을 바꾸더라도 매번 처음부터 신뢰를 잃지 않아도 됩니다.
오늘 바로 쓰는 안전 프롬프트
기본 안전형
너는 실무 보고서 편집자다.
아래 회의 메모를 임원 보고 초안으로 정리하라.
반드시 아래 구조만 사용하라.
1) 핵심 3줄
2) 결정된 내용
3) 미결 이슈
4) 다음 액션(담당자/기한)
5) 확인 필요
규칙:
- 메모에 없는 사실은 추가 금지
- 불명확한 내용은 확정형으로 쓰지 말 것
- 각 항목마다 근거가 된 원문 표현 1개를 붙일 것
- 근거가 없으면 '확인 필요'로 표시할 것더 강한 구조화형
아래 회의 메모를 JSON으로 정리하라.
필드:
- executive_summary: string[]
- decisions: [{item, evidence_quote, confidence}]
- pending_issues: [{item, evidence_quote, confidence}]
- next_actions: [{owner, due_date, task, evidence_quote, confidence}]
- needs_confirmation: string[]
규칙:
- confidence는 confirmed | unclear 중 하나만 사용
- 메모에 없는 사실 추가 금지
- due_date가 없으면 null로 두고 needs_confirmation에 넣을 것실전 꿀팁
- 보고용 문장보다 먼저 검수용 구조를 만든다.
요청사항은 특히 잘 지어내기 쉬우니explicit | inferred | none처럼 나누면 좋다.기한,담당자,지원 요청은 메모에 없으면 비워 두는 편이 낫다.- 모델 비교를 할 때도 문장력이 아니라 추정 문장 비율을 먼저 본다.
오늘 바로 점검할 체크리스트
- 프롬프트에
메모에 없는 사실 추가 금지가 들어가 있다. -
확인 필요섹션이 따로 있다. - 핵심 항목마다
근거 문장을 같이 뽑는다. - 샘플 5~10개로 먼저 검수한다.
- 기한과 요청사항은 메모 근거 없으면 비워 둔다.
다음 읽기
AI 생성 결과물을 포함한 문서입니다. 실제 보고 전에는 숫자, 담당자, 기한, 요청사항만 사람 기준으로 한 번 더 확인하세요.