H.264 vs HEVC vs AV1 비디오 코덱 비교 | 압축·호환성·인코딩 선택 가이드
이 글의 핵심
H.264(AVC), HEVC(H.265), AV1의 압축 효율·디코딩 부하·라이선스를 비교하고, 매크로블록·CTU·슈퍼블록·RDO·프로덕션 인코딩 패턴까지 내부 관점에서 정리했습니다.
들어가며
스트리밍·화상·게임 녹화·아카이브까지 비디오 코덱 선택은 품질·용량·재생 환경을 동시에 결정합니다. H.264는 여전히 기본값이고, HEVC는 고효율을, AV1은 로열티 없는 차세대 대안으로 자리 잡았습니다. 이 글에서는 세 코덱을 같은 기준으로 놓고 비교합니다. 비유로 말씀드리면, H.264는 어디서나 도는 표준 티비, HEVC는 전력은 덜 쓰지만 호환 TV를 골라야 하는 고효율 세트, AV1은 로열티 부담은 줄이고 인코딩은 무거울 수 있는 차세대 장비에 가깝습니다.
언제 H.264를, 언제 HEVC·AV1을 쓰나요?
| 관점 | H.264 (AVC) | HEVC (H.265) | AV1 |
|---|---|---|---|
| 성능 | 디코딩 부담 낮음 | 동일 화질에서 비트레이트 절감 | 로열티·대역폭 측면에서 장기적 대안 |
| 사용성 | 거의 모든 단말 | 라이선스·기기 이슈 확인 | 인코딩 시간·HW 확인 |
| 적용 시나리오 | 최대 호환 | 4K·저대역폭 | 웹·OTT 장기 전략 |
이 글을 읽으면
- H.264 / HEVC / AV1의 역할과 라이선스·호환성 차이를 이해합니다
- 매크로블록·CTU·슈퍼블록 등 블록 구조와 RDO(레이트-디스토션 최적화) 관점에서 인코더가 무엇을 최적화하는지 파악합니다
- 동일 주관적 화질에서의 대략적인 비트레이트·인코딩 시간 관계를 파악합니다
- 프로덕션 래더·2-pass·품질 검증 등 실서비스 인코딩 패턴과 FFmpeg로 인코딩·폴백 전략을 적용하는 방법을 익힙니다
- 서비스 단계(광범위 호환 vs 최신 단말)에 맞는 의사결정을 할 수 있습니다
1. 빠른 비교표
| 특성 | H.264 (AVC) | HEVC (H.265) | AV1 |
|---|---|---|---|
| 표준 | ITU-T H.264 / MPEG-4 AVC | ITU-T H.265 / MPEG-H | AOMedia Video 1 (AV1) |
| 대략적 압축 효율 (동일 화질 기준) | 기준(1×) | H.264 대비 약 40~50% 절감이 일반적 | HEVC 대비 동급 |
| 인코딩 속도 (동일 하드웨어) | 가장 빠른 편 | H.264보다 느림 | HEVC보다 더 느린 경우 많음 (소프트웨어) |
| 디코딩 | 거의 모든 기기 | 최신 TV·모바일·GPU (구형은 미지원) | 최신 브라우저·칩셋 (구형은 제한) |
| 로열티 | 특허 풀(제품별 과금 구조 존재) | 특허 풀 | AOMedia 로열티 프리 (구현 시 주의사항은 별도) |
| 대표 프로파일/용도 | Baseline~High, 방송·웹·저장 | Main/Main 10, 4K·HDR | 8/10bit, 웹 스트리밍·VOD |
2. 코덱 내부 구조 심화
아래는 재생 호환성이 아니라 인코더가 무엇을 최적화하는지를 이해하기 위한 골격입니다. 세 코덱 모두 예측(prediction) → 잔차(residual) 변환·양자화 → 엔트로피 부호화의 큰 흐름을 공유하지만, 블록 크기·분할 방식·보조 필터에서 효율과 복잡도가 갈립니다.
H.264(AVC): 매크로블록, 모션 벡터, 정수 변환
매크로블록(Macroblock, MB)은 휘도(luma) 기준 16×16 픽셀을 기본 단위로 삼습니다. 색차(chroma)는 일반적인 4:2:0에서 크로마가 가로·세로 각각 절반인 8×8로 대응됩니다. 한 매크로블록 안에서는 인터 예측(이전·이후 프레임에서 복사)과 인트라 예측(같은 프레임 내 주변 픽셀 참조)이 선택되며, 복잡한 움직임을 표현하기 위해 16×16, 16×8, 8×16, 8×8 등 파티션(partition)으로 더 잘게 쪼갤 수 있습니다. 8×8이 선택되면 그 안에서 다시 서브파티션이 정의되어, 모션 벡터(motion vector, MV)가 블록마다 따로 붙을 수 있습니다.
모션 보상은 정수 픽셀 격자만으로는 부족하므로, 1/4 픽셀(쿼터 펠) 보간이 도입됩니다. 참조 프레임에서 분수 위치의 밝기를 보간해 예측값을 만들고, 실제 픽셀과의 차이인 잔차만 코딩합니다. 이때 MV 자체도 차분 부호화(인접 블록 MV와의 차이)로 비트를 줄입니다.
잔차의 변환은 전통적인 DCT(이산 코사인 변환)를 그대로 쓰기보다, 정수 근사 변환(integer transform)으로 구현되는 것이 일반적입니다. Baseline에서는 4×4 블록 단위 변환이 핵심이며, High Profile 등에서는 8×8 변환 옵션이 추가되어 평탄한 영역에서 에너지를 더 잘 모을 수 있습니다. DC 계수 묶음에는 Hadamard 변환을 적용하는 경로도 있어, 저주파 에너지를 추가로 압축합니다. 양자화(quantization) 이후 계수는 CAVLC 또는 문맥을 적극 활용하는 CABAC으로 엔트로피 부호화됩니다.
블록 경계에서 생기는 블로킹 아티팩트를 줄이기 위해 디블로킹 필터(in-loop deblocking)가 표준 인코딩 루프 안에 포함됩니다. 디코더도 동일한 필터를 적용해야 하므로, 이후 프레임의 참조 프레임 품질 자체가 맞물려 동작합니다.
HEVC(H.265): CTU·쿼드트리 분할과 인코딩 효율
H.264의 고정된 매크로블록 대신, HEVC는 코딩 트리 유닛(CTU, Coding Tree Unit)을 최상위 블록으로 둡니다. 일반적으로 최대 64×64(일부 프로파일·설정에서 다를 수 있음)까지의 영역에서 시작해, 쿼드트리(quad-tree)로 재귀적으로 CU(Coding Unit)로 분할합니다. 분할 깊이에 따라 같은 물체 경계를 작은 블록으로만 쓰는 낭비를 줄이면서도, 평탄한 배경은 큰 블록으로 묶어 비트를 아낄 수 있습니다.
PU(Prediction Unit)는 예측 방식(인트라·인터, 파티션 형태)을 결정하고, TU(Transform Unit)는 실제 정수 변환·양자화에 쓰이는 블록입니다. HEVC는 4×4부터 32×32까지 다양한 TU 크기를 허용하여, 잔차의 주파수 특성에 맞춰 변환 기저를 고릅니다. 인트라 예측은 35가지 방향 모드 등으로 세분화되어, H.264 대비 같은 비트로 에지 방향을 더 정밀하게 따릅니다.
인코딩 효율 측면에서 HEVC는 SAO(Sample Adaptive Offset)와 개선된 디블로킹으로 링작·밴딩 같은 고주파 손실을 완화합니다. SAO는 픽셀값에 구간별 오프셋을 더해 주관적 품질을 끌어올리는데, 이 역시 루프 안에서 표준적으로 정의됩니다. 결과적으로 같은 VMAF·SSIM을 목표로 할 때 더 적은 비트로 수렴하는 경우가 많습니다. 다만 모드 결정 공간이 커져 인코더 복잡도는 H.264 대비 현저히 증가합니다.
AV1: 슈퍼블록·파티션과 필름 그레인 합성
AV1은 슈퍼블록(superblock)을 기본 타일로 사용하며, 일반적으로 128×128 또는 64×64 단위에서 10가지 파티션 패턴(예: 4-way split, T자형 분할 등)으로 영역을 나눕니다. HEVC의 쿼드트리와 달리 더 유연한 기하 분할을 허용해, 텍스트·얇은 선·경계 근처에서 예측 잔차 에너지를 줄이는 데 유리합니다. 변환 세트도 다양한 정수 변환(DCT/DST 계열)을 선택할 수 있어, 잔차의 방향성에 맞춰 계수 분포를 낮춥니다.
필름 그레인(film grain) 합성은 AV1의 실무적으로 중요한 특징입니다. 필름·고감도 촬영에서 흔한 입자 노이즈를 픽셀 잔차로 그대로 인코딩하면 비트를 많이 먹고, 시간적 안정성도 떨어집니다. AV1은 필름 그레인 매개변수를 메타데이터로 전송하고, 디코더가 결정론적으로(또는 규정된 방식으로) 텍스처를 합성합니다. 즉, “노이즈를 압축”하기보다 “노이즈의 통계를 복원”에 가깝습니다. 이는 주관적 화질과 스트리밍 비트 사이의 트레이드오프를 바꾸며, 원본의 필름 룩을 유지하려는 OTT·아카이브에서 의미가 큽니다.
엔트로피 부호화는 다중 심볼 적응 부호화 계열을 사용하여, H.264의 CABAC 한계를 넘어 문맥 적응 폭을 넓힙니다. 대신 디코더 스펙이 무거워져 구형 단말·소프트웨어 경로에서 CPU 부담이 될 수 있습니다.
3. 레이트-디스토션 최적화(RDO)
실제 인코더는 “눈에 덜 나쁜 왜곡”과 “쓰는 비트 수”를 동시에 줄이는 정합 문제입니다. 이를 레이트-디스토션 최적화(rate-distortion optimization, RDO)라고 하며, 대표적으로 라그랑주 비용 J = D + λR을 최소화하는 방향으로 모드·참조·MV·QP·분할을 고릅니다. 여기서 D는 왜곡(예: SSE, SATD 등으로 근사), R은 비트 수, λ(람다)는 품질·비트 균형을 정하는 라그랑주 승수입니다. λ는 보통 양자화 파라미터(QP)와 연동되며, QP가 클수록 λ가 커져 더 거친 양자화·더 단순한 모드가 선호됩니다.
왜 중요한가? 동일 QP라도 모드 결정이 달라지면 비트와 화질이 크게 달라집니다. 예를 들어 큰 CTU/슈퍼블록으로 묶을지, 작은 분할로 갈지는 한 블록의 R만 보고 결정하면 안 되고, 전역적인 J를 기준으로 해야 합니다. x264·x265·SVT-AV1 등은 내부적으로 트렐리스 양자화, 서브픽셀 정밀도, B-프레임·참조 프레임 수 같은 옵션과 결합해 RDO 강도를 조절합니다.
실무 시사점은 다음과 같습니다. 프리셋이 느릴수록 더 많은 후보를 탐색하므로 동일 QP에서 품질↑·비트↓인 경우가 많지만, 인코딩 시간↑입니다. 반대로 빠른 프리셋은 RDO 탐색을 줄여 실시간에는 유리하나 동일 파일 크기에서 VMAF가 떨어질 수 있습니다. CRF·CQ 모드 역시 내부적으로 목표 품질을 맞추기 위해 QP·λ를 프레임별로 조정합니다.
4. 프로덕션 인코딩 패턴
단일 FFmpeg 한 줄로 끝나는 경우는 소수이고, 서비스에서는 보통 아래 패턴이 반복됩니다.
1) 목표 지표 기반 래더(ABR ladder). 같은 소스에서 360p~4K까지 여러 렌디션을 만들 때, 고정 비트레이트만으로는 콘텐츠별 편차가 커집니다. per-title 인코딩은 콘텐츠 복잡도에 따라 비트레이트 점을 옮기고, convex hull 최적화로 불필요한 렌디션을 줄입니다. 품질은 VMAF(또는 사내 메트릭)로 하한선을 두는 방식이 널리 쓰입니다.
2) 2-pass·VBV·버퍼 모델. 방송·OTT는 피크 비트레이트 제약이 있습니다. x264/x265의 2-pass는 첫 패스에서 통계를 모아 둘째 패스에서 VBV(가상 버퍼) 제약을 맞춥니다. 실시간은 zerolatency·slice·하드웨어 인코더가 우선입니다.
3) 코덱별 역할 분리. 마스터는 편집 친화 포맷(예: ProRes, FFV1)으로 보관하고, 배포만 H.264/HEVC/AV1로 트랜스코드합니다. AV1은 SVT-AV1이 스케일·속도 균형이 좋고, libaom은 품질 튜닝 여지가 있습니다. HEVC는 NVENC/QSV/VideoToolbox 등 하드웨어가 잡히면 비용·지연 측면에서 유리합니다.
4) HDR·색 공간. HLG·PQ·메타데이터는 컨테이너·플랫폼마다 요구가 다릅니다. 인코딩 시 -color_primaries, -color_trc, -colorspace와 마스터링 디스플레이 메타를 검증된 파이프라인으로 맞춥니다.
5) 품질 검증 체크리스트. (a) 실기기 재생, (b) 첫·중간·끝 장면 VMAF 샘플, (c) 빠른 움직임·텍스트·그레인 구간 육안, (d) 오디오 싱크 및 캡션 트랙.
아래는 래더용 소스에서 SVT-AV1로 품질·속도 균형을 잡는 예시입니다. -svtav1-params로 필름 그레인·타일 등을 프로젝트 정책에 맞게 붙일 수 있습니다.
ffmpeg -i master.mov -c:v libsvtav1 -preset 6 -crf 32 \
-svtav1-params tune=0:keyint=240:film-grain=8 \
-pix_fmt yuv420p10le -c:a libopus -b:a 160k \
-movflags +faststart distribution_av1.mp4위 명령에서 -crf와 preset은 서비스 SLA에 맞춰 조정합니다. film-grain은 원본 그레인이 강한 소스에서만 의미가 있으며, 저노이즈 애니메이션에서는 오히려 불필요한 텍스처를 만들 수 있으니 A/B 테스트가 필요합니다. 10비트(yuv420p10le)는 밴딩 완화에 도움이 되지만 디코더·기기 지원을 확인해야 합니다.
5. 각 코덱 상세
앞선 코덱 내부 구조·RDO·프로덕션 패턴을 바탕으로, 여기서는 실무에서 바로 쓰는 요약과 FFmpeg 예제에 집중합니다.
H.264 (AVC)
특징: 산업 표준에 가깝고, 하드웨어 디코더 보급률이 가장 높습니다. 라이브·저지연 시나리오에서 여전히 기본 선택인 경우가 많습니다. 장점
- 스마트 TV, 구형 모바일, 임베디드까지 재생 호환성 최상
- 인코더·디코더 생태계 성숙, 실시간 인코딩 부담 상대적으로 낮음 단점
- HEVC/AV1 대비 동일 화질에서 비트레이트가 큼
- 고해상도·HDR에서 효율 한계 FFmpeg 예제 (libx264)
ffmpeg -i input.mp4 -c:v libx264 -preset medium -crf 23 \
-pix_fmt yuv420p -c:a aac -b:a 128k output.mp4HEVC (H.265)
특징: H.264 대비 같은 주관적 화질에서 비트레이트를 크게 줄이는 데 초점이 맞춰져 있습니다. 4K·HDR 콘텐츠에서 널리 쓰입니다. 장점
- 스트리밍 대역폭·저장 비용 절감에 유리
- 하드웨어 가속 인코딩/디코딩이 최신 기기에서 널리 지원 단점
- 특허·라이선스 이슈로 구현·배포 시 벤더 정책 확인 필요
- 구형 브라우저·OS는 소프트웨어 디코딩 또는 미지원 FFmpeg 예제 (libx265)
ffmpeg -i input.mp4 -c:v libx265 -preset medium -crf 28 \
-tag:v hvc1 -c:a aac -b:a 128k output.mp4AV1
특징: Alliance for Open Media가 개발한 개방형 코덱으로, 로열티 프리를 목표로 합니다. YouTube 등 대형 스트리밍이 채택을 확대 중입니다. 장점
- 동일 품질 대역폭 추가 절감 가능성 (콘텐츠·설정에 따라 다름)
- 장기적으로 라이선스 비용 민감 서비스에 유리 단점
- 소프트웨어 인코딩은 CPU 부하가 큼 (하드웨어 인코더는 플랫폼별 편차)
- 구형 단말·브라우저는 폴백 필수 FFmpeg 예제 (libaom-av1 / libsvtav1)
# SVT-AV1: 속도와 품질 균형이 실무에서 자주 쓰임
ffmpeg -i input.mp4 -c:v libsvtav1 -preset 6 -crf 30 \
-c:a libopus -b:a 128k output.mkv6. 성능 비교
절대 수치는 해상도, 프레임, 콘텐츠 복잡도, 프리셋, CRF에 따라 크게 달라집니다. 아래는 같은 머신·유사 설정에서 흔히 관찰되는 상대적 경향입니다.
| 지표 | H.264 | HEVC | AV1 |
|---|---|---|---|
| 동일 CRF 계열에서 파일 크기 | 가장 큼 | 중간 | 가장 작은 경우가 많음 |
| 인코딩 시간 (소프트웨어) | 짧음 | 중간 | 길음 |
| 실시간 인코딩 | 용이 | GPU/NVENC 등에 의존 | CPU 실시간은 부담 큼 |
시각화: 선택 의사결정 흐름
flowchart TD
A[코덱 선택] --> B{최우선은?}
B -->|모든 기기 재생| C[H.264]
B -->|대역폭 절감 + 최신 기기| D[HEVC 또는 AV1]
B -->|로열티 최소화| E[AV1 + H.264 폴백]
C --> F[호환성 최대]
D --> G[디코더 지원 매트릭스 확인]
E --> H[멀티 코덱 파이프라인]
실측을 할 때: 동일 소스로 VMAF/SSIM 등 품질 지표와 인코딩 시간을 함께 기록하고, 타깃 디코더(실기기)에서 재생 테스트를 병행하는 것이 안전합니다.
7. 사용 시나리오별 추천
| 시나리오 | 추천 | 이유 |
|---|---|---|
| 광범위 호환 (웹·임베디드) | H.264 | 디코더 보급률 최상 |
| 4K/HDR VOD, 최신 TV | HEVC 또는 AV1 | 대역폭·저장 효율 |
| 저지연 라이브 | H.264 또는 HW HEVC | 인코딩 지연·안정성 |
| 장기 아카이브 + 비용 | AV1 검토 + 메타데이터 보존 | 용량·라이선스 측면 검토 |
| 게임 녹화·편집 호환 | H.264 (편집 툴·공유) | 워크플로 단순화 |
| 실무 의사결정: (1) 지원 디코더 목록을 먼저 확정하고, (2) 인코딩 예산(시간·전력), (3) CDN 비용 순으로 가중치를 두면 선택이 단순해집니다. |
8. 마이그레이션 가이드
H.264 → HEVC
- 타깃 플랫폼에서 HEVC 디코딩 지원 여부 확인 (특히 웹은 브라우저별 차이).
-tag:v hvc1(MP4) 등 컨테이너 호환 태그를 맞춥니다.- 기존 사용자에게는 H.264 트랙 유지(멀티 코덱) 또는 별도 URL로 단계적 전환.
HEVC/H.264 → AV1
- 소프트웨어 인코딩이면 프리셋·타일 옵션으로 시간과 품질 균형 조정.
- 폴백: AV1 우선 재생 실패 시 H.264/HEVC로 전환하는 어댑티브 스트리밍(HLS/DASH) 구성.
- 구형 단말: 아카이브 원본(H.264/무압축)을 별도 보관해 재인코딩 여지를 남깁니다. 주의: 특허·배포 정책은 제품·지역별로 다르므로 법무/벤더 가이드를 반드시 확인하세요.
9. 실전 팁
혼합 파이프라인 (예: MP4 + H.264 + AAC)
- 호환 베이스라인: H.264 + AAC + MP4는 거의 모든 클라이언트에서 재생됩니다.
- 고효율 레이어: 동일 콘텐츠에 AV1 또는 HEVC 변형을 추가해 대역폭이 넉넉한 사용자에게만 제공할 수 있습니다.
폴백 전략
<video>+ multiple<source>(브라우저가 지원 코덱 선택).- HLS/DASH: 코덱별 렌디션 분리, 클라이언트가 적응 선택.
- 서버 트랜스코딩: 원본은 마스터(예: ProRes/무손실)로 보관하고 배포용만 코덱 분기.
<video controls>
<source src="trailer.av1.mp4" type='video/mp4; codecs="av01.0.08M.08"'>
<source src="trailer.hevc.mp4" type='video/mp4; codecs="hev1.1.6.L93.B0"'>
<source src="trailer.h264.mp4" type="video/mp4">
</video>10. 흔한 질문
Q1. 같은 CRF 숫자를 H.264, HEVC, AV1에 쓰면 되나요?
아니요. 코덱마다 CRF 스케일과 주관적 화질이 다릅니다. 코덱별로 별도 튜닝하고 VMAF 등으로 맞추는 것이 좋습니다.
Q2. AV1이 항상 HEVC보다 작은 파일을 만드나요?
대체로 그 경향은 있으나, 짧은 클립·저프레임·특정 프리셋에서는 차이가 줄어들 수 있습니다. 반드시 샘플로 검증하세요.
Q3. 실시간 방송에는 무엇이 적합한가요?
저지연·안정성이 우선이면 H.264 또는 검증된 하드웨어 HEVC가 많습니다. AV1 실시간은 환경에 따라 CPU 부담이 큽니다.
Q4. iOS Safari에서 AV1은?
정책과 버전에 따라 다릅니다. 2026년 기준에도 호환 매트릭스를 공식 문서로 확인하고 H.264/HEVC 폴백을 준비하는 것이 안전합니다.
Q5. HDR을 쓰려면?
HEVC·AV1 모두 HDR 메타데이터·프로파일 조합이 복잡합니다. 타깃 플랫폼 스펙(HLG/Dolby Vision 등)에 맞춰 별도 검증이 필요합니다.
Q6. AV1 필름 그레인 합성은 디테일을 지우나요?
목적은 “미세 입자를 비트로 때우는 것”을 줄이고 통계적으로 유사한 텍스처를 디코더에서 복원하는 것입니다. SVT-AV1의 film-grain 등은 원본 분석·강도에 따라 다르지만, 과도하면 고주파 디테일이 줄어들 수 있으므로 짧은 클립 VMAF·육안 A/B로 맞춥니다.
Q7. RDO를 직접 건드리지 않는데 왜 알아야 하나요?
프리셋·tune·참조 프레임 수 같은 옵션이 모두 RDO 탐색 범위·λ 연동과 연결됩니다. “느린 프리셋이 왜 비트를 아끼는지”를 설명하는 언어가 되므로, 인코딩 SLA와 품질 목표를 팀과 맞출 때 유리합니다.
마무리
- 호환성 최우선이면 H.264가 여전히 가장 무난한 기본값입니다.
- 대역폭·저장 비용이 크면 HEVC 또는 AV1을 검토하고, 디코더 지원과 인코딩 비용을 함께 계산합니다.
- AV1은 장기적으로 개방 생태계와 비용 측면에서 매력적이지만, 폴백과 인코딩 시간을 전제에 둡니다. 한 줄 정리: 모든 기기를 커버하려면 H.264를 기본으로 두고, 효율이 필요하면 HEVC/AV1을 추가 레이어로 얹는다.
관련 글
키워드
H.264, HEVC, H.265, AV1, 비디오 코덱, 압축, FFmpeg, 스트리밍, 비교
심화 부록: 구현·운영 관점
이 부록은 앞선 본문에서 다룬 주제(「H.264 vs HEVC vs AV1 비디오 코덱 비교 | 압축·호환성·인코딩 선택 가이드」)를 구현·런타임·운영 관점에서 다시 압축합니다. 도메인별 세부 구현은 글마다 다르지만, 입력 검증 → 핵심 연산 → 부작용(I/O·네트워크·동시성) → 관측의 흐름으로 장애를 나누면 원인 추적이 빨라집니다.
내부 동작과 핵심 메커니즘
flowchart TD A[입력·요청·이벤트] --> B[파싱·검증·디코딩] B --> C[핵심 연산·상태 전이] C --> D[부작용: I/O·네트워크·동시성] D --> E[결과·관측·저장]
sequenceDiagram participant C as 클라이언트/호출자 participant B as 경계(런타임·게이트웨이·프로세스) participant D as 의존성(API·DB·큐·파일) C->>B: 요청/이벤트 B->>D: 조회·쓰기·RPC D-->>B: 지연·부분 실패·재시도 가능 B-->>C: 응답 또는 오류(코드·상관 ID)
- 불변 조건(Invariant): 버퍼 경계, 프로토콜 상태, 트랜잭션 격리, FD 상한 등 단계별로 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
- 결정성: 순수 층과 시간·네트워크·스케줄에 의존하는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
- 경계 비용: 직렬화, 인코딩, syscall 횟수, 락 경합, 할당·GC, 캐시 미스를 의심 목록에 둡니다.
- 백프레셔: 생산자가 소비자보다 빠를 때 버퍼·큐·스트림에서 속도를 줄이는 신호를 어디에 둘지 정의합니다.
프로덕션 운영 패턴
| 영역 | 운영 관점 질문 |
|---|---|
| 관측성 | 요청 단위 상관 ID, 에러율·지연 p95/p99, 의존성 타임아웃·재시도가 대시보드에 보이는가 |
| 안전성 | 입력 검증·권한·비밀·감사 로그가 코드 경로마다 일관적인가 |
| 신뢰성 | 재시도는 멱등 연산에만 적용되는가, 서킷 브레이커·백오프·DLQ가 있는가 |
| 성능 | 캐시·배치 크기·커넥션 풀·인덱스·백프레셔가 데이터 규모에 맞는가 |
| 배포 | 롤백 룬북, 카나리/블루그린, 마이그레이션·피처 플래그가 문서화되어 있는가 |
| 용량 | 피크 트래픽·디스크·FD·스레드 풀 상한을 주기적으로 검증하는가 |
스테이징은 데이터 양·네트워크 RTT·동시성을 프로덕션에 가깝게 맞출수록 재현율이 올라갑니다.
확장 예시: 엔드투엔드 미니 시나리오
앞선 본문 주제(「H.264 vs HEVC vs AV1 비디오 코덱 비교 | 압축·호환성·인코딩 선택 가이드」)를 배포·운영 흐름에 맞춰 옮긴 체크리스트입니다. 도메인에 맞게 단계 이름만 바꿔 적용할 수 있습니다.
- 입력 계약 고정: 스키마·버전·최대 페이로드·타임아웃·에러 코드를 경계에 둔다.
- 핵심 경로 계측: 요청 ID, 단계별 지연, 외부 호출 결과 코드를 로그·메트릭·트레이스에서 한 흐름으로 본다.
- 실패 주입: 의존성 타임아웃·5xx·부분 데이터·락 대기를 스테이징에서 재현한다.
- 호환·롤백: 설정/마이그레이션/클라이언트 버전을 되돌릴 수 있는지 확인한다.
- 부하 후 검증: 피크 대비 p95/p99, 에러율, 리소스 상한, 알림 임계값을 점검한다.
handle(request):
ctx = newCorrelationId()
validated = validateSchema(request)
authorize(validated, ctx)
result = domainCore(validated)
persistOrEmit(result, idempotentKey)
recordMetrics(ctx, latency, outcome)
return result문제 해결(Troubleshooting)
| 증상 | 가능 원인 | 조치 |
|---|---|---|
| 간헐적 실패 | 레이스, 타임아웃, 외부 의존성, DNS | 최소 재현 스크립트, 분산 트레이스·로그 상관관계, 재시도·서킷 설정 점검 |
| 성능 저하 | N+1, 동기 I/O, 락 경합, 과도한 직렬화, 캐시 미스 | 프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거 |
| 메모리 증가 | 캐시 무제한, 구독/리스너 누수, 대용량 버퍼, 커넥션 미반납 | 상한·TTL·힙/FD 스냅샷 비교 |
| 빌드·배포만 실패 | 환경 변수, 권한, 플랫폼 차이, lockfile | CI 로그와 로컬 diff, 런타임·이미지 버전 핀 |
| 설정 불일치 | 프로필·시크릿·기본값, 리전 | 스키마 검증된 설정 단일 소스와 배포 매트릭스 표준화 |
| 데이터 불일치 | 비멱등 재시도, 부분 쓰기, 캐시 무효화 누락 | 멱등 키·아웃박스·트랜잭션 경계 재검토 |
권장 순서: (1) 최소 재현 (2) 최근 변경 범위 축소 (3) 환경·의존성 차이 (4) 관측으로 가설 검증 (5) 수정 후 회귀·부하 테스트.
배포 전에는 git add → git commit → git push 후 npm run deploy 순서를 권장합니다.
자주 묻는 질문 (FAQ)
Q. 이 내용을 실무에서 언제 쓰나요?
A. H.264(AVC), HEVC(H.265), AV1의 압축 효율·디코딩 부하·라이선스를 비교합니다. 스트리밍·아카이브·실시간에 맞는 코덱 선택과 FFmpeg 예제를 정리했습니다. 실전 예제와 코드로 개념부터 활용까지… 실무에서는 위 본문의 예제와 선택 가이드를 참고해 적용하면 됩니다.
Q. 선행으로 읽으면 좋은 글은?
A. 각 글 하단의 이전 글 또는 관련 글 링크를 따라가면 순서대로 배울 수 있습니다. C++ 시리즈 목차에서 전체 흐름을 확인할 수 있습니다.
Q. 더 깊이 공부하려면?
A. cppreference와 해당 라이브러리 공식 문서를 참고하세요. 글 말미의 참고 자료 링크도 활용하면 좋습니다.
같이 보면 좋은 글 (내부 링크)
이 주제와 연결되는 다른 글입니다.
- AV1 비디오 코덱 차세대 표준 | 로열티 프리·SVT-AV1·FFmpeg 실전
- HEVC(H.265) 비디오 코덱 실전 활용 | 4K·8K·x265·FFmpeg 튜닝
- H.264(AVC) 비디오 코덱 완전 가이드 | 프로파일·FFmpeg·스트리밍 실전
이 글에서 다루는 키워드 (관련 검색어)
비디오 코덱, H.264, HEVC, AV1, 비교, RDO, CTU, AV1 필름 그레인 등으로 검색하시면 이 글이 도움이 됩니다.