LangSmith LLM Gateway: runtime governance built into the agent lifecycle
Quick Summary
LangSmith LLM Gateway는 에이전트와 모델 제공자 사이에서 비용·민감정보 정책을 요청 단계에 집행하고, 위반 조사와 수정까지 기존 LangSmith 추적 환경에 통합하는 런타임 거버넌스 계층이다.
🖼️ 인포그래픽
🖼️ 4컷 인포그래픽
💡 한 줄 요약
LangSmith LLM Gateway는 에이전트와 모델 제공자 사이에서 비용·민감정보 정책을 요청 단계에 집행하고, 위반 조사와 수정까지 기존 LangSmith 추적 환경에 통합하는 런타임 거버넌스 계층이다.
📌 핵심 요약
- LLM Gateway는 에이전트의 모델 호출 경로에 위치해 지출 한도를 집행하고, 개인정보와 비밀정보가 모델이나 추적 데이터로 전달되기 전에 삭제 처리한다.
- 조직·작업공간·사용자·API 키 단위의 비용 상한과 실시간 비용 집계를 제공하며, 상한에 도달한 요청에는 명확한 오류와 함께 402 응답을 반환한다.
- 게이트웨이를 통과한 호출과 정책 위반 이벤트는 기존 LangSmith 작업공간에 기록되어, 차단된 요청에서 원인 추적과 설정 수정까지 한 제품 안에서 처리할 수 있다.
- 설정은 에이전트의 base_url을 LangSmith Gateway 엔드포인트로 바꾸고, 제공자 API 키를 작업공간 비밀정보에 추가한 뒤 화면에서 정책을 지정하는 방식이다.
- 현재 범위는 LLM 호출이지만 향후 보안 통제 확대, 단계적 집행, 모델 대체·속도 제한, 도구·에이전트 간 호출·MCP 상호작용에 대한 게이트웨이로 확장할 계획이다.
🧩 주요 포인트
- 모델 요청 경로에서 비용과 민감정보 정책을 직접 집행한다 → 사후 기록에 그치지 않고 과다 호출과 정보 전파를 발생 지점에서 차단한다.
- 정책 이벤트를 기존 추적·평가 환경에 연결한다 → 위반 원인 확인, 프롬프트나 도구 설정 수정, 재평가가 하나의 작업 흐름으로 이어진다.
- 거버넌스를 에이전트 개발 환경에 배치한다 → 이미 LangSmith를 사용하는 팀은 별도 게이트웨이·감시 화면·감사 파이프라인을 추가하는 부담을 줄일 수 있다.
🧠 상세 정리
1. 관찰 가능성과 정책 집행 사이의 공백
글은 운영 환경의 에이전트에서 관찰만으로 해결하기 어려운 두 가지 사례를 제시한다. 코딩 에이전트가 밤새 재시도 반복에 빠지면 1만 번의 모델 호출과 네 자릿수 금액의 청구서가 발생할 수 있고, 고객 지원 에이전트가 사회보장번호를 포함한 환불 요청을 처리하면 해당 번호가 모델 제공자의 로그와 추적 데이터, 후속 시스템으로 퍼질 수 있다. 관찰 도구는 이런 일이 벌어진 뒤 원인을 보여주지만, 발생 자체를 막으려면 모델 요청이 처리되는 경로에서 정책을 집행해야 한다. 기존에는 별도의 게이트웨이, 가드레일 플랫폼, 관찰 스택을 조합하고 각 시스템의 신호를 다시 연결해야 했지만, LLM Gateway는 집행과 추적을 LangSmith 안에 함께 두는 방식을 제시한다.
2. 베타에서 제공하는 비용·보안 통제
LLM Gateway는 조직, 작업공간, 사용자, API 키 수준에 지출 상한을 설정할 수 있으며, 상한에 도달하면 에이전트에 명확한 오류를 담은 402 응답을 보낸다. 작업공간·사용자·API 키별 비용도 실시간으로 집계해 월말에야 예상 밖의 청구액을 확인하는 상황을 줄이도록 설계됐다. 개인정보와 비밀정보는 요청과 응답에서 감지되어 모델에 도달하거나 추적 데이터에 기록되기 전에 삭제 처리되며, 이 과정에서도 에이전트는 계속 실행된다. 또한 정책을 계층별로 적용할 수 있어 통제가 필요한 범위에 집중할 수 있고, 모든 게이트웨이 관리 작업은 감사 로그로 남아 보안 및 규정 준수 팀이 별도 감사 파이프라인 없이 기록을 확인할 수 있다.
3. 추적 연속성과 간단한 도입 방식
게이트웨이를 거친 모든 모델 호출은 나머지 에이전트 실행 기록과 동일한 LangSmith 작업공간에 나타나므로, 라우팅 변경 때문에 관찰 데이터가 별도 시스템으로 분리되지 않는다. 정책 이벤트는 LangSmith Engine에도 표시되며, 담당자는 위반 항목을 선택해 이를 발생시킨 정확한 추적으로 이동할 수 있다. 도입 과정은 에이전트의 base_url을 LangSmith Gateway 엔드포인트로 교체하고 LangSmith API 키를 사용한 뒤, 모델 제공자 API 키를 작업공간 비밀정보에 추가하고 화면에서 정책을 설정하는 것으로 설명된다. 별도의 인프라를 구축하거나 애플리케이션 코드를 대폭 변경하는 방식이 아니라, 기본 URL을 바꾸면서 기존 코드를 유지하는 것이 핵심이다.
4. 개발·관찰·평가와 연결된 대응 흐름
일반적인 거버넌스 제품은 정책 설정, 경고 확인, 위반 조사를 각각 별도의 화면과 절차에서 수행하게 하지만, LLM Gateway는 이 작업을 기존 LangSmith 환경에 배치한다. 차단된 요청과 삭제 처리된 개인정보 일치는 추적 가능한 이벤트로 기록되며, 사용자는 해당 이벤트에서 실제 에이전트 실행 문맥을 곧바로 확인할 수 있다. 원인을 파악한 뒤에는 같은 제품 안에서 시스템 프롬프트나 도구 구성을 수정하고, 기존 테스트 세트를 이용해 변경 결과를 다시 평가할 수 있다. 따라서 이미 LangSmith에서 에이전트를 개발하는 팀은 정책 이벤트와 이를 설명하는 추적 데이터를 나란히 보면서 탐지, 조사, 수정 절차를 진행하고, 별도 도구와 작업 문맥 전환을 줄일 수 있다.
5. 기존 거버넌스 접근법과의 차이
네트워크 계층 게이트웨이는 속도 제한, 라우팅, 트래픽 관리처럼 일반 API 인프라에 가까운 강한 통제를 제공하지만, 정책이 발동한 이유를 설명하는 에이전트 추적 문맥과 인공지능 특화 정책 조정이 부족할 수 있다. 독립형 가드레일 플랫폼은 소형 평가 모델 등을 활용한 정교한 평가와 정책을 제공하지만, 에이전트가 바뀔 때 모델을 계속 조정해야 하며 추적과 평가 환경이 두 곳으로 나뉜다. 데이터 플랫폼의 거버넌스 계층은 이미 해당 카탈로그나 레이크하우스를 사용하는 팀에는 적합하지만, 그렇지 않은 팀에는 단순 기능 추가가 아니라 플랫폼 이전에 가까운 도입이 된다. LLM Gateway는 에이전트가 실제로 개발되고 실행되는 환경에 연결함으로써 정책 이벤트를 추적·평가·대시보드와 같은 작업공간에 배치한다. 글은 특히 에이전트가 이미 LangSmith에 있는 팀을 대상으로, 별도의 생태계로 이동하지 않고 실제 운영 행동을 바탕으로 정책을 조정할 수 있다는 점을 차별점으로 제시한다.
6. 향후 확장 방향과 공개 베타
현재 출시 범위는 LLM 호출이지만, LangSmith는 Agent Gateway를 다양한 런타임 정책을 관리하는 중앙 통제면으로 확장하려 한다. 계획에는 개인정보와 비밀정보 탐지를 넘어서는 보안 통제, 즉시 차단 전에 적용할 수 있는 단계적 도입, 정책 발동 시 에이전트 실행을 유지하기 위한 모델 대체와 폴백, 동작을 조절하는 속도 제한이 포함된다. 같은 집행 방식을 모델 호출뿐 아니라 도구 호출, 에이전트 간 호출, MCP 서버 상호작용에도 적용하는 것이 향후 방향이다. 글은 거버넌스를 에이전트 시스템 위에 별도로 덧붙이기보다, 에이전트를 개발·관찰·평가하는 제품이 실행 규칙까지 집행해야 한다고 결론짓는다. 최초 발표 시점에는 비공개 베타였으나 7월 30일 업데이트에서 공개 베타 전환이 안내됐으며, LangSmith의 사이드바에서 LLM Gateway를 선택해 시작할 수 있다.
🧾 핵심 주장 / 시사점
- 이 글의 핵심 구분은 관찰과 집행이다. 추적 데이터가 사고 원인을 사후 설명한다면, 요청 경로의 게이트웨이는 비용 초과와 민감정보 전파가 완료되기 전에 정책을 적용한다.
- 조직부터 API 키까지 적용 범위를 나누고 위반을 실제 추적에 연결하는 구조는 정책의 대상과 원인을 함께 확인하게 해, 일률적인 차단보다 구체적인 수정과 재평가에 초점을 맞춘다.
- 도구·에이전트 간 호출·MCP까지 포함한 계획은 현재의 LLM 프록시를 출발점으로 삼아, 에이전트 런타임 전반에 동일한 집행 원칙을 적용하려는 방향을 보여준다.
✅ 액션 아이템
- 에이전트 base_url을 LangSmith Gateway 엔드포인트로 바꾸고 제공자 API 키를 작업공간 비밀정보에 넣은 뒤 화면에서 비용·민감정보 정책을 지정한다.
- 조직·작업공간·사용자·API 키 단위 지출 상한과 실시간 비용 집계 기준을 정하고 상한 도달 시 402 차단이 의도대로 동작하는지 점검한다.
- 개인정보·비밀정보가 모델과 추적 데이터로 전달되기 전 삭제되는지, 정책 위반 기록이 기존 LangSmith 작업공간에서 원인 추적·설정 수정으로 이어지는지 확인한다.
❓ 열린 질문
- 민감정보 삭제 처리가 모델 입력과 LangSmith 추적 데이터에 동일한 기준으로 적용되는가?
- 조직·작업공간·사용자·API 키 단위 상한 중 어느 계층을 우선 집행 단위로 둘 것인가?
- 현재 LLM 호출 범위 이후 보안 통제 확대, 단계적 집행, 모델 대체·속도 제한, 도구·에이전트·MCP 확장 중 어떤 순서가 우선인가?