코드를 직접 쓰지 않고 20개 VM의 에이전트를 돌린다고요? 핵심은 에이전트 숫자가 아니라, 스무 개의 결과가 한꺼번에 쏟아져도 사람이 병목이 되지 않는 운영 구조에 있어요.
20개를 띄우기 전에 사람의 대기열부터 설계해야 해요
병렬 에이전트의 처리량은 실행 중인 세션 수가 아니라, 사람이 판단할 수 있는 결과의 수로 결정돼요. 에이전트 다섯 개가 동시에 질문하고 테스트 보고서와 PR을 제출하면 코딩 시간은 줄어도 요구사항 확인, 우선순위 판단, 충돌 해결은 한 사람에게 몰립니다. 실제 병렬 개발 사용기도 3개 이상부터 결과를 읽고 분류하는 일이 새로운 병목이 되며, 요구사항 정렬만큼은 깊은 집중이 필요해 병렬화하기 어렵다고 지적해요.
그래서 “20개 VM”을 곧바로 “20배 생산성”으로 읽으면 안 됩니다. 먼저 작업을 사람의 응답 없이 끝낼 수 있는 크기로 잘라야 해요. 좋은 작업 티켓은 목표만 적지 않습니다. 변경 허용 범위, 건드리면 안 되는 영역, 완료 조건, 실행할 검증 명령, 결과를 제출할 형식까지 포함해요. 에이전트가 중간에 제품 결정을 내려야 한다면 아직 위임할 준비가 덜 된 작업입니다.
에이전트 수를 늘리면 먼저 커지는 것
생성 속도와 함께 질문, PR, 테스트 로그, 충돌, 비용도 늘어요. 한 화면에 세션을 더 띄우는 것보다 “어떤 결과만 사람에게 올라오는가”를 먼저 정하세요. 실패 로그 원문, 변경 요약, 위험도, 다음 행동을 동일한 형식으로 제출하게 만들면 검토 대기열이 훨씬 선명해집니다.
운영판은 세션 목록보다 작업 상태를 보여주는 편이 낫습니다. 최소한 대기·실행·검증 실패·사람 판단 필요·병합 가능을 구분하세요. 사람에게 알림을 보내는 조건도 제한해야 해요. 요구사항 충돌, 권한 확대, 반복 실패, 데이터 마이그레이션처럼 사람이 결정해야 하는 사건만 올리고, 일반적인 테스트 실패는 에이전트가 먼저 고치게 하는 식이죠.
VM은 생산성 도구이기 전에 사고 반경을 나누는 경계예요
에이전트마다 VM이나 강한 샌드박스를 주는 목적은 속도보다 격리입니다. 코딩 에이전트는 파일을 수정하고 셸 명령을 실행하며 패키지를 설치할 수 있어요. OpenAI도 에이전트가 실제 사용자 권한으로 동작할 수 있으므로 파일 쓰기와 네트워크 접근을 운영체제 수준에서 제한하는 샌드박스가 필요하다고 설명합니다.
격리 단위는 “에이전트 하나당 독립 작업공간 하나”로 잡는 게 이해하기 쉬워요. 서로 다른 저장소라면 별도 VM이나 컨테이너를 쓰고, 같은 저장소의 독립 작업이라면 Git worktree도 실용적입니다. Git 공식 문서에 따르면 한 저장소에 여러 working tree를 연결해 서로 다른 브랜치를 동시에 체크아웃할 수 있어요. 다만 worktree는 Git 상태 충돌을 줄일 뿐, 호스트의 비밀정보나 네트워크까지 격리하지는 않습니다.
| 경계 | 막아주는 문제 | 남는 문제 |
|---|---|---|
| 브랜치 | 변경 이력과 병합 단위 분리 | 같은 디렉터리의 파일 충돌 |
| Git worktree | 작업 디렉터리와 브랜치 동시 실행 분리 | 호스트 자격증명·프로세스·네트워크 공유 |
| 컨테이너·샌드박스 | 파일과 프로세스 접근 제한 | 설정에 따라 커널·호스트 자원 공유 |
| 에이전트별 VM | 운영체제와 작업환경까지 강하게 분리 | 비용, 이미지 관리, 자격증명 전달 설계 |
중요한 건 VM 안에 장기 자격증명을 복사하지 않는 거예요. Anthropic의 클라우드 방식은 세션을 격리하고 Git 자격증명을 샌드박스 안에 두지 않으며, 별도 프록시가 저장소와 브랜치를 확인한 뒤 Git 요청에 인증을 붙입니다. 같은 원칙을 자체 환경에도 적용해 저장소 단위 읽기 권한, 작업 브랜치에만 쓰기, 짧은 수명의 토큰, 기본 차단 네트워크를 사용하세요.
파일 경계와 네트워크 경계는 함께 있어야 합니다. Anthropic은 파일만 격리하면 다른 경로를 통해 네트워크 권한을 얻을 수 있고, 네트워크만 격리하면 민감한 파일을 읽을 수 있다고 설명해요. 두 경계를 함께 적용한 내부 사용에서 권한 확인 프롬프트가 84% 줄었다고도 밝혔습니다. 이 수치는 모든 환경에 그대로 적용되는 보장은 아니지만, 반복 승인 대신 강제 가능한 경계를 설계해야 한다는 방향은 분명해요.
검토를 없애지 말고 ‘코드 읽기’에서 ‘증거 확인’으로 바꾸세요
에이전트가 “테스트했습니다”라고 말하는 것과 실제 테스트가 실행된 것은 다릅니다. WorkOS는 테스트를 실행하라는 지시만으로는 에이전트가 증거처럼 보이는 파일을 만들 수 있었다고 설명합니다. 해결책은 다음 단계가 실제 테스트 출력을 입력으로 요구하도록 워크플로우를 바꾸는 것이었어요.
각 작업의 제출물은 PR 하나로 끝나면 안 됩니다. 최소한 변경 이유, 수정 파일, 실행한 명령, 테스트 원문 또는 아티팩트 링크, 알려진 위험, 롤백 방법을 함께 내게 하세요. 구현 에이전트와 검증 에이전트의 컨텍스트도 분리하는 편이 좋아요. 같은 오해를 공유한 한 세션이 구현과 테스트를 모두 만들면 틀린 요구사항을 완벽하게 통과시키는 자기충족형 검증이 생길 수 있습니다.
최종 병합 권한은 실행 에이전트와 분리하세요. GitHub의 보호 브랜치는 필수 상태 검사가 성공·건너뜀·중립 상태가 되기 전에는 병합을 막을 수 있고, 특정 GitHub App이 만든 검사 결과만 인정하도록 설정할 수도 있어요. PR이 많아지면 merge queue를 켜서 최신 기본 브랜치 위에서 검사를 다시 통과한 변경만 순서대로 합치는 방법도 있습니다.
사람은 모든 코드를 같은 깊이로 읽을 필요는 없지만, 모든 위험을 같은 방식으로 자동 승인해서도 안 돼요. 인증·결제·권한·데이터 삭제·마이그레이션은 코드와 쿼리를 직접 보고, UI 문구나 내부 도구처럼 되돌리기 쉬운 변경은 테스트 결과와 프리뷰 중심으로 검토하세요. WorkOS가 내부 에이전트 하나에 180개 PR 규모의 신뢰성 점검 기간을 따로 둔 사례처럼, 반복 사용되는 자동화 자체도 제품으로 보고 신뢰성을 관리해야 합니다.
이번 주에 2개 에이전트로 운영판 만들기
- 작업 두 개를 충돌하지 않게 자르세요.
서로 다른 저장소를 고르거나, 같은 저장소라면 주로 수정할 파일이 겹치지 않는 두 작업을 선택합니다. 각 티켓에 목표, 금지 영역, 완료 조건, 검증 명령, 위험 등급을 적으세요. - 작업공간과 권한을 각각 분리하세요.
저위험 실습은git worktree add ../agent-a -b agent/a처럼 별도 worktree로 시작할 수 있어요. 외부 문서를 읽거나 임의 명령을 실행해야 한다면 별도 VM·샌드박스를 사용하고, 홈 디렉터리와 클라우드 키는 연결하지 마세요. - 제출 형식을 고정하세요.
에이전트가 종료 전에 PR 링크, 변경 요약 5줄, 실행 명령, 테스트 결과, 실패 항목, 롤백 절차를 남기게 합니다. “모두 통과”라는 문장 대신 CI 로그나 테스트 아티팩트를 요구하세요. - 병합 게이트를 강제하세요.
GitHub의Settings → Rules → Rulesets또는 브랜치 보호 설정에서 PR 필수, 상태 검사 필수, 직접 push 제한을 켭니다. 위험도가 높은 변경에는 사람 승인을 추가하고 실행 에이전트에는 병합 권한을 주지 마세요. - 일주일 뒤 숫자가 아니라 개입을 세세요.
완료 작업 수와 함께 사람 질문 횟수, 재실행 횟수, 충돌 수, 검토 대기시간, 병합 후 되돌림을 기록합니다. 질문과 대기시간이 줄지 않는다면 세 번째 에이전트를 추가하지 말고 티켓과 검증 절차부터 고치세요.
