월간 27억 토큰을 처리한 LLM 라우팅 실운영 리포트 (1개월 회고)

지금까지 Zenn에서 두 개의 글을 공개했습니다.

첫 번째 글에서는 비용 비교를, 두 번째 글에서는 폴백(fallback) 메커니즘을 설명했습니다. 하지만 '실제로 계속 사용했을 때 어땠는지'에 대한 실운영의 생생한 목소리에는 충분히 다루지 못했습니다.

본 기사에서는 1개월간의 실운영 데이터를 바탕으로 회고를 전해드립니다.

현재 운영 구성은 다음과 같은 3단계 구조입니다.

┌─────────────────────────────────────────────┐
│ Layer 1: Z.AI Max (GLM-5.1) │
│ 월액: $160 사용량: Claude Pro의 약 60배 │
...

총 월액 **$180(약 28,000엔)**으로, Claude Code Max (20x)의 $220보다 저렴하면서도 사용량은 대폭 많은 구성입니다.

WSL2 Ubuntu상의 Claude Code CLI 환경에서 로컬 레이트 프록시를 거쳐 Z.AI API에 연결하고 있습니다.

Z.AI 대시보드에서 확인한 30일간의 실적입니다.

| 구성 | 월액 | 27.4억 토큰 처리 가능 여부 |
|---|---|
| Claude Code Max (20x) | $220 | ❌ 상한 도달 가능성 높음 |
| ... |
$180/월로 27억 토큰을 처리할 수 있다는 것은 멀티 프로바이더 구성만이 가능한 결과입니다.

체감상으로 볼 때, 대략 다음과 같은 비율로 분산됩니다.

| 레이어 | 비율 | 주요 용도 |
|---|---|
| Layer 1 (GLM-5.1) | 85% | 일반 개발・설계 판단・코드 생성 |
| ... |
GLM-5.1이 8~9할을 담당하고, MiniMax가 나머지를 커버합니다. Claude API는 안전망(safety net)으로 존재하는 정도일 뿐, 실제로는 거의 발동하지 않았습니다.

1개월간의 운영에서 마주친 트러블과 그 해결 방법을 정리했습니다.

가장 큰 인시던트는 Z.AI Max의 레이트 리밋 도달로 인한 약 3시간 동안의 완전 정지였습니다.

Z.AI Max 플랜의 제한은 '5시간 윈도우 1,600 프롬프트', '주간 8,000 프롬프트'입니다. 개발에 몰두하고 있으면, 특히 피크 시간대(JST 기준 15:00~19:00)에는 GLM-5.1이 평소의 3배 소비량이 되기 때문에 순식간에 상한에 도달합니다.

Claude Code CLI에는 API 레벨의 폴백 메커니즘이 없습니다. 429가 반환되면, 개발 플로우가 완전히 정지합니다.

대책: 로컬 레이트 프록시(glm-rate-proxy)를 개발하여 도입했습니다.

Claude Code → localhost:8787 (프록시) → Z.AI API / MiniMax API

이 프록시는 Z.AI 사용률에 따라 자동으로 모델을 전환합니다.

| 사용률 | 모드 | 모델 | 소비 |
|---|---|
| <80% | Normal | GLM-5.1 | 3배(피크) / 2배(오프피크) |
| ... |
사용률이 높아지면 자동으로 소비가 적은 모델로 전환하여, 429 도달을 미연에 방지합니다. 429가 발생하더라도 GLM-4.7-Flash (무료 구간) → MiniMax M2.7 순으로 폴백하기 때문에, 개발이 멈추는 일은 없었습니다.

결과: 프록시 도입 후, 429로 인한 정지는 제로입니다.

프록시는 Claude Code의 세션 시작 시에 훅 스크립트(hook script)로 구동하지만, 간혹 구동에 실패하는 경우가 있었습니다. 이 경우, ANTHROPIC_BASE_URL
이 localhost:8787
을 가리킨 채 프록시가 없기 때문에, 모든 통신이 실패합니다.

대책: 페일 세이프(fail-safe) 메커니즘을 구현했습니다.

• 프록시 구동 성공 →
  settings.json
  의 URL을 localhost:8787
  로 변경 - 프록시 구동 실패 →
  settings.json
  을 Z.AI 직결 URL 그대로 유지(변경하지 않음)

이를 통해 프록시가 구동되지 않아도 Z.AI에 직접 연결하여 계속 작동합니다.

LLM 라우팅과는 직접적인 관련은 없지만, 운영상 큰 과제였습니다.

7개의 MCP 서버가 제공하는 툴 정의가 대화 컨텍스트의 약 10%(21.4k 토큰)를 차지하고 있었습니다. 이로 인해 장시간 세션에서는 컨텍스트 부족에 빠지기 쉬워집니다.

대책: 사용 빈도가 낮은 MCP 서버(linear, sentry, supabase, tavily, stripe)를 삭제하여 6개 서버로 줄였습니다. 약 35k 토큰을 절약할 수 있었습니다.

또한, 설정 파일이 두 개(~/.claude.json와 ~/.claude/settings.json) 존재하며, 이 두 파일이 모두 병합되어 로드되는 것을 인지하지 못해 삭제가 반영되지 않는 트러블도 경험했습니다. Claude Code CLI의 claude mcp remove 명령어로 두 파일에서 일괄 삭제할 수 있으므로, 수동 편집보다는 CLI 사용을 추천합니다.

이 구성으로 1개월 동안 달성한 개발 성과입니다.

월 $180(약 28,000엔)로 이 정도의 개발 성과를 내고 있다는 것은 비용 대비 효과가 매우 높다고 판단합니다.

같은 작업을 Claude 공식 플랜으로 진행할 경우, Max(20x)인 $220만으로는 사용량이 부족할 수 있습니다. 종량제(従量課金)로 보완하면 월 $500~$1,000 이상이 드는 것도 드물지 않습니다.

개인 개발자에게 '아무리 써도 월정액 고정'이라는 안정감은 개발의 지속성과 직결됩니다. '비용을 신경 쓰느라 AI에 맡기는 것을 망설이는' 상황을 없애는 것이 가장 큰 효과였다고 느꼈습니다.

1개월 운영을 통해 파악한 과제와 향후 개선 예정입니다.

현재 프록시의 상태 확인은 수동(curl http://127.0.0.1:8787/proxy/status)으로 이루어지고 있습니다. 장기적으로는 자동적인 헬스 체크와 알림을 통합할 계획입니다.

Z.AI 대시보드에서 전체 사용량은 확인할 수 있지만, '어떤 프로젝트에서 얼마나 소비했는지' 내역은 파악하기 어렵습니다. 프로젝트별 사용량 트래킹을 도입하고 싶습니다.

현재 GLM이 타임아웃할 경우 MiniMax로 폴백(fallback)하고 있지만, '요약・테스트 생성・포맷 변환'과 같은 정형 처리의 경우 처음부터 MiniMax로 분배하는 것이 토큰 단가적으로 효율적입니다. 태스크의 성격에 따른 사전 라우팅 도입을 검토하고 있습니다.

1개월 동안 27억 토큰을 처리한 LLM 라우팅 실운영을 통해 다음 사항들을 알게 되었습니다.

• 멀티 프로바이더 구성은 유효: 단일 프로바이더의 429 오류나 장애에 강함 -
• 로컬 레이트 프록시가 핵심: 사용률에 따른 자동 모델 전환으로 429를 예방 -
• 월 $180로 충분한 개발 가능: 개인 개발 규모라면 공식 플랜보다 저렴하게 해결 가능 -
• 페일세이프 설계가 중요: 프록시가 고장 나도 직접 연결로 계속 작동하는 설계가 필수

'저렴한 LLM을 사용한다'는 단순한 비용 절감이 아닙니다. 멀티 프로바이더의 복원력(レジリエンス), 태스크별 최적화, 그리고 개발의 지속성이라는 관점에서 단일 프로바이더에는 없는 우위성이 있습니다.

• Claude Code CLI를 GLM (Z.AI)으로 대체한 이야기 (비용 대폭 절감 실측)
• Claude Code CLI에 MiniMax를 폴백(fallback)으로 결합한 이야기
• Claude Code의 기억을 Obsidian에서 SSOT화하는 설계

Z.AI (GLM)를 시험해 보고 싶은 분은 아래 소개 링크에서 등록할 수 있습니다.

소개 링크 경유로 등록하면 필자에게 보너스가 부여됩니다(사용자의 요금은 변동 없음)

MiniMax를 시험해 보고 싶은 분은 아래 소개 링크에서 등록할 수 있습니다. 소개 코드를 사용하면 10% 할인이 됩니다.

소개 링크 경유로 등록하면 사용자에게는 10% 할인, 필자에게 API 보너스가 부여됩니다.