모바일에서 큰 이미지를 내려받지 않게: srcset·sizes 검수 순서

화면에 보이는 크기와 내려받는 파일 크기는 다릅니다

모바일에서 사진이 화면 안에 들어간다고 해서 작은 파일을 내려받은 것은 아닙니다. 가로로 큰 원본을 받아 놓고 CSS로 줄여 보여줄 수도 있습니다. 반대로 작은 이미지를 큰 화면에 늘리면 파일은 가볍지만 세부가 흐려집니다. 반응형 이미지 검수는 “잘리지 않는다”는 확인과 “필요한 후보 파일을 선택한다”는 확인을 나누는 작업입니다. 이 글은 상품 사진이나 가이드 도식을 여러 화면에서 제공할 때 원본, 후보 파일, 표시 폭, 실제 선택 결과를 연결하는 절차를 설명합니다. 실제 사이트의 속도 개선 성과를 보고하는 글은 아닙니다.

검수의 출발점은 압축률이 아니라 이미지가 맡은 역할입니다. 상품의 봉제선이나 연결부를 보여주는 사진은 작은 썸네일과 본문 확대 이미지가 같은 파일일 필요가 없습니다. 구성 순서를 설명하는 도식은 글씨가 줄어도 읽히는지 별도로 봐야 합니다. 모바일의 첫 화면을 가볍게 만들겠다고 중요한 디테일을 지우면 독자는 파일을 더 빨리 받더라도 상품을 더 이해하기 어려울 수 있습니다. 먼저 어떤 장면에 어떤 정보가 남아야 하는지 정한 뒤 파일 후보를 구성합니다.

원본 폭·표시 폭·화면 폭을 세 칸으로 기록합니다

원본 폭은 이미지 파일 자체의 픽셀 수입니다. 표시 폭은 페이지에서 이미지가 차지하는 CSS 픽셀의 너비이고, 화면 폭은 브라우저의 뷰포트 너비입니다. 같은 화면 안에서도 본문 사진, 두 열 카드, 작은 후기 썸네일의 표시 폭은 다릅니다. 세 값을 모두 “이미지 크기”라고 부르면 편집자가 파일을 줄여야 하는지, 개발자가 레이아웃 힌트를 바꿔야 하는지 구분하기 어렵습니다.

설명용으로 화면 폭이 390 CSS 픽셀이고 본문 좌우 여백이 각각 20 CSS 픽셀이라고 가정해 보겠습니다. 이미지가 본문 폭을 모두 사용한다면 표시 폭은 350 CSS 픽셀입니다. 이것은 실제 detailry의 모든 페이지에 적용되는 값이 아니라 계산 관계를 보여주는 가정입니다. 두 열 카드 안에서는 같은 화면이어도 이미지가 훨씬 작아질 수 있으므로, 뷰포트가 390이라고 모든 이미지에 390만 필요하다고 결론내리지 않습니다.

같은 장면의 후보 파일과 다른 구도의 이미지를 구분합니다

srcset은 브라우저가 선택할 이미지 후보를 제시합니다. 폭 설명자 w를 쓰는 방식에서는 각 후보의 실제 파일 폭을 적고, sizes로 표시 공간에 대한 힌트를 제공합니다. 파일 이름에 800이 들어간다고 실제 폭이 800 픽셀인 것은 아니므로, 등록 전에 파일 속성을 확인해야 합니다. 브라우저는 표시 공간과 화면 밀도 등의 조건을 참고해 후보를 고릅니다. 특정 후보를 모든 기기에서 강제로 고르는 장치로 이해하지 않습니다. 이 관계는 MDN 반응형 이미지 안내에서 확인할 수 있습니다.

후보끼리는 기본적으로 같은 장면을 같은 비율로 보여주는 편이 검수하기 쉽습니다. 큰 파일에는 상품의 뚜껑이 열려 있고 작은 파일에는 닫혀 있다면, 사용자는 화면 조건에 따라 서로 다른 상태를 보게 됩니다. 해상도 선택을 위해 만든 파일 묶음에 내용 차이가 섞인 것입니다. 제품 버전, 색상, 배경, 촬영 상태가 동일한지 후보 목록에서 먼저 대조합니다. 구도가 달라져야 한다면 별도의 편집 판단으로 관리합니다.

모바일에서 인물이나 상품의 핵심 부위를 더 크게 보여주기 위해 구도를 바꾸는 것은 단순한 해상도 선택과 다릅니다. 이 경우 picture처럼 조건에 따라 다른 이미지를 제공하는 구조를 검토할 수 있습니다. 다만 파일을 바꿀 때도 원래 사진이 전달하던 사실과 적용 조건을 유지해야 합니다. 큰 화면의 구성품 사진에서 일부를 잘라내 놓고 모바일에서는 그 구성품이 포함되지 않는 것처럼 보이게 만드는 편집은 피합니다.

sizes 예제는 실제 레이아웃을 설명해야 합니다

다음은 원리를 설명하기 위한 예제입니다. 작은 화면에서는 뷰포트에서 좌우 여백 합계 40 CSS 픽셀을 뺀 폭을 사용하고, 큰 화면에서는 표시 폭을 최대 800 CSS 픽셀로 제한한다고 가정했습니다. 실제 사이트의 본문 폭이나 분기점과 다르면 그대로 복사하지 않습니다. 후보 파일의 이름과 폭도 설명용이며 이 글에서 실제 파일을 제공하는 코드가 아닙니다.

<img
  src="tray-800.jpg"
  srcset="tray-400.jpg 400w, tray-800.jpg 800w, tray-1600.jpg 1600w"
  sizes="(max-width: 840px) calc(100vw - 40px), 800px"
  width="1600" height="1000"
  alt="트레이의 테두리와 손잡이를 포함한 외형을 보여주는 사진">

이 예제에서 sizes는 CSS를 대신하지 않습니다. 이미지가 실제로 본문 폭을 사용하도록 만드는 레이아웃과 함께 대조해야 합니다. 편집자가 화면 여백을 20에서 24로 바꾸거나 큰 화면의 본문을 두 열로 나누었다면, 힌트가 이전 표시 공간을 가리키고 있을 수 있습니다. 레이아웃 변경 요청에 이미지 후보와 힌트 확인을 같이 넣어야 하는 이유입니다.

파일 후보의 실제 폭을 잘못 적는 오류와 힌트가 레이아웃보다 크게 잡히는 오류도 구분합니다. 전자는 후보의 명세가 사실과 다른 문제이고, 후자는 이미지가 차지하는 공간을 잘못 설명한 문제입니다. 둘 다 파일 용량만 줄이는 작업으로 해결된다고 보지 않습니다. 검수표에는 실제 후보 폭, 선언한 폭, 페이지 표시 폭을 각 열로 남겨 어느 단계에서 어긋났는지 찾습니다.

화면 캡처만으로 내려받은 후보를 판정하지 않습니다

검수자는 브라우저 개발자 도구의 네트워크 목록에서 이미지 요청 URL과 전송 정보를 확인하고, 선택한 이미지 요소의 currentSrc와 대조할 수 있습니다. currentSrc는 현재 요소가 사용하는 이미지 주소를 확인하는 데 도움이 됩니다. 사용 방법은 MDN currentSrc 문서를 참고합니다. 개인정보가 포함된 요청이나 관리자 세션을 외부로 공유하지 않고 이미지 관련 항목만 기록합니다.

화면을 넓혔다가 좁히는 동작만 반복하면 이미 받은 큰 후보나 캐시의 영향이 남을 수 있습니다. 각 조건을 새로 확인할 때는 캐시 사용 여부와 새로고침 방식을 검수 조건에 적습니다. 이것은 항상 같은 파일 선택을 보장하기 위한 절차가 아니라, 서로 다른 검사자가 어떤 조건에서 관찰했는지 비교하기 위한 기록입니다. 실제 기기의 화면 밀도와 확대 상태도 가상 뷰포트의 폭과 별도로 남깁니다.

이미지 요청이 보이지 않으면 먼저 화면 아래의 지연 로딩 이미지인지 확인합니다. 아직 화면 가까이 오지 않은 이미지에 대해 요청이 없다는 이유만으로 파일이 깨졌다고 판정하지 않습니다. 해당 위치까지 이동한 뒤 요청이 발생하는지, 최종 응답이 정상인지, 요소에 실제 이미지가 표시되는지 순서대로 봅니다. 반대로 로딩 아이콘이 사라졌다는 사실만으로 필요한 정보가 선명하다고 보지도 않습니다.

선택 결과와 읽기 품질을 한 장부에서 비교합니다

기술 검수 장부에는 페이지 주소, 이미지 역할, 표시 폭, 화면 밀도, 선택 URL, 파일의 실제 폭, 관찰 시각을 적습니다. 편집 검수 칸에는 무엇이 읽혀야 하는지를 기록합니다. 예를 들어 손잡이 결합부 사진이라면 연결 위치가 보이는지, 치수 도식이라면 측정선의 끝점이 구분되는지 확인합니다. “이미지 정상”이라는 한 칸 대신 선택 결과와 설명 품질을 분리하면 작은 후보가 불필요하게 흐린지, 큰 후보가 정보를 추가하지 못하는지 대화하기 쉬워집니다.

이 표는 실제 성능 측정값이 아니라 검수 항목의 예시입니다. 특정 후보 크기나 전송량이 모든 사이트에 적합하다고 정하지 않습니다. 이미지가 맡는 정보량과 페이지 위치, 사용자가 확대해서 볼 필요, 운영자가 관리할 수 있는 후보 수를 함께 고려합니다. 필요 이상의 후보 파일을 만들면 교체 시 누락할 위치가 늘어날 수도 있으므로, 운영 장부에서 함께 관리할 수 있는 묶음으로 정리합니다.

파일을 가볍게 만들면서 정보까지 없애지 않습니다

상품 상세 사진은 압축 후 색상 차이, 질감, 얇은 연결선이 달라질 수 있습니다. 작은 도식 안의 글자는 파일이 정상 표시돼도 읽기 어려울 수 있습니다. 따라서 이미지의 정보는 가능한 한 본문 설명과 표에도 남깁니다. 복잡한 도식에 대한 접근성 원칙은 W3C WAI 복잡한 이미지 안내를 참고합니다. 이미지 속 작은 글씨를 대체 텍스트에 무작정 모두 넣기보다, 주변 문서에서 독자가 같은 의미를 확인할 수 있게 구성합니다.

후보마다 다른 대체 설명을 붙여 별개의 제품처럼 읽히게 만들 필요는 없습니다. 해상도 후보가 같은 의미를 전달한다면 이미지 요소의 설명도 그 의미를 중심으로 유지합니다. 구도가 달라져 사실의 범위까지 바뀌면 설명이 여전히 맞는지 다시 봅니다. 대표 사진에 “전체 구성”이라고 썼는데 모바일 구도에서 구성품 일부가 빠졌다면 이미지 선택과 문장을 함께 수정해야 합니다. 파일 최적화와 내용 검수는 별개의 담당자가 하더라도 한 번의 공개 승인으로 연결하는 편이 좋습니다.

공개 전에 마지막으로 확인할 순서

1. 사진·도식의 역할과 핵심 정보를 먼저 적습니다.
2. 후보 파일의 실제 폭·비율·상품 상태를 대조합니다.
3. 페이지의 표시 폭과 sizes 힌트가 같은 레이아웃을 설명하는지 봅니다.
4. 작은 화면과 큰 화면에서 선택 URL·표시 상태를 각각 기록합니다.
5. 지연 로딩 이미지는 해당 위치까지 이동한 뒤 판단합니다.
6. 파일 교체 후 본문·대체 설명·다운로드 링크·옵션 이미지가 같은 버전인지 확인합니다.

검수의 결론은 “작은 파일을 썼으니 빠르다”가 아니라 어느 페이지의 어떤 이미지가 어떤 조건에서 무엇을 선택했고, 독자가 필요한 정보를 확인할 수 있었는지입니다. 페이지 전체 속도는 이미지 외의 글꼴, 스크립트, 서버 응답 등에도 영향을 받으므로 한 장의 파일 선택 결과를 사이트 전체 성능이나 구매 전환 개선으로 확대하지 않습니다. 문제가 보이면 후보 파일, 표시 폭 힌트, 편집 구도 중 수정할 대상을 구분해 다시 확인합니다.

운영 장부에는 최종 승인된 이미지 묶음과 검사 조건을 같이 남깁니다. 모바일 구도를 나중에 바꿨다면 기존의 승인 기록을 그대로 재사용하지 않습니다. 이미지가 한 번 정상 선택됐다는 사실은 향후 모든 레이아웃과 모든 기기에서 같은 결과가 유지된다는 뜻이 아닙니다. 반복해서 관리할 수 있는 검수 절차를 만드는 것이 원본 파일을 크게 또는 작게 만드는 단발 작업보다 중요합니다.

참고 자료와 적용 범위

• MDN: 반응형 이미지 — 후보 파일·표시 공간 힌트·구도 변경의 개념.
• MDN: HTMLImageElement.currentSrc — 현재 이미지 요소가 사용하는 주소 확인.
• W3C WAI: 복잡한 이미지 — 도식의 정보를 문서 설명과 함께 제공하는 원칙.

자료 대조일: 2026-09-13. 본문의 숫자·파일 이름·검수 장부는 설명용 예제이며 실제 고객 사이트의 성과 자료나 실측 보고서가 아닙니다. 작성·운영: 오경연 / detailry. 오류와 보완 자료는 정정·문의로 전달할 수 있습니다.

함께 읽기: 이미지 로딩 전 공간 예약 · 이미지 설명의 역할 구분.

후보가 커진 원인을 기록표에서 좁히는 예시

아래 선택 파일은 가상 관측 기록입니다. 브라우저가 이 조건에서 반드시 해당 파일을 고른다는 예측표가 아닙니다.

큰 후보를 받았다는 기록만으로 이미지 압축 문제라고 결론내리면 sizes의 잘못된 슬롯 폭을 놓칠 수 있습니다. 먼저 같은 구도인지, 표시폭과 DPR·확대 조건이 같았는지 대조한 뒤 전후 요청을 비교합니다. 전송량이 줄어도 치수선이나 작은 글자를 읽지 못하면 그 후보는 승인하지 않습니다. 파일 선택 확인과 읽기 품질 확인을 따로 끝내야 합니다.