명품몰 썸네일이 제대로 만들어졌는지 점검하는 check_images.sh 를 돌렸더니 대부분 정상이었다. 그런데 점검을 통과한 항목인데 상품 목록 화면에서 비율이 깨져 보였다.
Table of contents
Open Table of contents
원인 — 이름만 확인하던 점검
파일을 열어 보니 thumb_300.jpg 라는 이름의 파일은 있는데 치수가 지금 규칙과 달랐다. 옛 규칙 300x300 으로 만들어진 것이었고 규칙이 300x400 으로 바뀐 뒤에도 그대로 남아 있었다.
점검 코드는 기대하는 이름이 listObjects() 목록에 있는지만 보고 있었다. 그 파일이 지금 규격에 맞는지는 확인하지 않았다.
판단 기준 — 규격이 다른데 통과한 이유
이름이 있으면 통과이므로 내용이 틀린 것은 검사 자체를 지나간다. 점검이 통과했다는 사실이 결과가 맞다는 근거가 되지 못했다.
있다는 것과 맞다는 것을 같은 검사로 다루면 틀린 것이 정상으로 집계된다. 무엇을 검사하고 있었는지를 다시 정의해야 했다.
조치 — 무엇을 검사할지 넷으로 나눈다
제대로 만들어졌는가를 존재와 규격과 내용과 최신 넷으로 나눴다. 원래 검사는 첫째만 하고 있었다.
두 가지 방법이 있었다. 파일을 전부 받아 identify 로 치수를 읽는 것과, HEAD 응답의 Content-Length 만으로 옛 규격을 추정하는 것이다. 앞쪽을 골랐다. 이유는 크기만으로는 300x300 과 300x400 이 안 갈려서다. 대신 점검이 수천 건 다운로드만큼 느려지는 것을 감수했다. 원본의 Last-Modified 가 변환본보다 나중이면 낡은 것으로 보는 검사도 넣었다. 내용 일치는 비용이 커서 이번에는 넣지 않고 그 판단을 기록에 남겼다.
규칙이 어디에 있는가
규격을 검사하려면 규칙이 무엇인지 알아야 하는데 그것이 ThumbnailService 안에만 있었다. 짧은 축의 길이에 따라 세 구간으로 갈리는 규칙을 읽어서 정리했다.
같은 규칙을 변환하는 쪽과 점검하는 쪽이 모두 알아야 하므로 원래는 thumb-rules.yml 한 곳에 두고 공유하는 것이 맞다. 당장은 양쪽에 두되 주석으로 연결해 어느 한쪽만 바뀌는 것을 막았다.
검증 — 차이와 결함의 구분
이 김에 도구 전체를 코드와 대조하니 의도와 다른 것이 몇 개 나왔다. 처리 순서가 설계와 다르지만 의존 관계가 충족되어 결과가 같은 것도 있었다.
그것은 결함이 아니라 기능이 같은 차이로 판정하고 기록만 남겼다. 반대로 grep 으로 호출부가 하나도 없는 폴백 경로도 찾았는데 있는 것처럼 보이는 코드가 읽는 사람을 안심시키므로 미구현으로 명시했다.
정리
- 이름의 존재만 확인하는 검사는 내용이 틀린 것을 통과시킨다
- 점검 통과가 결과가 맞다는 근거가 되지 않는다
- 제대로 만들어졌는가를 존재와 규격과 내용과 최신으로 나눈다
- 규격을 검사하려면
identify로 실제 치수를 읽는다 - 같은 규칙을 두 곳이 알아야 하면 한 곳에 두고 공유한다
- 의도와 구현의 차이를 결함과 기능 동치로 구분한다
- 결과가 안 달라지면 기록만 하고 넘어간다
- 호출부가 없는 코드는 검색으로 찾아 미구현으로 명시한다