모델·일자·프로젝트별 사용량 대시보드 구축기

사용량 대시보드를 새로 만들면서 모델별/일자별/프로젝트별 집계 뷰를 한 번에 볼 수 있게 정리했다. 초기 사용량 추적 기능이 있었지만, 실제 운영팀과 개발팀이 쓸 만한 수준의 대시보드가 없었거든.

왜 이 작업이 필요했나

처음엔 간단한 로깅만 있었다. 매일 사용량이 누적되고 있는데, 막상 "지난 주에 어떤 모델을 가장 많이 썼지?", "프로젝트 A의 비용 추이는?", "오늘 사용량이 평소보다 많나?" 같은 질문에 답할 수 없었다. 로그 테이블을 직접 쿼리해야 했고, 비개발자들은 접근 자체가 불가능했다.

특히 팀 운영 관점에서 보면, 각 프로젝트별 리소스 할당과 비용 최적화를 논할 때 정량적 근거가 전혀 없었다. "이 모델 쓰는 게 효율적인가?", "우리가 실제로 프리미엄 모델에 투자할 만한 가치가 있나?" 같은 의사결정을 할 수 없었고, 결국 추측으로만 움직이고 있었다.

대시보드의 세 가지 축

세 가지 다른 관점에서 데이터를 볼 수 있게 설계했다:

• 모델별 조회 — 어떤 모델(Claude 3.5 Sonnet, Haiku 등)을 가장 많이 쓰는지, 각 모델의 토큰 사용량 분포
• 일자별 추이 — 시간이 흐르면서 사용량이 어떻게 변하는지, 트렌드 감지 (갑자기 튀는 날이 있으면 원인을 찾게 됨)
• 프로젝트별 현황 — 어느 팀/프로젝트가 가장 많이 쓰는지, 리소스 할당의 근거

이 셋을 동시에 제공하려면 백엔드 집계 로직뿐 아니라 프론트엔드 UI 도 신경 써야 했다. 너무 많은 정보를 한 화면에 때려 박으면 오히려 읽기 힘들어지니까.

파일 구조와 책임 분리

초반에는 모든 로직을 한 파일에 집어넣고 싶은 유혹이 있었다. "어차피 대시보드인데, 작은 기능 아닌가" 하면서. 하지만 팀에서 나중에 이 대시보드를 확장하거나 수정할 때 필요한 것들을 고려했다. 타입 정의를 따로 빼면 다른 팀원이 API 응답을 추가할 때 헤맬 일이 줄어든다. 포맷팅 로직을 분리하면 테스트도 쉽고, 기획팀의 "천 단위 표시 방식 바꿔 줄 수 있나?" 같은 요청에 대응하기도 간단하다.

회고: 일관된 명칭과 초기 설계의 중요성

이 작업을 진행하면서 배운 게 하나 있다면, 처음부터 데이터 포맷과 용어를 정확히 정의해야 한다는 것이다. 예를 들어 "사용량"이 "토큰 수"인지 "API 호출 횟수"인지 "비용"인지 명확히 해야 한다. 중간에 정의를 바꾸면 기존 집계 로직과 UI가 모두 영향을 받는다.

또 하나는 초기 단순함과 확장성의 균형이다. 사용량 추적은 앞으로 더 복잡할 가능성이 높다. 이번엔 모델/일자/프로젝트 세 축이지만, 나중엔 사용자별, 요청 타입별 등 더 세분화된 분석이 필요할 수 있다. 그래서 타입과 포맷팅을 별도로 분리하고, 컴포넌트 구조도 탭으로 확장하기 좋게 만들었다.

코드리뷰할 때도 이 부분을 중점적으로 봤다. 다른 팀원이 나중에 "새로운 뷰를 추가하고 싶은데" 하면 기존 구조를 최대한 안 건드리게 하려고.

운영 관점의 임팩트

대시보드가 나가고 나니 달라진 게 있다. 회의에서 "어제 사용량 어땠어?" 하는 질문에 스크린셰어로 바로 답할 수 있게 됐다. 시계열 그래프를 보면서 "아, 목요일마다 튀네?" 같은 패턴도 눈에 띈다 (아마도 배치 작업이 도는 날일 거다). 그러면 그 원인을 파고들 수 있고, 필요하면 최적화 작업의 우선순위를 정할 수 있게 된다.

팀 입장에서도 좋았다. 기존엔 사용량 데이터가 "블랙박스" 같았는데, 이제 투명하게 공개되니까 각 팀이 자신들의 리소스 사용을 인식하게 된다. 자연스럽게 효율성에 대한 관심이 생긴다.

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

• 모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

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