Anthropic MCP 논쟁: 왜 AI 에이전트가 느려지는가

MCP가 약속했던 미래와 지금의 현실

AI 에이전트에게 수십, 수백 개의 도구를 연결하면 무엇이 가능할지 상상하는 사람은 많습니다. 그런데 막상 써 보면 "왜 이렇게 느리고 멍청하지?"라는 탄식이 먼저 나옵니다.

MCP(Model Context Protocol)는 이 문제를 해결하겠다며 등장했습니다. 어떤 도구가 어디에 있든 하나의 표준으로 묶어서, 모델이 자연어로 원하는 일을 지시하면 알아서 적절한 도구를 쓰게 만들어 보겠다는 발상이었습니다. 그런데 실제 구현을 들여다보면, 이 표준이 모델을 똑똑하게 만들기는커녕 더 둔하게 만들었다는 비판이 거세집니다.

가장 큰 병목은 단순합니다. 모델이 도구를 쓰려면, 그 도구의 설명과 스키마를 매번 같이 읽어야 합니다. GitHub, Slack, Jira, 데이터베이스 MCP를 한 번에 붙이면, 대화 시작 전에만 수만에서 많게는 십만 토큰이 증발합니다. 작업 내용은 "프론트 코드 한 줄 고쳐줘" 수준인데, 그 뒤에 붙는 MCP 정의는 백과사전 한 권입니다. 토큰이 비싸고, 지연 시간이 중요한 한국 기업 환경에서는 이 구조 자체가 이미 치명적인 약점입니다.

MCP가 에이전트를 바보로 만드는 방식

컨텍스트가 늘어나면 모델이 더 많이 알게 되니 좋아 보입니다. 하지만 실제로는 정반대입니다. 사용하지도 않는 도구 정의가 히스토리를 채우면서, 정작 중요한 사용자 의도는 뒤로 밀립니다. 모델은 매번 긴 설명을 다시 읽으면서도, 어느 부분이 이번 작업에 중요한지 제대로 구분하지 못합니다.

여기서 많은 팀이 빠지는 함정이 있습니다. "우리 서비스에 MCP를 붙이면 곧바로 슈퍼 에이전트가 탄생하겠지"라는 기대입니다. 현실에서는 툴 정의를 붙이는 순간, 비용과 레이턴시, 실패율이 동시에 올라갑니다. 특히 한국처럼 이미 레거시 시스템이 복잡한 환경에서는, MCP가 복잡함을 흡수하기보다 그대로 증폭하는 역할을 합니다.

누가 MCP에 열광하고 누가 피해야 하는가

자체 IDE, OS급 플랫폼을 만들려는 빅테크에는 MCP가 매력적입니다. 도구 연결을 위한 공통 언어가 있으면 생태계를 통제하기 좋기 때문입니다. 반대로 한정된 예산으로 실제 프로덕트를 운영하는 스타트업이나 중견 개발팀에게는 상황이 다릅니다. 단일 서비스에 필요한 도구가 5~10개 수준이라면, MCP가 가져오는 구조적 오버헤드가 이득보다 크기 쉽습니다.

제 기준에서는 "도구 개수가 많고, 조직 내부에 프로토콜을 관리할 전담 인력이 있는 팀"만이 MCP를 진지하게 고민할 만합니다. 한국의 대부분 서비스 개발팀이라면, MCP 이전에 단일 API 설계와 코드 기반 오케스트레이션을 먼저 완성하는 편이 훨씬 현실적입니다.

Anthropic의 세 가지 반격: 검색, 코드, 예제로 떼우기

Anthropic은 이런 MCP의 한계를 인정하듯, 세 가지 새로운 기능을 들고 나왔습니다. 도구 검색, 코드 기반 도구 호출, 도구 사용 예제라는 이름의 패치입니다. 언뜻 들으면 깔끔한 개선처럼 보이지만, 구조를 뜯어보면 "망가진 표준 위에 덧댄 대형 반창고"에 가깝습니다.

Tool Search: 도구를 미리 주지 말고 필요할 때 찾게 하자

첫 번째는 "tool search"입니다. 요지는 간단합니다. 모든 도구 정의를 처음부터 컨텍스트에 넣지 말고, 메타 검색 도구만 넣은 뒤, 모델이 필요할 때 검색해서 해당 도구만 불러오게 하자는 방식입니다. 이렇게 하면 토큰 사용량이 최대 80% 이상 줄어드는 사례도 나옵니다.

언뜻 합리적으로 들리지만, 새로운 위험도 같이 들어옵니다. 도구 정의가 대화 히스토리 안으로 흘러들어오면, 프롬프트 인젝션에 취약해집니다. 악의적인 입력이 도구 이름과 설명을 교란하면, 모델은 엉뚱한 도구를 믿고 호출할 수 있습니다. 국내에서 보안 요구 사항이 높은 금융, 공공 분야라면 이 지점을 절대 가볍게 보면 안 됩니다. 저라면 tool search를 도입할 때, 최소한 도구 이름과 핵심 스키마는 코드 상에서 고정하고, 설명만 검색으로 가져오는 하이브리드 구조를 설계하겠습니다.

Programmatic Tool Calling: 자연어 대신 코드로 오케스트레이션

두 번째는 "programmatic tool calling"입니다. 여기서 Anthropic도 사실을 인정합니다. 자연어로 "도구 A를 호출한 뒤 결과를 보고 조건에 따라 도구 B와 C를 실행해라"라고 설명하는 것보다, 그냥 TypeScript나 Python으로 짧은 코드를 쓰게 하는 편이 훨씬 정확합니다.

이 접근이 중요한 이유는 성능 때문입니다. 예를 들어 고객 데이터를 조회하고 필터링하는 흐름을 생각해 보면, 기존 MCP 흐름에서는 "전체 조회 → 결과를 컨텍스트에 통째로 집어넣기 → 모델이 그 안에서 눈으로 골라내기"를 반복합니다. 반면 코드 실행 환경을 열어주면, 모델은 "전체 조회 → 코드로 필터링 → 필요한 몇 줄만 컨텍스트로 다시 전달"이라는 경로를 택할 수 있습니다. 토큰이 줄어들고, 실패율도 내려갑니다.

문제는 여기서 다시 언어 선택으로 돌아옵니다. 최신 벤치마크를 보면 Anthropic 모델조차 TypeScript에서 더 높은 정답률을 보입니다. 그럼에도 공식 예시는 Python 위주로 흘러갑니다. 생태계 때문이라는 설명이 가능하지만, 코드 오케스트레이션을 본격적으로 활용할 팀이라면, 내부 표준 언어를 어떻게 가져갈지 지금부터 고민해야 합니다. 저라면 장기적으로 TypeScript 기반 도구 오케스트레이션을 염두에 두겠습니다. 서버와 클라이언트, 에이전트 로직을 한 언어로 묶을 수 있기 때문입니다.

Tool Use Examples: JSON까지 예제로 오염시키기

세 번째는 도구 사용 예제입니다. 단순한 JSON 스키마만으로는 "형식상 유효한 호출"과 "실제로 팀이 기대하는 호출"을 구분하기 어렵습니다. 그래서 MCP 정의 안에 "이런 식으로 쓰는 것이 바람직하다"는 예시를 같이 넣도록 하는 것입니다.

문제는 이 방식이 개발자의 글쓰기 능력에 전적으로 기대고 있다는 점입니다. 이미 API 문서도 제대로 안 쓰는 현장에서, 모델을 위한 예제 JSON까지 꼼꼼하게 관리할 팀은 많지 않습니다. 대부분은 자동 완성에 맡기거나, 복붙으로 복제할 가능성이 높습니다. 이 경우 예제는 품질 개선이 아니라 오히려 편향을 고착시키는 역할을 합니다. 구체적 맥락이 다른데도 옛 예제 패턴을 그대로 답습하는 에이전트가 양산될 수 있습니다.

AI 에이전트의 진짜 병목: 표준이 아니라 층층이 쌓인 레이어

많은 사람이 "표준이 정리되면 에이전트가 자연스럽게 좋아지지 않을까"라는 기대를 품습니다. MCP를 둘러싼 최근 움직임은 이 기대가 얼마나 낙관적이었는지 보여줍니다. 지금 벌어지는 일은 표준의 정리가 아니라, 레이어의 폭발입니다.

우리는 이미 또 하나의 운영체제를 만들고 있다

데이터가 있습니다. 그 위에 API가 있습니다. API 앞에 MCP 서버가 서고, MCP 정의 파일이 붙습니다. 이제 도구 검색을 위한 메타 도구가 추가되고, 그 위에 코드 실행 샌드박스가 올라갑니다. 마지막으로 이 모든 것을 안내하는 시스템 프롬프트와 예제 JSON이 실립니다. 한 번의 "사용자 질문" 뒤에 이런 구조가 줄줄이 달라붙습니다.

문제는 이 레이어들이 서로 다른 팀, 다른 문서, 다른 버전에 의해 관리된다는 점입니다. 국내 서비스 환경처럼 인력 교체가 잦고 문서 문화가 약한 곳에서는, 이 구조를 6개월만 지나도 아무도 전체를 이해하지 못하는 블랙박스로 만들 가능성이 큽니다. 그래서 MCP와 고급 도구 사용 기능이 약속하는 "표준화된 미래"는, 현실에서 "누구도 책임지기 어려운 거대한 복잡성"으로 변할 위험이 있습니다.

코드 중심 사고로 돌아갈 때

그럼에도 이번 변화에서 주목할 부분이 하나 있습니다. Anthropic이 결국 "코드 실행을 전면으로 끌어올렸다"는 점입니다. 모델이 모든 것을 자연어로 처리한다는 환상은 거의 끝났습니다. 루프, 조건, 필터, 조인 같은 것은 여전히 코드가 가장 잘합니다. LLM의 역할은 그 코드를 잘 쓰도록 돕는 쪽에 가깝습니다.

이 관점에서 보면, MCP는 도구 연결의 언어라기보다 "코드를 잘 쓰게 만들기 위한 메타데이터 레이어" 정도로 위치를 조정해야 합니다. 에이전트 설계의 중심에는 여전히 코드가 있어야 하고, MCP는 그 코드가 호출할 리소스를 묘사하는 수단에 머무르는 편이 더 안전합니다. 저라면 신규 프로젝트에서 MCP를 도입하더라도, "도구 검색과 예제"보다 "코드 기반 오케스트레이션"을 먼저 실험하겠습니다.

지금 당장 체크해야 할 것: 우리에게 맞는 전략인가

MCP와 Anthropic의 고급 도구 사용 기능은 분명 흥미로운 실험입니다. 그렇다고 한국의 모든 개발팀이 당장 따라가야 하는 방향이라고 보기는 어렵습니다. 조직의 규모, 레거시 수준, 보안 요구 사항에 따라 결과는 완전히 달라집니다.

이 전략이 맞지 않는 팀의 특징

도입을 서두르면 안 되는 팀은 의외로 많습니다. 도구 수가 10개 이하이고, 대부분 내부 서비스에서만 호출하는 API라면 MCP의 이점이 거의 없습니다. 문서화와 스키마 관리에 들일 인력이 따로 없다면, tool use examples는 오히려 거짓 안전감을 줄 수 있습니다. 무엇보다 인프라를 단순하게 유지해야 하는 스타트업이나 소규모 팀에게 MCP 서버와 코드 실행 샌드박스는 유지보수 리스크만 늘릴 가능성이 큽니다.

국내 환경에서는 규제가 강한 금융, 공공, 의료 영역도 조심해야 합니다. 도구 검색과 프롬프트 인젝션, 히스토리 기반 도구 정의 확장은 아직 공격 표면 분석이 충분히 이뤄지지 않았습니다. 이 영역에서는 MCP를 전면 도입하기보다, 폐쇄망 내부의 코드 오케스트레이션과 정적 스키마를 이용한 제한된 도구 호출부터 검증하는 편이 더 안전합니다. 제 기준에서는 "실시간 외부 액션"보다 "내부 보고서 자동화, 로그 분석 보조" 같은 수동적 에이전트 용도에 MCP를 한정하는 것이 현실적입니다.

그래도 시작한다면, 첫 번째 행동 한 가지

그럼에도 이 흐름을 완전히 외면하기는 어렵습니다. 언젠가는 어떤 형태로든 에이전트와 도구 연결이 개발자의 기본 역량이 될 가능성이 높습니다. 그렇다면 당장 해야 할 첫 행동은 MCP를 붙이는 일이 아니라, "우리 조직의 도구와 데이터가 코드로 얼마나 잘 묶여 있는지"를 점검하는 일입니다.

내부 API가 일관된 설계와 스키마를 가지는지, 주요 비즈니스 흐름을 몇 줄의 코드로 표현할 수 있는지, 로그와 데이터베이스에 대한 표준 쿼리가 정리돼 있는지부터 살펴볼 필요가 있습니다. 이런 기반이 없는 상태에서 MCP와 고급 도구 사용 기능을 올리면, 복잡성만 늘어난 채 효과는 매우 제한적입니다. 저라면 지금 시점의 MCP를 "모든 문제를 해결할 표준"이 아니라, 코드 중심 설계를 더 잘 드러내 주는 일종의 리트머스 시험지 정도로 취급하겠습니다. 그 시험지 위에 무엇을 올릴지는, 각 팀이 가진 현실의 무게를 보고 결정할 문제입니다.

출처 및 참고 :