MCP는 죽었나?

• MCP는 LLM을 외부 도구에 연결하지만, 개발 워크플로에서는 컨텍스트 비용·운영 안정성·CLI/API 중복이 큰 부담으로 드러남
• Quandri 측정에서 Linear·Notion·Slack·Postgres의 도구 정의 77개는 약 21,077토큰으로 Claude 200K 컨텍스트의 10.5%를 차지함
• Linear 이슈 조회는 MCP 방식이 42개 도구 정의를 항상 싣기 때문에 CLI 방식 약 200토큰보다 훨씬 큰 약 12,957토큰을 소비함
• MCP는 별도 서버 프로세스와 인증·초기화·충돌·외부 왕복 지연이 붙지만, CLI/API는 터미널에서 재현·디버깅·조합하기 쉬움
• Quandri는 기존 CLI를 Skills로 감싸 약 21K 토큰을 확보했고, CLI가 없거나 팀 단위 권한 제어가 필요한 경우에만 MCP를 사용함

---

MCP가 드러낸 핵심 비용

• MCP(Model Context Protocol) 는 LLM을 GitHub, Linear, Notion, Slack 같은 외부 도구에 연결하지만, 실제 개발 워크플로에서는 컨텍스트 사용량, 운영 안정성, 기존 CLI/API와의 중복이 주요 문제가 됨
• 2024년 말 출시 이후 “AI 생태계의 USB-C”로 불렸지만, 일상적으로 쓰는 개발자에게는 다른 비용이 먼저 드러남
• Claude Code에는 측정 이후 Tool Search with Deferred Loading이 도입되어 MCP 도구 스키마를 필요할 때 로드하고 컨텍스트 사용량을 85% 이상 줄임
• 현재 Claude Code에서는 컨텍스트 팽창 문제가 상당 부분 완화됐지만, 성능, 디버깅, 아키텍처 문제는 여전히 남아 있음

컨텍스트 창을 크게 소모함

• 컨텍스트 창은 LLM이 작업에 쓰는 공간이며, MCP 서버를 연결하면 실제 작업 내용이 아니라 도구 정의만으로도 큰 부분이 차지됨
• Quandri 환경에서 연결된 MCP 서버의 실제 도구 정의를 추출해 측정한 결과, 4개 서버를 모두 연결하면 도구 정의만으로 컨텍스트 창의 10.5% 가 사용됨
• 도구 정의 크기:
  • Linear: 42개 도구, 약 51,229자, 약 12,807토큰
  • Notion: 14개 도구, 약 16,156자, 약 4,039토큰
  • Slack: 12개 도구, 약 15,168자, 약 3,792토큰
  • Postgres: 9개 도구, 약 1,755자, 약 438토큰
  • 전체: 77개 도구, 약 84,308자, 약 21,077토큰
• 모델별 컨텍스트 사용량:
  • Claude 200K 컨텍스트에서는 도구 정의가 10.5%를 차지함
  • GPT-4o 128K 컨텍스트에서는 도구 정의가 16.5%를 차지함
• Linear 단독으로도 42개 도구 정의가 항상 로드되어 약 12,800토큰 이상을 차지하며, 실제로 get_issue와 save_issue만 쓰는 경우에도 전체 정의가 함께 실림
• 큰 도구 정의 예시:
  • linear/save_issue: 2,479자, 약 619토큰
  • slack/search_public: 1,614자, 약 403토큰
  • linear/list_issues: 1,588자, 약 397토큰
  • notion/fetch: 1,379자, 약 344토큰
  • slack/send_message: 1,248자, 약 312토큰

운영 안정성과 성능 부담

• MCP는 별도 프로세스를 시작하고 유지해야 하므로 초기화 실패와 반복 인증 문제가 생길 수 있음
• 도구 호출마다 외부 서버 왕복이 필요해 AI 응답 속도가 느려짐
• MCP 서버 프로세스가 충돌하면 세션 중간에 도구가 사라질 수 있음
• 각 도구가 실제로 어떤 권한을 갖는지 불분명해 권한 가시성이 낮음
• MCP is dead. Long live the CLI의 Jira MCP 벤치마크에서는 REST API 직접 호출 대비 MCP가 호출당 3배 느렸고, 초기화를 포함한 첫 호출은 9.4배 느렸음
• 이 성능 차이는 Jira에만 한정되지 않고, LLM과 기본 API 사이에 MCP 서버라는 프로세스 계층이 추가되는 구조에서 비롯됨
• 같은 오버헤드는 Quandri 스택의 Linear, Notion, Slack 서버에도 적용됨

기존 CLI/API와 중복됨

• CLI/API는 사람과 LLM이 같은 명령을 사용할 수 있지만, MCP는 LLM 대화 내부에서만 존재함
• CLI/API는 파이프, jq, grep과 자유롭게 조합할 수 있지만, MCP는 서버가 반환하는 형식에 묶임
• CLI/API는 터미널에서 즉시 재현하고 디버깅할 수 있지만, MCP는 대화 컨텍스트 안에서만 재현 가능함
• LLM은 이미 man page와 StackOverflow를 통해 CLI/API 사용법을 학습했지만, MCP는 별도 도구 정의가 필요함
• CLI/API는 대부분 이미 설치되어 있는 반면, MCP는 서버 설정, 인증, 프로세스 관리가 추가로 필요함

Linear 이슈 조회의 토큰 비용

• 같은 Linear 이슈를 조회할 때 MCP 방식은 CLI 방식보다 약 65배 많은 토큰을 소비함
• CLI 방식은 약 200토큰을 사용함:
  • curl 명령 프롬프트: 약 50토큰
  • 응답: 약 150토큰
• MCP 방식은 약 12,957토큰을 사용함:
  • 항상 로드되는 Linear 도구 정의 42개: 약 12,807토큰
  • 도구 호출과 응답: 약 150토큰
• CLI 예시는 Linear GraphQL API를 직접 호출함:

curl -s -H "Authorization: Bearer $LINEAR_TOKEN" \ -H "Content-Type: application/json" \ -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' \ https://api.linear.app/graphql

대안: CLI 우선 전략과 Skills

• CLI → API → 문서 순서로 제공하는 방식이 더 가볍고 직접적임
• LLM은 이미 man page와 StackOverflow에서 CLI 사용법을 학습했기 때문에 별도 도구 정의를 항상 싣지 않아도 됨
• 기존 CLI를 직접 사용하면 도구 정의로 컨텍스트를 낭비하지 않고, 사람과 AI가 같은 인터페이스를 사용하므로 디버깅이 쉬움
• 파이프라인을 통해 다른 명령과 자유롭게 조합 가능함
• MCP가 “식탁에 모든 메뉴를 미리 펼쳐놓는” 방식이라면, Skills는 “필요한 책만 사서에게 요청하는” 방식에 가까움
• MCP는 연결 시 모든 도구 정의를 로드하고 항상 컨텍스트를 점유하지만, Skills는 필요할 때만 로드되고 사용 중일 때만 컨텍스트를 차지함
• 서버가 늘어날수록 MCP의 컨텍스트 압박은 커지지만, Skills는 스킬 수에 비례해 항상 컨텍스트를 차지하지 않음
• 핵심은 CLI 사용 지침을 Skills 안에 넣는 방식이며, CLI 우선 전략과 결합하면 가장 효율적임
• Linear Skill 예시는 API URL, 인증 방식, 이슈 조회용 curl 명령, GraphQL 검색 방식, jq로 JSON을 파싱한다는 지침만 포함함:

# Linear Issue Lookup Skill - Linear API: https://api.linear.app/graphql - Auth: Bearer Token ($LINEAR_TOKEN env var) - Get issue: curl -s -H "Authorization: Bearer $LINEAR_TOKEN" -H "Content-Type: application/json" -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' https://api.linear.app/graphql - Search issues (GraphQL): adjust the query field for JQL-like filtering - Results are JSON, parse with jq

• 이 방식에서는 LLM이 해당 스킬을 호출할 때만 위 내용을 컨텍스트에 로드함
• 42개 Linear 도구 정의를 항상 들고 다니지 않고, 필요한 CLI 명령만 로드하면 됨

MCP가 여전히 유효한 경우

• 서비스에 CLI가 없을 때 MCP가 유일한 연결 방식일 수 있음
• 터미널을 쓰지 않는 비개발자 사용자에게는 MCP가 더 접근하기 쉬움
• 단순 요청-응답을 넘어서는 실시간 양방향 통신에서는 MCP가 적합할 수 있음

데이터베이스 접근의 선택 기준

• 데이터베이스는 결국 쿼리 실행이며, LLM은 SQL과 MongoDB 쿼리를 이미 잘 알고 있음
• DB 정보와 CLI 사용법을 Skill에 넣고 스키마를 제공하면 MCP 없이도 LLM이 쿼리를 작성할 수 있음
• Postgres Skill 예시는 호스트, 테이블 스키마, psql CLI 사용법만 포함함:

# Postgres Skill - Host: postgres://localhost:5432/myapp - Tables: users (id, name, email), orders (id, user_id, status) - CLI: psql -h localhost -d myapp -c "SELECT * FROM users WHERE ..."

• 데이터베이스에서는 MCP의 장점도 있음:
  • 쿼리 안전성: MCP 서버가 읽기 전용 모드를 강제하고 위험한 쿼리를 서버 레벨에서 차단할 수 있음
  • 자격 증명 보호: CLI 방식은 프롬프트에 연결 문자열이 노출될 수 있지만, MCP 서버는 내부에서 자격 증명을 관리함
• 로컬 개발 또는 개인 DB에는 Skills + CLI가 가볍고 빠르며 실수에서 복구하기 쉬움
• 프로덕션 DB 또는 공유 팀 환경에는 MCP가 적합하며, 서버 레벨의 쿼리 검증과 접근 제어 같은 안전장치가 중요함
• 대부분의 개발자 워크플로에서는 MCP가 과도한 설계가 되기 쉬움

Quandri의 사용 방식

• Quandri는 서비스에 맞춰 Bash + CLI, Skills, MCP를 함께 사용함
• gh, psql, aws처럼 매일 쓰는 도구에는 Bash + CLI를 사용함:
  • 컨텍스트 비용이 없음
  • 유연성이 높음
  • 터미널에서 바로 디버깅 가능함
• 커밋 작성과 PR 리뷰처럼 반복적인 다단계 워크플로에는 Skills를 사용함:
  • 호출될 때만 로드됨
• 강한 CLI가 없는 Slack, Linear, Notion 같은 서비스에는 MCP를 사용함
• 프로덕션 데이터베이스 접근처럼 팀 단위 인증이나 권한 범위 지정이 중요한 경우에도 MCP를 사용함
• 이미 CLI가 있고 로컬 인증이 가능하면 보통 그 방식이 가장 가벼움
• 서비스에 CLI가 없거나 팀 전체에 일관된 인증이 필요하면 MCP가 가치를 가짐

결론과 측정 방식

• 모든 것을 연결하는 것보다 잘 가르치는 것이 더 중요함
• Quandri에서는 기존 CLI를 감싸는 Skills로 MCP 서버를 대체해 약 21K 토큰의 컨텍스트를 확보함
• 일상 워크플로에서 초기화 실패가 사라졌고, 디버깅은 터미널에서 유지됨
• 필요한 도구만, 필요한 때에, CLI 지침과 함께 로드하는 방식이 더 효율적임
• MCP가 앞으로 이런 문제를 해결하도록 진화할 수는 있지만, 현재 기준으로는 Skills가 더 나은 선택임
• 측정 방법:
  • Claude Code 환경에서 실제 로드된 MCP 서버의 각 도구 JSON 스키마를 추출함
  • 도구 이름, 설명, 매개변수를 기준으로 크기를 측정함
  • 토큰 추정은 약 4자당 1토큰 휴리스틱을 사용함
  • 전체 서버 추정치는 샘플 도구 평균에서 외삽함