호스트·게스트 모두 접속했으나 매칭이 안 되는 현상

사건 개요

2026-06-05 14:00 KST 아동059 아동 수업. 게스트(아동059)와 호스트(션) 모두 접속했으나 서로 인식하지 못함. 호스트는 노쇼 처리(completionStatus=300), 게스트는 standalone 모드로 AI와 수업 진행.

roomId: dc8e7ac9-dfe2-4a96-8684-de59d56c88ed_17

실패 세션 타임라인 — dc8e7ac9-..._17

게스트 측 (UTC)

호스트 측 (UTC)

핵심 발견: WaitingApproval = 모니터링 클레임 존재 증명

서버의 GUEST_REQUEST_ENTRY 핸들러는 peers Map에서 role === "host" && monitoringRoomId === roomId인 peer를 찾은 경우에만 WaitingApproval을 반환합니다.

// room-handlers.ts:228
const hostPeer = Array.from(peers.values()).find(
  (p) => p.role === "host" && p.monitoringRoomId === roomId,
);

if (!hostPeer) {
  callback({ error: "RoomNotFound" });  // line 253
  return;
}
// hostPeer 있을 때만 아래로 내려가서 WaitingApproval 반환
callback({ status: "WaitingApproval", ... });

따라서 04:54:20 WaitingApproval = 그 시점 peers Map에 호스트 모니터링 클레임이 확실히 존재했음. 그 이후 04:55:55 서버측 소켓 disconnect 시점에 클레임이 제거됨 (v3에서 서버 로그로 확정 — 아래 참조).

타임라인 핵심 불일치

get-peers:{peers:[0]}의 올바른 해석

v1 분석에서 04:52:39의 peers:[0]을 "호스트 클레임 없음"으로 해석했으나 이는 잘못된 해석입니다.

// connection-handlers.ts:484 — GET_PEERS 핸들러
for (const [, peerInfo] of peers.entries()) {
  if (peerInfo.roomId === roomId) {  // ← roomId 기준
    peersInRoom.push({ ... });
  }
}

모니터링 클레임(HOST_START_MONITORING으로 등록)은 roomId: null, monitoringRoomId: <실제 roomId>로 저장됩니다. GET_PEERS는 peerInfo.roomId만 확인하므로 모니터링 클레임은 항상 GET_PEERS 결과에 나타나지 않습니다. peers:[0]은 "방에 일반 peer가 없다"는 것이지 "모니터링 클레임이 없다"는 게 아님.

구조적 버그: hasStartedRef.current 미리셋 문제

소켓 재연결 후 HOST_START_MONITORING이 재발송되지 않는 이유:

// apps/web/features/monitor/room-monitoring/model/use-room-monitoring.ts:140
useEffect(() => {
  if (enabled && monitoringPeerId && !hasStartedRef.current) {
    hasStartedRef.current = true;  // ← 한 번 true가 되면 재연결 시에도 리셋 안 됨
    startMonitoring();
  }
}, [enabled, monitoringPeerId, startMonitoring]);

소켓이 재연결되어 새 socketId를 발급받아도, hasStartedRef.current는 컴포넌트가 언마운트되지 않는 한 true를 유지합니다. 즉, 소켓 재연결 후 호스트 쪽에서 모니터링 클레임을 서버에 재등록하지 않습니다.

tab-hidden 상태에서 서버가 peer를 일시적으로 정리(reaper 또는 brief transport drop)한 경우, 소켓 자체는 공식 단절 없이 복구되더라도 클레임은 사라진 채로 남습니다.

재현 시나리오 (v3 서버 로그 반영)

성공 세션 비교 — 411421c4-..._19

핵심 차이: 게스트가 연결 시도하는 시점에 호스트 tab이 visible인지 여부. 성공 세션에서는 호스트가 tab hidden 없이 대기했고 소켓 단절도 없었음.

인프라 확인: 단일 EC2 인스턴스

클레임 제거 메커니즘 — 확정 (v3, Grafana/Loki 서버 로그)

v2에서 "미확인"으로 남겼던 04:55:38~05:00:10 구간 클레임 제거를 ppi-socket 서버 로그(Loki)로 조회한 결과 완전히 특정됨. 후보 3개 중 "tab-hidden → 서버측 소켓 disconnect"가 정답이며, 메커니즘은 reaper가 아닌 Socket.IO pingTimeout disconnect 핸들러였다.

// {service="ppi-socket"} |= "x8PY5tqkRRnGUV9bAAFL"
04:52:50.567  [DIAG] Socket CONNECTED
04:52:50.817  [DIAG] JOIN_ROOM received
04:55:55.210  [DIAG] Socket DISCONNECT event        // ← tab hidden(04:55:38) +17초
04:55:55.210  [DIAG] Disconnect scanning peers

04:55:55.100Z WARN [DIAG] Disconnect scanning peers
   { socketId: x8PY5tqkRRnGUV9bAAFL, totalPeersInMap: 5,
     matchingPeersForThisSocket: 3, matchingPeerIds: [ 952d9107-…, role:host … ] }
04:55:55.101Z INFO Cleaning up peer 952d9107-…                                  after disconnect  // host base
04:55:55.101Z INFO Cleaning up peer monitoring:952d9107-…-monitoring-…_17 after disconnect  // ★ 클레임
04:55:55.102Z INFO Cleaning up peer 952d9107-…-…_17-65230892-…                  after disconnect  // transport (Closed 1)

// {service="ppi-socket"} |= "V8bbpscP5O8NbNGlAAGr"
05:19:08.193  [DIAG] Socket CONNECTED
05:19:08.445  [DIAG] JOIN_ROOM received        // ← JOIN_ROOM만. START_MONITORING 없음
05:20:34.646  [DIAG] Socket DISCONNECT event

// roomId 전 구간 START_MONITORING/monitoring 재등록 검색 결과: 0건

재현용 LogQL 쿼리 (Grafana → Loki, datasource P8E80F9AEF21F6940)

시간 범위: 2026-06-05 04:50~05:20 UTC (= 13:50~14:20 KST). Explore에서 datasource Loki 선택 후 아래 쿼리 실행. roomId / socketId만 바꾸면 다른 세션에도 재사용 가능.

※ Grafana 프록시 직접 호출 시: /api/datasources/proxy/uid/P8E80F9AEF21F6940/loki/api/v1/query_range?query=…&start=<ns>&end=<ns>&limit=2000&direction=forward (start/end는 epoch nanoseconds). 라벨은 service = ppi-socket.

관련 코드 위치

Fix 방향

// use-room-monitoring.ts — 소켓 재연결 감지 useEffect 추가
useEffect(() => {
  const handleReconnect = () => {
    hasStartedRef.current = false;  // 재연결 시 리셋
  };
  socket?.on("connect", handleReconnect);
  return () => { socket?.off("connect", handleReconnect); };
}, [socket]);

결정적 증거 요약

• 04:54:20 WaitingApproval → 그 시점 호스트 모니터링 클레임 peers Map에 확실히 존재 (서버 코드상 다른 경우 불가)
• [v3] 04:55:55 서버 로그: 호스트 소켓 DISCONNECT(pingTimeout) → disconnect 핸들러가 monitoring 클레임 정리 — 클레임 제거 메커니즘 확정
• 05:00:10 RoomNotFound → 클레임은 이미 04:55:55에 제거된 상태 (4분 15초 전)
• [v3] 05:10:08은 클라이언트가 단절을 인지한 시각일 뿐 — 서버 단절(04:55:55)과 14분 괴리, 탭 freeze가 원인. v2의 "단절이 원인 아님" 판단을 정정
• [v3] 05:19:08 재연결 후 JOIN_ROOM만 수행, START_MONITORING 재등록 0건 (서버 로그) → hasStartedRef.current 버그 재확인
• 성공 세션(411421c4-..._19): 호스트 tab-visible 유지 + 소켓 단절 없음 → 매칭 성공
• 단일 EC2 인스턴스 확인 → cross-instance 가설 완전 폐기