특정 채널 전체에 이미지 복구 작업을 넣는 일을 인계받았다. 대상이 20만 건이라 선별 조건이 중요했는데 인계 문서에 적격 조건이 17개 항목으로 잘 정리돼 있어 그대로 SQL을 짜면 되는 상태였다. 그래도 실행 핸들러 원본과 한 줄씩 대조해 봤다.
Table of contents
Open Table of contents
문서에 없던 다섯 게이트
대조하니 문서에 없는 게이트가 다섯 개 나왔다. 재고가 0보다 클 것과 개별 제외 플래그가 아닐 것과 차단 목록에 없을 것과 차단 공급사에 속하지 않을 것과 시스템 작업 제외 공급사에 속하지 않을 것이다.
문서가 틀린 것은 아니었다. 문서는 무엇을 넣을지를 적었고 핸들러는 실행 시점에 무엇을 실행할지를 따로 판단하고 있었다. 두 계층이 다른 질문에 답하고 있어서 한쪽 목록에 다른 쪽 조건이 안 들어간 것이다.
부적격 처리의 실제 동작
다섯 중 재고 조건이 걸려서 워커 코드를 열어 봤는데 부적격이면 다음 건으로 넘어갈 것이라는 예상과 달랐다.
if (!$this->canExecuteJob($job)) {
// 건너뛰지 않는다 — 마켓에 STOP을 보낸다
$this->stopProduct($job);
}연동 해제를 실행하고 있었다. 재고가 0이거나 판매 상태가 아니면 마켓에서 그 상품을 내린다. 의도 자체는 맞는 동작이다. 재고 없는 상품이 마켓에 걸려 있으면 안 되니 자동으로 내려 주는 것이다.
그런데 내 작업 맥락에서는 다르게 작동한다. 이미지를 복구하려고 넣은 작업이 상품을 판매 중지시킨다. 재고 필터를 빠뜨렸으면 20만 건 중 재고가 0인 것들이 전부 마켓에서 내려갔을 것이다.
지금은 0건인 조건
보강한 SQL을 운영 DB에 읽기 전용으로 돌려서 다섯 게이트를 추가했을 때 얼마나 더 걸러지는지를 세어 봤더니 0건이었다.
이유도 명확했다. 정상 상태이면서 최근 갱신에 성공한 상품은 재고가 0이 되는 순간 시스템이 자동으로 내려 상태가 바뀌므로 지금 스냅샷에는 정상인데 재고가 0인 것이 없다.
그러면 이 필터가 필요 없는가 하면 그렇지 않다. 이 실행은 대상이 20만 건이라 몇 시간이 걸리고 그동안 재고가 빠지는 상품이 계속 생긴다. 시작할 때 0건이었다는 것은 시작 시점의 사실이지 실행 내내의 사실이 아니다.
효율과 안전의 갈림
같은 0건이라는 관측을 놓고 두 방향으로 결론이 갈린다. 필터를 효율로 생각하면 아무것도 안 거르는 조건이 쿼리만 무겁게 하므로 빼는 것이 맞고, 안전으로 생각하면 그 조건이 걸러야 할 상황이 실행 중에 생길 수 있으므로 0건이어도 넣는 것이 맞다.
갈림의 기준은 걸러지지 않았을 때 무슨 일이 나는가다. 그냥 건너뛰는 것이면 효율 문제이고 되돌리기 어려운 동작이 일어나면 안전 문제인데 이번 건은 후자였다.
문서와 정본
이번에 문서를 그대로 믿었으면 그 조건 그대로 실행됐을 것이고 문서가 잘 쓰여 있을수록 그렇게 되기 쉽다. 17개 항목이 번호까지 붙어 정리돼 있으면 검증할 생각이 잘 안 든다.
인계 문서는 그 시점에 조사한 결과이고 정본은 코드다. 그래서 조건 목록을 받으면 판별 로직 원본과 라인 단위로 대조하고, 문서에 없는 게이트가 나오면 빠뜨린 것인지 다른 계층의 것인지 본다. 특히 실행 시점에 다시 평가되는 조건을 따로 찾는데 이것은 SQL 조건과 성격이 다르다. 마지막으로 부적격 처리가 건너뛰기인지 다른 동작인지를 코드로 확인한다. 이번 건의 핵심이 그것이었다. 함수 이름은 실행 가능 여부를 판단할 것처럼 보이는데 안에서 외부 시스템을 호출하고 있었다.
정리
- 부적격 처리가 건너뛰기가 아닐 수 있다
- 이름이 판단처럼 보여도 안에서 동작할 수 있다
- 조건 필터를 빼도 되는지는 걸러지지 않았을 때의 결과로 판단한다
- 효율이면 0건일 때 빼고 안전이면 0건이어도 넣는다
- 시작 시점 0건은 몇 시간짜리 실행 내내의 0건이 아니다
- 인계 문서의 조건 목록은 시작점이고 정본은 판별 로직 원본이다
- 실행 시점에 다시 평가되는 게이트를 따로 찾는다