MCP 쓰는 사람 지금 멈춰

숫자 하나로 시작하겠습니다. Linear, Notion, Slack, Postgres의 MCP 도구 정의 77개를 합치면 약 21,077토큰, Claude의 200K 컨텍스트 창에서 10.5%를 차지합니다. 아직 아무 작업도 시키지 않았는데 말이죠. 오늘 GeekNews에서 활발하게 읽힌 세 편의 글은 공교롭게도 같은 질문을 던집니다. AI 에이전트에게 무엇을, 얼마나 쥐여줄 것인가. 도구를 줄이는 이야기(MCP), 코드베이스를 한눈에 보는 이야기(CodeBoarding), 그리고 에이전트가 쓴 코드를 아예 거부하는 이야기(SQLite)까지 묶어 정리했습니다.

MCP는 죽었나? 토큰 65배의 진실

도구 정의만으로 컨텍스트 10.5%가 사라진다

Quandri 엔지니어링 팀이 실제로 연결된 MCP 서버의 도구 스키마를 추출해 측정했습니다. Linear는 도구 42개에 약 12,807토큰, Notion 14개에 약 4,039토큰, Slack 12개에 약 3,792토큰, Postgres 9개에 약 438토큰. 전체 77개 도구의 정의만으로 약 21,077토큰이 쌓이고, 이는 Claude 200K 컨텍스트의 10.5%, GPT-4o 128K 기준으로는 16.5%에 해당합니다. 문제는 이 정의가 ‘항상’ 로드된다는 점입니다.

같은 Linear 이슈를 조회하는 작업을 비교하면 차이가 극명합니다. curl로 GraphQL API를 직접 부르는 CLI 방식은 프롬프트 약 50토큰과 응답 약 150토큰을 합쳐 약 200토큰이면 끝납니다. 반면 MCP 방식은 실제 호출과 응답은 똑같이 약 150토큰이지만, 항상 따라붙는 42개 도구 정의 약 12,807토큰 때문에 합계가 약 12,957토큰, 즉 약 65배를 소비합니다. 성능도 부담입니다. 한 Jira 벤치마크에서 MCP는 REST API 직접 호출 대비 호출당 3배, 초기화를 포함한 첫 호출은 9.4배 느렸습니다. 별도 서버 프로세스, 반복 인증, 외부 왕복 지연, 프로세스 충돌 시 도구 소실 같은 운영 리스크도 따라옵니다.

Quandri의 대안은 ‘CLI 우선, 그다음 API, 마지막에 문서’ 전략입니다. LLM은 이미 man page와 StackOverflow로 CLI 사용법을 학습했으니, 기존 CLI를 Skills로 감싸 필요할 때만 로드하면 약 21K 토큰을 그대로 회수할 수 있다는 것입니다. 다만 모든 경우에 통하는 것은 아닙니다. 서비스에 CLI가 없거나, 비개발자에게 접근을 열어줘야 하거나, 프로덕션 DB처럼 팀 단위 권한과 읽기 전용 강제가 중요할 때는 MCP가 여전히 제 몫을 합니다. 또한 측정 이후 Claude Code에 지연 도구 로딩(Tool Search with Deferred Loading)이 도입되어 컨텍스트 팽창은 85% 이상 완화됐습니다. Hacker News 토론에서 OpenAI 측 담당자는 “거의 모든 회사가 MCP 서버를 만들고 있고, 그중 다수는 CLI도 외부 API도 없다”며 프로토콜로서의 MCP는 죽지 않았다고 반박하기도 했습니다.

AI가 짠 코드, 구조는 누가 보나

정적 분석과 LLM으로 그리는 코드베이스 지도

CodeBoarding은 사람과 AI 에이전트가 함께 보는 코드베이스 지도를 자동으로 그려주는 오픈소스 도구입니다. 정적 분석과 LLM 추론을 결합해 고수준 아키텍처 다이어그램과 주요 컴포넌트 문서를 생성하고, 결과물은 프로젝트의 .codeboarding/ 디렉터리에 Markdown 문서와 Mermaid 다이어그램 형태로 저장됩니다. 그대로 IDE, CI, PR, 문서에 임베드할 수 있고, 코드 일부만 바뀌면 그 부분만 다시 분석하는 증분 업데이트를 지원해 대규모 레포지토리에서도 빠르게 동작합니다.

내부는 여섯 개 컴포넌트로 구성됩니다. 분석 워크플로를 시작하는 Application Orchestrator와 Repository Manager, 전문 도구를 호출하는 LLM Agent Core, 정적 분석을 수행하는 Static Code Analyzer, 에이전트가 분석 엔진에 질의하는 Agent Tooling Interface, 변경분만 처리하는 Incremental Analysis Engine, 결과를 문서와 다이어그램으로 변환하는 Documentation & Diagram Generator입니다. Python, TypeScript, JavaScript, Java, Go, PHP, Rust, C# 등 8개 언어를 지원하고, OpenAI, Anthropic, Google, AWS Bedrock, Ollama, OpenRouter 등 여러 LLM 프로바이더와 연동됩니다.

배포 형태는 세 가지입니다. 로컬 분석과 CI 자동화용 CLI(pipx install codeboarding), 에디터에서 바로 보는 VS Code 익스텐션, 다이어그램을 항상 최신으로 유지하는 GitHub Action입니다. 이미 800개 이상의 유명 오픈소스 레포지토리를 시각화한 샘플 DB를 제공하며, 라이선스는 MIT입니다. 비전은 인간과 AI 에이전트가 모두 활용할 수 있는 ‘코드 이해의 오픈 스탠더드’를 만드는 것입니다.

SQLite가 ‘현재는’을 지운 이유

에이전트 코드는 거부, 버그 리포트는 환영

SQLite가 코드베이스에 AGENTS.md 파일을 추가했습니다. 이 파일은 SQLite 자체 개발 지침이 아니라, SQLite를 대상으로 에이전트를 돌리는 외부 사용자를 위한 정책 문서입니다. 핵심은 분명합니다. SQLite는 사전 합의나 풀 리퀘스트를 퍼블릭 도메인에 두는 법적 서류 없이는 어떤 PR도 받지 않으며, 사람이 잘 정리한 PR도 개념 증명으로만 검토할 뿐 실제 변경은 SQLite 개발자가 직접 다시 구현합니다.

에이전트가 생성한 코드(agentic code)는 받지 않습니다. 다만 재현 가능한 테스트 케이스가 포함된 에이전트 버그 리포트는 받을 수 있고, 수정 방향을 보여주는 패치도 문서화 목적이라면 환영합니다. 주목할 변화는 최근 커밋입니다. 원래 문구는 “SQLite does not (currently) accept agentic code”였는데, 가장 최근 커밋이 “(currently)”를 삭제했습니다. 커밋 메시지는 “Strengthen the statement about not accepting agentic code”, 즉 임시적 표현을 더 단정적인 방침으로 굳힌 것입니다.

배경에는 품질이 들쭉날쭉한 AI 생성 버그 리포트의 급증이 있습니다. SQLite는 이를 기존 포럼에서 분리해 별도의 SQLite Bug Forum을 새로 만들었고, D. Richard Hipp가 그 이슈들을 직접 처리하며 코드베이스에 커밋을 이어가고 있습니다. 문제 보고와 사람 개발자의 재구현을 명확히 분리한 셈입니다. SQLite가 2050년까지 코드를 지원하겠다고 공언해 온 장기 관점을 떠올리면, 이 결정은 갑작스러운 보수성이 아니라 일관된 철학의 연장선입니다.

관련 글

• MCP 도구를 코드로 바꾸니 토큰이 98% 줄었다: Anthropic의 새 접근법
• 대규모 코드베이스에서 Claude Code가 작동하는 방식
• GitDiagram – GitHub Repo를 인터랙티브 다이어그램으로 시각화
• AI 보조 코딩에 대해 틀리는 열두 가지 방식
• 지루한 기술을 선택하라 (2015)

출처

1. Quandri Engineering — Is MCP Dead?
2. CodeBoarding — GitHub Repository
3. Simon Willison — SQLite does not accept agentic code
4. GeekNews — MCP는 죽었나?