VM 띄우고, App Service 올리고, 컨테이너도 돌려봤다.
다음 배울 것은 서버리스다.
1. 서버리스 서비스의 이해
서버리스(Serverless)란?
이름만 보면 "서버가 없다"는 뜻이지만, 실제로 서버가 없는 건 아니다. 개발자가 서버를 관리할 필요가 없다는 의미다. 클라우드 제공업체가 서버 인프라의 프로비저닝, 유지 관리, 스케일링 등을 전부 처리한다.
작동 원리는 단순하다:
- 개발자가 함수 형태로 코드를 작성하고 클라우드 플랫폼에 배포한다
- 특정 이벤트(HTTP 요청, DB 변경, 파일 업로드 등)가 발생하면 함수가 트리거된다
- 클라우드가 필요한 컴퓨팅 리소스를 동적으로 할당하여 함수를 실행한다
- 함수 실행이 완료되면 리소스가 해제되고, 사용한 만큼만 비용이 청구된다
기존 PaaS와의 차이를 보면, PaaS는 App Service처럼 인스턴스가 항상 떠 있다. 서버리스는 이벤트가 없으면 아무것도 실행되지 않고, 비용도 0이다. 진정한 의미의 "쓴 만큼만 지불"이다.
서버리스 아키텍처의 주요 구성 요소
| 구성 요소 | 설명 | 예시 |
|---|---|---|
| 함수 (Functions) | 특정 작업을 수행하는 작은 코드 단위. 아키텍처의 핵심 | Azure Functions, AWS Lambda |
| 이벤트 소스 (Event Sources) | 함수를 트리거하는 서비스나 시스템 이벤트 | HTTP 요청, DB 변경, 파일 업로드, 타이머 |
| BaaS (Backend as a Service) | API를 통해 접근하는 백엔드 기능 | DB, 인증, 파일 스토리지 |
| API 게이트웨이 | 클라이언트 요청을 적절한 함수로 라우팅 | Azure API Management, AWS API Gateway |
핵심은 이벤트 드리븐이라는 것이다. 요청이 들어올 때만 함수가 실행되고, 끝나면 사라진다. 마이크로서비스를 극단까지 밀어붙인 형태라고 보면 된다.
서버리스 서비스 제공업체
3대 클라우드 벤더 모두 서버리스 컴퓨팅을 제공한다.
| 벤더 | 서비스명 | 특징 |
|---|---|---|
| Microsoft Azure | Azure Functions | Azure 생태계(Storage, Cosmos DB, Service Bus 등)와 긴밀한 통합 |
| AWS | Lambda | 가장 먼저 출시(2014). S3, DynamoDB, SQS 등 AWS 서비스와 통합 |
| GCP | Cloud Functions | Cloud Storage, Pub/Sub 등과 연동. Firebase와의 조합이 강점 |
시장 점유율은 AWS Lambda가 가장 높지만, Azure Functions는 이미 Microsoft 생태계(Office 365, Dynamics 365, Power Platform 등)를 쓰고 있는 기업에서 도입 장벽이 낮다. GCP Cloud Functions는 Firebase 기반 모바일 백엔드에서 특히 많이 쓰인다.
서버리스의 장점
- 비용 효율성: 실제 실행 시간에 대해서만 비용을 지불한다. 트래픽이 0이면 비용도 0이다
- 자동 스케일링: 요청이 1건이든 100만 건이든 클라우드가 알아서 리소스를 확장/축소한다
- 유지보수 간소화: 서버 관리 부담이 없어서 비즈니스 로직에 집중할 수 있다
- 빠른 개발 및 배포: 인프라 설정 없이 함수 코드만 작성하면 바로 배포 가능하다
서버리스의 단점
장점만 있으면 모든 서비스가 서버리스로 바뀌었겠지만, 현실은 그렇지 않다.
- 콜드 스타트(Cold Start): 일정 시간 호출이 없으면 인스턴스가 내려간다. 다시 호출되면 새 인스턴스를 띄우는 시간이 걸리는데, 이게 수백ms~수초까지 걸릴 수 있다. 레이턴시에 민감한 서비스에서는 치명적이다
- 벤더 종속성(Vendor Lock-in): 각 클라우드의 트리거, 바인딩, SDK가 다르기 때문에, 한번 특정 벤더에 올리면 다른 벤더로 마이그레이션하기 어렵다
- 장기 실행 작업에 부적합: 대부분의 서버리스 플랫폼은 함수 실행 시간에 제한을 둔다. Azure Functions Consumption Plan은 기본 5분, 최대 10분이다
- 디버깅과 모니터링의 어려움: 분산된 함수들의 호출 체인을 추적하기가 로컬 개발 환경보다 훨씬 복잡하다
서버리스가 적합한 사례
| 사례 | 이유 |
|---|---|
| 이벤트 기반 처리 | 비동기 작업, 실시간 데이터 스트림 처리에 딱 맞다 |
| 마이크로서비스 | 독립적인 함수 단위로 서비스를 쪼개기 좋다 |
| 변동성 높은 워크로드 | 트래픽 피크/오프피크가 극심한 서비스에 효과적이다 |
| 빠른 프로토타이핑 | MVP를 빠르게 만들고 검증하는 데 적합하다 |
반대로 상시 가동이 필요하거나, 실행 시간이 긴 배치 작업, 레이턴시가 극도로 중요한 서비스에는 서버리스가 맞지 않는다. 이런 경우 App Service나 Container Apps가 더 나은 선택이다.
2. 클라우드의 대표적인 서버리스 서비스
Azure Functions
Azure의 서버리스 컴퓨팅 플랫폼이다. 핵심 특징을 정리하면:
| 특징 | 설명 |
|---|---|
| 서버리스 아키텍처 | 인프라 관리 없이 코드 실행에만 집중 |
| 이벤트 기반 실행 | HTTP 요청, 타이머, 메시지 큐, 파일 변경 등 다양한 트리거 |
| 다국어 지원 | C#, JavaScript, Python, Java, PowerShell |
| 자동 확장성 | 요청량에 따라 자동 스케일 아웃 |
| Azure 서비스 통합 | Storage, Cosmos DB, Service Bus 등과 바인딩으로 연결 |
AWS Lambda
AWS의 서버리스 컴퓨팅 서비스다. 2014년 출시된 서버리스의 원조격 서비스로, 가장 넓은 생태계를 갖고 있다.
| 특징 | 설명 |
|---|---|
| 서버리스 아키텍처 | 서버 관리 없이 코드 실행 |
| 이벤트 기반 실행 | S3, DynamoDB, API Gateway, SQS 등과 연동 |
| 다국어 지원 | Node.js, Python, Java, C#, Go, Ruby |
| 자동 확장성 | 동시 실행 수에 따라 자동 스케일 |
Azure Functions와 Lambda의 기능 자체는 거의 동일하다. 차이는 주변 생태계다. 이미 AWS를 쓰고 있다면 Lambda, Azure를 쓰고 있다면 Functions를 선택하는 것이 자연스럽다.
Azure Functions 호스팅 옵션
Azure Functions는 4가지 호스팅 플랜을 제공한다. 선택에 따라 비용, 성능, 제약이 크게 달라진다.
| 플랜 | 특징 | 적합한 상황 |
|---|---|---|
| Consumption Plan | 실행 시간에만 과금. 자동 확장. 기본 서버리스 호스팅 | 트래픽이 불규칙하거나 비용 최적화가 중요할 때 |
| Premium Plan | 콜드 스타트 없음. VNet 통합. 더 강력한 리소스 | 레이턴시가 중요하거나 VNet 접근이 필요할 때 |
| App Service Plan | App Service 인스턴스 위에서 실행. 항상 활성 | 이미 App Service를 쓰고 있어서 리소스를 공유할 때 |
| Flex Consumption Plan | 사전 인스턴스 프로비전 + 빠른 확장 | 콜드 스타트는 줄이면서 비용도 최적화하고 싶을 때 |
Consumption Plan이 가장 저렴하지만 콜드 스타트 문제가 있다. 이걸 해결하려면 Premium Plan으로 올려야 하는데, 당연히 비용이 올라간다. 이 트레이드오프를 잘 판단해야 한다.
SLA (Service Level Agreement)
SLA는 서비스 제공자와 고객 간의 서비스 품질 계약이다. 가동 시간, 응답 시간, 문제 발생 시 보상 조건 등이 포함된다.
Azure Functions의 SLA는 99.95%다. 이걸 실제 시간으로 환산하면:
| 기간 | 허용 다운타임 |
|---|---|
| 월간 | 약 21.9분 |
| 연간 | 약 4시간 22분 |
99.95%라는 숫자가 높아 보이지만, 연간 4시간 이상의 장애가 허용된다는 뜻이다. 미션 크리티컬한 서비스라면 SLA만 믿지 말고 자체적인 장애 대응 전략(재시도, 데드 레터 큐, 멀티 리전 등)을 반드시 갖추어야 한다.
3. 서버리스 서비스 활용 사례 분석
Azure Functions Trigger
Azure Functions에서 함수의 실행을 시작하는 것이 트리거(Trigger)다. 각 함수에는 하나의 트리거만 설정할 수 있다.
| 트리거 유형 | 설명 | 실무 예시 |
|---|---|---|
| 스토리지 | Cosmos DB, Blob Storage 등의 이벤트 감지 | 이미지 업로드 시 썸네일 자동 생성 |
| 이벤트 | Event Grid, Event Hubs의 이벤트 수신 | IoT 센서 데이터 실시간 처리 |
| HTTP | 웹 요청, 웹훅 처리 | REST API 엔드포인트 |
| 큐 | Queue Storage, Service Bus 메시지 처리 | 주문 처리, 이메일 발송 |
| 타이머 | 지정된 시간 간격으로 실행 | 매일 자정 데이터 정리, 리포트 생성 |
Azure Functions Bindings
바인딩(Binding)은 다른 리소스 또는 서비스를 함수에 선언적으로 연결하는 방법이다. 코드에서 SDK를 직접 호출하는 대신, 설정 파일(function.json)에 바인딩을 선언하면 프레임워크가 알아서 연결해준다.
- 입력 바인딩(Input Binding): 함수 실행 시 외부 데이터를 파라미터로 받는다. 예를 들어 Azure SQL 입력 바인딩은 DB에서 데이터를 조회해서 함수에 전달한다
- 출력 바인딩(Output Binding): 함수의 반환 값을 외부 서비스로 보낸다. Azure SQL 출력 바인딩을 쓰면 함수 결과를 DB에 자동으로 삽입할 수 있다
트리거와 바인딩의 조합이 서버리스의 진짜 힘이다. 예를 들어 "Blob Storage에 파일이 업로드되면(트리거) → 함수가 실행되어 파일을 처리하고 → 결과를 Cosmos DB에 저장(출력 바인딩)"하는 파이프라인을 코드 몇 줄 + 설정 파일 하나로 구현할 수 있다.
Azure Serverless Services 전체 그림
Azure에서 서버리스로 분류되는 서비스는 Functions만이 아니다. 여러 서비스가 레고 블록처럼 조합된다.
| 카테고리 | 서비스 | 역할 |
|---|---|---|
| 컴퓨팅 | Azure Functions | 이벤트 기반 코드 실행 |
| 메시징 | Service Bus | 엔터프라이즈 메시지 큐 |
| 이벤트 | Event Grid | 이벤트 라우팅 (Pub/Sub) |
| 이벤트 | Event Hubs | 대용량 이벤트 스트리밍 |
| 데이터 | Cosmos DB | 글로벌 분산 NoSQL DB |
| 데이터 | Azure SQL | 관리형 관계형 DB |
| 통합 | Logic Apps | 워크플로우 자동화 (로우코드) |
| 웹 | App Service | 웹앱/API 호스팅 |
아키텍처 사례 분석
PDF에서 소개하는 서버리스 다이어그램들의 공통 패턴을 정리하면:
사례 1 — 문서 처리 파이프라인
Blob Storage(트리거) → Azure Function → Form Recognizer(테이블 추출) → Azure Table(저장) → Power BI(시각화)
사례 2 — 차량 번호판 인식 시스템
차량 사진 → Blob Storage → Azure Function(Computer Vision API로 OCR) → Event Grid(이벤트 라우팅) → 성공 시 Cosmos DB 저장 / 실패 시 수동 검토 큐 → Logic Apps(CSV 내보내기 + 이메일 알림) → Application Insights(모니터링)
사례 3 — 모바일 앱 백엔드
Mobile App → Storage Blob(이미지 업로드) + Queue(작업 요청) → Azure Function(Computer Vision, Azure Search 연동) → SQL Database + Cosmos DB → Web App(관리 포탈) + Power BI(분석)
사례 4 — PDF 문서 자동 처리
이메일 수신/직접 업로드 → Logic Apps(이메일 처리) → Data Lake Storage → Logic Apps(함수 호출) → Azure Functions + Form Recognizer(PDF 파싱) → Cosmos DB(저장) → Power BI(분석)
이 사례들의 공통점은 명확하다: 각 서비스가 하나의 역할만 하고, 이벤트로 연결된다. 서비스 간 결합도가 낮아서 특정 컴포넌트만 교체하거나 확장하기 쉽다. 이것이 서버리스 아키텍처의 본질이다.
실습 진행
Functions 리소스를 만들고 실행해 보겠다.
파이썬 런타임 스택을 사용하기 위해서는 리눅스 운영체제를 사용해야하므로,
사용량 모델(Windows)는 못쓰고 유연한 사용량을 선택했다
배포 성공. Linux 환경에서 포탈 내에서 함수 만들기 기능이 사라졌기 때문에, 바로 VSCode로 가보겠다.
우선 http 트리거를 실행해보자
f5를 눌러 실행한 URL에 접속하고, name = 장성근으로 get요청을 보내면 트리거로 실행된다.
이제 blob 트리거를 실행해보자
중간에 프로젝트의 스토리지를 고르는데, 이때 remote storage의 function 리소스와 연결된 스토리지를 골라야한다.
그래야 스토리지 path가 설정되고, jobstorage에 path를 붙여넣을 수 있다.
이제 감시의 타겟이 되는 스토리지 계정을 만들어서 target_storage의 path를 지정해주어야한다
PNG를 업로드한 것을 잘 캐치한 모습을 볼 수 있었다.
이후 특정 확장자를 감지하여 경고 로그를 출력하는 코드를 추가하고,
exe 파일을 업로드 해 보았다.
마찬가지로 잘 트리거 되는 모습을 볼 수 있었다.
이제 이 금지 확장자 파일이 업로드 되었을 때,
자동으로 삭제하는 코드를 작성하고 실행해보자.
확장자명을 임의로 변경해서 업로드하더라도 탐지할 수 있도록, 파일 헤더를 직접 읽는 코드도 추가해보자.
MZ가 실행 파일이라는 것을 나타내는 헤더 바이트이므로, 확장자명을 변경하더라도 탐지가 가능하다.
azure에 바로 배포하도록 하자
정리
- 서버리스는 "서버가 없다"가 아니라 "서버를 관리하지 않아도 된다"는 의미다
- 이벤트 기반으로 함수가 실행되고, 실행 시간에 대해서만 과금된다
- Azure Functions, AWS Lambda, Google Cloud Functions가 3대 서버리스 컴퓨팅 서비스다
- 콜드 스타트, 벤더 종속성, 실행 시간 제한은 서버리스의 본질적인 한계다
- Azure Functions는 Consumption/Premium/App Service/Flex 4가지 호스팅 플랜을 제공하며, 콜드 스타트 vs 비용의 트레이드오프가 핵심이다
- 트리거(이벤트 감지)와 바인딩(입출력 연결)의 조합으로 복잡한 파이프라인을 선언적으로 구성할 수 있다
- 서버리스는 특정 서비스가 아니라 아키텍처 패턴이다. 여러 서버리스 서비스를 레고 블록처럼 조합해서 시스템을 구성한다
'개인공부' 카테고리의 다른 글
| [Microsoft Azure] 9. 컨테이너 기술의 이해 - 쿠버네티스 (1) | 2026.06.03 |
|---|---|
| [Microsoft Azure] 8. 컨테이너 기술의 이해 - 도커 (0) | 2026.06.03 |
| [Microsoft Azure] 6. 클라우드 웹 서비스 플랫폼 (2) (0) | 2026.04.21 |
| [Microsoft Azure] 5. 클라우드 웹 서비스 플랫폼 (1) (1) | 2026.04.21 |
| [AWS] 2. AWS 클라우드 운영 환경 이해하기 (0) | 2026.04.09 |