회의록을 AI에게 시키는 진짜 워크플로우 — 5분 회의록의 함정

5분 회의록은 왜 함정인가

회의 끝나자마자 5분 만에 완성되는 회의록은 매력적입니다. 녹취 파일 하나 던지면 요약·결정 사항·액션 아이템까지 정리된 결과가 메일로 날아옵니다. 시간 절약이 명확하니 한 번쯤 써보고 싶어집니다.

그런데 받아본 결과를 실제 회의 내용과 맞춰보면 종종 의문이 생깁니다. 이름이 바뀌어 있거나, 결정이 안 난 사안이 결정처럼 적혀 있거나, 가장 중요했던 한마디가 빠져 있는 경우입니다.

한 번은 한국어 회의록 자동화 서비스인 클로바노트로 두 시간짜리 회의를 정리해봤는데, 결과가 실제 회의와 상당히 달랐습니다. 화자 분리가 잘 안 됐고, 요약은 회의에서 나오지 않은 결론을 끼워 넣었습니다. 짧은 1대1 통화에서는 꽤 정확하던 같은 도구가 인원이 많고 시간이 길어지면 흔들렸습니다.

한국에서는 클로바노트·다글로·에이닷 노트·티로 같은 도구가 자리잡았고, 해외에서는 Otter·Fireflies·Granola·Fathom 같은 도구가 시장을 나누고 있습니다. 도구가 다양해진 만큼 정확도와 기능도 빠르게 좋아지고 있지만, "회의가 끝난 뒤 던지기"라는 기본 가정은 대부분 공유하고 있습니다.

이 글에서 정리할 AI 회의록 워크플로우의 함정은 도구 자체의 한계라기보다, "회의 끝난 다음에 던지는" 구조 자체에 있는 것 같았습니다.

사후 자동화가 망가지는 세 지점

회의가 끝난 뒤 녹취를 던지는 흐름은 세 곳에서 자주 어긋납니다.

첫째는 화자 식별입니다. 화자 분리가 흐려지면 누가 무엇을 말했는지가 사라지고, 회의록의 신뢰도 자체가 같이 사라집니다. 결정의 주체가 모호해지면 사후 책임도 모호해집니다.

둘째는 "결정"과 "논의"의 구분입니다. AI는 화제에 오른 내용을 결정 사항처럼 정리하는 경향이 있습니다. 실제로는 "검토해보자"였는데 "도입하기로 했다"로 적히는 식입니다. 한 줄 차이가 다음 주 일정을 바꿉니다.

셋째는 검증 단계의 부재입니다. 회의가 끝난 뒤 만들어진 회의록은 참석자 각자에게 확인을 받기 전까지는 사실상 한 사람(AI)의 해석입니다. "내가 그런 말 했어?"라는 반응이 며칠 뒤에 돌아오면, 회의록은 합의 도구가 아니라 분쟁의 씨앗이 됩니다.

짧은 전화 회의는 함정이 아니다

함정이 모든 회의에 똑같이 적용되는 건 아닙니다. 짧고 단순한 1대1 전화 회의 같은 경우, 자동 솔루션은 충분히 정확하게 동작합니다. 화자가 둘뿐이고, 톤이 단순하고, 시간이 짧기 때문에 STT의 약점이 잘 드러나지 않습니다.

회의 단위로 도구를 다르게 쓰는 게 우선이라는 결론에 자연스럽게 닿습니다. "5분 자동 회의록"이 잘 작동하는 회의도 있고, 작동하지 않는 회의도 있다는 구분이 먼저입니다.

아주 중요한 회의 — 단계별 인간 개입

반대편 극단에 있는 회의도 있습니다. 사후 추적이 반드시 필요한 회의, 한 문장의 누락이 큰 비용으로 이어지는 회의입니다. 이때는 워크플로우 자체가 무거워집니다.

녹취 파일을 OpenAI Whisper로 텍스트로 옮긴 뒤, 그 텍스트를 클로드 같은 LLM에게 다시 정리하게 시키고, 마지막에는 직접 본문을 읽으며 중요한 부분에 마킹을 합니다. 단계마다 사람이 개입하기 때문에 시간이 많이 드는 대신, 사후 검증이 가능하고 책임 추적도 가능합니다.

다만 모든 회의에 이렇게 할 수는 없습니다. 정말 중요한 의사결정이 걸린 회의에만 적용할 만한 워크플로우입니다.

진짜 워크플로우 — 회의 중에 같이 정리한다

가장 자주 쓰는 방식은 회의가 끝난 뒤가 아니라 회의를 하면서 정리하는 흐름입니다. 사실 이건 새로운 발상이 아닙니다. AI가 등장하기 한참 전부터 회의 중에 메모장을 열어 정리한 내용을 그 자리에서 참석자들과 공유하는 방식은 흔히 쓰던 습관이었습니다. 회의가 끝나면 그 메모가 곧 회의록이 되는 흐름입니다.

AI는 이 익숙한 습관을 더 가볍게 만들어줍니다. 회의 중에 한 세션 안에서 정리를 도와주는 도구가 하나 옆에 있는 것뿐입니다. 본질은 "한 세션 안에서 진행되는 정리 흐름" 그리고 "참석자가 화면을 함께 보는 합의 구조"입니다.

단계 자체는 단순합니다.

• 회의 시작 전에 회의록 파일을 하나 엽니다. VS Code의 .md 파일이든, 데스크탑 메모장이든, 노션·옵시디언·구글 독스·간단한 텍스트 에디터든 무관합니다. 핵심은 회의 내내 한 자리에 모이는 메모 공간이 있다는 점입니다.
• 아젠다마다 ## 같은 헤더 한 줄로 구분해둡니다. 아젠다의 크기는 묶기 나름이라, 너무 잘게 쪼개지 않고 회의 흐름에 맞춰 잡습니다.
• 회의가 진행되는 동안 각 아젠다 아래에 낙서하듯 가볍게 메모합니다. 결정 사항, 이견, 누가 무엇을 맡기로 했는지 같은 내용을 짧게 적습니다.
• 한 아젠다가 어느 정도 정리되면, 회의 참석자 모두가 보는 자리에서 AI에게 그 부분만 정리해달라고 요청합니다. 도구는 본인 환경에 맞는 것을 쓰면 됩니다. 에디터 안의 AI 어시스턴트일 수도 있고, 옆 모니터에 띄워둔 ChatGPT·클로드·제미나이 같은 웹 AI 창일 수도 있습니다. 메모 한 토막을 붙여넣고 정리를 받는 흐름은 어디서든 동일합니다.
• 결과를 화면에 띄워 함께 읽습니다. 이견이 있으면 그 자리에서 바로 말합니다. 즉시 수정합니다.
• 다음 아젠다로 넘어가 같은 방식을 반복합니다. 한 회의를 같은 AI 세션 안에서 처리하면 앞서 정리한 맥락이 그대로 이어져 더 매끄러워집니다.
• 회의가 끝나면 전체 파일을 AI에게 던지면서 "이메일 톤으로 정리해줘" 요청을 합니다. 결과를 참석자 전원에게 발송합니다.

녹취는 거의 쓰지 않습니다. 회의가 진행되는 동안 정리된 내용을 모두가 함께 확인했기 때문에, 사후 이견이 나올 여지가 거의 없습니다. 이견이 있었으면 그 자리에서 이미 말했을 것이기 때문입니다.

흥미로운 점은 해외에서 Granola 같은 도구가 위에서 정리한 흐름과 비슷한 방향으로 자리잡고 있다는 점입니다. 회의 중에 사용자가 직접 메모를 쓰면 AI가 옆에서 그 메모와 회의 흐름을 합쳐 정리해주는 구조입니다. 같은 발상이 별도 도구 카테고리로 자리잡아가는 중이라는 신호로 읽힙니다. 다만 도구가 흐름을 만들어주는 것이 아니라, 흐름이 먼저 있고 도구가 그 자리에 끼워지는 것입니다.

이 워크플로우의 세 가지 효과

회의 중에 같이 정리하는 흐름은 세 가지 효과를 동시에 만듭니다.

첫째, 회의록 작성 시간이 회의 시간과 일치합니다. 회의가 끝나는 순간 회의록도 끝나 있습니다. 사후 작업이 0에 가깝습니다.

둘째, 합의 단계가 회의 안으로 들어옵니다. AI가 정리한 내용을 참석자 모두가 그 자리에서 보면서 검증합니다. 회의가 끝난 뒤 며칠 지나 "내가 그렇게 말했나?"가 나올 일이 없습니다. 이견은 회의 안에서 해결되고, 회의록은 합의된 결과로 남습니다.

셋째, AI의 한계가 회의 전체로 번지지 않습니다. 아젠다 한 개를 정리한 결과가 어긋나도 그 자리에서 수정되기 때문에, 다음 아젠다에 영향을 주지 않습니다. 사후 자동화가 망가지면 회의록 전체가 망가지지만, 실시간 정리는 잘못된 한 부분만 고치면 됩니다.

함정은 AI가 아니라 워크플로우의 설계에 있다

"5분 회의록의 함정"을 피하는 답은 AI를 쓰지 않는 것이 아닙니다. AI는 회의 중에 함께 정리해주는 도구로 들어올 때 가장 강력합니다.

함정은 도구의 한계가 아니라 워크플로우의 설계에 있습니다. 회의를 끝낸 뒤 모든 부담을 AI에게 떠넘기는 흐름 자체가 함정이고, 그 부담을 회의 안으로 다시 가져오는 순간 같은 도구가 다른 결과를 냅니다.

회의록을 AI에게 시키는 진짜 워크플로우는 결국 회의를 어떻게 진행할 것인가에 대한 질문에서 출발합니다. 그 질문이 풀리면 AI는 도구로서 제 자리를 찾습니다.