멀티테넌트 (Multi-tenant) 데이터베이스 구조

핵심 인사이트 (3줄 요약)

1. 본질: 멀티테넌트(Multi-tenant) 데이터베이스 아키텍처는 하나의 클라우드 애플리케이션(SaaS)을 이용하는 **여러 독립적인 고객사(Tenant)**들의 데이터를 어떻게 효율적으로 저장하고 안전하게 격리(Isolation)할 것인가를 결정하는 물리적/논리적 설계 전략이다.
2. 가치: 인프라 비용(서버, 라이선스) 절감을 극대화하려면 모든 고객 데이터를 한곳에 섞어 담아야 하고, 보안과 장애 격리를 극대화하려면 고객마다 DB를 아예 따로 주어야 한다. 멀티테넌트 설계는 이 비용 효율성(Cost)과 격리성(Isolation) 사이의 트레이드오프를 조율하는 핵심 가이드다.
3. 융합: 일반적으로 데이터베이스 분리(Silo), 스키마 분리(Bridge), 단일 테이블 내 Row 레벨 분리(Pool)라는 3가지 기본 패턴이 존재하며, 최근에는 Row Level Security(RLS) 같은 RDBMS 기술 및 AWS Aurora와 같은 서버리스 DB 기술과 융합되어 보안과 비용 두 마리 토끼를 잡고 있다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

• 개념: 테넌트(Tenant)는 '세입자'라는 뜻으로, 클라우드 서비스를 구독하는 각 고객사(A기업, B기업)를 말한다. 멀티테넌시는 이 세입자들을 하나의 건물(소프트웨어/인프라)에 입주시켜 자원을 공유하게 만드는 방식이다. 이때 가장 중요한 것이 '세입자들끼리 짐(데이터)이 섞이지 않도록 방과 서랍장을 어떻게 짤 것인가' 하는 데이터베이스 아키텍처다.

• 필요성: 만약 B2B SaaS 기업(예: 슬랙, 세일즈포스)이 고객사가 가입할 때마다 EC2 서버 1대와 RDS 데이터베이스 1개를 새로 만들어준다면(Single-tenant), 1만 개의 고객사를 유치했을 때 관리해야 할 서버와 DB가 1만 개가 된다. 이는 폭발적인 인프라 비용과 버전 업데이트의 불가능이라는 참사를 부른다. 따라서 단일 시스템의 코어 엔진을 유지하면서 수만 개의 고객 데이터를 우아하게 수용할 데이터베이스 설계 패턴이 필수적이다.

• 💡 비유: 대형 아파트(SaaS)를 지을 때, 세입자(고객사)마다 아예 다른 건물을 지어줄 것인지(DB 분리), 같은 건물 안에 살되 층수와 현관문 번호를 완벽히 나눌 것인지(스키마 분리), 아니면 큰 강당 하나에 다 같이 모여 살되 각자 물건에 자기 이름표 스티커만 붙여놓게 할 것인지(Row 레벨 분리)를 결정하는 것이 바로 멀티테넌트 설계입니다.

• 등장 배경 및 발전 과정:

  1. ASP 및 패키지 소프트웨어 시대: 과거에는 기업마다 서버를 구매해 전산실에 넣고 소프트웨어를 설치했다 (완벽한 단일 테넌트). 보안은 좋았으나 유지보수 비용이 막대했다.
  2. 초기 SaaS의 Shared DB 도입: Salesforce 같은 SaaS 선구자들은 수백만 유저의 데이터를 하나의 거대 DB 테이블에 넣고 tenant_id 컬럼으로 구분하는 풀(Pool) 방식을 채택하여 미친 듯한 이익률(마진)을 달성했다.
  3. 규제 준수와 하이브리드 진화: GDPR, 망분리 등 보안 규제가 강해지면서, VIP 고객에게는 독자 DB를 주고, 일반 고객은 공유 DB를 쓰는 하이브리드 멀티테넌트 아키텍처가 현대 B2B SaaS의 표준으로 자리 잡았다.

• 📢 섹션 요약 비유: 호텔을 운영할 때, 돈 많은 VIP 손님에게는 수영장 딸린 독채 풀빌라를 내어주고, 배낭여행객들은 게스트하우스의 큰 방 하나에 침대만 쪼개서 자게 하는 것처럼, 고객이 내는 돈(비용)과 원하는 사생활 보호(격리성) 수준에 맞춰 방의 구조를 다르게 짜는 전략입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

멀티테넌트 데이터베이스 3대 아키텍처 모델

비용 효율성(Cost)과 데이터 격리성(Isolation)을 기준으로 3가지 모델(Silo, Bridge, Pool)로 분류한다.

  ┌───────────────────────────────────────────────────────────────┐
  │         멀티테넌트 데이터베이스 3가지 핵심 아키텍처 비교             │
  ├───────────────────────────────────────────────────────────────┤
  │                                                               │
  │  [1] Database per Tenant (Silo 모델 / 인스턴스 분리)            │
  │   - 각 고객사마다 물리적/논리적으로 완전히 분리된 DB 인스턴스 할당.         │
  │   - App ─▶ [ DB A (A기업) ] , [ DB B (B기업) ] , [ DB C (C기업) ] │
  │   - 특징: 완벽한 보안, 장애 격리. but 인프라 비용 극상, 스키마 마이그레이션 지옥.│
  │                                                               │
  │  [2] Schema per Tenant (Bridge 모델 / 스키마 분리)              │
  │   - DB 인스턴스 1대 안에, 고객사마다 독립적인 스키마(Schema) 생성.        │
  │   - App ─▶ [ 단일 DB ( Schema A | Schema B | Schema C ) ]     │
  │   - 특징: DB 엔진은 공유하여 비용 절감, 테이블 이름 공간은 분리되어 데이터 혼재 방어.│
  │                                                               │
  │  [3] Shared Database, Shared Schema (Pool 모델 / Row 분리)      │
  │   - 모든 고객사가 완벽히 똑같은 1개의 테이블에 데이터를 쏟아넣음.            │
  │   - App ─▶ [ 단일 DB ( Table: Users ) ]                        │
  │             └─ Row 1: (TenantID=A, Name=Kim)                  │
  │             └─ Row 2: (TenantID=B, Name=Lee)                  │
  │             └─ Row 3: (TenantID=A, Name=Park)                 │
  │   - 특징: 인프라 효율성 극대화, 테이블 스키마 변경 용이. but 개발자 실수 시  │
  │           타사 데이터 유출 가능성(Noisy Neighbor) 위험.           │
  └───────────────────────────────────────────────────────────────┘

아키텍처별 트레이드오프 상세 분석

[핵심 기술 원리: Row Level Security (RLS)] 최근 3번(Pool) 모델의 최대 약점인 "개발자가 SQL 쿼리에서 WHERE tenant_id = 'A' 조건을 빼먹으면 남의 회사 데이터가 털린다"는 보안 리스크를 막기 위해, PostgreSQL 같은 RDBMS가 제공하는 RLS (Row Level Security) 기능이 각광받고 있다. RLS를 켜두면, 애플리케이션 코드가 아니라 DB 엔진단에서 접속된 계정의 권한을 보고 자기가 속한 테넌트의 Row(행) 외에는 아예 보이지 않게 강제로 필터링해 버려, 보안 사고를 원천 차단한다.

Ⅲ. 실무 적용 및 기술사적 판단

실무 시나리오

1. 시나리오 — 시끄러운 이웃 (Noisy Neighbor) 문제 발생: SaaS 스타트업이 비용을 아끼고자 3번 Pool 모델(단일 테이블 공유)로 서비스를 런칭했다. 어느 날 초대형 고객사 A가 들어와 수백만 건의 데이터를 쏟아붓고 무거운 통계 쿼리(Group by)를 돌리자, 같은 테이블을 쓰는 중소 고객사 수백 곳의 서비스 접속이 일제히 타임아웃 되며 뻗어버린 상황.

   • 판단: 자원을 완벽하게 공유하는 Pool 모델의 치명적인 한계인 '시끄러운 이웃(Noisy Neighbor)' 문제다. 한 명의 세입자가 건물의 수도관을 다 써버리면 남들이 물을 못 쓰는 것과 같다.
   • 해결책: 데이터 파티셔닝(Sharding) 설계가 필요하다. VIP 고객사(A기업)의 트래픽을 감지하여, 백그라운드에서 A기업의 데이터만 별도의 격리된 전용 DB(Silo 모델)로 분리 이전(Migration) 시켜주거나, 애플리케이션의 API 게이트웨이 단에서 테넌트별로 초당 쿼리 수(Throttling/Rate Limit)를 제한하여 자원 독식을 물리적으로 막아내야 한다.

2. 시나리오 — 극단적인 규제 도메인 (의료 데이터): 전 세계 병원들의 환자 차트를 관리하는 클라우드 EMR(전자 의무 기록) 시스템을 구축하려 한다. 개발팀은 유지보수가 쉬운 Pool(공유 DB) 모델을 제안했지만, 병원장들은 "우리 병원 환자 데이터가 다른 병원 데이터와 같은 하드디스크 조각에 섞여 있다는 건 절대 용납 못 한다"고 반대하는 상황.

   • 판단: 의료(HIPAA 규제), 방산, 금융 데이터는 논리적 격리(RLS나 스키마 분리)만으로는 심리적/법적 규제를 통과할 수 없는 경우가 많다.
   • 해결책: 철저하게 1번 Silo(DB 분리) 모델로 가야 한다. 단, 인프라 비용과 관리의 악몽을 덜기 위해 인프라를 코드(IaC, Terraform)로 선언하여 새 병원이 가입할 때마다 완벽하게 자동화된 파이프라인이 1개의 전용 VPC와 1개의 전용 RDS 인스턴스를 찍어내도록 자동화된 Silo 팩토리 아키텍처를 구축해야 한다.

도입 체크리스트

• 비즈니스적: 우리 SaaS의 수익 모델(Pricing)이 어떻게 짜여 있는가? (구독료를 월 10만 원 내는 고객 1만 개라면 무조건 공유(Pool) 모델로 뭉쳐야 하고, 월 1억 원을 내는 엔터프라이즈 고객 10개라면 무조건 격리(Silo) 모델로 대우해 줘야 한다.)
• 아키텍처적: 어떤 모델을 쓰든 데이터베이스 연결(Connection String)과 라우팅을 클라이언트 코드에 하드코딩하지 않고, JWT 토큰(Claim 내에 tenant_id 포함)을 해석하여 백엔드 프레임워크 층(예: Hibernate Multi-tenancy 설정)에서 알아서 올바른 DB/스키마/Row로 동적 스위칭해 주는 로직이 구현되어 있는가?

안티패턴

• 프랑켄슈타인 테넌시 (하이브리드의 실패): 1번 모델과 3번 모델을 섞어 쓰는 것은 훌륭한 전략이나, 테이블 스키마 버전을 한 번에 맞추는 자동화된 마이그레이션(Flyway, Liquibase) 도구 없이 사람이 수동으로 "A기업 DB 업데이트하고, B기업 DB 업데이트하고..." 하다 보면, 어떤 DB는 v1.0이고 어떤 DB는 v1.5가 되어 백엔드 코드가 호환되지 않아 전면 장애가 발생하는 패턴이다.

Ⅳ. 기대효과 및 결론

정량/정성 기대효과

멀티테넌트 아키텍처는 소프트웨어가 '용역'에서 '서비스(SaaS)'로 진화하기 위한 필수 관문이다. 기술사는 개발팀의 "코딩하기 편한 구조"와 재무팀의 "비용 절감", 그리고 영업팀의 "엔터프라이즈 고객의 보안 우려 불식"이라는 상충되는 세 가지 요구를 하나의 테이블 위에 올려놓고, 데이터의 격리 수준(Isolation Level)을 비즈니스 티어(Tier)에 따라 동적으로 라우팅해주는 똑똑한 데이터 아키텍처를 설계해야 한다.

📌 관련 개념 맵 (Knowledge Graph)

👶 어린이를 위한 3줄 비유 설명

1. 체육관에 친구들 100명이 놀러 왔어요. 첫 번째 방법은 친구마다 100개의 작은 텐트를 각각 쳐주는 거예요 (Silo 방식). 돈이 많이 들지만 완벽한 개인 공간이 생기죠.
2. 두 번째 방법은 하나의 큰 텐트를 치고 그 안에 커튼으로 100개의 칸막이를 치는 거예요 (Bridge 방식). 돈은 좀 아꼈지만 옆방 소리가 살짝 들려요.
3. 세 번째 방법은 칸막이도 없이 그냥 아주 넓은 강당에 100명을 풀어놓고, 자기 등에 이름표만 붙이고 놀게 하는 거예요 (Pool 방식). 가장 돈이 안 들고 공간이 넓지만, 친구들끼리 부딪히고 가방이 섞일 위험이 있는 방식이랍니다!