1. 서버리스란 무엇인가?
서버리스(Serverless)는 개발자와 인프라 엔지니어가 서버 관리의 부담에서 벗어나 애플리케이션 로직에 집중할 수 있게 해준다고 해요. 2014년 AWS Lambda의 출시와 함께 본격적으로 주목받기 시작했으며, 이는 클라우드의 Auto Scaling과 Event-driven 컴퓨팅 기술 발전의 결과물이기도 하죠.
서버리스의 핵심 특징
- Auto Scaling: 트래픽 부하에 따라 인스턴스가 자동으로 생성되고 제거됩니다.
- 관리형 인프라: 서버 프로비저닝, 패치 관리, 로드 밸런싱 등 인프라 운영 부담이 최소화됩니다.
- Event Driven: S3 업로드, API 호출, 메시지 큐 등 특정 이벤트가 발생하면 함수가 실행됩니다.
- 비용 효율성: 사용한 리소스만큼만 과금되는 Pay-as-you-go 모델로, 유휴 서버 비용이 없습니다.
인프라 관점 인사이트: 서버리스는 전통적인 VM 기반 인프라에서 벗어나 클라우드 제공자가 하드웨어와 운영체제 레벨을 추상화한 결과로, 인프라 팀의 역할이 "서버 관리"에서 "아키텍처 설계와 모니터링"으로 전환되고 있어요.
2. 서버리스의 대표적인 구현 방식
서버리스는 주로 FaaS(Function as a Service) 와 BaaS(Backend as a Service) 로 구현되는데요. 주요 클라우드 벤더별 서비스를 살펴보면 다음과 같아요.
| 서비스 | 제공 업체 | 주요 특징 |
|---|---|---|
| AWS Lambda | AWS | 다양한 이벤트 소스 트리거, 강력한 생태계 |
| Google Cloud Functions | GCP | Firebase와 연동 강점, NoSQL 친화적 |
| Azure Functions | Azure | .NET 개발자 친화적, Durable Functions 지원 |
| Cloudflare Workers | Cloudflare | 엣지에서 실행, 초저지연 응답 속도 |
FaaS vs BaaS
- FaaS: AWS Lambda처럼 개별 함수 단위로 코드가 실행되며, 인프라 엔지니어는 이벤트 트리거와 실행 환경만 신경 쓰면 됩니다.
- BaaS: Firebase나 AWS Amplify처럼 인증, 데이터베이스, API Gateway 등 백엔드 기능을 통합 제공해 인프라 설계를 단순화합니다.
FaaS는 단일 작업 단위에 최적화되어 있고, BaaS는 전체 백엔드 스택을 아우르니 프로젝트 요구사항에 따라 둘을 조합하는 하이브리드 접근도 가능해요.
3. 서버리스의 장점과 단점
✅ 서버리스의 장점
- 운영 부담 감소: 서버 프로비저닝, OS 패치, 네트워크 설정 등 인프라 유지보수가 필요 없습니다.
- 비용 절감: 사용량 기반 과금으로 유휴 리소스 비용이 없습니다.
- 확장성: 수평 확장이 자동으로 처리되어 트래픽 급등에도 안정적입니다.
- 빠른 개발: MVP(최소 기능 제품) 구축 속도가 빨라집니다.
- 이벤트 기반 설계: 실시간 데이터 처리와 같은 이벤트 드리븐 시스템에 적합합니다.
⚠️ 서버리스의 단점
- 콜드 스타트: 초기 요청 시 지연이 발생하며, Java나 .NET 같은 무거운 런타임에서 두드러집니다.
- 벤더 락인: 특정 클라우드 벤더의 생태계에 종속될 위험이 큽니다.
- 트랜잭션 관리: 상태 유지(Stateful) 워크로드에는 부적합합니다.
- 실행 시간 제한: Lambda의 경우 최대 15분으로, 장시간 작업에 제약이 있습니다.
- 모니터링 복잡성: 분산 환경에서 로깅과 디버깅이 더 까다롭습니다.
콜드 스타트는 프로비저닝된 동시성(Provisioned Concurrency)으로 완화할 수 있지만 추가 비용이 발생해요. 벤더 락인을 줄이려면 오픈소스 프레임워크(Serverless Framework 등)를 활용하는 것도 방법이 되겠네요.
4. 서버리스에 대한 흔한 오해
❌ 오해 1: “서버리스는 서버가 없는 것이다?”
서버리스는 “서버가 없는(Server-less)” 것이 아니라 “서버를 신경 쓰지 않아도 되는(Server-abstracted)” 아키텍처에요. 실제로는 클라우드 제공자의 서버에서 실행되지만, 인프라 관리를 우리가 직접 하지 않는다는 점이 핵심이죠.
❌ 오해 2: “서버리스는 항상 비용이 저렴하다?”
짧고 간헐적인 트래픽에서는 비용 효율적이지만, 지속적인 고부하 트래픽에서는 EC2 같은 전통 인프라가 더 저렴할 수 있어요.
- 예시: EC2 월 $30 고정 비용 vs Lambda 호출 횟수 증가 시 비용 상승.
❌ 오해 3: “모든 애플리케이션에 적합하다?”
이벤트 기반 시스템이나 API 백엔드에는 적합하지만, 고성능 컴퓨팅이나 상태 유지 애플리케이션에는 한계가 있어요.
❌ 오해 4: “서버리스면 DevOps가 필요 없다?”
여전히 배포 파이프라인, 모니터링(AWS X-Ray, CloudWatch), 보안 설정이 필요합니다. 인프라 팀의 역할이 "관리"에서 "최적화"로 바뀔 뿐이에요.
5. 서버리스를 도입해야 할 때와 피해야 할 때
✅ 도입에 적합한 경우
- 이벤트 기반 워크로드: 파일 업로드 후 자동 처리 등.
- 변동 트래픽: 크리스마스 시즌 같은 대규모 이벤트.
- 빠른 개발: 스타트업의 MVP 제작.
- IoT/실시간 처리: 센서 데이터 처리, 챗봇 등.
❌ 피해야 할 경우
- 고성능 컴퓨팅: 머신러닝 학습처럼 CPU 집약적인 작업.
- 장시간 작업: 배치 프로세싱(대안으로 ECS나 Batch 추천).
- 복잡한 트랜잭션: 상태 관리와 롤백이 중요한 시스템.
- 지속 고부하: Kubernetes로 컨테이너 오케스트레이션이 더 나음.
6. 내가 서버리스 아키텍처에 빠진 이유?!
최근 진행한 프로젝트들은 인증/인가부터 간단한 데이터 서빙, 저장 등 다양한 부분에서 서버리스 아키텍처 기반으로 설계하고 있어요.
특히, AWS Lambda, DynamoDB를 정말 잘 사용하고 있는데, Cognito 등 AWS에서 제공하는 다양한 서비스들과 연동하기도 편리하고 1인 개발을 할 때에 인프라 구축에 들어가는 비용을 절감할 수 있다는 점이 너무 좋은 것 같아요.
중요 비즈니스 로직, 유휴 시간이 상대적으로 짧은 서비스들은 EC2 내에서 돌리지만 나머지는 대부분 Function 형태로 분리해서 설계하고 있구요.
토이 프로젝트에서 가장 중요한 부분 중에 하나는 비용이잖아요? 사실, 우리가 간단하게 만드는 프로젝트는 대부분 무료 제공 할당량 내에 존재하기에 서버리스 서비스를 사용해도 비용이 들지 않는 장점도 있구요.
이렇게 좋고 편리한 서버리스 아키텍처도 만능이 아니라는 것에 대해서는 계속 염두해두고 사용 중이에요.
7. 결론: 서버리스는 강력하지만 만능은 아니다
서버리스는 인프라 관리 부담을 줄이고 빠른 개발과 확장성을 제공하는 강력한 도구에요. 하지만 콜드 스타트, 벤더 락인, 트랜잭션 관리의 한계를 고려해야 해요. 도입 전에는 다음을 점검하는게 좋을 것 같아요.
- 비용 분석: 트래픽 패턴에 따른 Lambda vs EC2 비교
- 성능 요구사항: 콜드 스타트 허용 범위 확인
- 운영 전략: 모니터링 및 배포 파이프라인 설계
적절히 활용하면 서버리스는 클라우드 환경에서 인프라 엔지니어와 개발자 모두에게 혁신적인 가치를 제공할 수 있다는 것은 분명하다고 생각해요.
토이 프로젝트를 생각하고 계신 분들, 이참에 서버리스 아키텍처로 도전해보시는 거 어때요?