멀티테넌시(Multi-tenancy)란?

멀티테넌시(Multi-tenancy)란?

멀티테넌시란?

멀티테넌시는 하나의 애플리케이션과 하나의 인프라(DB, 서버)를 여러 고객이 함께 쓰면서도, 각 고객의 데이터와 설정은 완전히 분리해서 관리하는 아키텍처다. 여기서 Tenant는 서비스를 사용하는 하나의 고객(회사·조직)을 말한다.

헬스장 회원관리 SaaS를 예로 들면 이런 구조가 된다.

회원관리 서비스
├── 헬스장 A
├── 헬스장 B
└── 헬스장 C

헬스장 A, B, C가 각각 Tenant다. 모두 같은 프로그램을 쓰지만 서로의 회원 정보는 절대 조회할 수 없다.

왜 멀티테넌시를 쓸까?

헬스장마다 서버와 DB를 따로 운영한다고 해보자.

헬스장 A → 서버 + DB
헬스장 B → 서버 + DB
헬스장 C → 서버 + DB

고객이 늘수록 비용이 폭발한다. 반면 멀티테넌시는 하나의 서버와 하나의 DB를 여러 고객이 나눠 쓴다.

회원관리 서비스
        │
   하나의 DB 서버
        │
 헬스장A  헬스장B  헬스장C

비용이 싸고 유지보수가 쉽다. SaaS에서 가장 많이 쓰는 방식이다.

데이터는 어떻게 분리될까?

가장 흔한 방식은 모든 테이블에 tenant_id를 넣는 것이다. member 테이블이라면 이렇게 된다.

id tenant_id name

1	gym_a	김철수
2	gym_a	이영희
3	gym_b	박민수

조회할 때는 항상 tenant_id 조건을 건다.

SELECT *
FROM member
WHERE tenant_id = 'gym_a';

그래서 gym_a 사용자는 gym_b 데이터를 절대 못 본다.

멀티테넌시 구현 방식

1. Shared Database, Shared Schema. 가장 많이 쓰는 방식이다. 하나의 DB에 모든 테이블을 두고, 각 테이블에 tenant_id 컬럼을 붙인다.

DB
member
trainer
payment
...

구현이 가장 간단하고, 비용이 가장 싸고, 운영이 쉽다. 대신 tenant_id 조건을 하나라도 빼먹으면 다른 고객 데이터가 새어 나간다.

2. Shared Database, Separate Schema. DB는 하나지만 스키마를 고객별로 나눈다.

DB
gym_a.member   gym_a.payment
gym_b.member   gym_b.payment

분리가 조금 더 안전한 대신 관리가 복잡해진다.

3. Separate Database. 고객마다 DB를 통째로 분리한다.

DB Server
gym_a_database
gym_b_database
gym_c_database

가장 안전하지만 비용도 가장 크다.

Role과 Tenant는 뭐가 다를까?

멀티테넌시를 처음 보면 제일 헷갈리는 부분이다. 결론부터 말하면 둘은 푸는 문제가 다르다.

Tenant는 "어느 고객의 데이터인가"를 다룬다. BBQ, BHC, 교촌이 같은 서비스를 쓴다고 하자. tenant = BBQ인 사용자는 BBQ 데이터만 봐야 하고, BHC나 교촌 데이터는 절대 조회하면 안 된다. 즉 Tenant는 고객 간 데이터 경계를 만드는 개념이다.

Role은 "같은 회사 안에서 누가 어디까지 보는가"를 다룬다. BBQ 안에도 본사, 영업팀, 물류팀, 가맹점이 있고 ROLE_ADMIN, ROLE_MANAGER, ROLE_FRANCHISE 같은 권한이 있다.

• ROLE_ADMIN → BBQ 전체 조회
• ROLE_MANAGER → 담당 가맹점 조회
• ROLE_FRANCHISE → 자기 가맹점만 조회

즉 Role은 같은 Tenant 내부에서 권한을 나누는 개념이다.

둘은 함께 쓴다

JWT에 이렇게 담겨 있다고 하자.

{
  "tenantId": "BBQ",
  "role": "MANAGER"
}

조회는 두 단계로 간다. 먼저 tenant로 BBQ 데이터만 걸러내고, 그다음 Role로 범위를 좁힌다. ROLE_MANAGER면 담당 가맹점만 조회한다. 실제 순서는 Tenant → Role이다.

tenant_id만 있으면 Role은 필요 없을까?

아니다. tenant_id는 "다른 회사 데이터를 못 보게 하는 장치"고, Role은 "우리 회사 안에서 누가 어디까지 보는가"를 정한다. Tenant는 회사 간 분리, Role은 회사 내부 권한. 서로 대체하는 게 아니라 같이 쓰는 개념이다.

내가 만든 ERP는 멀티테넌시였을까?

내가 참여한 ERP는 본사 → 영업팀 → 가맹점 구조였고, 직급과 부서에 따라 조회 범위가 달랐다. 영업팀장은 모든 가맹점을, 담당자는 담당 가맹점을, 가맹점주는 자기 매장만 봤다. 데이터 접근 제한은 분명히 있었다. 하지만 이건 Role 기반 접근 제어(RBAC)다.

왜 멀티테넌시가 아니냐면, 그 ERP는 하나의 회사(BBQ)만을 위한 시스템이었기 때문이다. tenant는 BBQ 하나뿐이었다. 만약 이걸 BBQ, BHC, 교촌, 굽네에 다 팔아서 한 시스템에서 굴린다면 그때부터 tenant = BBQ, tenant = BHC 같은 개념이 생긴다. 그게 멀티테넌시다. 정리하면 내 ERP는 RBAC는 있었지만 멀티테넌시는 없었다고 보는 게 맞다.

멀티테넌시로 확장한다면?

기존 구조가 BBQ → 가맹점 → 회원이었다면, 멀티테넌시에서는 맨 앞에 회사(Tenant) 계층이 하나 더 붙는다.

Tenant(BBQ) → 가맹점 → 회원
Tenant(BHC) → 가맹점 → 회원

기존 구조 앞에 "회사"라는 층을 하나 얹는 것이다.

정리

Role과 멀티테넌시는 다른 개념이다. Role은 "누가 보는가", 멀티테넌시는 "어느 고객의 데이터인가"를 정한다. 실무에서는 대부분 tenant_id로 고객 데이터를 먼저 자르고, Role로 회사 내부 권한을 다시 자른다. 즉 Tenant → Role → Data 순서로 접근을 제어하는 게 일반적인 멀티테넌시 구조다.