공개 벤치마크 트레이스에서 에이전트의 중복 실행을 측정해봤습니다. 같은 도구를 같은 인자로 두 번 호출하고 결과까지 같은 경우를 세는 방식입니다.
6,780개 트레이스에서 8,042건이 나왔는데, 절반 가까이는 작업 완료 선언 반복 같은 것 빼면 4,249건이었습니다. 그중 상태를 변경하는 도구의 중복 호출 3,432건에 대해 응답에 담긴 엔티티 ID를 비교해보니, 159건은 실제로 두 개가 생성된 게 확인됐습니다. 같은 제목 문서가 두 개, 같은 스프레드시트가 네 개 만들어진 식입니다.
여기 명확한 한계가 있습니다. 이 숫자는 전부 벤치마크 트레이스입니다. 22개 모델이 태스크를 푸는 기록이지 실제 운영 서비스가 아닙니다. 공개 데이터셋을 여덟 개 뒤졌는데 이 현상을 관측할 수 있는 게 이거 하나뿐이었습니다. 대부분의 벤치마크가 정확도 채점을 위해 설계돼서, 중복이 일어나면 오답이 되는 구조더군요.
그래서 실제로 운영하시는 분들께 여쭤보고 싶습니다.
- MCP 도구(혹은 서버)를 몇 개나 붙여서 쓰시나요?
저희가 본 두 데이터셋은 중복률이 3배 차이났습니다(0.80% vs 2.41%). 도구 수도 20개 대 523개로 크게 달랐는데, 태스크 성격과 모델 구성도 함께 달라서 도구 수가 원인인지는 분리하지 못했습니다.
실제로 벤치마크 안에서 태스크에 붙은 서버 수로 나눠보니 4~5개일 때 가장 높고(약 2.5%), 그 이상에서는 오히려 낮아지는 비단조 패턴이었습니다. 단순히 "도구가 많으면 중복이 는다"는 관계는 못 봤습니다. 실제 운영에서는 어떠신지 궁금합니다.
- 중복 실행을 겪으신 적 있나요? 어떻게 발견하셨나요?
저희가 본 사례는 대부분 에러가 안 났습니다. 두 번 다 200이고 로그도 깨끗해서, 사후에 로그만 봐서는 안 보이더군요. 실제로는 고객이 알려줘서 아는 경우가 많을 것 같은데 어떠신지요.
- 쓰시는 도구들이 응답에 엔티티 ID를 돌려주나요?
이게 "두 번 호출됐다"와 "두 개가 생겼다"를 가르는 지점이었습니다. 문서 생성 API는 대부분 ID를 주는데, 이메일 발송은 "성공" 문자열만 주는 경우가 많았습니다. 판정 불가였던 3,197건 중 2,011건이 이 경우였고, 응답에 ID를 한 번도 안 주는 도구가 24종이었습니다.
정답을 원하는 게 아니라, 벤치마크와 실제 운영이 얼마나 다른지 감을 잡고 싶습니다. 경험담만으로도 큰 도움이 됩니다.