에이전트 더 쪼개면 좋아질 거란 기대, 6개월 굴려보니 반은 틀렸습니다

요즘 멀티에이전트 글 보면 대부분 "역할을 더 잘게 쪼개고 에이전트 수를 늘리면 품질이 올라간다"는 전제로 깔고 가는데, 저는 좀 반대로 봅니다. 6개월 정도 역할별 서브에이전트 오케스트레이션을 실제로 굴려보고 나서 내린 결론이라 어느 정도는 자신 있게 말씀드리는 거고요.

확실히 효과 본 건 딱 두 가지였습니다. 만드는 에이전트와 검수하는 에이전트를 분리한 것(Maker-Critic), 그리고 자기 결과물을 자기가 검수하지 못하게 막은 것. 같은 컨텍스트 안에서 스스로 리뷰시키면 거의 자기 합리화만 하더라고요. 검수자를 물리적으로 별도 프롬프트/세션으로 떼어내니까 그제서야 진짜 반려가 나왔습니다. 이 루프 하나는 지금도 안 끄고 씁니다.

반면 에이전트 종류를 늘린 건 대부분 노이즈였어요. 12명, 20명까지 늘려봤는데 통과율이나 결과 품질이 유의미하게 좋아지지 않았고, 오히려 핸드오프 단계마다 컨텍스트가 깎여서 디버깅만 어려워졌습니다. 역할 8개나 25개나 사용자가 체감하는 차이는 거의 없었던 듯하고요.

제일 조용히 위험했던 건 자동 라우팅이었습니다. 키워드로 요청을 에이전트에 꽂는 구조였는데, 틀려도 에러를 안 냅니다. 그냥 엉뚱한 에이전트가 그럴듯한 빈 결과를 반환해요. 멘션 붙은 케이스만 테스트하면 멀쩡해 보여서 발견이 한참 늦습니다. 라우팅 오분류는 throw가 아니라 silent하게 샌다는 걸 늦게 배웠습니다.

그래서 지금은 역할 분리랑 검수 루프만 남기고 나머지 오케스트레이션 레이어는 거의 걷어냈습니다. 에이전트 수를 늘려서 풀린 문제는 솔직히 하나도 없었고, 라우팅 자동화는 차라리 명시적으로 박는 게 사고가 덜 납니다. 화려한 멀티에이전트 다이어그램은 대체로 오버엔지니어링이라고 봅니다.