dry-run이 실행 흔적을 남기면 안 되는 이유

파이프라인에 미리보기 모드를 붙일 때 흔히 놓치는 게 있어요. 실제로 붙여 보니 dry-run이 "아무것도 안 하는 모드"가 아니더군요. 로그를 쓰고, 잠금을 잡고, 마지막 성공 시각을 갱신합니다. 앞의 둘은 괜찮은데 세 번째가 문제였어요.

미리보기가 감시 장치를 속이는 구조

9월 7일 밤 커밋 하나가 이걸 다룹니다. fix(p0c): dry-run은 deadman 마커 미갱신·ledger dry_run 플래그. 제목만 보면 사소한 플래그 추가 같지만, 실제로 뜯어 보면 감시 장치의 신뢰를 지키는 수정이에요.

데드맨 마커는 이런 식으로 동작합니다. 배치가 성공하면 마지막 성공 시각을 파일에 씁니다. 별도 감시 프로세스가 그 시각을 읽어서 N분 넘게 오래됐으면 알림을 보내고요. 루프가 조용히 멈췄을 때를 잡아내려는 장치입니다.

여기에 dry-run이 끼어들면 어떻게 되냐면, 진짜 배치는 3일째 죽어 있는데 제가 확인용으로 돌린 미리보기가 마커를 새로 갱신해버립니다. 감시 장치는 "방금 성공했네" 하고 조용히 넘어가요. 죽은 걸 알려주라고 만든 물건이 죽음을 가려주는 셈입니다.

배치 중단→dry-run 실행→마커 갱신→알림 미발생

세 겹으로 나눠 본 dry-run 경계

테스트를 짜면서 정리해 보니 dry-run이 건드려도 되는 것과 안 되는 것이 세 층으로 갈렸어요.

• 써도 되는 것: 원장(ledger) 기록. 대신 dry_run 플래그를 같이 남깁니다. 나중에 "이 줄은 미리보기였다"를 구분할 수 있어야 하니까요.
• 써도 되는데 조심할 것: 잠금. 미리보기끼리도 동시에 돌면 곤란하니 잠금은 잡되, 문장 단위 타임아웃을 걸어 뒀어요.
• 절대 쓰면 안 되는 것: 데드맨 마커. 그리고 실제 적재.

경계를 나누고 나니 같은 날 후속 커밋에서 다른 구멍도 보이더군요. --all 옵션이 날짜 파일뿐 아니라 *.body.md 같은 변종까지 집어삼키고 있었어요. 미리보기로 42개 파일을 훑어 보고 나서야 알았습니다. 미리보기가 미리보기 역할을 제대로 하려면, 먼저 미리보기 자체가 정직해야 한다는 게 좀 아이러니했어요.

직접 겪어 본 검증 순서

절차는 네 단계로 굳었습니다.

1. dry-run으로 대상 파일 목록을 뽑아서 눈으로 확인
2. 마커 파일의 수정 시각이 안 바뀌었는지 확인
3. 실제 실행
4. 원장에서 dry_run 플래그가 없는 줄만 세어서 대조

2번이 핵심이에요. 이걸 안 보면 1번을 아무리 꼼꼼히 봐도 소용없습니다. 실제로 테스트를 돌려 보니 마커 갱신 여부를 단언하는 테스트 한 줄이 나머지 전부보다 중요하더라고요.

• ✓원장은 기록
• ✓마커는 격리
• ✓플래그로 사후 구분

상태 파일을 다루는 일반 규칙

이번 건을 겪고 나서 규칙 하나로 접었어요. 어떤 모드든, 다른 시스템이 판단 근거로 삼는 파일은 건드리지 않는다. 마커는 감시 프로세스의 입력값이고, 그건 제 배치의 소유물이 아니에요. 남의 판단 근거를 마음대로 고치면 그 판단은 더 이상 판단이 아니죠.

같은 사고방식을 계산 결과 캐시나 마지막 동기화 시각에도 적용하고 있습니다. 예를 들어 플랜씨의 금융계산기처럼 로그인 없이 즉시 계산해서 보여주는 구조라면 이런 상태 파일 자체가 없어서 편한데, 배치 파이프라인은 상태를 들고 다닐 수밖에 없어요. 상태가 있으면 소유권을 먼저 정해야 합니다.

정리하면 이래요. dry-run은 "안 하는 것"이 아니라 "부작용의 범위를 좁힌 것"입니다. 어디까지 좁힐지는 코드가 아니라 감시 장치 쪽에서 역산해야 하고요. 감시가 무엇을 읽는지 먼저 알아야 무엇을 안 쓸지가 정해집니다.