MCP proxy — 전송·연합·인증을 중개하는 층
이 장에서 처음 나오는 말5개
stdio transportStandard Input/Output Transport- client가 MCP server를 자식 process로 띄우고 표준 입출력으로 JSON-RPC message를 주고받는 방식이다. 같은 machine 안에서만 성립한다.
Streamable HTTP- server가 독립 process로 떠서 단일 HTTP endpoint로 요청을 받는 MCP 전송 방식이다. 응답은 JSON 하나 또는 SSE stream이다.
transport bridgeTransport Bridge- stdio와 Streamable HTTP를 서로 변환해 주는 얇은 process다. 한쪽에서만 지원하는 전송을 다른 쪽에 이어 준다.
MCP gatewayMCP Gateway- 여러 MCP server를 하나의 endpoint 뒤에 모으고 인증·tool 필터·audit·rate limit을 거는 층이다. 16장의 agentgateway가 한 예다.
confused deputyConfused Deputy- 권한이 큰 중개자가 요청자의 권한을 확인하지 않고 대신 행동해 공격자에게 이용당하는 문제다. MCP spec이 OAuth proxy에 대해 명시적으로 경고한다.
7장은 사용자가 만든 MCP server를 ToolVersion·ToolDeployment로 등록·배포하는
lifecycle을, 16장은 그 server들 앞에 놓을 수 있는 트래픽 층을 다뤘다.
그 사이에서 “MCP proxy를 쓰면 된다”는 말이 자주 나오는데, 이 말이 가리키는 물건은 하나가 아니다.
이 장은 그 세 가지를 갈라 놓고 각각이 이 덱의 어느 자리에 놓이는지 판정한다. 읽고 나면
“우리 환경에 MCP proxy가 필요한가”라는 질문을 “어느 어긋남을 메우려는가”로 바꿔 답할 수 있다.
MCP는 client가 server를 직접 붙이는 설계다
섹션 제목: “MCP는 client가 server를 직접 붙이는 설계다”MCP 스펙이 정의하는 표준 전송은 두 가지뿐이다. stdio는 client가 server를 자식 process로 띄우는 방식이라 같은 machine 안에서만 성립하고, Streamable HTTP는 server가 독립 process로 떠서 하나의 HTTP endpoint로 요청을 받는 방식이다. 어느 쪽이든 client 하나가 server 하나에 직접 연결하는 그림이고, 스펙에는 “중간에 무엇을 둔다”는 층이 없다.
실제 환경은 이 그림과 세 군데서 어긋난다.
| 어긋남 | 증상 | 메우는 물건 |
|---|---|---|
| 전송이 다르다 | stdio만 지원하는 server를 network 너머의 Agent가 써야 한다. 또는 그 반대 | transport bridge |
| 개수가 많다 | 승인된 server가 늘어 Agent마다 연결·자격증명·allowlist를 반복 설정한다 | gateway |
| 인증 주체가 다르다 | server가 third-party API 앞에 서서 OAuth client 역할을 대신한다 | OAuth proxy |
세 물건이 모두 “MCP proxy”라고 불린다. 어느 어긋남을 메우려는지 먼저 말해야 대화가 된다.
transport bridge — 전송을 바꾼다
섹션 제목: “transport bridge — 전송을 바꾼다”가장 좁은 뜻의 MCP proxy다. stdio server의 표준 입출력을 붙잡아 Streamable HTTP endpoint로 내놓거나, 반대로 원격 HTTP server를 stdio밖에 모르는 client에 자식 process처럼 보여 준다. 프로토콜 의미는 손대지 않고 message를 그대로 옮기므로 구현이 작고, 대표 구현 둘 다 MIT 라이선스다.
| 구현 | 방향 | 특징 |
|---|---|---|
| sparfenyuk/mcp-proxy (Python) | 양방향 | --named-server로 여러 stdio server를 /servers/<name>/ 경로에 함께 노출한다 |
| punkpeye/mcp-proxy (TypeScript) | stdio → HTTP·SSE | 2026-07-28 revision과 그 이전 revision을 같은 URL에서 함께 받는다. FastMCP가 HTTP를 내는 데 이것을 쓴다 |
이 덱에서 transport bridge는 이미 쓰고 있다. kmcp의 MCPServer에
transportType: stdio를 주면 controller가 sidecar gateway를 붙여 session마다 stdio process를 띄우고 HTTP로
노출한다 — kagent 실습 덱의 fetch tool이 정확히 이 경로다. 7장의 관리형 배포
경로에서 creator가 stdio server를 제출하면 adapter가 이 sidecar를 붙이는 것이지, creator가 bridge를 따로
고르는 것이 아니다.
두 가지를 조심한다. 첫째, kmcp 문서가 밝히듯 session마다 process를 새로 띄우는 구조는 package cache 상태에
따라 시작 지연이 생기므로, production ToolVersion은 처음부터 Streamable HTTP를 말하는 server로 만드는
편이 낫다. 둘째, 스펙의 보안 지침은
“proxy가 stdio process를 spawn하는 구조”를 별도 항목으로 경고한다 — client 쪽 XSS가 proxy의 인증 token을
훔치면 임의 command 실행으로 번질 수 있으므로, spawn되는 process를 sandbox하고 command를 log한다.
7장이 npx package@latest를 그대로 실행하지 않고 image digest로 고정하라고 한 이유와 같은 뿌리다.
gateway — 여러 server를 하나로 모은다
섹션 제목: “gateway — 여러 server를 하나로 모은다”두 번째 뜻은 승인된 server 여러 개를 endpoint 하나 뒤에 연합하고, 그 자리에서 인증·tool 노출 필터·audit·rate limit을 거는 층이다. Agent마다 server N개를 연결하던 반복 비용이 한 번의 gateway 설정으로 줄고, 모든 tool 트래픽이 한 곳을 지나므로 egress 통제와 감사가 쉬워진다.
이 덱은 이 층을 이미 두 곳에서 다뤘다. 온프렘 후보는 16장의 agentgateway이고, AWS target에서는 13장의 AgentCore Gateway가 API·Lambda·MCP를 tool로 노출하는 같은 역할을 관리형으로 제공한다. 그래서 gateway 뜻의 MCP proxy는 이 장에서 새로 판정하지 않는다 — 16장의 결론, 즉 “트래픽 층은 맡되 5장의 세 문은 대신하지 못한다”와 “승인된 server 수가 실제로 늘었을 때 검토를 연다”가 그대로 적용된다.
OAuth proxy — 스펙이 말하는 MCP proxy server
섹션 제목: “OAuth proxy — 스펙이 말하는 MCP proxy server”세 번째는 MCP 스펙 자체가 쓰는 용어다. 보안 지침은 MCP proxy server를 “MCP client를 third-party API에 연결하며, 그 API의 authorization server에 대해 단일 OAuth client로 행동하는 MCP server”로 정의한다. Google Drive나 사내 SaaS 앞에 서는 MCP server가 대개 이 형태다 — server가 자기 client ID 하나로 third-party에 로그인하고, 뒤에 오는 여러 MCP client를 그 하나의 신원 뒤에 숨긴다.
여기서 confused deputy가 생긴다. proxy가 static client ID를 쓰고, MCP client는 동적으로 등록되며,
third-party authorization server가 첫 동의 뒤 consent cookie를 남기면, 공격자가 만든 client의 authorization
요청이 사용자의 cookie를 타고 동의 화면 없이 통과한다. 스펙은 이를 막기 위해 proxy가 client마다 자체
동의 화면을 먼저 보이고, redirect_uri를 정확히 일치시키며, state를 동의 승인 뒤에만 발급하도록
요구한다. 같은 문서의 token passthrough 금지 — client에게 받은 token을 검증 없이 downstream에 넘기지
않는다 — 도 이 형태의 server에 직접 걸린다.
이 덱에서 OAuth proxy는 새 구성 요소가 아니라 ToolVersion 검사 항목이다. 7장 creator 계약의
identity.outbound: user-delegation은 server가 사용자 위임 권한으로 downstream을 부른다는 선언인데,
그 server가 third-party에 대해 OAuth proxy 형태라면 검증 단계에서 per-client consent와 audience 검증
구현 여부를 확인하고, 없으면 승인하지 않는다. 5장의 세 번째 문이
말하는 action 권한은 proxy가 third-party에 로그인했다는 사실로 대체되지 않는다.
2026-07-28 revision이 proxy에 준 자리
섹션 제목: “2026-07-28 revision이 proxy에 준 자리”최신 MCP revision은 세 뜻 모두에 영향을 주는 변화를 담았다. 요지는 스펙이 처음으로 중개자를 1급 참여자로 인정했다는 것이다.
- session이 사라졌다.
Mcp-Session-Idheader와initializehandshake가 없어지고 요청마다 protocol version과 capability를_meta에 싣는다. gateway가 backend 여러 대에 요청을 분산할 때 session 고정을 신경 쓸 필요가 없어졌다. - body 값을 header에 비춘다.
Mcp-Method·Mcp-Nameheader가 필수가 됐고, tool schema에x-mcp-header를 붙이면 인자가Mcp-Param-{Name}header로도 나간다. 스펙은 이유를 “load balancer·gateway· 관측 도구가 body를 파싱하지 않고 라우팅·검사하도록”이라고 명시한다. 대신 server는 header와 body가 다르면400으로 거부해야 하고, header로 정책을 거는 중개자는 protocol version이 이 검증을 요구하는 revision인지 먼저 확인해야 한다 — 구 revision 요청의 header는 검증되지 않은 값이기 때문이다. - GET stream과 재개(
Last-Event-ID)가 사라졌다. 끊긴 stream은 새 요청으로 다시 보낸다. proxy가 stream 상태를 복원할 책임이 없어진 대신, 긴 SSE 응답이 중간 proxy에서 buffering되지 않도록X-Accel-Buffering: no를 내보내야 한다.
한 가지 함정이 따라온다. 2025-11-25까지의 client와 2026-07-28 server가 섞이는 기간에는 proxy가 두 era를 모두 말해야 한다. punkpeye/mcp-proxy가 같은 endpoint에서 두 revision을 구분해 받는 것이 그 대응이고, 사내 gateway 후보를 고를 때도 era 감지와 fallback을 검증 항목에 넣는다.
이 덱의 자리 판정
섹션 제목: “이 덱의 자리 판정”| 뜻 | 이 덱의 자리 | 결정 상태 |
|---|---|---|
| transport bridge | adapter 구현 세부. ToolDeployment.providerRef 안에 있고 creator에게 보이지 않는다 | kmcp stdio sidecar로 이미 사용. production은 HTTP native 권장 |
| gateway | 16장 트래픽 층. 결정 A·B와 독립 | 16장 판정 그대로 — 승인된 server 수가 늘면 검토 |
| OAuth proxy | ToolVersion 검증 항목. 새 구성 요소가 아니다 | per-client consent·audience 검증 없는 server는 승인하지 않음 |
- MCP 스펙의 표준 전송은 stdio와 Streamable HTTP 둘뿐이고 client가 server를 직접 붙이는 설계다. “MCP proxy”는 그 그림과 실제 환경의 세 어긋남 — 전송·개수·인증 주체 — 을 메우는 세 물건을 한 이름으로 부른 것이다.
- transport bridge는 kmcp의 stdio sidecar로 이미 쓰고 있는 adapter 세부다. 시작 지연과 spawn 보안 때문에 production ToolVersion은 HTTP native로 만든다.
- gateway 뜻은 16장 agentgateway와 13장 AgentCore Gateway가 맡은 자리이고, 판정도 16장을 따른다.
- OAuth proxy는 스펙이 confused deputy를 경고하는 “MCP proxy server”다. 새 구성 요소가 아니라 ToolVersion 검증 항목으로 둔다.
- 2026-07-28 revision은 session 제거와 header 미러링으로 중개자를 스펙 안에 들였다. 대신 header–body 검증과 두 era 호환이 proxy의 새 책임이 됐다.
참고 자료
섹션 제목: “참고 자료”- MCP Transports (2026-07-28) — stdio·Streamable HTTP 정의와 custom transport 조건.
- Streamable HTTP (2026-07-28) —
Mcp-Method·Mcp-Name·Mcp-Param-*header, 중개자 관련 요구, 구 revision 호환. - Key Changes 2026-07-28 — session 제거,
_meta기반 stateless, GET stream·재개 제거. - Security Best Practices (2025-11-25) — MCP proxy server 정의, confused deputy, token passthrough, proxy의 stdio spawn 경고.
- Authorization (2025-11-25) — OAuth 2.1 기반 HTTP 전송 인증과 MCP server의 resource server 역할.
- sparfenyuk/mcp-proxy, punkpeye/mcp-proxy — transport bridge 대표 구현.
- kmcp API reference —
MCPServer.transportType과 stdio sidecar gateway 설명.