AI 게이트웨이란? API 게이트웨이, MCP 게이트웨이와 무엇이 다를까

사용자가 AI 에이전트에게 "이번 달 매출을 조회해서 보고서로 만들어줘"라고 요청했다고 가정해 보겠습니다. 여기서 에이전트는 사용자의 요청을 받아 스스로 여러 단계를 실행하는 AI 프로그램입니다.

에이전트는 먼저 모델을 호출해 어떤 작업을 해야 할지 판단합니다. 이후 사내 매출 데이터를 조회하는 도구를 실행하고, 조회 결과를 다시 모델에 전달해 보고서를 작성합니다. 사용자가 요청한 작업은 하나지만, 내부에서는 서로 다른 두 종류의 호출이 발생합니다.

• 모델 호출 모델에 판단과 답변을 요청합니다.
• 도구 호출 데이터베이스나 사내 시스템을 사용합니다.

두 호출은 관리해야 할 대상도 다릅니다. 모델 호출에서 어떤 모델을 사용할지, 토큰과 비용이 얼마나 발생했는지, 프롬프트에 민감한 정보가 포함됐는지를 확인해야 합니다. 도구 호출에서 이 에이전트가 해당 데이터에 접근해도 되는지, 조회뿐 아니라 수정이나 삭제까지 허용할지를 확인해야 합니다.

API 게이트웨이는 일반 API 요청을, AI 게이트웨이는 모델 호출을, MCP 게이트웨이는 에이전트의 도구와 데이터 접근을 관리합니다. 세 계층 모두 흩어진 호출을 하나의 통로로 모은다는 점에서는 같습니다. 하지만 통제하는 대상과 정책을 판단하는 기준은 다릅니다.

‍

API 게이트웨이, AI 게이트웨이, MCP 게이트웨이 비교

한 가지 미리 짚어두면, 이 경계가 제품 단위로 딱 나뉘지는 않습니다. 기존 API 게이트웨이에 AI 관련 기능을 더하는 경우도 있고, 한 제품이 AI 게이트웨이와 MCP 게이트웨이 기능을 함께 제공하기도 합니다. 셋을 나눠 설명하는 것은 제품을 세 개 두라는 뜻이 아니라, 통제할 대상이 세 종류라는 뜻입니다.

‍

API 게이트웨이란

API 게이트웨이는 클라이언트와 백엔드 서비스 사이에 두는 계층입니다. 로그인 여부를 확인하는 코드를 서비스 열 곳에 각각 넣는 대신, 게이트웨이 한곳에서 확인한 뒤 통과시킵니다. 인증과 요청 제한, 라우팅 같은 공통 정책도 같은 방식으로 적용합니다.

‍

AI 게이트웨이란

AI 게이트웨이는 애플리케이션과 모델 사이에 두는 계층입니다. 각 서비스가 모델 제공사나 자체 호스팅 모델에 직접 요청하는 대신 게이트웨이를 거치게 하면, 모델 호출과 관련된 정책을 한곳에서 적용할 수 있습니다. AI 게이트웨이(AI Gateway)는 LLM 게이트웨이라고 부르기도 합니다.

제품에 따라 차이가 있지만 일반적으로 다음 세 가지를 담당합니다.

• 모델 선택 요청의 성격에 따라 어느 모델로 보낼지 정합니다. 이렇게 요청을 모델별로 나눠 보내는 것을 모델 라우팅이라고 합니다. 간단한 요약은 저렴한 모델로, 복잡한 추론은 성능이 좋은 모델로 나누는 식입니다. 특정 모델이나 제공사가 응답하지 않을 때 다른 모델로 넘기는 우회 경로도 여기서 관리합니다. 이런 경로를 대체 경로라고 하는데, 서비스마다 각자 구현하면 장애가 났을 때 서비스별로 다르게 동작합니다.
• 비용 관리 토큰은 모델이 글의 양을 세는 단위입니다. 대부분의 텍스트 모델은 입력과 출력에 사용한 토큰을 기준으로 요금이 매겨집니다. 게이트웨이는 각 호출의 토큰 사용량을 팀·프로젝트별로 나눠 기록하는데, 이렇게 사용량의 주인을 밝히는 것을 비용 귀속이라고 합니다. 여기에 한도를 정해 두고 일정 수준을 넘으면 알림을 보내거나 호출을 제한할 수 있습니다. 제공사 콘솔에서도 키나 프로젝트 단위 사용량은 볼 수 있습니다. 다만 여러 팀이 하나의 키를 공유하면 LLM 비용이 어느 팀에서 나왔는지 확인하기 어렵습니다.
• 프롬프트 정책과 감사 기록 프롬프트는 모델에 보내는 질문과 지시문입니다. 게이트웨이가 이 내용을 확인해 허용되지 않은 요청을 막습니다. 예를 들어 고객 이름이나 연락처가 들어간 프롬프트를 외부 모델로 보내지 못하게 할 수 있습니다. 이 과정에서 누가 언제 어떤 모델에 무엇을 물었는지 기록이 남고, 규제 산업에서는 이 기록을 감사에 대응할 근거로 쓰기도 합니다.

‍

MCP 게이트웨이란

MCP는 Model Context Protocol의 줄임말로, 에이전트가 외부 도구나 데이터에 연결되는 방식을 정한 규격입니다. 도구를 제공하는 쪽을 MCP 서버라고 합니다. 앞의 예에서 매출 데이터를 조회하는 도구가 바로 MCP 서버가 제공하는 도구입니다.

이 글에서 MCP 게이트웨이는 에이전트가 MCP를 통해 도구나 데이터에 접근하는 지점을 통제하는 계층이라는 뜻으로 사용합니다. 제품에 따라 이 범위를 조금 다르게 정의하기도 합니다. MCP 게이트웨이가 맡는 일도 구현과 제품마다 다르지만, 대체로 다음 세 가지로 모입니다.

• 도구 접근 에이전트가 연결할 수 있는 MCP 서버와 도구 목록을 게이트웨이에서 정합니다. 에이전트 쪽 설정을 하나씩 확인하지 않아도 어디까지 붙을 수 있는지 한곳에서 파악할 수 있습니다.
• 권한 관리 같은 도구라도 누가 호출했는지에 따라 허용 여부를 달리 정합니다. 매출 조회 도구는 전사에 열어두고, 인사 조회 도구는 특정 팀의 에이전트만 쓰게 하는 식입니다. 한 서버가 여러 도구를 제공할 때 그중 일부만 노출하거나, 조회는 허용하고 수정과 삭제는 막는 것처럼 범위를 좁히는 일도 여기에 들어갑니다.
• 호출 기록 어떤 에이전트가 어떤 도구를 어떤 인자로 호출했는지 기록합니다. 사내 시스템에 연결된 도구는 민감한 데이터를 다루는 경우가 많아, 나중에 문제가 생겼을 때 되짚을 기록이 특히 중요합니다.

‍

기존 API 게이트웨이만으로는 왜 부족할까

AI 게이트웨이와 MCP 게이트웨이도 요청을 공통 통로로 모아 정책을 적용한다는 발상은 API 게이트웨이와 같습니다. 다만 모델 호출에서는 모델·토큰·프롬프트를, 도구 호출에서는 도구·인자·호출 주체를 함께 살펴야 한다는 점이 다릅니다.

차이는 정책을 적용할 때 어떤 정보를 함께 보는지에서 드러납니다. 짧은 질문 하나와 문서 수십 장을 붙인 질문 하나는 모두 API 요청 한 건이지만, 사용하는 토큰과 비용은 크게 달라질 수 있습니다. AI 게이트웨이는 요청 건수뿐 아니라 모델과 토큰 사용량, 예상 비용 같은 모델 호출 정보를 함께 관리합니다.

정책을 판단하는 기준도 다릅니다. 일반적인 API 정책은 경로·인증 정보·요청 빈도만으로 상당 부분 결정할 수 있습니다. 반면 모델 호출에서는 프롬프트 내용 자체가 판단 대상이 되는 경우가 많습니다. 프롬프트 안에 무엇이 들어 있는지까지 확인해야 정책을 판단할 수 있습니다.

MCP 게이트웨이는 또 다른 기준을 봅니다. 요청 경로나 토큰이 아니라 "이 에이전트가 이 도구를 호출해도 되는가"를 판단해야 하므로, 도구 이름과 인자, 호출 주체가 기준이 됩니다.

‍

AI · MCP 게이트웨이가 각각 필요한 상황

두 게이트웨이가 항상 함께 필요한 것은 아닙니다. 어느 쪽이 먼저 필요한지는 지금 흩어지고 있는 대상이 모델 호출인지 도구 호출인지에 따라 달라집니다.

AI 게이트웨이는 모델 호출이 여러 곳으로 퍼졌을 때 먼저 필요합니다. 다음 중 해당하는 항목이 있는지 보면 됩니다.

• 여러 팀이 각자 모델 제공사에 직접 연결해 두어 비용을 팀별로 나눠 보기 어렵습니다
• 모델 교체와 대체 경로 로직을 서비스마다 따로 구현하고 있습니다
• 프롬프트에 민감한 데이터가 섞여 나가는지 확인할 지점이 없습니다

MCP 게이트웨이는 에이전트가 붙는 도구가 늘어났을 때 먼저 필요합니다.

• 사내 시스템이나 데이터베이스에 연결된 MCP 서버가 여러 개 생겼습니다
• 어떤 에이전트가 어떤 도구까지 쓸 수 있는지를 서버마다 다르게 관리하고 있습니다
• 외부에서 제공하는 MCP 서버를 검토 없이 그대로 연결하고 있습니다

한 팀이 한 모델만 사용하고 도구도 몇 개뿐이라면 두 계층 모두 과할 수 있습니다. 이때는 애플리케이션이나 공통 라이브러리에서 팀·프로젝트 정보와 도구 호출 기록을 함께 남기는 정도로도 충분할 수 있습니다.

‍

함께 사용할 때의 구조

두 게이트웨이를 함께 쓸 때 에이전트는 두 개의 경로를 지납니다. 모델 호출은 AI 게이트웨이를 거쳐 모델로, 도구 호출은 MCP 게이트웨이를 거쳐 사내 시스템이나 외부 서비스의 도구로 나갑니다.

하나의 사용자 요청을 처리하는 동안 에이전트는 이 두 경로를 번갈아 지납니다. 앞의 매출 보고서 예에서 모델의 판단과 보고서 작성은 AI 게이트웨이 경로를, 매출 조회는 MCP 게이트웨이 경로를 거칩니다. 두 게이트웨이를 하나의 제품으로 운영하더라도 무엇을 통제하는지는 구분해서 보는 것이 좋습니다. 특히 MCP 게이트웨이는 사내 시스템이나 데이터에 직접 연결될 수 있기 때문에 권한 설계를 더 세심하게 다뤄야 합니다.

기록이 두 지점으로 나뉜다는 점도 미리 고려할 부분입니다. 같은 작업에서 발생한 모델 호출과 도구 호출을 나중에 연결해서 보려면, 두 경로에 공통된 추적 문맥(trace context)이나 상관관계 식별자(correlation ID)가 이어지도록 설계하는 것이 좋습니다.

‍

게이트웨이와 옵저버빌리티의 차이

게이트웨이가 호출 기록을 남기기 때문에 옵저버빌리티 역할까지 대신할 수 있다고 생각하기 쉽습니다. 앞의 매출 보고서 요청을 다시 보겠습니다. MCP 게이트웨이는 이 에이전트가 인사 데이터를 조회하지 못하도록 막을 수 있고, AI 게이트웨이에는 모델 호출과 토큰 사용량이 남습니다. 그런데 완성된 보고서의 숫자가 엉뚱하다면, 이 기록만으로는 원인을 찾기 어렵습니다.

게이트웨이는 요청이 모델이나 도구로 전달되는 경로에서 정책을 적용하는 통제 지점입니다. 옵저버빌리티는 모델 호출과 도구 호출에서 발생한 데이터를 연결해 전체 실행 과정과 결과를 관찰하고 분석하는 계층입니다. 여러 호출이 어떤 순서로 이어졌는지, 어느 단계에서 판단이 틀어졌는지, 최종 응답이 적절했는지는 실행 흐름을 하나로 이어 봐야 알 수 있습니다. 둘은 대체 관계가 아니라 서로 다른 역할을 맡는 계층입니다.

‍

마치며

AI 게이트웨이와 MCP 게이트웨이는 이름이 비슷해 하나로 묶어 생각하기 쉽지만, 지키는 자리가 다릅니다. 하나는 모델로 나가는 호출을 맡고, 다른 하나는 에이전트가 닿는 도구와 데이터를 맡습니다. 여기에 그 호출들이 실제로 어떻게 실행됐는지 보는 옵저버빌리티까지 더하면, 세 계층이 각각 다른 문제를 나눠 맡는 구도가 됩니다.

• 모델 호출이 여러 팀과 서비스로 흩어지기 시작하면 AI 게이트웨이를 검토할 시점입니다.
• 에이전트가 접근하는 도구와 데이터가 늘어나면 MCP 게이트웨이를 검토할 시점입니다.
• 전체 실행 과정과 실패 원인을 파악하려면 옵저버빌리티가 필요합니다.

게이트웨이가 남기는 기록은 호출 단위입니다. 프롬프트와 응답, 도구 호출 기록을 하나의 트랜잭션으로 이어서 봐야 한다면 와탭 LLM Observability 공식 문서에서 관련 기능을 살펴보세요.

‍

자주 묻는 질문

AI 게이트웨이와 LLM 게이트웨이는 다른가요

같은 계층을 가리키는 경우가 대부분입니다. LLM 게이트웨이는 이름 그대로 언어 모델 호출을 관리하는 계층을 뜻하고, AI 게이트웨이는 여기에 이미지나 음성 같은 다른 모델까지 포함해 조금 더 넓게 쓰이는 편입니다. 제품 소개에서는 두 이름이 섞여 쓰이므로, 이름보다 무엇을 통제하는지를 보고 판단하는 편이 정확합니다. 모델 라우팅과 토큰·비용 관리, 프롬프트 정책을 다룬다면 이 글에서 말하는 AI 게이트웨이와 같은 역할입니다.

‍

AI 게이트웨이를 거치면 응답 지연이 늘지 않나요

늘어날 수 있습니다. 다만 모델 추론 자체에 시간이 걸리는 경우가 많아, 게이트웨이를 거치면서 추가되는 지연은 전체 응답 시간에서 작은 비중을 차지할 수 있습니다. 더 주의해서 볼 부분은 스트리밍 응답입니다. 게이트웨이가 모델의 응답을 전부 받은 뒤 사용자에게 전달하면 첫 응답이 보이기까지의 시간이 길어질 수 있습니다. 도입할 때는 모델의 스트리밍 응답을 게이트웨이가 그대로 전달하는지 확인하는 것이 좋습니다.

‍

AI 게이트웨이를 직접 구축하는 것과 제품을 도입하는 것 중 무엇이 나은가요

모델을 사용하는 팀과 제공사, 그리고 에이전트가 붙는 도구가 얼마나 많은지부터 보는 것이 현실적입니다. 범위가 작은 초기 단계라면 별도의 게이트웨이를 두는 것이 과할 수 있습니다. 반대로 여러 팀이 여러 모델 제공사를 사용하거나 MCP 서버가 늘어나기 시작하면, 라우팅·비용 관리·접근 정책을 서비스마다 따로 구현하게 됩니다. 이런 공통 기능이 반복되기 시작하는 시점이 별도의 게이트웨이 계층을 검토할 만한 지점입니다.

‍

AI 게이트웨이와 MCP 게이트웨이가 단일 장애점이 되지 않나요

될 수 있습니다. 모델 호출이나 도구 호출을 한곳에 모으면 그 게이트웨이가 멈췄을 때 전체가 멈추는 단일 장애점이 됩니다. 특히 두 기능을 하나의 제품이나 배포 단위에서 함께 운영하는 경우, 장애가 AI 기능 전반에 영향을 줍니다. 따라서 운영 환경에서는 게이트웨이를 여러 인스턴스로 나눠 한쪽이 멈춰도 나머지가 요청을 받도록 구성하는 편이 안전합니다.

장애가 났을 때의 정책도 미리 정해 두는 편이 좋습니다. 게이트웨이를 우회하지 않고 요청을 차단하는 방식(fail-closed)과, 모델 제공사나 MCP 서버에 직접 연결하도록 허용하는 방식(fail-open)이 있습니다. 우회를 허용하면 가용성은 높일 수 있지만 접근 통제나 감사 기록에 빈틈이 생길 수 있습니다.

‍

더 읽을거리

• ‍LLM Observability 소개 (와탭 공식 문서)‍
• MCP(Model Context Protocol) (와탭 공식 문서)‍
• AI 에이전트 옵저버빌리티(Observability) 개념과 도입 이유 (와탭 블로그)‍
• OpenTelemetry GenAI 시맨틱 컨벤션과 LLM 옵저버빌리티 표준 (와탭 블로그)

‍

참고 자료

• ‍Model Context Protocol 공식 문서 (modelcontextprotocol.io)‍
• Trace Context (W3C Recommendation)