AWS SBT를 활용해 30일 만에 SaaS로 전환하는 방법

뷰런은 자율주행과 스마트 인프라를 위한 LiDAR 인지 소프트웨어를 만드는 회사입니다. 단순히 알고리즘만 개발하는 것이 아니라, 3D 데이터 기반 AI를 실제 산업 현장에 적용하는 데 필요한 엔드투엔드(E2E) 플랫폼 뷰엑스(VueX)를 함께 제공합니다.

북미와 아시아를 중심으로 다양한 글로벌 프로젝트를 수행해 왔고, OEM, Tier 1, 로보틱스, 스마트시티 파트너들과 협업하며 정확성, 실시간성, 안전성을 가장 중요하게 생각합니다.

뷰런이 개발한 인지 AI 개발 플랫폼, 뷰엑스는 단순한 개발 툴이 아닙니다. 데이터 수집 → 라벨링(가공) → 학습 → 검증 → 배포까지 이어지는 전 과정을 하나의 파이프라인으로 연결해, 대규모 데이터 기반 AI 개발을 ‘표준화’하는 플랫폼입니다.

그리고 이번 글에서는, 이 뷰엑스를 단 한 달 만에 SaaS 모델로 전환한 방법과 전환 후 성과에 대해서 이야기해보도록 하겠습니다.

생각보다 큰 설치형 모델의 한계

뷰런은 그동안 뷰엑스를 고객 환경에 직접 설치하는 온프레미스 방식으로 제공해왔습니다. 프로젝트 단위로 인프라를 세팅하고, 고객사 보안 정책에 맞춰 환경을 구성하고, 그 위에 솔루션을 얹는 구조였습니다.

처음에는 유연한 방식처럼 보였으나, 프로젝트가 늘어날수록, 문제는 점점 구조적인 이슈로 바뀌기 시작했습니다.

SaaS vs 온프레미스 비교

프로젝트가 늘어나면 느려지는 온보딩

고객사마다 아래와 같은 인프라가 달랐습니다.

• 사용하는 클라우드/온프레미스 환경이 다르고

• 권한 체계가 다르고

• 보안 정책이 다르고

• 네트워크 구조도 제각각이었습니다

결국 매번 비슷하지만 다른 설치 작업을 반복해야 했습니다. 새 고객을 온보딩할 때마다 환경 분석 → 커스터마이징 → 설치 → 검증 과정을 거쳐야 했고, 이 과정은 자연스럽게 일정 지연으로 이어졌습니다.

버그는 있는데, 재현이 어려웠다

고객사마다 시스템 환경이 다르다 보니 같은 기능이라도 동작 방식이 미묘하게 달랐습니다. 특정 고객 환경에서만 발생하는 버그, 동일 버전인데 서로 다른 동작, 패치 후 또 다른 환경에서 발생하는 이슈와 같은 환경에서 발생하는 문제가 반복되었고, 버그 재현 → 수정 → 재배포 → 검증까지의 사이클이 길어졌습니다.

배포 스크립트도 고객사 네트워크와 보안 구조에 따라 분기되다 보니 배포 속도는 느려지고, 품질 가시성도 떨어졌습니다.

LiDAR 데이터는 테라바이트 단위로 쌓인다

PCD(Point Cloud Data), 라벨 데이터, 학습 모델 아티팩트 등 LiDAR 기반 AI 개발의 특성상 다루는 데이터는 작지 않습니다. 이 모든 것이 테라바이트(TB) 단위로 축적됩니다. 문제는 단순히 “용량이 크다”가 아니었습니다. 고객사별 다른 저장 경로, 표준화되지 않은 데이터 정책, 제각각의 보관 및 백업 전략 등으로 인해 저장 비용 예측은 어려워졌고 비용 최적화가 쉽지 않았습니다. 더군다나 처리 성능도 일정하지 않아 데이터는 쌓이지만, 운영 효율은 오히려 낮아지는 아이러니한 구조였습니다.

국가·리전별 거버넌스 대응도 따로따로

글로벌 프로젝트를 수행하다 보니 국가 및 리전별 데이터 거버넌스 요구사항도 달랐습니다. 각 리전에 맞춰 별도 대응을 해야 했고, 이 또한 설치형 모델에서는 매번 반복 작업이 되었습니다. 결국 엔지니어링 리소스는 제품 고도화가 아니라 환경 대응에 더 많이 투입되고 있었습니다.

결국, 방향을 바꾸기로 했습니다. 우리가 반복적으로 쓰고 있는 이 리소스가 고객 가치를 만드는 일에 잘 쓰이고 있는가?를 생각해봤을 때 답은 명확해졌습니다.

환경별 설치, 설정, 배포 대응에 들어가는 리소스를 줄이고 제품 개발과 플랫폼 고도화에 더 집중해야했습니다. 그 선택이 바로 SaaS 모델 도입이었습니다.

30일 만의 SaaS 전환, 어떻게 가능했을까?

뷰런은 AWS가 제공하는 오픈소스 도구, SaaS Builder Toolkit for AWS(SBT) 를 활용해 뷰엑스를 SaaS 형태로 전환했습니다.

SBT란 무엇인가?

SBT(SaaS Builder Toolkit for AWS)는 AWS에서 SaaS 애플리케이션을 보다 효율적으로 만들 수 있도록 설계한 오픈소스 도구 모음입니다.

AWS Cloud Development Kit

AWS Cloud Development Kit (CDK) is an open-source software development framework used to model and provision your cloud application resources with familiar programming languages.

https://aws.amazon.com/ko/cdk/

SBT의 가장 큰 장점은 두 가지입니다.

1. SaaS에 필요한 공통 구조를 미리 제공

SaaS를 만들 때 반복적으로 등장하는 구성 요소들인 테넌트 관리, 사용자 온보딩, 인증, 서비스 분리 구조 등을 재사용 가능한 형태로 제공합니다.
즉, 기초 작업에 들어가는 시간을 줄여줍니다.

2. AWS CDK 기반의 유연한 인프라 구성

SBT는 AWS의 IaC(Infrastructure as Code) 도구인 CDK 기반으로 만들어졌습니다. 덕분에 코드 수준에서 인프라를 정의하고, 필요에 맞게 구조를 확장하거나 수정할 수 있습니다. 또한, 선도적인 ISV 제품들과의 사전 연동 구성이 포함되어 있어
복잡한 통합 과정을 상당 부분 단순화할 수 있습니다.

SBT를 활용해 구축한 방법 톺아보기

기존 DevOps 자산과 AWS SBT의 시너지: 가속화된 아키텍처 최적화

뷰런이 Cloud SaaS 환경으로의 전격적인 전환을 결정했을 때, 가장 중요하게 고려한 것은 기존의 우수한 개발 문화와 인프라 관리 체계를 얼마나 유연하게 이식할 수 있는가였습니다. 뷰런은 이미 다음과 같은 탄탄한 DevOps 기반을 갖추고 있었습니다.

• 코드형 인프라(IaC)의 내재화: Terraform을 활용해 클라우드 리소스를 체계적으로 관리하며 인프라의 가시성과 재사용성을 확보하고 있었습니다.

• 통합된 CI/CD 및 트래킹 시스템: JIRA와 밀접하게 연동된 CI/CD 파이프라인을 통해 모든 SaaS 서비스의 변경 사항을 실시간으로 추적하고 관리하는 환경을 구축해 왔습니다.

• Feature Flag 기반의 유연한 배포: 지속적인 배포(CD)와 개발 환경의 심리스(Seamless)한 운영을 위해 Feature Flag 방식을 적극 도입하여, 코드 수준에서의 제어 능력을 극대화했습니다.

이러한 뷰런의 기술적 성숙도는 AWS SBT 도입 과정에서 강력한 촉매제가 되었습니다. SBT가 제공하는 표준 가이드 위에서, 뷰런은 기존에 보유한 IaC 역량과 Feature Flag 전략을 활용해 Well-Architected SaaS 구조를 탐색적으로 적용하고 재구성을 반복할 수 있었습니다. 결과적으로 시행착오를 최소화하며 뷰런의 고유한 서비스 특성에 가장 최적화된 SaaS 아키텍처를 빠르게 도출해낼 수 있었습니다.

SaaS 기본 사항

SaaS는 Control Plane, Application Plane 두 가지 영역으로 나뉩니다. Control Plane은 멀티테넌트 SaaS 솔루션을 보다 단일되고 통합된 경험을 제공하기 위해 온보딩, 인증, 테넌트 관리, 운영 및 분석하는 데 사용되는 모든 기능과 서비스를 포함합니다. Application Plane은 애플리케이션의 멀티테넌트, 테넌트별 격리가 구현되는 영역입니다.

SBT는 CDK(Cloud Development Kit) 로 구축되었습니다. CDK는 코드를 사용하여 클라우드 인프라를 정의하고, AWS CloudFormation을 통해 이를 배포하는 오픈 소스 프레임워크입니다. SBT를 통해 Control Plane과 Application Plane을 쉽게 구축할 수 있습니다. CDK 응용 프로그램을 개발환경에 구성한 후, 아래와 같이 SBT 구성요소를 설치 할 수 있습니다.

npm install @cdklabs/sbt-aws

Control Plane

SBT 패키지 설치 후에, SaaS 서비스를 위해 아래와 같이 Control Plane을 구축하기 위한 파일을 생성합니다. 여기서, SaaS 서비스 관리자가 임시 비밀번호를 수신할 수 있는 실제 이메일 주소를 전달합니다.

import { CognitoAuth, ControlPlane } from '@cdklabs/sbt-aws';
import { Stack } from 'aws-cdk-lib';
import { Construct } from 'constructs';

export class ControlPlaneStack extends Stack {
 public readonly regApiGatewayUrl: string;
 public readonly eventBusArn: string;

 constructor(scope: Construct, id: string, props: any) {
   super(scope, id, props);
   const cognitoAuth = new CognitoAuth(this, 'CognitoAuth', {
     idpName: 'COGNITO',
     systemAdminRoleName: 'SystemAdmin',
     systemAdminEmail: 'ENTER YOUR EMAIL HERE',
   });

   const controlPlane = new ControlPlane(this, 'ControlPlane', {
     auth: cognitoAuth,
   });
   this.eventBusArn = controlPlane.eventBusArn;
   this.regApiGatewayUrl = controlPlane.controlPlaneAPIGatewayUrl;
 }
}

이 예제에서는 “ControlPlaneStack”이라는 새로운 CDK 스택 을 만들고 있다는 점에 주목하세요. 이 스택에서 우리는 @cdklabs/sbt-aws 패키지를 import 해서 단일 ControlPlane Construct를 만들고 있습니다. 이 Construct는 다양한 프로퍼티들을 이용하여 생성되며, 대부분은 Amazon EventBridge 을 통한 통신을 설정하는 데 이용됩니다.

여기서 주목할 만한 또 하나의 중요한 개념은 플러그 접근 방식입니다. 참고로 여기에 구현 “cognitoAuth”라는 “auth” 컴포넌트는 SBT 코어 패키지에 정의된 IAuth 인터페이스를 구현합니다. 현재 IAuth를 Amazon Cognito로 구현했지만, 이 인터페이스를 구현한 어떤 아이덴티티 프로바이더라도 구현할 수 있도록 설계되었습니다.

Application Plane

Application Plane 구축의 핵심은 Control Plane과의 연결을 고성능 서버리스 EventBridge 기반으로 구현하는 매커니즘을 제공하는 데 있습니다.

export interface AppPlaneProps extends cdk.StackProps {
 eventManager: sbt.IEventManager;
}

export class ApplicationPlaneStack extends Stack {
 constructor(scope: Construct, id: string, props: AppPlaneProps) {
   super(scope, id, props);

   const ProvisioningScriptJobProps: TenantLifecycleScriptJobProps = {
     eventManager,
     permissions: new PolicyDocument({
       statements: [
         new PolicyStatement({
           actions: ['*'],
           resources: ['*'],
           effect: Effect.ALLOW,
         }),
       ],
     }),
     script: fs.readFileSync('./scripts/Provisioning.sh', 'utf8'),
     environmentStringVariablesFromIncomingEvent: ['tenantId', 'tier', 'tenantName','email'],
     environmentVariablesToOutgoingEvent: {
       tenantData:['tenantS3Bucket', 'tenantConfig', 'prices', 'tenantName','email'],
       tenantRegistrationData: ['registrationStatus'],
     }
   };
   const ProvisioningScriptJob: ProvisioningScriptJob = new ProvisioningScriptJob(
     this,
     'ProvisioningScriptJob',
      ProvisioningScriptJobProps
   );
   new sbt.CoreApplicationPlane(this, 'CoreApplicationPlane', {
     eventManager: props.eventManager,
     scriptJobs: [ProvisioningScriptJobProps],
   });
 }
}

이 코드는 SBT의 Core Application Plane을 사용하여 EventBridge로 SaaS의 두 영역을 연결합니다. 또한, 온보딩 프로세스를 구현하기 위해 SBT의 TenantLifecycleScriptJobProps를 사용합니다. 이 기능을 통해 SaaS 구현 시 일반적으로 여러 컴포넌트와 단계에 걸쳐 복잡하게 구현되기 쉬운, 온보딩 프로세스를 단일 지점에서 통합적으로 처리할 수 있습니다. 이처럼, SBT를 이용하면 비즈니스 요구사항에 맞는 서비스들의 배포와 프로비저닝을 중앙화된 방식으로 효율적으로 구축할 수 있습니다. 자세한 사항은 핸즈온 워크숍을 통해 SBT의 전체적인 아키텍처를 경험해보실 수 있습니다.

뷰엑스의 SaaS 아키텍처

뷰엑스는 LiDAR AI 개발을 위한 데이터 수집, 라벨링, 학습, 검증, 배포까지 전 과정을 SaaS 서비스로 제공합니다. 뷰런은 SBT를 기반으로 Control Plane과 Application Plane을 적용하고, 고객이 셀프 온보딩 후 바로 데이터를 업로드하고 AI 파이프라인을 실행할 수 있도록 설계 및 구현했습니다.

Control Plane 구성

Control Plane은 SaaS 서비스 운영을 위해 공통적으로 필요한, 온보딩/오프보딩, 테넌트 인증, 테넌트 등록, 사용자 관리의 기능을 SaaS 관리자에게 제공합니다. 이 영역은 SBT 를 이용해 구현되었으며, SBT를 통해 Control Plane 기능을 위해 필요한 Amazon API Gateway, Amazon EventBridge, AWS Step Functions, AWS CodeBuild, Amazon DynamoDB, Amazon Cognito를 자동으로 구성하고, 서비스를 위한 테넌트 관리, 사용자 관리, 온보딩 처리를 위한 Lambda 함수들이 프로비저닝 됩니다.

뷰엑스를 구독하는 테넌트는 AWS Marketplace에서 뷰엑스 SaaS를 구독하거나 초대를 통해 가입합니다. Cognito가 사용자 인증과 권한 관리를 담당하고, SaaS 서비스의 API Gateway는 외부 요청을 받아 Control Plane과 Application Plane으로 전달합니다. Control Plane DB는 모든 테넌트 메타데이터를 저장하며, 이를 기반으로 Application Plane의 리소스가 프로비저닝 됩니다.

Application Plane 구성

고객 데이터와 AI 워크로드는 Application Plane에서 실행됩니다. 뷰엑스의 여러 테넌트들을 위한 서비스를 진행하기 위해, AWS의 관리형 Kubernetes 서비스인 Amazon Elastic Kubernetes Service(EKS) 를 사용하며, EKS는 SaaS 서비스를 구축하는 최적의 환경을 제공합니다. 각 테넌트 워크로드와 관련 테넌트 관련 오브젝트들은 Namespace 단위로 격리됩니다. 테넌트에 대한 리소스는 티어(구독 플랜)에 따라 다른 방식으로 할당되며, 각 티어별 리소스는 Auto Scaling Group과 GPU 노드를 통해 라벨링/추론 워크로드를 수평 확장됩니다.

• Free 티어 (Pool): 여러 테넌트가 하나의 클러스터와 리소스를 공유합니다. 리소스를 공유하므로 비용 효율적으로 이용할 수 있습니다.

• Standard 티어 (Less Pool): 테넌트별로 네임스페이스는 분리하되 일부 리소스를 공유합니다. 성능과 격리 수준의 균형을 제공합니다.

• Premium 티어 (Silo): 특정 테넌트가 전용 리소스를 할당받습니다. Amazon RDS, Amazon Simple Queue Service(Amazon SQS), Amazon ElastiCache(Redis) 까지 모두 전용으로 제공되어 높은 보안과 성능이 요구되는 엔터프라이즈 환경에 적합합니다.

데이터 경로와 보안 설계

뷰엑스는 AI Annotation 기능을 제공하며 대규모 3D Point Cloud 데이터를 안전하고 효율적으로 처리하도록 설계되었습니다. 테넌트별 Point Cloud Data(PCD)는 Amazon S3에 저장되며, 내부 GPU 학습 노드 등은 S3 Gateway Endpoint를 통해 VPC 내에서 직접 접근합니다. 이 아키텍처는 데이터를 외부 인터넷으로 노출시키지 않으므로 데이터 전송 비용을 절감하고 보안을 극대화합니다.

데이터 시각화를 위해 Amazon CloudFront로 PCD를 사용자에게 전달하며, 이때 Lambda@Edge를 활용해 테넌트 간 데이터 접근을 완벽하게 격리합니다. Lambda@Edge는 오리진(S3)으로 요청이 도달하기 전에 사용자의 접근 권한을 동적으로 검증하여, 오직 인가된 사용자만이 자신의 데이터에 접근하도록 보장합니다.

운영 자동화 및 확장성

뷰엑스 아키텍처는 멀티테넌트 SaaS 환경에서 운영 편의성과 확장성을 확보하기 위해 설계되었습니다. 각 고객사별 리소스에 대해 논리적 분리를 기반으로, 시스템은 특정 테넌트의 리소스 사용 현황을 실시간으로 수집하고 모니터링합니다. 이를 통해 리소스를 자동으로 확장 및 축소하고, 문제가 발생한 테넌트에만 선별적으로 핫픽스 배포가 가능하도록 제어 체계를 구축했습니다.

주요 구현 사항으로는, SBT를 활용한 테넌트 온보딩 자동화를 통해 신규 고객이 계약 직후 30분 이내에 서비스를 이용할 수 있도록 했으며, 중앙 집중식 프로세스를 통해 인프라 프로비저닝과 보안 정책 적용, 권한 설정까지 일관되고 신속하게 처리됩니다. 또한, EKS 클러스터에서 Karpenter 기반 자동 확장을 도입해 GPU 노드를 필요에 따라 동적으로 배치함으로써 비용과 성능을 최적화했습니다. 이러한 구조는 멀티 테넌트 환경의 수요 변동에도 유연하게 대응하며, SaaS 운영 효율성을 크게 향상시킵니다.

뿐만 아니라, 공유 리소스 기반의 Pool 모델과 독립 환경의 Silo 모델을 함께 지원하여 고객별 요구와 보안 수준에 맞는 다양한 운영 옵션을 구현했습니다.

SaaS 전환이 쏘아 올린 만족스러운 성과

뷰런은 뷰엑스를 SaaS 형태로 제공하여, 고객이 회원가입만 하면 계정 생성 → 데이터 업로드 → 결과 확인을 즉시 스스로 진행할 수 있습니다. 복잡한 설정이나 대기 시간이 사라져 전체 과정이 단순하고 직관적으로 연결됩니다. 이에 따라 고객은 제품을 처음 접하는 순간부터 가치를 빠르게 체감(Time-to-Value) 하고 만족도가 크게 높아지고 있습니다.

온보딩 속도의 혁신

이전에는 새로운 고객이 파일럿을 시작하기까지 계정 설정, 프로젝트 생성, 버킷 생성 및 권한 할당을 엔지니어가 수동으로 처리해야 했으며, 평균적으로 약 4~6시간이 소요되었습니다. 이제는 고객이 뷰엑스에 가입하면 엔지니어가 수동으로 처리했던 작업과 프로비저닝이 모두 자동화되어, 고객은 구독 직후 30분 이내에 데이터 업로드와 Viewer 확인까지 스스로 완료할 수 있습니다. 이를 통해 고객이 서비스를 처음 경험하는 과정이 크게 개선되어, 서비스에 대한 첫 인상과 고객 사용 여정이 획기적으로 향상되었습니다.

운영 일관성과 안정성 확보

AWS SBT의 Control Plane을 적용하면서 테넌트 관리, 사용자 권한, 과금, 메트릭 수집이 표준화된 API와 워크플로로 통일되었습니다. 이로 인해 테넌트가 늘어나도 운영 복잡도를 효과적으로 억제할 수 있으며, 버전 릴리스와 보안 정책을 모든 고객에게 동시에 적용할 수 있게 되었습니다. 또한, 일관된 환경에서 장애 대응과 버그 재현이 가능해져 운영 효율성이 크게 향상되었습니다.

성능과 비용의 균형

뷰엑스의 핵심 워크로드인 오토라벨링과 추론 작업은 GPU 자원이 필요합니다. SBT 기반 멀티테넌트 모델에 EKS 오토스케일링을 적용해 GPU 노드가 워크로드에 따라 자동으로 확장되면서, 배치 처리량은 약 3.5배 향상되고 처리 지연은 30% 이상 감소했습니다. 또한 S3 Intelligent-Tiering과 GPU 스팟 인스턴스 활용을 통해 월 인프라 비용을 약 25% 절감할 수 있었습니다.

보안과 거버넌스 내재화

이전에는 고객별 요구사항에 따라 보안 정책을 따로 관리했지만, 이제는 IRSA(IAM Roles for Service Accounts) 최소 권한, AWS Key Management Service(KMS) 기반 암호화, 사전서명 URL을 통한 안전 업로드가 기본값으로 적용됩니다. 리전별 데이터 거버넌스 요구도 Control Plane에서 정책 기반으로 관리되어, 엔터프라이즈 고객이 요구하는 규제 준수, 감사 추적을 손쉽게 충족할 수 있습니다.

고객층 확장 가능성

SBT를 통해 뷰엑스는 다양한 고객층을 위한 유연한 Pool/Silo 모델을 운영할 수 있게 되었습니다. 스타트업 고객은 저비용의 공유형(Pool)에서 빠르게 시작할 수 있고, 엔터프라이즈 고객은 전용형(Silo)으로 보안과 성능을 보장받을 수 있습니다. 이러한 아키텍처는 OEM부터 스타트업까지 다양한 고객 요구를 충족하면서, 뷰런의 SaaS를 글로벌 시장으로 확장할 수 있는 기반이 되었습니다.

마치며

멀티테넌트, SaaS 서비스 아키텍처를 설계하는 과정은 수많은 고민과 어려운 결정의 연속이었습니다. 특히 어떤 요소를 필수로 포함해야 하고, 어떤 방향으로 아키텍처를 설계해야 하는지 판단하는 일은 쉽지 않았습니다. 이 과정에서 SaaS Builder Toolkit for AWS(SBT)는 Well-Architected 프레임워크에 기반한 효과적인 도구로서 큰 도움을 주었습니다.

SBT가 가장 유용했던 점은 프로비저닝 파이프라인 자동화였습니다. 아키텍처 설계 단계에서 반드시 고민해야 할 많은 요소들이 이미 준비되어 있었기 때문에, 저희는 AWS CDK를 통해 배포만 하면 곧바로 활용할 수 있는 수준으로 시작할 수 있었습니다. 덕분에 단기간에 기초적인 구조를 설계하고 구현할 수 있었습니다.

SBT가 많은 부분에서 유용했지만, 세부적인 기능이나 내부 동작을 완전히 이해하기 위해서는 코드를 직접 분석하고 학습하는 과정이 필요했습니다. 예를 들어, EventBridge를 통한 프로비저닝 데이터 처리 부분은 코드와 스크립트를 살펴보며 세심하게 파악해야 했습니다. 또한, 실제 서비스 환경의 비즈니스 요구사항을 반영하기 위해 SBT의 내부 구조와 흐름을 충분히 이해하고 필요한 부분을 커스터마이징하는 작업이 필수적이었습니다.

결국 멀티테넌트 SaaS 아키텍처 구축에서 프로비저닝과 인증 로직은 가장 필수적인 출발점이며, 어떠한 아키텍처를 구상하더라도 반드시 첫 번째로 다루어야 할 과제라는 점을 다시금 확인할 수 있었습니다. 뷰런은 SBT를 통해 이와 관련된 핵심 정보를 얻고 빠르게 기초 아키텍처를 구현할 수 있었으며, 이는 SaaS 서비스 구축에 있어 매우 중요한 경험이 되었습니다.

SaaS 전환은 단순히 기술을 바꾸는 일이 아니라, 아키텍처에 대한 사고방식을 재정립하는 과정이었습니다. 그리고 그 경험은 앞으로의 뷰엑스 고도화와 글로벌 확장에 있어 가장 중요한 자산이 되었습니다.