PPI-1233 영상 스텝 중 AI 발화 출력 — LiveKit response_created 미연결 원인 분석 및 수정수정 로컬 적용

요약

보상전환영상 재생 4.2초 지점부터 약 6초간 티키 발화가 영상 위로 겹쳐 출력된 사례. 스텝 전환·마이크 차단·인터럽트는 모두 정상 동작했고, 뚫린 곳은 "차단 상태에서 새로 시작된 agent 응답을 취소하는 경로" 하나였다.

신규 정책이 아니라 런타임 간 동작 불일치다. Realtime·TTS 모드에는 원래 이 차단이 있었고(각각 다른 메커니즘으로), LiveKit 전환 과정에서 둘 다 무력화됐다.

관측 — 시간순 인과 체인

기준 t=0은 게스트 Video play event fired(ts 1787640525347). 세션 로그 14,750줄에서 재구성.

-1.57s  티키 response-1 종료 ("자 오늘 배운 내용 꼭 기억해줘! …")
   ↓
-0.73s  아동이 발화 꼬리에 겹쳐 말 시작  AI_SESSION | Child speech started  (turn-1)
   ↓
-0.55s  auto-finish 매칭 → goToNextStep → 6/1 보상전환영상 (full:video)
        Preparing full video auto-transition lock / Response blocked state changed {blocked:true}
   ↓
-0.53s  Muting microphone for non-AI step / Cancelling AI response on non-AI step entry
-0.52s  ~ +0.08s  manual_interrupt 3회 요청·완료 (host_cancel_ai_response)
   ↓
 0.00s  영상 재생 시작 (duration 29.141s)
   ↓
+0.32s  agent: user_turn_terminalization_scheduled
+0.33s  agent: user_turn_pending_started   ← 아동 턴이 interrupt 이후에도 생존
   ↓
+2.22s  agent: on_user_turn_completed_trace ×3  →  +2.22s user_turn_dropped
   ↓
+2.57s  agent_response_started (response-2)   ← 차단 실패 지점
        클라이언트: "Assistant transcript delta ignored during video transition" ×수십
+2.84s  terminal_boundary tts_provider_stream_started
+3.30s  terminal_boundary tts_provider_first_pcm
   ↓
+4.16s ~ +10.04s  AI_SPEAKING_START / STOP ×3  =  영상 위 약 6초 발화
        avatarState=talking 이 진행자 모니터로 전파
   ↓
+29.11s 영상 종료 → 다음 활동(7/0 토론소개)으로 정상 전환

원인 — 런타임 3종 비교

차단 정책은 use-step-transition.ts가 비-AI 스텝 진입 시 setResponseBlocked(true)로 켠다. 그 뒤 실제로 오디오를 막는 방식이 런타임마다 다르다.

코드 근거

① 방어는 원래 있었고 의도도 명시돼 있다

apps/web/entities/guest-page-session/model/use-step-transition.ts:186 주석이 정책과 그 역사(PPI-907 revert 사유)를 그대로 적어 두었다.

// 응답 차단 모드 ON: 이후 server_vad가 자동 생성하는 response.created를
// 핸들러에서 즉시 cancel하고 audio element 자동 unmute를 막는다.
// cancelResponse만으로는 사용자 발화 중(speech_started) 진입 시 미래 response를
// 막지 못해 영상/이미지 위로 AI 발화가 흐르는 회귀가 있었다 (PPI-907 revert 사유).
aiSessionRef.current.setResponseBlocked?.(true);

② 소비자 쪽 방어 (실행되지 않았다)

apps/web/entities/guest-session/model/use-ai-session.ts:4281

case "response_created":
  if (responseBlockedRef.current) {
    logger.info("Cancelling response.created during non-AI step block", { … });
    cancelResponseRef.current?.({ skipTruncate: true });   // ← LiveKit에서 도달 불가
    break;
  }

③ 이벤트가 버려지던 지점

apps/web/lib/voice-agent/livekit-client-session.ts의 liveKitDataToVoiceSessionEvent. agent_response_started는 isAgentVoiceEventType 목록에는 있어 신뢰 검사는 통과하지만, 매퍼에 분기가 없어 함수 끝의 return null로 떨어졌다. session-events.ts:278의 response_created 생성은 OpenAI response.created 전용이다.

수정 — 2곳 (동작 변경) + 3곳 (헬퍼·테스트·로그)

① 매퍼에 분기 신설 핵심

livekit-client-session.ts:642 — agent_response_started를 response_created로 정규화한다. agent_response_id·source_user_turn_id는 있을 때만 실어 보낸다.

if (event.type === "agent_response_started") {
  const responseId = stringField(event, "agent_response_id");
  const sourceUserTurnId = stringField(event, "source_user_turn_id");
  return {
    type: "response_created",
    source: "livekit",
    conversationRuntime: "livekit",
    ...(responseId ? { conversationItemId: responseId, responseId } : {}),
    ...(sourceUserTurnId ? { previousConversationItemId: sourceUserTurnId } : {}),
    ...(lifecycleTrace ? { lifecycleTrace } : {}),
    raw: event,
  };
}

agent_response_id가 없어도 이벤트를 버리지 않는 것이 중요하다 — 차단 판정은 응답 id에 의존하지 않으므로, id 없는 이벤트를 매퍼가 버리면 차단이 다시 뚫린다. 이 경로를 별도 테스트로 고정했다.

② pending 부기를 realtime 계열로 한정

// session-events.ts — 순수 헬퍼로 분리(테스트 가능 + 이유를 코드에 기록)
export function shouldTrackResponsePending(source: VoiceSessionEventSource): boolean {
  return source !== "livekit";
}

// use-ai-session.ts:4295 — 차단 검사는 그대로 타고, 부기만 건너뛴다
if (!shouldTrackResponsePending(event.source)) break;
setIsResponsePending(true);

③ 차단 로그에 런타임 소스 기록

로그 문구가 response.created(OpenAI 용어)여서 어느 런타임에서 취소됐는지 구분되지 않았다. payload에 source를 추가해 운영 로그에서 이번 수정의 동작 여부를 판별할 축을 만들었다.

검증

재사용할 판별법

남은 범위 · 미확정

• 취소는 응답 시작 후 — 완전 차단은 agent 쪽에 agent.setResponseBlocked RPC를 추가해 _response_block_reason에 사유를 넣고 StopResponse()로 떨어뜨리는 방식이다(agent.py:1576, 기존 RPC 4종과 동일 패턴). LLM·TTS가 아예 돌지 않으므로 오디오가 생성되지 않는다. 이번 범위 밖.
• 릴레이 게이팅 미포함 — 취소 전에 새어나간 오디오는 여전히 진행자·녹음에 들어갈 수 있다. ai-audio producer pause() 또는 소스 트랙 enabled=false가 후보이나, 이 트랙은 LiveKit 원격 트랙의 clone이라 과거 clone 무음·스톨 이슈 재발 여부를 실기기로 확인해야 한다.
• 부수 발견 (미확정) — agent가 turn-1을 user_turn_dropped(+2.22s)로 떨궜는데도 350ms 뒤 response-2가 시작됐다. on_user_turn_completed_trace가 드롭 마커보다 먼저 찍혀 있어 판정 시점에 드롭 사유가 아직 기록되지 않은 경합으로 보이지만, 클라이언트 로그에 publish_decision이 실리지 않아 확정하지 못했다. agent 로그(Grafana service=ppi-livekit-agent) 대조 필요. 위의 RPC 방식은 세션 레벨 플래그라 이 경합을 우회한다.

관련 문서