월 고정 요금을 내는 사용자에게 "이번 달 한도를 초과했습니다"라는 메시지를 보내는 순간, 그 사용자의 절반은 떠난다. B2B SaaS를 운영하면서 나도 이 문제를 직접 겪었다. 토큰 예산 관리를 어떻게 설계하느냐가 곧 서비스의 신뢰도와 수익성을 동시에 결정짓는다는 걸 알게 된 건 솔직히 꽤 늦은 편이었다.
플랜 설계 - 요청 횟수로 제한하면 안 되는 이유
"월 100회 요청 제한"이 합리적이라고 생각하는 사람들도 있는데, 나는 이 방식이 근본적으로 잘못됐다고 본다. 직접 써봤을 때 문제가 너무 명확했다.
짧은 질문 100번과 긴 계약서 분석 100번은 API 비용 기준으로 수십 배 차이가 난다. 그런데 요청 횟수로만 관리하면 이 둘이 똑같이 취급된다. 라이트 유저는 한도가 너무 넉넉해서 비용 대비 낭비가 발생하고, 헤비 유저는 너무 빠듯해서 불만이 쌓인다. 결국 어느 쪽도 만족시키지 못하는 구조가 된다. 놀랍게도 아직도 많은 서비스가 이 방식을 쓴다. 구현이 간단하기 때문이겠지만, 장기적으로는 비용 구조가 왜곡되고 사용자 불만이 누적된다. 나는 초기에 요청 횟수 제한으로 시작했다가 정확히 이 문제를 경험했고, 결국 전부 뜯어고쳤다.
내가 전환한 방식은 토큰 기반 예산이다. 토큰이란 LLM이 텍스트를 처리하는 최소 단위로, 영어 기준으로 단어 하나가 대략 1~1.5개 토큰에 해당하고 한국어는 더 높은 비율로 토큰이 소비된다. 베타 사용자 100명의 실제 사용 데이터를 분석한 결과, 중앙값 사용자는 월 약 35만 토큰을 쓰고 상위 5% 헤비 유저는 200만 토큰을 훌쩍 넘겼다. 이 분포를 기준으로 Free 플랜은 월 50만 토큰, Pro 플랜은 500만 토큰으로 설정했다. 데이터 없이 감으로 이 수치를 정했다면 틀렸을 가능성이 높다. 실제 사용 패턴은 예상보다 훨씬 편향된 분포를 보였다.
한 가지 더 중요한 점은, 토큰 예산을 단순히 입력+출력 토큰 합산으로 관리하면 안 된다는 것이다. Opus 모델의 입력 토큰 단가는 Haiku 대비 20배 수준이다. 같은 50만 토큰이라도 어떤 모델을 쓰느냐에 따라 실제 과금 금액이 완전히 달라진다. 이 문제를 해결하기 위해 내부적으로 Credit Unit이라는 환산 레이어를 도입했다. 모델별 단가 비율을 반영한 가중치를 토큰에 곱해서 비용 기준으로 통일된 예산 단위를 만드는 방식이다. 이 레이어 하나가 나중에 모델을 교체하거나 추가할 때 훨씬 유연한 구조를 만들어줬다. 처음에 이 레이어 없이 토큰 수만으로 관리했다가, 모델을 추가하면서 예산 계산식 전체를 갈아엎어야 했던 경험이 있다.
Redis 슬라이딩 윈도우로 예산을 추적하는 법
분산 서버 환경에서 토큰 예산을 정확하게 추적하는 건 생각보다 까다롭다. 일반적으로 DB에 사용량을 기록하면 된다고 알려져 있지만, 실제로 써보니 동시 요청이 몰릴 때 레이스 컨디션 문제가 발생했다. 레이스 컨디션이란 여러 프로세스가 동시에 같은 데이터를 읽고 쓰면서 결과가 꼬이는 현상으로, 예산 초과 상태에서도 요청이 통과되는 치명적인 버그로 이어진다. 실제로 이 버그가 발생해서 예산을 초과한 사용자가 계속 API를 쓰는 상황이 생긴 적이 있었다.
이를 해결한 방법이 Redis 기반 슬라이딩 윈도우 알고리즘이다. 슬라이딩 윈도우란 고정된 월 초기화 방식 대신 현재 시점에서 과거 30일을 기준으로 사용량을 계산하는 방식으로, 월말에 몰아서 쓰거나 월초에 초기화되는 문제를 방지한다. 사용자 ID를 Redis 키로, 남은 예산을 값으로 저장하고, API 호출 전에 잔액을 확인한 뒤 호출 후 실제 사용량을 차감한다. Redis의 원자적 연산은 동시 요청이 수백 개 들어와도 예산 추적이 정확하게 유지되도록 보장한다.
플랜별 예산 관리에서 핵심 포인트를 정리하면 다음과 같다. Free 플랜은 월 50만 Credit Unit으로 70%, 90%, 100% 도달 시 이메일과 인앱 알림을 보낸다. Pro 플랜은 월 500만 Credit Unit으로 100% 도달 시 즉시 차단 대신 저속 모드로 전환한다. Enterprise는 계약 기준 커스텀 한도를 설정하고 90% 도달 시 고객사 관리자에게 알림을 보내며, 자동 갱신은 없다.
Enterprise 정책에서 자동 갱신을 막은 건 처음에 고민이 많았다. 하지만 예상치 못한 대규모 청구서를 받은 고객이 한 명만 나와도 계약이 끊기는 걸 봤기 때문에, 투명한 예산 통제가 장기 신뢰 관계에 훨씬 중요하다는 판단을 내렸다. 단기적으로는 매출 기회를 놓치는 것처럼 느껴지지만, 장기적으로는 신뢰 자산이 된다. 이 결정을 내리기까지 팀 내에서 꽤 오랜 논쟁이 있었는데, 지금은 옳은 선택이었다고 확신한다.
모델 라우팅으로 비용을 줄이는 방법
모델 라우팅은 예산 관리와 뗄 수 없는 주제다. 모델 라우팅이란 요청의 복잡도나 성격에 따라 자동으로 적합한 모델을 선택해 호출하는 로직으로, 동일한 사용자 경험을 유지하면서 인프라 비용을 크게 낮출 수 있다.
요청 분류 기준을 크게 세 가지로 나눴다. 단순 분류나 짧은 요약처럼 패턴이 명확한 요청은 Haiku로, 중간 복잡도의 분석이나 초안 작성은 Sonnet으로, 복잡한 추론이나 긴 문서 처리가 필요한 경우에만 Opus로 라우팅한다. 실제 운영 데이터 기준으로 전체 요청의 약 65%가 Haiku 처리 대상이었고, Opus로 올라가는 건 10% 미만이었다. 이 구조 하나만으로 월 인프라 비용이 직전 대비 절반 이하로 줄었다.
Claude Code 엔터프라이즈 배포 사례를 보면, 개발자 1인당 활성 날짜 기준 평균 비용이 약 13달러, 월간으로는 150~250달러 수준으로 집계된다. 전체 사용자의 90%는 활성 날 하루 30달러 미만을 소비한다는 분포를 보면, 소수의 헤비 유저가 비용 구조를 왜곡한다는 점을 알 수 있다. 모델 라우팅은 바로 이 상위 사용자들의 고비용 요청을 효율적으로 처리하는 데 핵심적인 역할을 한다.
일반적으로 Pro 플랜 이상 사용자는 무제한에 가깝게 최상위 모델을 써도 된다는 시각도 있는데, 개인적으로는 이건 위험한 접근이라고 생각한다. 반복적인 단순 작업을 경량 모델로 처리하도록 설계해도 사용자가 체감하는 품질 차이는 거의 없으면서, 서비스 제공자 입장에서는 비용 구조가 훨씬 안정적으로 유지된다. 물론 라우팅 로직을 잘못 설계하면 단순한 질문이 최상위 모델로 가거나 복잡한 질문이 경량 모델로 내려가는 역방향 문제가 생길 수 있다. 라우팅 판단의 정확도를 주기적으로 검증하는 체계가 반드시 필요하다. 나는 처음에 이 검증 체계를 만들지 않았다가, 특정 유형의 요청이 계속 잘못된 모델로 라우팅되고 있었다는 걸 몇 주 뒤에야 발견했다.
예산 소진 경고를 UX로 풀어야 하는 이유
토큰 예산 관리의 가장 큰 딜레마는 공정성과 예측 가능성 사이의 긴장이다. 사용자는 정액 요금을 내고 얼마나 쓸 수 있는지 명확히 알고 싶어 한다. 그런데 LLM 비용은 모델 선택, 컨텍스트 길이, 출력 길이에 따라 요청마다 완전히 다르다. 이 불확실성을 단순한 월 X토큰 숫자 하나로 해결하려는 건 사실 무리가 있다.
내가 선택한 해법은 저속 모드였다. 예산 100% 도달 시 즉시 차단 대신, 모든 요청을 경량 모델로만 처리하고 최대 출력 토큰 수를 절반으로 줄이는 방식이다. max_tokens란 API 응답에서 생성할 수 있는 최대 토큰 수를 제한하는 파라미터로, 이 값을 낮추면 같은 예산으로 더 많은 요청을 처리할 수 있다. 사용자 입장에서는 서비스가 갑자기 멈추지 않고 속도나 응답 품질이 살짝 낮아지는 느낌만 받게 된다. 이 방식을 도입한 이후 예산 소진 후 즉시 이탈하는 사용자 비율이 눈에 띄게 줄었다.
클라우드 비용 최적화 분야 연구에 따르면, LLM API 비용에서 모델 선택과 출력 토큰 제어만으로도 전체 비용의 60% 이상을 절감할 수 있다는 결과가 보고되고 있다. 나는 여기서 한 발 더 나아가, 단순 차단 대신 스마트 가이드 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