두 개의 코딩 에이전트 (coding-agent) 작업이 커밋 A에서 시작됩니다. 작업 X는 인증 (authentication)을 수정하고, 작업 Y는 로깅 (logging)을 수정합니다. 두 작업이 실행되는 동안, 사람이 커밋 B를 푸시합니다.

만약 패치 (patches)가 자신의 베이스 (base)를 식별하지 못한다면, “둘 다 적용 (apply both)”하는 것은 안전하지 않습니다. 병렬 에이전트 세션은 단순히 속도에 관한 기능이 아니라 일관성 (consistency)의 문제입니다.

다음은 MonkeyCode SaaS에 대한 블랙박스 실험이며, 해당 서비스의 동시성 (concurrency) 구현에 대한 주장이 아닙니다.

네 가지 불변량 (invariants) 정의

1. 모든 결과는 불변의 베이스 A와 연관되어야 한다.
2. X는 Y의 커밋되지 않았거나 생성된 파일을 관찰할 수 없다.
3. 각 작업은 허용된 범위 내에서만 변경을 수행한다.
4. 브랜치 드리프트 (Branch drift)가 베이스를 조용히 변경해서는 안 된다.

일회성 저장소 (disposable repository)를 구축합니다:

src/auth.py          tests/test_auth.py
src/logging.py       tests/test_logging.py
TASK_X_SENTINEL.txt  TASK_Y_SENTINEL.txt

A 상태에서 두 테스트가 독립적으로 실패하도록 만듭니다.

작업 X는 인증 파일만 수정할 수 있고, 작업 Y는 로깅 파일만 수정할 수 있습니다. 두 작업 모두 센티넬 (sentinel) 파일을 변경하는 것은 금지됩니다. 요구사항 해시 (requirement hashes)와 전체 베이스 SHA를 기록합니다.

워크플로가 허용하는 한 최대한 동시에 두 작업을 시작합니다. 작업이 활성화된 동안, 관련 없는 문서 커밋 B를 푸시합니다.

다음 내용을 캡처합니다:

task_id: "<id>"
requested_base: "<A>"
reported_or_inferred_base: "<SHA or unknown>"
...

unknown은 정직한 관찰 결과이지만, 도입 단계의 관문 (adoption gate)을 통과하지 못할 수도 있습니다.

조합 전 테스트 격리 (Test isolation before composition)

A의 깨끗한 체크아웃 (clean checkouts) 상태에 X와 Y를 각각 별도로 적용합니다. 허용된 파일, 집중된 테스트, 관련 없는 피스처 (fixture), 그리고 센티넬을 확인합니다.

그 다음 두 가지 순서를 평가합니다:

A + X + Y
A + Y + X

각 순서 후에 두 테스트를 실행합니다. 만약 한 가지 순서만 작동한다면, 해당 작업들은 반드시 표현되고 검토되어야 하는 의존성 (dependency)을 가지고 있는 것입니다.

이제 B + X + Y를 테스트합니다. 깨끗한 적용, 명시적인 충돌, 또는 B로부터 재실행 요청이 발생하는 것은 모두 합리적일 수 있습니다. 베이스가 조용히 교체되는 것은 합리적이지 않습니다.

마지막으로, 의도적으로 동일한 라인을 수정하는 두 개의 작업을 생성합니다. 요구되는 속성은 마법 같은 자동 병합 (automatic merge)이 아니라, 눈에 보이는 충돌과 재실행 증거입니다.

출처: MonkeyCode repository 및 SaaS.

한계: 두 개의 작업은 부하 테스트(load test)가 아니며, 프로세스 또는 테넌트(tenant) 수준의 격리를 증명할 수 없습니다.

공개 사항: 저는 MonkeyCode 사용자로서 저의 개인적인 경험을 공유하는 것이며, 해당 프로젝트와 관계가 없습니다. 이 글은 동일한 운영자에 의해 관리되는 계정에서 발행된 여러 독립적이고 유용한 기술 문서 중 하나이며, 독립적인 보증이 아닙니다.

어떤 이벤트가 새로운 베이스로부터의 재시작을 강제해야 할까요: 인간의 커밋 B, 중첩되는 패치들, 아니면 둘 중 하나일까요?