이미지 압축은 어떻게 작동하나: JPEG·PNG·WebP·AVIF의 원리

무손실과 손실 압축의 차이, JPEG의 DCT와 양자화, 8×8 블록 노이즈, 크로마 서브샘플링, PNG 필터와 deflate, WebP·AVIF의 탄생과 브라우저 지원 시점까지 한 번에 정리합니다.

everytooleverywhereallatonce · 작성

4000×3000 사진 한 장을 압축 없이 저장하면 픽셀 1,200만 개 × 3바이트(빨강·초록·파랑)로 약 36MB가 됩니다. 같은 사진이 휴대폰 갤러리에서는 3~5MB 정도입니다. 그 사이 90% 가까운 차이를 만드는 것이 이미지 압축이고, 방식은 크게 두 갈래로 나뉩니다.

무손실과 손실: 되돌릴 수 있느냐의 차이

무손실 압축은 풀었을 때 원래 픽셀과 비트 하나까지 같아야 합니다. ZIP 파일처럼 데이터 안의 반복과 규칙성을 찾아 짧게 적는 방식이라, 줄어드는 정도는 이미지가 얼마나 단조로운지에 달려 있습니다. 흰 바탕에 도형 몇 개가 있는 그림은 수십 분의 일로 줄지만, 노이즈가 가득한 야경 사진은 거의 줄지 않습니다. PNG, GIF, 무손실 WebP가 여기에 속합니다.

손실 압축은 되돌릴 수 없습니다. 사람 눈이 알아채기 어려운 정보를 골라 버리고, 버리는 양을 「품질」이라는 숫자로 조절합니다. JPEG, 손실 WebP, AVIF가 여기에 속합니다. 손실 압축이 사진에서 압도적으로 강한 이유는, 사진의 용량 대부분이 눈에 거의 보이지 않는 미세한 변화(센서 노이즈, 잔 질감)에 쓰이기 때문입니다.

흔한 오해가 하나 있습니다. 「PNG는 고화질, JPEG는 저화질」이 아닙니다. 이미 JPEG로 한 번 손실된 사진을 PNG로 저장하면 그 손실을 그대로 보존한 채 용량만 몇 배 커집니다. 화질은 원본에서 한 번 결정되고, 포맷은 그걸 어떻게 담느냐의 문제입니다.

JPEG: 색을 나누고, 주파수로 바꾸고, 반올림한다

JPEG 표준은 ITU-T T.81로 1992년 9월에 승인됐습니다. 30년이 넘었지만 지금도 가장 많이 쓰이는 사진 포맷이고, 그 원리는 이후 나온 포맷에도 거의 그대로 이어집니다.

1단계: 밝기와 색 분리

먼저 RGB를 밝기(Y) 하나와 색차(Cb, Cr) 둘로 바꿉니다. 사람 눈은 밝기 변화에는 예민하지만 색의 세밀한 변화에는 둔합니다. 그래서 색차 채널은 해상도를 줄여도 티가 잘 안 납니다. 가로세로 모두 절반으로 줄이는 방식을 4:2:0이라 부르는데, 이것만으로 색 데이터가 4분의 1이 됩니다. 가로만 줄이면 4:2:2, 줄이지 않으면 4:4:4입니다.

부작용도 여기서 나옵니다. 흰 바탕의 가는 빨간 글씨는 밝기 차이는 작고 색 차이가 큰 대상입니다. 색 해상도를 절반으로 줄이면 빨강이 옆 픽셀로 번지고 테두리가 뿌옇게 됩니다. 사진에서는 안 보이던 문제가 배너, 도표, 자막 캡처에서 유독 눈에 띄는 이유입니다.

2단계: 8×8 블록과 DCT

각 채널을 8×8 픽셀 블록으로 자른 뒤, 블록마다 **이산 코사인 변환(DCT)**을 적용합니다. DCT는 64개 픽셀 값을 64개의 「주파수 성분」으로 바꿉니다. 왼쪽 위 첫 값은 블록 평균 밝기(DC)이고, 오른쪽 아래로 갈수록 점점 촘촘한 줄무늬 패턴의 세기를 뜻합니다. 이 단계 자체는 손실이 없습니다. 같은 정보를 다른 좌표로 표현했을 뿐입니다.

핵심은 자연 사진의 블록 대부분이 완만하게 변한다는 점입니다. 그래서 에너지가 낮은 주파수 몇 개에 몰리고, 높은 주파수 값은 0 근처에 작게 흩어집니다.

3단계: 양자화, 유일하게 정보를 버리는 곳

각 주파수 값을 양자화 표의 해당 숫자로 나누고 반올림합니다. 높은 주파수일수록 큰 수로 나누도록 표를 짜 두기 때문에, 작은 고주파 값들은 대부분 0이 됩니다. 품질 슬라이더는 결국 이 표를 얼마나 크게 할지 정하는 손잡이입니다. 품질을 낮추면 나누는 수가 커지고 0이 많아집니다.

0이 길게 이어진 데이터는 이후 허프만 부호화(엔트로피 부호화) 단계에서 아주 짧게 적힙니다. 이 마지막 단계는 다시 무손실입니다.

블록 노이즈와 링잉은 어디서 오나

품질을 크게 낮추면 블록마다 평균값(DC)과 저주파 몇 개만 남습니다. 각 블록이 독립적으로 근사되니 이웃 블록과의 경계가 맞지 않아 8×8 격자 무늬가 드러납니다. 하늘이나 벽처럼 완만한 그라데이션에서 계단처럼 보이는 것이 이 현상입니다.

글자나 선처럼 경계가 날카로운 곳은 원래 고주파 성분이 많아야 표현됩니다. 그 고주파를 잘라내면 경계 주변에 물결 같은 얼룩, 즉 링잉이 생깁니다. 스크린샷을 JPEG로 저장했을 때 글자 주위가 지저분해 보이는 이유입니다.

그리고 JPEG를 다시 JPEG로 저장하면 이미 생긴 블록 노이즈 위에 새 양자화 오차가 더해집니다. 품질 100으로 다시 저장해도 원본으로 돌아가지 않고, 오히려 기존 노이즈까지 「디테일」로 보존하느라 파일이 커지기도 합니다.

PNG: 차이를 적고 deflate로 묶는다

PNG는 GIF 특허 문제를 피하려고 1990년대 중반 만들어졌고, 2025년 6월 W3C가 3판을 권고안으로 냈습니다. 압축 방식은 두 단계입니다.

첫째, 필터. 각 행마다 다섯 가지 중 하나를 골라 픽셀 값을 이웃과의 차이로 바꿉니다. 그대로 두는 None, 왼쪽 픽셀과의 차이인 Sub, 위 픽셀과의 차이인 Up, 왼쪽과 위 평균과의 차이인 Average, 그리고 왼쪽·위·왼쪽 위 세 픽셀로 예측하는 Paeth입니다. 단색 배경이나 부드러운 그라데이션은 차이값이 0이나 작은 수로 바뀝니다.

둘째, deflate. ZIP과 같은 계열의 압축(최대 32KB 창 안에서 반복을 찾는 LZ77 + 허프만 부호화)으로 필터 결과를 묶습니다. 0이 줄지어 있으면 아주 짧아집니다.

그래서 PNG는 스크린샷, UI, 로고, 도표처럼 색이 적고 같은 값이 반복되는 이미지에서 강합니다. 반대로 사진은 옆 픽셀과의 차이도 노이즈 때문에 제각각이라 필터가 별 효과를 못 냅니다. 같은 사진을 PNG로 저장하면 JPEG보다 몇 배 큰 게 정상입니다.

같은 PNG라도 어떤 필터를 행마다 고르느냐, deflate를 얼마나 끈질기게 돌리느냐에 따라 크기가 달라집니다. 전용 최적화 도구가 PNG를 무손실로 더 줄일 수 있는 것도, 브라우저 내장 인코더로 PNG를 다시 저장하면 원본보다 커질 수 있는 것도 이 때문입니다.

WebP: 동영상 코덱에서 온 사진 포맷

구글은 2010년 9월 30일 크로미움 블로그에서 WebP를 발표했습니다. 손실 WebP는 동영상 코덱 VP8의 키프레임 압축을 가져온 것입니다. JPEG와 같은 DCT·양자화 뼈대 위에 두 가지가 더해졌습니다.

  • 블록 예측: 이미 처리한 주변 블록을 보고 현재 블록을 예측한 뒤, 예측과 실제의 차이(잔차)만 변환해 저장합니다.
  • 적응형 비트 배분과 산술 부호화: 이미지를 구역으로 나눠 단조로운 곳엔 비트를 적게, 복잡한 곳엔 많이 씁니다.

무손실 WebP는 PNG와 전혀 다른 설계로, 공간 예측, 색 채널 상관 제거, 팔레트, LZ77 역참조, 최근 색 캐시 등을 조합합니다. 구글 문서는 같은 체감 화질에서 WebP가 PNG·JPEG보다 약 30% 작고, 투명 PNG를 손실+알파 WebP로 바꾸면 평균 60~70% 줄었다고 밝히고 있습니다. 손실 압축이면서 투명도를 가질 수 있다는 점이 JPEG와 가장 큰 차이입니다.

AVIF: AV1 동영상 코덱의 정지 화면

AVIF는 Alliance for Open Media(AOMedia)가 만든 AV1 동영상 코덱으로 압축한 이미지를, HEIF 컨테이너(ISO 기본 미디어 파일 형식 기반)에 담은 포맷입니다. 더 큰 가변 블록, 다양한 방향 예측, 강한 후처리 필터 덕분에 낮은 용량에서도 블록 노이즈 대신 부드럽게 뭉개지는 쪽으로 열화됩니다. HDR과 넓은 색역, 10·12비트 색 깊이도 담을 수 있습니다.

대가는 인코딩 속도입니다. 같은 이미지를 만드는 데 JPEG나 WebP보다 훨씬 오래 걸리고, 브라우저 캔버스에서 AVIF를 직접 인코딩할 수 있는 환경도 제한적입니다. 또 품질 숫자의 의미가 달라서, AVIF 50이 JPEG 80과 비슷해 보이는 경우가 흔합니다. 포맷끼리 품질 숫자를 그대로 비교하면 안 됩니다.

브라우저 지원 시점

Can I use 기준, 각 포맷을 완전히 지원하기 시작한 버전은 다음과 같습니다.

브라우저 WebP AVIF
Chrome 32 85
Firefox 65 93
Safari 16.0 (14~15.6은 부분 지원) 16.4 (iOS는 16.0부터)
Edge 18 121

WebP는 크롬이 먼저 지원하고 파이어폭스와 사파리가 한참 뒤에 따라온 탓에, 한동안 「사파리에서 안 보이는 포맷」이라는 이미지가 있었습니다. 지금은 두 포맷 모두 전 세계 브라우저 사용량의 95% 이상에서 표시됩니다. 다만 표시(디코딩)와 저장(인코딩)은 별개입니다. 브라우저가 AVIF를 보여줄 수는 있어도 캔버스로 AVIF 파일을 만들지 못할 수 있습니다.

언제 무엇을 쓰나

상황 추천 이유
웹에 올릴 일반 사진 WebP 또는 AVIF, 호환성이 걱정되면 JPEG 손실 압축의 이득이 가장 큼
스크린샷, 문서 캡처, 도표 PNG, 또는 품질 90 이상의 WebP 글자 경계의 링잉과 색 번짐 방지
투명 배경 로고·아이콘 고품질 WebP, 원본 보관은 PNG(가능하면 SVG) JPEG는 투명도를 담지 못함
계속 편집할 원본 PNG 또는 카메라 원본 저장할 때마다 손실이 쌓이지 않게
오래된 시스템·이메일 첨부 JPEG 어디서나 열림

하나 더 기억할 것은 해상도가 품질보다 큰 손잡이라는 점입니다. 파일 크기는 대략 픽셀 수에 비례하므로, 4000px 사진을 2000px로 줄이면 픽셀이 4분의 1이 됩니다. 화면에 1000px 폭으로 보여줄 사진을 4000px로 올려놓고 품질을 40까지 낮추는 것보다, 먼저 이미지 크기 조절로 알맞게 줄이고 품질은 넉넉히 두는 편이 더 작고 더 깨끗합니다.

실제로 어떤 품질에서 용량이 꺾이는지는 사진마다 다릅니다. 이미지 압축기는 여러 품질로 직접 인코딩해 보고 그 지점을 골라 주며, 여러 장의 포맷을 한꺼번에 바꿀 때는 이미지 변환기를 쓸 수 있습니다.

출처