서버리스는 사기다: 그냥 컨테이너 쓰세요

• 서버리스는 간편해 보이지만 실제로는 복잡성, 제약, 고비용을 유발하는 구조임
• 컨테이너는 이식성, 상태 유지, 명확한 제어를 제공하며 대부분의 사용 사례에 더 적합함
• 서버리스는 비용 구조가 불투명하고 예측 불가능하며, 구성 요소 간 불필요한 복잡성을 초래함
• 서버리스의 확장성과 간편성은 제한적인 사용 사례에만 적합함
• 실제 운영환경에서는 컨테이너 기반 배포가 단순하고 확장 가능하며 비용 효율적임

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)

• 서버리스는 이론상 멋져 보임
• 현실에서는:
  • 불투명
  • 고비용
  • 과도한 복잡성
  • 과대홍보

시작하기 전 스스로에게 물어보라:
“이걸 그냥 컨테이너로 만들 수 없을까?”

• 답이 ‘예’라면, 컨테이너로 시작하는 것이 더 나은 선택

후속 행동 권장

• 서버리스로 인해 예상치 못한 비용, 비효율적인 워크플로우를 겪은 사례 공유 권장
• 단순한 문제를 과도하게 복잡하게 만들지 말 것