실제 시스템 설계: 인증, RBAC, 및 멀티 테넌트 아키텍처 (Part 1)

발행: (2025년 12월 22일 오후 08:04 GMT+9)
6 min read
원문: Dev.to

Source: Dev.to

Why This Series?

대부분의 튜토리얼은 다음과 같이 보여줍니다:

  • “JWT 인증 추가”
  • “라우트 보호”
  • “admin, user 같은 역할 생성”

하지만 실제 시스템에서는 더 어려운 질문에 답해야 합니다:

  • 여러 조직(테넌트)에 대한 인증을 어떻게 설계할까?
  • 부서나 프로젝트마다 역할이 어떻게 달라질까?
  • 권한 폭발을 어떻게 방지할까?
  • 나중에 모든 코드를 다시 쓰지 않고 RBAC를 어떻게 확장할까?

우리는 이러한 문제들을 단계별로 해결할 것입니다.

The Core Building Blocks

1. Authentication (Who are you?)

Authentication은 한 가지 질문에 답합니다:

이 요청을 만든 사람은 누구인가?

일반적인 접근 방식:

  • 이메일/비밀번호
  • OAuth (Google, GitHub, SSO)
  • 토큰 기반 인증 (JWT, 불투명 토큰)
  • 세션 기반 인증

⚠️ Authentication은 무엇을 할 수 있는지를 결정하지 않습니다. 단지 신원을 증명할 뿐입니다.

2. Authorization & RBAC (What are you allowed to do?)

Authorization은 다음 질문에 답합니다:

이 인증된 사용자가 어떤 리소스에 접근하거나 수정할 수 있는가?

RBAC는 가장 널리 사용되는 모델입니다:

Users → Roles → Permissions

실제 시스템에서는:

  • 역할이 테넌트마다 다름
  • 권한이 상황(context)마다 다름
  • 일부 행동은 소유권이나 계층 구조에 따라 달라짐

우리는 다음을 살펴볼 것입니다:

  • 간단한 RBAC
  • 역할‑권한 매핑
  • 상황 인식 권한
  • RBAC가 깨지는 경우와 대신 사용할 수 있는 방법

3. Multi‑Tenant Architecture (Where do you belong?)

멀티‑테넌시는 다음 질문에 답합니다:

이 사용자의 데이터와 규칙은 어느 조직에 적용되는가?

전형적인 예시:

  • SaaS 제품
  • 엔터프라이즈 도구
  • 여러 기업이 사용하는 내부 플랫폼

핵심 과제:

  • 데이터 격리
  • 테넌트별 역할 및 권한
  • 로직 중복 없이 확장성 확보
  • 교차 테넌트 접근 버그 방지

여기서 한 번이라도 체크를 놓치면 보안 사고가 될 수 있습니다.

A Real‑World Example We’ll Build On

이 시리즈 전체에 걸쳐, 우리는 현실적인 시나리오를 사용할 것입니다: 여러 회사를 대상으로 하는 SaaS 플랫폼. 각 회사는 부서, 사용자, 역할, 권한을 가집니다.

High‑level structure

Organization (Tenant)
 └── Company
     └── Department
         └── Users
             └── Roles
                 └── Permissions

Rules

  • 사용자는 하나의 테넌트에 속한다
  • 역할은 테넌트별로 정의된다
  • 권한은 기능 및 데이터 접근을 제어한다
  • 접근은 역할과 상황(context) 모두에 의존한다

이는 많은 엔터프라이즈 시스템이 실제로 작동하는 방식을 반영합니다.

Common Mistakes Teams Make Early

  • ❌ 역할을 하드코딩 (if user.role === 'admin' 등)
  • ❌ 전역 관리자 역할이 하나라고 가정
  • ❌ 인증과 인가 로직을 혼합
  • ❌ 쿼리에서 테넌트 경계를 무시
  • ❌ 기능이 늘어나고 난 뒤에야 RBAC를 설계

이 시리즈는 이러한 함정을 피하도록 도와줄 것입니다.

What This Series Will Cover

Authentication in Real Systems

  • JWT vs. 세션
  • 토큰 수명 주기
  • 안전한 로그인 흐름

Designing RBAC That Scales

  • 역할 vs. 권한 설계
  • 데이터베이스 스키마 패턴
  • 역할 폭발 방지

Multi‑Tenant Authorization

  • 테넌트 격리 전략
  • 쿼리 수준 보안
  • 미들웨어 패턴

Advanced Patterns

  • 정책 기반 접근 제어 (Policy‑based access control)
  • 속성 기반 접근 제어 (ABAC)
  • 기능 플래그 & 권한 게이트

Common Security Pitfalls

  • 권한 상승 버그
  • 안전하지 않은 기본값
  • 인가 테스트 전략

Who This Series Is For

  • 백엔드 엔지니어
  • SaaS 제품 개발자
  • API 설계자
  • 구현 방법뿐 아니라 이런 패턴이 존재하는지 이해하고 싶은 모든 사람

백엔드 개발에 대한 기본적인 이해를 전제로 하지만, 개념은 모든 스택에 적용됩니다.

What’s Next

Part 2에서는 멀티‑테넌트 시스템에서의 인증 설계—신원, 토큰, 테넌트 컨텍스트를 처음부터 올바르게 구조화하는 방법—에 대해 시작합니다.

실제 시스템 설계 패턴에 관심이 있다면, 계속해서 따라와 주세요.

Back to Blog

관련 글

더 보기 »