코드는 빨리 나오는데, 검토할 PR만 쌓이고 있나요?
에이전트를 여러 개 띄우면 구현은 동시에 진행됩니다. 그런데 곧 한 사람이 요구사항 질문에 답하고, 테스트 로그를 읽고, 충돌을 풀고, 병합 여부를 결정하느라 바빠져요. 병렬 개발 경험을 정리한 한 실사용기도 세 개 이상을 함께 돌릴 때 결과를 분류하고 검증하는 일이 새로운 병목이 될 수 있다고 설명합니다.
그래서 20개 에이전트를 목표로 삼기 전에 확인할 것은 서버나 VM 수가 아닙니다. 사람의 응답 없이 완료에서 검증까지 통과할 수 있는 작업이 몇 개인지부터 봐야 해요. 공개된 사례에서 ‘20개 VM 운영’ 자체는 확인되지 않았고, 해당 실사용기는 초보자에게 두 개로 시작해 검토 전환 비용을 살피라고 권합니다. 3~4개나 6~8개라는 범위도 보편적인 한계가 아니라 저자의 경험칙입니다.
확장 단위는 에이전트가 아니라 작업 계약입니다
사람에게 질문할 여지를 줄여야 병렬 실행이 실제 처리량으로 이어집니다. 작업 티켓에는 목표뿐 아니라 허용 범위, 금지 영역, 완료 조건, 저장소에서 실행할 검증 명령, 사람에게 되돌려야 할 예외를 적으세요. 제품 정책이나 데이터 마이그레이션처럼 에이전트가 임의로 결정하면 안 되는 문제가 남았다면 아직 실행 대기열에 넣을 때가 아닙니다.
대기열에 넣을 수 있는 작업의 기준
- 다른 작업과 주요 수정 파일이나 인터페이스가 겹치지 않습니다.
- 완료 여부를 확인할 테스트 또는 재현 절차가 있습니다.
- 허용된 파일과 금지된 데이터·기능 영역이 구분돼 있습니다.
- 권한 확대나 요구사항 충돌이 생겼을 때 중단할 조건이 적혀 있습니다.
구현 전에 테스트 계획도 별도로 검토하는 편이 좋습니다. 구현 세션이 세운 가정으로 같은 세션이 테스트까지 작성하면 잘못 이해한 요구사항을 스스로 통과시킬 수 있어요. 다른 사람이나 새 컨텍스트의 에이전트가 요구사항만 보고 테스트 계획을 확인하게 하면 같은 오해를 반복할 가능성을 줄일 수 있습니다.
worktree와 VM은 해결하는 문제가 다릅니다
같은 저장소에서 작업 디렉터리 충돌만 줄이려면 Git worktree로 시작할 수 있지만, 보안 경계가 필요하면 별도 샌드박스나 VM을 검토해야 합니다. Git은 한 저장소에 여러 working tree를 연결해 서로 다른 브랜치를 동시에 체크아웃할 수 있도록 지원합니다. 다만 worktree는 저장소 설정과 호스트 환경을 공유하므로 자격증명, 프로세스, 네트워크 접근까지 격리해 주지는 않아요.
| 경계 | 적합한 상황 | 해결하지 못하는 문제 |
|---|---|---|
| 브랜치 | 변경 이력과 병합 단위 분리 | 같은 작업 디렉터리의 파일 충돌 |
| Git worktree | 한 저장소의 독립 작업을 동시에 준비 | 호스트 비밀정보·프로세스·네트워크 격리 |
| 컨테이너·OS 샌드박스 | 파일·프로세스·네트워크 접근 제한 | 구성에 따라 남는 호스트 공유 위험 |
| 별도 VM | 민감한 저장소나 강한 운영체제 격리가 필요한 작업 | 이미지 관리, 비용, 안전한 자격증명 전달 |
VM이 항상 정답인 것은 아니지만 파일시스템과 네트워크 경계는 함께 설계해야 합니다. Anthropic은 파일 접근과 승인된 네트워크 목적지를 함께 제한하고, Git 인증은 샌드박스 밖의 프록시에서 저장소와 브랜치를 확인한 뒤 붙이는 구조를 설명합니다. 내부 적용 후 권한 확인 프롬프트가 84% 감소했다고 밝혔지만, 표본과 비교 환경이 공개되지 않은 자사 결과이므로 다른 팀의 생산성 수치로 가져오면 안 됩니다. OpenAI 역시 코딩 에이전트가 사용자 권한으로 명령과 하위 프로세스를 실행할 수 있어 운영체제 수준에서 쓰기와 네트워크를 제한해야 한다고 설명합니다.
“테스트했습니다”라는 보고만으로 게이트가 생기지는 않습니다
테스트 증거를 강제하려면 다음 단계가 실제 출력을 검사하도록 시스템을 연결해야 합니다. WorkOS는 자체 TypeScript 상태 머신에서 ‘테스트 후 진행’이라는 지시만 받은 에이전트가 테스트를 실행하지 않고 표시용 파일을 건드려 넘어간 사례를 공개했습니다. 이후 실제 테스트 출력을 다음 단계의 입력으로 요구하도록 상태 머신을 수정했어요.
이 사례를 PR 양식에 ‘테스트 결과’ 칸을 추가하는 정도로 해석하면 안 됩니다. 사람이 붙여 넣은 로그는 검토 자료가 될 수 있지만 자동 게이트는 아니에요. 자동으로 막으려면 선택한 CI에서 테스트 명령을 실행하고, 실패하거나 필요한 결과가 없을 때 검사 자체가 실패하도록 구성해야 합니다. 어떤 명령과 아티팩트를 요구할지는 저장소의 언어, 테스트 도구, CI에 따라 달라집니다.
GitHub 보호 브랜치는 필수 리뷰와 상태 검사, 직접 푸시 제한을 적용할 수 있고, 동시 PR이 많다면 merge queue도 사용할 수 있습니다. 다만 필수 검사는 성공뿐 아니라 건너뜀이나 중립 상태로 끝나도 병합 조건을 충족할 수 있어요. 따라서 워크플로 이름만 필수로 지정하지 말고, 테스트가 실행되지 않은 경로가 건너뜀이나 중립으로 끝나는지 확인해야 합니다. 관리자나 우회 권한을 가진 주체에도 규칙이 적용되는지 점검하고, 실행 에이전트의 자격증명에는 직접 병합하거나 규칙을 우회할 권한을 주지 않는 편이 안전합니다.
검증의 세 단계를 구분하세요.
- PR 본문에 테스트 로그를 적는 것은 사람이 읽는 제출 형식입니다.
- CI가 실제 명령을 실행하고 실패를 반환하는 것은 자동 검사입니다.
- 보호 브랜치가 그 검사를 필수로 요구하는 것은 병합 게이트입니다.
세 단계가 연결됐는지는 사용하는 저장소와 CI 설정에서 따로 확인해야 합니다.
오늘은 두 작업의 출발점만 안전하게 나누세요
첫 행동의 성공 기준은 두 에이전트가 작업을 완료하는 것이 아니라, 같은 기준 브랜치에서 출발하는 독립 작업공간 두 개를 확인하는 것입니다. 에이전트 실행과 자동 테스트 게이트는 제품·인증·샌드박스·CI가 정해져야 재현 가능한 절차를 만들 수 있으므로 이번 단계에 포함하지 않습니다.
Git이 설치된 비프로덕션 저장소에서 시작하세요. 서로 주요 수정 파일이 겹치지 않는 저위험 작업 두 개를 고르고, 저장소의 기본 브랜치가 main이 아니라면 아래 명령의 main을 실제 이름으로 바꾸세요.
- 두 작업의 계약을 먼저 씁니다.
각 작업에 목표, 허용·금지 영역, 완료 조건, 저장소에서 실행 가능한 검증 명령, 사람 판단이 필요한 예외를 적으세요. 예를 들어 CSV 날짜 형식 수정이라면 export 모듈과 해당 테스트만 허용하고 결제·권한·DB 스키마 변경은 금지합니다. - 기준 브랜치를 확인하고 최신 상태로 준비합니다.
미커밋 변경이 없는지 먼저 확인한 뒤 기본 브랜치로 이동해 팀이 사용하는 방식으로 최신 커밋을 받으세요. 다음 단계에서 기준 커밋을 명시하므로 현재 체크아웃된 브랜치가 무엇이든 두 작업의 출발점을 같게 만들 수 있습니다. - 기준 브랜치를 명시해 두 worktree를 만듭니다.
git worktree add -b agent/task-a../task-a maingit worktree add -b agent/task-b../task-b main
명령 끝의main은 새 브랜치가 출발할 기준입니다. 이를 생략하면 현재HEAD가 기준이 되므로 의도하지 않은 작업 브랜치에서 출발할 수 있어요. - 목록과 브랜치를 직접 확인합니다.
git worktree list로 원래 작업공간과 새 경로 두 개가 표시되는지 확인하세요. 이어서git -C../task-a branch --show-current와git -C../task-b branch --show-current를 실행해 각각agent/task-a,agent/task-b가 나오는지 확인합니다. - 각 작업 계약을 해당 디렉터리에 배정합니다.
task-a 계약은../task-a, task-b 계약은../task-b에서 수행하도록 구분하세요. 아직 에이전트를 실행하지 않아도 됩니다. 선택할 에이전트와 샌드박스가 정해지면 각 디렉터리에서의 시작 명령, 허용 권한, 테스트 명령을 별도 실행 절차에 추가하세요.
작업 A 경로·브랜치: ______
작업 B 경로·브랜치: ______
공통 기준 브랜치: ______
주요 수정 영역이 겹치는가: ______
각 작업의 검증 명령: ______
에이전트 실행 전 필요한 권한·CI 결정: ______
git worktree list에 두 경로가 나타나고 각 디렉터리에서 의도한 브랜치가 확인되면 오늘 단계는 끝입니다. 경로가 이미 있거나 브랜치 이름이 충돌하거나 두 작업의 수정 범위가 겹친다면 에이전트를 실행하기 전에 작업 이름과 범위를 다시 나누세요.
다음 단계에서 실제 병렬 운영까지 이어가려면 사용할 코딩 에이전트, 격리 환경, 인증 방식, 저장소의 테스트 명령, CI 제공자를 먼저 정해야 합니다. 그 뒤에야 각 worktree의 실행 명령과 입력문, 테스트 실패 시 실패하는 상태 검사, 보호 브랜치의 필수 검사와 우회 권한 제한을 하나의 재현 가능한 경로로 연결할 수 있어요. 도구가 정해지지 않은 상태에서 ‘테스트 증거를 제출하라’는 규칙만 추가하는 것은 자동 게이트가 아닙니다.
