MCP의 다음 병목은 인증이 아니라 컨텍스트 비용이다

MCP의 진짜 병목은 연결 이후에 나타난다

MCP의 다음 병목은 단순히 인증이 아닙니다. 더 정확히 말하면, 인증과 권한 관리가 어느 정도 갖춰진 뒤에는 컨텍스트 비용, 응답 지연, 도구 관리가 새로운 병목으로 떠오릅니다.

처음 MCP를 도입할 때는 보통 이런 질문을 합니다. “우리 사내 시스템을 Claude나 Cursor 같은 AI 도구에 안전하게 연결할 수 있을까?” 이 질문은 당연히 중요합니다. 기업 환경에서는 인증, 권한, 감사 로그, 개인정보 보호가 기본 전제이기 때문입니다.

하지만 실제 운영 단계로 들어가면 질문이 바뀝니다. Git, Jira, Confluence, Sentry, Prometheus, 사내 API, 데이터베이스, 배포 시스템까지 연결 대상이 늘어나면, AI가 사용할 수 있는 도구도 빠르게 많아집니다. 이때 모든 도구 설명을 매번 모델에게 읽히면, 사용자가 질문하기 전부터 많은 토큰이 소모됩니다.

쉽게 비유하면 이렇습니다. 사용자가 “지난 배포의 에러율만 확인해줘”라고 물었는데, AI에게 회사의 모든 업무 매뉴얼을 먼저 읽게 하는 셈입니다. 답을 찾기 전에 준비 비용이 너무 커지는 것입니다.

그래서 엔터프라이즈 MCP 설계의 핵심은 “얼마나 많은 도구를 붙일 수 있는가”에서 “필요한 도구를 필요한 순간에만 찾고 실행할 수 있는가”로 이동하고 있습니다.

확인된 사실은 무엇이고, 무엇을 조심해야 할까

MCP의 공식 명칭은 Model Context Protocol입니다. MCP 공식 문서는 MCP를 AI 애플리케이션이 외부 시스템에 연결되는 표준 방식으로 설명합니다. 쉽게 말해 AI가 여러 업무 도구와 대화할 수 있도록 해주는 공통 연결 규격입니다.

Anthropic은 Code execution with MCP 글에서 도구가 많아질수록 모델이 읽어야 하는 도구 설명과 중간 결과가 늘어나 비용과 지연이 커질 수 있다고 설명했습니다.

Anthropic이 제시한 150,000토큰에서 2,000토큰으로 줄어든 사례는 강한 참고 사례입니다. 다만 특정 상황에서 나온 예시이므로, 모든 MCP 환경에서 같은 절감률이 보장된다고 보면 안 됩니다.

Cloudflare도 내부 AI 엔지니어링 스택에서 여러 MCP 서버와 많은 도구를 운영하면서 도구 설명이 컨텍스트를 차지하는 문제를 설명했습니다. 다만 Cloudflare Codemode는 문서상 Beta이자 experimental로 표시되어 있으므로, 안정적인 정식 기능처럼 단정하기보다는 검토 중인 운영 패턴으로 보는 편이 안전합니다.

도구가 많아질수록 AI가 느려지는 이유

MCP가 중요한 이유는 분명합니다. 기존에는 AI 애플리케이션이 외부 시스템과 연결되려면 서비스마다 별도 연결 코드를 만들어야 했습니다. GitHub는 GitHub대로, Slack은 Slack대로, 사내 DB는 사내 DB대로 붙여야 했습니다.

MCP는 이 연결 방식을 표준화합니다. AI는 MCP client가 되고, 외부 시스템은 MCP server가 되어 도구와 데이터를 제공합니다. 이 구조 덕분에 AI 에이전트는 더 많은 업무 시스템과 연결될 수 있습니다.

하지만 표준화가 곧 최적화를 의미하지는 않습니다. MCP 서버가 1~2개이고 도구가 적을 때는 문제가 크지 않습니다. 문제는 기업 내부 플랫폼처럼 도구 수가 빠르게 늘어나는 경우입니다.

예를 들어 배포 조회, 로그 검색, 장애 지표 확인, 이슈 조회, PR 리뷰, 문서 검색, 릴리즈 승인 같은 작업이 모두 MCP 도구로 붙는다고 해보겠습니다. 도구가 많아질수록 모델은 “어떤 도구를 어떻게 써야 하는지”를 설명하는 문서도 함께 읽어야 합니다.

이때 생기는 부담을 Tool Schema Overhead라고 부를 수 있습니다. 한국어로 풀면 “도구 사용법 설명서가 너무 많아져 생기는 부담”입니다. 모델은 실제 답변에 필요한 정보뿐 아니라, 아직 쓸지 말지 모르는 도구 설명까지 먼저 읽게 됩니다.

Anthropic의 Code execution with MCP 접근은 이 문제를 다르게 풀려고 합니다. 모든 도구를 모델에게 한꺼번에 보여주는 대신, 도구를 코드 API처럼 다루고 필요한 도구만 찾아 쓰게 하는 방식입니다.

이 방식의 핵심은 단계적 공개입니다. 처음부터 모든 도구 설명을 보여주지 않고, 필요한 순간에 필요한 도구만 찾게 합니다. 사람으로 치면 회사 전체 매뉴얼을 처음부터 다 읽는 것이 아니라, 지금 처리해야 하는 업무와 관련된 문서만 검색해 보는 방식입니다.

Cloudflare의 사례도 같은 방향을 보여줍니다. Cloudflare는 내부 AI 엔지니어링 스택에서 여러 production MCP 서버와 182개 이상의 도구를 운영한다고 밝혔습니다. 이런 환경에서는 도구를 무작정 늘리는 것만으로는 충분하지 않습니다. 도구 접근을 중앙화하고, 모델에게 보여주는 도구 설명을 줄이는 운영 설계가 필요해집니다.

여기서 Code Mode는 단순히 토큰을 아끼기 위한 편법이 아닙니다. AI가 모든 중간 결과를 대화창으로 가져오는 대신, 실행 환경에서 검색, 필터링, 집계, 반복 처리를 하고 필요한 결과만 모델에게 돌려주는 구조에 가깝습니다.

다만 이 방식이 항상 더 쉬운 것은 아닙니다. 모델이 생성한 코드를 실행하려면 안전한 실행 공간, 실행 시간 제한, 네트워크 접근 제어, 로그 기록, 권한 검증이 필요합니다. 즉 비용은 줄일 수 있지만 운영 책임은 더 정교해집니다.

직접 호출 방식과 Code Mode 방식의 차이

기업이 MCP를 설계할 때 봐야 할 것

백엔드 개발자나 플랫폼 엔지니어가 MCP를 도입할 때 가장 조심해야 할 생각은 “우리 API를 전부 MCP 도구로 감싸면 편하지 않을까?”입니다. 처음에는 좋아 보이지만, 내부 API 단위를 그대로 모두 노출하면 도구 수가 빠르게 늘어납니다.

예를 들어 주문 시스템을 MCP로 연결한다고 해보겠습니다. 주문 조회, 결제 조회, 클레임 조회, 배송 조회, 환불 조회, 쿠폰 조회, 포인트 조회를 모두 별도 도구로 만들 수 있습니다. 하지만 에이전트의 실제 목적이 “고객 문의에 답하기 위한 주문 상태 요약”이라면, 내부 API를 그대로 노출하는 것보다 목적 중심의 도구를 설계하는 편이 더 안정적일 수 있습니다.

중요한 것은 도구 수가 아니라 업무 목적입니다. AI가 실제로 해결해야 하는 일이 무엇인지 먼저 정하고, 그 일을 처리하는 데 필요한 수준으로 도구를 묶어야 합니다. 그래야 모델이 불필요한 도구 설명을 읽지 않고도 정확한 답을 만들 수 있습니다.

또 하나 중요한 기준은 결과를 그대로 모델에게 넘기지 않는 것입니다. 로그 수천 줄, 스프레드시트 수만 행, 모니터링 지표 전체를 모델 컨텍스트에 넣으면 비용이 커집니다. 실행 환경에서 먼저 필터링하고, 모델에게는 판단에 필요한 결과만 넘기는 구조가 필요합니다.

물론 이 방식은 보안 설계를 더 중요하게 만듭니다. 모델이 생성한 코드가 실제 도구 호출을 조합한다면, 어디까지 네트워크 접근을 허용할지, 어떤 작업은 사람의 승인이 필요한지, 민감한 정보가 로그에 남지 않도록 어떻게 막을지 정해야 합니다.

결국 MCP 운영 설계는 단순한 연결 작업이 아닙니다. 어떤 시스템을 연결할지, 어떤 권한으로 연결할지, 어떤 도구를 모델에게 직접 보여줄지, 어떤 결과만 모델에게 돌려줄지, 호출 비용과 실패율을 어떻게 관측할지까지 함께 설계해야 합니다.

결론: 더 많은 도구보다 더 좋은 운영 설계

MCP의 확산은 AI 에이전트가 실제 업무 시스템과 연결되는 데 큰 전환점이 됐습니다. 하지만 엔터프라이즈 환경에서 MCP의 성패는 “연결됐는가”만으로 결정되지 않습니다.

연결된 도구가 많아질수록 모델이 읽어야 하는 도구 설명도 늘어납니다. 중간 결과가 모델 컨텍스트를 반복해서 통과하면 토큰 비용과 응답 지연도 함께 커집니다. 결국 MCP는 연결 표준을 넘어 운영 최적화의 문제가 됩니다.

Anthropic의 Code execution with MCP와 Cloudflare의 Code Mode 사례가 보여주는 핵심은 같습니다. 도구를 많이 붙이는 것보다, 필요한 도구를 필요한 순간에 찾고, 안전한 실행 환경에서 조합하며, 모델에는 필요한 결과만 돌려주는 설계가 중요합니다.

따라서 MCP를 도입하는 팀은 인증과 OAuth 설정에서 멈추면 안 됩니다. 그 다음 질문은 “우리 MCP 환경에서 매 요청마다 낭비되는 도구 설명은 얼마나 되는가?”, “대용량 결과가 모델 컨텍스트를 불필요하게 차지하고 있지는 않은가?”, “도구 탐색과 실행을 분리할 수 있는가?”가 되어야 합니다.

MCP의 다음 경쟁력은 더 많은 도구가 아니라 더 효율적인 운영 설계입니다. 그리고 그 운영 설계의 중심에는 컨텍스트 비용, 단계적 도구 탐색, 안전한 실행 환경, 관측성이 있습니다.

FAQ