LLM 추적 도구가 이제 AI 게이트웨이까지 구축하는 이유

2026년 LangSmith, Langfuse, Opik, Braintrust는 모두 모델 제공업체 앞에 게이트웨이를 추가했다. 가장 큰 이유는 제어다. 추적 도구는 모델 호출을 기록만 할 수 있지만, 게이트웨이는 호출을 차단할 수 있다.

서로 다른 역할을 맡았던 두 가지 도구

지난 2년간 많은 팀은 대규모 언어 모델(LLM) 애플리케이션을 두 가지 도구로 운영했다. 애플리케이션과 모델 제공업체 사이에는 게이트웨이가 있었다. 게이트웨이는 제공업체 API 키를 보관하고, 제공업체별 API 간 변환을 처리하며, 실패한 호출을 재시도했다. 오픈 소스 프록시인 LiteLLM이 이 용도로 널리 쓰이게 됐다. 애플리케이션 옆에는 LangSmith나 Langfuse 같은 추적 도구가 있어 각 모델 호출, 도구 호출, 검색 단계를 기록했고, 엔지니어는 이를 통해 에이전트가 무엇을 했는지 확인할 수 있었다.

이처럼 역할을 나눈 데는 타당한 이유가 있었다. 게이트웨이는 빠르게 작동하고 모든 제공업체의 API를 지원해야 하는 반면, 추적 도구에는 편리한 인터페이스와 대용량 페이로드를 저장할 공간, 애플리케이션 코드를 감싸는 SDK가 필요하다. Langfuse는 여전히 두 도구를 함께 사용하는 설정을 안내하며, 모든 호출을 프록시를 거쳐 Langfuse로 보내는 LiteLLM Proxy 연동도 제공한다. 2026년에는 추적 도구 업체들이 직접 게이트웨이를 구축하기 시작했다.

6개월 동안 이어진 네 차례 출시

LangChain은 2026년 5월 LangSmith LLM 게이트웨이를 비공개 베타로 발표하고, 7월 30일 공개 베타로 전환했다. 이후 이 게이트웨이를 LangSmith의 고객 자체 클라우드 배포에도 포함했다. Braintrust는 기존 AI 프록시를 더 이상 지원하지 않기로 하고 사용자에게 새 게이트웨이를 안내했다. 이 게이트웨이는 현재 프리뷰 단계이며 정식 출시 전까지 무료다. Comet은 OpenAI 형식 요청을 받는 베타 엔드포인트로 Opik LLM 게이트웨이를 출시했다. 11월 4일 Langfuse는 Langfuse Cloud와 자체 호스팅 배포 환경 모두에서 AI 게이트웨이를 공개 베타로 출시했다. 이 게이트웨이는 MIT 라이선스로 제공되며 Rust로 작성됐다.

MLflow는 추적 도구가 아니라 머신러닝 수명 주기 관리 도구로 시작했으며, 예산 알림과 한도를 제공하는 AI 게이트웨이를 더 오래전부터 갖추고 있었다.

게이트웨이는 수년 전부터 사용돼 왔으며, 게이트웨이를 운영할 때의 위험도 잘 알려져 있다. 새 게이트웨이를 내놓은 곳은 모델 호출을 기록하는 일을 주력으로 해 온 기업들이다. 이제 이 기업들은 모든 호출이 먼저 자사의 게이트웨이를 거치도록 하려 한다.

예산을 관리하려면 요청 경로에 있어야 한다

추적 도구는 제공업체가 응답하고 토큰 비용을 지불한 뒤에야 모델 호출을 기록한다. 이 기록만으로도 지출 차트를 만들 수 있지만, 추적 도구는 지출을 막을 수 없다. 팀 예산을 지키고, 특정 모델을 차단하거나, 프롬프트에서 비밀 정보를 삭제하려면 요청이 제공업체에 도달하기 전에 확인해야 한다. 요청 경로에 있는 구성 요소만 이를 수행할 수 있다.

LangChain은 출시 게시물에서 이런 주장을 펼친다. 별도의 게이트웨이, 가드레일 제품, 관측성 도구를 조합해 사용하는 팀을 언급하며, 문제를 예방하려면 요청 계층에서 정책을 적용해야 한다고 설명한다. LangChain의 게이트웨이는 예산을 초과하게 되는 호출을 제공업체로 전달하는 대신 HTTP 상태 코드 402로 응답한다.

단일 진입점에서 모든 호출을 기록한다

두 번째 이유는 가시성이다. SDK는 누군가 계측한 코드 경로만 기록한다. 그 경로를 벗어난 곳에서는 에이전트 오류가 발견되지 않은 채 지나가기 쉽다. 노트북이나 랩톱에서 실행하는 스크립트, 또는 복사한 API 키를 사용하는 코딩 에이전트는 아무런 흔적도 남기지 않는다. 제공업체 키를 보관하는 게이트웨이는 제공업체로 가는 다른 경로가 없기 때문에 모든 호출을 확인할 수 있다.

Langfuse는 이 아이디어를 바탕으로 게이트웨이를 구축한다. 게이트웨이 문서에 따르면 각 게이트웨이 키는 사용자나 서비스 계정에 속하며, 팀이나 비용 센터 같은 메타데이터를 포함할 수 있다. 제공업체 인증 정보는 게이트웨이만 보유하고, 관리자는 각 인증 정보로 호출할 수 있는 모델을 승인한다. LangSmith는 Claude Code, Codex, Gemini CLI를 게이트웨이로 라우팅하는 설정 안내 페이지를 공개한다. 이 에이전트들은 애플리케이션의 추적 코드 바깥에 있는 개발자 컴퓨터에서 모델을 호출한다.

추적 도구의 게이트웨이가 더하는 것

추적 도구 업체들은 반대 방향의 주장도 내놓는다. 독립형 게이트웨이만으로는 충분하지 않다는 것이다. Langfuse는 출시 게시물에서 독립형 게이트웨이는 토큰과 비용만 집계할 수 있지만, 자사 게이트웨이를 사용하면 각 호출을 전체 트레이스의 일부로 만들 수 있다고 설명한다. Langfuse 게이트웨이는 W3C traceparent 헤더를 받아, 이를 통과한 호출이 애플리케이션에서 이미 시작된 트레이스에 합류하도록 한다. 기본 설정에서는 프롬프트와 응답 내용이 아니라 사용량과 비용을 기록한다.

게이트웨이를 추적 도구에 통합해야 한다는 주장을 뒷받침하는 가장 강력한 기술적 근거다. 독립형 게이트웨이는 모델 응답을 단순한 목록으로 볼 뿐이다. 반면 추적 도구는 이미 SDK를 통해 에이전트의 도구 호출과 검색 단계를 기록하므로, 각 게이트웨이 호출을 그 구조 안에 배치할 수 있다.

업체들이 직접 밝히지는 않지만, 상업적인 관점에서도 볼 수 있다. 게이트웨이를 운영하는 쪽은 제공업체 키와 사용 비용 보고서를 보유하며, 재무팀과 플랫폼팀은 바로 이 비용 보고서를 확인한다. 이 때문에 게이트웨이는 추적 뷰어보다 교체하기 어렵다. LangSmith와 Langfuse는 이미 이 위치를 서로 다르게 활용하고 있다. LangSmith는 고객이 자체 제공업체 키 없이 Kimi 같은 호스팅 모델을 호출할 수 있게 해 주는 Gateway Credits를 판매하는 반면, Langfuse의 FAQ에는 토큰을 재판매하지 않는다고 나와 있다.

베타 게이트웨이의 한계

이 게이트웨이들은 아직 초기 단계이며, 업체들은 자체적으로 부족한 점을 문서에 공개하고 있다. 현재 Langfuse 게이트웨이는 OpenAI와 Anthropic만 지원하며, Amazon Bedrock, Google Vertex AI, Google AI Studio 지원은 로드맵에 올라 있다. 제공업체 간 대체 연결과 팀, 사용자 또는 키별 강제 사용 한도 기능은 계획되어 있지만 아직 출시되지 않았다. 현재 게이트웨이가 제공하는 기능은 사용 비용 대시보드와 알림이다. 문서에는 호출 속도 제한이나 응답 캐싱에 대한 설명이 없다.

Langfuse 게이트웨이는 API 형식 간 변환을 지원하지 않으므로, OpenAI 클라이언트는 OpenAI 모델만 호출할 수 있다. 자체 호스팅 버전은 공식 제공업체 URL만 호출하므로, 현재는 Azure OpenAI, Bedrock 또는 내부 프록시를 사용할 수 없다. Comet은 Opik 게이트웨이가 개발과 테스트를 위해 설계됐다고 설명한다. Braintrust는 게이트웨이의 가격을 발표하지 않았다.

LangSmith의 게이트웨이는 이미 다른 게이트웨이보다 더 많은 기능을 제공한다. 문서에는 대체 연결, 사용 한도, 호출 속도 제한, 데이터 정책이 현재 기능으로 기재되어 있으며, OpenAI Chat Completions, OpenAI Responses, Anthropic Messages 형식을 지원한다. 대체 연결과 호출 속도 제한은 5월에 향후 작업으로 기재되어 있었으므로 베타 기간에 추가된 기능이다. 제품 전체는 여전히 베타로 표시되어 있다.

부하 테스트에서는 또 다른 유형의 한계가 드러났다. Langfuse 게이트웨이, LiteLLM, AcruxCore를 자체 호스팅해 진행한 벤치마크에 따르면 Langfuse 게이트웨이는 호출당 추가 지연 시간이 LiteLLM보다 짧았다. 하지만 Docker 기본 설정에서는 동시에 진행되는 스트림 1,000개 중 739개에 실패했다. 프로세스가 Docker의 기본 열린 파일 한도인 1,024개를 그대로 사용했기 때문이다. Langfuse의 Compose 파일에 한 줄을 추가하자 문제가 해결됐다.

이 베타 제품들과 비교하면, 수년간 독립형 게이트웨이로 운영되어 온 LiteLLM은 100개가 넘는 제공업체를 지원하며 가상 키, 사용 비용 추적, 가드레일, 부하 분산, 관리자 대시보드를 이미 제공한다. LiteLLM은 요청 처리 경로도 Python에서 Rust로 옮기고 있다. Rust 기반 AI 게이트웨이는 베타 버전이며, LiteLLM 팀은 Anthropic 스타일의 /v1/messages 요청이 12월 1일까지 Rust에서 처음부터 끝까지 처리될 것으로 예상하며, 지연 시간은 약 20배 줄어들 전망이다. MLflow와 AcruxCore 같은 일부 오픈 소스 플랫폼은 이미 게이트웨이와 추적 기능을 하나의 제품으로 제공한다.

게이트웨이와 추적기를 분리할 이유

게이트웨이를 추적기에 통합하면 비용이 따르며, 가장 큰 문제는 두 기능이 서로 강하게 결합된다는 점이다. 게이트웨이가 분리되어 있으면 로깅 콜백을 바꾸는 것만으로 팀이 추적 공급업체를 변경할 수 있다. 하지만 추적기가 게이트웨이 역할도 하면 모든 서비스의 기본 URL, 키, 모델 식별자까지 바꿔야 한다. 예를 들어 Langfuse는 모델 식별자를 credential:model 형식으로 기록한다.

추적기는 런타임 의존 요소가 되기도 한다. 추적 백엔드가 중단되면 팀은 추적 데이터를 잃는다. 게이트웨이가 중단되면 모델 호출이 실패한다. 게이트웨이를 운영하는 추적 공급업체는 이제 핵심 인프라에 걸맞은 가동 시간을 보장해야 한다.

보안 업체들도 요청 처리 경로에서 같은 위치를 차지하려 한다. Palo Alto Networks는 독립형 게이트웨이인 Portkey를 2026년 5월에 인수 완료하고, 이를 Prisma AIRS 플랫폼의 AI 게이트웨이로 만들었다. 보안팀은 관측 도구 안에 게이트웨이를 두기보다 직접 통제하기를 원할 수 있다. 3월의 LiteLLM 공급망 침해 사례에서 드러났듯, 게이트웨이는 공격자들의 표적이 되기도 했다.

팀의 선택 기준

팀은 모델을 호출하기 전에 무엇이 이루어져야 하는지 목록부터 작성할 수 있다. 가시성만 필요하다면 요청 처리 경로와 분리된 추적기만으로 충분하며 런타임 의존성도 추가되지 않는다. 예산, 키 정책, 모델 승인도 필요하다면 어떤 형태로든 게이트웨이가 필요하다.

다음으로는 제공업체 지원 범위를 살펴봐야 한다. 팀은 Azure OpenAI와 Bedrock을 포함해 프로덕션 환경에서 호출하는 모든 제공업체와 API 형식을 기록하고, 각 게이트웨이의 로드맵이 아니라 현재 지원 범위와 대조해야 한다.

이미 LiteLLM을 운영하는 팀은 베타 게이트웨이가 현재 없는 기능을 제공하기 전까지는 옮길 이유가 거의 없다. 추적기의 게이트웨이가 더해 주는 핵심 기능은 게이트웨이 호출을 에이전트 추적 정보 안에 포함하는 것이며, 이를 위해 이전할 가치가 있어야 한다. 새로 시작하는 팀은 한 업체가 게이트웨이와 추적기를 모두 제공하더라도 게이트웨이를 별도 계층으로 둘 수 있다. 기본 URL과 키를 하나의 설정 모듈에 모아 두면 나중에 옮길 때 코드를 수정할 필요 없이 설정만 바꾸면 된다.

대부분의 게이트웨이는 베타 또는 프리뷰로 표시되어 있으므로, 부족한 기능 목록은 빠르게 줄어들 것이다. 여전히 답이 나지 않은 질문은 일반적인 기업 환경에서 요청 처리 경로를 누가 담당할 것인가이다. 관측 팀인가, 독립형 게이트웨이를 운영하는 플랫폼팀인가, 아니면 보안팀인가? 올해 LangSmith와 Langfuse는 자체 게이트웨이를 구축했고 Palo Alto Networks는 게이트웨이 업체를 인수했지만, 많은 기술 스택에서는 여전히 LiteLLM을 통해 요청이 처리된다.