12단계 에이전트 실행에서 로그에 15개의 200 OK가 찍힌다. 개별 호출은 전부 성공했다. 그러나 최종 답은 틀렸다. 3단계의 불량 응답이 4단계를 오염시키고, 그 영향이 12단계까지 전파됐기 때문이다. 에이전트 게이트웨이(agent gateway)는 이 문제를 해결하는 전용 인프라 레이어로, 에이전트 코드 내부가 아니라 에이전트가 호출하는 모든 대상(LLM 프로바이더, MCP 도구 서버, 서브에이전트) 앞에 위치하며 라우팅·정책·관측을 중앙에서 처리한다.
LLM 게이트웨이와의 차이
표준 LLM 호출은 트랜잭션이다. 요청 하나, 응답 하나, 범위가 고정된 비용, 국소적인 실패. 에이전트는 다르게 동작한다.
- 실행마다 복수의 프로바이더: 계획에는 Claude, 분류에는 GPT-4o-mini, 이미지에는 Gemini — MCP 도구 호출과 서브에이전트 위임이 섞인다.
- 도구 호출은 LLM 외부에 닿는다: 웹 검색 타임아웃이나 잘못된 DB 응답이 다음 프롬프트에 유효한 컨텍스트처럼 주입된다.
- 장애가 발생 지점에 머물지 않는다: 3단계 불량 응답이 4→5→12단계까지 전파된다.
- 토큰 비용이 복리로 쌓인다: 각 단계의 출력이 다음 단계의 입력이 되므로, 멀티 에이전트 루프 하나가 대규모 비용을 순식간에 발생시킨다.
| 항목 | LLM 게이트웨이 | 에이전트 게이트웨이 |
|---|---|---|
| 대상 범위 | 단일 LLM 요청/응답 | 전체 에이전트 실행 체인 |
| 관측 단위 | 개별 호출 로그 | 실행 단위 계층적 트레이스 |
| 비용 제어 | 요청별 | 에이전트·워크스페이스별 예산 |
| 보안 적용 | 최종 응답 | 모든 단계 입출력 |
| MCP 도구 관리 | 해당 없음 | 크레덴셜 주입·접근 제어·감사 |
에이전트 게이트웨이가 해결하는 6가지 문제
1. 크레덴셜 분산: 멀티 프로바이더 에이전트는 API 키가 코드·환경변수·서비스 설정에 흩어진다. 게이트웨이가 크레덴셜을 중앙 저장하고 런타임에 주입한다. AWS Secrets Manager, Azure Key Vault, HashiCorp Vault 연동 지원.
2. 멀티 프로바이더 신뢰성: 4단계에서 프로바이더 장애가 발생해도 실행 전체가 멈추지 않는다. 조건부 라우팅·자동 폴오버·지수 백오프 재시도가 장애를 발생 지점에서 처리한다.
3. 범위 지정 접근 제어: 모든 에이전트가 모든 프로바이더·모델·MCP 도구에 접근하면 안 된다. 게이트웨이는 워크스페이스별로 허용 프로바이더, 허용 모델, 노출 MCP 도구를 3단계로 제한한다.
4. 모든 홉에서 가드레일 적용: 도구 입력에 프롬프트 인젝션이나 PII가 포함되어 있다면 도구 실행 전에 차단해야 한다. 도구 출력에 비밀이나 위험 콘텐츠가 있다면 다음 LLM 호출이 컨텍스트로 흡수하기 전에 차단한다. 사용자에게 전달되는 최종 응답만 검사하는 것이 아니라 모든 단계에서 가드레일이 동작한다.
5. 비용 예산 집행: 재귀 루프, 장황한 완성 결과, 무제한 에이전트 실행은 가장 비용이 큰 실패 유형이다. 게이트웨이는 에이전트·팀별로 토큰 예산을 추적·집행해 한 워크스페이스의 폭주 에이전트가 공유 예산을 소진하지 못하게 막는다.
6. 전체 체인 관측성: 단계별 로그로는 12단계 실행이 왜 잘못됐는지 알 수 없다. 실행 단위로 모든 모델 호출·도구 호출·서브에이전트 위임을 하나의 트레이스 ID 아래 묶은 OTEL 준수 트레이스가 필요하다. 15개 로그를 따로 뒤지는 대신 계층적 뷰 하나를 열면 된다.
아키텍처 구조
┌─────────────────────────────┐
│ 에이전트 코드 │
│ (LangGraph, CrewAI, SDK...) │
└──────────────┬──────────────┘
↓ 모든 호출
┌─────────────────────────────┐
│ 에이전트 게이트웨이 │ ← 라우팅, 정책, 관측
├─────────────────────────────┤
│ AI Gateway │ MCP Gateway │
│ (LLM 호출) │ (도구 호출) │
└──────┬──────────────┬───────┘
↓ ↓
LLM 프로바이더 MCP 서버·서브에이전트누구에게 유용한가?
- 멀티 프로바이더 에이전트를 프로덕션에 운영하는 팀: 실행 추적·비용 제어·가드레일을 에이전트 코드 수정 없이 적용하고 싶을 때
- 플랫폼 엔지니어: 여러 팀의 에이전트가 공유 크레덴셜과 예산을 안전하게 사용하도록 제어해야 할 때
- 보안·컴플라이언스 담당자: 에이전트가 어느 도구를 언제 어떤 파라미터로 호출했는지 감사 기록이 필요할 때
구현 사례
Portkey는 AI Gateway(LLM 라우팅·신뢰성·비용), MCP Gateway(MCP 서버 프록시·접근 제어), Agent Gateway(A2A 프로토콜 에이전트 서버 레지스트리)를 통합한 3단 구조로 에이전트 게이트웨이를 구현한다.
관련 도구
- litellm — OpenAI 형식으로 100개+ LLM을 통합 호출하는 오픈소스 AI 게이트웨이
- langfuse — LLM 앱 관찰·평가·모니터링 오픈소스 플랫폼
- agentops — AI 에이전트 프로덕션 운영 관찰·제어 레이어
- aiops — LLM 시스템 동작·비용·품질을 요청 단위로 통제하는 운영 계층
- mcp — 에이전트와 외부 시스템을 연결하는 표준 프로토콜
참고 자료
- What’s an agent gateway? — Portkey Blog (2026-05-04)