사진 용량을 10분의 1로! JPEG 압축은 도대체 무엇을 버리고, 왜 우리는 눈치채지 못할까

▲ 4,800만 화소 수준의 사진을 무압축 24비트로 저장하면 이론상 약 100MB가 넘고, 1,200만 화소면 약 36MB예요. JPEG는 이걸 보통 수 MB로 줄입니다.

🤔 일단 계산부터: 사진은 원래 얼마나 무거울까?

압축 얘기를 하려면 "원래 크기"부터 알아야겠죠. 디지털 사진은 작은 점, 즉 픽셀의 모음이에요. 일반적인 컬러 사진은 픽셀 하나에 빨강(R), 초록(G), 파랑(B) 세 값을 저장하고, 각 값은 0~255 사이의 숫자, 즉 8비트(1바이트)예요. 그러니까 픽셀 하나 = 3바이트.

요즘 흔한 1,200만 화소(4000×3000) 사진을 계산해볼게요.
4000 × 3000 × 3바이트 = 36,000,000바이트, 약 36MB.
사진 100장이면 3.6GB, 1,000장이면 36GB예요. 여행 한 번 다녀오면 폰 저장공간이 비명을 지르겠죠? 😱

그런데 실제 JPEG 파일은 같은 해상도에서 보통 2~5MB 안팎이에요. 대략 10:1 정도의 압축이 "눈으로 보기에 거의 차이 없는" 수준으로 흔히 언급되는 이유가 바로 이거예요. 화질을 조금 더 양보하면 20:1, 30:1도 충분히 가능하고요.

핵심은 이거예요. JPEG는 아무거나 막 버리는 게 아니라, 사람 눈이 둔한 부분만 골라서 버린다는 것. 그래서 JPEG를 이해하는 건 사실 "인간의 시각이 어디서 허술한가"를 이해하는 것과 같아요. 공학과 생물학이 만나는 지점이라 꽤 낭만 있죠.

📜 JPEG, 이름부터 짚고 가자

JPEG는 Joint Photographic Experts Group의 약자예요. 파일 형식 이름이기 전에 위원회 이름이에요. ISO와 CCITT(현재의 ITU-T)가 공동으로 만든 전문가 그룹이 1986년쯤 결성됐고, 이들이 만든 표준이 1992년에 ITU-T T.81(이후 ISO/IEC 10918-1)로 승인됐어요.

재미있는 건, 우리가 쓰는 ".jpg" 파일은 엄밀히 말하면 JPEG 압축 데이터를 담는 JFIF나 Exif 같은 컨테이너 형식이라는 점이에요. Exif는 카메라 기종, 촬영 시각, GPS 같은 정보까지 담는 형식이라 폰 사진은 대부분 이쪽이에요. 확장자가 .jpg든 .jpeg든 내용은 같아요. 옛날 윈도우가 확장자를 세 글자로 제한했던 시절의 흔적이 .jpg로 남은 거예요.

30년이 넘은 기술인데 아직도 웹과 카메라의 사실상 표준이라는 게 놀랍지 않나요? 그만큼 설계가 영리했다는 뜻이에요. 이제 그 영리함을 해부해봅시다. 🔍

🛠️ JPEG 압축 파이프라인: 6단계 전체 지도

JPEG 기본 방식(Baseline)은 크게 여섯 단계로 굴러가요. 주황색 뱃지가 붙은 단계가 실제로 정보를 버리는(손실이 생기는) 단계예요. 나머지는 버리지 않고 "정리"하거나 "포장"만 해요.

즉, JPEG가 "버리는" 건 딱 두 군데예요. 색의 해상도와 고주파 디테일의 정밀도. 이 두 가지만 기억해도 오늘 내용의 80%는 챙긴 거예요. 이제 단계별로 천천히 걸어볼게요.

1️⃣ 색 공간 변환: RGB를 밝기와 색으로 쪼개기

카메라 센서와 모니터는 RGB로 세상을 다루지만, 사람 눈은 좀 다르게 작동해요. 망막에는 막대세포(명암 담당)와 원뿔세포(색 담당)가 있는데, 막대세포가 약 1억 2천만 개, 원뿔세포가 약 600만 개 정도로 알려져 있어요. 대충 비교해도 명암 감지 쪽이 압도적이죠. 물론 밝은 낮엔 원뿔세포가 주로 일하지만, 결과적으로 사람의 시각은 밝기 변화에는 예민하고, 색의 세밀한 변화에는 상대적으로 둔감해요.

그래서 JPEG는 먼저 RGB를 YCbCr로 바꿔요.

JFIF에서 쓰는 변환식은 이래요(값 범위 0~255 기준).

Y  =  0.299 R + 0.587 G + 0.114 B
Cb = -0.1687 R - 0.3313 G + 0.5 B + 128
Cr =  0.5 R - 0.4187 G - 0.0813 B + 128

Y 식에서 G의 계수가 0.587로 가장 크죠? 사람 눈이 초록빛 밝기에 가장 민감하기 때문이에요. 반대로 파랑은 0.114밖에 안 돼요. 이건 아날로그 컬러 TV 시절(ITU-R BT.601)부터 내려온 가중치예요. 흑백 TV와 호환되도록 밝기 신호와 색 신호를 분리했던 방송 기술의 유산이 지금 여러분 폰 사진에 그대로 살아있는 거죠. 📺

2️⃣ 크로마 서브샘플링: 색은 대충 칠해도 티가 안 나

여기서 첫 번째 "버리기"가 등장해요. 밝기(Y)는 모든 픽셀마다 그대로 두고, 색(Cb, Cr)은 여러 픽셀이 하나의 값을 나눠 쓰게 만드는 거예요. 어린이 색칠공부 생각해보세요. 선(밝기)은 정교하게 그려져 있으니, 색연필이 살짝 삐져나가도 그림이 멀쩡해 보이잖아요? 딱 그 원리예요. 🖍️

숫자 표기 "4:2:0"은 처음 보면 암호 같은데, 원래 방송 분야에서 쓰던 표기라 직관적이진 않아요. 실용적으로는 이렇게 외우면 돼요.

4:2:0을 계산해보면 이래요. 원래는 픽셀당 Y, Cb, Cr 세 값이니 4픽셀이면 12개 값. 서브샘플링 후엔 Y 4개 + Cb 1개 + Cr 1개 = 6개. 압축 알고리즘 본편을 시작하기도 전에 이미 절반을 덜어낸 셈이에요. 그런데 사진을 보는 우리는 거의 눈치를 못 채죠. 이것만으로도 JPEG 설계자들의 "인간 이해도"가 보여요.

3️⃣ 8×8 블록과 DCT: 그림을 "주파수"로 번역하기

이제 JPEG의 심장부예요. 이미지를 8×8 픽셀짜리 작은 타일로 나누고(서브샘플링된 색 채널도 각각 8×8로), 각 타일에 이산 코사인 변환(DCT, Discrete Cosine Transform)을 적용해요. DCT는 1974년 아메드(Nasir Ahmed), 나타라잔, 라오가 발표한 변환으로, 오늘날 JPEG뿐 아니라 MP3·AAC 계열 오디오(정확히는 변형된 MDCT), H.264 같은 영상 코덱의 뼈대가 됐어요.

"주파수"라는 말에 겁먹지 마세요. 이렇게 생각하면 쉬워요.

DCT는 어떤 8×8 그림이든 64개의 기본 무늬(기저 패턴)를 적절한 비율로 섞어서 표현해요. 마치 음악의 화음을 "도 얼마, 미 얼마, 솔 얼마"로 분해하는 것처럼요. 🎵 각 무늬를 얼마나 섞는지 나타내는 숫자 64개를 DCT 계수라고 불러요.

64개 계수 중 왼쪽 맨 위 한 칸은 특별해요. 이건 "타일 전체의 평균 밝기"를 나타내는 DC 계수예요. 나머지 63개는 AC 계수로, 오른쪽·아래로 갈수록 점점 더 촘촘한 무늬(고주파)를 의미해요.

여기서 마법 같은 성질이 하나 있어요. 실제 사진의 8×8 영역은 대부분 하늘, 피부, 벽처럼 밝기가 서서히 변하는 부분이에요. 그래서 DCT를 하면 정보(에너지)의 대부분이 왼쪽 위 몇 개 계수에 몰리고, 오른쪽 아래 고주파 계수들은 0에 가까운 작은 값이 돼요. 이걸 "에너지 집중(energy compaction)" 성질이라고 불러요.

참고로 DCT 전에 픽셀 값(0~255)에서 128을 빼서 -128~127 범위로 옮기는 "레벨 시프트"를 해요. 0을 중심으로 대칭이 되면 DC 계수 값이 작아져서 다루기 편하거든요.

왜 하필 8×8일까요? 블록이 너무 크면 계산량이 커지고(1990년대 초 하드웨어를 생각해보세요) 한 블록 안에 서로 다른 내용이 섞여 에너지 집중이 약해져요. 너무 작으면 압축 효율이 떨어지고요. 8×8은 당시 기준으로 성능과 효율의 절충점이었어요. 최신 영상 코덱(HEVC, AV1 등)이 4×4부터 64×64 이상까지 블록 크기를 유연하게 바꾸는 걸 보면, 8×8 고정은 시대적 한계이기도 했죠.

4️⃣ 양자화: 드디어 진짜로 버리는 순간 🗑️

자, 오늘의 주인공 등장입니다. 양자화(Quantization)는 각 DCT 계수를 정해진 숫자로 나누고 반올림하는 거예요. 정말 그게 다예요. 그런데 이 단순한 나눗셈이 용량의 대부분을 날려버려요.

비유하자면 이래요. 친구가 "나 키 173.48cm야"라고 하면, 우린 그냥 "173"으로 기억하잖아요? 더 대충이면 "170 정도". 나누는 숫자가 클수록 더 뭉뚱그려 기억하는 것이고, 뭉뚱그린 정보는 다시 정확하게 복원할 수 없어요. 이게 손실 압축의 정체예요.

간단한 예를 들어볼게요. 어떤 DCT 계수가 -415.4이고, 양자화 테이블의 해당 값이 16이라면:

양자화:   -415.4 ÷ 16 = -25.96  →  반올림  →  -26
복원:     -26 × 16 = -416
오차:     -416 - (-415.4) = -0.6   ← 이 정도는 눈에 안 보여요

그런데 고주파 쪽 계수가 3.2이고 테이블 값이 99라면?

양자화:   3.2 ÷ 99 = 0.032  →  반올림  →  0
복원:     0 × 99 = 0
결과:     그 무늬는 그냥 사라짐 ✨

이렇게 고주파 계수들은 거의 다 0이 돼버려요. 그리고 0이 줄줄이 이어지면 다음 단계에서 엄청나게 효율적으로 압축할 수 있죠. 바로 이게 "10분의 1"의 비밀이에요.

📋 양자화 테이블: 칸마다 다른 "대충 기준"

JPEG 표준 부록(Annex K)에는 예시용 양자화 테이블이 실려 있어요. 밝기(Y)용 테이블은 이렇게 생겼어요.

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

보이시나요? 왼쪽 위는 10~16 정도로 작고, 오른쪽 아래로 갈수록 100 안팎으로 커져요. 저주파는 섬세하게, 고주파는 과감하게 다루겠다는 뜻이에요. 사람 눈이 아주 촘촘한 무늬의 미세한 강도 차이를 잘 구분하지 못한다는 시각 실험 결과를 반영한 설계예요. 색차(Cb, Cr)용 테이블은 대부분의 칸이 99로 채워질 만큼 훨씬 더 과감해요. 색에 둔감한 눈의 특성을 또 한 번 써먹는 거죠.

IJG 방식의 배율 공식은 이래요. 궁금한 친구들을 위해 살짝만 보여줄게요.

if (quality < 50)  scale = 5000 / quality;
else               scale = 200 - quality * 2;

새_테이블값 = (표준_테이블값 * scale + 50) / 100   // 1 ~ 255 범위로 제한

품질 75(많은 프로그램의 기본값)면 scale이 50이라 표준 테이블의 약 절반 값이 되고, 품질 90이면 scale 20으로 약 5분의 1이 돼요. 품질 10이면 scale이 500, 즉 테이블 값이 5배가 되어 화면이 블록투성이가 되죠.

5️⃣ 지그재그 스캔과 런 렝스 부호화: 0을 한데 몰아라

양자화가 끝난 8×8 블록은 대충 이런 모양이 돼요. 왼쪽 위에 숫자 몇 개, 나머지는 0의 바다. 🌊

-26  -3   -6   2   2   0   0   0
  1  -2   -4   0   0   0   0   0
 -3   1    5  -1  -1   0   0   0
 -4   1    2  -1   0   0   0   0
  1   0    0   0   0   0   0   0
  0   0    0   0   0   0   0   0
  0   0    0   0   0   0   0   0
  0   0    0   0   0   0   0   0

이걸 한 줄로 펴야 저장할 수 있는데, 그냥 가로로 읽으면 0과 숫자가 뒤섞여요. 그래서 앞의 그림처럼 지그재그 순서로 읽어요. 저주파부터 고주파 순서로 읽게 되니, 의미 있는 숫자는 앞에 몰리고 0은 뒤에 쭉 몰려요.

그다음 AC 계수들은 "앞에 0이 몇 개 있고, 그다음 값이 뭐다" 식의 (0의 개수, 값) 쌍으로 표현해요. 이게 런 렝스(Run-Length) 방식이에요. 그리고 블록 끝까지 0만 남으면 EOB(End Of Block)라는 특수 기호 하나로 "나머지 전부 0!"이라고 선언해버려요. 0이 40개든 50개든 기호 하나면 끝. 이 얼마나 시원한가요. 😎

한편 DC 계수(블록 평균 밝기)는 이웃 블록끼리 값이 비슷한 경우가 많아서, 이전 블록 DC와의 차이값만 저장해요(DPCM 방식). -26, -25, -27처럼 비슷하면 차이는 +1, -2처럼 작아지니까 더 적은 비트로 표현돼요.

6️⃣ 허프만 부호화: 자주 나오는 놈한테 짧은 이름을

마지막 포장 단계예요. 허프만 부호화는 1952년 데이비드 허프만이 고안한 무손실 압축으로, 자주 등장하는 기호에 짧은 비트열을, 드문 기호에 긴 비트열을 붙여요. 모스 부호에서 영어에 가장 흔한 E가 점 하나(·)인 것과 같은 발상이에요.

JPEG에서는 EOB나 작은 값들이 엄청 자주 나오니까 이들에게 2~4비트짜리 짧은 코드를 주고, 드문 큰 값엔 긴 코드를 줘요. 이 단계는 손실이 전혀 없어요. JPEG 표준은 허프만 대신 산술 부호화(Arithmetic coding)도 선택지로 정의했는데, 압축률이 대략 5~10% 정도 더 좋다고 알려져 있지만 과거 특허 문제 때문에 거의 쓰이지 않았어요. 특허가 만료된 지금도 호환성 때문에 대부분 허프만을 써요.

🔍 그래서 결국, JPEG는 정확히 무엇을 버렸나?

여기까지 왔으면 제목의 질문에 깔끔하게 답할 수 있어요. 한 장으로 정리해볼게요.

반대로 절대 함부로 버리지 않는 것도 있어요. 각 블록의 평균 밝기(DC), 큰 윤곽을 만드는 저주파 성분, 그리고 모든 픽셀의 밝기 해상도예요. 사람이 "사진이 같다"고 느끼는 데 핵심인 정보는 꽉 붙잡고, 덜 중요한 것만 덜어낸 거죠. 이것이 바로 지각 기반 압축(Perceptual coding)의 철학이고, 정보 지능공학에서 말하는 "인간 중심의 정보 처리"의 교과서적인 사례예요. MP3가 귀가 못 듣는 소리를 버리는 것과 완전히 같은 계열의 아이디어죠.

👀 JPEG의 흔적: 압축 아티팩트 구별법

너무 많이 버리면 결국 티가 나요. JPEG 특유의 "상처" 세 가지를 알아두면, 앞으로 인터넷 짤을 보면서 "아 이거 몇 번 재압축됐네" 하고 아는 척할 수 있어요. 🤓

링잉은 왜 생길까요? 날카로운 경계(검은 글씨와 흰 배경 같은)는 수많은 고주파 성분이 합쳐져야 정확히 표현되는데, 그중 일부를 잘라내면 경계 근처에서 값이 출렁거려요. 신호처리에서 "깁스 현상(Gibbs phenomenon)"이라 부르는 것과 같은 계열의 현상이에요. 그래서 텍스트, 선화, 스크린샷은 JPEG와 상극이에요.

♻️ 세대 손실: 저장할 때마다 조금씩 상해요

JPEG를 열어서 편집하고 다시 JPEG로 저장하면, 디코딩 → 재인코딩 과정에서 또 양자화가 일어나요. 이게 반복되면 화질이 점점 나빠지는데, 이를 세대 손실(Generation loss)이라고 해요. 커뮤니티에서 수천 번 퍼날라진 "고대 짤"이 누렇고 뭉개진 이유가 이거예요. 🥲

흥미롭게도 같은 품질 설정, 같은 프로그램으로 편집 없이 재저장만 하면 양자화 결과가 거의 수렴해서 손실이 크게 누적되지 않는 경우도 있어요. 문제는 크기 조절, 자르기(8픽셀 단위가 아닌), 다른 품질 설정, 다른 프로그램이 끼면 블록 정렬과 테이블이 달라져서 손실이 쌓인다는 거예요. 그래서 실무에서는 원본을 무손실(RAW, TIFF, PNG 등)로 보관하고, 마지막 내보내기에서만 딱 한 번 JPEG로 저장하는 게 정석이에요.

⚙️ 실전 응용: 똑똑하게 JPEG 쓰는 법

이론을 알았으니 실전에서 바로 써먹을 수 있는 감각도 챙겨가요. 블로그 썸네일을 만들든, 쇼핑몰 상세 페이지를 만들든, 재능넷에 포트폴리오 이미지를 올리든, 이미지 용량은 페이지 로딩 속도와 직결되거든요.

🌀 프로그레시브 JPEG

JPEG에는 위에서부터 한 줄씩 그려지는 기본(Baseline) 방식 말고, 전체가 흐릿하게 먼저 나타났다가 점점 선명해지는 프로그레시브(Progressive) 방식도 있어요. DCT 계수를 저주파부터 여러 번에 나눠 전송하는 방식이죠. 지그재그로 줄 세운 계수 구조를 그대로 활용한 거예요. 같은 이미지에서 파일 크기가 조금 더 작아지는 경우가 많고(특히 큰 이미지), 느린 네트워크에서 체감 속도가 좋아요.

🧠 인코더도 진화한다

표준은 "디코더가 어떻게 해석하는지"만 정해요. 그래서 같은 표준 안에서도 인코더를 더 똑똑하게 만들면 같은 화질에 더 작은 파일을 만들 수 있어요. 모질라의 MozJPEG는 트렐리스 양자화 같은 최적화로 기존 libjpeg 대비 용량을 줄였고, 구글의 Guetzli(2017)는 사람의 시각 모델을 기반으로 계산을 아주 오래 돌려서 더 작은 파일을 만들었어요. 구글 연구진은 이후 Jpegli(2024)라는 인코더도 공개했어요. 모두 표준 JPEG 디코더로 그대로 열린다는 게 포인트예요. 30년 된 형식이 아직도 진화 중이라니, 은근 감동 포인트죠.

🚀 JPEG 다음 타자들: 왕좌는 계속될까?

당연히 후배들도 열심히 도전 중이에요. 대부분 JPEG의 "변환 → 양자화 → 엔트로피 부호화" 뼈대를 계승하면서, 블록 크기를 유연하게 바꾸고, 주변 블록에서 값을 예측하고, 더 정교한 엔트로피 부호화를 써서 효율을 높였어요.

그럼에도 JPEG가 여전히 1등인 이유는 단 하나, "어디서나 열린다"는 압도적인 호환성이에요. 30년 전 만든 디지털카메라 사진도, 오늘 찍은 사진도, 세상 거의 모든 기기와 프로그램이 별 고민 없이 열어요. 기술의 우열보다 생태계의 힘이 더 크다는 걸 보여주는 사례죠. 아이폰에서 찍은 HEIC를 공유하면 자동으로 JPEG로 바뀌는 경우가 많은 것도 같은 이유예요.

🧪 정보 지능공학 관점에서 한 번 더 생각하기

JPEG를 "옛날 파일 형식"으로만 보면 아쉬워요. 공학적으로 보면 여기엔 정보처리의 핵심 개념이 다 들어 있거든요.

최근에는 아예 신경망 기반 이미지 압축(Learned image compression) 연구도 활발해요. 인코더·디코더를 딥러닝으로 학습시켜서, DCT 같은 고정된 변환 대신 데이터에서 "가장 효율적인 표현"을 스스로 찾게 하는 방식이에요. 2024년에는 JPEG 위원회가 학습 기반 이미지 코딩 표준인 JPEG AI의 표준화를 진행하기도 했어요. 그런데 이 최신 연구들도 결국 "변환하고, 양자화하고, 엔트로피 부호화한다"는 JPEG의 3단 구조를 놀라울 만큼 닮아 있어요. 1992년의 설계가 일종의 원형(archetype)이 된 셈이죠.

📝 오늘 수다 정리 카드

이제 사진 저장 버튼 옆의 "품질 80" 슬라이더가 조금 다르게 보이지 않나요? 그 숫자 하나 뒤에는 망막의 세포 구성, 아날로그 TV 시대의 유산, 1970년대의 수학, 1950년대의 정보이론이 겹겹이 쌓여 있어요. 우리가 매일 무심코 주고받는 사진 한 장이 사실 인간의 눈을 정교하게 속이는 공학의 결정체였던 거죠. 다음에 단톡방에서 뭉개진 짤을 보면, 친구들한테 "이거 양자화 테이블이 너무 셌네" 하고 한마디 던져보세요. 반응은 책임 못 지지만요. 😉

그리고 이런 이미지 최적화 감각은 웹 디자인, 사진 보정, 쇼핑몰 운영 등 여러 분야에서 바로 쓰이는 실용 기술이기도 해요. 직접 하기 번거롭다면 재능넷 같은 재능 공유 플랫폼에서 이미지 작업에 능숙한 전문가의 도움을 받아보는 것도 좋은 방법이에요.