이미지 겉핥기 (1) — 포맷과 렌더링

웹에서 이미지는 가장 중요한 콘텐츠이다. HTTP Archive에 따르면 최적화되지 않은 경우 평균 웹페이지에서 이미지가 차지하는 비중은 약 38%에 달하며, web.dev에 의하면 모바일 페이지의 73%가 이미지를 LCP(Largest Contentful Paint) 요소로 사용한다고 한다.

최적화되지 않은 이미지는 페이지를 느리게 만들고, 자연스럽게 검색 엔진 순위도 뒤로 밀리게 된다. Google의 연구에 따르면 페이지 로딩이 1초에서 3초로 늘어나면 이탈률이 32% 증가한다고 하니, 이미지 최적화는 사용자 경험과 비즈니스 성과 모두에 직결되는 문제다.

이번 글에서는 이미지의 기본 개념과 브라우저가 이미지를 처리하는 과정을 정리해보고, 다음 글에서 이를 바탕으로 실제 최적화 전략을 다루려고 한다.

이미지

이미지는 렌더링 관점에서 래스터 이미지와 벡터 이미지 두 가지로 분류된다. 또 래스터 이미지 안에서는 손실을 어느 정도 허용하는지에 따라서 여러 가지 확장자로 분류된다.

1) 렌더링 관점에서의 이미지 분류

• 래스터 이미지 래스터 이미지는 픽셀에 표현하고자 하는 색상을 그려서 이미지 형태로 표현하는 방식이다. (JPEG, PNG, GIF 등) 픽셀로 이미지를 표현하다 보니 품질이 좋은 이미지를 만들기 위해서는 이미지의 용량도 늘어나고 렌더링 속도도 떨어진다.
• 벡터 이미지 벡터 이미지는 수학 방정식을 포함하고 있는 방식의 이미지 형태이다. 컴퓨터는 선의 표현, 크기, 색상 등의 정보를 이미지 안에 있는 계산식으로 연산하여 이미지를 제공한다. 이러한 연산을 사용하다 보니 해상도에 따라서 이미지 용량이 달라지지 않는다.
• 비교표

2) 래스터 이미지 타입

벡터 이미지는 간단하게 SVG 포맷이지만 래스터 이미지에는 색상 표현의 범위, 투명도, 압축 방식에 따라서 다양한 타입이 존재한다.

*GIF의 LZW 압축 자체는 무손실이지만, 원본을 256색 팔레트로 양자화하는 과정에서 색상 정보 손실이 발생한다. 따라서 "팔레트 축소 시 손실 + LZW 무손실 압축"으로 이해하는 것이 정확하다.

JPEG

JPEG는 1992년에 개발된 가장 오래되고 널리 사용되는 이미지 포맷이다.

압축 원리 JPEG는 손실 압축 방식을 사용한다. 이미지를 작은 블록으로 나눈 후, 인간의 눈이 잘 감지하지 못하는 미세한 색상 변화나 디테일을 의도적으로 제거하여 파일 크기를 줄인다. 압축률을 높일수록 파일 크기는 작아지지만 품질도 함께 떨어진다. 일반적으로 품질 75-85% 설정이 시각적 품질과 파일 크기의 균형점으로 알려져 있다.

장점

• 사진처럼 복잡한 색상과 그라데이션이 있는 이미지에 매우 효과적
• 압축률을 자유롭게 조절할 수 있어 용도에 맞게 최적화 가능
• 모든 브라우저와 디바이스에서 완벽하게 지원
• 1600만 색상(24비트 컬러) 표현 가능

단점

• 투명 배경을 지원하지 않음 (항상 불투명)
• 텍스트나 날카로운 선이 있는 이미지에서 블러링 현상 발생
• 저장할 때마다 재압축되어 품질이 조금씩 저하됨 (세대 손실)
• 단색 영역이나 선명한 경계에서 노이즈가 보일 수 있음

적합한 사용 사례: 상품 사진, 풍경 사진, 인물 사진, 복잡한 색상의 배경 이미지

PNG (Portable Network Graphics)

PNG는 1996년 GIF의 특허 문제를 해결하기 위해 개발된 무손실 압축 포맷이다.

압축 원리 PNG는 무손실 압축 방식으로 원본 이미지의 모든 정보를 보존한다. 반복되는 패턴을 찾아내고, 인접한 픽셀 간의 유사성을 활용하여 압축한다. 아무리 많이 저장하고 편집해도 품질이 전혀 저하되지 않는다.

PNG의 종류

• PNG-8: 256색만 표현, 파일 크기가 작음, GIF 대체용
• PNG-24: 1600만 색상 표현, 투명도 없음
• PNG-32: 1600만 색상 + 투명도, 가장 일반적으로 사용

장점

• 256단계의 부드러운 투명도 표현 가능 (반투명 효과)
• 원본 품질을 완벽하게 유지 (무손실 압축)
• 텍스트, 선, 로고 등이 매우 선명하게 표현됨
• 아무리 저장해도 품질 저하 없음
• 점진적 로딩 지원 (위에서 아래로 천천히 나타남)

단점

• 사진의 경우 JPEG보다 파일 크기가 2-5배 큼
• 애니메이션을 지원하지 않음
• 압축률을 조절할 수 없어 무조건 무손실로만 저장됨

적합한 사용 사례: 로고, 아이콘, UI 요소, 투명 배경이 필요한 이미지, 텍스트가 포함된 이미지, 스크린샷, 다이어그램

GIF (Graphics Interchange Format)

GIF는 1987년 CompuServe가 개발한 가장 오래된 웹 이미지 포맷이다.

압축 원리 GIF는 이미지를 256색으로 축소한 후 LZW 알고리즘으로 압축한다. 원본이 수백만 색상을 가지고 있어도 256개의 색상만 선택하여 저장하기 때문에 사진 품질이 크게 떨어진다. 대신 애니메이션을 지원하는 유일한 레거시 이미지 포맷으로 오랫동안 사용되었다.

장점

• 애니메이션 지원 (여러 프레임을 하나의 파일에 저장)
• 모든 브라우저에서 완벽하게 지원
• 투명 배경 지원 (완전 투명 또는 완전 불투명만 가능)
• 단순한 그래픽에는 효율적

단점

• 256색 제한으로 사진 품질이 매우 떨어짐
• 애니메이션 파일 크기가 비효율적 (같은 내용을 MP4로 만들면 10분의 1 크기)
• 부드러운 투명도 표현 불가 (반투명 효과 없음)
• 그라데이션이 계단 현상으로 보임

적합한 사용 사례: 매우 단순한 아이콘 (256색 이하), 레거시 시스템 지원이 필요한 경우

참고: 현대 웹에서 GIF는 점차 사용되지 않는다. Twitter, Imgur, Discord 등은 사용자가 GIF를 업로드하면 자동으로 MP4나 WebP로 변환한다.

WebP

WebP는 2010년 Google이 개발한 현대적인 이미지 포맷이다.

압축 원리 WebP는 비디오 압축 기술(VP8)을 이미지에 적용한다. 손실 압축과 무손실 압축을 모두 지원하며, JPEG와 PNG의 장점을 결합했다. 주변 픽셀을 예측하여 압축 효율을 높이고, 더 작은 블록 단위로 처리하여 JPEG보다 아티팩트가 적다.

장점

• JPEG 대비 25-35% 작은 파일 크기 (같은 품질 기준)
• PNG 대비 26% 작은 파일 크기 (무손실 모드)
• 손실/무손실 압축 모두 선택 가능
• 256단계 투명도 지원 (PNG처럼)
• 애니메이션 지원 (GIF보다 64% 작음)
• 이미지 메타데이터(EXIF) 보존 가능

단점

• Safari 16 미만 버전(2022년 9월 이전)에서 미지원
• JPEG보다 인코딩/디코딩 시간이 조금 더 걸림
• 일부 오래된 이미지 편집 프로그램에서 지원 안 됨

브라우저 지원: Chrome 32+ (2014년), Firefox 65+ (2019년), Edge 18+ (2018년), Safari 16+ (2022년)

적합한 사용 사례: 모든 종류의 웹 이미지 (사진, 로고, 애니메이션), 파일 크기 최적화가 중요한 경우

AVIF (AV1 Image File Format)

AVIF는 2019년 개발된 최신 이미지 포맷으로, 차세대 비디오 코덱(AV1)을 기반으로 한다.

압축 원리 AVIF는 최신 비디오 압축 기술을 활용하여 지금까지 나온 이미지 포맷 중 가장 효율적인 압축을 제공한다. 이미지 특성에 따라 다양한 크기의 블록으로 분할하고, 여러 압축 기법을 동적으로 선택하여 최적의 결과를 만든다. 특히 저용량에서도 높은 품질을 유지하는 것이 특징이다.

장점

• WebP보다 20-30% 더 작은 파일 크기
• 저용량에서도 뛰어난 시각적 품질 유지
• HDR(High Dynamic Range) 이미지 지원
• 12비트 컬러 지원 (더 풍부한 색상 표현)
• 투명도 및 애니메이션 모두 지원
• 무손실 압축도 PNG보다 효율적

단점

• 브라우저 지원이 아직 완벽하지 않음 (2021년부터 점진적 지원)
• 인코딩 시간이 매우 오래 걸림 (WebP의 5-10배)
• 디코딩도 상대적으로 느려 CPU/메모리 사용량이 높음
• 이미지 편집 도구 지원이 부족

브라우저 지원: Chrome 85+ (2020년 8월), Firefox 93+ (2021년 10월), Safari 16.4+ (2023년 3월), Edge 121+ (2024년 1월)

적합한 사용 사례: 최신 브라우저만 타겟으로 하는 서비스, 파일 크기 최적화가 매우 중요한 경우, 고품질 사진을 작은 용량으로 제공해야 할 때

성능 비교 (100KB JPEG 기준)

AVIF:  ~50KB (50% 감소)
WebP:  ~65KB (35% 감소)
JPEG: 100KB (기준)
PNG:  ~250KB (150% 증가)

현대 웹에서의 포맷 제공 전략

<picture> 태그를 활용한 점진적 향상

브라우저가 지원하는 가장 효율적인 포맷을 자동으로 선택하도록 구성한다.

<picture>
  <source srcset="product.avif" type="image/avif">
  <source srcset="product.webp" type="image/webp">
  <img src="product.jpg" alt="상품 이미지" loading="lazy">
</picture>

브라우저는 위에서부터 순서대로 확인하며 지원하는 첫 번째 포맷을 사용한다:

• 최신 Chrome/Firefox → AVIF 사용 (가장 작은 용량)
• Safari 16+ → WebP 사용 (작은 용량)
• 구형 브라우저 → JPEG 사용 (호환성 보장)

Next.js의 자동 포맷 변환

Next.js의 <Image> 컴포넌트는 브라우저에 따라 자동으로 최적의 포맷을 제공한다.

import Image from 'next/image';

<Image
  src="/product.jpg"
  width={800}
  height={600}
  quality={85}
  alt="상품 이미지"
/>

포맷 변환 동작 방식

Next.js는 브라우저의 Accept 헤더를 확인하여 지원 가능한 포맷을 자동으로 판단한다.

// 브라우저 요청 헤더
Accept: image/avif,image/webp,image/apng,image/*

// Next.js가 응답하는 포맷
Content-Type: image/avif  // AVIF 지원 브라우저
Content-Type: image/webp  // WebP만 지원 브라우저
Content-Type: image/jpeg  // 둘 다 미지원 브라우저

내부 처리 과정

1. 브라우저 요청: /product.jpg
   Accept: image/avif, image/webp, image/*

2. Next.js Image Optimization API:
   - Sharp 라이브러리로 실시간 변환
   - AVIF 지원? → product.jpg를 AVIF로 변환하여 제공
   - WebP만 지원? → product.jpg를 WebP로 변환하여 제공
   - 둘 다 미지원? → 원본 JPEG 제공

3. 변환된 이미지 캐싱 (.next/cache/images/)
   - 다음 요청부터는 캐시된 이미지 재사용

포맷 우선순위 설정

next.config.js에서 제공할 포맷의 우선순위를 지정할 수 있다.

// next.config.js
module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'], // 우선순위 순서
  },
}

이렇게 설정하면:

• 개발자는 JPEG 원본만 업로드
• Next.js가 요청 시점에 자동으로 AVIF, WebP로 변환
• 브라우저는 지원 가능한 가장 효율적인 포맷을 제공받음

실제 효과

같은 product.jpg 파일에 대해:

원본 JPEG: 100KB

자동 변환 후:
→ Chrome 사용자: AVIF (~50KB, 50% 감소)
→ Safari 16 사용자: WebP (~65KB, 35% 감소)
→ IE11 사용자: JPEG (100KB, 원본)

해상도와 이미지 디코딩

이미지가 화면에 보이기까지는 디코딩(압축 해제)과 리샘플링(크기 조정)이라는 두 가지 핵심 과정을 거친다. 이 두 과정은 이미지의 해상도에 직접적으로 영향을 받으며, 최적화의 핵심 포인트이기도 하다.

물리적 해상도와 논리적 해상도

2010년 iPhone 4가 출시되었을 때 화면 물리적 해상도(640x960)는 iPhone 3(320x480)의 두 배였다. 하지만 iPhone 4의 화면 크기는 iPhone 3와 거의 동일했다.

일차원적으로 생각해보았을 때, 500x500픽셀 컨테이너에 표시되는 이미지는 500x500픽셀 크기라고 생각하겠지만, 실제로는 다르다는 것이다.

물리적 해상도 (Physical Resolution)

물리적 해상도는 디스플레이의 실제 픽셀 수를 의미하며, 화면이 얼마나 선명하게 보일지를 결정하는 주요 요인이다. 물리적 해상도가 높을수록 **픽셀 밀도(PPI, Pixels Per Inch)**가 높아지고, 개별 픽셀이 눈에 보이지 않게 된다.

iPhone 3: 320 × 480 물리적 픽셀
iPhone 4: 640 × 960 물리적 픽셀

→ 같은 화면 크기에 4배 많은 픽셀
→ 훨씬 선명한 텍스트와 이미지

논리적 해상도 (Logical Resolution / CSS Pixels)

논리적 해상도는 소프트웨어가 디스플레이에서 인식하는 가상의 해상도다.

iPhone 3: 320 × 480 논리적 픽셀 (= 물리적 픽셀)
iPhone 4: 320 × 480 논리적 픽셀 (물리적으로는 640 × 960)

흔히 Figma에 정의된 px 단위가 논리적 해상도이며, CSS에서 사용하는 px 단위도 논리적 픽셀이다. 개발자는 논리적 픽셀로 UI를 설계하되, 이미지는 물리적 해상도를 고려하여 제공해야 한다.

DPR (Device Pixel Ratio)

물리적 해상도와 논리적 해상도의 비율을 **DPR(Device Pixel Ratio)**이라고 한다.

DPR = 물리적 픽셀 / 논리적 픽셀

iPhone 3: 320 / 320 = 1 (DPR 1x)
iPhone 4: 640 / 320 = 2 (DPR 2x)
iPhone 12 Pro: 1170 / 390 = 3 (DPR 3x)

리샘플링 — DPR이 이미지에 미치는 영향

200×200 이미지가 있다고 가정해보자. CSS로 width: 200px을 지정하면 두 기기에서 같은 크기로 보인다. 하지만 내부적으로는 다른 일이 일어난다.

DPR 1x (iPhone 3)

논리적 200px = 물리적 200px

원본 이미지: 200 × 200 픽셀
필요한 픽셀: 200 × 200 픽셀

→ 1:1 매핑, 리샘플링 불필요
→ 선명하게 표시됨 ✅

이미지 픽셀     디스플레이 픽셀
    ■       →      ■
    (1:1 대응)

DPR 2x (iPhone 4)

논리적 200px = 물리적 400px

원본 이미지: 200 × 200 픽셀
필요한 픽셀: 400 × 400 픽셀

→ 업샘플링 필요! (2배 확대)
→ 흐릿하게 표시됨 ❌

이미지 픽셀     디스플레이 픽셀
              ┌───┬───┐
    ■    →    │ ■ │ ■ │   (1개가 2개로 늘어남)
              └───┴───┘

브라우저는 부족한 픽셀을 정해진 스케일링 알고리즘으로 채우게 되는데, 이 과정에서 이미지가 흐릿해진다.

반대로 DPR 2x 기기에서 800×800 이미지를 200px 영역에 표시하면 다운샘플링이 발생한다. 시각적으로는 선명하지만, 필요 이상으로 큰 이미지를 다운로드하고 디코딩하는 데 불필요한 비용이 든다.

이미지 디코딩 — 해상도가 메모리에 미치는 영향

이미지 디코딩은 압축된 바이트를 RGBA 비트맵으로 변환하는 과정이다. 결과물은 픽셀당 4바이트(Red, Green, Blue, Alpha 각 8비트)를 사용하므로, 메모리 사용량은 width × height × 4 bytes로 계산된다.

100KB JPEG가 실제 메모리에서 차지하는 용량: 만약 해당 이미지가 1500×1000 픽셀이라면, 디코딩 후 메모리 사용량은 1500 × 1000 × 4 = 6MB로 원본의 약 60배에 달한다.

핵심은 디코딩 비용은 압축 파일 크기가 아니라 해상도(픽셀 수)에 비례한다는 점이다. 아무리 압축률이 좋은 AVIF를 사용하더라도, 4000×3000 이미지를 디코딩하면 48MB의 비트맵이 메모리에 올라간다. 그리고 이 비트맵이 200px 영역에 표시된다면, 브라우저는 다시 리샘플링(다운스케일링)을 수행해야 한다.

즉 이미지 포맷 최적화와 해상도 최적화는 별개의 문제다. 포맷은 네트워크 전송 비용을 줄이고, 해상도 최적화는 디코딩·리샘플링 비용을 줄인다.

해상도 최적화 방법

srcset, sizes, picture 태그

DPR과 뷰포트에 맞는 적절한 크기의 이미지를 제공하는 것이 핵심이다. srcset의 w 디스크립터는 이미지의 실제 픽셀 너비를, sizes는 뷰포트 크기별로 이미지가 차지할 CSS 너비를 브라우저에 알려준다. 브라우저는 이 두 정보와 기기의 DPR을 종합해서 최적의 이미지를 자동으로 선택한다.

<img
  src="product-800.jpg"
  srcset="product-400.jpg 400w,
          product-800.jpg 800w,
          product-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw,
         (max-width: 1200px) 50vw,
         33vw"
  alt="상품 이미지"
  width="400"
  height="400"
/>

예를 들어 DPR 2x인 모바일(뷰포트 375px)에서 sizes가 100vw이면 브라우저는 375 × 2 = 750px에 가장 가까운 product-800.jpg를 선택한다. 불필요하게 1600px짜리를 다운로드하지 않으므로 디코딩 메모리와 리샘플링 비용을 동시에 절감할 수 있다.

디코딩 메모리 비교:
product-1600.jpg 디코딩 → 1600 × 1600 × 4 = 10.2MB
product-800.jpg  디코딩 →  800 ×  800 × 4 = 2.5MB  (↓ 75% 감소)

그리고 800px 이미지는 750px 영역에 거의 1:1로 매핑되므로
리샘플링 비용도 최소화된다.

아트 디렉션 — picture 태그 활용

picture 태그는 포맷 분기 외에도, 화면 크기에 따라 아예 다른 크롭/구도의 이미지를 제공하는 아트 디렉션에도 사용된다.

<picture>
  <!-- 모바일: 정방형 크롭 -->
  <source
    media="(max-width: 600px)"
    srcset="product-mobile.jpg 400w, product-mobile-2x.jpg 800w"
    sizes="100vw"
  />
  <!-- 데스크톱: 전체 라이프스타일 샷 -->
  <source
    srcset="product-desktop.jpg 1200w, product-desktop-2x.jpg 2400w"
    sizes="33vw"
  />
  <img src="product-fallback.jpg" alt="상품명" width="400" height="400" />
</picture>

모바일에서는 400px 정방형 이미지를, 데스크톱에서는 1200px 가로형 이미지를 제공함으로써 각 기기에서 필요한 만큼만 디코딩하게 된다.

DPR별 품질 전략

디코딩 비용을 더 줄이는 방법으로 DPR별 품질 차등 적용이 있다. 인간의 눈은 고밀도 디스플레이에서 개별 픽셀을 구분하기 어렵기 때문에, DPR이 높을수록 압축 품질을 낮춰도 시각적 차이를 거의 느끼지 못한다.

1x 디스플레이: 품질 85% (픽셀이 크므로 품질이 눈에 띔)
2x 디스플레이: 품질 70% (픽셀 밀도가 높아 차이 미미)
3x 디스플레이: 품질 60% (픽셀이 매우 작아 차이 거의 없음)

이 전략은 Cloudinary와 같은 이미지 CDN 서비스에서도 널리 사용되며, 같은 시각적 품질에서 파일 크기를 추가로 줄여 디코딩 시간을 단축할 수 있다.

이미지 렌더링

앞에서 이미지가 화면에 표시되기까지 디코딩과 리샘플링이라는 비용이 발생한다는 것을 살펴보았다. 그렇다면 이 과정들이 브라우저 내부에서 어떤 스레드에서, 어떤 순서로 일어나는 걸까?

Chrome의 RenderingNG 아키텍처를 기반으로 살펴보면, 이미지는 메인 스레드에서 레이아웃이 결정된 후 컴포지터 스레드에서 디코딩되고, 최종적으로 GPU에서 화면에 그려진다. 각 단계를 따라가 보자.

1. Render Process - Main Thread

이미지의 배치와 레이아웃을 설계하는 단계다.

• Parser: HTML을 파싱하며 이미지 리소스 파악 및 요청 (preload scanner를 통한 선제적 요청)
• Style, Layout: 이미지를 포함한 요소들의 계산된 스타일을 만들고, 화면에서의 크기와 위치를 결정
• Pre-paint: 속성 트리를 계산하며, 이미지가 바뀐 경우 기존 GPU 텍스처 타일 및 디스플레이 목록을 무효화하여 새로 그릴 준비
• Paint: 이미지를 어떻게 래스터링할지 기록한 디스플레이 목록(Display list)을 생성
• Commit: 이 모든 정보(속성 트리, 디스플레이 목록)를 Compositor Thread로 복사

2. Render Process - Compositor Thread

이미지 디코딩과 래스터 작업을 조정하고 레이어를 관리하는 단계다.

• Layerize: 독립적인 래스터화와 애니메이션을 위해 조합된 레이어 목록으로 분할
• Raster, Decode (조정):
  • 디코딩: Compositor Thread Helper가 인코딩된 이미지를 비트맵으로 변환하는 작업을 수행
  • 래스터: Compositor Thread는 래스터 작업을 조정 (실제 GPU를 사용한 래스터화는 Viz 프로세스의 GPU 기본 스레드에서 실행)
• Activate: 작업이 완료된 타일들을 모아 Compositor Frame을 생성

3. Viz 프로세스 - Display Compositor Thread

• Aggregate: 브라우저 UI와 각 탭(렌더링 프로세스)에서 보낸 프레임들을 단일 global compositor frame으로 통합

4. Viz 프로세스 - GPU Main Thread

실제 GPU 자원을 사용하여 픽셀을 만드는 단계다.

• Raster: Compositor Thread로부터 받은 디스플레이 목록을 실제 GPU 텍스처 타일로 변환
• Draw: 집계된 프레임을 바탕으로 GPU에서 실행하여 화면에 실제 픽셀을 출력

AI를 통해 생성한 렌더링 과정 표

다음 글 예고

이번 글에서는 이미지 포맷의 특성, 해상도와 디코딩의 관계, 그리고 브라우저의 렌더링 파이프라인을 살펴보았다. 다음 글에서는 이 이해를 바탕으로 실제 이미지 최적화 전략을 다룰 예정이다.

• 이미지 요청 최적화 (preload, priority hints, 캐싱 전략)
• 이미지 에셋 관리 (해상도별 제공, CDN 활용)
• 상품 이미지 최적화 (업로드 시 처리, 렌더링 시 최적화)

참고

• web.dev - Top CWV
• 올리브영 테크 블로그 - 이미지 최적화
• 올리브영 테크 블로그 - Next.js 이미지 최적화
• 올리브영 테크 블로그 - Next CDN Standalone
• web.dev - Browser-level Image Lazy Loading
• web.dev - Image Performance
• Preload Scanner란 무엇인가
• Chrome RenderingNG Architecture
• 이미지 디코딩 - johnny-mh
• Cloudinary - Retina and HiDPI Devices
• HTTP Archive - Page Weight