에이전트가 크래시하면 로그에 남는다. 하지만 비용이 터질 때는 아무 알림도 없다. 청구서가 날아올 때까지.
dev.to에서 연재 중인 'Cost-audit series'의 저자는 AI 에이전트 하나가 하룻밤 사이 136M 토큰을 소각한 사건으로 시리즈를 시작했다. 에이전트는 크래시하지 않았다. 루프를 돌며 매 호출마다 정상적으로 응답을 받았고, 그 결과가 비용 명세서로 돌아왔다.
LangGraph 기본값이 숨긴 7배 승수
같은 시리즈 4화에서 분석된 LangGraph의 기본 상태 모델은 이 문제의 구조적 원인을 정확히 짚는다. LangGraph 공식 퀵스타트가 권장하는 MessagesState + add_messages 패턴의 실체는 append-only 리스트다. 대화 히스토리가 매 턴마다 누적되고, 상태를 읽는 모든 노드가 그 전체 리스트를 LLM에 전송한다.
수치로 보면 명확하다. 20턴 대화에서 나이브하게 추정하면 11,000 토큰이지만, add_messages 기본값을 그대로 쓰면 실제 입력 토큰은 77,500이다. 7배 차이. Claude Haiku 기준 하루 500개 대화, 한 달이면 $132 예상이 $930 실청구로 돌아온다. 월 $798의 침묵 과금이다.
여기서 멈추지 않는다. LangGraph의 장점인 멀티노드 그래프, human-in-the-loop 인터럽트, 병렬 팬아웃—이 세 가지 기능이 모두 동일한 승수로 작동한다. 3개 노드가 각각 state["messages"]를 읽으면 히스토리 토큰이 3배로 청구된다. 인터럽트 후 재개할 때마다 전체 체크포인트가 역직렬화되어 다시 주입된다. Send API로 3개 워커에 팬아웃하면 히스토리가 3벌 복사돼 각각 LLM 호출에 들어간다. 이건 버그가 아니다. 설계된 기본값이다.
에이전트 루프는 크래시보다 비싸다
별도의 오픈소스 프로젝트 SpendGuard(github.com/gommapane1/SpendGuard)가 등장한 배경도 같은 공포에서 출발한다. 저자는 에이전트가 동일한 프롬프트를 반복 전송하는 루프를 직접 경험했다. 개별 API 호출은 모두 정상이었고, 루프도 에러를 내지 않았다. 단지 돈이 빠져나갔다.
SpendGuard는 에이전트 앞단에 앉는 프록시다. 예산 캡을 설정해 스트림 중간에 차단하고, 동일 프롬프트 반복을 감지해 API 호출 전에 루프를 끊는다. 로컬 실행, 별도 가입 불필요. 이게 공개 라이브러리로 나왔다는 것 자체가, 이 문제가 특정 팀의 실수가 아니라 구조적으로 반복되는 패턴임을 방증한다.
99% 절감은 특수 사례가 아니다
Idyllic Services에서 실제 프로덕션 파이프라인을 재설계한 사례(dev.to/@rugvedrc)는 이 문제의 해법이 얼마나 구체적인지를 보여준다. 기존 파이프라인은 후보자 50명에 대해 LLM을 루프 안에서 50회 호출했다. 200,000 토큰, 6분 소요. 세 가지 변경으로 5,000 토큰, 90초로 줄였다.
첫째, RAG + 벡터 DB(Qdrant)로 전체 히스토리 대신 관련 스니펫 2~3개만 검색해 주입했다. 15,000 토큰짜리 컨텍스트가 400 토큰으로 줄었다. 둘째, 구조화된 데이터를 JSON 대신 TOON(Token-Oriented Object Notation) 포맷으로 전환했다. 키를 헤더 행으로 한 번만 선언하는 방식으로 동일 데이터를 847 토큰에서 290 토큰으로 압축했다. 셋째, 루프 안의 50번 LLM 호출을 단일 배치 프롬프트 1회로 교체했다.
이 세 가지는 모두 코드 레벨 변경이다. 모델 교체도, 인프라 교체도 아니다.
팀 리드 관점에서 실제로 짚어야 할 것
LangGraph가 trim_messages와 TypedDict 기반의 스코핑 옵션을 이미 제공한다는 점은 중요하다. 문제는 기본값이 아니라는 것이다. 공식 퀵스타트가 비용을 7배 부풀리는 패턴을 권장하는 상태에서, 팀이 그걸 그대로 프로덕션에 올리는 건 흔한 일이다.
내가 팀에 요구하는 체크포인트는 세 가지다. 첫째, 새 에이전트를 배포하기 전에 토큰 소비 시뮬레이션을 스펙 문서에 포함시켜라. 20턴 대화, 50개 입력, 3개 노드—이 정도 시나리오면 실제 비용 곡선을 미리 그릴 수 있다. 둘째, 프레임워크 기본값을 신뢰하지 마라. LangGraph든 LangChain이든, 공식 예제가 비용 최적화를 전제로 설계되지 않았을 수 있다. 셋째, 루프와 팬아웃은 항상 상한을 설계하라. SpendGuard 같은 프록시가 필요한 이유는 코드에 하드캡이 없기 때문이다.
전망: 비용 설계는 아키텍처 설계다
AI 에이전트의 비용 구조가 복잡해질수록, 이건 DevOps나 FinOps의 영역이 아니라 시스템 설계 단계의 결정이 된다. 어떤 노드가 전체 히스토리를 보는지, 어떤 경로에서 LLM 호출이 반복되는지, 어떤 데이터를 배치로 묶을 수 있는지—이 질문들은 코드를 다 짠 뒤에 최적화하는 것보다 설계 단계에서 결정할 때 비용이 훨씬 적다.
프레임워크는 편의를 위해 기본값을 제공한다. 그 기본값의 비용 구조를 이해하는 것은 우리 몫이다. 에이전트를 돌리기 전에 토큰 흐름을 그릴 수 없다면, 청구서가 그 그림을 대신 그려줄 것이다.