두 코딩 에이전트가 같은 파일을 읽고 각각 수정했습니다. 마지막 저장이 앞선 변경을 덮지 않게 어떻게 통합하나요?

각 작업자가 어떤 기준 버전을 읽었는지와 어느 파일·기능을 소유하는지 명확히 해야 합니다. 같은 파일을 무조건 마지막 쓰기로 저장하면 앞선 변경을 잃을 수 있습니다. 작업 범위를 분리하거나 독립 브랜치·작업 트리를 사용하고, 반영할 때 현재 버전과 기준 버전을 대조해 충돌을 검출하겠습니다. 모델이 서로 대화한다고 저장소 동시성이 자동 해결되지는 않습니다.

격리와 통합은 다른 단계

독립 worktree는 파일 덮어쓰기를 줄이지만 최종 병합 충돌과 의미 충돌까지 없애지는 않습니다. 한 작업자가 함수 인자를 바꾸고 다른 작업자가 옛 인자로 새 호출자를 만들면 Git 충돌 없이도 빌드가 깨질 수 있습니다. 공유 인터페이스 변경은 한 통합자가 결정하고 하위 작업에는 고정된 계약을 전달해야 합니다. 겹치는 변경이 발견되면 최신 파일을 다시 읽고 의도를 합쳐야지 무조건 한쪽을 선택하지 않습니다.

파일 편집 API에 기준 해시나 정확한 이전 문자열 조건을 둘 수 있습니다. 읽은 뒤 바뀌었으면 쓰기를 거절하고 새 내용을 기반으로 다시 수정합니다. 충돌 감지를 피하려고 강제 덮어쓰기 옵션을 쓰면 사용자의 다른 변경을 잃을 수 있으므로, 명시적으로 폐기할 버전을 승인받은 경우와 단순 병합을 구분합니다. 문서·원격 artifact의 버전 저장도 같은 원칙이 적용됩니다.

검증은 통합 결과에서 수행합니다

각 작업자의 테스트가 통과해도 합친 결과에서는 다시 테스트해야 합니다. 단위 테스트뿐 아니라 인터페이스·스키마·사용자 흐름의 연동을 확인하고, 변경이 누락됐는지 diff와 원래 요구 목록을 대조합니다. 통합자의 역할은 메시지를 합치는 것이 아니라 최종 파일과 실행 상태에 책임지는 것입니다. 하위 작업이 아직 실행 중이면 그 결과를 예측해서 완료로 보고하지 않습니다.

작은 수정에는 여러 writer를 쓰는 비용이 더 클 수 있습니다. 읽기 검토는 병렬화하고 실제 구현은 한 writer가 맡는 구조를 기준선으로 둘 수 있습니다. 분할한다면 파일 경계가 아니라 공유 불변식과 의존 관계도 봅니다. 시험은 동시 저장, rename·삭제, 공통 타입 변경, 통합 뒤 테스트 회귀를 포함합니다. 최종 목표는 충돌 메시지가 없는 것이 아니라 두 의도와 사용자의 기존 작업이 정확히 보존되는 것입니다.

실행 사례로 확인합니다

파일을 읽은 시점의 해시 H1과 현재 H2가 다르면 단순 문자열 치환이 우연히 가능해도 의미를 다시 확인할 필요가 있습니다. 다른 작업자가 같은 함수의 불변식을 바꿨을 수 있기 때문입니다. 큰 파일 전체를 덮는 방식보다 좁은 patch와 버전 조건은 의도하지 않은 삭제를 줄입니다. 작업 완료 알림을 받은 뒤에도 그 알림이 가리키는 commit이나 산출물 버전을 읽어야 나중 변경과 섞이지 않습니다. 최종 병합 후에는 기존 사용자의 변경이 보존됐는지 확인하고, 합쳐진 결과만 게시합니다. 각 작업자가 같은 원격 브랜치를 직접 푸시하는 구조보다 통합 지점을 하나로 두는 것이 결과와 책임을 추적하기 쉽습니다.