쉬운 설명
서버리스는 '서버가 없다'는 뜻이 아닙니다. 서버는 있지만 그 운영을 클라우드 사업자가 대신 해 준다는 뜻입니다. 개발자는 '이 요청이 오면 이 함수가 실행돼야 한다'만 정의하고, 그 함수를 어디에 어떻게 띄울지는 신경 쓰지 않습니다.
장점은 두 가지입니다. 첫째, 평소엔 자원이 안 돌아가니 트래픽이 적을 때 비용이 거의 0입니다. 둘째, 트래픽이 폭발해도 클라우드가 자동으로 함수를 수천 개 띄워 대응합니다. 그래서 사이드 프로젝트·간헐적인 작업·이벤트 기반 처리에 잘 맞습니다.
동작 흐름은 단순합니다. ① 함수 코드를 클라우드(AWS Lambda·Cloudflare Workers·Vercel Functions)에 업로드. ② 트리거(HTTP 요청·S3 이벤트·메시지 큐·cron)를 등록. ③ 트리거가 발생하면 클라우드가 함수를 띄워 실행하고 결과를 돌려준 뒤 함수를 종료. ④ 사용한 시간(ms 단위)과 메모리에 비례해 과금.
단점도 분명합니다. ① 콜드 스타트: 함수가 처음 띄워질 때 100ms~수초의 지연이 있습니다. ② 실행 시간 제한(보통 15분~30분). ③ 로컬에서 디버깅하기 까다로움. ④ 비용이 트래픽에 비례해 폭증할 수 있음. ⑤ 무거운 의존성·큰 파일이 들어가면 시작이 느려짐. 그래서 모든 워크로드에 서버리스가 맞지는 않습니다.
사용 사례가 잘 맞는 영역: 웹훅 처리(외부 시스템에서 이벤트가 오면 실행), 이미지·동영상 변환, 이메일·SMS 발송, 단순 API 엔드포인트, cron 작업, 챗봇 응답. 반대로 안 맞는 영역: 항상 켜져 있는 무거운 백엔드, 실시간 양방향 통신(WebSocket 일부), 큰 모델을 띄우는 ML 추론.
비유로 보면
서버리스는 호텔의 룸서비스와 비슷합니다. 평소엔 주방에 직원을 두지 않다가, 손님이 주문 버튼을 누르는 순간 자동으로 요리사가 나타나 음식을 만들고 가져다 주고 사라집니다. 손님이 적은 시간엔 인건비가 0에 가깝지만, 동시에 100명이 주문하면 100명의 요리사가 한꺼번에 나타납니다.
어디에서 만나나
웹훅 처리, 이미지·동영상 변환, 이메일·SMS 발송, IoT 이벤트 처리, 챗봇 응답, 간헐적 cron 작업, 사이드 프로젝트의 백엔드, 정적 사이트의 동적 부분(Vercel·Netlify의 함수). 트래픽이 들쭉날쭉한 거의 모든 작업에 잘 맞습니다.
작은 예시
회사 사이트에 '문의 폼이 제출되면 슬랙으로 알림을 보낸다'는 작은 기능을 만들 때, 24시간 도는 서버를 띄우는 건 과합니다. Lambda 함수로 만들면 폼이 한 달에 100건이든 1만 건이든 들어온 만큼만 실행되고, 비용은 몇십 원~몇천 원 수준입니다.
자주 하는 오해
한 줄 정리
서버리스의 진짜 가치는 '트래픽이 들쭉날쭉할 때 인프라 걱정을 안 한다'에 있습니다. 평소엔 0원, 폭주엔 자동 확장 — 작은 팀에 가장 큰 이득이 옵니다.