서버리스란 무엇인가: 서버가 사라진 게 아니라, 당신의 문제 목록에서 사라진 것이다

들어가며: 당신이 정말 하고 싶은 건 서버 관리가 아니다

이 시리즈를 처음부터 따라왔다면, 우리가 걸어온 길을 떠올려 보자:

1. 온프레미스 — 서버를 사고, 전산실을 짓고, 24시간 관리했다
2. EC2 — 서버를 빌렸다. 하드웨어는 AWS 몫, OS부터는 내 몫
3. Docker — 환경을 컨테이너로 패키징했다. "내 컴퓨터에서는 되는데" 종료
4. ECS/쿠버네티스 — 수백 개 컨테이너를 자동 관리했다. 하지만 EC2 인스턴스는 여전히 신경 써야 했다
5. Fargate — EC2마저 추상화했다. 컨테이너만 정의하면 됐다

매 단계에서 개발자의 짐이 하나씩 줄어들었다. 하지만 Fargate에서도 여전히 해야 하는 것이 있다: Docker 이미지를 빌드하고, 태스크를 정의하고, 서비스를 설정하고, 오토스케일링을 구성한다.

"나는 비즈니스 로직 함수 하나만 실행하고 싶을 뿐인데, 이 모든 것이 정말 필요한가?"

이 질문이 서버리스(Serverless) 의 출발점이다. 서버가 사라진 게 아니다. 서버가 당신의 문제 목록에서 사라진 것이다.

---

1. 서버리스 이전의 세계: 기업들이 겪은 진짜 문제들

서버리스가 왜 필요한지 이해하려면, 기존 방식에서 기업들이 실제로 겪은 문제들을 먼저 살펴봐야 한다.

문제 1: "서버는 돌아가는데, 하는 일이 없다"

EC2 인스턴스는 켜져 있는 시간 기준으로 과금된다. 야간에 트래픽이 0이어도, 연휴에 아무도 접속하지 않아도, 서버가 켜져 있으면 돈이 나간다.

실제 사례를 보자. 2016년 한 스타트업의 모바일 앱 백엔드:

월 $2,400을 내면서 서버의 96%는 아무것도 하지 않고 있었다. 오토스케일링? 트래픽이 너무 적어서 최소 인스턴스 수(3대) 밑으로 줄일 수 없었다. 가용성을 위해 최소 3대가 필요했기 때문이다.

이것은 극단적인 예가 아니다. Datadog의 2023년 클라우드 보고서에 따르면, 기업 EC2 인스턴스의 평균 CPU 사용률은 **약 11~17%**에 불과하다.

문제 2: "트래픽이 10배로 튀는 순간을 대비해야 한다"

이커머스 서비스를 운영한다고 하자. 평소 트래픽은 분당 1,000건. 하지만 플래시 세일이 시작되면 순식간에 분당 50,000건으로 치솟는다.

EC2 + 오토스케일링으로 대응하면:

• 새 인스턴스가 시작되는 데 2~5분
• 2분 동안 기존 서버에 과부하 → 응답 시간 폭증 또는 에러
• 세일이 끝나면 축소되는 데 또 시간

ECS/쿠버네티스 + Fargate로 개선해도:

• 새 태스크 시작에 30초~2분 (이미지 Pull 포함)
• 콜드 스타트 동안의 트래픽 손실

초 단위로 반응하는 스케일링은 전통적인 서버 기반 아키텍처에서는 구조적으로 어렵다.

문제 3: "인프라에 시간을 쓰느라 제품을 못 만든다"

이것이 가장 은밀하지만 가장 큰 비용이다. 5명짜리 스타트업에서 1명이 인프라를 관리하면 개발 인력의 20%를 인프라에 소비하는 셈이다.

UC Berkeley의 2019년 논문 "Cloud Programming Simplified: A Berkeley View on Serverless Computing"에서는 이렇게 지적했다:

"클라우드의 궁극적 약속은 자원 관리에서 개발자를 해방하는 것이다. 하지만 EC2 이후 10년이 지났음에도, 클라우드 사용자는 여전히 복잡한 인프라 운영에 상당한 시간을 쓰고 있다."

---

2. 서버리스란 무엇인가

정의

서버리스 컴퓨팅은 클라우드 사업자가 서버의 프로비저닝, 스케일링, 유지보수를 완전히 관리하고, 사용자는 코드(또는 컨테이너)만 제공하며 실행된 만큼만 과금되는 클라우드 실행 모델이다.

핵심 원칙 3가지:

1. 서버 관리 제로: 서버가 없는 게 아니라, 당신이 관리할 서버가 없다. OS 패치, 용량 계획, 스케일링 — 전부 클라우드가 한다.

2. 이벤트 기반 실행: 코드가 항상 실행되지 않는다. 이벤트(HTTP 요청, 파일 업로드, DB 변경, 스케줄)가 발생하면 그때 실행되고, 끝나면 사라진다.

3. 사용량 기반 과금: 코드가 실행된 시간(밀리초 단위)과 처리한 요청 수만큼만 비용 발생. 아무도 접속하지 않으면 비용 0원.

"서버리스"라는 이름의 아이러니

서버리스에서 가장 흔한 오해: "서버가 없다고요?" — 물론 서버는 있다. 어딘가의 데이터센터에서 실제 서버가 코드를 실행한다. 하지만 당신이 그 서버의 존재를 인식할 필요가 없다. 전기를 쓸 때 발전소를 신경 쓰지 않듯, 서버리스에서는 서버를 신경 쓰지 않는다.

서버리스의 두 가지 형태

---

3. 서버리스의 역사: 아이디어에서 산업 표준까지

선구자들

서버리스의 아이디어는 클라우드 이전부터 존재했다.

2006년 — Zimki: 영국 기업 Fotango가 만든 최초의 "pay-per-use" 코드 실행 플랫폼. JavaScript 코드를 올리면 사용한 만큼 과금. 시대를 너무 앞섰고, 2007년에 서비스 종료.

2008년 — Google App Engine: "코드만 올리면 자동으로 스케일링"이라는 혁명적 약속. 서버리스의 PaaS 선구자. 하지만 Google 고유의 API에 종속되는 문제로 대중화에 한계.

2012년 — Iron.io가 "Serverless" 용어 사용: Iron.io의 Ken Fromm이 블로그에서 "The Serverless Framework is Here"라고 선언. 서버리스라는 용어가 업계에 퍼지기 시작.

AWS Lambda: 서버리스의 빅뱅 (2014)

2014년 11월, AWS re:Invent에서 Lambda가 발표됐다. 반응은 반신반의였다 — "함수 하나만 실행하는 서비스가 무슨 의미가 있지?"

하지만 Lambda가 증명한 것은 컴퓨팅 모델의 근본적 전환이었다:

• 과금 단위: 시간당 → 100밀리초당
• 스케일링: 수동 설정 → 자동, 0에서 수천으로
• 관리 대상: 서버 → 없음
• 유휴 비용: 항상 발생 → 0원

---

4. 서버리스가 기존 방식의 문제를 어떻게 해결하는가

유휴 비용 문제 → 완전 해결

앞서 예로 든 스타트업의 경우를 서버리스로 바꾸면:

월 $2,400 →$85. 96% 비용 절감. 트래픽 패턴이 불규칙한 소규모 서비스일수록 서버리스의 비용 이점은 극대화된다.

스케일링 문제 → 근본적으로 다른 접근

EC2/ECS에서 스케일링은 "반응형"이다. 트래픽이 올라오면 감지하고, 새 인스턴스/태스크를 시작한다. 시간 지연이 불가피하다.

서버리스에서 스케일링은 "내재적"이다. 각 요청이 독립된 실행 환경을 트리거하므로, 1개 요청이 오든 10,000개 요청이 동시에 오든 자동으로 처리된다.

인스턴스를 띄우고, 헬스체크를 기다리고, 로드밸런서에 등록하는 과정이 없다. 이벤트가 오면 즉시 실행된다.

운영 부담 문제 → 대폭 감소

---

5. 서버리스의 전체 풍경: FaaS만이 서버리스가 아니다

Lambda 같은 FaaS가 서버리스의 대표이지만, 2026년 현재 서버리스 생태계는 컴퓨팅을 훨씬 넘어선다.

서버리스 서비스 지도

---

6. 서버리스의 한계: 은탄환은 없다

서버리스가 만능은 아니다. 명확한 한계와 트레이드오프가 있다.

콜드 스타트 (Cold Start)

서버리스의 가장 유명한 단점. 한동안 실행되지 않은 함수가 호출되면 실행 환경을 새로 만들어야 한다. 이 초기화 시간이 콜드 스타트다.

Go나 Python은 콜드 스타트가 짧아 문제가 덜하지만, Java/Spring 같은 무거운 프레임워크는 수 초가 걸릴 수 있다. 실시간 응답이 중요한 서비스에서는 치명적일 수 있다.

완화 방법:

• Provisioned Concurrency (Lambda): 미리 인스턴스를 따뜻하게 유지. 콜드 스타트 제거, 하지만 비용 발생
• 경량 런타임 사용: Python, Go, Rust 선택
• SnapStart (Lambda, Java): JVM 상태를 스냅샷으로 저장해 시작 시간 90% 단축

실행 시간 제한

Lambda의 최대 실행 시간은 15분이다. 30분 걸리는 데이터 처리, 몇 시간 걸리는 ML 학습 같은 장시간 작업에는 적합하지 않다.

상태 관리의 어려움

서버리스 함수는 무상태(Stateless) 다. 한 번 실행이 끝나면 메모리의 모든 것이 사라진다. 이전 요청의 결과를 기억하려면 외부 저장소(DynamoDB, Redis, S3)를 사용해야 한다.

벤더 종속 (Vendor Lock-in)

AWS Lambda로 작성한 코드를 Google Cloud Functions로 옮기려면 상당한 수정이 필요하다. 이벤트 소스, API, SDK가 모두 다르다.

디버깅과 관측성

로컬에서 서버리스 환경을 재현하기 어렵다. 분산된 함수들의 호출 체인을 추적하려면 X-Ray 같은 분산 트레이싱이 필수다.

---

7. 서버리스 vs 컨테이너 vs EC2: 언제 무엇을

이 시리즈의 핵심 질문이다. "우리 서비스에는 무엇이 맞는가?"

비용 교차점: 트래픽에 따른 선택

서버리스의 비용 구조는 사용량에 비례한다. EC2와 컨테이너는 프로비저닝된 용량에 비례한다. 이 두 곡선에는 교차점이 있다.

교차점: 대략적으로, 함수가 하루에 100만 회 이상 호출되고 각 실행 시간이 수백 ms 이상이면 컨테이너가 더 저렴해진다. 하지만 이 교차점은 워크로드마다 다르므로 반드시 실측해야 한다.

의사결정 가이드

---

8. 실제 사례: 서버리스를 채택한 기업들

Coca-Cola: 벤딩머신의 서버리스

코카콜라는 전 세계 수백만 대의 자판기(벤딩머신)에서 발생하는 결제·재고 이벤트를 Lambda로 처리한다. 자판기 한 대에서 발생하는 이벤트는 하루 수십 건에 불과하지만, 전체 규모를 합치면 하루 수억 건이다.

EC2로 이 트래픽을 처리하려면 수백 대의 서버가 필요하고, 대부분의 시간에 놀고 있을 것이다. Lambda로 전환하면서 인프라 비용 65% 절감, 운영 인력 80% 감소를 달성했다.

iRobot: IoT 이벤트 처리

로봇 청소기 룸바의 제조사 iRobot은 수백만 대의 로봇에서 발생하는 센서 데이터를 Lambda로 처리한다. 각 로봇이 청소 중에만 데이터를 보내므로 트래픽이 매우 불규칙하다 — 서버리스의 완벽한 유스케이스다.

Lyft: 서버리스 데이터 파이프라인

차량 공유 서비스 Lyft는 실시간 수요 예측과 가격 산정에 서버리스를 활용한다. 이벤트(승차 요청)가 발생할 때마다 Lambda가 주변 수요 데이터를 분석하고 동적 가격을 계산한다.

한국 기업 사례

• 배달의민족: 주문 알림, 결제 처리, 쿠폰 이벤트 등 이벤트 기반 처리에 Lambda 활용
• 야놀자: 예약 확인 SMS/이메일 발송, 결제 웹훅 처리를 Lambda로 자동화
• 당근마켓: 이미지 리사이징을 Lambda@Edge로 처리. 수백만 장의 중고 거래 이미지를 서버 없이 변환

---

9. 서버리스의 현재와 미래

서버리스 컨테이너의 부상

FaaS의 제약(실행 시간, 런타임, 패키지 크기)을 넘어, 서버리스 컨테이너가 빠르게 성장하고 있다:

• AWS Fargate: ECS/EKS에서 서버리스 컨테이너
• Google Cloud Run: Docker 이미지를 올리면 자동 스케일링, 0까지 축소
• Azure Container Apps: 이벤트 기반 서버리스 컨테이너

Cloud Run은 특히 주목할 만하다. "Lambda의 서버리스 과금 + Docker의 유연성"을 결합했다. 어떤 언어, 어떤 프레임워크든 Docker 이미지로 만들면 서버리스로 실행된다.

AI와 서버리스

2025~2026년의 가장 흥미로운 조합은 AI + 서버리스다:

• AI 추론의 서버리스화: 가벼운 AI 모델을 Lambda에서 직접 실행
• 이벤트 기반 AI 파이프라인: 파일 업로드 → Lambda가 AI 처리 → 결과 저장
• 비용 최적화: AI 추론은 간헐적 — 서버리스의 유휴 비용 0원 모델이 최적

"모든 것이 서버리스"를 향해

2026년의 트렌드는 서버리스의 경계가 사라지는 것이다. 예전에는 "Lambda를 쓸까, EC2를 쓸까"가 양자택일이었지만, 이제는:

• Lambda가 컨테이너 이미지를 실행할 수 있다 (2020~)
• Fargate가 0으로 스케일 다운할 수 있다
• Aurora Serverless가 DB를 자동 스케일링한다
• DynamoDB가 용량 계획 없이 자동 확장한다

서버리스와 컨테이너, 심지어 기존 서버 기반 서비스의 경계가 흐려지고 있다. 중요한 것은 기술 분류가 아니라 **"얼마나 적게 관리하면서 서비스를 운영할 수 있는가"**다.

---

마치며: 추상화의 끝에 무엇이 있는가

이 시리즈 전체를 관통하는 하나의 흐름이 있다:

각 단계는 개발자에게 **"하나 덜 신경 써도 된다"**는 약속이었다. 서버리스는 그 약속의 현재 도달점이다. 서버가 사라진 것이 아니라, 서버가 수도나 전기처럼 보이지 않는 인프라가 된 것이다.

물론 서버리스가 모든 것의 답은 아니다. GPU가 필요한 AI 학습, 장시간 실행 작업, 대규모 상시 트래픽 — 이런 워크로드에는 EC2나 컨테이너가 여전히 최선이다. **"어떤 추상화 레벨이 우리의 문제에 맞는가"**를 판단하는 것이 진짜 엔지니어링이다.

코어닷투데이의 AI 서비스들은 이 모든 레벨을 조합한다. Edge 디바이스에서의 실시간 추론(로컬), 클라우드에서의 모델 서빙(ECS/Fargate), 이벤트 기반 데이터 처리(Lambda) — 각 워크로드의 특성에 맞는 추상화 레벨을 선택하는 것이 우리의 접근이다.

다음 글에서는 서버리스의 대표 서비스인 AWS Lambda를 깊이 파고들어, 실전에서 어떻게 사용하고 최적화하는지를 다뤄보겠다.