PPI-1267 좀비 녹음세션 반복
— 수정 설계·구현과 추론 과정 구현 완료 · PR #1060

"재접속시 수업시간 아니면 입장 불가한데, 어떻게 입장된거야?"

이 질문을 좇아 코드를 다시 추적한 결과: 수업시간 hard-cut 검증(validateLessonTime)은 웹 HTTP 층의 /api/validate-lesson에만 있었다. 이건 전화번호+PIN으로 최초 입장할 때 딱 한 번 호출된다. 반면 socket.io 층의 재접속 경로(JOIN_ROOM → validateLessonSessionOwner)는 "이 lessonSessionId가 발급된 게 맞는가"만 확인하고 시간은 아예 보지 않았다. 원인 문서의 로그 팩트("정식 입장은 8/29 11:42 1회뿐, 이후 9/1까지 재입장 없이 JOIN_ROOM만 반복")가 정확히 이 구조를 가리키고 있었는데, 처음 설계 때는 이 구멍을 메우는 대신 그 결과(빈 녹음·좀비 ERROR)만 막으려 했던 것이다.

"그럼 소켓 재접속시에도 시간 검증 추가하면 좀비 세션 간단하게 막을 수 있는거 아냐?"

맞았다. validateLessonSessionOwner가 이미 부르는 내부 API(validate-owner/route.ts)가 getLesson으로 lesson 레코드를 이미 가져오고 있었고, 그 레코드엔 plannedStartTime이 있었다. 새 API 호출 없이 기존 호출 한 곳에 검증 한 줄만 추가하면 되는 구조였다. 레거시(isLegacyMode, 진행자가 수동 시작하는 시간 미고정 수업)는 이번 범위에서 제외하기로 사용자가 확정했다.

"이 코드 다 수정 필요한거야?"

시간 게이트 하나로 무한 반복 자체가 끊기므로, 앞서 구현한 ①(모니터 게이트 녹음 억제)③(좀비 stop 순서/discardIfEmpty)은 "부가 개선"일 뿐 이번 티켓 해결의 필수 조건이 아니었다. 사용자가 최소화를 선택해 ①③과 idle 타임아웃(②) 전부 롤백하고 시간 게이트 2파일만 남겼다.

1. validate-owner/route.ts — hard-cut 검증 추가

validateCurrentLessonSessionOwner는 원래 소유권 일치만 boolean으로 반환하는 한 줄짜리 함수였다. 소유권 통과 후 plannedStartTime이 문자열이면 validateLessonTime(plannedStartTime, now)의 hard-cut(예정시각+1시간) 결과를 그대로 반환하도록 확장했다(route.ts:103-119). 레코드에 값이 없으면(방어적 타입) 기존처럼 통과시킨다.

알려진 한계(고의로 남김): plannedStartTime이 파싱 불가능한 문자열이면 validateLessonTime 내부의 모든 Date 비교가 NaN이 되어 결국 통과(isValid:true) 처리된다. 이건 이번에 새로 만든 위험이 아니라 최초 입장 게이트(/api/validate-lesson)도 이미 똑같이 신뢰하던 동작이라, 코드리뷰에서 Suggestion으로만 기록하고 손대지 않았다.

2. connection-handlers.ts — force-kick 2곳

JOIN_ROOM 안에는 소유권 검증이 두 번 있다. 첫 번째(694번 줄 부근, JOIN_ROOM 초입)가 실패하면 예전엔 {success:false, error:"invalid lesson session owner"} ack만 보냈다. 이것만으론 안 된다 — socket.io는 ack 실패와 무관하게 계속 재연결을 시도하므로, 거부만 하면 거부 자체가 무한 반복된다. 그래서 응답 전에 socket.emit(GUEST_FORCE_KICKED, {reason:"complete"})를 추가해(connection-handlers.ts:703) 클라이언트를 layoutMode:"lesson-ended"(terminal, sticky)로 보내 재접속 자체를 막았다.

코드리뷰에서 찾은 두 번째 구멍: JOIN_ROOM 안에는 router 준비를 기다리는 동안 소유권을 한 번 더 재확인하는 두 번째 검증(stillOwnsSession, 961번 줄 부근)이 있는데, 이 경로는 실패해도 첫 번째와 똑같은 에러 문구를 클라이언트에 보내면서도 force-kick이 빠져 있었다. 두 검증 사이의 좁은 시간 창(router 생성 대기 중)에 수업시간이 만료되면 이 경로를 타는데, 그러면 여전히 재접속 루프가 안 끊길 수 있었다. 동일하게 force-kick을 추가해(connection-handlers.ts:971) 두 경로 모두 같은 결과를 보장했다.

reason을 "complete"로 재사용한 이유

강제퇴장 사유는 원래 "kick"(관리자 강퇴, "잠깐 준비하고 왔어..." 화면)과 "complete"(수업 정상 종료, "오늘도 재밌었어!" 화면) 둘뿐이었다. 새 사유 타입을 shared 패키지에 추가하는 안(idle_timeout)도 한때 구현했지만, 최소화 결정 이후엔 완전히 걷어내고 기존 "complete"를 그대로 재사용했다 — 새 타입 없이도 "정상 종료처럼 보이는 화면"이 이 상황에 가장 자연스러웠고, shared 타입·웹 훅 타입을 건드릴 필요가 없어졌다.