월 고정 요금을 내는 사용자에게 "이번 달 한도를 초과했습니다"라는 메시지를 보내는 순간, 그 사용자의 절반은 떠납니다. B2B SaaS를 운영하면서 저도 이 문제를 직접 겪었습니다. 토큰 예산 관리를 어떻게 설계하느냐가 곧 서비스의 신뢰도와 수익성을 동시에 결정짓는다는 걸 알게 된 건 솔직히 꽤 늦은 편이었습니다.
요청 횟수로 제한하면 안 되는 이유
"월 100회 요청 제한"이 합리적이라고 생각하는 분들도 있는데, 저는 이 방식이 근본적으로 잘못됐다고 봅니다. 직접 써봤을 때 문제가 너무 명확했습니다.
짧은 질문 100번과 긴 계약서 분석 100번은 API 비용 기준으로 수십 배 차이가 납니다. 그런데 요청 횟수로만 관리하면 이 둘이 똑같이 취급됩니다. 라이트 유저는 한도가 너무 넉넉해서 비용 대비 낭비가 발생하고, 헤비 유저는 너무 빠듯해서 불만이 쌓입니다. 결국 어느 쪽도 만족시키지 못하는 구조가 됩니다.
제가 전환한 방식은 토큰(Token) 기반 예산입니다. 여기서 토큰이란 LLM이 텍스트를 처리하는 최소 단위로, 영어 기준으로 단어 하나가 대략 1~1.5개 토큰에 해당하고 한국어는 더 높은 비율로 토큰이 소비됩니다. 베타 사용자 100명의 실제 사용 데이터를 분석한 결과, 중앙값 사용자는 월 약 35만 토큰을 쓰고 상위 5% 헤비 유저는 200만 토큰을 훌쩍 넘겼습니다. 이 분포를 기준으로 Free 플랜은 월 50만 토큰, Pro 플랜은 500만 토큰으로 설정했습니다.
한 가지 더 중요한 점은, 토큰 예산을 단순히 입력+출력 토큰 합산으로 관리하면 안 된다는 겁니다. Opus 모델의 입력 토큰 단가는 Haiku 대비 20배 수준입니다. 같은 50만 토큰이라도 어떤 모델을 쓰느냐에 따라 실제 과금 금액이 완전히 달라집니다. 이 문제를 해결하기 위해 저는 내부적으로 Credit Unit(크레딧 유닛)이라는 환산 레이어를 도입했습니다. 쉽게 말해 모델별 단가 비율을 반영한 가중치를 토큰에 곱해서 비용 기준으로 통일된 예산 단위를 만드는 방식입니다.
Redis 슬라이딩 윈도우로 예산을 추적하는 법
분산 서버 환경에서 토큰 예산을 정확하게 추적하는 건 생각보다 까다롭습니다. 일반적으로 DB에 사용량을 기록하면 된다고 알려져 있지만, 실제로 써보니 동시 요청이 몰릴 때 레이스 컨디션(Race Condition) 문제가 발생했습니다. 레이스 컨디션이란 여러 프로세스가 동시에 같은 데이터를 읽고 쓰면서 결과가 꼬이는 현상으로, 예산 초과 상태에서도 요청이 통과되는 치명적인 버그로 이어집니다.
이를 해결한 방법이 Redis 기반 슬라이딩 윈도우(Sliding Window) 알고리즘입니다. 슬라이딩 윈도우란 고정된 월 초기화 방식 대신 현재 시점에서 과거 30일을 기준으로 사용량을 계산하는 방식으로, 월말에 몰아서 쓰거나 월초에 초기화되는 문제를 방지합니다. 사용자 ID를 Redis 키로, 남은 예산을 값으로 저장하고, API 호출 전에 잔액을 확인한 뒤 호출 후 실제 사용량을 차감합니다. Redis의 원자적 연산(INCR/DECR)은 동시 요청이 수백 개 들어와도 예산 추적이 정확하게 유지되도록 보장합니다.
플랜별 예산 관리에서 핵심 포인트를 정리하면 다음과 같습니다.
- Free 플랜: 월 50만 Credit Unit, 70%/90%/100% 도달 시 이메일+인앱 알림
- Pro 플랜: 월 500만 Credit Unit, 100% 도달 시 즉시 차단 대신 저속 모드 전환
- Enterprise: 계약 기준 커스텀 한도 설정, 90% 도달 시 고객사 관리자 알림, 자동 갱신 없음
Enterprise 정책에서 자동 갱신을 막은 건 처음에 고민이 많았습니다. 하지만 예상치 못한 대규모 청구서를 받은 고객이 한 명만 나와도 계약이 끊기는 걸 봤기 때문에, 투명한 예산 통제가 장기 신뢰 관계에 훨씬 중요하다는 판단을 내렸습니다.
모델 라우팅으로 비용을 60% 줄이는 방법
모델 라우팅(Model Routing)은 예산 관리와 뗄 수 없는 주제입니다. 모델 라우팅이란 요청의 복잡도나 성격에 따라 자동으로 적합한 모델을 선택해 호출하는 로직으로, 동일한 사용자 경험을 유지하면서 인프라 비용을 크게 낮출 수 있습니다.
저는 요청 분류 기준을 크게 세 가지로 나눴습니다. 단순 분류나 짧은 요약처럼 패턴이 명확한 요청은 Haiku로, 중간 복잡도의 분석이나 초안 작성은 Sonnet으로, 복잡한 추론이나 긴 문서 처리가 필요한 경우에만 Opus로 라우팅합니다. 실제 운영 데이터 기준으로 전체 요청의 약 65%가 Haiku 처리 대상이었고, Opus로 올라가는 건 10% 미만이었습니다. 이 구조 하나만으로 월 인프라 비용이 직전 대비 절반 이하로 줄었습니다.
Claude Code 엔터프라이즈 배포 사례를 보면, 개발자 1인당 활성 날짜 기준 평균 비용이 약 13달러, 월간으로는 150~250달러 수준으로 집계됩니다(출처: Anthropic). 전체 사용자의 90%는 활성 날 하루 30달러 미만을 소비한다는 분포를 보면, 소수의 헤비 유저가 비용 구조를 왜곡한다는 점을 알 수 있습니다. 모델 라우팅은 바로 이 상위 사용자들의 고비용 요청을 효율적으로 처리하는 데 핵심적인 역할을 합니다.
일반적으로 Pro 플랜 이상 사용자는 무제한에 가깝게 Opus를 써도 된다는 시각도 있는데, 개인적으로는 이건 위험한 접근이라고 생각합니다. 반복적인 단순 작업을 Haiku로 처리하도록 설계해도 사용자가 체감하는 품질 차이는 거의 없으면서, 서비스 제공자 입장에서는 비용 구조가 훨씬 안정적으로 유지됩니다.
예산 소진 경고를 UX로 풀어야 하는 이유
토큰 예산 관리의 가장 큰 딜레마는 공정성과 예측 가능성 사이의 긴장입니다. 사용자는 정액 요금을 내고 얼마나 쓸 수 있는지 명확히 알고 싶어 합니다. 그런데 LLM 비용은 모델 선택, 컨텍스트 길이, 출력 길이에 따라 요청마다 완전히 다릅니다. 이 불확실성을 단순한 월 X토큰 숫자 하나로 해결하려는 건 사실 무리가 있습니다.
제가 선택한 해법은 '저속 모드(Slow Mode)'였습니다. 예산 100% 도달 시 즉시 차단 대신, 모든 요청을 Haiku로만 처리하고 max_tokens(최대 출력 토큰 수)를 절반으로 줄이는 방식입니다. max_tokens란 API 응답에서 생성할 수 있는 최대 토큰 수를 제한하는 파라미터로, 이 값을 낮추면 같은 예산으로 더 많은 요청을 처리할 수 있습니다. 사용자 입장에서는 서비스가 갑자기 멈추지 않고 속도나 응답 품질이 살짝 낮아지는 느낌만 받게 됩니다.
클라우드 비용 최적화 분야 연구에 따르면, LLM API 비용에서 모델 선택과 출력 토큰 제어만으로도 전체 비용의 60% 이상을 절감할 수 있다는 결과가 보고되고 있습니다(출처: Sitepoint). 저는 여기서 한 발 더 나아가, 단순 차단 대신 스마트 가이드 UX가 필요하다는 생각을 갖게 됐습니다. 예산 소진 전에 사용자의 작업 패턴을 분석해 "남은 예산으로 완료할 수 있는 작업 유형"을 제안하거나, 효율적인 사용 방법을 안내하는 방식입니다. 지금 운영 중인 서비스에 이 기능을 붙인 이후 예산 소진 후 이탈률이 눈에 띄게 줄었습니다.
토큰 예산은 비용 통제 수단이기 이전에 사용자 경험을 설계하는 도구입니다. 이 관점의 전환 하나가 제 서비스 운영 방식을 완전히 바꿔놓았습니다.
처음 요청 횟수 제한을 도입했다가 실패하고, 토큰 기반으로 전환하고, 저속 모드를 붙이기까지 꽤 긴 시간이 걸렸습니다. 직접 겪으면서 배운 가장 큰 교훈은, 예산 설계는 결국 사용자와의 신뢰 계약이라는 점입니다. 어떤 모델을 쓰고 어떤 임계치를 설정할지는 기술 문제이지만, 그 경험을 어떻게 전달할지는 서비스 철학의 문제입니다. 지금 SaaS에 LLM을 붙이고 있다면, 예산 설계 단계에서 이 두 가지를 함께 고민해보시길 권합니다.
참고:
- Anthropic Claude Code Cost Management: https://code.claude.com/docs/en/costs
- Claude API Token Optimization - 60% Cost Reduction (Sitepoint, 2026): https://www.sitepoint.com/claude-api-token-optimization/
- Building Production Apps with Claude API (Medium, 2025): https://medium.com/@reliabledataengineering/building-production-apps-with-claude-api
- Anthropic API Pricing Guide 2026: https://www.finout.io/blog/anthropic-api-pricing