PPI-1167 — 사라진 '듣기 ON' 사건 원인 확정 수정 완료 QA 대기

결론 — 범인부터 공개한다

기능의 대표 시나리오(진행자 부재)만 확인하면 통과하는 형태의 결함이었다. fallback은 별도 축이라 정상이었고, 깨진 것은 진행자가 있는 일반 수업의 듣기 복원이다.

사건의 재구성 — 6컷

수사 일지 ① — 사건 발생과 신고

용의자 선상 — 의도(configured)의 이중 장부

수사망은 곧 한 가지 구조적 사실로 좁혀졌다. 진행자의 '듣기' 의도가 코드베이스에 두 곳 존재한다:

그리고 1167의 변경 지점이 정확히 이 갈림길 위에 있었다:

- toggleMicrophone(true);      // 무조건 ON — 사본이 false여도 강제로 true로 만들며 켜짐
+ applyDeferredListening();    // 자기 사본을 읽어 판정 → false면 no-op

축 분리(configured / fallback) 자체는 옳았다. 죄목은 읽도록 만들면서 세션 재시작 후 그 값을 채워줄 경로를 만들지 않은 것이다. 이전 코드는 값을 읽지 않았으므로 사본이 stale이어도 무해했고 — 그래서 이 이중 장부 구조는 오래 방치될 수 있었다.

결정적 단서 — 재현 로그의 서명

재현 로그를 시간순으로 복원하자 범행의 전모가 드러났다. 웹툰 6컷이 그대로 이 타임라인이다:

[19.084] 진행자 '듣기 ON'  — 아동은 full:video 스텝                     ← 컷 1
   ├─ page-session microphoneEnabledRef = true          configured 진짜 SSOT
   └─ "Blocked microphone enable during non-AI step"
        setAgentListeningEnabled 호출 안 함
        → ai-session isMicrophoneEnabledRef = false 유지   [사본 어긋남 시작]
              |
[36.276] 영상 → AI 활동 전환                                            ← 컷 2
   └─ "Listening fallback synced" presence="present", shouldActivate=false
        → 진행자 부재 fallback 아님. 순수 configured 경로
              |
[36.279] "Stopping session for new activity" → "Session stopped"
   └─ stopSession 이 isMicrophoneEnabledRef = false 로 강제 리셋
      (use-ai-session.ts:2186 — 활동 전환마다 무조건)
              |
[36.896] 새 세션 시작                                                   ← 컷 3
   └─ hasListeningIntent() 는 page ref(true)를 보고 통과 → 예약 성립
        "Defer mic: will apply after first AI response or fallback"
              |
[39.073] 첫 AI 발화 → AEC 안정화 300ms 대기
              |
[39.370] "Defer mic: applied after AEC stabilization delay"             ← 컷 4
   └─ applyDeferredListening():
        isMicrophoneEnabledRef  = false   (리셋된 stale 사본)
        listeningFallbackActive = false   (진행자 present)
        → 두 분기 모두 빠져나가 no-op
              |
   "Agent listening enabled" 로그 없음 = 듣기 실제로 안 켜짐   [증상]      ← 컷 5

왜 no-op이 곧 OFF인가 — 단 한 번의 기회

세션 시작 시 트랙 초기값도 resolveListeningIntent() = configured(false) || fallback(false) = 닫힘이다. AEC 피드백 방지를 위해 일부러 닫고 출발하므로 예약 적용이 유일한 개방 기회이고, 그 한 번이 no-op이면 해당 스텝 내내 닫힌 채 남는다.

범행 경로 — 사본이 false로 리셋되는 길 3개

검거 — 예약 쪽지에 값을 동봉한다

하위 훅(use-ai-session)은 상위(use-guest-page-session)를 import하지 않아 SSOT를 직접 읽을 수 없다. 그래서 상위가 예약 시점에 값을 인자로 내려보내는 통로를 만들었다 (컷 6).

// 상위 (use-step-transition, restartCurrentSession)
scheduleMicOnAfterFirstResponse({ configuredIntent: !!microphoneEnabledRef.current })

// 하위 (use-ai-session)
pendingConfiguredListeningRef.current = options?.configuredIntent ?? isMicrophoneEnabledRef.current;

// 적용
const configuredIntent = pendingConfiguredListeningRef.current || isMicrophoneEnabledRef.current;
if (configuredIntent) { toggleMicrophone(true); return; }          // 모니터 동기화까지 복구
if (listeningFallbackActiveRef.current) applyListeningIntent(...);  // fallback은 gate만

• 적용 시점의 || isMicrophoneEnabledRef.current는 백스톱 — 예약~적용 사이 진행자가 ON 했는데 mediaStream이 아직 없어 "intent stored"만 남은 좁은 창을 건진다.
• 예약 취소(cancelPendingMicTimers)·세션 종료 시 스냅샷도 정리. 진행자 OFF는 취소 경로가 존중한다.
• 예약 로그에 configuredIntent 필드를 추가해 동일 증상을 로그만으로 판별 가능하게 했다.

수사 일지 ② — 여죄: 늦게 도착한 옛 편지 (presence snapshot race)

게스트 requestMonitorPresence 발신
   → 진행자 입장 push (revision 7, present) 먼저 적용
   → 지연된 snapshot 응답 (revision 6, absent) 나중 도착 → 무조건 덮어씀
   → presence 가 absent 로 되돌아감

수정: source 구분 없이 revision <= applied면 드롭. 드롭 시 Monitor presence ignored (stale revision) 로그를 남긴다(이 race는 로그 없이 사후 판별 불가). 유효 응답 도착 시 재시도 예산은 staleness 판정과 무관하게 리셋.

함께 넣은 방어 — 재연결 시 revision baseline 리셋. Redis 재기동·키 유실로 서버 revision이 1부터 다시 시작하면 이전 연결의 큰 revision 때문에 이후 presence가 전부 stale로 버려져 진행자 판정이 얼어붙는다. 이 구멍은 snapshot의 무조건 덮어쓰기에 가려져 있었을 뿐 push에는 원래 존재했다. JOIN_ROOM 하이드레이션 push가 새 공간을 다시 채운다.

수사 일지 ③ — 수사관의 오판: snapshot revision 캡처 순서

getRoomMonitorPresenceSnapshot() 기존 순서
  ① presence 계산 → (이 사이 publish 가 revision 을 7로 올림) → ② currentRevision 읽기 = 7
  응답 = { 진행자 없음(낡음), revision 7(최신) }

이 응답이 진짜 push 보다 먼저 도착하면
  snapshot {없음, 7} 적용 → push {있음, 7} 은 7 <= 7 이라 무시
  → 낡은 상태가 최신 revision 으로 고정

수정: currentRevision()을 presence 계산 앞으로 이동. 불변식이 뒤집힌다.

"push 유실 후 복구 경로가 막힌다"는 초기 우려도 성립하지 않는다. push를 놓쳤다면 게스트 revision이 서버보다 뒤처져 있어, 선-읽은 revision도 게스트 값보다 크고 정상 적용된다. 이 순서 의존성은 클라이언트 주석에도 명시해 한쪽만 바뀌는 것을 막았다.

사건이 남긴 것 — 구조적 교훈

• 읽기를 도입하면 공급자도 같이 만들어야 한다. 1167은 판정을 하위로 내리면서 데이터 경로를 만들지 않아 구조적으로 미완성이었다.
• 대표 시나리오만 검증하면 사이드 이펙트를 놓친다. 부재 케이스는 정상, 진행자 있음 케이스가 파손 — 기능 검증으로는 안 잡힌다.
• 이중 소스 구조는 그대로 남아 있다. 근본 정리는 비-AI 스텝 차단을 fallback처럼 별도 gate로 만들어 effective = (configured || fallback) && !nonAiStepBlocked로 통일하고 stopSession이 configured를 건드리지 않게 하는 것. PPI-907 방어와 얽혀 revert 직후 동시 수행은 위험하므로 별도 티켓 권장.

검증 상태

관련 파일

• 원본 분석 문서 (현행 포맷) — 이 파일럿과 비교용
• 텍스팅 수업 진행자 부재 시 AI 듣기 OFF — 원인 및 monitor presence fallback 설계 (원본 설계 문서)
• 호스트 모니터링 claim / 그룹 모니터링 — 코드레벨 동작 흐름