멀티테넌트 데이터베이스 아키텍처란?

멀티테넌트 데이터베이스 아키텍처는 여러 고객을 하나의 데이터 계층에 저장하고 행, 스키마, 별도 데이터베이스 단위로 격리하는 설계 방식입니다. 이 세 가지 격리 수준이 결정 공간의 전부입니다. 이 주제의 나머지는 모두 그 결과입니다. 마이그레이션이 어떻게 실행되는지, 복원에 드는 비용은 얼마인지, 노이지 네이버(noisy neighbor)가 어디에 있는지, 각 패턴이 어디까지 확장되는지가 그렇습니다.

핵심 요약

SQL로 보는 세 가지 패턴

-- 패턴 1 · 공유 스키마("pool"): 하나의 테이블 집합, 모든 행에 테넌트
CREATE TABLE invoices (
  tenant_id uuid   NOT NULL,
  id        bigint GENERATED ALWAYS AS IDENTITY,
  total     numeric(10,2),
  PRIMARY KEY (tenant_id, id)      -- 테넌트가 선두: 인덱스와 샤딩에 대비
);
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_rows ON invoices
  USING (tenant_id = current_setting('app.tenant')::uuid);

-- 패턴 2 · 테넌트별 스키마("bridge"): 하나의 데이터베이스, 테넌트마다 네임스페이스
CREATE SCHEMA tenant_acme;          -- 같은 테이블을 테넌트마다 반복

-- 패턴 3 · 테넌트별 데이터베이스("silo"): 완전한 물리적 분리
CREATE DATABASE tenant_acme;        -- 가장 강한 격리, 모든 것이 N개

관리형 백엔드에서는 같은 보장을 SQL 없이 표현합니다. 접근 제어가 데이터 자체에 있으므로 API, 대시보드, SDK 등 모든 경로에서 격리가 유지됩니다:

// JavaScript / Node.js — Back4app JS SDK
// The same query for every tenant — ACLs scope results server-side
const query = new Parse.Query('Invoice');
const invoices = await query.find({ sessionToken: user.getSessionToken() });
// Only rows this tenant's role can read come back. No WHERE clause to forget.

// Flutter / Dart — Back4app Flutter SDK
// The same query for every tenant — ACLs scope results server-side
final query = QueryBuilder<ParseObject>(ParseObject('Invoice'));
final response = await query.query();
// The session's role decides which rows exist, before results leave the server
if (response.success) {
  print('${response.results?.length} invoices visible to this tenant');
}

// iOS / Swift — Back4app Swift SDK
// The same query for every tenant — ACLs scope results server-side
let query = Invoice.query()
query.find { result in
  if case .success(let invoices) = result {
    print("\(invoices.count) invoices visible to this tenant")
  }
}

// Android / Kotlin — Back4app Android SDK
// The same query for every tenant — ACLs scope results server-side
val query = ParseQuery.getQuery<ParseObject>("Invoice")
query.findInBackground { invoices, e ->
  if (e == null) {
    Log.d("Billing", "${invoices.size} invoices visible to this tenant")
  }
}

공유 스키마 vs. 테넌트별 스키마 vs. 테넌트별 데이터베이스

발목을 잡는 세부 사항

• 인덱스는 테넌트 우선입니다. tenant_id는 조인 때문에 중복처럼 보이는 곳까지 포함해 모든 테이블에 두고, 모든 복합 인덱스의 맨 앞에 배치합니다. 순서는 (tenant_id, created_at)이며 그 반대가 아닙니다. 실제 쿼리는 모두 한 테넌트로 범위가 제한되므로 인덱스도 그래야 합니다.
• 마이그레이션은 격리 수준만큼 늘어납니다. silo의 유연성에는 오케스트레이션 계층이라는 비용이 따릅니다. 테넌트별 버전 추적, 재시도 로직, 드리프트 감지가 필요합니다. 팀들이 표의 어떤 행보다도 과소평가하는 부분입니다.
• 행 수준 보안에는 운영상의 세부 조항이 있습니다. 정책은 연결 단위 설정을 기준으로 삼는데, 이 설정은 커넥션 풀링 모드와 상호작용합니다. 테넌트는 트랜잭션 단위로 설정하고 풀러를 테스트해야 합니다. 어떤 역할이 RLS를 우회하는지도 감사해야 합니다. 슈퍼유저 경로는 전형적인 허점입니다.
• 연결 수 계산. 테넌트 데이터베이스마다 풀을 두면 연결이 금세 고갈됩니다. 공유 스키마 설계는 하나의 풀을 공유합니다. 규모가 커져야 비로소 드러나는 pool 패턴의 또 다른 조용한 장점입니다.
• 복원의 비대칭이 등급화를 이끕니다. “우리 데이터만 어제 시점으로 복원할 수 있습니까?”는 엔터프라이즈 계약에서 나오는 질문입니다. 답이 반드시 “예”여야 한다면 그 테넌트는 silo에 속하며, 이는 곧바로 하이브리드로 이어집니다.

확장과 하이브리드 최종 형태

pool 패턴의 성장 경로는 테넌트 기준 샤딩입니다. 공유 스키마 데이터베이스 여러 개가 각각 테넌트의 일부를 담고, 카탈로그가 테넌트 → 샤드를 대응시킵니다(오픈소스 Citus는 이를 PostgreSQL에 내장했으며, 부하가 큰 테넌트를 전용 노드로 옮기는 기능도 포함합니다). 등급화와 결합하면 대부분의 성숙한 SaaS가 수렴하는 아키텍처가 됩니다. 무료 등급은 pool에, 중간 규모 테넌트는 여러 샤드에 걸친 pool에, 소수의 규제 대상이거나 거대한 테넌트는 silo에 둡니다. 모든 곳의 모든 스키마에 tenant_id를 유지하므로, 어떤 테넌트든 구조를 뜯어고치지 않고 등급 사이를 옮길 수 있습니다. 테넌트 이동성은 첫날부터 설계해야 하는 속성이며, 나중에 덧붙이기는 거의 불가능합니다.

일반적인 사용 사례

• B2B SaaS. 대표적인 사례입니다. 제품 안의 모든 워크스페이스, 조직, 팀이 이 패턴들 중 하나의 테넌트입니다.
• 대규모 부분 유료화(freemium) 제품. 수천 개의 작은 무료 테넌트를 거의 0에 가까운 한계 비용으로 pool에 담습니다. 무료 등급을 가능하게 하는 경제성입니다.
• 규제 산업. 의료, 금융, 법률 고객은 계약상 silo를 요구하며, 하이브리드를 통해 같은 코드베이스에서 서비스됩니다.
• 에이전시와 플랫폼. 하나의 애플리케이션이 여러 고객 조직을 서비스하고, 각 조직은 자체 경계를 가집니다.
• 사내 멀티팀 플랫폼. 공유 도구 위의 부서가 테넌트입니다. 패턴은 같고 위협 모델은 더 온건합니다.

어떤 패턴을 선택해야 할까? 결정 매트릭스

그리고 메타 답변이 있습니다. 회사 단위가 아니라 등급 단위로 선택해야 합니다. 하이브리드 설계는 각 테넌트를 요구 사항을 충족하는 가장 저렴한 패턴에 두고, 요구 사항이 바뀌면 옮깁니다.

한계와 트레이드오프

• 공유 스키마: 데이터베이스가 강제하는 격리가 가장 절실한 패턴입니다. 필터 하나만 빠져도 침해이므로, RLS나 데이터 계층 ACL은 선택적인 보안 강화가 아니라 타협할 수 없는 요건입니다.
• 테넌트별 스키마: 어정쩡한 중간 지대입니다. 마이그레이션 오케스트레이션은 silo만큼 필요한데 격리는 silo보다 약하고, 데이터베이스 메타데이터 한계는 의외로 일찍 찾아옵니다.
• 테넌트별 데이터베이스: 마이그레이션, 백업, 모니터링, 연결, 비용 등 모든 것이 × N이 되며, 테넌트 간 분석은 하나의 데이터 엔지니어링 프로젝트가 됩니다.
• 세 가지 모두: 테넌트 컨텍스트가 쿼리, 캐시, 작업, 로그 등 모든 곳에 스며듭니다. 그리고 첫날부터 ID 규율(전역적으로 고유한 식별자, silo를 포함한 모든 곳의 tenant_id 열)을 지키지 않으면 패턴 간 이동에 큰 비용이 듭니다.

Back4app에서의 멀티테넌트 데이터

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 이 글의 철칙인 “격리는 데이터베이스에서 강제한다”에 대한 Back4app의 답은 객체별 ACL, 테넌트별 역할, 클래스 수준 권한이며, 위 코드 탭에서 본 것처럼 플랫폼이 모든 표면에서 들어오는 모든 요청마다 이를 확인합니다. WHERE 절의 위험을 제거한 공유 스키마 패턴인 셈입니다. 행 수준 보안에 관한 엔지니어링 심층 분석은 문서 데이터베이스에서의 전체 패턴을 단계별로 보여 주며, 같은 주제의 호스팅 수준 관점은 그 위의 인프라 계층을 다룹니다.