dry-run이 하트비트 마커를 건드리면 감시가 거짓말을 해요

파이프라인에 감시 장치를 붙여 두면 마음이 놓입니다. 마지막 성공 시각을 파일에 찍어 두고, 그게 오래 묵으면 알림이 오게 해 두는 식이죠. 그런데 이 구조를 직접 돌려 보니, 감시 장치가 조용히 거짓말을 하는 경로가 하나 있었어요.

미리보기가 성공을 흉내 낸다

dry-run은 실제로 아무것도 적재하지 않고 "이렇게 될 겁니다"만 보여주는 모드예요. 문제는 그 실행이 본 실행과 같은 코드 경로를 타면서 마지막 성공 마커까지 같이 갱신해 버린다는 점이었습니다.

이러면 이렇게 됩니다. 본 실행이 며칠째 실패하고 있어도, 누군가 확인차 dry-run을 한 번 돌리면 마커 시각이 지금으로 바뀝니다. 감시는 "최근에 잘 돌았네요" 하고 침묵해요.

본 실행 실패→확인용 dry-run 실행→마커 갱신→감시 침묵→아무도 모름

9월 7일 밤에 이 부분을 두 갈래로 나눠 고쳤어요. 하나는 dry-run일 때 마커를 아예 건드리지 않게 하는 것, 다른 하나는 실행 기록에 dry_run 플래그를 남겨서 나중에 "이건 미리보기였다"를 구분할 수 있게 한 것이었습니다. 커밋 하나에 로더와 테스트 두 종류, 총 3개 파일이 같이 움직였어요.

죽은 감시 항목이 더 위험해요

비슷한 결의 문제를 하나 더 만났습니다. 7월에 정지시킨 잡이 감시 목록에는 그대로 남아 있었어요. 매번 DOWN이 뜨는데, 실제로는 "멈추기로 한 것이 멈춰 있는" 정상 상태였죠.

이런 항목이 하나 끼어 있으면 알림 전체가 무뎌집니다. DOWN 표시를 보고도 "아, 그거 원래 그래요" 하고 넘기게 되거든요. 그러다 진짜 죽은 잡이 생겨도 같은 반응을 하게 됩니다. 9월 11일에 감시 스크립트에서 해당 항목을 제거했어요. 파일 한 개 수정으로 끝나는 일인데, 미루는 동안 알림 신뢰도만 깎였습니다.

• ✓dry-run은 마커 미갱신
• ✓실행 기록에 모드 플래그
• ✓정지한 잡은 감시 목록에서 제거

상태 파일을 고칠 때 확인한 것

테스트해 보면 감이 오는데, 이런 종류의 수정은 "코드가 통과한다"로는 부족해요. 실제로 상태 파일을 열어서 값이 안 바뀌었는지 눈으로 봐야 합니다.

제가 확인한 순서는 이랬어요.

1. 마커 파일의 현재 시각을 적어 둡니다
2. dry-run을 돌립니다
3. 마커 파일을 다시 열어 시각이 그대로인지 봅니다
4. 본 실행을 돌려서 이번엔 갱신되는지 봅니다

4단계면 충분합니다. 2번과 3번 사이에서 값이 바뀌면 수정이 안 된 거예요. 테스트 코드만 보고 넘겼다면 놓쳤을 부분입니다.

배운 것

감시 장치를 만들 때는 "어떤 실행이 성공으로 기록되어도 되는가"를 먼저 정해야 해요. 이걸 정하지 않으면 미리보기, 재시도, 부분 실행 같은 것들이 전부 성공 신호를 남길 수 있습니다.

상태를 남기는 코드에는 모드 정보를 같이 남기는 게 안전해요. 나중에 로그를 볼 때 "이 성공은 진짜였나"를 되물을 수 있으니까요.

혼자 개발하다 보면 이런 감시 배선을 대충 넘기기 쉬운데, 조용히 썩은 감시는 없는 것보다 나쁩니다. 저는 계산기 도구인 플랜씨(plan-c)처럼 사용자가 바로 결과를 보는 서비스에는 이런 문제가 덜 생기는 반면, 백그라운드에서 도는 파이프라인은 아무도 안 보는 사이에 조용히 멈춰 있을 수 있다는 걸 이번에 다시 확인했어요.

다음은 마커가 오래 묵었을 때 알림이 실제로 오는지를 한 번 더 확인해 볼 차례입니다.