AWS SaaS Builder Toolkit을 활용한 엔터프라이즈 IdP 솔루션의 SaaS 전환 사례

온프레미스 환경에서 고객사마다 개별 설치·운영하던 IAM/MFA 솔루션을 Software as a Service (SaaS)로 전환하는 것은 단순한 기술 마이그레이션이 아닙니다. 제품을 판매하고 가치를 전달하는 방식 자체를 바꾸는 일입니다. AirCUVE는 AWS SaaS Builder Toolkit(SBT)을 활용해 단 3개월 만에 V-FRONT를 멀티테넌트 SaaS 플랫폼으로 전환하고 AWS Marketplace에 등재했습니다. 이 글에서는 그 기술적 여정과 아키텍처 설계 원칙을 공유합니다.

1. V-FRONT 소개 및 SaaS 전환 배경

1.1. V-FRONT 플랫폼 개요

AirCUVE는 사용자 인증과 접근 관리를 위한 통합 플랫폼 V-FRONT를 제공하는 기업입니다. V-FRONT는 단순한 인증 서버를 넘어, 사용자 식별부터 인증 수단 관리, 접근 권한 제어, 감사까지 포함하는 ICAM(Identity, Credential, Access Management) 체계 기반의 통합 IAM/MFA 솔루션입니다.

다양한 사용자 인증 수단

V-FRONT는 SSO를 통한 편의성과 함께, FIDO2/Passkey, 생체인증(얼굴/지문), 모바일 OTP/Push/QR, YubiKey 등 다양한 사용자 인증 수단을 지원합니다. Password-less 환경도 유연하게 구성할 수 있어, AWS 환경에서도 온프레미스 수준의 인증 통제와 보안을 제공하는 IAM/MFA 솔루션으로 자리매김하고 있습니다.

표준 프로토콜 기반의 확장성

OIDC, SAML 2.0을 기본 지원하여 AWS를 포함한 다양한 클라우드 서비스와 SSO 연동이 가능하며, LDAP·AD·DBMS 등 기존 계정 시스템과도 연동됩니다. 글로벌 표준과 K-보안 기술을 결합한 하이브리드 IAM 솔루션으로, 국내외 다양한 규제 환경에 유연하게 대응합니다.

Zero Trust 및 하이브리드 아키텍처 지원

Zero Trust 및 ICAM 가이드라인을 충실히 반영한 구조로, 국내 보안 규제 환경에 최적화된 AWS 연계 인증 플랫폼입니다. 온프레미스, AWS, 하이브리드 아키텍처를 모두 지원하기에, 기존 온프레미스 환경을 유지하면서 AWS로 점진적으로 확장할 수 있습니다.

1.2. SaaS 전환의 필요성

AirCUVE는 기존의 V-FRONT를 고객사 환경에 설치하는 전통적인 온프레미스 방식으로 제공했으며, 이 과정에서 다음과 같은 운영상의 어려움을 겪었습니다:

개별 환경 대응의 복잡성: 고객사마다 상이한 인프라 환경, 보안 정책, 인증 요구사항에 맞춰 개별 설치와 설정을 반복해야 했고, 이로 인해 서비스 온보딩이 지연되었습니다.
커스터마이징 부담 증가: 특히 금융권과 공공기관의 엄격한 보안 요구사항으로 인해 커스터마이징 작업이 늘어났고, 각기 다른 시스템 환경으로 인해 문제 해결과 패치 배포가 복잡해져 효율적인 유지보수가 어려웠습니다.
시장 확장의 제약: AWS 클라우드를 사용하는 고객층으로의 시장 확대가 제한되어, 새로운 비즈니스 기회를 잡기 위한 변화가 필요한 시점이었습니다.

1.3. SaaS 전환을 통한 혁신

AirCUVE는 이러한 도전과제들을 해결하고 제품 혁신에 더 많은 역량을 집중하기 위해 AWS Marketplace를 통한 SaaS 전환을 결정했습니다. 이번 블로그에서는 AirCUVE가 온프레미스 환경에서 운영되던 V-FRONT를 AWS Marketplace에 성공적으로 등재하고 글로벌 SaaS 모델로 전환한 기술적 여정과 성과를 소개합니다.

이 전환을 통해 기존 V-FRONT 설치형 제품 대비 개발 기간 50% 단축, 운영비용 40% 절감, 시스템 가용성 99.99% 달성이라는 성과를 이루었습니다. 단순한 인프라 이전을 넘어, 고객에게 가치를 전달하는 방식 자체가 바뀐 여정이었습니다.

2. SaaS Builder Toolkit을 활용한 아키텍처 설계 여정

2.1. SBT 도입 배경

이번 프로젝트의 목표는 안정적인 멀티테넌트 SaaS 버전의 V-FRONT를 3개월 내 구축하는 것이었습니다. 이를 위해 AWS SaaS Builder Toolkit(SBT)을 핵심 프레임워크로 선택했습니다.

SBT는 AWS와 AWS 파트너사들이 공동으로 개발한 오픈소스 프로젝트로, AWS Cloud Development Kit(AWS CDK) 기반의 재사용 가능한 구성 요소와 멀티테넌트 SaaS 개발 모범 사례를 제공합니다. SaaS 개발에서 반복적으로 구현해야 하는 핵심 기능들이 이미 검증된 형태로 제공되어 있어, 팀이 인프라 기반 작업보다 애플리케이션 및 비즈니스 로직 개발에 집중할 수 있습니다.

SBT의 핵심 설계 원칙은 Control Plane과 Application Plane의 명확한 분리입니다. Control Plane은 테넌트 온보딩, 사용자 관리, 청구 관리 등 SaaS 운영에 필요한 관리 기능을 담당하고, Application Plane은 실제 비즈니스 로직이 동작하는 애플리케이션 영역을 담당합니다. 두 영역은 Amazon EventBridge를 통한 이벤트 기반 아키텍처로 연결되어, 각각 독립적으로 확장하고 관리할 수 있는 구조를 제공합니다.

내부적으로 자세히 살펴보면 SBT는 크게 4개의 스택(Control Plane Stack, Core App Plane Stack, Shared Infrastructure Stack, Tenant Template Stack)으로 구성되며, 각 스택은 명확한 역할 분리를 통해 확장성과 유지보수성을 보장합니다: 이러한 4-Stack 구조는 대규모 SaaS 플랫폼에서 각 레이어를 독립적으로 확장하고 관리할 수 있도록 설계되었으며, 엔터프라이즈급 SaaS 구축의 모범 사례를 반영합니다.

[그림 1] SBT(SaaS Builder Toolkit) Reference Architecture

2.2. 복잡함을 단순함으로 – Rapid SaaS Architecture

SBT의 4-Stack 구조는 대규모 엔터프라이즈 SaaS 플랫폼에 적합하도록 설계되었습니다. V-FRONT 프로젝트는 3개월 내 MVP 완성 및 AWS Marketplace 등재라는 명확한 목표를 설정했으며, 초기 단계에서는 4개 스택의 세밀한 분리보다 핵심 기능 구현과 빠른 시장 진입에 집중할 필요가 있었습니다. 이에 따라 SBT의 핵심 원칙은 유지하면서도, 프로젝트 일정과 목표에 최적화된 2-Stack 구조로 재구성했습니다.

아키텍처 단순화 전략:

Control Plane + Core App Plane → 통합 Control Plane: 테넌트 관리와 공통 애플리케이션 로직을 하나의 스택으로 통합하여 초기 개발 복잡도 감소
Shared Infrastructure + Tenant Template → Application Plane: 공유 리소스와 테넌트별 템플릿을 하나의 애플리케이션 플레인으로 통합하여 프로비저닝 로직 단순화
결과: ‘하나의 Control Plane이 여러 개의 Application Plane을 프로비저닝한다’는 직관적인 구조 확립

이러한 단순화를 통해 개발팀이 아키텍처를 빠르게 이해하고 구현에 집중할 수 있었으며, 3개월 내에 안정적인 멀티테넌트 SaaS를 구축할 수 있었습니다. 본 프로젝트에서는 이 구조를 ‘Rapid SaaS Architecture’로 명명했습니다.

[그림 2] Rapid SaaS Architecture

2.3. 고객 니즈에 맞춘 멀티테넌트 전략

V-FRONT의 고객층은 비용 효율성을 중시하는 중소기업부터 높은 격리 수준을 요구하는 금융·공공기관까지 다양합니다. 이 다양한 요구사항을 하나의 플랫폼에서 수용하기 위해 두 가지 테넌트 티어를 설계했습니다.

구분	Pooled Tier	Silo Tier
대상	중소기업, 비용 효율 우선 고객	엔터프라이즈, 금융/공공기관
격리 수준	논리적 격리(DB Instance 공유)	물리적 격리(VPC 독립)
프로비저닝 시간	5-10분	15-20분
온프레미스 연결	미지원	AWS Direct Connect / AWS Site-to-Site VPN

Pooled Tier는 공유 리소스(Amazon RDS, Amazon ElastiCache) 위에 테넌트별 독립 ECS Cluster를 프로비저닝하는 구조로, 빠른 온보딩과 비용 효율성을 동시에 확보합니다. Silo Tier는 VPC부터 모든 인프라를 테넌트별로 완전히 분리하여 엄격한 보안 요구사항을 충족하며, 기존 온프레미스 AD/LDAP 시스템과의 직접 연결도 지원합니다.

3. 클라우드 네이티브로의 기술적 전환

3.1. 컨테이너화 – 첫 번째 도전

V-FRONT를 클라우드로 옮기는 첫 번째 단계는 기존 온프레미스 애플리케이션을 컨테이너화하는 것이었습니다. 이는 단순히 컨테이너 이미지를 만드는 것 이상의 의미를 가졌습니다. 기존에 물리 서버나 가상머신에서 동작하던 애플리케이션을 클라우드 네이티브 환경에 최적화된 형태로 재구성해야 했기 때문입니다.

본 프로젝트에서는 Amazon Elastic Container Service(Amazon ECS)에서 AWS Fargate를 컨테이너 실행 환경으로 사용했습니다. 서버리스 컨테이너 실행 환경인 Fargate는 인프라 관리 부담을 크게 줄여주면서도, 각 테넌트별로 독립적인 컨테이너 환경을 제공할 수 있습니다. Application Load Balancer를 통한 트래픽 분산과 AWS WAF를 통한 웹 애플리케이션 보안까지 고려한 완전한 컨테이너 기반 아키텍처를 구축했습니다.

컨테이너화 전환의 핵심 요소들:

컨테이너 기반 애플리케이션 패키징으로 환경 일관성 확보
Amazon ECS 및 AWS Fargate를 통한 서버리스 컨테이너 실행
Application Load Balancer를 통한 고가용성 트래픽 분산
AWS WAF 적용으로 웹 애플리케이션 보안 강화

3.2. Infrastructure as Code – 모든 것을 코드로

SaaS 환경에서는 동일한 인프라를 반복적으로, 그리고 일관성 있게 배포할 수 있어야 합니다. 이를 위해 AWS CDK를 활용하여 모든 인프라스트럭처를 코드로 정의했습니다. 특히 인상적이었던 부분은 테넌트별 리소스를 템플릿화할 수 있다는 점입니다. Control Plane에서 새로운 테넌트 생성 요청이 들어오면, 미리 정의된 CDK 템플릿을 기반으로 해당 테넌트에 필요한 모든 AWS 리소스가 자동으로 생성됩니다. 이는 수동 작업으로 인한 실수를 방지하고, 일관된 품질의 인프라를 보장해주었습니다.

IaC 구조는 두 개의 주요 스택으로 구성되었습니다. Control Plane Stack은 테넌트 관리와 프로비저닝 로직을 담당하고, Application Plane Stack은 각 테넌트별 리소스 템플릿을 정의하며, 티어에 따른 네트워킹과 보안 같은 공통 리소스를 관리합니다.

3.3. 자동화된 배포 파이프라인 구축

개발 속도와 배포 안정성을 동시에 확보하기 위해 두 가지 다른 배포 전략을 적용했습니다. Control Plane의 경우, SBT 기반이라 상대적으로 변경사항이 적을 것으로 예상되어 GitLab Branch 전략을 채택했습니다. dev, stg, prod 브랜치를 각각의 AWS 계정과 1:1로 매핑하여, 브랜치별로 자동 배포가 이루어지도록 구성했습니다. 이를 통해 안정적인 단계별 배포가 가능했습니다.

반면 Application Plane은 프로젝트 기간 동안 빈번한 변경이 예상되어 Trunk-based Development 전략을 선택했습니다. main 브랜치 중심의 단순한 구조로 개발 속도를 높이되, 버전 태깅을 통해 각 환경별로 원하는 버전을 선택적으로 배포할 수 있도록 했습니다.

배포 전략의 핵심:

Control Plane: GitLab Branch 전략으로 안정성 확보 (dev/stg/prod 브랜치별 자동 배포)
Application Plane: Trunk-based Development로 개발 속도 향상 (main 브랜치 기반 버전 태깅)

[그림 3] Rapid SaaS CI/CD Pipeline

3.4. 하이브리드 연결 – 온프레미스와 클라우드의 만남

V-FRONT의 많은 고객들이 기존 시스템과의 연동을 필요로 했습니다. 특히 금융기관이나 대기업의 경우, 기존 Active Directory나 LDAP 시스템과의 원활한 연동이 필수 요구사항이었습니다. 이 문제를 해결하기 위해 AWS PrivateLink를 핵심 기술로 활용했습니다. AWS PrivateLink를 사용하면 고객의 네트워크와 SaaS 환경 사이에 복잡한 네트워크 연결을 구성하지 않고도, 특정 서비스 엔드포인트에 대해서만 안전한 프라이빗 연결을 제공할 수 있습니다.

실제로 구현해보니 고객사의 테넌트가 자신들의 AD 서버나 데이터베이스에 접근할 때 마치 같은 네트워크에 있는 것처럼 자연스럽게 연동되었습니다. 동시에 고객사의 직원들도 자신의 업무 단말에서 V-FRONT 서비스에 완전히 프라이빗한 경로로 접근할 수 있게 되었습니다. 이는 공공기관이나 금융기관처럼 보안 요구사항이 까다로운 고객들에게도 서비스를 제안할 수 있는 기반이 되었습니다.

4. 운영의 새로운 차원 – 모니터링과 관찰 가능성

4.1. 통합 모니터링 시스템 구축

온프레미스에서 SaaS로 전환하면서 운영 방식도 근본적으로 바뀌었습니다. 현장 대응 중심이었던 기존 방식에서 벗어나, Amazon CloudWatch를 중심으로 한 통합 모니터링 시스템을 구축했습니다. Amazon ECS Container Insights with enhanced observability를 사용하면 ECS 기반 컨테이너 환경에서 CPU, 메모리, 네트워크 등 테넌트별 리소스 사용 패턴을 실시간으로 파악할 수 있습니다.

4.2. 구조화된 로깅과 비즈니스 인사이트

모든 애플리케이션 로그를 JSON 기반 구조화 형태로 표준화했습니다. 이를 통해 CloudWatch Logs Insights로 원하는 정보를 손쉽게 쿼리할 수 있게 되었고, CloudWatch Metric Filters를 활용해 로그인 성공/실패 횟수, 기능 사용 빈도, 세션 지속 시간 등 비즈니스 메트릭을 자동으로 추출하는 시스템도 구축했습니다. 고객 데이터의 프라이버시를 안전하게 보호하면서도 서비스 개선에 필요한 인사이트를 확보할 수 있다는 점이 핵심 가치였습니다.

AWS X-Ray와 OpenTelemetry를 활용한 분산 트레이싱으로, 사용자 요청이 시스템을 통과하는 전체 경로를 시각적으로 추적하고 성능 병목을 정확히 파악하여 최적화하기도 했습니다.

4.3. SLA/SLO 체계 구축

SaaS 제공자로서 고객에게 명확한 서비스 수준을 약속해야 했습니다. 이를 위해 SLI(Service Level Indicator), SLA(Service Level Agreement), SLO(Service Level Objective)를 체계적으로 정의했습니다.

가용성: 99.99%
API 응답 시간: 95th percentile 기준 목표 레이턴시 이내 처리
처리 능력: 테넌트당 1,000 TPS
장애 복구: 15분 이내

실제 부하 테스트 결과 100명 동시 로그인 15분 유지 시 Auth-Portal 95th percentile 416ms, Self-Service Portal 1.3s 이내로 처리되었으며, 총 2,283건의 인증이 성공적으로 완료되었습니다. 이 기준은 고객에게는 신뢰를, 내부적으로는 지속적인 개선의 동기를 제공했습니다.

5. 보안과 신뢰 – 엔터프라이즈급 보안 체계 구축

5.1. 다층 보안과 Zero Trust 접근 제어

IdP 솔루션을 SaaS로 제공한다는 것은 고객의 가장 민감한 인증 정보를 관리한다는 의미입니다. 이를 위해 네트워크, 애플리케이션, 데이터 레이어에 걸친 다층 보안 전략을 구현했습니다.

네트워크 레이어에서는 VPC, 서브넷, 보안 그룹을 통한 철저한 격리를 적용했으며, Silo Tier의 경우 테넌트별 독립 VPC를 제공합니다. 데이터 레이어에서는 전송 중 데이터에 TLS 1.3, 저장 중 데이터에 AES-256 암호화를 적용하고, 모든 암호화 키는 AWS KMS로 관리합니다.

Zero Trust 원칙에 따라 IAM 역할 기반의 최소 권한 원칙을 적용하여 각 구성 요소가 필요한 권한만 갖도록 설계했습니다. 모든 API 호출과 시스템 접근은 AWS CloudTrail을 통해 변조 불가능한 형태로 기록되며, 관리자의 테넌트 데이터 접근에는 별도의 승인 프로세스를 적용하여 내부자 위협도 방지했습니다.

5.2. 컴플라이언스 – 국내외 규제 대응

V-FRONT가 국내 공공기관 및 금융기관 시장에서 경쟁하기 위해서는 규제 준수가 필수 요건이었습니다. 특히 CSAP(클라우드 서비스 보안 인증)는 국내 공공기관 클라우드 도입의 필수 요건으로, CSAP SaaS 표준등급 인증 대응을 통해 국내 공공기관 및 금융기관 고객에게 규제 준수 환경을 제공할 수 있는 기반을 마련했습니다.

핵심 컴플라이언스 준비 항목:

CSAP: 국내 클라우드 서비스 보안 인증 (공공기관 필수 요건)
ISO 27001: 체계적인 정보보안 관리 체계 구축
SOC 2 Type II: 운영 통제 효과성 입증
GDPR: 글로벌 개인정보보호 규정 대응

단순한 인증 취득을 넘어, 정기적인 보안 감사·취약점 스캔·침투 테스트를 통해 보안 수준을 지속적으로 유지하고 개선하는 체계를 구축했습니다.

6. AWS Marketplace 진출 – 글로벌 무대로의 도약

6.1. 새로운 판매 채널과 Co-sell 기회

AWS Marketplace 진출은 단순한 판매 채널 확장을 넘어 비즈니스 모델의 변화를 수반했습니다. 고객이 서드파티 솔루션 비용을 AWS 빌링과 통합해 처리할 수 있고, 기존 AWS 약정(EDP, Enterprise Discount Program) 예산을 활용한 구매도 가능해져 도입 과정이 간소화되었습니다. 또한 Marketplace 등재는 AWS Co-sell 프로그램 참여의 전제 조건으로, AWS 영업팀과의 공동 고객 발굴이 가능해지면서 기존에 접근하기 어려웠던 엔터프라이즈 고객층으로의 확장 기반이 마련되었습니다.

3개월이라는 제한된 프로젝트 기간과 기존 고객사의 영업 방식을 고려해, 복잡한 사용량 측정 시스템이 필요한 구독형 대신 계약형(Contract) 모델을 우선 채택했습니다. 이 결정 덕분에 핵심 기능 구현에 집중할 수 있었고, 기존 온프레미스 고객의 전환 부담도 최소화했습니다. 향후 실제 사용 패턴 데이터가 쌓이면 Pay-as-you-go 구독형으로 확장할 계획입니다.

6.2. 기술 연동과 파트너 생태계 확장

기술적 연동은 두 가지 핵심 컴포넌트로 구성됩니다. Landing API는 고객이 Marketplace에서 제품 구매 시 토큰을 검증하고 SaaS 애플리케이션으로 온보딩을 처리하며, Entitlements Handler는 Amazon Simple Notification Service(Amazon SNS)를 통해 수신한 계약 변경 이벤트(신규/갱신/만료) 를 AWS Lambda를 거쳐 Amazon DynamoDB에 실시간 반영합니다. 향후 Best Practice에 따라 SNS → SQS → Lambda 구조로 전환할 예정입니다. Amazon Simple Queue Service(Amazon SQS)를 중간에 두면 Lambda 처리 실패 시 메시지가 큐에 보존되어 자동 재시도가 가능하고, Dead Letter Queue(DLQ)를 통한 실패 이벤트 격리, 동시성 제어를 통한 경쟁 상태 방지, 그리고 트래픽 급증 시 버퍼 역할까지 확보할 수 있어 Entitlement 이벤트 유실로 인한 과금 불일치를 예방할 수 있습니다.

판매 채널 확장을 위해 CPPO(Channel Partner Private Offer) 모델도 함께 구축했습니다. CPPO는 AWS MSP 파트너사가 고객에게 Marketplace 제품을 대신 판매할 수 있는 간접 판매 채널입니다. 이미 고객과 신뢰 관계를 구축한 파트너 네트워크를 활용함으로써, 직접 영업만으로는 닿기 어려운 고객층까지 효과적으로 확장할 수 있습니다. Marketplace 등재 → Co-sell → CPPO로 이어지는 이 성장 구조는 AirCUVE가 글로벌 AWS 생태계 안에서 독립적으로 영업하는 것을 넘어, AWS 및 파트너 네트워크와 함께 성장할 수 있는 핵심 기반이 되었습니다.

7. 성과 및 교훈

7.1. 정량적 성과

3개월간의 프로젝트를 통해 다음과 같은 성과를 달성했습니다:

개발 기간: 3개월 (일반적인 SaaS 개발 대비 50% 단축)
테넌트 프로비저닝 시간: Pooled Tier 5-10분, Silo Tier 15-20분
시스템 가용성: 99.99% 업타임 달성
비용 효율성: 온프레미스 대비 운영비용 40% 절감
확장성: 테넌트당 1,000 TPS, 수평 확장으로 유연 대응

7.2. 핵심 성공 요인

SBT 프레임워크 활용

AWS SaaS Builder Toolkit의 모범 사례를 기반으로 하되, 프로젝트 요구사항에 맞게 커스터마이징함으로써 개발 속도와 품질을 동시에 확보했습니다

단계적 접근 방식

구현이 복잡한 구독형 모델 대신, 계약형 모델을 먼저 개발하여 빠른 시장 진출을 달성하고, 이후 점진적으로 기능을 확장하는 전략을 채택했습니다.

운영 중심 설계

초기 설계 단계부터 모니터링, 로깅, 알람 시스템을 고려하여 안정적인 서비스 운영 기반을 마련했습니다.

7.3. 주요 교훈

아키텍처 설계 시 고려사항:

멀티테넌시 전략은 비즈니스 모델과 고객 요구사항을 종합적으로 고려하여 결정
보안과 컴플라이언스는 초기 설계 단계부터 반영
운영 효율성을 위한 자동화와 모니터링 시스템 구축 필수
비용 최적화를 위한 리소스 공유와 격리의 균형점 찾기

8. 결론

본 사례는 AWS SaaS Builder Toolkit(SBT)을 활용해 기존 온프레미스 IdP 솔루션을 3개월의 짧은 기간에 멀티테넌트 SaaS 플랫폼으로 전환하고, AWS Marketplace에 성공적으로 진출한 여정을 담고 있습니다.

이 프로젝트의 주요한 성공 요인은 ‘완벽한 준비보다 빠른 실행‘이었습니다. 표준 SBT를 2개 컴포넌트로 단순화한 Rapid SaaS Architecture, 계약형 모델 우선 선택, 초기 설계부터 모니터링과 보안을 내재화한 운영 중심 사고—이 세 가지가 맞물려 짧은 기간 내 성공적인 결과물을 만들어냈습니다.

SaaS 전환을 고려하는 기업이라면, 검증된 프레임워크를 자신의 상황에 맞게 재해석하고 운영과 보안을 처음부터 설계에 녹여내는 것이 중요함을 이 사례가 보여줍니다.

추가 리소스:

V-FRONT SaaS에 관심이 있거나 유사한 SaaS 전환을 계획하고 있다면 다음 리소스를 참고하세요:

AWS 기술 블로그