멀티테넌시(multi-tenancy)는 하나의 서비스가 여러 고객(테넌트, tenant)의 데이터를 함께 다루는 구조다. 핵심 설계 질문은 테넌트 사이의 데이터를 얼마나 강하게 떼어 놓을 것인가이고, 한쪽 끝은 공유 DB, 반대쪽 끝은 테넌트 전용 DB다.
격리 수준
| 공유 DB + 행 구분 | 스키마 분리 | 전용 DB(dedicated) | |
|---|---|---|---|
| 구조 | 한 테이블에 tenant_id로 구분 | 테넌트마다 스키마 | 테넌트마다 DB·인스턴스 |
| 격리 | 논리적 | 중간 | 물리적 |
| 비용·운영 | 싸고 단순 | 중간 | 비싸고 복잡 |
| 위험 | 필터 한 줄 실수 = 유출 | 마이그레이션 반복 | 테넌트 수만큼 마이그레이션 |
- 공유 DB에서는 애플리케이션이 모든 쿼리에
tenant_id조건을 붙여야 한다. 깜빡하면 남의 데이터가 보인다. 이를 DB 수준에서 강제하는 장치가 RLS다 - 전용 DB는 애초에 남의 데이터에 닿을 수 없어 금융·의료처럼 격리가 중요한 고객에게 제공한다
- 실무에서는 "기본은 공유 DB + RLS, 보안 요구가 큰 대형 고객만 전용 DB"인 하이브리드가 흔하다
"dedicated"의 다른 뜻
dedicated DB는 표준 용어가 아니라 맥락에 따라 뜻이 갈린다.
- 용도 전용: 분석·로그·검색 소스처럼 무거운 작업을 핵심 DB에서 떼어 낸 DB. 워크로드 격리(workload isolation)가 목적이다(읽기 전용 복제본)
- 테넌트 전용: 위의 멀티테넌시 의미
- 인스턴스 전용: 클라우드 플랜에서 다른 사용자와 하드웨어를 공유하지 않는 등급. "시끄러운 이웃(noisy neighbor)" 영향을 피한다
공통 트레이드오프는 "격리·성능·보안을 얻는 대신 비용과 운영 복잡도가 오른다"다. 테넌트가 아주 많아지면 샤딩으로 이어지고, 서비스 경계를 나누는 관점은 바운디드 컨텍스트와도 닿는다.