변환본 둘, 규칙 둘

한 업체의 대표 이미지가 다른 상품보다 작게 보인다는 지적이 왔다. 첫 가설은 본문 태그에 크기 지정이 들어갔다는 것이었다.

Open Table of contents

데이터로 배제한 첫 가설

본문을 직접 조회해서 이미지 태그의 크기 속성과 스타일 속성과 본문 내 폭 지정을 각각 셌다. 셋 다 0건이었다.

가설을 배제하고 다음으로 넘어갔다. 가설을 세웠으면 아마 아닐 것이라고 넘기지 않고 데이터로 배제하는 것이 순서다.

저장소의 원본 해상도를 조회하니 짧은 축이 1000보다 작았다. 같은 원본에서 만들어지는 변환본이 둘 있어서 각각의 크기도 봤는데 서로 달랐다.

변환 설정을 여니 규칙이 갈려 있었다. 한쪽은 짧은 축을 특정 구간으로 제한만 하고 업스케일하지 않으며 다른 쪽은 짧은 축을 무조건 1000까지 확대한다.

마켓으로 나가는 대표 이미지가 어느 변환본인지 확인하니 업스케일하지 않는 쪽이었다. 그래서 원본이 작은 이 업체만 작게 나가고 원본이 큰 다른 상품들은 상한에 맞춰 나가고 있었다.

우리 처리가 정상 동작해도 작게 나가는 구조였고 원인이 원본에 있었다. 셀러가 올린 원본의 짧은 축이 상한보다 작다는 것이 전부였다.

해결이 셋이었고 각각 영향이 달랐다. 셀러가 더 큰 원본을 재업로드하는 것이 근본적이고 무손실이다.

변환 규칙이 업스케일하도록 바꾸는 것은 전 상품에 영향이 가고 없는 픽셀을 만드는 것이라 화질이 떨어져서 권장하지 않는다. 마켓 대표로 다른 변환본을 보내면 일괄 해소되지만 다른 데서 그 변환본을 기대하고 있는지 검토가 필요하다.

셋 중 하나를 고르지 않고 셋을 다 적었다. 판단 주체가 다르기 때문인데 재업로드 요청은 운영이 할 일이고 나머지 둘은 개발 판단이다.

내가 하나를 골라 제안하면 다른 데서 그 변환본을 쓰는지 모르는 채로 정하는 것이 된다. 선택지와 각각의 영향을 주고 판단은 그것을 아는 쪽에 넘겼다.

조사 순서를 되짚으니 원본 해상도를 먼저 봤으면 훨씬 빨랐다. 마크업을 의심하고 배제한 뒤에야 원본을 봤기 때문이다.

그래서 이미지가 작다는 민원을 우리 처리 버그나 마크업 문제로 먼저 의심하지 않고 셀러 원본의 짧은 축 해상도부터 보기로 규칙을 남겼다. 조회 하나면 되고 대부분 거기서 끝난다.