Next.js App Router 인증 권한 설계 가이드: SaaS 관리자 화면 보호 기준 > 인사이트

본문 바로가기

인사이트

Next.js App Router 인증·권한 설계 가이드: SaaS 관리자 화면을 안전하게 운영하는 기준

결론부터 말하면, Next.js App Router 인증·권한 설계의 핵심은 로그인 여부를 한 곳에서 확인하는 것이 아니라 권한 결정을 여러 계층에 맞게 분산하되, 최종 판단은 서버와 데이터 소스 가까이에 두는 것입니다. 클라이언트는 메뉴와 버튼을 숨기는 UX 계층, Proxy는 빠른 리다이렉트와 큰 라우트 그룹 차단 계층, Server Components는 페이지 렌더링 전 세션 확인 계층, Data Access Layer는 실제 데이터 접근 권한을 판단하는 중심 계층, Server Actions와 Route Handlers는 변경 작업과 API 호출의 방어선으로 나누어야 합니다.

Next.js App Router 인증 권한 설계를 검토하는 SaaS 관리자 화면과 코드 에디터
App Router 인증은 로그인 화면보다 라우트, 데이터, 액션 권한의 책임 분리가 먼저입니다.

Next.js 공식 문서는 인증을 사용자가 누구인지 확인하는 과정, 세션 관리를 요청 사이에서 인증 상태를 추적하는 과정, 권한 부여를 사용자가 어떤 라우트와 데이터에 접근할 수 있는지 결정하는 과정으로 나누어 설명합니다. App Router와 React Server Components 환경에서는 이 세 가지가 한 파일에 모이지 않고 UI, 서버 렌더링, 서버 함수, API, 데이터 계층으로 흩어지기 때문에 설계 기준이 없으면 코드가 빠르게 중복됩니다. ([nextjs.org](https://nextjs.org/docs/app/guides/authentication))

SaaS 관리자 화면에서는 이 문제가 더 빨리 드러납니다. 처음에는 admin 한 가지 권한만 있으면 충분해 보이지만 곧 고객사별 조직, 팀원 초대, 결제 담당자, 읽기 전용 운영자, 외부 파트너, 슈퍼 관리자, 감사 로그, 데이터 내보내기 권한이 생깁니다. 이때 클라이언트에서 메뉴만 숨기는 방식으로 출발하면 권한 우회, 고객사 간 데이터 노출, 유지보수 비용 증가가 동시에 발생합니다.

1. 먼저 정해야 할 원칙: 권한 결정은 데이터 가까이, UX 처리는 바깥쪽에

실무에서 가장 안전한 기준은 단순합니다. 보안상 반드시 막아야 하는 판단은 데이터 소스 가까이에 두고, 사용자를 편하게 안내하는 판단은 라우팅과 UI 계층에 둡니다. Next.js 공식 문서도 Proxy가 초기 확인에는 유용하지만 데이터 보호의 유일한 방어선이 되어서는 안 되며, 대부분의 보안 검사는 데이터 소스 가까이에서 수행해야 한다고 설명합니다. ([nextjs.org](https://nextjs.org/docs/app/guides/authentication))

운영 원칙: Proxy는 문 앞의 안내 데스크이고, Data Access Layer는 출입 권한을 실제로 확인하는 보안 게이트입니다. 안내 데스크에서 통과했다고 금고 문까지 열린 것으로 보면 안 됩니다.

계층맡기기 좋은 일맡기면 위험한 일SaaS 관리자 화면 예시
Client Component메뉴 표시, 버튼 비활성화, 로딩 상태, 권한별 안내 문구최종 권한 판단, 민감 데이터 필터링권한 없는 사용자에게 삭제 버튼을 숨김
Proxy로그인 여부 기반 리다이렉트, 큰 라우트 그룹 차단, 테넌트 도메인 정규화모든 데이터 접근 권한의 단독 판단/admin 접근 시 미로그인 사용자를 로그인 페이지로 이동
Server Component page·leaf렌더링 전 세션 확인, 필요한 DTO 조회, 권한별 서버 렌더링공유 layout에만 인증 로직을 두고 끝내기관리자 대시보드에서 현재 조직 기준 통계만 조회
Data Access Layer세션 검증, role·permission 확인, tenant scope 강제, DTO 반환각 페이지가 직접 DB를 조회하도록 방치getInvoiceListDTO()가 세션의 조직 ID로만 조회
Server Actions데이터 변경 전 인증·권한·소유권·입력 검증버튼을 숨겼으니 안전하다고 가정멤버 초대, 권한 변경, 결제 정보 수정 전 재검사
Route Handlers·BFF외부 호출, 파일 다운로드, 웹훅, API 응답 권한 검사프론트에서 이미 검사했다는 이유로 생략CSV export API에서 감사 로그와 권한 확인
백엔드 API·DB여러 클라이언트가 공유하는 최종 권한 정책Next.js 화면이 항상 올바르게 호출한다고 믿기모바일 앱, 파트너 API, 관리자 웹이 같은 권한 정책 사용

2. 2026년 기준 Proxy와 Middleware를 어떻게 봐야 하나

Next.js 16에서는 기존 middleware.ts 파일 규칙이 proxy.ts로 이름이 바뀌었고, 요청이 라우트로 완료되기 전에 서버에서 실행되어 리다이렉트, rewrite, 헤더·쿠키 처리, 직접 응답 등에 사용됩니다. 공식 문서는 middleware 파일 규칙이 deprecated 되었고 proxy로 변경되었다고 안내합니다. ([nextjs.org](https://nextjs.org/docs/app/api-reference/file-conventions/proxy))

따라서 새 프로젝트라면 문서와 팀 내 용어를 Proxy 기준으로 맞추는 편이 좋습니다. 다만 Next.js 15 이하 프로젝트나 라이브러리 예제에서는 여전히 Middleware라는 이름이 나올 수 있습니다. 마이그레이션 중인 팀이라면 인증 설계 문서에 “Next.js 16 이상은 proxy.ts, 이전 버전은 middleware.ts”처럼 명시해 두는 것이 혼선을 줄입니다. Next.js 16 릴리스 문서도 middleware.ts에서 proxy.ts로 rename하고 함수명을 proxy로 바꾸라고 설명합니다. ([nextjs.org](https://nextjs.org/blog/next-16))

Proxy는 좋은 입구 장치입니다. 예를 들어 /app, /dashboard, /admin 같은 보호 라우트에 접근한 미로그인 사용자를 로그인 화면으로 보내거나, 로그인 사용자가 다시 /login에 접근하면 대시보드로 보내는 처리는 Proxy에 잘 맞습니다. 더 세부적인 Matcher, 리다이렉트, A/B 테스트 경계는 이전 글 Next.js Middleware·Proxy 설계 기준에서 별도로 다뤘습니다.

3. 요청 흐름으로 보는 권한 검사 위치

Proxy부터 DAL과 Server Action까지 이어지는 Next.js 인증 권한 검사 흐름
Proxy는 입구, DAL은 권한의 중심, Server Actions와 API는 변경 작업의 방어선입니다.

관리자 화면 요청 하나를 따라가 보면 각 계층의 역할이 선명해집니다. 사용자가 /org/acme/admin/members에 접근하면 Proxy는 세션 쿠키 존재 여부와 라우트 그룹을 보고 로그인 페이지로 보낼지 판단합니다. 이후 Server Component는 현재 사용자와 활성 조직을 확인하고, DAL의 requirePermission 같은 함수를 통해 member.read 권한이 있는지 확인합니다. 실제 DB 쿼리는 세션에서 검증된 orgId로만 범위를 좁히고, 클라이언트에는 필요한 필드만 담은 DTO를 반환합니다.

  1. Proxy: 미로그인 사용자 리다이렉트, 공개·보호 라우트 분기, 큰 경로 차단
  2. Server Component: 페이지 렌더링 전 현재 세션과 활성 조직 확인
  3. DAL: 세션 유효성, 조직 멤버십, role·permission, resource ownership 검증
  4. DB 또는 API: 검증된 tenant scope로만 조회·변경 수행
  5. Client Component: 이미 허용된 데이터만 받아 버튼, 탭, 모달, 테이블 UX 구성
  6. Server Action: 저장·삭제·초대·권한 변경 전 같은 권한 검사를 다시 수행

특히 layout에만 인증 검사를 두는 방식은 주의해야 합니다. Next.js 문서는 partial rendering 특성 때문에 layout이 탐색마다 다시 렌더링되지 않을 수 있으므로, 권한 검사는 데이터 소스 또는 조건부 렌더링이 일어나는 컴포넌트 가까이에 두라고 설명합니다. 또한 SPA에서 흔한 “권한 없으면 layout에서 null 반환” 패턴은 nested route segment와 Server Actions 접근을 막지 못하므로 권장되지 않습니다. ([nextjs.org](https://nextjs.org/docs/app/guides/authentication))

4. Server Actions는 버튼 뒤의 함수가 아니라 공개 엔드포인트로 취급한다

App Router를 처음 쓰는 팀이 자주 놓치는 부분이 Server Actions입니다. 화면 코드 안에 함수처럼 보이기 때문에 “이 버튼을 볼 수 있는 사용자만 실행하겠지”라고 생각하기 쉽습니다. 그러나 Next.js 문서는 Server Functions가 애플리케이션 UI를 통해서만 호출되는 것이 아니라 직접 POST 요청으로 도달 가능하므로, 모든 Server Function 안에서 인증과 권한을 항상 확인해야 한다고 설명합니다. ([nextjs.org](https://nextjs.org/docs/app/getting-started/mutating-data))

따라서 관리자 화면의 변경 작업은 다음 순서를 기본값으로 삼아야 합니다.

  • 서버에서 세션을 읽고 유효성을 확인한다.
  • 사용자의 활성 조직 또는 테넌트를 세션 기준으로 확정한다.
  • 요청 대상 리소스가 그 조직에 속하는지 확인한다.
  • 사용자에게 해당 action permission이 있는지 확인한다.
  • 입력값을 서버에서 검증한다. hidden input이나 bind로 전달한 ID를 신뢰하지 않는다.
  • 삭제, 권한 변경, 데이터 내보내기, 결제 정보 변경은 감사 로그를 남긴다.
  • 변경 후 cache revalidation 또는 refresh 전략을 명시한다.

예를 들어 “팀원 권한 변경” 액션은 member.update 권한만 보면 부족합니다. 요청자가 같은 조직의 멤버인지, 대상자가 같은 조직에 속하는지, 자기 자신의 owner 권한을 제거하는 것인지, 마지막 owner를 제거하는 것인지, 지원팀의 임시 접근인지까지 확인해야 합니다.

5. 권한 모델은 role이 아니라 actor·tenant·resource·action으로 설계한다

SaaS 권한 설계에서 admin, user 두 가지만 두면 빠르게 한계가 옵니다. 관리자가 모든 것을 할 수 있는지, 결제 담당자도 멤버 초대를 할 수 있는지, 읽기 전용 사용자가 CSV export를 할 수 있는지, 고객사 owner와 플랫폼 super admin은 같은 admin인지가 곧 애매해집니다.

질문설계 항목예시
누가 요청하는가?Actor사용자, 지원 담당자, 시스템 작업, API key
어느 고객사 범위인가?Tenantorganization, workspace, customer account
무엇을 대상으로 하는가?Resourceinvoice, member, project, report, billing profile
무슨 행동인가?Actionread, create, update, delete, export, invite, approve
어떤 조건이 붙는가?Condition요금제, 소유자 여부, 상태값, 시간, 재인증 필요 여부
기록해야 하는가?Auditrole 변경, impersonation, 대량 다운로드, 삭제

초기 MVP에서는 owner, admin, member, viewer 정도의 RBAC로 시작할 수 있습니다. 다만 코드 내부에서는 role 문자열을 직접 비교하기보다 hasPermission(user, org, 'invoice.export')처럼 permission 중심의 함수로 감싸는 편이 장기 운영에 유리합니다. 나중에 “admin이지만 결제는 못 보게 해주세요”라는 요구가 들어와도 role 이름을 계속 늘리지 않고 permission matrix를 조정할 수 있기 때문입니다.

다중 테넌트 SaaS에서는 권한 모델보다 더 중요한 것이 테넌트 스코프입니다. URL의 orgSlug나 폼의 organizationId를 그대로 믿으면 IDOR 형태의 취약점이 생깁니다. OWASP Authorization Cheat Sheet도 객체 ID를 추측하거나 조작하는 것만으로 권한 없는 리소스에 접근하지 못하도록, 요청마다 객체·기능 단위 접근 제어를 수행해야 한다고 설명합니다. ([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)) 고객사별 데이터 분리 구조는 다중 테넌시 데이터 모델링 기준과 함께 검토하는 것이 좋습니다.

6. 세션과 토큰: 편의성보다 폐기 가능성을 본다

관리자 화면의 세션 설계에서 중요한 질문은 “자동 로그인이 되느냐”가 아니라 “역할이 바뀌거나 계정이 비활성화되었을 때 얼마나 빨리 막을 수 있느냐”입니다. 장기 운영형 SaaS에서는 멤버 퇴사, 고객사 계약 종료, 권한 회수, 보안 사고 대응이 반복됩니다. JWT에 role과 org 목록을 오래 담아두면 빠르지만 회수와 갱신이 어려워질 수 있습니다. 반대로 DB 세션은 조회 비용이 있지만 강제 로그아웃과 권한 반영이 명확합니다.

방식적합한 경우주의점
서버 세션 + HttpOnly 쿠키관리자 웹, B2B SaaS, 권한 회수가 중요한 서비스세션 저장소, 만료 정책, 재인증 정책 필요
JWT 기반 stateless 세션짧은 만료, API 호출이 많고 분산 환경이 단순한 경우role 변경·계정 차단 반영 지연, 토큰 폐기 전략 필요
Access Token + Refresh Token별도 백엔드 API, 모바일 앱, 장기 세션 유지가 필요한 경우refresh token 저장 위치, 회전, 재사용 탐지, 서버 측 폐기 정책 필요
관리형 Auth Provider 세션SSO, MFA, 조직 관리, 빠른 MVP가 중요한 경우벤더 정책, 데이터 위치, 장애 대응, 커스텀 권한 모델 확인 필요

쿠키를 쓴다면 Secure, HttpOnly, SameSite, Domain, Path 범위를 운영 정책으로 정해야 합니다. OWASP Session Management Cheat Sheet는 세션 ID 보호를 위해 HTTPS와 Secure 속성, 자바스크립트 접근을 막는 HttpOnly, CSRF 방어에 도움이 되는 SameSite 설정, 과도하게 넓은 Domain 범위의 위험을 설명합니다. ([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)) SameSite는 유용하지만 모든 CSRF 방어를 대체하지는 않으므로 상태 변경 요청의 메서드, Origin 검증, CSRF 정책도 함께 봐야 합니다. ([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)) Refresh Token 구조를 쓰는 경우에는 Refresh Token 설계 가이드를 같이 확인해 보시기 바랍니다.

7. Auth.js, Clerk, Better Auth, 커스텀 세션 선택 기준

Next.js 인증 도구 선택을 비교하는 컨설팅 매트릭스
도구 선택은 기능 목록이 아니라 운영 리스크, 데이터 통제, 조직 권한 요구사항으로 판단해야 합니다.

인증 도구 선택은 “어떤 라이브러리가 더 유명한가”보다 “우리 서비스가 어떤 운영 리스크를 감당할 것인가”의 문제입니다. Auth.js는 서버 측 세션 조회와 리소스 보호 패턴을 제공하고, Next.js Proxy와 API Route 보호 예시도 문서화되어 있습니다. ([authjs.dev](https://authjs.dev/getting-started/session-management/get-session)) Clerk는 App Router 서버 측 auth(), auth.protect(), 조직 Role·Permission 검사, clerkMiddleware 기반 라우트 보호를 문서화하고 있습니다. ([clerk.com](https://clerk.com/docs/reference/nextjs/app-router/auth)) Better Auth는 Next.js RSC와 Server Actions에서 세션을 얻는 방식, Proxy에서 cookie-only check는 보안 판단이 아니라 optimistic redirect로만 써야 한다는 경고, organization plugin의 role·permission 모델을 제공합니다. ([better-auth.com](https://better-auth.com/docs/integrations/next))

선택지맞는 상황확인할 것운영 리스크
Auth.js오픈소스 기반, OAuth provider 연동, 자체 DB와 권한 모델을 직접 운영하려는 팀사용 버전, 세션 전략, adapter, RBAC 구현 위치, 보안 업데이트 정책권한·조직·감사 로그는 대부분 서비스 도메인에 맞게 직접 설계해야 함
Clerk빠른 B2B MVP, 로그인 UI, MFA, 조직 관리, Role·Permission 기능을 빠르게 붙이고 싶은 팀요금 정책, 데이터·계정 통제, 조직 모델이 우리 SaaS 모델과 맞는지, 서버 측 검증 위치벤더 종속성과 커스텀 비즈니스 권한 모델의 경계를 명확히 해야 함
Better AuthNext.js 친화적인 오픈소스 auth, organization·admin plugin, 커스텀 권한 모델을 함께 검토하는 팀프로덕션 안정성, 플러그인 성숙도, 세션 저장소, Proxy·RSC·Server Actions 연동 방식문서 예제를 그대로 복사하기보다 각 페이지·액션의 서버 측 검증을 별도 설계해야 함
커스텀 세션·백엔드 API기존 사내 IdP, 엄격한 보안·감사 요구, 여러 클라이언트가 하나의 권한 정책을 공유하는 경우세션 폐기, 비밀번호·MFA, CSRF, 감사 로그, 보안 패치, 침해 대응 프로세스초기 구현은 자유롭지만 장기 유지보수와 보안 책임이 가장 큼

도구를 선택한 뒤에도 원칙은 변하지 않습니다. 로그인 UI와 세션 발급은 도구에 맡길 수 있지만, “이 사용자가 이 고객사의 이 데이터를 이 행동으로 조작할 수 있는가”는 서비스 도메인 정책입니다. 이 정책은 문서, 테스트, DAL, 백엔드 API에 남아 있어야 합니다.

8. 관리자 화면 라우트 구조 예시

폴더 구조는 조직의 권한 모델을 설명할 수 있어야 합니다. 예를 들어 공개 페이지, 로그인 후 사용자 영역, 고객사 관리자 영역, 플랫폼 운영자 영역을 같은 /dashboard 아래에 섞으면 시간이 갈수록 예외가 늘어납니다. 다음처럼 큰 경계를 나누면 권한 매트릭스를 라우트와 연결하기 쉽습니다.

라우트 그룹의미기본 검사추가 검사
app/(public)랜딩, 가격, 로그인, 회원가입대부분 공개로그인 사용자의 로그인 페이지 재접근 리다이렉트
app/(app)로그인 사용자 공통 영역세션 필요사용자 상태, 이메일 인증, 약관 동의
app/(tenant)/[orgSlug]고객사별 SaaS 화면세션 + 조직 멤버십resource별 permission, tenant scope
app/(admin)고객사 관리자 기능세션 + 조직 admin 이상초대, 청구, 데이터 export 등 action별 권한
app/(ops)Agent, 운영자, 슈퍼 관리자 영역별도 플랫폼 권한강한 감사 로그, impersonation 제한, 재인증

중요한 점은 platform_admin과 고객사의 org_admin을 같은 권한으로 취급하지 않는 것입니다. 고객사 관리자는 자기 조직의 멤버와 데이터만 볼 수 있어야 하고, 플랫폼 운영자는 장애 대응과 고객 지원을 위해 제한적으로 접근하더라도 모든 행동이 감사 로그에 남아야 합니다. 특히 impersonation 기능은 편리하지만 사고 시 추적이 어려우므로 시작·종료 시각, 수행자, 대상 고객사, 수행 액션, 사유를 기록해야 합니다.

9. 출시 전 체크리스트

SaaS 관리자 화면 출시 전 인증 권한 체크리스트를 확인하는 PM 책상
출시 전에는 로그인 성공보다 권한 누락, 테넌트 혼선, 감사 로그 부재를 먼저 점검해야 합니다.

지원사업 MVP나 초기 SaaS에서는 인증 화면 구현에 견적이 집중되는 경우가 많습니다. 하지만 운영 중 사고를 줄이려면 로그인 페이지보다 아래 체크리스트가 먼저입니다.

  • 권한 용어표가 있는가: owner, admin, member, viewer, platform_admin의 의미가 문서화되어 있는가?
  • permission matrix가 있는가: resource와 action 기준으로 read, create, update, delete, export, invite, approve 권한을 나눴는가?
  • 테넌트 스코프가 강제되는가: 모든 DB 쿼리와 API 호출이 검증된 orgId 또는 tenantId를 기준으로 제한되는가?
  • Proxy는 UX용 초기 차단으로 쓰이는가: Proxy 통과를 보안 통과로 착각하지 않는가?
  • layout 의존을 피했는가: 페이지, leaf component, DAL에서 다시 검증하는가?
  • Server Actions 내부에 세션·권한·소유권·입력 검증이 있는가?
  • Route Handlers와 파일 다운로드 API도 별도 권한 검사를 하는가?
  • Client Component에 민감 데이터 전체 객체를 넘기지 않고 DTO로 줄였는가?
  • 세션 쿠키의 Secure, HttpOnly, SameSite, Domain, Path 정책이 운영 환경 기준으로 정리되어 있는가?
  • 역할 변경, 조직 탈퇴, 계정 차단, 비밀번호 변경 후 세션 무효화 정책이 있는가?
  • 권한 없는 접근, 다른 조직 ID 조작, 삭제 권한 부족, 만료 세션, 비활성 계정 테스트 케이스가 있는가?
  • 관리자 작업에 감사 로그가 남는가: 누가, 언제, 어느 조직에서, 무엇을, 어떤 값에서 어떤 값으로 바꿨는가?
  • 고객 지원용 임시 접근은 시간 제한과 사유 입력, 로그 조회가 가능한가?
  • 권한 변경 후 캐시와 화면 상태가 일관되게 갱신되는가?

10. AgentMit이 프로젝트 초기에 보는 부분

AgentMit은 SaaS, 관리자 화면, 자동화 백오피스, 정부지원사업 MVP를 설계할 때 로그인 화면부터 만들기보다 권한 모델과 라우트 보호 기준을 먼저 정리합니다. 특히 BizMit 기반 업무 시스템이나 B2B SaaS에서는 “관리자 화면이 있다”는 말만으로는 부족합니다. 고객사 관리자, 내부 운영자, 외부 파트너, 읽기 전용 담당자, 결제 담당자가 어떤 데이터를 볼 수 있고 어떤 버튼을 누를 수 있는지 표로 확정해야 개발 범위와 보안 기준이 함께 잡힙니다.

실제 구축을 앞두고 있다면 다음 자료를 준비해 보세요. 첫째, 사용자 유형 목록. 둘째, 고객사 또는 조직 구조. 셋째, 관리자 화면 메뉴 구조. 넷째, 데이터 변경·삭제·내보내기 기능 목록. 다섯째, 외부 API나 기존 백엔드 연동 방식입니다. 이 다섯 가지가 있으면 Auth.js, Clerk, Better Auth, 커스텀 세션 중 어떤 선택이 운영상 맞는지 더 현실적으로 판단할 수 있습니다. 구현 상담이 필요하다면 BizMit 서비스 안내제작 문의에서 프로젝트 조건을 남길 수 있습니다.

FAQ

Q1. Next.js App Router에서 인증 검사는 Proxy에만 두면 되나요?

아니요. Proxy는 로그인 여부에 따른 빠른 리다이렉트나 큰 라우트 그룹 차단에는 유용하지만, 데이터 보호의 유일한 장치가 되면 안 됩니다. 페이지, DAL, Server Actions, Route Handlers, 백엔드 API에서도 각각 필요한 인증·권한 검사를 해야 합니다.

Q2. 관리자 메뉴를 Client Component에서 숨기면 권한 처리가 된 건가요?

아닙니다. 메뉴 숨김은 사용자 경험 개선일 뿐 보안 통제가 아닙니다. 사용자는 브라우저 개발자 도구나 직접 요청으로 API와 Server Action을 호출할 수 있으므로 서버 측에서 role, permission, tenant, resource ownership을 다시 확인해야 합니다.

Q3. Server Actions에도 권한 검사가 필요한가요?

필요합니다. Server Actions는 UI 버튼에서만 호출되는 함수처럼 보이지만 네트워크 요청으로 호출될 수 있는 서버 측 엔드포인트입니다. 데이터 변경 전에는 항상 세션 확인, 권한 확인, 객체 소유권 확인, 입력 검증을 실행해야 합니다.

Q4. SaaS에서 tenantId나 orgId는 URL 파라미터를 믿어도 되나요?

믿으면 안 됩니다. URL의 orgSlug, orgId, projectId는 조회 대상 힌트일 뿐입니다. 검증된 세션에서 사용자의 활성 조직과 멤버십을 확인하고, 모든 쿼리에 tenant scope를 강제해야 고객사 간 데이터 노출을 줄일 수 있습니다.

Q5. Auth.js, Clerk, Better Auth, 커스텀 세션 중 무엇을 선택해야 하나요?

도구보다 운영 조건을 먼저 봐야 합니다. 빠른 B2B MVP와 조직 기능이 중요하면 관리형 도구가 유리할 수 있고, 데이터 통제와 커스터마이징이 중요하면 오픈소스 또는 커스텀 구조가 맞을 수 있습니다. 다만 어떤 도구를 쓰든 최종 권한 검사는 서버와 데이터 계층에 남겨야 합니다.

참고한 공식 자료

  • Next.js 공식 문서: Authentication, Proxy, Mutating Data, Data Security 문서를 통해 App Router 기준의 권한 검사 위치와 Server Actions 보안 전제를 확인했습니다.
  • Auth.js, Clerk, Better Auth 공식 문서: 각 도구의 Next.js App Router 연동, 서버 측 세션 확인, Proxy 또는 middleware 보호 패턴, 조직·권한 기능을 확인했습니다.
  • OWASP Cheat Sheet Series: 요청별 접근 제어, 객체 단위 권한 확인, 세션 쿠키 보안 속성, SameSite와 CSRF 방어 한계를 확인했습니다.

자주 묻는 질문

Next.js App Router에서 인증 검사는 Proxy에만 두면 되나요?
아니요. Proxy는 로그인 여부에 따른 빠른 리다이렉트나 큰 라우트 그룹 차단에는 유용하지만, 데이터 보호의 유일한 장치가 되면 안 됩니다. 페이지, DAL, Server Actions, Route Handlers, 백엔드 API에서도 각각 필요한 인증·권한 검사를 해야 합니다.
관리자 메뉴를 Client Component에서 숨기면 권한 처리가 된 건가요?
아닙니다. 메뉴 숨김은 사용자 경험 개선일 뿐 보안 통제가 아닙니다. 사용자는 브라우저 개발자 도구나 직접 요청으로 API와 Server Action을 호출할 수 있으므로 서버 측에서 role, permission, tenant, resource ownership을 다시 확인해야 합니다.
Server Actions에도 권한 검사가 필요한가요?
필요합니다. Server Actions는 UI 버튼에서만 호출되는 함수처럼 보이지만 네트워크 요청으로 호출될 수 있는 서버 측 엔드포인트입니다. 데이터 변경 전에는 항상 세션 확인, 권한 확인, 객체 소유권 확인, 입력 검증을 실행해야 합니다.
SaaS에서 tenantId나 orgId는 URL 파라미터를 믿어도 되나요?
믿으면 안 됩니다. URL의 orgSlug, orgId, projectId는 조회 대상 힌트일 뿐입니다. 검증된 세션에서 사용자의 활성 조직과 멤버십을 확인하고, 모든 쿼리에 tenant scope를 강제해야 고객사 간 데이터 노출을 줄일 수 있습니다.
Auth.js, Clerk, Better Auth, 커스텀 세션 중 무엇을 선택해야 하나요?
도구보다 운영 조건을 먼저 봐야 합니다. 빠른 B2B MVP와 조직 기능이 중요하면 관리형 도구가 유리할 수 있고, 데이터 통제와 커스터마이징이 중요하면 오픈소스 또는 커스텀 구조가 맞을 수 있습니다. 다만 어떤 도구를 쓰든 최종 권한 검사는 서버와 데이터 계층에 남겨야 합니다.
  • Company. 주식회사 에이전트밋
  • Addr.부산광역시 부산진구 서전로 8, 6층 101호(부전동) CEO. 윤성훈 Email. agentmit@naver.com
  • BR. 333-87-04232 TEL. 0507-1314-2790
Copyright © 2026 ~ 에이전트밋. All rights reserved.