JPEG가 여전히 널리 쓰이는 이유: 압축보다 큰 호환성
JPEG가 오래 살아남은 이유를 압축률 하나로 설명하기는 어렵습니다. 사진을 충분히 작고 보기 좋게 저장하면서, 카메라·편집기·브라우저·문서 프로그램 사이에서 교환하기 쉬웠다는 점이 더 큰 이유라고 봅니다.
그렇다고 지금 새로 만드는 웹사이트의 모든 사진을 JPEG로 제공해야 한다는 뜻은 아닙니다. 오래 쓰이는 포맷의 장점과, 특정 페이지에 가장 적합한 포맷은 구분해야 합니다. 이 글에서는 JPEG가 자리 잡은 이유를 살펴보고, 실제 이미지 포맷을 고를 때 쓸 기준으로 연결해 보겠습니다.
사진에 잘 맞는 절충안
GIF와 JPEG의 차이를 단순히 무손실 대 손실로만 보면 중요한 부분을 놓칩니다. GIF89a 규격의 색상표는 최대 256색입니다. LZW 압축은 무손실이지만, 수많은 색이 있는 사진을 이 색상표로 변환하는 단계에서는 원래 색을 잃을 수 있습니다.
일반적인 컬러 JPEG는 더 풍부한 색을 표현하면서, 사람이 비교적 덜 민감하게 느끼는 정보를 줄여 용량을 절충합니다. 하늘의 그라데이션이나 피부처럼 색이 연속적으로 변하는 사진에 잘 맞습니다. 반면 작은 글자, 도형, UI 캡처에서는 경계 주변의 손실이 더 쉽게 보입니다.
아래 세 이미지는 IEEE Spectrum의 JPEG 역사 기사에 실린 비교 예시입니다. 직접 인코딩해 측정한 실험 결과는 아닙니다.
JPEG 압축에서 실제로 정보를 잃는 곳
웹에서 흔히 만나는 손실 JPEG의 핵심 흐름은 다음과 같습니다. 이는 JPEG 표준의 모든 모드를 설명하는 것이 아니라, 대표적인 DCT 기반 압축을 단순화한 것입니다.
- 색 표현과 해상도 조절: 흔히 밝기와 색차를 분리하고 색차 성분의 해상도를 줄입니다. 색차 서브샘플링을 사용한다면 이 단계에서도 정보가 줄어듭니다.
- 8×8 블록의 DCT: 픽셀 값을 저주파·고주파 성분의 계수로 바꿉니다. 변환 자체보다 다음 양자화가 주요 손실 단계입니다.
- 양자화: 계수를 정해진 간격으로 나누고 반올림합니다. 강한 압축일수록 세부 정보를 더 많이 버립니다.
- 엔트로피 부호화: 남은 계수를 효율적으로 저장합니다. 이 단계는 추가로 시각 정보를 버리기보다 표현에 필요한 비트를 줄입니다.
규격의 근거는 ITU-T T.81, 교환 형식과 색 변환의 구분은 JPEG 위원회의 JPEG 1 설명에서 확인할 수 있습니다.
원문이 품질 설정 50으로 소개한 이미지. 품질이 원본의 50%라는 뜻은 아닙니다.
quality: 80 같은 숫자는 공통된 화질 단위가 아닙니다. 서로 다른 인코더나 포맷에 같은 숫자를 넣어도 동등한 품질을 보장하지 않습니다. 그러므로 포맷 비교는 같은 품질 숫자보다 같은 표시 크기에서 받아들일 수 있는 시각적 품질을 맞추는 것이 먼저입니다.
원문이 품질 설정 5로 소개한 이미지. 블록 경계와 세부 묘사의 변화를 살펴볼 수 있습니다.
한 번 손실된 정보를 재저장으로 복구할 수는 없습니다. 캡처 자체가 JPEG 노이즈를 만드는 것도 아닙니다. 이미 손상된 그림을 캡처하거나, 캡처를 JPEG로 저장하고 다시 압축하면서 손실이 누적될 수 있습니다. 파생 이미지는 가능하면 재압축된 썸네일이 아닌 보관용 원본에서 생성하는 편이 낫습니다.
점진적 JPEG는 같은 이미지 정보를 여러 스캔으로 나눠 전송합니다. 다운로드가 끝나기 전에 전체 윤곽을 보여줄 수 있지만, 그것만으로 모든 환경에서 더 빨리 표시된다고 단정할 수는 없습니다. 순차 방식과의 선택에도 실제 파일 크기와 디코딩·표시 동작을 확인해야 합니다.
압축 알고리즘보다 오래가는 호환성
JPEG의 핵심 표준은 1992년 만들어졌습니다. 표준화는 서로 다른 회사가 같은 이미지 데이터를 읽고 쓸 수 있는 토대를 제공했습니다. 다만 공개 규격과 보급된 구현체, 하드웨어, 기존 파일의 축적이 함께 작용한 것이지, 국제 표준이라는 이유만으로 성공이 보장된 것은 아닙니다. JPEG 1 개요
특허 문제도 당시 포맷 선택에 영향을 줬습니다. GIF의 LZW 특허 라이선스 논란은 PNG 개발의 계기였습니다. 이 사실은 PNG 개발자가 정리한 역사에서 확인할 수 있습니다. 그렇다고 JPEG의 역사 전체가 특허 분쟁 없이 흘렀다거나, 모든 JPEG 구현의 조건이 같았다고 일반화하면 안 됩니다.
여기서 제가 중요하게 보는 것은 교체 비용입니다. 웹페이지에서 새 포맷을 표시하는 것과, 고객이 내려받아 오래된 편집기·문서 도구에 붙여 넣는 것은 다른 경로입니다. 서비스의 실제 출력 경로가 많을수록 압축률 이득만으로 포맷 하나를 일괄 교체하기 어려워집니다.
새 웹사이트라면 무엇을 선택할까
다음 표는 절대적인 순위가 아니라, 먼저 비교할 후보입니다. WebP 공식 FAQ는 손실·무손실 압축과 투명도를 지원한다고 설명합니다. 실제 절감 폭은 입력 이미지와 설정에 따라 확인해야 합니다.
| 이미지와 사용 목적 | 먼저 비교할 후보 | 확인할 부분 |
|---|---|---|
| 사진을 웹에서 표시 | JPEG, WebP, AVIF | 목표 화질의 전송량, 인코딩 비용, 대상 환경 |
| 작은 글자가 많은 UI 캡처 | PNG, 무손실 WebP | 글자 경계, 색 번짐, 실제 표시 배율 |
| 투명 배경이 필요한 래스터 이미지 | PNG, WebP | 알파 지원과 합성 결과 |
| 사용자가 내려받아 다른 도구에서 편집 | JPEG 등 대상 도구가 받는 형식 | 가져오기·재저장·출력까지의 호환성 |
웹 표시용과 다운로드용 형식을 분리할 수도 있습니다. 아래는 같은 사진을 세 형식으로 준비했을 때의 예입니다. 경로와 크기는 예시이며, 실제 이미지로 바꿔야 합니다.
1
2
3
4
5
6
<picture>
<source srcset="/images/photo.avif" type="image/avif">
<source srcset="/images/photo.webp" type="image/webp">
<img src="/images/photo.jpg" width="1200" height="800"
alt="산 능선 뒤로 해가 지는 풍경">
</picture>
브라우저는 지원 형식과 조건을 보고 소스를 선택합니다. 이 구조는 지원하지 않는 형식에 대한 대안을 제공하지만, 선택한 파일의 404 오류까지 자동 복구하는 장치는 아닙니다. HTML 표준의 picture 설명
포맷을 바꾸기 전에 할 작은 실험
대표 사진, 글자가 섞인 이미지, 그라데이션 이미지부터 골라 비교하면 됩니다.
- 표시할 픽셀 크기를 맞춥니다. 불필요하게 큰 이미지를 보내면서 포맷만 바꾸면 해상도 문제를 놓칩니다.
- 같은 원본에서 각 형식의 후보를 만듭니다. 인코더 이름·버전·품질·색차 설정을 기록합니다.
- 모바일의 실제 표시 크기와 확대 상태에서 글자, 피부, 하늘, 경계를 비교합니다.
- 파일 크기뿐 아니라 목표 기기의 표시 시간과 다운로드 후 사용 경로도 확인합니다.
이 글에 새 포맷 간 직접 측정값은 없습니다. 따라서 특정 포맷이 몇 퍼센트 더 낫다는 결론 대신, 위 조건으로 서비스의 대표 이미지를 확인하는 것을 권합니다.
JPEG는 익숙해서만 살아남은 포맷이 아닙니다. 사진 압축과 폭넓은 교환 가능성 사이에서 유용한 절충점을 제공해 왔습니다. 새 포맷의 이점을 받아들이면서도 JPEG가 필요한 경로를 남겨두는 선택은 충분히 합리적입니다.