구축형 복제가 운영 비용을 키우는 방식
B2B 솔루션을 고객사마다 서버를 따로 띄워 납품하는 방식은 처음에는 단순합니다. 하지만 고객이 늘수록 비용이 고객 수에 비례해 커집니다. 고객사 요청을 반영하려고 소스를 분기하면 같은 버그를 여러 브랜치에서 따로 고쳐야 하고, 보안 패치 하나를 배포할 때도 서버마다 작업을 반복해야 합니다.
예를 들어 고객사가 20곳이고 서버 1대에 배포·검증하는 데 30분이 걸린다면, 패치 1건에 10시간이 듭니다. 한 달에 패치가 4건이면 배포에만 40시간이 들어갑니다. 여기에 고객사마다 버전이 다르면 장애 재현과 문의 대응도 그만큼 어려워집니다.
멀티테넌시 전환을 검토해야 할 신호는 다음과 같습니다.
데이터 격리 모델 3가지
| 모델 | 격리 수준 | 비용 | 적합한 경우 |
|------|----------|------|------------|
| 공유 DB·공유 스키마 (tenant_id) | 낮음 | 가장 낮음 | 중소 고객 다수, 빠른 확장 |
| 스키마 분리 | 중간 | 중간 | 수십~수백 개 테넌트, 고객별 백업 요구 |
| DB 분리 | 높음 | 가장 높음 | 금융·공공, 계약상 물리 분리 요구 |
정답은 하나로 정해져 있지 않습니다. 대부분의 고객은 공유 스키마로 운영하고, 보안 규정이 엄격한 대형 고객만 DB 분리로 배치하는 혼합 구성이 현실적입니다. 스키마 분리는 테넌트가 수천 곳으로 늘어나면 마이그레이션 시간이 테넌트 수에 비례해 늘어난다는 점을 함께 고려해야 합니다.
테넌트 격리를 코드에서 보장하는 법
공유 스키마 모델에서 가장 흔한 사고는 `WHERE tenant_id = ?` 조건이 하나 빠져서 다른 고객사 데이터가 노출되는 것입니다. 개발자가 매번 조건을 기억하는 방식으로는 막을 수 없습니다.
이중 방어선
RLS는 테이블 소유자 계정에는 기본적으로 적용되지 않으므로 `FORCE ROW LEVEL SECURITY`를 설정하거나, 애플리케이션 전용 계정을 별도로 두어야 합니다.
DB 밖의 경계
캐시 키에는 `tenant:{id}:` 접두어를 붙이고, 파일 저장소는 테넌트별 경로와 접근 정책으로 나누며, 검색 인덱스에도 테넌트 필터를 강제합니다. DB만 격리하고 캐시나 파일 저장소를 놓치는 경우가 의외로 많습니다.
고객사별 차이를 분기 없이 처리하기
고객사 요구는 소스 분기가 아니라 설정으로 흡수합니다.
다른 고객에게도 쓸모가 있는 요구는 제품 기능으로 만들고, 한 고객에게만 필요한 요구는 API·웹훅 연동으로 외부에서 처리하도록 기준을 정해 두면 코어 코드가 오염되지 않습니다.
시끄러운 이웃과 운영 문제
한 테넌트가 대량 엑셀 업로드나 무거운 리포트를 실행하면 같은 자원을 쓰는 다른 고객의 응답이 느려집니다.
단계적 전환 로드맵
POLYGLOTSOFT와 함께하는 멀티테넌트 전환
POLYGLOTSOFT는 구독형 개발 방식으로 격리 모델 설계, RLS 기반 데이터 보호, 설정·기능 플래그 구조, 기존 고객 이관까지 단계적으로 지원합니다. 한 번에 큰 예산을 들이지 않고 월 단위로 범위를 조정하며 진행할 수 있습니다. 현재 구조와 고객사 현황을 요구사항 문서로 정리해 보내주시면 전환 방향을 함께 검토해 드립니다.