회원 레포트와 같은 데이터를 보호자(외부 뷰어) 그릇으로 옮기는 별도 앱 도입 머지. 모바일 우선 컨테이너(max-w-[430px]), Parent/ParentStudent/ParentInvitation 3 신규 모델, 초대 토큰 + 회원가입 단일 트랜잭션(4 write), 별도 JWT 시크릿(1h access / 30d refresh), 전화번호 = 로그인 ID 결정을 같은 dev 머지 사이클 4시간 안에 BE + FE Mock + FE 인증 연동까지 묶은 도입 단계 마일스톤이다.
운영자가 본인 담당 클래스 1개만 떠야 하는데 모든 클래스가 떴다. 목록 API에 operatorId 필터를 깔고 끝낸 줄 알았는데, 직접 URL로 미담당 클래스 ID를 두드리니 상세·수정·승인 5개 엔드포인트가 그대로 200을 돌려줬다. 원인은 JWT payload.sub(User ID)와 Operator 테이블 id(Operator ID)의 분리 + validateClassAccess 헬퍼 부재 둘이었다. 라운드 한 번에 BE → QA → 추가 BE → QA 재검증으로 닫은 NestJS ForbiddenException + Prisma classOperator.findFirst 패턴을 정리한다.
혼자서 BE·FE·QA·PM을 동시에 맡는 환경에서 학습 클라이언트 웹 프로토타입 첫 QA 라운드를 돌렸다. 브랜치 미동기화로 인한 미구현 오보, 만료 토큰 잔존으로 인한 401, UI 스모크 수준의 검증 충실도 부족까지 세 함정을 한 라운드에 만났고, 다음 라운드부터의 운영 체크리스트로 정리했다.
활동 로그 인터셉터에서 request.user가 undefined로 잡혔다. 원인을 파고드니 JwtAuthGuard 구현 누락, Auth Service와 Guard 간 JWT_SECRET 불일치, FE의 base64(JSON) Mock 토큰까지 3중 함정이 차례로 드러났다. 새벽 3시 임시 우회부터 다음 날 17시 정상화까지의 디버깅 흐름과 NestJS 글로벌 Guard·명시적 secret 검증·실제 BE API 시드 패턴을 정리한다.
NestJS 멀티테넌트 도입 다음 날 아침, 다른 고객사 토큰으로 회원 상세를 열었더니 200 OK가 떨어졌다. JWT payload·@CurrentUser·Repository 시그니처 3계층에 tenantId를 강제하고, ts-morph 정적 스캔과 cross-tenant e2e로 회귀까지 차단한 6시간 트러블슈팅.