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

PaaS는 제공업체가 코드를 배포할 플랫폼을 운영하되, 애플리케이션 자체는 여전히 사용자가 작성하고 관리하는 클라우드 모델입니다. 쉽게 말해 플랫폼은 빌리지만 앱은 여전히 사용자의 것입니다. NIST 정의는 그 선을 정확히 긋습니다. 제공업체가 서버, 운영체제, 런타임을 제어하고, 사용자는 배포된 애플리케이션과 그 데이터를 제어합니다.

핵심 요약

PaaS 사용의 모습

PaaS의 대표적인 경험은 인프라 설정 없이 명령 하나로 배포하는 것입니다:

# 전형적인 PaaS 워크플로: 코드를 푸시하면 나머지는 플랫폼이 처리
$ git push platform main
-----> Runtime detected: Node.js
-----> Installing dependencies, building release
-----> Launching web process (2 instances)
       https://my-api.example.app deployed

그런데 그 명령이 배포하는 것은 여전히 사용자가 작성한 완전한 서버 애플리케이션입니다. 라우팅, 검증, 데이터베이스 연결, 인증 처리까지 전부입니다:

// server.js – PaaS에서는 이 전부를 여전히 사용자가 작성하고 유지보수합니다
import express from 'express';
const app = express();

app.get('/tasks', async (req, res) => {
  const user = await authenticate(req);            // 직접 만든 것
  const tasks = await db.query(                    // 이것도
    'SELECT * FROM tasks WHERE owner = $1 AND done = false',
    [user.id]
  );
  res.json(tasks);                                 // 이것도
});

app.listen(process.env.PORT);

이것이 PaaS의 본질적인 트레이드오프입니다. 인프라는 사라지지만, 백엔드 애플리케이션과 그 안의 모든 보안 패치, 의존성 업그레이드, 엔드포인트는 여전히 사용자의 코드베이스에 남습니다.

추상화 사다리

각 클라우드 서비스 모델은 한 가지 질문에 답합니다. 얼마나 빌리고, 얼마나 여전히 직접 운영하는가?

계층별 책임 분담:

더 좁은 용도를 위한 특화형 PaaS도 있습니다. 통합 플랫폼, 모바일 플랫폼, 데이터베이스 플랫폼, 커뮤니케이션 플랫폼 등이지만, 모두 같은 단에 있습니다. 사용자가 만든 소프트웨어를 실행하거나 연결하는 관리형 자리입니다.

PaaS vs. BaaS: 실질적인 차이

BaaS는 한 단 위이며, 차이는 사용자가 작성하지 않는 것에서 드러납니다. 위의 작업 목록 엔드포인트(인증 확인, 쿼리, 응답)는 BaaS에서 어떤 클라이언트에서든 직접 호출하는 SDK 호출 하나로 대체되고, 접근 제어는 플랫폼이 집행합니다:

// JavaScript / Node.js — Back4app JS SDK
const query = new Parse.Query('Task');
query.equalTo('done', false);
query.descending('createdAt');
const tasks = await query.find();
console.log(`${tasks.length} open tasks`);

// Flutter / Dart — Back4app Flutter SDK
final query = QueryBuilder<ParseObject>(ParseObject('Task'))
  ..whereEqualTo('done', false)
  ..orderByDescending('createdAt');
final response = await query.query();
if (response.success) {
  print('${response.results?.length} open tasks');
}

// iOS / Swift — Back4app Swift SDK
let query = Task.query("done" == false)
  .order([.descending("createdAt")])
query.find { result in
  switch result {
  case .success(let tasks):
    print("\(tasks.count) open tasks")
  case .failure(let error):
    print(error.localizedDescription)
  }
}

// Android / Kotlin — Back4app Android SDK
val query = ParseQuery.getQuery<ParseObject>("Task")
query.whereEqualTo("done", false)
query.orderByDescending("createdAt")
query.findInBackground { tasks, e ->
  if (e == null) {
    Log.d("Tasks", "${tasks.size} open tasks")
  }
}

PaaS vs. 서버리스

두 모델은 사촌이지 동의어가 아닙니다. PaaS 앱은 사용자가 설정한 용량에서 상시 실행되고, 서버리스 컴퓨팅은 이벤트가 발생할 때마다 생성되어 호출 단위로 과금되고 0으로 축소되는 대신 콜드 스타트와 실행 제한을 치릅니다. 실무에서는 경계가 흐려집니다. 현대의 플랫폼은 PaaS 방식 호스팅에 서버리스 함수를 덧붙이고, 서버리스 아키텍처는 PaaS가 앱 하나로 호스팅했을 API 전체를 제공할 수 있습니다. 결정은 트래픽 형태에 달려 있습니다. 꾸준한 부하는 상시 가동 PaaS 프로세스에, 간헐적이거나 유휴가 많은 부하는 호출 단위 컴퓨팅에 유리합니다.

일반적인 사용 사례

• 커스텀 웹 API와 서비스. 가격 책정 엔진, 마켓플레이스, 내부 도구처럼 미리 구축된 기능으로는 담기 어려운 특수한 로직을 가진 백엔드를 서버 소유 없이 배포합니다.
• 다수의 배포 표준화. 수십 개의 서비스를 운영하는 팀은 모든 서비스가 같은 방식으로 빌드, 배포, 로깅, 확장되도록 PaaS를 도입합니다.
• 직접 관리하던 서버에서의 이전. 기존 서버 애플리케이션(특히 12-factor 앱)은 대부분 그대로 PaaS로 옮겨 갑니다. 코드는 같고, OS 패치는 더 이상 없습니다.
• BaaS가 PaaS를 대체하는 곳: 표준 앱 백엔드. 백엔드가 사용자 + 데이터 + 파일 + 알림이라면, 미리 구축된 기능이 PaaS가 호스팅했을 애플리케이션 계층을 없앱니다. 모바일과 웹 제품의 흔한 경우입니다.
• 하이브리드: PaaS 방식의 커스텀 코어, 나머지는 BaaS. 커스텀 서비스 하나는 플랫폼에 두고, 사용자 관리, 데이터 API, 스토리지는 옆의 BaaS에서 가져오는 팀도 있습니다.

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

대부분의 요구사항이 표준이고 몇 가지만 커스텀이라면, 그것은 PaaS를 고를 이유가 아닙니다. 함수 런타임이 내장된 BaaS가 양쪽을 더 적은 코드로 감당합니다.

한계와 트레이드오프

• 여전히 애플리케이션을 소유합니다. 프레임워크 업그레이드, 의존성의 보안 패치, 인증 버그까지 전부입니다. PaaS는 백엔드를 호스팅할 뿐 유지보수하지 않습니다. BaaS는 없애 주고 PaaS는 없애 주지 않는 비용입니다.
• 벤더 종속(vendor lock-in). 플랫폼 전용 서비스와 배포 형식에 맞춰 작성된 앱은 옮기기 비쌉니다. 완화책은 개방 표준 고수, 컨테이너화, 오픈소스 기반 플랫폼 선호입니다. 같은 벤더 종속 주의는 사다리 위아래 어디에나 적용됩니다.
• 지속적인 규모에서의 비용. 관리형 편의에는 마진이 붙습니다. 크고 꾸준한 워크로드는 결국 사다리의 낮은 단에서 더 저렴해지지만, 운영 부담을 다시 떠안는 대가를 치릅니다.
• 제어권 축소. OS 접근 불가, 제한된 네트워크 튜닝, 제공업체 일정에 따르는 런타임 버전. 인프라 제어를 요구하는 규제 체계에서는 이 모델이 배제될 수 있습니다.
• 제공업체 의존. 장애, 요금 변경, 지원 중단은 사용자가 아니라 제공업체의 일정에 따라 옵니다. 제공업체의 이력도 아키텍처의 일부로 판단해야 합니다.

Back4app에서의 PaaS vs. BaaS

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 그래서 PaaS보다 한 단 위에 있습니다. 모든 앱이 완전한 백엔드가 이미 프로비저닝된 상태로 시작합니다. 그렇지 않았다면 PaaS로 다시 끌어내렸을 커스텀 로직의 공백은 Cloud Code가 메웁니다. 서버리스 함수, 트리거, 예약 작업입니다. 그리고 스택이 오픈소스이므로 벤더 종속 반론은 뒤집힙니다. 같은 백엔드를 어떤 인프라에서든 직접 호스팅할 수 있으므로, 나중에 사다리를 내려가는 일도 재작성 없이 가능합니다.