MCP는 끝났는가? Model Context Protocol이 복잡성을 얻게 될 때

지난주 "mcp is dead"라는 제목의 게시물이 Hacker News 메인 페이지에 올라와 311점의 추천과 거의 300개의 댓글을 기록했습니다. 이는 클릭을 유도한 뒤 눈을 굴리게 만드는 종류의 헤드라인입니다. 왜냐하면 이 분야에서는 6개월이라는 타임라인 안에 죽는 것이 아무것도 없기 때문입니다. 그래서 저는 그 논거를 읽고, 수치를 뽑아보고, 이 프로토콜을 구축하는 사람들이 무엇이라고 말하는지 확인했습니다. 짧은 결론을 말씀드리자면: MCP는 죽지 않았습니다. 당신이 소유한 모든 도구를 MCP 서버에 연결해야 한다는 생각이 죽어가고 있는 것이며, 올해 무엇을 만들지 결정하려는 사람에게는 이 차이가 매우 중요합니다.

사람들이 분노하는 이유

hype(열풍)를 놓친 분들을 위해 설명하자면, Model Context Protocol (MCP)은 언어 모델이 하나의 일관된 인터페이스를 통해 외부 도구 및 데이터와 통신할 수 있도록 2024년 11월에 Anthropic이 출시한 표준입니다. 이를 공통 플러그라고 생각하면 됩니다. 제안 자체는 좋았습니다. 서버 하나를 작성하면, 호환 가능한 어떤 모델이든 그것을 사용할 수 있다는 것이었습니다.

불만 사항은 그 플러그를 사용하는 데 드는 비용에 관한 것입니다. MCP 서버가 노출하는 모든 도구는 연결 시 모델의 컨텍스트 윈도우 (context window)로 전체 정의를 전송합니다. 이름, 파라미터 스키마 (parameter schema), 응답 형식 등 모든 것이 포함됩니다. 최근의 논란을 촉발한 Quandri의 보고서에서 이를 측정했습니다: 4개의 서버가 연결되었을 때, 77개의 도구가 있었고, 모델이 당신의 글을 단 한 단어라도 읽기 전에 이미 21,077 tokens가 사라졌습니다. 이는 200k 컨텍스트 윈도우의 10.5%가 당신이 거의 호출하지 않을 정의들에 소비된 것입니다. Linear 서버 하나만 해도 저자가 단 두 개의 도구만 사용했을 때 42개의 도구에 대해 약 12,807 tokens를 잡아먹었습니다.

다음은 속도 문제입니다. 동일한 분석 결과, MCP 호출은 호출당 약 3배 느렸으며, 서버 초기화까지 포함하면 첫 번째 호출에서 9.4배 더 느렸습니다. 여기에 이 시스템을 실행해 본 사람이라면 누구나 뼈저리게 알고 있는 실패 모드들을 더해 보십시오: 시작되지 않는 서버, 세션 중간에 만료되는 인증 (auth), 작업 도중 죽어버려 전체 실행을 중단시키는 도구 같은 것들 말입니다.

이것은 지엽적인 불평이 아닙니다. 지난 3월, Perplexity의 CTO인 Denis Yarats는 ASK 2026 이벤트에서 회사가 내부적으로 MCP에서 벗어나 일반 API와 명령줄 도구 (command-line tools)로 이동하고 있다고 밝혔으며, 그 이유로 앞서 언급한 것과 동일한 컨텍스트 윈도우 (context-window) 낭비와 번거로운 인증 (auth) 문제를 들었습니다. 이는 단순한 개인적 의견 (hot take)이 아니라, 대규모로 에이전트 (agents)를 운영하는 팀으로부터 나온 실제 신호였기에 곳곳에서 화제가 되었습니다.

헤드라인이 생략한 부분

"MCP는 끝났다"라는 말이 바이럴될 때 놓치게 되는 부분이 여기 있습니다. MCP를 만든 회사인 Anthropic은 동일한 문제에 대해 자체적인 엔지니어링 포스트를 게시했으며, 그들의 관점은 장례식과는 정반대였습니다. 그들은 MCP를 수천 개의 커뮤니티 서버를 보유한 사실상의 표준 (de-facto standard)이라고 부르며, 어떻게 하면 컨텍스트를 낭비하지 않도록 할 수 있는지 보여줍니다.

그들의 해결책은 코드 실행 (code execution)입니다. 모델이 벽처럼 쌓인 도구 정의 (tool definitions) 중에서 하나를 선택하고 모든 중간 결과물을 다시 자신에게 전달하는 대신, MCP 서버를 모델이 직접 작성하여 호출할 수 있는 코드 API로 제시하는 방식입니다. 모델은 파일 시스템을 탐색하여 도구를 발견하고, 현재 작업에 필요한 정의만을 로드합니다. 그들의 실제 사례에서는 작업량을 150,000 토큰 (tokens)에서 2,000 토큰 (tokens)으로 줄였습니다. 이는 98.7%의 절감이며, 2시간 분량의 회의 녹취록을 컨텍스트에 두 번 스트리밍하는 대신 모델에 도달하기 전에 데이터를 필터링함으로써 얻은 결과입니다.

따라서 프로토콜 자체가 문제는 아닙니다. 모든 것을 성급하게 (eagerly) 로드하는 것이 문제입니다. MCP는 죽어가는 것이 아니라 성장하고 있습니다.

내가 선택할 방식

저는 비교 콘텐츠와 소규모 도구들을 제작하며 생계를 유지하고 있고, 하루 종일 제 스택에 에이전트를 실행하고 있습니다. 따라서 이것은 저에게 토론 동아리식 논쟁이 아닌 실질적인 문제입니다. 제가 내린 결론은 지루하지만 유효합니다.

먼저 CLI (Command-Line Interface)를 활용하세요. 서비스에 괜찮은 명령줄 도구가 있다면, 모델은 이미 매뉴얼 페이지(man pages)와 Stack Overflow를 통해 그 절반 정도는 알고 있습니다. 정의를 내리는 데 토큰이 전혀 들지 않으며, 인간과 에이전트가 공유하는 단일 인터페이스를 얻을 수 있습니다. 다음으로는 문서화할 가치가 있는 다단계 워크플로우(multi-step workflow)가 있을 때 스킬 (skills)을 활용하세요. 지침은 작업이 필요할 때만 로드되기 때문입니다. 구체적이고 빠른 무언가가 필요할 때는 일반적인 API 호출을 사용하세요.

MCP는 2024년의 유행이 시사했던 것보다 더 좁은 범위의 사례에서 그 입지를 확보하며, 그 사례들은 실질적입니다:

• 서비스에 CLI가 없고 전적으로 웹 UI 뒤에 존재하는 경우
• 사용자가 개발자가 아니어서 터미널 사용이 불가능한 경우
• 공유된 운영 데이터베이스(production database)에 대해 DROP TABLE 명령이 실행되기 전에 이를 거부하는 쿼리 검증(query validation)과 같은 서버 측 가드레일 (guardrails)이 필요한 경우
• 요청과 응답 (request and response) 방식이 아닌 실제 양방향 통신 (bidirectional communication)이 필요한 경우

그 데이터베이스 사례는 제가 포기하지 않을 부분입니다. CLI는 서버에 존재하는 액세스 제어 (access control)를 강제할 수 없습니다. 하지만 MCP 서버는 가능합니다. 영향 범위 (blast radius)가 공유된 운영 데이터베이스일 때, 프로토콜 오버헤드 (protocol overhead)는 안전을 보장하며, 이는 공정한 거래입니다.

구축 중이라면 이것이 중요한 이유

교훈은 "한쪽 편을 들어라"가 아닙니다. 모델과 당신의 도구 사이의 인터페이스는 측정 가능한 비용이 발생하는 설계 결정이며, 대부분의 팀은 이를 기본값으로 취급해 왔다는 것입니다. 만약 작업이 시작되기도 전에 컨텍스트 (context)의 10~50%가 사라진다면, 당신의 에이전트는 아무 이유 없이 더 멍청해지고 느려지며, 당신은 매 호출마다 그 비용을 지불하게 됩니다.

그러므로 당신이 연결하는 것들을 감사(audit)하십시오. 당신이 호출하는 도구(tools)에 비해 노출하고 있는 도구의 수를 계산해 보십시오. 만약 MCP를 실행 중이라면, Anthropic의 수치가 시사하는 것처럼 코드 실행(code execution)이나 점진적 로딩(progressive loading)이 토큰 비용을 절감할 수 있는지 확인하십시오. 만약 이미 CLI가 존재한다면, 서버가 정말로 필요한지 자문해 보십시오. 그리고 만약 MCP 서버를 구축할 계획이라면, 직접 호출할 수 있는 REST API를 단순히 감싸는 방식이 아니라, 접근 제어(access control)와 양방향(bidirectional) 요소 등 MCP를 정당화할 수 있는 기능들을 갖추어 MCP가 승리할 수 있는 케이스를 위해 구축하십시오.

마지막 지점이 바로 대부분의 고통이 발생하는 곳입니다. 사람들은 유스케이스(use case)에 서버가 필요해서가 아니라, MCP가 구축해야 할 대상이기 때문에 MCP 서버를 만듭니다. 실질적인 가드레일(guardrails)을 갖추고 하나의 작업만을 수행하는 잘 정의된 범위(well-scoped)의 서버는 유지할 가치가 있습니다. 단순히 체크박스를 채우기 위해 존재하는 서버는 나중에 당신이 원망하게 될 12,807 tokens가 될 뿐입니다.

MCP는 죽지 않았습니다. 모든 것을 MCP를 통해 연결하려는 반사적인 움직임이 죽은 것입니다. 작업이 요구할 때 서버를 구축하고, 그 외의 시간에는 더 저렴한 인터페이스를 사용하십시오.

가치를 증명하는 MCP 서버를 구축하기 위한 패턴, 즉 구조, 도구 설계, 가드레일이 궁금하다면 mcp server cookbook에 모아두었습니다. 그리고 더 넓은 범위에서 프로토콜과 도구들을 비교 분석하고 싶다면, tools.thesoundmethod.me에서 이러한 분석 글들을 작성하고 있습니다.

sources

• quandri engineering blog, "mcp is dead": https://www.quandri.io/engineering-blog/mcp-is-dead
• anthropic engineering, "code execution with mcp": https://www.anthropic.com/engineering/code-execution-with-mcp
• perplexity CTO Denis Yarats가 MCP에서 API 및 CLI로 전환함, 2026년 3월 보도