Kong 게이트웨이로 REST API를 MCP로 변환하기: 엔터프라이즈 MCP 전략

핵심 메시지

• LLM이 에이전트의 '뇌'라면 MCP는 '손발', API는 이를 잇는 '신경계'로, MCP는 브레인과 실행을 잇는 표준 인터페이스다.
• MCP는 2024년 11월 앤트로픽이 공개한 뒤 OpenAI·구글 등 주요 진영이 빠르게 채택하며 사실상의 표준으로 자리 잡았다.
• 기업엔 수만 개의 기존 REST API가 있고, Kong 게이트웨이 3.12의 MCP 프록시 플러그인은 이를 즉석에서 MCP로 동적 변환한다.
• MCP의 진짜 난제는 도입이 아니라 안정성으로, 명세가 약 3개월마다 바뀌고 클라이언트·서버마다 지원 범위가 제각각이다.
• 게이트웨이에 위임하면 인증(API 키·OAuth 2.1)과 관측성(Prometheus·Grafana)을 기존 플러그인으로 몇 번의 설정만에 붙일 수 있다.

쉽게 이해하기

발표자는 LLM을 에이전트의 '뇌'에 비유한다. LLM은 사고는 잘하지만 실제로 무언가를 하려면 '손발'이 필요하고, 그 역할을 MCP(Model Context Protocol)가 맡는다. API는 이 둘을 잇는 신경계에 해당한다. REST는 예측 가능한 정해진 단계에 맞춰 설계돼 있어, 상황에 따라 적응하는 에이전트에는 잘 맞지 않는다는 것이 MCP가 필요한 이유로 제시된다.

MCP는 2024년 11월 앤트로픽이 공개한 비교적 새로운 표준이지만, 두 달 만에 OpenAI가 동참하고 구글도 합류하는 등 주요 벤더가 이례적으로 빠르게 하나의 표준으로 결집했다. 구조적으로는 호스트(예: 클로드 데스크톱·클로드 코드), 그 안의 MCP 클라이언트, 그리고 대부분 원격으로 동작하는 MCP 서버로 구성되며, 요청-응답 방식이던 REST와 달리 세션 상태와 컨텍스트를 관리하는 대화형 방식이라는 점이 강조된다.

핵심 과제는 '이미 20년간 쌓아온 수만 개의 REST API를 어떻게 활용하느냐'다. 초기에는 각 엔드포인트를 하나의 MCP 도구로 1:1 변환하는 방식이 유행했다. 시연에서는 Kong 게이트웨이 3.12의 MCP 프록시 플러그인을 변환 리스너 모드로 두고, 항공 마일리지 회원 조회용 REST API를 코드 작성 없이 Insomnia에서 MCP 도구로 즉시 소비하는 모습을 보여준다.

발표자는 MCP의 가장 큰 어려움으로 '안정성'을 꼽는다. 명세에는 should·must·must not이 많지만 클라이언트와 서버마다 지원하는 부분집합이 달라, 어떤 조합에서는 되고 다른 조합에서는 안 되는 상황이 흔하다. 명세 자체도 약 3개월마다 바뀐다. 그래서 이 복잡성을 게이트웨이와 Insomnia에 위임하라는 것이 핵심 제안이다. 보안 측면에서도 로컬 중심이던 초기의 API 키 방식에서 원격·스트리밍으로 넘어오며 OAuth 2.1이 도입됐고, 동적 클라이언트 등록처럼 기업이 꺼리는 기능은 프록시로 차단하거나 대체할 수 있다.

단순 1:1 변환의 한계도 지적된다. API마다 도구를 하나씩 만들면 컨텍스트가 금세 넘치고 에이전트가 혼란스러워진다. 그래서 Kong은 여러 API 호출을 하나의 비즈니스 흐름으로 묶어 단일 도구로 노출하며, 이 흐름을 오픈 API 제작진이 만든 오픈소스 명세 Arazzo로 정의한다. 또한 개별 도구를 잔뜩 주기보다 강력한 검색 도구 하나를 신뢰해 맡기는 접근도 소개한다. 관측성은 Prometheus·Grafana 플러그인을 활성화하고 MCP 통계를 켜는 것만으로 확보된다. 끝으로 A2A·AP2·ACP·UTCP 같은 여러 표준이 경쟁하는 상황에서, 게이트웨이에 위임하면 새 프로토콜 대응 부담을 덜 수 있다고 정리한다.

주요 인사이트

• MCP를 '에이전트의 손발'로 규정하면, 기업 통합 과제의 본질은 새 서버를 만드는 것이 아니라 기존 API 자산을 어떻게 재활용하느냐로 좁혀진다.
• MCP의 최대 리스크는 기능 부족이 아니라 명세 변동성과 구현 편차이며, 게이트웨이 계층이 이 변화를 흡수하는 완충재 역할을 한다.
• REST API용으로 쓰던 인증·레이트리밋·로깅 플러그인을 MCP에도 그대로 적용할 수 있다는 점이 별도 스택 없이 도입 비용을 낮춘다.
• 엔드포인트를 1:1로 도구화하면 컨텍스트가 넘쳐 에이전트 성능이 오히려 떨어지므로, 비즈니스 흐름 단위로 묶는 설계가 중요하다.
• 여러 에이전트 표준이 난립하는 시기에는 특정 프로토콜에 직접 종속되기보다 게이트웨이에 추상화를 위임하는 편이 안전하다.

자주 묻는 질문

관련 AI 소식