회의가 끝나면 브라우저를 열지 않는다, 팀 업무 도구에 MCP를 붙이고 달라진 것

왜 만들었나

혼자 쓰는 도구가 아니라, 같이 일하는 도구가 필요했다

일을 하다 보면 기록은 늘 흩어진다. 회의 내용은 누군가의 노트에, 결정사항은 메신저 어딘가에, 할 일은 각자의 메모장에 남는다. 회의 때 분명히 정한 일인데 일주일 뒤에 "그거 누가 하기로 했었지?"라는 말이 나온다. 혼자 정리를 잘한다고 해결되는 문제가 아니었다. 팀이 같은 기록을 보고, 같은 할 일 목록을 기준으로 움직여야 했다.

그래서 팀이 함께 쓰는 업무 서비스를 직접 만들었다. 회의록을 올리면 요약, 결정사항, 할 일이 정리되고, 그 할 일이 담당자의 「오늘」 화면, 일정, 마일스톤, 주간보고로 이어진다. 회의록 하나에서 팀 전체의 일정과 할 일이 만들어지는 구조다. 팀원들은 같은 워크스페이스에서 같은 기록을 보고, 권한에 따라 직접 고칠 수도 있다.

그런데 정작 나는 터미널에 있었다

문제는 나 자신이었다. 하루 대부분을 이 서비스가 아니라 터미널에서 보낸다. 회사 PC에서 Claude Code를 켜두고 개발도 하고 문서도 쓴다. 그러다 "이번 주에 뭐 하기로 했더라" 싶으면 하던 일을 멈추고 브라우저를 열고, 로그인하고, 할 일 화면을 찾아 들어가야 했다. 한 번이면 별일 아니지만, 하루에 몇 번씩 반복되니 흐름이 계속 끊겼다.

회의가 끝나면 정리가 또 하나의 일이었다

팀이 함께 보는 기록이 되려면 누군가는 회의를 정리해서 올려야 한다. 녹음을 듣고, 요약을 쓰고, 결정사항과 할 일을 뽑아서 하나씩 옮긴다. 회의보다 정리가 더 귀찮을 때도 있었다. 정리가 늦어지면 팀원들은 그만큼 늦게 할 일을 받는다.

그래서 바라는 모습은 두 가지였다.

1. 터미널에서 "이번 주 내 할 일 보여줘"라고 물으면 팀 서비스에 쌓인 데이터로 답이 온다.
2. "오늘 회의록 올려줘" 한마디로 녹음 정리부터 등록까지 끝나고, 팀원들이 바로 볼 수 있다.

이걸 가능하게 해주는 연결 방식이 MCP(Model Context Protocol)다.

어떤 구조로 되어 있나

한 줄 요약: AI가 쓸 수 있는 도구 상자를 서비스가 직접 내준다

MCP는 AI 도구(여기서는 Claude Code)와 다른 서비스를 잇는 표준 연결 방식이다. 서비스가 "나는 이런 기능들을 갖고 있고, 각 기능은 이런 정보를 받는다"는 목록을 내주면, Claude Code는 연결하는 순간 그 목록을 받아 필요한 기능을 알아서 골라 쓴다.

사용자 입장에서 중요한 건 이 점이다. 사용 설명서를 따로 써줄 필요가 없다. 설명은 서비스 서버 안에 들어 있고, 기능이 바뀌어도 서버만 고치면 된다. 팀원마다 설정 문서를 따로 챙길 필요도 없다.

연결은 명령 한 줄

서비스 설정 화면의 「외부 접근」 카드에서 토큰을 발급하면, Claude Code 등록 명령이 토큰까지 채워진 채로 나온다. [명령 복사]를 눌러 터미널에 붙이면 연결이 끝난다.

claude mcp add --transport http team-tool https://<주소>/api/mcp \
  --header "Authorization: Bearer <토큰>" --scope user

토큰 원문은 발급 직후 한 번만 보여주고, 그 뒤에는 끝 4자리만 남는다.

토큰마다 볼 수 있는 범위와 할 수 있는 일이 정해진다

팀이 함께 쓰는 서비스라 권한 구분이 특히 중요했다. 토큰을 발급할 때 두 가지를 정한다.

• 어느 워크스페이스인가. 토큰 하나는 워크스페이스 하나만 볼 수 있다. 회사 PC에서 토큰이 유출되더라도 다른 팀의 공간은 열리지 않는다.
• 읽기만 할 것인가, 쓰기도 할 것인가. 처음엔 읽기 전용으로 시작하고, 쓰기가 필요해지면 그때 따로 발급하면 된다.

읽기 전용 토큰으로 연결하면 쓰기 기능은 목록에 아예 나타나지 않는다. 막혀 있는 게 아니라 처음부터 없는 것이다. MCP로 연결해도 팀 안에서 정한 권한은 그대로 적용된다. 보기 전용 권한인 팀원에게는 회의록 원문 자체가 응답에 들어가지 않고, 가계부는 관리자 이상만 읽을 수 있다.

쓸 수 있는 기능 19개

읽기 16개, 쓰기 3개다. 쓰기는 미리보기 → 적용 → 롤백 세 단계가 한 세트다. AI가 바로 데이터를 바꾸지 않고, 무엇을 바꿀지 먼저 보여준 뒤 내가 확인하면 적용한다.

AI가 바꾼 기록은 팀이 보는 화면에 남는다

서비스 웹 화면의 어시스턴트에는 「채팅 / MCP」 탭이 있다. MCP 탭에는 Claude Code가 어떤 토큰으로, 언제, 무엇을, 몇 건 바꿨는지가 쌓이고, 마음에 안 드는 변경은 거기서 [롤백]으로 취소한다. AI가 팀 데이터를 바꾼 기록이 팀 모두가 볼 수 있는 곳에 남는 셈이다.

회의 정리는 MCP 두 개를 잇는다

회의 녹음은 Tiro로 한다. Tiro도 MCP를 제공하기 때문에, Claude Code 스킬 하나가 Tiro와 서비스를 이어준다.

1. 회의를 Tiro로 녹음한다.
2. Claude Code에서 "오늘 회의록 올려줘"라고 입력한다.
3. Claude Code가 Tiro에서 전사본을 읽고, 정해둔 템플릿(정기 회의, 외부 미팅, 결정 회의)으로 요약, 결정사항, 할 일을 정리한다.
4. 정리안을 보여주고, 내가 확인하면 서비스에 올린다.
5. 결정사항과 할 일을 방금 만든 회의록에 연결한다. 이때부터 팀원들도 같은 회의록과 할 일을 본다.

반대 방향의 연결도 있다. 팀원이 서비스에 새 회의록을 올리면 내 Claude Code 세션에 한 줄 알림이 뜬다. PC를 꺼둔 사이에 올라온 회의록도 다음에 켤 때 알려준다.

이걸 하면 뭐가 좋은가

1. 팀의 기록이 한곳에 모인다

회의록, 결정사항, 할 일이 각자의 메모장이 아니라 팀이 함께 보는 서비스에 쌓인다. 정리하는 수고가 줄어 기록이 밀리지 않고, 덕분에 팀원들이 같은 정보를 같은 시점에 본다. "그거 누가 하기로 했었지?"를 물을 일이 줄었다.

2. 일하던 자리를 떠나지 않는다

할 일 확인, 회의록 검색, 마일스톤 확인을 터미널에서 묻고 바로 답을 받는다. 브라우저를 열고 로그인하고 메뉴를 찾아 들어가는 몇 단계가 질문 한 줄로 줄었다. 작은 차이 같지만, 하루에 몇 번씩 끊기던 흐름이 이어진다.

3. 회의 뒤처리가 대화 한 번으로 끝난다

녹음을 다시 듣고, 요약을 쓰고, 할 일을 하나씩 옮기던 일이 "오늘 회의록 올려줘"로 바뀌었다. 나는 AI가 만든 정리안을 읽고 확인만 하면 된다. 템플릿이 정해져 있어서 누가 정리해도 회의록 형식이 같고, 팀원들이 읽기도 편하다.

4. 비용이 따로 들지 않는다

원래 웹 화면의 [요약 생성] 버튼은 서버에서 Claude API를 호출해서 쓸 때마다 비용이 들었다. 이 흐름은 내가 이미 쓰고 있는 Claude Code 구독 안에서 끝난다.

5. AI에게 맡겨도 불안하지 않다

팀이 함께 쓰는 데이터를 AI가 직접 바꾼다고 하면 걱정이 먼저 든다. 그래서 안전장치를 겹겹이 뒀다.

• 쓰기 전에 공간부터 확인한다. Claude Code는 쓰기 전에 get_workspace로 지금 연결된 공간이 어디인지 확인한다. 엉뚱한 팀의 공간에 회의록을 올리는 실수를 막기 위해서다.
• 바꾸기 전에 미리보기로 보여준다. 삭제는 한 번 거절된 뒤 다시 확인해야 통과한다.
• 적용한 뒤에도 롤백할 수 있다. 터미널에서 AI가 한 일을 브라우저에서 검토하고 취소할 수 있다는 게 생각보다 든든하다.
• 토큰은 공간 하나, 권한 하나로 묶인다. 팀 안에서 정한 권한도 그대로 적용된다.

솔직히 롤백이 없었다면 쓰기 토큰은 발급하지 않고 읽기 전용에서 멈췄을 것이다.

6. 팀원이 올린 회의록을 놓치지 않는다

새 회의록이 올라오면 내가 일하는 터미널로 알림이 온다. 새 회의록이 있는지 서비스에 들어가 확인할 필요가 없다. 내가 올리면 팀원이 보고, 팀원이 올리면 내가 바로 안다.

마무리

처음 목표는 혼자 정리를 잘하는 게 아니라, 팀이 같은 기록을 보며 함께 일하는 것이었다. 그래서 팀 업무 서비스를 만들었고, 거기에 MCP를 붙이면서 가장 큰 걸림돌이었던 "기록을 올리는 수고"를 덜었다. 지금은 회의가 끝나도 브라우저를 열지 않는다. 녹음은 Tiro가, 정리는 Claude Code가, 기록과 공유는 서비스가 맡고, 나는 확인만 한다.

팀과 함께 쓰는 업무 도구가 있고, 하루 대부분을 AI 도구 안에서 보내고 있다면, MCP로 둘을 이어 보는 것도 방법이다. 도구를 오가는 시간이 생각보다 많았다는 걸 알게 된다.

영수증을 열어봤다

클로드 코드로 두 달쯤 일했다. 개발도 하고 사업 문서도 쓰고 리서치도 시켰다. 그러다 문득 궁금해졌다. 나는 토큰을 도대체 얼마나 쓴 걸까.

찾아보니 기록이 다 남아 있었다. ~/.claude/projects/ 아래에 세션마다 파일이 하나씩 있고, 그 안에 응답 한 번당 토큰을 몇 개 썼는지가 그대로 적혀 있다. 추정할 필요가 없다. 영수증이 있는 셈이다.

전부 긁어모아 합산했다. 세션 28개, 7월 9일부터 9월 13일까지.

총 71억 5,000만 토큰

숫자만 보면 무섭다. 그런데 뜯어보니 이 71억의 정체가 내 생각과 달랐다.

토큰은 한 종류가 아니다

토큰은 네 가지로 나뉘고, 종류마다 가격이 다르다.

AI가 실제로 써낸 글은 전체의 0.3%다. 나머지는 읽는 데 들어갔다.

AI는 매번 처음부터 다시 읽는다

왜 이렇게 되나. AI에게 기억이 없기 때문이다.

대화가 이어지는 것처럼 보이지만, 실제로는 질문 하나에 답할 때마다 그 세션의 대화를 처음부터 끝까지 다시 읽는다. 100번째 질문에 답하려면 앞의 99번을 읽어야 한다. 200번째면 199번을 읽는다.

그래서 대화가 길어지면 한 마디 주고받는 비용이 계속 올라간다. 질문이 어려워져서가 아니라 읽어야 할 앞부분이 길어져서다.

캐시는 이걸 싸게 만들어주는 장치다. 같은 내용을 다시 읽을 때는 정가의 10%만 받는다. 그래서 개수로는 96%를 차지해도 실제 비용은 그만큼 나오지 않는다. 반대로 출력은 입력의 5배로 비싸다. 0.3%밖에 안 되는 출력이 비용에서는 꽤 큰 자리를 차지하는 이유다.

아래부터는 종류별 가격 차이를 반영해서 환산한 값으로 비교했다. 그래야 같은 기준으로 놓고 볼 수 있다.

긴 대화는 9배 비싸다

세션을 길이별로 묶어서 질문 한 번 던지는 데 얼마가 드는지 계산했다.

똑같이 "이거 고쳐줘" 한 줄을 쳐도 긴 대화 끝에서 치면 9배가 든다.

제일 긴 세션은 대화가 2,495번까지 갔다. 이 세션은 질문 한 번에 720만 토큰을 썼다. 짧게 끝낸 세션들은 30만 토큰 언저리였다. 같은 일을 시켜도 어디서 시키느냐에 따라 20배가 갈린다.

대화가 길어지면 느려진다는 건 알고 있었다. 느려지는 게 아니라 비싸지고 있었다.

세션을 쪼개 쓰고 있었다

나는 몇 달 전부터 작업을 좀 이상하게 하고 있다. 세션 하나를 관제탑으로 정해두고 실제 작업은 다른 세션들에 맡긴다. 관제탑은 지시를 내리고 결과를 기록 파일에 한 줄씩 적는다. 개발은 개발 세션에서, 문서는 문서 세션에서 한다.

원래는 맥락이 섞이지 않게 하려고 만든 방식이다. 코드 얘기하다 사업 문서 얘기를 꺼내면 둘 다 흐려지니까.

이번에 집계하면서 다른 게 하나 눈에 들어왔다.

관제탑이 딱 절반이다.

그런데 이걸 관제가 효율적이라는 뜻으로 읽으면 안 된다. 맨 오른쪽 칸을 보자. 관제탑은 질문 하나에 도구를 3.9번 쓰고 실행 세션은 9번 쓴다. 관제탑이 하는 일은 파일 위치를 알려주고 기록에 한 줄 적는 거라 원래 가볍다. 실행 세션은 코드를 읽고 고치고 테스트를 돌리니 무거울 수밖에 없다. 하는 일이 다른 둘을 비용으로만 비교한 셈이다.

진짜 이유는 다른 데 있다.

일을 여러 세션으로 쪼개면 각 세션이 짧게 유지된다.

한 세션에 전부 밀어넣으면 뒤로 갈수록 질문 한 줄이 계속 비싸진다. 나눠서 맡기면 모든 세션이 앞쪽 구간, 그러니까 싼 구간에 머문다. 관제탑도 결과 요약만 받으니 살이 안 찐다.

돈을 아끼려고 만든 방식이 아니었는데 그렇게 굴러가고 있었다.

그래서 뭘 바꿨나

세 가지를 바꿨다.

일이 끝나면 세션을 끊는다. 아깝다고 붙잡고 있으면 다음 질문부터 비싸진다. 맥락이 필요하면 결과를 파일로 남기고 새로 시작하는 편이 싸다.

무거운 일과 가벼운 일을 섞지 않는다. 코드를 한참 읽힌 세션에서 문장 하나 다듬어달라고 하면, 그 한 문장을 위해 앞의 코드를 전부 다시 읽는다.

요약을 파일로 남긴다. 대화를 통째로 이고 다니는 것보다 결론만 적어두고 다음 세션에서 그 파일만 읽히는 게 훨씬 싸다. 내 경우엔 그게 그 기록 파일이었다.

남은 한계

몇 가지는 짚어둬야겠다.

세션을 제목으로 분류했다. 기록에 세션 고유번호가 안 남아서 어느 세션 것인지 정확히 가려내지는 못한다.

AI가 따로 띄운 보조 세션이 쓴 토큰은 저장 위치가 달라서 이 집계에 안 들어갔다. 48건이다. 실제 총량은 이보다 크다.

캐시 저장 단가를 1.25배로 잡았다. 캐시를 오래 물고 있는 설정이면 2배가 된다. 어느 쪽이든 긴 세션이 비싸다는 결론은 그대로다.