긴 상품 상세 이미지를 쪼개면 왜 더 빨라지는가

문제

상품 상세에는 세로로 매우 긴 통이미지가 자주 쓰입니다. 제작팀 입장에서는 하나의 이미지로 디자인을 통제하기 쉽고, 셀러 입장에서는 HTML을 복잡하게 만들지 않아도 됩니다. 하지만 고객 입장에서는 첫 화면에 필요한 정보보다 훨씬 많은 데이터를 한 번에 받게 됩니다. 상단 일부만 보려고 들어왔는데 하단 수천 픽셀까지 함께 다운로드하는 구조입니다.

긴 통이미지는 실패 비용도 큽니다. 네트워크가 불안정하거나 모바일 환경이 느릴 때 큰 이미지 하나가 지연되면 화면 전체가 비어 보입니다. 중간에 요청이 실패하면 다시 받아야 하는 단위도 큽니다. 고객은 특정 구간을 보고 싶지만 브라우저는 하나의 거대한 파일을 처리해야 합니다.

그래서 긴 상품 상세 이미지는 단순히 "용량이 크다"가 아니라 "로딩 단위가 너무 크다"는 문제로 봐야 합니다. 첫 화면에 필요한 부분과 나중에 봐도 되는 부분을 같은 우선순위로 보내면 LCP와 체감 속도가 모두 나빠집니다.

원인

긴 이미지는 브라우저가 파일을 받은 뒤 디코딩하고 레이아웃에 반영하는 비용이 큽니다. 압축률이 좋아도 한 파일이 지나치게 크면 첫 의미 있는 노출이 늦어질 수 있습니다. 특히 상세 이미지 상단에 중요한 상품 컷과 혜택 정보가 있고, 하단에는 상세 설명과 고지 이미지가 이어지는 구조라면 모든 구간을 같은 시점에 받을 이유가 없습니다.

또 하나의 원인은 운영 편의성입니다. 셀러나 디자인팀은 한 장으로 등록하는 것이 편하지만, 고객 경험은 조각난 로딩이 더 유리할 수 있습니다. 문제는 등록 프로세스를 바꾸지 않고 어떻게 고객에게는 나뉜 형태로 보낼 것인가입니다. 원본을 사람이 다시 자르고 재등록하면 운영 부담이 커집니다.

흔한 오해는 이미지를 쪼개면 HTTP 요청 수가 늘어 항상 느려진다는 것입니다. 과거에는 요청 수가 큰 비용이었지만, 현재는 HTTP/2, HTTP/3, 캐시, lazyload를 함께 고려해야 합니다. 중요한 것은 무작정 많이 쪼개는 것이 아니라 첫 화면과 이후 영역의 우선순위를 나누는 것입니다.

해결

내부에서 먼저 할 수 있는 일은 긴 이미지의 실제 노출 구간을 보는 것입니다. 첫 화면에 보이는 픽셀, 스크롤 후 1~2화면 안에 보이는 영역, 거의 보지 않는 하단 영역을 나눕니다. 첫 화면 구간은 우선 로드하고, 하단 구간은 lazyload로 늦춰도 됩니다. 단, 분할된 이미지 영역의 높이는 미리 확보해야 CLS가 생기지 않습니다.

분할 기준은 디자인 단위와 정보 단위가 같이 맞아야 합니다. 상품 대표 컷, 혜택 배너, 성분/스펙, 사용법, 고지사항처럼 의미 단위로 나누면 운영자가 나중에 문제를 추적하기 쉽습니다. 너무 작은 조각으로 쪼개면 관리가 어려우므로, 첫 화면 최적화와 캐시 효율 사이의 균형이 필요합니다.

M2 Live Cloud의 splitimg 관점은 원본 등록 방식을 크게 바꾸지 않고 응답 시점에 고객 경험을 나누는 것입니다. 긴 원본을 보존하되, 필요한 구간을 나누어 전송하고, 브라우저·디바이스에 맞는 포맷과 크기로 응답합니다. 핵심은 제작팀의 원본 운영 편의와 고객의 빠른 노출 경험을 분리하는 데 있습니다.

지금 실행

• 직접 확인: 대표 상세 이미지의 세로 길이, 파일 크기, 첫 화면에 실제로 보이는 영역을 기록하세요. DevTools Network에서 큰 이미지가 LCP 또는 긴 blocking 리소스처럼 동작하는지도 확인합니다.
• 내부 조치: 첫 화면에 필요한 상단 정보와 하단 상세 정보를 나누고, 하단 이미지는 lazyload 대상이 될 수 있는지 검토하세요. 분할 후에는 이미지 영역 높이를 미리 잡아 CLS가 생기지 않게 해야 합니다.
• 구조 검토: 긴 통이미지가 수천 개 상품에 반복되고 셀러 등록 프로세스를 바꾸기 어렵다면 수동 분할은 유지 비용이 큽니다. 이 경우 이미지 최적화 가이드를 기준으로 splitimg 방식의 앞단 처리를 검토하세요.