AI로 회의록 액션 아이템 자동 추출
요약
AI로 회의록을 분석해 담당자와 마감일이 명시된 액션 아이템을 추출한다. 슬래시 커맨드로 Notion/Linear에 자동 생성하고 Slack으로 담당자에게 알린다. 회의 후 25분 정리를 90초로 줄이는 3단계 워크플로우.
AI 회의록에서 액션 아이템 자동 추출은 회의 후 수동 정리를 90% 줄여준다. 회의는 끝났지만 액션 아이템은 살아남지 못한다. 대부분의 팀이 이걸 안다. 회의 끝에 "이건 따로 싱크하자"고 하고 모두가 고개를 끄덕이지만, 목요일이면 누가 뭘 맡았는지 아는 사람이 없다. 이 가이드는 회의 원본에서 Notion이나 Linear로 갈 수 있도록 담당자와 마감일이 명시된 액션 아이템을 만드는 정확한 커맨드 체인이다. 슬래시 커맨드 3개와 회의 기록 도구 1개면 된다.
왜 액션 아이템들은 회의 10분 후에 사라지나
팀이 일부러 액션 아이템을 잃는 건 아니다. 액션 아이템은 "누군가 말했다"와 "누군가 맡았다" 사이 틈에서 사라진다. 회의록은 "우리 뭐해야 할 것 같은데"와 "할 수 있어?" 같은 표현을 모두 기록하지만, 회의록은 할 일 목록이 아니다. 4000단어 대화 속에 실제 약속은 3개 정도밖에 없다.
더 좋은 회의 기록 도구가 해결책이 아니다. 해결책은 옵스 리드가 회의록을 읽는 방식 그대로 읽는 커맨드다: 액션(뭘), 담당자(누가), 마감일(언제)을 찾고, 셋 중 하나라도 없으면 "명확하지 않음"이라고 표시하는 방식. Fellow에서 설명한 AI 회의 에이전트 동작 방식도 같은 점을 말한다: 가장 깔끔한 회의록을 주는 도구가 아니라, 너가 빌드하지 않고도 바로 쓸 수 있는 할 일 목록을 주는 도구가 이기는 도구다.
대부분 팀은 이미 회의 기록 도구를 갖고 있다. 부족한 건 중간 단계다: "회의록 요약"과 "팀이 실제로 쓰는 시스템의 할 일" 사이 단계. 그 중간 단계는 또 다른 SaaS 구독이 아니라 슬래시 커맨드고, 이 가이드가 바로 그걸 만드는 법이다.
1단계: 담당자와 마감일을 제대로 추출하는 회의 기록 도구 고르기
슬래시 커맨드를 만들기 전에, 먼저 회의록이 제대로 된 구조를 가져야 한다. 모든 회의 기록 도구가 액션 아이템을 같은 방식으로 추출하진 않는데, 그 차이가 녹음/전사 정확도보다 훨씬 중요하다.
30초 브리핑: 회의에 봇이 들어가면 팀원들의 발언이 달라진다면 봇 없는 도구로 가고, 그렇지 않다면 액션 아이템과 의사 결정을 깔끔하게 분리하는 도구를 고르자.
Fathom의 요약 구조는 우리가 원하는 형태에 가깝다: 의사 결정, 액션 아이템, 미해결 질문을 각각 따로 블록으로 보여준다. 한 덩어리 텍스트가 아니라는 뜻이고, 이게 2단계의 슬래시 커맨드가 파싱하기 좋은 포맷이다.
Fireflies는 영업옵스 중심이다: 액션 아이템을 HubSpot이나 Salesforce 필드로 바로 날린다. 액션 아이템이 "이 딜의 다음 단계"라면 도움이 되는데, 팀 내부 작업 과제라면 덜 좋다.
Granola는 회의에 봇을 집어넣지 않는다. 로컬로 전사하고 너의 손으로 쓴 노트를 올려 맞추니까, Granola가 추출하는 액션 아이템이 AI 생각이 아니라 너가 중요하다고 표시한 것에 묶인다.
하나를 골라라. 정확도 크로스체크 목표로 회의에 두 개 도구를 돌리지 말자. 정리 작업이 2배가 되고 2단계 슬래시 커맨드는 정확한 회의록 하나를 기대하는데 정반대되는 두 개를 받는다.

2단계: 회의록을 할 일 목록으로 바꾸는 /recap 커맨드 만들기
CommanderGPT의 Workflow Builder에서 /recap이라는 새 커맨드를 만든다. 이 프롬프트는 3가지를 순서대로 한다:
회의록을 가져온다 (복붙하거나, 회의 기록 도구의 내보내기 링크를 연결할 수 있다)
약속 패턴을 찾는다: "내가 할게", "우리 이거 해야 할 것 같은데", "할 수 있어?", "해보자"
매칭되는 문장마다 3개 필드를 출력한다: 액션, 담당자, 마감일. 담당자나 마감일이 없으면 "명확하지 않음"이라고 쓴다 (추측하지 말 것)
세 번째 규칙은 팀들이 빼는 부분이고, 그게 가장 중요한 부분이다. AI가 회의록에 이름 없는 사람을 할당하면 그건 모호함을 뒤로 밀어낼 뿐이다. 3일 뒤에 "팀"이 해야 할 일을 아무도 자기 것이라고 생각하지 않는다는 걸 발견하게 된다.
한 리브옵스 리더가 딜 리뷰 회의에서 쓰는 실제 커맨드 바디는 이렇다:
/recap [회의록 붙여넣기]
→ 액션 아이템을 추출: - [ ] 액션 | 담당자 | 마감일
→ 담당자나 마감일이 없으면 "명확하지 않음"이라고 표시하고, 추측하지 말 것
→ 의사 결정과 공지만 무시하고, 실행 가능한 약속만 출력하기이 커맨드를 진짜 회의록 하나 시험해 보고 신뢰할 준비를 해라. 6명이 있는 45분 회의의 첫 번째 실행은 대개 수정 한 번이 필요하다: 누군가 "가격 알아봐"라고 했는데 "누가"를 말하지 않았을 것이고, 커맨드가 그걸 건너뛰지 말고 표시해야 한다.
3단계: Notion이나 Linear로 손으로 타이핑하지 않고 액션 아이템 보내기
/recap이 깔끔한 목록을 뱉어내면, 체인의 두 번째 커맨드 /sync가 그 목록을 받아서 실제 할 일을 만든다. 이 단계는 대부분 팀이 손으로 하는 단계고, 시간을 가장 많이 잡아먹는 단계다: 요약 이메일의 6줄을 Notion 6개 행에 복붙.
팀이 이미 Notion에 사니까, /sync는 추출한 각 행을 데이터베이스 엔트리로 바꾼다: 할 일 이름, 담당자(팀원 리스트 매칭), 마감일, 회의 녹음 링크 역참조. 엔지니어링 인접 옵스 팀이 Linear를 쓴다면, 커맨드가 데이터베이스 행 대신 이슈를 만들고, 회의 날짜로 태그를 붙여서 나중에 추적 가능하게 한다.
첫 실행에서 매핑이 자동이 아니다. /sync는 Notion 어떤 속성이 담당자 이름을 가지고 있는지, 어느 게 마감일인지 알아야 하고, Linear는 새 이슈를 커맨드에서 받기 전에 기본 팀과 이슈 템플릿이 준비돼야 한다. 이 셋업을 빼먹으면 커맨드가 조용히 실패하거나, 더 나쁜 경우 액션 아이템이 틀린 팀의 백로그에 생긴다.
셋업 비용은 실제다: Notion 데이터베이스 필드 매핑이나 Linear 이슈 템플릿 첫 셋업에 20-30분 예상해라. 그 다음부턴 회의 당 손 작업은 0이다. 우리가 본 한 CS옵스 팀은 주간 QBR 준비 회의에서 25분 사후 정리를 90초 검토-승인 스텝으로 줄였다. 네 상황의 정리 시간은 다를 것 같겠지만 (회의 당 액션 아이템 개수), 이런 식의 개선가 가능하다는 뜻이다.

/recap → /sync → /notify 체인: 손 놓고 도는 워크플로우
전체 체인은 2개가 아니라 3개 커맨드다. 세 번째는 /notify고, /sync가 Notion이나 Linear에 쓰기를 끝낸 직후 Slack DM으로 각 담당자에게 자기 액션 아이템과 마감일을 보낸다.
Workflow Builder에서 3개를 연결하면 순서는 이렇다: 회의록 들어가고, /recap 추출, /sync 할 일 만들기, /notify 담당자들한테 핑. 대시보드 확인도 없고, 다이제스트 이메일 훑을 필요도 없다. 액션 아이템 담당자는 회의 끝나고 1분 안에 자기 할 일을 안다. 맥락이 아직 따뜻할 때.
이게 "3개 커맨드, 1 워크플로우, 0 마찰"이 제 몫을 하는 부분이다: 각 커맨드는 한 가지 일을 하고, 어느 하나 (다른 회의 도구, 다른 목적지, 다른 알림 채널)를 바꿔도 전체 체인을 다시 빌드하지 않는다.

여긴 안 될 수 있다: 정기 회의, 조용한 사람, 어색한 동사
3가지 실패 모드는 팀 전체한테 배포하기 전에 알고 있는 게 낫다.
정기 회의에서 반복된다. /sync가 지난 14일 열린 같은 이름 액션 아이템을 먼저 확인하지 않으면, 같은 "법무팀 포기하기" 행이 6주치 Notion 데이터베이스에 생긴다. 지난 14일 열린 액션 아이템 중복 제거를 커맨드에 추가하자.
조용한 사람은 건너뛰어진다. 회의 중 옆길 댓글이나 채팅에서 약속했는데 큰 목소리로 말하지 않으면, 회의록도 안 보이고 /recap도 안 본다. 이건 튜닝 문제가 아니라 진짜 차이다.
어색한 동사는 애매한 액션 아이템을 만든다. "가격에 대해 생각해 보자"는 액션 아이템이 아니라 대화 주제고, 잘 튜닝된 /recap이 "명확하지 않음"이라고 표시해야 한다. 커맨드가 애매한 회의에서 놀랄 정도로 완벽한 할 일 목록을 만들면, 추측 중이라는 뜻이고 그건 감사할 만한 가치가 있다.
30일 뒤 뭘 쟀나
워크플로우 말만 믿지 말고 직접 재라. 배포 30일 뒤 추적할 2개 수치가 있다: 완료율 (/recap이 추출한 액션 아이템 중 마감일까지 실제로 완료된 건 몇 %인가)와 수정률 (커맨드가 잘못 뽑은 담당자나 마감일을 몇 번이나 고쳤는가).
자동화 전 베이스라인과 비교해서 완료율이 그대로라면, 병목은 추출이 아니라 팔로우스루고, 슬래시 커맨드 체인으로는 책임 문제를 해결할 수 없다. 처음 2주 뒤 수정률이 5개 중 1개보다 높으면, 회의 도구를 바꿀 게 아니라 /recap 프롬프트를 다듬어야 한다. Fellow의 완료율 추적 가이드도 완료율 쪽에 쓸 만한 틀을 가지고 있다.
네트워크 벤치마크는 없다. 1주차 너의 베이스라인을 재고 비교해라.
셋업할 다음 커맨드
/recap만 시작해라. 다음 딜 리뷰나 QBR 준비 회의에서 한 번 돌려보고, 아웃풋을 손으로 Notion에 한 번 복붙해서 수정이 얼마나 필요한지 봐라. 추출을 신뢰하기 전에 3개 커맨드를 모두 연결하면, 틀린 할 일 목록을 빨리 자동화할 뿐이다.
3번 연속 회의에서 /recap이 20% 미만 수정으로 깔끔한 담당자-마감일 쌍을 만들면 /sync를 추가해라. /notify는 목적지가 맞을 때 마지막에 추가해라. 조사 완료 후 10명 팀에 전체 체인을 배포해라.