여러 코딩 에이전트 (Coding Agents)를 병렬로 실행하는 것은 컴퓨팅 문제(Compute problem)를 일으키기 전에 검토 문제(Review problem)를 발생시킵니다.

병목 현상은 새로운 터미널을 여는 것에서 발생하는 경우가 드뭅니다. 병목 현상은 어떤 세션이 주의를 기울일 가치가 있는지, 각 변경 사항의 소유자가 누구인지, 그리고 결과를 수락하기에 어떤 증거가 충분한지를 결정하는 데서 발생합니다.

채팅 창이 벽처럼 쌓여 있는 것은 이러한 질문에 답을 주지 못합니다. 팀 리더에게는 소유권이 명확한 아티팩트 (Artifacts)와 검토 결정 사항이 담긴 큐 (Queue)가 필요합니다.

병렬화 전 작업 분할하기

모든 작업은 하나의 소유자, 하나의 요청된 아티팩트 (Artifact), 그리고 하나의 쓰기 범위 (Write scope)를 가져야 합니다. 만약 두 세션이 동일한 파일을 편집할 가능성이 있다면, 누가 최종 변경 사항을 통합할지 결정하거나 작업을 직렬화 (Serialize) 하십시오.

이것이 첫 번째 제어 장치인 이유는 소유권 없는 병렬 실행은 충돌 해결 (Conflict resolution) 문제를 검토 단계로 미루기만 하기 때문입니다. 모든 세션이 성공적으로 완료되더라도, 결합된 변경 사항은 수락이 불가능한 상태로 남을 수 있습니다.

유용한 작업 카드 (Task card)에는 다음 내용이 포함되어야 합니다:

• 요청된 동작 (Requested behavior);
• 허용된 파일 또는 서브시스템 (Subsystem);
• 검증 명령 (Validation command);
• 인수인계 시 기대되는 증거 (Evidence expected at handoff);
• 관찰 가능한 중단 조건 (Observable stop condition).

세션 식별자 (Session identifier)는 작업 카드, 증거, 그리고 최종 검토 결정과 함께 전달되어야 합니다.

필요한 인간의 행동에 따라 상태 순위 매기기

모든 활성 세션이 동일한 주의를 기울일 가치가 있는 것은 아닙니다. 실용적인 큐 (Queue)는 리더가 다음에 해야 할 행동에 따라 상태의 순위를 매깁니다:

1. 승인 또는 입력 필요 (Approval or input required). 인간의 결정 없이는 작업을 계속할 수 없습니다.
2. 검증 실패 (Failed verification). 아티팩트 (Artifact)는 존재하지만, 테스트, 빌드 또는 런타임 체크 (Runtime checks)가 실패했습니다.
3. 검토 준비 완료 (Ready for review). 제한된 변경 사항과 증거 패킷 (Evidence packet)이 준비되었습니다.
4. 실행 중 (Running). 세션이 진행 중이며 개입이 필요하지 않습니다.
5. 유휴 또는 만료 (Idle or stale). 현재 필요한 조치는 없으나, 소유권 정리가 필요할 수 있습니다.

이러한 순서 지정은 소음이 심한 장기 실행 작업이 단 하나의 승인을 기다리고 있는 작은 작업을 가리는 것을 방지합니다.

검토 패킷 (Review packet) 요구하기

세션의 마지막 메시지는 하나의 주장 (Claim)입니다. 검토 패킷 (Review packet)은 그 주장에 대한 증거입니다.

코드 변경의 경우, 해당 패킷(packet)에는 diff 범위(diff scope), 진단(diagnostics), 빌드 또는 테스트 결과, 그리고 변경 사항이 사용자에게 노출되는 영역(user-facing surface)을 포함할 때는 실제 사용성 확인(real usage check)이 포함되어야 합니다. 연구(research)나 운영(operations)의 경우에는 소스 URL, 영수증(receipts), 읽기-다시-쓰기 상태(read-back state), 그리고 해결되지 않은 모든 불확실성(unresolved uncertainty)이 포함되어야 합니다.

팀 리더는 전체 트랜스크립트(transcript)를 다시 열어보지 않고도 다음 세 가지 질문에 답할 수 있어야 합니다:

• 무엇이 변경되었는가?
• 그것이 작동한다는 것을 무엇이 증명하는가?
• 무엇이 여전히 잘못될 수 있는가?

만약 패킷이 이 질문들에 답할 수 없다면, 해당 항목은 검토할 준비가 되지 않은 것입니다.

연대기(Chronology)보다 검토 위험(Review risk)을 우선시하라

가장 오래전에 완료된 작업이 항상 다음에 검토해야 할 작업은 아닙니다. 영향 범위(blast radius)와 가역성(reversibility)에 따라 정렬하십시오.

인증(Authentication), 권한(permissions), 마이그레이션(migrations), 배포 설정(deployment configuration), 그리고 공유 계약(shared contracts)은 고립된 복사 변경(isolated copy changes)보다 먼저 주의를 기울여야 합니다. 쉽게 되돌릴 수 있는 로컬 수정 사항은 설령 먼저 완료되었더라도, 외부로 드러나는 작업(externally visible action)보다 뒤로 밀릴 수 있습니다.

이것이 세션 상태(session status)를 아티팩트 상태(artifact status)와 분리하여 유지해야 하는 이유이기도 합니다. 세션은 완료되었더라도 그 변경 사항은 여전히 검토되지 않았거나, 거부되었거나, 통합(integration)이 차단된 상태일 수 있습니다.

승인 후에만 통합하라

“에이전트 완료(agent finished)”가 곧 “변경 사항 배포(change shipped)”가 되도록 두지 마십시오. 준비됨(ready), 검토 중(under review), 승인됨(accepted), 통합됨(integrated), 그리고 통합 후 검증됨(verified after integration)의 명시적인 상태를 유지하십시오.

이러한 순서는 팀을 두 가지 흔한 오류로부터 보호합니다: 증거 없이 그럴듯한 결과를 병합(merging)하는 것, 그리고 해당 결과를 생성한 세션이 이미 종료되었다는 이유로 좋은 결과를 놓치는 것입니다.

대시보드는 관찰 용도로만 유지하라

리더의 상태 보조 도구(status companion)는 소유권(ownership), 긴급도(urgency), 그리고 증거(evidence)를 더 쉽게 볼 수 있게 만들어야 합니다. 명령을 조용히 승인하거나, 변경 사항을 병합하거나, 릴리스를 배포해서는 안 됩니다. 중대한 결과가 따르는 작업(Consequential actions)은 권한과 감사 이력(audit history)이 이미 존재하는, 해당 작업을 소유한 시스템 내에서 이루어져야 합니다.

따라서 유용한 인터페이스는 다음과 같이 간결합니다: 세션 식별자 (session identity), 소유자 (owner), 현재 상태 (current state), 영향을 받는 아티팩트 (affected artifact), 최신 증거 (latest evidence), 그리고 다음 인간의 결정 (next human decision). 트랜스크립트 (transcript) 텍스트가 더 많아지면 통제력이 높아지는 것이 아니라, 오히려 더 많은 스캐닝 (scanning)을 유발할 뿐입니다.

조정의 단위가 채팅 세션이 아니라 검토 가능한 아티팩트 (artifact)가 될 때, 병렬 코딩 에이전트 (parallel coding agents)를 관리할 수 있게 됩니다. 리드 (lead)는 결정 큐 (queue of decisions)를 운영하며, 세션들은 해당 큐에 증거 (evidence)를 공급하는 역할을 합니다.

전체 구현 체크리스트는 팀 리드 멀티 에이전트 리뷰 워크플로 (team lead multi-agent review workflow)에서 확인할 수 있습니다.