클라우드 컴퓨팅의 발전은 개발자들에게 매혹적인 장밋빛 미래를 약속했습니다. “서버 관리는 우리가 할 테니, 여러분은 비즈니스 로직에만 집중하세요.” 이 한마디로 대변되는 서버리스(Serverless) 아키텍처는 인프라 구축과 유지보수의 번거로움을 없애줄 구원투수로 등장했습니다.
하지만 막상 프로덕션 환경에 서버리스를 도입한 엔지니어들은 환상 뒤에 숨겨진 냉혹한 현실과 마주하게 됩니다. 진정으로 서버가 사라진 것인지, 아니면 우리의 통제력이 사라진 것인지 깊이 있게 짚어보겠습니다.
1. 서버리스는 정말 ‘서버가 없는’ 것일까?
많은 초급 개발자들이 서버리스라는 단어를 말 그대로 ‘서버가 존재하지 않는다’로 오해하곤 합니다. 그러나 물리적인 서버가 사라졌을 리 만만무합니다. 서버리스의 본질은 ‘개발자가 서버를 직접 프로비저닝하고 관리할 필요가 없다’는 뜻에 가깝습니다.
AWS 람다(Lambda)나 구글 클라우드 펑션(Cloud Functions) 같은 FaaS(Function-as-a-Service) 환경에서 백엔드 코드는 클라우드 사업자의 거대한 인프라 풀 위에서 실행됩니다.
- 개발자는 오직 함수(Function) 단위의 코드 조각만 작성해 업로드합니다.
- 트래픽이 몰리면 클라우드 시스템이 알아서 인스턴스를 수평 확장(Scale-out)합니다.
- 요청이 없으면 인스턴스는 0개로 줄어들어 자원을 아낍니다.
표면적으로는 완벽해 보이는 이 구조는 인프라 관리 비용을 획기적으로 낮춰주지만, 동시에 백엔드 아키텍처의 전통적인 규칙들을 송두리째 흔들어 놓습니다.
2. 비용 절감의 역설: 트래픽이 늘수록 폭탄이 되는 구조
서버리스의 가장 큰 마케팅 포인트는 ‘사용한 만큼만 지불한다(Pay-as-you-go)’는 점입니다. 24시간 내내 켜져 있어야 하는 EC2 인스턴스와 달리, 호출된 밀리초(ms) 단위로만 과금되기 때문에 초기 트래픽이 적은 스타트업에게는 매력적인 선택지입니다.
하지만 트래픽 패턴이 폭발적이거나 상시 고도화되는 대규모 서비스에서는 이야기가 달라집니다.
- 무한 확장(Auto-scaling)의 공포: DDoS 공격이나 마케팅 이벤트로 인해 예상치 못한 대량의 요청이 들어오면, 서버리스 함수는 무한대에 가깝게 인스턴스를 늘립니다. 이 과정에서 아키텍처적 제어 장치가 없다면 다음 달 청구서에는 상상 이상의 클라우드 비용 폭탄이 찍히게 됩니다.
- 상시 대기(Always-on) 요구사항: 트래픽이 끊기지 않아야 하는 핵심 코어 시스템의 경우, 서버리스의 장점인 ‘요청 없을 시 자원 회수’ 효과가 사라지고 오히려 상시 호출 상태가 되어 일반 서버보다 비용이 더 비싸지는 역설이 발생합니다.
3. 상태(State)를 가질 수 없는 무상태(Stateless)의 한계
전통적인 모놀리식 또는 컨테이너 기반 서버는 메모리나 로컬 디스크에 일시적인 상태(State)를 저장하며 동작할 수 있었습니다. 예를 들어, 사용자의 세션 정보나 간단한 캐시 데이터를 메모리에 적재해 두는 방식입니다.
그러나 서버리스 환경은 철저하게 무상태(Stateless)를 강제합니다.
- 언제든 컨테이너가 생성되고 소멸하기 때문에 로컬 파일 시스템에 파일을 쓰는 행위는 의미가 없습니다.
- 모든 데이터는 외부 데이터베이스나 레디스(Redis), 오브젝트 스토리지(S3) 등에 영구 저장해야 합니다.
- 이로 인해 컴포넌트 간 네트워크 통신 횟수가 급증하며, 사소한 로직 하나를 처리하는 데도 여러 번의 외부 I/O가 발생해 전체적인 지연 시간(Latency)이 늘어나는 부작용을 낳습니다.
4. 개발 및 디버깅의 악몽: 로컬 시뮬레이션의 한계
서버리스 환경에서 개발하는 엔지니어들이 가장 크게 고통받는 부분은 디버깅과 테스트입니다.
로컬 개발 환경에서는 완벽하게 동작하던 코드가 AWS나 클라우드 환경에 배포하는 순간 오류를 뿜어내는 경우가 허다합니다. 클라우드 전용 IAM 권한 설정, API Gateway 연동 에러, 환경 변수 주입 방식의 차이 등은 로컬에서 완벽하게 재현하기 어렵기 때문입니다. 결국 코드를 수정할 때마다 빌드하고 클라우드에 배포(Deploy)한 뒤 로그를 확인하는 구시대적인 삽질을 반복하게 되며, 이는 개발자 경험(DevEx)을 심각하게 저하시킵니다.
5. 벤더 종속성(Vendor Lock-in)이라는 보이지 않는 수갑
특정 클라우드 업체의 서버리스 생태계에 깊숙이 결합할수록, 다른 플랫폼으로의 이전은 사실상 불가능에 가까워집니다.
예컨대 AWS 람다를 기반으로 DynamoDB, SNS, SQS, API Gateway 등을 복잡하게 엮어놓았다면, 이는 독자적인 애플리케이션 코드가 아니라 AWS라는 거대한 플랫폼에 종속된 종속재가 됩니다. 클라우드 사업자가 갑작스럽게 가격 정책을 변경하거나 서비스 지원을 중단하더라도, 기업은 수억 원의 비용을 들여 코드를 처음부터 다시 짜지 않는 이상 그 틀에서 벗어날 수 없습니다.
맺음말: 은빛 탄환(Silver Bullet)은 없다
서버리스는 분명 인프라 관리의 패러다임을 바꾼 혁신적인 기술입니다. 이벤트 기반의 가벼운 백그라운드 작업, 주기적인 데이터 처리, 혹은 예측 불가능한 트래픽을 처리하는 마이크로서비스의 특정 모듈에는 이보다 더 좋을 수 없는 선택입니다.
그러나 “서버가 없으니 고민도 없다”는 환상에 빠져 무작정 도입했다가는 비용 폭탄, 복잡한 디버깅, 그리고 벤더 종속성이라는 거대한 삼중고를 마주하게 됩니다. 기술의 화려한 마케팅 뒤에 숨겨진 아키텍처적 트레이드오프를 정확히 이해하고, 우리 서비스의 비즈니스 모델에 맞는 균형 잡힌 인프라 전략을 세우는 것이 진정한 시니어 엔지니어의 역량일 것입니다.