결제 API 수정, 관리자 화면 보강, 회귀 테스트 작성을 세 세션에 나누면 세 배 빨라질 것처럼 보입니다. 실제로는 세 작업이 같은 라우터와 타입 파일을 건드리면서 마지막 통합에 반나절이 더 들 수 있습니다. Claude Squad는 터미널 세션과 Git 작업 공간을 나누지만, 요구사항과 공유 자원까지 자동으로 분리해 주지는 않습니다.
핵심 Claude Squad는 서로 다른 파일과 독립된 검증 결과를 가진 작업을 동시에 돌릴 때 유용합니다. 공통 계약이 아직 흔들리거나 한 파일에 수정이 몰리는 작업은 한 세션에서 순서대로 끝내는 편이 빠릅니다.
세 갈래로 나누기 전에 충돌 지도를 그립니다. 작업 A는 결제 서비스와 단위 테스트, B는 관리자 화면, C는 브라우저 회귀만 맡는다고 가정합니다. 라우터, 잠금 파일, 공용 타입은 통합 담당만 수정하도록 남깁니다. 세 작업이 모두 같은 API 계약을 기다린다면 병렬화하지 않고 계약을 먼저 확정합니다.
이렇게 나누면 각 작업 공간의 변경은 독립적으로 검증됩니다. 반대로 “결제 기능 개선”처럼 결과만 나누고 파일 소유를 정하지 않으면 세 에이전트가 같은 문제를 서로 다른 방식으로 풀게 됩니다.
Claude Squad가 격리하는 것과 못 하는 것. 공식 저장소 설명대로 Claude Squad는 터미널 세션과 Git 작업 공간을 사용해 작업별 브랜치와 디렉터리를 만듭니다. 그래서 한 세션의 미커밋 파일이 다른 세션에 바로 섞이지 않습니다.
하지만 개발 포트, 로컬 DB, 캐시, 외부 샌드박스 계정은 그대로 공유될 수 있습니다. 두 테스트가 같은 데이터 행을 지우거나 같은 포트를 열면 작업 공간이 달라도 실패합니다. 포트와 테스트 데이터 이름까지 작업별로 나눠야 합니다.
세션에 넘길 계약은 짧고 검증 가능해야 합니다. 각 세션에는 구현 지시보다 경계를 먼저 줍니다.
기준: origin/main의 확정 커밋
목표: 결제 실패 사유를 관리자 화면에 표시
소유: web/admin/billing/**, tests/admin/billing/**
금지: server/**, package lock, 공용 라우터
검증: 관리자 화면 단위 테스트와 390px 렌더
반환: 변경 파일, 테스트 결과, 공용 계약 변경 제안
커밋·푸시·배포 금지
완료 시간은 통합 뒤에 측정합니다. 순차 작업이 150분 걸릴 것으로 예상됐고 병렬 세션 세 개가 각각 45분에 끝나도, 충돌 해결 70분과 전체 회귀 40분이 들면 이득은 거의 없습니다. 다음 배치에서는 세션별 실행 시간과 함께 겹친 파일 수, 통합 수정 줄 수, 전체 테스트 재실행 시간을 기록합니다.
독립 작업 세 개가 각각 통과하고 공용 파일 충돌이 없으며 전체 회귀까지 90분에 끝났다면 병렬화가 성공한 것입니다. 세션 성공 개수는 성과 지표가 아닙니다.
이 조건에서는 즉시 줄이거나 멈춥니다. 두 세션이 같은 공용 파일을 수정했거나 API 계약을 서로 다르게 해석하면 새 세션을 더 열지 않습니다. 한 작업의 실패가 다른 작업의 기준을 바꾼다면 선행 작업만 남깁니다. 자동 승인이 운영 자격, 배포 명령, 데이터 변경과 만나는 경우에도 중단합니다.
Claude Squad는 병렬성의 비용을 없애는 도구가 아닙니다. 독립성을 눈에 보이는 작업 공간으로 만드는 도구입니다. 그 독립성을 설명할 수 없으면 설치하지 않는 것이 낫습니다.
병렬 세션을 열기 전에 Claude Code로 충돌을 찾습니다. 다음은 실측 기록이 아니라 세 작업의 독립성을 확인하는 계획 세션 예시입니다. Claude Squad를 실행하기 전 기본 Claude Code 세션에서 공용 파일부터 찾습니다.
cd /path/to/project
claude --permission-mode plan
AGENTS.md, 결제 서비스, 관리자 화면, 관련 테스트와 공용 타입을 읽으세요.
코드는 수정하지 말고 세 작업의 공유 파일과 선행 결정을 찾으세요.
허용 도구: Read, Glob, Grep
Edit, Bash, 새 Worktree 생성은 검토 전 승인하지 않습니다.
반환 형식: 기준 상태 / 작업별 소유 파일 / 공용 파일 / 검증 / 병렬 불가 조건
작업 계약을 확정한 뒤 세션을 나눕니다. 공용 라우터와 타입 소유자가 정해진 뒤 후속 프롬프트로 "결제 서비스 작업만 준비하세요. 지정된 서비스와 테스트 외 파일은 수정하지 말고 공용 계약 변경은 제안으로 반환하세요."라고 보냅니다. 관리자 화면과 브라우저 검증 세션에도 서로 다른 소유 경로와 같은 기준 상태를 줍니다.
각 세션의 성공보다 통합 변경 차이를 봅니다. 아래 명령은 통합 담당자가 실행할 예시입니다. 실제 브랜치 이름과 테스트 명령은 저장소 규칙에 맞춥니다.
git worktree list
git diff --stat
npm test
git status --short
병렬 세션을 줄이거나 닫는 기준. 두 세션이 같은 공용 파일을 수정하거나 API 계약을 다르게 해석하면 새 작업을 열지 않습니다. 개발 포트, DB, 외부 계정이 격리되지 않아도 중단합니다. 같은 기준 상태와 작업 계약이면 재개할 수 있지만 선행 결정이 바뀌면 기존 세션을 닫고 새 계획에서 다시 나눕니다.