자동 재생은 실패, 직접 누르면 성공: 같은 영상의 다섯 조건

파일은 그대로 두고 시작 조건을 바꿨습니다

Windows에 설치된 Chrome 155.0.8059.85와 Edge 156.0.4314.42를 자동화된 headless 모드로 실행했습니다. 색상 격자가 움직이는 약 6초의 640×360 WebM을 직접 만들었습니다. VP8 영상과 무음 Opus 오디오 트랙이 들어 있으며, 파일 크기는 355,284바이트입니다. 무음 트랙이 있다는 것과 플레이어의 muted 속성을 켰다는 것은 구분했습니다.

매번 캐시와 사이트 이용 이력이 없는 새 임시 환경을 만들었습니다. 정상 응답을 유지한 채 ① 음소거 속성 없이 자동 시작, ② muted를 켠 자동 시작, ③ 재생 버튼 클릭을 비교했습니다. 이어서 클릭 조건은 유지하고 서버 응답만 ④ HTML 문서, ⑤ 403 거절 응답으로 바꿨습니다. 브라우저마다 다섯 조건을 세 번씩, 총 30회 확인했습니다.

자동 시작은 페이지 스크립트가 사용자 동작 없이 play()를 호출하도록 했고, 클릭 조건은 실제 버튼 클릭 이벤트를 자동화했습니다. 자동 재생 허용 정책을 강제로 바꾸는 옵션은 사용하지 않았습니다. 파일 전송은 로컬 HTTP였으며 외부 서비스의 장애를 재현했다고 주장하지 않습니다.

자동 시작만 실패한 정상 파일과, 클릭해도 실패한 응답

표를 좌우로 밀면 나머지 열을 볼 수 있습니다.

두 브라우저에서 성공한 12회는 재생 요청이 완료된 뒤 약 700ms 후 읽은 영상 시간이 0.665~0.700초로 진행됐습니다. 이 숫자는 재생이 움직였다는 확인값입니다. 초기 로딩 시간이나 회선 속도 측정값으로 쓰지 않았습니다.

가장 중요한 차이는 오류가 발생한 단계였습니다. 정상 파일의 자동 시작 실패는 재생 요청의 허용 문제였고, HTML·403 표본에서는 사용 가능한 영상 응답을 얻지 못했습니다. ‘실패했다’는 한 문장으로 묶으면 필요한 다음 조치가 사라집니다.

NotAllowedError를 보고 코덱부터 바꾸면 순서가 어긋납니다

음소거 없는 자동 시작 6회에서는 play()가 NotAllowedError로 거절됐지만 video.error는 null이었습니다. 같은 파일의 버튼 클릭 조건 6회가 모두 성공했으므로, 이번 자동 시작 실패를 파일 자체의 재생 불능으로 설명할 근거는 없었습니다.

Chrome 공식 문서는 음소거 여부와 사용자의 사이트 상호작용, 데스크톱 미디어 이용 이력 등이 자동 재생 허용에 영향을 준다고 설명합니다. 따라서 자주 쓰던 창에서는 재생되다가 새 환경에서는 멈추는 차이가 생길 수 있습니다. 이번 결과를 ‘모든 브라우저는 소리가 있으면 무조건 차단한다’로 확대하면 안 됩니다.

사용자 입장에서는 플레이어 안의 재생 버튼을 한 번 직접 눌렀을 때 달라지는지가 먼저 볼 차이입니다. 이 조건에서 정상 재생된다면 영상 교체나 전체 쿠키 삭제부터 시작할 이유가 약해집니다. 직접 눌러도 실패하면 다음 응답 기록으로 넘어갑니다.

HTTP 200인데 오류 4, HTTP 206인데 정상 재생

정상 파일을 받을 때 브라우저는 Range: bytes=0-를 요청했고 서버는 206과 video/webm으로 응답했습니다. 206은 요청한 데이터 범위를 전달한 정상 응답입니다. 숫자가 200이 아니라는 이유로 영상 문제로 분류하면 정상 표본부터 잘못 판단하게 됩니다.

정상 파일: 206 · video/webm · 재생 버튼 클릭 → 성공
HTML 문서: 200 · text/html  · 재생 버튼 클릭 → 오류 4
거절 응답: 403 · text/plain · 재생 버튼 클릭 → 오류 4

HTML 표본은 응답 상태가 200이어도 내용은 영상이 아니었습니다. 영상 주소를 요청했는데 로그인 화면이나 안내 문서가 돌아오는 상황과 구별할 때 쓸 수 있는 비교 조건입니다. 반면 이번 403은 실험 서버가 의도적으로 거절한 응답입니다. 실제 서비스의 403이 만료, 권한, 지역, 요청 규칙 중 무엇 때문인지는 이 숫자만으로 확정할 수 없습니다.

두 실패 모두 MediaError.code = 4였지만 HTTP 상태와 본문 종류는 달랐습니다. 오류 4는 상세 원인 하나를 지목하는 표시가 아니었습니다. 어떤 응답이 영상 대신 도착했는지가 다음 확인을 결정했습니다.

네트워크 기록을 볼 수 있다면

1. 개발자 도구의 Network를 연 뒤 재생을 한 번 시도합니다.
2. 페이지 문서가 아니라 영상 요청을 선택합니다. 미디어가 여러 조각으로 나뉘는 서비스라면 실패한 조각이나 재생 목록도 구별해야 합니다.
3. Status와 Content-Type을 함께 봅니다. text/html이면 Response에 실제로 어떤 안내문이 왔는지 확인합니다.
4. 영상 응답을 받았는데도 실패한다면 오류 이름과 브라우저 버전을 남깁니다. 이 단계부터 디코딩, 파일 형식 등 다른 가설을 비교할 수 있습니다.

한 번에 한 조건만 바꾸는 판단표

표를 좌우로 밀면 나머지 열을 볼 수 있습니다.

도움을 요청할 때는 ‘안 돼요’ 대신 직접 클릭한 결과 / 오류 문구 / 미디어 응답 상태 / 브라우저 버전 / 발생 시각을 묶어 남기면 다음 비교가 쉬워집니다. 로그인 토큰이 붙은 전체 영상 URL이나 쿠키 값까지 공개할 필요는 없습니다. 도움말의 기록 예시를 사용할 수 있습니다.

무엇을 확인했고, 어디까지 다시 확인해야 하나요?

이번에는 동일 파일의 재생 조건과 응답 종류를 분리했습니다. 자동 시작 거절과 파일 사용 실패가 다른 기록을 남긴다는 점을 두 데스크톱 브라우저에서 반복 확인했습니다. 두 브라우저는 모두 Chromium 계열이므로, 엔진이 전혀 다른 브라우저까지 확인한 결과는 아닙니다.

iPhone Safari, Android 실기기, DRM, HLS·DASH 스트리밍, 확장 프로그램 충돌, 실제 서비스의 계정·지역 정책은 시험하지 않았습니다. 자동화 환경과 평소 사용하는 프로필의 이용 이력도 다를 수 있습니다. 이 표는 원인을 좁히는 비교 자료이며 모든 재생 장애의 해결 보장은 아닙니다.

재현하려면 같은 WebM을 일반 video 요소에 넣고 음소거 속성과 시작 방법만 먼저 바꿉니다. 그다음 재생 버튼 조건은 유지한 채 서버가 보내는 상태·본문을 바꿔 비교합니다. 환경, 반복 횟수, 응답 헤더와 재생 결과를 함께 남겨야 다른 결과가 나왔을 때도 이유를 검토할 수 있습니다.

사용한 합성 영상과 전체 원기록을 제공합니다. JSON의 playback 항목 30개가 이 글의 근거이며, preload 항목 18개는 재생 전 데이터 사용 실험에 해당합니다.