💡 핵심 인사이트
서버리스 DB는 개발자가 CPU나 메모리(인스턴스 크기)를 미리 예측하고 할당할 필요 없이, 트래픽이 폭주하면 수 초 만에 컴퓨팅 파워를 무한대로 늘리고, 사용자가 0명이면 DB를 완전히 재워버려(비용 0원) 비용과 확장을 100% 자동화한 클라우드 네이티브 DBMS입니다.
컴퓨팅(연산) 노드와 스토리지(저장소) 노드를 물리적으로 완벽히 분리했기 때문에 가능한 마법입니다. (대표작: Amazon Aurora Serverless)

Ⅰ. 기존 클라우드 DB의 한계 (Provisioned DB)

과거 클라우드 DB(예: AWS RDS)는 서버를 빌릴 때 "8코어 CPU, 32GB RAM짜리 DB를 띄워줘"라고 미리 스펙(Provisioning)을 정해야 했습니다.

• 낭비: 쇼핑몰 새벽 3시에는 접속자가 한 명도 없지만, 그 거대한 8코어 DB는 켜져 있으므로 똑같이 시간당 요금이 과금됩니다.
• 장애: 블랙프라이데이 세일로 접속자가 100배 폭증하면 DB CPU가 100%를 치고 터집니다. 급하게 DB 사이즈를 키우려면(Scale-up) DB를 껐다 켜야 하므로 서비스 중단(Downtime)이 발생합니다.

Ⅱ. 서버리스 데이터베이스의 아키텍처 혁신

서버리스 DB(Amazon Aurora Serverless 등)는 이 딜레마를 건축학적으로 해결했습니다. 핵심은 **컴퓨팅과 스토리지의 완벽한 분리(Decoupling)**입니다.

1. 스토리지 계층 (데이터 저장소)

• 데이터 파일과 트랜잭션 로그는 클라우드 벤더(AWS)가 관리하는 거대하고 무한히 늘어나는 분산 스토리지 클러스터에 안전하게 저장됩니다. 이 스토리지는 서버가 꺼져도 영구적으로 보존됩니다.

2. 라우터 / 프록시 계층 (Proxy)

• 애플리케이션(웹 서버)은 실제 DB 엔진에 직접 연결하지 않고, 앞단에 있는 똑똑한 '라우터 플릿(Proxy)'과 커넥션을 맺습니다.
• 트래픽 폭주 시 뒤에서 DB 엔진이 교체되더라도, 프록시가 커넥션을 물고 있기 때문에 클라이언트(앱) 입장에서는 DB가 재부팅되는 것을 전혀 눈치채지 못합니다. (Connection Drop 없음)

3. 컴퓨팅(연산) 노드의 동적 스케일링 (Auto-Scaling)

• 트래픽이 몰려와 CPU가 딸리기 시작하면, AWS는 옆에 준비해 둔 거대한(예: 32코어) 컴퓨팅 노드를 순식간에 띄웁니다.
• 이 거대한 노드에 분산 스토리지의 연결 선(Volume)만 딱 꽂아주고 트래픽을 넘깁니다. (스토리지 복사가 없으므로 스케일 업이 수십 밀리초(ms) 만에 일어납니다.)
• 반대로 접속자가 0명이 되면, 컴퓨팅 노드를 아예 0(Zero)으로 꺼버립니다. 이때 컴퓨팅 요금은 0원이 되고 싼 스토리지 보관 비용만 냅니다. (Cold Start 발생)

Ⅲ. 서버리스 DB의 활용 시나리오

• 가장 적합한 곳 (Unpredictable Workload):
  • 이벤트성 트래픽이 잦은 게임 런칭 초창기.
  • 낮에는 직원이 100명 쓰지만 밤과 주말에는 아무도 안 쓰는 사내 ERP 시스템 (퇴근 시 DB 과금 0원 쌉가능).
  • 트래픽 예측이 전혀 안 되는 초기 스타트업.
• 부적합한 곳: 24시간 내내 꾸준하게 높은 트래픽이 들어오는 대형 포털 사이트는 오히려 서버리스 요금제가 기존 고정형 DB보다 훨씬 비싸게 나옵니다.

📢 섹션 요약 비유: 기존 DB가 월세를 내고 임대하는 **'고정형 개인 창고'**라면, 서버리스 DB는 짐의 양에 따라 벽이 고무줄처럼 늘어났다 줄어들고, 짐이 하나도 없으면 방을 없애버리고 보관 수수료 0원을 청구하는 마법의 4차원 도라에몽 주머니입니다.