회의가 끝나는 순간 태스크를 자동 정리: Tiro MCP 셋업

매주 한 번 팀이 모여 한 시간을 들여 회의를 합니다. 회의가 끝나는 순간, 모든 참여자가 "다음 주에 무엇을 해야 하는가"를 머릿속에 명확히 들고 나갑니다. 그러나 진짜 비용은 그 다음에 발생합니다. 머릿속의 액션은 노트, 슬랙, 캘린더, 태스크 도구로 흩어집니다. 일주일이 지나면 의도가 천천히 소실되고, 다음 회의가 돌아왔을 때 "분명히 정했는데 왜 안 됐는가"가 반복됩니다.

이 글에서는 이 현상을 회의의 후행 비용이라고 부르겠습니다. 결정 자체는 한 시간이면 끝나지만, 그 결정을 일주일 동안 살려두는 비용이 결정 자체보다 큽니다. 그리고 이 비용은 AX의 가장 큰 공백인 Context Source 레이어에서 발생합니다.

이번 글은 30년 된 회의 형식인 KPT 위에 Tiro MCP를 적용하여 회의의 후행 비용을 사실상 제거한 저희 팀의 AX 셋업 5단계의 기록입니다.

30년의 역사를 가진 회고 형식: KPT

KPT는 1980년대 도요타의 카이젠 운동에서 출발한 회고 형식입니다. Keep(계속할 것) · Problem(문제) · Try(시도)의 세 축으로 회의를 진행합니다. 단순한 구조 덕분에 30년 넘게 변형되며 살아남았고, 한국 스타트업은 보통 Keep / Stop / Continue / Start로 변형해 굴립니다. 저희 팀도 이 4분류를 사용합니다.

KPT의 강점은 명확합니다. 회의가 끝나면 모든 참여자가 동일한 형식으로 "다음 주에 무엇을 할 것인가"를 들고 나갑니다.

문제는 그 다음에 발생합니다. 결정된 액션이 어디로 흘러가야 하는지에 대한 합의는 형식 자체에 포함되어 있지 않습니다. KPT는 결정의 형식이지, 실행의 형식이 아닙니다. 그래서 일주일 동안 의도가 새고, 다음 KPT에서 "지난주에 결정한 것이 왜 안 됐는지"를 다시 논의하게 됩니다.

이전 글에서 다룬 AX 5-Layer 관점에서 보면, 회의록은 AX의 Context Source 레이어에 해당합니다. 그리고 이 레이어는 대부분의 조직에서 가장 큰 공백입니다.

회의록이 LLM-Ready Data가 되는 순간

이전 글에서 Conversation Intelligence를 정의했습니다. 음성 회의 데이터를 받아 AI가 활용할 수 있는 형태, 즉 LLM-Ready Data로 변환하는 카테고리입니다.

이 카테고리가 KPT에 직접적인 의미를 가지는 이유는 단순합니다. 회의록이 LLM-Ready Data가 되는 순간, 회의의 후행 비용은 자동화의 대상이 됩니다. 사람이 회의록을 다시 읽고, 액션을 추출하고, 태스크 도구에 옮겨 적는 일을 에이전트가 대신 할 수 있게 되기 때문입니다.

그러나 회의록을 LLM-Ready Data로 변환했다고 해서 자동화가 완성되는 것은 아닙니다. 그 데이터를 에이전트에게 어떻게 연결하느냐가 다음 질문입니다.

이 셋업의 한가운데, Tiro MCP

직전 글에서 정리했듯이, 티로는 API, MCP, CLI, Skill 네 가지 도구를 모두 지원합니다. KPT 자동화 시나리오에서는 MCP가 사용됩니다.

Tiro MCP는 회의록·요약·화자 분리 결과를 LLM이 직접 가져갈 수 있게 노출한 통로입니다. 14개 도구가 6개 영역(Authentication, Notes Discovery, Notes Retrieval, Templates, Share Links, Folders)에 걸쳐 있습니다.

KPT 자동화 워크플로우에서 다루는 회의록의 무게는 가볍습니다. 한 회의의 액션 항목을 분류하는 작업은 본문 전체가 아니라 요약·화자별 발언 단위로도 충분합니다. 즉 multi-turn reasoning의 영역이고, 그 자리에 MCP가 가장 적합합니다. 1시간 분량의 transcript 전체를 컨텍스트 윈도우에 부어 넣을 필요가 없습니다.

이 셋업에 함께 등장하는 다른 도구도 같은 원리로 자리를 잡았습니다. Slack은 비즈팀의 메신저 채널 맥락을 제공하는 Context Source이고, Linear는 팀의 모든 태스크를 관리하는 이슈 트래킹 도구입니다. Tiro, Slack, Linear의 MCP 세 개가 이 셋업의 부품입니다.

5단계 셋업 공개

KPT 회의 자체는 그대로 두고, 회의의 전후 흐름에 4개의 Claude Skill을 넣었습니다.

[1] 회의 전 수집 → [2] KPT 회의 → [3] 회의 후 분류 (Tiro MCP)
                                          │
                                          ↓
                                  [4] Linear 자동 반영
                                          │
                                          ↓
                                  [5] 데일리 슬랙 푸시
                                          │
                                          └→ (다시 [1]로)

각 단계의 Skill을 차례로 풀어봅니다.

1단계. 회의 전 수집

회의 직전에 /kpt-before를 호출하면, 지난 화요일 KPT 이후부터 현재까지의 Linear 이슈 상태와 Slack 메시지 맥락이 발표용 표로 정리됩니다.

~/.claude/skills/kpt-before.md

description: 화요일 KPT 직전, 지난 KPT 이후부터 지금까지 Linear/Slack 상태를 발표용 표로 정리.

1. 기간 설정: 지난 화요일 18:00부터 지금까지

2. Linear: assignee=본인 이슈를 Done / In progress / Blocked로 분류

3. Slack: #biz 채널과 DM을 전체 스캔하여 액션·결정·수치·요청 4 카테고리로 분류

4. 표 4 섹션 출력

발표 자료를 사람이 30분 동안 손으로 정리하는 단계가 사라집니다. 수집은 자동화의 대상이고, 판단은 사람의 영역이라는 분업이 명확해집니다.

2단계. KPT 회의

이 단계는 자동화하지 않습니다. KPT의 가치는 사람들끼리 같은 자료를 보면서 결정에 합의하는 데 있습니다. 자동화의 대상이 아닙니다.

다만 모든 참여자가 발표 자료를 사전에 들고 들어오기 때문에, 회의에 드는 시간 자체는 단축됩니다.

3단계. 회의 후 분류

회의가 끝나는 순간 /kpt-after를 호출합니다. 이 단계가 셋업의 한가운데, 즉 Tiro MCP가 작동하는 지점입니다.

~/.claude/skills/kpt-after.md

description: 화요일 비즈 KPT 직후, Tiro 회의록을 4 분류해 본인이 owner인 액션만 추출하고 Linear에 자동 반영.

1. Tiro MCP list_notes로 비즈 5인 참여자가 모두 포함된 노트 1건 식별

2. get_note_transcript로 본문 로드

3. 팀 전체 액션을 Keep / Stop / Continue / Start로 분류

4. owner=본인 항목만 표로 추출 (다음 한 발은 LLM 추론)

5. kpt-linear-sync 스킬 자동 호출

회의록이 Conversation Intelligence의 정의 그대로 작동하는 순간입니다. 음성에서 출발한 회의 데이터가 화자 분리·구조화·메타데이터 첨부의 파이프라인을 거쳐 LLM-Ready Data가 되어, 다음 일주일의 입력값으로 곧장 흘러갑니다.

4단계. Linear 자동 반영

~/.claude/skills/kpt-linear-sync.mdescription: kpt-after 결과를 Linear tiro-ax 팀에 자동 반영.

1. Start : save_issue로 신규 이슈 생성 (due·priority는 회의록에서 추출)

2. Continue : list_issues로 후보 3개 추림, quote 비교로 1개 선택, get_issue로 현재 상태 확인 후 업데이트

3. Stop : 같은 방식으로 매칭, status=Canceled

4. Keep : 변경 없음

3단계 직후 자동으로 호출됩니다. 한 가지 안전장치가 있습니다. 기존 이슈를 업데이트하기 전에 반드시 현재 상태를 먼저 조회합니다. 지난 일주일 사이에 동료가 description을 수정했거나 우선순위를 바꿨을 수 있기 때문입니다. 사람이 손댄 부분을 자동화가 덮어쓰지 않도록 막는 패턴입니다.

5단계. 데일리 슬랙 푸시

~/.claude/skills/daily-kpt-push.md

description: 매일 아침, Linear 이슈 중 오늘 집중할 1~3개를 Slack DM으로 push.

1. Linear active 이슈를 due / priority / 지연 기준으로 sort, 상위 3개 선별

2. 각 이슈의 "다음 한 발"을 description·코멘트에서 추출

3. Slack DM에 카드 형식으로 푸시

(매일 9시 자동 실행: cron 또는 Claude Code Schedule)

상위 1~3개로 제한한 것은 의도된 설계입니다. 처음에는 active 이슈 전부를 푸시했고, 결과적으로 한 시간 안에 푸시 자체를 끄게 되는 현상이 발생했습니다. 사람이 하루에 의식적으로 다룰 수 있는 일은 통상 3개를 넘기 어렵습니다. 그 한계를 인정하고 정렬 기준을 단순화한 뒤에 푸시가 매일 그대로 따라가는 패턴이 잡혔습니다.

이 설계가 가르치는 것

이 셋업이 보여주는 것은 도구 몇 개의 조합이 아닙니다.

회의 전후의 흐름 자체를 다시 설계할 때 비로소 회의의 후행 비용이 사라진다는 점입니다. ChatGPT에 회의록 요약을 시키는 정도의 도구 교체로는 이 비용이 줄지 않습니다. Paul David가 1990년 논문에서 보여준 전기 모터의 교훈과 같은 구조입니다. 도구를 바꾸는 것은 몇 주면 가능하지만, 흐름의 재설계는 시간이 듭니다. 그리고 생산성은 언제나 후자에서만 발생합니다.

회의록의 본질도 함께 바뀝니다. 작년까지 회의록은 "지나간 일을 적은 기록"이었습니다. 이 셋업 안에서 회의록은 다음 일주일을 굴리는 입력값입니다. 동일한 음성 파일에서 출발하더라도, 어디까지 변환하고 어디로 흘려보내느냐에 따라 완전히 다른 카테고리가 됩니다.

자주 묻는 질문

Q. MCP는 무엇인가요?

MCP(Model Context Protocol)는 2024년 11월 Anthropic이 발표한 오픈소스 표준입니다. AI 에이전트가 외부 도구와 데이터에 접근할 때 항상 같은 형식으로 대화할 수 있도록 설계된 프로토콜이며, JSON-RPC 위에서 동작합니다. 자세한 내용은 API, MCP, CLI, Claude Skill: 무엇이 다르고, 언제 써야 하는가?에서 정리했습니다.

Q. Tiro MCP는 어떻게 사용하나요?

Tiro 계정과 연동된 MCP 서버를 Claude Desktop이나 Claude Code에 설정하면, list_notes · get_note · get_note_transcript 등 14개 도구로 회의록에 직접 접근할 수 있습니다. 코드를 오울 필요없이, 자연어로도 직접 호출이 가능합니다. 전체 사양은 api-docs.tiro.ooo에서 확인할 수 있습니다.

Q. AX와의 관계는 무엇인가요?

AX 5-Layer 아키텍처에서 회의록은 Context Source 레이어의 핵심 영역입니다. Tiro MCP는 회의를 LLM-Ready Data로 변환한 뒤 에이전트의 자동화 안에 부품으로 끼울 수 있게 만든 통로이고, 본문의 5단계 셋업은 이 부품 위에서 KPT라는 회의 형식을 닫힌 루프로 만든 사례입니다.

Q. 같은 셋업을 우리 팀에도 적용할 수 있나요?

회의 형식이 KPT가 아니더라도 적용 가능합니다. 핵심은 세 가지입니다. (1) 회의가 LLM-Ready Data로 변환되어야 하고, (2) 그 데이터를 받아 액션을 분류하는 절차가 Skill로 명시화되어야 하며, (3) 분류 결과가 팀의 태스크 트래킹 도구로 흘러가야 합니다. 회의의 형식보다 회의 전후의 흐름이 본질입니다.

시작하기