2016년 글이 아직도 읽히는 이유
유튜브, 넷플릭스, 줌 화상회의, 차량 블랙박스, CCTV까지. 우리가 매일 보는 영상의 상당수가 H.264라는 코덱으로 압축돼 있어요. 코덱이 뭐냐면, 영상을 작게 줄이고(인코딩) 다시 풀어서 재생하는(디코딩) 규칙이에요. Sid Bala가 쓴 'H.264 Is Magic'은 이 코덱의 원리를 수식 없이 풀어낸 글이에요. 나온 지 10년 가까이 됐는데도 여전히 입문서로 자주 추천되거든요. 그 핵심을 따라가면서 지금의 맥락까지 덧붙여 볼게요.
원본 영상은 얼마나 클까요?
먼저 압축을 안 하면 어떻게 되는지 계산해 볼게요. 1080p 영상의 한 프레임은 1920×1080, 약 207만 픽셀이에요. 픽셀마다 빨강·초록·파랑에 1바이트씩 3바이트가 필요하니 한 장에 약 6MB예요. 이걸 초당 60장 보여주면 1초에 약 370MB가 돼요. 1분이면 20GB가 넘죠. 그런데 실제 1080p 스트리밍은 보통 초당 몇 메가비트 수준이에요. 수백 분의 1로 줄어든 건데, 어떻게 이게 가능할까요?
마법 1: 눈이 못 알아채는 건 과감히 버린다
ZIP 같은 무손실 압축은 원본을 한 비트도 틀리지 않고 복원해야 해요. 그래서 영상에서는 별 효과가 없어요. H.264는 손실 압축이에요. 정보를 버리되, 사람 눈이 알아채기 어려운 것만 골라서 버리는 거죠. '무엇을 버릴지' 고르는 기술이 바로 이 마법의 정체예요.
마법 2: 주파수로 쪼개서 디테일을 덜어낸다
이미지는 '얼마나 빠르게 변하는가'에 따라 나눠볼 수 있어요. 파란 하늘처럼 완만하게 변하는 부분은 저주파예요. 나뭇잎 가장자리나 글자 테두리처럼 급하게 변하는 부분은 고주파고요. 음악 이퀄라이저로 저음과 고음을 나누는 것과 비슷하죠.
사람 눈은 미세한 고주파 디테일의 변화에 꽤 둔감해요. 그래서 H.264는 이미지를 작은 블록으로 나눈 뒤 DCT 계열의 변환으로 주파수 성분을 뽑아내요. 그리고 고주파 성분을 대충 반올림해 버리죠. 이 과정을 양자화라고 해요. 반올림하다 보면 0이 엄청 많아지는데, 0이 많은 데이터는 아주 잘 압축되거든요.
마법 3: 색보다 밝기를 아낀다
사람 눈은 밝기에는 민감하지만 색에는 의외로 둔감해요. 그래서 H.264는 RGB 대신 밝기(Y)와 색차(Cb, Cr)로 나눈 YCbCr이라는 방식을 써요. 그리고 색 정보는 가로세로 절반 해상도로만 저장해요. 이걸 4:2:0 크로마 서브샘플링이라고 하는데, 이것만으로도 데이터가 절반으로 줄어요.
마법 4: 이전 장면을 재활용한다
진짜 큰 절약은 여기서 나와요. 뉴스 앵커 영상을 떠올려 보세요. 배경은 그대로고 입과 손만 조금씩 움직이잖아요. 매 프레임을 통째로 저장할 이유가 없죠.
H.264는 가끔씩만 한 장을 온전히 저장해요. 이걸 I-프레임(키프레임)이라고 해요. 나머지 프레임은 다른 프레임을 참고해서 차이만 저장하고요. 앞 프레임만 참고하면 P-프레임, 앞뒤를 모두 참고하면 B-프레임이에요. 방식은 이래요. 화면을 작은 블록으로 나누고, 블록마다 '이전 프레임의 저 위치에서 이만큼 옮겨왔다'는 정보를 남겨요. 이게 모션 벡터예요. 여기에 약간의 보정값(잔차)만 더해서 기록하는 거죠. 이 기법을 움직임 보상이라고 불러요.
마법 5: 남은 데이터를 한 번 더 꽉 짜기
마지막으로 엔트로피 코딩을 거쳐요. 모스 부호에서 자주 쓰는 E가 점 하나인 것처럼, 자주 나오는 값은 짧은 코드로, 드문 값은 긴 코드로 바꾸는 거예요. H.264의 CABAC은 상황에 맞춰 확률을 계속 업데이트하면서 처리해서 데이터를 한층 더 줄여줘요.
업계 맥락: 후속 코덱이 많은데 왜 아직 H.264일까
H.265(HEVC)는 같은 화질을 대략 절반 비트레이트로 내는 걸 목표로 나왔어요. 하지만 특허 라이선스가 복잡해서 웹에서는 확산이 더뎠죠. 그 틈을 구글의 VP9이 파고들었고, 구글·넷플릭스·아마존 등이 모인 AOMedia의 로열티 프리 코덱 AV1도 뒤따랐어요. 그런데도 H.264가 여전히 기본값인 이유는 호환성 때문이에요. 거의 모든 기기에 하드웨어 디코더가 들어 있어서, 오래된 폰에서도 배터리를 아끼며 재생되거든요.
한국 개발자에게 주는 시사점
원리를 알고 나면 FFmpeg 옵션이 갑자기 읽히기 시작해요. 예를 들어 ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset medium -g 60 output.mp4에서 -crf는 화질 기준값이에요. 숫자가 낮을수록 고화질이고, 18 전후면 눈으로 구분하기 어려운 수준이에요. -g 60은 키프레임 간격이에요. 영상 탐색(시크)이 얼마나 빠른지, HLS 세그먼트가 깔끔하게 잘리는지와 직결되죠. 화면 공유 영상에서 글자만 유독 뭉개지는 이유도 이제 보이죠? 글자는 고주파 덩어리라서 그래요.
마무리
한줄 정리: H.264의 마법은 결국 '사람 눈이 무엇을 못 보는지'를 정확히 아는 데서 나와요.
여러분 서비스는 아직 H.264를 쓰고 있나요, 아니면 AV1이나 HEVC로 넘어가셨나요? 전환하면서 겪은 호환성 이슈나 비용 절감 경험을 공유해 주세요!
🔗 출처: Hacker News