---
term: 'BaaS vs. 서버리스'
seoTitle: 'BaaS vs 서버리스 차이: 개념, 비교, 선택 기준'
headline: 'BaaS vs. 서버리스: 차이점은?'
slug: baas-vs-serverless
category: cloud-architecture
shortDefinition: '서버리스는 제공업체가 코드를 주문형으로 실행하는 실행 모델이고, BaaS는 백엔드를 미리 구축된 형태로 제공하는 서버리스 모델입니다.'
relatedTerms:
  - baas-vs-custom-backend
  - serverless-architecture
  - cloud-code-serverless-functions
  - paas-vs-baas
  - no-ops-development
contrastsWith:
  - paas-vs-baas
aboutTerms:
  - 'Backend-as-a-Service (BaaS)'
  - 'Serverless Computing'
  - 'Functions-as-a-Service (FaaS)'
faq:
  - question: 'BaaS는 서버리스와 같은 것입니까?'
    answer: '아닙니다. 겹치지만 동의어는 아닙니다. 서버리스는 실행 모델입니다. 제공업체가 컴퓨팅을 주문형으로 할당하고 사용자는 서버를 전혀 관리하지 않습니다. BaaS는 그 모델을 사용하는 한 가지 특정한 방식으로, 데이터베이스, 인증, 파일 스토리지, API 같은 백엔드 기능 자체가 미리 구축되어 제공됩니다. 일상적으로 "서버리스"는 나머지 절반인 FaaS, 즉 여전히 사용자가 함수를 작성하는 쪽을 가리키는 경우가 많습니다.'
  - question: 'BaaS는 서버리스의 한 종류입니까?'
    answer: '예. Backend-as-a-Service는 서버리스로 분류됩니다. martinfowler.com에 실린 Mike Roberts의 글에서 정식화되고 CNCF 서버리스 백서가 채택한 표준 분류는 서버리스를 BaaS와 FaaS를 모두 아우르는 상위 개념으로 봅니다. 둘 다 개발자가 서버를 관리하지 않고, 용량이 자동으로 확장되며, 비용이 사용량을 따르기 때문에 서버리스로 분류됩니다. 혼동이 생기는 이유는 마케팅에서 "서버리스"를 FaaS만의 의미로 쓰는 일이 잦기 때문입니다.'
  - question: 'BaaS와 FaaS의 차이는 무엇입니까?'
    answer: '범위입니다. FaaS(Functions-as-a-Service)는 여전히 사용자가 작성해야 하는 단일 목적의 이벤트 트리거 함수를 실행합니다. 관리형 인프라 위의 커스텀 컴퓨팅입니다. BaaS(Backend-as-a-Service)는 작성 자체를 없앱니다. 인증, 데이터베이스 CRUD, 파일 스토리지, API가 클라이언트 SDK에서 사용하는 완성된 기능입니다. FaaS는 런타임을 아웃소싱하고, BaaS는 백엔드를 아웃소싱합니다.'
  - question: 'BaaS와 FaaS를 함께 사용할 수 있습니까?'
    answer: '예. 그것이 예외가 아니라 실무에서 지배적인 패턴입니다. BaaS 계층이 사용자, 데이터, 파일, API 같은 표준 요구를 담당하고, FaaS 런타임이 실제 앱이라면 결국 필요해지는 커스텀 로직, 즉 검증, 결제 웹훅, 예약 작업을 처리합니다. 성숙한 BaaS 플랫폼 대부분이 바로 이 이유로 FaaS 런타임을 내장해 제공하며, Back4app에서는 이를 Cloud Code라고 부릅니다.'
  - question: 'FaaS 대신 BaaS를 선택해야 하는 때는 언제입니까?'
    answer: '사용자 계정, 데이터베이스, 파일 스토리지 같은 표준 요구를 가진 완전한 애플리케이션 백엔드를 만들면서 소규모 팀으로 빠르게 출시하려 할 때 BaaS를 선택합니다. 웹훅 핸들러, 이미지 처리, 예약 작업처럼 주변에 완전한 백엔드가 없는 이벤트 기반 연결 작업이나 데이터 파이프라인을 만들 때는 순수 FaaS를 선택합니다. 표준 백엔드와 커스텀 로직이 모두 필요하다면 함수가 내장된 BaaS가 양쪽을 감당합니다.'
  - question: '서버리스가 BaaS보다 저렴합니까?'
    answer: '모델 자체가 아니라 워크로드의 형태에 달려 있습니다. 순수 호출당 요금은 유휴 비용이 0이므로 간헐적이거나 적은 트래픽에서 이기지만, 지속적인 고부하에서는 고정 플랜을 넘어설 수 있고 예측도 더 어렵습니다. BaaS 플랫폼은 보통 무료 등급과 플랜 기반 요금을 결합해 요청당 효율을 약간 내주고 예측 가능성을 얻습니다. 결정하기 전에 실제 트래픽 곡선을 모델링해야 합니다.'
  - question: 'BaaS 플랫폼은 벤더 종속을 일으킵니까?'
    answer: '그럴 수 있습니다. 이 위험은 BaaS와 FaaS 모두에 해당하는데, 독점 API에 맞춰 작성된 코드와 독점 형식으로 저장된 데이터는 옮기기 비싸기 때문입니다. 완화책은 오픈소스에 기반한 플랫폼을 고르는 것입니다. Back4app은 오픈소스 기반 위에서 실행되므로 같은 백엔드, SDK 호출, 함수를 어떤 인프라에서든 직접 호스팅할 수 있고, 벤더 종속은 강제된 의존에서 편의에 따른 선택으로 바뀝니다.'
  - question: 'BaaS 플랫폼에도 콜드 스타트가 있습니까?'
    answer: '함수 절반에만 있습니다. 콜드 스타트는 이벤트 트리거 FaaS 컴퓨팅에 영향을 주며, 유휴 상태의 런타임을 첫 호출 전에 프로비저닝해야 할 때 발생합니다. BaaS의 상시 가동 API 계층(CRUD, 인증, 파일 제공)은 콜드 스타트가 없습니다. 이 점이 표준 작업은 한결같이 빠르게 느껴지는 반면 드물게 호출되는 커스텀 함수는 첫 요청에서 비용을 치를 수 있는 실질적인 이유 중 하나입니다.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Serverless Architectures — Mike Roberts (martinfowler.com)'
    url: 'https://martinfowler.com/articles/serverless.html'
  - name: 'CNCF Serverless Whitepaper'
    url: 'https://github.com/cncf/wg-serverless/blob/master/whitepapers/serverless-overview/cncf_serverless_whitepaper_v1.0.pdf'
  - name: 'Backend as a service (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Backend_as_a_service'
  - name: 'Back4app Cloud Code documentation'
    url: 'https://www.back4app.com/docs/get-started/cloud-functions'
cta:
  title: '서버리스의 두 절반을 한 플랫폼에서'
  text: 'Back4app은 데이터베이스, 인증, 스토리지, API를 갖춘 완전한 BaaS에 커스텀 로직을 위한 Cloud Code 서버리스 함수를 결합합니다. 표준적인 80%는 작성하지 않고 출시하고, 나머지는 함수로 배포하면 됩니다.'
  linkText: '무료로 시작하기'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-26'
translationKey: baas-vs-serverless
---

**서버리스는 제공업체가 코드를 주문형으로 실행하는 실행 모델이고, BaaS는 백엔드를 미리 구축된 형태로 제공하는 서버리스 모델입니다.** 그러므로 이 비교는 경쟁자 사이의 양자택일이 아니라 범위의 문제입니다. FaaS(대부분의 사람이 "서버리스"라고 할 때 뜻하는 모델)는 *여전히 사용자가 작성하는* 함수를 실행합니다. BaaS는 더 나아가 작성 자체를 없앱니다. 인증, 데이터베이스, 스토리지, API가 완성된 기능으로 도착합니다.

## 핵심 요약

| 질문 | 답 |
| --- | --- |
| 경쟁 관계인가? | 아니요. BaaS는 서버리스라는 상위 개념의 절반이고, FaaS가 나머지 절반 |
| 백엔드 로직은 누가 작성하는가? | FaaS: 사용자. BaaS: 플랫폼이 이미 작성함 |
| 무엇을 배포하는가? | FaaS: 함수. BaaS: 없는 경우가 많음. 클라이언트가 SDK와 통신 |
| 어느 쪽이 저렴한가? | 모델이 아니라 트래픽 형태에 달림 |
| 실무 권장안 | 결합: 표준적인 80%는 BaaS, 나머지는 함수 |

## 백엔드는 누가 작성하는가? 서로 다른 두 답

FaaS에서 "서버리스"는 커스텀 로직이 관리형 이벤트 트리거 컴퓨팅에서 실행된다는 뜻이지만, 로직은 여전히 사용자가 작성해야 합니다:

```javascript
// cloud/main.js – FaaS 절반: 여전히 사용자가 작성하는 커스텀 로직
Parse.Cloud.beforeSave('Review', (request) => {
  const stars = request.object.get('stars');
  if (stars < 1 || stars > 5) {
    throw 'Rating must be between 1 and 5';
  }
});
```

BaaS에서는 답이 달라집니다. 표준 기능에는 작성할 백엔드 코드가 전혀 없습니다. 사용자 가입(비밀번호 해싱, 세션 토큰, 중복 검사, 이메일 흐름)은 어떤 클라이언트에서든 SDK 호출 한 번입니다:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
const user = new Parse.User();
user.set('username', 'ada');
user.set('password', 'correct-horse-battery');
user.set('email', 'ada@example.com');
await user.signUp(); // hashing, session token, email flow — all managed
console.log(`Signed up: ${user.getUsername()}`);
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
final user = ParseUser.createUser(
    'ada', 'correct-horse-battery', 'ada@example.com');
final response = await user.signUp();
if (response.success) {
  print('Signed up: ${user.username}');
}
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
var user = User()
user.username = "ada"
user.password = "correct-horse-battery"
user.email = "ada@example.com"
user.signup { result in
  switch result {
  case .success(let user):
    print("Signed up: \(user.username ?? "")")
  case .failure(let error):
    print(error.localizedDescription)
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
val user = ParseUser().apply {
  username = "ada"
  setPassword("correct-horse-battery")
  email = "ada@example.com"
}
user.signUpInBackground { e ->
  if (e == null) {
    Log.d("Auth", "Signed up: ${user.username}")
  }
}
```

두 예제 모두 서버리스입니다. 사용자가 프로비저닝, 패치, 확장하는 서버가 없습니다. 차이는 무엇을 아웃소싱했느냐입니다. FaaS는 *런타임*을, BaaS는 *백엔드 자체*를 아웃소싱합니다.

## 두 모델의 관계

이 비교를 둘러싼 혼동은 정의의 문제이므로 명시적으로 풀어 둘 가치가 있습니다. [martinfowler.com에 실린 Mike Roberts의 표준적인 틀](https://martinfowler.com/articles/serverless.html)은, 이후 CNCF 백서가 채택한 대로, 서버리스를 두 절반으로 이루어진 상위 개념으로 정의합니다:

```mermaid
flowchart TB
  accTitle: 서버리스라는 상위 개념
  accDescr: 서버리스는 두 절반을 아우릅니다. SDK를 통해 사용하는 미리 구축된 백엔드 서비스인 BaaS와, 0으로 축소되는 이벤트 트리거 무상태 함수인 FaaS입니다.
  S["서버리스<br/>(관리할 서버 없음, 자동 확장, 사용한 만큼 지불)"]
  S --> B["BaaS<br/>미리 구축된 백엔드 서비스"]
  S --> F["FaaS<br/>주문형으로 실행되는 사용자의 함수"]
  B --> B1["인증, 데이터베이스, 스토리지, API<br/>클라이언트 SDK로 사용"]
  F --> F1["이벤트 트리거, 무상태,<br/>0으로 축소"]
```

그러나 일상적으로 "서버리스"는 FaaS 절반만을 줄여 부르는 말인 경우가 많습니다. "BaaS vs. 서버리스"를 마치 경쟁 관계인 것처럼 묻는 이유입니다. 정식으로는 모든 BaaS는 서버리스이지만, 서버리스인 모든 것이 BaaS는 아닙니다.

## BaaS vs. FaaS: 실질적인 차이

| 차원 | BaaS | FaaS(서버리스 함수) |
| --- | --- | --- |
| 배포하는 것 | 없는 경우가 많음. 클라이언트가 SDK를 호출 | 함수 코드 |
| 백엔드 로직 | 플랫폼이 미리 구축 | 사용자가 작성 |
| 추상화 단위 | 백엔드 기능 전체 | 함수 하나 |
| 트리거 모델 | SDK와 API를 통한 요청/응답 | 이벤트: HTTP, 데이터베이스 변경, 스케줄 |
| 상태 | 관리형 데이터베이스와 파일 스토리지 포함 | 무상태. 상태는 다른 곳에 |
| 콜드 스타트 | 없음(상시 가동 API 계층) | 있음, 유휴 함수에서 |
| 요금 형태 | 무료 등급 + 플랜. 예측 가능 | 호출 횟수 + 컴퓨팅 시간. 사용량을 따름 |
| 벤더 종속 위험 | 독점 API와 데이터. 단, 오픈소스라면 예외 | 독점 트리거와 서비스. 단, 이식 가능하다면 예외 |
| 최적 용도 | 표준 요구를 가진 완전한 앱 백엔드 | 이벤트 기반 연결 작업, 파이프라인, 커스텀 컴퓨팅 |

## 일반적인 사용 사례

- **BaaS: 완전한 앱 백엔드.** 계정, 데이터, 파일, API가 필요한 모바일 또는 웹 앱. 모든 백엔드의 표준적인 80%를 백엔드 팀 없이 운영합니다.
- **BaaS: 마감이 있는 MVP.** 제품을 검증할 때 몇 주짜리 인증과 CRUD 연결 작업은 없애야 할 비용이지, 검증하려는 가치가 아닙니다.
- **FaaS: 이벤트 기반 연결 작업.** 웹훅 수신기, 결제 확인, 서드파티 동기화. 주변에 완전한 백엔드가 없는 짧은 반응입니다.
- **FaaS: 데이터 처리.** 업로드 시 이미지 리사이징, 저장 시 검증, 예약된 정리 작업. 몇 초 실행되고 사라지는 컴퓨팅입니다.
- **둘 다: 규모 있는 실제 제품.** 표준 기능은 BaaS 계층에서 실행되고, 피할 수 없는 커스텀 로직(비즈니스 규칙, 통합, 작업)은 그 옆에서 함수로 실행됩니다.

## 하이브리드 패턴: 양자택일이 드문 이유

가장 흔한 프로덕션 아키텍처는 두 모델 중 하나를 고르는 것이 아니라 둘을 조합하는 것입니다. BaaS 계층이 사용자, 데이터, 스토리지를 다루고, 내장된 FaaS 런타임이 플랫폼이 예측할 수 없었던 모든 것, 즉 위의 `beforeSave` 검증, 결제 웹훅, 야간 보고서를 다룹니다. 성숙한 BaaS 플랫폼이 함수를 핵심 기능으로 제공하는 이유가 여기 있습니다. 두 모델은 대체재가 아니라 상호 보완하는 계층입니다. [Backend-as-a-Service](https://www.back4app.com/backend-as-a-service-baas) 계층은 사용자가 *작성하지 않는* 것을 정의하고, 함수 계층은 사용자가 *작성하는* 부분이 어떻게 실행되는지를 정의합니다.

## BaaS와 FaaS 중 무엇을 선택해야 할까? 결정 매트릭스

| BaaS 쪽으로 기울 때 | 순수 FaaS 쪽으로 기울 때 |
| --- | --- |
| 완전한 앱 백엔드(인증, 데이터, 파일)를 구축 중 | 주변에 백엔드가 없는 이벤트 연결 작업을 구축 중 |
| 표준 구성 요소가 대부분의 요구사항을 충족 | 모든 요구사항이 커스텀 컴퓨팅 |
| 팀이 프론트엔드/모바일 중심이고 DevOps가 없음 | 팀이 이미 주변 인프라를 운영 중 |
| 출시 시간이 아키텍처 제어보다 중요 | 함수 하나하나의 세밀한 제어가 중요 |
| 데이터, 인증, 로직을 한 플랫폼에서 원함 | 독립적인 관리형 서비스 여러 개를 조합 중 |

양쪽 열 모두에 해당한다면(실제 애플리케이션 대부분이 그렇습니다) FaaS 런타임을 내장한 BaaS를 고르면 되고, 그러면 선택할 필요가 없습니다.

## 한계와 트레이드오프

- **콜드 스타트(FaaS 절반).** 유휴 함수는 첫 호출에서 수 밀리초에서 수 초에 이르는 프로비저닝 비용을 치릅니다. BaaS API 계층은 그렇지 않지만, 커스텀 함수는 그럴 수 있습니다.
- **커스터마이징 한계(BaaS 절반).** 미리 구축된 기능은 일반적인 경우를 구현합니다. 특이한 인증 흐름, 독특한 쿼리 엔진처럼 그 범위를 크게 벗어난 요구사항은 플랫폼과 싸우게 될 수 있습니다. 내장 함수 계층이 숨통을 틔워 주지만, 거기에도 한계는 있습니다.
- **벤더 종속(vendor lock-in, 양쪽 모두).** 독점 SDK 호출과 독점 이벤트 형식은 둘 다 마이그레이션 비용입니다. 오픈소스에 기반한 플랫폼은 이를 무력화합니다. Back4app의 스택은 Parse Server이며 언제든 직접 호스팅할 수 있습니다.
- **지속적인 규모에서의 비용(양쪽 모두).** 사용한 만큼 내는 요금은 트래픽이 간헐적일 때 당할 상대가 없고, 일정하고 무거울 때는 가혹합니다. 어느 모델이든 사용량이 안정되면 계산을 다시 해야 합니다.
- **무상태성(FaaS 절반).** 함수는 호출 사이에 아무것도 유지하지 않으므로 상태는 데이터베이스나 캐시에 있어야 합니다. BaaS에서는 관리형 데이터베이스가 이미 있어 이 고통이 덜합니다.

## Back4app에서의 BaaS와 서버리스

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 하이브리드 패턴을 제품으로 만든 것입니다. BaaS 계층은 모든 앱에 [서버리스 아키텍처](/glossary/ko/serverless-architecture/)의 핵심 요소를 프로비저닝합니다. FaaS 계층은 [**Cloud Code**](https://www.back4app.com/docs/get-started/cloud-functions)입니다. 대시보드나 CLI에서 배포하는 JavaScript 함수, 데이터베이스 트리거, 예약 작업입니다. 그리고 스택 전체가 그 아래에서 오픈소스이므로 두 절반 모두 이식 가능하게 유지됩니다. 그래서 "관리형의 편의냐, 미래의 자유냐"라는 양자택일 자체에서 벗어날 수 있습니다.