멀티테넌트 데이터베이스 모델: Silo, Pool, Bridge

서비스 하나를 여러 고객이나 조직이 함께 사용하는 시스템을 만들 때 중요한 문제가 있습니다.

서로 다른 고객의 데이터를 어떻게 분리해서 저장할 것인가?

예를 들어 하나의 게임 운영 플랫폼을 여러 게임 회사가 사용한다고 생각해보겠습니다.

게임회사 A → 천국게임즈
게임회사 B → 드래곤게임즈
게임회사 C → 슬라임게임즈

이 세 회사가 동일한 SaaS 서비스를 사용하지만 회사 A의 플레이어 데이터가 회사 B에게 보여서는 안 됩니다.

이처럼 하나의 서비스를 여러 독립적인 사용자 그룹이 사용하는 구조를 멀티테넌트(Multi-tenant) 구조라고 합니다.

여기서 각각의 고객이나 조직을 **Tenant(테넌트)**라고 합니다.

Tenant A → 천국게임즈
Tenant B → 드래곤게임즈
Tenant C → 슬라임게임즈

멀티테넌트 환경에서 데이터와 인프라를 어떻게 격리하고 공유할지를 설계하는 대표적인 방식으로 Silo Model, Pool Model, Bridge Model이 있습니다. AWS 역시 Silo를 전용 리소스 방식, Pool을 공유 리소스 방식, Bridge를 두 방식을 조합하는 하이브리드 방식으로 설명합니다.

---

먼저 Tenant란?

게임 SaaS 서비스를 만든다고 가정해보겠습니다.

이 서비스를 세 게임 회사가 사용합니다.

tenant_id	회사	운영 게임
1	천국게임즈	천상의 기사
2	드래곤게임즈	드래곤 월드
3	슬라임게임즈	슬라임 RPG

각 회사는 같은 서비스를 사용하지만 데이터는 서로 독립적으로 관리되어야 합니다.

예를 들어 플레이어 데이터가 다음과 같습니다.

천국게임즈

player_id	nickname	level
1	천기사	35
2	성기사	42

드래곤게임즈

player_id	nickname	level
1	용기사	28
2	흑룡	51

슬라임게임즈

player_id	nickname	level
1	슬라임왕	17
2	킹슬라임	26

같은 player_id = 1이 존재하더라도 서로 다른 회사의 플레이어입니다.

따라서 시스템은 항상

이 데이터가 어느 Tenant의 데이터인가?

를 구별할 수 있어야 합니다.

---

세 가지 모델을 먼저 비교해보기

가장 단순하게 표현하면 다음과 같습니다.

Silo Model

Tenant A → 전용 공간
Tenant B → 전용 공간
Tenant C → 전용 공간

즉 핵심은 얼마나 공유하고 얼마나 분리할 것인가입니다. AWS의 정의에서도 Silo는 tenant별 전용 리소스, Pool은 여러 tenant가 공유하는 리소스, Bridge는 두 패턴을 필요한 영역에 각각 적용하는 방식입니다.

---

Silo Model

Silo Model은 Tenant마다 리소스를 별도로 제공하는 방식입니다.

데이터베이스 관점에서 가장 직관적인 형태는 Tenant마다 데이터베이스를 따로 만드는 것입니다.

천국게임즈
    ↓
Database_A

드래곤게임즈
    ↓
Database_B

슬라임게임즈
    ↓
Database_C

AWS 역시 별도의 데이터베이스 또는 완전히 독립된 인프라 스택을 tenant별로 제공하는 방식을 Silo의 대표적인 형태로 설명합니다.

---

Silo Model 데이터 구조

예를 들어 Tenant A를 위한 데이터베이스가 있습니다.

Database_A

player

player_id	nickname	level
1	천기사	35
2	성기사	42

그리고 Tenant B는 완전히 다른 데이터베이스를 사용합니다.

Database_B

player

player_id	nickname	level
1	용기사	28
2	흑룡	51

Tenant C 역시 별도의 데이터베이스를 사용합니다.

Database_C

player

player_id	nickname	level
1	슬라임왕	17

구조를 그림으로 나타내면 다음과 같습니다.

각 Tenant의 데이터가 물리적으로 분리되어 있습니다.

---

Silo Model의 장점

가장 큰 장점은 강한 격리입니다.

Tenant A와 B가 서로 다른 데이터베이스를 사용한다면 애플리케이션 쿼리에서 실수로 다른 Tenant의 행을 조회할 가능성을 구조적으로 줄일 수 있습니다.

또 특정 Tenant만 백업하거나 장애를 분석하고 성능을 조절하는 것도 비교적 독립적으로 처리할 수 있습니다.

예를 들어 다음과 같은 상황입니다.

Tenant A

player 100만 명
접속량 매우 높음

        ↓

DB_A만 Scale Up

다른 Tenant의 데이터베이스는 그대로 둘 수 있습니다.

---

Silo Model의 단점

반대로 Tenant 수가 많아질수록 관리해야 하는 리소스도 증가합니다.

Tenant가 3개라면

DB 3개

이지만,

Tenant가 10,000개라면 단순한 Database-per-Tenant 설계에서는 관리 대상도 매우 크게 증가할 수 있습니다.

예를 들어 모든 Tenant의 Player 테이블에 새로운 컬럼을 추가한다고 생각해봅시다.

ALTER TABLE player
ADD COLUMN last_login_at TIMESTAMP;

Tenant별 데이터베이스를 완전히 따로 관리한다면 이 스키마 변경을 모든 데이터베이스에 일관되게 배포하는 운영 체계가 필요합니다.

그래서 Silo는 격리 측면에서는 유리하지만 공유 인프라를 사용하는 Pool보다 비용 효율과 대규모 운영 측면에서 불리할 수 있습니다. AWS도 Pool 모델의 주요 동기로 공유 인프라를 통한 비용 효율, 관리성, 민첩성을 설명합니다.

---

Pool Model

Pool Model은 여러 Tenant가 같은 리소스를 공유하는 방식입니다.

데이터베이스에서는 흔히 다음과 같은 구조로 구현할 수 있습니다.

즉 모든 Tenant의 데이터를 같은 테이블에 넣습니다.

그 대신 각 행에

tenant_id

를 저장해 Tenant를 구분합니다.

Pool은 여러 Tenant가 동일한 인프라를 공유하는 전형적인 멀티테넌트 패턴입니다.

---

Pool Model의 실제 테이블

Player 테이블이 하나만 존재합니다.

player

tenant_id	player_id	nickname	level
1	1	천기사	35
1	2	성기사	42
2	1	용기사	28
2	2	흑룡	51
3	1	슬라임왕	17

여기에서

tenant_id = 1
→ 천국게임즈

tenant_id = 2
→ 드래곤게임즈

tenant_id = 3
→ 슬라임게임즈

입니다.

따라서 Tenant 1의 플레이어만 조회하려면

SELECT *
FROM player
WHERE tenant_id = 1;

처럼 조회합니다.

결과는

tenant_id	player_id	nickname	level
1	1	천기사	35
1	2	성기사	42

입니다.

---

Pool Model에서는 PK도 생각해야 한다

다음 데이터를 보겠습니다.

tenant_id	player_id	nickname
1	1	천기사
2	1	용기사
3	1	슬라임왕

모든 Tenant에서 player_id = 1이 존재합니다.

따라서 player_id 하나만으로는 전체 공유 테이블에서 데이터를 유일하게 구별할 수 없습니다.

한 가지 설계 방법은

PK = (tenant_id, player_id)

처럼 복합키를 사용하는 것입니다.

tenant_id + player_id

1 + 1 → 천기사

2 + 1 → 용기사

3 + 1 → 슬라임왕

또는 시스템 전체에서 유일한 별도의 ID를 사용하는 방법도 있습니다.

중요한 것은 Pool 구조에서는 모든 쿼리와 권한 검사가 Tenant 경계를 올바르게 유지하도록 설계되어야 한다는 것입니다.

---

Pool Model 구조

전체적인 구조는 다음처럼 생각할 수 있습니다.

각 테이블에는 Tenant를 구별하는 값이 들어갑니다.

---

Pool Model의 장점

가장 큰 장점은 리소스 공유 효율입니다.

Tenant가 1,000개 있어도 모든 Tenant가 하나의 공통 인프라를 사용할 수 있습니다.

예를 들어

Tenant 1
Tenant 2
Tenant 3
...
Tenant 1000
      │
      ▼
Shared Database

형태가 가능합니다.

스키마 변경도 공유 테이블에 한 번 적용하면 됩니다.

ALTER TABLE player
ADD COLUMN last_login_at TIMESTAMP;

player 테이블 자체가 하나이므로 배포 구조도 단순해질 수 있습니다.

공유 리소스가 Pool 모델의 비용·관리 효율성을 높이는 핵심 이유입니다.

---

Pool Model의 단점

반대로 Tenant 격리는 애플리케이션과 데이터베이스의 접근 제어 설계에 더 많이 의존하게 됩니다.

예를 들어 원래 다음 쿼리를 작성해야 했다고 해봅시다.

SELECT *
FROM player
WHERE tenant_id = 1;

그런데 개발자가 실수로

SELECT *
FROM player;

를 실행했다면 모든 Tenant의 데이터가 조회될 수 있습니다.

tenant_id	nickname
1	천기사
1	성기사
2	용기사
2	흑룡
3	슬라임왕

따라서 Pool Model에서는 단순히 모든 테이블에 tenant_id를 추가하는 것으로 끝나는 것이 아니라 Tenant Isolation을 강제하는 보안 구조가 중요합니다. AWS도 공유 인프라 방식에서는 tenant isolation이 더 복잡한 과제가 된다고 설명합니다.

---

Noisy Neighbor 문제

Pool 모델에서는 여러 Tenant가 같은 리소스를 공유하기 때문에 Noisy Neighbor 문제도 고려해야 합니다.

예를 들어

Tenant A
사용자 100명

Tenant B
사용자 200명

Tenant C
사용자 500만 명

이라고 해봅시다.

모두 같은 DB를 사용합니다.

Tenant C가 갑자기 매우 무거운 쿼리를 대량으로 실행하면 공유 데이터베이스의 CPU, 메모리, I/O를 많이 사용할 수 있습니다.

그 결과 A와 B의 서비스 응답까지 느려질 가능성이 있습니다.

AWS SaaS 문서에서도 tenant별 리소스 소비와 다른 tenant에 미치는 영향을 고려하는 Noisy Neighbor를 별도의 SaaS 설계 주제로 다룹니다.

---

Bridge Model

Bridge Model은 Silo와 Pool을 조합하는 방식입니다.

Silo
+
Pool
=
Bridge

단순히 말하면

모든 Tenant를 완전히 분리하지도 않고, 모든 것을 완전히 공유하지도 않는 방식

입니다.

AWS에서는 Bridge를 시스템의 각 계층이나 리소스에 적합한 Silo 또는 Pool 방식을 조합하는 하이브리드 패턴으로 설명합니다.

---

Bridge Model의 첫 번째 예시

게임 SaaS 서비스에서 웹 서버와 인증 시스템은 모든 Tenant가 공유한다고 해봅시다.

하지만 게임 데이터는 각 Tenant마다 별도의 데이터베이스를 사용합니다.

즉

Web / API
→ Pool

Database
→ Silo

입니다.

AWS 문서에서도 웹 계층은 공유하면서 애플리케이션/스토리지 계층은 Tenant별로 분리하는 Bridge 예시를 제시합니다.

---

Bridge Model과 Schema-per-Tenant

데이터베이스만 좁게 바라보면 Bridge의 한 구현 예시로 Database는 공유하지만 Schema를 Tenant별로 나누는 방식을 생각할 수 있습니다.

다만 Bridge = 반드시 Schema-per-Tenant라는 뜻은 아닙니다. Bridge의 본질은 시스템의 일부는 Pool, 일부는 Silo 방식으로 조합하는 것입니다.

PostgreSQL에서 다음과 같은 구조를 생각해볼 수 있습니다.

Database 자체는 하나지만 Schema는 Tenant별로 분리됩니다.

---

Schema-per-Tenant 데이터 예시

tenant_a.player

player_id	nickname	level
1	천기사	35
2	성기사	42

tenant_b.player

player_id	nickname	level
1	용기사	28
2	흑룡	51

tenant_c.player

player_id	nickname	level
1	슬라임왕	17

PostgreSQL에서는 다음처럼 접근할 수 있습니다.

SELECT *
FROM tenant_a.player;

또는

SELECT *
FROM tenant_b.player;

처럼 조회할 수 있습니다.

---

Silo와 Bridge의 차이

둘 다 데이터가 분리되어 있어서 비슷해 보일 수 있습니다.

하지만 대표적인 Database-per-Tenant와 Schema-per-Tenant 구조를 비교하면 차이가 명확합니다.

Silo 예시

데이터베이스 자체가 분리됩니다.

Bridge에서 사용할 수 있는 예시

데이터베이스 리소스는 공유하지만 데이터 구조의 일부 경계를 분리합니다.

다만 실제 Bridge는 이보다 훨씬 다양한 조합이 가능합니다. 예를 들어 일부 Tenant만 전용 DB를 사용하고 나머지는 공유 DB를 사용하는 방식도 Bridge로 볼 수 있습니다.

---

대형 고객만 별도로 분리하는 Bridge Model

서비스에 다음과 같은 고객이 있다고 생각해봅시다.

Tenant	사용자 수	등급
A	500	Basic
B	1,000	Basic
C	2,000	Basic
D	1,000만	Enterprise

A, B, C는 공유 DB를 사용합니다.

하지만 사용자가 1,000만 명인 D는 전용 DB를 사용합니다.

Tenant D
   │
   ▼
Dedicated DB

전체 구조는 다음과 같습니다.

이 역시 Silo와 Pool을 함께 사용하는 Bridge 형태입니다. Bridge는 각 영역에 Silo와 Pool의 장단점을 선택적으로 적용하는 방식입니다.

---

중요한 데이터만 Silo로 분리할 수도 있다

게임 서비스에서 일반적인 게임 정보는 Pool로 저장한다고 해봅시다.

player
guild
item

하지만 결제 정보는 보안 및 운영 요구사항 때문에 Tenant별로 따로 관리하고 싶을 수 있습니다.

반면

결제 데이터

Tenant A → Payment DB A
Tenant B → Payment DB B
Tenant C → Payment DB C

처럼 설계할 수 있습니다.

이 역시

일반 데이터 → Pool

중요 데이터 → Silo

를 조합한 Bridge 접근입니다.

---

세 모델을 게임 건물로 비유해보기

아파트를 하나 운영한다고 생각하면 비교하기 쉽습니다.

Silo Model

각 플레이어에게 독립된 집 한 채를 제공합니다.

천기사     → 집 A
흑마법사   → 집 B
궁수왕     → 집 C

집 자체가 전부 다릅니다.

격리는 매우 확실하지만 집을 각각 관리해야 합니다.

---

Pool Model

모든 플레이어가 하나의 거대한 기숙사를 사용합니다.

공간을 효율적으로 사용할 수 있지만 서로의 영역을 정확하게 구분해야 합니다.

---

Bridge Model

하나의 아파트 건물을 공유하지만 Tenant별 공간을 일부 분리하거나, 일부 고객만 독립 건물을 사용합니다.

공용 로비
공용 엘리베이터

        ↓

Tenant A 전용 공간
Tenant B 전용 공간
Tenant C 전용 공간

또는

일반 Tenant → 공용 아파트

VIP Tenant → 독립 주택

처럼 구성할 수 있습니다.

---

세 모델을 데이터로 비교

같은 플레이어 세 명을 저장한다고 가정해보겠습니다.

Silo

DB_A.player

player_id	nickname
1	천기사

DB_B.player

player_id	nickname
1	용기사

DB_C.player

player_id	nickname
1	슬라임왕

---

Pool

SharedDB.player

tenant_id	player_id	nickname
1	1	천기사
2	1	용기사
3	1	슬라임왕

모두 한 테이블에 들어갑니다.

---

Bridge의 Schema-per-Tenant 예시

SharedDB.tenant_a.player

player_id	nickname
1	천기사

SharedDB.tenant_b.player

player_id	nickname
1	용기사

SharedDB.tenant_c.player

player_id	nickname
1	슬라임왕

물리적인 Database는 공유하지만 Schema 단위로 분리한 구현입니다.

---

구조를 한눈에 비교

---

장단점 비교

항목	Silo	Pool	Bridge
리소스 공유	낮음	높음	중간~가변
Tenant 격리	강함	논리적 격리 중심	설계에 따라 다름
인프라 효율	낮은 편	높은 편	중간~가변
운영 복잡도	Tenant 증가 시 커질 수 있음	공유 구조 자체는 단순하지만 격리 로직 중요	조합 때문에 복잡해질 수 있음
Tenant별 튜닝	쉬움	상대적으로 어려움	일부 가능
스키마 변경	다수 환경에 배포 필요 가능	공유 테이블이면 한 번	구조에 따라 다름
Noisy Neighbor	상대적으로 적음	주의 필요	분리 수준에 따라 다름
대표적인 사용 이유	강한 격리	비용·운영 효율	격리와 효율의 절충

이 표는 일반적인 경향을 정리한 것입니다. 실제 장단점은 Database, Compute, Storage 등 어느 계층을 공유하고 어느 계층을 분리했는지에 따라 달라집니다. 특히 Bridge는 특정한 하나의 DB 구조를 뜻하기보다 여러 계층에서 Silo와 Pool을 섞는 개념입니다.

---

언제 Silo Model을 고려할까?

다음과 같은 요구가 강하다면 Silo 방식이 적합할 수 있습니다.

Tenant별 데이터 격리가 매우 중요하다.

특정 고객만 별도로 백업해야 한다.

고객별 성능 튜닝이 필요하다.

고객마다 서로 다른 리소스 크기가 필요하다.

예를 들어 대형 게임 회사 하나가

우리 데이터는 다른 고객과
같은 DB에 저장하면 안 됩니다.

라는 요구를 한다면 전용 리소스를 사용하는 Silo 접근을 검토할 수 있습니다.

---

언제 Pool Model을 고려할까?

반대로 Tenant가 매우 많고 각 Tenant의 데이터 규모가 크지 않다면 Pool 방식의 효율성이 높을 수 있습니다.

예를 들어

소규모 게임 개발팀
100,000개

각 팀의 평균 사용자
100명

같은 서비스라고 생각해봅시다.

모든 Tenant마다 별도 DB를 운영하는 것보다 공유 데이터베이스에서 tenant_id를 이용해 구분하는 것이 리소스 활용과 운영 효율 측면에서 유리할 수 있습니다. Pool 방식의 주요 목적 중 하나가 바로 공유 인프라에서 얻는 규모의 경제와 관리 효율입니다.

---

언제 Bridge Model을 고려할까?

실제 서비스에서는 모든 Tenant가 동일하지 않을 수 있습니다.

Basic 고객
→ 사용자 100명

Standard 고객
→ 사용자 10,000명

Enterprise 고객
→ 사용자 1,000만 명

이 경우

Basic / Standard
       │
       ▼
   Shared DB


Enterprise
       │
       ▼
 Dedicated DB

처럼 설계할 수 있습니다.

즉

기본 고객은 Pool로 비용 효율을 높이고, 높은 격리나 성능이 필요한 고객은 Silo로 제공

하는 방식입니다.

이러한 선택적 조합이 Bridge 모델의 핵심입니다.

---

Pool에서 가장 중요한 tenant_id

Pool 방식의 게임 데이터베이스를 설계한다면 대부분의 Tenant 종속 테이블에 Tenant 식별자가 필요할 수 있습니다.

예를 들어 다음과 같습니다.

player

tenant_id	player_id	nickname
1	1	천기사
2	1	용기사

guild

tenant_id	guild_id	guild_name
1	10	용기사단
2	10	드래곤즈

inventory

tenant_id	player_id	item_id	quantity
1	1	101	5
2	1	101	20

이 구조에서 단순히

player_id = 1

만으로 데이터를 찾으면 Tenant가 구분되지 않습니다.

따라서

tenant_id = 1
AND
player_id = 1

처럼 Tenant 범위가 포함되어야 합니다.

이 때문에 Pool 설계에서는 Tenant Context를 애플리케이션부터 데이터 계층까지 일관되게 전달하고 격리를 강제하는 것이 중요합니다.

---

Silo → Pool은 단순히 DB 개수 차이가 아니다

다음처럼 외우기 쉽습니다.

Silo
= DB 여러 개

Pool
= DB 하나

Bridge
= Schema 여러 개

하지만 이것은 데이터베이스 구현을 단순화해서 설명한 예시일 뿐 정확한 정의는 아닙니다.

정확한 핵심은 다음과 같습니다.

Silo
= Tenant별 전용 리소스

Pool
= Tenant들이 리소스를 공유

Bridge
= 일부는 전용, 일부는 공유

리소스는 데이터베이스만 의미하지 않습니다.

Web Server
Application Server
Database
Storage
Message Queue
Cache

등 다양한 계층에 Silo, Pool을 각각 적용할 수 있습니다. AWS 역시 Silo/Pool 패턴이 컴퓨팅, 스토리지, 메시징 등을 포함한 여러 아키텍처 요소에 적용될 수 있다고 설명합니다.

---

실제 서비스에서는 이렇게 섞을 수도 있다

예를 들어 다음 게임 SaaS가 있다고 생각해봅시다.

여기서

Web
→ Pool

API
→ Pool

일반 고객 DB
→ Pool

Enterprise DB
→ Silo

입니다.

전체 서비스는 Bridge Model이라고 볼 수 있습니다.

---

세 모델을 선택하는 기준

어떤 모델이 무조건 가장 좋은 것은 아닙니다.

선택할 때는 다음 요소들을 함께 고려해야 합니다.

Tenant 수는 얼마나 되는가?

Tenant별 데이터 규모는 얼마나 다른가?

얼마나 강한 데이터 격리가 필요한가?

Tenant별 성능 보장이 필요한가?

운영 비용은 어느 정도까지 허용되는가?

Tenant별 백업이나 복원이 필요한가?

공유 리소스의 부하를 어떻게 제어할 것인가?

규제나 고객 계약상 별도 환경이 필요한가?

SaaS 아키텍처에서는 규제, 비용 효율, 시장 요구, 운영 방식 등의 조건에 따라 Silo·Pool·Bridge 패턴을 단독 또는 조합해 적용할 수 있습니다.

---

전체 흐름으로 이해하기

가장 강하게 분리된 쪽에서 가장 많이 공유하는 쪽으로 놓으면 다음처럼 생각할 수 있습니다.

격리 강함
비용 높아질 가능성
운영 대상 많음

        SILO
          │
          │
          ▼
       BRIDGE
          │
          │
          ▼
        POOL

공유 높음
리소스 효율 높음
Tenant 격리 로직 중요

Bridge는 정확히 가운데 하나의 고정된 구조라기보다 필요한 부분마다 Silo와 Pool을 조합할 수 있는 방식이라는 점이 중요합니다.

---

정리

Silo, Pool, Bridge Model은 멀티테넌트 시스템에서 여러 Tenant의 데이터와 리소스를 얼마나 분리하고 얼마나 공유할 것인지 결정하는 아키텍처 패턴입니다.

가장 간단하게 정리하면 다음과 같습니다.

모델	핵심
Silo	Tenant마다 전용 리소스를 사용
Pool	여러 Tenant가 리소스를 공유
Bridge	Silo와 Pool을 필요에 따라 조합

게임 데이터베이스 예시로 다시 보면

SILO

천국게임즈 → DB A
드래곤게임즈 → DB B
슬라임게임즈 → DB C

처럼 이해할 수 있습니다.

특히 주의해야 하는 것은 다음과 같습니다.

Silo = 무조건 Database-per-Tenant, Bridge = 무조건 Schema-per-Tenant, Pool = 무조건 하나의 테이블이라는 공식은 아닙니다.

이것들은 흔히 사용하는 데이터베이스 구현 예시이고, 본래의 개념은 더 넓습니다. Silo와 Pool은 데이터베이스뿐 아니라 Compute, Storage 등 여러 리소스 계층에 적용할 수 있으며 Bridge는 이 두 방식을 시스템 요구사항에 따라 조합합니다.

따라서 세 모델의 핵심을 한 문장씩 기억하면 됩니다.

Silo = "고객별로 분리하자." Pool = "같이 쓰되 Tenant를 구분하자." Bridge = "공유할 것은 공유하고, 분리할 것은 분리하자."

앞에서 배운 Schema와 연결해서 보면 Schema-per-Tenant가 왜 등장하는지도 이해할 수 있습니다. 하나의 Database를 공유하면서도 Schema라는 Namespace를 이용해 Tenant별 구조를 어느 정도 분리하는 것이 가능한 것입니다.