3아동 수업 시작 소리 안 들림 — 원인 분석 로그 근거 판별

마지막 업데이트 2026-07-27

📅 분석일 2026-07-27 📱 iPhone Chrome · Android Chrome · Windows Chrome 🔊 범위: 핑퐁이 및 영상 오디오

결론 요약

세 사례 모두 음원 다운로드·생성·디코딩 실패로 볼 근거는 없다. 앱 내부에서는 재생 시간과 오디오 신호가 진행됐지만, 실제 청취 단계에서 서로 다른 문제가 발생했다. 김태희는 iOS 출력 loopback 라우팅 실패, 윤단우는 탭 백그라운드 전환에 따른 영상 정지, 이진서는 Windows 기본 출력의 Bluetooth 전환이 핵심 원인이다.

아동·환경	핵심 원인	대표 근거	확신도
김태희 iPhone Chrome	iOS 출력 sink/WebRTC loopback 불안정	`setSinkId` 사용자 제스처 오류, source RMS 존재·remote RMS 0, loopback 연결 실패 반복	높음
윤단우 Android Chrome	탭 백그라운드 전환 후 미디어 정지	`isVisible:false` 직후 영상이 7.999초에 고정되고 pause/recovery 반복	매우 높음
이진서 Windows Chrome	기본 출력이 Bluetooth SRS-X11로 전환	입장 시 Realtek, 이후 기본값이 `SRS-X11 Stereo (Bluetooth)`; 앱 재생·디코딩 정상	높음

공통으로 배제되는 원인

카메라·마이크 권한 거부가 아니다. 세 기기 모두 권한 및 장치 열거가 정상이다.
영상 파일 로드 실패가 아니다. 영상 metadata/canplay/play 이벤트가 발생했고 재생 준비 상태도 정상이다.
TTS 생성 실패가 아니다. 응답 수신, 오디오 디코딩, playback start와 재생 시간 증가가 확인된다.
서버가 음성을 전혀 만들지 못한 공통 장애가 아니다. 사례별 실패 지점이 출력 라우팅·브라우저 상태·OS 기본 장치로 갈린다.

주의: AUDIO_PROBE suspectedSilent:false는 AudioContext 시간이 진행된다는 뜻이지, 사용자가 실제로 선택된 물리 스피커에서 소리를 들었다는 보장은 아니다.

1. 김태희 — iPhone Chrome

관찰 타임라인

09:31:15.491 video setSinkId failed — A user gesture is required

09:31:19.153 Audio warmed up via user gesture

09:31:20.073 첫 영상 play, muted=false, readyState=4

09:31:22.074 영상 currentTime 증가, audioTrackCount=1

09:31:23.009 sourceRms=0.0288, remoteRms=0

09:31:23.010 loopback lost — silent-remote-stream

09:31:34.498 이후 receiver-connection-failed 반복

09:31:36.548 첫 “소리가 안 들려요” 신고

판정

영상 소스에는 오디오가 있었지만 WebRTC loopback의 수신 측은 무음이었다. 동시에 iOS가 출력 sink 적용을 사용자 제스처 제한으로 거부했고, 이후 영상 및 TTS loopback 연결도 반복해서 끊겼다. 따라서 서버나 콘텐츠가 아니라 iPhone의 출력 sink/loopback 경로에서 소리가 유실된 것이 가장 유력하다.

로그의 probe는 매번 실행 상태로 복구됐으므로 iPhone 물리 볼륨이나 무음 모드 자체는 확정할 수 없다. 다만 source 신호 존재와 remote 신호 0은 애플리케이션 loopback 실패를 직접 지시한다.

2. 윤단우 — Android Chrome

관찰 타임라인

09:00:19.759 오프닝 영상 play, visibility=visible, muted=false

09:00:21.760 currentTime=1.936, audioDecodedByteDelta=33031

09:00:27.816 탭 상태 isVisible=false

09:00:27.820 영상 pause, currentTime=7.994, visibility=hidden

09:00:29 이후 play 복구 직후 다시 pause, 7.999초에 고정

09:02:48.345 “소리가 안 들려요” 신고

판정

오디오 출력과 영상 디코딩은 시작 후 약 8초까지 정상이다. 탭이 숨김 상태로 바뀐 순간 Android Chrome이 영상을 정지했고, 애플리케이션의 즉시 재생 복구는 브라우저 정책에 의해 계속 다시 정지됐다. 소리만 별도로 고장 난 것이 아니라 백그라운드 탭에서 영상과 오디오가 함께 멈춘 사례다.

탭이 숨겨진 이유가 사용자 앱 전환, 화면 잠금, 시스템 UI 진입 중 무엇인지는 로그만으로 구분할 수 없다. 그러나 visibilityState:hidden과 정지 시점의 인과는 명확하다.

3. 이진서 — Windows Chrome

관찰 타임라인

입장 단계 기본 출력: 스피커(Realtek High Definition Audio)

07:00:13.290 첫 영상 play, muted=false, visibility=visible

07:00:15.291 audioDecodedByteDelta=32777, currentTime 정상 증가

07:00:42 이후 TTS playback 및 audio output health 정상 반복

07:03:42.116 기본 출력 목록 최상단이 SRS-X11 Stereo (Bluetooth)

이후 Bluetooth Hands-Free·Stereo와 Realtek이 동시에 존재

판정

Chrome 내부에서는 영상과 TTS가 디코딩·재생됐고 AudioContext와 재생 시간이 계속 진행됐다. 반면 Windows의 기본 출력 대상은 입장 당시 Realtek에서 Bluetooth SRS-X11으로 바뀌었다. 애플리케이션이 default 장치를 따르므로 소리는 정상 생성됐지만 사용자가 기대한 내장 스피커가 아닌 Bluetooth 장치로 출력된 것이 가장 유력하다.

로그에는 Bluetooth 스피커의 실제 전원·착용·청취 상태가 없다. 따라서 “Bluetooth 출력 전환”은 확정되지만 사용자가 못 들은 마지막 물리적 이유는 정황 판정이다.

운영 판별 체크리스트

영상 시간이 멈췄는지 확인: currentTime 고정과 visibilityState:hidden이면 백그라운드 정지를 우선 판정한다.
출력 장치 라벨 확인: Windows에서 기본값이 Bluetooth·HDMI 장치로 바뀌었는지 확인한다.
소스와 loopback 신호 비교: sourceRms > 0인데 remoteRms = 0이면 loopback 전달 실패다.
sink 적용 오류 확인: iOS의 A user gesture is required와 연결 실패가 같이 나오면 출력 라우팅 문제로 분류한다.
probe를 과신하지 않기: probe 정상은 브라우저 내부 클럭 정상이지 물리 스피커 청취 보장이 아니다.

최종 핵심 원인

김태희	iOS 사용자 제스처 제한과 WebRTC loopback 수신 무음/연결 실패가 겹친 출력 라우팅 장애
윤단우	수업 시작 약 8초 후 Chrome 탭이 백그라운드로 전환되어 영상·오디오가 정지
이진서	Windows 기본 출력이 내장 Realtek에서 Bluetooth SRS-X11으로 전환

분석 자료: 김태희 iPhone Chrome, 윤단우 Android Chrome, 이진서 Windows Chrome 클라이언트 로그 export. 개인정보 보호를 위해 로컬 경로와 세션·사용자 식별자는 기재하지 않았다.