어디까지 내가 관리하고, 어디부터 맡길 것인가
"As a Service"의 본질

클라우드 서비스 모델을 이야기할 때 자주 등장하는 IaaS, CaaS, PaaS, SaaS는 결국 하나의 질문으로 요약된다.
"컴퓨팅 스택 중 어디까지를 내가 직접 관리하고, 어디부터를 클라우드 업체에 맡길 것인가."
서버, OS, 미들웨어, 런타임, 애플리케이션, 데이터로 이어지는 계층 중 관리 경계선을 어디에 긋느냐에 따라 모델이 나뉜다.
IaaS — 인프라만 빌린다

IaaS(Infrastructure as a Service)는 컴퓨팅, 스토리지, 네트워크, 가상화 같은 인프라 자원을 클라우드로 제공받는 모델이다.
물리 서버를 사고 관리할 필요는 없어지지만, 그 위에 올라가는 OS, 미들웨어, 런타임, 애플리케이션, 데이터는 여전히 사용자가 직접 구성하고 책임진다. 대표적으로 AWS EC2, Google Compute Engine이 여기 속한다.
가장 큰 장점은 제어권이다. 원하는 대로 OS를 고르고 소프트웨어를 설치할 수 있어 자유도가 가장 높다. 대신 그만큼 보안 패치, 장애 복구, 확장 설정까지 전부 직접 챙겨야 한다는 부담이 따라온다. 비유하자면, 집을 짓는 과정을 도급업자에게 맡기되 완성된 집의 내부 설비와 유지관리는 여전히 내 몫으로 남는 것과 비슷하다.
CaaS — 컨테이너 단위로 빌린다

CaaS(Containers as a Service)는 IaaS와 PaaS 사이 어딘가에 위치한 모델로, VM 대신 컨테이너를 기본 단위로 삼는다.
컨테이너를 실행하고 관리하기 위한 인프라 자체는 클라우드 업체가 맡아주기 때문에 개발자는 기본 OS 설정을 신경 쓸 필요 없이 컨테이너화된 애플리케이션을 올리는 데 집중할 수 있다. Google Kubernetes Engine(GKE)이 대표적인 예다.
마이크로서비스 아키텍처를 운영하거나, 하이브리드·멀티클라우드 환경에서 워크로드를 자유롭게 옮겨야 하는 경우 특히 유용하다. 다만 컨테이너는 호스트 OS의 커널을 공유하는 구조이기 때문에, VM 방식보다 격리 수준이 낮아 보안 측면에서 별도의 주의가 필요하다.
PaaS — 개발 플랫폼까지 빌린다
PaaS(Platform as a Service)는 애플리케이션 개발에 필요한 하드웨어와 소프트웨어 환경을 통째로 제공한다. 서버 프로비저닝, OS 관리, 미들웨어 설정, 런타임 구성까지 클라우드 업체가 담당하고, 사용자는 코드를 작성하고 배포하는 데만 집중하면 된다. AWS Elastic Beanstalk, Google App Engine, Cloud Run 등이 여기 해당한다.

개발 속도를 크게 끌어올릴 수 있다는 게 핵심 장점이다. 인프라를 신경 쓰지 않아도 되니 시장 출시까지 걸리는 시간(Time To Market)이 단축된다. 대신 플랫폼이 지원하는 언어나 프레임워크 범위 안에서만 개발해야 하는 제약이 생기고, 특정 클라우드 업체의 PaaS 서비스에 깊이 의존할 경우 벤더 락인(vendor lock-in) 위험도 커진다.
SaaS — 완성된 서비스를 그대로 쓴다

SaaS(Software as a Service)는 인프라부터 애플리케이션까지 전체 스택이 이미 완성된 상태로 제공되는 모델이다. Gmail이나 Google Workspace처럼 웹브라우저만 있으면 별도 설치 없이 바로 사용할 수 있다. 업데이트, 버그 수정, 서버 유지보수는 전부 서비스 제공업체 몫이다.
가장 쉽고 빠르게 도입할 수 있다는 장점이 있지만, 그만큼 인프라나 보안에 대한 통제권은 거의 없다고 봐야 한다. 커스터마이징의 폭도 좁고, 기존에 쓰던 다른 도구들과의 연동이 매끄럽지 않을 수 있다는 점도 고려 대상이다.
집으로 비유하면

이 네 가지 모델은 흔히 주거 형태에 비유된다.
- 온프레미스는 자재를 직접 사서 집을 처음부터 짓는 것
- IaaS는 도급업자에게 시공만 맡기되 내부 설비와 관리는 직접 하는 것
- CaaS는 기본 설비가 갖춰진 집을 빌려 가구 배치만 직접 하는 것
- PaaS는 가구까지 다 갖춰진 집을 빌려 그냥 들어가 사는 것
- SaaS는 이미 완성되어 관리까지 되는 집에 살면서 관리비만 내는 것
집을 지을 자유는 뒤로 갈수록 줄어들지만, 대신 신경 써야 할 일도 함께 줄어든다.
결국 선택의 기준은 "통제냐, 편의냐"
IaaS는 자유도가 높은 대신 관리 부담이 크고, SaaS는 관리 부담이 없는 대신 통제권이 거의 없다. PaaS와 CaaS는 그 중간 지점에서 각자 다른 방식으로 균형을 잡는다.
그리고 이 네 모델은 서로 배타적이지 않다. 실제 조직에서는 핵심 데이터베이스는 IaaS로 직접 관리하면서, 사내 협업 도구는 SaaS로 쓰고, 특정 마이크로서비스는 CaaS나 PaaS로 배포하는 식의 혼합 구성이 흔하다.
결국 어떤 모델을 선택할지는 "이 시스템에서 우리가 반드시 직접 통제해야 하는 부분은 무엇이고, 남에게 맡겨도 되는 부분은 무엇인가"를 먼저 정하는 데서 출발한다.
'Cloud, IT Infra > 개념·용어' 카테고리의 다른 글
| [Cloud] 멀티테넌시(Multi-tenancy) 이해하기 (0) | 2026.07.13 |
|---|---|
| [Infra] 가용성과 다운타임 (0) | 2026.07.13 |
| [Infra] RTO / RPO란? (0) | 2026.07.13 |
| [Cloud] Scale-up과 Scale-out (1) | 2026.07.13 |
| [Infra] 트레이드오프(trade-off) (0) | 2026.07.13 |