LLM 게이트웨이: AI 에이전트를 위한 라우팅, 인증, 비용 제어

LLM 게이트웨이는 AI 에이전트 프로세스와 업스트림 모델 공급자 엔드포인트 사이에 위치한 HTTP 리버스 프록시로, 모든 아웃바운드 추론 트래픽의 데이터 플레인으로 작동합니다. 전달 전에 와이어 레이어에서 불투명한 키 핸들을 해석하고, 슬라이딩 윈도우 카운터를 사용해 테넌트별 스로틀 할당량을 적용하며, 요청별 OpenTelemetry 지출 텔레메트리를 방출하고, 업스트림 P99 지연 시간이 구성된 임계값을 초과하면 서킷 브레이커를 엽니다. 에이전트 애플리케이션 코드를 변경할 필요가 없습니다. 3개 이상의 동시 추론 소비자를 실행하는 모든 플릿은 이를 도입해야 합니다.

LLM 게이트웨이는 AI 에이전트 프로세스와 모델 공급자 엔드포인트 사이의 데이터 플레인에 위치한 HTTP 리버스 프록시로, 와이어 레이어에서의 불투명 키 해석, 슬라이딩 윈도우 카운터를 통한 테넌트별 할당량 적용, 요청별 OpenTelemetry 지출 텔레메트리, 서킷 브레이커 페일오버를 애플리케이션 코드에 보이지 않는 인프라 프리미티브로 제공합니다.

멀티 에이전트 추론에서의 데이터 플레인 문제

전용 추론 데이터 플레인 없이는 각 에이전트 프로세스가 자체 업스트림 연결을 관리합니다: 환경 상태에서 키를 해석하고, 프로세스별 할당량이 없으며, 요청별 텔레메트리가 없고, 업스트림 엔드포인트가 저하되었는지 여부에 대한 가시성이 없습니다. 에이전트가 2개일 때는 관리 가능합니다. 20개가 되면 4가지 뚜렷한 장애 모드가 발생합니다.

환경 검사를 통한 키 유출

환경에 평문 공급자 키를 보유한 에이전트 프로세스는 단 하나의 적대적 명령으로 이를 유출시킬 수 있습니다. 공격 면은 프로세스 환경 자체입니다: os.environ, Linux 호스트의 /proc/self/environ, 프로세스 상태를 직렬화하는 상세 오류 트레이스백, Authorization 필드를 포함한 아웃바운드 HTTP 헤더를 캡처하는 디버그 로그 구성.

에이전트가 환경 상태를 에코하게 하는 프롬프트 인젝션 공격은 평문 키를 보유한 에이전트에 대한 문서화된 공격 클래스입니다(OWASP LLM01:2025). 구조적 수정은 더 나은 입력 검증이 아닙니다: 에이전트 프로세스에서 평문 키를 완전히 제거하는 것입니다. Authorization 헤더가 작성되기 전에 와이어 레이어에서 불투명한 핸들($CRED{openai})을 해석하는 LLM 게이트웨이는 에이전트 프로세스가 유출될 수 있는 자료를 보유하지 않음을 의미합니다.

OpenLegion의 메시는 이를 인프라 수준에서 구현합니다: $CRED{} 핸들은 메시 호스트 경계에서 해석됩니다. 에이전트 컨테이너는 구조적으로 해석된 값에 도달할 수 없습니다. 그렇게 하지 말라는 지시를 받아서가 아니라, 해석이 주소 공간 외부에서 이루어지기 때문입니다.

공유 키 스로틀링에 의한 할당량 소진

업스트림 모델 공급자는 API 키 수준에서 스로틀링합니다. 20개의 에이전트 프로세스가 하나의 키를 공유하는 플릿에서, 예상 속도의 10배로 요청을 보내는 단일 프로세스(재시도 폭풍, 폭주 루프, 또는 무제한 추론 호출을 유발하는 프롬프트 인젝션 페이로드로 인해)는 나머지 19개의 키를 속도 제한 영역으로 밀어넣을 수 있습니다.

게이트웨이는 에이전트 식별자를 키로 하는 슬라이딩 윈도우 카운터를 사용해 테넌트별 할당량을 적용합니다. 에이전트의 카운터가 구성된 한도에 도달하면 게이트웨이는 게이트웨이 레이어에서 HTTP 429로 응답합니다: 업스트림 요청은 전달되지 않고, 공급자 할당량은 소비되지 않으며, 형제 에이전트는 영향을 받지 않습니다.

에이전트별 할당량은 OWASP LLM10:2025(무제한 소비)에 대한 구조적 완화 수단이기도 합니다. 적대적 명령이 에이전트로 하여금 무제한 추론 호출을 방출하게 하는 패턴입니다.

누락된 업스트림 관측 가능성

추론 데이터 플레인 없이는 요청별 텔레메트리가 각 에이전트 프로세스 내부의 계측을 필요로 합니다. 이는 중복적이고 일관성이 없습니다. 게이트웨이는 와이어 레이어에서 요청별로 OpenTelemetry OTLP 로그 레코드를 방출합니다: 에이전트 식별자, 업스트림 엔드포인트, 모델 이름, 입력 토큰 수, 출력 토큰 수, 캐시 히트 토큰, HTTP 응답 상태, 요청 기간.

요청별 지출 레코드(입력_토큰 × 1k_입력_가격 + 출력_토큰 × 1k_출력_가격)는 에이전트별 지출 원장에 누적됩니다. 이 원장은 일별 및 월별 지출 한도, 그리고 지출 이상 알림을 지원합니다.

보이지 않는 업스트림 저하

공급자 엔드포인트는 저하됩니다. 용량 이벤트 중 GPT-4o의 P99 테일 지연 시간은 12초에 달할 수 있습니다(OpenLegion 인프라 벤치마크, 2026년 6월). 데이터 플레인에 서킷 브레이커 없이는 플릿의 모든 에이전트가 모든 요청에서 이 저하를 흡수합니다.

서킷 브레이커를 가진 게이트웨이는 엔드포인트별 오류율과 P99 지연 시간을 추적합니다. 구성 가능한 실패 임계값이 초과되면(예: 5회 연속 5xx 응답 또는 30초 윈도우에서 P99가 8초 초과) 서킷이 열립니다: 이후 요청은 기본 엔드포인트가 시간 초과되기를 기다리지 않고 즉시 구성된 폴백 엔드포인트로 전달됩니다.

OpenLegion의 2026년 6월 벤치마크는 GPT-4o 기본 → Claude 3.5 Sonnet 폴백 토폴로지를 측정했습니다: 에이전트 코드를 변경하지 않고 P99가 12초에서 3.1초(3.9배)로 감소했습니다.

게이트웨이 아키텍처: 데이터 플레인 vs. 제어 플레인

데이터 플레인: 요청별 적용

모든 추론 요청은 데이터 플레인을 순서대로 통과합니다:

TLS 종료: 에이전트 프로세스가 TLS를 통해 게이트웨이에 연결합니다. mTLS 배포의 경우 에이전트도 인증서를 제시합니다. mTLS는 에이전트와 게이트웨이 사이의 요청별 인증 토큰 필요성을 제거합니다.
워크로드 ID 해석: 게이트웨이가 연결 워크로드를 테넌트 ID에 매핑합니다. mTLS 배포에서는 클라이언트 인증서에 내장된 SPIFFE SVID가 워크로드 ID를 전달합니다.
불투명 핸들 해석: 게이트웨이가 $CRED{} 핸들 패턴을 찾아 아웃바운드 Authorization 헤더를 검사합니다. 일치하는 핸들은 게이트웨이의 백킹 시크릿 스토어에 대해 해석됩니다.
할당량 확인: 게이트웨이가 테넌트의 슬라이딩 윈도우 카운터를 증가시키고 구성된 한도와 비교합니다. 카운터가 한도를 초과하면 게이트웨이는 Retry-After 헤더와 함께 429를 반환합니다. 업스트림 연결은 열리지 않습니다.
서킷 브레이커 확인: 게이트웨이가 대상 엔드포인트의 서킷 상태를 평가합니다. 서킷이 열려 있으면 요청은 기본 시도 없이 즉시 폴백으로 리다이렉트됩니다.
업스트림 디스패치: 게이트웨이가 자체 연결 풀에서 업스트림 엔드포인트로 연결을 열고 응답을 스트림 백합니다.
텔레메트리 방출: 응답 완료 시 게이트웨이가 텔레메트리 파이프라인에 OTLP 로그 레코드를 씁니다.

웜 패스(캐시에 해석된 핸들, 메모리에 할당량 카운터, 닫힌 서킷, 풀링된 연결)의 총 오버헤드: 0.7~~2.1ms. 콜드 패스(아웃바운드 시크릿 스토어 조회가 필요한 캐시 미스): 2.6~~6.6ms. 500ms~30초의 공급자 추론 지연 시간에서 웜 패스 오버헤드는 총 왕복 시간의 0.5% 미만입니다.

제어 플레인: 구성 및 정책

제어 플레인은 데이터 플레인의 동작을 관장합니다. 주요 책임:

테넌트 ID 및 할당량 구성, 엔드포인트 토폴로지, 핸들 권한 범위: 어떤 워크로드 ID가 어떤 핸들을 해석할 수 있는지. openai:read 범위를 가진 테넌트는 $CRED{openai}를 해석할 수 있지만 $CRED{anthropic}는 해석할 수 없습니다. 이것은 테넌트 간의 수평 이동을 방지합니다.

감사 정책: OTLP 로그 레코드에 어떤 필드가 나타나는지.

제어 플레인 API는 에이전트 측 네트워크에서 접근할 수 없어야 합니다. GHSA-53mr-6c8q-9789(LiteLLM, CVE-2026-35029, v1.83.0에서 패치됨)는 제어 플레인의 구성 쓰기 경로가 충분한 인가 없이 네트워크에서 접근 가능한 경우 무슨 일이 일어나는지 보여주었습니다.

배포 토폴로지

중앙 집중식 인그레스

단일 게이트웨이 클러스터가 에이전트 플릿의 모든 아웃바운드 추론 트래픽을 처리합니다. 운영 단순성이 우선시되는 약 50개 에이전트까지의 플릿에 적합합니다.

사이드카 패턴

각 에이전트 컨테이너가 루프백 인터페이스에서 게이트웨이 프로세스를 실행합니다. 장애 도메인은 하나의 에이전트 컨테이너입니다. 에이전트별 장애 격리가 우선시되는 대규모 플릿(50+ 에이전트)에 적합합니다.

메시 네이티브 프록시

OpenLegion에서 추론 프록시는 메시 서비스입니다. 메시 네이티브 모델은 워크로드 ID를 기본적으로 처리합니다: 각 에이전트 컨테이너는 스폰 시 메시가 발급한 ID를 받습니다.

OpenLegion의 견해

LLM 게이트웨이 기능 세트(mTLS, 슬라이딩 윈도우 할당량 적용, OTLP 지출 텔레메트리, 서킷 브레이커 페일오버)는 멀티 에이전트 플릿의 선택적 인프라가 아닙니다. 최소 실행 가능한 데이터 플레인입니다.

OpenLegion의 2026년 6월 인프라 테스트의 세 가지 측정값이 위험성을 수치화합니다:

페일오버 없는 P99 테일 지연: 공급자 용량 이벤트 중 GPT-4o 전용 배포에서 12초. 서킷 브레이커 폴백으로 Claude 3.5 Sonnet 사용 시: 3.1초. 3.9배 개선은 에이전트 애플리케이션 코드 변경이 전혀 필요하지 않았습니다.

키 유출 공격 면: 모든 에이전트가 환경에 평문 키를 보유한 20 에이전트 플릿에서, 프롬프트 인젝션(OWASP LLM01:2025)으로 침해된 단일 에이전트는 다른 모든 에이전트의 업스트림 연결 키를 유출할 수 있습니다. 불투명 핸들 해석을 가진 게이트웨이 중재 플릿에서는 동일하게 침해된 에이전트가 유출할 수 있는 자료를 보유하지 않습니다.

OWASP LLM 커버리지: 게이트웨이에서의 테넌트별 할당량 적용은 LLM10:2025(무제한 소비)를 해결합니다. 핸들 범위 적용은 LLM06:2025(과도한 에이전시)를 해결합니다.

AI 에이전트를 위한 자격 증명 관리 패턴을 평가하는 팀에게 게이트웨이의 불투명 핸들 해석은 거기에 설명된 볼트 프록시 패턴의 배포 수준 구현입니다.

LLM 게이트웨이 비교

기능	자체 호스팅 (LiteLLM)	OpenAI 네이티브	OpenLegion 메시 프록시
키 해석 모델	Postgres 백 키 스토어	관리형 서비스	불투명 핸들 → 와이어 레이어의 볼트
mTLS 워크로드 ID	지원 안됨	지원 안됨	에이전트 컨테이너별 SPIFFE SVID
할당량 적용	구성 기반, 키당	조직별 한도	슬라이딩 윈도우 카운터, 테넌트별
서킷 브레이커 페일오버	플러그인 기반	사용 불가	네이티브, 하프 오픈 프로브 포함
OTLP 지출 텔레메트리	부분적	내보내기 안됨	요청별, 모든 필드
제어 플레인 격리	수동; 기본으로 노출	관리형	프라이빗 메시 서브넷만
CVE 이력 (2024–2026)	GHSA-53mr-6c8q-9789 + 기타	공개 없음	없음

플릿에 맞는 게이트웨이 선택

mTLS vs. 베어러 토큰 인증

mTLS(mutual TLS)는 HTTP 페이로드가 교환되기 전에 TLS 핸드셰이크 레이어에서 클라이언트(에이전트)와 서버(게이트웨이) 모두를 인증합니다. 클라이언트 인증서는 암호학적으로 검증 가능한 워크로드 ID인 SPIFFE SVID를 전달합니다. 헤더에 베어러 토큰이 전송되지 않으며, 토큰을 발급, 배포, 교체할 필요가 없습니다.

프로덕션 멀티 에이전트 플릿의 경우 SPIFFE 발급 SVID를 사용한 mTLS가 올바른 인증 모델입니다. 토큰 관리 공격 면을 완전히 제거합니다.

슬라이딩 윈도우 vs. 고정 윈도우 할당량 카운터

고정 윈도우 카운터는 시계 경계에서 재설정됩니다. 에이전트는 하나의 윈도우 마지막 초와 다음 윈도우 첫 초에 최대 속도로 요청함으로써 명목 속도의 두 배로 버스트할 수 있습니다. 슬라이딩 윈도우 카운터는 악용할 시계 경계 없이 연속 시간 간격에 걸쳐 지속적인 카운트를 유지합니다. 추론 워크로드에는 슬라이딩 윈도우 적용이 올바른 모델입니다.

텔레메트리 세분화 요구사항

요청별 OTLP 레코드는 유용한 플릿 관측 가능성의 최소한입니다. 게이트웨이가 모든 레코드에서 이 필드를 제공하는지 평가하세요: agent_id, model_id, input_tokens, output_tokens, cache_tokens, upstream_latency_ms, upstream_status. 텔레메트리를 집계하는 게이트웨이는 에이전트별 지출 이상 감지나 정확한 서킷 브레이커 조정을 지원할 수 없습니다.

시작하기

mTLS 워크로드 ID, 슬라이딩 윈도우 할당량 적용, 요청별 OTLP 지출 텔레메트리로 멀티 에이전트 추론 플릿을 배포하세요.

OpenLegion에서 시작하기 문서 읽기 LiteLLM vs OpenLegion 비교

자주 묻는 질문

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

LLM 게이트웨이는 AI 에이전트 프로세스와 업스트림 모델 공급자 엔드포인트 사이의 데이터 플레인에 위치한 HTTP 리버스 프록시입니다. 와이어 레이어에서 불투명한 키 핸들을 해석하고(에이전트 프로세스는 평문 키를 보유하지 않음), 업스트림 디스패치 전에 테넌트별 슬라이딩 윈도우 할당량 제한을 적용하며, 요청별 OpenTelemetry 지출 텔레메트리를 방출하고, 업스트림 엔드포인트가 구성된 임계값을 초과하면 서킷 브레이커를 엽니다. 이 기능들은 에이전트 애플리케이션 코드 변경이 필요 없는 인프라 프리미티브로 작동합니다.

모델 공급자가 하나뿐이어도 LLM 게이트웨이가 필요한가요?

단일 공급자 플릿도 세 가지 게이트웨이 기능의 혜택을 받습니다: 불투명 핸들 해석, 테넌트별 할당량 적용, 요청별 OTLP 지출 텔레메트리. 웜 패스 오버헤드는 0.7~~2.1ms로 공급자 추론 지연 시간 500ms~~30초에 비해 무시할 수 있습니다.

LLM 게이트웨이에서 서킷 브레이커 페일오버는 어떻게 작동하나요?

게이트웨이는 롤링 관찰 윈도우 내에서 엔드포인트별 오류율과 P99 지연 시간을 추적합니다. 구성 가능한 실패 임계값이 초과되면(예: 5회 연속 5xx 응답, 또는 30초 윈도우에서 P99가 8초 초과) 서킷이 열립니다: 이후의 모든 요청은 저하된 기본 엔드포인트가 시간 초과되기를 기다리지 않고 즉시 구성된 폴백 엔드포인트로 전달됩니다. 냉각 기간 후 게이트웨이는 기본 엔드포인트에 하프 오픈 프로브를 디스패치합니다. 성공한 프로브는 서킷을 닫고, 실패한 프로브는 냉각 타이머를 재시작합니다. OpenLegion의 2026년 6월 벤치마크는 GPT-4o → Claude 3.5 Sonnet 토폴로지에서 P99를 12초에서 3.1초로 감소시키는 것을 측정했습니다.

mTLS란 무엇이며 LLM 게이트웨이에서 왜 중요한가요?

mTLS(mutual TLS)는 HTTP 페이로드가 교환되기 전에 TLS 핸드셰이크 레이어에서 연결하는 에이전트 프로세스와 게이트웨이 모두를 인증합니다. 에이전트는 암호학적으로 검증 가능한 워크로드 ID인 SPIFFE SVID를 전달하는 클라이언트 인증서를 제시합니다. HTTP 헤더에 베어러 토큰이 전송되지 않고, 토큰을 발급, 배포, 교체할 필요가 없습니다. SVID에서 파생된 워크로드 ID는 핸들 범위 적용을 구동합니다: 게이트웨이는 연결 워크로드가 SPIFFE ID의 범위에 있는 불투명 핸들만 해석할 수 있도록 허용하여 에이전트 컨테이너가 침해되더라도 테넌트 간 수평 이동을 방지합니다.

슬라이딩 윈도우와 고정 윈도우 할당량 적용의 차이는 무엇인가요?

고정 윈도우 카운터는 시계 경계에서 재설정됩니다. 에이전트는 하나의 윈도우 마지막 초와 다음 윈도우 첫 초에 최대 속도로 요청함으로써 명목 속도의 두 배로 버스트할 수 있습니다(분당 60 요청이 경계에서 20초에 120 요청이 됨). 슬라이딩 윈도우 카운터는 악용할 시계 경계 없이 연속 시간 간격에 걸쳐 지속적인 카운트를 유지합니다. 버스트가 업스트림 공급자 스로틀링을 유발할 수 있는 추론 워크로드에는 슬라이딩 윈도우 적용이 올바른 모델입니다.

요청별 OTLP 텔레메트리는 집계 지출 보고와 어떻게 다른가요?

요청별 OpenTelemetry OTLP 레코드는 모든 추론 호출에서 개별 필드를 캡처합니다: 에이전트 ID, 모델 변형, 입력 토큰, 출력 토큰, 캐시 히트 토큰, 업스트림 지연 시간, HTTP 상태. 이 레코드들은 에이전트별 지출 원장에 누적되어 일별 및 월별 예산 한도(에이전트가 한도에 도달하면 게이트웨이가 차단), 지출 이상 감지(에이전트의 요청당 비용이 롤링 기준선의 N배일 때 플래그 설정), 크로스 모델 비용 벤치마킹을 지원합니다. 집계 지출 보고는 신호가 요청별 분산에 있기 때문에 이상 감지를 지원할 수 없습니다.

게이트웨이 제어 플레인이 에이전트 측 네트워크에 노출하지 말아야 할 것은 무엇인가요?

제어 플레인은 할당량 구성, 엔드포인트 토폴로지, 핸들 권한 범위, 감사 정책을 관리합니다. 외부 접근 경로 없이 프라이빗 서브넷에 배포해야 합니다. GHSA-53mr-6c8q-9789(LiteLLM, CVE-2026-35029, v1.83.0에서 패치됨)는 관리 API에서의 불충분한 인가를 문서화했습니다. 에이전트 측 네트워크는 게이트웨이의 데이터 플레인 포트만 접근해야 합니다.

플릿을 위한 서킷 브레이커 임계값을 어떻게 조정하나요?

24주간의 프로덕션 트래픽에 걸쳐 공급자 엔드포인트별 P50, P95, P99 지연 시간 히스토그램을 수집하세요. 서킷 브레이커 오픈 임계값은 공급자의 일반 SLA에 비해 명확히 저하된 P99 값으로 설정해야 합니다(일반적으로 중앙 P99의 23배). 하프 오픈 프로브 전 냉각 기간은 공급자의 일반적인 복구 시간을 초과해야 합니다(30~60초가 합리적인 기준선입니다).