단계 신호였던 0

복구 작업을 채널 하나에 돌리기 시작했는데 로그를 보니 이상한 점이 있었다. 복원은 계속 진행되는데 작업 삽입 건수가 0으로 찍히고 있었다.

Open Table of contents

중단 직전의 확인

대상 선별 로직에 버그가 있나 싶어 중단하고 되돌릴까 하다가 왜 0인지부터 확인하기로 했다. 로그에 찍힌 상품 식별자를 그대로 조회하니 연동 행 자체가 존재하지 않았다.

상품 테이블을 다시 보니 그 식별자들이 전부 마스터 상품이었다. 로그의 식별자를 직접 조회한 것이 대상의 성격을 바로 알려 준 셈이다.

실행 코드를 열어 보니 마스터를 전량 처리한 뒤에 마켓 자식 단계로 넘어가는 구조였다. 마스터는 연동 행이 없는 정본 상품이라 작업을 만들 필요가 없고 그래서 해당 플래그가 꺼진 채로 돈다.

즉 작업은 자식 단계에 진입해야 비로소 생긴다는 뜻이었다. 로그를 다시 훑으니 마스터 복구 시작이라는 줄과 전체 건수가 찍혀 있었고 아직 그 단계의 초반이었다.

결국 버그가 아니라 단계가 진행 중이라는 신호였다. 여기서 중단하고 되돌렸으면 정상 동작을 버그로 판단해 이미 처리한 것을 되돌리고 없는 버그를 찾느라 시간을 쓴 뒤 다시 돌려도 같은 것을 봤을 것이다.

오탐으로 판단해 중단하는 것 자체가 실제 손해이므로 실행 초반의 작업 0건은 마스터 단계가 진행 중이라는 신호이고 중단하지 않는다고 기록에 남겼다.

이 일을 겪고 나서 진행률을 보는 방법 자체를 바꿨다. 전에는 로그에서 특정 문구를 세었는데 문구가 바뀌면 안 잡히고 단계별로 문구가 다르면 헷갈리며 성공과 건너뜀과 오류가 섞여 있으면 못 가른다.

진행 기록을 결정 유형별로 집계하는 방식으로 바꾸니 필요한 숫자가 한 번에 갈려서 나온다. 로그 문구에 의존하지 않으므로 문구가 바뀌어도 그 집계는 그대로 쓸 수 있다.

진행률을 주기적으로 보려고 만든 셸 스크립트가 카운트를 산술로 모으는 자리에서 죽었다. 값이 비거나 숫자가 아닐 때 산술이 실패한 것으로 보이지만 원인을 확정하지는 못했다.

더 나은 방법이 이미 있었으므로 그 원인을 파고들 이유가 없었다. 집계 한 줄로 교체하고 원인 미확정을 미확정 그대로 적었다. 셸 산술은 빈 값에 약하므로 집계는 집계할 수 있는 도구에 맡기는 편이 낫다.