자동 저작 전 Git 사본 동기화

2026-10-02 기준으로 자동 저작 흐름은 모델을 호출하기 전에 작업 사본을 원격 기본 브랜치로 fast-forward하고, 갱신할 수 없으면 종료 코드 1로 저작을 시작하지 않도록 고쳤어요. 사본이 오래됐다는 사실을 저작이 끝난 뒤에 발견하면, 잘못된 분류나 규칙을 근거로 작업을 중단하거나 초안을 만들 수 있기 때문이에요.

오래된 작업 사본이 만드는 증상

자동 저작은 카테고리 목록, 형식 규칙, 검증 조건처럼 저장소 안의 문서를 입력으로 읽어요. 작업 사본이 갱신되지 않으면 현재 규칙에는 있는 값을 예전 목록에서 찾지 못하고, 저작기는 소재가 아니라 규칙 충돌 때문에 멈출 수 있어요.

이번 작업 기록에서도 실험 레인이 현재 목록에 있는 카테고리를 예전 사본에서 찾지 못해 스스로 중단했어요. 원인은 새 카테고리나 소재가 아니라, 사본이 2026-09-08 상태에 머물러 있었고 갱신 절차가 없었던 데 있었어요.

이 문제는 단순히 최신 기능을 못 쓰는 수준에서 끝나지 않아요. 같은 입력을 다시 넣어도 어느 작업 사본이 실행되느냐에 따라 카테고리 판정과 후속 흐름이 달라져요.

저작 전제인 규칙 집합이 고정되지 않았으므로, 초안 품질을 검토해도 출발점이 흔들린 상태예요.

표는 2026-10-02 기준이에요. 여기서 중요한 관찰은 ‘뒤처짐’과 ‘분기’를 같은 성공 조건으로 취급하지 않았다는 점이에요. 뒤처진 사본은 원격의 이력을 그대로 따라갈 수 있지만, 분기된 사본은 어느 쪽 변경을 기준으로 저작해야 하는지 자동화가 결정하면 안 되는 상태예요.

저작보다 앞선 fast-forward 검사

고친 흐름은 발행 스위치와 주간 상한을 확인한 직후, 모델 호출보다 앞에 사본 갱신을 배치해요. 원격 기본 브랜치를 가져온 뒤 fast-forward만 허용하는 갱신을 시도하고, 실패하면 저작 단계로 내려가지 않아요.

Git에서 fast-forward 전용 동작은 현재 브랜치가 대상 이력의 조상일 때만 브랜치 포인터를 앞으로 옮겨요. 병합 커밋을 만들지 않고 갱신할 수 없는 경우를 거절한다는 뜻이라, 분기된 사본을 조용히 합쳐서 규칙의 출처를 흐리는 일을 피할 수 있어요. 세부 동작은 Git의 git pull --ff-only 문서에서 확인할 수 있어요.

fetch_remote_default_branch

if ! fast_forward_only; then
  exit 1
fi

start_authoring

핵심은 명령 한 줄보다 순서예요. 모델 호출이나 소재 선택이 먼저면, 이미 오래된 규칙을 읽은 뒤라 실패를 되돌려도 작업 시간과 로그가 남아요. 반대로 입력 사본을 먼저 확정하면 이후 단계는 같은 규칙 집합을 전제로 움직여요.

다만 모든 실행 환경에 사본이 있는 것은 아니에요. 작업 기록은 테스트 환경처럼 사본이 없는 경우에는 이 단계를 건너뛰도록 했어요.

사본이 없다는 사실과 사본이 있는데 갱신할 수 없다는 사실은 다르기 때문이에요. 전자는 이 검사 대상이 없다는 뜻이고, 후자는 오래된 규칙으로 저작할 위험 신호예요.

실패를 저작 실패로 섞지 않는 경계

갱신 실패 뒤에도 모델을 호출해 초안을 만들면, 나중에 보이는 실패는 콘텐츠 문제인지 규칙 사본 문제인지 구분하기 어려워져요. 이번 변경은 갱신 실패를 종료 코드 1로 끝내고 저작과 후속 흐름을 시작하지 않게 했어요.

이 경계는 실패를 숨기는 방식이 아니에요. 오히려 실패 원인을 ‘사본을 신뢰할 수 없음’으로 좁혀서 운영자가 복구할 대상이 콘텐츠인지 작업 환경인지 판단하게 해요. 사본이 분기된 경우 자동 병합을 시도하지 않은 것도 같은 이유예요.

저작 자동화에서 작업 사본은 편의를 위한 캐시가 아니라 규칙의 입력이에요. 따라서 갱신 실패를 재시도 횟수나 모델 품질로 보정하려 하기보다, 저작 시작 조건을 만족하지 못한 상태로 처리하는 편이 더 안전해요.

회귀 테스트로 남긴 조건

이런 수정은 정상 경로만 확인하면 쉽게 되돌아가요. 작업 기록은 로컬 원격을 기준으로, 사본이 한 커밋 뒤처진 경우에는 기본 브랜치까지 전진하는지 확인했어요.

반대로 사본이 분기된 경우에는 종료 코드 1로 끝나며 저작과 후속 흐름을 시작하지 않아야 해요. 이 조건이 없다면 fast-forward 전용이라는 이름만 남고, 실제로는 분기된 사본으로 저작을 계속할 수 있어요.

마지막으로 갱신 로직을 제거한 변이에서 테스트가 실패하는지도 확인했어요. 테스트 284건 통과와 실패 0건, 셸 구문 검사는 변경 직후의 결과일 뿐이에요.

‘갱신이 안 되면 저작하지 않는다’는 경계가 다음 수정에서도 테스트로 계속 검증된다는 점이 더 중요해요.

이 방식은 사본을 항상 최신으로 만들겠다는 약속보다 좁고 명확해요. 최신 상태를 만들 수 있을 때만 저작을 시작하고, 만들 수 없는 분기 상태는 원인을 해결할 때까지 입력으로 쓰지 않는 방식이에요.