여러 AI 코딩 도구 사용량을 통합 집계하는 멀티 프로바이더 추적 구현

여러 AI 코드 작성 도구를 함께 쓰는 팀이 생기면서, 사용 현황을 한 곳에서 추적해야 하는 상황이 생겼다. 기존에는 한 종류의 로그만 읽고 있었는데, 이제 다중 제공자(multi-provider)의 사용량을 함께 스캔하고 통합하는 기능을 만들었다.

멀티 프로바이더 추적이 필요해진 배경

개발팀이 성장하면서 도구 스택도 다양해진다. 초기에는 한 가지 AI 어시스턴트만 썼을 때는 사용량 집계가 간단했다. 하지만 프로젝트 특성에 따라 다른 도구를 병행하거나, 팀원마다 선호하는 도구가 다르면 상황이 복잡해진다. 특히 비용 청구/최적화 관점에서는 "전체 사용량이 어디서 발생하는가"를 정확히 파악해야 한다. 한 제공자의 로그만 보면 실제 소비 그림이 불완전하고, 팀이 낭비하고 있는 부분을 놓치기 쉬워진다.

이 작업은 단순히 기능 추가가 아니라, 팀의 도구 사용 투명성을 높이고 의사결정의 근거를 확보하는 것이었다.

구현 관점: 로그 수집과 비용 집계의 재설계

변경된 파일들을 보면 구조가 명확하다.

핵심은 usage-aggregate 계층에 있다. 각 제공자가 내보내는 로그 포맷이 제각각이라면, 중간에 정규화 계층이 필요하다. Codex의 로그와 Claude Code의 로그를 같은 구조로 변환한 후, 비용 집계 로직이 이를 일관되게 처리할 수 있도록 한 것이다.

Claude Code Log
  ↓
  ├─ [정규화] → { provider: 'claude', tokens: N, timestamp: T }
  │
Codex Log
  ↓
  ├─ [정규화] → { provider: 'codex', tokens: M, timestamp: T' }
  │
usage-aggregate → usage-cost (제공자별 단가 적용) → 최종 청구액

테스트와 비용 정책의 복잡성

비용 계산(usage-cost.test.ts)이 무시할 수 없는 부분이다. 각 AI 제공자마다 요금 정책이 다르기 때문이다.

• Claude: 입력/출력 토큰 가격 다름
• Codex: 모델 버전마다 가격 상이
• 양쪽 모두: 사용량 기준 티어/할인 적용될 수 있음

테스트에서는 단순히 "수치가 맞는가"만 검증하면 안 되고, "프로바이더 A의 로그를 잘못 읽어도 B의 로그 집계는 정확한가" 같은 격리 시나리오도 커버해야 한다. 한쪽 파서가 깨져도 다른 쪽 비용 추적이 계속되도록.

회고: 확장성과 운영 관점

이런 작업을 하면서 얻은 교훈:

1. 제공자 추상화의 중요성 — 세 번째, 네 번째 도구가 추가될 때 기존 코드를 얼마나 덜 건드릴 수 있을까. 초반부터 interface 기반 설계를 했으면 나중 온보딩이 훨씬 수월했을 것이다.

2. 로그 포맷 버전 관리 — AI 도구 제공자들도 API/로그 포맷을 업데이트한다. 어느 한쪽이 로그 구조를 바꾸면 우리 파서도 깨진다. 버전 감지 및 호환성 레이어를 미리 준비하는 게 좋다.

3. 팀 코뮤니케이션 — 개발팀에 "앞으로 누가 어떤 도구를 쓸 때 비용이 얼마나 드는지 추적된다"는 투명성이 있으면, 도구 선택이 더 신중해진다. 단순 기능이 아니라 조직 문화에도 영향을 준다.

비용/사용량 추적은 초기에는 간단해 보이지만, 팀이 성장하고 도구가 다양해질수록 핵심 도메인이 된다. 이번 멀티 프로바이더 지원이 그 첫 단계였다.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.