한 업체의 대표 이미지가 다른 상품보다 작게 보인다는 지적이 왔다. 첫 가설은 본문 태그에 크기 지정이 들어갔다는 것이었다.
Table of contents
Open Table of contents
데이터로 배제한 첫 가설
본문을 직접 조회해서 <img>의 width= 속성과 style= 속성과 본문 내 max-width 지정을 각각 LIKE로 셌더니 셋 다 0건이었다.
가설을 배제하고 다음으로 넘어갔다. 가설을 세웠으면 아마 아닐 것이라고 넘기지 않고 데이터로 배제하는 것이 순서다.
원본과 두 변환본
S3 원본 해상도를 identify로 조회하니 짧은 축이 1000보다 작았다. 같은 원본에서 만들어지는 thumb과 large 변환본이 둘 있어서 각각의 크기도 봤는데 서로 달랐다.
변환 설정을 여니 규칙이 갈려 있었다. thumb은 짧은 축을 특정 구간으로 제한만 하고 upscale: false이며 large는 짧은 축을 무조건 1000까지 확대한다.
나가는 쪽의 규칙
마켓으로 나가는 대표 이미지가 어느 변환본인지 확인하니 thumb 쪽이었다. 그래서 원본이 작은 이 업체만 작게 나가고 원본이 큰 다른 상품들은 상한에 맞춰 나가고 있었다.
우리 처리가 정상 동작해도 작게 나가는 구조였고 원인이 원본에 있었다. 셀러가 올린 원본의 짧은 축이 상한보다 작다는 것이 전부였다.
선택지 셋과 각각의 영향
해결이 셋이었고 각각 영향이 달랐는데 셀러가 더 큰 원본을 재업로드하는 것이 근본적이고 무손실이다.
변환 규칙을 upscale: true로 바꾸는 것은 전 상품에 영향이 가고 없는 픽셀을 만드는 것이라 화질이 떨어져서 권장하지 않는다. 마켓 대표로 large를 보내면 일괄 해소되지만 다른 데서 그 변환본을 기대하고 있는지 검토가 필요하다.
판단을 넘기는 방식
두 가지 방법이 있었는데 셋 중 하나를 골라 제안하는 것과 셋을 영향과 함께 다 적어 넘기는 것이다. 뒤쪽을 골랐다. 이유는 판단 주체가 달라서인데 재업로드 요청은 운영이 할 일이고 나머지 둘은 개발 판단이다. 대신 결론 없이 넘겨 답이 나오기까지 한 번 더 오가는 것을 감수했다.
내가 하나를 골라 제안하면 다른 데서 그 변환본을 쓰는지 모르는 채로 정하는 것이 된다. 선택지와 각각의 영향을 주고 판단은 그것을 아는 쪽에 넘겼다.
순서로 남긴 규칙
조사 순서를 되짚으니 원본 해상도를 먼저 봤으면 훨씬 빨랐다. 마크업을 의심하고 배제한 뒤에야 원본을 봤기 때문이다.
그래서 이미지가 작다는 민원을 우리 처리 버그나 마크업 문제로 먼저 의심하지 않고 identify로 셀러 원본의 짧은 축 해상도부터 보기로 규칙을 남겼다. 조회 하나면 되고 대부분 거기서 끝나므로 마크업은 그다음에 본다.
정리
- 가설을 세웠으면 데이터로 배제한다
- 같은 원본의 변환본마다 규칙이 다를 수 있다
- 어느 변환본이 밖으로 나가는지 확인한다
- 원본이 작으면 정상 동작해도 작게 나간다
- 이미지가 작다는 민원은
identify로 원본 해상도부터 본다 - 해결 선택지가 여럿이면 각각의 영향을 적는다
- 판단 주체가 다른 선택지를 섞어 하나로 고르지 않는다
- 조회 하나로 끝나는 확인을 마지막에 두지 않는다