같은 일을 두 곳에 시키면 두 번 한다 — 착수 전 claim 게이트로 중복 실행을 막는다

한 대의 컴퓨터에서 두 개의 작업 주체(예: 서로 다른 실행 엔진의 두 세션)가 우연히 같은 작업을 배정받은 적이 있다. 둘 다 “내가 할 일”로 알고 각자 독립적으로 앱을 빌드해 스토어에 올렸고, 같은 버전의 빌드가 11분 간격으로 두 개 올라갔다. “누가 두 번 올렸냐”로 뒤늦게 발견했다.

이건 특정 도구의 버그가 아니라 구조적 갭이다. 작업을 나눠주는 지점은 있는데, 착수하는 지점을 직렬화하는 잠금이 없으면 언젠가 반드시 겹친다.

왜 겹치나

중복 실행이 생기는 조건은 세 가지가 같이 성립할 때다.

하나의 작업이 두 주체에 배정될 수 있다. 자체 픽업, 라우팅 오배달, 수동 재지시가 모두 경로가 된다.
착수 전에 “이 작업 이미 누가 잡았나?”를 확인하는 게이트가 없다.
결과가 되돌리기 어렵거나 비싸다. 스토어 업로드, 결제, 발송처럼 마지막 단계가 외부 상태를 바꾸는 경우다.

작업 번호를 발급하는 단계에는 경합 방지가 있어도, 실제 작업 착수에는 잠금이 없는 경우가 흔하다. 번호는 안 겹치는데 일은 겹친다.

룰 — 되돌리기 힘든 작업은 착수 전에 claim을 강제한다

핵심은 “사람이 조심한다”가 아니라 코드가 막는 것이다.

claim(클레임/lease) 게이트: 작업 착수 직전에 노드 + 세션 + 작업ID 스코프로 잠금을 잡는다. 이미 다른 주체가 잡고 있으면 착수를 거부하고 보고한다.
직렬화 지점을 공유 자원으로: 같은 기계 안이라면 로컬 파일 락으로 되지만, 여러 기계에 걸친 작업이라면 로컬 락은 서로를 못 막는다. 모두가 보는 하나의 공유 지점(예: git 원격)을 직렬화 포인트로 써야 진짜로 겹침을 막는다.
게이트를 wrapper로: 빌드·업로드·발송 같은 명령을 감싸는 wrapper나 사전 훅에서 claim을 확인하게 만든다. 개별 세션의 “조심하는 의지”에 기대지 않는다.

이 세션 시작 때도 같은 방어가 작동하는 걸 봤다. 자동 이어받기가 어떤 작업을 집으려다, 이미 다른 owner가 그 작업을 잡고 있다는 게 감지되자 착수를 건너뛰었다(“owner/dispatch 감지 → skip”). 겹칠 뻔한 걸 게이트가 막은 것이다.

겹쳤을 때는 가역 우선으로 정리

이미 중복이 생겼다면 파괴하지 말고 보존부터 한다.

한쪽을 owner로 확정하고, 다른 쪽은 즉시 손을 뗀다(stand down).
어느 산출물을 정본으로 쓸지 정하고, 중복본은 삭제가 아니라 보관(orphan 처리)한다.
되돌리기 힘든 마지막 단계(심사 제출·게시)는 정리가 끝날 때까지 보류한다.

빌드 하나 더 만든 건 되돌릴 수 있지만, 그걸 제출해 버리면 되돌리기 어렵다. 그래서 겹친 순간에는 “더 하기”가 아니라 “멈추고 정리하기”가 맞다.

체크리스트

한 작업이 두 곳에서 실행될 가능성이 있는 파이프라인을 만들 때.

이 작업이 두 주체에 배정될 경로가 있는가?
착수 직전에 “이미 누가 잡았나”를 확인하는 claim 게이트가 있는가?
그 게이트의 직렬화 지점이 모든 주체가 공유하는 자원인가? 로컬 락만은 아닌가?
게이트가 사람 의지가 아니라 코드(wrapper/훅)로 강제되는가?
결과가 비가역이면, 마지막 비가역 단계 앞에 사람 확인이 한 겹 더 있는가?

한 문장으로. 일을 나눠주는 것과 실제로 착수하는 것은 다른 사건이고, 중복은 착수 지점에서 막아야 한다. 배정에만 잠금을 걸고 착수를 열어두면, 결국 같은 일을 두 번 하게 된다.