서버 없이 시작하는 서비스

1. 서버는 있는데 안 보일 뿐입니다

서버리스(serverless)라는 이름은 조금 과장입니다. 서버는 여전히 어딘가에서 돌아가고, 우리가 직접 빌리고 관리하지 않을 뿐이죠. 이 방식이 널리 알려진 건 2014년 11월 AWS가 리인벤트(re:Invent)에서 람다(Lambda)를 발표하면서부터입니다. 요청이나 이벤트가 들어올 때만 코드가 실행되고, 일이 끝나면 사라집니다. 서버를 켜 두고 관리하고 트래픽에 맞춰 늘리는 일은 클라우드 회사가 맡고요. 요즘은 버셀(Vercel)과 클라우드플레어 워커스(Cloudflare Workers) 덕분에 프론트엔드 개발자에게도 가까워졌습니다. Next.js 프로젝트를 버셀에 올리면 API 경로가 따로 설정하지 않아도 함수로 배포되니까요.

2. 쓴 만큼만 내는 요금, 그리고 첫 요청의 기다림

가장 큰 매력은 요금입니다. 람다는 매달 요청 100만 건과 40만 GB초의 실행 시간을 무료로 주고, 그 뒤로는 요청 100만 건당 0.2달러에 실행 시간만큼 받습니다. 방문자가 적을 땐 거의 돈이 들지 않고, 이벤트 페이지처럼 트래픽이 갑자기 튀어도 알아서 늘어납니다. 대신 콜드 스타트라는 대가가 있습니다. 한동안 쉬던 함수는 첫 요청이 오면 실행 환경을 새로 띄우느라 응답이 늦어집니다. 회사마다 푸는 방식도 다릅니다. 워커스는 컨테이너 대신 V8 엔진의 아이솔레이트를 써서 시작 시간을 몇 밀리초 수준으로 줄였고, 기다린 시간이 아니라 CPU를 실제로 쓴 시간에만 요금을 매깁니다. AWS는 미리 데워 둔 환경을 유지하는 옵션을 따로 팝니다.

3. 그래도 진짜 서버가 나은 순간

서버리스가 만능은 아닙니다. 람다 함수 하나는 최대 15분까지만 실행되니 긴 영상 변환이나 대용량 데이터 처리는 쪼개거나 다른 곳으로 보내야 합니다. 실시간 채팅처럼 연결을 오래 붙잡아 두는 기능도 까다롭고, 함수가 동시에 수백 개씩 뜨면 데이터베이스 연결 수 한도에 부딪히기도 합니다. 트래픽이 늘 꾸준히 많다면 고정 요금 서버가 더 싸게 먹히기도 하고요. 그런데 요즘은 서버리스 쪽이 점점 서버를 닮아 갑니다. 버셀은 2025년 4월부터 새 프로젝트에 플루이드 컴퓨트(Fluid compute)를 기본으로 켜서, 인스턴스 하나가 여러 요청을 함께 처리하게 바꿨습니다. 소개 글 제목부터 '서버의 힘을 서버리스의 형태로'였죠.

4. 세컨드펭귄의 시선: 하나를 고르기보다 섞어 씁니다

지금 보고 계신 이 블로그는 사실 서버 위에서 돌아갑니다. 글과 이미지를 관리하는 Strapi는 데이터베이스와 업로드 파일을 계속 붙들고 있어야 해서, Docker로 묶어 우리 서버에 올려 두었죠. 반면 캠페인 기간에만 잠깐 열리는 랜딩 페이지나 문의 폼 하나를 처리하자고 서버를 한 대 더 띄우는 건 낭비에 가깝습니다. 이럴 땐 서버리스 함수가 훨씬 가볍습니다. 그래서 우리는 기술부터 정하지 않고 몇 가지를 먼저 묻습니다. 트래픽이 꾸준한지 들쭉날쭉한지, 한 번 실행에 얼마나 걸리는지, 상태를 오래 기억해야 하는지, 오픈한 뒤에는 누가 운영할지. 답에 따라 한 프로젝트 안에서 서버와 서버리스를 섞어 쓰는 경우가 오히려 흔합니다.