서버가 필요하다는데, 서버가 뭔데?
Cursor로 웹앱을 뚝딱 만들었다. Vercel에 올리니 페이지도 잘 뜬다. 그런데 문의 폼을 달려고 하면 갑자기 "서버가 필요합니다"라는 말이 튀어나온다. 서버? 그게 대체 뭔데?
정리하면 이렇다. 웹사이트에서 보여주기만 하는 것, 페이지나 이미지, 텍스트 같은 것은 서버 없이도 된다. 정적 파일을 CDN에 올려놓으면 그만이다. 하지만 뭔가를 처리해야 하는 순간이 오면 이야기가 달라진다. 폼 데이터를 저장하거나, 로그인을 확인하거나, 외부 API를 호출할 때. 이런 코드를 실행할 컴퓨터가 필요하다. 그 컴퓨터가 서버다.
여기서 두 갈래로 나뉜다.
첫 번째는 식당을 차리는 방법이다. AWS EC2나 VPS를 빌려서 서버를 직접 세팅한다. 운영체제 설치, 보안 패치, 트래픽 관리를 전부 내가 맡는다. 손님이 한 명도 안 와도 임대료는 매달 나간다.
두 번째는 공유 주방을 쓰는 방법이다. 요리할 때만 주방을 빌리고, 쓴 시간만큼만 돈을 낸다. 주방 설비 관리, 청소, 가스비 정산 같은 건 주방 업체가 알아서 한다. 주문이 갑자기 100건 들어와도 걱정할 것 없다. 옆 주방까지 열어준다. 이게 서버리스다.
"서버리스"라는 이름 때문에 서버가 아예 없다고 오해하기 쉽다. 서버는 있다. 다만 내가 신경 쓸 일이 없을 뿐이다. 나는 코드만 올리면 된다. 서버 세팅, 트래픽 확장, 장애 대응은 클라우드 업체 몫이다.
사실 이미 서버리스를 쓰고 있을 수도 있다
서버리스가 낯설게 느껴질 수 있는데, Vercel에 Next.js 앱을 올려본 적이 있다면 이미 써본 거다.
Next.js의 API Routes, app/api/ 폴더에 만드는 그 파일들이 서버리스 함수다. 요청이 들어오면 Vercel이 서버를 깨워서 코드를 실행하고, 끝나면 다시 꺼둔다. 서버를 직접 세팅한 적이 없는데 백엔드 코드가 돌아갔다면, 그게 서버리스 덕분이다.
바이브 코더가 서버리스를 만나는 상황은 대체로 네 가지쯤 된다.
문의 폼 처리. 사용자가 입력한 내용을 이메일로 보내야 하는데, API 키를 브라우저에 노출할 수 없으니 서버 쪽에서 돌려야 한다. 로그인과 회원가입. 비밀번호 검증이나 세션 관리처럼 민감한 처리는 서버에서 해야 안전하다. AI 기능 연동. OpenAI API 키를 숨기면서 호출하려면 서버 쪽 코드가 필수다. 정기 작업. 매일 아침 데이터를 긁어오는 크론잡도 서버리스 함수로 돌릴 수 있다.
이 모든 경우에 EC2를 빌려서 서버를 세울 필요가 없다. 서버리스 함수 하나면 충분하다. Vercel이 그걸 몰래 해주고 있었을 뿐이다.
Lambda, Workers, Vercel Functions: 뭘 고를까
서버리스 함수를 제공하는 플랫폼은 여럿인데, 바이브 코더가 마주칠 가능성이 높은 세 가지만 놓고 보자.
Vercel Functions. Next.js를 쓰고 있다면 이미 손에 들고 있는 셈이다. app/api/ 폴더에 파일 하나 만들면 알아서 서버리스 함수가 된다. 따로 설정할 것도 없고, git push 한 번이면 배포까지 끝난다. 처음 시작하는 사람에게 진입 장벽이 가장 낮다. 무료 범위는 월 10만 호출.
Cloudflare Workers. 속도와 가격이 강점이다. 서버리스 함수 대부분은 한동안 호출이 없으면 잠든 서버를 다시 깨우는 시간(콜드 스타트)이 생기는데, Workers는 V8 isolate라는 방식 덕분에 이 시간이 사실상 없다. 데이터를 저장할 KV나 D1, 파일을 담을 R2 같은 부속 도구도 잘 갖춰져 있어서 프론트엔드 없이 API만 빠르게 만들고 싶을 때 제격이다. 무료 범위는 하루 10만 요청.
AWS Lambda. 셋 중 가장 강력하고, 셋 중 가장 복잡하다. AWS가 가진 수십 가지 서비스(파일 저장 S3, 데이터베이스 DynamoDB, 메시지 큐 SQS 등)와 자유롭게 연결할 수 있다. 대신 시작부터 IAM으로 권한을 세팅하고 API Gateway로 요청을 라우팅해야 한다. 첫 서버리스 경험으로 잡기엔 허들이 높다. 무료 범위는 월 100만 요청.
그래서 뭘 골라야 하냐고? 간단하다.
Next.js를 쓰고 있다면 Vercel Functions부터 시작한다. 이미 쓰고 있을 확률이 높다. 프론트엔드 없이 가벼운 API만 필요하다면 Cloudflare Workers가 빠르고 무료 한도도 넉넉하다. AWS의 다른 서비스(S3, DynamoDB 등)와 묶어야 하는 상황이라면 Lambda 외에 선택지가 없다. 복잡하지만 그만큼 할 수 있는 게 많다.
비용이 걱정된다면 너무 앞서간 거다. 사이드 프로젝트 수준, 하루 방문자 100명 안팎이라면 세 곳 모두 무료 범위 안에서 충분히 돌아간다.
자주 걱정하는 것 세 가지
"요금 폭탄 맞으면 어쩌지?"
사이드 프로젝트에서 무료 한도를 넘기기가 오히려 어렵다. 월 100만 요청이면 하루 약 33,000번 호출인데, 개인 프로젝트에서 이 숫자를 찍기란 쉽지 않다. 그래도 불안하면 요금 알림을 걸어두면 된다. AWS에는 Budget Alert, Vercel에는 Spend Management가 있다. 진짜 조심할 건 코드 안에서 무한 루프가 도는 경우인데, 이건 배포 전에 로컬에서 한 번만 테스트해도 막을 수 있다.
"콜드 스타트가 느리다던데?"
콜드 스타트는 서버리스 함수가 한동안 호출되지 않았다가 다시 깨어나는 시간이다. 공유 주방에 도착해서 문 열고 가스불 켜는 시간쯤 되겠다. Cloudflare Workers는 구조 자체가 달라서 이 시간이 거의 없다. Lambda는 짧으면 100ms, 길면 수 초까지 걸릴 수 있지만 일반적인 웹 앱에서 사용자가 "느리다"고 체감할 정도는 아니다. 실시간 채팅처럼 밀리초 단위 반응이 필요한 게 아니라면 크게 신경 쓰지 않아도 된다.
"서버리스는 소규모에서만 쓰는 거 아닌가?"
Netflix도, Coca-Cola도 서버리스를 쓴다. 트래픽이 갑자기 치솟을 때 자동으로 서버가 늘어나니까 오히려 대규모 서비스에 유리한 면도 있다. 규모 걱정은 규모가 실제로 커졌을 때 해도 늦지 않다.
세 줄 요약
서버리스를 처음 접하는 바이브 코더라면 이것만 기억하자.
무료 티어 한도를 먼저 확인하고 시작한다. 세 플랫폼 모두 개인 프로젝트에는 넉넉하다. 요금 알림은 반드시 켜둔다. 예상치 못한 과금을 막는 가장 확실한 안전장치다. 그리고 처음에는 Vercel이나 Workers로 시작한다. Lambda가 필요해지면 그때 옮겨도 늦지 않다.
여기까지 읽었으면 서버리스가 뭔지, 어디서 만나는지, 뭘 골라야 하는지 감이 잡혔을 거다. 서버리스를 이해했다는 건, 프론트엔드에만 머무르지 않고 백엔드 쪽에 한 발을 내디딘 셈이다. 생각보다 별거 아니다.