서버리스 컴퓨팅, 언제 쓰고 언제 피해야 하는가 — 장단점과 도입 판단 기준

서버리스는 서버를 미리 프로비저닝하지 않고 함수 단위로 코드를 실행하는 모델이다. 인프라 운영 부담을 걷어내는 대신, 콜드 스타트와 벤더 종속이라는 새로운 종류의 비용을 떠안는다. 도입 결정은 결국 이 트레이드오프를 감당할 워크로드인지 아닌지를 가리는 일이다.

함수 단위 실행이 바꾸는 것

서버리스는 사용자 측에서 서버 프로비저닝·패치·스케일링을 하지 않아도 되는 관리형 런타임 위에서 함수 단위로 코드가 실행되는 방식이다. 이벤트가 발생하면 구동되고, 요청량에 따라 자동으로 확장·축소된다. 구성은 크게 두 갈래로 나뉜다. FaaS(Function as a Service)는 코드를 함수 단위로 배포·실행하며 짧은 수명의 컨테이너를 관리형으로 운용하고, BaaS(Backend as a Service)는 인증·스토리지·메시징 같은 백엔드 기능을 API로 제공한다.

과금은 요청 수와 실행 시간, 메모리/CPU 사용량을 기준으로 매겨진다. 유휴 리소스에 대한 비용이 사실상 없어 버스트 트래픽 환경에서 경제성이 두드러진다. 다만 콜드 스타트 지연, 실행 시간·메모리 상한, 실행 환경 제약은 구조적으로 존재하고 제공자별 한도와 기능이 달라 최신 정보를 그때그때 확인해야 한다.

이벤트·트리거 아키텍처는 HTTP, 메시지 큐, 스케줄, 스토리지 이벤트 등 다중 트리거를 지원하며 이벤트 라우팅과 리트라이 정책으로 내결함성을 확보한다. 실행 수명주기는 콜드 스타트에서 웜 실행, 스케일 인/아웃으로 이어지는 구조가 반복되고, 동시성을 예약하거나 프로비저닝해두면 지연·처리량을 예측 가능한 범위로 관리할 수 있다.

함수는 무상태(stateless) 설계가 원칙이라 상태는 외부 스토리지나 DB에 위임해야 한다. 멱등성 키, 분산 잠금, 사가(Saga) 패턴으로 업무 일관성을 보장하는 게 일반적이다. 배포는 IaC 기반으로 버전을 관리하고 캐너리·블루그린 같은 점진적 롤아웃을 적용하며, 로그·메트릭·분산 트레이싱으로 지연·에러·스로틀링 가시성을 확보한다. 보안은 최소 권한 IAM, 비밀 관리, VPC/프라이빗 링크 같은 네트워크 경계로 다루고, 멀티테넌시와 데이터 지역성 규제도 함께 고려 대상이다.

언제 유리한가

가격 효율성이 첫 번째 이유다. 사용량 기준 과금으로 유휴 리소스 비용이 사라지고, 버스트형 트래픽에서는 TCO를 2060% 절감할 수 있다(워크로드·지역·요금제에 따라 변동). 애플리케이션 품질에 집중할 수 있는 환경도 장점이다. 인프라 운영·패치 부담이 줄어 피처 개발 속도가 올라가고, 표준화된 배포 파이프라인·테스트 자동화와 결합하면 릴리스 리드타임이 단축되며 온보딩 시간을 3050% 단축할 수 있다. 가용성과 유연성 역시 강점이다. 다중 AZ/리전 기반 가용성과 자동 복구 메커니즘이 기본 제공되고, 이벤트 기반 확장으로 수요 변동에 대응하기 쉽다.

감수해야 할 것들

반대편에는 세 가지 비용이 있다.

콜드 스타트로 인한 지연이 가장 자주 부딪히는 문제다. 런타임 초기화·컨테이너 기동 비용 때문에 p95 지연이 늘어날 수 있고, 네트워크나 VPC에 연결하는 함수는 추가 오버헤드까지 붙는다. **공급자 종속(Vendor Lock-in)**도 무시하기 어렵다. 트리거·권한·관측·워크플로가 관리형 서비스에 깊이 결합될수록 이전 비용이 커지고, 멀티클라우드나 온프레미스로의 이식성이 떨어진다. 장시간·고성능 워크로드에서는 비효율이 드러난다. 1회 호출 시간과 메모리 제한 때문에 배치·스트리밍·ML 트레이닝 같은 작업은 애초에 맞지 않고, 지속 연결이나 세션 유지가 필요한 워크로드도 비효율적이다.

세 문제 모두 완화할 방법은 있지만, 완화 자체가 트레이드오프를 동반한다. 콜드 스타트는 프로비저닝 동시성이나 최소 인스턴스를 두고 Go·Node.js 같은 경량 런타임과 슬림한 번들을 쓰면 줄일 수 있지만, 그만큼 리소스를 상시 예약하는 비용 증가와 경제성 저하를 감수해야 한다. 공급자 종속은 OpenAPI 같은 표준 API, 표준 메시징, Terraform 같은 IaC, 포트/어댑터 추상화 계층으로 최소화할 수 있는데, 그 대가로 관리형 고급 기능을 못 쓰는 생산성 손실이 따라온다. 장시간 작업은 스텝 함수·워크플로, 큐·배치·컨테이너로의 오프로딩, 청크 처리와 사가 보상 트랜잭션으로 우회할 수 있지만 아키텍처 복잡도와 운영 포인트가 늘어난다.

실무에서 쓰는 패턴

API 게이트웨이 뒤에 함수를 붙여 웹훅과 API 백엔드를 처리하는 구성이 가장 흔하다. 캐싱·멱등성 처리·레이트리밋으로 안정성을 확보하는 게 관건이다. 오브젝트 스토리지 이벤트를 트리거로 데이터를 변환해 웨어하우스에 적재하는 데이터 파이프라인·ETL도 대표적인 패턴인데, 실패 재시도와 데드레터큐, 스키마 검증이 신뢰성을 좌우한다.

크론 트리거로 리포트를 생성·배포하는 스케줄드 작업에서는 실행 시간 한도를 넘길 때 작업을 분할하고 체크포인팅하는 설계가 필요하다. IoT·결제 같은 실시간 이벤트 처리에서는 메시지 브로커가 함수를 호출해 집계·검증하고 알림이나 DB를 업데이트하는데, 멱등 처리와 트랜잭션 경계 분리로 데이터 정합성을 지켜야 한다. 이미지·문서 업로드를 트리거로 변환이나 경량 ML 추론을 수행해 CDN으로 배포하는 패턴에서는 동시성 제한과 비용 상한으로 폭주를 제어하는 게 실무 포인트다.

컨테이너·VM과 비교하면

항목	서버리스	컨테이너(Kubernetes)	가상머신(전통 IaaS)
성능(지연)	콜드 스타트 시 가변, 웜 상태 우수	안정적, 튜닝 여지 큼	예측 가능하나 과도 프로비저닝 위험
확장성	자동 확장, 버스트 강점	HPA/오토스케일로 유연	수동/정책 기반, 속도 제한
일관성/트랜잭션	외부화·사가 패턴 필요	서비스 간 트랜잭션 설계 용이	모놀리식·DB 중심 트랜잭션 용이
안정성/가용성	AZ 분산 기본 제공	설계·운영 품질에 의존	설계·운영 품질에 의존
운영 편의	인프라 추상화로 간편	클러스터 운영 복잡	OS·미들웨어 전담 필요

요청이 함수 실행까지 흐르는 경로

⤢✕

도입 판단 기준

이벤트 구동형이고 실행이 짧으며 트래픽이 불규칙한, 빠른 출시가 필요한 환경이라면 서버리스가 적합하다. 반대로 콜드 스타트·공급자 종속·장시간 처리 비효율은 도입 전에 반드시 따져야 할 항목이고, 동시성·멱등성·관측성·보안을 포함한 운영 표준을 함께 마련해야 한다.

실무적으로는 API·이벤트 처리와 스케줄 작업부터 점진적으로 도입하고, 장시간·고성능 워크로드는 컨테이너나 배치로 분리하는 하이브리드 아키텍처를 권장할 만하다.