AI 에이전트를 실제 서비스에 붙이기 시작한 팀이라면 곧 두 가지 문제에 부딪힌다. 하나는 폐쇄형 API 모델, 오픈소스 모델, 로컬 모델, 사내에서 튜닝한 커스텀 모델이 제각기 다른 호출 방식을 요구한다는 점이고, 다른 하나는 이 모든 호출에서 쌓이는 사용 기록이 대부분 로그로만 남고 버려진다는 점이다. 최근 Show HN에 공개된 오픈소스 프로젝트 Experiential은 이 두 문제를 하나의 '컨트롤 플레인'으로 묶으려는 시도다. 스스로를 '오픈소스판 오픈라우터'로 소개하면서도, 단순 라우팅을 넘어 사용 데이터를 더 나은 모델로 되돌리는 것을 목표로 내세운다.
하나의 게이트웨이로 묶는 모델들
기본 사용 방식은 로컬에 OpenAI 호환 게이트웨이를 띄우는 것이다. 처음 실행하면 설정 마법사가 공급자(provider), 모델, 추론 강도(reasoning effort)를 고르는 공용 선택기를 통해 연결 정보를 잡고, 선택한 각 공급자 연결을 로컬에 저장한다. 이어서 공개 별칭(public alias)과 식별자, 그리고 기본값으로 잡힌 50달러의 커맨드 예산을 보여준 뒤 일회성 키를 한 번 출력한다. 사용자는 예컨대 opus-5 같은 별칭을 정하고 발급된 키를 받아 요청을 보내면 된다. 여러 공급자의 서로 다른 모델을 하나의 OpenAI 호환 엔드포인트 뒤에 숨기고, 별칭으로 추상화한다는 것이 핵심 아이디어다.
직접 게이트웨이를 운영하는 대신 관리형을 원한다면 platform.experientiallabs.ai의 호스팅 플랫폼을 쓸 수 있다. 이쪽은 동일한 OpenAI 호환 API에 더해 Anthropic Messages API까지 api.experientiallabs.ai/v1 주소로 제공한다. 특히 눈에 띄는 것은 SETUP.md에 담긴 방식인데, 사람이 직접 설정을 밟는 대신 Claude Code, Cursor, Codex 같은 코딩 에이전트에게 붙여넣을 프롬프트 네 개를 제공하고 에이전트가 설정을 대신 수행하도록 한다. 설정 자체를 에이전트에게 위임하는, 요즘의 '에이전트 우선' 흐름을 반영한 선택이다.
로컬 데이터 플레인과 파이썬 연동
로컬 게이트웨이는 exp 또는 exp run 명령으로 띄우며, 컴파일된 네이티브 데이터 플레인이 루프백(loopback) 위에서 모든 라우트를 처리한다. 즉 실제 트래픽 처리 부분은 성능을 위해 네이티브로 구현되어 로컬 인터페이스에서만 동작한다. 파이썬에서는 학습이 끝난 프로젝트 라우터를 공식 OpenAI 클라이언트 형태로 불러올 수 있는데, 이 클라이언트는 자신만의 사설 게이트웨이를 백엔드로 삼는다. 기존 OpenAI SDK 코드를 거의 그대로 두고 백엔드만 바꿔 끼울 수 있다는 점에서 도입 장벽을 낮추려는 설계로 읽힌다.
프로젝트에서 가장 차별화되는 지점은 '사용을 모델로 되돌리는' 파이프라인이다. 먼저 현재 운영 중인 에이전트에서 OpenTelemetry 트레이스를 수집한다. 당장 시험만 해보고 싶다면 공개된 terminal-tasks OTLP 데이터셋을 받아 쓸 수 있다. 그다음 build 명령이 공급자·모델·예산 설정을 안내하고 트레이스 파일을 요구하며 프로젝트를 만든다. 라우터가 트레이스를 모은 뒤에는 Tinker를 이용해 사용자가 소유한 오픈소스 모델을 파인튜닝한다. 정리하면 실제 사용 로그(트레이스) → 라우터 학습 → 내가 소유한 모델의 미세조정으로 이어지는 순환이며, 여기서 '사용이 곧 더 나은 모델이 된다'는 표어가 구체화된다.
실무자가 따져봐야 할 것
프라이버시 측면에서 익명 집계 방식의 PostHog 제품 텔레메트리가 기본으로 켜져 있다는 점은 짚어둘 만하다. 프로젝트 설명에 따르면 이 텔레메트리에는 프롬프트, 트레이스, 액션, 관측값, 경로, 모델명, 자격증명, 원본 고객 데이터가 절대 포함되지 않는다. 관련 설정은 로컬의 .exp/settings.toml에 저장되므로 조직 정책상 외부 전송을 막아야 한다면 이 파일에서 조정하는 흐름이 될 것이다. 저장소와 문서 규약은 AGENTS.md에 정리되어 있다.
종합하면 Experiential은 게이트웨이·라우팅·파인튜닝을 한 축으로 엮으려는 야심 찬 오픈소스지만, 현재 공개된 정보만으로는 판단을 유보해야 할 부분도 분명하다. 트레이스 기반 라우터가 실제 비용과 품질을 얼마나 개선하는지에 대한 정량 지표, Tinker 파인튜닝에 필요한 자원과 결과물의 성능, 50달러라는 기본 예산이 어떤 단위로 소진되는지 등은 원문에서 확인되지 않는다. 여러 모델을 하나의 API로 통합하려는 팀, 그리고 자체 트레이스로 소유 모델을 개선하는 실험을 해보려는 팀이라면 로컬 게이트웨이와 공개 데이터셋으로 먼저 가볍게 검증해본 뒤 도입 여부를 저울질하는 편이 합리적이다.