멀티 에이전트 워크플로우를 잘못 사용하고 있었던 것 같네요

토큰을 엄청 많이 쓰겠네요. 저는 그런 방식보다는 좀 더 보수적입니다. 아낄 수 있다면 아끼는 게 좋지 않나요?

꽤 괜찮아 보이네. GenTeam에 대해 궁금하긴 했는데 내 워크플로우 어디에 적용해야 할지 확신이 안 섰거든. '계획 수립' 단계에 사용하는 게 훨씬 합리적이네. 한번 시도해 봐야겠어.

저도 같은 경험을 했습니다. 가치 있는 부분은 항상 누군가 접근 방식을 확정하기 전의 의견 충돌이었지, 세 에이전트가 똑같은 실행 과정을 내레이션하는 게 아니었어요. 그 단계를 지나면 더 중요한 건 확실한 분리입니다. 각 에이전트가 자신의 작업 트리(worktree)에 머물러서 두 에이전트가 같은 파일을 절대 건드리지 못하게 하는 게 낫지, 서로 방해하지 않게 하려고 영리한 조정을 하는 건 별로예요.

맞아, 나도 결국 같은 결론에 도달했어. 내 프로젝트에 Claude 에이전트 몇 개를 돌려봤는데, 멀티 에이전트 방식이 확실하게 이득을 보는 구간은 코드가 나오기 전 단계뿐이더라고. 두 모델이 서로의 논리적 허점을 찌르면서 내가 미처 생각하지 못했던 가정들을 수면 위로 끌어올려 주거든.

근데 일단 계획이 확정되고 나면, 에이전트가 많아질수록 충돌할 가능성만 커질 뿐이야. 한 번은 에이전트 두 개가 동시에 같은 파일을 수정하게 뒀다가, 그거 수습하느라 그냥 내가 직접 기능 구현하는 것보다 시간이 더 걸린 적도 있어. 그래서 이제는 계획 단계에서...

네가 찾은 방식이 나랑 똑같네. 발산 단계에서는 여러 머리가 필요하지만 수렴 단계에서는 아니거든. 일단 계획이 나오면 두 번째 의견은 그냥 지연 시간만 늘리고 돈만 나가는 꼴이지.

한 가지 덧붙이자면, 회의실을 나가기 전에 합의된 계획을 파일로 저장해 둬. 단일 빌더 에이전트는 대화로만 들은 계획을 자기 마음대로 해석해 버리는데, 나중에 diff 확인하기 전까지는 눈치채지도 못하거든.

요즘 업계의 중론이랑 일치하네. 멀티 에이전트는 초반의 발산적 사고에 빛을 발하고, 그다음에는 실행자 한 명이 마무리하는 게 맞아. 실패하는 경우는 작업 중간에 에이전트들이 토론을 벌이는 건데, 접근 방식을 탐색할 땐 좋지만 끝낼 땐 최악이지.

별도의 워크트리를 쓰면 파일 덮어쓰기 문제는 해결되지만, 모든 통합 충돌을 막을 순 없어. 깔끔하게 병합되는 두 변경 사항도 공유 API나 데이터 형식에 대해서는 서로 의견이 다를 수 있거든. 병렬 작업 후에 명시적인 통합 확인 단계를 넣는 걸 추천해. 단순히 개별적으로 성공했다는 보고만 믿지 말고, 결합된 결과를 검토할 책임자를 한 명 두는 게 좋아.

공유할 만한 좋은 깨달음이네. '멀티 에이전트'라고 불리는 것들 중 상당수는 사실 도구 몇 개를 쥐여준 에이전트 하나인 경우가 많거든. 괜히 나누면 별 이득도 없이 조율 비용만 늘어날 뿐이지. 하위 작업들이 진짜로 서로 다른 컨텍스트를 필요로 할 때만 효과가 있는 법이야.