AI 에이전트 워크플로우에서 발생하는 예상치 못한 비용 급증은 어떻게 디버깅하시나요?

내가 제일 먼저 보는 건 전체 비용이 아니라 단계별 토큰 수임. 비용이 2배로 튀면 거의 항상 특정 노드 하나가 평소보다 훨씬 긴 입력을 받기 시작한 게 원인임. 컨텍스트가 누적해서 전달되는데 아무도 눈치 못 챘거나, 이전 단계에서 너무 긴 출력을 내보내서 그게 다음 단계로 넘어간 경우지. 로그는 무슨 일이 일어났는지만 알려주지만, traces는 어디서 일어났는지 알려줌. traces 안 쓰면 그냥 블랙박스 안에서 이진 탐색하는 거나 다름없음. LangSmith도 괜찮긴 한데...

비용 급증은 보통 특정 단계에서 루프가 돌거나 예상보다 훨씬 많은 컨텍스트를 가져올 때 발생함. 그래서 가장 빨리 찾는 방법은 트레이스에서 단계별 토큰 사용량을 확인하는 거임. 스팬별로 비용을 쪼개보면 어떤 툴 호출이나 리트리벌에서 비용이 폭증했는지 바로 보임. 단계별 토큰 사용량을 시간에 따라 추적하면, 나중에 전체 비용만 보고 멍하니 있는 대신, 특정 노드에서 튀는 스파이크를 통해 루프가 도는 걸 바로 잡아낼 수 있음.

저번에 사무실에서 갑자기 비용이 2배 뛴 적 있는데, 리트리버가 S3 버킷의 훨씬 큰 덩어리를 조용히 재인덱싱하고 있었음. 첫 번째 단서는 챗 컴플리션이 아니라 트레이스 내의 임베딩 호출 스파이크였음. 어제 벡터 검색 로그랑 지난주 로그를 Honeycomb이랑 LangSmith 익스포트로 비교해 보니까 10분 만에 원인을 찾음. 이제는 재무팀에서 먼저 연락 오기 전에 Grafana로 인덱스 크기 차이랑 토큰 할당량을 추적함.

가장 먼저 확인하는 건 워크플로우가 바뀌었는지, 아니면 같은 워크플로우가 다른 경로를 타고 있는지야. 재시도 루프, 추가적인 툴 호출, 혹은 라우팅 변경 때문에 아무도 모르게 비용이 두 배로 뛸 수 있거든. Braintrust가 트레이스를 나란히 놓고 비교할 때 유용한데, 그런 차이점들이 보통 금방 눈에 띄거든.

실행 중 컨텍스트 누적(context accumulation)은 다들 얘기하는 거긴 한데, 나를 당황하게 만든 건 실행 간에 발생하는 중복 작업이었음. 내 에이전트들은 아무것도 바뀐 게 없는데도 실행할 때마다 똑같은 사전 검사 파일들을 다시 읽고 있었거든. 파일들은 거의 정적이었는데(음성 규칙, 메모리 상태 등), 에이전트는 그걸 몰라서 매번 다시 읽은 거지. 실행당 토큰 예산의 대략 40%가 이미 지난번에 처리했던 파일들을 읽는 데 쓰이고 있었음. 다른 거 보다가 우연히 발견함. 이게 나를...