서버리스는 사기다: 그냥 컨테이너 쓰세요
(sliplane.io)- 서버리스는 간편해 보이지만 실제로는 복잡성, 제약, 고비용을 유발하는 구조임
- 컨테이너는 이식성, 상태 유지, 명확한 제어를 제공하며 대부분의 사용 사례에 더 적합함
- 서버리스는 비용 구조가 불투명하고 예측 불가능하며, 구성 요소 간 불필요한 복잡성을 초래함
- 서버리스의 확장성과 간편성은 제한적인 사용 사례에만 적합함
- 실제 운영환경에서는 컨테이너 기반 배포가 단순하고 확장 가능하며 비용 효율적임
Serverless Is a Scam. Just Use a Container.
서버리스란 무엇인가?
- 서버리스는 개별 함수 단위로 코드를 배포하여, 클라우드 플랫폼이 실행 및 스케일링을 자동 처리하는 방식임
- 그러나 실제로는 다음과 같은 문제들이 존재함
- 실행 시간 제한 (예: AWS Lambda는 15분 제한)
- 상태 유지 불가 (매 실행마다 초기화)
- 콜드 스타트 문제
- 디버깅 불가능한 환경
- 플랫폼별 설정 및 구성
- 과도한 YAML 사용
- 간단해 보이지만, 복잡한 작업에는 부적합
컨테이너: 단순하고 강력하며, 좋은 의미에서 지루함
- 컨테이너는 다음과 같은 장점이 있음
- 빠른 시작
- 어느 환경에서나 실행 가능
-
상태 유지 가능 (
Docker volume사용) - 실행 시간 제한 없음
- 디버깅, 로컬 개발, 운영 환경 전환이 자유로움
- 예시 코드:
docker run -v my-data:/data my-app - 결과적으로 상태를 가진 워크로드를 어디서든 일관되게 실행 가능
- 벤더 종속성 없음, 숨겨진 비용 없음, 불필요한 구조 변경 없음
서버리스 가격 책정: 사용자 혼란을 유도함
- 서버리스 비용은 매우 복잡하게 구성됨
- 호출당 비용
- 메모리 사용량
- 실행 시간
- 전송된 데이터량
- 리전별 차등
- 비밀 키 접근 비용 등
- 혼란을 주는 용어 예시:
- Provisioned Concurrency Units
- GB-seconds
- Requests Tier 1/2/3
- 예측 불가능한 과금 구조로 인해 예상치 못한 고지서 발생 가능
- 비교: $5 VPS는 예측 가능한 정액 요금으로 모든 자원 제어 가능
“서버리스는 확장 가능하다”에 대한 반론
- 서버리스는 기술적으로 확장 가능하지만, 실제로 대부분의 앱은 필요 없음
- 대부분의 애플리케이션이 필요로 하는 것은 다음과 같음
- 예측성
- 모니터링 가능성
- 적절한 자원 제한
- 개발 및 스테이징 환경
- 컨테이너 기반에서는 확장도 간단함
replicas: 5 - 혹은 로드 밸런서 사용으로 수평 확장 가능
무상태 설계는 인위적인 문제를 만듦
- 서버리스는 무조건 무상태 설계를 강요함
- 캐시, 세션, 임시 파일, 지속 연결 불가
- 결과적으로 필요한 요소:
- 외부 데이터베이스
- 분산 캐시
- 파일 스토리지
- 이벤트 버스
- 상태 머신
- 결국 “단순한” 서버리스 앱이 6개 이상의 SaaS 종속성을 가지게 됨
- 반면, 컨테이너에서는 다음이 가능함
- 메모리 캐시
- 디스크 쓰기
- 세션 유지
- 무제한 실행
“서버를 관리하고 싶지 않다”에 대한 답변
- 서버 관리 없이 컨테이너 기반 플랫폼을 사용할 수 있는 방법이 존재함
- Sliplane, Railway, Coolify 등 플랫폼 사용
- 단순히 VPS에서 Docker + systemd만으로도 가능
- Git 기반 배포, 롤백, 로깅, 메트릭 등 운영 편의성 보장
- 시스템 전체에 대한 이해와 제어 가능
“서버리스가 더 저렴하다”는 주장에 대한 반론
- 극히 낮은 호출 빈도에서는 저렴할 수 있음
- 하지만 아래 상황에서는 비용 급증
- 트래픽이 일정 이상일 경우
- 메모리 증가 필요 시
- 실질적인 연산이 많을 경우
- 데이터 전송이 많은 경우
- 서버리스는 플랫폼이 모든 것을 숨기기 때문에 최적화 어려움
- 반면, 컨테이너는
- 저렴한 하드웨어에서도 지속 실행 가능
- 캐시 및 저장소와 병합 가능
- 벤치마크 및 튜닝이 쉬움
- 밀리초 단위 요금 없음
서버리스가 실제로 적합한 경우
- 다음과 같은 간헐적이고 상태 없는 작업에 적합
- 이벤트 기반 함수 (예: 이미지 리사이징)
- 드물게 실행되는 작업이나 웹훅
- 내부 도구
- POC
- 빠른 스케일 업/다운이 필요한 경우
- 그러나 실제 애플리케이션에서는 한계에 부딪히고,
- 시간, 비용, 복잡도에서 큰 대가를 치르게 됨
컨테이너가 더 나은 선택인 이유
- 컨테이너는 다음을 제공함
- 이식성
- 제어력
- 단순성
- 투명성
- 유연성
- 단일 또는 다중 컨테이너 배포, 스케일링, 상태 유지, 백그라운드 작업, DB 연동 모두 가능
- 코드를 재작성할 필요 없이 플랫폼 이전도 가능
요약 (TL;DR)
- 서버리스는 이론상 멋져 보임
- 현실에서는:
- 불투명
- 고비용
- 과도한 복잡성
- 과대홍보
시작하기 전 스스로에게 물어보라:
“이걸 그냥 컨테이너로 만들 수 없을까?”
- 답이 ‘예’라면, 컨테이너로 시작하는 것이 더 나은 선택
후속 행동 권장
- 서버리스로 인해 예상치 못한 비용, 비효율적인 워크플로우를 겪은 사례 공유 권장
- 단순한 문제를 과도하게 복잡하게 만들지 말 것
과거 PHP 웹호스팅 서비스들에서, PHP를 빼고 벤더락 왕창 들어간 JS를 넣으면....
대표적인 서버리스 FaaS 플랫폼들과 구분하기 힘들 것 같다는 생각을 떨칠수가 없습니다.
물론 PHP와 JS/TS를 주로 사용하는 똥1믈리에인 저는 만족스럽게 활용하고 있지만,
그렇다고 많은 사람들이 이걸 맛있다 평가하는 이유는 잘 모르겠네요.
개발 경험이 네이티브에 비해 현저히 떨어지는 게 너무 큰 pain point이고, 소프트웨어 자체가 인프라 제공자에 의존성이 생기니 한번 자리 잡으면 탈출하기가 어려워집니다. 레퍼런스가 확연히 적은 것은 물론이고 관찰 가능성이 너무 떨어집니다.
클라우드플레어가 그나마 다른 회사들에 비해 서버리스를 잘 해보려는 것 같습니다. 데이터베이스도 서버리스, 키밸류 스토리지도 서버리스, 심지어 메세지 큐도 서버리스가 있고...
(물론, 이렇게 되다보면 플랫폼에 완전히 종속되고 구속되는 것 같아 거부감이 느껴지기도 합니다)
그럼에도 불구하고 디버깅, 관찰 가능성 및 개발 경험이 개선되지 않는다면 여전히 제자리 걸음일 것 입니다.
개인적인 생각으로는 벤더의 서버리스 서비스를 이용하는 건 위험하지만, 컨테이너를 이용해서 회사 자체적으로 서버리스 환경을 제공하는 건 좋은 것 같습니다. 서버리스를 서비스가 아닌 하나의 개념으로 활용하면 좋을 거 같네요.
컨테이너 기반 환경(ECS Fargate 중심, 쿠버네티스 클러스터)과 서버리스 환경(AWS) 모두 경험한 입장에선 크게 와닿진 않네요.
컨테이너 기반 환경의 장점이라고 나열한 사항들은, 장점이자 동시에 단점이 될 수도 있는 부분들입니다.
'직접 제어 가능하고 상태를 가질 수 있다'며 언급한 부분들 모두 관리 포인트가 되어 운영 난이도가 높아진달까요.
저는 소규모 조직, 전문적인 서버 관리 팀이 없는 조직일수록 서버리스를 강력히 추천하네요.
아, 비용 계산이 복잡하거나 예상하기 힘들다는 점, 그리고 벤더락 문제는 동의합니다.
개발경험과 관측가능성을 말씀하시는 분이 계셔서 덧붙이자면,
초기 통합 환경만 잘 구성해놓으면 컨테이너 기반 못지 않은, 어쩌면 컨테이너 기반보다 더 네이티브에 가까운 개발경험도 가져갈 수 있습니다. (이를 위한 다양한 툴들이 있고요)
관측가능성이야 딥하게 하겠다면 서버리스나 컨테이너기반이나 똑같이 쉬운 문제가 아닙니다. 로그 중앙 집중화, 각종 매트릭 시각화, APM, cpu/memory 사용률 시각화와 그에 따른 스케일링 전략 세우기 등등...
그 정도 단계가 아니라면, 클라우드 벤더가 기본적으로 제공하는 매트릭/로그통합이 강력해서 거기서 거기고요.
어그레시브하게 표현하자면, '서버리스 어느정도까지 제대로 해봤는데?' 묻고 싶네요...😅
일부 필요한 엔드포인트만 람다에 띄우는 게 낫지 않나 싶기도 한데요. 애초에 저는 서버리스 개발 경험이 없어서 뭐라 말은 못하겠지만, 특수한 몇몇 케이스에는 좋을 것 같아보이긴 해서요.
전에도 프론트엔드 쪽에서 nextjs(vercel)에 대해 우려하는 netlify (경쟁사) 개발자의 글을 의심하시는 분이 계셨었죠. 댓글을 보면 편향되진 않은것 같습니다.
저는 프론트엔드 쪽이라... 이쪽과 친하진 않은데 서버리스(서버있음) 이라는 밈은 자주 본거 같긴 합니다 ㅎ
Hacker News 의견
- 서버리스는 초기 작은 프로젝트에는 좋았지만, AWS Lambda는 큰 애플리케이션에서는 유지보수 지옥임 (빌드, 의존성, 디버깅, 배포 느림 등)
- 그럼에도 2019년에 배포한 Lambda 기반 리액트 웹앱이 아직도 아무 변경 없이 작동 중이라는 점은 인상적임
- 유지보수 문제는 프레임워크 때문이라는 반론도 있으며, 모듈형 설계와 로컬 개발을 병행하면 대부분 해결 가능
- Lambda는 종종 런타임 업데이트가 필요하며, 이는 오랫동안 문제 없다가 갑자기 중단되는 형태로 나타날 수 있음
- 의존성이 적다면 업데이트는 쉽지만, 오래된 런타임에 의존하는 경우 미리 준비하는 것이 중요함
- 서버리스는 간헐적이고 상태 없는 워크로드에 적합하며, 내부/외부 JSON API에 잘 맞음
- 하지만 지나친 감성적 서술보다는 서버리스가 전가의 보도가 아님을 명확히 설명했으면 더 좋았을 것이라는 의견
- 서버리스는 자체 복구력이 좋고, 상태를 갖는 시스템(컨테이너 등)보다 운영 부담이 적음
- 그럼에도 컨테이너의 개발 모델이 더 낫다는 의견도 있음 — 어디서든 실행 가능하지만, 상태 관리와 확장성에 한계 존재
- 컨테이너는 본질적으로 상태를 갖지 않으며, 상태를 추가할 수 있을 뿐임
- 큰 조직에서는 결국 Kubernetes(K8s)가 표준이 되고, 이는 컨테이너의 간결함과는 거리가 있음
- K8s도 플랫폼 팀이 있다면 단순하게 운영 가능하나, 그런 환경은 드물다는 지적
- GCP Cloud Run은 저평가된 서버리스 플랫폼으로, 사용 시점 기준으로만 비용을 청구해 경제적임
- AWS Lambda에서 Postgres 연결이나 bcrypt 사용은 가능하지만, 설정과 실행이 매우 번거로웠다는 피드백 있음
- 드라이버를 직접 빌드해야 하고, libc 버전 차이로 인한 문제 발생
- 로컬 테스트 환경도 명확하지 않아 시행착오가 많음
- 해당 글은 마치 Sliplane을 홍보하는 글처럼 보인다는 지적 있음
- "비즈니스 로직을 Lambda에 넣기보단, 클라우드 환경을 프로그래밍하는 용도로 써야 한다"는 의견도 존재
- 서버리스 덕분에 작은 팀이 큰 규모의 서비스를 운영 가능하지만, 복잡성 문제는 여전히 존재
- 컨테이너 기술을 배운 사람이 자신의 경쟁력을 높이기 위해 모두에게 컨테이너 사용을 강요하는 것처럼 보인다는 비판도 있음
- 1세대 서버리스 플랫폼(AWS Lambda 등)은 확장성과 상태 관리에 어려움이 있음
- 2세대 플랫폼은 컨테이너 기반 서버리스로 진화 중이나, 컨테이너에 상태를 추가하는 건 스케일링 시 큰 문제 유발
- 예: "Docker volume 추가로 상태 유지"는 확장성을 고려하지 않은 위험한 조언임
- 글에서 언급한 “10개 컨테이너로 확장 + 자체 DB 운영” 등의 내용은 현실적으로 불가능하거나 비효율적인 주장으로 평가됨
- 일부는 이 글을 "공정한 평가"라고 보지만, 다른 이들은 지나치게 감성적이거나 상업적 의도가 짙다고 판단
한동안 vercel의 Edge rendering을 포기했다는 트윗과 영상[1], serverless server(ㅋㅋㅋ)[2]에 대한 글이 핫했었죠. 그때 나온 글들과 비슷한 견해를 갖고 있는 것 같습니다.
개인적인 의견이지만, 프론트엔드 개발자 입장에서는 사용자의 요청에 serverless function을 붙이는 것은 아직 먼 이야기라고 생각합니다(만드려는 어플리케이션이 MVP가 아니라면요).
[1] https://youtu.be/lAGE-k1Zfrg
[2] https://vercel.com/blog/…
[2-1] https://bobaekang.com/blog/…