특정 상태값에서 다르게 동작하는 분기를 넣는 작업이었고 안전 근거로 그 상태값이 운영 DB에 0건이므로 이 분기는 발동하지 않는다고 적었다. 조회 자체는 정확했고 진짜로 0건이었는데 그 근거가 틀렸다.
Table of contents
Open Table of contents
0건인 이유
코드를 따라가 보니 그 상태값은 이렇게 쓰이고 있었다.
$this->updateStatusExport($item); // 여기서 그 값을 넣는다
$this->updateStatusExportSuccess($item); // 바로 다음 줄에서 다른 값으로 덮는다찍자마자 덮이므로 어느 시점에 스냅샷을 떠도 항상 0건이 나온다. 도달하지 않아서 0건인 것이 아니라 도달했다가 즉시 지나가서 0건이었고 오히려 지배적인 경로가 반드시 거치는 과도 상태였다. 내 분기는 매번 발동하는데 스냅샷이 그것을 못 보여 줄 뿐이었다.
0건이 보증하는 범위
그렇다고 0건이 아무 의미가 없는 것은 아니고 훨씬 좁은 것만 보증한다. 지금 이 순간 그 상태로 멈춰 있는 행이 없다는 것까지가 0건이 말해 주는 전부다.
그 상태에 도달하지 않는다는 것과 앞으로도 없을 것이라는 것과 그 분기가 실행되지 않는다는 것은 0건이 말해 주지 않는다. 내가 필요했던 것은 세 번째였는데 손에 쥔 것은 첫 번째였다.
시점 의존적인 모수
비슷한 것을 다른 작업에서도 봤다. 실패한 작업을 일괄 수정하는 캠페인에서 지금 오류 상태인 것으로 대상을 뽑아 270건을 고치고 잔존 0건을 확인하고 끝냈는데 며칠 뒤 63건이 새로 나타났다.
그 시스템은 재시도 횟수가 임계에 닿아야 오류로 집계되는 구조였다. 수정 시점에 아직 재시도가 남아 있던 건들은 그때 목록에 없었고 나중에 소진되면서 표출된 것이다. 놓친 것도 새로 생긴 것도 아니라 모수 정의 자체가 시점에 의존하고 있었다. 대상을 오류인 것이 아니라 완료되지 않은 것으로 잡았어야 했다.
표출과 오류의 구분
새로 나타난 63건에 같은 수정 SQL을 다시 돌리려다 멈추고 데이터가 실제로 틀렸는지 먼저 검증했다.
690개 항목 중 고쳐야 할 것이 0개였다. 전부 이미 올바른 값이었고 다른 경로로 채워져 있었다. 필요한 조치는 데이터 수정이 아니라 실패 카운터를 초기화하는 것뿐이었는데, 그냥 돌렸으면 올바른 690개를 불필요하게 덮어썼을 것이다. 오류로 표출됐다는 사실이 데이터가 틀렸다는 뜻은 아니다.
근거를 세우는 방법
과도 상태는 스냅샷으로 잴 수 없으므로 그 값을 쓰는 코드 지점을 세고 세팅 직후에 덮는 경로가 있는지 본다. 안전 근거는 카운트가 아니라 구조에서 나온다.
모수 정의가 시점에 의존하는지도 본다. 지금 실패인 것은 오늘의 스냅샷이고 완료되지 않은 것은 상태와 무관한 집합이라 캠페인 대상으로는 후자가 안정적이다. 잔존 0을 완료 선언으로 쓰지 않고 며칠 뒤 재확인하며, 재확인에서 나온 건에 같은 수정을 바로 돌리지 않고 실제로 고칠 것이 있는지 먼저 센다.
0건이 뒷받침하는 문장 하나
처음의 근거를 전부 버려야 하는 것은 아니고 하나가 남는다. 이 분기 추가가 오늘 데이터에 대해 아무 동작도 하지 않는다는 문장은 참이다.
다만 내가 하려던 주장인 이 분기는 발동하지 않으니 안전하다와는 다른 문장이다. 앞의 것은 오늘에 한정되고 뒤의 것은 앞으로도를 포함한다. 0건은 앞의 문장까지만 뒷받침하고 그 경계를 넘으면 근거가 아니라 희망이 된다.
정리
- 0건은 지금 그 상태로 멈춰 있는 행이 없다는 것만 보증한다
- 도달 불가와 즉시 덮임은 둘 다 0건으로 나타난다
- 둘을 가르려면 코드를 읽어야 한다
- 과도 상태의 안전 근거는 카운트가 아니라 구조에서 나온다
- 모수를 지금 실패인 것이 아니라 완료되지 않은 것으로 잡는다
- 잔존 0을 완료로 쓰지 않는다. 지연 표출이 따라온다
- 오류로 표출된 것이 데이터가 틀렸다는 뜻은 아니다
- 재확인에서 나온 건은 고칠 것이 있는지 먼저 센다