출처 : Reason Under Pressure - Your Images Are (Probably) Oversized (2025.09.06)

✼✼ disclaimer ✼✼ 본 글은 AI 번역 후 직접 검수하여 작성했습니다. 효율적인 정보 전달을 위해 AI 번역을 활용하되, 부자연스러운 표현은 수정했습니다. 번역 오류가 있을 수 있으니 정확한 내용은 원문을 확인하시기 바랍니다.

<img/> 태그에 sizes 속성을 설정하고 있나요?

아니라고요?

그렇다면 당신은 필요 이상으로 큰 이미지를 제공하고 있을 가능성이 높습니다. 심지어 데스크톱처럼 큰 화면에서도 말이죠.

"나는 NextJS의 <Image/> 컴포넌트를 쓰니까 걱정할 필요 없어요"라고 말하고 있나요? 안타깝게도 그렇지 않습니다.

현실 점검

디자이너가 막 완성한 멋진 랜딩 페이지를 구현하고 있다고 해봅시다. 대부분의 랜딩 페이지가 그렇듯, 히어로 섹션에 눈에 띄는 이미지가 있을 겁니다.

위 예시에서 히어로 이미지는 가로와 세로로 늘어나며(물론 원본 비율은 항상 유지하면서) 화면 거의 전체를 덮습니다. 그래서 렌더링되는 크기는 사용자 기기의 크기에 따라 직접적으로 달라지죠.

다행히 디자이너도 이를 이해하고 있어서, 그 어떤 화면 크기에서도 이미지가 선명하게 보이도록 매우 높은 해상도의 이미지를 보냅니다. 예를 들어 3600x2400 픽셀 정도로요. 이 정도 픽셀이면 가장 큰 모니터에서도 선명하게 보일 겁니다.

하지만 문제는, 대부분의 사용자가 이 모든 픽셀을 활용할 만큼 큰 화면을 가지고 있지 않다는 점입니다. 그래서 이렇게 큰 이미지를 다운로드하게 하는 건 사실상 대역폭과 컴퓨팅 자원의 낭비나 마찬가지죠. 이 자원들은 다른 곳에 더 잘 활용될 수 있는데 말입니다.

"아! 하지만 나는 NextJS <Image> 컴포넌트를 쓰니까 이런 문제가 없어요. 이미지를 최적화해서 필요 이상으로 크지 않게 만들어주거든요."

그래서 별 고민 없이 NextJS <Image/> 컴포넌트를 이렇게 사용합니다:

<Image 
  priority // FCP의 일부니까 즉시 로드하고 싶어요
  src="/hero-image.jpg" 
  alt="Moutains" 
  className="relative w-screen h-screen object-cover" 
  width={3600} 
  height={2400}
/>

이게 맞아 보인다면, 안타까운 소식이 있습니다.

하나 보여드리겠습니다:

이건 위에서 본 바로 그 랜딩 페이지인데, 이번엔 훨씬 좁은 뷰포트에서 본 모습입니다. 정확히는 425px 너비로요.

NextJS <Image> 컴포넌트를 이런 식으로 사용하는 것만으로 이미지 크기가 적절하게 조정된다면, 위 예시에서는 원본보다 훨씬 작은 이미지가 제공될 거라고 기대할 수 있겠죠.

하지만 실제로는 이렇습니다:

이미지의 렌더링 크기(실제 표시 크기)는 425 x 810 픽셀인데, 이미지 파일 자체의 크기(고유 크기)는 원본보다도 더 큽니다. 이미지 파일 용량도 원본만큼 크고요.

여러분 중 일부는 이게 NextJS 개발 모드의 부작용이 아닌지 궁금해할 수 있습니다. 개발 모드에서는 디버깅과 개발 편의를 위해 일부 최적화를 의도적으로 비활성화하는 것으로 알려져 있으니까요. 하지만 아닙니다. 이건 실제로 프로덕션 모드에서 실행된 결과입니다.

그리고 명확히 하자면, 이건 NextJS를 꼬집으려는 게 아닙니다(애초에 NextJS의 잘못도 아니고요). 예시로 선택한 이유는 단지 가장 널리 사용되는 React (메타)프레임워크이기 때문입니다.

그리고 이게 NextJS만의 문제라고 생각한다면 오해입니다. Vue 기반 (메타)프레임워크인 Nuxt에서도 거의 동일한 결과를 얻으니까요.

이제 sizes prop을 설정하면 어떻게 되는지 봅시다:

<Image 
  priority // FCP의 일부니까 즉시 로드하고 싶어요
  src="/hero-image.jpg" 
  alt="Moutains" 
  className="relative w-screen h-screen object-cover" 
  width={3600} 
  height={2400}
  sizes="100vw" // 뷰포트 전체를 가로로 차지하니까 100vw
/>

아, 이제야 제대로 나왔네요! 현재 뷰포트에 적절한 크기의 이미지가 나왔고, 이게 파일 크기에도 엄청난 영향을 미칩니다. 이제 원본보다 약 25배나 작아졌거든요.

참고

원본의 약 1/6 너비인 이미지가 어떻게 약 25배나 작아지는지 궁금할 수 있습니다.

이미지는 직사각형이기 때문에, 가로세로 비율을 유지하면서 한 차원(너비나 높이)을 선형적으로 조정하면 이미지의 픽셀 수는 제곱으로 변한다는 걸 기억하세요. 즉, 이미지 너비를 두 배로 늘리면 픽셀 수는 네 배가 되고, 반대로 너비를 반으로 줄이면 픽셀 수는 원래의 1/4이 됩니다.

또한 압축 알고리즘도 관여하는데, 같은 이미지라도 크기에 따라 압축률이 달라질 수 있습니다. 그래서 36배가 아닌 25배 정도 작아진 거죠.

반응형 이미지의 작동 원리

방금 NextJS의 <Image> 컴포넌트에 sizes 속성만 전달해도 사용자에게 제공하는 이미지에 엄청난 영향을 미친다는 걸 봤습니다. 하지만 이야기는 여기서 끝이 아닙니다.

이 글에서는 반응형 이미지를 다루면서 마주하는 문제들, 그리고 프론트엔드에서 이를 해결하는 실전 방법을 함께 살펴보겠습니다.

그러기 위해 먼저 반응형 이미지가 어떤 문제를 해결하는지 이해해야 합니다.

픽셀에 관하여

일반적으로 이미지의 픽셀이 많을수록 더 좋아 보입니다. 픽셀이 많다는 건 정보가 많고 시각적 표현이 더 세밀하다는 뜻이니까요. 하지만 한계가 있습니다. 특정 임계값을 넘으면 픽셀을 더 추가해도 보는 사람에게는 이미지가 얼마나 세밀해 보이는지에 전혀 기여하지 못하는 지점이 있죠.

명확히 하자면, 여기서 말하는 건 인간의 지각이 아니라 이미지를 표시하는 기기의 물리적 한계에 관한 것입니다.

디지털 디스플레이 기기(디지털 모니터, 노트북 디스플레이, 모바일 화면 등)의 맥락에서 픽셀은 해당 기기가 다룰 수 있는 가장 작은 시각적 단위입니다. 따라서 기기가 가진 픽셀 수는 특정 시점에 그 기기에서 표시할 수 있는 디지털 픽셀 수에 물리적 제한을 가합니다.

예를 들어, 20x20 해상도(즉, 각각 20개의 물리적 픽셀로 이루어진 20개의 행)를 가진 기기에 이미지를 표시한다고 해봅시다. 표시할 이미지가 몇 픽셀이든, 이미지 전체를 이 기기에 표시하려면 항상 이 400픽셀에 맞춰야 합니다.

실제로 이는 너비가 20픽셀보다 넓거나 높이가 20픽셀보다 큰 이미지의 경우, 하나의 기기(물리적) 픽셀이 두 개 이상의 디지털 픽셀을 표현하는 데 사용된다는 의미입니다. 결과적으로 정보를 잃게 되므로, 이미지는 표시되는 기기의 픽셀 수만큼만 보이게 됩니다.

이는 사용자 화면보다 픽셀이 많은 이미지를 제공하는 건 낭비이며, 항상 사용자에게 적절한 해상도의 이미지를 제공하도록 노력해야 한다는 걸 말해줍니다.

반응형 이미지는 바로 이 문제를 해결합니다.

각자에게 맞는 이미지를

화면 크기마다 다른 해상도의 이미지가 필요하다는 건 이제 알았습니다. 그렇지 않으면 사용자의 소중한 CPU 사이클과 대역폭을 낭비하게 되죠. 그렇다면 이제 남은 질문은, 어떻게 구현하느냐는 겁니다.

<img> 태그에 단순히 src만 전달한다면, 화면 크기와 관계없이 하나의 이미지만 제공할 수 있습니다. 해답은 <img> 태그의 두 가지 속성에 있습니다: srcset과 sizes.

srcset 속성은 src 속성의 일종의 "대체재" 역할을 합니다. 항상 제공되는 단일 이미지 대신, 특정 조건에서 제공될 여러 이미지를 지정할 수 있게 해주죠.

앞에서 본 랜딩 페이지 예시로 돌아가서, 순수 HTML로 작성한다면 이런 식으로 할 수 있습니다:

<img
  src="/hero-image.jpg"
  alt="Moutains"
  class="relative w-screen h-screen object-cover"
  width="3600"
  height="3400"
  srcset="
    /hero-image-425.jpg  425w,
    /hero-image-800.jpg  800w,
    /hero-image.jpg     3600w
  "
/>

srcset은 이미지 URL과 의도된 너비의 목록을 쉼표로 구분해서 받습니다.

참고

이미지의 의도된 너비만 지정하면 되고 높이는 지정할 필요가 없습니다. 브라우저는 항상 가로세로 비율을 그대로 유지한다고 가정하기 때문입니다.

위 예시에서는 브라우저에게 최대 425픽셀 너비의 화면에는 /hero-image-425.jpg에 있는 이미지를 제공하고, 426픽셀부터 800픽셀 너비까지는 /hero-image-800.jpg에 있는 이미지를, 그리고 마지막으로 800픽셀보다 큰 화면에는 원본 이미지를 제공하라고 말하고 있습니다.

srcset 속성은 때때로 혼란스러울 수 있으니 몇 가지를 명확히 하겠습니다:

첫째, 이미지 위치 바로 뒤에 오는 의도된 너비가 px 같은 게 아니라 이상한 w 단위를 사용한다는 걸 주목하세요. 이유가 있는데 나중에 설명하겠지만, 지금은 w를 px처럼 생각해도 됩니다. 그래서 425w는 425px로 해석되는 식이죠.

둘째, 논리적으로 세 번째 이미지 옵션(/hero-image.jpg 3600w)의 경우 마지막 옵션이므로 제공할 최대 너비(3600w)를 명시할 필요가 없어 보이지만, srcset은 모든 이미지 옵션 뒤에 항상 포함하도록 요구합니다. 그래서 이 경우 원본 이미지 너비와 일치하는 3600w를 사용했지만, 800w보다 큰 다른 값을 사용해도 됩니다.

<img> 태그에 srcset을 전달하면, 브라우저가 자동으로 화면(viewport)의 현재 너비에 따라 적절한 이미지를 요청하고 표시합니다.

여기서 눈치 빠른 분들은 알아차렸을 겁니다. 지금 방식은 이미지가 화면을 가득 채우기 때문에 작동하는 겁니다. 즉, 항상 화면만큼 넓으니까 화면이 예를 들어 425픽셀 너비면 이미지도 425픽셀 너비가 필요한 거죠. 하지만 이미지 너비가 화면 너비의 일부에 불과하다면 어떻게 될까요?

여기서 sizes 속성이 등장합니다.

예를 들어 설명하자면, 랜딩 페이지에서 어떤 이유로 이미지를 화면 중앙에 두고 절반 크기로만 보여주고 싶다고 칩시다 (보기 안 좋다는 건 알지만, 지금은 그게 중요한 게 아닙니다):

이제 화면이 800픽셀 너비일 때, 이미지의 표시 크기는 400픽셀만 될 텐데, 여전히 800픽셀 너비의 이미지를 제공하게 됩니다.

하지만 sizes 속성을 사용하면 브라우저에게 이미지에 필요한 실제 너비를 알려줄 수 있습니다.

이렇게 사용합니다:

<img
  src="/hero-image.jpg"
  alt="Moutains"
  class="relative w-[50%] object-cover"
  width="3600"
  height="3400"
  srcset="
    /hero-image-425.jpg  425w,
    /hero-image-800.jpg  800w,
    /hero-image.jpg     3600w
  "
  sizes="50vw"
/>

이 경우 이미지가 화면 너비에 비례해서 크기가 조정되므로, vw 단위를 사용해서 sizes를 지정합니다. 하지만 px, em, rem, vh 등 다른 CSS 단위도 사용할 수 있습니다. 퍼센트는 제외하고요. 실제로 calc(50vw - 12px)나 min(40vw, 320px) 같은 CSS 함수도 사용할 수 있습니다.

sizes 속성의 또 다른 강력한 기능은 미디어 쿼리로 중단점마다 다른 크기를 지정할 수 있다는 겁니다. 중단점에 따라 이미지 크기 로직이 달라지는 경우에 유용합니다.

현재 중단점에 따라 다른 크기를 지정할 때는 이렇게 합니다:

<img
  src="/hero-image.jpg"
  alt="Moutains"
  class="
    relative object-cover 
    w-[200px] min-[400px]:w-[400px] 
    min-[800px]:w-[600px]
  "
  width="3600"
  height="3400"
  srcset="
    /hero-image-425.jpg  425w,
    /hero-image-800.jpg  800w,
    /hero-image.jpg     3600w
  "
  sizes="
    (width < 400px) 200px,
    (400px <= width < 800px) 400px,
    (800px <= width) 600px
  "
/>

마지막으로, sizes에 전달할 수 있는 "특별한" 값이 있는데 바로 auto입니다. auto를 사용하면 브라우저가 자동으로 올바른 이미지 크기를 추론합니다.

하지만 함정이 있습니다: 이미지가 지연 로드(lazy load)될 때만 작동합니다.

이미지 로딩 전략에 대한 여담

<img> 태그에는 해당 이미지에 대한 두 가지 로딩 전략 중 하나를 선택할 수 있는 loading 속성이 있습니다: 즉시 로딩(loading="eager")과 지연 로딩(loading="lazy").

기본 전략은 이미지를 즉시 로드하는 것입니다(loading 속성을 지정하지 않으면 이 전략이 사용됩니다). 이미지는 <img> 태그가 파싱되는 즉시 가져오기 시작합니다.

그다음 지연 로딩 전략이 있는데, 이미지가 화면에 들어올 때까지 가져오기를 연기합니다.

참고

실제로 브라우저는 지연 로드 이미지가 화면에 들어올 때까지 꼭 기다리지는 않습니다. 이미지가 실제로 화면에 나타날 때 이미 로드되어 있도록 "버퍼 거리(buffer-distance)"를 두고 미리 가져올 수 있거든요. 또한 브라우저는 사용자의 대역폭이나 다른 리소스가 가져와지고 있는지 여부 같은 다른 요인도 고려해서 이미지를 가져올 정확한 시점을 결정할 수 있습니다.

핵심은 "이미지가 화면에 들어올 때까지 기다렸다가 가져온다"는 말을 문자 그대로 받아들이면 안 된다는 겁니다. 브라우저마다 실제 구현 방식이 다를 수 있으니까요.

얼마 전까지만 해도 JavaScript와 IntersectionObserver를 사용해서 이미지를 지연 로드해야 했지만, 이제 다행히 브라우저가 기본적으로 지원합니다.

기본값이 즉시 로딩인 건 역사적인 이유 때문이지만, 대부분은 지연 로딩을 쓰는 게 좋습니다. 즉시 로딩이 확실히 필요한 경우는 첫 화면 렌더링(FCP)에 바로 보여야 하는 이미지 정도입니다.

자동 크기 조정

다시 강조하면, 이미지의 loading 속성이 lazy로 설정된 경우에만 sizes를 auto로 지정할 수 있으며, 그러면 브라우저가 이미지의 구체적인 크기(이미지의 렌더링 크기)를 알 때까지 기다렸다가 적절한 이미지를 요청합니다.

아래 데모를 확인해보세요:

이 데모에는 세 개의 다른 이미지가 있고, 각 이미지 위에는 현재 제공되는 이미지 파일의 너비를 나타내는 숫자가 겹쳐져 있습니다(onload 이벤트를 연결해서 새 이미지 파일이 로드될 때마다 추적합니다).

모든 이미지가 정확히 같은 구체적 크기(이 경우 min(50vw, 500px))를 가지고 있는 걸 볼 수 있습니다.

하지만 sizes 속성값은 다릅니다:

<img
  width="6336"
  height="9504"
  srcset="
    img-1_100.jpg   100w,
    img-1_200.jpg   200w,
    img-1_300.jpg   300w,
    img-1_400.jpg   400w,
    img-1_500.jpg   500w,
    img-1_600.jpg   600w,
    img-1_700.jpg   700w,
    img-1_800.jpg   800w,
    img-1_900.jpg   900w,
    img-1_1000.jpg 1000w,
    img-1_1100.jpg 1100w,
    img-1_1200.jpg 1200w
  "
  sizes="min(50vw, 500px)"
/>

<img
  width="3753"
  height="5017"
  sizes="auto"
  srcset="
    img-2_100.jpg   100w,
    img-2_200.jpg   200w,
    img-2_300.jpg   300w,
    img-2_400.jpg   400w,
    img-2_500.jpg   500w,
    img-2_600.jpg   600w,
    img-2_700.jpg   700w,
    img-2_800.jpg   800w,
    img-2_900.jpg   900w,
    img-2_1000.jpg 1000w,
    img-2_1100.jpg 1100w,
    img-2_1200.jpg 1200w
  "
  loading="lazy"
/>

<img
  width="2667"
  height="4000"
  sizes="auto"
  srcset="
    img-3_100.jpg   100w,
    img-3_200.jpg   200w,
    img-3_300.jpg   300w,
    img-3_400.jpg   400w,
    img-3_500.jpg   500w,
    img-3_600.jpg   600w,
    img-3_700.jpg   700w,
    img-3_800.jpg   800w,
    img-3_900.jpg   900w,
    img-3_1000.jpg 1000w,
    img-3_1100.jpg 1100w,
    img-3_1200.jpg 1200w
  "
  loading="eager"
/>

첫 번째 이미지에서는 sizes를 명시적 값인 min(50vw, 500px)로 설정했고 loading은 기본값인 eager입니다.

두 번째 이미지에서는 sizes가 auto로 설정되고 loading은 lazy입니다.

세 번째 이미지에서는 sizes가 auto로 설정되었지만 loading이 eager로 설정되었습니다(명시적으로 설정해서 눈에 띄게 했지만, 설정하지 않는 것과 동일합니다. eager가 기본값이니까요).

첫 번째와 두 번째 이미지의 경우 브라우저가 올바른 이미지 파일을 요청할 수 있지만, 세 번째의 경우 sizes="auto"가 즉시 로딩에서는 작동하지 않아서 기본 sizes 값인 100vw로 되돌아가거든요. 즉, 이미지가 화면 전체만큼 넓다고 간주합니다. 이래서 이미지의 렌더링 크기가 500px를 넘지 않는데도 브라우저가 계속 500px보다 큰 이미지를 요청하는 겁니다.

지연 로딩과 즉시 로딩이 어떻게 작동하는지 조금만 생각해보면 모두 말이 됩니다.

즉시 로딩에서는 <img> 태그를 읽자마자 이미지를 요청하기 때문에, 브라우저가 아직 HTML 파싱도 다 끝내지 못한 상태입니다. 당연히 레이아웃 단계도 시작하지 않았고, 그래서 이미지가 화면에 보이는지, 크기가 얼마인지 알 길이 없죠.

마지막으로, sizes="auto"가 모든 브라우저에서 지원되는 건 아니라는 점을 기억하세요(https://caniuse.com/mdn-html_elements_img_sizes_auto).

예를 들어, 동일한 데모를 이번엔 Firefox에서 해봤습니다:

따라서 sizes="auto"가 보편적으로 지원될 때까지는 auto 다음에 항상 대체값을 함께 넣어야 합니다. 다음처럼요:

<img
  width="2667"
  height="4000"
  sizes="auto, min(50vw, 500px)"
  srcset="
    img-2_100.jpg   100w,
    img-2_200.jpg   200w,
    img-2_300.jpg   300w,
    img-2_400.jpg   400w,
    img-2_500.jpg   500w,
    img-2_600.jpg   600w,
    img-2_700.jpg   700w,
    img-2_800.jpg   800w,
    img-2_900.jpg   900w,
    img-2_1000.jpg 1000w,
    img-2_1100.jpg 1100w,
    img-2_1200.jpg 1200w
  "
  loading="lazy"
/>

정확한 sizes를 지정하기 어렵더라도, 뭐라도 전달하는 게 낫습니다. 안 그러면 기본값인 100vw로 돌아가는데, 대부분의 경우 필요 이상으로 큰 값이거든요.

픽셀에 관하여 - 2부

반응형 이미지에 대해 논의해야 할 마지막 주제가 하나 있습니다. 바로 기기 픽셀 비율(DPR)입니다.

먼저 픽셀의 정의로 돌아가야 합니다.

지금까지는 기기 픽셀(device pixel)과 CSS 픽셀을 혼용해서 써왔습니다. 때로는 일치하기도 하지만, 엄밀히 말하면 다른 개념이죠.

기기 픽셀은 앞서 말했듯이 해당 기기가 다룰 수 있는 가장 작은 시각적 단위입니다.

반면 CSS 픽셀은 "96dpi 픽셀 밀도를 가진 기기를 팔 길이(보통 28인치) 거리에서 봤을 때 한 픽셀의 시각"으로 정의됩니다. 말이 좀 복잡하지만, 간단히 말해 CSS 픽셀은 특정 기기에서 인치나 센티미터 같은 실제 물리적 거리로 환산된다는 뜻입니다.

참고

CSS 픽셀에 관해서는 여기 담기 어려운 이야기가 더 많지만, 핵심만 말하자면 이렇습니다. CSS 픽셀은 CSS에서는 절대 단위(vw, vh, 퍼센트 같은 상대 단위와 달리)지만, 기기와 그 특성에 따른 물리적 값에 기반해야 한다는 점에서는 상대적입니다.

이렇게 정의된 이유는 CSS 픽셀이 어떤 기기에서든 지각적으로 일관되게 보이도록 하기 위해서입니다.

더 자세한 내용은 여기부터 읽고 여기로 넘어가시면 됩니다.

그렇다면 CSS 픽셀과 기기 픽셀의 관계는 무엇이고, 전자가 후자에 어떻게 매핑될까요?

여기서 기기 픽셀 비율(DPR)이 등장합니다. DPR은 하나의 CSS 픽셀이 몇 개의 기기 픽셀에 해당하는지 지정합니다.

예를 들어, DPR이 1이면 각 CSS 픽셀이 정확히 하나의 기기 픽셀에 매핑됩니다. DPR이 2면 각 CSS 픽셀이 2개의 기기 픽셀에 매핑되는 식이죠.

DPR을 계산하기 위해 브라우저는 기기의 픽셀 밀도, 의도된 읽기 거리(예: TV는 보통 모니터보다 먼 거리에서 보고, 모니터는 휴대폰보다 먼 거리에서 봅니다), 줌 레벨 등 몇 가지를 고려합니다.

예전에는 웹사이트를 렌더링하는 데 사용되는 대부분의 기기(주로 모니터)가 96dpi의 픽셀 밀도를 가지고 있었고 "팔 길이"에서 보도록 의도되었기 때문에, 기기 픽셀이 CSS 픽셀과 정확히 일치했습니다.

하지만 시간이 지나면서, 특히 모바일 기기의 등장과 함께 더 높은 픽셀 밀도를 가진 기기들이 생산되기 시작했고, 이로 인해 하나의 CSS 픽셀이 두 개 이상의 기기 픽셀에 걸쳐지는 기기들이 생겨났습니다.

이미지가 필요 이하도 초과도 아닌 적절한 정보를 담기 위해 몇 픽셀이어야 하는지에 대한 기본 원칙은 동일합니다. 즉, 이미지는 (이상적으로) 표시될 영역이 가진 기기 픽셀 수만큼의 디지털 픽셀을 가져야 합니다.

여기서 중요한 건, 브라우저가 이미지를 렌더링할 때, 어떤 이미지를 제공할지 결정하는 기준인 구체적 크기(concrete size)를 CSS 픽셀로 측정한다는 점입니다. 따라서 브라우저는 적절한 이미지를 고를 때 기기의 픽셀 밀도까지 감안합니다.

예를 들어, DPR이 2인 경우 실제 표시 크기가 200 CSS 픽셀 너비인 이미지라면, 이미지 픽셀과 기기 픽셀이 일대일로 대응되려면 실제 이미지 파일은 400픽셀 너비여야 합니다.

당신의 기기(또는 사용자의 기기) DPR을 확인하는 쉬운 방법은 window 객체의 devicePixelRatio 속성을 통하는 겁니다.

표준 줌 레벨에서 제 모니터의 DPR은 1입니다. (네, 별로 좋지 않죠. 하지만 막 차를 수리했는데 돈이 많이 들어서 모니터 업그레이드는 기다려야 할 것 같네요.)

줌을 예를 들어 150%로 높이면 DPR이 1.5로 증가합니다.

표준 줌 레벨에서 제 노트북의 DPR은 2입니다. 화면의 픽셀 밀도가 더 높거든요. 그리고 제 휴대폰의 DPR은 무려 2.8입니다!

마지막으로, 데모로 돌아가서 이게 이미지에 어떻게 영향을 미치는지 봅시다:

먼저 빨간 사각형에 주목하세요. 특정 DPR을 설정할 수 있는 컨트롤인데, 현재 1로 설정되어 있습니다.

그다음, 이미지의 구체적 크기가 min(50vw, 500px)로 설정되어 있으므로, 316px 너비의 화면에서 158px 너비가 됩니다. DPR이 1인 기기에서는 200px 이미지가 선택됩니다.

DPR을 2로 바꾸면 어떻게 되는지 보세요:

이제 이미지가 여전히 158 CSS 픽셀 너비지만, DPR이 2이면 픽셀 수가 두 배 필요하고, 그래서 이미지의 400px 버전이 선택됩니다.

srcset 속성 얘기로 돌아가면, 픽셀 대신 그 특이한 w 단위로 이미지 너비를 지정했던 걸 기억하실 겁니다. 이게 바로 DPR 때문이죠. w 값은 DPR 곱하기 CSS 픽셀 단위 이미지 크기와 같고, 이는 결국 이미지가 "채워야" 할 실제 기기 픽셀 수를 의미합니다.

또한 srcset 내에서 이미지 크기를 지정할 때 w를 사용하는 대신 DPR 자체를 사용하는 대안도 있다는 걸 언급해야겠네요. 이렇게요:

<img
  width="2667"
  height="4000"
  sizes="auto, min(50vw, 500px)"
  srcset="img-2_500.jpg 1x, img-2_1000.jpg 2x"
  loading="lazy"
/>

w 단위로 숫자를 지정하는 대신, 의도된 DPR 뒤에 x를 붙여서 지정합니다.

하지만 주의할 점이 있습니다. DPR "방식"으로 이미지 크기를 지정하는 건 고정 크기 이미지에만 쓰도록 만들어진 거고, w 방식은 이미지가 고정 크기든 반응형이든 상관없이 쓸 수 있습니다. 그래서 가능하면 w 방식을 쓰는 게 낫습니다.

요약 가이드

이 글을 통해 반응형 이미지의 이유와 방법을 살펴봤으니, 마무리로 필요할 때 다시 참고할 수 있도록 우리가 본 모든 걸 요약한 실용적인 구현 가이드를 드리고 싶습니다.

프론트엔드에서 이미지를 다룰 때 가장 먼저 알아야 할 것은 이 이미지가 반응형이어야 하는지, 즉 렌더링되는 크기가 사용자 화면의 크기에 따라 달라지는지입니다.

화면의 크기와 관계없이 고정된 너비와 높이를 가진 이미지(예: 아이콘)라면, sizes 속성을 이미지의 렌더링 너비(절대 고정값이 됩니다)로 설정하고, 다른 DPR에 적절한 이미지를 제공하도록 srcset도 설정하세요.

<!-- DPR 지정자 사용 -->
<img
  width="24"
  height="24"
  sizes="24px"
  srcset="
    close_icon.jpg     1x,
    close_icon_1.5.jpg 1.5x,
    close_icon_2x.jpg  2x
  "
/>

<!-- 너비 지정자 사용 -->
<img
  width="24"
  height="24"
  sizes="24px"
  srcset="
    close_icon.jpg      24w,
    close_icon_1.5x.jpg 36w,
    close_icon_2x.jpg   48w
  "
/>

렌더링 크기가 화면 크기에 따라 달라지는 이미지의 경우, sizes 속성을 이미지의 렌더링 너비로 설정하고 srcset에는 w 단위 사용을 권장합니다.

또한 이미지가 애플리케이션의 첫 화면 렌더링(FCP)의 일부인지 확인하세요. 그렇지 않다면 loading을 lazy로 설정하고 sizes 값 앞에 auto를 추가하세요.

<!-- FCP -->
<img
  width="2667"
  height="4000"
  sizes="min(50vw, 500px)"
  srcset="
    hero_100.jpg   100w,
    hero_200.jpg   200w,
    hero_300.jpg   300w,
    hero_400.jpg   400w,
    hero_500.jpg   500w,
    hero_600.jpg   600w,
    hero_700.jpg   700w,
    hero_800.jpg   800w,
    hero_900.jpg   900w,
    hero_1000.jpg 1000w,
    hero_1100.jpg 1100w,
    hero_1200.jpg 1200w
  "
/>

<!-- Non FCP -->
<img
  width="8390"
  height="2000"
  loading="lazy"
  sizes="auto, (width < 625px) 100vw, min(750px, 70vw)"
  srcset="
    banner_100.jpg   100w,
    banner_200.jpg   200w,
    banner_300.jpg   300w,
    banner_400.jpg   400w,
    banner_500.jpg   500w,
    banner_600.jpg   600w,
    banner_700.jpg   700w,
    banner_800.jpg   800w,
    banner_900.jpg   900w,
    banner_1000.jpg 1000w,
    banner_1100.jpg 1100w,
    banner_1200.jpg 1200w
  "
/>

참고 자료

[FE/optimization] 당신이 쓰는 이미지, 생각보다 훨씬 크다