[시리즈2: BaaS 할용하기] 서버리스 vs BaaS? 논쟁을 끝낼 ‘BaaS 내장 컴퓨트’ 활용 전략

서버리스(FaaS)로 모든 로직을 짜자니 아키텍처가 너무 파편화되어 번거롭고, 그렇다고 BaaS(Backend as a Service)만 쓰자니 복잡한 비즈니스 로직을 구현할 방법이 없어 답답했던 경험이 있으신가요?

BaaS와 서버리스를 “A냐 B냐”의 대결 구도로 보는 것은 현대적인 백엔드 설계를 이해하는 데 방해가 되곤 합니다. 오늘날의 BaaS는 단순한 데이터 저장소를 넘어, 서버리스의 영역인 컴퓨트(Compute) 기능을 내재화하며 진화했기 때문입니다.

이제는 "어느 것을 쓸까"가 아니라 "어디까지 BaaS 내장 기능을 쓰고, 언제 밖으로 뺄 것인가"를 고민해야 할 때입니다.

‍

1. BaaS는 이미 서버리스를 품고 있다

최근의 BaaS 플랫폼들은 DB·Auth·Storage 같은 상태(State) 레이어뿐만 아니라, 특정 로직을 실행할 수 있는 컴퓨트 레이어를 기본으로 제공합니다.

SkyReve BaaS: UI를 통해 파이썬 문법으로 직접 Function 작성 및 운영 기능 제공.
Supabase: 전 세계 Edge 네트워크에 배포되는 Edge Functions(TypeScript 기반) 제공.
Firebase: 이벤트 기반으로 동작하는 Cloud Functions 운영.
Appwrite / Nhost: 각각 Functions와 Serverless Functions를 통해 워크플로 처리 지원.
AWS Amplify: Lambda 기반 Functions로 복잡한 커스터마이징 대응.

따라서 우리는 아키텍처의 조합을 다음과 같이 3단계로 재정의할 수 있습니다.

BaaS (상태/정책): DB, Auth, Storage, 권한 제어(RLS/ACL 등)
BaaS 내장 컴퓨트 (내장 서버리스): Functions, 웹훅, 플랫폼 내 이벤트 핸들러
외부 서버리스 (확장 컴퓨트): 내장 컴퓨트의 사양이나 제약으로 인해 외부(AWS Lambda 등)로 분리한 경우

핵심 원칙:
"상태는 BaaS에 두고, 규칙은 컴퓨트로 처리한다. 이때 컴퓨트는 'BaaS 내장 기능'부터 우선 활용한다."

‍

2. 혼동하기 쉬운 두 개념: Realtime vs Events

BaaS 기능을 다루다 보면 '실시간 데이터 업데이트'와 '서버 측 로직 실행'을 혼동하는 경우가 많습니다. 이 둘은 목적지부터 다릅니다.

구분	역할	핵심 경험
Realtime (구독)	데이터 변경을 클라이언트에 동기화	실시간 UI 업데이트 (Sync)
Events/Functions	변경을 트리거로 서버 로직 실행	비즈니스 로직 및 외부 연동 (Action)

By distinguishing between "Realtime Sync" and "Server-side Event Execution (Functions)," you can significantly reduce communication overhead within your team.

‍

용어를 "Realtime(구독)"과 "서버 측 이벤트 실행(Functions)"으로 나누어 정의하면, 협업 시 의사소통 비용을 줄일 수 있습니다.

‍

3. "DB 업데이트는 누가 하는가?" 오해 바로잡기

BaaS 환경에서 대부분의 CRUD는 클라이언트가 직접 BaaS DB를 업데이트하는 것이 기본입니다. "서버리스가 DB를 대신 써준다"는 생각은 오히려 구조를 복잡하게 만듭니다.

그럼에도 컴퓨트(Functions)가 DB에 써야 하는 순간이 있다면, 그것은 'DB가 없어서'가 아니라 '신뢰와 정합성' 때문입니다.

오해: "모든 DB 쓰기는 서버리스 함수를 거쳐야 안전하다."
진실(1): "일반적인 CRUD는 권한 정책(RLS 등)을 통해 BaaS에서 직접 처리한다."
진실(2): "검증된 입력(예: 결제 완료 웹훅) 기반의, 서비스 역할 권한을 이용한 업데이트나, 복잡한 도메인 규칙이 필요한 경우에만 컴퓨트를 개입시킨다."

‍

4. 내장 컴퓨트 활용 시의 트레이드 오프

내장 기능을 우선하되, 아래와 같은 기술적 제약 사항(Trade-off)을 반드시 인지하고 있어야 합니다.

Cold Start 이슈: Edge Functions는 빠르지만, 복잡한 런타임을 사용하는 내장 함수(예: 이미지 처리용 라이브러리 sharp 호출)는 첫 호출 시 지연이 발생할 수 있습니다.
Vendor Lock-in: 플랫폼 전용 함수(예: Supabase Edge Functions)를 많이 사용할수록 나중에 다른 플랫폼으로 이주하기가 까다로워집니다.
리소스 제한: 대부분의 내장 함수는 실행 시간(Timeout)과 메모리 할당량에 엄격한 제한을 둡니다.

‍

5. 실전 가이드: 내장 컴퓨트 vs 외부 서버리스, 그리고 “결합” 선택 패턴

BaaS 중심 설계에서 중요한 건 “어느 쪽이 더 좋나”가 아니라, 내장 컴퓨트를 기본값으로 두고(디폴트), 외부 서버리스를 확장 옵션으로 결합하는 방식입니다. 아래 3가지 패턴으로 정리하면 빠른 판단이 가능합니니다.

패턴 A. BaaS 내장 컴퓨트로 끝내는 경우 (즉시성 + 단순성)

특징

빠르게 반응해야 하고
실행 시간이 짧고
플랫폼 제약(메모리/타임아웃/의존성)이 걸리지 않는 로직

예시

결제/구독 웹훅 처리: 외부 결제사(Stripe 등)의 신호를 받아 '서비스 전용 권한(Service Role)'으로 DB의 결제 상태를 즉시 업데이트할 때.
가입/권한 부여 후처리: 회원가입 직후 프로필 레코드를 생성하거나, 기본 설정을 저장하는 등 “DB 트랜잭션 중심” 작업.
외부 API 프록시: API 키를 숨기고 단순한 데이터 포맷만 변경하여 클라이언트에 전달하는 가벼운 게이트웨이 역할.

패턴 B. 외부 서버리스(확장 컴퓨트)로 넘어가야 하는 경우 (고성능, 긴 실행 시간)

특징

실행 시간이 길거나 CPU/메모리를 많이 쓰거나
네이티브/OS 의존 라이브러리, 대용량 처리, VPC 접근이 필요하거나
내장 런타임 제약이 기능적으로 막는 경우

예시

무거운 파일/이미지 프로세싱: Storage에 업로드된 대용량 영상을 인코딩하거나, 수백 장의 PDF를 병합하는 등 CPU 점유율과 실행 시간이 긴 작업. (BaaS 내장 함수의 타임아웃 제한을 넘을 때)
복잡한 비즈니스 로직 및 라이브러리 의존: 특정 OS 레벨의 라이브러리가 필요하거나, 수천 줄의 복잡한 연산 로직을 가진 도메인 엔진을 돌려야 할 때.
VPC 및 내부 인프라 연결: BaaS 환경 밖의 폐쇄망(VPC)에 있는 레거시 DB나 기업 내부 시스템에 안전하게 접근해야 할 때.

패턴 C. 내장 컴퓨트 + 외부 서버리스 결합 (가장 실전적인 확장 패턴)

특징

내장 컴퓨트는 ‘트리거/검증/오케스트레이션’을 맡고, 외부 서버리스는 무거운 작업을 맡습니다
즉, 안에서 결정하고 밖에서 일하는 구조입니다.

예시

“즉시 반응” + “비동기 처리” 분리
1. 클라이언트:
  - 사용자가 “리포트 생성” 버튼을 클릭
2. BaaS 내장 컴퓨트(Ochestrator):
  - 요청 검증/권한 체크
  - reports 테이블에 status=pending 레코드 생성
  - 외부 서버리스 호출을 위한 job_id 발급
  - 클라이언트에 즉시 200 (OK) 응답
3. 외부 서버리스(Worker):
  - job_id로 필요한 데이터를 DB/Storage에서 조회
  - PDF 생성/병합 등 무거운 작업 수행
  - 결과 파일을 BaaS의 Storage에 업로드
  - 동 외부 서버리스가 DB에 status=done과 result_url을 업데이트
4. 클라이언트:
  1. Realtime 또는 폴링으로 DB의 status=done 상태를 감지하고 다운로드 버튼 활성화

‍

다른 방법:
1) 기본은 Worker가 done을 기록합니다. 단, 외부 서버리스(Worker)에 DB 쓰기 권한을 주기 어렵다면 Worker는 콜백만 하고 done 기록은 내장 컴퓨트가 하도록 할 수 있습니다.
2) 대용량, 비용, 관리적 요건에 따라, Worker가 생성한 파일은 BaaS의 Storage가 아닌 S3 등 외부 객체 스토리지에 업로드하는 것도 가능합니다.

‍

마무리: 겹치는 영역을 활용하는 쪽이 이긴다

BaaS와 서버리스는 대립하는 기술이 아닙니다. 오히려 BaaS가 서버리스를 흡수하며 더 강력한 플랫폼으로 진화하고 있는 것이 현재의 흐름입니다.

가장 실전적인 아키텍처 결론은 이것입니다."Start Small, Scale Smart."

처음부터 거대한 외부 인프라를 구축하려 애쓰지 마세요. 상태는 BaaS에 맡기고, 규칙은 내장 컴퓨트부터 시작하세요. 그러다 서비스가 성장하여 내장 기능의 한계에 부딪히는 그 지점이, 바로 여러분이 밖으로 나갈 가장 완벽한 타이밍입니다.

‍