위임은 일을 사람 수만큼 복제하는 기법이 아니라, 서로 기다리지 않아도 되는 증거 단위를 분리하고 하나의 통합자가 의미를 다시 확인하는 방식입니다. 따라서 시작할 때 작업 그래프, 각 작업의 반환 형식, 기준 버전을 먼저 고정해야 병렬성의 이득과 통합 비용을 함께 판단할 수 있습니다.
역할 수와 독립 증거의 수
작은 함수 수정에 설계자·작성자·검토자를 붙이면 문맥 전달과 통합이 구현보다 비쌀 수 있습니다. 독립된 공식 계약 조사·분리 모듈 검토처럼 결과를 합칠 기준이 명확한 작업을 먼저 나눕니다. 각 branch가 최종 판단을 바꿀 수 있는지, 다른 결과를 기다리는 의존성이 있는지 봅니다.
독립 조사 3개가 각 2분이고 통합 1분이면 이상적 wall time은 약 3분이나 작업 비용은 6분+통합입니다. 서로 같은 자료를 읽으면 오류도 상관될 수 있습니다. 단일 host 기준선과 성공·누락·중복 조사·통합 비용을 비교합니다.
실제 선택에서는 먼저 작업을 원자적인 질문으로 쪼갭니다. 예를 들어 “retry 계약의 최대 횟수”와 “호출자가 retry를 관찰하는 방법”은 자료가 다르고 결론도 독립적일 수 있지만, 같은 파일의 두 함수에 동시에 손대는 일은 독립 작업으로 세지 않습니다. 한 작업이 다른 작업의 미확정 사실을 기다려야 한다면 병렬 분할이 아니라 순차 의존성으로 기록합니다.
위임 목표·질문과 제외 범위
| 계약 | 구체 내용 |
|---|---|
| 역할·목표 | 특정 API의 retry 계약 확인 |
| 범위·제외 | 해당 module 읽기, 구현·게시 금지 |
| 확정 조건 | 고정 interface·현재 version·사용자 제약 |
| 권한·예산 | 읽을 자료·전송 범위·시간·호출 상한 |
| 반환 | 결론·근거 위치·재현 입력·실행 결과·미확인 |
| 중단 | 필요한 사실 확보·권한 차단·새 결정 발견 |
“테스트 통과”에는 명령·환경·결과가 필요하고 “위험한 경계”보다 “n=0에서 X:42 인덱스 오류, Y로 재현”이 통합 가능성이 높습니다. 의심과 확정 결함·제안과 실행을 나눕니다. 하위 작업이 새로운 설계 결정을 만나면 범위를 넓히지 말고 host에 돌려줍니다.
상태를 조사 중 → 근거 확보 → 결론/미확인 반환으로 추적하면 “완료”와 “실행하지 않음”을 구분할 수 있습니다. 예를 들어 명령을 실행하지 못한 하위 작업은 테스트 통과라고 보고할 수 없고, 실행 명령과 출력이 없는 결론은 host가 재현 가능한 증거로 취급하지 않아야 합니다.
공유 불변식과 통합 책임자
읽기 조사와 여러 writer의 코드는 다릅니다. 변경을 분할한다면 disjoint 소유권·고정 인터페이스·독립 worktree를 사용합니다. 한 branch가 함수 인자를 바꾸고 다른 branch가 옛 인자의 호출자를 추가하면 텍스트 충돌 없이 의미 충돌이 생깁니다. 파일 이름이 다르다고 독립적인 변경은 아닙니다.
그림을 글로 읽기
- host · 목표·공유 계약·권한
- 범위 A · 독립 증거/작업
- 범위 B · 독립 증거/작업
- 기준 버전·의미 충돌 검토
- 통합 diff·회귀·사용자 흐름
- host · 목표·공유 계약·권한 → 범위 A · 독립 증거/작업: 고정 계약
- host · 목표·공유 계약·권한 → 범위 B · 독립 증거/작업: 고정 계약
- 범위 A · 독립 증거/작업 → 기준 버전·의미 충돌 검토: 근거·실패 포함
- 범위 B · 독립 증거/작업 → 기준 버전·의미 충돌 검토: 근거·실패 포함
- 기준 버전·의미 충돌 검토 → 통합 diff·회귀·사용자 흐름: 최종 책임
통합 전에 인터페이스의 입력·출력·오류 의미를 작은 표로 고정하고, 각 변경이 그 표를 바꿨는지 확인합니다. 파일 충돌이 없어도 호출 규약, 직렬화 형식, version 의미가 달라졌다면 의미 충돌입니다. 이 검사는 diff의 줄 수보다 통합 후 실제 호출 흐름을 우선해야 합니다.
읽은 버전과 현재 버전의 의미 충돌 조정
파일 해시 H1을 읽었는데 현재 H2면 좁은 patch가 우연히 적용돼도 의미를 다시 봅니다. 정확한 old string·base hash·version 조건으로 덮어쓰기를 막고 현재 내용을 재조회해 의도를 합칩니다. 원격 문서 저장도 같은 원칙입니다. 충돌을 피하려 force overwrite하는 것은 사용자 변경을 버리는 별도 결정입니다.
rename·삭제·공통 타입 변경·사용자 미커밋 변경을 확인하고 한 통합 지점에서 반영합니다. worktree는 동시 파일 덮어쓰기를 줄이지만 최종 merge 정확성을 보장하지 않습니다. 각각 통과한 테스트도 합친 tree에서 다시 실행합니다.
진단 순서는 기준 버전 확인, 현재 파일 재조회, 변경 의도와 현재 변경의 교집합 계산, 통합 tree에서 회귀 실행 순서가 안전합니다. base가 달라졌는데도 patch를 강제로 적용하면 문법은 맞아도 새 필드의 기본값이나 호출 순서가 사라질 수 있으므로, 충돌이 없다는 결과만으로 안전성을 선언하지 않습니다.
결과 알림과 수용 심사
완료 알림이 가리키는 commit·산출물 version을 읽고 요구 충족·누락·모순·실제 실행을 대조합니다. 하위 보고의 “검증 생략 가능”은 상위 정책을 바꾸지 않습니다. 실패 branch가 필수 증거면 전체를 차단하고, 아니라면 제한된 결론에 누락을 표시합니다. 아직 실행 중인 결과를 예측해 완료라고 하지 않습니다.
근거가 충분하면 불필요한 새 branch를 만들지 않고 필요 없는 실행은 수명 계약에 따라 취소합니다. 이 노트는 위임·통합 설계이며 여러 에이전트를 실행해 속도 개선을 측정한 결과는 아닙니다.
수용 심사에서는 각 주장에 결론·근거·실행 여부·미확인 네 칸을 대응시킵니다. 예를 들어 “테스트 통과”에는 명령, 실행 환경, 실제 출력이 있어야 하고, “구현하지 않음”은 누락이 아니라 범위 계약을 지킨 결과일 수 있습니다. 필수 branch가 실패했다면 통합자는 성공 결과만 모아 전체 성공으로 바꾸지 않습니다.