송아인 24회기 AI발화·영상오디오 “지지직”
— 아동 단말 출력 경로 오염 원인 분석 원인 미확정 · 유력가설 1건 · 수정 미적용

결론

확정이 아니다. 노이즈가 시작된 정확한 시각을 특정할 로그 신호가 없고(관측 공백), 아동 단말의 UA·기종·CPU 지문이 로그에 전혀 남지 않는다. 아래 “즉시 판별 3단”이 남아 있다.

시간순 인과 다이어그램

아동 단말(비-iOS Chromium) 세션 시작
   → 마이크 캡처 EC(AEC)+NS+AGC ON 으로 시작
   → 브라우저가 저지연 "통신 출력 경로"로 전환   [실측] outputLatency 0.06 → 0.008 (18:36:13)
   → 이 경로 위에서 앱의 모든 소리가 재생됨
        ├ AI 발화 = LiveKit remote Opus track → audioElement.srcObject (브라우저 WebRTC 디코더)
        └ 영상 오디오 = <video> 직접 재생 (비-iOS는 WebAudio/loopback 미경유)
   → 활동 스텝 전환마다 LiveKit room·PeerConnection·AudioWorklet 전량 재생성 x9
     + 매번 mic 재캡처(AEC 재초기화)   [실측] "Defer mic: applied after AEC stabilization delay" x8
   → (가설) 반복되는 캡처/AEC 세션 재개설 + 영상 디코드 + mediasoup producer 2개 부하
     → 브라우저 오디오 서비스의 통신 출력 스트림(8ms 버퍼)이 언더런/리샘플 파손 상태로 진입
   → 그 경로를 공유하는 AI 발화 + 영상 오디오가 동시에 "지지직"        [제약 1 충족]
   → 탭 리로드는 렌더러만 재생성 — 오디오 서비스/HAL 상태는 그대로     [제약 3 충족]
   → 크롬 앱 완전 종료 시에만 오디오 서비스가 죽고 스트림 재초기화 → 회복

[진행자가 들은 소리는 별개 경로다]
   ① 진행자는 같은 영상을 자기 단말에서 직접 재생 중 (volume 1, muted false) [실측]
   ② 진행자 기본 출력이 "다중 출력 기기(Aggregate)" + BlackHole 2ch          [실측]
   ③ 아동 스피커 → 아동 마이크 음향 누출 → mic-audio 업링크                  (가설)
   ④ ai-audio 업링크 = 아동이 디코드한 remote track의 clone — 출력단보다 앞에서 분기
      ⇒ 출력단 오염이면 ④는 깨끗해야 한다. 이것이 결정적 판별자다.

실측 근거

1. 아동 단말은 iPad가 아니다 사실

독립 근거 4개가 모두 같은 방향을 가리킨다. 신고에는 “크롬앱 종료 후 재시작”이라 적혔지만 단말은 비-iOS Chromium이다.

귀결: isIosFamilyDevice 게이팅(apps/web/lib/utils.ts:22-25) 때문에 이 단말에서는 영상 WebRTC loopback이 애초에 생성되지 않는다(apps/web/shared/ui/guest-layout-content.tsx:86-89 → meet-video.tsx:114에서 즉시 return). TTS 로컬 재생 모드도 blob이다(use-ai-session.ts:2857,2906). 세션 로그에 loopback 문자열이 0건인 것은 관측 공백이 아니라 실행되지 않았기 때문이다.

2. 이 세션은 Typecast(클라이언트 TTS) 경로가 아니다 사실

• 세션 로그에 tts_player_skipped 9건 — TtsPlayer가 한 번도 생성되지 않았다.
• AI 로컬 재생은 LiveKit remote track을 element에 attach: apps/web/lib/voice-agent/livekit-client-session.ts:1495 (audioTrack.attach(args.audioElement)). 로그 AI audio element health … srcKind:"srcObject" 14건.
• 모니터로 가는 AI 오디오는 그 remote track의 사본이다: livekit-client-session.ts:1515-1516 → apps/web/hooks/mediasoup/use-mediasoup-producer.ts:781-790(clone() → appData:{type:"ai-audio"}) → 모니터 수신 apps/web/hooks/client-host/use-audio-streams.ts:83-90.

따라서 “Typecast 응답 디코드 → TtsPlayer masterGain → aiAudioStream” 형태의 인과도는 이 사건에 존재하지 않는다. 실제 경로는 agent TTS(서버) → LiveKit Opus → 아동 브라우저 WebRTC 디코드 → (분기) element 재생 / clone 업링크다.

3. 출력 경로가 캡처 상태에 따라 재구성된다 사실(상관)

18:36:12  warmup                   outputLatency 0.06
18:36:13  meet-video-first-play    outputLatency 0.008   ← 이후 18:49:39까지 계속 0.008
18:53:25  STEP_TRANSITION "Muting microphone for non-AI step"
18:53:26  meet-video-first-play    outputLatency 0.062   ← mic mute 직후 복귀
sampleRate 는 13건 전부 48000 으로 불변, ctxState 는 항상 running

즉 이 단말에서는 앱 출력 버퍼/경로가 마이크 캡처·AEC 상태에 결합되어 재구성된다. AI 발화와 영상 오디오의 공통 하류 지점이 JS 노드가 아니라 브라우저/OS의 공용 출력 스트림이라는 직접 증거다. 다만 이 변화는 세션 종료 1분 전이라 노이즈 발생 트리거로 해석해서는 안 된다.

4. 18분 세션에서 오디오 체인이 9회 전량 재생성됐다 사실

18:36:40 Audio chain graph built  #1 → 18:38:35 room disconnected
18:39:25 #2 → 18:40:04    18:41:05 #3 → 18:42:42    18:44:10 #4 → 18:45:46
18:45:47 #5 → 18:48:20    18:48:21 #6 → 18:49:15    18:49:16 #7 → 18:49:39
18:50:08 #8 → 18:52:13    18:52:14 #9
동반 로그: AI_SESSION "DataChannel closed" 9건 · "Defer mic: applied after AEC stabilization delay" 8건
LiveKit 서버(Loki service_name="ppi-livekit")에는 teardown dtls timeout warn 뿐, 오디오 손상 신호 없음

부수 발견 — LiveKit 프로파일은 gate/EQ/compressor/limiter/autoGain이 전부 false라 오디오 체인이 사실상 pass-through인데도(apps/web/hooks/audio-processing-presets.ts:125-156), 그 pass-through 워클렛까지 스텝마다 9회 재생성된다. 이득 없는 부하다.

5. 녹음 합본의 클리핑 밀도가 대조군보다 뚜렷이 높다 참고 · 단독으로는 미확정

같은 날 녹음 4건을 48kHz mono float로 디코드해 동일 지표로 비교했다(|x|≥0.999 = 클리핑 샘플, 인접 샘플 점프 >0.25 = 클릭/지지직 후보).

해석 주의: 합본은 서버 amix + mp3 인코딩 이후라 AI 트랙과 마이크 트랙을 분리할 수 없다. 전체 RMS가 4~5dB 높다는 것은 “믹스가 더 컸다”는 뜻이기도 해서, 클리핑 밀도 차이가 곧 지지직의 증거는 아니다. stem 분리 청취가 필요하다.

서버측 점검 결과 — 문제 없음

“아동 단말” 결론을 내리기 전에 서버 4개 축을 전수 점검했다. 이 세션과 관련된 서버측 이상은 발견되지 않았다.

발견했으나 범인이 아닌 것 — Dropping unreadable/corrupt stem segment. 이 방에서 child stem 4개(seg11/14/17/23)가 ffprobe 실패로 믹스에서 제외됐다. 그러나 같은 날 17–22시 구간에서 다른 방들은 10~18건씩 나온다 — 이 세션은 오히려 적은 편이다. 전 세션 공통 기저 패턴이며 판별력이 없다(빈 OGG 세그먼트 분석 참고).

확인하지 못한 서버측 1건: agent가 실제로 합성한 PCM 파형의 품질. Loki service_name 라벨 목록에 ppi-livekit-agent가 존재하지 않아(alb, livekit-test, ppi-api, ppi-batch, ppi-livekit, ppi-scheduler, ppi-socket, ppi-stt, ppi-web, unknown_service) agent 프로세스 원본 로그를 조회할 수 없다. 텔레메트리는 타이밍·성공여부만 알려준다. 합성 파형이 깨졌는지는 녹음 stem 청취로만 확정된다 — 그래서 “즉시 판별 3단”의 1번이 stem이다.

배제된 원인

추정 원인

오염 트리거는 여전히 미확정이다. “무엇이 언제 출력 경로를 망가뜨렸는가”를 특정할 로그 신호가 없다. 노이즈 시작 시각조차 로그로 확정되지 않는다.

영향 범위

추천 해결책

즉시 판별 3단 코드 변경 0

1. 녹음 stem 청취 — ai-audio stem이 깨끗한데 아동만 노이즈를 들었다면 아동 단말 출력단 오염 확정. stem에도 노이즈가 있으면 출력단보다 앞(agent 합성·전송·디코드) 확정. 단일 검사로 가설 공간이 반으로 갈린다. (합본 mp3만으로는 amix 이후라 불가)
2. 진행자 기본 출력을 내장 스피커로 바꾸고 재확인 — Aggregate/BlackHole 경로를 즉시 배제 또는 확정.
3. 재발 시 아동에게 물을 것 — “AI 소리만 / 영상 소리만 / 둘 다”, 그리고 “브라우저 밖 다른 앱 소리도 지지직인가”. 브라우저 프로세스 범위인지 기기 전체 범위인지를 가르는 가장 값싼 결정적 실험이다.

앱측 조치 (우선순위 순)

회귀 위험 (사이드 이펙트)

미확인 목록

조사 방법

아동 세션 로그 11,029건(S3 prod/lesson-logs/bcd09fea…/lesson-24/archives/)을 KST 시각·ctx·role로 정렬해 복원했고, LiveKit 서버 로그는 Loki service_name="ppi-livekit"에서 userId로 방 10개를 식별해 교차 조회했다. 녹음 합본 4건(신고 1 + 대조 3)은 48kHz mono float로 디코드해 클리핑·인접샘플 점프 밀도를 동일 지표로 비교했다. 원인 분석은 developer(Codex)·reviewer(Claude Code) 2단계 교차 검토를 거쳤으며, reviewer가 developer의 전제 2개(단말이 iOS다 / Typecast 경로다)를 코드로 뒤집었다. 이 문서는 뒤집힌 쪽을 반영한 결과다.

신고 문구와 실제의 괴리: 제목의 “Typecast 기계음”과 “iPad”는 둘 다 사실과 달랐다. 증상 신고의 기술 용어를 전제로 삼지 말고 로그로 단말·런타임부터 확정할 것.

수정 미적용: 이 문서는 원인 분석과 방안 정리까지다. 코드 변경은 없다.