NestJS 인증은 Middleware와 Guard 중 하나를 고르는 문제가 아니었다
관리자 요청의 인증·권한 책임 비교
당시 인증·권한 책임과 현재의 개선 판단은 요청 생명주기에서 어떻게 다른가?
당시 요청은 AdminAuthMiddleware에서 토큰·쿠키·CSRF 확인과 req.user 주입을 거친 뒤 AdminLevelGuard에서 관리자 등급을 확인하고 Controller로 전달됐습니다. 현재 다시 설계한다면 요청은 공개 경로를 제외한 Global Auth Guard에서 기본 인증을 거친 뒤 별도 Permission Guard에서 관리자 등급을 확인하고 Controller로 전달됩니다.
Before
당시 구현
Express 경험에서 출발해 인증과 요청 객체 준비를 Middleware에, 등급 확인을 Guard에 나눴습니다.
- 관리자 요청
- AdminAuthMiddleware
- AdminLevelGuard
- Controller
- 직접 연결관리자 요청토큰·쿠키·CSRF 확인 ↓토큰·쿠키·CSRF 확인 →AdminAuthMiddleware
- 직접 연결AdminAuthMiddlewarereq.user 주입 후 등급 확인 ↓req.user 주입 후 등급 확인 →AdminLevelGuard
- 직접 연결AdminLevelGuard권한 확인 후 전달 ↓권한 확인 후 전달 →Controller
After
현재 개선 판단
인증을 Global Auth Guard의 기본값으로 두고 공개 경로와 세부 등급 권한을 분리합니다.
- 요청
- Global Auth Guard
- Permission Guard
- Controller
- 직접 연결요청기본 인증·공개 경로 제외 ↓기본 인증·공개 경로 제외 →Global Auth Guard
- 직접 연결Global Auth Guard인증 후 관리자 등급 확인 ↓인증 후 관리자 등급 확인 →Permission Guard
- 직접 연결Permission Guard권한 확인 후 전달 ↓권한 확인 후 전달 →Controller
익숙한 실행 지점에서 인증을 시작했습니다
행사 호텔 예약·결제 플랫폼의 관리자 인증을 구현할 당시 저는 Node.js와 Express에는 익숙했지만 NestJS의 요청 생명주기와 권장 패턴을 충분히 비교해 본 상태는 아니었습니다. 그래서 Access·Refresh 토큰과 CSRF 값을 확인하고, 필요할 때 토큰과 쿠키를 갱신하며, 이후 로직에서 사용할 req.user를 주입하는 책임을 AdminAuthMiddleware에 두었습니다.
관리자 등급은 별도 AdminLevelGuard에서 확인했습니다. 즉, 당시 구현은 인증과 요청 객체 준비를 Middleware가 맡고 엔드포인트별 등급 권한을 Guard가 맡는 구조였습니다.
동작한 구조와 권장 구조는 같은 질문이 아니었습니다
이 책임 분리는 실제 코드에 반영됐지만, Middleware를 Guard보다 우선하는 대안을 충분히 비교한 뒤 선택한 것은 아니었습니다. 기존 글처럼 “Middleware가 더 견고했다”거나 “Guard 선언 누락을 없앴다”고 결론 내리면 당시 판단을 사후에 합리화하게 됩니다.
프로젝트에서 확인한 사실은 Middleware와 Guard를 함께 사용해 인증과 등급 권한을 나눴다는 데까지입니다. 고객사 스테이징 UAT를 진행했지만, 그것을 인증 구조의 운영 안전성이나 권한 누락 없음에 대한 검증으로 확대하지 않습니다.
지금 다시 설계한다면 인증을 기본값으로 둡니다
현재의 판단은 다릅니다. 다시 구성한다면 Global Auth Guard로 인증을 기본 적용하고 공개 경로만 명시적으로 제외하겠습니다. 로그인한 사용자의 세부 관리자 등급은 별도의 권한 Guard로 분리하겠습니다.
핵심은 Middleware와 Guard 중 하나를 절대적인 정답으로 고르는 것이 아니라, 인증과 권한 확인의 책임을 어디에서 기본 적용하고 어디에서 세분화할지 정하는 것입니다. 이 프로젝트의 회고에서는 기본 인증과 세부 권한을 Guard 계층에서 드러내는 편이 NestJS 구조를 읽는 사람에게 더 명확하다고 판단했습니다.
당시 구현과 현재 판단의 경계를 남깁니다
Global Auth Guard 구조는 이 프로젝트에서 다시 구현하거나 운영으로 검증한 결과가 아니라, 보류 이후의 개선 판단입니다. 반대로 당시 Middleware 구조가 동작했다는 사실도 그 방식이 모든 NestJS 인증에 더 적합하다는 근거는 아닙니다.
따라서 이 사례에서 가져갈 기준은 “Middleware 대신 무조건 Guard”가 아닙니다. 인증의 기본 적용, 공개 경로 예외와 관리자 등급 권한을 서로 다른 책임으로 명시하고, 프레임워크 안에서 그 경계가 가장 잘 드러나는 위치를 선택하는 것입니다.