LLM 게이트웨이는 어떻게 작동하나요? 엔지니어링 팀을 위한 실용 가이드

LLM 게이트웨이는 애플리케이션과, 게이트웨이를 통해 연결하는 모델 제공업체 사이에 위치하며, 자격 증명을 관리하고 사용량을 추적할 수 있는 단일 지점을 제공합니다.

“지금은 완전히 엉망진창이에요.” 2026년 9월, 한 엔지니어가 Reddit의 r/LLMDevs에 이렇게 썼습니다.

“다들 Claude, OpenAI, AWS Bedrock은 물론이고 우리가 쓰는 다른 모든 추론 제공업체의 키를 각자 따로 갖고 있어요.”

BigGo의 llm-proxy-tk 관련 기사에서는 경량 FastAPI 게이트웨이인 이 도구의 구성을 LLM을 “기업용 수돗물”로 만드는 일에 비유하며, 게이트웨이를 건물의 메인 밸브에 견줍니다.

하지만 이 배관을 그만큼 믿고 맡기기 전에, 무엇을 설치하려는 것인지부터 살펴보겠습니다.

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

LLM 게이트웨이는 모델 호출을 위한 리버스 프록시입니다. 애플리케이션은 OpenAI, Anthropic, Google 등 사용 중인 LLM 제공업체에 직접 요청을 보내는 대신 게이트웨이로 요청을 보냅니다. 게이트웨이는 이 요청을 전달하면서 그 과정에서 사용자가 정한 규칙을 적용합니다.

LLM 제공업체마다 고유한 API가 있습니다. 요청 형식도, 인증 방식도, 오류를 반환하는 방식도 제각각입니다. 속도 제한과 장애 양상도 각기 다릅니다. 그런데 이들 앞에 공유 계층이 없다면, 제공업체를 호출하는 애플리케이션마다 모든 것을 직접 처리해야 하고, 그 방식도 조금씩 달라집니다.

수돗물 비유가 모든 것을 설명해 주지는 않지만, 적어도 여기까지는 들어맞습니다. 제공업체는 게이트웨이에서 한 번만 배관에 연결됩니다. 그 이후로 각 애플리케이션은 계량기가 달린 자체 연결을 갖게 되므로, 누가 무엇을 사용하는지 확인할 수 있고, 다른 연결은 건드리지 않고 특정 라인 하나만 차단할 수 있습니다.

LLM, AI, MCP, API 게이트웨이: 무엇이 다를까요?

LLM 게이트웨이는 어떻게 작동하나요?

애플리케이션에서 모델로 갔다가 다시 돌아오는 요청 하나를 따라가 보겠습니다.

1. 요청이 게이트웨이에 도착합니다: 애플리케이션이 평범해 보이는 채팅 요청을 게이트웨이의 엔드포인트로 보냅니다. 이 요청은 주로 OpenAI 호환 형식입니다. 애플리케이션 입장에서 이 엔드포인트는 모델에 도달하기 위해 호출하는 주소입니다.
2. 게이트웨이가 요청자와 허용된 권한을 확인합니다: 게이트웨이는 요청을 전달하기 전에 자격 증명을 검증합니다. 대개 팀이나 제품에 발급된 가상 키입니다. 입력 가드레일을 연동해 두었다면, 프롬프트에 민감한 데이터가 있는지, 모델의 지시를 무력화하려는 시도가 있는지도 검사할 수 있습니다.
3. 게이트웨이가 이미 답을 가지고 있는지 확인합니다: 캐싱이 활성화되어 있으면, 조건에 맞는 일치 요청은 제공업체를 다시 호출하지 않고 저장된 응답으로 처리할 수 있습니다. 일부 게이트웨이는 시맨틱 캐싱도 제공하는데, 이는 동일한 요청이 아니라 충분히 유사하다고 판단되는 요청을 찾는 방식입니다. FAQ 유형의 트래픽에 적합할 수 있습니다.
4. 게이트웨이가 요청을 보낼 곳을 선택합니다: 요청에는 특정 모델이나 별칭이 지정되어 있을 수 있습니다. 게이트웨이는 구성에서 일치하는 라우트를 찾습니다. 백업 라우트를 구성할 수도 있습니다. 제공업체 A가 시간 초과되면 게이트웨이가 제공업체 B를 시도할 수 있습니다.
5. 게이트웨이가 호출을 준비하고 응답을 반환합니다: 게이트웨이는 요청을 선택된 제공업체의 형식으로 변환하고, 외부로 나가는 호출을 인증합니다. 응답을 받으면 즉시 애플리케이션이 요구하는 형식으로 변환합니다.
6. 게이트웨이가 일어난 일을 기록합니다: 로깅이 활성화되어 있으면 게이트웨이는 호출한 사람, 호출을 처리한 모델, 토큰 수, 지연 시간, 비용 등의 세부 정보를 기록합니다. 서두에 등장한 Reddit 엔지니어에게 없던 바로 그 로그입니다.

게이트웨이를 프로덕션에 도입하기 전에 알아야 할 4가지

앞 섹션에서 설명한 모든 기능은 게이트웨이가 자신을 거치는 모든 요청을 볼 수 있기 때문에 가능합니다. 바로 이것이 게이트웨이의 세일즈 포인트입니다. 하지만 이는 동시에 대비해야 할 공격 표면과 벤더 종속성에 대한 설명이기도 합니다.

게이트웨이는 이제 AI 스택에서 가장 값진 장비입니다

게이트웨이는 액세스를 중앙화합니다. 따라서 수많은 자격 증명이 하나의 서비스가 닿을 수 있는 범위에 모이게 됩니다. Microsoft 보안팀이 정리한 바에 따르면, LiteLLM 배포는 제공업체 API 키, 자체 마스터 키, 가상 키 레코드, 데이터베이스 연결 문자열, 라우팅 설정, 테넌트 정책을 보유하거나 가져올 수 있습니다.

2026년 10월, Check Point Research가 LiteLLM의 고위험 취약점 2건을 공개했습니다:

• CVE-2026-35029는 읽기 전용 사용자를 포함한 인증된 사용자가 관리 기능에 접근해 인스턴스를 장악할 수 있는 취약점이었습니다.
• CVE-2026-59823은 사용자가 요청을 자신이 제어하는 서버로 리디렉션해 제공업체 키를 탈취할 수 있는 취약점이었습니다.

두 취약점 모두 버전 1.83.9에서 수정되었습니다. 게이트웨이를 사용하는 애플리케이션이 게이트웨이 설정을 변경할 수 있어서는 안 됩니다.

가드레일에는 장애 정책이 필요합니다

Pillar Security의 2026년 10월 4일 검토 보고서는 LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management, Apigee 등 주요 게이트웨이의 서드파티 가드레일 통합을 정리하고 있습니다. (Pillar는 가드레일을 판매하는 회사이므로, 권장 사항을 읽을 때 이 점을 염두에 두세요.)

훅(hook)은 요청 경로상의 한 지점으로, 일반적으로 프롬프트가 모델로 전달되기 전이나 응답이 돌아온 후에 위치하며, 게이트웨이는 이 지점에서 콘텐츠를 외부 스캐너에 넘겨 판정을 받을 수 있습니다. 차단형 검사는 판정이 나올 때까지 기다린 뒤에 트래픽을 통과시킵니다. Portkey의 문서에서는 이를 before_request_hooks와 after_request_hooks라고 부르며, TrueFoundry는 네 가지 훅을 실행해 MCP 도구 호출 전후의 검사를 추가합니다.

여기서 확인할 점은 두 가지입니다.

• 스캐너 자체에 장애가 발생하면 어떻게 될까요? 요청을 차단하면 검사되지 않은 트래픽은 막을 수 있지만 애플리케이션이 중단될 수 있습니다. 요청을 통과시키면 애플리케이션은 해당 검사 없이 계속 작동합니다. 장애 로그를 통해 나중에 검사가 누락되었다는 사실을 알 수 있어 유용하긴 하지만, 실제로 검사를 실행한 것과 같지는 않습니다.
• 스캐너를 교체할 수 있나요? 다른 제공업체가 지원되지 않는다면, 애플리케이션을 업데이트하거나 다른 프록시를 사용해 연결해야 할 수도 있습니다.

TrueFoundry의 MCP 훅은 게이트웨이의 범위를 모델 요청에서 도구 호출까지 확장합니다. 하지만 게이트웨이는 자신을 거치는 트래픽만 검사할 수 있습니다. 개발자의 머신에서 명령을 실행하는 코딩 에이전트는 이 시야 밖에 있을 수 있습니다.

Perplexity의 오픈소스 Numbat은 바로 그쪽을 담당합니다. Numbat은 로컬 훅을 통해 지원되는 에이전트에 연결되며, 셸 명령이나 파일 쓰기 같은 계획된 작업을 실행 전에 검사할 수 있습니다. 차단 기능은 선택 사항이며 기본적으로 꺼져 있습니다. 게이트웨이는 자신을 통해 라우팅되는 모델 트래픽을 봅니다. Numbat은 에이전트가 그 응답으로 무엇을 하는지에 대한 가시성을 더해 줍니다.

게이트웨이의 통제 범위가 어디까지인지 알아야 합니다

Forkast News는 서로 다른 방향에서 게이트웨이로 다가가는 세 가지 계보를 제시합니다.

• LLM 중심 게이트웨이: LiteLLM과 Portkey는 제공업체 간 변환, 요청 라우팅, 토큰 추적 등 모델 호출에서 출발했습니다. 현재는 도구 호출에 대한 제어 기능을 추가하고 있습니다.
• API 관리 플랫폼: Kong, Google의 Apigee, Azure API Management는 인증, 권한, 트래픽 관리에서 출발해 이후 모델 지원과 AI 특화 규칙을 추가했습니다.
• 에이전트 네이티브 인프라: 예를 들어 agentgateway는 MCP와 A2A를 포함해 에이전트가 모델, 도구, 다른 에이전트와 통신하는 방식을 중심으로 구축되었습니다.

어떤 유형을 선택할지는 무엇을 라우팅하느냐에 달려 있습니다.

• 모델 호출만 라우팅하나요? LLM 우선 게이트웨이로 시작하는 것이 좋습니다.
• 이미 API 규칙이 가득한 엔터프라이즈 환경에서 모델 호출을 라우팅하나요? 이미 보유한 플랫폼으로 시작하세요.
• 에이전트가 도구를 호출하고, 그 도구가 다시 모델을 호출하나요? 이러한 연결도 포괄되는지 확인하세요.

모두가 공유하는 단일 장애 지점이 생깁니다

고객 지원 챗봇은 OpenAI를, 리서치 도구는 Anthropic을 사용하고, 둘 다 같은 게이트웨이를 통해 연결된다고 가정해 보겠습니다. 그런데 그 게이트웨이가 작동을 멈추면, OpenAI와 Anthropic이 정상적으로 운영되고 있더라도 두 도구 모두 모델에 접근할 수 없게 됩니다.

실제로 일어난 일입니다. 2025년 6월 12일 장애 당시 Cloudflare의 AI Gateway 오류율은 최대 97%에 달했습니다. 이 게이트웨이는 설정 저장을 Cloudflare의 Workers KV 스토리지 서비스에 의존했는데, 바로 그 서비스에 장애가 발생한 것입니다.

게이트웨이를 직접 운영한다면, 하나에 장애가 발생했을 때 대신 처리할 수 있는 다른 사본을 함께 실행해 두세요. 다른 업체가 게이트웨이를 호스팅한다면, 장애 발생 시 서비스를 어떻게 유지하는지, 복구 중에 요청은 어떻게 처리되는지 문의하세요.

LLM 게이트웨이에서 살펴봐야 할 핵심 기능

게이트웨이에 모든 사람의 자격 증명에 대한 액세스 권한을 맡기는 만큼, 그 대가로 게이트웨이가 무엇을 해 주는지 까다롭게 따져야 합니다.

• 여러 제공업체 앞에 놓인 하나의 API: 코드는 하나의 형식(주로 OpenAI 호환 형식)을 사용하고, 게이트웨이가 이를 변환합니다. LLM 제공업체들도 이에 발맞추고 있습니다. 예를 들어 Perplexity의 Agent API는 OpenAI의 Responses API 인터페이스를 지원하므로, 팀에서 기존 OpenAI 클라이언트 라이브러리를 재사용할 수 있습니다.
• 규칙이 적용된 가상 키: 각 팀이나 제품은 자체 키를 받으며, 이 키에는 허용 모델, 요청 한도, 지출을 관리하는 규칙이 적용됩니다.
• 라우팅 및 폴백: 게이트웨이는 사용자가 정한 설정에 따라 요청을 모델로 보내며, 이 설정은 비용이나 속도, 특정 제공업체를 우선하도록 구성할 수 있습니다. 호출이 실패하면 다른 모델을 시도할 수 있습니다. Perplexity의 Agent API에서는 다른 제공업체의 모델을 포함해 최대 5개의 모델을 원하는 순서대로 지정할 수 있습니다.
• 캐싱: 저장된 응답을 활용하면 제공업체를 한 번 더 호출하지 않아도 됩니다. 일부 게이트웨이는 동일한 요청을 일치시키고, 다른 게이트웨이는 의미가 유사한 요청까지 일치시킬 수 있습니다. 캐시된 응답을 사용자나 팀별로 분리할 수 있는지, 개인화된 답변이나 시간에 민감한 답변에 대해서는 캐싱을 끌 수 있는지 확인하세요.
• 스트리밍 및 일관된 오류 처리: 응답은 생성되는 대로 전달되며, 제공업체 오류는 애플리케이션이 처리할 수 있는 형식으로 변환됩니다. AI 가드레일을 추가했을 때 어떻게 되는지 확인하세요.
• 로깅 및 비용 할당: 게이트웨이는 누가 호출했는지, 어떤 모델이 처리했는지, 토큰을 얼마나 사용했는지, 시간이 얼마나 걸렸는지, 그리고 예상 비용을 기록합니다. 로그에 프롬프트와 응답이 포함되는지, 로그가 얼마나 오래 보관되는지 확인하세요.
• 가드레일 훅: 요청 경로상에서 게이트웨이가 콘텐츠를 외부 스캐너에 보내 판정을 받을 수 있는 지점입니다. 일반적으로 모델 요청 전이나 응답 후에 위치합니다. 스캐너에 장애가 발생했을 때 요청이 중단되는지 계속 진행되는지, 그리고 다른 스캐너를 연결할 수 있는지 확인하세요.
• 잠글 수 있는 관리자 인터페이스: 게이트웨이는 제공업체 자격 증명에 대한 액세스와 모든 사람이 사용하는 규칙을 관리합니다. 관리자 액세스를 애플리케이션 트래픽과 별도로 제한할 수 있는지, 읽기 전용 사용자가 설정을 변경할 수 없는지 확인하세요. 메인 밸브에는 잠금장치가 필요합니다.

LLM 게이트웨이를 구축하는 데 사용할 수 있는 도구는 무엇인가요?

기능 목록은 시장 전반에 걸쳐 서로 겹칩니다. 내부 모델 액세스에 관한 한 Reddit 스레드에서 작성자는 이렇게 물었습니다. 전담 엔지니어가 필요 없는 게이트웨이는 무엇일까요?

저희가 보기에는 이것이 올바른 질문이며, 작업을 얼마나 직접 맡을 의향이 있느냐에 따라 네 가지 답이 있습니다.

직접 작성하기

최소한의 게이트웨이가 처리하는 작업은 몇 가지뿐입니다. 요청을 받고, 호출자의 키를 확인하고, 제공업체 자격 증명을 추가하고, 호출을 전달하고, 결과를 기록하는 것입니다. 하지만 다양한 제공업체 형식을 지원하려면 일이 늘어납니다. 전체 시스템을 계속 가동하는 일도 마찬가지입니다.

이미 Envoy를 운영하고 있다면, Envoy의 외부 처리(external processing) 필터를 사용해 요청과 응답을 검사하고 변경하는 서비스를 연결할 수 있습니다. 다만 그 서비스는 여전히 직접 구축하고 운영해야 합니다.

게이트웨이가 비용을 줄여 주는지에 관한 r/LLMDevs 스레드에서 u/QuanTradin은 모든 호출에 토큰과 캐시 적중 플래그를 기록한 덕분에 동일한 프롬프트에 전액을 지불하던 작업 두 개를 찾아낼 수 있었다고 말했습니다.

“...그 문제를 고친 것이 어떤 라우팅 계층을 도입하는 것보다 더 가치 있었어요.”

이는 한 사용자가 전한 경험이지만, 출발점으로 삼기에 좋습니다. 정교한 라우팅 방식을 구축하기 전에 무엇에 비용을 지불하고 있는지부터 파악하세요.

오픈소스 게이트웨이 자체 호스팅하기

이 경우 흔히 선택하는 것은 LiteLLM입니다. OpenAI와 호환되고, 다양한 제공업체를 지원하며, 커뮤니티 규모도 큽니다. Bifrost는 요청당 오버헤드를 낮추도록 설계된 대안입니다. 기능 목록에서 관측 가능성(observability)이 최우선이라면 Helicone도 살펴볼 만합니다.

LiteLLM도 다른 제품과 마찬가지로 일부 팀에게는 한계가 있습니다. 직접 구축하는 방식의 대안에 관한 r/aiagents 스레드에서 u/Own_Bar_920은 LiteLLM이 라우팅은 잘 처리했지만, 팀 간 프롬프트 버전 관리와 모델 교체 시 지속적인 평가(eval)에서는 부족해 결국 별도의 도구로 옮겼다고 말했습니다.

이러한 기능은 기본적인 게이트웨이 라우팅의 범위를 벗어나는데, 바로 그 점이 핵심입니다. 라우팅이 주된 요구 사항이라면 LiteLLM은 이들에게 충분히 제 역할을 했습니다.

에디션에 따라 일부 기능이 다르긴 하지만, 기성 기능 목록을 그대로 활용하면서 게이트웨이를 내부 네트워크 안에 둘 수 있습니다. 대신 패치 작업도 직접 책임져야 하는데, 앞서 살펴본 Check Point의 취약점 공개 사례가 이를 구체적으로 보여 줍니다. 게이트웨이의 가용성 역시 직접 책임져야 하며, 이는 단일 장애 지점 섹션에서 다룬 내용입니다.

다만 이를 책임질 담당자를 위한 예산은 마련해 두세요. 내부 액세스용 게이트웨이에 관한 한 r/LLMDevs 스레드에서 제기된 우려 중 하나는 유지 관리였습니다. u/Informal-Writer9685는 “유지 관리를 위해 전담 엔지니어가 필요하지 않은” 것을 원했고, 알려진 LiteLLM의 업그레이드 불안정성이 자신들 규모에서도 실제 문제인지, 아니면 프로덕션 환경에서만 우려할 일인지 물었습니다.

관리형 게이트웨이 사용하기

Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter, Portkey의 호스팅 게이트웨이는 서비스를 대신 운영해 줍니다. 호환되는 애플리케이션이라면 URL 변경과 API 키만으로도 첫 요청을 보낼 수 있을 만큼 간단할 수 있습니다.

여기서 감수해야 할 부분은 이제 모든 프롬프트가 제공업체에 도달하기 전에 서드파티를 거친다는 점입니다. 규정 준수 서류에 데이터 처리자가 하나 더 추가되는 셈이며, 게이트웨이 자체의 장애는 벤더의 인시던트이므로 직접 해결할 수 없습니다.

예를 들어 2026년 2월 17일과 19일, 캐싱 종속성에 장애가 발생한 뒤 OpenRouter에서 각각 38분과 35분 동안 서비스 장애가 이어졌습니다. 일부 고객은 “User not found” 오류를 받고 아무 문제 없는 API 키를 디버깅하느라 시간을 허비했습니다. 문제는 게이트웨이의 인프라에 있었습니다.

하지만 OpenRouter가 상세한 사후 분석 보고서를 공개하고, 캐시 장애로 데이터베이스에 과부하가 걸리지 않도록 보호 장치를 추가한 점은 높이 평가할 만합니다. OpenRouter 같은 관리형 게이트웨이는 액세스를 단순화할 수 있지만, u/QuanTradin이 r/LLMDevs에서 지적했듯이 청구서를 통합한다고 해서 지출이 자동으로 줄어들지는 않습니다.

이미 사용 중인 API 게이트웨이 확장하기

이미 Kong, Apigee 또는 Azure API Management가 서비스의 앞단을 맡고 있다면, 각각 AI 특화 기능을 제공합니다. Kong AI Gateway, Apigee의 AI 게이트웨이 정책, Azure API Management의 AI 게이트웨이입니다. 기존의 인증, 네트워크 규칙, 운영 절차를 기반으로 플러그인이나 정책을 통해 모델 제어 기능을 추가할 수 있습니다.

대기업에서는 이 방법이 조직 내 저항이 가장 적은 경로일 수 있습니다. 다만 이들의 AI 기능은 독립형 게이트웨이의 기능보다 역사가 짧습니다. 사용하려는 플러그인이나 정책 전체를 적용한 상태에서 토큰 기반 속도 제한과 스트리밍을 반드시 테스트하세요.

그러니 꼭 마스터 밸브, 즉 전능한 게이트웨이를 설치하세요. 다만 서두에 등장한 엔지니어의 말에도 일리가 있습니다. 회사의 모델 접근 권한이 어쩌다 서랍 속에 맞는 키를 넣어 둔 사람에게 좌우되어서는 안 됩니다.

게이트웨이는 이러한 키를 중앙에서 관리함으로써 이 문제를 해결하지만, 그만큼 서랍을 열어 두었을 때의 위험도 커집니다. 그 서랍이 누구의 것인지 알고 있어야 합니다.

LLM 게이트웨이 FAQ

LLM 게이트웨이는 무료인가요?

LLM 게이트웨이 제품군 전반을 말씀하시는 것이라면, 일부 LLM 게이트웨이는 무료 버전을 제공합니다.

LLM 게이트웨이의 가격은 무료 오픈 소스 소프트웨어에서 월 50달러 안팎으로 시작하는 유료 요금제까지 다양하며, 엔터프라이즈 배포에는 맞춤형 가격이 적용됩니다. 대신 일정 비율을 부과하는 곳도 있습니다. 예를 들어 OpenRouter의 Standard 요금제는 크레딧 구매 금액에 5.5%를 추가로 부과합니다.

어떤 LLM 게이트웨이가 가장 좋을까요?

직접 맡을 의향이 있는 작업은 어디까지인가요?

• 셀프 호스팅하면서 구성을 직접 제어하고 싶다면 Bifrost나 Helicone을 살펴보세요.
• OpenRouter나 Vercel AI Gateway 같은 관리형 옵션은 서비스 운영을 다른 곳에 맡기고 싶은 팀에 적합합니다.
• 이미 Kong이나 Azure API Management를 사용하고 있다면 해당 제품의 AI 기능부터 확인해 보세요.

후보로 추린 게이트웨이를 실제 요청으로 테스트해 보고, 제공업체에 장애가 발생했을 때 어떻게 동작하는지도 확인하세요.

AWS에도 LLM 게이트웨이가 있나요?

네. Amazon Bedrock AgentCore Gateway는 AWS에서 “추론 대상(inference targets)”이라고 부르는 기능을 통해 모델 호출을 지원합니다. 이를 통해 애플리케이션은 하나의 엔드포인트로 Amazon Bedrock, OpenAI, Anthropic 등의 제공업체에 접근할 수 있으며, 제공업체 자격 증명과 라우팅은 게이트웨이가 처리합니다.