병렬 코딩 에이전트는 공짜가 아니다: Git 워크트리는 상태가 아니라 파일을 격리한다¶
빠른 답변: 이번 주 Hacker News 스레드 "Git 워크트리는 코딩 에이전트의 격리 경계가 아니다"는 대부분의 병렬 에이전트 설정이 놓치는 지점을 짚었습니다: 워크트리는 파일을 격리하지 상태를 격리하지 않습니다. 여러 에이전트가 같은 계획, 활성화 저장소, 토큰 스트림, 증거 로그를 대상으로 실행되면 멀티스레드 코드와 똑같은 경쟁 조건이 발생합니다 — 유실된 업데이트, 이중 소비, 조용한 충돌. 파일 격리는 필요 조건이지 충분 조건이 아닙니다; 트랜잭션 상태와 명시적 조정도 필요합니다.
병렬 에이전트 과대광고와 현실¶
병렬 코딩 에이전트는 이제 어디에나 있습니다: Claude Code, Codex, OpenCode를 나란히 실행하는 tmux TUI, 병렬 에이전트용 로컬 병합 큐, 에이전트마다 워크트리 하나씩을 만드는 팀. 아이디어는 단순합니다 — 에이전트는 값싸니 더 많이 돌리면 된다.
현실 점검은 이번 주 스레드에서 나왔습니다. 워크트리는 격리 경계가 아니다라는 주장이었습니다. 핵심을 정확히 짚었습니다: 두 워크트리의 두 에이전트는 서로의 소스 파일을 망칠 수 없지만, 서로의 상태는 충분히 망칠 수 있습니다.
워크트리 격리가 실제로 주는 것¶
git 워크트리는 각 에이전트에게 자기만의 작업 디렉터리와 브랜치를 줍니다. 보호되는 것:
- 소스 파일 — 에이전트 A의 수정이 에이전트 B의 파일을 덮어쓸 수 없습니다.
- 브랜치 — 각 에이전트는 자기 브랜치를 병합하고, 충돌은 병합 시점에 드러납니다.
보호되지 않는 것:
- 활성화 저장소 — 어떤 워크플로가 활성인지, 계획이 어떤 토큰에 있는지.
- 토큰 전진 — 두 에이전트가 모두 "현재 토큰 = 3"을 읽고 둘 다 4로 전진합니다. 한 단계가 두 번 실행되고, 다른 단계는 아예 실행되지 않습니다.
- 증거와 검증 — 에이전트 A의 검증 로그가 같은 검사를 실행한 에이전트 B의 결과로 덮어쓸 수 있습니다.
- 공유 캐시와 락 — 같은 락 파일, 같은 레지스트리, 같은
.aios상태 디렉터리.
에이전트들이 이 중 하나라도 공유한다면, 워크트리는 격리된 느낌만 주고 그 아래의 상태 머신은 버그 있는 멀티스레드 코드처럼 경쟁합니다: 유실된 업데이트, 이중 소비, 조용한 충돌.
상태 수준 격리의 모습¶
"함께 작동하는 병렬 에이전트"와 "서로를 망치는 병렬 에이전트"를 가르는 세 가지:
1. 트랜잭션 상태 쓰기¶
상태 업데이트는 원자적이고 크래시에 안전해야 합니다. 에이전트가 쓰기 도중 크래시하면 다음 실행은 전진하거나 fail-closed로 처리됩니다 — 반쯤 쓰인 프로젝션을 결코 신뢰하지 않습니다. AIOS v5.4.0은 활성화 쓰기를 트랜잭션으로 만듭니다 (write-ahead 트랜잭션, 재시작 시 자동 roll-forward, stale-activation-projection 실패를 통한 읽기 측 일관성 검증).
2. 공유 토큰에 대한 실제 락¶
병렬 에이전트는 같은 Command 토큰을 이중 소비하면 안 됩니다. 스토어 파일 락이 전진을 직렬화합니다: 동시 호출은 조용히 경쟁하는 대신 AIOS_REX_STORE_BUSY를 받습니다. 이는 SELECT ... FOR UPDATE와 같은 훈련입니다 — 병렬화할 수 없는 한 가지, 즉 다음 단계를 소유하는 주체를 직렬화합니다.
3. 암묵적 신뢰가 아닌 명시적 조정¶
병렬성에는 조정 레이어가 필요합니다: 명확한 소유권을 가진 독립 작업 패키지, 모니터링 (누가 막혀 있나?), 안전한 복구 (워커가 죽으면 어떻게 되나?). AIOS의 Agent Team 라우트는 작업을 수용 기준이 있는 독립 패키지로 나누고 live 상태를 보여주는 HUD를 제공합니다; Solo Harness는 저널과 stop/resume과 함께 하나의 긴 목표를 위한 워크트리 격리를 제공합니다 — 목적이 다른 두 도구입니다.
경험 법칙¶
작업이 독립 상태를 가진 독립 패키지로 나뉠 때 병렬 에이전트를 쓰세요. 결합된 변경은 순차적으로 유지하세요 — 워크플로 정책이 이미 그렇게 합니다 (planned 라우트, 결합 변경은 한 클라이언트에 유지). 두 에이전트가 같은 활성화, 토큰, 증거를 건드려야 한다면 병렬 작업이 두 개가 아니라 경쟁 조건이 있는 작업 하나입니다.
안전한 시작 순서¶
aios init --all
aios doctor --native --verbose
독립 작업 패키지와 HUD 모니터링은 Agent Team 가이드, 워크트리 격리로 재개 가능한 장기 작업은 Solo Harness 가이드, 결합 변경이 언제 순차적으로 유지되어야 하는지는 워크플로 정책을 읽으세요.
FAQ¶
그럼 워크트리 사용을 중단해야 하나요?¶
아니요. 워크트리는 훌륭한 파일 수준 격리 메커니즘입니다. 요점은 충분하지 않다는 것입니다: 그 위에 트랜잭션 상태와 명시적 조정을 더하지 않으면, 병렬성이 파일 충돌이 절대 못 미치는 방식으로 당신을 물어뜯을 것입니다.
에이전트들이 상태를 공유하는지 어떻게 알 수 있나요?¶
워크트리 밖에 무엇을 쓰는지 확인하세요: 공유 .aios 디렉터리, 락 파일, 레지스트리, 또는 "지금 어느 단계인지" 기록하는 것. 두 에이전트가 같은 파일을 읽고 쓸 수 있다면 상태를 공유하는 것입니다.
병합 큐만으로 충분한 조정 아닌가요?¶
병합 큐는 코드를 조정합니다 — 브랜치가 언제 병합되는지. 상태는 조정하지 않습니다 — 누가 계획 토큰을 전진시키고, 누가 검증을 소유하는지. 둘 다 필요합니다.
세부 내용은 어디서 볼 수 있나요?¶
Changelog에 v5.4.0 상태 강화 릴리스들이 정리되어 있고, 릴리스 게시물 Workflow Iteration v2.1이 닫히고 있는 동시성 실패 모드를 설명합니다.
병렬성은 증폭기입니다 — 처리량에 대해서도, 손상에 대해서도. 파일은 어떤 수단을 써서든 격리하세요. 상태를 격리하지 않으면, 에이전트들이 최악의 방식으로 당신 대신 격리해 버릴 것입니다.