김민호 17회기 AI 발화 토막 — TTS 공급 붕괴와 재생 버퍼 부재 원인 분석

결론

확정 범위: 증상의 형태(화자 감지 13조각·파형 20조각), 텍스트·첫 발화 정상, 자기끊기 루프·에코·게스트 재생 장치·게스트↔LiveKit 전송 이상 징후 배제, 수정 전 Typecast 어댑터에 의도적인 선행 완충이 없었던 구조까지다. Typecast 청크 간격의 불규칙성, 실제 출력 큐 고갈, 공급이 밀린 주체는 미확정이다.

수정: PPI-1210의 c16a7159에서 Typecast PCM을 처음 1초 분량 모은 뒤 LiveKit AudioEmitter로 넘기도록 변경했다. 이는 유력 가설에 대한 방어적 완화이며, 근본 원인이 Typecast 공급 지연으로 확정됐다는 의미는 아니다.

기각된 초기 가설: "AI가 자기 목소리를 입력으로 잡아 스스로 말을 끊고 재시작하는 루프"는 성립하지 않는다. 근거는 아래 배제된 원인 절.

시간순 인과

아래는 모두 진행자·에이전트 시계 기준이다. 아동 브라우저 시계가 3.76초 느려서 두 로그를 나란히 볼 때 반드시 보정해야 한다(아래 시계 보정).

06:44:14.33  진행자가 아동 대신 60자 텍스트 전송 (소리 아님 · AI 입력)
06:44:14.36  아동 발화 종료 (user_state_changed talking=false)
06:44:14.9 ~ 15.4  AI 답변 텍스트 스트림 완료 — 1회, 완전, 반복 없음
                   "오냐, 이 할애비 이제 들었다. 그릇을 고르고, 바코드 찍고,
                    토핑 얹고, 마지막에 저울에 올려서 계산! 그렇게 하는 거구나!"
      ↓
06:44:16.43  음성 재생 시작  ← 시작 시각 정상 (1.52초 / 중앙값 1.57초)
      ↓
06:44:16.4 ~ 31.1  송출 트랙의 음성 활동 분절 관측 → 발화 13조각 · 무음 12회 · 총 5.2초
                   (파형 분석으로는 20조각)
      ↓
06:44:31.11  진행자가 '말하기 멈춤' — 세션 중 유일한 수동 개입, 이로써 종료
06:44:40.6   다음 응답(종료 멘트) 정상 발화

증상의 위치가 핵심이다. 생성과 첫 발화는 정상이었고 이상은 재생 도중에 나타났다. 다만 클라이언트 로그가 직접 보여 주는 것은 음성 활동의 분절이며, 이를 만든 공급 지연이나 버퍼 고갈은 추론이다.

관측 — 발화·무음 교대 구조

아동 로그의 AI_SPEAKING_START/STOP 26줄을 그대로 펼친 것이다(아동 시계).

같은 세션 60개 응답 중 무음 총량 1위다. 2위와도 배 이상 벌어진다.

반복 생성이 아닌 근거 — 발화 속도가 정상이다

발화 시간 합계를 글자수로 나눠 같은 캐릭터의 다른 응답과 비교했다. 같은 값이 나오면 음성 총량이 텍스트 분량과 맞는다는 뜻이고, 말을 더 만들어내지 않았다는 근거가 된다.

캐릭터마다 속도가 다르므로(아동 캐릭터는 6.4~9.6 자/초) 반드시 같은 활동끼리 비교해야 한다. 문제 응답은 할아버지 캐릭터 범위 안에 있다.

파형 근거도 같은 방향이다. 별도 파형 분석에서 "짧은 소리 20개가 서로 닮지 않음(상관 0.15)"이 나왔다. 매번 첫 음절 "오(냐)"만 나오고 잘렸다면 20개가 전부 같은 소리이므로 상관이 높게 나와야 한다. 상관 0.15는 조각들이 서로 다르다는 뜻이고, 이는 한 문장이 순서대로 토막났다는 것과 일치한다.

배제된 원인

문장 분할도 원인이 아니다

typecast_tts.py:65가 TTSCapabilities(streaming=False)를 선언하므로, LiveKit 기본 tts_node(voice/agent.py:506)가 이를 StreamAdapter로 감싸 문장 단위로 쪼개 순차 HTTP 요청한다(tts/stream_adapter.py:123). 실제 토크나이저(blingfire)에 문제 문장을 넣어 확인했다.

요청 1 (58자) "오냐, 이 할애비 이제 들었다. 그릇을 고르고, 바코드 찍고,
               토핑 얹고, 마지막에 저울에 올려서 계산!"
요청 2 (11자) "그렇게 하는 거구나!"        ← 요청 1이 끝나야 시작 (순차)

"들었다."의 마침표에서는 안 잘렸다 — blingfire가 !·?는 문장 끝으로 보고 .는 보지 않아서 첫 요청이 58자로 길어졌다.

요청이 2번이면 요청 사이의 틈은 최대 1번이다. 실제 무음은 12번이었으므로, 나머지는 전부 요청 1 하나를 받는 도중에 발생했다. 분할 방식으로는 설명되지 않는다.

수정 전 구조 — Typecast 단계의 선행 완충이 없었다

Typecast HTTP 응답은 WAV 컨테이너로 들어오고, 에이전트가 최대 4KB씩 읽어 WAV 헤더를 제거한 PCM을 AudioEmitter에 넘긴다. 4096은 Typecast가 반드시 4KB 패킷을 보낸다는 뜻이 아니라 HTTP 클라이언트의 읽기 크기다.

# apps/livekit-agent/typecast_tts.py (PPI-1210 수정 전)
async for chunk in resp.aiter_bytes(_STREAM_CHUNK_SIZE):   # 최대 4096 bytes씩 읽기
    payloads = parser.feed(chunk)                          # WAV → PCM
    for pcm in payloads:
        output_emitter.push(pcm)                           # 별도 선행 완충 없이 전달

“버퍼 0”의 정확한 의미: 전체 LiveKit 송출·브라우저 재생 계층에 버퍼가 전혀 없다는 뜻이 아니다. AudioEmitter는 PCM을 오디오 프레임으로 조립하고 이후 계층에도 큐와 지터 처리가 있다. 수정 전 typecast_tts.py가 공급 흔들림을 흡수하려고 의도적으로 확보한 추가 선행 버퍼가 0ms였다는 뜻이다.

일반적으로 네트워크와 서버 처리 때문에 스트림 도착 간격은 달라질 수 있지만, 이 사건에서 실제 청크 간격이 불규칙했다는 기록은 없다. 따라서 “공급 지연 → 큐 고갈 → 분절”은 관측 형태와 구조가 지지하는 가설이지 로그로 직접 측정된 사실이 아니다.

PPI-1210 수정 — 1초 분량의 선행 버퍼

c16a7159에서 apps/livekit-agent/typecast_tts.py에 고정 _PREBUFFER_MS = 1000을 추가했다. WAV에서 추출한 PCM을 먼저 모으고, 해당 포맷 기준 1초 분량에 도달하면 한 번에 AudioEmitter로 넘긴다. 기본 32kHz·모노·16bit에서는 64,000바이트(약 62.5KiB)다.

prebuffer.extend(pcm)
bytes_per_second = sample_rate * channels * bits_per_sample // 8

if len(prebuffer) >= bytes_per_second * 1000 // 1000:
    output_emitter.push(bytes(prebuffer))
    prebuffer_released = True

# 1초보다 짧은 음성은 스트림 종료 시 남은 PCM을 전달
if prebuffer:
    output_emitter.push(bytes(prebuffer))

검증: apps/livekit-agent/tests/test_typecast_tts.py에 500ms만 도착한 상태에서는 첫 프레임이 나오지 않고 임계 도달 후 전체 PCM이 보존되는 테스트, 100ms 단음성이 EOF에서 유실 없이 배출되는 테스트를 추가했다. Typecast 테스트 결과는 9 passed다.

판별법 — 아동 로그만으로 여기까지 가는 방법

재현되지 않는 단발 사건이라 사후 로그만으로 판정해야 했다. 다음 사례에 재사용할 순서다.

1. 반복 생성 배제 — AI_SPEAKING_START/STOP 쌍의 ON 시간 합 ÷ 전사 글자수를 같은 캐릭터 다른 응답과 비교. 같으면 음성 총량이 텍스트와 맞으므로 반복 아님.
2. 이상 응답 특정 — span − on(응답 내 무음 총량). 세션 중앙값 0.8초, 90퍼센타일 2.0초. 5초대면 확실한 이상.
3. boundary 정체 특정 — 아래 표.

agent_response_terminal_boundary는 응답당 이름별로 한 번씩만 발행되어(agent_transcript_events.py:108) 순서가 고정이다. 그런데 클라이언트가 boundary 이름과 elapsed_ms를 버리고 eventType만 기록하므로 어느 것이 무엇인지 알 수 없다. 59개 응답에서 "첫 음성 감지보다 먼저 오는 비율"을 세어 역으로 특정했다.

물리적으로 4·5번은 소리가 나기 전에 일어나야 하는 사건이고, 실제로 대부분 그렇다.

이 사건에서는 4·5번이 소리가 난 뒤에 도착했다. (5번 도착) − (첫 음성 감지)를 "보고 지연"이라 하면 세션 중앙값이 −0.28초(음성보다 먼저)인데 문제 응답은 +1.57초로 세션 최대이고, 무음 총량과 상관 r=0.59다. 에이전트가 자기 진단 이벤트조차 제때 못 쏠 만큼 밀려 있었다는 뜻이다.

다만 이것은 원인이 아니라 정황이다. 보고가 늦는다고 소리가 끊기지 않는다. 그리고 보고는 데이터 채널로, 소리 감지는 SFU 신호로 오는 다른 경로다. 데이터 채널만 늦었다면 같은 역전이 생기고 그 경우 무음의 원인은 다시 열린다. 사건 13초 뒤 진행자 취소 왕복이 32ms로 측정돼 채널 자체는 그 시점에 정상이었으나, 13초 전 상태는 알 수 없다.

시계 보정 — 두 로그를 나란히 보기 전에

아동 브라우저 시계가 3.76초 느렸다. 보정 없이 대조하면 인과가 뒤집혀 보인다.

진행자 로그  15:44:14.327  "[Host Message] Sent to guest…"   (송신)
아동  로그  15:44:10.581  "Received message from host:"     (수신)
             → 수신이 송신보다 3.75초 빠름 = 있을 수 없음 → 아동 시계가 느림

반대 방향(아동이 emit → 진행자가 수신)으로도 +3.78초가 나와 두 독립 측정이 일치한다. 진행자·에이전트 시계는 서로 맞으므로 진행자 기준으로 정렬한다.

미확정 — 왜 공급이 밀렸는가

후보 셋을 구분할 수 없다.

원인 하나로 세 관측을 모두 설명하는 것은 ③이다. 다만 ①②도 "초반 정상 → 이후 느려짐"이면 성립하고, 그 경우 보고 지연은 별개 원인이 된다. 어느 쪽도 확정이 아니다.

③의 배경으로 agent.py:294의 PPI_AGENT_LOAD_THRESHOLD = 0.99는 워커가 거의 꽉 찰 때까지 새 수업을 받는다는 뜻이라 여유가 얇게 운영된다. 다만 그 시각 실제 동시 작업 수·CPU는 확인할 수 없다.

관측 공백 — 확정을 막은 것

조치 상태와 후속 제안

외부 유사 사례 — DFRobot ESP32 I2S

DFRobot/DFR1154_Examples 이슈 #1은 네트워크에서 읽은 TTS 데이터를 I2S로 바로 쓰다가 공급이 비면 잡음·끊김이 발생한 사례로, 네트워크 입력과 고정 속도 출력을 버퍼로 분리해야 한다는 점에서 이번 수정과 원리가 같다.

증거로 사용할 수 없는 이유: 해당 이슈는 ESP32 하드웨어와 OpenAI TTS를 대상으로 하며, 작성자가 분석이 AI로 생성됐고 충분히 검토하지 못했다고 명시한다. 따라서 PPI의 근본 원인을 입증하지는 않으며, 버퍼링 설계의 유사 사례로만 참고한다.

부수 발견 — 토막나면 언어가드가 조용히 죽는다

진행자 로그에서 ai_speaking_start마다 MFCC 분석 버퍼를 폐기한다.

15:44:16.429  [MFCC] discarding 26 stale events on ai_speaking_start
15:44:17.638  [MFCC] discarding 2 stale events on ai_speaking_start
   … 이후 매 조각마다 반복 …
15:44:32.658  MFCC turn buffer uploading  turnId=…response-4
              events=2 · bytes=92 · sampleCount=0 · 범위 309ms

16초 발화에서 마지막 309ms만 남았다. 토막이 잦아질수록 언어가드 검사가 무력화되는 경로이며, 이번엔 문제가 되지 않았지만 별건으로 볼 만하다.

관련 문서

• 박승율 1회기 종료멘트 자동전환 실패 — LiveKit 완료 이벤트 누락 (같은 agent_response_terminal_boundary·agent_response_completed 계열 이벤트를 다룬다. 그쪽은 완료 이벤트 누락이 자동전환을 막은 사례이고, 이번 건은 같은 이벤트가 지연돼 정황 지표로 쓰였다는 점에서 대조된다)
• LiveKit 방 전환 레이스 — 아동 마이크·AI 오디오 무음 송출 (같은 "소리만 없고 연결은 살아 있는" 형태지만 그쪽은 완전 무음이고 이번 건은 간헐 토막이다. 그쪽 판별 지표 currentTimeAdvanced가 이번 건에서는 true로 나와 재생 경로를 배제하는 데 쓰였다)
• LiveKit 음성 에이전트 흐름과 두 SFU 구조 (에이전트 TTS 송출과 mediasoup 릴레이가 갈라지는 지점의 기반 문서)
• 아동측 미디어·세션 이상 전반 — 원인 판별용 로깅 추가 범위 (이번 관측 공백 절의 로그 제안이 그 범위의 연장선)