SaaS와 멀티테넌시

 

우리 회사는 얼마 전까지만 해도 SI 프로젝트를 통해 제품을 고객의 요구사항에 맞춰 개발해주는 회사였다.

그런데 클라우드 플랫폼 사업으로의 확장을 고민하면서, 기존 SI 프로젝트 형태로 제공되던 제품을 서비스화 하자는 논의가 있었다.

그러면서 자연스럽게 나온 개념이 바로 SaaS와 멀티테넌시(Multi-tenancy)였다.

 

SaaS와 멀티테넌시라는 개념 자체는 알고는 있었지만, 구체적으로 어떤 구조인지, 우리가 지금 처한 상황에 맞게 적용할 수 있는지에 대해선 명확하지 않았다.
우선 머릿속에 떠오른 의문점들은 다음과 같았다.

• SaaS와 우리가 해오던 SI는 정확히 무엇이 다른가?
• 멀티테넌시를 꼭 도입해야 하는가?
• 고객마다 요구사항이 제각각인데, 하나의 공통 플랫폼으로 제공하는 게 가능한가?

이러한 질문들에 대한 실마리를 찾기 위해 개념을 간단하게 정리해보았다.

 

SaaS란 무엇인가?

 

SaaS는 Software as a Service, 즉 서비스 형태의 소프트웨어’다.

기존의 SI 방식은 고객마다 별도의 시스템을 구축하고, 운영 및 유지보수도 고객마다 따로 관리해야 했다.
반면 SaaS는 하나의 소프트웨어를 여러 고객이 온라인을 통해 사용할 수 있도록 만든다.

예를 들어, 우리가 만드는 제품이 ERP라고 하면, 고객사마다 설치해주는 방식이 아니라, 우리가 제공하는 도메인에 접속해서 회원가입만 하면 바로 사용할 수 있도록 제공하는 것이다.

 

왜 멀티테넌시가 필요할까?

 

SaaS 구조에서 자연스럽게 따라오는 이슈가 바로 멀티테넌시(Multi-tenancy)다.

서비스를 SaaS 형태로 제공하면, 여러 고객(테넌트)이 하나의 시스템을 공유하게 된다.
하지만 당연히 고객사 A의 데이터가 고객사 B에게 보이면 안 된다.
하나는 공유되되, 데이터는 철저히 분리되어야 한다.

이러한 요구사항을 만족시키기 위한 구조가 바로 멀티테넌시 아키텍처다.

멀티테넌시 구조는 다음과 같은 특징을 가진다:

• 하나의 코드베이스와 인프라를 여러 고객이 함께 사용
• 각 고객의 데이터는 tenant_id 컬럼 또는 별도의 스키마/DB로 논리적 또는 물리적으로 분리

 

참고 :https://woopi1087.tistory.com/125 (멀티테넌시 아키텍처)

 

실제로 우리가 고민했던 것들

• 테넌트 간 격리는 어떤 방식으로 할까?
  → DB 레벨에서 접근 제어를 적용했고, 업무 특성상 테넌트 ID 기반 처리 + 스키마 분리를 병행했다.
• 기존 고객들의 다양한 요구사항은 어떻게 대응할까?
  → SaaS 구조의 핵심은 공통 플랫폼. 하지만 현실적으로 완전한 공통 구조는 어려웠기 때문에,
  기능을 feature 단위로 나눠 on/off 설정이 가능하도록 개발 방식에 변화를 주었다.

 

정리하며

결론부터 말하자면, 아직은 SaaS를 완전히 도입하지 못했다.

다만 일부 개념은 도입한 상태다.

• 고객 간 데이터를 분리하기 위해 DB 스키마 분리를 적용했고,
• 코드베이스는 하나의 소스로 통합되었으며,
• 신규 기능은 feature 단위로 개발되어, 고객에 따라 on/off가 가능하도록 설계하고 있다.

그러나 사업 특성상 고객마다 요구사항이 정말 많고, 그걸 안 해줄 수는 없다고 한다.
그래서 사업부는 SaaS 형태의 통합 제공보다는, 고객별 맞춤형 서비스 제공을 선호하는 상황이다.

현재는 Kubernetes 환경에서, 각 고객사마다 pod를 따로 띄워 배포 중이다.

 

추가로, 결국 소스는 하나지만 고객별로 동작 방식이 달라야 하는 상황이 많아서,
내부적으로는 전략 패턴(Strategy Pattern)을 활용해 기능을 분기처리하고 있다.
이 부분은 나중에 별도의 글로 정리해보려 한다.

 

마치며

SaaS와 멀티테넌시는 단순한 기술 용어가 아니라,
비즈니스 모델과 개발 문화까지 함께 변화시켜야 하는 큰 흐름이라는 걸 몸소 느꼈다.

처음부터 완벽하게 도입하기보단 업무와 조직 상황에 맞춰 단계적으로 흡수해가는 것도 좋은 전략이 될 수 있다고 생각한다.