Claude Code를 2개 세션 병렬로 돌려 11개의 PR을 냈지만, 한계는 인간 측에 있었다

지난번에 공개한 기사의 속보와 같은 내용입니다.

결론부터 말씀하자면

おすそぐら(防災備蓄管理 SaaS, β 공개 완료)의 Phase 3 잔여 작업을, Claude Code의 2개 세션을 병렬로 실행하여 진행했습니다.

** git worktree로 격리 / MEMORY.md를 공유 허브로 사용 / 파일 분리 사전 규칙** 이라는 3가지 포인트로, 실제 시간 1시간 55분 만에 11개의 PR을 처리했습니다 (테스트 +180건, main 머지(merge) 충돌 0건). 병렬로 작동하던 세션 B는 Observability 계열을 별도 브랜치에서 진행하고 있었습니다. 단일 세션으로 순차적으로 돌렸다면, 리뷰 대기나 문맥 전환(context switching)의 누적으로 인해 반나절 가까이 걸렸을 것이라는 느낌이 듭니다.

하지만 가장 힘들었던 것은 AI가 아니라, 인간 측의 컨텍스트 스위칭(context switching)이었습니다.

isolation(충돌 회피)은 상당히 해결되어 가고 있습니다. 마지막까지 남은 것은 coordination(교통 정리)이었습니다.

왜 병렬화했는가

Claude Code + CodeRabbit 운용 방식에서는 PR을 제출한 후의 리뷰 대기 / 재리뷰 대기가 빈번하게 발생합니다. 그래서 의존성이 낮은 별도의 태스크(A: 테스트 정비 / B: Observability)를 별도 세션으로 병행시켜, 대기 시간을 다른 작업으로 채울 수 없을지 시도해 보았습니다.

장치

git worktree로 격리

CLI 하나로 완결됩니다:

cd /Users/suna/Projects/osusogura
git worktree add ../osusogura-b5 -b feat/b5-otel origin/main

다른 터미널에서 cd ../osusogura-b5 && claude를 실행하면, 두 번째 세션이 물리적으로 분리된 상태로 시작됩니다.

MEMORY.md를 허브로 한 문맥 공유

Claude Code의 세션은 독립되어 있으므로, 공유 허브로서 Claude Code의 memory 기능에 진행 로그용 markdown을 두었습니다:

## 진척 로그
각 세션이 추가. 포맷: `- YYYY-MM-DD HH:MM [A or B] 이벤트`
- 2026-05-12 [A] 착수: branch feat/b1-auth-tests, `lib/auth/{...}` 읽기 완료
...

파일 분리 사전 규칙

세션을 만들기 전에, 양측이 건드려도 좋은 경로를 명시해 둡니다:

담당	기대 커밋 범위
세션 A	web/src/lib/**/*.test.ts / web/tests/e2e/*.spec.ts / fixtures / docs/roadmap.md의 A 담당 섹션
세션 B	web/src/instrumentation* / web/src/lib/logger* / infra/modules/app-env/*.tf / docs/roadmap.md의 B 담당 섹션

그리고 양쪽 세션이 건드릴 가능성이 있는 파일(roadmap.md / package.json / pnpm-lock.yaml / schedule.md)에 "건드리기 전에 진척 로그에 적는다"라는 규칙을 추가했습니다.

결과적으로 11개의 PR을 통해 main으로의 merge 충돌은 0건이었습니다. 다만, 아찔했던 순간은 한 번 있었습니다 (후술 §개선 포인트).

한계 / 적성

독립된 코드 영역(test / infra / docs)에서는 강력했습니다. 반면, schema migration이나 UI 전체 refactor와 같이 순서 의존적이고 광범위한 변경에서는 파괴되기 쉽습니다. 동일한 도메인을 2개 세션으로 작성하면, 인식의 차이로 인해 중복 구현이 될 수도 있습니다.

시간 규모는 1~2시간의 집중 작업을 가끔 2개 세션으로 만드는 정도가 현실적이었습니다.

직접 해보며 알게 된 것은 컨텍스트 스위칭(context switching)의 고통입니다. worktree를 통해 파일 충돌은 거의 사라졌습니다. 하지만 인간 측의 컨텍스트 스위칭은 사라지지 않았습니다. 코드베이스는 물리적으로 나뉘어 있어도, 테스트 코드에서 Terraform 설정으로 머리를 전환하는 비용은 상상 이상으로 컸습니다.

해보며 깨달은 개선 포인트

"성립은 했지만, 다음에 한다면 이 부분을 바꾸고 싶다"를 두 가지로 압축합니다.

1. 공유 리소스(공유 파일 + 의존성)는 담당을 한쪽으로 고정한다

유일하게 아찔했던 순간은 docs/roadmap.md의 이중 편집이었다. 첫 번째 PR이 머지(merge)되지 않은 상태에서 두 번째 PR을 별도의 브랜치(branch)로 생성했는데, 양쪽 모두 동일한 섹션을 편집하고 있어 머지 직전에 충돌을 발견했다. 당초 세워두었던 "수정하기 전에 진행 로그에 기록한다"라는 규칙이 작동했어야 함에도 불구하고, 진행 로그가 업데이트되지 않은 순간에 실수를 저질렀다. package.json과 같은 의존성 파일에서도 동일한 구조로 사고가 발생할 수 있다.

공유 리소스(공유 파일 + 의존성 변경)는 병행 작업 중에는 어느 한쪽의 PR에만 한정해야 한다. 느슨한 규칙이 아니라 강제 규칙으로 다루어야 했다.

2. 의존 관계가 있는 연속적인 리팩터링 (refactor)은 PR을 쌓아 올리는 방식으로 한다

11개의 PR까지 늘린 결과, 브랜치(branch) 수가 불어나 시각적으로 혼란스러워지는 순간이 있었다. 병행 작업이 필요한 것은 독립적인 태스크뿐이며, 의존 관계가 있는 연속적인 리팩터링 (refactor)은 PR을 차례로 쌓아 올리는 방식이 더 깔끔했을 것이다. 다음에는 "병렬로 진행할 것인가 / 쌓아 올릴 것인가"를 착수 전에 구분한다.

나중에 조사해 보니, 동일한 문제는 이미 인지되어 있었다

나중에 조사해 보니, claude -w나 .claude/rules/와 같은 격리 (isolation) 지원 기능, AGENT_SYNC.md나 claude-mem과 같은 운영 패턴은 이미 존재하고 있었다[1]. 내가 발명한 것이 아니라, 기존 패턴으로 자연스럽게 수렴하고 있었음이 밝혀졌다. 다만, 진행 상황 공유나 머지 (merge) 순서 제어와 같은 조정 (coordination)은 여전히 사용자 운영에 크게 의존하고 있다[2].

고찰

이번 병렬 운용을 통해 느낀 점은, 동일 계통의 모델을 병렬화하면 동일한 간과(oversight) 또한 병렬화되기 쉽다는 것이었다. 병렬도를 높일수록 문제는 "에이전트 (agent)의 수"가 아니라 "사고 편향의 유사성"이 된다.

요약

워크트리 (worktree)나 규칙 (rules)을 통해 격리 (isolation) 문제는 상당히 해결되어 가고 있다.

하지만 조정 (coordination)은, 여전히 인간이 교통정리를 하고 있다.