PaaS, 인프라 운영과 애플리케이션 코드 사이의 경계를 대신 그어주는 플랫폼
PaaS의 런타임·빌드팩·서비스 바인딩 구조와 배포 파이프라인, Heroku 배포 절차를 IaaS·Serverless와 비교하며 정리한다.
2026-08-13 · 최초 발행 2025-12-03
IaaS와 Serverless 사이, PaaS가 서 있는 자리
서버 한 대의 OS 패치부터 오토스케일링 정책까지 전부 팀이 책임지는 구조와, 함수 하나를 올리면 나머지는 신경 쓰지 않아도 되는 구조. 두 극단 사이에서 코드는 직접 다루되 실행 환경의 운영은 넘기고 싶은 팀들이 자리 잡는 지점이 PaaS(Platform as a Service)다.
PaaS는 애플리케이션 실행에 필요한 런타임, 미들웨어, 빌드·배포 파이프라인, 서비스 바인딩, 관측을 관리형으로 제공하는 클라우드 플랫폼이다. 개발자는 코드와 설정에 집중하고, 플랫폼은 빌드·릴리즈·스케일링·보안을 일관된 규칙으로 자동화한다. IaaS 위에서 동작하며 컨테이너 오케스트레이션, 이미지 레지스트리, 라우팅, 서비스 카탈로그를 통합 제공한다. Cloud Foundry, Heroku, Google App Engine, Azure App Service, Red Hat OpenShift가 이 모델을 대표한다.
운영 모델은 멀티테넌시 기반 격리, 조직·스페이스 단위 거버넌스, 정책 기반 스케일링·자원 할당, 서비스 브로커를 통한 외부 관리형 서비스 연동으로 구성된다.
코드가 서비스로 나가기까지 플랫폼이 대신 하는 일
애플리케이션은 컨테이너 기반으로 실행되고 상태 비저장 프로세스 모델을 따르며, 라우터나 Ingress가 요청을 분배한다. 롤링·블루-그린·카나리 같은 표준 배포 전략을 지원하고, 헬스체크·재시작 정책·네임스페이스 격리로 안정성을 확보한다. SLA 기반 가용성 보장도 이 계층에서 이뤄진다.
빌드는 Buildpack이나 Dockerfile을 통해 이미지 생성을 자동화한다. 종속성 추적, 캐시, 재현성 있는 빌드를 제공하며 Git push·CLI·API 트리거로 단일 명령 배포가 가능하다. CI 파이프라인과 시맨틱 버전·아티팩트 서명을 연계할 수 있다.
서비스 바인딩은 서비스 브로커를 통해 DB·캐시·메시지 큐 같은 관리형 서비스를 프로비저닝하고 바인딩한다. VCAP_SERVICES 같은 표준 형식으로 연결 정보를 주입하며, 시크릿은 KMS·HSM 연계로 암호화 관리하고 회전 정책과 최소권한 원칙을 적용한다.
관측 측면에서는 메트릭·로그·트레이스 수집을 내장하고, SLO 기반 알림과 오토스케일링을 연계한다. 비정상 컨테이너는 자가치유로 재배치되며, HPA나 지표 기반 스케일 아웃·인으로 비용·성능 균형을 최적화한다.
거버넌스는 조직·프로젝트 단위 할당량, 빌드팩 허용 목록, 네트워크 정책으로 규범화되고, 감사 로그와 SBOM 생성으로 규정 준수를 지원한다. 이미지 서명, 런타임 정책(OPA/Gatekeeper), 취약점 스캔은 공급망 보안을 강화한다.
코드 푸시부터 트래픽 응답까지, 배포 파이프라인이 흐르는 경로
실제로 PaaS를 쓰는 조직의 장면들
사내 공통 PaaS로 런타임·빌드팩·보안 가드레일을 표준화하면 팀 간 재사용과 규정 준수가 강화된다. 서비스 카탈로그를 통해 관리형 DB·메시징을 공유하면서 비용·품질·속도의 균형을 맞추는 방식이 대표적이다.
트래픽 변동이 큰 캠페인이나 민원 시스템에는 오토스케일링을 적용해 장애 시 자동 복구로 MTTR을 단축하고, 블루-그린이나 카나리 배포로 무중단 배포를 구현한다.
WAS 중심 모놀리식 애플리케이션을 12-Factor 원칙으로 전환해 외부 상태를 분리하고, CI 파이프라인과 결합해 릴리스 빈도를 높이는 레거시 현대화 사례도 있다. 운영이 표준화되면 신규 인력의 온보딩 시간도 단축된다.
배포 절차를 입력→처리→출력으로 보면, 입력은 코드 커밋과 환경 변수·시크릿·서비스 바인딩 요청이고, 처리는 Buildpack 빌드→이미지 서명/스캔→배포 전략(롤링/블루-그린) 실행이며, 출력은 새 릴리즈 라우팅과 메트릭·로그 생성, 알림이다.
Heroku로 Node.js 애플리케이션을 올리는 절차
전제조건은 Node.js 18+, Git 2.40+, Heroku CLI v8+ 설치이며, 리전·요금제는 최신 정보를 별도 확인해야 한다.
저장소를 준비한다.
git init && echo "web: node server.js" > Procfile
애플리케이션을 생성하고 빌드팩을 지정한다.
heroku create myapp-xyzheroku buildpacks:add heroku/nodejs
배포·스케일링·관측을 진행한다.
git push heroku mainheroku config:set NODE_ENV=productionheroku ps:scale web=2heroku logs --tail
빌드가 실패하면 heroku builds:output으로 상세 로그를 확인하고 Node/LTS 버전 호환성을 점검한다. 포트 바인딩 오류가 나면 PORT 환경 변수 사용 여부와 서버 코드의 동적 포트 바인딩 적용 여부를 확인한다.
IaaS·Serverless와 견줘 무엇을 얻고 무엇을 내주는가
| 지표 | IaaS | PaaS | Serverless(FaaS) |
|---|---|---|---|
| 성능 | 고정 자원 튜닝 유연, 관리 부담 큼 | 표준화된 성능, 조정 범위 중간 | 콜드스타트·제한 존재, 단위 실행 최적화 |
| 확장성 | 수동/반자동 스케일, 설계 복잡 | 정책 기반 오토스케일링 용이 | 이벤트 기반 극대화, 상태 관리 제약 |
| 일관성 | 팀별 편차 큼 | 빌드·배포·관측 표준화 | 함수 단위 표준화, 시스템 전반 일관성 한계 |
| 안정성 | 운영 품질에 의존 | 자가치유·롤백 내장 | 플랫폼 내결함성 우수, 외부 종속성 영향 |
| 운영 편의 | 고난도 운영 요구 | 운영 자동화 높음 | 운영 최소화, 벤더 종속성 상존 |
이 표가 보여주듯 PaaS는 애플리케이션 생애주기 전반의 표준화·자동화로 생산성과 안정성을 동시에 얻는 대신, IaaS만큼의 세밀한 튜닝 자유도나 Serverless만큼의 운영 최소화는 포기하는 위치에 있다.
도입이 가져오는 효과는 수치로도 드러난다. 리드타임은 3070% 단축되고 배포 빈도는 25배 늘며 MTTR은 4080% 감소한다. 인프라 작업 시간은 50% 이상 절감되고, 표준화된 파이프라인으로 실패율은 2040% 줄며 오토스케일링으로 피크 대비 비용을 15~35% 최적화할 수 있다. 정성적으로는 개발자 경험(DX) 향상, 온보딩 간소화, 규정 준수 일관성 확보, 운영-개발 간 책임 경계 명확화, 공급망 보안·가시성 개선이 뒤따른다.
도입 시에는 대표 워크로드로 우선순위를 선정하고, 파일럿을 구축한 뒤 빌드팩·보안·관측 가드레일을 정의하고, 개발팀 온보딩을 거쳐 SLO 기반 운영으로 단계적으로 정착시키는 접근이 유효하다. 벤더 종속성과 커스텀 요구 제한이라는 잠재 리스크는 멀티클라우드 이식성과 Buildpack·OCI·SBOM 같은 오픈 표준 채택으로 완화할 수 있다.