운영을 시작하면 곧 '비용이 왜 이렇게 늘었지?'와 '어느 customer가 만들었지?'라는 질문을 받게 돼. 답하려면 tenant별 ledger가 필요해. 호출마다 tenant_id, model, prompt_tokens, completion_tokens, reasoning_tokens, timestamp를 저장하고 일별·tenant별로 합산해.
전체 비용만으로는 원인을 알 수 없어
총합만 보면 특정 customer가 비용의 80%를 썼는지 알 수 없어. tenant별 breakdown이 없으면 청구액 원인을 추측하게 돼. 호출 시점에 기록하는 건 저렴하지만 지나간 세부값을 나중에 되살릴 수는 없어.
rate limit header로 동시 요청 수를 조절해
응답마다 x-ratelimit-remaining-requests를 읽어. 20% 아래면 동시 요청 수를 절반으로 줄이고 80% 위로 회복하면 늘려. 429에 부딪힌 뒤가 아니라 남은 양을 보고 먼저 움직여.
tenant별 예산 상한을 둬
ledger가 있으면 customer별 월 예산을 적용해 한도를 넘는 호출을 거부하거나 더 저렴한 모델로 내릴 수 있어. 상한이 없으면 한 customer의 버그가 전체 비용을 키울 수 있어.