이제 개발자들은 상태 파일이 덮어씌워지거나 숨겨진 파일 충돌이 발생할 걱정 없이 여러 코딩 에이전트 세션을 동시에 실행할 수 있습니다. 권고형(advisory) "share-nothing" 패턴은 각 에이전트의 작업 공간을 격리하고 잠재적인 충돌을 경고합니다. 이 방식은 하드 락(hard lock) 대신 가벼운 레지스트리를 사용하여 작업이 겹치기 전에 미리 알림으로써, 세션이 충돌하더라도 파이프라인이 계속 작동하도록 유지합니다.
병렬 에이전트가 문제를 일으키는 이유
단일 저장소에서 하나 이상의 자동화된 코딩 어시스턴트를 실행하면 코드 생성, 테스트 또는 리팩터링 속도를 높일 수 있습니다. 하지만 실제로는 두 가지 문제가 즉시 나타납니다.
- 상태 손상(State corruption) – 두 에이전트가 동일한 상태 파일에 기록을 시도합니다. 나중에 기록된 내용이 이전 내용을 덮어씌워 진행 상황이 삭제됩니다.
- 파일 충돌(File collision) – 두 에이전트가 서로의 존재를 모른 채 동일한 소스 파일을 수정합니다. 충돌은 나중에 diff를 통해 서로 다른 변경 사항이 나타날 때 발견됩니다.
두 문제 모두 개발자의 시간을 낭비하며 추적하기 어려운 버그를 유발할 수 있습니다.
"share nothing" 규칙
핵심 아이디어는 간단합니다. 각 에이전트는 디스크에 자신만의 전용 스크래치패드(scratchpad)를 가지며, 해당 세션에 속한 파일에만 기록합니다. 브랜치당 의도적으로 공유되는 파일은 단 하나만 허용되며, "마지막 기록자가 승리(last-writer-wins)" 규칙을 따릅니다. 즉, 마지막으로 기록을 수행한 에이전트가 최종 콘텐츠를 결정합니다.
**프레젠스 레이어(presence layer)**는 모든 활성 세션을 추적합니다:
- 브랜치 이름
- 수정 중인 파일 목록
- 마지막 활동 타임스탬프
새로운 세션이 시작되면 레지스트리를 조회합니다. 만약 다른 세션이 이미 동일한 파일 중 하나라도 처리하고 있다면, 개발자는 작업이 시작되기 전에 경고를 받게 됩니다.
권고형(Advisory) vs. 차단형(Blocking) 락
전통적인 락 파일은 막다른 길처럼 작동합니다. 일단 락이 걸리면 다른 프로세스는 락이 해제될 때까지 대기해야 합니다. 만약 락을 소유한 세션이 충돌하면 락이 무기한 남아있을 수 있으며, 이로 인해 오래된(stale) 락 파일을 수동으로 찾아 제거해야 하는 상황이 발생합니다.
권고형 모델은 더 유연합니다. 잠재적인 충돌이 감지되면 경고를 보내지만, 새로운 세션을 중단시키지는 않습니다. 레지스트리 항목이 오래된 경우(즉, 해당 항목을 생성한 프로세스가 더 이상 존재하지 않는 경우)에도 시스템은 경고만 보낼 뿐, 계속 진행할지 여부는 개발자가 결정하도록 합니다.
패턴 구현 방법
- 작성자별로 상태 분할 – 각 에이전트에게 임시 파일 및 상태를 위한 전용 디렉터리를 할당합니다. 공유 파일은 진정으로 전역적인 데이터용으로만 남겨두고, 해당 파일에만 "마지막 기록자가 승리" 규칙을 적용합니다.
- 시작 시 인지 기능 주입 – 에이전트가 시작되기 전에 프레젠스 레지스트리를 읽고 요청된 파일 목록을 기존 항목과 비교합니다. 중복이 발견되면 중단하거나 경고를 보냅니다.
- 읽기 시 생존 여부 확인 – 레지스트리 항목을 조회할 때, 기록된 프로세스 ID가 OS에서 여전히 실행 중인지 확인합니다. 종료된 프로세스에 속한 항목은 삭제합니다.
- 차단형보다 권고형 선호 – 개발자가 제어권을 유지할 수 있도록 합니다. 경고를 통해 개발자가 계속 진행, 일시 중지 또는 취소할 수 있게 하여 데드락(deadlock)을 방지합니다.
- 대기 상태 추적 – 많은 에이전트가 활성화되어 있으면 개발자의 주의력이 병목 현상이 됩니다. 어떤 에이전트가 사람의 입력을 기다리고 있는지 표시하여 작업의 우선순위를 재조정할 수 있도록 합니다.
이 모든 것은 단순한 JSON 파일 디렉터리로 구축할 수 있으며, 외부 데이터베이스나 메시지 버스가 필요하지 않습니다. 단순한 저장 형식 덕분에 시스템을 감사하기 쉽고 다양한 환경으로 이식하기 용이합니다.
위험 요소 및 반론
어떤 팀은 하드 락이 안전을 보장한다고 주장할 수 있습니다. 즉, 두 에이전트가 동일한 파일에 절대 기록할 수 없게 만드는 것입니다. 하지만 그 대가로 회복 탄력성(resilience)이 떨어집니다. 세션이 충돌하면 고아(orphaned) 락이 남아 전체 워크플로우를 중단시킬 수 있기 때문입니다.
주의 사항
여러 개의 AI 기반 코딩 어시스턴트를 동시에 사용하고 있다면, "share nothing" 권고형 패턴은 에이전트들이 서로의 작업을 방해하지 않도록 하는 실용적인 해결책을 제공합니다. 상태를 격리하고, 의도를 조기에 노출하며, 진행 여부를 사람이 결정하게 함으로써, 이 방식은 현대적인 개발 파이프라인이 요구하는 유연성과 안전성 사이의 균형을 맞춥니다.