회의가 끝나는 순간 태스크를 자동 정리: Tiro MCP 셋업
회의가 끝난 뒤 흩어지는 액션 항목은 회의 전후의 흐름을 다시 설계해야 사라집니다. 이 글은 KPT 회고 회의 앞뒤에 클로드 스킬 네 개를 붙여, 티로 MCP로 회의록을 불러오고 액션을 분류한 뒤 리니어 이슈로 반영하고 매일 아침 슬랙으로 상위 세 건만 밀어 넣는 5단계 셋업을 그대로 공개합니다. 도구를 하나 바꾸는 것만으로는 이 비용이 줄지 않습니다.
이 글은 2026년 5월에 발행했으며, 2026년 8월에 내용을 갱신했습니다.
매주 한 번 팀이 모여 한 시간을 들여 회의를 합니다. 회의가 끝나는 순간, 모든 참여자가 "다음 주에 무엇을 해야 하는가"를 머릿속에 명확히 들고 나갑니다. 그러나 진짜 비용은 그 다음에 발생합니다. 머릿속의 액션은 노트, 슬랙, 캘린더, 태스크 도구로 흩어집니다. 일주일이 지나면 의도가 천천히 소실되고, 다음 회의가 돌아왔을 때 "분명히 정했는데 왜 안 됐는가"가 반복됩니다.
이 글에서는 이 현상을 회의의 후행 비용이라고 부르겠습니다. 결정 자체는 한 시간이면 끝나지만, 그 결정을 일주일 동안 살려두는 비용이 결정 자체보다 큽니다. 그리고 이 비용은 AX의 가장 큰 공백인 Context Source 레이어에서 발생합니다.
이번 글은 오래 쓰여 온 회의 형식인 KPT 위에 티로 MCP를 적용하여 회의의 후행 비용을 크게 줄인 저희 팀의 AX 셋업 5단계 기록입니다.
KPT 회고는 왜 실행 단계에서 새는가?
KPT는 Keep(계속할 것), Problem(문제), Try(시도)의 세 축으로 회의를 진행하는 회고 형식입니다. 구조가 단순해 팀마다 자유롭게 변형해 쓰기 좋고, 한국 스타트업은 보통 Keep / Stop / Continue / Start로 바꿔 굴립니다. 저희 팀도 이 4분류를 사용합니다.
KPT의 강점은 명확합니다. 회의가 끝나면 모든 참여자가 동일한 형식으로 "다음 주에 무엇을 할 것인가"를 들고 나갑니다.
문제는 그 다음에 발생합니다. 결정된 액션이 어디로 흘러가야 하는지에 대한 합의는 형식 자체에 포함되어 있지 않습니다. KPT는 결정의 형식이지, 실행의 형식이 아닙니다. 그래서 일주일 동안 의도가 새고, 다음 KPT에서 "지난주에 결정한 것이 왜 안 됐는지"를 다시 논의하게 됩니다.
이전 글에서 다룬 AX 5-Layer 관점에서 보면, 회의록은 AX의 Context Source 레이어에 해당합니다. 그리고 이 레이어는 대부분의 조직에서 가장 큰 공백입니다.
회의록은 언제 LLM이 읽을 수 있는 데이터가 되는가?
이전 글에서 Conversation Intelligence를 정의했습니다. 음성 회의 데이터를 받아 AI가 활용할 수 있는 형태, 즉 LLM-Ready Data로 변환하는 카테고리입니다.
이 카테고리가 KPT에 직접적인 의미를 가지는 이유는 단순합니다. 회의록이 LLM-Ready Data가 되는 순간, 회의의 후행 비용은 자동화의 대상이 됩니다. 사람이 회의록을 다시 읽고, 액션을 추출하고, 태스크 도구에 옮겨 적는 일을 에이전트가 대신 할 수 있게 되기 때문입니다.
그러나 회의록을 LLM-Ready Data로 변환했다고 해서 자동화가 완성되는 것은 아닙니다. 그 데이터를 에이전트에게 어떻게 연결하느냐가 다음 질문입니다.
이 셋업에서 티로 MCP는 어떤 역할을 하는가?
직전 글에서 정리했듯이, 티로는 MCP와 API를 제공합니다. KPT 자동화 시나리오에서는 MCP가 사용됩니다.
티로 MCP는 회의록, 요약, 화자 분리 결과를 LLM이 직접 가져갈 수 있게 노출한 통로입니다. 노트 조회, 전사 본문 로드, 공유 링크, 위키 검색 같은 도구가 제공됩니다.
KPT 자동화 워크플로우에서 다루는 회의록의 무게는 가볍습니다. 한 회의의 액션 항목을 분류하는 작업은 본문 전체가 아니라 요약과 화자별 발언 단위로도 충분합니다. 즉 multi-turn reasoning의 영역이고, 그 자리에 MCP가 가장 적합합니다. 1시간 분량의 transcript 전체를 컨텍스트 윈도우에 부어 넣을 필요가 없습니다.
이 셋업에 함께 등장하는 다른 도구도 같은 원리로 자리를 잡았습니다. 슬랙은 비즈팀의 메신저 채널 맥락을 제공하는 Context Source이고, 리니어는 팀의 모든 태스크를 관리하는 이슈 트래킹 도구입니다. 티로, 슬랙, 리니어의 MCP 세 개가 이 셋업의 부품입니다.
5단계 셋업은 어떻게 구성되어 있는가?
KPT 회의 자체는 그대로 두고, 회의의 전후 흐름에 4개의 클로드 스킬을 넣었습니다.
[1] 회의 전 수집 → [2] KPT 회의 → [3] 회의 후 분류 (Tiro MCP)
│
↓
[4] Linear 자동 반영
│
↓
[5] 데일리 슬랙 푸시
│
└→ (다시 [1]로)
각 단계의 스킬을 차례로 풀어봅니다.
1단계. 회의 전 수집
회의 직전에 /kpt-before를 호출하면, 지난 화요일 KPT 이후부터 현재까지의 리니어 이슈 상태와 슬랙 메시지 맥락이 발표용 표로 정리됩니다.
~/.claude/skills/kpt-before.md
description: 화요일 KPT 직전, 지난 KPT 이후부터 지금까지 Linear/Slack 상태를 발표용 표로 정리.
기간 설정: 지난 화요일 18:00부터 지금까지Linear: assignee=본인 이슈를 Done / In progress / Blocked로 분류Slack: #biz 채널과 DM을 전체 스캔하여 액션·결정·수치·요청 4 카테고리로 분류표 4 섹션 출력
발표 자료를 사람이 30분 동안 손으로 정리하는 단계가 사라집니다. 수집은 자동화의 대상이고, 판단은 사람의 영역이라는 분업이 명확해집니다.
2단계. KPT 회의
이 단계는 자동화하지 않습니다. KPT의 가치는 사람들끼리 같은 자료를 보면서 결정에 합의하는 데 있습니다. 자동화의 대상이 아닙니다.
다만 모든 참여자가 발표 자료를 사전에 들고 들어오기 때문에, 회의에 드는 시간 자체는 단축됩니다.
3단계. 회의 후 분류
회의가 끝나는 순간 /kpt-after를 호출합니다. 이 단계가 셋업의 한가운데, 즉 티로 MCP가 작동하는 지점입니다.
~/.claude/skills/kpt-after.md
description: 화요일 비즈 KPT 직후, Tiro 회의록을 4 분류해 본인이 owner인 액션만 추출하고 Linear에 자동 반영.
Tiro MCP list_notes로 비즈 5인 참여자가 모두 포함된 노트 1건 식별get_note_transcript로 본문 로드팀 전체 액션을 Keep / Stop / Continue / Start로 분류owner=본인 항목만 표로 추출 (다음 한 발은 LLM 추론)kpt-linear-sync 스킬 자동 호출
회의록이 Conversation Intelligence의 정의 그대로 작동하는 순간입니다. 음성에서 출발한 회의 데이터가 화자 분리, 구조화, 메타데이터 첨부의 파이프라인을 거쳐 LLM-Ready Data가 되어, 다음 일주일의 입력값으로 곧장 흘러갑니다.
4단계. 리니어 자동 반영
~/.claude/skills/kpt-linear-sync.md
description: kpt-after 결과를 Linear tiro-ax 팀에 자동 반영.
Start : save_issue로 신규 이슈 생성 (due·priority는 회의록에서 추출)Continue : list_issues로 후보 3개 추림, quote 비교로 1개 선택, get_issue로 현재 상태 확인 후 업데이트Stop : 같은 방식으로 매칭, status=CanceledKeep : 변경 없음
3단계 직후 자동으로 호출됩니다. 한 가지 안전장치가 있습니다. 기존 이슈를 업데이트하기 전에 반드시 현재 상태를 먼저 조회합니다. 지난 일주일 사이에 동료가 description을 수정했거나 우선순위를 바꿨을 수 있기 때문입니다. 사람이 손댄 부분을 자동화가 덮어쓰지 않도록 막는 패턴입니다.
5단계. 데일리 슬랙 푸시
~/.claude/skills/daily-kpt-push.md
description: 매일 아침, Linear 이슈 중 오늘 집중할 1~3개를 Slack DM으로 push.
Linear active 이슈를 due / priority / 지연 기준으로 sort, 상위 3개 선별각 이슈의 "다음 한 발"을 description·코멘트에서 추출Slack DM에 카드 형식으로 푸시
(매일 9시 자동 실행: cron 또는 Claude Code Schedule)
상위 1~3개로 제한한 것은 의도된 설계입니다. 처음에는 active 이슈 전부를 푸시했고, 결과적으로 한 시간 안에 푸시 자체를 끄게 되는 현상이 발생했습니다. 사람이 하루에 의식적으로 다룰 수 있는 일은 통상 3개를 넘기 어렵습니다. 그 한계를 인정하고 정렬 기준을 단순화한 뒤에 푸시가 매일 그대로 따라가는 패턴이 잡혔습니다.
이 설계가 가르치는 것은 무엇인가?
이 셋업이 보여주는 것은 도구 몇 개의 조합이 아닙니다.
회의 전후의 흐름 자체를 다시 설계할 때 비로소 회의의 후행 비용이 사라진다는 점입니다. ChatGPT에 회의록 요약을 시키는 정도의 도구 교체로는 이 비용이 줄지 않습니다. Paul David가 1990년 논문에서 보여준 전기 모터의 교훈과 같은 구조입니다. 도구를 바꾸는 것은 몇 주면 가능하지만, 흐름의 재설계는 시간이 듭니다. 그리고 생산성은 언제나 후자에서만 발생합니다.
회의록의 본질도 함께 바뀝니다. 오랫동안 회의록은 "지나간 일을 적은 기록"이었습니다. 이 셋업 안에서 회의록은 다음 일주일을 굴리는 입력값입니다. 동일한 음성 파일에서 출발하더라도, 어디까지 변환하고 어디로 흘려보내느냐에 따라 완전히 다른 카테고리가 됩니다.
자주 묻는 질문
Q. MCP는 무엇인가요?
MCP(Model Context Protocol)는 앤트로픽이 공개한 오픈소스 표준입니다. AI 에이전트가 외부 도구와 데이터에 접근할 때 항상 같은 형식으로 대화할 수 있도록 설계된 프로토콜입니다. 자세한 내용은 API, MCP, CLI, Claude Skill: 무엇이 다르고, 언제 써야 하는가?에서 정리했습니다.
Q. 티로 MCP는 어떻게 사용하나요?
티로 계정과 연동된 MCP 서버를 클로드 데스크톱이나 클로드 코드에 설정하면, list_notes, get_note, get_note_transcript 같은 도구로 회의록에 직접 접근할 수 있습니다. 코드를 쓸 필요 없이 자연어로도 호출이 가능합니다. 전체 사양은 docs.tiro.ooo에서 확인할 수 있습니다.
Q. KPT 회고란 무엇인가요?
Keep(계속할 것), Problem(문제), Try(시도)의 세 축으로 지난 기간을 돌아보는 회고 형식입니다. 팀이 잘 굴러간 부분과 막힌 부분을 같은 틀 안에서 이야기하고, 다음 기간에 시도할 일을 합의하는 것이 목적입니다. 한국 스타트업에서는 Keep / Stop / Continue / Start의 4분류로 변형해 쓰는 경우가 많습니다.
Q. AX와의 관계는 무엇인가요?
AX 5-Layer 아키텍처에서 회의록은 Context Source 레이어의 핵심 영역입니다. 티로 MCP는 회의를 LLM-Ready Data로 변환한 뒤 에이전트의 자동화 안에 부품으로 끼울 수 있게 만든 통로이고, 본문의 5단계 셋업은 이 부품 위에서 KPT라는 회의 형식을 닫힌 루프로 만든 사례입니다.
Q. 같은 셋업을 우리 팀에도 적용할 수 있나요?
회의 형식이 KPT가 아니더라도 적용 가능합니다. 핵심은 세 가지입니다. (1) 회의가 LLM-Ready Data로 변환되어야 하고, (2) 그 데이터를 받아 액션을 분류하는 절차가 스킬로 명시화되어야 하며, (3) 분류 결과가 팀의 태스크 트래킹 도구로 흘러가야 합니다. 회의의 형식보다 회의 전후의 흐름이 본질입니다.
더 읽어볼 글
- 회의록 AI 15종 비교: 무엇을 언제 쓰면 되는가. 도구 선택 단계에서 먼저 읽으면 좋은 관문 글입니다.
- 상황별 AI 추천 (2026년). 회의 외의 업무 상황까지 포함해 도구를 고르는 기준을 정리했습니다.
- 티로와 클로바노트 비교. 한국어 회의록 도구 두 가지를 실제 조건으로 비교했습니다.
시작하기
이 글의 셋업을 직접 따라해 보고 싶다면 티로 무료 체험에서 시작할 수 있습니다. 3주 300분이 제공되며, MCP와 API도 함께 사용해 볼 수 있습니다.
