Remote MCPs: What we learned from shipping - John Welsh, Anthropic

영상 링크: Remote MCPs: What we learned from shipping — John Welsh, Anthropic
채널명: AI Engineer

원격 MCP 구현 경험: Anthropic의 대규모 시스템 적용기 핵심 요약

• 발표자 존 웰시는 20년간 대규모 시스템을 구축해온 엔지니어로서, Anthropic에서 MCP(Machine Context Provider) 클라이언트 및 통합을 담당하며 얻은 경험을 공유함
• 최근 AI 모델의 툴 호출 역량이 급성장하면서, 많은 팀들이 개별적으로 다양한 커스텀 엔드포인트와 통합을 빠르게 구축함에 따라 조직 내에 통합의 혼란과 중복이 발생했음
• Anthropic는 이러한 혼란의 해결책으로 ‘MCP 접점 표준화’에 집중함
• MCP는 핵심적으로 JSON RPC 메시지 규격(메시지 송수신 표준)과 글로벌 트랜스포트 표준(HTTP, OAuth 2.1 등)을 포함함
• 모든 통합에서 MCP 포맷 채택을 통해 내부와 외부 서비스 간 연동의 복잡성을 획기적으로 낮추고, 이후 확장성·유지보수성을 제고함
• MCP 표준 채택은 전 세계 AI 랩이 참여하는 산업계 표준화 움직임과 맞물려 조직 내외에서 생기는 다양한 상황(샘플링, 과금, 토큰 제한 등)의 해결책을 미리 내장함
• Anthropic는 MCP Gateway라는 단일 접점/중재 인프라를 구축해, 엔지니어들이 쉽게 MCP 기반 통합을 구현하도록 지원함(‘pit of success’ 전략)
• MCP Gateway는 URL 기반 라우팅, 일원화된 인증/크레덴셜 처리, 중앙 집중식 트래픽 제한·감사 등 부가적 이점 제공
• 다양한 트랜스포트(웹소켓, gRPC, 유닉스 소켓, 이메일 등)에서도 모든 MCP 메시지를 일관된 방식으로 취급할 수 있도록 설계
• MCP 도입으로 새로운 서비스 통합 및 프로토콜 진화가 용이해지고, 중앙 집중화로 보안·정책 적용·운영 간소화에 큰 효과를 거둠

세부 요약 - 주제별 정리

엔지니어링 혼란은 AI 도구 통합 증가로 조직 내에서 폭발적으로 심화됨

• AI 모델이 구글 드라이브, 맵, 문자 발송 등 외부 툴을 호출할 수 있게 되면서 엔지니어와 팀들이 저마다 여러 통합 엔드포인트를 빠르게 구현함
• 슬래시 호출 형식(/call-tool, /get-context 등) 서비스와 별도 인증 로직 등 다양한 사내 엔드포인트가 우후죽순처럼 등장함
• 같은 기능이 서비스마다 반복 구현되고, 서비스 간 인터페이스 차이로 지원 전환에 수주(week) 단위 개발 시간이 소요됨
• 이로 인해 전체 조직의 통합 설계가 혼란스러워지고 일관성이 깨지는 상황이 초래됨

자연스럽게 모든 통합 엔드포인트는 ‘MCP와 유사한 형태’로 수렴하게 됨

• 여러 엔드포인트가 결국 getTool, getResource, 컨텍스트 요청 등 MCP가 정의하는 기능과 매우 흡사한 구조로 진화함
• “처음에는 모든 공간을 쓰진 않더라도 점차 MCP의 형태로 확장될 수밖에 없다”고 강조함
• 내부 서비스와 상관 없이 MCP가 메시지 송수신(클라이언트/서버 간) 표준으로 작동할 수 있음을 확인

MCP는 표준 메시지 규격(JSON RPC)과 글로벌 트랜스포트 표준이라는 두 축으로 구성됨

• JSON RPC는 MCP의 ‘대화 용어’로, 엔지니어가 모델-서비스-컨텍스트 제공자 간 통신을 표준화함
• 글로벌 트랜스포트는 HTTP 스트리밍, OAuth 2.1 세션 등 전세계적으로 통일된 통신 규격을 의미하며, 규모 확장·연결성 측면에서 중요
• 메시지 규격 표준화 덕분에 조직 내외 코드가 동일한 방식으로 통신·확장 가능

내부 MCP 표준화는 엔지니어 교육·운영·확장에 구조적 이점을 제공함

• 모든 통합에서 하나의 표준(MCP)만 학습하면 되므로, 개발·운영 속도가 빨라지고 반복적인 ‘연결 파이프라인’ 고민에서 벗어날 수 있음
• 서비스A에서 잘 동작한 통합 코드를 서비스B로 옮길 때 추가 개발 비용이 거의 발생하지 않음(유지보수 용이)
• 각 신규 통합 시, 기존 문제점 해결 및 조직 내 표준 체계 강화를 자동으로 유발

MCP는 이미 산업계에서 표준 채택이 빠르게 진행되고 있으며, 장기적으로 반드시 필요함

• 주요 AI 연구실, 조직이 MCP 개발 및 표준 논의에 참여하고 있어 업계 표준으로 자리잡고 있음
• 프로토콜 발전에 따라 새 모델 기능(예: 새로운 툴, 관리 방식)이 MCP에 신속히 반영됨
• 내부적으로 ‘MCP 표준’을 채택하면 외부 변화·통합에 대한 대비가 자연스럽게 가능해짐

MCP가 내장하는 기능들은 복잡도 높은 케이스의 해결책을 사전에 제공함

• 예: 서로 다른 과금/토큰 모델을 가진 4개의 제품을 한 번에 슬라이드(프레젠테이션)와 연동해야 하는 경우, MCP 프로토콜은 샘플링 요청 프리미티브를 이미 내장하고 있음
• 별도 복잡한 로직 없이도, 해당 기능을 표준 방식으로 호출해 모든 시스템에서 일관 적용 가능

‘MCP Gateway’ 중앙 인프라 구축으로 통합·확장·운영을 ‘성공의 함정(pit of success)’으로 유도함

• 조직 전체가 ‘정답을 따르기 쉽게’ 시스템을 설계(=pit of success), 즉 엔지니어가 별다른 고민 없이 올바른 방식을 따르도록 유도
• MCP Gateway는 단일 인프라로서 모든 MCP 통신의 입구/출구 역할을 수행
• 내부 외부 서버, 서비스 구별 없이 동일한 호출 방식(URL+org/account ID) 사용
• 자동 크레덴셜 관리(OAuth 처리), 중앙 집중식 인증, 관찰성, 속도 조절 등 부가적 효과 획득
• ‘한 줄 코드로 MCP 접속’, ‘SDK 반환’ 구조로 새로운 프로토콜 기능도 자동으로 수용/사용

다양한 트랜스포트(웹소켓, gRPC, 이메일 등)에서도 MCP는 코드 일관성을 유지함

• Anthropic은 내부적으로 웹소켓을 기본 트랜스포트로 채택, JSON RPC 메시지를 블롭으로 송수신
• 필요하다면 gRPC(멀티플렉스 트랜스포트), 유닉스 소켓, IMAP 이메일 전송 등 상황별로 다양한 옵션이 가능
• 핵심은 메시지 흐름(read stream/write stream)만 맞추면 어떤 트랜스포트 위에서도 동일한 방식으로 MCP SDK 사용 가능

인증·크레덴셜 처리는 MCP Gateway에 집중시켜 서비스 복잡도를 제거함

• 인증 플로우(get OAuth URL, 인증 완료 등)까지 MCP Gateway에 집약, 각 서비스 개발자는 인증 구현 부담이 없음
• 다양한 인증 엔드포인트(Anthropic의 API, cloud.ai 등) 전환도 게이트웨이 차원에서 자동 지원
• 배치잡 등에서 재인증 없이 동일 크레덴셜로 요청·서비스 이용 가능
• 실제 구현: 내부 서비스가 MCP gateway로 웹소켓 + OAuth 토큰을 넘기면, 게이트웨이가 인증 된 SDK 세션을 반환

중앙 MCP Gateway로 보안/정책/운영 측면에서 강력한 통제력을 확보함

• 모든 메시지와 컨텍스트가 표준 MCP 포맷으로 중앙 게이트웨이를 통과하므로, 보안 정책 적용·감사·이상 탐지 용이
• 연구 논문에서 언급된 ‘MCP 기반 프롬프트 인젝션 공격’ 등도 감지 및 차단 가능
• ‘악성 서버 차단’, ‘요청 내용 분류’, ‘서비스별 별도 정책 부과’ 등으로 운영 안정성 제고
• “툴 실행/정의/리소스 관리 등 모든 흐름”에 플러그인 방식으로 개입 가능

MCP 기반 표준화는 조직에 지속적인 편의성과 미래 호환성을 제공함

• 새로운 서비스/언어/팀 별도 MCP 패키지 가져오기만으로 통합 가능(언어 불문)
• 엔지니어는 본질 기능(제품 개발)에 집중, 반복되는 통합작업은 최소화
• 단일 진입점·표준 메시지 포맷·지속적 프로토콜 진화와 연동된 자동 업데이트 효과로 장기적 유지보수·확장성이 극대화됨

MCP의 본질은 ‘JSON 스트림 표준화’이며, 조직 내 통합 방식(트랜스포트 등)은 부차적이며 쉽게 적용 가능함

• “MCP는 결국 JSON 스트림이다. 이를 어떻게 라우팅하든 본질은 몇 줄의 코드만으로 해결 가능”이라는 메시지 강조
• 어떤 표준이든 조속히 채택하는 게 조직 미래에 유리(미래의 자신에게 고마움을 얻게 됨)
• 성공의 함정, 중앙 집중화 등 핵심 전략을 효과적으로 적용할 것을 제안하며 발표를 마무리함