건설 솔루션 기업 두올테크의 Amazon ECS 기반 SaaS 플랫폼 전환 여정

들어가며

많은 기업들이 기존 솔루션을 SaaS로 전환하고자 하지만, 여러 기술적 허들로 인해 전환을 미루고 있습니다. 특히 고객사별 데이터를 안전하게 격리하면서도 공유 인프라에서 효율적으로 서비스해야 하는 멀티테넌트 구조의 설계가 복잡하게 느껴지고, 레거시 시스템의 기술적 부채와 특정 OS나 프레임워크에 종속된 기존 애플리케이션을 현대화된 환경으로 전환하려면 여러 재개발이 필요합니다.

건설 산업 B2B 솔루션 기업 두올테크(Doalltech)는 이러한 문제점들을 Pool 방식의 논리적 테넌트 분리와 단계적 접근을 통해 해결하며 기존 시스템을 빠르게 SaaS 플랫폼으로 전환하는 데 성공했습니다.

이 글은 두올테크가 AWS, 메가존클라우드와 함께 이룬 SaaS 전환 여정을 공유하며, 같은 고민을 하고 있는 기업들에게 실질적인 인사이트를 제공합니다.

두올테크 소개

두올테크는 건설 산업의 디지털 전환을 선도하는 B2B 건설 솔루션 기업입니다. BIM(Building Information Modeling) 기반의 3D 디지털 모델링, 견적 시각화, 프로젝트 관리, 출입 통제, 자재 물류 관리 등 건설 현장의 핵심 업무를 통합 지원하는 Viewcost 등의 플랫폼을 제공합니다.

국내외 주요 건설사들의 현장에서 실제로 활용되며, 복잡하고 수작업에 의존하던 건설 업무 프로세스를 데이터 중심의 자동화된 워크플로우로 전환함으로써, 고객이 더 빠르고 효율적으로 프로젝트를 운영할 수 있도록 돕고 있습니다.

두올테크의 주요 솔루션

두올테크의 솔루션은 건설 현장의 전 과정을 아우르는 통합 플랫폼입니다. BIM 기반 3D 시각화 시스템을 통해 설계 단계에서부터 시공, 유지보수에 이르기까지 모든 정보를 실시간으로 공유하고 관리할 수 있습니다. 견적 시각화 시스템은 복잡한 건설 비용을 직관적으로 파악하고 최적화할 수 있도록 지원하며, 프로젝트 관리 플랫폼은 일정, 자원, 인력을 효율적으로 배치하고 추적할 수 있게 합니다. 또한 얼굴인식 기반 출입 통제 시스템 (Gateware) 과 자재 물류 관리 시스템 (BIMLOGI) 은 건설 현장의 보안과 자원 관리를 자동화하여, 현장 관리자들이 더 중요한 의사결정에 집중할 수 있도록 돕습니다.

이 모든 기능은 Web 기반 클라우드 SaaS 모델로 제공되어, 고객들은 별도의 복잡한 설치나 유지보수 없이 언제 어디서나 웹 브라우저를 통해 서비스를 이용할 수 있습니다.

기존 상황: Windows 기반 EC2 아키텍처의 한계

두올테크의 기존 아키텍처는 .NET Framework 기반 ASP.NET 애플리케이션이 Windows Server EC2 인스턴스에서 실행되는 구조였습니다. 이 구조는 초기에는 충분했지만, 비즈니스가 성장하면서 여러 한계에 직면했습니다.

비즈니스 측면의 도전 과제

두올테크의 빠른 성장과 함께 인프라에도 새로운 요구 사항들이 나타나기 시작했습니다.

고객 피드백을 반영한 기능 개선이 늘어나면서, 더 빠른 배포와 반복적인 업데이트 환경이 필요했습니다. 하지만 기존의 수동 배포 방식은 느리고, 배포 실패 시 즉각적인 복구가 어려워 서비스 안정성을 저해하는 요인이 되었습니다. 대규모 프로젝트나 특정 시점의 사용자 트래픽 급증에 대비할 수 있는 안정적이고 유연한 아키텍처도 요구되었습니다. 2D/3D 도면 시각화와 같은 리소스 집약적 작업을 안정적으로 처리해야 했기 때문입니다.

무엇보다 단순한 인프라 운영을 넘어, B2B SaaS 모델을 통한 비즈니스 확장성과 수익성 강화가 중요한 과제로 떠올랐습니다. 고객사별 데이터를 완전히 분리하여 보안과 프라이버시를 보장하면서도, 공유 인프라에서 여러 고객을 효율적으로 서비스해야 했습니다.

기술적 측면의 도전 과제

기술적으로도 여러 어려움이 있었습니다. 기존 IIS/ASP 기반 레거시 환경에서 Vue.js, Python/Flask 등 최신 스택으로 전환하는 과정에서 기술 스택의 근본적인 변화에 직면했습니다. Vue.js, Python 라이브러리 등 최신 기술의 버전 업그레이드 및 의존성 관리도 복잡했습니다. 또한 SaaS 환경의 테넌트 격리와 관련된 인증/인가 기능 구현을 위해 Cognito, JWT 등 새로운 인증 기술 학습이 필요했습니다.

두올테크는 이러한 한계를 극복하고 진정한 의미의 멀티테넌트 SaaS 플랫폼으로 전환하기로 결정했습니다.

SaaS 전환을 위한 기술적 요구사항

진정한 SaaS 플랫폼이 되기 위해서는 다음의 핵심 요소들이 필수적이었습니다.

첫째, 멀티테넌트 아키텍처입니다. 고객사별 데이터를 완전히 분리하여 보안과 프라이버시를 보장하면서도, 공유 인프라에서 여러 고객을 효율적으로 서비스하며 각 고객에게 독립적인 경험을 제공해야 했습니다.

둘째, 탄력적 확장성입니다. 대규모 프로젝트의 동시 접속자 증가나 특정 시점의 트래픽 급증에 자동으로 대응하고, 고객 수 증가에 따라 예측 가능하고 비용 효율적으로 인프라를 확장할 수 있어야 했습니다.

셋째, 빠른 배포 주기와 민첩성입니다. 코드 커밋부터 프로덕션 배포까지 완전 자동화된 CI/CD 파이프라인이 필요했습니다. Blue/Green 배포를 통해 고객 서비스 영향을 최소화하는 무중단 배포와, 문제 발생 시 즉시 이전 버전으로 복구 가능한 안전장치도 구현해야 했습니다.

넷째, 컨테이너 기반 현대적 아키텍처입니다. 기능별로 독립적인 컨테이너로 구성하여 개발과 배포의 독립성을 확보하고, 개발 환경과 프로덕션 환경 간 일관성을 보장하며, 컨테이너 밀도 향상을 통한 인프라 효율화를 달성해야 했습니다.

이러한 요구사항을 충족하기 위해 두올테크는 체계적인 전환 로드맵을 수립했습니다.

SaaS 전환 8단계 로드맵

1단계: Business 기획에서는 B2B 타겟 고객을 명확히 정의하고, 고객사별 마케팅에 맞는 화면 UI 작업을 진행했습니다. 성공적인 SaaS 비즈니스를 위해 비즈니스 의도를 명확히 하고, 시장 적합성을 확보할 수 있는 차별화된 제품 로드맵과 마케팅 전략을 수립했습니다.

2단계: Application 현대화에서는 모놀리식 애플리케이션을 컨테이너화했습니다. 테넌트 간 리소스 격리와 환경 일관성을 보장하기 위해 컨테이너 기술 도입이 필수적이었고, 리스크를 줄이기 위해 단계적으로 컨테이너화를 진행하며 Amazon ECS 기반으로 표준화하여 성능을 최적화했습니다.

3단계: 테넌트 모델 설계에서는 Pool 방식을 채택했습니다. 비용과 보안 요건을 고려하여 최적의 테넌트 격리 모델을 설계하고, Terraform으로IaC (Infrastructure as code)를 구축하여 향후 테넌트 자동화를 준비했습니다.

4단계: 인증 전략 설계에서는 API Gateway + Cognito+JWT조합을 도입했습니다. API Gateway를 보안의 시작점으로 삼고 Cognito를 활용해 멀티테넌트 인증 기능을 구현했으며, 테넌트 ID가 포함된 JWT를 사용하여 마이크로서비스 간 안전하고 효율적인 권한 검증 체계를 마련했습니다.

5단계: 테넌트별 Routing에서는 projectId 기반 로직을 구성했습니다. 도메인이나 헤더 정보를 통해 유입되는 트래픽의 테넌트를 식별하고 테넌트별 권한을 적용한 후 DB 및 데이터 리소스로 라우팅합니다. 신규 고객 온보딩 시 식별자 생성과 라우팅 규칙 설정이 자동화되도록 통합 워크플로우를 구축했습니다.

6단계: Amazon ECS 기반 배포에서는 표준 배포 아키텍처를 정립했습니다. 멀티테넌트 환경의 안정적 확장을 위해 Amazon ECS 기반의 표준 배포 아키텍처를 정립하고, 개발 환경에 Spot 인스턴스를 적용하여 비용을 절감했으며, ENI 부족 문제 등에 대한 대응책을 마련했습니다.

7단계: CI/CD 최적화에서는 Blue/Green 배포와 Terraform을 활용했습니다. Terraform을 활용해 복잡한 멀티테넌트 인프라를 코드로 정의하여 관리 효율성을 높이고, Blue/Green 전략으로 무중단 배포 환경을 구현했으며, 빌드 캐싱을 통해 CI/CD 파이프라인 속도를 최적화했습니다.

8단계: 모니터링 구축에서는 Amazon CloudWatch와 AWS X-Ray를 도입했습니다. 전체 시스템뿐만 아니라 테넌트별로 분리된 리소스 사용량과 서비스 상태를 모니터링해야 했고, Amazon CloudWatch와 AWS X-Ray를 활용하여 애플리케이션 상태를 감시하고 분산 아키텍처의 성능 병목을 신속하게 파악할 수 있게 되었습니다.

이제 이 로드맵의 핵심 단계들을 상세히 살펴보겠습니다. 먼저 SaaS 아키텍처의 근간이 되는 테넌트 격리 전략부터 시작합니다.

테넌트 격리 전략: Pool 모델 선택

테넌트 격리란?

AWS Well-Architected Tool의 SaaS Lens에서는 테넌트 격리(Tenant Isolation)를 SaaS 아키텍처의 가장 중요한 설계 원칙 중 하나로 정의합니다. 테넌트 격리란 한 테넌트가 다른 테넌트의 리소스에 접근하는 것을 방지하는 메커니즘입니다. 이는 단순한 보안 요구사항을 넘어, SaaS 비즈니스의 신뢰성과 규정 준수의 기반이 됩니다.

테넌트 격리가 중요한 이유는 크게 네 가지입니다. 첫째, 테넌트 간 데이터 유출 방지는 SaaS의 기본적인 보안 요건입니다. 둘째, 산업별 규제를 충족하기 위한 필수 조건입니다. 셋째, 한 테넌트의 과도한 리소스 사용이 다른 테넌트의 서비스 품질에 영향을 주는 “Noisy Neighbor” 문제를 방지할 수 있습니다. 넷째, 테넌트별 모니터링, 과금, 문제 해결을 위한 운영 효율성 및 고도화의 기반이 됩니다.

세 가지 격리 모델

AWS Well-Architected SaaS Lens는 테넌트 격리를 위한 세 가지 모델을 제시합니다.

Silo 모델은 각 테넌트에게 완전히 독립된 인프라를 제공하는 방식입니다. 테넌트별로 별도의 데이터베이스, 컴퓨팅 리소스, 네트워크를 할당하므로 최고 수준의 격리를 보장합니다. 금융이나 의료처럼 규제가 엄격한 산업이나, 완전한 데이터 격리를 요구하는 엔터프라이즈 고객에게 적합합니다. 다만 테넌트 수가 늘어날수록 관리 복잡도와 비용이 선형적으로 증가하는 단점이 있습니다.

Pool 모델은 모든 테넌트가 동일한 인프라를 공유하면서, 애플리케이션 레벨에서 논리적으로 데이터를 분리하는 방식입니다. 하나의 데이터베이스에서 테넌트 ID를 기준으로 데이터를 구분합니다. 비용 효율성이 높고 빠른 확장이 가능하지만, 애플리케이션 코드에서 테넌트 격리 로직을 철저히 구현해야 합니다.

Hybrid 모델은 기본적으로 Pool 방식을 사용하되, 특정 조건을 충족하는 테넌트(높은 사용량의 고객, 높은 보안 요구 등)에게는 Silo 환경을 제공하는 방식입니다. 다양한 규모와 요구사항을 가진 고객을 동시에 서비스해야 하거나, Pool로 시작해서 점진적으로 성숙한 SaaS로 발전하려는 경우에 적합합니다.

그림 1: Silo 모델 – 테넌트별 전용 인프라 구성

그림 2: Pool 모델 – 공유 인프라 + 논리적 격리

그림 3: Hybrid 모델 – Pool 기반 + 선택적 Silo 승격

두올테크의 선택: Pool 모델

앞서 언급한 요구사항들을 고려하여 두올테크는 Pool 모델을 선택했습니다.

첫째, 빠른 시장 진입이 가능합니다. 완전한 Silo 구조를 구축하려면 상당한 시간과 비용이 필요하지만, Pool 방식은 기존 애플리케이션에 테넌트 식별 로직을 추가하는 방식으로 SaaS 전환 시간을 단축할 수 있습니다.

둘째, 비용 효율성이 높습니다. 공유 인프라를 사용하므로 테넌트가 늘어나도 인프라 비용이 선형적으로 증가하지 않습니다. 특히 초기 단계에서 고객 수가 적을 때 고정 비용 부담을 줄일 수 있습니다.

셋째, 점진적 고도화가 가능합니다. Pool 방식으로 시작하더라도, 향후 특정 대형 고객이나 규제 요건이 있는 고객을 위해 Silo로 승격할 수 있는 구조를 미리 설계해두었습니다.

Pool 모델 구현: projectId 기반 논리적 멀티테넌시

핵심 설계

현재 아키텍처는 Amazon ECS 기반 공용 애플리케이션 환경에서 실행되지만, 실질적으로는 projectId를 Tenant Key로 활용하는 논리적 멀티테넌시(Logical Multi-Tenancy) 모델로 설계되어 있습니다. 하나의 애플리케이션 풀(Pooled Application Layer) 위에서 다수의 테넌트가 공유 리소스를 사용하는 구조이면서도, 모든 요청은 projectId 기반 테넌트 컨텍스트가 강제됩니다.

인증 및 데이터 접근은 다음과 같은 흐름으로 이루어집니다. 먼저 API Gateway → Cognito → JWT 파이프라인에서 인증이 완료됩니다. 그 다음 JWT Claims와 HTTP 파라미터에 포함된 projectId를 기준으로 DB의 사용자-테넌트 매핑 테이블을 조회합니다. 마지막으로 ORM이 쿼리 실행 시 해당 테넌트 소유 데이터만 필터링합니다.

이러한 설계는 단순한 서비스 계층 RBAC(Role-Based Access Control)가 아니라, 코드 레벨에서 테넌트 컨텍스트가 일관되게 흐르는 Pooled Multi-Tenant 아키텍처입니다. DB, Cache, Amazon S3 Prefix 등 데이터 계층에서도 동일 컨텍스트로 확장 가능하다는 점에서 SaaS-ready 구조입니다.

미래 확장을 고려한 설계

Pool 방식을 선택했다고 해서 나중에 Silo가 필요할 때 처음부터 다시 만들어야 하는 것은 아닙니다. 두올테크는 처음부터 테넌트 컨텍스트를 코드 전반에 일관되게 적용했기 때문에, 나중에 격리 수준을 높이는 것이 “재설계”가 아니라 “선택적 확장”이 됩니다.

SaaS 성숙도 모델로 보면, Shared-Everything에서 시작하여 특정 테넌트만 분리가 필요할 때 Shared-Something(DB 스키마 분리)으로, 완전한 격리가 필요할 때 Shared-Nothing(별도 Amazon RDS 인스턴스)으로 단계적 발전이 가능합니다.

현재 두올테크는 projectId 기반 Row-Level Isolation을 수행하고 있습니다. 하지만 모든 요청이 이미 projectId와 UserContext 단위로 식별되고 있기 때문에, 대형 고객이 전용 DB를 요구하면 해당 테넌트의 데이터만 별도 스키마로 마이그레이션할 수 있습니다. 규제 요건으로 완전 분리가 필요하면 별도 Amazon RDS 인스턴스로 승격할 수 있고, 프리미엄 티어를 추후 구현할 때는 API Gateway Usage Plan을 테넌트별로 분리할 수 있습니다. 이 모든 것이 기존 코드를 크게 수정하지 않고도 가능합니다.

과금과 모니터링 기반 확보

SaaS 비즈니스에서 빠뜨리기 쉬운 것이 바로 테넌트별 사용량 측정(Metering)입니다. 두올테크의 구조에서는 모든 요청이 projectId 단위로 식별되므로, 테넌트별 API 호출 횟수 집계, 테넌트별 저장소 사용량 추적, 테넌트별 처리량 모니터링이 가능합니다. 이런 데이터를 기반으로 사용량 기반 과금(Usage-Based Pricing)이나 티어별 차등 요금제를 구현할 수 있는 기반이 이미 마련되어 있습니다.

기술적 도전 과제와 구현 상세

앞서 살펴본 8단계 로드맵을 실행하는 과정에서 두올테크는 네 가지 핵심 기술 과제에 직면했습니다.

도전 1: Windows 컨테이너에서 Linux 컨테이너로 전환

두올테크의 기존 아키텍처는 .NET Framework 기반 ASP.NET 애플리케이션이 Windows Server EC2 인스턴스에서 실행되는 구조였습니다. SaaS 전환을 위해 극복해야 할 기술적 간극은 크게 네 가지였습니다.

첫째, .NET Framework에서 .NET Core로 전환하고 Windows 전용 API 의존성을 제거하며 IIS에서 Kestrel 웹 서버로 전환해야 했습니다. 둘째, 모놀리식 애플리케이션을 기능별 컨테이너로 분리하고 Dockerfile 작성 및 멀티 스테이지 빌드를 최적화해야 했습니다. 셋째, Amazon EC2 기반에서 Amazon ECS 컨테이너 오케스트레이션으로, 수동 배포에서 GitHub Actions + AWS CodePipeline/ AWS CodeDeploy 자동화로, 정적 인프라에서 Terraform 기반 IaC (Infrastructure as code) 로 전환해야 했습니다. 넷째, 단일 고객 환경에서 멀티테넌트 격리 모델로, 기본 인증에서 AWS Cognito 기반 OIDC 인증으로 전환해야 했습니다.

이러한 간극을 메우기 위해 두올테크는 메가존클라우드와 협력하여 단계적 PoC를 진행하기로 결정했습니다.

Windows 컨테이너의 한계

Windows 컨테이너에는 여러 한계가 있었습니다. 이미지 사이즈가 GB 단위로 커서 빌드/배포 시간이 길고 레지스트리 비용이 증가했습니다. Container/Task 시작 시 수십 초에서 수 분이 소요되는 Cold Start 문제가 있었고, Linux 대비 3~10배 느린 Scale Out으로 Autoscaling이 비효율적이었습니다. 또한 Windows OS 패치 주기마다 재부팅이 필요한 보안 업데이트 문제도 있었습니다.

Linux 컨테이너 전환 효과

Linux 컨테이너로 전환하면서 여러 이점을 얻었습니다. m7i-flex Spec으로 ENI를 다수 사용하여 EC2 컨테이너 집약 비용을 효율화했고, Windows OS 라이선스 비용이 제거되었습니다. 이미지 사이즈가 축소되고 Autoscaling 속도가 향상되었으며, Amazon ECR 관리도 효율적으로 변했습니다.

단계적 전환 전략

전환은 단계적으로 진행했습니다. 1단계(단기)에서는 Windows Container로 빠르게 PoC/데모를 제공했습니다. 2단계(중기)에서는 코드를 분석하여 Windows 종속 제거 항목을 리스트업했습니다. 3단계(장기)에서는 Linux Container 재설계와 재개발 계획을 수립했습니다.

Windows 컨테이너에서 Linux 컨테이너로의 전환은 SaaS 환경의 운영 효율성과 비용 효율성을 극대화하기 위한 핵심 전략이었습니다. 단기적으로 Windows 컨테이너 실행 PoC, 중기적으로 언어 변환에 따른 코드 분석, 장기적으로 Linux 재설계/재개발 계획을 수립하여 안정적인 전환을 진행했습니다.

최종 기술 스택은 다음과 같습니다. AWS 서비스로는 API Gateway, Cognito, ECS, AWS Lambda, Amazon EC2, NLB, ALB, Amazon RDS, Amazon ECR을 사용하고, 오픈소스로는 Docker, Docker Compose, AWS CodePipeline, AWS CodeDeploy를 활용합니다. Git은 GitHub과 GitHub Actions를 사용하며, 언어는 프론트엔드에 Vue.js, 백엔드에 Python/Flask를 사용합니다.

그림 4: Amazon ECS 기반 SaaS 아키텍처 전체 구성도

도전 2: 멀티테넌트 데이터 격리

앞서 설명한 Pool 모델을 실제로 구현하기 위해, 단일 DB 내에서 데이터 격리를 구현하는 관계형 데이터베이스의 외래키(Foreign Key) 매핑을 활용한 논리적 격리 아키텍처를 설계했습니다.

그림 5: Pool 모델 기반 멀티테넌트 데이터 격리 프로세스

핵심 구현 전략: DB Lookup 기반의 동적 컨텍스트 주입

단순히 토큰 정보에 의존하는 것이 아니라, 매 요청마다 DB에 정의된 사용자-테넌트 매핑 관계를 실시간으로 참조하여 데이터 접근 범위를 결정합니다. Pool Model(Shared Database)을 통해 모든 테넌트 데이터를 단일 스키마에서 관리하여 운영 효율성을 확보하고, Relationship-Based Isolation을 통해 DB 내의 외래키 관계로 사용자의 접근 권한(Tenant Scope)을 명확히 규정합니다.

상세 프로세스는 다음과 같습니다. 먼저 Identity Verification(Authentication) 단계에서 API 요청 시 토큰을 통해 사용자 신원(User Identity)을 우선 식별합니다. 다음으로 Context Lookup(Via DB Mapping) 단계에서 식별된 사용자 ID를 기준으로 DB의 사용자-테넌트 매핑 테이블을 조회하고, 외래키(Foreign Key)로 연결된 테넌트 정보를 확인하여 현재 요청이 접근 가능한 Tenant Context를 동적으로 결정합니다. 마지막으로 Scoped Access Enforcement(ORM) 단계에서 Lookup을 통해 확정된 TenantID를 애플리케이션 컨텍스트에 주입하고, ORM이 쿼리 실행 시 이 ID를 참조하여 해당 테넌트 소유의 데이터만 조회되도록 필터링 조건을 자동 적용합니다.

도전 3: CI/CD 파이프라인 구축

그림 6: CI/CD 파이프라인 구축 아키텍처

SaaS 비즈니스의 경쟁력은 속도입니다. 고객의 피드백을 얼마나 빨리 서비스에 반영할 수 있는가가 시장에서의 성패를 좌우합니다. 하지만 속도만 추구하다가 장애가 발생하면 더 큰 문제가 됩니다.

두올테크가 직면한 딜레마는 세 가지였습니다. 개발팀은 GitHub에서 바로 배포하고 싶어했고, 보안팀은 외부 서비스가 프로덕션에 직접 접근하는 것을 우려했으며, 운영팀은 배포 실패 시 롤백이 어려운 점을 걱정했습니다.

두올테크는 개발 편의성(GitHub)과 운영 보안성(AWS)의 장점을 결합한 하이브리드 파이프라인을 구축하여 이 문제를 해결했습니다.

핵심 구현 전략: Amazon S3 Hand-off 기반의 보안 경계 분리

외부(GitHub)와 내부(AWS 프로덕션)의 접점을 최소화하기 위해 Amazon S3를 아티팩트 전달의 교두보(Hand-off Point)로 활용했습니다.

[GitHub Actions] → [S3 Artifact] → [AWS CodePipeline] → [CodeDeploy]
     (빌드)            (교두보)            (트리거)        (Blue/Green 배포)

CI 단계에서는 개발자에게 친숙한 GitHub 환경에서 빌드와 테스트를 수행합니다. 단, 이곳에는 프로덕션 배포 권한을 부여하지 않고, 빌드 결과물(Artifact)을 Amazon S3에 업로드하는 권한만 부여하여 보안 경계(Security Boundary)를 명확히 했습니다.

Bridge 단계에서는 Amazon S3에 새로운 아티팩트가 업로드되면, 이를 트리거로 내부망에 있는 AWS CodePipeline이 자동으로 작동합니다.

CD 단계에서는 실제 배포를 AWS 서비스인 CodeDeploy가 전담합니다. 앞서 요구사항에서 언급한 Blue/Green 배포 전략을 적용하여 트래픽을 안전하게 제어하며, 배포 중 오류 감지 시 즉시 이전 버전으로 트래픽을 원복(Rollback)하는 무중단 배포 환경을 구현했습니다.

이러한 파이프라인 구축을 통해 소스 코드 변경부터 서비스 반영까지의 시간을 기존 수십 분에서 5분 이내로 단축했으며, 배포 실패에 대한 리스크를 시스템적으로 제거했습니다.

도전 4: 이중 오토스케일링

SaaS 환경에서 트래픽은 예측하기 어렵습니다. 건설 현장에서 아침 출근 시간에 접속이 몰리기도 하고, 대형 프로젝트 마감 전에 갑자기 사용량이 급증하기도 합니다.

기존의 단순한 오토스케일링 방식에는 문제가 있었습니다. CPU 사용량이 올라가면 무조건 새 서버를 띄우는 방식이었는데, 이러면 기존 서버에 여유 공간이 있어도 새 서버가 생성되는 자원 파편화(Fragmentation) 문제가 발생합니다. 결과적으로 비용은 늘어나고, 관리할 서버도 많아집니다.

두올테크는 이 문제를 해결하기 위해 이중 스케일링(Dual-Layer Scaling) 아키텍처를 구현했습니다.

핵심 구현 전략: Capacity Provider와 Bin Packing

그림 7. ECS Capacity Provider + Binpack 기반 이중 오토스케일링

단순히 CPU 사용량에 따라 늘리는 것이 아니라, 실제 필요한 ‘예약 가능한 자원’을 기준으로 정교하게 인프라를 제어합니다. Dual-Layer Scaling을 통해 컨테이너 레벨(Service Scaling)과 인프라 레벨(Cluster Scaling)을 이중으로 제어하고, High Density 전략으로 빈 공간을 찾아 채워 넣는 방식을 통해 인스턴스 집적도를 향상시킵니다.

Precision Scaling(ECS Capacity Provider)에서는 단순 CPU 점유율이 아닌 Capacity Provider Reservation 지표를 활용하여 스케일링을 트리거합니다. 실제 실행 대기 중인 Task의 요구량을 분석하여, 필요한 만큼만 정확하게 EC2 인스턴스를 확장(Scale-out)하거나 축소(Scale-in)합니다.

Deployment Strategy(Binpack)에서는 컨테이너 배치 전략으로 Binpack(빈팩) 모드를 적용합니다. 새로운 인스턴스를 무조건 띄우는 대신, 기존 인스턴스의 CPU/Memory 잔여 공간을 실시간 계산하여 컨테이너를 최대한 밀도 있게 배치합니다. 이를 통해 인스턴스 내 유휴 공간(Slack Space)을 제거하고 자원 파편화를 방지합니다.

이러한 전략을 통해 트래픽 급증 시 3~4분 내의 인프라 대응이 가능해졌으며, 평시에는 최소한의 인스턴스로 서비스를 유지하는 아키텍처를 달성했습니다.

두올테크의 SaaS 아키텍처 설계 원칙

지금까지 살펴본 기술적 도전 과제들을 해결하면서, 두올테크는 다섯 가지 핵심 설계 원칙을 수립했습니다.

1. 비용 최적화를 위한 환경별 차등 구성

Stage 환경은 트래픽이 거의 없고 Testing 목적이므로 단일 AZ로 구성해 네트워크 비용(NAT GW, Subnet, ENI 등)을 최소화했습니다. 반면 Production은 고가용성을 위해 2개의 AZ로 구성하되, Terraform을 활용하여 필요 시 손쉽게 AZ 개수를 확장/축소할 수 있게 설계했습니다.

인프라 비용 절감을 위해 m7i-flex와 ENI Trunking을 활용하여 하나의 EC2 인스턴스에 다중 IP를 할당하고 최대 10개의 컨테이너를 효율적으로 운영합니다. 스테이징 환경은 주말 및 야간에 EC2 및 컨테이너 수를 축소하고 평일 오전 출근 시간에 자동으로 복구되도록 하여 불필요한 시간대 비용을 최소화했습니다.

2. Amazon ECS 선택: 운영 복잡성 최소화

Amazon ECS, ALB/NLB, Cognito, API Gateway, Amazon RDS 등 다수의 AWS 매니지드 서비스를 사용하지만, 모든 리소스는 Terraform으로 자동화 가능하도록 모듈화했습니다.

Amazon EKS 대신 Amazon ECS를 선택한 이유는 명확합니다. EKS 대비 운영 부담이 훨씬 적고, SaaS Control Plane 관리가 불필요하며, 운영자가 Kubernetes의 복잡성을 다루지 않아도 됩니다. 그러면서도 컨테이너와 Blue/Green 배포 등 핵심 기능은 동일하게 제공됩니다. Kubernetes에 비해 단순한 운영 환경을 제공하는 Amazon ECS를 선택함으로써 DevOps 리소스 부담을 낮추고 운영 인력의 효율성을 확보했습니다.

이로써 “운영 비용과 복잡성을 낮추면서, 배포 안정성은 그대로 유지”라는 목표를 달성했습니다.

3. 3-Tier Architecture + Internal NLB

서비스를 프론트엔드/백엔드/데이터 계층으로 분리하고, Backend는 Private Subnet 내부에서만 동작하도록 구성했습니다. 내부 통신은 Internal NLB를 사용하여 서비스 간 연결이 안전하고 확장 가능하며, 프론트엔드는 ALB 또는 CloudFront를 통해 외부에 노출됩니다. 이를 통해 보안 수준이 크게 상승하고 계층 간 장애 영향이 최소화됩니다.

4. API Gateway + Cognito + JWT 인증 체계

기존 백엔드에서 인증 로직을 직접 구현하는 방식은 보안 취약점과 운영 부담이 컸습니다. 이를 해결하기 위해 API Gateway를 로그인 및 회원관리 페이지를 제외한 모든 API 요청 통로로 사용하고, Cognito로 인증 처리 및 JWT 발급을 담당하게 했습니다. JWT를 통해 Backend에서 Stateless 상태를 유지할 수 있게 되어, 보안을 강화하면서도 운영을 단순화하는 효과를 얻었습니다.

5. GitHub + AWS CodePipeline으로 현대적인 CI/CD 구현

앞서 도전 3에서 설명한 것과 같이, 빌드는 GitHub Actions에서 빌드 캐시를 활용해 빠르게 수행하고, 배포는 AWS CodePipeline + CodeDeploy로 자동화했습니다. GitHub에서는 빠른 빌드(Cache)로 비용을 절감하고 빌드 속도를 최소화하며, AWS에서는 안정적인 Blue/Green 배포를 수행합니다. 롤백 자동화를 구현하여 오류 배포 시 빠른 회복이 가능하고, 배포 시 검증 확인 후 배포가 진행됩니다.

Node.js, Python 의존성과 Docker 이미지 등을 캐시(Amazon ECR, Amazon S3)에 저장하여 빌드 시간을 단축하고 비용을 절감하는 CI/CD 빌드 캐시 전략도 적용했습니다.

결과: 인프라 현대화가 가져온 비즈니스 전환

두올테크의 SaaS 전환은 단순한 아키텍처 변경이 아닌, 서비스 품질 전반을 끌어올린 전환점이 되었습니다. Amazon ECS 기반 컨테이너 아키텍처와 자동화된 배포 체계를 도입한 이번 프로젝트를 통해, 두올테크는 고객 경험과 내부 운영 모두에서 기대 이상의 효과를 확인할 수 있었습니다.

고객 만족도가 향상되었습니다. 최적화된 아키텍처 덕분에 서비스 응답 속도가 개선되었고, 고객들은 보다 빠르고 안정적인 환경에서 솔루션을 경험하게 되었습니다. 이는 단순한 기술 개선을 넘어 고객과의 신뢰를 강화하는 성과로 이어졌습니다.

서비스 배포 주기가 60% 단축되었습니다. 과거 수동으로 수십 분이 걸리던 배포 작업이 git push만으로 5분 내로 단축되었습니다. Blue/Green 배포로 안정적인 배포 서비스를 제공하면서, 시장의 요구와 고객의 피드백을 훨씬 빠르게 서비스에 반영하여 경쟁 우위를 확보했습니다.

개발팀이 혁신에 집중할 수 있게 되었습니다. 개발자들은 더 이상 인프라 관리나 반복적인 배포 작업에 시간을 쏟지 않고, 고객을 위한 새로운 기능 개발에 집중할 수 있게 되었습니다.

미래 성장 동력을 확보했습니다. 안정적이고 확장 가능한 컨테이너 기반 아키텍처는 향후 본격적인 SaaS 비즈니스 모델로 전환하고, 더 많은 고객에게 서비스를 제공할 수 있는 강력한 기술적 기반이 되었습니다.

나가며

SaaS 전환을 고민하면서도 선뜻 시작하지 못하는 기업들이 많습니다. 멀티테넌트 아키텍처가 복잡해 보이고, 기존 시스템을 다 뜯어고쳐야 할 것 같고, 실패에 대한 우려도 있기 때문입니다. 두올테크도 같은 고민을 했습니다.

하지만 비즈니스와 기술적인 AS-IS를 파악하여 점진적으로, 하지만 확실하게 구현함으로써 성공적인 SaaS 전환을 할 수 있었습니다. 두올테크는 AWS의 프리미어컨설팅 파트너사인 메가존클라우드의 SA 들과 함께 Windows 컨테이너로 PoC를 시작해서, 점진적으로 Linux 컨테이너로 전환하는 여정을 함께 고민하고 나아갔습니다.

기술적 복잡성 및 관리 부담 역시 AWS의 여러 관리형 서비스를 통해 적정 기술 스택을 선택하여 인프라에 소모되던 시간을 서비스 품질 개선과 기능 개발에 집중할 수 있게 되었습니다. 결과적으로 고객에게 더 빠르고 안정적인 SaaS 경험을 제공할 수 있었습니다. 앞으로도 두올테크는 여기서 멈추지 않고, 건설 자동화·AI·멀티테넌트 최적화로 지속적으로 발전하는 서비스를 만들고, 안정적이고 유연한 AWS 기반 인프라를 바탕으로 건설 B2B SaaS 시장에서 디지털 혁신을 주도해 나갈 계획입니다.

저자 소개