SaaS 아키텍처 — 엔터프라이즈 플랫폼을 위한 실무 엔지니어링 가이드

한눈에 보기

SaaS 아키텍처는 모든 플랫폼이 따라야 할 단 하나의 정석 다이어그램이 있는 것처럼 논의되는 경우가 많은데, 이는 오해를 불러일으킵니다 — 진정한 규율은 잘 알려진 기업의 엔지니어링 블로그에서 복사하는 대신 특정 제품의 실제 요구사항에 맞춰 멀티 테넌시, 인증, 청구, 확장을 둘러싸고 내리는 신중한 트레이드오프의 집합입니다.

이 가이드는 SaaS 아키텍처가 실제로 무엇인지부터 시작해, 엔터프라이즈 플랫폼을 처음부터 끝까지 구성하는 핵심 구성 요소를 다룬 뒤, 멀티 테넌시 모델, 인증과 인가, 청구 및 구독 시스템, 확장성과 안정성, 보안과 규정 준수를 구체적으로 더 깊이 다룹니다.

멀티 테넌시는 특별한 주목을 받습니다. 테넌트별 데이터베이스, 테넌트별 스키마, 공유 데이터베이스 중에서의 결정은 실제 고객 데이터가 쌓인 뒤에는 되돌리기 가장 어려운 결정 중 하나이기 때문입니다 — 그리고 이는 팀이 그렇게 하고 있다는 것을 인식하든 안 하든 모든 SaaS 플랫폼이 명시적으로 내려야 하는 결정입니다.

유망한 플랫폼을 운영상의 부채로 바꾸는 흔하고 피할 수 있는 실수들도 다룹니다 — 테넌트 격리 무시, 감사 로그 생략, 부차적인 문제로 취급되는 청구, 취약한 권한 모델, 실질적인 모니터링 부재, 확장 전략 부재입니다.

이것은 스타트업 클리셰 가이드가 아닙니다. 전 과정에 걸친 초점은 엔터프라이즈 엔지니어링입니다 — 아키텍처 결정이 장기적인 유지보수성, 보안 태세, 값비싼 재구축 없이 더 크고 더 까다로운 고객을 서비스할 수 있는 플랫폼의 능력에 어떤 영향을 미치는지입니다.

인증, 인가, 보안

인증은 누구인지에 답하고, 인가는 무엇을 할 수 있는지에 답하며, 보안과 규정 준수는 플랫폼이 그 두 가지가 실제로 강제되고 있음을 어떻게 증명하는지에 답합니다 — 계약이 체결되기 전 공식 보안 설문지를 통해서라도 엔터프라이즈 구매자가 서명 전에 면밀히 검토하는 세 가지 밀접하게 연관된 관심사입니다.

멀티 테넌시 모델과 그 사이에서 선택하는 방법

멀티 테넌시는 공유 인프라에서 고객 데이터가 어떻게 격리되는지를 결정하는 아키텍처 결정입니다 — 실제 고객 데이터가 쌓인 뒤에는 되돌리기 가장 어려운 결정 중 하나이며, 그렇기에 이 가이드에서 다루는 다른 거의 모든 결정보다 초기에 제대로 하는 것이 불균형하게 가치 있습니다.

SaaS 아키텍처에서 흔한 실수

유망한 SaaS 플랫폼을 운영 및 보안상의 부채로 바꾸는 반복적이고 피할 수 있는 실수들입니다 — 대부분은 소수의 초기 고객만 있을 때는 눈에 보이지 않다가 비즈니스가 성공하기 시작하고 엔터프라이즈 고객이 더 어려운 질문을 던지기 시작할 때 비용이 드러납니다.

실제로 구축하면 이런 모습입니다

이 가이드에서 다룬 개념을 실제로 구현한, 저희 대표 솔루션 컬렉션의 레퍼런스 아키텍처입니다.