MCP 프록시란 무엇인가 - 그리고 언제 게이트웨이가 실제로 필요한가?

요약 (TL;DR)

• MCP 프록시(MCP proxy)는 AI 에이전트와 MCP 서버 간의 요청을 전달합니다. 이는 전송(transport)을 처리할 뿐, 거버넌스(governance)를 처리하지는 않습니다. 설정은 빠르지만, 팀이 하나 이상이거나 서버가 두 개 이상이 되는 순간 한계에 부딪힙니다.
• MCP 게이트웨이(MCP gateway)는 해당 라우팅 계층 위에 신원(identity), 역할 기반 액세스 제어 (RBAC), 감사 추적(audit trails), 그리고 도구별 정책 집행(per-tool policy enforcement)을 추가합니다. 즉, 조직의 실제 AI 정책이 집행되는 곳입니다.
• 우리는 프록시로 시작했다가 프록시가 처리하지 못하는 바로 그 문제들 때문에 고생했고, 결국 게이트웨이가 필요하게 되었습니다. 이 글은 제가 그런 결정을 내리기 전에 읽었더라면 좋았을 내용입니다.

우리 엔지니어링 팀을 위해 MCP 서버를 연결하기 시작했을 때, 저는 계속해서 "MCP 프록시"라는 용어를 접하게 되었고, 그것이 정확히 무엇을 의미하는지 또는 "MCP 게이트웨이"와 어떻게 다른지 완전히 확신하지 못했습니다. 둘 다 AI 클라이언트와 MCP 서버 사이에 위치합니다. 둘 다 요청을 전달합니다. 그 차이는 실질적인 내용이라기보다 브랜딩(branding)처럼 보였습니다.

하지만 그렇지 않습니다. 저는 비싼 대가를 치르고 나서야 그것을 깨달았습니다.

여기에 제가 결국 조각조각 모아 정리한 명확한 설명과, 그 차이가 중요해졌던 실제 상황을 정리했습니다.

MCP 프록시의 실제 정의

MCP 프록시는 전송 계층(transport layer)입니다. 이 기능의 역할은 프로토콜 중재(protocol mediation)입니다. 즉, MCP 클라이언트로부터 MCP 서버로 요청을 전달하고, 응답을 다시 돌려주는 것입니다. 그것이 전부입니다.

프록시를 사용하는 가장 흔한 이유는 stdio 문제입니다. Claude Code, Cursor, 그리고 대부분의 로컬 MCP 클라이언트는 stdio를 사용합니다. 즉, 서버 프로세스를 실행하고 stdin/stdout을 통해 통신하기를 기대합니다. 하지만 만약 MCP 서버가 원격으로 실행 중이라면 (Docker 컨테이너 내부, 스테이징 서버, 또는 다른 사람의 컴퓨터 등), 중간에서 해당 stdio 인터페이스를 감싸고 이를 HTTP/SSE 또는 WebSockets를 통해 노출하여 원격 클라이언트가 접근할 수 있게 해주는 무언가가 필요합니다. 그것이 바로 프록시입니다.

프록시가 하지 않는 일:

프록시는 다음을 수행하지 않습니다:

두 번째 문제는 프롬프트 인젝션 (Prompt Injection)에 의한 아찔한 사고였습니다. 한 에이전트가 컨텍스트 (Context)로 문서를 가져오기 위해 Confluence MCP 서버를 사용하고 있었습니다. 한 업체가 Confluence에 지원 티켓을 남겼는데, 알고 보니 서식 내에 삽입된 인젝션 명령어가 포함되어 있었습니다. Claude는 티켓 내용을 처리했고, 사람이 이를 발견하기 전에 삽입된 텍스트의 단계들을 실행하기 시작했습니다. 파괴적인 결과가 발생하지는 않았지만, 이는 "에이전트와 도구 사이에 정책 계층 (Policy Layer)이 없다"는 것이 실제로 무엇을 의미하는지를 보여주는 생생한 사례였습니다.

세 번째 문제는 가시성 (Visibility)이었습니다. 보안 책임자가 "지난 30일 동안 어떤 에이전트가 우리의 내부 데이터 API에 접근했으며, 어떤 파라미터 (Parameters)를 사용했는가?"라고 물었을 때, 정직한 답변은 "모릅니다"였습니다. API 자체에는 서버 로그가 있었지만, 어떤 에이전트나 사용자 식별자 (User Identity)가 각 호출을 트리거했는지에 대한 상관관계는 없었습니다. 감사 추적 (Audit Trail)이 네트워크 계층에서 끊겨 있었던 것입니다.

그 순간 저희 팀은 우리가 직면한 문제가 프록시 (Proxy) 문제가 아니라는 것을 깨달았습니다. 우리는 거버넌스 (Governance) 문제를 겪고 있었습니다. 그리고 프록시는 이 문제를 해결해 줄 수 없었습니다.

실제적인 차이점: 프록시 vs 게이트웨이 (Proxy vs Gateway)

결국 제가 이해하게 된 사고 모델 (Mental Model)은 다음과 같습니다:

프록시는 다음을 답변합니다: 이 요청이 목적지에 도달할 수 있는가?

게이트웨이는 다음을 답변합니다: 이 요청이 아예 허용되어야 하는가 — 그리고 이 요청이 수행되었다는 기록이 있는가?

화이트보드 위에서는 이 구분이 미묘해 보일 수 있습니다. 하지만 운영 환경 (Production)에서 이는 "MCP가 실행 중이다"와 "MCP가 거버넌스 하에 관리되고 있다"의 차이입니다.

구체적으로, 게이트웨이는 다음을 추가합니다:

식별 및 인증 (Identity and Authentication). 게이트웨이는 누가 요청을 보내는지 압니다. 단순히 어떤 클라이언트인지를 넘어, 기업의 IdP (Identity Provider, OAuth 2.0, SAML, SSO)를 통해 인증된 어떤 실제 사용자인지를 압니다. 이것이 액세스 권한 취소 (Access Revocation)를 깔끔하게 작동하게 만드는 핵심입니다. 예를 들어 Okta에서 누군가의 계정을 해지하면, 해당 사용자의 토큰은 게이트웨이에서 작동을 멈추고, 그 즉시 모든 MCP 서버에 대한 접근 권한을 잃게 됩니다.

도구 수준의 RBAC (Role-Based Access Control, 역할 기반 액세스 제어). 단순히 "팀 A가 GitHub 서버에 접근할 수 있다"는 수준을 넘어, "팀 A는 search_repositories와 read_file은 사용할 수 있지만, push_commit이나 delete_branch는 사용할 수 없다"와 같은 제어가 가능합니다. 이러한 세밀함(Granularity)이야말로 단순한 의도를 넘어선 실제 정책(Policy)을 구분 짓는 요소입니다.

도구 호출별 감사 추적 (Audit trail). 모든 호출은 사용자 식별 정보, 도구 이름, 요청 파라미터, 응답 및 지연 시간(Latency)과 함께 로그로 기록됩니다. 이는 쿼리가 가능하며, SIEM (Security Information and Event Management)으로 내보낼 수도 있습니다. 이것이 바로 보안 팀의 질문에 답할 수 있게 만드는 핵심입니다.

실행 전후 가드레일 (Pre- and post-execution guardrails). 도구가 실행되기 전(이 입력값이 허용되어야 하는가?)과 실행된 후(이 출력값에 개인정보(PII)나 비밀 정보(Secrets)가 포함되어 에이전트의 컨텍스트로 돌아가기 전에 제거해야 하는가?)에 정책을 평가합니다. 이는 프롬프트 인젝션 (Prompt Injection) 완화 전략이기도 합니다. 게이트웨이는 도구의 응답을 검사하여, 주입된 명령어가 에이전트에 도달하기 전에 이를 제거하거나 플래그를 지정할 수 있습니다.

통합 자격 증명 관리 (Unified credential management). 사용자는 게이트웨이에 한 번만 인증합니다. 게이트웨이는 모든 다운스트림 MCP 서버에 대한 아웃바운드 인증을 처리합니다. 자격 증명(Credentials)은 개발자의 로컬 머신이 아닌 볼트(Vault)에 저장됩니다.

우리가 실제로 사용하게 된 것

감사(Audit) 관련 사고 이후, 우리는 몇 가지 옵션을 검토했습니다. 솔직히 말씀드리면, 여러 번의 고민 끝에 우리는 TrueFoundry의 MCP Gateway를 선택했습니다. 왜 이 아키텍처가 우리의 문제에 적합했는지 구체적으로 설명하겠습니다.

우리에게 가장 중요했던 점은 통합된 토큰 관리였습니다. 게이트웨이를 도입하기 전에는 서버가 6개라면 개발자 한 명당 6개의 자격 증명 관계가 필요했습니다. TrueFoundry를 사용하면 각 개발자는 단 하나의 개인 액세스 토큰 (Personal Access Token, PAT)만 받으면 됩니다. 게이트웨이는 해당 토큰과 GitHub, Confluence, Jira, Sentry, Datadog에 대한 OAuth 자격 증명 간의 매핑을 유지하며, 만료 시 자동으로 갱신합니다. 오프보딩(Offboarding)은 단 한 번의 작업, 즉 PAT를 취소하는 것으로 끝납니다. 그것으로 충분합니다.

두 번째는 가상 MCP 서버 (Virtual MCP Servers)였습니다. 이는 저희가 직접 구축하기 전까지는 다른 곳에서 본 적이 없는 개념입니다. 에이전트에게 파괴적인 도구를 포함한 모든 도구가 담긴 전체 MCP 서버를 노출하는 대신, 특정 팀이나 에이전트가 보기를 원하는 도구만을 노출하는 큐레이션된 논리적 엔드포인트 (logical endpoint)를 정의합니다. 저희 제품 엔지니어링 팀의 "dev tools" 엔드포인트는 GitHub 읽기 도구, Jira 읽기/쓰기, 그리고 Sentry를 노출합니다. 내부 데이터 API나 Datadog 쓰기 도구는 노출하지 않습니다. 이러한 도구들은 보안 팀의 엔드포인트에만 나타납니다. 에이전트는 하나의 깔끔한 접점 (surface)을 보게 되며, 거버넌스 (governance)는 플랫폼 내에서 관리됩니다.

세 번째는 가드레일 (guardrail) 계층이었습니다. 실행 전 검사 (Pre-execution checks)는 무언가가 실행되기 전에 정의된 정책에 따라 도구 입력을 검증합니다. 실행 후 검증 (Post-execution validation)은 도구 응답이 에이전트의 컨텍스트 (context)에 도달하기 전에 개인정보 (PII), 비밀 정보 (secrets), 또는 주입된 콘텐츠 (injected content)가 있는지 검사합니다. 이는 저희가 이미 겪었던 Confluence 프롬프트 인젝션 (prompt injection) 사고를 직접적으로 해결합니다.

실제 환경에서 성능 오버헤드 (performance overhead)는 문제가 되지 않았습니다. 문서에 따르면 요청당 DB 조회 대신 인메모리 인증 (in-memory auth) 및 속도 제한 (rate limiting)을 사용하여 부하 상황에서도 3ms 미만의 지연 시간 (latency)을 기록합니다. 워크플로당 수십 번의 도구 호출을 수행하는 에이전트에게 이는 매우 중요한 요소입니다.

프록시가 실제로 정답인 경우

프록시가 항상 틀린 것처럼 들리게 하고 싶지는 않습니다. 그렇지 않습니다.

다음과 같은 경우에는 아마도 프록시만 필요할 것입니다:

• 개발 환경에서 로컬 AI 클라이언트를 한두 개의 MCP 서버에 연결하는 1인 개발자인 경우
• 개념 증명 (proof-of-concept)을 진행 중이며 거버넌스 (governance)가 아직 범위에 포함되지 않은 경우
• 유일한 문제가 stdio-to-HTTP 전송 격차 (transport gap)인 경우 — 로컬 STDIO 서버를 가지고 있고 이를 원격으로 노출해야 하는 경우

다음과 같은 경우에는 게이트웨이가 필요합니다:

• 여러 명이 MCP 도구 (tools)를 사용하고 있으며, 누가 무엇에 접근할 수 있는지 제어해야 하는 경우
• 보안 팀이나 컴플라이언스 (compliance) 요구 사항을 충족하는 감사 추적 (audit trail)이 필요한 경우
• 에이전트 (agents)가 민감한 내부 시스템에 접근하고 있으며, 이들이 무엇을 건드렸는지 파악해야 하는 경우
• 팀원이 퇴사할 때 해당 인원의 도구 접근 권한을 확실하게 차단해야 하는 경우
• MCP 도구 응답을 통한 프롬프트 인젝션 (prompt injection) 사고가 발생했거나 발생할 뻔한 경우

솔직한 버전: 대부분의 팀은 무언가를 작동시키는 가장 빠른 방법이기 때문에 프록시 (proxy)로 시작합니다. 그것은 괜찮습니다. 실수는 시스템이 이미 프록시가 관리할 수 있는 수준을 넘어섰음에도 불구하고, 프록시를 영구적인 솔루션으로 취급하는 것입니다.

지금 던져야 할 질문

만약 현재 조직 내에서 MCP 도구들이 실행되고 있다면, 제가 던질 구체적인 질문은 다음과 같습니다: 만약 보안 팀이 "지난 30일 동안 어떤 에이전트가 누구의 신원으로 어떤 도구를 호출했는가?"라고 묻는다면, 당신은 답변할 수 있습니까?

만약 그렇다면 - 좋습니다, 당신의 거버넌스 (governance) 계층이 제대로 작동하고 있는 것입니다.

만약 아니라면 - 당신은 게이트웨이 (gateway)가 필요한 곳에 프록시를 사용하고 있을 가능성이 높습니다.

다른 분들은 무엇을 운영하고 있는지 궁금합니다. 대부분의 사람들이 여전히 가공되지 않은 프록시 설정을 사용하고 있나요, 아니면 보안 압박으로 인해 예상보다 빠르게 팀들이 적절한 게이트웨이로 이동하고 있나요? 그리고 MCP 도구 응답을 통한 프롬프트 인젝션 문제를 대규모로 다뤄본 분이 계신가요? 실제로 무엇이 효과적이었는지 듣고 싶습니다. 아래에 댓글을 남겨주세요.