LLM 청구서가 숨기고 있는 5가지 사실 (그리고 이를 찾아내는 방법)
요약
LLM 비용 급증 시 단순 모델별 총액이 아닌 기능 및 사용자 단위의 세부 분석이 필요함을 강조합니다. 비용을 유발하는 실제 기능과 수익성이 낮은 사용자를 식별하여 비즈니스 모델을 최적화하는 방법을 제시합니다.
핵심 포인트
- 모델 레벨이 아닌 기능 레벨의 비용 귀속(Feature Attribution)이 필수적임
- LLM 호출 시 기능 태그를 삽입하여 정확한 비용 발생 지점을 파악해야 함
- 사용자 및 플랜별 비용 분석을 통해 단위 경제성(Unit Economics)을 검토해야 함
- 고정 가격제 사용 시 헤비 유저로 인한 수익성 악화 위험을 경계해야 함
우리는 23일 만에 620달러에서 2,480달러로 비용이 급증했습니다.
새로운 기능이 출시된 것도 아니었습니다. 트래픽 급증도 없었습니다. 에러 알림도 제로였습니다. 배포 로그(Deployment logs)도 깨끗했습니다. 다섯 명의 엔지니어는 총액만 보여줄 뿐 그 외에는 아무것도 알려주지 않는 대시보드를 멍하니 바라보고 있었습니다.
우리가 가진 것은 영수증이었습니다. 우리에게 필요했던 것은 지도였습니다.
현재 여러분의 LLM 청구서 안에 숨겨져 있으며, 여러분의 모니터링 스택(monitoring stack)이 거의 확실히 보여주지 못하고 있는 다섯 가지를 소개합니다.
1. 어떤 기능이 실제로 비용을 유발하고 있는가
모든 제공업체의 대시보드는 모델 레벨(model level)의 총액을 보여줍니다. GPT-4o: $X. Claude: $Y.
그 숫자는 디버깅(debugging)에는 쓸모가 없습니다.
필요한 것은 기능 레벨의 귀속(feature level attribution)입니다. 어떤 제품 기능이 각 호출(call)을 트리거했는지를 알아야 합니다. 저희의 경우, 배치 보고서 생성기(batch report generator)가 전체 지출의 74%를 차지하고 있었습니다. 저희는 다른 두 기능이 비싸다고 '느껴졌기' 때문에 2주 연속으로 그 기능들을 최적화하고 있었습니다.
48시간 동안 수집된 실제 귀속 데이터는 다음과 같았습니다:
| 기능 | 월간 비용 | 점유율 |
|---|---|---|
| 배치 보고서 생성기 (Batch Report Generator) | $1,847 | 74% |
| ... |
저는 내내 잘못된 두 기능을 최적화하고 있었던 것입니다.
조치 사항: 사후 처리(post-processing)나 주간 보고서가 아니라, 호출이 발생하는 시점에 모든 LLM 호출에 기능 태그(feature tag)를 삽입(Instrument)하세요. 데이터는 요청을 트리거한 것이 무엇인지 포착할 때에만 의미를 갖습니다.
2. 어떤 사용자가 수익성이 없는가
이 문제는 처음에는 비용 문제처럼 느껴지지 않습니다. 나중에는 가격 책정(pricing) 문제로 느껴집니다.
기능 레벨의 귀속을 실행한 후, 이를 사용자 및 플랜 등급(plan tier)별로 집계했습니다. 그 결과는 저희의 비즈니스 운영 방식을 바꾸어 놓았습니다:
| 플랜 | 사용자당 월평균 서비스 비용 | 좌석당 MRR | 마진 |
|---|---|---|---|
| Starter | $3.20 | $49 | 93% ✓ |
| ... |
가장 활발한 사용자가 가장 수익성이 낮은 사용자였습니다.
단일 가격 정책(Flat pricing)은 이 문제를 14개월 동안 보이지 않게 만들었습니다. 사용자별 귀속(Per user attribution)은 48시간 만에 이 문제를 무시할 수 없게 만들었습니다.
우리는 Enterprise 요금제를 사용량 기반 (usage-based)으로 재산정했습니다. 고객들과의 그 논의는 어렵지 않았는데, 수치가 정확했기 때문입니다. 사용자당. 기능당. 월간. 논쟁의 여지가 없었습니다.
조치 사항: 기능 귀속 (feature attribution)이 작동하기 시작하면 사용자당 비용을 합산(Roll up)하세요. 단위 경제성 (unit economics)의 격차는 오직 그 계층에서만 가시화됩니다. 만약 고정 가격제 (flat pricing)를 사용 중인데 헤비 유저 (power users)가 동시에 가장 많은 LLM 사용자라면, 현재 가장 소중한 고객들에게 오히려 손해를 보고 있을 실질적인 가능성이 있습니다.
3. 어떤 서비스가 제공업체를 이중 호출(double-calling)하고 있는가
이 문제는 서비스 계층 (service layer)에서 추적하기 전까지는 보이지 않습니다.
우리의 문서 처리 서비스 (document-processing-service)는 컴플라이언스 (compliance) 호출을 수행하고 있었습니다. 우리의 컴플라이언스 서비스 (compliance-service) 또한 동일한 문서에 대해 하류 (downstream)에서 컴플라이언스 호출을 수행하고 있었습니다. 우리는 동일한 입력값에 대해 동일한 프롬프트 (prompt) 비용을 매번 두 번씩 지불하고 있었습니다.
사용자 측면의 증상은 전혀 없었습니다. 오류도 없었습니다. 알림도 없었습니다. 매달 180달러가 그냥 사라지고 있었습니다.
세 가지 차원이 중요합니다: 기능 (feature), 사용자 (user), 서비스 (service). 단일 차원만으로는 나머지 두 가지 버그를 놓치게 됩니다. 우리는 14개월 동안 하나의 차원만 가지고 있었고, 가시성 (visibility)을 확보했다고 생각했습니다.
조치 사항: 모든 호출에 기능 및 사용자와 함께 시작 서비스 이름 (originating service name)을 태그로 지정하세요. 비용을 서비스별로 분해하면, 개별적으로는 완전히 정상적으로 보이지만 시스템 수준에서는 중복인 겹치는 호출들을 발견하게 될 것입니다.
4. 오류율이 0%이지만 예산을 갉아먹고 있는 기능들
이것은 이 목록에서 가장 위험한 카테고리입니다.
오류가 발생하는 기능은 플래그 (flag)가 지정됩니다. 하지만 잘못된 트리거 (trigger)로 인해 너무 자주 성공하는 기능은 아무런 조치도 취해지지 않습니다.
우리의 컴플라이언스 체크 (compliance checker)는 모든 문서 저장 시 실행되었습니다. 자동 저장 간격: 30초. 엔터프라이즈 사용자 40명. 이는 시간당 4,800회의 GPT-4o 호출을 의미합니다. 매 업무 시간마다. 매 업무일마다.
응답 수준에서 아무런 문제가 없었기 때문에 알림이 울린 적은 한 번도 없었습니다. 모든 호출은 성공했습니다. 모든 로그는 깨끗해 보였습니다. 버그는 호출 자체가 아니라 트리거 설계에 있었습니다.
해결책: 준수 사항 확인(compliance check)을 수동 트리거 및 문서 제출 시에만 수행하도록 이동했습니다.
결과: 월 $1,890에서 $190로 감소했습니다. 단 한 줄의 코드였습니다. 삭제된 기능도, 다운그레이드된 모델도 없었습니다. 사용자 영향도 제로였습니다.
조치 사항: 호출당 비용(cost per call)뿐만 아니라 기능별 호출 빈도(call frequency per feature)를 살펴보세요. 평균 호출 비용이 $0.09인 기능이 하루에 2,000번 실행된다면, 이는 월 $5,400짜리 기능입니다. 이 수치는 개별 요청을 조사할 때는 나타나지 않으며, 시간이 지남에 따라 기능별로 비용을 합산(rolling up)할 때만 나타납니다.
5. 모니터링 스택이 도달하지 못하는 계층
이 부분은 우리가 이해하는 데 가장 오랜 시간이 걸렸습니다.
우리에게는 Datadog이 있었습니다. OpenAI 사용량 대시보드도 있었고, CloudWatch도 있었습니다. 이 모든 것들은 단 하나의 질문에만 답했습니다: '얼마인가?'
어떤 기능인지, 어떤 사용자인지, 어떤 서비스인지는 아무도 답해주지 않았습니다.
이것들은 완전히 다른 질문입니다. 인프라 모니터링(Infrastructure monitoring)은 인프라를 감시합니다. 요청이 성공했는지는 알 수 있습니다. 하지만 어떤 제품 기능이 이를 트리거했는지, 어떤 고객이 유발했는지, 또는 해당 성공이 귀사의 가격 책정(pricing)을 고려했을 때 수익성이 있는지에 대한 개념은 없습니다.
이 격차는 대시보드나 시각화의 문제가 아닙니다. 스택의 어느 지점에서 데이터가 캡처되느냐의 문제입니다. 애플리케이션 코드와 제공업체 API(provider API) 사이에 위치하여, 호출이 발생하는 순간 무엇이 이를 트리거했는지 태깅(tagging)하는 계측(instrumentation)이 필요합니다.
표준 모니터링 도구들은 해당 계층에 도달하지 못합니다. 이는 해당 도구들에 대한 비판이 아닙니다. 그 도구들은 그렇게 만들어지지 않았을 뿐입니다. 하지만 프로덕션 환경에서 LLM 기능을 실행하면서 인프라 모니터링에만 의존하고 있다면, 귀하는 마치 정상적으로 작동하는 것처럼 보이는 사각지대(blind spots)를 갖게 됩니다.
조치 사항: 스스로에게 한 가지 질문을 던져보세요. 다음 질문에 60초 이내로 답할 수 있습니까?
어떤 기능이 실행 비용이 가장 많이 들며, 어떤 사용자들에 의한 것이고, 그 수치가 현재의 가격 책정 하에서 귀사의 단위 경제성(unit economics) 측면에서 건강한 수치인가?
만약 답변의 어느 부분이라도 찾아내기 위해 파헤쳐야 한다면, 위험은 모니터링에 있는 것이 아닙니다. 바로 귀사의 모니터링이 도달하지 못하는 계층에 있습니다.
우리가 사용한 것
23일 동안 치솟는 청구서와 잘못된 추측과 씨름한 끝에, 한 팀원이 Slack에 CostReveal을 공유했습니다. 이 SDK는 기존의 프로바이더 (provider) 호출을 래핑(wrap)하여 모든 호출을 기능(feature), 서비스(service), 사용자(user)별로 태깅합니다. 하나의 대시보드에서 이 세 가지 차원을 모두 보여주며, 청구서가 도착하기 전에 작동하는 실시간 예산 알림 (budget alerts) 기능을 제공합니다.
설정에는 단 하룻밤이 걸렸습니다. 실제 데이터는 48시간 이내에 나타났습니다. 자동 저장 (autosave) 버그와 서비스 중복 호출 (double-calling) 버그 모두 계측 (instrumentation) 후 72시간 이내에 드러났습니다.
바로 설정을 시작하고 싶다면 docs.costreveal.com에서 문서를 확인하세요.
총 지출액은 영수증입니다. 기여도 분석 (Attribution)은 지도입니다.
우리는 지도를 얻기 전까지 14개월 동안 영수증만 가지고 있었습니다.
여러분도 이와 같은 조용한 비용 버그를 발견한 적이 있나요? 기능은 완벽하게 작동하지만, 알림 하나 없이 조용히 예산을 갉아먹고 있는 기능 말입니다. 댓글로 알려주세요. 이러한 패턴이 얼마나 흔한지 진심으로 궁금합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기