누적시간 회귀 03:49 → 02:29 — 재현 경로 파악 과정

입력은 이미 작성된 원인 분석 문서 + "이 이슈 발생 재현 경로 찾아줘" 요청. 증상 키워드 "경과시간 감소/회귀"를 라우팅표에 매핑 → 도메인 = 누적시간 타이머(useCumulativeElapsed), 영역 = monitor-dashboard 포커스뷰(jacob-handover).

이 케이스는 LogRocket/Grafana 1차 조사(Stage 0~2)가 원본 문서로 이미 끝나 있었다. 게다가 원인이 미디어/타이밍 버그가 아니라 결정론적 상태 로직(클라이언트 산술)이라, 이번 라운드의 가치는 LogRocket 재조사가 아니라 코드 검증 + 반증 + 재현에 있다고 판단했다.

원본 §3의 설명을 1차 가설로 둔다:

재접속이 타이머의 두 입력을 동시에 흔들었다 — ① /sessions가 일시적으로 빈 배열 반환(DB 누적 하락), ② anchor(lessonStartedAt)가 새 시각으로 재설정되어 now − anchor가 축소.

apps/web/hooks/use-cumulative-elapsed.ts:58-123의 getCumulativeElapsedSeconds와 app/monitor-dashboard/[group]/[roomId]/page.tsx:338-371의 lessonStartedAt 라이프사이클을 읽었다.

• 모니터는 서버 sessionId 미보유 → currentSessionId를 안 넘김(page.tsx:349). 라이브 구간 가산은 anchor 한 값에만 의존.
• lessonStartedAt은 재접속마다 서버 복원이 아니라 prev ?? Date.now()로 새로 찍힘. disconnect 시 null(page.tsx:339,363), 재unmute 시 새 값(:366).
• 결정적 발견 — hasLiveCurrentRecord(:71-73): sessions[]에 duration==null 레코드가 하나라도 있으면 true. 이때 (now − anchor) B구간(:108-110)을 타지 않고, 라이브 레코드의 (now − enteredAt)로만 카운트(:103).

안티패턴 "반증 없이 첫 가설 확정"을 피하기 위해, 가설을 깨는 것이 목적인 refuter 서브에이전트를 띄워 코드 기반으로 독립 반증시켰다(관점: 인과 일관성 · 반례 이벤트 · 대안 설명).

refuter 판정: "부분수정 필요"

refuter 주장의 코드 재검증 (load-bearing이라 직접 확인)

flaky한 E2E race를 띄우는 대신, 버그의 본질인 getCumulativeElapsedSeconds 산술을 그대로 옮겨 문서에 기록된 상태 전이를 주입했다. Date.now()를 now 인자로 치환해 결정론화. 모니터 호출 조건 고정(currentSessionId=null, disableFallbackStart=true).

주입한 5개 상태 (T0=레슨시작=0, 끊김=230s, 재접속 T1=255s)

// ① BEFORE 끊김: 라이브 레코드 존재, anchor=T0
get([{enteredAt:0, duration:null}], anchor=0, now=229)        // hasLive=true
// ② AFTER race [{count:0}]: 라이브 레코드 부재, anchor=T1
get([], anchor=255, now=255+54)                                // hasLive=false
// ③ AFTER race [stale duration=95]: 부분 확정, anchor=T1
get([{enteredAt:0, duration:95}], anchor=255, now=255+54)      // hasLive=false
// ④ 반례 R1: 새 라이브 레코드 반영됨(정상 경로)
get([{enteredAt:0,duration:230},{enteredAt:255,duration:null}], anchor=255, now=255+54)
// ⑤ 반례 R3: 카메라 off/on — 레코드 불변
get([{enteredAt:0, duration:null}], anchor=255, now=255+54)    // hasLive=true

실행 결과 (npx tsx)

① BEFORE (끊김 직전, now=229s)
   hasLiveCurrentRecord=true → now - enteredAt
   => 03:49 (229s)   ✓ 03:49 재현

② AFTER race [{count:0}] (now=T1+54s)  ← 회귀
   hasLiveCurrentRecord=false → now - anchor = 54s
   => 00:54 (54s)   ✓ 회귀 발생 (229s→54s)

③ AFTER race [stale duration=95s] (now=T1+54s)  ← 문서 02:29 재현
   hasLiveCurrentRecord=false → beforeAnchor(95s) + (now-anchor)(54s)
   => 02:29 (149s)   ✓ 02:29 정확 재현

④ 반례 R1 [라이브 레코드 반영됨] (now=T1+54s)  ← 회귀 없음(정상)
   hasLiveCurrentRecord=true → 230(full) + (now-255)=54
   => 04:44 (284s)   ✓ 연속 카운트(회귀 없음)

⑤ 반례 R3 [카메라 off/on] (now=T1+54s)  ← 회귀 없음
   hasLiveCurrentRecord=true → now - enteredAt(0) = 309s
   => 05:09 (309s)   ✓ 원복(회귀 없음)

전제 (셋 다 동시 성립해야 회귀)

1. 네트워크 끊김으로 호스트 측 guestInfo 소실 → setLessonStartedAt(null)(page.tsx:338-341). 카메라 off는 ❌ (반례 R3)
2. 재접속 후 게스트 createSession POST가 모니터 /sessions refetch(즉시+1.5s+4s, page.tsx:369-371)보다 늦게 반영 → hasLiveCurrentRecord=false 창.
3. 직전 세션이 disconnectedAt override로 종료 확정(grace 갭 ≤30s 제외) 또는 {count:0}.

단계

1. 호스트 포커스뷰 시청 중, 게스트 진행 → anchor=T0, 헤더 03:49 (라이브 레코드 now − enteredAt).
2. 게스트 네트워크 끊김 → 30s grace 시작, guestInfo 소실 → anchor=null.
3. 게스트 재접속 → createSession(이전 세션 auto-close) + guest-video-unmuted → anchor=T1(재접속 시각). ← T* 인과 지점
4. 모니터 즉시 refetch가 race 창에 걸림 → hasLiveCurrentRecord=false → before-anchor 트리밍 + (now−T1)로 재계산.
5. → 헤더 02:29로 회귀. 회귀폭 ≈ (T1−T0) − 종료세션의 [T0,T1] 확정분 + grace 갭.
6. 1.5s/4s 재시도가 라이브 레코드를 잡으면 hasLiveCurrentRecord=true 복귀 → ≤4초 자가복구(사람이 캡처하려면 그 창에서 봐야 함).

이 버그는 포커스뷰 타이머 버그 중 드물게 네트워크 조작으로 결정론화 가능한 케이스라 chrome-devtools MCP로 자동화할 수 있다. 레시피:

1. 게스트 페이지를 chrome-devtools로 띄워 레슨 진행, 호스트 모니터 헤더 시간 확보.
2. 게스트 네트워크를 offline(emulate/throttle)로 끊어 guestInfo 소실 유도.
3. 재접속 직후 게스트 POST /api/lessons/.../sessions(createSession)를 4초+ 지연/블록 → race 창을 refetch 밖으로 유지.
4. 그 창에서 호스트 헤더 회귀를 take_snapshot/evaluate_script로 캡처.

오프라인→온라인은 올바른 트리거 계열이지만, 단순히 끊었다 붙이면 거의 재현되지 않는다. 코드 레벨 함정이 둘 있다.

함정 ① — 빠른 재접속이면 guest-disconnected가 아예 안 나간다

서버는 게스트 소켓 disconnect 정리 시, 같은 peerId를 새 소켓이 이미 점유했으면 정리·브로드캐스트를 통째로 skip한다 (apps/socket/src/sfu-socket/signalingHandler.ts:149-159):

const replaced = !!currentPeer && currentPeer.socketId !== socket.id;
if (replaced) { // 게스트가 같은 peerId로 빠르게 재진입
  ...skipping cleanup and broadcast; continue;   // guest-disconnected emit 안 함
}
// 정상 정리 경로에서만:
socket.to(roomId).emit("guest-disconnected", { roomId });  // :162, 끊김 즉시 emit

• 재접속이 너무 빠르면 → "replaced" 판정 → guest-disconnected 미발송 → 호스트 guestInfo 안 비워짐 → anchor 재스탬프 없음 → 회귀 없음.
• 따라서 오프라인을 충분히 길게(socket.io ping timeout 넘겨 서버가 실제 disconnect 처리 + 호스트 화면에서 게스트가 사라지는 게 보일 때까지) 둬야 guest-disconnected가 나가 guestInfo가 비워진다.

함정 ② — guestInfo가 비워져도 회귀는 ≤4초 race 창에서만 보인다

회귀가 보이려면 hasLiveCurrentRecord=false(새 라이브 레코드 미반영)여야 하는데, 모니터는 재접속 직후 /sessions를 즉시 + 1.5s + 4s 재시도로 다시 읽는다(monitor-dashboard/[group]/[roomId]/page.tsx:369-371).

• 게스트 createSession이 그 안에 반영되면 hasLiveCurrentRecord=true로 복귀 → 회귀가 ≤4초 만에 자가복구된다.
• 그냥 재접속하면 그 순간을 스냅샷/육안으로 잡아야만 보인다.

• 시스템 설계: 누적 경과시간 추적 — 세션 합산·단조 클램프 코드레벨 동작 흐름
• 원인 분석 본편: 경과시간 03:49 → 02:29 감소 — 게스트 재접속 후 누적시간 회귀 분석
• 반대 방향(이중가산): 경과시간 09:08 → 18:03 점프 — 누적시간 이중 가산 (PR #703)
• 코드: apps/web/hooks/use-cumulative-elapsed.ts:58-123 · app/monitor-dashboard/[group]/[roomId]/page.tsx:338-371 · lib/api/services/lesson-session.service.ts:34-39,93-150 · apps/socket/src/utils/pending-disconnect-tracker.ts:15
• 설계 의도: docs/handover/jacob/{architecture,focus-view,card-view,runbooks}.md