MCP 서버, 언제 게이트웨이로 묶을까? 도입 기준과 비용 비교

여러 에이전트 클라이언트에서 MCP 서버 접근 규칙을 공통으로 적용해야 한다면 MCP 게이트웨이 도입을 검토할 때입니다. 개발자 6명이 클라이언트 4개에서 MCP 서버 8개를 쓰면 클라이언트와 서버 간 연결 설정이 192개에 이를 수 있습니다. 도입의 핵심 가치는 접근 권한을 관리하고 툴 호출을 조사할 지점을 하나로 모으는 데 있습니다. 운영 비용을 책임질 담당자도 분명해야 합니다.

MCP 서버 접근을 관리하는 게이트웨이의 역할

MCP 게이트웨이는 에이전트와 MCP 서버 사이에서 인증, 툴 허용 목록, 로깅, 호출 횟수 제한을 관리하는 공통 제어 지점입니다. MCP(Model Context Protocol)는 AI 애플리케이션이 툴을 찾고 실행을 요청할 때 사용하는 공통 인터페이스입니다. 게이트웨이는 이런 연결을 한곳에서 관리하도록 해줍니다. 제공하는 제어 기능은 구현마다 다릅니다. Kong의 MCP 게이트웨이 설명은 이러한 프록시와 정책 적용 역할을 다룹니다.

운영 업무를 돕는 어시스턴트가 고객 정보를 조회한 뒤 지원 티켓을 수정하는 상황을 생각해 보겠습니다. MCP 서버는 이 작업들을 툴로 제공합니다. 게이트웨이는 호출 주체가 누구인지, 그 주체에게 어떤 작업을 허용할지, 실행 결과가 어땠는지를 확인할 수 있어야 합니다.

Claude, ChatGPT, Codex, Cursor를 사용하는 개발자에게는 조직이 승인한 클라이언트 전반에 일관된 툴 접근 권한을 적용할 수 있다는 이점이 있습니다. 다만 클라이언트별 요금제, 인증 지원, 연결 방식은 각각 확인해야 합니다.

각 제어 기능의 역할은 다음과 같습니다.

• 인증: 요청을 보낸 사람이나 워크로드의 신원을 확인합니다. 그 주체가 무엇을 할 수 있는지는 인가 단계에서 결정합니다. API 키 하나를 공유하면 개인별 책임 소재가 드러나지 않을 수 있습니다.
• 툴 허용 목록: 의도적으로 선택한 작업만 노출하고 실행을 허용합니다. 예를 들어 지원 어시스턴트에는 고객 조회를 허용하되 삭제 툴은 차단할 수 있습니다. 툴 목록을 보여줄 때뿐 아니라 실제로 호출할 때도 규칙을 적용해야 합니다.
• 로깅: 작업을 조사하는 데 필요한 호출 주체, 서버, 툴, 정책 판단, 실행 결과를 남깁니다. 어떤 인수를 기록할지, 민감한 값은 어떻게 처리할지도 정해야 합니다.
• 호출 횟수 제한: 보호해야 할 대상에 맞춰 호출 주체별, 툴별, 업스트림 서비스별로 호출량을 제한합니다. 같은 작업을 반복하는 에이전트는 백엔드에 과부하를 주기 전에 정해진 한도에 걸려야 합니다.

이 기능들은 직접 확인해야 할 요구사항입니다. 제품 이름에 게이트웨이가 들어간다고 해서 모두 제공되는 것은 아닙니다. 로컬 툴을 모아주는 도구는 유용할 수 있지만, 조직의 신원 관리나 호출 횟수 제한은 별도로 구현해야 할 수도 있습니다.

MCP 게이트웨이와 MCP 서버의 차이

MCP 서버는 기능을 제공하고, MCP 게이트웨이는 하나 이상의 서버에 대한 접근을 관리합니다. 서버는 데이터베이스 조회나 티켓 생성 같은 작업을 제공할 수 있습니다. 게이트웨이는 승인된 기능을 클라이언트에 보여주고, 호출을 라우팅하며, 설정된 제어 규칙을 적용합니다.

MCP 아키텍처에서 클라이언트는 tools/list로 툴을 찾고 tools/call로 호출합니다. 게이트웨이는 에이전트 쪽에는 서버로, 업스트림 서버 쪽에는 클라이언트로 동작할 수 있습니다. 호출 주체가 어떤 레코드를 읽거나 수정할 수 있는지는 여전히 실제 애플리케이션이 결정합니다.

예를 들어 티켓 수정 툴을 허용했다고 해서 모든 고객 계정에 접근할 수 있는 것은 아닙니다. 레코드 단위 권한과 테넌트 간 경계는 애플리케이션과 서버 연동 계층이 책임져야 합니다.

AI·LLM 게이트웨이와는 무엇이 다른가요?

AI 또는 LLM(대규모 언어 모델) 게이트웨이는 모델로 보내는 요청을 관리합니다. MCP 게이트웨이는 툴로 보내는 요청을 관리합니다. 이 차이에 따라 해결할 수 있는 문제가 달라집니다.

Cloudflare AI Gateway는 모델 요청 로깅, 캐싱, 호출 횟수 제한, 재시도, 폴백을 문서화하고 있습니다. 이런 기능은 추론 비용과 제공업체의 안정성을 관리하는 데 도움이 됩니다. 반면 MCP 게이트웨이의 툴 정책은 에이전트가 고객 시스템에서 승인된 작업을 실행해도 되는지 판단할 수 있습니다.

두 경로를 모두 다루는 제품도 있습니다. 그래도 각 경로는 따로 평가해야 합니다. 모델 예산을 설정했다고 툴 권한까지 보장되는 것은 아니며, 툴 허용 목록이 모든 모델 요청량을 제한하지도 않습니다. 예산을 투입하려는 문제가 모델 라우팅, 추론 비용, 제공업체 장애라면 코딩 에이전트용 AI 게이트웨이 비교를 참고하십시오.

일반 API 게이트웨이도 HTTP 요청을 인증하고 호출량을 제한할 수 있습니다. MCP를 이해하는 관리 계층은 요청 안의 의미까지 다룹니다. 툴 탐색, 툴 이름, 호출 인수가 그 대상입니다. 여러 작업이 같은 /mcp URL을 사용할 수 있으므로, 해당 URL만 허용하는 규칙은 의도한 툴 정책보다 훨씬 넓은 권한을 줄 수 있습니다.

2026년 9월 24일, 실제로 달라진 점

Cloudflare는 2026년 9월 24일 MCP Server Portals를 모든 Cloudflare 고객에게 정식 출시했습니다. 공식 발표는 승인된 서버를 연결하는 단일 엔드포인트와 툴·프롬프트·리소스 활동을 기록하는 Access 로그를 설명합니다.

발표에는 자율 에이전트용 서비스 토큰 인증, 더 상세한 HTTP 로깅과 데이터 손실 방지를 위한 Gateway 라우팅, 활동 기록을 내보내는 Logpush 지원도 포함되어 있습니다. 데이터 손실 방지(DLP)는 민감한 정보에 관한 규칙에 따라 콘텐츠를 검사하는 기능입니다.

이 출시로 게이트웨이 프로세스를 직접 운영하지 않고도 원격 MCP 접근을 중앙에서 관리할 수 있는 선택지가 생겼습니다. 다만 서비스를 사용할 수 있게 되었다고 해서 검토가 끝나는 것은 아닙니다. 보유한 서버와 클라이언트가 호환되는지, 필요한 감사 기능이 요금제에 포함되는지를 판단해야 합니다.

MCP 게이트웨이는 이전부터 존재하던 아키텍처 패턴입니다. 이번 출시는 특정 관리형 서비스의 제공 범위를 바꾼 것이며, 모든 MCP 연결에 게이트웨이가 필요해졌다는 뜻은 아닙니다.

소규모 팀은 언제 MCP 게이트웨이를 도입해야 하나요?

클라이언트, 직원, 서버 담당자가 바뀌어도 접근 정책을 일관되게 유지해야 한다면 게이트웨이가 필요합니다. 서버가 몇 개 수준을 넘어서는 것은 참고할 만한 신호지만, 더 중요한 계기는 정책이 여러 곳으로 흩어지는 상황입니다.

같은 개발자가 여러 클라이언트를 쓰고, 모든 클라이언트에서 같은 제한된 툴 집합이 필요하다면 도입을 검토하십시오. 운영팀이 접근을 철회하거나 작업 이력을 재구성해야 할 때, 민감한 툴이나 데이터를 변경할 수 있는 툴에 공통 정책을 적용해야 할 때도 마찬가지입니다. 영향이 큰 쓰기 작업이 있는 작은 환경이라면, 공개 문서 조회 툴이 많이 모인 환경보다 이런 관리가 더 일찍 필요할 수 있습니다.

예시로 개발자 6명, 에이전트 클라이언트 4개, MCP 서버 8개가 있고, 모든 개발자가 각 클라이언트에 모든 서버를 설정한다고 가정하겠습니다.

• 직접 연결: 6 × 4 × 8 = 192개의 클라이언트-서버 연결 설정입니다.
• 공용 게이트웨이 하나: 6 × 4 = 24개의 클라이언트-게이트웨이 연결 설정에 업스트림 엔드포인트 정의 8개를 더합니다.
• 엔드포인트 참조 합계: 32개입니다.

이는 연결 설정 수를 계산한 예시이며, 실제 배포 관측값이나 성능 측정 결과가 아닙니다. 이미 설정을 중앙에서 배포하고 있을 수도 있고, 역할에 따라 서로 다른 게이트웨이나 프로필이 필요할 수도 있습니다. 각 사용자가 서비스에 부여하는 업스트림 OAuth 권한 역시 엔드포인트 정의와는 별도로 관리해야 합니다.

게이트웨이의 가치는 승인된 서버 주소나 툴 정책을 중앙에서 변경할 수 있다는 데 있습니다. 물론 중앙에서 잘못된 설정을 적용할 가능성도 있습니다. 정책을 버전 관리하고, 누가 변경할 수 있는지 정하십시오.

도입을 미뤄도 되는 경우는 담당자 한 명이 기존 신원 관리 기능과 공용 설정으로 작고 위험도가 낮은 툴 집합을 이미 관리할 수 있을 때입니다. 게이트웨이를 추가하면 서비스와 의존성이 늘고 장애가 발생할 경로도 하나 더 생깁니다. 해결하려는 운영 문제를 구체적으로 짚을 수 있어야 합니다.

에이전트가 MCP 툴을 사용하지 않는다면 직접적인 영향이 없습니다. 모델 요청만 관리하려는 경우에는 LLM 게이트웨이부터 검토하십시오. 애플리케이션이 필요한 툴 정책과 감사 경로를 이미 갖추고 있다면, 그 관리 범위를 개선할 수 있을 때 게이트웨이를 추가하십시오.

개발·운영·구매 담당자가 확인할 사항

개발 담당자: 전송 방식부터 확인합니다

운영 중인 서버에 연결할 수 있는 게이트웨이를 선택하십시오. stdio는 클라이언트가 입출력 스트림을 통해 로컬 프로세스와 통신하는 방식입니다. Streamable HTTP는 MCP 트래픽을 원격 엔드포인트로 전달합니다. 프로토콜 아키텍처는 두 방식을 모두 설명합니다.

관리형 원격 게이트웨이가 노트북의 stdio 프로세스를 자동으로 실행해주는 것은 아닙니다. 이 프로세스를 호스팅되는 HTTP 서비스로 바꾸려면 배포와 자격 증명 관리 작업이 필요합니다. 클라이언트 설정을 교체하기 전에 전송 방식의 호환성을 확인하십시오.

운영 담당자: 실제 호출 경로를 관리합니다

공통 정책은 대상 호출이 그 경로를 통과할 때만 효과가 있습니다. 게이트웨이 연결뿐 아니라 직접 연결에 쓰는 자격 증명과 엔드포인트도 목록에 포함하십시오. 승인된 클라이언트가 툴에 접근하는 방식, 사고 기록을 남길 위치, 게이트웨이 장애 시 복구 담당자를 정해야 합니다.

지원 업무에서는 티켓을 바꾼 주체와 작업을 확인할 수 있는 기록이 필요합니다. 연결 성공 로그만으로는 그 질문에 답할 수 없습니다. 모든 로깅 기능이 같은 증거를 제공한다고 가정하지 말고, 선택한 제품이 실제로 남기는 기록을 확인하십시오.

구매 담당자: 필요한 관리 범위에 비용을 씁니다

게이트웨이, 업스트림 서버, 양쪽 운영을 맡을 담당자의 비용을 함께 잡으십시오. Free 플랜이 사용자 수 조건은 충족해도 필요한 로그 보존 기간에는 못 미칠 수 있습니다. 오픈소스 소프트웨어가 배포 요구사항에 맞더라도 신원 관리 연동은 추가로 필요할 수 있습니다.

요구사항이 미승인 서버 탐지, 상세한 런타임 검사, 기업 차원의 사고 대응까지 넓어진다면 기업용 에이전트를 위한 MCP 보안 플랫폼 비교에서 더 넓은 범위의 구매 기준을 확인할 수 있습니다.

MCP 게이트웨이 3종 비교: 2026년 10월 4일 확인 기준

Cloudflare는 원격 접근을 관리형 서비스로 통제할 때, Docker는 서버를 컨테이너로 운영할 때, Lasso는 플러그인으로 요청 흐름을 조정할 때 적합합니다. 선택 기준은 전송 방식, 접근 제어, 로깅, 서비스 운영 주체입니다.

아래 가격과 라이선스는 2026년 10월 4일 각 제공업체의 공개 페이지와 저장소에서 확인했습니다. 뒤에서 다루는 비용 시나리오는 명시된 가정을 바탕으로 계산한 값입니다.

출처: Cloudflare 요금제, Docker 라이선스, Lasso 라이선스.

Cloudflare MCP Server Portals

Cloudflare MCP Server Portals는 Cloudflare One이 조직의 신원 관리와 운영 요구사항에 맞을 때, 승인된 원격 MCP 서버를 관리하는 선택지입니다. 여러 서버를 하나의 HTTP 엔드포인트로 묶고, Cloudflare Access로 인증하며, 관리자가 포털에 노출할 툴과 프롬프트를 선택할 수 있게 합니다.

현재 요금표에는 최대 50명까지 $0인 Free, 사용자당 월 $7인 Pay-as-you-go, 사용자당 연간 가격을 별도로 협의하는 Contract 플랜이 나와 있습니다. 표준 로그 보존 기간은 Free에서 최대 24시간, Pay-as-you-go에서 최대 30일로 기재되어 있으며, 실제 기간은 사용하는 서비스에 따라 달라집니다.

주요 제약은 호환성과 감사 기능의 이용 자격입니다. Cloudflare 포털 문서에 따르면 원격 HTTP MCP 서버를 지원하며, 포털 하나에 최대 80개 서버를 연결할 수 있습니다. stdio만 지원하는 서버는 먼저 인증을 적용한 HTTP 엔드포인트로 호스팅해야 합니다. 일부 업스트림 서버는 프록시를 거치는 클라이언트 연결을 거부합니다.

포털 로깅과 외부 로그 내보내기는 구매 조건도 다릅니다. Cloudflare의 Logpush 연동은 Enterprise 전용입니다. 감사 담당자에게 외부 보관소 제공을 약속하기 전에 이용 자격을 확인하십시오.

호환되는 원격 툴에 공통 접근 정책을 적용하면서 게이트웨이 컴퓨팅 자원은 직접 운영하고 싶지 않을 때 선택하십시오. 사용자 수, 호스팅, 감사에 따른 비용은 Cloudflare MCP Portals는 무료인가요?에서 따로 다룹니다.

Docker MCP Gateway

Docker MCP Gateway는 MCP 서버 운영 자체가 해결해야 할 문제에 포함될 때 적합한 오픈소스 선택지입니다. 서버를 격리된 컨테이너에서 실행하고 수명 주기를 관리하며, 자격 증명과 라우팅을 처리하고, 사용 가능한 서버를 프로필로 묶습니다. 프로필은 클라이언트에 제공할 서버 집합을 저장한 것입니다.

독립형 게이트웨이 코드에는 MIT 라이선스가 적용됩니다. Docker 문서는 Docker Engine을 사용하는 수동 설치와 Docker Desktop을 통한 설치를 모두 안내합니다. 호스트, 업데이트, 자격 증명, 배포 설계는 여전히 직접 책임져야 합니다.

Docker Desktop의 상업적 이용에는 별도 조건이 있습니다. Docker의 라이선스 안내에 따르면 상업적 용도로 Desktop을 무료 사용하려는 소규모 기업은 직원 수 250명 미만이면서 연 매출 $10 million 미만이어야 합니다. 더 큰 조직과 정부 기관은 유료 구독이 필요합니다. Docker Pro는 월간 결제 시 사용자당 월 $11, 연간 플랜에서는 사용자당 월 $9입니다. 이는 Desktop 구독 비용이며 게이트웨이 코드 이용료가 아닙니다.

제품 제공 방식에서도 구분할 부분이 있습니다. Docker의 현재 게이트웨이 문서는 Docker AI Governance에 포함된 MCP Gateway를 영업팀을 통한 초대 방식으로만 제공한다고 별도로 명시합니다. 공개 MIT 저장소는 여전히 독립형 코드 선택지입니다. 상용 거버넌스 제품의 예산을 잡을 때 공개 저장소의 라이선스 비용을 그대로 적용해서는 안 됩니다.

컨테이너 격리와 서버 운영이 중요하고 런타임을 책임질 담당자가 있다면 Docker를 선택하십시오. 노트북마다 실행하는 게이트웨이로 로컬 툴을 통합할 수는 있습니다. 다만 조직 공통 정책과 원격 클라이언트 접근을 구현하려면 배포 구조를 별도로 설계해야 합니다.

Lasso MCP Gateway

Lasso MCP Gateway는 MCP 요청과 응답 사이에서 동작하는 플러그인 기반 중계 계층입니다. 서버 설정을 읽고 설정된 서버를 관리하며, 통합 인터페이스로 서버의 기능을 제공합니다. 저장소에는 Cursor와 Claude Desktop용 예시가 있습니다.

게이트웨이 코드에는 MIT 라이선스가 적용됩니다. basic 플러그인은 토큰과 비밀 정보를 마스킹합니다. 선택 기능인 presidio 플러그인은 개인정보 마스킹을 담당합니다. xetrack은 SQLite에 저장하는 이벤트 기반 트레이싱을 추가하며, 별도 설치 요구사항이 있습니다.

확인해야 할 핵심 제약은 플러그인이 어디서 어떻게 처리하는지입니다. lasso 플러그인은 Lasso API 키가 필요하며, 검사를 위해 콘텐츠를 Lasso의 API로 보냅니다. 게이트웨이의 MIT 라이선스로는 이 호스팅 API의 가격이나 이용 조건을 알 수 없으며, README에도 가격이 제시되어 있지 않습니다. 예산을 잡거나 콘텐츠 전송 범위를 결정할 때 별도 서비스 의존성으로 다뤄야 합니다.

요청·응답 처리를 확장해야 하고 주변 운영 환경을 책임질 수 있다면 Lasso를 선택하십시오. README만으로는 공통 신원 관리, 사용자별 툴 권한, 호출 횟수 제한을 바로 사용할 수 있는 서비스라고 볼 수 없습니다. 그런 제어가 게이트웨이 도입의 목적이라면 요구사항으로 분명히 명시하십시오.

MCP 게이트웨이 운영 비용은 얼마나 드나요?

소프트웨어 라이선스는 예산의 한 항목일 뿐입니다. 게이트웨이 소프트웨어나 구독료, 컴퓨팅 자원과 로그, 운영 담당자의 시간, 워크플로에서 사용하는 모델과 업스트림 애플리케이션을 나눠 계산하십시오.

관리형 서비스는 신원 관리 좌석이나 사용량 기준 요금에 더해 필요한 로그 내보내기와 보안 부가 기능을 포함해야 합니다. 직접 호스팅할 때는 게이트웨이와 서버의 컴퓨팅 자원, 로그 보존, 업데이트, 자격 증명 관리, 복구 작업까지 계산해야 합니다. 게이트웨이가 무료여도 그 뒤에서 유료 SaaS 계정과 유료 모델을 사용할 수 있습니다.

소규모 팀의 예산 계획을 예로 들겠습니다. 간접비를 포함한 내부 인건비를 시간당 $100으로 가정합니다. 자체 호스팅으로 추가되는 컴퓨팅 자원과 로그 비용은 월 $20으로 잡습니다. 이는 예산 계산을 위해 정한 입력값이며, 업체 견적이나 측정된 호스팅 요구사항이 아닙니다.

이 가정에서 자체 호스팅은 직접 연결 설정을 지원하는 기준 비용보다 월 $180을 절약합니다. 게이트웨이 코드의 라이선스 비용이 $0이어도 운영 비용은 월 $220입니다. 도입에 직원 작업 시간 8시간이 필요하다면 $800을 더해야 합니다. 첫해 예상 비용은 12 × $220 + $800 = $3,440이며, 같은 가정에서 직접 연결을 지원하는 기준 비용은 $4,800입니다.

절감액은 게이트웨이가 가정한 만큼 지원 업무를 줄여주는지에 전적으로 달려 있습니다. 현재 투입하는 시간을 측정해 입력값을 바꾸십시오. 간단한 공용 설정 하나로 유지되는 직접 연결 환경이라면 비용이 훨씬 적을 수 있습니다.

제공업체 가격을 실제 사용 환경에 적용합니다

활성 Cloudflare 사용자 6명이라면 Free의 50명 한도 안에서 Cloudflare 요금제 비용 $0으로 이용할 수 있습니다. 표의 호환되는 관리형 시나리오에서는 가정한 내부 정책 관리 인건비가 여전히 월 $50입니다. 호스팅되는 업스트림 서버, 모델 사용량, 구독, 부가 기능 비용은 이 금액에 포함되지 않습니다.

Pay-as-you-go 유료 좌석 60개를 구매한다면 공개된 $7 요금 기준으로 60 × $7 = 월 $420, 또는 연 $5,040입니다. 이 계산은 유료 좌석 60개 전체에 비용을 적용합니다. Free의 50명 한도는 별도 요금제의 조건이며, 이 계산에서 좌석 50개를 빼주는 공제가 아닙니다. Cloudflare의 좌석 관리 문서에 따르면 사용 가능한 좌석 수는 구매한 사용자 수를 따르며, 한 사용자 신원은 접근하는 애플리케이션 수와 관계없이 좌석 하나를 차지합니다.

선택한 Desktop 설치 방식에 Docker Pro 월간 구독 6개를 새로 추가해야 한다면, Docker 공식 가격 기준으로 6 × $11 = 월 $66입니다. 필요한 구독을 이미 보유하고 있다면 추가 구독 비용은 $0일 수 있습니다. Engine 기반 배포에는 별도 인프라 예산이 필요합니다.

Lasso는 MIT 게이트웨이 코드에서 시작해 호스트와 로깅 예산을 더하십시오. API에 의존하는 플러그인을 활성화한다면 호스팅 서비스의 이용 조건을 따로 확인해야 합니다. 가격을 확인하지 않은 의존 서비스를 예산에 $0으로 넣어서는 안 됩니다.

직접 연결·자체 호스팅·관리형 서비스 중 무엇을 선택할까요?

기존 제어 체계가 워크플로 요구사항을 충족하는 동안은 직접 연결을 유지하십시오. 책임질 담당자가 있고 접근 철회와 감사 절차가 작동하는, 작고 통제된 툴 집합에 적합합니다. 클라이언트나 역할이 추가되거나 민감한 작업이 늘면서 정책이 달라지기 시작하면 결정을 다시 검토하십시오.

런타임 담당자를 명확히 정할 수 있다면 자체 호스팅 오픈소스를 선택하십시오. MCP 서버를 컨테이너로 운영하려면 Docker가 더 분명한 출발점입니다. 플러그인으로 요청·응답을 가로채 처리해야 한다면 Lasso가 더 관련 있는 예시입니다. 신원 관리 연동, 호스팅, 로그 예산을 별도로 잡고 필요한 제어 기능이 작동하는지 검증하십시오.

호환되는 원격 툴에 공통 정책이 필요하고 게이트웨이를 직접 운영하고 싶지 않다면 관리형 서비스를 선택하십시오. 소규모 Cloudflare One 환경에서는 Cloudflare부터 평가해볼 수 있습니다. 넓게 도입하기 전에 전송 방식, 업스트림 인가, 툴 정책, 필요한 감사 요금제를 확인하십시오.

요구사항 하나만 달라도 선택은 바뀔 수 있습니다. 관리형 서비스가 서버에 연결하지 못하거나 필요한 제어 기능을 제공하지 못한다면 자체 호스팅 담당자를 정하거나, 통제된 직접 연결 방식을 유지하십시오. 제공업체의 기능 수가 많아도 운영 요구사항과 관리 범위가 맞지 않는 문제는 해결되지 않습니다.

MCP 게이트웨이에 대한 과도한 기대

URL 하나로 연결한다고 신뢰할 수 있는 권한 체계가 자동으로 완성되지는 않습니다. 게이트웨이에 연결하는 것만으로 인가, 감사, 보안이 한 번에 해결된다는 생각이 가장 큰 오해입니다.

포털에 로그인한 뒤에도 업스트림 OAuth 권한 승인이 필요할 수 있습니다. 게이트웨이 정책과 업스트림 애플리케이션의 레코드 권한이 모두 중요합니다. MCP의 보안 지침은 다른 리소스용으로 발급된 토큰을 받아 그대로 전달하는 행위를 명시적으로 경고합니다.

툴을 허용하는 것도 사용을 통제하는 일의 일부일 뿐입니다. 허용된 작업이라도 서버 연동 계층이 막지 않으면 안전하지 않은 인수를 받거나 잘못된 테넌트에 영향을 줄 수 있습니다. 응답 마스킹은 애플리케이션 권한이나 영향이 큰 작업에 대한 사람의 승인을 대체하지 않습니다.

Cloudflare 문서에는 구체적인 정책 사례가 있습니다. 포털을 통해 서버 사용을 승인할 때 별도의 MFA, 사용 목적 설명, 임시 인증은 적용되지 않지만, 그룹이나 기기 보안 상태 같은 선택 조건은 계속 적용된다고 설명합니다. MFA는 추가 인증 요소를 사용하는 방식입니다. 포털을 승인 워크플로로 간주하기 전에 이 정책 제약을 확인하십시오.

또한 게이트웨이를 우회하는 툴 트래픽은 게이트웨이가 기록할 수 없습니다. 승인된 경로를 정하고 업스트림 권한을 유지하며, 서버 유지보수도 관리 범위에 포함하십시오. 제품은 유용한 제어 지점을 제공하지만, 그 관리 범위가 얼마나 완전한지는 운영 책임자에게 달려 있습니다.

월요일에 시작할 도입 검증

워크플로 하나로 시범 운영하며 도입하려는 제어 기능을 검증하십시오. 해당 워크플로에서 위험도가 낮은 툴과 영향이 큰 툴을 고른 뒤, 운영 담당자들이 이미 사용하는 에이전트 클라이언트로 시험합니다.

1. 1

   현재 연결 구조를 정리합니다

   각 클라이언트, 서버 엔드포인트, 전송 방식, 자격 증명 담당자, 노출된 툴, 로그 저장 위치를 기록하십시오. 반복되는 정책 변경 중 무엇을 중앙에서 처리할지 정합니다. 되돌릴 수 있도록 기존 클라이언트 설정을 보관하십시오.

2. 2

   운영 방식을 선택합니다

   기존 제어 체계로 충분하다면 직접 연결을 사용하십시오. 자체 호스팅 시범 운영은 런타임 담당자가 있을 때만 선택합니다. Cloudflare로 시범 운영한다면 Zero Trust > Access controls > MCP Portals로 이동해 호환되는 HTTP 서버를 추가하고, 서버와 포털의 Access 정책을 지정한 뒤 허용할 툴과 프롬프트를 선택하십시오.

3. 3

   툴 탐색과 호출을 검증합니다

   선택한 클라이언트를 각각 지원되는 방식으로 연결하십시오. 위험도가 낮은 작업을 찾고 호출할 수 있는지 확인하고, 금지된 작업은 명시적으로 요청해도 거부되는지 검증합니다. 게이트웨이의 툴 목록뿐 아니라 업스트림 데이터 접근 권한도 확인하십시오.

4. 4

   접근을 철회하고 기록을 확인합니다

   시범 운영에 쓰는 주체의 권한을 제거한 뒤 다음 작업 시도가 실패하는지 확인하십시오. 제품이 제공하는 기록에서 허용된 요청과 거부된 요청을 찾습니다. 로그 저장 위치와 보존 기간이 요구사항에 맞는지도 확인하십시오.

5. 5

   비용을 계산하고 담당자를 유지합니다

   구독료, 업스트림 호스팅, 로깅, 직원 작업 시간을 기록하십시오. 정책과 복구 경로가 작동하는 것을 확인한 뒤에만 확대합니다. 통제되지 않는 우회 경로를 만들지 않고 이전의 통제된 설정으로 돌아가는 방법을 문서화하십시오.

자주 묻는 질문

MCP 게이트웨이란 무엇인가요?

MCP 게이트웨이는 AI 클라이언트와 MCP 서버 사이의 제어 지점입니다. 인증, 툴 허용 목록, 로깅, 호출 횟수 제한, 라우팅을 중앙에서 관리할 수 있습니다. 모든 툴 통합 도구가 이런 기능을 제공한다고 가정하지 말고, 선택한 구현에서 각각 확인하십시오.

MCP 게이트웨이와 MCP 서버는 어떻게 다른가요?

MCP 서버는 툴, 리소스, 프롬프트를 제공합니다. 게이트웨이는 하나 이상의 서버에 대한 접근을 관리하고 승인된 기능을 공통 인터페이스로 제공할 수 있습니다. 실제 작업의 수행과 권한 검증은 여전히 업스트림 서버와 애플리케이션이 담당합니다.

우리 팀에도 MCP 게이트웨이가 필요한가요?

여러 클라이언트나 역할에 공통 툴 정책, 접근 철회 절차, 감사 경로가 필요할 때 사용하십시오. 담당자가 이미 이런 요구사항을 충족하고 있다면 직접 연결도 적절한 선택입니다. 서버가 특정 개수에 이르면 게이트웨이를 반드시 써야 한다는 프로토콜 규칙은 없습니다.

프록시와 MCP 게이트웨이는 무엇이 다른가요?

기본 프록시는 트래픽을 전달합니다. MCP를 이해하는 게이트웨이는 툴 탐색과 호출을 해석하고, 기능을 통합하며, 툴별 정책을 적용할 수 있습니다. 여러 MCP 작업이 하나의 HTTP 엔드포인트를 사용할 수 있으므로 URL 단위 권한만으로는 필요한 작업 제한을 표현하지 못할 수 있습니다.

MCP도 API 게이트웨이와 같은 것인가요?

MCP 자체는 프로토콜입니다. MCP 게이트웨이는 API 게이트웨이와 비슷한 역할을 하지만, MCP 기능과 호출을 관리합니다. 같은 아키텍처 안에서 API 게이트웨이를 함께 사용해 HTTP 인증, 네트워크 제어, 호출량 제한을 처리할 수도 있습니다.

MCP와 HTTP는 같은 것인가요?

아닙니다. MCP는 메시지와 기능을 정의하고, HTTP는 그 메시지를 원격 서버로 전송하는 한 가지 방식입니다. MCP는 로컬 프로세스용 stdio도 지원합니다. 이 전송 방식의 차이 때문에 관리형 HTTP 게이트웨이가 모든 로컬 전용 서버를 직접 사용할 수는 없습니다.

REST 대신 MCP를 사용하는 이유는 무엇인가요?

MCP는 호환되는 AI 클라이언트가 툴을 찾고 호출할 수 있는 공통 방식을 제공합니다. 서버가 기존 REST API를 감싸서 제공할 수 있으므로 내부적으로 REST를 유지해도 됩니다. 실제 클라이언트가 필요로 하는 인터페이스를 선택하십시오. MCP를 추가한다고 모든 애플리케이션 API를 다시 작성할 필요는 없습니다.

MCP는 JSON 기반인가요?

네. MCP는 요청, 응답, 알림에 JSON-RPC 2.0 메시지를 사용합니다. 프로토콜은 툴 탐색과 호출을 포함해 각 메시지의 의미를 정의하므로, 일반적인 JSON 엔드포인트 이상의 역할을 합니다.

MCP와 RAG는 어떻게 다른가요?

MCP는 툴과 데이터를 연결하는 통합 프로토콜입니다. RAG(검색 증강 생성)는 모델의 답변에 활용할 정보를 검색합니다. 검색 툴을 MCP로 제공할 수 있으므로 둘은 함께 사용할 수 있습니다. 게이트웨이를 추가하는 것만으로 검색 품질이 좋아지지는 않습니다.

실무에 필요한 인프라 선택 기준과 확인 시점을 명시한 가격 정보를 더 받아보려면 뉴스레터를 구독하십시오.