에이전트 데모는 도구와 모델을 직접 연결하면 빠르게 만들 수 있지만, 운영 단계에서는 라우팅, 안전 필터, 프로바이더 교체, 추적 코드를 모든 서비스에 반복해서 넣게 된다. Plano는 이 공통 인프라를 애플리케이션 밖 데이터 플레인(data plane)으로 이동시키는 오픈소스 AI 네이티브 프록시다. Envoy 기반이며 GitHub ★6.5k, Apache-2.0 라이선스로 공개되어 있다(2026년 5월 24일 확인).
해결하는 문제
| 애플리케이션 내부 구현 | Plano 데이터 플레인 |
|---|---|
| 에이전트마다 라우팅 코드 작성 | YAML에 agent URL과 설명 선언 |
| 프로바이더별 SDK와 폴백 처리 | 통합 LLM 라우팅 API |
| 서비스마다 OTEL 계측 추가 | 요청 흐름 자동 트레이스와 signal 수집 |
| 각 agent에 별도 안전 검사 | filter chain으로 moderation·memory hook 적용 |
구성 방식
Plano는 OpenAI 호환 chat completion 엔드포인트를 구현한 에이전트를 등록하고, listener와 router 설정을 통해 요청을 적합한 에이전트로 전달한다.
version: v0.3.0
agents:
- id: weather_agent
url: http://localhost:10510
listeners:
- type: agent
name: travel_assistant
port: 8001
router: plano_orchestrator_v1
agents:
- id: weather_agent
description: "도시별 실시간 날씨를 조회한다."
tracing:
random_sampling: 100에이전트 코드는 Plano의 LLM gateway를 base_url로 사용하면 모델 프로바이더 라우팅과 관측 기능을 공유한다.
구분해서 볼 점
litellm 같은 LLM 게이트웨이는 주로 모델 API 호환성과 비용·폴백을 다룬다. Plano는 LLM 라우팅뿐 아니라 여러 에이전트 사이의 오케스트레이션과 agentic signal, filter chain을 전면에 둔다. agent-gateway의 실행 체인 중앙 통제 패턴을 실제 오픈소스 프록시로 구현하려는 도구에 가깝다.
공식 README는 프로젝트가 제공하는 Plano 계열 라우팅 모델을 첫 실행 경험을 위해 호스팅한다고 안내한다. 실제 프로덕션 적용 전에는 해당 모델의 운영 위치, 데이터 처리 정책, 자체 호스팅 방식과 보안 정책을 별도로 검토해야 한다.
누가 쓰면 좋은가
- 여러 개의 전문 에이전트를 HTTP 서비스로 이미 나눠 운영하는 플랫폼 팀
- 모델 공급자를 바꾸면서 애플리케이션 코드를 최소화하려는 팀
- 가드레일과 end-to-end 추적을 에이전트마다 복제하지 않으려는 운영자
관련 문서
- agent-gateway – 에이전트 실행 체인을 중앙 통제하는 인프라 패턴
- litellm – 다중 LLM 프로바이더 게이트웨이
- agent-harness – 에이전트 실행 품질을 좌우하는 하네스 설계
참고 자료
- katanemo/plano – GitHub 공식 저장소