아무 .jpg 파일이나 hex 에디터로 열어보라. 처음 두 바이트:
FF D8
이것이 Start of Image(SOI) 마커다. 모든 JPEG 파일은 이것으로 시작한다. 지구상의 모든 JPEG 디코더는 이것을 찾는다. 그 다음 바이트들은 디코더에게 이 JPEG이 어떤 변종인지, 어떤 색 공간을 예상해야 하는지, 픽셀 데이터가 어디서 시작하는지를 알려준다. 이 포맷은 웹 브라우저보다 오래되었음에도 불구하고, 2025년 Web Almanac에 따르면 현대 웹에서 제공되는 모든 이미지의 약 **57%**를 여전히 담당하고 있다.
JPEG을 낳은 저장 공간 위기
1986년, 원시 640 × 480 그레이스케일 이미지는 디스크 307 KB를 잡아먹었다. 동일 해상도의 컬러 이미지는 921 KB가 필요했다. 20 MB 하드 드라이브가 수백 달러하고 1.44 MB 플로피 디스크가 표준 교환 매체였던 시대에, 단 하나의 압축되지 않은 사진이 디스크의 3분의 2를 채울 수 있었다.
필요성은 명백했다: 연속 톤 이미지——사진이지 선화가 아닌——용 표준 압축 포맷이 필요했다. 여러 그룹이 이 문제를 연구하고 있었다. 1986년 ISO/IEC와 ITU-T에 의해 설립된 **Joint Photographic Experts Group(JPEG)**은 최고의 아이디어들을 하나의 초안으로 병합했다. 6년의 다듬기를 거쳐, 1992년 ISO/IEC 10918-1로 표준이 발표되었다.
JPEG은 단 하나의 이미지 포맷이 되려 한 적 없었다. 설계된 목적은 단 하나: 사진을 저장하고 전송할 만큼 작게 만드는 것이다. 이는 매우 특정한 순서로 정보를 버림으로써 달성된다.
JPEG이 이렇게 잘 압축되는 이유
JPEG 압축은 단일 알고리즘이 아니라 파이프라인이다. 각 단계는 인간 시각 시스템이 가장 덜 눈치챌 데이터를 제거한다.
1. 색 공간 변환(RGB → YCbCr)
화면은 RGB를 표시한다. JPEG은 YCbCr을 저장한다. Y 채널은 휘도(밝기)를 담당한다. Cb와 Cr은 색차(청색차와 적색차)를 담당한다. 이것이 중요한 이유는, 인간의 눈에는 밝기에 맞춰진 약 250만 개의 원추세포가 있는 반면, 색상에 맞춰진 것은 10만 개뿐이기 때문이다. 우리는 색상 디테일보다 휘도 디테일을 훨씬 더 잘 본다.
2. 크로마 서브샘플링(Chroma Subsampling)
대부분의 JPEG은 4:2:0 서브샘플링을 사용한다. 휘도 샘플 4개당 Cb 샘플 1개, Cr 샘플 1개가 있다. 즉 크로마 채널은 휘도 채널의 4분의 1 해상도로 저장된다. 4000 × 3000 이미지의 경우, Y 평면은 풀 해상도다. Cb와 Cr 평면은 각각 2000 × 1500이다. 진정한 압축이 시작되기 전에 원시 데이터의 대략 50%를 잘라낸 것이며, 대부분의 시청자는 전혀 눈치채지 못한다.
3. 이산 코사인 변환(DCT)
이미지는 8 × 8 픽셀 블록으로 분할된다. 각 블록은 DCT를 거쳐 공간 데이터(픽셀 값)를 주파수 데이터(블록 전반에 값이 얼마나 빨리 변하는지)로 변환한다. 결과는 8 × 8 계수 행렬이다. 좌상단 값은 DC 계수——블록의 평균 밝기다. 나머지 63개는 점점 더 고주파 디테일을 나타내는 AC 계수다.
고주파 계수는 미세한 질감을 인코딩한다: 머리카락, 잔디, 노이즈. 저주파 계수는 넓은 형태를 인코딩한다: 하늘, 벽, 피부 톤.
4. 양자화(Quantization)
여기서 손실이 발생한다. JPEG은 각 DCT 블록에 양자화 테이블을 적용한다. 이 테이블은 두 번째 8 × 8 나눗셈 행렬이다. 각 DCT 계수는 대응하는 양자값으로 나누어지고 가장 가까운 정수로 반올림된다.
표준 양자화 테이블은 고주파 계수를 가장 세게 타격한다:
16 11 10 16 24 40 51 61
12 12 14 19 26 58 60 55
14 13 16 24 40 57 69 56
14 17 22 29 51 87 80 62
18 22 37 56 68 109 103 77
24 35 55 64 81 104 113 92
49 64 78 87 103 121 120 101
72 92 95 98 112 100 103 99
예를 들어 7이라는 고주파 계수가 121로 나누어지고 0으로 반올림된다. 사라졌다. 되돌릴 수 없다. 디코더는 그것을 다시 보지 못한다. 이것이 손실 압축이다: 데이터는 재인코딩되는 것이 아니라 파괴된다.
품질 90에서는 양자값이 더 작은 스케일링 계수로 나누어진다. 품질 50에서는 스케일링 계수가 더 크다. 더 많은 계수가 0이 된다. 파일은 더 작아진다. 이미지는 더 부드러워진다.
5. 엔트로피 부호화(Entropy Coding)
양자화 후, 남은 계수들은 지그재그 스캔되고, 런렝스 부호화되고, 허프만 부호화로 압축된다. 이 단계는 무손실이다. 이미 파괴된 데이터를 더 효율적으로 포장할 뿐이다.
결과: 1200만 화소의 압축되지 않은 RGB 이미지는 36 MB다. JPEG 품질 90, 4:2:0 서브샘플링으로 저장하면 약 3.5 MB로 줄어든다. 이는 10:1 감축이며, 확대하지 않는 한 가시적인 품질 손실은 거의 없다.
실제로 얼마나 손실이 큰가?
손상은 균일하지 않다.
| 품질 | 일반적인 크기(1200만 화소) | 시각적 영향 |
|---|---|---|
| 95+ | ~8 MB | 거의 보이지 않음; 아카이빙에 적합 |
| 90 | ~3.5 MB | 미세한 부드러움; 카메라 표준 |
| 75 | ~1.8 MB | 미세 디테일에서 흐림 가시적; 웹 기본값 |
| 50 | ~1.0 MB | 100% 확대 시 블로킹 아티팩트 명확 |
| 30 | ~600 KB | 컬러 밴딩, 모기 소음, 인쇄 불가 |
품질이 떨어짐에 따라 세 가지 명확한 아티팩트가 나타난다:
- 블로킹(Blocking): 8 × 8 그리드 가장자리가 보인다. 특히 하늘처럼 부드러운 그라데이션에서.
- 링잉(Ringing): 고대비 에지 주위에 진동하는 헤일로(배경 옆 텍스트 등).
- 컬러 블리딩(Color bleeding): 크로마 서브샘플링이 선명한 경계를 넘어 색을 번지게 한다.
진짜 치명타는 **세대 손실(generation loss)**이다. JPEG을 열고, 편집하고, 다시 JPEG로 저장한다. 저장할 때마다 전체 파이프라인이 재실행된다: RGB → YCbCr → 서브샘플링 → DCT → 양자화. 반올림 오차가 누적된다. 10세대 후에는 수채화처럼 보인다. 50세대 후에는 알아볼 수 없다.
그린 시프트와 기타 재압축 특이성
JPEG을 충분히 많이 다시 저장하면 색온도가 이동하는 것을 알 수 있다. 일부 이미지에는 미묘한 녹색 빛이 깃든다. 다른 것들은 마젠타로 기운다. 이유는 크로마 채널 깊숙이 묻혀 있다.
JPEG은 Cb와 Cr을 낮은 해상도로 저장하고 공격적으로 양자화한다. 저장할 때마다 두 채널 모두에 반올림 오차가 도입된다. RGB로 되돌리는 변환은 이 행렬을 사용한다:
R = Y + 1.402 × (Cr - 128)
G = Y - 0.344136 × (Cb - 128) - 0.714136 × (Cr - 128)
B = Y + 1.772 × (Cb - 128)
녹색은 Cb와 Cr 모두에서 계산된다는 점에 주목하라. 반복된 양자화가 Cb를 위로, Cr을 아래로 단 한 양자화 스텝씩만 밀어도, G 채널은 표류한다. Cb의 양의 편향은 녹색을 아래로 밀고, Cr의 음의 편향은 녹색을 위로 밀어낸다. 이 상호작용은 대칭이 아니다. 왜냐하면 계수 -0.344136과 -0.714136은 서로 다른 크기를 가지기 때문이다. 결과: 원래 크로마 값이 이미 양자화 경계에 가까웠던 일부 이미지 영역에서 녹색이 서서히 축적된다.
이것은 보장된 효과가 아니다. 인코더의 양자화 테이블, 서브샘플링 모드, 이미지 콘텐츠에 달려 있다. 하지만 이것은 실재하고 재현 가능하며, 전문 워크플로우가 JPEG을 다시 저장하지 않는 이유 중 하나다.
JPEG이 이렇게 결함이 많은데, 왜 모든 것이 JPEG을 쓰는가?
JPEG이 인기 있는 이유는 완벽해서가 아니다. 인기 있는 이유는 충분하고 보편적이기 때문이다.
- 특금 잠금 없음: 기본 JPEG 특허(Forgent Networks 소유)은 2006년에 만료되었다. 로열티 프리다.
- 하드웨어 디코딩: 모든 카메라, 휴대전화, 프린터, 브라우저에 실리콘이나 고도로 최적화된 C로 JPEG 디코더가 내장되어 있다. 렌더링 비용은 거의 제로다.
- 충분히 좋다: 소셜 미디어, 뉴스 사이트, 이메일 첨부 파일용으로는, 휴대전화 화면에서 품질 75 JPEG은 소스와 구분이 안 된다.
- 생태계 관성: CMS, CDN, 이미지 라이브러리, 레거시 아카이브는 모두 JPEG을 말한다. 이것들을 교체하려면 더 나은 포맷만으로는 부족하다. 페타바이트 규모의 기존 자산을 이전할 이유도 필요하다.
이겼어야 할 포맷들
JPEG을 무너뜨리려 시도한 포맷이 여럿 있다. 어느 것도 완전한 성공을 거두지 못했다.
| 포맷 | 손실 | 무손실 | 투명도 | 애니메이션 | 최대 비트 깊이 | 핵심 장점 |
|---|---|---|---|---|---|---|
| JPEG | 예 | 아니오 | 아니오 | 아니오 | 8-bit | 보편적 지원 |
| PNG | 아니오 | 예 | 예 | 아니오 | 16-bit | 완벽한 무손실, 알파 |
| WebP | 예 | 예 | 예 | 예 | 8-bit | JPEG보다 25–35% 작음, 브라우저 내장 |
| HEIC | 예 | 예 | 예 | 예 | 16-bit | JPEG보다 약 50% 작음, Apple 기본 |
| AVIF | 예 | 예 | 예 | 예 | 12-bit | 현재 최고 압축률, 로열티 프리 |
| JPEG XL | 예 | 예 | 예 | 예 | 32-bit | 무손실 JPEG 재압축, 프로그레시브 디코딩 |
PNG은 무손실 문제를 해결했지만, 사진에서는 JPEG의 5–10배 크기의 파일을 낳는다. 스크린샷, UI 에셋, 그래픽을 장악하고 있다.
WebP(Google, 2010)은 크기에서 JPEG을 이기고 투명도와 애니메이션을 추가했다. 이제 모든 주요 브라우저에 탑재되어 있다. 2025년 Web Almanac은 WebP가 LCP 이미지의 **11%**를 차지하고 있으며, 2024년의 7%에서 상승했다고 본다. 현재 안전한 업그레이드 경로다.
HEIC(Apple, 2017)은 ISOBMFF 컨테이너 내부에 HEVC 압축을 사용한다. JPEG보다 약 40–50% 작고 파일당 여러 이미지를 담을 수 있다. Apple 생태계를 지배하고 있으며, HEVC 특허 풀 때문에 그 외 지역에서는 정체 상태다.
AVIF(AOM, 2019)은 AV1 비디오에서 파생되었다. 널리 지원되는 포맷 중 최고의 압축률을 달성한다——동등 품질에서 WebP보다 약 30% 작다. 단점은 디코딩 속도다. 모바일 기기에서 AVIF 이미지는 JPEG보다 2–3배 더 오래 렌더링될 수 있어 배터리를 소모하고 LCP를 지연시킨다.
JPEG XL(ISO/IEC 18181, 2021)은 기술적으로 이들 모두를 능가한다. JPEG보다 50–60% 작게 압축한다. 디코딩이 빠르다. 프로그레시브 디코딩을 지원한다: 파일의 약 **1%**만 다운로드해도 사용 가능한 이미지가 나타난다. 가장 중요한 것은, 기존 JPEG을 무손실 재압축하여 약 20%의 크기 절감을 이루면서 원본을 비트 단위로 복구할 수 있다는 점이다. 다른 어떤 포맷도 이것을 할 수 없다.
현재 상황
JPEG XL의 어린 시절은 순탄치 않았다. Google은 2021년에 Chrome에 실험적 지원을 추가했다가, 2022년 10월 31일에 제거했다——"할로윈 결정"으로 불린다. 밝혀진 이유: 기존 포맷에 대한 증분적 이익이 불충분하다는 것이었다. 반발은 즉각적이었다. 해당 Chromium 이슈는 프로젝트 역사상 두 번째로 많은 스타를 받은 이슈가 되었다. Google은 Google이 공동 설립한 Alliance for Open Media에 묶인 AVIF를 보호하고 있다는 비난을 받았다.
2025년 말, Chromium은 방향을 전환했다. 새로운 Rust 디코더(jxl-rs)가 Chrome Canary에 탑재되었다. Chrome 145는 2026년 2월에 출시되어 플래그 뒤에서 JPEG XL 지원을 탑재했다. Safari는 2023년부터 지원하고 있다. Firefox Nightly도 동일한 Rust 디코더를 통합 중이다. JPEG XL은 아직 기본적으로 활성화되지 않았지만, 코드베이스에 복귀했다.
한편 AVIF는 2026년의 현실적인 선택이다. 브라우저 지원이 넓다. 인코더가 개선되고 있다. Cloudinary와 Cloudflare는 모두 Accept 헤더 협상을 통해 자동으로 AVIF를 제공한다. CoreDash 데이터에 따르면, AVIF나 WebP를 제공하는 페이지의 LCP 양호율 중간값은 **81%**인 반면, JPEG만 제공하는 페이지는 **64%**다.
결론
JPEG은 33년 된 타협안이다. 색 해상도, 고주파 질감, 수치적 정밀도를 대가로, 1990년대에 디지털 사진을 가능하게 한 파일 크기를 실현했다. 아티팩트는 잘 알려져 있다. 세대 손실은 실재한다. 그린 드리프트도 일어난다.
그럼에도 JPEG이 버티는 이유는 QWERTY 키보드가 버티는 이유와 같다: 전환 비용이 현상 유지의 고통보다 크다.
실용적인 전진 경로는 계층적이다:
- 고품질 마스터를 보관하라. 원본을 PNG, TIFF, 또는 품질 95 이상의 JPEG으로 아카이브하라. 품질 75의 웹 익스포트에서 다시 편집하지 마라.
- 현대 포맷을 동적으로 제공하라. CDN이나 이미지 서비스를 사용하여 브라우저의
Accept헤더를 기반으로 AVIF, WebP, JPEG XL을 협상하라. 마스터는 하나만 저장하고, 엣지에서 요청 시 변환하게 하라. - JPEG을 일괄 재인코딩하지 마라. 각 세대가 데이터를 파괴한다. 더 작은 파일이 필요하면 다른 JPEG이 아니라 마스터에서 재인코딩하라.
JPEG은 갑자기 죽지 않을 것이다. GIF가 사라진 것과 같은 방식으로 희미해질 것이다: 여전히 어디서나 지원되고, 모든 뷰어에서 열리지만, 동일한 작업을 더 적은 바이트와 더 적은 아티팩트로 수행하는 포맷에게 점점 밀리게 될 것이다. 이번에는 대체 포맷들이 실제로 이기고 있다는 점이 다르다.
