---
term: 'IaaS vs. PaaS vs. CaaS vs. FaaS vs. BaaS vs. mBaaS vs. SaaS'
seoTitle: 'IaaS vs PaaS vs SaaS 차이: 7가지 클라우드 모델 비교'
headline: '클라우드 서비스 모델 비교: IaaS, PaaS, CaaS, FaaS, BaaS, mBaaS, SaaS'
slug: iaas-paas-baas-faas
category: cloud-architecture
shortDefinition: '클라우드 서비스 모델은 제공업체가 얼마나 많은 부분을 대신 운영하느냐에 따라 IaaS, CaaS, PaaS, FaaS, BaaS, mBaaS, SaaS 순으로 늘어선 사다리입니다.'
relatedTerms:
  - infrastructure-as-a-service
  - paas-vs-baas
  - baas-vs-serverless
  - mbaas-vs-baas
  - baas-vs-custom-backend
  - serverless-architecture
  - containerization
contrastsWith:
  - paas-vs-baas
aboutTerms:
  - 'Infrastructure-as-a-Service (IaaS)'
  - 'Containers-as-a-Service (CaaS)'
  - 'Platform-as-a-Service (PaaS)'
  - 'Functions-as-a-Service (FaaS)'
  - 'Backend-as-a-Service (BaaS)'
  - 'Mobile Backend-as-a-Service (mBaaS)'
  - 'Software-as-a-Service (SaaS)'
faq:
  - question: 'IaaS, PaaS, SaaS의 핵심 차이는 무엇입니까?'
    answer: '누가 무엇을 관리하느냐의 차이입니다. IaaS는 가상 머신, 스토리지, 네트워크 같은 인프라를 빌려주며, 운영체제부터 그 위는 전부 사용자의 몫입니다. PaaS는 관리형 플랫폼을 빌려줍니다. 사용자는 애플리케이션 코드와 데이터만 가져오고, 나머지는 제공업체가 운영합니다. SaaS는 완성된 소프트웨어를 제공하므로 그냥 사용하면 됩니다. 사다리를 한 단 오를 때마다 제어권을 내주는 대신 속도를 얻고 운영 부담을 줄입니다.'
  - question: 'CaaS, FaaS, BaaS는 IaaS와 SaaS 사이 어디에 위치합니까?'
    answer: '고전적인 세 모델이 건너뛴 단에 있습니다. CaaS는 IaaS와 PaaS 사이에 있습니다. 사용자는 컨테이너를 넘기고, 제공업체가 오케스트레이션을 운영합니다. FaaS는 PaaS 위에 있습니다. 사용자는 개별 함수를 넘기고, 함수는 이벤트마다 실행됩니다. BaaS는 프로그래밍 가능성을 유지하면서 가장 멀리 나아갑니다. 데이터베이스, 인증, 스토리지, API 등 백엔드 자체가 미리 구축되어 있어 표준 기능에는 서버 측 코드가 전혀 필요 없습니다.'
  - question: 'BaaS는 Backend-as-a-Service입니까, Backup-as-a-Service입니까?'
    answer: '애플리케이션 개발에서 BaaS는 거의 항상 Backend-as-a-Service, 즉 SDK를 통해 사용하는 미리 구축된 앱 백엔드를 뜻합니다. 일부 엔터프라이즈 스토리지 분야에서는 같은 약어를 Backup-as-a-Service, 즉 관리형 데이터 백업이라는 전혀 다른 의미로 씁니다. 모바일 앱, API, 앱 플랫폼이 논의되는 자리라면 BaaS는 백엔드로 읽으면 됩니다. 문맥이 의미를 정하며, 이 페이지는 백엔드 쪽 의미를 다룹니다.'
  - question: 'CaaS와 PaaS의 차이는 무엇입니까?'
    answer: '제공업체에 넘기는 단위가 다릅니다. CaaS에서는 컨테이너를 넘깁니다. 언어와 스택에 제약이 없고 패키징 방식도 자유로우며, 오케스트레이션에 관한 선택권은 사용자가 유지합니다. PaaS에서는 애플리케이션 코드를 넘기고, 더 단순한 푸시 즉시 배포 워크플로를 얻는 대신 플랫폼이 지원하는 런타임과 관례를 받아들입니다. CaaS는 마이크로서비스와 다중 언어 스택에, PaaS는 가장 적은 절차를 원하는 표준 앱에 맞습니다.'
  - question: 'FaaS는 서버리스와 같은 말입니까?'
    answer: 'FaaS는 서버리스의 절반이지, 동의어가 아닙니다. martinfowler.com에 실린 Mike Roberts의 정의, 즉 표준으로 통하는 정의는 서버리스를 FaaS(주문형으로 실행되는 사용자의 함수)와 BaaS(미리 구축된 백엔드 서비스)를 모두 아우르는 상위 개념으로 봅니다. 일상적으로는 "서버리스"가 FaaS만을 가리키는 경우가 많아서 두 용어가 뒤섞입니다.'
  - question: 'BaaS와 mBaaS의 차이는 무엇입니까?'
    answer: 'mBaaS는 이 범주가 시작된 곳입니다. 푸시 알림, 기기를 인식하는 SDK, 오프라인 동기화를 핵심 기능으로 갖추고 모바일 앱을 겨냥해 미리 구축된 백엔드였습니다. 웹 앱 역시 클라이언트 중심으로 바뀌면서 모델이 일반화되었고 m이 떨어져 나갔습니다. 오늘날 제대로 된 mBaaS는 모두 웹도 똑같이 지원하므로, 두 용어는 대체로 같은 플랫폼을 강조점만 달리해 부르는 이름입니다.'
  - question: '가장 저렴한 클라우드 서비스 모델은 무엇입니까?'
    answer: '모델이 아니라 워크로드의 형태에 달려 있습니다. FaaS는 유휴 비용이 0이므로 트래픽이 간헐적이거나 적을 때 가장 저렴하고, 지속적인 고부하에서는 비쌉니다. IaaS는 크고 안정적인 규모에서 순수 단위 가격이 가장 좋지만, 이를 운영할 팀이라는 숨은 비용이 따라옵니다. CaaS, PaaS, BaaS는 그 사이에서 플랫폼 마진을 내는 대신 엔지니어링 시간을 없애 주는데, 소규모 팀에는 보통 그 시간이 가장 큰 비용입니다.'
  - question: '여러 서비스 모델을 함께 사용할 수 있습니까?'
    answer: '실제 기업은 거의 모두 그렇게 합니다. 전형적인 구성은 업무 도구는 SaaS, 제품 운영은 BaaS 또는 PaaS, 이벤트 기반 연결 작업은 FaaS, 오케스트레이션 제어가 필요한 컨테이너 서비스는 CaaS, 드물게 있는 특수 워크로드는 IaaS입니다. 각 모델은 워크로드를 하나씩 올려놓는 단이며, 실무에서 필요한 역량은 워크로드마다 충분하면서도 가장 저렴한 단을 찾아 짝지어 주는 일입니다.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'The NIST Definition of Cloud Computing (SP 800-145)'
    url: 'https://csrc.nist.gov/pubs/sp/800/145/final'
  - name: 'Serverless Architectures — Mike Roberts (martinfowler.com)'
    url: 'https://martinfowler.com/articles/serverless.html'
  - name: 'As a service (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/As_a_service'
  - name: 'Kubernetes documentation — overview'
    url: 'https://kubernetes.io/docs/concepts/overview/'
  - name: 'Back4app Cloud Code documentation'
    url: 'https://www.back4app.com/docs/get-started/cloud-functions'
cta:
  title: '사다리의 맨 위에서 시작하기'
  text: 'Back4app은 첫날부터 BaaS 단에 올려 줍니다. 데이터베이스, 인증, 스토리지, API가 미리 구축되어 있고, FaaS 단이 필요할 때는 Cloud Code 함수가 있습니다. 오픈소스 위에 구축되어 있어 사다리를 다시 내려오는 길도 열려 있습니다.'
  linkText: '무료로 시작하기'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-26'
translationKey: iaas-paas-baas-faas
---

**클라우드 서비스 모델은 제공업체가 얼마나 많은 부분을 대신 운영하느냐에 따라 IaaS, CaaS, PaaS, FaaS, BaaS, mBaaS, SaaS 순으로 늘어선 사다리입니다.** 모든 "aaS"는 같은 질문에 선 하나를 서로 다른 높이에 그어 답합니다. *이 선 위는 사용자가 만들고, 아래는 우리가 운영합니다.* 대부분의 해설은 NIST 정의가 공식화한 고전적인 세 모델(IaaS, PaaS, SaaS)에서 멈추고, 현대의 제품이 실제로 자리 잡은 단은 건너뜁니다. 이 가이드는 일곱 모델을 모두 다루며, 각각을 제대로 정의한 뒤 실제로 혼동하기 쉬운 쌍을 비교합니다. 단을 고르는 순간, 팀이 평생 유지보수할 대상도 함께 고른 셈입니다.

## 핵심 요약

| 질문 | 답 |
| --- | --- |
| 한 줄로 보는 사다리 | IaaS: 머신 임대 · CaaS: 오케스트레이션 임대 · PaaS: 플랫폼 임대 · FaaS: 함수 실행 단위 임대 · BaaS: 백엔드 임대 · mBaaS: 모바일 백엔드 임대 · SaaS: 완성된 앱 임대 |
| 진짜 변수 | 사용자 관리 / 제공업체 관리를 가르는 선의 위치 |
| 배포 단위 | VM → 컨테이너 → 애플리케이션 → 함수 → 데이터 모델 → 없음 |
| 서버리스는? | FaaS와 BaaS를 *모두* 아우르는 상위 개념이지, 별도의 단이 아님 |
| 어느 것이 최선인가 | 잘못된 질문. 워크로드마다 충분하면서 가장 저렴한 단을 짝지어야 함 |
| 추세 | 팀들은 해마다 사다리의 더 높은 단에서 출발함 |

## 각 단에서 "백엔드를 띄운다"는 말의 의미

```bash
# 같은 작업(요청을 처리하는 백엔드 띄우기)을 한 단씩 올라가며 비교
# IaaS – 머신을 받습니다:
$ ssh admin@vm-01              # 그다음: 설치, 설정, 패치, 확장, 모니터링…
# CaaS – 오케스트레이션을 받습니다:
$ docker push registry/api:v1  # 컨테이너는 사용자 몫, 스케줄러·네트워킹·확장은 제공업체 몫
# PaaS – 플랫폼을 받습니다:
$ git push platform main       # 앱 코드는 사용자 몫, 서버·런타임·확장은 제공업체 몫
# FaaS – 이벤트 단위 런타임을 받습니다:
$ deploy functions/api.js      # 함수는 사용자 몫, 주문형 실행과 0으로의 축소는 제공업체 몫
# BaaS / mBaaS – 백엔드 자체를 받습니다:
#   배포할 것 없음 – 인증, 데이터베이스, API가 이미 실행 중
# SaaS – 완성된 제품을 받습니다:
#   만들 것 없음 – 로그인해서 사용하면 끝
```

BaaS 단은 증명이 필요합니다. "배포할 것이 없다"는 말은 마케팅처럼 들리기 때문입니다. 스키마, API, 접근 제어, 확장이 모두 제공업체 쪽에 있는 프로덕션 백엔드에 주문 하나를 저장하는 일은 클라이언트 측 호출 한 번이면 됩니다:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
const order = new Parse.Object('Order');
order.set('total', 129.9);
order.set('status', 'paid');
await order.save(); // schema, API, auth, scaling: all the rungs below you
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
final order = ParseObject('Order')
  ..set('total', 129.9)
  ..set('status', 'paid');
await order.save(); // schema, API, auth, scaling handled below you
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
var order = Order()
order.total = 129.9
order.status = "paid"
order.save { result in
  if case .success = result {
    print("saved — the platform ran every layer underneath")
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
val order = ParseObject("Order").apply {
  put("total", 129.9)
  put("status", "paid")
}
order.saveInBackground { e ->
  if (e == null) Log.d("Order", "saved — platform ran every layer underneath")
}
```

## 한 사다리 위의 일곱 모델

```mermaid
flowchart LR
  accTitle: 일곱 단으로 이루어진 as-a-service 사다리
  accDescr: 온프레미스에서 IaaS, CaaS, PaaS, FaaS, 그리고 모바일 특화형 mBaaS를 포함한 BaaS를 거쳐 SaaS까지 여덟 단계이며, 단계마다 제공업체에서 더 많은 것을 빌립니다. 머신, 컨테이너 오케스트레이션, 플랫폼, 실행 단위 함수, 백엔드, 마지막으로 완성된 애플리케이션 순입니다.
  A["온프레미스"] --> B["IaaS<br/>머신 임대"]
  B --> C["CaaS<br/>오케스트레이션 임대"]
  C --> D["PaaS<br/>플랫폼 임대"]
  D --> E["FaaS<br/>함수 실행 단위 임대"]
  E --> F["BaaS · mBaaS<br/>백엔드 임대"]
  F --> G["SaaS<br/>완성된 앱 임대"]
```

[NIST의 클라우드 컴퓨팅 정의](https://csrc.nist.gov/pubs/sp/800/145/final)는 2011년에 고전적인 세 단을 공식화했습니다. IaaS("처리, 스토리지, 네트워크를 프로비저닝"), PaaS("제공업체가 지원하는 도구로 사용자가 만든 애플리케이션을 배포"), SaaS("제공업체의 애플리케이션을 사용")가 그것이며, CaaS, FaaS, BaaS가 범주로 존재하기 전의 일입니다. 새로운 단들은 NIST가 남긴 빈자리에 들어갑니다. CaaS는 IaaS와 PaaS 사이에, FaaS와 BaaS는 PaaS와 SaaS 사이에 자리하며, 여전히 프로그래밍 가능하지만 프로그램 가운데 사용자의 몫은 점점 줄어듭니다.

## 누가 무엇을 관리하는가: 책임 매트릭스

주제 전체가 표 하나에 담겨 있습니다. 열을 위에서 아래로 읽으면 각 모델이 사용자의 몫으로 남기는 것이 보입니다:

| 계층 | 온프레미스 | IaaS | CaaS | PaaS | FaaS | BaaS / mBaaS | SaaS |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 비즈니스 로직 | 사용자 | 사용자 | 사용자 | 사용자 | 사용자(함수 형태) | 커스텀 로직만 | 제공업체 |
| 백엔드 기능(인증, CRUD, 스토리지, 푸시) | 사용자 | 사용자 | 사용자 | 사용자 | 사용자 | **제공업체** | 제공업체 |
| 앱 패키징 및 런타임 | 사용자 | 사용자 | 사용자(컨테이너) | 제공업체 | 제공업체 | 제공업체 | 제공업체 |
| 오케스트레이션 및 확장 | 사용자 | 사용자 | **제공업체** | 제공업체 | 제공업체(0까지) | 제공업체 | 제공업체 |
| OS 및 패치 | 사용자 | 사용자 | 제공업체 | 제공업체 | 제공업체 | 제공업체 | 제공업체 |
| 서버, 네트워크, 하드웨어 | 사용자 | **제공업체** | 제공업체 | 제공업체 | 제공업체 | 제공업체 | 제공업체 |
| 데이터 및 접근 정책 | 사용자 | 사용자 | 사용자 | 사용자 | 사용자 | 사용자 | **여전히 사용자** |

글로만 설명하면 잘 드러나지 않지만 이 매트릭스로 보면 분명해지는 것이 두 가지 있습니다. 맨 아래 행은 결코 넘어가지 않습니다. 데이터와 ID 관리 관행은 SaaS를 포함한 모든 단에서 사용자의 몫입니다. 그리고 각 모델의 이름은 "제공업체"가 시작되는 가장 높은 계층을 가리킬 뿐입니다.

## IaaS(Infrastructure-as-a-Service)란?

IaaS는 머신, 블록 스토리지, 네트워크 같은 가상화된 인프라를 시간 단위로 빌려줍니다. 하이퍼바이저 위는 전부 사용자의 몫입니다. 운영체제, 패치, 런타임, 확장 로직, 그리고 새벽 3시의 장애 호출까지. 최대의 제어권과 최대의 운영 범위를 가진 단이며, [IaaS 항목](/glossary/ko/infrastructure-as-a-service/)에서 자세히 다룹니다.

| | IaaS 프로필 |
| --- | --- |
| 배포하는 것 | 가상 머신과 그 위의 모든 것 |
| 제공업체가 운영하는 것 | 물리 하드웨어, 가상화, 네트워크 패브릭 |
| 요금 형태 | 리소스 시간당, 사용 여부와 무관 |
| 선택할 때 | 특수 하드웨어/런타임, 엄격한 인프라 제어, 리프트 앤 시프트 |
| 떠날 때 | 운영 인력 비용이 제어권의 가치를 넘어설 때 |

이 단을 제대로 평가하려면 운영 2일차(Day 2)가 어떤 모습인지 보면 됩니다. IaaS의 2일차는 OS 패치 시간대, 커널 업그레이드, 디스크 용량 경보, 보안 그룹 감사, 용량 계획, 그리고 더 높은 모든 단이 기본으로 제공하는 모니터링을 직접 구축하는 일로 채워집니다. 그중 어느 것도 사용자의 제품이 아닙니다. 이 단이 제값을 하는 상황은 정확히 세 가지입니다. 어떤 플랫폼도 제공하지 않는 하드웨어나 런타임, 인프라 제어를 의무화하는 규제 체계, 그리고 운영 팀의 비용까지 계산한 *뒤에도* 순수 단위 가격이 관리형 마진을 이길 만큼 크고 지속적인 규모입니다. 마지막 조건의 문턱은 대부분의 팀이 짐작하는 것보다 훨씬 높습니다.

## CaaS(Containers-as-a-Service)란?

CaaS는 대부분의 해설이 건너뛰는 계층을 빌려줍니다. 사용자는 언어와 스택에 관계없이 서비스를 [컨테이너](/glossary/ko/containerization/)로 패키징하고, 제공업체는 스케줄러, 서비스 네트워킹, 확장 장치를 운영합니다. 보통 [Kubernetes](/glossary/ko/kubernetes/)나 그에 준하는 것입니다. 이 단은 의도적으로 IaaS와 PaaS 사이에 놓여 있습니다. 머신보다 추상적이고, 플랫폼보다 덜 규범적입니다. 그래서 PaaS의 관례와 마찰을 빚을 [마이크로서비스](/glossary/ko/microservices-vs-monolith/)와 다중 언어 환경에 자연스러운 보금자리가 됩니다.

| | CaaS 프로필 |
| --- | --- |
| 배포하는 것 | 컨테이너 이미지, 배포 매니페스트 |
| 제공업체가 운영하는 것 | 오케스트레이션 컨트롤 플레인, 노드, 네트워킹 |
| 요금 형태 | 노드/클러스터당 또는 실행 중인 컨테이너당 |
| 선택할 때 | 마이크로서비스, 다중 언어 스택, 클러스터 운영 없이 오케스트레이션 제어가 필요할 때 |
| 떠날 때 | 표준 앱 하나뿐일 때. PaaS나 BaaS로 더 단순하게 같은 결과를 낼 수 있음 |

CaaS를 호스팅된 [Kubernetes](/glossary/ko/kubernetes/) 튜토리얼과 구분하는 미묘한 지점은 이것입니다. 넘어가는 것은 스케줄러, etcd, API 서버, 노드 상태 같은 *컨트롤 플레인*이고, 이미지와 매니페스트로 표현되는 모든 것, 즉 베이스 이미지 위생, 리소스 요청량, 라이브니스 프로브, 배포 전략, 서비스 토폴로지는 사용자의 몫으로 남습니다. 이는 엄연한 하나의 전문 분야이며, 바로 그래서 이 단이 별도의 상품으로 존재합니다. 그런 표현력은 필요하지만 그 아래의 장치를 직접 운영할 생각은 없는 팀을 위한 것입니다. 이식성은 컨테이너 자체가 담보합니다. 같은 이미지가 표준을 따르는 어떤 오케스트레이터에서도 실행되므로, CaaS는 사다리에서 벤더 종속이 가장 약한 단에 속합니다.

## PaaS(Platform-as-a-Service)란?

PaaS는 관리형 애플리케이션 플랫폼을 빌려줍니다. 사용자가 코드를 푸시하면 제공업체가 그 아래의 런타임, 확장, 운영체제를 제공합니다. 절차 대신 관례를 받아들이는 거래입니다. `git push` 배포를 얻는 대가로 지원되는 언어와 플랫폼의 관용구를 따릅니다. PaaS가 없애 주지 *않는* 결정적인 것은 이것입니다. 인증, 엔드포인트, 검증 등 백엔드 애플리케이션 전체를 여전히 사용자가 작성하고 소유합니다. 이 구분은 [PaaS vs. BaaS 항목](/glossary/ko/paas-vs-baas/)에서 자세히 분석합니다.

| | PaaS 프로필 |
| --- | --- |
| 배포하는 것 | 애플리케이션 코드 |
| 제공업체가 운영하는 것 | 런타임, OS, 서버, 확장 |
| 요금 형태 | 인스턴스/등급당 |
| 선택할 때 | 백엔드 로직이 곧 제품인 커스텀 서버 앱 |
| 떠날 때 | BaaS가 이미 제공하는 표준 백엔드 기능을 직접 작성하고 있을 때 |

PaaS 계약은 한 세대의 좋은 습관을 빚어냈습니다. 12-factor 앱, 환경 변수에 담긴 설정, 무상태 프로세스, 스트림으로서의 로그가 그것인데, 이전에는 조언에 불과했던 것을 플랫폼이 *강제하기* 때문입니다. 그 경계 역시 시사하는 바가 큽니다. 플랫폼은 애플리케이션을 실행하지만 그 안에 무엇이 있는지는 전혀 모르므로, [세션](/glossary/ko/session-management/), 권한, 마이그레이션, [속도 제한](/glossary/ko/api-rate-limiting-throttling/) 같은 모든 백엔드 관심사는 여전히 사용자가 작성하고 테스트하고 패치하는 코드입니다. 잘못된 단에 있다는 신호가 바로 여기서 나옵니다. PaaS에 올린 코드베이스의 대부분이 사용자 관리, CRUD, 파일 업로드를 다시 구현하고 있다면, 한 단 위를 손으로 짓고 있는 것입니다.

## FaaS(Functions-as-a-Service)란?

FaaS는 컴퓨팅을 이벤트 단위로 빌려줍니다. 사용자는 개별 함수를 배포하고, 제공업체는 호출마다 주문형으로 실행한 뒤 호출 사이에는 0으로 축소(scale to zero)합니다. [서버리스 컴퓨팅](/glossary/ko/serverless-architecture/)의 가장 순수한 형태입니다. 무슨 일이 일어나기 전까지는 아무것도 실행되지 않고 아무것도 과금되지 않습니다. 비용은 아키텍처에서 치릅니다. [콜드 스타트](/glossary/ko/serverless-cold-starts/), 실행 제한, 그리고 모든 영속성을 다른 곳으로 밀어내는 무상태성입니다. 함수가 직접 운영하는 서비스 집합과 어떻게 비교되는지는 [함수 vs. 마이크로서비스](/glossary/ko/serverless-functions-vs-microservices/) 항목의 질문입니다.

| | FaaS 프로필 |
| --- | --- |
| 배포하는 것 | 개별 함수 |
| 제공업체가 운영하는 것 | 나머지 전부, 호출 단위로 |
| 요금 형태 | 호출 횟수 + 실행 시간, 유휴 = 0 |
| 선택할 때 | 이벤트 기반 작업: 웹훅, 작업, 파이프라인, 연결 로직 |
| 떠날 때 | 지속적인 고부하. 호출당 요금이 오히려 불리해짐 |

무상태성이 구조를 떠받치는 제약입니다. 함수는 어떤 호출 뒤에도 파괴될 수 있으므로 세션, 파일, 큐, 데이터 등 오래 남아야 하는 모든 것은 함수 *주변의* 서비스에 있어야 합니다. 이 제약을 끝까지 따라가면 조용히 BaaS가 조립됩니다. 로직은 함수에, 상태가 있는 모든 것은 관리형 서비스에 두는 구조입니다. 두 단이 실무에서 수렴한 이유, 그리고 자체 오케스트레이션 위에서 이벤트 단위 모델을 원하는 팀을 위해 오픈소스 런타임(Knative, OpenFaaS)이 존재하는 이유가 여기 있습니다. 요금도 같은 이벤트 형태의 논리를 따릅니다. 유휴 시 무료는 간헐적 트래픽에는 당할 상대가 없고 꾸준한 부하에는 가혹합니다. 모든 FaaS 청구서가 결국 가르쳐 주는 역전입니다.

## BaaS(Backend-as-a-Service)란?

BaaS는 백엔드 자체를 빌려줍니다. 데이터베이스, [인증](/glossary/ko/authentication-vs-authorization/), 파일 스토리지, [자동 생성 API](/glossary/ko/auto-generated-database-apis/), 푸시 알림이 미리 구축되고 관리되는 상태로 제공되며 [클라이언트 SDK](/glossary/ko/backend-sdk/)에서 사용합니다. 위의 코드 예제가 보여 주듯 표준 기능에는 작성할 서버 측 코드가 전혀 없습니다. 커스텀 로직은 내장된 [클라우드 함수](/glossary/ko/cloud-code-serverless-functions/)에서 실행되며, 그래서 성숙한 BaaS 플랫폼은 FaaS 단과 경쟁하기보다 그것을 품고 있습니다. 이 결정의 구축 대 구매 버전은 [별도 항목](/glossary/ko/baas-vs-custom-backend/)에 있고, 이 단의 솔직한 약점인 벤더 종속(vendor lock-in) 문제는 플랫폼이 [오픈소스인지 독점인지](/glossary/ko/open-source-vs-proprietary-baas/)에 달려 있습니다.

| | BaaS 프로필 |
| --- | --- |
| 배포하는 것 | 데이터 모델, 보안 규칙, 커스텀 함수. 그 외에는 없는 경우가 많음 |
| 제공업체가 운영하는 것 | SDK와 API 뒤의 표준 백엔드 전체 |
| 요금 형태 | 무료 등급 + 사용량/플랜 |
| 선택할 때 | 사용자, 데이터, 파일 같은 표준 앱 백엔드이고 속도가 중요할 때 |
| 떠날 때 | 백엔드 로직이 *곧* 제품이거나 요구사항이 표준에서 크게 벗어날 때 |

BaaS가 없애는 것은 *인프라와 보일러플레이트 코드*이지 엔지니어링이 아닙니다. [데이터 모델](/glossary/ko/data-modeling/), [보안 규칙](/glossary/ko/access-control-lists-acl/), 비즈니스 로직은 어떤 플랫폼도 대신 내려 주지 않는 결정으로 남습니다. 이 단의 경제성은 사다리에서 가장 뛰어납니다. 몇 분 만에 동작하는 백엔드, 거의 0에 가까운 초기 비용. 구조적 위험도 그만큼 큽니다. 독점 플랫폼에서는 데이터 스키마, 인증, 함수가 모두 벤더의 형태로 존재하므로, BaaS는 프로그래밍 가능한 단 가운데 벤더 종속이 가장 강합니다. 오픈소스 변형은 바로 그 점을 해소합니다. 같은 플랫폼을 직접 호스팅할 수 있다면 떠나는 일은 다시 짓기가 아니라 옮기기가 됩니다. AI 시대는 이 단의 수요층도 넓혔습니다. 생성된 프론트엔드에는 진짜 백엔드가 빨리 필요하고, 권한이 갖춰진 기성 백엔드가 그에 맞는 형태입니다.

## mBaaS(Mobile Backend-as-a-Service)란?

mBaaS는 BaaS 범주가 시작된 곳입니다. [푸시 알림](/glossary/ko/push-notifications-apns-fcm/), 기기를 인식하는 SDK, [오프라인 동기화](/glossary/ko/offline-first-data-sync/)를 부가 기능이 아닌 핵심 기능으로 갖추고 모바일 앱을 겨냥해 미리 구축된 백엔드였습니다. 단일 페이지 웹 앱 역시 클라이언트 중심이 되면서 모델이 일반화되었고 *m*은 조용히 떨어져 나갔습니다. 오늘날 제대로 된 플랫폼은 모두 같은 백엔드로 웹과 모바일을 함께 지원합니다. 이 구분이 여전히 의미 있는 경우와 그저 역사의 잔재인 경우는 [mBaaS vs. BaaS 항목](/glossary/ko/mbaas-vs-baas/)의 주제입니다.

| | mBaaS 프로필 |
| --- | --- |
| 배포하는 것 | BaaS와 동일, 모바일 네이티브 SDK를 통해 |
| 제공업체가 운영하는 것 | 백엔드에 더해 모바일 전용 요소: 푸시 게이트웨이, 기기 상태, 동기화 |
| 요금 형태 | BaaS와 동일 |
| 선택할 때 | 푸시, 오프라인, 기기별 상태에 의존하는 모바일 우선 제품 |
| 떠날 때 | BaaS와 별개로 떠날 일은 없음. 경쟁자가 아니라 특화형 |

*m*이 여전히 제 글자값을 하는 곳은 세 군데입니다. 푸시 알림은 API 호출 한 번이 아니라 플랫폼 게이트웨이(APNs, FCM)와의 관계입니다. 토큰 등록, 기기 타게팅, 전달 의미론까지 mBaaS급 플랫폼이 끝에서 끝까지 관리합니다. 오프라인 우선 동기화는 SDK가 얇은 HTTP 래퍼가 아니라 상태 머신이라는 뜻입니다. 로컬 영속성, 대기열에 쌓인 쓰기, 연결이 돌아왔을 때의 충돌 처리가 포함됩니다. 그리고 기기별 상태(설치, 채널, 세그먼트)는 웹 앱에는 아예 없는 데이터 모델입니다. 이 세 가지가 제품을 설명한다면 플랫폼의 모바일 혈통이 중요하고, 그렇지 않다면 BaaS와 mBaaS는 같은 구매입니다.

## SaaS(Software-as-a-Service)란?

SaaS는 완성된 소프트웨어를 빌려줍니다. 로그인해서 사용하면 됩니다. 사다리에서 유일하게 *위에 짓는* 것이 아니라 *소비하는* 단이며, 그래서 다른 단과 비교하는 일은 범주의 전환입니다. 앞의 여섯 모델은 "내 제품의 스택 가운데 얼마를 내가 운영하는가"에 답하고, SaaS는 "이것이 애초에 내 제품으로 존재해야 하는가"에 답합니다. CRM, 이메일, 분석 도구는 SaaS입니다. 도구 안에 사용자의 커스텀 로직이 필요해지는 순간 SaaS 단에서 떨어져 아래의 단이 필요해집니다.

| | SaaS 프로필 |
| --- | --- |
| 배포하는 것 | 없음. 설정만 함 |
| 제공업체가 운영하는 것 | 사용자의 데이터와 접근 정책을 제외한 전부 |
| 요금 형태 | 사용자(시트)당 월 요금 |
| 선택할 때 | 문제가 이미 제품화되어 있고 차별화 요소가 아닐 때 |
| 떠날 때 | 벤더의 로드맵에 없는 커스텀 동작이 필요할 때 |

이 비교에서 SaaS가 중요한 이유는 주로 *경계*로서입니다. 더 이상 프로그래밍할 것이 남지 않았을 때 "완전 관리형"이 어떤 모습인지 정의하며, 다른 모든 단이 20년 동안 올라온 방향이 바로 그곳입니다. 또한 구축용 단들이 내세울 수 있는 제안의 천장을 정합니다. BaaS가 "내 제품의 백엔드가 첫날부터 SaaS처럼 느껴진다"에 가까워질수록, 남는 엔지니어링은 정확히 차별화되는 부분이 됩니다. 의존이 그 대가입니다. 로드맵, 요금, 데이터 이식성은 선의 벤더 쪽에 있고, 사용자의 데이터와 접근 정책만이 결코 사용자 쪽을 떠나지 않는 행입니다.

## 사다리가 자라 온 과정

| 시기 | 등장한 것 | 추상화한 것 |
| --- | --- | --- |
| 2006–2009 | IaaS, 이어서 PaaS | 하드웨어 구매, 이어서 서버 운영 |
| 2011 | NIST가 IaaS/PaaS/SaaS를 공식화 · 모바일 앱을 위한 mBaaS 등장 | 정의, 이어서 모바일 백엔드 |
| 2013–2014 | 컨테이너의 주류화 → CaaS · 최초의 FaaS 런타임 | 머신 이미지, 이어서 상시 가동 서버 |
| 2015–2020 | mBaaS가 BaaS로 일반화 · "서버리스"라는 상위 개념 등장 | 모바일 전용 프레이밍, 이어서 개념으로서의 서버 |
| 오늘날 | 팀들은 기본적으로 충분한 가장 높은 단을 택함 | 다음 후보: 보일러플레이트 코드 자체 |

20년에 걸친 패턴은 한 방향입니다. 새 모델마다 이전 모델이 여전히 드러내던 계층을 추상화하고, 새 세대의 팀마다 이전 세대보다 높은 곳에서 출발합니다. 일반 BaaS보다 mBaaS가 *먼저* 등장했다는 사실은 이 사다리의 가장 흥미로운 뒷이야기입니다. 서버 팀이 없고 앱 스토어 출시 주기에 묶인 모바일의 제약이 가장 높은 추상화를 먼저 강제했고, 업계의 나머지가 그 뒤를 따라잡았습니다.

## 피자 비유를 일곱 단으로 확장하기

고전적인 교육용 비유(2014년 소프트웨어 아키텍트 Albert Barron이 만든 것)는 세 모델을 저녁 식사에 빗댑니다. 온프레미스는 집에서 요리하기, IaaS는 반조리 피자를 사 와 굽기, PaaS는 배달, SaaS는 외식입니다. 새 단들도 자연스럽게 이어집니다. **CaaS는 규격화된 팬이 갖춰진 공용 주방을 빌리는 것**입니다. 레시피도 포장도 사용자 방식대로, 조리는 그들의 장비로 합니다. **FaaS는 조각당 값을 치르는 것**입니다. 배가 고파지기 전에는 피자가 존재하지 않고, 빈 테이블 값은 결코 내지 않습니다. **BaaS는 사용자만의 마무리 손길을 빼고 전부 준비된 밀키트**입니다. 도우, 소스, 오븐은 해결되어 있고, 사용자는 자기 가게를 만드는 토핑을 얹습니다. 그리고 **mBaaS는 같은 키트를 푸드트럭 크기로 맞춘 것**입니다. 모바일이라는 제약이 키트의 형태를 먼저 잡았고, 나머지 모두가 그 뒤에 채택했습니다.

## IaaS vs. CaaS vs. PaaS vs. FaaS vs. BaaS vs. SaaS 비교

| 차원 | IaaS | CaaS | PaaS | FaaS | BaaS / mBaaS | SaaS |
| --- | --- | --- | --- | --- | --- | --- |
| 사용자가 관리하는 것 | OS부터 위로 | 컨테이너 + 앱 | 앱 + 데이터 | 함수 + 데이터 | 커스텀 로직 + 데이터 | 설정 |
| 배포 단위 | 가상 머신 | 컨테이너 | 애플리케이션 | 함수 | 없는 경우가 많음(SDK 호출) | — |
| 확장 | 사용자가 설정 | 제공업체가 오케스트레이션 | 플랫폼, 인스턴스 단위 | 자동, 0까지 | API 뒤에서 자동 | 보이지 않음 |
| 요금 형태 | 리소스 시간당 | 노드/컨테이너당 | 인스턴스/등급당 | 호출 횟수 + 시간 | 무료 등급 + 플랜 | 사용자당 월 요금 |
| 첫 요청까지 걸리는 시간 | 며칠 | 몇 시간 | 몇 시간 | 몇 분 | **몇 분, 인증과 데이터 포함** | 즉시 |
| 벤더 종속 압력 | 낮음 | 낮음–중간 | 중간 | 중간–높음 | 높음. 단, 오픈소스라면 예외 | 가장 높음 |
| 최적 용도 | 완전한 제어, 특수 워크로드 | 마이크로서비스, 다중 언어 스택 | 커스텀 서버 앱 | 이벤트 기반 컴퓨팅 | 표준 앱 백엔드 | 만드는 것이 아니라 소비하기 |

### 사람들이 실제로 비교하는 쌍

**IaaS vs. PaaS** – "머신을 운영하고 싶은가, 아니면 앱만 배포하고 싶은가?"의 문제입니다. IaaS는 제어 자체가 요구사항일 때만 선택합니다. 그 외에는 같은 애플리케이션에 대해 PaaS가 OS부터 위의 부담을 지워 줍니다.

**IaaS vs. CaaS** – 같은 질문을 한 계층 위에서 묻는 것입니다. 빌린 머신 위에서 오케스트레이션을 직접 운영할 것인가, 오케스트레이션까지 빌릴 것인가. 컨트롤 플레인 운영이 팀의 전문 분야가 아니라면 CaaS입니다.

**CaaS vs. PaaS** – 넘기는 단위의 차이입니다. 컨테이너(어떤 스택이든, 사용자 방식의 패키징, 오케스트레이션 수준의 제어)냐, 애플리케이션 코드(그들의 런타임, 그들의 관례, 더 적은 절차)냐의 선택입니다. 마이크로서비스와 다중 언어 환경은 CaaS 쪽으로, 표준 앱 하나는 PaaS 쪽으로 기웁니다.

**CaaS vs. FaaS** – 상주냐 이벤트냐의 문제입니다. 서비스 간 트래픽이 있는 장기 실행 서비스는 컨테이너에, 산발적이고 이벤트 형태인 작업은 0으로 축소되는 함수에 속합니다. 실제 시스템 대부분은 둘 다 운영합니다.

**PaaS vs. BaaS** – 사다리에서 가장 깊은 혼동이며, [별도 항목](/glossary/ko/paas-vs-baas/)이 있습니다. PaaS는 *여전히 사용자가 작성해야 하는* 백엔드를 호스팅하고, BaaS는 표준 기능에 대해 그 단계를 없앱니다. 백엔드를 작성할 것인가, 가질 것인가의 차이입니다.

**FaaS vs. BaaS** – 아웃소싱 범위의 차이로, [BaaS vs. 서버리스](/glossary/ko/baas-vs-serverless/)에서 자세히 분석합니다. FaaS는 사용자가 작성하는 코드의 런타임을 아웃소싱하고, BaaS는 백엔드를 아웃소싱해 그 코드 대부분이 아예 존재하지 않게 합니다. 성숙한 BaaS 플랫폼은 FaaS를 내장하므로 실무에서는 두 단이 결합됩니다.

**BaaS vs. mBaaS** – [역사 대 현재](/glossary/ko/mbaas-vs-baas/)의 문제입니다. 같은 단이되 기원이 모바일 우선입니다. 제품이 푸시, 오프라인, 기기 상태에 의존한다면 *m*은 여전히 요구사항을 설명하지만, 플랫폼은 어쨌든 수렴했습니다.

**SaaS vs. 나머지 전부** – 범주의 전환입니다. 다른 모든 모델은 그 *위에* 짓는 것이고, SaaS는 그 위에 *아무것도* 짓지 않는 것입니다. 어떤 워크로드가 SaaS일 수 있다면 거의 항상 그것이 충분하면서 가장 저렴한 단입니다. 다만 더 이상 *사용자의* 소프트웨어가 아니게 될 뿐입니다.

## "서버리스"의 자리

서버리스는 여덟 번째 단이 아닙니다. 프로그래밍 가능한 가장 높은 두 단을 덮는 상위 개념입니다. [표준으로 통하는 정의](https://martinfowler.com/articles/serverless.html)는 FaaS(주문형으로 실행되는 사용자의 코드)와 BaaS(미리 구축된 백엔드 서비스)를 모두 포괄합니다. 둘 다 팀의 누구도 서버를 관리하지 않고, 용량은 자동으로 확장되며, 비용은 사용량을 따릅니다. 누군가 "서버리스로 전환했다"고 말하면 사다리 관점에서 물어야 할 질문은 *어느 단*인가입니다. 직접 작성한 함수인가, 작성하지 않은 백엔드인가, 아니면 가장 흔한 경우인 그 둘의 조합인가.

## 일반적인 사용 사례

- **IaaS:** 리프트 앤 시프트 마이그레이션, 특수한 런타임과 하드웨어, 인프라 제어를 요구하는 규제 체계.
- **CaaS:** 마이크로서비스 집합, 다중 언어 시스템, 컨트롤 플레인 운영 없이 [Kubernetes급 오케스트레이션](/glossary/ko/kubernetes/)을 원하는 팀.
- **PaaS:** 백엔드 로직이 *곧* 제품인 커스텀 웹 애플리케이션과 API, 서버 운영 없이 배포하려는 팀.
- **FaaS:** 웹훅 핸들러, 예약 작업, 이미지 및 데이터 파이프라인 등 주변에 완전한 백엔드가 없는 이벤트 기반 작업.
- **BaaS:** 사용자, 데이터, 파일, 알림 같은 표준 요구를 가진 완전한 앱 백엔드, 특히 프론트엔드 중심 팀.
- **mBaaS:** 같은 것의 모바일 우선 버전. 푸시, 오프라인 동기화, 기기별 상태 위에 지어진 제품.
- **SaaS:** 회사가 사용하지만 만들지는 않는 모든 것. 설계의 토대가 아니라 소비하는 단.

## 어느 단을 선택해야 할까? 결정 매트릭스

```mermaid
flowchart TD
  accTitle: 배포하는 것을 기준으로 클라우드 서비스 모델 고르기
  accDescr: 결정 흐름입니다. 누군가 이미 그 제품을 팔고 있다면 SaaS를 사용합니다. 직접 만드는데 백엔드 요구가 표준적이라면 BaaS를, 모바일 우선 제품이라면 mBaaS를 사용합니다. 백엔드 로직이 곧 제품이라면 앱 하나에는 PaaS를, 마이크로서비스에는 CaaS를 사용합니다. 이벤트 기반 연결 작업에는 어느 경로에서든 FaaS를 사용하고, 인프라 제어 자체가 요구사항일 때만 IaaS를 사용합니다.
  Q0{"이미 살 수 있는<br/>제품이 있는가?"} -->|예| S["SaaS – 그대로 사용"]
  Q0 -->|아니요, 직접 구축| Q1{"백엔드 요구가 표준적인가?<br/>(사용자, 데이터, 파일, 푸시)"}
  Q1 -->|예| B["BaaS – 모바일 우선이면 mBaaS"]
  Q1 -->|"아니요 – 백엔드 로직이 곧 제품"| Q2{"앱 하나인가, 여러 서비스인가?"}
  Q2 -->|앱 하나| P["PaaS"]
  Q2 -->|마이크로서비스 / 다중 언어| C["CaaS"]
  Q1 -.->|이벤트 기반 부수 작업| F["FaaS – 어느 경로에서든"]
  Q2 -.->|인프라 제어가 요구사항| I["IaaS"]
```

| 상황 | 시작할 단 | 이유 |
| --- | --- | --- |
| 제품을 출시하는 프론트엔드 또는 모바일 팀 | BaaS / mBaaS | 표준 백엔드가 첫날부터 존재하므로 고유한 부분만 작성 |
| 커스텀 서버 코드베이스 하나를 가진 백엔드 팀 | PaaS | 코드는 완전히 제어하고 머신은 전혀 신경 쓰지 않음 |
| 마이크로서비스 또는 다중 언어 환경 운영 | CaaS | 컨트롤 플레인 운영 없는 오케스트레이션 |
| 이벤트, 연결 작업, 예약 작업 자동화 | FaaS | 무슨 일이 일어날 때만 비용 지불 |
| 레거시 시스템이나 특수 하드웨어 운영 | IaaS | 낮은 단의 제어권 자체가 요구사항 |
| 누군가 이미 제품화한 문제 해결 | SaaS | 직접 만드는 것은 곁길 |

그 위에 솔직한 규칙 두 가지가 얹힙니다. 맞는 단 가운데 가장 높은 단을 기본값으로 삼을 것(한 단 내려갈 때마다 운영 업무를 다시 떠안게 됩니다), 그리고 워크로드마다 다시 평가할 것(기업은 설계상 여러 단에 동시에 올라가 있습니다).

## 한계와 트레이드오프

- **IaaS:** 단위 가격은 듣기 좋지만, 패치하고 확장하고 보호할 운영 인력이 진짜 청구서입니다.
- **CaaS:** 아웃소싱한 것은 컨트롤 플레인이지 복잡성이 아닙니다. 이미지, 매니페스트, 서비스 메시, 배포 파이프라인은 여전히 엔지니어링 전문 분야입니다.
- **PaaS:** 의존성 업그레이드와 인증 버그를 포함한 애플리케이션 전체를 여전히 소유하며, 플랫폼 형태의 관례까지 따릅니다.
- **FaaS:** 콜드 스타트, 실행 제한, 그리고 지속적인 고부하에서 적대적으로 변하는 호출당 요금.
- **BaaS / mBaaS:** 표준에서 크게 벗어난 요구사항에 부딪히는 커스터마이징 한계, 그리고 *독점 플랫폼일 때* 사다리에서 가장 강한 [벤더 종속](/glossary/ko/cloud-vendor-lock-in/). 오픈소스 기반 플랫폼이 중요한 이유가 여기 있습니다. 출구를 실제로 열어 둡니다.
- **SaaS:** 전면적 의존. 로드맵, 요금, 데이터 이식성이 모두 다른 누군가의 결정에 달려 있습니다.
- **공통:** 공동 책임의 선은 움직이지만, 사용자의 데이터, 접근 정책, 판단을 넘어서는 일은 결코 없습니다.

## Back4app에서의 서비스 모델 사다리

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. BaaS 단을 차지하며, 푸시와 모바일 SDK를 핵심 기능으로 갖춘 mBaaS 완전체이고, 의도적으로 양쪽 방향 모두에 대비합니다. 위쪽으로는 표준 백엔드가 미리 구축되어 있어, 자기 제품의 백엔드를 첫날부터 SaaS처럼 바로 쓸 수 있습니다. 아래쪽으로는 [Cloud Code](https://www.back4app.com/docs/get-started/cloud-functions) 함수, 트리거, 예약 작업이 플랫폼 안에서 FaaS 단을 제공하고, 같은 회사가 컨테이너가 필요한 워크로드를 위해 [CaaS 단](https://blog.back4app.com/containers-as-a-service/)을 문서화하고 있습니다. 그리고 스택이 오픈소스이므로 사다리의 최악의 실패 양상인 꼭대기에서의 종속에는 문서화된 내려오는 길이 있습니다. 같은 백엔드를 아래의 어느 단에서든 다시 작성 없이 직접 호스팅할 수 있습니다.