문제해결·AI운영·비용관리

AI 사용량을 운영 지표로 만들기 위해 관측 기준을 다시 세운 과정

서로 다른 범위를 보던 메트릭과 로그를 맞추고, 비용·좌석 운영에 쓸 수 있는 집계 기준과 자동화 경계를 정리한 과정이다.

문제
서로 다른 범위를 집계하던 메트릭과 로그를 바로잡아 예산과 좌석 운영에 쓸 수 있는 관측 기준을 만들어야 했다.
선택
사용량은 소비와 비용을 판단하는 지표로 한정하고, 집계와 추천만 자동화하며 실제 운영 변경은 사람이 결정하도록 구분했다.
결과
재현 가능한 관측 기준과 자동화 경계는 정리했지만, 자동화 구축과 좌석·한도 기준 확정은 남아 있다.

AI 도구의 사용량을 예산과 좌석 운영에 활용해야 했지만, 그 숫자를 성과로 해석해서는 안 됐다. 수집된 비용 값은 실제 결제액이 아니라 API 단가로 환산한 소비 지표였다. 사용자별 로그도 전수를 오래 보관하는 구조가 아니었다. 관측은 유지하되 쓰임을 비용 운영에 한정하고, 자동으로 처리할 부분과 사람이 판단할 부분을 나눠야 했다.

초기 분석에서는 실제 누락도 확인했다. 한 실행 환경만 골라 사용자별 로그를 집계한 탓에 같은 도구를 다른 두 환경에서 쓴 기록이 빠졌다. 총량 메트릭에는 세 환경이 모두 포함돼 사용자별 분석과 전체 사용량이 서로 다른 범위를 보고 있었다.

실제로 맡은 문제

예산을 잡고 유료 좌석을 조정하려면 누가 어느 정도 쓰는지 알아야 했다. 사용량이 많다는 사실만으로 업무 성과가 높다고 말할 근거는 없었다. 하루치 값도 좌석을 바꾸는 기준으로 쓰기 어려웠다. 실제 측정에서는 같은 사용자가 하루 차이로 낮은 등급과 높은 등급을 오갔다. 일부 팀은 원격 측정이 연결되지 않아 관측 밖에 있었다.

확인한 사실과 제약

두 데이터 소스의 역할은 달랐다. 메트릭은 전체 비용과 토큰 총량을 안정적으로 보여주지만 사용자 정보가 없었다. 로그에는 사용자, 요청, 모델, 세션 정보가 있었으나 한 번에 가져올 수 있는 건수가 제한되고 보존 기간도 짧았다. 사용자별 비용은 여러 시간대의 로그 표본으로 점유율을 구한 뒤 전체 메트릭에 대입해야 했다. 전수 집계는 아니었다.

좌석에 포함된 실제 사용 한도 역시 공개된 고정값이 아니었다. 사용자가 한도에 도달한 시점과 그때까지의 누적 소비를 함께 기록해야 추정할 수 있었다. 이 보정값 없이는 추가 크레딧 예산을 확정하기 어려웠다.

내가 한 선택

관측 문서에서 사용량은 성과 평가가 아닌 소비 지표로 다뤘다. 일 총량은 메트릭을 기준으로 삼고 사용자별 비중은 로그 표본으로 나눴다. 좌석 등급은 하루치 값 대신 최근 여러 주의 근무일 평균으로 계산하는 안을 남겼다.

자동화 범위도 구분했다. 반복 집계, 이상 징후 알림, 좌석 조정 추천표 작성까지는 자동화 대상으로 뒀다. 좌석 변경, 개인 한도 조정, 추가 크레딧 승인처럼 사람에게 직접 영향을 주는 실행은 수동 결정으로 남겼다.

실제로 한 일

두 데이터 소스의 역할과 한계를 나누고 재현 절차를 문서화했다. 전체 일 사용량을 구하는 방법부터 로그 표본의 사용자 점유율 계산, 월 소비량 환산 기준까지 한 흐름으로 정리했다. 긴 컨텍스트 요청, 특정 모델 편중, 세션별 소비처럼 비용이 커지는 원인을 확인할 항목도 구분했다.

초기 누락 사례를 반영해 사용자별 로그 집계에서는 특정 실행 환경 필터를 걸지 않도록 명시했다. 로그가 오래 남지 않으므로 주간 집계를 따로 저장해야 한다고 기록했다. 조회 상한에 걸린 표본은 시간 창을 줄이거나 여러 구간의 평균을 내도록 했다.

확인된 결과와 남은 일

사용량을 다시 계산할 절차와 해석 범위는 정리됐다. 전체 소비량, 사용자별 추정 비중, 비용이 커지는 사용 패턴을 같은 기준으로 확인할 수 있게 됐다. 사용량이 업무 성과를 증명한다는 주장은 이 결과에 넣지 않았다.

구축과 운영 결정은 아직 남아 있다. 자동 대시보드와 알림에는 쓰기 권한이 필요하고, 주간 리포트와 좌석 추천표도 설계 단계다. 누가 크레딧을 승인할지, 어느 기간을 보고 좌석을 낮출지, 개인별 사용량을 누구에게 공개할지도 정해지지 않았다. 성과와 검증량을 어떤 지표로 볼지 역시 열린 문제다.