API 비용을 모델별·계정별로 한눈에 보기
목차
Claude API를 팀 단위로 쓰면서 가장 신경 쓰이는 게 비용 관리다. 이번에 계정별 사용량을 모델별로 분리해서 추적하고, Discord를 통해 자동으로 리포트하는 기능을 만들었다.
왜 필요했는가
API 기반 서비스를 운영하다 보면 비용이 빠르게 불어난다. 특히 Sonnet과 Opus 같은 서로 다른 모델을 섞어 쓸 때는 더 그렇다. Opus는 강력하지만 비싸고, Sonnet은 상대적으로 저렴하지만 성능 트레이드오프가 있다. 팀원 몇 명이 각각 다른 모델로 실험하고 있다면, 전체 사용량만 봐서는 "어느 계정이, 어느 모델로, 얼마나" 써고 있는지 파악이 어렵다.
여기에 활성계정 표시까지 추가하면 좋은 이유가 또 있다. 혹시 테스트용으로 만든 API 키를 누군가 깜빡하고 자동화 스크립트에 남겨두진 않았나, 업무상 쓰지 않는 옛날 계정이 여전히 요청을 보내고 있진 않나 하는 '좀비 계정' 추적이 가능해진다. 운영 관점에서는 이게 꽤 유용하다.
어떻게 구현했나
| 파일 | 역할 | 변화 |
|---|---|---|
scripts/claude-usage.py |
기본 사용량 수집 | 모델별 집계 추가, 활성계정 로직 |
scripts/claude-usage-discord.py |
Discord 리포트 자동화 | 모델별 분해 표시, 활성도 뱃지 |
두 개의 스크립트를 함께 수정했다는 건 중요한 포인트다. 기본 수집 로직과 리포트 로직을 분리하면, 나중에 Slack이나 다른 채널로도 쉽게 확장할 수 있다. 이게 단일 파일에서 처리했다면 나중에 리팩토링 비용이 컸을 텐데, 처음부터 '데이터 레이어'와 '표현 레이어'를 분리해 놨으니 유지보수성이 훨씬 낫다.
구체적으로는:
- 모델별 사용량 분리: API 응답에서 모델 정보를 추출해 Sonnet, Opus 등으로 분류하고, 각각의 입출력 토큰을 따로 집계
- 활성계정 플래그: 지난 기간(예: 지난 7일) 동안 최소 1회 이상 요청을 보낸 계정을 마크해두고, 장시간 미사용 계정과 구분
- Discord 메시지 포맷: 리포트를 읽기 쉽게 테이블 형식으로 정리하고, 활성계정에만 초록색 체크 이모지를 붙이기
📊 Claude API Usage Report (This Week)
─────────────────────────────────────
Account: team-prod
├─ Total: 2.5M tokens
├─ Sonnet: 1.8M tokens (72%)
├─ Opus: 0.7M tokens (28%)
└─ Status: ✅ Active
Account: dev-test
├─ Total: 150K tokens
├─ Sonnet: 150K tokens (100%)
├─ Opus: 0K tokens
└─ Status: ⏸️ Inactive
팀 관점에서 본 의미
이 변경이 단순 모니터링을 넘어 팀의 의사결정을 돕는다고 생각한다. 예를 들어, 이제 주간 회고에서 "이 주에 Opus 사용을 좀 줄여보면 어떨까?" 같은 구체적인 대화가 가능해진다. 단순히 "비용이 많이 든다"가 아니라, "우리 팀은 Sonnet으로도 충분한 작업이 이 정도 있고, 정말 Opus가 필요한 건 이 정도"라는 데이터 기반 논의가 생긴다.
또한 여러 계정을 관리하는 조직이라면, 활성도 표시가 "누군가 잊고 있는 리소스"를 발견하는 데 큰 도움이 된다. Discord 슬랙에 매주 자동으로 올라오니까 누군가는 반드시 본다. 그러다가 "어? 이 계정 또 활성화됐네?"라고 깨닫고 정리할 수 있다.
구현하며 고민한 것
가장 고민이 많았던 부분은 '활성계정의 정의'였다. "지난 7일 중 1회 이상"으로 할 것인가, "지난 30일"로 할 것인가. 너무 짧으면 일시적 비활성도 빨리 '비활성'으로 표시되어 혼동이 생기고, 너무 길면 실제로 죽은 계정을 놓칠 수 있다. 결국 조직 문화와 운영 사이클에 맞춰 결정해야 한다. 우리 팀은 주간 리포트이니 "지난 7일"이 적절했지만, 월간 리포트라면 다를 수 있다. 이런 식으로 설정을 외부화할 생각도 한다.
또 다른 고민은 두 스크립트를 얼마나 공유된 코드로 통합할 것인가다. DRY 원칙상 모델별 집계 로직은 한 번만 작성되어야 한다. 하지만 usage.py는 순수 데이터, usage-discord.py는 포맷팅이 섞여 있으니, 단순히 함수 호출로 연결할 수 없다. 결국 usage.py를 데이터 수집에 집중시키고, usage-discord.py에서 이를 import해서 쓰는 식으로 설계했다. 이게 각 스크립트의 책임을 명확하게 유지하면서도 코드 중복을 줄이는 균형이라고 본다.
다음을 위한 메모
이 기능이 정착되면, 다음 단계로는 히스토리 추적을 생각할 수 있다. "지난 한 달간 모델별 사용 트렌드는?"을 그래프로 보면 훨씬 강력한 인사이트가 나온다. 하지만 지금은 현재 데이터만 보고 있다. 이건 데이터 저장소(간단히는 CSV, 크면 DB) 추가 작업이 필요하니, 팀 모니터링 필요성이 더 높아질 때 우선순위 올리기로.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.