명품몰 일괄 등록에서 이미지 누락으로 반려된 건을 조사하면서 이미지 점검 도구 check_images.sh 를 돌렸다. 복구할 것이 없고 전부 정상이라는 결과가 나왔다.
Table of contents
Open Table of contents
증상 — 도구가 낸 전부 정상
그 결과를 그대로 인용해 우리 쪽은 문제없다고 답하려 했다. 답하기 전에 상세 이미지도 봤느냐는 지적이 들어왔다.
도구가 무엇을 대상으로 도는지는 확인한 적이 없었다. 결과 숫자만 보고 범위를 전체로 읽고 있었다.
원인 — 명시적으로 제외된 종류
도구를 열어 보니 SELECT … FROM product_images WHERE kind = 'MAIN' 으로 조회 조건에서 한 종류를 명시적으로 빼고 있었다. 이미지가 대표와 상세 두 종류인데 그중 상세 페이지 쪽이 대상에서 제외돼 있었다.
이 제외는 결함이 아니라 설계였다. 상세 이미지는 product_detail_html 본문 안에 있어 저장 구조도 다르고 복구 방법도 달라서 이 도구의 범위 밖이었다.
판단 기준 — 도구는 안 보는 것을 말해 주지 않는다
결과 어디에도 무엇을 안 봤는지가 안 적혀 있으므로 전부 정상이 아니라 본 것은 정상이라고 읽어야 했다. 범위가 있는 것이 문제가 아니라 범위를 모르고 쓴 것이 문제였다.
두 가지 방법이 있었다. check_images.sh 를 고쳐 상세까지 보게 하는 것과, 도구는 그대로 두고 제외된 쪽을 별도로 조회하는 것이다. 뒤쪽을 골랐다. 이유는 상세 이미지는 본문 파싱이 필요해서 같은 도구에 넣으면 대표 이미지 점검까지 느려져서다. 대신 점검이 두 단계로 갈리는 것을 감수했다. 그래서 순서를 바꿔서 도구가 무엇을 보는지 먼저 확인하고 그 범위 안에서 결과를 해석하게 됐다.
레코드 없이 본문에만 있는 경우
별도 조회에서 결과가 0개인 건이 있었는데 그것이 누락인지 확인이 필요했다. product_detail_html 을 열어 보니 이미지가 product_images 레코드 없이 <img src> 로 직접 박혀 있었다.
그래서 본문을 파싱해 이미지 주소를 뽑고 각 주소를 curl -sI 로 저장소에 실제로 있는지 전수로 확인했다. 404 도 외부 주소도 없어서 상세 쪽도 정상인 것이 확정됐다.
우연히 맞은 답
결과적으로 처음 하려던 답과 최종 결론이 같았지만 근거가 달랐다. 처음 것은 절반만 보고 낸 결론이었고 최종은 두 종류를 다 확인한 것이었다.
상세 쪽에 누락이 있었다면 처음 답은 틀린 채로 몰 운영사에 넘겨졌을 것이다. 우연히 맞은 답을 맞은 답으로 세지 않는 것이 이 건의 결론이었다.
정리
- 도구가
kind = 'MAIN'처럼 일부를 명시적으로 제외할 수 있다 - 제외는 결함이 아니라 설계 범위일 수 있다
- 결과에는 무엇을 안 봤는지가 안 적혀 있다
- 도구 결과는 전부 정상이 아니라 본 것은 정상이다
- 도구가 무엇을 보는지 먼저 확인하고 그 범위에서 해석한다
- 제외된 쪽은 다른 조건으로 따로 조회한다
- 레코드가 없어도 본문에
<img src>로 직접 박혀 있을 수 있다 - 우연히 맞은 답을 맞은 답으로 세지 않는다