dry-run이 데드맨 마커를 건드리면 생기는 가짜 초록불

혼자 자동화를 굴리면서 제일 무서운 상황은 실패가 아니에요. 조용히 멈춰 있는데 감시기는 초록불인 상태예요. 이번 주에 그 구멍을 하나 만들었다가 7분 만에 메웠어요. 만든 커밋이 밤 10시 17분, 고친 커밋이 10시 24분이었거든요.

어떤 파이프라인이었나

플랜씨나 플랜엘 같은 서비스를 만드는 것 말고도, 라이프케어로그는 마케팅용 일일 브리프를 정제해서 DB에 쌓는 배치를 하나 돌려요. 매일 아침 10시 50분에 launchd가 스크립트를 깨우고, 원문을 읽어 항목별로 나눈 뒤 적재하는 구조예요.

원문 브리프 읽기→항목 파싱→DB 적재→데드맨 마커 갱신→별도 검사기가 마커 시각 확인

여기서 데드맨 마커는 "마지막으로 진짜 성공한 시각"을 적어 두는 파일이에요. 검사기는 실행기와 다른 경로에서 돌면서 이 시각만 봐요. 너무 오래됐으면 알림을 보내죠. 실행기가 아예 안 깨어나도 잡을 수 있게 분리한 거예요.

적재 기능을 붙인 커밋은 파일 5개를 건드렸어요. 적재기, 파이프라인 본체, 실행 진입점, DB 실행 헬퍼, 그리고 테스트 픽스처 하나요.

미리보기가 성공으로 보이던 문제

실제 적재 전에 결과만 확인하는 --dry-run 옵션이 있어요. 백필을 앞두고 42개 파일을 미리보기로 돌려 보니 출력은 멀쩡했어요. 그런데 마커 파일의 갱신 시각이 방금으로 바뀌어 있더라고요.

곰곰이 따져 보니 당연한 결과였어요. 마커 갱신을 "스크립트가 끝까지 돌았을 때"에 걸어 뒀는데, dry-run도 끝까지 도니까요. 검사기 입장에서는 DB에 한 줄도 안 들어갔는데 방금 성공한 것처럼 보이는 거예요. 아침 실행이 며칠 죽어 있어도 제가 미리보기만 한 번 돌리면 알림이 안 울려요.

고친 것 두 가지

수정은 파일 3개짜리 작은 커밋이었어요. 적재기 하나와 테스트 둘이요.

• ✓마커 갱신은 실제 적재 경로에서만
• ✓dry-run 기록엔 dry_run 플래그
• ✓검사기는 실행기와 다른 경로 유지

첫째, 마커 갱신을 "끝까지 돌았다"가 아니라 "실제로 썼다" 뒤로 옮겼어요. dry-run은 성공이 아니라 아무것도 안 한 상태라서 시각을 남길 자격이 없어요.

둘째, 실행 기록을 남기는 ledger 행에 dry_run 플래그를 넣었어요. 나중에 이력을 볼 때 미리보기와 실적재가 섞이면 또 같은 착각을 하게 되거든요.

테스트는 먼저 썼어요. dry-run 실행 뒤 마커의 수정 시각이 그대로여야 한다는 단언을 넣고, 빨간불을 확인한 다음 적재기를 고쳤어요. 셸 통합 테스트와 파이썬 단위 테스트 양쪽에 같은 조건을 뒀어요.

혼자 만들 때 남는 교훈

직접 만들어 보니 감시 장치는 붙이는 것보다 무엇을 성공으로 칠지 정하는 게 어렵더라고요. 성공 신호는 되돌릴 수 없는 부작용이 실제로 생긴 지점에서만 나와야 해요. 로그가 찍혔다, 종료 코드가 0이다, 이런 건 성공이 아니에요.

플랜씨 계산기처럼 로그인 없이 바로 쓰는 화면은 고장 나면 사용자가 바로 알려 줘요. 뒤에서 도는 배치는 아무도 안 봐요. 그래서 검사기를 실행기와 다른 경로에 두고, 실행기 안의 어떤 모드도 검사기를 만족시킬 수 없게 막아 두는 게 1인 운영의 최소 안전장치라고 느꼈어요.

미리보기 모드를 가진 스크립트가 있다면 한 번 테스트해 보면 좋아요. dry-run 뒤에 상태 파일이 바뀌는지만 확인하면 돼요.