3에서 8개의 코딩 에이전트를 병렬로 실행하면서 추적을 잃지 않는 방법

두 개의 에이전트를 동시에 실행하는 데는 5분이 걸립니다. 두 개의 터미널을 열고 각각에게 작업을 할당한 후, 텍스트가 스크롤되는 것을 지켜봅니다.

문제는 네 번째 에이전트부터 시작됩니다.

어느 에이전트가 리뷰를 기다리고 있는지, 어느 에이전트가 완료되었는지, 어느 에이전트가 다른 곳을 보고 있는 동안 10분 전에 충돌했는지 더 이상 알 수 없습니다. 잘못된 터미널을 스크롤합니다. 이미 완료된 작업을 다시 시작합니다. 한 시간이 지나면, 방향을 유지하기 위해 세 개의 에이전트가 할 일을 수작업으로 하고 있습니다.

이것은 성능의 문제가 아닙니다. 가시성의 문제입니다.

진정한 병목은 당신의 머리

자율적으로 코딩하는 에이전트는 간헐적으로 결과물을 제공합니다. 40초 동안 생각하고, 작성하고, 멈추고, 당신의 승인을 기다립니다. 그 40초 동안 두 번째 에이전트를 따라갈 수 있습니다. 두 번째 에이전트가 작성하는 동안, 첫 번째 에이전트를 승인합니다.

최대 3개의 에이전트까지는 당신의 뇌가 따라갑니다. 5개를 넘어서면, 흐름을 놓칩니다.

Anthropic은 문서에서 흥미로운 수치를 발표했습니다: 가이드가 없는 시도는 세 번 중 한 번 정도 성공합니다. 많은 양을 배송하는 사람들과 다른 사람들 사이의 차이는 모델이 아닙니다. 시작하기 전에 마련한 구조입니다.

따라서 확장하기 전에 구조를 마련하세요.

규칙 1: 하나의 에이전트, 하나의 독립된 작업 공간

고전적인 실수는 세 개의 에이전트를 동일한 레포지토리 복사본에 배치하는 것입니다. 서로 간섭합니다. 하나가 package.json을 편집하면, 다른 하나도 그렇게 하고, 결국 풀 수 없는 병합 문제에 직면하게 됩니다.

해결책은 두 단어입니다: git worktree.

git worktree add ../project-auth feature/auth
git worktree add ../project-billing feature/billing
git worktree add ../project-export feature/export

각 에이전트는 자신의 폴더, 자신의 브랜치, 자신의 파일에서 작업합니다. 충돌은 없습니다. 각 브랜치를 별도로 리뷰하고 준비가 되면 병합합니다.

이것이 연구자들이 고립된 위임이라고 부르는 것의 기초입니다: 중앙 관리자가 작업을 분할하고, 각 하위 작업은 자신의 영역에서 실행되며, 통합은 나중에 테스트를 통해 검증됩니다.

규칙 2: 동일한 중앙 파일을 두 번 나누지 마세요

작업을 나누기 전에 여러 기능이 수정해야 할 파일을 찾으세요. 라우터, 데이터베이스 스키마, API 경로 설정.

이 파일들은 정확히 하나의 에이전트에게만 할당됩니다. 다른 에이전트들은 기다리거나 우회합니다.

동일한 routes.ts 파일을 두 개의 병렬 에이전트에게 주면 병렬 처리에서 얻을 것이라 생각했던 이점을 병합 충돌로 잃게 됩니다. 그 거래는 항상 손해입니다.

규칙 3: 열 개의 터미널이 아닌 하나의 보드

대부분의 사람들은 여기서 멀티 에이전트를 포기합니다. 여덟 개의 터미널 탭을 열고 흐름을 잃고, 다시 하나의 에이전트로 돌아갑니다.

세 가지 질문에 즉시 답할 수 있는 하나의 뷰가 필요합니다:

• 지금 코딩 중인 에이전트는 누구인가요?
• 내 리뷰를 기다리는 에이전트는 누구인가요?
• 완료되었거나 충돌한 에이전트는 누구인가요?

그 뷰가 없으면 멀티 에이전트는 속도보다 정신적 부담을 더 많이 줍니다. 그 뷰가 있으면, 한 번에 6개 또는 8개의 작업 흐름을 진정으로 유지할 수 있습니다.

이것이 바로 AgentsRoom이 채우는 정확한 간극입니다. 각 에이전트는 자신의 타일, 상태, 색상을 가집니다. 당신의 응답을 기다리는 에이전트는 빨간색으로 변하고 알림을 보냅니다. 잘못된 터미널을 스크롤하는 것을 멈추고, 보드를 보고 어디로 가야 할지 알 수 있습니다.

실제로 작동하는 리듬

제가 시작할 리듬은 다음과 같습니다.

파일을 공유하지 않는 두 가지 기능에 두 개의 에이전트로 시작하세요. 리뷰 후 병합 루프에 익숙해지세요. 그 루프가 코드가 아니라 당신의 실제 작업이 됩니다.

그 루프가 매끄럽게 느껴지면 네 개로 늘리세요. 높은 영향력을 가진 작업의 엄격한 우선순위 목록을 유지하고, 계획 모드에 강하게 의존하세요: 에이전트가 한 줄을 작성하기 전에 계획을 승인합니다. 사전에 승인된 계획은 나중에 고통스러운 리뷰를 줄여줍니다.

달콤한 지점은 시각적 감독과 함께 동일한 레포지토리에서 3개에서 8개의 기능 사이에 있습니다. 그 이상은, 좋은 보드가 있더라도 리뷰가 병목이 되어 이점을 잃게 됩니다.

실제로 얻는 것

멀티 에이전트는 95%의 작은 작업에는 무의미합니다. 오타를 수정하거나 버튼을 추가하는 데는 단일 에이전트로 충분하며 더 빠릅니다.

큰 작업에서 주간을 바꾸는 것은 다릅니다. 저녁에 세 개의 독립적인 리팩터링을 시작하고, 그것들이 도착할 때 리뷰하고, 다음 날 아침에는 병합할 준비가 된 삼일치의 작업이 있습니다.

비밀은 에이전트의 수가 아닙니다. 항상 지금 당신이 필요한 에이전트를 아는 것입니다. 그 문제를 해결하면 나머지는 따라옵니다.