야스닷컴 영상 재생 오류, 증상부터 나눠서 확인해요

야스닷컴에서 멈춘 화면은 어디였나요?

2026-10-24에 이 안내 홈과 글 페이지의 HTML을 확인했어요. 영상 재생 요소인 <video>와 삽입 플레이어용 <iframe>은 둘 다 없었고, 홈의 바로가기는 외부 목록으로 연결됐어요. 이 화면의 이미지가 움직이지 않는 것과 이동한 서비스의 영상이 재생되지 않는 것은 확인할 대상이 달라요.

아래는 외부 서비스의 장애 로그가 아닌 통제 실험이에요. Windows의 Chrome 155와 로컬 HTTP 서버를 사용했어요. 직접 만든 320×180 WebM에는 VP8 영상과 무음 Opus 오디오 트랙을 넣었고, 파일 크기는 47,709바이트였어요. 같은 환경에서 재생되는 정상 표본이 비교 기준이에요.

같은 브라우저에서 세 번 비교했어요

버튼을 눌러 재생하는 조건은 유지하고 서버 응답만 바꿨어요. 정상 파일은 영상 바이트를, 없는 파일은 404를, 마지막 표본은 200 상태로 HTML 문서를 보내도록 구성했어요. 세 조건을 각각 세 번 실행했고, 성공 여부와 오류 분류는 세 번 모두 같았어요.

정상 표본의 시간은 play() 성공 뒤 약 0.7초 후 읽은 값이에요. 재생이 진행되는지 확인한 기록이며 로딩 속도의 측정값은 아니에요. 세 차례의 원기록과 응답 정보도 함께 남겼어요.

이 결과에서 얻은 판단 기준은 오류 4를 코덱 문제로 해석하기 전에 영상 응답이 도착했는지 확인하자는 거예요. 정상 표본은 같은 브라우저에서 재생됐으니, 이번 두 실패를 브라우저 전체의 재생 불능으로 설명할 수도 없었어요.

자동 재생이 거절돼도 파일은 정상일 수 있어요

사용자 조작 전 자동 재생은 별도로 한 번 확인했어요. 오디오 트랙이 있고 음소거 상태가 아닌 동일 표본에서 play()가 NotAllowedError로 거절됐지만, video.error는 null이었어요. 직접 재생 버튼을 누르자 파일을 바꾸지 않아도 재생 시간이 약 0.687초로 진행됐어요.

이 경우에는 파일 교체나 쿠키 삭제가 필요하지 않았어요. NotAllowedError는 현재 조건에서 재생 요청이 허용되지 않았다는 신호예요. 앞선 파일 실험의 NotSupportedError와 구별해야 해요. 자동으로 시작하지 않는다면 재생창 안의 버튼을 직접 눌렀을 때 달라지는지 먼저 확인해 보세요.

Chrome 공식 설명에는 사이트와의 상호작용, 데스크톱의 미디어 이용 이력 등에 따라 소리 있는 자동 재생이 허용될 수 있다고 나와요. 따라서 이 한 번의 거절이 모든 기기에서 재현된다고 보지는 않았어요. 직접 눌러도 실패한다면 서버 응답을 살펴볼 차례예요.

200은 영상 정상, 206은 실패라는 뜻일까요?

HTTP 상태는 요청에 대한 서버 응답을, 미디어 오류는 브라우저의 재생 실패 분류를 보여 줘요. 두 기록을 나란히 봐야 같은 오류 번호 뒤의 서로 다른 상황을 구별할 수 있어요.

정상 표본       HTTP 206 · Content-Type: video/webm
없는 파일       HTTP 404 · Content-Type: text/plain
HTML 응답 표본  HTTP 200 · Content-Type: text/html

정상 영상에서는 브라우저가 Range: bytes=0-로 파일 범위를 요청했고 서버가 206으로 응답했어요. 206 Partial Content는 요청한 범위의 데이터를 보내는 정상 응답이에요. 영상 요청에 206이 표시됐다는 이유만으로 다운로드 실패로 분류하면 안 돼요.

반대로 200 표본은 주소가 .webm으로 끝나도 본문은 HTML이었어요. 확장자와 상태 코드만으로 영상이 도착했다고 판단할 수 없었던 이유예요. 응답 헤더의 Content-Type과 본문을 함께 봐야 차이가 분명해졌어요.

데스크톱 Chrome에서 확인하는 순서

1. 개발자 도구의 Network를 열어 둔 뒤 재생 버튼을 한 번 눌러요.
2. 실패한 미디어 요청의 Status와 Headers를 확인해요. HTML 페이지 자체의 200 응답과 구별해요.
3. Response나 Preview에 HTML 안내문이 보인다면 그 내용을 기록해요. 영상 데이터 자체를 복사할 필요는 없어요.

이번에는 단일 WebM 파일을 썼어요. 재생 목록과 여러 조각을 받는 스트리밍 플레이어에서는 어느 요청이 실패했는지 별도로 구분해야 해요.

미디어 오류 1~4는 원인 확정표가 아니에요

MDN의 MediaError.code 구분은 아래와 같아요. 직접 재현한 숫자는 4이며, 1·2·3은 문서의 정의를 정리했어요.

• 1 · 중단: 사용자 요청으로 미디어 가져오기가 중단된 경우예요.
• 2 · 네트워크: 사용 가능했던 미디어를 가져오는 과정에 네트워크 오류가 생긴 경우예요.
• 3 · 디코딩: 사용 가능하다고 판단한 미디어를 해독하다 문제가 생긴 경우예요.
• 4 · 소스 사용 불가: 주어진 미디어 소스를 사용할 수 없는 경우예요. 이번에는 404와 HTML 응답이 모두 여기에 들어갔어요.

4만 보고 “코덱을 지원하지 않는다”거나 “영상이 삭제됐다”고 확정할 수는 없어요. 서버 응답, 오류 문구, 정상 비교 표본이 함께 있어야 추측을 줄일 수 있어요. 다른 브라우저에서도 번호나 문구가 같을 것이라고 단정하지 않았어요.

내 상황에는 이 순서로 적용해 보세요

1. 직접 누르면 재생돼요: 자동 시작 조건부터 확인해요. 이때 전체 쿠키나 기기 설정부터 초기화할 이유는 약해요.
2. 눌러도 안 되고 미디어 요청이 404예요: 요청한 파일을 받지 못한 기록을 남겨요. 코덱 교체보다 제공 쪽의 해당 파일 상태를 확인하는 데 도움이 돼요.
3. 200인데 응답이 HTML이에요: 표시된 안내문을 읽어 봐요. 정상 상태 코드와 영상 파일의 정상 전달을 구별해요.
4. 영상 응답은 왔는데 계속 실패해요: 같은 영상·같은 연결에서 다른 브라우저와 비교해요. 여러 조건을 한꺼번에 바꾸면 달라진 이유를 짚기 어려워요.

문의할 때는 수동 재생 결과 → HTTP 상태 → 응답 종류 → 오류 문구 → 발생 시각을 적으면 상황이 분명해져요. 계정 정보나 인증 토큰이 들어간 전체 요청 주소를 공개할 필요는 없어요.

모바일 Safari, 확장 프로그램 충돌, 실제 서비스의 전송 성능은 이번에 검증하지 않았어요. 우리가 확인한 범위에서는 설정을 바꾸기 전에 실패가 발생한 단계를 찾는 것이 먼저였어요. 같은 오류 번호에도 다른 원인이 들어갈 수 있다는 점이 가장 실용적인 결론이었어요.