오답 보기는 여기서 꺼내 쓴다. 원장에 없는 오해를 즉석에서 지어내지 않는다.
각 항목은 M-<번호>로 참조한다. 새 항목을 추가할 때는 실제로 사람들이 그렇게 믿는 근거(현업 대화, 블로그 오류, 스택오버플로 오답 등)를 한 줄 적는다.
- 실제: MP4는 컨테이너(상자)지 코덱이 아니다. 인코딩은 코덱(H.264/VP9/AV1)으로 하고 MP4는 그 결과를 담는다. 두 축은 독립이라 H.264는 MP4·MPEG-TS에 다 들어가지만 WebM에는 못 들어간다.
- 왜 믿는가: 확장자가 포맷의 전부처럼 쓰인다. 같은 .mp4가 기기마다 재생 성패가 갈리는 원인(안의 코덱·프로파일)이 이 어휘 혼동 뒤에 숨는다.
- 오답 유형:
adjacent
- 실제: 이미 H.264+AAC라면 HLS 패키징은 세그먼트 분할 + 재목록화일 뿐
-c copy(remux)로 가능하다. 트랜스코딩은 비트스트림을 다시 만드는 것 — 손실·CPU 대량 소모. remux는 무손실·I/O 바운드. - 왜 믿는가: "변환"이라는 동사가 재인코딩을 연상시킨다. 그래서 포맷 요구가 바뀔 때마다 인코딩(비쌈)과 패키징(저렴)을 한 단계로 뭉뚱그려 처리하는 낭비가 생긴다.
- 오답 유형:
adjacent
- 실제: CMAF(ISO/IEC 23000-19)는 fMP4 세그먼트에 제약 프로파일을 가한 규격이다. 하나의 세그먼트 파일이 HLS media playlist에서도 DASH MPD에서도 유효하게 만들어, 캐시 객체 수가 절반으로 줄고 인코딩도 한 번으로 공유된다.
- 왜 믿는가: "두 프로토콜을 통일했다"는 요약이 "하나로 대체했다"로 읽힌다. 코덱·프로토콜·컨테이너라는 층위가 이미 섞여 있으니 새 포맷 하나로 오해하기 쉽다.
- 오답 유형:
adjacent
- 실제: CRF는 화질을 고정하고 크기는 콘텐츠 복잡도 따라 가변된다 — 산출 크기를 예측할 수 없다. 렌디션 규격(평균 비트레이트)이 계약이면 2-pass VBR, 완화된 규격이면 CRF+maxrate/bufsize(capped CRF)다.
- 왜 믿는가: CRF가 "품질 기반 인코딩의 권장 방식"으로 소개되곤 해서 모든 경우의 좋은 기본값처럼 보인다.
- 오답 유형:
one-step-short
- 실제: 같은 비트레이트에서 품질은 코덱·인코더·프리셋에 따라 달라진다. 소프트웨어→하드웨어 인코더 교체 후 "비트레이트는 같은데 화질 하락"이 대표 사례. 판정은 VMAF와 재생 지표로 한다.
- 왜 믿는가: 비트레이트가 품질을 숫자로 요약하는 유일한 값처럼 보인다. 인코더 교체 리뷰에서 "평균 비트레이트가 목표와 같으니 품질도 같다"는 결론이 반복된다.
- 오답 유형:
overgeneralized
- 실제: HLS/DASH는 HTTP 정적 파일 서빙 + 클라이언트 로직이다. RFC 8216은 "plain HTTP servers" 위의 전송으로 설명을 시작한다. 그래서 CDN이 그대로 쓰인다. 전용 스트리밍 프로토콜 서버(RTSP/RTP 계열)는 웹 VOD의 주류가 아니다.
- 왜 믿는가: "스트리밍"이라는 말이 특수 프로토콜 인프라를 연상시킨다. 방송·통신 시대의 상식이 그대로 남아 있다.
- 오답 유형:
outdated
- 실제: GIF는 프레임 간 압축이 없고 256색이라 같은 구간의 H.264보다 수십 배 크기가 커지기 쉽다. 무음 MP4 루프(muted autoplay playsinline)가 모바일 웹에서 재생되고 기존 인코더를 그대로 쓰는 실무 정답이다.
- 왜 믿는가: GIF는 어디서나 열려 "안전한 기본값"으로 굳었다. 썸네일·프리뷰 예산이 전송 비용으로 이어지는 구조를 못 본다.
- 오답 유형:
outdated
- 실제: 평균 수십 초 이하의 피드형 UGC는 faststart MP4 + Range 요청이 나을 때가 많다. 세그먼트 분할은 캐시 객체 수를 폭발시켜 롱테일 미스만 키우고, 재생 시간이 짧아 렌디션 전환의 적응 가치도 희박하다. ABR은 긴 콘텐츠·화질 스위칭 요구·라이브에서 빛난다.
- 왜 믿는가: ABR이 "스트리밍의 표준"이라는 서사가 길이 분포·시청 분포 같은 조건을 덮어버린다.
- 오답 유형:
overgeneralized
- 실제: 세그먼트를 짧게 자르면 캐시 객체 수가 선형으로 늘고 요청당 과금·카디널리티가 악화된다. 멱법칙 시청 분포에서 보이지 않는 콘텐츠의 세그먼트는 1~2회 요청으로 끝나 재히트가 없다(롱테일 미스).
- 왜 믿는가: 적응 반응성만 보면 짧은 쪽이 좋아 보인다. 캐시 비용은 서빙 측 효과라 인코딩 문서에서 자주 빠진다.
- 오답 유형:
overgeneralized
- 실제: 플레이어의 전환 유연성은 4
5개 렌디션에서 체감상 포화하고, 인코딩 비용·스토리지·캐시 객체 수는 렌디션 수에 거의 선형으로 는다. UGC는 34개 렌디션이 정답인 경우가 많다(프리미엄 VOD의 7~8개 렌디션과 다름). - 왜 믿는가: 프리미엄 VOD 사업자의 공개 래더를 그대로 이식한다. 콘텐츠 성격·비용 구조가 다르다는 전제가 누락된다.
- 오답 유형:
overgeneralized
- 실제: 처리량·단가는 이기지만 같은 비트레이트에서 화질이 열세일 수 있다(세대·튜닝별). NVENC/QSV 교체는 VMAF 비교 게이트를 통과해야 하는 변경이지 단순 치환이 아니다.
- 왜 믿는가: "GPU가 빠르다"가 "GPU가 낫다"로 번역된다. 화질 회귀는 비트레이트 지표에 나타나지 않아 게이트 없이 지나간다.
- 오답 유형:
overgeneralized
- 실제: 코덱 선택은 디코딩 기기 플릿 + 인코딩 비용 + 이중 저장(캐시 객체 분열)의 교집합이다. AV1 도입은 capable 클라이언트에만 내리는 이중 렌디션으로 시작하는 마이그레이션이지 전환이 아니다.
- 왜 믿는가: 압축 효율 숫자만 놓고 보면 결론이 "전환"으로 나온다. 디코더 보급률과 이그레스 절감의 교차점은 별도 계산이다.
- 오답 유형:
overgeneralized
- 실제: 확장자와 실제 컨테이너·코덱이 다른 UGC가 흔하다. 업로드 게이트는 ffprobe로 실제 스트림(코덱·프로파일·해상도·fps·회전·오디오 유무)을 실측해야 한다. 매직바이트 확인은 컨테이너 식별까지만 유효하다.
- 왜 믿는가: 파일 시그니처·확장자가 "식별"처럼 느껴진다. 서버 사망 사고의 다수가 이 검증 부재에서 시작한다.
- 오답 유형:
overgeneralized
- 실제: HLS/DASH는 매니페스트가 언어별 자막 트랙을 가리키고 클라이언트가 고르는 구조다(EXT-X-MEDIA / AdaptationSet). 구워 넣으면 렌디션 벌이 언어 수만큼 곱해져 인코딩·저장·캐시 객체가 배수로 늘고 자막 배치·크기도 고정된다.
- 왜 믿는가: 플레이어마다 사이드카 자막 지원이 제각각이던 시절의 호환 경험이 규격 현황보다 오래 남는다.
- 오답 유형:
overgeneralized
- 실제: HLS는 자막 규격으로 WebVTT를 정의하고 DASH 생태계는 TTML/IMSC 계열을 요구한다. 원본 자막을 한 벌로 두고 파생은 텍스트 변환으로 뽑는다 — 비디오 재인코딩과 비용 차원이 다르다.
- 왜 믿는가: "텍스트는 텍스트"라는 동질성 가정. 프로토콜별 클라이언트가 요구하는 포맷이 다르다는 걸 재생 사고가 나고 나서 본다.
- 오답 유형:
overgeneralized
- 실제: 인코딩은 공유돼도 암호화는 생태계별 규격을 따른다. HLS/FairPlay 진영과 DASH 계열이 요구하는 암호 모드(cbcs vs cenc)가 갈려, 암호문 산출은 프로토콜별로 다시 패키징된다(ISO/IEC 23001-7).
- 왜 믿는가: "하나의 규격이 전부를 통일했다"는 요약이 암호화 축까지 덮는다고 읽힌다.
- 오답 유형:
overgeneralized
- 실제: 세그먼트는 반드시 키프레임에서 시작해야 하므로 실제 길이는 "지정 시간을 넘는 첫 키프레임까지"다. 키프레임 간격(GOP)을 먼저 고정하지 않으면
-hls_time 4를 줘도 8초 세그먼트가 나온다. 장면전환 감지(scnecut)가 키프레임을 흔들지 않게 끄는 것까지가 한 세트다. - 왜 믿는가: 설정값이 결과를 정한다는 직관. "4초로 나눴는데 왜 전부 8초죠?"가 실무 장애의 상투형이다.
- 오답 유형:
inverted
- 실제: 청크는 closed GOP 경계에서 잘려야 결합 지점이 살고, 모든 청크에 같은 인코딩 파라미터가 적용돼야 무손실 concat이 성립한다. 레이트 컨트롤도 청크마다 독립이 되므로 2-pass와 충돌한다.
- 왜 믿는가: "나눠서 동시에 돌린다"는 병렬화 직관이 경계 조건을 숨긴다. 결합 지점 아티팩트는 나고 나서야 보인다.
- 오답 유형:
one-step-short
- 실제: 주요 메시지 큐는 at-least-once가 본질이다(가시성 타임아웃 만료·중복 전달). "효과적으로 한 번"은 출력 키를 입력+인코딩 스펙 버전만으로 결정하는 설계와 조건부 상태 전환으로 만드는 것이지, 큐가 주는 것이 아니다.
- 왜 믿는가: 큐의 "전달 보장"을 "실행 보장"으로 읽는다. 중복 잡이 서로 다른 URL의 산출물 두 개를 만들고 나서야 발견된다.
- 오답 유형:
one-step-short
- 실제: 원본(mezzanine) 보존이 재인코딩(스펙 변경·코덱 전환)의 전제다. 렌디션은 이미 손실 재압축을 거친 결과라 원본으로 쓰면 2세대 손실이 누적된다. 안 보일 콘텐츠의 전량 사전 생성 자체도 낭비라 최소 렌디션 + lazy 생성이 실무 해법이다.
- 왜 믿는가: 파생물이 원본을 대체한다는 착시. 스토리지 절감이라는 눈앞의 숫자가 재인코딩 옵션 소실을 덮는다.
- 오답 유형:
one-step-short
- 실제: 메타데이터(moov)가 파일 끝에 있으면 재생 시작 전에 파일을 거의 끝까지 받아야 한다.
-movflags +faststart리먹스로 moov를 앞으로 옮기면 무손실·저비용으로 해결된다. 업로더가 만든 파일은 moov-at-end가 흔하다. - 왜 믿는가: 로컬 재생은 잘 되니 서빙 구조의 문제로 안 보인다. "재생이 느리다"는 CS가 CDN 대역폭으로 오진된다.
- 오답 유형:
one-step-short
- 실제: 이 파라미터들은 level이 정하는 디코딩 상한(DPB 등)과 묶여 있다. 상한을 넘으면 최신 기기는 멀쩡하고 특정 기기군만 재생에 실패한다. profile/level은 화질 축이 아니라 기기 호환 계약이다.
- 왜 믿는가: 압축 파라미터를 품질 축으로만 본다. 재생 실패가 인코딩 변경과 연결돼 보이지 않아 원인 추적이 멀어진다.
- 오답 유형:
overgeneralized
- 실제: 폰은 센서가 가로 방향으로 녹화하고 회전을 컨테이너 메타데이터로 표시하는 경우가 많다. 이를 무시하면 세로 영상이 눕거나 썸네일만 눕는다. 파이프라인은 probe에서 회전을 확인하고 정규화해야 한다.
- 왜 믿는가: 회전이 픽셀이 아니라 메타데이터라는 사실을 접할 일이 없다. 일부 처리 경로만 반영하면 "재생은 되고 썸네일만 눕는" 불일치가 생긴다.
- 오답 유형:
inverted
- 실제: ABR 렌디션 전체에서 오디오는 코덱·샘플레이트·채널이 하나의 규격으로 통일되는 것이 관례다. 렌디션마다 다르면 렌디션 전환 시 소리가 튀고, 일부 조합(44.1kHz 계열)은 기기 호환 사고로 이어진다. 무음·채널 뒤바뀜은 UGC CS의 단골이다.
- 왜 믿는가: 오디오가 비트에서 차지하는 비중이 작아 "신경 안 써도 된다"고 읽힌다. 비용은 작지만 사고는 잦은 영역이다.
- 오답 유형:
one-step-short
- 실제: 라이브는 매니페스트가 슬라이딩 윈도우로 갱신되고(미디어 시퀀스 증가·옛 세그먼트 삭제), 인코더 교체 시 불연속 표시가 필요하다. 세그먼트 주기마다 산출이 강제되므로 프리셋 선택도 그 벽시계 안으로 제한된다.
- 왜 믿는가: 같은 프로토콜을 쓰니 같은 운영이라고 상상한다. VOD 파이프라인 지식을 라이브에 그대로 이식하면 종료 처리·페일오버에서 사고가 난다.
- 오답 유형:
overgeneralized
- 실제: 첫 프레임은 검은 화면·페이드인·흔들림인 경우가 흔하다. 장면 전환 검출·선명도 점수로 후보를 뽑고 업로더가 고르게 하는 구조가 클릭률 대비 비용이 가장 좋다.
- 왜 믿는가: "영상의 시작"이 "영상의 대표"처럼 느껴진다. 피드 상품성은 썸네일이 결정하는데 그 예산이 인코딩 이야기에 밀린다.
- 오답 유형:
one-step-short
- 실제: 라이브 재생목록은 창이 밀리며 내용이 계속 바뀌는 가변 리소스다. 세그먼트는 불변이라 긴 TTL이 옳지만 재생목록은 짧은 TTL로 최신을 받게 해야 한다. 재생목록이 긴 TTL에 걸리면 엣지마다 옛 목록이 남아 시청자가 멈춘 화면에서 벗어나지 못한다.
- 왜 믿는가: "캐시는 URL 단위" 통짜 적용. 같은 URL의 내용이 시간에 따라 바뀐다는 라이브 특유의 축을 못 본다.
- 오답 유형:
inverted
- 실제: 세그먼트를 다듹게 자르면 GOP·인코딩 효율, 요청 수, 캐시 카디널리티가 함께 나빠진다. LL-HLS/LL-DASH는 세그먼트를 완성 전에 부분 단위로 공개하고(EXT-X-PART) 재생목록 요청을 서버가 갱신까지 붙잡는(blocking reload) 방식으로 지연을 줄인다.
- 왜 믿는가: 지연 ≈ 세그먼트 길이 × 버퍼 수라는 1차 근사만 들고 전송 구조를 다시 보지 않는다.
- 오답 유형:
one-step-short
- 실제: 시작 직후는 대역폭 추정 오차가 가장 크고 초기 버퍼링이 이탈로 직결된다. 실무 플레이어는 낮은 렌디션으로 시작해 버퍼가 쌓이며 올리는 보수 규칙으로 만들어지고, 처리량 기반 단독은 오버슈팅·진동을 만들어 버퍼 점유를 함께 보는 혼합 규칙(BBA 계열)이 표준이다.
- 왜 믿는가: "가진 대역폭을 다 쓰는 게 최적"이라는 자원 활용 직관. 시작 실패 비용의 비대칭을 못 본다.
- 오답 유형:
inverted
- 실제: 표준 실무는 간격을 두고 뽑은 프레임을 스프라이트 시트 한 장으로 묶고 시간-좌표 매핑을 함께 내리는 것 — 요청 1~2회로 탐색 전 구간이 커버된다. HLS는 EXT-X-I-FRAMES-ONLY 재생목록으로 탐색·트릭플레이용 I-frame 스트림을 규격화한다.
- 왜 믿는가: 이미지 서빙(필요한 것만 그때 받는다) 직관을 움직이는 미리보기에 그대로 이식한다.
- 오답 유형:
one-step-short
- 실제: CDN 측 서명 검증은 우회 가능한 앞단 계층이다(파라미터 제거 요청이 오리진까지 도달한 사고가 공개 발표로 확인돼 있다). 오리진은 자체적으로 요청 헤더로 서명을 재검증해야 다층 방어가 성립한다.
- 왜 믿는가: 엣지에서 막았다고 믿는 단일 계층 방어 착시. 이미지 서명 URL 구조를 동영상에 그대로 옮기며 오리진 재검증을 빠뜨린다.
- 오답 유형:
vendor-mixup
- 실제: 인코딩과 디코딩 능력은 비대칭이고 협상은 미디어 방향별이다. 실시간 인코딩이 안 되는 기기도 소프트웨어 디코딩은 되므로, 수신부터 신형 코덱을 적용하는 점진 전환이 성립한다(Meta RTC AV1 실측).
- 왜 믿는가: 코덱을 세션 단위 단일 선택으로 기억하고, 송수신을 한 덩어리로 본다.
- 오답 유형:
overgeneralized
- 실제: 광고를 타임라인에 꿰매는 구형 스티칭의 성질일 뿐이다. HLS Interstitials처럼 광고를 자산 목록 참조로 실으면 본편 매니페스트는 세션 공통으로 돌아가 다시 캐시 가능해진다.
- 왜 믿는가: SSAI = 세션별 매니페스트라는 등식으로 배웠고, 참조 방식의 존재를 모른다.
- 오답 유형:
overgeneralized
- 실제: 짧은 영상 연속 재생에서는 재생 전 매니페스트 순차 왕복이 지배 항이 되기도 한다. 매니페스트를 메타데이터 API 응답에 실어 로컬 주입하면 왕복 자체가 사라진다(Pinterest 실측). 세그먼트는 그대로 CDN에 남긴다.
- 왜 믿는가: 바이트가 큰 쪽이 병목이라는 직관. 왕복 수와 바이트 수를 같은 축으로 본다.
- 오답 유형:
adjacent