서버리스 클라우드 함수 vs. 커스텀 마이크로서비스

서버리스 클라우드 함수는 배포 가능한 백엔드 로직의 단일 단위이고, 마이크로서비스는 독립적으로 운영되는 하나의 완전한 서비스입니다. 이 한 문장이 비교 전체의 축소판입니다. 나머지 모든 것(운영 부담, 비용 곡선, 콜드 스타트, 상태)은 배포 단위가 무엇인지에서 따라 나옵니다. 플랫폼에 넘기는 함수인지, 직접 운영하는 서비스인지의 차이입니다.

핵심 요약

코드로 보는 배포 단위

다음은 결제(checkout) 연산을 위한 배포물 전체입니다. 함수 하나뿐이며, 서비스별 저장소도, 컨테이너 이미지도, 파이프라인도 없습니다.

// JavaScript / Node.js — the function is the whole deployable
// cloud/main.js — runs on the platform; there is no service to operate
Parse.Cloud.define('checkout', async (request) => {
  const cart = await new Parse.Query('Cart').get(request.params.cartId, {
    sessionToken: request.user.getSessionToken(),
  });
  // …price the cart, reserve stock, write the order…
  return { orderId: cart.id, status: 'confirmed' };
});

// Any client calls it by name — no gateway, container, or pipeline
const result = await Parse.Cloud.run('checkout', { cartId });

// Flutter / Dart — Back4app Flutter SDK
// Calling the function: one named endpoint, no service discovery
final checkout = ParseCloudFunction('checkout');
final response = await checkout.execute(
  parameters: {'cartId': cartId},
);
if (response.success) {
  print(response.result['status']); // confirmed
} else {
  print(response.error?.message);
}

// iOS / Swift — Back4app Swift SDK
// Calling the function: one named endpoint, no service discovery
struct Checkout: ParseCloudable {
    typealias ReturnType = [String: String]
    var functionName: String = "checkout"
    var cartId: String
}

let result = try await Checkout(cartId: cartId).runFunction()
print(result["status"] ?? "") // confirmed

// Android / Kotlin — Back4app Android SDK
// Calling the function: one named endpoint, no service discovery
val params = hashMapOf("cartId" to cartId)
ParseCloud.callFunctionInBackground<Map<String, String>>(
    "checkout", params
) { result, e ->
    if (e == null) {
        Log.i("Checkout", result["status"] ?: "")
    } else {
        Log.w("Checkout", "failed: ${e.code}")
    }
}

이 스니펫의 마이크로서비스 버전은 저장소 하나입니다. HTTP 서버, 컨테이너 빌드, 배포 매니페스트, 서비스 디스커버리, 헬스 체크, 대시보드, 온콜 순번이 결제 로직의 첫 줄을 쓰기도 전에 필요합니다.

서버리스 클라우드 함수 vs. 커스텀 마이크로서비스

마이크로서비스 문헌은 이 아키텍처의 이점이 자동화된 배포, 정교한 모니터링, 장애를 전제한 설계 같은 상당한 운영 성숙도를 대가로 얻어진다는 점을 분명히 밝힙니다. 함수는 바로 그 부담을 플랫폼에 넘기며, Mike Roberts의 서버리스 분석이 FaaS를 통제권을 내주고 운영 부담을 근본적으로 줄이는 거래로 규정하는 이유가 여기에 있습니다. 어느 거래도 공짜는 아니며, 관건은 팀이 어느 쪽의 대가를 감당할 수 있는가입니다.

요청에 실제로 일어나는 일

아래쪽 절반에는 위쪽 절반에서 표현할 수 없는 요소가 더해진다는 점에 주목해야 합니다. 서비스 간 호출, 서비스별 데이터 저장소, 게이트웨이가 그것이며, 마이크로서비스의 복잡성이 실제로 자리 잡는 곳이 바로 이 조정 영역입니다. 장바구니 서비스와 주문 서비스 사이의 분산 트랜잭션, 재시도, 부분 장애는 직접 작성해야 하는 코드입니다. 함수 모델에서는 같은 워크플로가 보통 함수 하나와 데이터베이스 하나이며, 이벤트 기반 요소(트리거, 예약 작업)는 직접 운영하는 큐가 아니라 플랫폼이 처리합니다.

함수가 마이크로서비스 집합을 대체하는 때와 대체할 수 없는 때

BaaS 패턴 뒤에 있는 솔직한 관찰은 이렇습니다. 전형적인 제품의 마이크로서비스 대부분은 얇습니다. 입력을 검증하고, 규칙을 적용하고, 데이터베이스를 읽거나 쓰고, 이웃 서비스를 호출합니다. 그 로직을 둘러싼 운영 껍데기가 무게의 90%입니다. BaaS 안의 클라우드 함수는 그 껍데기를 지웁니다. 데이터베이스, 인증, 파일 스토리지, API가 플랫폼 서비스이므로 각 “서비스”는 소수의 함수와 트리거로 축소됩니다. CRUD에 로직을 더한 제품을 출시하는 1–10명 규모의 팀에는 그 이상이 필요한 경우가 드뭅니다.

한계 역시 분명합니다. 함수는 특수 하드웨어가 필요한 추천 모델, 한 시간 동안 실행되는 비디오 트랜스코더, 커스텀 튜닝이 들어간 웹소켓 팬아웃 엔진, 지속적인 처리량 때문에 호출당 요금이 비싼 선택지가 되는 컴포넌트를 호스팅할 수 없습니다. 컴포넌트가 이 선을 넘으면 실제 서비스로 추출해 함수와 상호 운용하도록 하면 됩니다. 검증된 핫스팟을 추출하는 것은 너무 일찍 만든 추측성 집합을 분해하는 것보다 훨씬 저렴한 마이그레이션이며, 이는 모놀리스 우선 논거가 한 단계 위에서 가르치는 것과 같은 교훈입니다.

일반적인 사용 사례

• 함수: API와 모바일 백엔드. 관리형 데이터베이스 위에서 요청을 처리하는 로직입니다. 가장 대표적인 사례이며 BaaS 플랫폼이 처음부터 끝까지 패키징하는 바로 그 사례입니다.
• 함수: 트리거와 연결 작업. 저장 시 검증, 업로드 시 크기 조정, 서드파티 API 동기화, 야간 작업 실행. 전용 서비스로 만들기에는 민망할 만큼 짧게 끝나는 반응들입니다.
• 함수: 급증하거나 예측 불가능한 트래픽. 출시, 캠페인, MVP. 0으로 축소되는 특성이 급증과 한산한 시기를 모두 흡수합니다.
• 마이크로서비스: 지속적으로 무거운 컴포넌트. 검색, 피드, 가격 책정 엔진. 상시 가동 용량이 더 저렴하고 튜닝 가능한 꾸준한 부하입니다.
• 마이크로서비스: 특수 런타임. 비표준 언어, 네이티브 의존성, GPU, 장시간 실행 프로세스.
• 하이브리드. API 표면과 이벤트는 함수로, 수치가 요구하는 컴포넌트 한두 개는 추출한 서비스로.

함수와 마이크로서비스 중 무엇을 선택해야 할까? 결정 매트릭스

한계와 트레이드오프

• 함수: 실행 제한은 넘을 수 없는 벽입니다. 긴 작업은 작업 시스템이나 서비스로 옮겨야 합니다. 어떤 묘책도 타임아웃을 우아하게 늘려 주지 않습니다.
• 함수: 콜드 스타트와 체인. 호출당으로는 드물지만, 함수가 함수를 호출하는 아키텍처에서는 콜드 스타트가 누적됩니다. 핫 패스는 얕게 유지해야 합니다.
• 함수: 플랫폼 결합. 런타임과 그 API는 플랫폼의 것입니다. 셀프 호스팅할 수 있는 오픈소스 기반이 종속에 대한 실질적인 보험입니다.
• 마이크로서비스: 운영 청구서는 서비스 단위입니다. 파이프라인, 모니터링, 버전 관리되는 계약, 온콜이 집합과 함께 곱해집니다. 이를 과소평가하는 것이 전형적인 실패 양상입니다.
• 마이크로서비스: 분산 시스템 문제가 첫날부터 찾아옵니다. 네트워크 분할, 부분 장애, 서비스 간 일관성은 예외 상황이 아니라 아키텍처의 상수입니다.
• 양쪽 모두: 상태는 어차피 외부화됩니다. 함수는 이를 강제하고, 잘 운영되는 서비스는 이를 선택합니다. 어느 설계에서든 결국 신뢰할 수 있는 원본 데이터를 보관하는 것은 컴퓨팅이 아니라 데이터베이스입니다.

Back4app에서의 서버리스 함수와 마이크로서비스

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 이 비교의 함수 쪽을 통째로 제공하는 셈입니다. Cloud Code는 위의 checkout 같은 이름 있는 함수와 함께 데이터베이스 트리거, 예약 작업을 실행하며, 그 옆에는 마이크로서비스 집합이 맡았을 모든 기능이 이미 갖춰져 있습니다. 그래서 대부분의 제품이 만들었을 집합은 관리형 서비스 위의 함수가 됩니다. 그리고 기반이 오픈소스이고 셀프 호스팅할 수 있으므로 추출 경로는 열려 있습니다. 컴포넌트 하나가 함수 모델을 넘어서면 주변 플랫폼을 버리지 않고도 전용 서비스로 분리할 수 있습니다.