핸드오프가 한 작업을 15배 토큰 청구서로 바꿀 수 있다

핸드오프는 전문 에이전트가 작업을 이어받아야 할 때 유용합니다. 동시에 비용을 숨기기도 쉬워집니다. 청구량이 눈에 보이는 채팅 턴 하나가 아니라 그래프 노드 여러 곳에 나뉘어 쌓이기 때문입니다.

LangGraph 핸드오프에서 토큰이 왜 불어날까?

LangGraph 핸드오프에서 토큰이 불어나는 이유는 모델을 호출하는 각 노드가 지침, 이전 메시지, 검색 자료, 도구 반환값, 요약, 아티팩트를 다시 보낼 수 있고, 루프나 핸드오프가 다음 에이전트에서도 그 페이로드를 반복하기 때문입니다. 토큰 증폭은 한 트레이스 전체의 프롬프트와 완료 토큰 합계를 같은 작업의 더 단순한 기준선으로 나눈 값입니다. Anthropic은 2025년 6월, 멀티 에이전트 시스템이 채팅보다 약 15배 더 많은 토큰을 사용하면서 내부 리서치 평가 점수는 90.2% 높였다고 보고했습니다 .

빠른 답변: 각 에이전트가 좁게 정리된 작업 패킷 대신 복사된 컨텍스트를 받으면 핸드오프가 토큰 비용을 끌어올립니다. Anthropic의 2025년 6월 리서치 시스템은 이 트레이드오프를 분명히 보여줬습니다. 멀티 에이전트 실행은 채팅보다 약 15배 더 많은 토큰을 사용했지만, 내부 리서치 평가 점수는 90.2% 더 높았습니다 .

LangGraph에서 실제 문제는 그래프가 나쁘냐가 아니라 관측 가능성과 예산 관리입니다. LangGraph 프로젝트는 이 런타임을 지속성, 사람의 제어, 메모리, 디버깅 지원을 갖춘 상태 유지형 장기 실행 에이전트를 만드는 방법으로 설명합니다. 바로 그 특성 덕분에 추측에 의존하지 않고 컨텍스트가 어디서 커지는지 측정할 수 있습니다.

"멀티 에이전트 시스템은 개방형 리서치 작업에서 매우 효과적인 경우가 많지만, 토큰 사용량은 상당할 수 있습니다." — Anthropic 엔지니어링 팀

아래의 작은 검증 데모는 15배 청구가 어떻게 나오는지 산술로 보여줍니다. 5개 에이전트가 관련 컨텍스트 사본을 각각 3번 받으면 100토큰짜리 작업이 청구 기준 1,500토큰이 됩니다 .

"""작은 토큰 계산 데모: 핸드오프는 같은 작업 컨텍스트를 배수로 늘린다."""

task_tokens = 100
agents = 5
context_copies_per_handoff = 3  # 지침 + 작업 + 요약/히스토리

direct_bill = task_tokens
handoff_bill = task_tokens * agents * context_copies_per_handoff

print(f"직접 처리하는 단일 에이전트 작업: {direct_bill} tokens")
print(f"핸드오프 워크플로: {agents} agents x {context_copies_per_handoff} context copies x {task_tokens} tokens")
print(f"토큰 청구량: {handoff_bill} tokens ({handoff_bill / direct_bill:.0f}x)")

LangGraph 비용을 추적하기 전에 준비할 것

LangGraph 비용을 추적하기 전에, 해당 작업에 정말 그래프 형태의 조율이 필요한지 아니면 더 나은 도구를 갖춘 단일 에이전트로 충분한지 먼저 판단하세요. LangChain의 멀티 에이전트 가이드는 멀티 에이전트 시스템이 모델 호출과 토큰을 추가하며, 전문 핸드오프가 필요 없는 작업에서는 더 단순한 에이전트 설계가 비용 면에서 더 나은 경우가 많다고 경고합니다 .

그래프를 바꾸기 전에 LangSmith 트레이싱을 사용하세요. 하나의 트레이스 트리 안에서 각 LLM 호출, 프롬프트 포매팅 구간, 검색 단계, 도구 호출, 그래프 노드를 살펴볼 수 있어야 합니다 . 이런 구조가 없으면 “핸드오프는 비싸다”는 말이 너무 막연해서 고치기 어렵습니다.

제공자가 노출하는 곳에서는 사용량 메타데이터를 모두 수집하세요. 입력 토큰, 출력 토큰, 총 토큰, 모델 이름, 제공자 이름, 비용 필드가 여기에 포함됩니다. LangSmith의 LLM 트레이스 로깅 문서는 토큰 및 모델 계산을 위한 사용량 메타데이터 필드를 설명하고 , 비용 추적 문서는 트레이스 보기와 프로젝트 대시보드에서 토큰 및 비용 합계를 확인하는 방법을 보여줍니다 .

마지막으로 기준선을 만드세요. 같은 작업을 단일 에이전트 또는 라우터 전용 경로로 실행한 뒤, 전체 그래프 토큰을 그 기준선과 비교합니다. 원시 지출액은 청구 관리에 유용하고, 증폭률은 엔지니어링 의사결정에 유용합니다.

비용이 많이 드는 경로를 찾는 단계

비용이 많이 드는 LangGraph 핸드오프를 가장 빠르게 찾는 방법은 추적된 각 그래프 실행을 더 단순한 기준 경로와 비교한 뒤, 추가로 사용된 토큰을 특정 노드, 루프 턴, 핸드오프 경계에 귀속시키는 것입니다. LangSmith 트레이스는 워크플로를 실행 또는 스팬으로 표현하므로, 모델 호출, 검색 호출, 도구 호출, 프롬프트 포매팅 작업을 별도 단위로 점검할 수 있습니다 .

1. 먼저 같은 작업을 가장 단순하게 가능한 경로로 실행합니다. 단일 에이전트, 라우터만 있는 플로, 또는 수동으로 호출한 도구 경로가 될 수 있습니다. 총 토큰 수, 모델 호출 횟수, 최종 답변 길이, 답변이 작업 기준을 충족했는지를 기록합니다.
2. LangSmith 추적을 켠 상태로 LangGraph 버전을 실행합니다. 지출을 노드, 전환, 루프 반복, 핸드오프 출발점, 수신 서브그래프별로 묶습니다. LangSmith 비용 추적은 트레이스 트리, 프로젝트 통계, 대시보드에서 토큰 및 비용 합계를 보여줍니다 .
3. 실행을 비교하기 전에 안정적인 트레이스 태그를 추가합니다: graph_version, node_name, active_agent, handoff_source, handoff_destination, task_type, benchmark_case. LangSmith 사용자 지정 LLM 트레이스는 입력 토큰, 출력 토큰, 총 토큰, 토큰 세부 정보, 비용을 포함한 사용량 메타데이터를 기록할 수 있습니다 .
4. 총 그래프 토큰을 기준 경로 토큰으로 나누어 증폭률을 계산합니다. 그런 다음 총 그래프 토큰을 최종 전달 출력 토큰으로 나누어 전달 효율을 계산합니다. 첫 번째 비율은 오케스트레이션 오버헤드를 보여주고, 두 번째 비율은 눈에 보이는 답변 토큰 하나당 보이지 않는 조율에 얼마나 썼는지를 보여줍니다.
5. 추측하지 말고 공개된 패턴 데이터와 트레이스를 비교합니다. LangChain의 멀티 에이전트 가이드에 따르면 원샷 커피 작업은 서브에이전트를 쓰면 4번의 모델 호출을 사용하지만, 핸드오프, 스킬, 라우터를 쓰면 3번을 사용합니다. 또한 여러 도메인을 오가는 핸드오프는 대화 이력이 도메인 전반에 걸쳐 커질 때 14K 토큰을 넘을 수 있습니다 .

아래의 검증된 장난감 계산은 의도적으로 작게 만들었지만, 회계 구조는 잘 보여줍니다. 반복 핸드오프는 같은 작업 컨텍스트를 여러 번 복사할 수 있습니다.

"""작은 토큰 계산 데모: 핸드오프는 같은 작업 컨텍스트를 배수로 늘린다."""

task_tokens = 100
agents = 5
context_copies_per_handoff = 3  # instructions + task + summary/history

direct_bill = task_tokens
handoff_bill = task_tokens * agents * context_copies_per_handoff

print(f"직접 실행한 단일 에이전트 작업: {direct_bill} tokens")
print(f"핸드오프 워크플로: {agents} agents x {context_copies_per_handoff} context copies x {task_tokens} tokens")
print(f"토큰 비용: {handoff_bill} tokens ({handoff_bill / direct_bill:.0f}x)")

LangGraph 상태를 정리할 때 주의할 점

LangGraph 상태 정리는 메시지를 삭제, 축소, 요약하기 전에 단기 그래프 상태와 장기 저장 메모리를 구분할 때만 안전합니다. LangGraph의 메모리 가이드는 단기 메모리를 그래프를 따라 전달되는 상태로 다루고, 장기 메모리는 필요할 때 검색할 수 있는 저장소에 두는 것으로 설명합니다 .

첫 번째 함정은 제공자 메시지 이력을 유효하게 유지하는 데 필요한 텍스트까지 삭제하는 것입니다. 어시스턴트 메시지에 도구 호출이 포함되어 있다면, 그에 대응하는 도구 결과 메시지가 올바른 순서로 남아 있어야 합니다. 그렇지 않으면 다음 모델 호출이 실패하거나 다르게 동작할 수 있습니다. 예산은 문자 수나 메시지 수만이 아니라 모델이 실제로 받는 내용을 기준으로 잡도록 토큰 인식 방식의 trimming을 사용합니다.

두 번째 함정은 너무 일찍 요약하는 것입니다. 오래된 턴에는 압축된 요약이 유용하지만, 최근 의사결정 맥락, 활성 지시사항, 현재 아티팩트, 아직 해결되지 않은 도구 출력은 그대로 유지해야 합니다. 요약은 오래되어 부피만 큰 대화 내용을 대체해야지, 다음 노드가 도구를 선택하거나 다른 에이전트로 라우팅하거나 최종 답변을 만들기 위해 필요한 근거를 대체해서는 안 됩니다.

세 번째 함정은 모든 핸드오프를 전체 대화록 전달로 취급하는 것입니다. 서브그래프 핸드오프의 경우 LangChain의 핸드오프 가이드는 페이로드 선택을 명확히 합니다. 수신 에이전트가 전체 대화를 필요로 하지 않는다면, 트리거가 된 AIMessage, 대응하는 ToolMessage, 명확한 작업 설명, 선택된 아티팩트만 전달합니다 .

• 유지: 현재 사용자 목표, 활성 제약 조건, 해결되지 않은 도구 결과, 아티팩트 참조.
• 축소: 반복되는 채팅 이력, 오래된 scratchpad 텍스트, 장황한 검색 문서, 중간 작업자 대화.
• 이동: 지속적인 선호 사항, 재사용 가능한 사실, 프로젝트 메모리는 모든 노드를 거치며 복사하지 말고 장기 저장소로 옮깁니다.

트레이스가 깔끔해진 뒤의 다음 실험

깔끔한 LangGraph 트레이스는 실험의 출발점이지, 핸드오프를 유지할 가치가 있다는 증거는 아닙니다. 다음 단계는 같은 작업 세트, 토큰 예산, 성공 기준에서 더 저렴한 경로와 더 복잡한 경로를 비교하는 것입니다. Google은 2026년 1월, 180개 구성과 5개 아키텍처를 대상으로 한 실험에서 멀티 에이전트 조정이 병렬화 가능한 작업에는 도움이 됐지만 순차 작업에서는 성능을 떨어뜨렸다고 보고했습니다 .

• 병렬 브랜치가 단순히 트레이스 활동을 늘리는 데 그치지 않고, 가치 가중 작업 성공률을 높이는지 테스트하세요. Google은 중앙집중식 조정이 Finance-Agent 성능을 80.9% 개선한 반면, 멀티 에이전트 변형은 PlanCraft 성능을 39-70% 떨어뜨렸다고 밝혔습니다 .
• 고정 토큰 예산에서 단일 에이전트 기준선과 비교하세요. Tran과 Kiela의 2026년 프리프린트는 추가 테스트 시점 컴퓨팅을 통제하면 일부 멀티 에이전트 이득이 사라진다고 주장합니다 .
• 복사된 서브에이전트 transcript를 아티팩트 참조, 압축된 발견 사항, 구조화된 필드로 바꾸세요. Anthropic의 2025년 6월 연구 시스템 글은 서브에이전트가 결과를 외부 메모리에 기록해, 리드 에이전트가 모든 중간 세부사항을 채팅 기록에 싣지 않고도 조정할 수 있는 방식을 설명합니다 .

핸드오프 경로는 측정된 이득이 추가 토큰, 도구 호출, 재시도, 지연 시간을 정당화할 때만 승격하세요. Anthropic은 내부 멀티 에이전트 연구 평가에서 90.2% 개선을 보고했지만, 일반 에이전트는 채팅보다 약 4배 더 많은 토큰을 사용했고 멀티 에이전트 시스템은 채팅보다 약 15배 더 많은 토큰을 사용했다고도 밝혔습니다 . 실무적 결론은 이렇습니다. 측정 가능한 작업 품질을 높이는 그래프 형태는 유지하고, 조정 오버헤드만 늘리는 핸드오프는 삭제하세요.

자주 묻는 질문

LangGraph에서 토큰 증폭은 어떻게 측정하나요?

LangGraph의 토큰 증폭은 LangSmith 트레이스 전체의 프롬프트 및 완료 토큰 합계를 같은 작업의 더 단순한 기준선으로 나누어 측정합니다. LangSmith는 추적된 LLM 실행에 대해 입력 토큰, 출력 토큰, 총 토큰, 비용 메타데이터를 추적할 수 있습니다 . 또 하나 유용한 비율은 총 그래프 토큰을 최종 전달 출력 토큰으로 나눈 값입니다. 사용자에게 보이는 출력이 아니라 조정에 얼마나 많은 비용이 들어갔는지 보여주기 때문입니다.

핸드오프는 항상 서브에이전트보다 더 비싼가요?

아닙니다. 핸드오프가 항상 서브에이전트보다 더 비싼 것은 아닙니다. LangChain의 멀티 에이전트 가이드는 비용을 모델 호출과 처리된 토큰 관점에서 설명하며, 예시에서는 패턴 선택이 작업 형태, 특히 작업이 반복형인지, 순차형인지, 병렬형인지에 따라 달라진다는 점을 보여줍니다 . 핸드오프는 각 수신 에이전트가 좁은 작업 페이로드 대신 계속 커지는 대화 기록을 물려받을 때 비효율적이 될 수 있습니다.

LangGraph 상태에서 무엇을 먼저 제거해야 하나요?

오래된 검색 텍스트, 중복된 도구 출력, 이전 scratchpad 내용, 요약이나 아티팩트 참조로 대체할 수 있는 전체 transcript를 제거하세요. LangGraph 메모리 가이드는 대화가 컨텍스트 한도에 가까워질 때 메시지 트리밍, 메시지 삭제, 오래된 메시지 요약, 상태 필터링을 지원합니다 . 도구 호출이 포함된 경우에는 provider 메시지 기록의 유효성을 유지하세요. assistant-tool 교환의 한쪽만 삭제하면 이후 호출이 깨질 수 있습니다.

멀티 에이전트 LangGraph 설계는 언제 비용을 감수할 가치가 있나요?

멀티 에이전트 LangGraph 설계는 병렬 검색 폭, 전문화된 도구, 지속 상태가 작업 성공률을 충분히 높여 추가 토큰, 지연 시간, 디버깅 작업을 정당화할 때 비용을 감수할 가치가 있습니다. Anthropic은 자체 멀티 에이전트 연구 시스템이 내부 연구 평가에서 단일 에이전트 기준선을 90.2% 앞섰다고 보고했으며, 동시에 채팅 상호작용 대비 약 15배의 토큰 사용량도 보고했습니다 . 이를 예산 규칙으로 다루세요. 측정 가능한 품질이 올라가면 그래프를 유지하고, 트레이스가 조정 비용만 보여준다면 단순화하세요.

이 글이 도움이 되셨다면, 새 글이 올라올 때마다 이메일로 받아보세요.

구독하기