SaaS 아키텍처, 테넌트 격리 방식이 나머지를 결정한다

고객이 하나 늘 때마다 서버를 새로 띄워야 하는 서비스는 SaaS가 아니다. SaaS(Software as a Service)를 가르는 기준은 결국 여기다 — 애플리케이션 코드베이스 하나를 여러 테넌트가 나눠 쓰는 멀티테넌시 위에서, 사용자는 설치나 운영 부담 없이 브라우저나 경량 클라이언트로 기능만 소비하는 구독형 모델이다. 책임의 경계도 그만큼 뚜렷하다. 공급자는 애플리케이션, 데이터 저장, 가용성, 보안 통제를 주도해서 관리하고, 사용자는 자기 데이터 품질과 접근 권한, 설정을 책임진다. 서버·라이선스·운영 인건비까지 공급자가 떠안는 구조라 초기 CAPEX가 OPEX로 전환되고, 이 방식만으로 TCO 30~50% 절감을 기대할 수 있다. XaaS(Anything as a Service) 안에서 보면 IaaS가 인프라를 내주고 PaaS가 플랫폼을 내주는 동안, SaaS는 최종 사용자 가치에 가장 가깝게 붙는 최상위 서비스 계층에 해당한다.

테넌트를 어떻게 나눌 것인가부터 정해야 한다

멀티테넌시 아키텍처에서 맨 처음 부딪히는 결정이 격리 방식이다. 테넌트마다 전용 DB를 두는 방식, 하나의 DB를 공유하되 스키마는 테넌트별로 나누는 방식, 아예 테이블까지 공유하고 Row-Level Security로 행 단위 접근만 가르는 방식 — 이 세 조합 중 어디를 고르느냐는 데이터 주권 요구와 성능 요구가 결정한다. 전용 DB는 격리가 강한 만큼 운영 비용이 크고, 완전 공유 테이블은 자원 효율이 가장 높지만 한 쿼리 실수가 다른 테넌트 데이터를 노출시킬 위험을 안는다.

컴퓨트·스토리지·네트워크를 테넌트 간에 공유해 규모의 경제를 실현하는 것 자체가 SaaS의 본질적인 이점이지만, 그만큼 한 테넌트의 트래픽 폭주가 다른 테넌트에 그대로 번지는 노이즈 네이버 문제가 따라붙는다. QoS와 리소스 쿼터 정책 없이는 이 공유 이점이 바로 장애 전파 경로가 된다.

배포는 테넌트 단위로 조심스럽게 굴린다

CI/CD 파이프라인에 카나리·블루그린 배포를 적용하는 것 자체는 다른 서비스와 다를 게 없지만, SaaS에서는 스키마 마이그레이션이 다운타임 없이 지나가야 한다는 제약이 하나 더 붙는다. 하위 호환을 유지하는 Backward-Compatible 마이그레이션이나 Online DDL을 쓰는 이유가 여기 있다. 릴리스는 Stable·Beta·Canary 채널로 나누고 피처 플래그를 도입해서, 새 기능을 전체 테넌트에 한 번에 켜는 대신 테넌트별로 점진적으로 활성화하며 리스크를 분산한다. 이 체계로 기능 롤아웃 리드타임을 60~80% 단축하고, 신규 테넌트 프로비저닝도 수분 내로 자동화할 수 있다.

인증·데이터 보호와 눈에 보이지 않는 관측성

인증·인가는 SAML이나 OIDC 기반 SSO, MFA, SCIM 프로비저닝 연계로 처리하고, 테넌트 경계를 벗어나지 못하게 스코프 기반 RBAC나 ABAC로 통제한다. 데이터는 전송·저장 구간 모두 KMS나 HSM으로 암호화하고 키를 주기적으로 롤오버하며 키 자체도 분리 관리하는데, 여기에 감사 로그와 활동 추적, 법적 보존 요구까지 얹혀야 SaaS 수준의 보안 준수가 된다.

관측성은 SLO 기반으로 가용성·지연시간·오류율을 모니터링하고 에러 버짓을 운영하는 방식이 표준이다. 다만 테넌트별로 메트릭·트레이스·로그를 따로 걷지 않으면 특정 테넌트 하나의 장애가 전체 평균 지표에 묻혀버리기 때문에, 멀티테넌트 단위의 수집은 선택이 아니라 필수다. SLA는 보통 99.9~99.99% 가용성 구간에서 정해지고, 지원 등급별로 응답·해결 시간이 별도로 명문화된다.

요청이 실제로 흐르는 경로

⤢✕

요청은 API Gateway에서 인증을 먼저 통과하고, Tenant Router가 도메인·헤더·토큰으로 테넌트를 식별한 뒤 그 테넌트가 전용 DB인지 공유 스키마인지에 따라 다른 경로로 갈린다. 오류율이 오르면 오토스케일이 반응하고, 요청 한도를 넘기면 429와 Retry-After로 클라이언트에 신호를 준다.

돈은 구독과 사용량을 섞어서 번다

과금은 구독과 사용량을 혼합한 요금제가 일반적이다. 사용자 수, 요청 수, 저장 용량, 통합 커넥터 수 같은 지표를 실시간으로 계량해서 청구하고 한도를 관리해야 하고, 여기에 엔티틀먼트 관리와 업셀·크로스셀 경로까지 내장해서 가격 실험과 할인 정책을 A/B로 운영하는 것도 SaaS 특유의 수익화 방식이다.

실무에서 SaaS가 놓이는 자리

엔터프라이즈 업무 애플리케이션 — CRM·ERP·ITSM·협업 도구를 글로벌 멀티리전으로 제공하면서, 데이터 주권 요구가 있는 국가에는 리전을 핀닝한다. 데이터 분석·통합 — ELT·Reverse ETL, 대시보드, 이벤트 스트리밍을 SaaS로 내주고 커넥터 마켓플레이스로 확장한다. 개발자 생산성 — 소스 리포지토리, CI/CD, 테스트, 피처플래그, 관측성 플랫폼을 SaaS로 도입하면서 사내 IdP 연동과 감사 추적을 강화한다.

도입은 적합도 평가에서 시작한다

입력은 비즈니스 요구사항, 규제·보안 요구, 통합 대상 시스템 목록이다. 처리 단계는 넷이다. 데이터 민감도·지역 규제·성능 SLO·커스터마이징 필요도로 적합도를 평가하고, IP Allowlist나 Private Link 같은 네트워크 제약과 SSO/SCIM, 로그 수집 경로를 설계하고, 데이터 맵핑과 병행 운영·검증 계획으로 마이그레이션을 수행하고, 모니터링 대시보드와 런북·알림, RACI로 운영 체계를 세운다. 출력은 서명 가능한 SLA·DPA, 운영 핸드북, 롤백 계획, 비용 예산서다.

XaaS 계층별로 늘어놓고 비교하면

모델	성능	확장성	일관성	안정성	운영 편의
IaaS	사용자 설계에 따라 고/중 변동	수평/수직 스케일 수월	데이터 일관성 직접 설계 필요	구성 품질에 의존	인프라 운영 부담 높음
PaaS	런타임 최적화로 중~고	오토스케일 내장	트랜잭션/스토리지 옵션 제공	관리형 서비스로 중~고	애플리케이션에 집중 용이
SaaS	애플 공유형 최적화로 중~고	테넌트 단위 무중단 확장	앱 수준 일관성 보장	다중 AZ/리전으로 고	최고 수준의 운영 편의
DaaS	워크스테이션 대체로 중	세션/호스트 풀 확장 용이	상태 관리 전략 필요	네트워크 품질에 민감	단말 관리 부담 축소
XaaS	메타 모델로 다양	서비스별 상이	서비스별 상이	서비스별 상이	카탈로그 기반 선택 편의

표준화와 커스터마이징 사이

보안 쪽 모범사례는 SSO·MFA, 키 관리 분리, 고객관리형 키 옵션, Row-Level Security, 고객 데이터 암호화·분리 저장이다. 운영 쪽은 에러 버짓·SLO, 멀티테넌트 관측성, 카나리 배포, 장애 게임데이, 랜딩존·프라이빗 연결 구성으로 이어진다. 다만 이 모든 표준화에는 대가가 있다 — 커스터마이징 한계와 벤더 종속 리스크는 구조적으로 남고, 데이터 거버넌스·레포팅 요구가 높은 고객을 만나면 하이브리드 구성이나 BYOK, 데이터 이그레스 전략을 별도로 병행해야 한다.