에이전트 비용은 걸음 수보다 빨리 늘어난다

지난 글에서 사람을 어디에 붙일지 정했다면, 그다음에 거의 반드시 오는 질문이 비용이다. 에이전트를 시범 운영으로 돌릴 때는 신경 쓸 일이 없다가, 하루 수천 건이 되는 순간 청구서가 예상의 세 배로 온다.

세 배가 되는 이유는 단가가 오른 것도 트래픽이 는 것도 아니다. 한 작업이 쓰는 토큰이 걸음 수에 비례하지 않기 때문이다.

걸음이 두 배면 비용은 네 배에 가깝다

에이전트 루프는 걸음마다 앞의 도구 결과를 문맥에 남긴 채로 모델을 다시 부른다. 그래서 걸음이 늘수록 한 걸음의 입력 자체가 길어진다.

첫 걸음의 입력이 $c$ 이고 걸음마다 도구 결과가 $d$ 만큼 붙는다면, $n$번째 걸음의 입력은 $c + (n-1)d$ 다. 작업 하나의 입력 토큰 총합은 그것들의 합이므로

$\sum_{k=1}^{n} \bigl(c + (k-1)d\bigr) = nc + \frac{n(n-1)}{2}d$

가 된다. 뒤쪽 항이 $n^2$ 에 비례하므로, 걸음이 5에서 10으로 두 배가 되면 총 입력은 두 배가 아니라 세 배에서 네 배로 뛴다. 도구 결과가 클수록($d$가 클수록) 이 효과가 심해진다.

실무에서 이게 왜 중요하냐면, 비용을 예측할 때 사람들이 거의 항상 작업당 평균 걸음 수로 계산하기 때문이다. 평균이 6걸음이어도 꼬리에 20걸음짜리가 5%만 섞여 있으면 그 5%가 전체 비용의 3할을 먹는다. 평균이 아니라 분포를 봐야 한다.

어디서 새는가

새는 자리는 대체로 정해져 있고, 큰 것부터 순서가 있다.

새는 자리	증상	대응
도구 결과를 통째로 넣음	한 걸음 입력이 갑자기 몇 만 토큰	필요한 필드만 남기고 잘라서 넣는다
앞 걸음을 계속 이고 감	걸음이 늘수록 입력이 선형으로 증가	오래된 걸음은 요약으로 접는다
시스템 프롬프트가 캐시를 못 탐	매 호출 입력이 전액 과금	앞부분을 고정해 캐시 경계를 만든다
실패하고 재시도	걸음 수는 같은데 호출 수만 늘어남	재시도 상한과 백오프, 실패 원인 고치기
끝났는데 안 멈춤	걸음 수 분포의 오른쪽 꼬리	종료 조건과 걸음 상한
큰 모델로 다 처리	전 구간 단가가 같음	판단이 쉬운 걸음은 작은 모델로

위에서 셋이 대체로 전체의 8할이다. 나머지를 먼저 손대는 것은 순서가 틀린 것이다.

도구 결과 자르기가 가장 효과가 크고 가장 자주 빠진다. 검색 API가 문서 20건을 본문까지 통째로 돌려주는데 그걸 그대로 문맥에 넣으면 한 걸음에 3만 토큰이 들어가고, 그게 이후 모든 걸음에 계속 남는다. 도구 쪽에서 요약·필드 선택·건수 제한을 걸어 두면 한 번의 수정으로 작업 전체 비용이 절반이 된다.

프롬프트 캐싱은 손이 가장 덜 가는 대응이다. 프롬프트 캐싱에서 다뤘듯 앞부분이 바이트 단위로 같아야 캐시가 걸리므로, 시스템 프롬프트와 도구 정의를 맨 앞에 고정으로 두고 그 뒤에만 변하는 것을 붙인다. 에이전트 루프는 같은 앞부분을 걸음마다 다시 보내는 구조라 캐시가 가장 잘 듣는 형태다.

문맥 접기는 문맥 압축과 요약 기억에서 다룬 것을 그대로 쓴다. 다만 에이전트에서는 접는 기준이 조금 다르다 — 오래됐다고 접는 것이 아니라 이후 걸음에서 참조되지 않는 것을 접는다. 세 걸음 전의 검색 결과는 이미 결론이 났으면 결론 한 줄만 남기면 된다.

상한은 세 겹으로 건다

줄이는 것과 별개로 터졌을 때 어디서 막을 것인가를 정해 둬야 한다. 한 겹만 걸면 반드시 어긋난다.

걸음 상한은 도구 결과 크기에 건다. 넘으면 자르고 계속 간다. 작업을 멈추지 않는 것이 핵심이다 — 조회 결과가 크다고 여섯 시간짜리 작업이 죽으면 안 된다.

작업 상한은 걸음 수와 총 토큰에 건다. 넘으면 지난 글에서 다룬 상태 저장을 하고 그 작업만 멈춘다. 여기서 흔한 실수는 상한을 걸음 수에만 거는 것이다. 걸음 수는 20인데 도구가 매번 큰 결과를 물어 오면 토큰은 걸음 100개짜리가 될 수 있다. 둘 다 건다.

하루 상한은 테넌트와 서비스 전체에 건다. 넘으면 새 작업을 안 받되 돌던 것은 마저 끝낸다. 돌던 것까지 죽이면 이미 쓴 비용이 그냥 버려진다.

세 겹이 필요한 이유는 각각이 다른 사고를 막기 때문이다. 걸음 상한은 조회 하나가 문맥을 터뜨리는 것을, 작업 상한은 하나가 무한히 도는 것을, 하루 상한은 여러 작업이 동시에 조금씩 새는 것을 막는다. 마지막은 앞의 둘로는 절대 안 잡힌다.

재시도가 생각보다 크다

비용 분석을 해 보면 예상보다 큰 조각이 재시도다. 도구가 실패하고 다시 부르는 동안 모델 호출은 매번 새로 일어나고 그때마다 전체 문맥이 다시 들어간다. 실패한 걸음이 세 번 반복되면 그 걸음 하나가 세 걸음 값이다.

그래서 재시도에는 셋을 둔다.

• 횟수 상한 — 같은 도구가 같은 오류로 세 번 실패하면 재시도가 아니라 보고다
• 재시도 대상 구분 — 시간 초과나 일시적 오류만 다시 한다. 인자가 틀려서 난 오류는 다시 해도 같다
• 문맥 절약 — 재시도 때는 실패 이유만 붙이고 실패한 응답 전문을 문맥에 남기지 않는다

셋째가 특히 효과가 좋다. 도구 오류 메시지가 스택 트레이스 통째로 문맥에 들어가서 그 뒤 모든 걸음이 비싸지는 경우가 흔하다.

모델을 걸음마다 다르게

같은 루프 안에서도 걸음의 난이도는 다르다. 「이 결과가 질문에 답이 되는가」를 판단하는 걸음과 「최종 보고서를 쓰는」 걸음이 같은 모델일 이유가 없다.

라우팅과 캐스케이드에서 다룬 방식이 그대로 적용되는데, 에이전트에서는 나누는 선이 조금 더 뚜렷하다.

• 작은 모델로 충분한 것 — 분류, 형식 변환, 「끝났는가」 판단, 짧은 요약
• 큰 모델이 필요한 것 — 계획 세우기, 여러 근거를 엮는 판단, 최종 산출물

다만 이걸 하기 전에 위의 도구 결과 자르기와 캐싱을 먼저 한다. 모델을 바꾸는 것은 품질에 영향을 주므로 재는 일이 따라붙지만, 앞의 둘은 품질을 거의 안 건드리면서 비용만 줄인다.

재기 전에는 줄이지 않는다

마지막으로 순서 이야기다. 비용 이야기가 나오면 곧장 최적화로 뛰어들기 쉬운데, 그 전에 작업 하나가 얼마인지를 알아야 한다.

최소한 이 넷은 작업마다 기록한다. 입력·출력 토큰, 걸음 수, 캐시 적중 토큰, 사용한 모델. LLM 비용 추적에서 다룬 것과 같은 구조이고, 에이전트에서는 여기에 걸음별 분해가 하나 더 붙어야 한다. 작업 총액만 있으면 어느 걸음이 비싼지 모르기 때문이다.

이 기록이 있으면 비싼 작업 열 개를 뽑아 보는 것만으로 새는 자리가 대개 눈에 보인다. 위 표의 대응 중 무엇을 먼저 할지도 그 열 개가 정해 준다.

정리

• 걸음이 두 배면 총 입력은 두 배가 아니라 서너 배다. 앞 걸음이 문맥에 계속 남기 때문이다
• 평균 걸음 수로 비용을 예측하면 틀린다. 꼬리의 긴 작업이 전체의 상당 부분을 먹는다
• 도구 결과 자르기·프롬프트 캐싱·문맥 접기 셋이 대체로 절감의 8할이다
• 도구 쪽에서 결과를 줄이는 것이 가장 싸고 가장 자주 빠진다
• 에이전트 루프는 같은 앞부분을 반복해 보내므로 캐싱이 가장 잘 듣는 형태다
• 상한은 걸음·작업·하루 세 겹으로 건다. 각각 다른 사고를 막는다
• 작업 상한은 걸음 수와 토큰에 둘 다 건다. 걸음 수만 걸면 큰 결과가 새는 것을 못 잡는다
• 재시도는 문맥 전체를 다시 태운다. 횟수 상한, 재시도 대상 구분, 실패 응답 전문 배제
• 판단이 쉬운 걸음은 작은 모델로 내린다. 다만 캐싱과 자르기를 먼저 한다
• 작업당 토큰·걸음·캐시 적중·모델을 걸음별로 기록하기 전에는 최적화를 시작하지 않는다

---

읽어주셔서 감사합니다. 😊