IaaS/PaaS/SaaS부터 서버리스, Kubernetes까지 — 클라우드 서비스 모델 실무 정리
클라우드 서비스 모델(IaaS/PaaS/SaaS)의 책임 분계선, AWS Lambda 기반 서버리스 아키텍처, Kubernetes 오케스트레이션과 클라우드 네이티브 트렌드를 정리한다
2026-08-12 · 최초 발행 2026-01-16
서버를 직접 사서 랙에 꽂던 시절과 지금의 차이는 결국 "무엇을 내가 관리하고, 무엇을 남에게 맡기느냐"의 경계선이 어디로 이동했느냐에 있다. IaaS·PaaS·SaaS는 그 경계선의 위치를 나눈 것이고, 서버리스는 그 경계선을 인프라 자체가 안 보이는 지점까지 밀어붙인 것이다.
온디맨드로 자원을 빌린다는 것
클라우드 컴퓨팅은 네트워크를 통해 서버·스토리지·네트워크·애플리케이션 같은 컴퓨팅 자원을 온디맨드로 제공하는 서비스다. 핵심 특징은 셀프서비스로 즉시 프로비저닝할 수 있고, 사용량이 측정되며, 필요에 따라 탄력적으로 늘고 줄고, 여러 사용자가 자원 풀을 공유한다는 점이다. 배포 형태로는 AWS·Azure·GCP 같은 퍼블릭 클라우드, 오픈스택 기반의 프라이빗 클라우드, 그리고 둘을 섞은 하이브리드 클라우드가 있다.
이게 가져오는 변화는 세 갈래다. 서버를 미리 사두는 CAPEX 대신 쓴 만큼 내는 OPEX로 비용 구조가 바뀌고, 트래픽이 늘면 서버가 자동으로 늘어나는 수평 확장과 전 세계 데이터센터를 통한 글로벌 배포가 가능해지며, 수개월 걸리던 서버 구축이 API 호출 몇 번으로 수분 안에 끝나면서 테스트 환경을 즉시 만들고 지울 수 있게 된다.
IaaS·PaaS·SaaS, 책임이 어디까지 넘어가는가
세 모델의 차이는 결국 애플리케이션·런타임·OS·가상화·하드웨어라는 다섯 계층 중 어디까지를 내가 관리하느냐다.
IaaS는 가상 서버·스토리지·네트워크만 제공하는 가장 낮은 추상화 계층이다. OS 설치·패치, 애플리케이션 배포, 보안 설정은 사용자 몫이고 클라우드는 물리 서버·가상화·데이터센터 운영을 책임진다. AWS EC2, Azure Virtual Machines, GCP Compute Engine이 대표적이며, 구성 요소는 컴퓨트(VM, 베어메탈), 스토리지(EBS 같은 블록·S3 같은 객체·EFS 같은 파일), 네트워크(VPC, 로드 밸런서, VPN)로 나뉜다. 레거시 애플리케이션을 그대로 옮기는 Lift and Shift, 환경별 임시 VM이 필요한 개발/테스트, Hadoop·Spark 같은 대규모 클러스터를 잠깐 띄웠다 지우는 빅데이터 작업에 쓰인다.
PaaS는 OS·런타임 관리를 걷어내고 애플리케이션 실행 플랫폼만 제공한다. 개발자는 코드만 작성·배포하면 되고, OS 패치·런타임 업데이트·자동 확장·로드 밸런싱은 클라우드가 맡는다. AWS Elastic Beanstalk, Azure App Service, Google App Engine, Heroku가 여기 속하고 Java·Python·Node.js·.NET 등 언어별 런타임을 지원하며 데이터베이스·캐시·큐·모니터링을 원클릭으로 붙일 수 있다. 빠른 MVP 개발, RESTful API 서버 배포, 서비스별 독립 배포가 필요한 마이크로서비스에 어울린다.
SaaS는 완성된 소프트웨어를 브라우저로 바로 쓰는 형태다. Gmail, Office 365, Salesforce, Slack, Zoom처럼 사용자는 데이터 입력과 설정만 하면 되고 개발·운영·업데이트는 전부 제공자 몫이다. 단일 애플리케이션을 여러 고객이 나눠 쓰는 멀티 테넌시, 월/연 구독 과금, 사용자 개입 없는 자동 업데이트가 특징이다.
| 항목 | IaaS | PaaS | SaaS |
|---|---|---|---|
| 추상화 수준 | 낮음 | 중간 | 높음 |
| 유연성 | 높음 | 중간 | 낮음 |
| 관리 복잡도 | 높음 | 중간 | 낮음 |
| 배포 속도 | 느림 | 빠름 | 즉시 |
| 사용자 | 인프라 엔지니어 | 개발자 | 최종 사용자 |
서버리스: 인프라가 아예 안 보이게
서버리스는 서버 프로비저닝·관리를 아예 없애고 이벤트가 발생하면 코드만 실행되는 모델이다. "서버 관리에서 해방되고 비즈니스 로직에만 집중한다"는 게 핵심 철학이고, AWS Lambda, Azure Functions, Google Cloud Functions가 대표 서비스다.
FaaS의 동작은 단순하다. 개발자가 함수 코드를 올리고, HTTP 요청·S3 파일 업로드·스케줄러 같은 이벤트 소스를 설정하면, 이벤트가 발생할 때 컨테이너가 자동으로 만들어져 함수를 실행하고 끝나면 컨테이너가 삭제된다. 과금은 실행 시간과 메모리 사용량을 곱한 값으로, 100ms 단위로 계산된다.
Lambda 함수는 이런 식으로 작성한다.
import json
def lambda_handler(event, context):
# 이벤트 처리
name = event.get('name', 'World')
# 비즈니스 로직
message = f"Hello, {name}!"
# 응답 반환
return {
'statusCode': 200,
'body': json.dumps({'message': message})
}이벤트 소스는 HTTP/REST 요청을 받는 API Gateway, 파일 업로드/삭제를 감지하는 S3, DB 변경을 감지하는 DynamoDB Streams, 매일 자정 같은 스케줄을 트리거하는 CloudWatch Events, 메시지 큐 이벤트인 SNS/SQS 등이 있다.
장점은 분명하다. 동시 요청 수천 개도 자동으로 처리하는 무한 확장성, 실행 시간만 과금해 유휴 비용이 0원이라는 점, 서버 패치·모니터링·로그 수집이 자동화된다는 점, 인프라 코드 없이 비즈니스 로직만 쓰면 된다는 개발 속도다. 대신 첫 요청에서 컨테이너를 새로 만드느라 100ms에서 수 초까지 지연되는 Cold Start, AWS Lambda 기준 최대 15분이라는 실행 시간 제한, 다른 클라우드로 옮기기 어려운 벤더 종속, 로컬 환경과 달라 까다로운 디버깅이라는 대가를 치른다.
실무에서 자주 보이는 패턴은 세 가지다. S3에 이미지가 올라오면 Lambda가 트리거되어 리사이징하고 결과를 다시 S3에 저장하는 이벤트 기반 처리, API Gateway + Lambda + DynamoDB로 구성해 트래픽 급증에도 서버 관리 없이 자동 확장되는 모바일 앱 백엔드, CloudWatch Events의 cron 설정으로 매일 자정 Lambda를 실행해 RDS 스냅샷을 뜨는 스케줄 작업이다.
Kubernetes가 컨테이너를 다루는 방식
Kubernetes는 컨테이너화된 애플리케이션의 배포·확장·관리를 자동화하는 오픈소스 플랫폼이다. Google 내부의 Borg 시스템을 기반으로 만들어져 2014년 오픈소스로 공개됐고, 비슷한 역할을 하는 것으로 AWS ECS, Docker Swarm, Nomad가 있다.
핵심 개념은 몇 가지로 압축된다. Pod는 하나 이상의 컨테이너를 묶는 최소 배포 단위로, 같은 Pod 안의 컨테이너는 IP와 스토리지를 공유한다(예: Nginx 웹 서버와 Fluentd 로그 수집기를 한 Pod에 묶는 식). Deployment는 Pod 복제본 개수와 업데이트 전략을 정의하고 롤링 업데이트·롤백·자동 복구를 담당한다(replicas: 3이면 항상 3개 Pod를 유지). Service는 Pod 집합에 대한 고정 네트워크 엔드포인트로, 클러스터 내부용 ClusterIP(기본값), 30000~32767 포트로 외부에 노출하는 NodePort, 클라우드 로드 밸런서를 자동으로 만드는 LoadBalancer 세 가지 타입이 있다. ConfigMap은 설정 파일·환경 변수를, Secret은 비밀번호·API 키를 암호화해 저장한다.
트래픽이 몰리면 Horizontal Pod Autoscaler(HPA)가 CPU 사용률·메모리·커스텀 메트릭을 기준으로 Pod 복제본을 늘린다. 예를 들어 CPU가 70%를 넘으면 Pod 개수를 2배로 늘리는 식이다.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: nginx-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx-deployment
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70Pod 수준을 넘어 워커 노드 자체가 부족해 Pod 스케줄링이 실패하면 Cluster Autoscaler가 노드를 추가한다. AWS Auto Scaling Group이나 GCP Managed Instance Group과 연동해 동작한다.
배포 전략에서는 롤링 업데이트가 기본이다. 기존 Pod를 하나씩 새 버전으로 바꿔가면서 일부 Pod는 계속 서비스를 유지하기 때문에 무중단 배포가 가능하고, 문제가 생기면 kubectl rollout undo 한 번으로 이전 버전으로 되돌릴 수 있다.
실무에서는 사용자·주문·결제 서비스를 각각 독립된 Deployment로 배포하고 Kubernetes DNS로 서비스를 자동 탐색하며 한 서비스의 장애가 전체로 번지지 않게 격리하는 마이크로서비스 아키텍처, Jenkins가 Docker 이미지를 만들어 레지스트리에 올리면 Kubernetes가 롤링 업데이트로 반영하고 Prometheus + Grafana로 모니터링하는 CI/CD 파이프라인, 그리고 YAML 매니페스트 하나로 AWS·Azure·GCP·온프레미스 어디서든 동일하게 실행되는 하이브리드/멀티 클라우드 구성에 쓰인다.
클라우드 네이티브를 완성하는 나머지 조각들
Docker로 애플리케이션과 의존성을 하나의 이미지로 패키징하고 OCI(Open Container Initiative)가 그 형식을 표준화하면서 컨테이너화가 자리 잡았다. 마이크로서비스 수가 늘면 서비스 간 통신을 프록시로 중재하는 서비스 메시가 필요해지는데, 트래픽 암호화·재시도·서킷 브레이커·추적 기능을 제공하는 Istio, Linkerd가 대표적이다.
인프라 상태를 Git 저장소를 단일 진실 소스로 관리하는 GitOps는 ArgoCD, Flux 같은 도구로 "Git Push → 자동 배포 → 상태 동기화" 흐름을 만든다. 그리고 클라우드 비용이 커지면 FinOps(Financial Operations)가 등장한다 — 미사용 자원 제거, Reserved Instance 구매, Spot Instance 활용 같은 방법을 AWS Cost Explorer, Kubecost 같은 도구로 관리한다.
이 조각들을 합치면 클라우드 컴퓨팅의 그림이 완성된다. IaaS로 인프라 민첩성을, PaaS로 개발 속도를, SaaS로 즉시 쓸 수 있는 솔루션을 얻고, 서버리스는 서버 관리 부담 자체를 없애며, Kubernetes와 HPA·롤링 업데이트·GitOps는 그 위에서 돌아가는 복잡한 마이크로서비스 환경을 코드로 관리 가능한 수준까지 끌어내린다.