교과서적인 정의로는 "IaaS는 인프라를 빌려주는 것, PaaS는 플랫폼을 제공하는 것" 정도로 설명되지만, 개발자 관점에서 이 둘을 가르는 본질은 추상화 계층(Abstraction Layer)의 높이와 책임의 경계(Shared Responsibility)에 있습니다.
특히 주니어 개발자들과 이야기하다 보면 종종 나오는 질문이 있습니다.
"PaaS도 어차피 밑단에서 EC2 같은 VM(가상 머신) 띄워서 돌아가는 거 아닌가요?"
결론부터 말하면 맞습니다. 클라우드 벤더가 마법으로 코드를 띄우는 것이 아니기에, 밑단에는 당연히 물리 머신과 하이퍼바이저, 그리고 그 위에서 돌아가는 VM과 컨테이너가 존재합니다.
그렇다면 왜 우리는 이 둘을 구분해서 부르고, 각기 다른 상황에서 선택하는 걸까요? 개발자 관점에서 정리해 보았습니다.
1. 핵심 차이: 내가 제어하는 경계의 높이
IaaS와 PaaS의 가장 큰 차이는 개발자가 넘겨받는 '시작점'입니다.
- IaaS (예: AWS EC2, GCP Compute Engine)
- 넘겨받는 것: 깨끗하게 비어 있는 OS (Ubuntu, RHEL, Windows Server 등)
- 개발자의 역할: SSH로 접속해서 방화벽 열고, 커널 파라미터 맞추고, Java/Python/Node 런타임 깔고, Nginx 설정하고, 로그 로테이션 걸고, 애플리케이션 데몬을 띄웁니다.
- PaaS (예: AWS Elastic Beanstalk, GCP Cloud Run, Heroku)
- 넘겨받는 것: 빌드팩(Buildpack)이나 컨테이너 이미지를 즉시 구동할 수 있는 완성형 런타임 환경
- 개발자의 역할: 코드(또는 Dockerfile)를 작성하고 Git push 또는 배포 파이프라인을 트리거합니다. 인프라 세팅은 신경 쓰지 않습니다.
한눈에 보는 비교
구분 | IaaS (AWS EC2 등) | PaaS (AWS Elastic Beanstalk, Cloud Run 등) |
|---|---|---|
제공 형태 | 가상 머신(VM) 및 OS 인스턴스 | 코드/컨테이너 실행 런타임 |
인프라 제어권 | OS 커널, 루트 권한(SSH/sudo) 완전 제어 | 인프라 직접 제어 불가 (환경 변수, 인스턴스 수 등 설정) |
개발자 작업 범위 | OS 보안 패치, 미들웨어 설치, 네트워크 설정 | 애플리케이션 코드 작성 및 비즈니스 로직 구현 |
스케일링 방식 | 오토스케일링 그룹(ASG), 로드밸런서(ALB) 직접 설계 | 트래픽 기준 자동 스케일아웃/인 (설정 몇 클릭으로 완료) |
장애 책임 영역 | OS 보안 취약점, 디스크 풀(Full), 런타임 크래시 | 순수 애플리케이션 레벨의 버그 및 부하 이슈 |
2. "PaaS 밑단에도 VM이 돈다"의 진짜 의미
PaaS를 쓰더라도 클라우드 데이터센터 어딘가에서는 하이퍼바이저가 VM을 할당하고, 그 위에 cgroups/namespaces 기반의 격리된 컨테이너가 생성되어 코드를 실행합니다.
차이는 그 VM의 '소유권과 생명주기(Lifecycle)'를 누가 쥐고 있느냐입니다.
① IaaS의 VM: 내 소유의 서버 (Pet)
- 개발자 또는 인프라팀에 루트 권한(SSH)이 주어집니다.
- OS 취약점이 발견되면 직접 패키지 업데이트(
apt update && apt upgrade)를 하거나 AMI를 새로 구워야 합니다. - 디스크 I/O 병목, 메모리 누수로 서버가 뻗으면 헬스체크와 복구 스크립트를 직접 설계해야 합니다. 즉, 하나의 서버를 애지중지 관리하는 Pet(반려동물) 모델에 가깝습니다.
② PaaS의 VM: 벤더가 관리하는 일회성 컴퓨팅 자원 (Cattle)
- VM은 완전히 클라우드 공급자의 관리 영역(Black Box) 뒤로 숨겨집니다.
- 개발자에게 영구적인 SSH 접근 권한을 주지 않습니다. 설령 디버깅용 셸 접속을 지원하더라도 일회성(Ephemeral) 세션에 불과하며, 컨테이너가 재시작되면 로컬에 남긴 변경사항은 증발합니다.
- OS 패치, 보안 업데이트, 노드 고장 시 교체(Drain & Replace) 작업은 벤더의 오케스트레이터가 무중단으로 알아서 처리합니다.
- 개발자는 IP 주소나 디스크 마운트 경로 대신 컨테이너 CPU/메모리 할당량, 동시 요청 수(Concurrency)만 바라봅니다.
3. 실무에서는 무엇을 선택해야 할까?
추상화 계층이 높다고 해서 무조건 PaaS가 우월한 것은 아닙니다. 제어권과 편의성 사이에는 명확한 트레이드오프가 존재합니다.
💡 IaaS가 더 적합한 경우
- OS 레벨의 커스텀이 필수적인 레거시 환경: 특정 리눅스 커널 모듈, 오래된 C/C++ 네이티브 바이너리, 금융/엔터프라이즈 전용 보안 에이전트 구동이 필요할 때
- 복잡한 네트워크 토폴로지 구성: 사내 온프레미스 망과의 전용선(Direct Connect/VPN) 연계, 복잡한 서브넷 라우팅 및 패킷 필터링을 세밀하게 제어해야 할 때
- 극한의 비용 최적화: 장기적으로 대규모 워크로드를 고정 운용하여 Reserved Instance(RI)나 Savings Plans를 극한으로 활용할 때 (PaaS는 관리 비용이 단가에 포함되어 대규모 트래픽 시 단가가 더 높을 수 있음)
💡 PaaS가 더 적합한 경우
- 비즈니스 로직에 집중해야 하는 모던 웹 서비스: Spring Boot, FastAPI, Node.js 등 표준화된 스택으로 빠르게 MVP를 만들거나 API 서비스를 운영할 때
- 운영 전담 인프라팀이 없거나 리소스가 부족한 팀: OS 패치, 백업 자동화, 로드밸런싱 등 인프라 유지보수에 투입할 엔지니어링 리소스가 부족할 때
- 트래픽 변동 폭이 큰 서비스: 평소에는 리소스를 최소화하다가 특정 이벤트나 피크 타임에 자동으로 스케일아웃이 필요한 워크로드
4. 요약: 추상화 계층을 고르는 기준
PaaS 역시 밑단에서는 가상 머신(VM)을 사용합니다. 하지만 "OS 설정과 서버 관리에 시간을 쓸 것인가, 아니면 그 시간에 비즈니스 기능을 하나 더 만들 것인가?"라는 질문에서 두 모델의 갈림길이 생깁니다.
인프라 세부 튜닝이 시스템의 핵심 경쟁력이 아니라면, 최근의 클라우드 네이티브 트렌드는 컨테이너 기반 PaaS(또는 Serverless Container)를 통해 인프라 운영 비용을 벤더에 위임하는 방향으로 수렴하고 있습니다. 프로젝트의 성격과 팀의 운영 역량에 맞춰 적절한 추상화 수준을 선택하는 안목이 중요합니다.