MCP 표준화 이후 필요한 인프라 구축 과제

MCP의 확산과 과제

MCP(Model-Client Protocol)는 AI 모델이 저장소, 데이터베이스, 브라우저, 관측 시스템, 내부 API 등 다양한 도구와 공유 프로토콜을 통해 연결될 수 있도록 표준화된 방식을 제공한다. 이 프로토콜은 Claude Code, Cursor, Codex, VS Code 등 여러 클라이언트에서 지원하며, GitHub, Linear, Notion 등 다양한 벤더 호스팅 엔드포인트가 존재한다. 관련 SDK는 월 5억 건에 가까운 다운로드를 기록하며 빠르게 확산되었다.

MCP는 AI 애플리케이션마다 자체 도구 호출 계층을 구축하던 기존 방식의 문제를 해결하고, 공통 인터페이스를 제공하여 여러 에이전트가 맞춤형 연결 없이 서버를 활용할 수 있게 했다. 그러나 프로토콜의 표준화 속도에 비해 이를 둘러싼 인프라 구축은 더디게 진행되고 있다. 도구 연결 자체는 쉬워졌지만, 실제 사용자와 자격 증명, 작업 환경에서 시스템을 안정적으로 운영하는 것은 여전히 어려운 과제로 남아 있다.

인프라 중복과 한계

데모 환경에서는 에이전트가 MCP 클라이언트, MCP 서버를 거쳐 도구를 호출하는 단순한 구조로 충분하다. 하지만 프로덕션 환경에서는 다수의 에이전트와 사용자, MCP 서버, 유출되어서는 안 될 자격 증명, 속도 제한, 사용자 및 작업별 권한, 오류 처리, 재시도, 로깅, 변경되는 도구 스키마, 컨텍스트 제약 등 복잡한 요소들이 추가된다. 이러한 환경에서는 인증, 라우팅 또는 게이트웨이, MCP 서버, 그리고 실제 백엔드 시스템으로 이어지는 다단계 구조가 필요하며, 각 계층은 독립적으로 실패할 수 있다.

개발자들은 인증, 배포, 연결 관리, 재시도, 로깅, 비밀 처리, 상태 확인, 접근 제어, 간단한 레지스트리, 캐싱, 속도 제한 등 동일한 인프라 구성 요소를 각자의 코드베이스에서 반복적으로 구축하고 있다. 이는 MCP 프로토콜이 메시지 형식을 표준화했지만, 운영상의 문제점까지 해결하지 못했기 때문이다. 이러한 인프라 중복은 과거 물리 서버의 불편함이 클라우드 추상화를 낳고, 애플리케이션별 인증 재발명이 통합 인증 플랫폼을 발전시킨 것과 유사한 양상을 보인다.

초기에는 stdio 기반의 로컬 MCP 서버가 이해하기 쉽고 사용자에게 가까우며 로컬 파일 및 프로세스와 자연스럽게 연결되어 실험에 적합했다. 로컬 실행은 네트워크 환경에서 발생하는 인증 및 멀티테넌시 문제도 피할 수 있었다. 그러나 팀 규모로 사용될 경우 설치 및 구성의 어려움, 버전 불일치, 자격 증명 관리 문제, 파편화된 관측 가능성 등의 한계가 드러난다. 원격 또는 호스팅 서버는 이러한 문제를 일부 해결하지만, 클라이언트 간 인증, 지연 시간, 멀티테넌시, 데이터 처리, 가동 시간, 권한, 벤더 종속성 등의 새로운 문제를 야기한다. 2026년 7월 사양 변경으로 프로토콜 수준의 세션과 초기화 핸드셰이크가 제거되어 원격 서버가 일반 HTTP 서비스처럼 확장될 수 있게 되었으나, 인증, 권한 부여, 운영 규율의 필요성은 여전하다.

구체적인 운영 문제와 해결 노력

코딩 에이전트는 저장소 컨텍스트를 필요로 하지만, 전체 트리를 에이전트에 무작정 제공하면 토큰 비용 증가, 불필요한 정보, 집중력 저하, 높은 지연 시간, 심지어 추론 품질 저하를 초래할 수 있다. 컨텍스트 창의 크기가 커져도 문제는 사라지지 않으며, '모델이 얼마나 많은 정보를 담을 수 있는가'에서 '어떤 컨텍스트가 필요한가'로 질문이 바뀐다. Hexum.dev의 초기 작업은 저장소 컨텍스트를 효율적으로 만들어 에이전트가 관련 구조를 파악하도록 돕는 데 집중했다. MBPP 및 HumanEval 벤치마크에서 모델에 전송되는 컨텍스트 토큰이 220,393개에서 27,352개로 87.6% 감소하면서도 모든 공식 테스트를 통과했다. 이는 컨텍스트 선택을 의도적인 단계로 다룰 때 효율성이 크게 향상됨을 보여준다.

개발자들은 현재 컨텍스트 엔지니어링이라는 이름으로 이 문제를 지속적으로 논의한다. 동적 도구 검색은 모든 서버의 모든 도구 스키마를 매 턴마다 컨텍스트에 로드하는 문제에 대한 해결책 중 하나이다. 클라이언트 모범 사례는 이제 전체 정의를 연기하고 검색 스타일의 메타 도구를 제공할 것을 권장한다. 이는 점진적 검색이 도구 정의 토큰을 크게 줄이고 모델이 더 작은 관련 도구 세트에 집중하도록 하여 선택 정확도를 높일 수 있기 때문이다. 프로토콜 자체도 점진적 검색 지침과 관련 작업을 통해 이 방향으로 나아가고 있다.

에이전트에 50개, 100개, 또는 수백 개의 도구를 제공하는 것이 오히려 해로워지는 지점이 있다. 도구 선택 정확도가 떨어지고, 모델이 필요 없을 수도 있는 스키마로 컨텍스트가 가득 차게 된다. 이름 충돌과 모호한 설명은 문제를 더욱 악화시킨다. 모든 도구 정의가 항상 활성 컨텍스트 내에 있어야 하는지, 아니면 도구 자체가 동적으로 검색되어야 하는지는 여전히 논의 중이다. 정적 등록은 표면이 작을 때 간단하지만, 점진적 검색, 도구 설명에 대한 의미론적 검색, 더 작은 세트를 노출하는 게이트웨이 스타일 라우팅 등 다양한 접근 방식이 시도되고 있다. 최소 권한 원칙도 중요하다. 모든 도구를 볼 수 있는 에이전트는 접근해서는 안 되는 도구를 호출하도록 속임수를 당할 수 있기 때문이다.

에이전트가 자율성을 갖게 되면서 보안 문제는 더욱 심각해진다. MCP 보안은 일반적인 API 보안과 다르다. 에이전트는 신뢰할 수 없는 텍스트를 읽고 이를 지시로 해석하여 도구를 호출하고 외부 상태를 변경할 수 있다. 이는 프롬프트 인젝션, 혼란스러운 대리인 문제(confused-deputy problems), 과도한 권한, 악의적이거나 오염된 도구 설명, 인자나 결과를 통한 비밀 유출, 서버 자체의 공급망 위험과 같은 새로운 공격 표면을 생성한다. 2026년 7,973개의 라이브 원격 MCP 서버를 대상으로 한 측정 연구에 따르면, 40.55%가 인증 없이 도구를 노출하고 있었다. 이는 프로토콜 문제가 아닌 배포 문제이지만, 실제 팀들이 직면하는 현실적인 문제이다.

인간이 소프트웨어를 사용하다 오류를 발견하면 작업을 중단하지만, 자율 에이전트는 계속 진행할 수 있다. 이는 재시도, 멱등성, 타임아웃 동작, 부분 실패, 도구 결과 검증에 대한 요구사항을 변화시킨다. 모델이 무엇을 믿었는지, 어떤 컨텍스트를 보았는지, 어떤 도구를 알고 있었는지, 어떤 도구를 선택했는지, 어떤 인자를 생성했는지, 도구가 무엇을 반환했는지, 그리고 다음에 무엇을 했는지 재구성해야 할 수 있으므로 관측 가능성이 더욱 중요해진다. OpenTelemetry의 GenAI 시맨틱 컨벤션에는 MCP 관련 스팬과 속성이 포함되기 시작했으며, 공식 Python SDK는 기본적으로 OpenTelemetry 스팬을 내보낸다. 이는 에이전트-도구 시스템 디버깅의 표준 방식으로 자리 잡을 가능성이 있다.

MCP 인프라의 미래

Hexum.dev를 구축하면서 얻은 교훈은 MCP가 단순한 프로토콜 문제가 아니라 하나의 인프라 범주로 진화하고 있다는 것이다. 처음에는 컨텍스트 효율성이 주요 문제라고 생각했지만, 컨텍스트를 최적화하면 도구 선택 문제에 부딪히고, 도구를 노출하면 배포 및 구성 문제에 직면한다. 도구가 원격으로 작동하면 인증 및 권한 문제가 발생하며, 에이전트가 더욱 자율적이 되면 안정성, 보안, 관측 가능성이 최우선 과제가 된다.

미래의 스택은 상단에 모델과 에이전트, 그 아래에 에이전트 런타임과 MCP 클라이언트, 그리고 라우팅, 인증, 권한, 컨텍스트 관리, 도구 검색, 캐싱, 관측 가능성, 정책, 안정성을 처리하는 인프라 계층, 그 아래에 MCP 서버, 그리고 서버가 접근하는 데이터베이스, API, 코드, SaaS 시스템으로 구성될 수 있다. 이러한 기능 중 일부는 모델 제공업체, 에이전트 런타임, 클라우드 플랫폼, 게이트웨이 또는 개별 MCP 서버 내부에 포함될 수 있으며, 그 경계는 고정되어 있지 않다.

새로운 표준의 역할과 한계

MCP의 가장 큰 성과는 개발자들이 도구 상호 운용성을 당연하게 여기기 시작했다는 점이다. 성공적인 표준은 이전에 어려웠던 문제를 평범하게 만든다. 그러나 표준은 인프라 문제를 제거하기보다는 다른 곳으로 이동시키는 경향이 있다. HTTP가 시스템 통신 방식을 표준화했지만, 그 주변에 CDN, 로드 밸런서, API 게이트웨이, 관측 플랫폼, ID 시스템, 클라우드 인프라를 구축해야 했던 것과 유사하다. MCP도 비슷한 경로를 따를 수 있다. 프로토콜은 에이전트에게 도구를 위한 공통 언어를 제공했지만, 이제는 그 언어를 대규모로 안정적으로 만들고 운영하는 데 필요한 모든 것을 구축해야 하는 과제가 남아 있다. 인터페이스 자체는 더 이상 가장 어려운 부분이 아니며, 그 주변의 시스템들이 새로운 핵심 과제로 부상하고 있다.