MCP는 뇌인 척하는 전송 계층(Transport Layer)이다

이번 주 HN(Hacker News)에서 화제가 된 게시물은 MCP의 폭발적 증가를 "분산 시스템의 악몽"이라고 불렀습니다. 그 논거는 다음과 같습니다. 현재 수백 개의 MCP 서버가 존재하고, 에이전트(Agent)들이 이를 자유롭게 호출하고 있지만, 언제 어떤 도구를 호출해야 하는지에 대한 조정(Coordination) 문제를 해결한 사람은 아무도 없다는 것입니다. 그 결과 무한 루프, 크레딧 낭비, 그리고 점심 식사 후 API 잔액에서 20달러가 사라진 것을 목격하며 망연자실하는 1인 창업자들이 발생하고 있습니다.

저는 이 문제를 개인적으로 잘 알고 있습니다. 제가 직접 일으켰기 때문입니다.

20달러짜리 점심시간

작년에 저는 교육용 프로젝트를 만들고 있었습니다. 코드에는 응답이 null로 돌아올 때 API 호출을 재시도하는 루프가 포함되어 있었습니다. 이는 표준적인 방어적 패턴(Defensive pattern)입니다. 문제는 응답이 실제로 실패한 것이 아니었다는 점입니다. 응답이 제대로 저장되지 않았을 뿐이었습니다. 저장(Storage) 코드가 고장 나 있었기 때문에, 루프는 계속해서 null을 확인했고, 계속 재시도했으며, 계속해서 Anthropic을 호출했습니다.

저는 점심을 먹으러 갔습니다. 한 시간 뒤에 돌아왔을 때, 크레딧 20달러가 통째로 사라져 있었습니다.

물론 20달러가 인생을 바꿀 만한 큰 금액은 아닙니다. 하지만 사용량 대시보드를 바라보며 앉아 있을 때, 두 가지 사실이 동시에 머리를 스쳤습니다. 첫째, 그 호출의 대부분은 "이것을 요약해줘", "저것을 추출해줘"와 같은 단순한 작업이었으며, 제가 호출한 모델까지는 필요하지 않았습니다. 저는 훨씬 저렴한 모델로도 아무 문제 없이 처리할 수 있는 작업들에 대해 Sonnet 가격을 지불하고 있었습니다. 둘째, 저와 API 사이에서 이 상황을 잡아낼 수 있는 장치가 아무것도 없었습니다. 예산 제한(Budget)도, 모니터(Monitor)도, 서킷 브레이커(Circuit breaker)도 없었습니다. 그저 루프 하나와 계속해서 답변하기를 즐거워하는 모델뿐이었습니다.

그것이 제가 Prism을 만들게 된 계기입니다.

MCP의 진짜 문제

MCP는 진심으로 편리합니다. MCP는 에이전트가 도구와 통신하는 방식인 전송 계층(Transport layer)을 표준화했습니다. 그 부분은 잘 작동합니다. 문제는 MCP가 표준화하지 못한 것, 즉 의도(Intent)입니다.

현재 에이전트가 MCP 서버에 접근할 수 있을 때, 사용자가 매우 구체적인 지침을 주지 않는 한 에이전트는 자신이 필요하다고 판단하는 것은 무엇이든 호출합니다. 예산에 대한 인식(Budget awareness)도 없습니다. 복잡도 분류(Complexity classification)도 없습니다. "이것은 단순한 조회이므로 저렴한 경로를 사용하라"와 같은 로직이 프로토콜에 내장되어 있지 않습니다. 에이전트는 그저 실행할 뿐이고, 비용은 당신이 지불합니다.

HN(Hacker News) 게시글은 이를 M×N 조정 문제(coordination problem)로 규정했습니다. 즉, 오케스트레이션 계층(orchestration layer) 없이 M개의 에이전트가 N개의 도구와 통신하는 상황 말입니다. 저는 이 방향성이 맞다고 생각하지만, 더 날카로운 프레임워크를 놓치고 있다고 봅니다. 문제는 도구가 너무 많다는 것이 아닙니다. 문제는 우리가 전송 계층(transport layer)을 마치 지능(intelligence)인 것처럼 취급하고 있다는 점입니다.

MCP는 에이전트에게 도구를 어떻게(how) 호출할지를 알려줍니다. 하지만 에이전트에게 도구를 호출할지 여부(whether), _어떤 모델(which model)_이 호출을 처리해야 하는지, 또는 그 호출에 _얼마만큼의 비용(how much)_을 허용해야 하는지는 알려주지 않습니다. 그것들은 라우팅(routing) 및 거버넌스(governance) 결정 사항이며, 현재로서는 그 어디에도 존재하지 않습니다. 프로토콜에도 없고, 에이전트 안에도 없습니다. 그것들은 개발자의 머릿속에 있으며, 문맥(context)이 복잡해지는 순간 깨져버리는 프롬프트 엔지니어링(prompt engineering)의 형태로 인코딩되어 있을 뿐입니다.

실제로 일어나야 하는 일

이에 대한 Gemini의 견해는 "전송 계층은 과잉 표준화하고, 의미적 의도(semantic intent)는 과소 표준화하고 있다"는 것이었습니다. 저는 이 진단에 동의합니다. 하지만 해결책은 단순히 "의도를 표준화하자"는 것보다 더 구체적이어야 한다고 생각합니다.

우리에게 필요한 것은 더 똑똑한 MCP 명세(spec)가 아닙니다. 우리에게 필요한 것은 에이전트와 도구 사이에서 다음 세 가지를 수행하는 계층입니다.

예산 인식 라우팅(Budget-aware routing). 모든 MCP 호출에는 비용 상한선이 있어야 합니다. 청구서가 나온 뒤 사후에 확인하는 전역 예산이 아니라, 호출이 나가기 전에 라우팅 계층이 강제하는 작업별(per-task) 예산이어야 합니다. 단순한 쿼리인가요? 저렴한 모델로 라우팅하십시오. 복잡한 추론인가요? Sonnet이나 Opus로 라우팅하십시오. 복잡도를 알 수 없나요? 먼저 분류(classify)한 다음 라우팅하십시오. 분류 자체에는 비용이 거의 들지 않아야 합니다.

일반적인 쿼리를 위한 고정된 경로 (Fixed paths for regular queries). 대부분의 에이전트 워크플로우(agent workflows)에는 끊임없이 반복되는 소수의 쿼리 패턴이 존재합니다. 이메일에서 이름을 추출하거나, 문서를 요약하거나, 스키마(schema)를 조회하는 것과 같은 작업들입니다. 이러한 작업들이 매번 전체 에이전트 추론 루프(agent reasoning loop)를 거칠 필요는 없습니다. 대신 조밀하고, 집중적이며, 비용이 저렴한 사전 정의된 경로를 타야 합니다. 이를 고정된 예산과 고정된 경로를 가진 MCP 에이전트라고 생각하십시오. 일반적인 작업은 초고도로 최적화된 상태를 유지하고, 전체 추론 경로(full reasoning path)는 진정으로 새로운 작업들을 위해 예약해 두는 것입니다.

학습하는 피드백 루프 (A feedback loop that learns). 라우팅 계층(routing layer)은 시간이 지남에 따라 더 똑똑해져야 합니다. 만약 특정 작업이 지속적으로 비용이 많이 드는 모델로 라우팅되는데 그 결과물이 저렴한 모델이 생성한 것과 구별할 수 없을 정도라면, 시스템은 이를 감지하고 조정해야 합니다. 특정 MCP 서버가 지속적으로 재시도(retries)를 유발한다면, 시스템은 이를 플래그(flag)로 표시해야 합니다. 이것은 AI의 마법이 아닙니다. 로깅(logging), 스코어링(scoring), 그리고 임계값(thresholds)의 문제입니다. 아무도 만들고 싶어 하지 않지만 모두에게 필요한 지루한 인프라(infrastructure)입니다.

Prism의 역할

Prism은 20달러짜리 점심시간 때문에 존재합니다. 첫 번째 버전은 가장 명백한 부분, 즉 쿼리를 작업을 망가뜨리지 않으면서도 가장 저렴한 모델로 라우팅하는 문제를 해결합니다. 세 가지 모드가 있습니다: Eco, Balanced, Sport. 분류(classification)는 호출 후에가 아니라 호출 전에 일어납니다. 그것만으로도 제 20달러를 아낄 수 있었을 것입니다. 재시도된 호출의 절반은 Sonnet으로 전송된 단순한 작업들이었기 때문입니다.

하지만 라우팅은 단지 첫 번째 계층일 뿐입니다. 우리의 비전은 AI API 관리의 Vercel에 가까워지는 것입니다. 즉, 여러분의 코드와 모델 사이에 위치하여 라우팅, 메모리(memory), 예산(budgets), 모니터링(monitoring), 그리고 지속적인 최적화(continuous optimization)를 처리하는 제어 평면(control plane)이 되는 것입니다. 또 다른 모델 제공업체가 아닙니다. 또 다른 MCP 서버도 아닙니다. 여러분이 점심을 먹는 동안 크레딧(credits)을 낭비하지 않으면서 이 모든 것들을 사용할 수 있게 만드는 계층입니다.

우리는 아직 그 단계에 도달하지 못했습니다. 현재 Prism은 라우팅 (routing)과 세션 메모리 (session memory)를 수행합니다. 예산 집행 (budget enforcement), 고정된 경로 (fixed paths), 피드백 루프 (feedback loop) — 이것이 우리가 향해 구축하고 있는 목표입니다. 하지만 아키텍처 (architecture)는 이를 위해 설계되었으며, '$20짜리 점심시간'은 모든 결정이 "호출당 비용이 얼마인가"에서 시작되는 이유입니다.

더 큰 그림 (The Bigger Picture)

MCP의 폭발적인 성장은 좋은 현상입니다. 더 많은 도구, 더 표준화된 접근 방식, 그리고 1인 개발자(solo builders)를 위한 더 많은 역량을 의미합니다. 하지만 우리는 모두가 접근성에는 열광하면서도 거버넌스 (governance)에 대해서는 아무도 생각하지 않는 단계에 있습니다. 이는 2016년 마이크로서비스 (microservices) 때와 동일한 패턴입니다. 모두가 아키텍처를 채택했지만, 아무도 관측성 (observability)을 구축하지 않았고, 결국 운영 환경(production)이 불타오른 후에야 모두가 지난 3년 동안 모니터링 (monitoring)을 덧붙이는 데 시간을 허비했습니다.

라우팅과 거버넌스 계층가 없는 MCP는 똑같은 함정입니다. 전송 (transport)은 작동합니다. 지능 (intelligence)은 아직 존재하지 않습니다. 누군가가 이를 구축하기 전까지, MCP가 연결된 에이전트 (agent)를 가진 모든 인디 해커 (indie hacker)는 단 하나의 고장 난 저장 함수 (storage function)만으로도 API 제공자에게 점심을 사줘야 하는 상황에 처할 수 있습니다.

저는 그 계층을 구축하고 있습니다. Prism은 ssimplifi.com에서 라이브 상태입니다. 현재는 라우팅과 세션 메모리를 제공하며, 다음 단계로는 예산 거버넌스 (budget governance)와 최적화 (optimization)를 제공할 예정입니다. 만약 여러분이 멍청한 루프 (dumb loop) 때문에 크레딧 (credits)을 낭비해 본 적이 있다면, 이것이 왜 중요한지 알고 계실 것입니다.