서버리스(Serverless) 아키텍처란? 클라우드 시대의 개발 패러다임 변화

반응형

 

서버리스(Serverless) 아키텍처란? 클라우드 시대의 개발 패러다임 변화

 

1. 서버리스 아키텍처의 개념과 특징

서버리스는 서버는 존재하지만 관리가 개발자 손을 떠난 개발 모델입니다. 인프라 운영(확장, 보안, 패치)은 클라우드가 맡고, 우리는 코드와 비즈니스 가치에 집중합니다.

 

과거에는 웹사이트나 앱을 운영하려면 서버를 직접 설치하고, 운영체제를 업데이트하고, 보안 패치를 적용하며, 트래픽에 맞춰 규모를 조절해야 했습니다.

서버리스 환경에서는 이러한 번거로운 작업을 클라우드 서비스 제공업체(AWS, Azure, GCP 등)가 담당합니다. 개발자는 서버 관리 걱정 없이 기능 구현과 개선에 집중할 수 있습니다.

 

🔷 기존 방식 vs 클라우드(IaaS) vs 서버리스(FaaS, BaaS)

🔸 기존 방식(온프레미스):

서버를 직접 구입·설치하고, 운영체제 업데이트, 보안 패치, 확장까지 모두 자체 관리합니다. 통제력은 크지만 초기비용·유지보수 부담이 큽니다.

🔸 클라우드(IaaS):

서버를 클라우드에서 임대합니다. 장비 구매는 없고 사용량 기준 과금이지만, OS 관리·보안·확장 설정은 여전히 사용자가 맡습니다.

🔸 서버리스(FaaS, Function as a Service):

함수 단위 코드를 올려두면 이벤트가 올 때만 실행됩니다. 서버 운영·확장·보안은 제공자가 담당하고, 사용자는 비즈니스 로직만 작성합니다. 호출 수·실행 시간(GB-초) 기준 과금, 자동 확장이 기본입니다.
예: AWS Lambda, Azure Functions, Google Cloud Functions

🔸 서버리스(BaaS, Backend as a Service):

인증, 데이터베이스, 저장소, 푸시 알림 같은 백엔드 기능을 API로 제공합니다. 필요한 기능을 바로 붙여 사용할 수 있습니다.

예: Firebase Auth/Firestore/Cloud Storage, AWS Cognito/DynamoDB/S3

 

🔷 서버리스의 주요 특징
🔸 사용량 기반 과금: 실제로 코드가 실행된 시간만 비용을 지불합니다.
🔸 자동 확장: 트래픽이 늘어나면 자동으로 인스턴스가 증가해 서비스가 멈추지 않습니다.
🔸 이벤트 기반 실행: 파일 업로드, 버튼 클릭, 메시지 수신 등 이벤트 발생 시에만 코드가 동작합니다.
🔸 무중단 배포: 서비스 중단 없이 새 버전을 적용할 수 있습니다 (예: 블루/그린, 카나리 배포).

 

2. 서버리스가 주목받는 이유

서버리스는 단순히 “새로운 기술”이기 때문이 아니라, 비용 절감·개발 속도·운영 안정성을 동시에 얻을 수 있기 때문에 각광받고 있습니다.

 

🔷 비용 효율성

24시간 서버를 켜두는 대신, 실행된 만큼만 비용을 냅니다.

예를 들어 하루에 10분만 동작하는 데이터 처리 코드는 그 10분에 해당하는 비용만 지불합니다.

🔷 자동 확장 기능

쇼핑몰 타임 세일처럼 사용자가 갑자기 몰려도, 인프라가 자동으로 확장되어 안정적으로 서비스가 유지됩니다.

운영자가 급히 서버를 늘릴 필요가 없습니다.

🔷 빠른 개발과 배포

서버 설치·설정 시간이 필요 없습니다.

코드를 준비하면 즉시 실행할 수 있어, 새로운 기능을 짧은 주기로 서비스에 반영할 수 있습니다. 특히 MVP나 PoC(개념 검증)에 유리합니다.

🔷 운영 부담 감소
OS 업데이트, 보안 패치, 장애 대응 같은 인프라 운영을 클라우드가 대신합니다.

개발팀은 서비스 기능 개발에 집중할 수 있습니다.

 

3. 주요 서비스와 활용 사례

서버리스는 이미 주요 클라우드 업체에서 다양한 형태로 제공되고 있습니다. 기본 원리는 같지만, 연동 서비스와 제공 기능은 조금씩 다릅니다.

 

🔷 대표적인 서버리스 서비스
🔸 AWS Lambda

이미지 처리, 데이터 변환, API 응답 등 이벤트 기반 작업을 수행합니다.

예를 들어 사용자가 사진을 업로드하면 자동으로 리사이즈/포맷 변환을 수행할 수 있습니다.

S3, API Gateway, EventBridge와 자연스럽게 연동됩니다.

🔸 Azure Functions
Microsoft 365, Azure Event Grid, Azure SQL 등과 밀접하게 연동됩니다.

예를 들어 회사 메일함에 특정 키워드가 포함된 메일이 오면 자동 분류·저장을 구현할 수 있습니다.

🔸 Google Cloud Functions
Cloud Storage, Firebase, Pub/Sub과 유기적으로 연결됩니다.

예를 들어 앱 사용자 행동 데이터를 실시간 분석하고 조건에 맞으면 푸시 알림을 보낼 수 있습니다.

🔸 대표적 BaaS
Firebase(Auth, Firestore, Cloud Storage)와 AWS(Cognito, DynamoDB, S3)는 인증·데이터·파일 저장을 즉시 사용 가능한 API로 제공합니다.

 

🔷 서버리스 활용 사례
🔸 간단한 기능(API) 빠른 구현
예: 회원 로그인, 내 정보 보기, 설문 제출. 필요한 기능만 빠르게 만들어 웹/앱에 연결합니다.

🔸 자동 데이터 처리
예: 이미지 자동 압축/변환, 영상 포맷 변경, 매일 한 번 데이터 분석. 파일이 올라오면 즉시 처리되어 사람이 일일이 개입할 필요가 없습니다.

세탁기에 빨래를 넣으면 알아서 세탁되는 것과 비슷합니다.

🔸 실시간 반응 서비스
예: 온도 센서 값 즉시 계산·표시, 위치 추적 데이터 바로 저장. 신호가 오면 대기 없이 처리합니다.

스마트홈에서 문이 열리면 즉시 알림이 오는 것과 같은 원리입니다.

🔸 예약 실행(스케줄링)
예: 매일 밤 12시 통계 보고서 생성, 하루 단위 데이터 백업. 알람 시계처럼 설정한 시간에 자동 실행됩니다.

 

4. 서버리스의 한계와 고려 사항

서버리스는 관리 편의와 비용 절감에 강점이 있지만, 모든 상황에서 최선은 아닙니다. 도입 전에 다음을 고려하세요.

 

🔷 콜드 스타트(Cold Start)
일정 시간 요청이 없다가 다시 실행되면 첫 호출이 느려질 수 있습니다. 실시간성이 중요한 경우, 사전 예열·프로비저닝 된 동시성 같은 방법을 검토합니다.

🔷 벤더 종속성(Vendor Lock-in)
특정 클라우드에 맞춘 구현은 다른 플랫폼으로 이동할 때 코드·설정을 크게 바꿔야 할 수 있습니다. 초기에 표준 인터페이스를 사용하고, 도메인 로직과 클라우드 의존 코드를 분리하면 리스크를 줄일 수 있습니다.

🔷 관측성·디버깅 난이도
서버에 직접 접속해 로그를 보는 방식이 아니므로, 문제 분석이 복잡할 수 있습니다. 중앙화된 로깅·모니터링을 함께 구성하세요.
예: AWS CloudWatch, Google Cloud Logging/Cloud Monitoring(구 Stackdriver), Azure Monitor

🔷 실행 시간·자원 제한
함수는 최대 실행 시간과 메모리에 제한이 있습니다(예: AWS Lambda 최대 15분). 장시간 연산이나 대용량 배치는 컨테이너 서비스(예: 서버리스 컨테이너, 배치 처리)나 전용 서버가 적합할 수 있습니다.

 

 

✔ 마무리

서버리스는 서버를 없애는 기술이 아니라, 서버 관리 부담을 줄여 개발자가 가치 창출에 집중하도록 돕는 클라우드 기반 개발 모델입니다.

실제로 실행한 만큼만 비용을 내고, 트래픽이 몰리면 자동으로 확장되며, 무중단으로 배포할 수 있다는 장점 덕분에 스타트업부터 대기업까지 널리 활용되고 있습니다.

다만 콜드 스타트, 벤더 종속, 관측성의 복잡성, 실행 시간·자원 제한 같은 제약이 있습니다. 따라서 모든 것을 서버리스로 바꾸기보다, 서비스 특성에 맞는 부분부터 선택적으로 도입하는 전략이 현명합니다.

핵심 요약:
🔸 서버리스 = 인프라는 클라우드가, 가치는 개발자가.
🔸 강점: 사용량 과금·자동 확장·빠른 배포·운영 부담 감소.
🔸 주의: 콜드 스타트·벤더 종속·관측성·자원 제한.
🔸 전략: MVP/이벤트 기반/간헐적 작업/스파이크 트래픽부터 적용해 효과를 확인하세요.

 

---

반응형

 

"본 글은 과거 cericube-it(티스토리)에서 발행했던 콘텐츠를 기반으로, 새롭게 정리한 업데이트 버전입니다."