AI 에이전트 운영비용, 1시간 점검으로 새는 토큰 비용 잡는 법

콘솔을 열고 지난달 API 호출 로그를 내려받았다. 합계 칸을 보는 순간 숫자가 이상했어요 — 재시도로 찍힌 호출이 전체의 3분의 1을 넘었거든요. Databricks가 자사 AI 에이전트 운영비를 딱 1시간 점검해 연간 100만 달러 규모 낭비를 찾아냈다는 사례(출처: Databricks 공식 블로그)를 읽고 나서 벼르던 일이었습니다. 이 글을 따라 하면 여러분 팀의 AI 에이전트 파이프라인에서도 토큰 비용이 어디서 새는지 직접 확인하고, 오늘 안에 최소 하나는 고칠 수 있게 됩니다. 거창한 도구는 필요 없어요. 로그 파일과 스프레드시트, 그리고 한 시간이면 충분하더라고요.

점검 전에 무엇을 준비해야 할까요?

준비물은 단출합니다. 첫째, 최근 2~4주치 API 호출 로그입니다 — 타임스탬프·토큰 수·응답 상태 코드가 찍힌 형태면 충분해요. 둘째, 에이전트가 쓰는 재시도 설정 파일이 필요하죠. 셋째, 실제 프롬프트 템플릿 원본도 챙겨야 합니다. 넷째, 숫자를 굴려볼 스프레드시트나 노트북 하나면 됩니다. 유료 API를 쓴다면 요금과 한도는 공식 페이지에서 직접 확인하는 편이 안전해요. 가격 정책은 자주 바뀌니까요. 저는 판다스로 로그를 불러와 groupby로 몇 줄 돌리는 정도로 시작했습니다.

토큰 낭비는 어디서 새는 걸까요?

토큰 낭비는 대개 세 군데에서 생깁니다. 재시도, 과도한 컨텍스트, 중복 호출이에요. 하나씩 로그를 훑으며 순서대로 확인해볼게요.

1단계: 재시도 로그부터 훑어보기

먼저 상태 코드별로 호출 건수를 집계합니다. 이렇게 입력하면 → df.groupby('status_code').size()를 돌리면 → 429(rate limit)와 timeout이 합쳐서 전체 호출의 22%를 차지한다는 결과가 나왔어요. 우리 파이프라인은 실패 시 지수 백오프 없이 즉시 3회 재시도하도록 짜여 있었는데, 그 즉시 재시도가 같은 컨텍스트를 통째로 다시 태우고 있었습니다. 재시도 자체는 필요하죠. 문제는 재시도할 때마다 처음부터 전체 프롬프트를 다시 보낸다는 점이었어요. 재시도 로직에 지수 백오프와 캐시된 부분 응답 재사용을 넣는 것만으로 그 22% 중 상당 부분을 줄일 수 있었습니다.

2단계: 컨텍스트 크기 점검하기

다음은 요청별 입력 토큰 수 분포를 봅니다. 이렇게 입력하면 → 요청 토큰 수를 히스토그램으로 그리면 → 상위 10% 요청이 전체 입력 토큰의 절반 가까이를 먹고 있다는 그림이 나오더라고요. 원인을 파보니 대화 이력 전체를 매번 통째로 붙여 보내고 있었습니다. 저는 최근 6턴만 남기고 그 이전은 요약본으로 대체하도록 바꿨어요. 바꾸고 나서 같은 작업 기준으로 평균 입력 토큰이 눈에 띄게 줄었습니다. 정확한 절감폭은 팀마다 다르겠지만, 대화 이력을 무한정 누적하는 구조라면 한번 확인해볼 가치가 있어요.

3단계: 중복 호출 패턴 찾기

세 번째는 같은 입력으로 같은 모델을 반복 호출하는 패턴을 찾는 것입니다. 이렇게 입력하면 → 프롬프트 해시값 기준으로 중복 건수를 세면 → 우리 경우엔 검색 도구 호출 하나가 같은 쿼리로 하루에 여러 번 반복되고 있었어요. 캐시 없이 매번 실시간 호출하도록 짜여 있었기 때문이죠. 결과가 바뀔 일이 거의 없는 조회성 호출에 짧은 캐시 계층 하나만 얹었더니 해당 도구 호출 횟수가 확연히 줄었습니다. 캐시 유효기간은 데이터 갱신 주기에 맞춰 짧게 잡는 게 안전해요.

점검하다 흔히 하는 실수는 무엇일까요?

토큰 비용을 점검하면서 세 번 정도 삽질했습니다. 첫째, 로그 타임존을 안 맞춰서 시간대별 트래픽 분석이 통째로 틀어졌어요 — 이거 바로잡느라 30분을 그냥 날렸습니다. 둘째, 재시도 횟수를 무작정 1회로 줄였다가 정상 요청까지 실패 처리되는 바람에 하루치 작업 큐가 밀렸어요. 재시도는 없애는 게 아니라 똑똑하게 만드는 게 맞더라고요. 셋째, 캐시를 걸면서 유효기간을 너무 길게 잡아 하루 지난 데이터를 최신인 것처럼 보여준 적도 있습니다. 캐시는 편하지만 신선도를 놓치면 다른 종류의 비용, 그러니까 신뢰도 손실을 치르게 되죠.

지금 당장 할 수 있는 것

점검을 마치고 나서 든 생각은 하나예요. 토큰 비용은 모델을 바꾼다고 줄어드는 게 아니라, 같은 요청을 몇 번 반복해서 보내고 있는지를 세어봐야 줄어듭니다. 지금 로그 파일 하나만 열어서 상태 코드별 집계 한 줄만 돌려봐도 AI 에이전트 파이프라인 어디가 새는지 감이 옵니다. 오늘 그 한 줄부터 시작해보길 권해요.

자주 묻는 질문

Q. 재시도 백오프는 몇 초부터 시작하면 되나요? A. 절대적인 정답은 없지만 저는 1초에서 시작해 실패할 때마다 2배씩 늘리고 최대 3회로 제한했습니다. 서비스 특성에 따라 조정이 필요해요.

Q. 대화 이력 요약은 어떤 방식으로 했나요? A. 오래된 턴을 별도 요약 프롬프트로 압축해 저장하고, 새 요청 시 요약본과 최근 6턴만 붙였습니다. 요약 생성에도 토큰이 들기 때문에 요약 주기를 너무 짧게 잡지 않는 게 좋아요.

Q. 캐시 유효기간은 어떻게 정해야 하나요? A. 데이터가 얼마나 자주 바뀌는지에 따라 다릅니다. 저는 하루에 한 번 바뀌는 데이터에는 1시간, 실시간성이 중요한 데이터에는 캐시를 아예 걸지 않았어요.

Q. 이 점검을 소규모 팀도 할 수 있나요? A. 가능합니다. 로그 export 기능만 있으면 스프레드시트로도 상태 코드 집계와 토큰 분포 확인 정도는 충분히 할 수 있어요.