왜 에이전트가 턴마다 모든 툴 스키마를 보내야 하죠??

실패 로그는 에이전트가 뭘 봤는지만 알려주지, 뭘 필요로 했는데 못 얻었는지는 안 알려줌. 아마 그게 빠진 테스트인 듯.

매번 40개의 전체 JSON 덩어리를 보내는 것보다 짧은 스키마를 먼저 보내고 나중에 전체를 보내는 게 더 깔끔해 보이네요.

에이전트가 처리하는 작업을 분할하는 건 고려해 보셨나요? 저도 같은 문제가 있었는데(컨텍스트가 매우 제한된 로컬 LLM을 써서요), 에이전트를 작업에 필요한 특화된 툴 세트를 가진 독립적인 단계들로 쪼갰습니다.

예를 들어 코딩 작업이라면 에이전트를 세 개의 독립적인 에이전트로 나눌 수 있죠.

1. 계획 에이전트 (컨텍스트 수집용 툴)
2. 작성 에이전트 (파일 처리용 툴...)

에이전트가 툴 몇 개를 넘어서면 컨텍스트 엔지니어링과 툴 스키마 관리가 까다로워집니다. 모든 툴 정의를 매 턴마다 넣으면 프롬프트 캐시 적중률에 악영향을 주고, 지연 시간을 추가하며, 환각 위험을 높입니다.

이 문제를 해결하는 꽤 표준적인 방법은 모듈형 스킬을 사용하는 것입니다. 전체 스키마를 미리 노출하는 대신, 시스템 프롬프트에는 가벼운 스킬 설명만 넣는 거죠. 모델이 특정 기능이 필요하다고 판단하면, 그 스킬을 동적으로 로드해서 관련 툴만 가져오는 겁니다.

워크플로우에서 이미 알고 있는 선택지라면 모델에게 맡기지 않는 것부터 시작할 것 같아요. 제한된 작업은 필요한 기능을 선언해야 하고, 그 계약(contract)을 통해 추론 전에 적합한 툴 세트를 선택할 수 있죠. 동적 라우팅은 그 세트 안에서는 여전히 유용하지만, 매 턴마다 전체 플랫폼에서 선택하는 건 아니게 됩니다.

저라면 실패한 실행에서 제외된 툴, 툴 선택 recall, 첫 유용한 동작 전까지의 토큰 수, 그리고 호출당 비용이 아닌 수락된 작업당 총 비용을 로그로 남길 겁니다.

여기서 진짜 중요한 지표는 호출당 토큰 비용이 아니라 달러당 작업 완료율입니다. 라우터 때문에 recall이 조금이라도 떨어지면 가지치기로 아낀 것보다 재시도에 더 많은 돈을 쓰게 될 거예요. 게이트가 있을 때와 없을 때의 완료된 작업에 대한 엔드투엔드 비용을 측정하세요. 나머지는 다 허상입니다.

잘못된 시스템 설계네요.

에이전트에 너무 많은 짐을 지워서 일을 망친 겁니다. 그렇게 하지 마세요.

라우터는 분류기니까, 매 턴 40개를 다 보내는 '아무것도 안 하는' 베이스라인과 비교해서 측정하세요. 예전에 트리아주 판별기를 만들었다가 그냥 다 받아들이는 것보다 못해서 실패한 적이 있는데, 그게 유용한 결과였죠. 게이트가 좁아서 recall이 떨어진 게 아니었어요. 올바른 툴이 스키마 텍스트가 아니라 대화의 맥락에 따라 달라졌기 때문이었죠. 그러니까 상태를 알 수 있는 곳에서는 가지치기를 결정론적으로 유지하고, 라우터가 확신이 없을 때만 모델이 전체 세트를 보게 하세요.

매 턴 정확한 툴을 예측하려고 하는 것보다 의도에 따른 가지치기와 폴백 세트를 두는 게 더 안전해 보입니다. 재시도 비용이 토큰 절감액을 순식간에 날려버릴 수 있으니까요.

작업 완료당 비용이 가장 중요하다고 생각합니다. 토큰을 아끼는 건 좋지만, 에이전트가 툴을 놓쳐서 재시도해야 한다면 소용없죠. 토큰은 아낄지 몰라도 전체적으로는 더 많은 돈을 쓰게 될 수도 있습니다. 저라면 작업 성공률과 재시도 횟수도 지켜볼 것 같아요. 결국 토큰을 적게 쓰는 것보다 일을 제대로 끝내는 게 더 중요하니까요.