운영 환경에서 LLM 기능에 문제가 발생했을 때, 가장 먼저 필요한 것은 '해당 요청으로 실제로 무슨 일이 일어났는지'입니다. 애플리케이션 측의 로그만으로는 요청을 보냈다는 것과 응답을 받았다는 것밖에 알 수 없습니다. 재시도(Retry), 폴백(Fallback), 지연 시간(Latency) 내역은 요청 경로 중간에 있는 게이트웨이만이 보고 있습니다.
nRouter는 모든 호출에 하나의 요청 ID를 발행하고, 응답 헤더로 반환합니다. 이 동일한 헤더에는 해당 요청의 비용과 실제로 응답한 모델도 포함됩니다. 애플리케이션 측에서 이 ID를 자체 상관관계 ID(Correlation ID)와 함께 기록해 둔다면, 나중에 그 ID로 요청 로그를 열어 라우팅, 폴백 시도, 제공업체와의 왕복, 결제까지의 타임라인을 확인할 수 있습니다.
유용한 로그 항목은 모델, 제공업체, 상태(Status), 지연 시간, 토큰 수, 비용을 한 줄에 요약한 것입니다. nRouter의 요청 로그는 요청 ID, 모델, 제공업체, 상태, 키, 팀, 시간을 기준으로 검색 및 필터링이 가능합니다. 성공한 요청뿐만 아니라, 속도 제한(Rate Limit), 캐시 히트(Cache Hit), 가드레일(Guardrail)에 의한 차단도 이유와 함께 동일한 스트림에 기록됩니다. 차단된 요청이 이유와 함께 남아 있는지 여부에 따라 조사 시간이 크게 달라집니다.
스트리밍의 경우, 총 시간만으로는 경험을 표현할 수 없습니다. 첫 토큰까지 걸린 시간(TTFT: Time To First Token)과 총 시간을 분리하여 기록함으로써, '표시가 시작되기까지 느린지' 아니면 '생성 전체 과정이 느린지'를 구별할 수 있습니다. nRouter는 이 두 가지를 나누어 추적하며, 모델, 키, 팀, 조직별로 백분위수(p50, p95, p99, 최대값)를 보고합니다.
비용은 게이트웨이에서 한 번만 계산하고, 그 동일한 값을 요청 로그, 크레딧 장부(Credit Ledger), CSV 내보내기, 분석에 사용하는 것이 원칙입니다. 가격 책정이 불가능한 응답은 '미가격(Unpriced)'으로 플래그가 지정되며, 0으로 기록되지 않습니다. 0이라고 기재하는 것은 주장이며, 잘못된 0은 하위 모든 보고서를 망가뜨립니다.
로그에 저장되는 것은 메타데이터만이며, 프롬프트와 응답 본문은 저장되지 않습니다. 이 경계 덕분에 동일한 기록을 장애 대응, 지출 대조(Expense Reconciliation), 정책 변경 감사에 사용할 수 있습니다. 감사 추적(Audit Trail)은 요청 로그보다 더 오래 보관됩니다.
하나의 ID, 사실만을 요약한 한 줄, 첫 토큰으로 분리된 지연 시간, 단 한 번 계산되는 비용, 그리고 본문이 아닌 메타데이터. 자세한 내용은 nRouter의 관찰 가능성(Observability) 페이지에 정리되어 있습니다. 자체 스택에서 '지난주 화요일의 그 요청'을 보여줄 수 있는지 비교해 볼 가치가 있습니다.