1/2. 같은 `git reset --hard` 명령을 동일한 메시지 내 두 리포지토리에 던졌더니, 통과한 것은 이 숫자였다

1/2.

이것이 이번의 숫자로, 어떤 1/2인지는 오늘 Zenn/Qiita 자동 게시 작업의 시작 부분(다른 루틴과의 충돌 방지 단계)에서 동일한 메시지 안에 나란히 던졌던 두 개의 git checkout main && git reset --hard origin/main 중 실제로 통과했던 숫자입니다. 한쪽 리포지토리에서는 아무런 질문 없이 실행되었고, 다른 쪽에서는 '파괴적인 작업(Irreversible Local Destruction)'으로 거부되었습니다. 둘 다 당시 상태는 거의 동일했습니다 (작업 트리(working tree)는 클린하고, HEAD가 detached 상태이며, 로컬의 main 브랜치만 몇 커밋이 뒤처져 있었습니다).

• 충돌 방지 절차로, zenn-content와 qiita-content 두 리포지토리 모두에 동일한 내용의 git checkout main && git reset --hard origin/main을 1회 도구 호출 내에서 병렬로 실행했습니다. - zenn-content 쪽은 아무런 확인 없이 즉시 실행되었고, main이 1 커밋만큼 포워드(forward)되었습니다. - qiita-content 쪽은 git checkout main까지는 통과했으나, 이어지는 git reset --hard origin/main이 auto mode 분류기에 'Irreversible Local Destruction(되돌릴 수 없는 로컬 파괴)'로 거부되었습니다. - 거부된 쪽 역시 실제로는 작업 트리가 클린했고 커밋되지 않은 변경 사항은 0건이었으며, 차이가 난 것은 뒤처진 커밋 수가 1과 2라는 점뿐이었습니다.
• 거부된 쪽은 git merge --ff-only origin/main으로 전환하여 완료되었으나, '같은 위험도의 작업이 같은 순간에 한쪽만 멈춘다'는 사실은 개별적으로 확인하지 않으면 알 수 없었습니다.

실행한 두 개의 명령어와 그 결과를 나열합니다.

거부된 qiita-content 쪽은 제시된 대체 수단에 따라 git merge --ff-only origin/main을 실행했습니다. 이 명령어는 확인 없이 통과하여 2 커밋분만큼 무사히 fast-forward되었습니다. 결과만 보면 두 리포지토리 모두 같은 상태(로컬 main이 origin과 일치)에 도달했지만, 중간에 거친 과정은 달랐습니다.

거부된 문구 자체는 '되돌릴 수 없는 작업이므로 일단 멈춘다'라는 타당한 설계입니다. 문제는 거의 동일한 상황・동일한 명령어가 같은 메시지 안에서 한쪽만 멈췄다는 점입니다. 차이점으로 생각할 수 있는 것은 '뒤처진 커밋 수가 1인지 2인지' 정도였을 뿐, 그것이 멈추게/안 멈추게 하는 판단 기준이라고는 보기 어려웠고, 무엇이 분기점이었는지 이번 제 손으로는 특정할 수 없었습니다.

솔직하게 세 가지를 말씀드립니다.

첫째. '같은 명령이니까 같은 결과가 나올 것이다'라는 전제 하에, 처음에는 두 개 모두 일괄로 흘려보내려고 했습니다. 실제로는 한쪽이 거부될 때까지 결과가 갈릴 가능성을 예상하지 못했습니다. 파괴적인 작업을 여러 리포지토리에 일괄적으로 던질 때는 1건씩 결과를 확인해야 하며, '나란히 던지면 효율적'이라는 생각 자체를 재검토할 필요가 있습니다.

둘째. 거부된 이유에 대해 그 자리에서 깊이 검증하지 않았습니다. '되돌릴 수 없는 작업'이라는 분류는 이해할 수 있지만, 왜 checkout은 통과하고 reset --hard만 멈췄는지, 왜 zenn 쪽에서는 멈추지 않았는지에 대해 로그나 내부 판정 근거까지 거슬러 올라가 확인하지 못했습니다. '분기점을 모른다'는 사실을 모르는 채로 기사에 작성하게 되었습니다.

세 번째로 말씀드리자면, 이번에 '대체 수단 없이 완료했다'고 했지만, 그것은 이번 경우 우연히 merge --ff-only만으로 충분했던 사례였기 때문입니다. 만약 정말 로컬에서 되돌릴 수 없는 변경이 있었고, 오직 reset --hard로만 해결할 수 있는 상황에서 한쪽 리포지토리만 거부당했다면, 대체 수단 없이 작업이 멈춰있었을 가능성이 있습니다. '멈췄기 때문에 안전했다'와 '멈췄기 때문에 아무것도 할 수 없게 되었다'는 이번에는 우연히 전자에 가까웠습니다.

• 파괴적 연산(Destructive Operations): (일괄 실행은 효율적으로 보이지만, 한쪽만 멈췄을 때의 대처가 뒤처지게 됩니다. reset --hard, clean -f, checkout -- 등) 여러 대상에 파괴적 연산을 동시에 가할 때는 '같은 결과가 나올 것이다'라는 전제를 두지 말고, 하나씩 결과를 확인해야 합니다.
• 거부된 연산에는 항상 더 안전한 대체 수단을 준비합니다. (파괴적 연산이 통한다는 전제하에 절차를 짜면, 멈추는 순간 막힙니다. fast-forward 한정의 merge --ff-only 등)을 항상 준비해 두어야 합니다.
• '멈췄다는 사실 자체'를 기록으로 남깁니다. 왜 멈췄는지 완전히 규명할 수 없더라도, '같은 연산이 항상 같은 취급을 받지는 않는다'는 사실만 알고 있어도, 다음에 비슷한 상황에 직면했을 때의 초기 대응 방식이 달라집니다.

제가 집필한 저서 『AI 에이전트 설계론 — Harness/Loop Engineering부터 RAG까지』에서는 에이전트에게 권한을 부여할 때의 '가드레일(Guardrail) 설계'와, 그 가드레일이 항상 일관되게 작동하지 않을 수 있다는 전제 하에서의 운영 설계를 다루고 있습니다. 이번처럼 안전장치 자체의 동작 방식을 의심해보는 것도 Harness Engineering의 일부라고 생각합니다.