AI 에이전트를 여러 개 띄우면 조사와 검증을 동시에 진행할 수 있다. 하지만 넓은 목표 하나를 그대로 복제해 맡기면 같은 파일을 고치고 같은 결론을 반복한다. 병렬화의 출발점은 에이전트 수가 아니라 서로 독립적인 산출물, 파일 소유권, 합류 조건이다.
Claude Code만 해도 서브에이전트, 에이전트 뷰, 에이전트 팀, 워크트리의 역할이 다르다. 현재 대화 안에서 결과를 모으려면 서브에이전트, 여러 독립 백그라운드 세션을 사람이 배정·모니터링하려면 에이전트 뷰, 작업자끼리 조율해야 하면 에이전트 팀이 맞다. 파일 수정이 겹치면 워크트리로 작업 공간을 나눈다. 제품별 차이를 무시하고 “여러 개 실행”부터 하면 조율 비용이 이득을 삼킨다. 선택 기준은 Claude Code 병렬 실행 공식 안내에서 확인할 수 있다.
1. 기다리지 않아도 되는 일만 병렬화한다
먼저 작업 사이의 의존성을 그린다. A의 결과가 나와야 B를 시작할 수 있다면 두 작업은 병렬이 아니다. 오류 로그 조사, 관련 코드 탐색, 보안 영향 검토처럼 서로의 답을 기다리지 않는 일은 동시에 맡길 수 있다. 반면 설계 확정 전 구현, 구현 전 회귀 테스트 작성처럼 입력이 이어지는 단계는 순차로 둔다.
서브에이전트는 별도 컨텍스트에서 일하고 요약을 호출자에게 돌려준다. 독립적인 조사 경로에 적합하지만, 기존 대화 전체를 자동으로 안다고 기대하면 안 된다. 목표, 읽을 범위, 제외할 경로, 반환 형식을 위임문에 넣는다. 동작 범위는 서브에이전트 공식 문서로 확인한다.
2. 작업이 아니라 산출물과 파일을 배정한다
“결제 모듈 개선” 대신 탐색 보고서, 변경 계획, 구현 파일, 회귀 테스트, 리뷰 메모로 나눈다. 각 항목에는 소유자 한 명과 수정 가능한 경로를 붙인다. 에이전트 팀의 작업 선점 잠금은 같은 작업을 중복으로 가져가는 일을 막을 뿐, 파일 충돌까지 막아 주는 장치가 아니다.
같은 파일을 건드릴 가능성이 있으면 역할을 다시 나누거나 별도 워크트리를 쓴다. 에이전트 뷰는 배정한 세션을 워크트리로 옮기지만, 에이전트 팀은 동료별 워크트리를 자동 제공하지 않으므로 서로 다른 파일 집합을 맡겨야 한다. 워크트리도 작업 공간을 격리할 뿐 같은 줄을 고친 뒤의 병합 충돌까지 없애지는 않는다. 합칠 사람은 시작 전에 기준 브랜치와 병합 순서, 충돌 시 버릴 쪽을 정한다.
3. 시작 조건과 완료 조건을 함께 쓴다
위임문에는 최소 다음 다섯 항목을 적는다.
- 역할: 무엇을 판단하는가
- 입력: 읽을 파일과 선행 결과는 무엇인가
- 변경 범위: 쓸 수 있는 경로와 금지 구역은 어디인가
- 완료 조건: 어떤 테스트와 근거가 있어야 끝인가
- 반환 형식: 확인 사실, 불확실성, 변경 파일, 다음 행동
“검토해 줘” 대신 “인증 모듈은 읽기만 하고, 누락된 회귀 테스트와 근거 줄 번호를 보고하라”라고 써야 결과가 합쳐진다. 구현 담당과 검토 담당도 분리한다. 같은 가정을 공유한 에이전트가 자기 결과를 다시 승인하게 만들지 않는다.
4. 두 개로 시작해 조율 비용을 측정한다
첫 실험은 조사 담당과 반대 검토 담당 두 개로 시작한다. 동시 실행 수, 도구 권한, 최대 비용과 중단 시각을 정하고, 합치는 데 걸린 시간과 다시 시킨 횟수를 기록한다. 에이전트 팀은 각 동료가 별도 컨텍스트를 써 토큰 사용량이 늘며, 현재 기본 비활성화된 실험 기능이다. 사용하려면 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1을 명시적으로 설정해야 한다. 조건은 에이전트 팀 공식 문서에서 확인한다.
성공 기준은 실행한 에이전트 수가 아니다. 한 명이 처리할 때보다 의사결정 시간이 줄었는지, 병합 충돌과 재작업이 늘지 않았는지가 기준이다. 이 수치가 좋아진 역할만 남기고 세 번째 에이전트를 추가한다. 좋은 병렬 워크플로우는 많은 AI를 켜는 방식이 아니라, 겹치지 않는 증거와 결과를 한 사람이 빠르게 판단하도록 모으는 구조다.