회의록을 AI로 정리하는 워크플로: 원문에서 결정·할 일·미결까지

회의록 정리는 AI에게 맡기기 좋은 작업입니다. 원문이 이미 있고, 나와야 할 산출물의 모양이 정해져 있기 때문입니다. 2026년 9월 11일 기준 Claude Code 공식 워크플로 문서는 "Claude Code works in any directory"라고 적으며, 노트 보관함이나 문서 폴더 안에서 마크다운을 검색·수정·재구성하는 일을 코드 작업과 같은 방식으로 다룹니다. 코드가 한 줄도 없는 폴더에서도 쓸 수 있다는 뜻입니다.
이 글은 회의 원문 하나를 결정 사항 · 할 일 · 확인이 필요한 사실 세 칸으로 옮기는 절차를 정리합니다. 등장하는 회의와 숫자는 모두 허구 예시이며 실제 자료가 아닙니다.
왜 세 칸인가
회의록을 "요약해 줘"라고만 시키면 문장이 짧아질 뿐 쓸모는 늘지 않습니다. 회의가 끝난 뒤 실제로 필요한 정보는 세 종류입니다.
| 칸 | 무엇이 들어가나 | 빠지면 생기는 일 |
|---|---|---|
| 결정 사항 | 합의된 방침, 하지 않기로 한 것 | 다음 회의에서 같은 논쟁을 다시 함 |
| 할 일 | 담당 · 내용 · 기한 | 아무도 안 함 |
| 확인이 필요한 사실 | 출처 없는 숫자, 애매한 날짜 | 미확인 숫자가 외부 자료로 새어 나감 |
세 번째 칸이 특히 중요합니다. 미확인 항목을 담아 둘 자리를 미리 만들지 않으면, 애매한 숫자가 확정된 사실처럼 정리본에 섞입니다.
원문에서 정리본까지
샘플 원문 meeting-notes-before.txt는 다듬지 않은 대화 그대로입니다. 일부를 옮기면 이렇습니다.
하준: 지난주 문의 37건이라고 했는데 그 숫자 출처가 뭐야?
시연: 내가 대충 센 거라 확정 아님. 시트에서 다시 세자.
민지: 도메인 이전은 보류. 이번 주 범위 아님.
같은 대화를 정리한 meeting-notes-after.md에서 할 일 칸은 한 줄뿐입니다.
| 담당 (가명) | 할 일 | 기한 |
|---|---|---|
| 하준 | 랜딩 카피 초안. 가격은 공식 페이지를 다시 연 뒤 작성 | 2026-09-17 오전 |
원문에서 기한을 말한 사람이 하준뿐이었기 때문입니다. 참석자가 셋이라고 할 일도 셋으로 맞추면 없는 배정을 만들어 내게 됩니다. "지난주 문의 37건"과 "목요일 15시"는 확인이 필요한 사실 칸으로 갑니다.
프롬프트는 목표→맥락→제약→산출물
한 번에 쓸 만한 결과를 받으려면 프롬프트를 네 덩어리로 씁니다. 구조와 예시는 프롬프트 빌더와 좋은 프롬프트의 구조에 정리돼 있습니다.
[목표] 아래 회의 원문을 결정 사항 / 할 일 / 확인이 필요한 사실 세 섹션으로 정리해 줘.
[맥락] 1인 창작자 팀의 주간 회의다. 참석자는 셋이고 모두 가명이다.
[제약]
- 원문에 없는 담당자, 날짜, 숫자를 만들지 마
- 출처를 밝히지 않은 숫자는 확인이 필요한 사실로 분류해
- 보류하기로 한 안건도 결정 사항에 적어
- 기한은 원문에 나온 표현 그대로 적고, 없으면 비워 둬
[산출물] 마크다운. 할 일은 담당·할 일·기한 3열 표로.
제약 항목이 곧 검수 기준입니다. Claude Code 터미널에서는 @회의록.txt처럼 파일을 직접 붙이고, 파일을 고치기 전에 제안만 보고 싶으면 공식 문서가 안내하는 plan 모드(Shift+Tab)를 씁니다. 붙여 넣어 쓸 수 있는 첫 세션 프롬프트는 claude-code-first-session-prompt.md에 있습니다.
터미널과 Desktop 중 어디서
두 화면 모두 같은 엔진을 씁니다. 공식 문서가 적는 차이는 이렇습니다.
| 터미널 CLI | Desktop Code 탭 | |
|---|---|---|
| 입력 방식 | 명령창에 프롬프트 | 창 안의 채팅 패널 |
| 변경 확인 | 텍스트 diff | 파일별 시각 diff, 줄 단위 코멘트 |
| 세션 | 터미널 창마다 하나 | 사이드바에서 여러 개 병렬 |
| 권한 | Manual · Accept edits · Plan · Auto · Bypass · dontAsk | Manual · Accept edits · Plan · Auto · Bypass |
| 요구 사항 | 설치 후 로그인 | 유료 구독 필요. Windows는 Git for Windows 필요 |
회의록처럼 결과를 눈으로 대조하는 작업은 Desktop의 diff 패널이 편합니다. 선택 기준은 Desktop Code 탭 vs 터미널 CLI에 있습니다.
내보내기 전 검토
정리본을 공유하기 전에는 사람이 한 번 봅니다. 전체 체크리스트는 fact-source-checklist.md에 있고, 회의록에는 그중 세 줄이 특히 자주 걸립니다.
- 출처 없는 숫자를 확정된 사실로 적지 않았는가
- 원문에 없는 담당·기한이 생기지 않았는가
- 메일 발송·결제·환불 같은 최종 행동을 사람 확인으로 남겼는가
세 번째는 회의에서 "환불 메일은 자동 발송 금지"라고 못 박은 이유이기도 합니다.
자동화로 넓힐 때
같은 작업을 매주 반복한다면 워크플로 도구로 옮길 수 있습니다. 회의 텍스트를 웹훅으로 받아 요약을 돌려주는 최소 형태의 입력·기대 출력은 n8n-webhook-summary.sample.json입니다. 기대 출력에 unverifiedClaims 배열이 따로 있는 점을 눈여겨보십시오. 자동화에서도 미확인 항목은 요약문에 섞지 않고 따로 뺍니다.
다만 회의가 주 1회이고 정리에 10분이 걸린다면, 워크플로를 만들고 유지하는 시간이 더 클 수 있습니다. 손익 분기는 자동화 ROI 계산기에서 추정치로만 확인하십시오.
다음 단계
- Claude Code 사용법: 처음 세션에서 익힐 6가지
- 좋은 프롬프트의 구조: 목표→맥락→제약→산출물
- n8n 사용법: 첫 AI 워크플로 만들기
- 준비 중인 무료 과정 안내는 AI 기초 강의에서 (현재 수강·결제는 불가)
