멀티에이전트를 6개월 굴려보니, 효과 본 건 역할을 쪼갠 게 아니라 검수를 분리한 것이었다

멀티에이전트 글은 대부분 "역할을 잘게 쪼개고 에이전트 수를 늘리면 품질이 올라간다"는 전제로 깔립니다. 역할별 서브에이전트 오케스트레이션을 6개월 굴려본 입장에서는, 이 전제의 절반은 틀렸다고 봅니다.

확실히 효과를 본 건 두 가지였습니다.

첫째, 만드는 에이전트와 검수하는 에이전트를 분리한 것(Maker-Critic). 둘째, 자기 결과물을 자기가 검수하지 못하게 막은 것. 같은 컨텍스트 안에서 스스로 리뷰시키면 거의 자기 합리화만 합니다. 자기가 짠 코드의 전제를 그대로 깔고 보니까 결함을 결함으로 안 봐요. 검수자를 별도 프롬프트/세션으로 떼어내서 결과물만 던져주니, 그제서야 진짜 반려가 나왔습니다. 이 루프는 지금도 끄지 않고 씁니다.

반면 에이전트 종류를 늘린 건 대부분 노이즈였습니다. 역할을 8개에서 12개, 25개까지 늘려봤는데 통과율이나 결과 품질이 유의미하게 좋아지지 않았습니다. 오히려 핸드오프 단계마다 컨텍스트가 깎여서, 앞 에이전트가 정리한 맥락을 뒤 에이전트가 못 받고 다시 추측하는 일이 생겼습니다. 디버깅도 어려워졌고요. 사용자가 체감하는 차이는 거의 없었습니다.

제일 조용히 위험했던 건 자동 라우팅이었습니다. 키워드로 요청을 에이전트에 꽂는 구조였는데, 분류가 틀려도 에러를 안 냅니다. 엉뚱한 에이전트가 그럴듯한 빈 결과를 반환할 뿐입니다. 멘션이 붙은 케이스만 테스트하면 멀쩡해 보여서 발견이 한참 늦었습니다. 라우팅 오분류는 throw가 아니라 silent하게 샌다는 걸 늦게 배웠고, 결국 새 채널을 라우팅 테이블에 등록 안 하면 확신도 0으로 떨어져 기본 에이전트로 잘못 가는 패턴까지 겪었습니다.

지금은 역할 분리와 검수 루프만 남기고 나머지 오케스트레이션 레이어는 거의 걷어냈습니다. 에이전트 수를 늘려서 풀린 문제는 없었고, 라우팅은 자동 추론보다 명시적으로 박는 쪽이 사고가 덜 납니다. 화려한 멀티에이전트 다이어그램은 대체로 오버엔지니어링이라고 봅니다. 늘려야 할 건 에이전트 수가 아니라 검수의 독립성입니다.