티로가 비즈니스 맥락을 기억하는 법 - MCP, API, CLI, Skill
"우리 팀, AI 도구는 다 깔았는데 정작 회의에서 뭘 결정했는지 AI가 모릅니다."
AX를 시작한 팀에서 가장 먼저 부딪히는 벽입니다. Notion은 연결했고, Jira도 붙였고, Slack도 MCP로 열었습니다. 그런데 이 모든 데이터를 만들어낸 원천, 즉 "왜 이 결정이 내려졌는가"를 담고 있는 회의 맥락은 AI 에이전트의 손이 닿지 않는 곳에 있습니다.
이유는 단순합니다. 비즈니스 맥락의 90%는 구두 대화에서 발생하고, 디지털화되지 않은 채 소실됩니다. Notion에 정리된 문서, Jira에 올라간 티켓, Slack에 남은 메시지. 이것들은 전체 맥락의 10%에 불과합니다. 나머지 90%는 "그 회의에서 누가 왜 그렇게 말했는지"에 들어 있고, 아무도 기록하지 않으면 다음 회의 전에 사라집니다.
이 빈 90%를 AI에게 넘겨주는 일을 Conversation Intelligence이라고 부릅니다. 회의 음성을 받아서, AI가 바로 읽을 수 있는 형태로 변환해 두는 거죠. 그런데 변환만 한다고 끝이 아닙니다. 어떻게 연결하느냐에 따라 AI가 일하는 모습이 완전히 달라집니다.
이전 글에서 AI 에이전트가 외부 시스템과 일하는 4가지 도구(API, MCP, CLI, Skill)의 차이를 정리했습니다. 이번 글에서는 한 발 더 들어가서, 사라지는 90%의 맥락을 AI 에이전트에게 연결하려면, 4가지 도구를 어떻게 사용해야 하는지. 티로가 이 문제를 어떻게 풀고 있는지를 구체적으로 보여드리겠습니다.
AX 5-Layer에서 가장 큰 빈 공간
AX에는 5개의 레이어가 있습니다. Context Source → Ontology → AI Model → Agentic Workflow → User Interface. 위쪽 세 레이어(AI Model, Agentic Workflow, UI)는 이미 치열한 경쟁이 벌어지고 있습니다. Claude, GPT 같은 모델은 매달 더 똑똑해지고, n8n이나 Zapier 같은 워크플로우 도구는 누구나 쓸 수 있고, Slack과 터미널은 이미 훌륭한 UI입니다.
그런데 바닥의 두 레이어, Context Source와 Ontology는 대부분의 조직에서 텅 비어 있습니다. 특히 Context Source에서 가장 큰 빈 공간이 회의와 대화 데이터입니다. 이 데이터들은 음성으로 존재하고, 끝나는 순간 사라지고, 누군가 의도적으로 변환하지 않으면 AI가 접근할 수 없습니다.
이 빈 공간을 채우는 소프트웨어를 Conversation Intelligence라고 부릅니다. 음성 회의 데이터를 받아서 AI가 활용할 수 있는 형태, 즉 LLM-Ready Data로 변환하는 것이 핵심 역할입니다.
맥락을 디지털화하는 것과, 에이전트에게 연결하는 것은 다릅니다
그런데 맥락을 디지털화하는 것만으로는 절반입니다. 나머지 절반은 그 맥락을 AI 에이전트가 실제로 쓸 수 있게 연결하는 것입니다. 회의록 한 건이 수천에서 수만 토큰인 세상에서, 연결 방식을 잘못 설계하면 오히려 에이전트가 느려집니다.
이전 글의 핵심을 한 줄로 요약하면 이렇습니다. 같은 데이터라도, AI 에이전트가 어떤 도구로 접근하느냐에 따라 결과가 가는 곳이 달라집니다. API를 쓰면 코드가 원하는 곳으로 보내고, MCP를 쓰면 챗봇이 그 자리에서 답을 하고, CLI를 쓰면 폴더에 파일로 떨어지고, Skill을 쓰면 다음 작업의 절차로 이어집니다. 4가지 도구는 대체재가 아니라, 결과물이 가는 곳이 다른 보완재라는 이야기였습니다.
Conversation Intelligence 제품에게 이 원칙은 특히 중요합니다. 다루는 데이터가 태생적으로 무겁기 때문입니다. 1시간짜리 회의록 하나가 수천~수만 토큰이고, 음성 파일은 한 건에 수백 MB까지 갑니다. 노트 30건을 한꺼번에 가져오면 백과사전 한 권 분량이 됩니다. 한 가지 도구에 전부 몰아넣으면 AI가 한 번에 들고 있을 수 있는 양을 금세 넘어섭니다.
그래서 티로는 API, MCP, CLI, Skill 네 가지를 모두 지원합니다.
전체 사양은 api-docs.tiro.ooo에서 확인할 수 있습니다.
API: 모든 것의 골격
티로의 API 아래에 45개 메서드가 4개 도메인(Notes, Folders, Voice Files, Word Memory)에 펼쳐져 있습니다. 다른 SaaS와 연결하거나, 자체 백엔드에서 호출하거나, 사내 도구를 만드는 모든 작업의 출발점입니다.
API가 빛나는 순간은 에이전트의 추론이 필요 없는 작업입니다. 예를 들면, 영업팀 회의가 끝나면 자동으로 세일즈포스에 기록되게 한다거나, 매주 월요일 오전에 지난주 회의 요약이 노션 한 페이지에 정리되어 있게 한다거나. 이런 작업은 IT 팀이 한 번 연결해두면 그 다음부터는 사람 손이 안 들어갑니다.
참고로 MCP도, CLI도 안쪽에서는 사실 이 API를 부르고 있습니다. 그래서 이 API를 “골격”이라고 부릅니다.
💻 실제 호출 예시는 글 끝의 "개발팀에 전달하실 때" 섹션에 모아 두었습니다.
MCP: 가벼운 맥락만 컨텍스트에 넣습니다
MCP는 챗봇이 회의 데이터에 직접 손을 뻗을 수 있게 해주는 길입니다. 클로드나 챗GPT에게 “지난 주 회의에서 결정된 것 중 진행 안 된 게 뭐지?”라고 물으면, 챗봇이 MCP를 타고 들어가서 직접 살펴보고 답을 주는 식입니다.
티로의 MCP 서버는 14개 도구를 6개 영역으로 구성했습니다. Authentication, Notes Discovery, Notes Retrieval, Templates, Share Links, Folders.
설계의 핵심은 토큰 예산을 단계적으로 쓰게 만드는 것 입니다. 영어로는 Progressive Disclosure라고 부르는 3단계 패턴으로 동작합니다.
1단계. “어떤 회의가 있었지?”같은 질문은 회의 목록과 짧은 매치 정보만 봐도 끝납니다. 따라서 list_notes 또는 search_notes로 메타데이터와 매치 스니펫만 먼저 가져옵니다. 노트당 수십~수백 토큰, 한 문단 분량. "어떤 회의가 있었지?" 같은 질문은 대부분 여기서 끝나죠.
2단계. 본문이 필요한 노트만 골라서get_note로 가져옵니다. include 옵션으로 요약이나 작성된 문서를 선택할 수 있고, 요약은 200~800 토큰 정도입니다.
3단계. 정말로 원문 발화 내용이 필요할 때만 get_note_transcript로 회의록 전체를 부릅니다. 3,000~5,000 토큰으로, 단편소설 한 편 분량입니다.
이렇게 단계를 나누면 일반적인 검색·요약 시나리오에서 토큰 사용량을 90% 이상 줄입니다. 10건의 회의 중 원하는 한 건을 찾을 때, 회의록 10건을 전부 불러오면 약 30,000 토큰이 들지만 list_notes(목록만) → get_note(후보만 요약) 패턴이면 약 800 토큰으로 끝납니다.
MCP가 빛나는 순간은 챗봇과 질문을 여러 번 주고받으면 판단을 좁혀가는 작업입니다. "지난주 회의에서 나온 결정 사항 중 아직 진행 안 된 게 뭐지?" 같은 질문이 대표적입니다. 목록을 훑고, 필요한 노트만 골라서 summary를 가져오고, 판단을 내리는 일련의 추론이 MCP의 영역입니다.
CLI: 무거운 짐은 폴더에 둡니다
분기 리뷰가 다가왔다고 해봅시다. 지난 90일 동안 고객사와 한 회의 12건을 전부 펼쳐서 회의록을 받아둬야 합니다. 이것을 모두 MCP로 부르면 챗봇이 한 번에 들고 있을 수 있는 양을 한참 넘깁니다.
CLI는 이런 큰 짐을 폴더에 떨궈 두는 길입니다. 명령어 한 줄이면, 지난 90일치 회의록 12건이 폴더에 마크다운으로 떨어집니다. 챗봇 손에 들리는 건 어디에 저장되었고, 크기가 얼마인지라는 영수증 한 장 뿐이니, 챗봇이 무거워지지 않습니다.
MCP로 같은 작업을 했다면 get_note_transcript를 12번 호출해야 하고, 그때마다 transcript 전체가 컨텍스트 윈도우로 들어갑니다. 12건이면 60~600KB의 dead weight이고요. CLI는 결과를 disk에 보내고, context에는 경로와 메타데이터만 남깁니다.
CLI가 빛나는 순간은 bulk 작업과 자동화입니다. 주간 리포트 자동 생성, CI/CD에서 회의 데이터 처리, cron으로 정기 export. disk와 pipe가 자연스러운 모든 곳에서 CLI가 일합니다.
💻 실제 명령어 예시도 글 끝의 부록에 모아 두었습니다.
Skill: 우리 팀만의 절차 매뉴얼
여기서 이야기가 한 단계 더 깊어집니다. API, MCP, CLI는 도구입니다. 도구는 쓰는 방법을 알아야 가치가 생기겠죠. 그 방법을 적어두는 것이 Skill입니다.
Skill은 SKILL.md라는 마크다운 파일에 절차적 지식을 적은 것입니다. 데이터를 가져오거나 행동을 일으키지는 않습니다. "이 task를 할 때는 이 순서로, 이런 도구를 써라" 라는 가이드를 적어두면, 에이전트가 그 절차대로 실행합니다.
이게 왜 중요한가 하면, 같은 Conversation Intelligence 데이터도 조직마다 쓰는 방식이 다르기 때문입니다. 컨설팅 회사는 고객 미팅 요약을 CRM에 연결하고, 제품팀은 스프린트 리뷰에서 나온 결정을 Linear 이슈로 만들고, 인사팀은 면접 기록을 온보딩 자료로 변환합니다. 데이터 소스는 같지만 워크플로는 전부 다릅니다.
몇 가지 실제 예시를 보겠습니다.
주간 지표 리뷰 Skill
---
name: weekly-metric-review
description: 주간 AARRR 지표 리뷰 미팅에서 결정 사항과 맥락을 추출할 때 사용
---
## 절차
1. 이번 주 지표 리뷰 회의를 검색한다
`tiro notes search "AARRR" --since 7d --json > metrics.jsonl`
2. 각 회의의 transcript를 disk에 저장한다
`cat metrics.jsonl | jq -r '.guid' | xargs -I{} tiro notes transcript {} --format md --output ./reviews/{}.md`
3. ./reviews/ 폴더의 .md 파일을 읽고 아래 기준으로 정리한다
- 숫자 변화의 *이유* (왜 이 지표가 올랐거나 내렸는가)
- 결정 사항과 담당자
- 다음 주까지의 실험 목록
4. 결과를 Notion 주간 리뷰 페이지에 업데이트한다
고객 미팅 분기 리뷰 Skill
---
name: quarterly-client-review
description: 특정 고객사의 지난 90일 미팅을 종합해 분기 리뷰를 생성할 때 사용
---
## 절차
1. 고객사 키워드로 지난 90일 회의를 검색한다
`tiro notes search "<고객사명>" --since 90d --json > client.jsonl`
2. transcript를 disk에 저장한다
`cat client.jsonl | jq -r '.guid' | xargs -I{} tiro notes transcript {} --format md --output ./client-reviews/{}.md`
3. 전체 transcript를 읽고 아래 기준으로 분기 리뷰를 작성한다
- 주요 논의 주제의 변화 추이
- 미결 이슈와 리스크
- 관계 건강도 (긍정/부정 시그널)
4. 결과를 Slack #account-reviews 채널에 게시한다
패턴이 보이시나요? CLI가 무거운 데이터를 disk에 깔아두고, MCP가 가벼운 metadata로 판단을 내리고, Skill이 그 순서를 기억합니다. 이전 글의 비유를 빌리면, 발이 짐을 옮기고, 손이 정밀하게 다루고, 근육 기억이 순서를 외우는 구조입니다.
Read → Reason → Act → Learn
Skill이 단순한 스크립트 모음이 아닌 이유가 있습니다. 잘 설계된 Skill은 순환 구조를 만듭니다.
Read. CLI로 회의 맥락을 disk에 가져옵니다. MCP로 metadata와 요약을 읽습니다.
Reason. 에이전트가 가져온 맥락을 바탕으로 판단합니다. "이 고객은 지난 세 번의 미팅에서 같은 불만을 반복하고 있다", "이 지표가 3주 연속 하락하고 있다" 같은 패턴 인식.
Act. 판단에 따라 행동합니다. Linear에 이슈를 만들거나, Slack에 알림을 보내거나, 리포트를 생성합니다.
Learn. 행동의 결과가 다음 회의에서 다시 논의됩니다. 그 회의도 다시 티로에 기록되고, 다음 Skill 실행에서 참조됩니다. 루프가 닫힙니다.
티로를 도입하는 것은 녹음기를 도입하는 것이 아닙니다. 워크플로우를 도입하는 것입니다. 회의 → 맥락 보존 → 에이전트 실행 → 결과 피드백 → 다음 회의. 이 순환 구조가 돌 때, 조직의 회의가 비로소 자산이 됩니다.
맥락이 무거운 제품이 빠지기 쉬운 함정
이 설계는 티로에 국한되지 않습니다. Conversation Intelligence뿐 아니라, 맥락이 자연스럽게 무거워지는 모든 제품에 해당합니다. 이전 글에서 Scalekit의 32배 토큰 차이 벤치마크를 소개했는데요. MCP 하나에 모든 것을 실으면 컨텍스트 윈도우가 터지고, CLI 하나로 다 처리하면 multi-turn reasoning을 잃습니다.
AX 도입을 고민하고 있는 팀이라면, 이 질문을 먼저 해보세요.
우리 조직에서 AI가 접근하지 못하는 맥락은 어디에 있나요? 그리고 그 맥락을 AI에게 연결할 때, 결과물은 에이전트의 컨텍스트 안에 있어야 하나요, 파일로 저장되면 되나요?
첫 번째 질문이 Context Source 레이어를 가리키고, 두 번째 질문이 도구 선택을 가리킵니다. 이 두 질문에 답할 수 있을 때, AX는 10%에서 움직이기 시작합니다.
자주 묻는 질문
Q. Conversation Intelligence란 뭔가요?
회의와 통화 같은 음성 대화를 받아서, AI가 활용할 수 있는 형태(LLM-Ready Data)로 변환하는 소프트웨어입니다. AX 5-Layer 아키텍처에서 Context Source 레이어의 핵심 영역이며, 기업의 비즈니스 맥락 중 디지털화되지 않은 90%(구두 대화)를 채우는 역할을 합니다.
Q. 티로의 MCP에는 어떤 도구가 있나요?
14개 도구가 6개 영역에 걸쳐 있습니다. Notes Discovery(list_notes, search_notes), Notes Retrieval(get_note, get_note_transcript), Templates, Share Links, Folders, Authentication. Progressive Disclosure 패턴으로 토큰을 단계적으로 씁니다. 전체 목록은 api-docs.tiro.ooo/mcp에서 확인할 수 있습니다.
Q. Skill.md는 누가 만드나요?
조직의 AX 담당자나 엔지니어가 만듭니다. 마크다운 파일 하나에 절차를 적으면 되기 때문에 코딩 지식이 반드시 필요하지는 않습니다. 중요한 건 "우리 팀이 회의 데이터를 어떤 순서로, 어디에 활용하는가" 를 명시화하는 것이고요. 한 번 만들어두면 팀 전체가 같은 절차를 일관되게 실행할 수 있습니다.
Q. MCP와 CLI를 언제 나눠서 써야 하나요?
결과물이 어디로 가느냐가 기준입니다. 에이전트의 컨텍스트 안에서 reasoning에 쓰여야 하면 MCP, 파일로 저장되어야 하면 CLI입니다. 노트 한 건의 요약(수백 토큰)은 MCP로, transcript 10건의 bulk export(수 MB)는 CLI로 처리하는 것이 자연스럽습니다. 자세한 결정 트리는 이전 글에서 다뤘습니다.
Q. 이미 회의록 도구를 쓰고 있는데, 뭐가 다른가요?
단순 회의록 도구는 기록에서 멈춥니다. 티로가 4가지 도구(API, MCP, CLI, Skill)를 모두 지원하는 이유는, 기록된 맥락이 AI 에이전트의 워크플로까지 흘러가야 AX가 성립하기 때문입니다. 녹음기를 도입하는 것과 워크플로우를 도입하는 것은 다릅니다.
더 읽어볼 글
시작하기
티로의 API, MCP, CLI 사양은 api-docs.tiro.ooo에서 확인할 수 있습니다.
📎 부록
코드를 직접 보셔야 하는 분들을 위해, 본문에서 빼둔 호출 예시를 여기 모아둡니다.
API 호출 예시
curl -H "Authorization: Bearer $TIRO_API_KEY" \
https://api.tiro.ooo/v1/external/notes
OpenAPI spec을 공개하고 있어서 SDK 자동 생성이나 Postman 임포트가 자유롭습니다.
CLI 일괄 처리 예시
tiro 명령어에서 transcript를 disk에 저장하고, 검색 결과를 NDJSON으로 pipe하고, jq와 조합합니다.
예를 들어 분기 리뷰를 위해 지난 30일간의 "Acme Corp" 회의를 모두 찾아서 transcript를 내려받는 작업은 이렇게 됩니다.
# 검색 → 메타데이터를 NDJSON으로
tiro notes search "Acme Corp" --since 30d --json > /tmp/acme.jsonl
# 한 건씩 transcript를 disk에 저장
cat /tmp/acme.jsonl \
| jq -r '.guid' \
| xargs -I{} tiro notes transcript {} --format md --output ./out/{}.md
--output을 쓰면 stdout에는 메타데이터 한 줄만 남습니다.
{"saved":"./out/abc123.md","size":5234,"format":"md","guid":"abc123","paragraphCount":42}
Skill 파일 예시 (주간 지표 리뷰)
---
name: weekly-metric-review
description: 주간 AARRR 지표 리뷰 미팅에서 결정 사항과 맥락을 추출할 때 사용
---
## 절차
1. 이번 주 지표 리뷰 회의를 검색한다
`tiro notes search "AARRR" --since 7d --json > metrics.jsonl`
2. 각 회의의 transcript를 disk에 저장한다
`cat metrics.jsonl | jq -r '.guid' | xargs -I{} tiro notes transcript {} --format md --output ./reviews/{}.md`
3. ./reviews/ 폴더의 .md 파일을 읽고 아래 기준으로 정리한다
- 숫자 변화의 *이유* (왜 이 지표가 올랐거나 내렸는가)
- 결정 사항과 담당자
- 다음 주까지의 실험 목록
4. 결과를 Notion 주간 리뷰 페이지에 업데이트한다
전체 API·MCP·CLI 사양은 api-docs.tiro.ooo에서 확인하실 수 있습니다.
"우리 팀, AI 도구는 다 깔았는데 정작 회의에서 뭘 결정했는지 AI가 모릅니다."
AX를 시작한 팀에서 가장 먼저 부딪히는 벽입니다. Notion은 연결했고, Jira도 붙였고, Slack도 MCP로 열었습니다. 그런데 이 모든 데이터를 만들어낸 원천, 즉 "왜 이 결정이 내려졌는가"를 담고 있는 회의 맥락은 AI 에이전트의 손이 닿지 않는 곳에 있습니다.
이유는 단순합니다. 비즈니스 맥락의 90%는 구두 대화에서 발생하고, 디지털화되지 않은 채 소실됩니다. Notion에 정리된 문서, Jira에 올라간 티켓, Slack에 남은 메시지. 이것들은 전체 맥락의 10%에 불과합니다. 나머지 90%는 "그 회의에서 누가 왜 그렇게 말했는지"에 들어 있고, 아무도 기록하지 않으면 다음 회의 전에 사라집니다.
이 빈 90%를 AI에게 넘겨주는 일을 Conversation Intelligence이라고 부릅니다. 회의 음성을 받아서, AI가 바로 읽을 수 있는 형태로 변환해 두는 거죠. 그런데 변환만 한다고 끝이 아닙니다. 어떻게 연결하느냐에 따라 AI가 일하는 모습이 완전히 달라집니다.
이전 글에서 AI 에이전트가 외부 시스템과 일하는 4가지 도구(API, MCP, CLI, Skill)의 차이를 정리했습니다. 이번 글에서는 한 발 더 들어가서, 사라지는 90%의 맥락을 AI 에이전트에게 연결하려면, 4가지 도구를 어떻게 사용해야 하는지. 티로가 이 문제를 어떻게 풀고 있는지를 구체적으로 보여드리겠습니다.
AX 5-Layer에서 가장 큰 빈 공간
AX에는 5개의 레이어가 있습니다. Context Source → Ontology → AI Model → Agentic Workflow → User Interface. 위쪽 세 레이어(AI Model, Agentic Workflow, UI)는 이미 치열한 경쟁이 벌어지고 있습니다. Claude, GPT 같은 모델은 매달 더 똑똑해지고, n8n이나 Zapier 같은 워크플로우 도구는 누구나 쓸 수 있고, Slack과 터미널은 이미 훌륭한 UI입니다.
그런데 바닥의 두 레이어, Context Source와 Ontology는 대부분의 조직에서 텅 비어 있습니다. 특히 Context Source에서 가장 큰 빈 공간이 회의와 대화 데이터입니다. 이 데이터들은 음성으로 존재하고, 끝나는 순간 사라지고, 누군가 의도적으로 변환하지 않으면 AI가 접근할 수 없습니다.
이 빈 공간을 채우는 소프트웨어를 Conversation Intelligence라고 부릅니다. 음성 회의 데이터를 받아서 AI가 활용할 수 있는 형태, 즉 LLM-Ready Data로 변환하는 것이 핵심 역할입니다.
맥락을 디지털화하는 것과, 에이전트에게 연결하는 것은 다릅니다
그런데 맥락을 디지털화하는 것만으로는 절반입니다. 나머지 절반은 그 맥락을 AI 에이전트가 실제로 쓸 수 있게 연결하는 것입니다. 회의록 한 건이 수천에서 수만 토큰인 세상에서, 연결 방식을 잘못 설계하면 오히려 에이전트가 느려집니다.
이전 글의 핵심을 한 줄로 요약하면 이렇습니다. 같은 데이터라도, AI 에이전트가 어떤 도구로 접근하느냐에 따라 결과가 가는 곳이 달라집니다. API를 쓰면 코드가 원하는 곳으로 보내고, MCP를 쓰면 챗봇이 그 자리에서 답을 하고, CLI를 쓰면 폴더에 파일로 떨어지고, Skill을 쓰면 다음 작업의 절차로 이어집니다. 4가지 도구는 대체재가 아니라, 결과물이 가는 곳이 다른 보완재라는 이야기였습니다.
Conversation Intelligence 제품에게 이 원칙은 특히 중요합니다. 다루는 데이터가 태생적으로 무겁기 때문입니다. 1시간짜리 회의록 하나가 수천~수만 토큰이고, 음성 파일은 한 건에 수백 MB까지 갑니다. 노트 30건을 한꺼번에 가져오면 백과사전 한 권 분량이 됩니다. 한 가지 도구에 전부 몰아넣으면 AI가 한 번에 들고 있을 수 있는 양을 금세 넘어섭니다.
그래서 티로는 API, MCP, CLI, Skill 네 가지를 모두 지원합니다.
전체 사양은 api-docs.tiro.ooo에서 확인할 수 있습니다.
API: 모든 것의 골격
티로의 API 아래에 45개 메서드가 4개 도메인(Notes, Folders, Voice Files, Word Memory)에 펼쳐져 있습니다. 다른 SaaS와 연결하거나, 자체 백엔드에서 호출하거나, 사내 도구를 만드는 모든 작업의 출발점입니다.
API가 빛나는 순간은 에이전트의 추론이 필요 없는 작업입니다. 예를 들면, 영업팀 회의가 끝나면 자동으로 세일즈포스에 기록되게 한다거나, 매주 월요일 오전에 지난주 회의 요약이 노션 한 페이지에 정리되어 있게 한다거나. 이런 작업은 IT 팀이 한 번 연결해두면 그 다음부터는 사람 손이 안 들어갑니다.
참고로 MCP도, CLI도 안쪽에서는 사실 이 API를 부르고 있습니다. 그래서 이 API를 “골격”이라고 부릅니다.
💻 실제 호출 예시는 글 끝의 "개발팀에 전달하실 때" 섹션에 모아 두었습니다.
MCP: 가벼운 맥락만 컨텍스트에 넣습니다
MCP는 챗봇이 회의 데이터에 직접 손을 뻗을 수 있게 해주는 길입니다. 클로드나 챗GPT에게 “지난 주 회의에서 결정된 것 중 진행 안 된 게 뭐지?”라고 물으면, 챗봇이 MCP를 타고 들어가서 직접 살펴보고 답을 주는 식입니다.
티로의 MCP 서버는 14개 도구를 6개 영역으로 구성했습니다. Authentication, Notes Discovery, Notes Retrieval, Templates, Share Links, Folders.
설계의 핵심은 토큰 예산을 단계적으로 쓰게 만드는 것 입니다. 영어로는 Progressive Disclosure라고 부르는 3단계 패턴으로 동작합니다.
1단계. “어떤 회의가 있었지?”같은 질문은 회의 목록과 짧은 매치 정보만 봐도 끝납니다. 따라서 list_notes 또는 search_notes로 메타데이터와 매치 스니펫만 먼저 가져옵니다. 노트당 수십~수백 토큰, 한 문단 분량. "어떤 회의가 있었지?" 같은 질문은 대부분 여기서 끝나죠.
2단계. 본문이 필요한 노트만 골라서get_note로 가져옵니다. include 옵션으로 요약이나 작성된 문서를 선택할 수 있고, 요약은 200~800 토큰 정도입니다.
3단계. 정말로 원문 발화 내용이 필요할 때만 get_note_transcript로 회의록 전체를 부릅니다. 3,000~5,000 토큰으로, 단편소설 한 편 분량입니다.
이렇게 단계를 나누면 일반적인 검색·요약 시나리오에서 토큰 사용량을 90% 이상 줄입니다. 10건의 회의 중 원하는 한 건을 찾을 때, 회의록 10건을 전부 불러오면 약 30,000 토큰이 들지만 list_notes(목록만) → get_note(후보만 요약) 패턴이면 약 800 토큰으로 끝납니다.
MCP가 빛나는 순간은 챗봇과 질문을 여러 번 주고받으면 판단을 좁혀가는 작업입니다. "지난주 회의에서 나온 결정 사항 중 아직 진행 안 된 게 뭐지?" 같은 질문이 대표적입니다. 목록을 훑고, 필요한 노트만 골라서 summary를 가져오고, 판단을 내리는 일련의 추론이 MCP의 영역입니다.
CLI: 무거운 짐은 폴더에 둡니다
분기 리뷰가 다가왔다고 해봅시다. 지난 90일 동안 고객사와 한 회의 12건을 전부 펼쳐서 회의록을 받아둬야 합니다. 이것을 모두 MCP로 부르면 챗봇이 한 번에 들고 있을 수 있는 양을 한참 넘깁니다.
CLI는 이런 큰 짐을 폴더에 떨궈 두는 길입니다. 명령어 한 줄이면, 지난 90일치 회의록 12건이 폴더에 마크다운으로 떨어집니다. 챗봇 손에 들리는 건 어디에 저장되었고, 크기가 얼마인지라는 영수증 한 장 뿐이니, 챗봇이 무거워지지 않습니다.
MCP로 같은 작업을 했다면 get_note_transcript를 12번 호출해야 하고, 그때마다 transcript 전체가 컨텍스트 윈도우로 들어갑니다. 12건이면 60~600KB의 dead weight이고요. CLI는 결과를 disk에 보내고, context에는 경로와 메타데이터만 남깁니다.
CLI가 빛나는 순간은 bulk 작업과 자동화입니다. 주간 리포트 자동 생성, CI/CD에서 회의 데이터 처리, cron으로 정기 export. disk와 pipe가 자연스러운 모든 곳에서 CLI가 일합니다.
💻 실제 명령어 예시도 글 끝의 부록에 모아 두었습니다.
Skill: 우리 팀만의 절차 매뉴얼
여기서 이야기가 한 단계 더 깊어집니다. API, MCP, CLI는 도구입니다. 도구는 쓰는 방법을 알아야 가치가 생기겠죠. 그 방법을 적어두는 것이 Skill입니다.
Skill은 SKILL.md라는 마크다운 파일에 절차적 지식을 적은 것입니다. 데이터를 가져오거나 행동을 일으키지는 않습니다. "이 task를 할 때는 이 순서로, 이런 도구를 써라" 라는 가이드를 적어두면, 에이전트가 그 절차대로 실행합니다.
이게 왜 중요한가 하면, 같은 Conversation Intelligence 데이터도 조직마다 쓰는 방식이 다르기 때문입니다. 컨설팅 회사는 고객 미팅 요약을 CRM에 연결하고, 제품팀은 스프린트 리뷰에서 나온 결정을 Linear 이슈로 만들고, 인사팀은 면접 기록을 온보딩 자료로 변환합니다. 데이터 소스는 같지만 워크플로는 전부 다릅니다.
몇 가지 실제 예시를 보겠습니다.
주간 지표 리뷰 Skill
---
name: weekly-metric-review
description: 주간 AARRR 지표 리뷰 미팅에서 결정 사항과 맥락을 추출할 때 사용
---
## 절차
1. 이번 주 지표 리뷰 회의를 검색한다
`tiro notes search "AARRR" --since 7d --json > metrics.jsonl`
2. 각 회의의 transcript를 disk에 저장한다
`cat metrics.jsonl | jq -r '.guid' | xargs -I{} tiro notes transcript {} --format md --output ./reviews/{}.md`
3. ./reviews/ 폴더의 .md 파일을 읽고 아래 기준으로 정리한다
- 숫자 변화의 *이유* (왜 이 지표가 올랐거나 내렸는가)
- 결정 사항과 담당자
- 다음 주까지의 실험 목록
4. 결과를 Notion 주간 리뷰 페이지에 업데이트한다
고객 미팅 분기 리뷰 Skill
---
name: quarterly-client-review
description: 특정 고객사의 지난 90일 미팅을 종합해 분기 리뷰를 생성할 때 사용
---
## 절차
1. 고객사 키워드로 지난 90일 회의를 검색한다
`tiro notes search "<고객사명>" --since 90d --json > client.jsonl`
2. transcript를 disk에 저장한다
`cat client.jsonl | jq -r '.guid' | xargs -I{} tiro notes transcript {} --format md --output ./client-reviews/{}.md`
3. 전체 transcript를 읽고 아래 기준으로 분기 리뷰를 작성한다
- 주요 논의 주제의 변화 추이
- 미결 이슈와 리스크
- 관계 건강도 (긍정/부정 시그널)
4. 결과를 Slack #account-reviews 채널에 게시한다
패턴이 보이시나요? CLI가 무거운 데이터를 disk에 깔아두고, MCP가 가벼운 metadata로 판단을 내리고, Skill이 그 순서를 기억합니다. 이전 글의 비유를 빌리면, 발이 짐을 옮기고, 손이 정밀하게 다루고, 근육 기억이 순서를 외우는 구조입니다.
Read → Reason → Act → Learn
Skill이 단순한 스크립트 모음이 아닌 이유가 있습니다. 잘 설계된 Skill은 순환 구조를 만듭니다.
Read. CLI로 회의 맥락을 disk에 가져옵니다. MCP로 metadata와 요약을 읽습니다.
Reason. 에이전트가 가져온 맥락을 바탕으로 판단합니다. "이 고객은 지난 세 번의 미팅에서 같은 불만을 반복하고 있다", "이 지표가 3주 연속 하락하고 있다" 같은 패턴 인식.
Act. 판단에 따라 행동합니다. Linear에 이슈를 만들거나, Slack에 알림을 보내거나, 리포트를 생성합니다.
Learn. 행동의 결과가 다음 회의에서 다시 논의됩니다. 그 회의도 다시 티로에 기록되고, 다음 Skill 실행에서 참조됩니다. 루프가 닫힙니다.
티로를 도입하는 것은 녹음기를 도입하는 것이 아닙니다. 워크플로우를 도입하는 것입니다. 회의 → 맥락 보존 → 에이전트 실행 → 결과 피드백 → 다음 회의. 이 순환 구조가 돌 때, 조직의 회의가 비로소 자산이 됩니다.
맥락이 무거운 제품이 빠지기 쉬운 함정
이 설계는 티로에 국한되지 않습니다. Conversation Intelligence뿐 아니라, 맥락이 자연스럽게 무거워지는 모든 제품에 해당합니다. 이전 글에서 Scalekit의 32배 토큰 차이 벤치마크를 소개했는데요. MCP 하나에 모든 것을 실으면 컨텍스트 윈도우가 터지고, CLI 하나로 다 처리하면 multi-turn reasoning을 잃습니다.
AX 도입을 고민하고 있는 팀이라면, 이 질문을 먼저 해보세요.
우리 조직에서 AI가 접근하지 못하는 맥락은 어디에 있나요? 그리고 그 맥락을 AI에게 연결할 때, 결과물은 에이전트의 컨텍스트 안에 있어야 하나요, 파일로 저장되면 되나요?
첫 번째 질문이 Context Source 레이어를 가리키고, 두 번째 질문이 도구 선택을 가리킵니다. 이 두 질문에 답할 수 있을 때, AX는 10%에서 움직이기 시작합니다.
자주 묻는 질문
Q. Conversation Intelligence란 뭔가요?
회의와 통화 같은 음성 대화를 받아서, AI가 활용할 수 있는 형태(LLM-Ready Data)로 변환하는 소프트웨어입니다. AX 5-Layer 아키텍처에서 Context Source 레이어의 핵심 영역이며, 기업의 비즈니스 맥락 중 디지털화되지 않은 90%(구두 대화)를 채우는 역할을 합니다.
Q. 티로의 MCP에는 어떤 도구가 있나요?
14개 도구가 6개 영역에 걸쳐 있습니다. Notes Discovery(list_notes, search_notes), Notes Retrieval(get_note, get_note_transcript), Templates, Share Links, Folders, Authentication. Progressive Disclosure 패턴으로 토큰을 단계적으로 씁니다. 전체 목록은 api-docs.tiro.ooo/mcp에서 확인할 수 있습니다.
Q. Skill.md는 누가 만드나요?
조직의 AX 담당자나 엔지니어가 만듭니다. 마크다운 파일 하나에 절차를 적으면 되기 때문에 코딩 지식이 반드시 필요하지는 않습니다. 중요한 건 "우리 팀이 회의 데이터를 어떤 순서로, 어디에 활용하는가" 를 명시화하는 것이고요. 한 번 만들어두면 팀 전체가 같은 절차를 일관되게 실행할 수 있습니다.
Q. MCP와 CLI를 언제 나눠서 써야 하나요?
결과물이 어디로 가느냐가 기준입니다. 에이전트의 컨텍스트 안에서 reasoning에 쓰여야 하면 MCP, 파일로 저장되어야 하면 CLI입니다. 노트 한 건의 요약(수백 토큰)은 MCP로, transcript 10건의 bulk export(수 MB)는 CLI로 처리하는 것이 자연스럽습니다. 자세한 결정 트리는 이전 글에서 다뤘습니다.
Q. 이미 회의록 도구를 쓰고 있는데, 뭐가 다른가요?
단순 회의록 도구는 기록에서 멈춥니다. 티로가 4가지 도구(API, MCP, CLI, Skill)를 모두 지원하는 이유는, 기록된 맥락이 AI 에이전트의 워크플로까지 흘러가야 AX가 성립하기 때문입니다. 녹음기를 도입하는 것과 워크플로우를 도입하는 것은 다릅니다.
더 읽어볼 글
시작하기
📎 부록
코드를 직접 보셔야 하는 분들을 위해, 본문에서 빼둔 호출 예시를 여기 모아둡니다.
API 호출 예시
curl -H "Authorization: Bearer $TIRO_API_KEY" \
https://api.tiro.ooo/v1/external/notes
OpenAPI spec을 공개하고 있어서 SDK 자동 생성이나 Postman 임포트가 자유롭습니다.
CLI 일괄 처리 예시
tiro 명령어에서 transcript를 disk에 저장하고, 검색 결과를 NDJSON으로 pipe하고, jq와 조합합니다.
예를 들어 분기 리뷰를 위해 지난 30일간의 "Acme Corp" 회의를 모두 찾아서 transcript를 내려받는 작업은 이렇게 됩니다.
# 검색 → 메타데이터를 NDJSON으로
tiro notes search "Acme Corp" --since 30d --json > /tmp/acme.jsonl
# 한 건씩 transcript를 disk에 저장
cat /tmp/acme.jsonl \
| jq -r '.guid' \
| xargs -I{} tiro notes transcript {} --format md --output ./out/{}.md
--output을 쓰면 stdout에는 메타데이터 한 줄만 남습니다.
{"saved":"./out/abc123.md","size":5234,"format":"md","guid":"abc123","paragraphCount":42}
Skill 파일 예시 (주간 지표 리뷰)
---
name: weekly-metric-review
description: 주간 AARRR 지표 리뷰 미팅에서 결정 사항과 맥락을 추출할 때 사용
---
## 절차
1. 이번 주 지표 리뷰 회의를 검색한다
`tiro notes search "AARRR" --since 7d --json > metrics.jsonl`
2. 각 회의의 transcript를 disk에 저장한다
`cat metrics.jsonl | jq -r '.guid' | xargs -I{} tiro notes transcript {} --format md --output ./reviews/{}.md`
3. ./reviews/ 폴더의 .md 파일을 읽고 아래 기준으로 정리한다
- 숫자 변화의 *이유* (왜 이 지표가 올랐거나 내렸는가)
- 결정 사항과 담당자
- 다음 주까지의 실험 목록
4. 결과를 Notion 주간 리뷰 페이지에 업데이트한다
전체 API·MCP·CLI 사양은 api-docs.tiro.ooo에서 확인하실 수 있습니다.