본문으로 건너뛰기
  1. 포스트/

싱글 테넌트 vs 멀티 테넌트 SaaS: 언제 무엇을 쓸까

· loading · loading ·
인재덕
작성자
인재덕
서울에 거주하는 리더 겸 소프트웨어 엔지니어

B2B SaaS를 하다 보면 언젠가는 반드시 테넌시 문제에 부딪힙니다. 보통은 큰 잠재 고객이 “우리 데이터를 다른 회사와 분리해서 둘 수 있나요?“라고 묻는 날이죠. 저도 이 논의를 여러 번 가까이서 지켜봤습니다. 답은 기본적으로 둘 중 하나입니다. 고객마다 전용 인스턴스를 주거나(싱글 테넌트, 멀티 인스턴스), 모두를 하나의 공유 인스턴스에서 운영하거나(멀티 테넌트, 싱글 인스턴스). 어느 쪽이 정답인 건 아닙니다. 그저 망가지는 방식이 다를 뿐입니다.

인프라 설계
#

싱글 테넌트와 멀티 테넌트의 차이

싱글 테넌트, 멀티 인스턴스
#

싱글 테넌트, 멀티 인스턴스: 이 설정에서는 여러 인프라 인스턴스가 여러 테넌트에 서비스를 제공합니다.

이 방식의 매력은 결국 격리입니다. 장점 대부분이 여기서 나옵니다. 고객 데이터가 각자 독립된 환경에 있으니 보안 리뷰와 컴플라이언스 이야기가 훨씬 수월해집니다. 배포 사고나 무거운 워크로드가 터져도 전체가 아니라 고객 한 곳만 영향을 받습니다. 인스턴스별로 독립적으로 확장하고 튜닝하고 커스터마이징할 수 있고, 리소스가 전용이라 옆 테넌트가 뭘 하든 내 성능이 흔들리지 않습니다. 유지보수도 고객 단위로 잡을 수 있어서 다운타임이 작고 국소적입니다. 가격 설계만 잘하면 인프라 비용을 테넌트별 실제 사용량에 맞출 수도 있습니다.

대가는 모든 걸 N벌씩 운영하게 된다는 점입니다. 리소스 오버헤드가 쌓이고, 인스턴스 간 설정이 조금씩 어긋나고, 전체 플릿의 버전과 데이터를 맞추는 일 자체가 하나의 프로젝트가 됩니다. 확장, 격리, 비용 관리 문제는 사라지는 게 아니라 늘어납니다.

멀티 테넌트, 싱글 인스턴스
#

멀티 테넌트, 싱글 인스턴스: 단일 소프트웨어 애플리케이션이 여러 테넌트에 서비스를 제공합니다.

이게 기본값인 데는 이유가 있습니다. 배포도 하나, 백업할 데이터베이스도 하나, 프로덕션 버전도 하나. 리소스 효율이 좋고 운영이 단순하며, 업데이트와 보안 패치가 모든 고객에게 동시에 적용됩니다.

어려운 부분은 공유의 이면입니다. 한 테넌트가 무겁게 쓰면 모두의 성능이 끌려 내려가고, 고객별 커스터마이징에는 한계가 있습니다. 그리고 데이터 격리가 인프라가 아니라 애플리케이션 코드의 책임이 되기 때문에, 버그 하나가 테넌트 간 데이터 유출로 이어질 수 있습니다. 확장성 병목은 모든 고객에게 동시에 오고, “이 고객만"이라는 영향 범위가 없어지는 만큼 유지보수에도 더 신경을 써야 합니다.

SaaS 솔루션에 대한 자세한 정보 - 멀티 인스턴스 vs. 멀티 테넌트 아키텍처

싱글 테넌트, 어디서부터 시작할까
#

싱글 테넌트로 간다면, 이게 “관리 가능한 일"이 될지 “슬로모션 재난"이 될지는 도구가 결정합니다. 서른 개의 환경을 손으로 돌볼 수는 없으니까요.

핵심은 컨테이너와 Infrastructure as Code입니다. Docker로 모든 테넌트에 동일한 형태로 앱을 패키징하고, Kubernetes로 그 많은 인스턴스의 배포와 확장을 처리합니다. Terraform, Pulumi, AWS CloudFormation으로 테넌트 스택 전체를 코드로 정의해 두면, 31번째 고객 셋업이 주말을 갈아 넣는 일이 아니라 풀 리퀘스트 하나가 됩니다. VM 세계에 더 가깝다면 Ansible, Chef, Puppet 같은 구성 관리 도구가 같은 역할을 해줍니다. CI/CD 파이프라인(Jenkins, GitLab CI/CD)은 평소보다 훨씬 중요해집니다. 모든 릴리스를 일일이 붙어 있지 않고도 전체 인스턴스에 배포해야 하거든요.

그다음부터는 제품의 형태에 달렸습니다. 일부 워크로드는 서버리스(AWS Lambda, Azure Functions)로 서버 계층 자체를 없앨 수 있습니다. Amazon RDS나 Azure SQL Database 같은 관리형 데이터베이스는 테넌트마다 DB를 손으로 관리하는 고행에서 구해줍니다. 모니터링(Prometheus, Grafana, New Relic)은 플릿이 생기는 순간부터 선택이 아닙니다. 어느 인스턴스가 아픈지는 고객이 말해주기 전에 알아야 하니까요. 인증은 Auth0나 Okta 같은 IAM 서비스에 맡기면 테넌트마다 새로 만들 필요가 없습니다. 어떤 언어를 쓰든 이런 배관 작업을 덜어주는 SaaS 지향 프레임워크나 라이브러리가 있을 것이고, 호스팅은 AWS, Azure, Google Cloud Platform 같은 대형 클라우드 어디든 무리 없이 받아줍니다.

첫날부터 이 목록을 전부 살 필요는 없습니다. 컨테이너와 IaC로 시작해서, 테넌트가 쌓이는 만큼 모니터링과 IAM을 더하고, 나머지는 실제로 아픈 순서대로 고르면 됩니다.