화면에 없고 전송에는 있던 값

외부로 이미지를 보내는 연동이 없는 파일을 요청하다 실패했다. 화면에는 이미지가 셋이고 전부 정상인데 전송에는 넷이 들어가고 있었다.

Open Table of contents

화면 조회와 전송 조회의 차이

두 조회를 나란히 놓고 보니 화면 쪽에만 실체가 있는 것을 거르는 조건이 붙어 있었다. 전송 쪽 조회에는 그 조건이 없어서 레코드만 남은 것까지 딸려 갔다.

네 번째는 예전에 교체된 이미지의 잔재였다. 실제 파일은 지워졌고 레코드만 남아 있어서 화면은 감추고 전송은 보내는 상태였다.

내가 들고 있던 가정은 화면에 안 보이면 전송에서도 빠진다는 것이었다. 같은 테이블을 쓰니 당연해 보였지만 조회 조건이 각자 붙어 있었다.

같은 데이터를 읽는다는 것이 같은 목록을 만든다는 뜻은 아니다. 이런 것은 화면만 보고는 알 수 없고 두 조회를 직접 대조해야 갈린다.

처음에는 잃어버린 이미지를 복구하는 쪽으로 생각했다. 원본을 다시 올리면 파일이 생기니 전송이 통과할 것이었다.

그런데 그 이미지는 이미 교체됐고 지금 쓰는 이미지가 따로 있었다. 증상만 보면 없어졌으니 되살린다로 가는데 맥락을 보면 남은 것이 잘못이니 지운다였다.

지우기 전에 이것이 진짜 잔재인지를 네 가지로 갈랐다. 화면에 보이는지와 원본과 변환본의 실체가 있는지와 등록 순서가 가장 오래됐는지를 봤다.

네 번째가 특히 중요했는데 지우고 나서 정상인 것이 남아 있어야 한다는 조건이었다. 잔재를 지웠더니 그 상품에 이미지가 하나도 없게 되면 고친 것이 아니기 때문이다.

운영 데이터를 지우는 것이므로 절차를 붙였다. 컬럼 하나가 아니라 그 레코드 전체를 파일로 백업하고 삭제 직전에 네 조건을 스크립트가 다시 검사하게 했다.

조사 시점과 실행 시점 사이에 상태가 바뀔 수 있으므로 재검사가 필요했다. 세 번째로 본문 HTML이 그 이미지를 참조하는지 확인했고 참조가 없는 것을 보고 지웠다.

같은 잔재가 다른 곳에도 있을 것 같아서 점검 도구에 규칙을 넣었다. 자동으로 지우지 않고 목록만 만들게 했더니 전수로 돌렸을 때 같은 부류가 여럿 드러났다.