"서버 용량 괜찮을까?", "트래픽 몰리면 어떡하지?", "OS 보안 패치는 언제 하지?" 백엔드 개발자라면 누구나 한 번쯤 서버 걱정에 밤잠을 설쳐본 경험이 있을 겁니다. 우리가 만든 코드를 세상에 선보이려면, 그 코드가 돌아갈 '집(서버)'을 구하고, 꾸미고(설정), 관리하는(운영) 수많은 잡일이 항상 따라다녔죠.
서버리스(Serverless) 는 이 지긋지긋한 서버 관리의 굴레에서 개발자를 해방시키기 위해 등장한 클라우드 컴퓨팅의 혁명입니다. 이름 때문에 "서버가 없다"고 오해하기 쉽지만, 사실은 "개발자가 서버에 대해 신경 쓸 필요가 없다" 는 의미에 가깝습니다.
서버리스란? 레고 블록처럼 쓰는 컴퓨팅 파워
서버리스를 이해하는 가장 좋은 방법은 전기를 사용하는 방식에 비유하는 것입니다. 💡 과거에 우리가 전기를 쓰려면, 집집마다 거대한 자가 발전기를 설치하고, 기름을 채우고, 주기적으로 정비해야 했습니다. 전기를 얼마나 쓸지 미리 예측해서 발전기 용량을 정하는 것도 큰일이었죠.
하지만 지금은 어떤가요? 우리는 그저 벽에 있는 콘센트에 플러그를 꽂기만 하면 됩니다. 전기가 어디서, 어떻게 만들어져서 우리 집까지 오는지는 전혀 신경 쓰지 않습니다. 그저 우리가 사용한 만큼만 전기 요금을 낼 뿐이죠.
서버리스가 바로 이와 같습니다. AWS Lambda, Google Cloud Functions, Azure Functions 같은 클라우드 제공업체가 거대한 '발전소(컴퓨팅 인프라)'를 운영하고, 개발자는 자신이 실행하고 싶은 코드 조각(함수)을 이 '콘센트'에 꽂기만 하면 됩니다. 코드가 실행될 때만 요금을 내고, 수억 명이 몰려도 클라우드가 알아서 순식간에 자원을 늘려줍니다.
무엇이 달라지는가? (Before vs. After)
기존 방식과 서버리스 방식의 차이는 개발자의 '관심사'가 어떻게 변하는지를 보면 명확해집니다.
👎 전통적인 서버 방식 (Express.js 예시)
// server.js
const express = require('express');
const app = express(); // 1. 웹 서버 프레임워크를 설정한다.
const port = 3000;
// 2. '/users/{id}' 경로로 요청이 오면 어떻게 처리할지 라우팅 규칙을 정한다.
app.get('/users/:id', (req, res) => {
const userId = req.params.id;
// ... 데이터베이스에서 유저 정보를 찾는 로직 ...
res.send({ id: userId, name: '홍길동' });
});
// 3. 24시간 365일 서버를 띄워놓고 요청을 기다린다.
app.listen(port, () => {
console.log(`서버가 ${port}번 포트에서 대기 중입니다.`);
});
// ※ 이 외에도 해야 할 일: 서버 구매/임대, OS 설치, 보안 설정, 트래픽 모니터링...
👍 서버리스 방식 (AWS Lambda 예시)
// getUser.js
// 개발자는 오직 '핵심 비즈니스 로직'에만 집중한다.
exports.handler = async (event) => {
// 라우팅, 서버 설정 등은 모두 클라우드가 알아서 해준다.
// 필요한 정보(id)는 event 객체를 통해 전달받는다.
const userId = event.pathParameters.id;
// ... 데이터베이스에서 유저 정보를 찾는 로직 ...
// 그냥 결과값만 반환하면 끝!
return {
statusCode: 200,
body: JSON.stringify({ id: userId, name: '홍길동' }),
};
};
서버를 만들고, 띄우고, 요청을 기다리는 모든 코드가 사라졌습니다. 개발자는 오직 "사용자 ID가 들어오면, 사용자 정보를 찾아서 돌려준다"는 가장 중요한 본질에만 집중하면 됩니다.
서버리스의 명과 암
이처럼 강력한 서버리스도 만능은 아닙니다. 장점과 단점이 명확하죠.
장점 (Pros) ✨
- 비용 효율성: 코드가 실행될 때만 (밀리초 단위로) 요금을 내므로, 트래픽이 거의 없는 서비스의 경우 비용을 극적으로 아낄 수 있습니다.
- 자동 확장/축소: 갑자기 트래픽이 폭증해도 자동으로 확장되고, 트래픽이 없으면 자원을 0으로 줄여줍니다.
- 운영 부담 감소: 개발자는 인프라가 아닌 코드에만 집중할 수 있어, 개발 속도가 빨라집니다.
단점 (Cons) 🤔
- 콜드 스타트 (Cold Start): 오랫동안 호출되지 않은 함수는 '잠들어' 있다가, 첫 호출 시 깨어나는 데 시간이 걸려 응답이 지연될 수 있습니다.
- 제한된 실행 환경: 실행 시간, 메모리 등 클라우드 제공업체가 정해놓은 제약이 있습니다. 아주 길고 무거운 작업을 처리하기엔 부적합할 수 있습니다.
- 상태 관리의 어려움: 각 함수는 독립적으로 실행되고 사라지므로, 여러 함수에 걸쳐 상태를 유지하기가 까다롭습니다. (별도의 DB 필요)
- 벤더 종속성 (Vendor Lock-in): AWS Lambda로 만든 코드를 Google Cloud Functions로 옮기려면 상당한 수정이 필요할 수 있습니다.
마치며
서버리스는 단순히 서버를 감추는 기술을 넘어, 소프트웨어를 만들고 배포하는 방식을 근본적으로 바꾸는 패러다임의 전환입니다. 모든 것을 서버리스로 만들 필요는 없지만, 이벤트 기반의 간단한 작업, API 게이트웨이, 데이터 처리 파이프라인 등 적재적소에 활용한다면, 비즈니스의 핵심 가치에 더 빠르게 집중할 수 있는 강력한 무기가 되어줄 것입니다. 🚀