운영자가 본인 담당 클래스 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 패턴을 정리한다.
PATCH body에 끼워 넣은 다른 tenantId가 통과해 옆 고객사 회원이 옮겨 쓰였다. NestJS Guard + DTO에서 tenantId 제거 + whitelist:true 3중 차단으로 쓰기 가드를 만들고, count/sum/groupBy는 where 변수 추출 + $transaction으로 묶었다. 시간 슬라이스는 KST 자정 고정, 멱등성은 Redis EX 60 + 충돌 검사 + audit, 정책 위반은 bypassPolicy + reason + audit. ts-morph 정적 스캔까지 1일 트러블슈팅.
NestJS 멀티테넌트 도입 다음 날 아침, 다른 고객사 토큰으로 회원 상세를 열었더니 200 OK가 떨어졌다. JWT payload·@CurrentUser·Repository 시그니처 3계층에 tenantId를 강제하고, ts-morph 정적 스캔과 cross-tenant e2e로 회귀까지 차단한 6시간 트러블슈팅.
SystemPolicy 8필드를 id @default(1) 싱글톤으로 묶고, 상호 의존 임계값은 zod superRefine으로 BE/FE 두 곳에서 검증했다. 동사 액션은 별도 라우트로 분리하고, 정책 변경은 방향성만 검증하는 e2e로 회귀를 차단한 1.5일 트러블슈팅.
B2B SaaS 플랫폼의 RBAC 인가 체계를 설계한 과정. 4역할 계층 구조, 리소스별 권한 매트릭스, Multi-tenancy 격리 전략, NestJS Guard/Decorator 구현까지 — 권한 설계 문서 1,292줄이 코드가 되기까지의 기록.