Serverless Architecture

📌 Brief Summary

서버리스 아키텍처(Serverless Architecture)는 개발자가 서버 인프라를 프로비저닝하거나 직접 관리할 필요 없이, 클라우드 제공업체가 리소스 할당과 확장을 동적으로 관리하는 클라우드 네이티브 소프트웨어 설계 패턴이다 [1-3]. 애플리케이션은 주로 특정 이벤트에 의해 트리거되는 소규모의 독립적인 함수(Function as a Service) 형태로 배포되며, 트래픽에 맞춰 자동으로 스케일링된다 [2, 4, 5]. 유휴 시간 없이 코드가 실제 실행된 시간에 대해서만 비용을 지불하는 종량제 모델을 통해 스타트업과 예측 불가능한 워크로드를 가진 프로젝트에 높은 경제성과 개발 민첩성을 제공한다 [1, 6, 7].

📖 Core Content

인프라 관리의 추상화 (No Infrastructure Management): '서버리스'라는 명칭은 서버가 물리적으로 존재하지 않는다는 뜻이 아니라, 운영 체제 관리, 패치 적용, 서버 프로비저닝 등의 인프라 운영 책임을 AWS, Azure, Google Cloud와 같은 클라우드 제공자에게 전적으로 위임한다는 것을 의미한다 [1, 2, 8, 9]. 이를 통해 개발자는 순수하게 비즈니스 로직과 코드 작성에만 집중할 수 있다 [9, 10].
이벤트 기반 함수 실행 (Event-Driven Functions): 서버리스 애플리케이션은 HTTP 요청, 데이터베이스 상태 변경, 파일 업로드, 예약된 작업(Scheduled tasks) 등과 같은 이벤트에 반응하여 비동기적으로 실행되는 개별 함수의 집합으로 구성된다 [2, 4].
자동화된 탄력적 확장 (Automatic Scalability): 트래픽이 급증하거나 변동성이 매우 큰 워크로드 환경에서도, 클라우드 플랫폼이 수요에 맞게 실시간으로 리소스를 할당하고 함수를 복제하여 처리한다 [10, 11]. 이 과정은 수동 개입 없이 이루어지며, 기본적으로 고가용성(High Availability) 및 내결함성(Fault Tolerance)을 내장하고 있다 [4, 12, 13].
사용량 기반의 경제적인 과금 모델 (Pay-per-use Pricing): 코드가 실행되는 컴퓨팅 시간에 대해서만 요금이 부과되므로 서버가 유휴 상태일 때는 비용이 발생하지 않는다 [6, 7, 12]. 중간 규모 이하의 트래픽을 가진 애플리케이션에서는 기존 클라우드 호스팅 방식보다 최대 70%까지 비용을 절감할 수 있어 MVP 개발 및 신속한 프로토타이핑에 매우 적합하다 [1, 7, 10].

⚖️ Trade-offs & Caveats

콜드 스타트 지연 (Cold Start Latency): 함수가 일정 시간 동안 호출되지 않아 비활성 상태에 머무르다가 다시 실행될 때, 클라우드 환경이 컨테이너를 초기화하는 과정에서 지연 시간(최대 5초 등)이 발생한다 [6, 12-14]. 이는 실시간 응답이 매우 중요한 채팅, 게임, 트레이딩 시스템에서는 치명적인 약점이 될 수 있다 [13, 14].
실행 시간 및 메모리 제약 (Execution & Resource Limits): 서버리스 함수는 실행 시간에 엄격한 제약(예: AWS Lambda의 경우 최대 15분)을 가지며, 메모리 리소스도 한정되어 있다 [6, 15, 16]. 따라서 오랜 시간이 걸리는 백그라운드 작업이나 대규모 리소스 집약적인 데이터 처리 프로세스에는 부적합하다 [15-17].
벤더 종속성 (Vendor Lock-in): 특정 클라우드 제공업체의 독자적인 생태계와 도구에 강하게 결합되므로, 향후 다른 클라우드 플랫폼(AWS에서 Azure 등)으로 마이그레이션하고자 할 때 코드와 아키텍처를 대대적으로 수정해야 하는 등 높은 전환 비용이 발생한다 [6, 12, 16, 18].
디버깅 및 모니터링의 복잡성 (Debugging & Observability Challenges): 코드가 다수의 분산된 독립 함수로 파편화되어 비동기적으로 실행되기 때문에 로컬 환경에서의 테스트가 어렵고 에러의 근본 원인을 추적하기가 매우 까다롭다 [12, 19, 20]. 이를 관리하려면 Datadog, New Relic과 같은 분산 추적(Distributed tracing) 기능이 포함된 특수 관측성 도구가 필수적이다 [20, 21].
규모의 경제 역전 비용 (Cost Inefficiency at Scale): 초기 및 변동성 트래픽에서는 비용 효율적이지만, 호출 볼륨이 지속적으로 매우 높거나 장시간 실행되는 워크로드의 경우, 지속적으로 할당된 가상 머신(VM)을 유지하는 것보다 오히려 컴퓨팅 비용이 초과되어 경제성이 떨어질 수 있다 [12, 17].

🔗 Knowledge Connections

[관계 유형 A (아키텍처 설계 사상)]

Event-Driven Architecture
- 연결 이유: 서버리스 애플리케이션의 핵심 동작 원리는 HTTP 요청, 파일 업로드 등의 이벤트가 발생할 때 함수가 트리거되는 비동기식 이벤트 구조에 철저히 의존하기 때문이다 [2, 4].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 서버리스 환경에서 수많은 개별 함수들이 중앙 서버 없이 어떻게 느슨하게 결합(Loose coupling)되어 상호작용하고, 트래픽 폭증 시 이벤트를 어떻게 병렬로 처리하는지 원리를 이해할 수 있다 [22, 23].
Microservices Architecture
- 연결 이유: 마이크로서비스를 구현하고 분리하는 가장 현대적이고 고도화된 방법 중 하나가 각각의 비즈니스 기능을 독립된 서버리스 함수로 구현하여 배포하는 것이기 때문이다 [23-25].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 모놀리식 아키텍처를 작은 단위의 독립적인 서비스로 분해하여 확장성과 탄력성을 확보하는 아키텍처의 진화 과정과 분산 시스템의 복잡성을 이해할 수 있다 [25, 26].
Modular Monolith
- 연결 이유: 서버리스와 마이크로서비스가 야기하는 극단적인 분산 시스템의 디버깅, 모니터링 복잡성에 대한 대안으로, 팀 규모나 요구사항에 따라 서버리스 대신 단일 코드베이스 내에서 논리적 모듈을 분리하여 통제력을 확보하는 접근 방식이기 때문이다 [27-29].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 프로젝트 초기 단계에서 네트워크 지연이 없는 단일 프로세스의 이점을 누릴지, 인프라 관리를 위임하는 서버리스를 선택할지에 대한 아키텍처의 전략적 트레이드오프(Trade-off)를 학습할 수 있다 [29-31].

[관계 유형 B (구현 및 운영 환경)]

Cloud-Native Computing
- 연결 이유: 서버리스 아키텍처는 클라우드 제공자의 인프라 및 리소스 동적 할당 기능에 전적으로 의존하는 클라우드 네이티브 설계의 궁극적인 형태이기 때문이다 [1, 4, 32].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 클라우드 인프라가 어떻게 동적으로 자원을 할당하고 오토 스케일링을 지원하는지, 그리고 클라우드 환경에 종속됨으로써 발생하는 벤더 락인(Vendor Lock-in)의 근본적인 원인을 파악할 수 있다 [4, 16, 33].

Deeper Research Questions

서버리스 아키텍처의 가장 큰 약점인 '콜드 스타트(Cold Start)'로 인한 초기 지연을 완화하기 위해 클라우드 제공업체와 아키텍트들은 어떠한 최적화 기법(예: 프로비저닝된 동시성 등)을 적용하고 있는가?
지속적으로 높은 트래픽이 발생하는 엔터프라이즈 환경에서 서버리스 비용이 가상 머신(VM)이나 컨테이너(예: Kubernetes) 기반 모델의 유지 비용을 초과하게 되는 손익분기점(Break-even point)은 어떻게 산정하고 모니터링할 수 있는가?
상태를 유지하지 않는(Stateless) 서버리스 함수의 특성상, 여러 서비스에 걸친 복잡한 비즈니스 트랜잭션을 처리할 때 데이터의 일관성(Data Consistency)은 어떻게 보장해야 하는가?
벤더 종속성(Vendor Lock-in) 리스크를 최소화하기 위해 오픈소스 프레임워크(예: Serverless Framework)나 컨테이너화된 함수 배포 방식 등 멀티 클라우드 전략을 어떻게 적용할 수 있는가?
기존의 모놀리식 아키텍처 기반 레거시 시스템을 서버리스 아키텍처로 점진적으로 마이그레이션(예: 스트랭글러 피그 패턴 활용)할 때 직면하게 되는 기술 부채 해결 및 데이터베이스 분리 과제는 무엇인가?

Practical Application Contexts

Implementation: AWS Lambda, Azure Functions, Google Cloud Functions와 같은 클라우드 FaaS(Function as a Service) 플랫폼을 활용하여, 인프라 세팅 없이 HTTP 요청이나 파일 업로드 시 실행될 단일 비즈니스 로직(코드 스니펫)만을 작성하고 배포한다.
System Design: 트래픽을 예측할 수 없거나 간헐적인 워크로드(예: 이메일 발송, 이미지 리사이징, 비정기적인 데이터 변환)에는 서버리스를 우선 적용하고, 지속적으로 빠른 응답이 필요한 코어 서비스는 컨테이너/모놀리스로 구성하는 하이브리드 아키텍처(Hybrid Architecture)를 설계한다.
Operation / Maintenance: 서버의 OS 패치나 용량 증설 등의 운영 부담은 사라지지만, 잘게 쪼개진 수많은 함수 간의 호출 흐름과 비동기 에러를 추적하기 위해 Datadog, New Relic과 같은 강력한 분산 추적(Distributed Tracing) 및 로깅 인프라를 반드시 구축해야 한다.
Learning Path: 전통적인 모놀리식 및 레이어드 아키텍처의 한계를 학습한 후, 분산 시스템인 마이크로서비스 설계 원칙을 이해하고, 최종적으로 인프라 관리의 책임을 클라우드로 완전히 위임하는 서버리스 및 이벤트 기반 설계로 아키텍처 지식을 확장한다.
My Project Relevance: 빠른 시장 출시가 최우선인 스타트업의 MVP 프로젝트나 마케팅 캠페인처럼 특정 시점에만 트래픽이 폭증하는 애플리케이션을 기획할 때, 초기 호스팅 비용을 0으로 맞추고 관리 오버헤드를 최소화하기 위한 핵심 백엔드 전략으로 도입을 검토할 수 있다.

Adjacent Topics

Backend as a Service (BaaS)
- 확장 방향: 서버리스 생태계를 구성하는 또 다른 축으로, 사용자 인증, 데이터베이스, 스토리지 등 백엔드의 공통 기능 전체를 클라우드 API로 제공받아 서버리스 함수(FaaS)와 결합하여 코딩을 최소화하는 아키텍처 방식 연구.
Saga Pattern
- 확장 방향: 서버리스나 마이크로서비스 환경처럼 개별 데이터베이스를 가지는 분산 시스템에서, 중앙화된 트랜잭션 관리가 불가능할 때 데이터 정합성(Eventual Consistency)을 유지하기 위한 보상 트랜잭션 설계 기법 연구.

Last updated: 2026-05-02

Cloud_Native_Architecture: 서버리스가 속한 상위 아키텍처 패러다임.
Microservices_Architecture: 서버리스 함수들이 모여 구성하는 고도로 분산된 서비스 체계.
Event_Driven_Architecture: 서버리스의 실행 기반이 되는 비동기 메시징 모델.

1. 개요

서버리스 컴퓨팅(Serverless Computing)은 개발자가 서버 인프라를 직접 관리하지 않고, 비즈니스 로직인 '함수(Function)' 단위로 코드를 배포하여 실행하는 클라우드 네이티브 아키텍처 모델이다. 인프라의 확장, 패치, 프로비저닝은 클라우드 제공자가 전담하며, 사용자는 실제 코드가 실행된 시간과 리소스에 대해서만 비용을 지불한다.

2. 핵심 메커니즘 (FaaS)

이벤트 트리거 (Event-driven): HTTP 요청, DB 변경, 파일 업로드 등 특정 이벤트에 의해 함수가 즉시 호출됨.
자동 확장 (Auto-scaling): 트래픽의 증감에 따라 함수 인스턴스가 0에서 무한대(플랫폼 한계까지)로 즉시 확장 및 축소됨.
무상태성 (Stateless): 각 함수 실행은 독립적이며 이전 실행의 상태를 유지하지 않음. 상태 저장이 필요한 경우 외부 DB나 스토리지를 활용.

3. 실전 적용 및 최적화

프레임워크별 특성:
- Express/Fastify: 가볍고 빠른 초기화 속도로 '콜드 스타트' 지연 최소화에 유리.
- NestJS: 구조화된 대규모 애플리케이션에 적합하나, 두꺼운 추상화 계층으로 인해 초기화 시 더 많은 메모리와 시간이 소요될 수 있음.
JAMstack 통합: 백엔드 로직을 서버리스 API로 추상화하여 프론트엔드와 독립적으로 배포 및 운영.

4. 트레이드오프 및 주의사항

콜드 스타트 (Cold Starts): 유휴 상태의 함수가 처음 실행될 때 발생하는 초기화 지연 시간. 성능 최적화의 핵심 과제.
플랫폼 종속성 (Vendor Lock-in): 특정 클라우드 제공자(AWS, Azure, GCP)의 독자적인 런타임 환경과 트리거 방식에 결합될 위험.
디버깅의 한계: 로컬 환경과 실제 클라우드 환경 간의 차이로 인해 분산 추적 및 정밀한 성능 튜닝이 어려울 수 있음.

🧪 검증 상태 (Validation)

정보 상태: 검증 완료 (Verified)
출처 신뢰도: A
검토 이유: 운영 비용 최적화와 개발 생산성 극대화를 위한 현대적 클라우드 실행 모델의 표준 가이드 정립.

14 KiB Raw Blame History