명품몰 상품 이미지를 몰 플랫폼으로 보내는 연동이 없는 파일을 요청하다 404 로 실패했다. 관리 화면에는 이미지가 셋이고 전부 정상인데 전송 페이로드에는 넷이 들어가고 있었다.
Table of contents
Open Table of contents
원인 — 화면 조회와 전송 조회의 차이
두 조회를 나란히 놓고 보니 화면 쪽 ImageRepository.findVisible() 에만 file_exists = 'Y' 로 실체가 있는 것을 거르는 조건이 붙어 있었다. 전송 쪽 findForSync() 에는 그 조건이 없어서 레코드만 남은 것까지 딸려 갔다.
네 번째는 예전에 교체된 이미지의 잔재였다. 실제 파일은 버킷에서 지워졌고 product_images 레코드만 남아 있어서 화면은 감추고 전송은 보내는 상태였다.
검증 — 가정이 코드에서 틀렸다
내가 들고 있던 가정은 화면에 안 보이면 전송에서도 빠진다는 것이었다. 같은 테이블을 쓰니 당연해 보였지만 조회 조건이 각자 붙어 있었다.
같은 데이터를 읽는다는 것이 같은 목록을 만든다는 뜻은 아니다. 이런 것은 화면만 보고는 알 수 없고 findVisible() 과 findForSync() 두 조회를 직접 대조해야 갈린다.
판단 기준 — 복구가 아니라 삭제였던 답
두 가지 방법이 있었다. 잃어버린 이미지를 원본에서 다시 올려 파일을 되살리는 것과, 남은 레코드를 지우는 것이다. 처음에는 앞쪽으로 생각했다. 원본을 다시 올리면 파일이 생기니 전송이 통과할 것이었다.
그런데 그 이미지는 이미 교체됐고 지금 쓰는 MAIN 이미지가 따로 있었다. 뒤쪽을 골랐다. 이유는 되살리면 같은 상품에 옛 이미지가 다시 노출되어서다. 대신 운영 데이터를 지우는 절차를 밟아야 하는 것을 감수했다. 증상만 보면 없어졌으니 되살린다로 가는데 맥락을 보면 남은 것이 잘못이니 지운다였다.
현역과 잔재를 가른 네 기준
지우기 전에 이것이 진짜 잔재인지를 네 가지로 갈랐다. 화면에 보이는지와 원본과 thumb_300 변환본의 실체가 있는지와 sort_order 가 가장 오래됐는지를 봤다.
네 번째가 특히 중요했는데 지우고 나서 정상인 것이 남아 있어야 한다는 조건이었다. 잔재를 지웠더니 그 상품에 이미지가 하나도 없게 되면 고친 것이 아니기 때문이다.
조치 — 삭제 전 세 가지 안전장치
운영 데이터를 지우는 것이므로 절차를 붙였다. 컬럼 하나가 아니라 그 레코드 전체를 mysqldump --where 로 백업하고 삭제 직전에 네 조건을 스크립트가 다시 검사하게 했다.
조사 시점과 실행 시점 사이에 상태가 바뀔 수 있으므로 재검사가 필요했다. 세 번째로 product_detail_html 본문이 그 이미지를 참조하는지 확인했고 참조가 없는 것을 보고 지웠다.
같은 잔재가 다른 곳에도 있을 것 같아서 check_images.sh 에 규칙을 넣었다. 자동으로 지우지 않고 목록만 만들게 했더니 전수로 돌렸을 때 같은 부류가 여럿 드러났다.
정리
- 화면 목록과 전송 목록이 같은 조건을 쓰지 않을 수 있다
- 같은 데이터를 읽는 것이 같은 목록을 만드는 것은 아니다
- 화면에 안 보이면 전송에서도 빠진다는 가정을
findForSync()코드로 확인한다 - 증상이 없어졌다여도 답이 남은 것을 지우는 쪽일 수 있다
- 현역과 잔재를 노출과 실체와
sort_order와 정상 잔존으로 가른다 - 삭제 전에
mysqldump --where로 전체 행을 백업하고 조건을 다시 검사한다 - 본문 HTML 에서 참조하는지 확인하고 지운다
- 하나를 고치면서 같은 부류를 찾는 규칙을 도구에 넣는다