Molayo

© 2026 Molayo

Dev.to헤드라인2026. 06. 04. 02:22

실제로 어떤 모델이 실행되었을까? `openrouter/auto` 사용량을 모델별로 실시간 추적하기

요약

OpenRouter의 'auto' 라우팅 기능을 사용할 때 실제로 어떤 모델이 호출되었는지와 비용을 추적하는 방법을 설명합니다. 응답 본문의 model 필드와 generation-lookup 엔드포인트를 활용하여 프록시 없이도 모델별 가시성을 확보하는 가이드를 제공합니다.

핵심 포인트

  • openrouter/auto 사용 시 응답의 model 필드로 실제 결정된 모델 확인 가능
  • generation-lookup 엔드포인트를 통해 상세 비용 및 토큰 사용량 조회 가능
  • 프록시 방식 대신 대역 외(out-of-band) 폴링 방식을 통한 안정적인 모니터링 권장

만약 openrouter/auto를 사용하여 OpenRouter를 통해 라우팅한다면, 여러분은 작지만 반복되는 미스터리에 직면하게 됩니다. 여러분은 "사용 가능한 최선의 모델"을 요청했고, OpenRouter는 그중 하나를 선택했습니다. 하지만 직접 찾아보지 않는 한, 어떤 모델이 요청을 처리했는지, 비용이 얼마인지 알 방법이 없습니다. 이를 시간당 수백 번의 호출을 수행하는 자율 에이전트(autonomous agent) — OpenClaw와 그 친구들은 auto를 매우 좋아합니다 — 에 적용하면, 월말 청구서는 마치 범인을 찾아야 하는 추리 소설(whodunit)처럼 변해버립니다.

좋은 소식은 OpenRouter가 이미 여러분에게 필요한 모든 것을 기록하고 있다는 점입니다. 여러분은 그저 그것을 가져오기만 하면 됩니다. 프록시(proxy), SDK 래퍼(wrapper), 또는 단 하나의 프롬프트(prompt)도 수정하지 않고 모델별, 개발자별 가시성을 확보하는 방법을 소개합니다.

모두가 놓치는 단 하나의 필드

OpenRouter에 채팅 완성(chat completion)을 보낼 때, 응답 본문(response body)은 실제로 어떤 모델이 답변했는지 알려줍니다. 설령 openrouter/auto를 요청했더라도, 응답의 model 필드는 결정된(resolved) 모델, 즉 라우터가 선택한 anthropic/claude-3.5-sonnet, google/gemini-flash-1.5 등을 나타냅니다.

{
  "id": "gen-abc123",
  "model": "anthropic/claude-3.5-sonnet",
...

그 id가 바로 여러분이 붙잡아야 할 실마리입니다. OpenRouter는 모든 호출에 대한 권위 있는 기록을 반환하는 생성 조회(generation-lookup) 엔드포인트를 제공합니다. 여기에는 크레딧 기준의 네이티브 비용(native cost), 업스트림 제공자(upstream provider), 그리고 토큰 수(token counts)가 포함됩니다.

curl https://openrouter.ai/api/v1/generation?id=gen-abc123 \
  -H "Authorization: Bearer $OPENROUTER_API_KEY"

응답에는 total_cost, model, tokens_prompt, tokens_completion, 그리고 서비스를 제공한 제공자(provider)가 포함됩니다. 완성(completion) 응답은 모델 정보를 즉시 제공하며, 생성(generation) 엔드포인트는 호출이 반환된 직후 약간의 시차를 두고 정확한 비용 정보를 제공합니다(비용은 호출 반환 후 약간의 시간이 지나야 정산됩니다). 대부분의 모니터링을 위해서는 두 가지 모두가 필요합니다. 즉, 실시간 모델 정보와 약간의 지연을 둔 비용 정보입니다.

프록시가 아닌 폴링(Polling)

이를 캡처하는 데에는 두 가지 방법이 있습니다. 하나는 요청 경로(request path)에 위치하는 것입니다. 즉, 모든 호출을 가로채는 프록시(proxy)나 패치된 SDK(patched SDK)를 사용하는 방식입니다. 이 방법도 작동은 하지만, 이제 여러분은 지연 시간(latency)에 민감한 프롬프트 처리 인프라의 일부를 직접 관리해야 하며, 개발자와 모델 사이에 스스로를 위치시키게 됩니다. 만약 모니터링 시스템에 문제가 생기면, 개발자들의 에이전트(agent)도 함께 문제가 생깁니다.

다른 방법은 사후에, 즉 대역 외(out of band) 방식으로 사용량 데이터를 읽는 것입니다. OpenRouter에는 정해진 일정에 따라 폴링(polling)할 수 있는 활동 인터페이스가 있습니다:

# 계정 수준의 크레딧 + 사용량 스냅샷
curl https://openrouter.ai/api/v1/credits \
  -H "Authorization: Bearer $OPENROUTER_API_KEY"

일정한 간격으로 이를 폴링하고, 연속된 스냅샷 간의 차이(diff)를 구하면, 실행 경로(hot path)에 직접 개입하지 않고도 지출 속도(spend velocity)를 파악할 수 있습니다. 여기에는 솔직한 트레이드오프(tradeoff)가 존재합니다. 폴링은 밀리초(sub-second) 단위가 아닌 실시간에 가까운(near-realtime) 정보를 제공하며, 데이터의 최신성을 약간 희생하는 대신 모니터링 대상의 의존성(dependency)이 되지 않을 수 있습니다. 속도 제한(rate limiting)과 같은 기능이 아닌 비용 모니터링의 목적이라면, 거의 모든 경우에 이것이 올바른 선택입니다.

개발자별 지출 귀속시키기

단일 조직(org) 키는 조직이 돈을 썼다는 사실은 알려주지만, 누가 썼는지는 알려주지 않습니다. 깔끔한 해결책은 개발자(또는 에이전트)당 하나의 OpenRouter 키를 생성하고 각각 태그를 지정하는 것입니다. OpenRouter는 여러 개의 키를 생성할 수 있도록 허용하므로, 사람별로 키를 발급하고 매핑 정보를 유지하세요:

KEY_OWNERS = {
    "sk-or-v1-aaa...": "ravi",
    "sk-or-v1-bbb...": "dana",
...

이제 각 키의 사용량을 폴링하고 소유자와 결정된 모델(resolved model) 모두를 기준으로 버킷(bucket)화합니다. 최소한의 애그리게이터(aggregator) 예시는 다음과 같습니다:

import requests, collections

def snapshot(key):
...

각 폴링 결과에 타임스탬프(timestamp)를 붙여 저장하면 개발자별, 시간 범위별 차이(delta)를 계산할 수 있습니다. 이를 완료 응답(completion responses)에서 캡처한 호출당 model 정보와 결합하면, 마침내 여러분이 실제로 원했던 테이블을 얻을 수 있습니다. 즉, 각 개인(또는 에이전트)이 얼마를 썼는지, 그리고 auto가 그들을 위해 어떤 모델을 선택했는지에 따라 분류된 데이터를 얻게 됩니다.

데이터를 트리와이어(tripwire)로 전환하기

아무도 열어보지 않는 대시보드는 새벽 2시에 폭주하는 에이전트(runaway agent)를 잡아낼 수 없습니다. 당신에게 필요한 것은 당신에게 페이지(page, 알림)를 보내는 임계값(threshold)입니다. 작동하는 가장 저렴한 버전은 다음과 같습니다: 각 개발자의 이동 평균 일일 지출액(rolling daily spend)을 계산한 다음, 해당 개발자의 평균값에 표준편차 3배(three standard deviations)를 더한 값을 초과하는 날을 플래그(flag)로 표시하는 것입니다.

import statistics

def is_anomaly(history, today):
...

전체적인 하나의 수치보다 개발자별 기준선(baseline)이 더 중요합니다. 하루 종일 프롬프트(prompt)를 미세 조정(fine-tuning)하는 엔지니어는 정당하게 높은 기준선을 가집니다. 반면 평소에 2달러를 쓰다가 갑자기 80달러를 쓰는 팀원이 당신이 찾아야 할 실제 신호(signal)입니다. 전역 임계값(global threshold)을 사용하면 두 번째 사례가 첫 번째 사례에 묻혀버립니다. 이상 징후가 나타난 당일에 Slack 메시지를 보내도록 체크 로직을 연결하세요. 월말에나 알게 되는 급증(spike)은 그저 비싼 역사 수업일 뿐입니다.

전체적인 구조

종합하면, 패턴은 다음과 같습니다: 실시간 모델별 귀속(attribution)을 위해 각 완료 응답(completion response)에서 결정된 model을 읽고, 권위 있는 비용 산출을 위해 사용량(usage) 및 생성(generation) 엔드포인트(endpoint)를 대역 외(out of band) 방식으로 폴링(poll)하며, 귀속을 위해 개발자별로 키(key)를 지정하고, 스냅샷을 저장하며, 당일에 알림을 주는 개인별 평균+3σ(mean-plus-3σ) 체크를 실행하는 것입니다. 프록시(proxy)도, 프롬프트 접근도 필요 없으며, 누구의 크리티컬 패스(critical path)에도 지연 시간(latency)을 추가하지 않습니다. 읽기 전용 키(read-only key)와 크론 잡(cron job)만으로도 대부분의 목표를 진정으로 달성할 수 있습니다.

만약 폴러(poller), 키별 배관 작업(plumbing), 그리고 기준선 수학 계산을 직접 유지 관리하고 싶지 않다면, 그것이 바로 저희 Reckon에서 구축하고 있는 기능입니다. 읽기 전용 사용량 API 폴링(프록시 없음, SDK 없음, 프롬프트를 절대 볼 수 없음), KMS 암호화된 키, 그리고 이제는 모델별 실시간 OpenRouter 추적 기능을 제공합니다. 따라서 openrouter/auto 및 OpenClaw 실행 결과가 발생하는 즉시 모델별 및 개발자별로 나타나며, Slack 요약, 당일 이상 징후 알림, /spend 명령어 및 Linear 연동을 지원합니다. 최대 3명의 개발자까지 무료입니다. (공지: 저는 Reckon에서 일합니다.) 하지만 위 기능 중 무엇도 저희가 반드시 필요한 것은 아닙니다. 엔드포인트는 바로 거기에 있으며, 주말 정도면 직접 연결하기에 충분합니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0