기술 소식 / 기술 노트
웹게임 무음 현상, 자동 재생 정책과 재생 상태의 점검
시작 버튼 뒤에는 파일 준비와 컨텍스트 재개, 소스 시작과 출력 확인이 이어진다. 각 API의 반환값과 오류를 나누고 연속 입력·복귀·안내 상태를 실제 시험 항목으로 정리한다.
기사 요약
- 파일·컨텍스트·소스·출력의 상태를 나눈다.
- play·resume·start의 결과 처리 방식은 다르다.
- 시각 안내와 음악 기준 플레이의 시작 조건을 적는다.
CAT BEAT : 비트를 깨워 · 개발 중 실제 화면
음악과 입력을 사용하는 실제 개발 화면이다. 시작 요청·출력 허용의 내부 상태는 아래 단계와 실행 기록에서 별도로 확인한다.
첫 재생 버튼이 책임질 상태를 정한다
웹 게임의 첫 소리는 파일 준비, 브라우저의 재생 허용, 소스의 시작과 출력 경로가 이어져야 들린다. Chrome 정책과 MDN 가이드는 사용자 동작과 자동 재생 조건을 설명한다. 사용자가 시작을 누른 뒤 앱이 어느 상태인지 알려 주는 설계가 필요하다.
이 글은 기존 정책과 API의 기술 해설이다. 새로운 공통 정책이 발표됐다는 소식과 구분하고 확인한 문서와 적용 질문을 정리한다.
관련 원자료: Chrome · Autoplay policy ↗ · MDN · Autoplay guide ↗
파일·컨텍스트·소스·출력을 나눠 조사한다
파일은 가져오기와 디코딩을 마쳐야 사용할 수 있다. AudioContext는 상태를 확인하고 필요한 경우 사용자 동작에서 resume()를 요청한다. 이어 버퍼 소스를 연결하고 시작을 예약한다. 마지막으로 게인과 출력 경로, 기기 음량을 확인한다.
running 상태는 컨텍스트의 동작 상태를 나타낸다. 실제 소스가 연결돼 있는지, 음량이 있는지와 출력 장치에서 들리는지는 각 단계의 확인 대상이다. suspended 상태도 발생 맥락과 직전 호출을 함께 기록해 원인을 좁힌다.
첫 소리를 조사할 자료
| 단계 | 기록 | 확인 |
|---|---|---|
| 파일 | 요청·디코딩 결과 | 사용할 버퍼 |
| 컨텍스트 | 상태·재개 결과 | 처리 가능한 상태 |
| 소스 | 노드 수·연결·시작 | 중복 없는 재생 |
| 출력 | 게인·장치·음량 | 실제로 들리는 소리 |
CAT BEAT : 비트를 깨워 · 개발 중 실제 화면
대전 UI의 조작·결과 영역을 보여 주는 화면이다. 브라우저의 첫 재생 정책은 문서와 API 결과를 근거로 설명한다.
첫 소리까지 확인하는 네 단계
편집부 작성 도표 · 파일 준비에서 기기 출력까지 역할을 나눈 자체 조사 경로.
열:파일→컨텍스트→소스→출력. 화살표=확인 순서.
작은 화면에서는 도표를 좌우로 밀어 볼 수 있다. 도표 크게 보기 ↗
도표의 값과 읽는 순서
- fetch·decode
- 상태·resume 결과
- buffer·연결·start
- gain·destination·기기
세 API의 결과를 다르게 처리한다
HTMLMediaElement.play()는 시작 시도의 Promise 결과를 처리한다. AudioContext.resume()도 재개 요청의 Promise를 처리한다. AudioBufferSourceNode.start()는 값을 반환하지 않고 한 노드에서 한 번 호출한다. 새로 시작할 때는 새 소스를 만든다.
각 호출의 성공·실패와 예외를 맡는 코드를 분리한다. 시작 버튼을 누른 순간에는 준비 중으로 알리고, 필요한 요청이 처리된 뒤 해당 상태를 표시한다. 실패하면 다시 시도할 행동을 제공한다.
관련 원자료: MDN · Autoplay guide ↗ · MDN · AudioContext.resume() ↗ · MDN · AudioBufferSourceNode.start() ↗
반환값과 재시도 책임
| API | 결과 | 처리 |
|---|---|---|
| media.play() | Promise | 이행·거부 뒤 상태 반영 |
| context.resume() | Promise | 상태·결과·출력 경로 확인 |
| source.start() | undefined·예외 가능 | 노드당 1회·재시작은 새 소스 |
연속 입력과 중단 후 복귀를 설계한다
시작 요청 처리 중에는 같은 요청이 중복돼 소스 여러 개를 만들지 않도록 관리한다. 요청 ID와 소스 수, 상태 전환 시각을 기록하면 한 번 누른 결과를 추적할 수 있다.
자체 복귀 정책의 예는 음악·노트를 함께 멈추고 파일 위치를 보관한 뒤, 준비 표시 후 새 소스 하나로 이어 가는 것이다. 실제 제품의 규칙과 지원 환경에 맞춰 선택하고, 중단 원인과 저장 위치를 남긴다.
소리가 준비되지 않은 때의 화면을 둔다
설명과 메뉴, 시각적 조작 안내는 소리 준비와 별도로 읽을 수 있게 한다. 음악을 기준으로 점수를 계산하는 플레이는 필요한 소리가 준비됐음을 확인한 뒤 시작한다. 시각 안내의 제공 범위와 채점 시작 조건을 명확히 적는다.
아래 네 상태는 실제 브라우저 화면의 캡처가 아닌 자체 UI 모형이다. 준비 중·사용자 시작 대기·재생 확인·오류에서 가능한 행동을 다르게 두었다. 오류 안내에는 바로 다시 시도하거나 설명으로 이동할 선택을 제공할 수 있다.
상태마다 다른 다음 행동을 보여 준다
편집부 작성 도표 · 실제 브라우저 캡처와 구분한 자체 UI 모형.
네 칸:준비 중·시작 대기·재생 확인·오류. 칸 크기에 수치 의미 없음.
작은 화면에서는 도표를 좌우로 밀어 볼 수 있다. 도표 크게 보기 ↗
도표의 값과 읽는 순서
- 준비 중:중복 시작 요청 관리
- 시작 대기:사용자 입력
- 재생 확인:정지·진행
- 오류:재시도·설명
실행 조건과 관찰 결과를 함께 남긴다
브라우저·버전·운영체제·출력 장치, 사용자 동작, 컨텍스트 상태와 API 결과를 기록한다. 처음 방문, 새로고침, 시작 버튼 연타, 탭 전환과 복귀를 나누어 시험한다. 식별이 필요한 범위를 정하고 개인 정보는 시험 기록에 넣지 않는다.
버튼 반응과 파일 요청·상태 전환은 자동 검사할 수 있다. 실제 출력과 음악·입력의 싱크는 기기에서 듣고 누르는 검증으로 확인한다. 검증 종류를 나누어 기록하면 첫 소리 문제를 재현하고 수정 근거를 남기기 쉽다.
출처·확인 범위
2026.10.17 Chrome 정책, MDN 자동 재생·resume·start의 반환값과 예외를 확인했다. 네 UI 상태와 복귀 정책은 자체 설계 예시다. 특정 브라우저 전체나 실기기 청감을 검증한 결과로 제시하지 않았다.