PaaS는 애플리케이션을 개발·배포·실행하는 플랫폼을 인터넷으로 빌려 쓰는 클라우드 서비스 모델입니다.
PaaS의 책임 범위는 애플리케이션 바로 아래에서 나뉩니다. 제공자는 네트워크부터 운영체제와 런타임까지 관리하고 사용자는 애플리케이션과 데이터를 운영합니다.
PaaS 과금 방식은 사용량 기반과 플랜 정액제로 나뉩니다. 도입 전에는 지원 언어·런타임과 벤더 종속·공동 책임 모델·오토스케일링 요금을 확인합니다.
개발자에게 서버 준비는 코드 작성만큼 손이 많이 가는 일입니다. 운영체제를 설치하고 실행 환경을 맞춰야 합니다. 접속이 늘면 서버도 늘려야 합니다. 이런 운영 작업을 제공자에게 맡기고 개발자는 코드에만 집중하도록 만든 방식이 PaaS입니다. 이번 글에서는 PaaS의 정의와 책임 범위를 살펴보고 구성 요소·과금 방식과 도입 전에 확인할 지점까지 정리하겠습니다.
PaaS란? PaaS 뜻과 정의
PaaS(Platform as a Service, 서비스형 플랫폼)는 애플리케이션을 개발·배포·실행하는 데 필요한 플랫폼을 인터넷으로 빌려 쓰는 클라우드 서비스 모델입니다.
미국 국립표준기술연구소(NIST)는 PaaS를 제공자가 지원하는 프로그래밍 언어·라이브러리·도구로 사용자가 직접 만들었거나 확보한 애플리케이션을 클라우드 인프라에 배포하는 모델로 정의합니다¹. 이 정의에서 사용자는 네트워크·서버·운영체제·스토리지를 관리하지 않습니다. 사용자가 통제하는 것은 배포한 애플리케이션과 실행 환경의 일부 설정입니다.
정리하면 PaaS는 서버를 빌리는 것이 아니라 ‘코드를 올리면 실행되는 환경’을 빌리는 모델입니다. 개발자가 코드를 플랫폼에 올리면 플랫폼이 그 코드를 실행·확장·관리합니다.
- NIST, The NIST Definition of Cloud Computing (Special Publication 800-145), 2011
PaaS 구조: 제공자와 사용자의 책임 범위
PaaS에서 제공자가 빌려주는 것은 인프라에 운영체제와 실행 환경까지 더한 플랫폼 계층입니다.
PaaS의 책임 범위
| 관리 주체 | 레이어 |
|---|---|
| 사용자 관리 | 데이터 |
| 애플리케이션 | |
| 제공자 관리 | 미들웨어·런타임 |
| 운영체제(OS) | |
| 가상화 | |
| 서버 | |
| 스토리지 | |
| 네트워크 |
IaaS에서는 운영체제부터 사용자가 관리합니다. PaaS에서는 책임 경계가 애플리케이션 바로 아래까지 올라갑니다. 운영체제 업데이트, 보안 패치, 런타임 설치, 버전 관리는 제공자가 맡습니다. 사용자는 애플리케이션 코드, 데이터, 환경 변수, 인스턴스 수 같은 실행 설정을 관리합니다. 완성된 애플리케이션까지 제공자가 맡으면 SaaS가 됩니다. PaaS는 실행 환경을 빌리고 애플리케이션만 직접 운영하는 모델입니다.
PaaS 등장 배경: 서버 관리에서 코드 배포 중심으로
클라우드 인프라 덕분에 서버는 몇 분 만에 빌릴 수 있게 됐습니다. 하지만 서버를 받은 뒤에도 운영체제 설정·웹 서버와 런타임 구성·보안 패치·확장 설정은 여전히 개발팀의 몫이었습니다. 웹 서비스가 빠르게 늘어나면서 이 작업은 프로젝트마다 반복되었습니다.
이 반복 작업을 없애려는 서비스가 2000년대 후반에 등장했습니다. 2007년 개발자들이 세운 Heroku²가 대표적입니다. 이듬해인 2008년 4월에는 구글이 웹 애플리케이션을 구글 인프라에서 실행하는 Google App Engine의 프리뷰 버전을 공개했습니다. App Engine은 인프라 관리를 대신 맡아 개발자가 코드 작성에 집중하게 돕는 서비스입니다.³ 2010년 세일즈포스(Salesforce)는 인수 발표에서 Heroku를 관리할 가상 머신도 설치할 소프트웨어도 관리할 하드웨어도 없는 플랫폼으로 소개했습니다.²
이후 2011년 NIST가 IaaS·PaaS·SaaS를 클라우드의 세 가지 서비스 모델로 정의하면서¹ PaaS라는 용어의 기준이 마련되었습니다. 시장도 커지고 있습니다. 가트너(Gartner)는 퍼블릭 클라우드 PaaS 부문의 최종 사용자 지출이 2025년 2086억 달러로 전년보다 21.6% 늘어날 것으로 전망했습니다.⁴
- Salesforce, salesforce.com Signs Definitive Agreement to Acquire Heroku, 2010
- Google, Introducing Google App Engine + our new blog, 2008
- Gartner, Gartner Forecasts Worldwide Public Cloud End-User Spending to Total $723 Billion in 2025, 2024
PaaS 구성 요소와 과금 방식
사용자는 GitHub 같은 원격 코드 저장소를 플랫폼에 연결하거나 로컬 PC의 코드를 명령어 한 줄로 플랫폼에 올려 애플리케이션을 배포합니다. 이 과정을 뒷받침하는 구성 요소와 요금이 매겨지는 방식을 나눠 살펴보겠습니다.
① PaaS 구성 요소 5가지
PaaS의 구성 요소는 코드가 배포되어 실행되고 관찰되는 흐름을 따라 이어집니다.
[PaaS 구성 요소 연결 구조도]
배포 파이프라인의 테스트 단계는 PaaS에 따라 GitHub Actions 같은 외부 CI 도구로 구성하기도 합니다.
- 배포 파이프라인(CI/CD): 코드 변경을 자동으로 빌드·테스트·배포하는 흐름입니다. 원격 코드 저장소에 코드를 올리거나 CLI로 직접 배포하면 새 버전이 실행 환경에 반영됩니다.
- 런타임: 코드를 실행하는 언어 환경입니다. Java·Python·Node.js처럼 PaaS 제공자가 지원하는 언어와 버전 가운데 하나를 골라 씁니다.
- 미들웨어: 애플리케이션과 운영체제 사이에서 웹 요청 처리·메시지 전달 같은 공통 기능을 맡는 소프트웨어입니다. 최종 사용자의 요청을 받아 애플리케이션에 전달합니다.
- 관리형 데이터베이스: PaaS 제공자가 설치·백업·패치를 맡는 데이터베이스입니다. 사용자는 데이터 구조 설계와 쿼리에 집중합니다.
- 모니터링·로깅: 실행 환경과 데이터베이스의 상태·오류·응답 시간을 기록하고 보여 주는 도구입니다. 장애가 생기면 개발자(PaaS 사용자)에게 알리고 원인을 추적하는 출발점이 됩니다.
② PaaS 과금 방식: 사용량 기반·플랜 정액제
PaaS 요금은 제공자와 상품마다 기준이 다르지만 대체로 두 방식으로 나뉩니다.
- 사용량 기반: 애플리케이션이 실행된 시간, 할당한 메모리·CPU 크기, 처리한 요청 수에 따라 요금을 냅니다. 요청이 없을 때 실행 인스턴스를 0개까지 줄여 요금이 거의 나오지 않게 하는 상품도 있습니다.
- 플랜 정액제: 정해진 사양의 실행 환경을 월 단위 고정 요금으로 씁니다. 비용 예측이 쉬운 대신 사양을 넘는 트래픽을 처리하려면 상위 플랜으로 올려야 합니다.
실행 환경 요금과 별도로 관리형 데이터베이스·스토리지·데이터 전송량에도 요금이 붙는 경우가 많습니다. 일부 제공자는 소규모 사용을 위한 무료 구간을 둡니다.
PaaS 활용 사례 3가지
① 웹 서비스·MVP 빠른 출시
MVP(Minimum Viable Product, 최소 기능 제품)는 시장 반응을 확인하려고 핵심 기능만 담아 만드는 첫 버전입니다. 이 단계에서는 인프라 구성보다 출시 속도가 중요합니다. PaaS를 쓰면 서버 구성 없이 코드를 배포해 바로 서비스를 열 수 있습니다. 반응이 좋으면 같은 환경에서 사양만 올려 운영을 이어 갈 수 있습니다.
② API·백엔드 서버 운영 자동화
모바일 앱이나 웹 프런트엔드는 데이터를 주고받을 백엔드 API 서버가 필요합니다. API 서버는 기능이 자주 추가되는 만큼 배포도 잦습니다. PaaS의 배포 파이프라인을 사용하면 코드를 저장소에 올리는 것만으로도 테스트와 배포가 이어집니다. 운영체제 패치는 제공자가 맡기 때문에 작은 팀도 백엔드 운영 부담을 줄일 수 있습니다.
③ 트래픽 변동이 큰 서비스의 자동 확장(오토스케일링)
이벤트 페이지나 캠페인 사이트처럼 특정 기간에 접속이 몰리는 서비스에서는 PaaS의 자동 확장 기능이 효과를 보입니다. PaaS는 오토스케일링을 플랫폼 기능으로 제공하는 경우가 많아, 사용자는 최소·최대 인스턴스 수 같은 조건만 정하면 됩니다. 행사가 끝나면 인스턴스 수가 다시 줄어 남는 자원에 드는 비용도 아낄 수 있습니다.
PaaS 장단점과 도입 시 고려사항
| 구분 | 내용 |
|---|---|
| 장점 | 서버와 운영체제 관리 없이 코드 배포로 서비스를 시작합니다. |
| 배포·확장·모니터링 기능이 플랫폼에 포함되어 개발 속도가 빨라집니다. | |
| 운영체제 패치와 런타임 관리를 제공자가 맡아 운영 인력 부담이 줄어듭니다. | |
| 단점 | 제공자가 지원하는 언어·버전·설정 범위 안에서만 개발할 수 있습니다. |
| 제공자 전용 기능을 많이 쓰면 다른 환경으로 옮기기 어려워집니다. | |
| 사용량이 커지면 같은 규모의 서버를 직접 운영할 때보다 비용이 높아질 수 있습니다. |
PaaS가 모든 상황에 맞는 선택은 아닙니다. 운영체제 커널 설정을 바꾸거나 플랫폼이 지원하지 않는 소프트웨어를 설치해야 한다면 PaaS로는 구현하기 어렵습니다. 반대로 Java·Python처럼 널리 쓰는 언어로 만든 웹 서비스나 API를 작은 팀이 빠르게 운영해야 한다면 PaaS가 적절합니다. 도입을 검토한다면 아래 네 가지 지점을 확인해 보세요.
① 지원 언어·런타임: 버전 지원 범위 확인
지원 언어·런타임은 PaaS가 실행해 주는 프로그래밍 언어와 그 버전의 범위입니다. 목록에 없는 언어나 버전은 기본 환경에서 실행할 수 없습니다.
- 현재 쓰는 언어·프레임워크 버전이 지원 목록에 있는지 여부
- 버전 지원 종료 공지 시점과 업그레이드 유예 기간
- 컨테이너 이미지 배포 지원 여부, 이미지 안 운영체제 패키지·런타임 업데이트의 담당 주체
② 벤더 종속(lock-in): 이전 가능성 확인
벤더 종속은 특정 제공자의 고유 기능에 묶여 다른 환경으로 옮기기 어려워지는 상태입니다. PaaS는 편의 기능이 많은 만큼 종속이 생기기 쉽습니다.
- 사용 중인 제공자 전용 기능 목록(데이터베이스·메시지 큐·인증 등)
- 데이터를 표준 형식으로 내보낼 수 있는지 여부
- 컨테이너 같은 표준 형식으로 다른 환경에서도 실행할 수 있는지 여부
③ 공동 책임 모델: 보안 책임 범위 확인
공동 책임 모델(Shared Responsibility Model)은 클라우드의 보안과 운영 책임을 제공자와 사용자가 계층별로 나눠 맡는 원칙입니다. PaaS에서 사용자는 배포한 애플리케이션과 실행 환경의 일부 설정을 통제합니다¹. 운영체제와 런타임 패치는 제공자가 맡지만 애플리케이션 코드의 취약점·접근 권한·데이터 보호는 사용자가 책임집니다.
- 제공자 책임 분담 문서에 적힌 런타임 위 계층의 책임 범위
- 코드에 쓴 외부 라이브러리의 보안 업데이트 담당자
- API 키·데이터베이스 비밀번호의 보관 위치(코드가 아닌 환경 변수나 비밀 관리 기능)
④ 오토스케일링 요금: 확장 상한과 과금 기준 확인
오토스케일링은 트래픽에 따라 실행 인스턴스 수를 자동으로 조절하는 기능입니다. 편리한 만큼 상한을 정하지 않으면 예상치 못한 트래픽이 그대로 요금으로 이어질 수 있습니다.
- 최대 인스턴스 수·월 예산 한도 설정 가능 여부
- 과금 기준(실행 시간·요청 수·할당 사양)
- 요청이 없는 유휴 시간의 최소 인스턴스 요금 부과 여부
PaaS 장단점과 도입 시 고려사항
PaaS는 서버 대신 애플리케이션을 실행하는 플랫폼을 빌려 쓰는 방식입니다. 제공자는 네트워크부터 운영체제와 런타임까지 책임지고 사용자는 애플리케이션과 데이터만 직접 운영합니다. 덕분에 개발팀은 인프라 작업을 줄이고 코드 배포와 서비스 개선에 시간을 쓸 수 있습니다.
다만 PaaS에서는 플랫폼이 정한 범위 안에서 개발해야 하는 한계도 있습니다. 도입 전에 지원 런타임과 이전 가능성을 확인하고 오토스케일링 요금 상한을 정해 두세요. PaaS로 서비스를 빠르고 안정적이게 운영할 수 있습니다.
| FAQ
PaaS와 IaaS의 가장 큰 차이는 무엇인가요?
가장 큰 차이는 운영체제와 런타임을 누가 관리하느냐입니다.
IaaS에서는 제공자가 가상 서버까지 제공하고 사용자가 운영체제를 설치해 관리합니다. PaaS에서는 운영체제와 런타임까지 제공자가 관리하고 사용자는 애플리케이션 코드와 데이터만 다룹니다. 그래서 IaaS는 환경을 자유롭게 구성할 수 있고 PaaS는 운영 부담이 적습니다. 서버 설정을 직접 바꿔야 하면 IaaS가, 코드 배포에 집중하려면 PaaS가 적합합니다.
PaaS를 쓰면 서버 관리가 전혀 필요 없나요?
서버와 운영체제 관리는 필요 없지만 애플리케이션 운영은 여전히 사용자 몫입니다.
PaaS에서 제공자는 서버·운영체제·런타임의 설치와 패치를 맡습니다. 사용자는 애플리케이션 코드의 품질과 보안, 데이터 관리, 인스턴스 수 같은 실행 설정을 관리해야 합니다. 장애가 나면 모니터링 도구로 원인이 코드에 있는지 확인하는 일도 사용자가 합니다. 서버 관리가 사라지는 것이지 운영 자체가 사라지는 것은 아닙니다.
서버리스(FaaS)는 PaaS에 속하나요?
서버리스는 서버 관리를 제공자에게 맡긴다는 점에서 PaaS와 같지만 실행 단위가 함수라는 점이 다릅니다.
FaaS(Function as a Service)는 애플리케이션 전체가 아니라 함수 단위의 코드를 이벤트가 발생할 때만 실행하는 방식입니다. 사용자가 서버를 관리하지 않는다는 점은 PaaS와 같습니다. 다만 FaaS는 요청이 없으면 실행 자체가 없고 실행 횟수와 시간 기준으로 요금을 매기는 경우가 많습니다. 자료에 따라 PaaS의 한 형태로 보기도 하고 별도 모델로 분류하기도 합니다.
PaaS로 운영하던 앱을 다른 클라우드로 옮길 수 있나요?
옮길 수 있지만 난이도는 제공자 전용 기능을 얼마나 썼는지에 따라 달라집니다.
표준 언어와 오픈소스 데이터베이스만 쓴 애플리케이션은 비교적 쉽게 옮겨집니다. 반면 제공자 전용 데이터베이스·인증·메시지 기능을 깊이 쓰면 해당 부분을 새 환경에 맞게 다시 개발해야 합니다. 애플리케이션을 컨테이너로 패키징해 두면 다른 환경에서도 비슷한 방식으로 실행할 수 있습니다. 도입 단계부터 전용 기능 사용 목록을 관리하는 것이 좋습니다.
PaaS 비용은 어떻게 계산되나요?
PaaS 비용은 실행 환경 요금에 데이터베이스·스토리지·전송량 같은 부가 서비스 요금을 더해 계산합니다.
실행 환경 요금은 사용량 기반이면 실행 시간·할당 사양·요청 수로, 플랜 정액제면 월 고정 금액으로 정해집니다. 관리형 데이터베이스와 스토리지는 대개 용량과 사양에 따라 별도로 과금됩니다. 오토스케일링을 쓰면 트래픽에 따라 인스턴스 수가 바뀌므로 최대 인스턴스 수를 기준으로 상한 비용을 함께 계산해 두는 것이 안전합니다.
오토스케일링이란 무엇인가요?
오토스케일링은 트래픽에 따라 애플리케이션을 실행하는 인스턴스 수를 자동으로 늘리고 줄이는 기능입니다.
인스턴스는 애플리케이션을 실행하는 서버나 컨테이너 한 개를 말합니다. CPU 사용률이나 요청 수가 사용자가 정한 기준치를 넘으면 인스턴스를 늘리고, 기준치 아래로 내려가면 줄입니다. PaaS는 이 기능을 기본으로 제공하는 경우가 많아 최소·최대 인스턴스 수를 정하면 됩니다. 다만 최대 인스턴스 수를 정하지 않으면 트래픽이 몰릴 때 요금이 예상보다 커질 수 있습니다.