IaaS·PaaS·SaaS·FaaS, 무엇을 언제 고르는가
IaaS·PaaS·SaaS·FaaS 서비스 모델과 배포 모델의 트레이드오프, 오토스케일·비용 최적화, TCO 검증 사례를 실무 시나리오 중심으로 정리한다.
2026-08-13 · 최초 발행 2025-12-03
서버 한 대를 사는 대신 구독하는 순간부터, 조직은 IaaS로 쓸지 PaaS로 쓸지 SaaS로 쓸지부터 결정해야 한다. 이 선택이 초기 투자, 확장 속도, 운영 부담을 전부 갈라놓는다. 클라우드 컴퓨팅 서비스는 네트워크를 통해 컴퓨트, 스토리지, 네트워크, 플랫폼, 애플리케이션을 주문형(on-demand)으로 제공하는 서비스 모델이며, 과금은 사용량 기반(pay-as-you-go), 예약(Reserved), 선점형/스팟(Spot)을 혼합해 최적화한다. 공급자별 가격·정책은 상이하므로 최신 정보를 확인해야 한다.
서비스 층위와 책임 범위
IaaS는 가상머신, 블록/오브젝트 스토리지, VPC를 제공하지만 운영체제·미들웨어는 직접 관리해야 한다. PaaS는 런타임·매니지드 DB·메시징을 제공해 배포·스케일링을 간소화하는 대신 벤더 종속성이 늘어날 수 있다. SaaS는 완성형 애플리케이션을 제공하는데 커스터마이징 범위가 제한되는 대신 TCO를 가장 낮출 수 있다. FaaS는 이벤트 기반 함수를 실행하며 초미세 과금이 가능하지만 콜드스타트·상태관리를 신경 써야 한다.
배포 모델도 갈라진다. 퍼블릭은 신속한 확장과 다양한 서비스를 제공하지만 데이터 주권·규제 이슈를 고려해야 하고, 프라이빗은 통제·보안이 강화되는 대신 확장 비용·운영 복잡성이 늘어난다. 하이브리드·멀티는 워크로드를 최적 배치해 리스크를 분산하지만 네트워크·아이덴티티·가시성 통합이 난제로 남는다.
확장성·탄력성은 지표 기반(CPU/RPS/큐길이)이나 이벤트 기반 오토스케일로 확보하며, 최소/최대 용량과 워밍업·쿨다운 파라미터를 튜닝해야 한다. 장애조치는 멀티AZ/리전, 헬스체크, 자동 복구로 대응하고 데이터 복제는 RPO/RTO 목표치를 정의해 둔다.
비용·청구 체계의 드라이버는 컴퓨트 타입, 스토리지 계층, 데이터 전송(Egress), 라이선스이며 쇼백·차지백 체계로 가시화해야 한다. 최적화 기법으로는 예약·세이빙 플랜, 스팟, 오토스케일, 스토리지 수명주기(Lifecycle), 아키텍처 라이트사이징이 쓰인다. 운영 자동화·관측성은 IaC로 선언적 프로비저닝과 변경 이력·승인·롤백 체계를 갖추고(상태 파일 락킹으로 동시성 제어), CI/CD 파이프라인에 블루/그린·카나리 전략을 적용하며, 로그·메트릭·트레이스를 통합해 SLO·에러버짓 기반으로 운영한다.
| 지표 | IaaS | PaaS | SaaS | FaaS |
|---|---|---|---|---|
| 성능 | 커스텀 튜닝 유연함 | 런타임 최적화 제공 | 앱 내 성능 관리 중심 | 짧은 버스트에 강함 |
| 확장성 | 오토스케일 구성 필요 | 내장 스케일링 | 벤더 확장에 의존 | 이벤트 드리븐 자동 확장 |
| 일관성 | OS/미들웨어 표준화 필요 | 플랫폼 정책 기반 | 테넌트 레벨 일관성 | 함수 단위 아이소레이션 |
| 안정성 | 설계/운영 품질 의존 | 매니지드 안정성 높음 | SLA 기반 | Cold/Warm 영향 관리 필요 |
| 운영 편의 | 고난도 운영 필요 | 중간 | 최고 | 코드 중심 단순화 |
요청이 실제로 흘러가는 경로
실무 시나리오
대규모 웹·모바일 백엔드 현대화는 CDN→WAF→API Gateway/Ingress→컨테이너 오케스트레이션→매니지드 DB/Cache로 구조를 잡고, IaC로 랜딩존을 구축한 뒤 블루/그린 배포를 도입하고 오토스케일 정책을 튜닝하며 A/B 테스트를 운영하는 절차로 진행한다.
데이터·분석 파이프라인은 오브젝트 스토리지(Data Lake)→스트리밍/큐→ETL/ELT→웨어하우스/레이크하우스→BI로 이어지며, 스키마 레지스트리·데이터 카탈로그를 정착시키고 비용을 계층화(핫/쿨/아카이브)한 뒤 파티셔닝·Z-Order로 최적화한다.
마이크로서비스·컨테이너 전환은 서비스 메시, 중앙 인증(OIDC), 분산 트레이싱, 서킷 브레이커로 구조를 짜고 도메인 경계를 설정한 뒤 공통 플랫폼(런타임/라이브러리)을 표준화하고 슬로우 롤아웃·카나리로 전환한다.
레거시 시스템 DR/BCP는 온프레미스와 클라우드 리전 간 복제, DNS 기반 페일오버로 구성하며 RPO/RTO를 정의한 뒤 데이터 동기화(로그십/증분)를 하고 주기적 DR 드릴과 자동화 플레이북을 운영한다.
AI/ML 실험-운영화는 매니지드 피처 스토어, MLOps 파이프라인, 실시간·배치 서빙 혼합으로 구조를 잡고, 데이터 거버넌스·샌드박스를 분리한 뒤 모델 레지스트리·승인 게이트를 거쳐 섀도우 테스트에서 프로덕션으로 승격한다.
실제로 얼마나 달라지는가
온프레미스 TCO 대비 2040% 절감이 가능하다(예약 60% 적용 + 스팟 20% 혼합을 가정한 수치이며, 데이터 전송(Egress) 비용은 별도로 고려해야 한다). 기능 출시 리드타임은 5080% 단축되는데, 셀프서비스 포털·템플릿 카탈로그를 도입하면 승인 대기 시간이 크게 줄어드는 게 주된 이유다. 멀티AZ 구성으로는 99.9~99.99% 가용성을 달성할 수 있고 자동 복구로 MTTR도 단축된다. 오토스케일로 버스트 트래픽 대응률이 오르면서 피크 대비 과다 용량을 구매할 필요도 없어진다. 중앙 정책(IAM/SCP), 키 관리(KMS), 감사 로깅으로 규제 대응도 강화된다.
간단한 비용 검증을 해보면 이렇다. 온프레미스 VM 50대(8vCPU/32GB)에 연 TCO 6억 원을 쓰는 조직이 클라우드로 옮기면서 예약 60%·스팟 20%·온디맨드 20%를 혼합했다고 가정하면, 컴퓨트 비용은 35% 줄고 스토리지 수명주기 비용은 20% 줄어서 총합 30~40% 감소로 추정된다. 다만 실제 단가는 리전·공급자별로 상이하므로 최신 정보를 확인해야 한다.
보안·아키텍처·운영에서 맞바꾸는 것들
보안은 최소 권한(IAM), 네트워크 세분화, 키/비밀 관리 분리, 중앙 감사 로깅이 원칙이다 — 세분화 정책이 늘면 운영 복잡도가 오르는데, 정책-as-code로 일관성을 확보하는 게 대응책이다. 아키텍처는 장애 도메인 분리(멀티AZ/리전), 스테이트리스 우선, 백프레셔·리트라이·아이템포턴시 확보가 원칙이지만, 멀티리전 구성은 데이터 일관성 지연을 늘리므로 읽기/쓰기 경로 분리나 CRDT·이벤트소싱을 고려해야 한다. 운영은 IaC 상태 락(Terraform state locking)으로 동시 배포 충돌을 막고 변경 실패율(Change Failure Rate)을 모니터링하는 게 원칙인데, 게이트를 엄격히 걸수록 배포 속도가 떨어지므로 위험 기반 릴리즈(리스크 태깅)로 균형을 잡는다.
도입은 이 순서로 진행한다
- 평가: 워크로드 분류(보안/성능/규제), TCO·ROI 분석, 서비스 모델 매핑.
- 파일럿: 한 개 도메인에 최소 기능 제품(MVP) 배포, SLO·에러버짓 정의.
- 랜딩존: 계정 구조, 네트워크, IAM, 로깅, 키 관리 표준화.
- 마이그레이션: Rehost→Replatform→Refactor 우선순위, 데이터 마이그레이션 런북 작성.
- 최적화: 오토스케일·예약/스팟 적용, 저장소 계층화, 비용 얼럿·쇼백 운영.
- 운영: SRE 관점의 SLI/SLO 체계, 카나리/롤백 자동화, 혼합 멀티클라우드 관측 단일창 구성.
추상화된 서비스 모델과 자동화 기반 운영 체계를 세우는 것이 클라우드 컴퓨팅 서비스 도입의 핵심이다. 서비스 특성·규제·비용 제약을 고려해 하이브리드·멀티 전략을 설계하고, 랜딩존 표준화와 IaC·관측성 체계를 조기에 정착시켜야 민첩성과 비용효율을 동시에 확보할 수 있다.