저는 팀원들에게 Claude Code, Codex, Kimi를 제공했습니다. 한 달 후, 저는 네 개의 서로 다른 결제 페이지를 열었지만 여전히 세 가지 기본적인 질문에는 답할 수 없었습니다. 즉, 누가 무엇을 얼마나 썼는지, 어떤 모델을 사용했는지, 그리고 첫 주의 흥분이 가라앉은 후에도 여전히 도구를 사용하는 사람이 있는지에 대한 질문이었습니다.

모든 제공업체는 각자의 결제 페이지를 가지고 있으며, 그 중 어느 것도 우리 팀과 사용자 구조에 맞지 않습니다. 그래서 저는 모든 것 앞에 하나의 게이트웨이를 두는, 작고 자체 호스팅이 가능한 참조 구현체(reference implementation)를 구축했습니다.

Repo (MIT): https://github.com/0xkaz/llm-governance-dashboard

구조 (The shape of it)

Coding agents (Codex / Claude Code / Kimi)
      │  per-user key, base_url = the proxy
      ▼
...

• **LiteLLM**이 게이트웨이 역할을 합니다: 모든 제공업체에 대해 하나의 OpenAI/Anthropic 호환 엔드포인트를 제공하며, 사용자별 가상 키(virtual keys)와 예산(budgets)을 관리합니다.
• 콜백 (callback) 기능이 모든 요청을 BigQuery로 스트리밍합니다 — 비용, 토큰, 지연 시간(latency), 팀, 사용자, 모델 정보가 포함됩니다.
• 작은 FastAPI 앱이 대시보드를 서버 사이드(server-side)에서 렌더링하며(JS 빌드 없음), Slack/이메일로의 예산 알림 및 키 발급/취소 셀프 서비스 기능을 제공합니다.

모든 것은 Docker를 통해 사용자의 노트북에서 실행됩니다; 저는 실제 GCP에서 전체 경로를 검증했습니다.

이것이 제공하는 두 가지

1. 비용 거버넌스 (Cost governance) — 사용자, 팀 및 모델별 지출/지연 시간 (latency); 80/100% 시점의 예산 알림; 사람들이 직접 발급하고 취소할 수 있는 가상 키 (마스터 키는 아무도 건드리지 않음).
2. 도입 추적 (Adoption tracking) — 더 흥미로운 절반: 팀이 실제로 에이전트를 사용하고 있는가, 그리고 그것이 지속되는가? 주간 활성 사용자 비율 (Weekly-active rate), 반복 사용 횟수, 그리고 각 개인이 사용하는 서로 다른 도구의 개수. 팀별로 집계되며, 개인별 사용량은 각자의 페이지에 유지됩니다. 저는 개발자당 산출물 수치가 아니라 의도적으로 **도입 (adoption)**을 추적합니다. 지속되는 사용은 조치를 취할 수 있는 신호인 반면, 리더보드는 사람들이 단순히 점수 조작(game)을 하게 만드는 요소이기 때문입니다.

나를 놀라게 한 세 가지

스트리밍 (Streaming)은 비용을 숨깁니다. 제공업체들은 스트리밍 응답에서 토큰 사용량을 생략하는 경우가 많아, 게이트웨이 자체의 키별 지출이 과소 집계됩니다. 명백히 비용이 발생한 요청임에도 때로는 $0로 표시되기도 합니다. 두 가지 해결책을 적용했습니다: 프록시(proxy) 단계에서 stream_options.include_usage=true를 주입하고, 대시보드가 정확하게 유지되도록 토큰으로부터 계산된 비용을 BigQuery로 백필 (backfill)합니다. 여기서 얻은 교훈은 다음과 같습니다: 데이터 웨어하우스 (warehouse)를 비용의 단일 진실 공급원 (source of truth)으로 취급하고, 게이트웨이의 엄격한 예산 차단 (budget-block) 기능은 최선 노력 (best-effort) 수준으로 간주하십시오. 두 수치는 서로 다를 수 있습니다. 어떤 작업에 무엇을 신뢰해야 하는지 알게 된다면 그것으로 충분합니다.

구독형 CLI는 게이트웨이를 우회합니다 — 하지만 이는 측정의 한계가 아니라 라우팅 (routing)의 문제입니다. ChatGPT에 로그인된 Codex, claude.ai 앱, 그리고 Moonshot의 Kimi CLI는 벤더와 직접 통신하므로, 해당 모드에서는 아무것도 기록되지 않습니다. 하지만 게이트웨이를 통과하는 모든 것은 측정됩니다 — 구독형 / 정액제 사용량도 포함됩니다 (토큰과 지연 시간은 기록되지만, 비용은 0으로 표시됨). 해결책은 라우팅입니다: 트래픽이 프록시를 통과하도록 강제하고 (API 키 인증 또는 Kimi를 위한 범용 OpenAI 호환 클라이언트 사용), 직접적인 외부 유출 (egress)을 차단하십시오. 이것은 도구의 한계가 아니라 조직의 정책 문제입니다. 이 두 측면 모두에 대해 솔직해질 가치가 있습니다.

사용자별 귀속 (Per-user attribution)을 위해서는 가상 키 (virtual keys)가 필요합니다. 원본 마스터 키 (raw master key)를 사용하면 모든 데이터가 단일 사용자로 표시됩니다. 각 사용자에게 권한이 제한된 키 (scoped key)를 부여하고 user_id / team 정보가 BigQuery의 모든 행에 기록되게 하십시오. 그러면 대시보드가 실제로 유용해집니다.

이것이 무엇인지 (그리고 무엇이 아닌지)

이것은 **데모 / 참조 구현체 (demo / reference implementation)**이며, 프로덕션 제품이 아닙니다. TLS가 적용되지 않았고, 단일 노드(single node)이며, 멀티 테넌트 보안 강화(multi-tenant hardening)가 되어 있지 않습니다. BigQuery와 Looker는 어떤 데이터 웨어하우스(warehouse)나 BI 도구로도 교체 가능합니다. 핵심 요구 사항은 단지 모든 요청별 로그(per-request log)를 보관하는 단 한 곳이 있다는 것입니다.

또한, 여러분이 가장 먼저 찾게 될 관측성 (observability) 도구들과는 의도적으로 다르게 설계되었습니다. Helicone, Langfuse, Portkey는 호출의 추적 (tracing) 및 디버깅 (debugging)에 탁월합니다. 반면 이것은 더 가볍고 다른 질문, 즉 **거버넌스 (governance) 및 도입 (adoption)**에 초점을 맞춥니다. 누가 얼마만큼의 비용을 쓸 수 있는지, 그리고 팀이 실제로 도구를 사용하고 있는지에 대한 질문입니다. 경쟁 관계가 아닌 상호 보완적인 관계입니다.

이 방식이 여러분의 문제 해결 접근 방식과 일치한다면, 포크(fork)하십시오.

다른 팀들은 AI 코딩 비용을 어떻게 관리하고 있는지 궁금합니다. 이와 같이 게이트웨이 우선 (gateway-first) 방식을 사용하시나요, 아니면 다른 방식을 사용하시나요?