기술사 학습노트 | imt-log

기술사 학습노트 › 시스템아키텍처 › 서버리스컴퓨팅 아키텍처

System Architecture · 정보관리기술사 / 컴퓨터시스템응용기술사

서버리스컴퓨팅 아키텍처(Serverless Computing Architecture)

서버 프로비저닝과 운영 부담을 클라우드 제공자에게 위임하고, 이벤트 기반으로 함수와 관리형 서비스를 조합하여 빠르게 애플리케이션을 구축·배포하는 클라우드 네이티브 아키텍처

정보관리기술사컴퓨터시스템응용기술사서버리스FaaSBaaS이벤트드리븐API Gateway오토스케일링콜드스타트클라우드네이티브

Ⅰ.개요 및 등장배경

가. 정의

서버리스컴퓨팅 아키텍처는 애플리케이션 개발자가 서버의 직접적인 구축, 패치, OS 운영, 용량 계획, 런타임 관리 부담을 최소화하고, 필요한 코드 또는 기능 단위만 구현하면 클라우드 제공자가 실행 환경과 확장성을 자동으로 제공하는 구조이다. “서버가 없다”는 의미가 아니라, 서버 관리 책임의 중심이 인프라 운영자에서 클라우드 제공자와 플랫폼 서비스로 이동한 형태라고 보는 것이 정확하다. 일반적으로 FaaS(Function as a Service), BaaS(Backend as a Service), 이벤트 브로커, API Gateway, 관리형 DB, 객체 스토리지, 인증 서비스가 조합되어 구현된다.

서버리스는 전통적인 3-Tier 시스템이나 VM 기반 인프라와 달리, 요청이 들어온 순간 함수가 실행되고 작업이 끝나면 자원을 반환하는 방식으로 비용 효율성과 민첩성을 확보한다. 개발팀은 비즈니스 로직과 서비스 흐름에 집중할 수 있고, 운영팀은 인프라 수명주기 관리보다 아키텍처 표준화, 보안 정책, 관측성, 비용 통제에 역량을 집중하게 된다. 따라서 서버리스는 단순 배포 옵션이 아니라 애플리케이션 구조 자체를 이벤트 중심, 관리형 서비스 중심으로 재구성하는 아키텍처 선택이라 할 수 있다.

나. 등장배경

• 클라우드 보편화: VM과 컨테이너 기반 운영이 확산되었지만, 여전히 패치, 오토스케일, 로드밸런싱, 장애조치 등 운영 복잡성이 남아 있었다.
• 마이크로서비스 확산: 기능 단위 분해가 늘어나면서 작은 서비스의 빠른 배포와 독립 확장이 가능한 실행 모델이 요구되었다.
• 이벤트 기반 업무 증가: 파일 업로드, 결제 완료, IoT 센서 이벤트, 메시지 큐, 실시간 알림 등 비동기 이벤트 처리 수요가 증가하였다.
• 비용 구조 변화: 트래픽이 간헐적이거나 예측이 어려운 서비스에서는 상시 서버 유지보다 사용량 기반 과금이 경제적이다.
• DevOps와 자동화 진전: CI/CD, IaC, 모니터링 자동화가 발전하면서 함수 단위 배포와 관리형 서비스 조합이 실무적으로 가능해졌다.
• 빠른 실험과 서비스 출시 요구: MVP, 모바일 백엔드, 데이터 처리 파이프라인, API 서비스에서 짧은 개발 주기가 중요해졌다.

다. 핵심 특성

서버리스의 핵심 특성은 이벤트 기반 실행, 자동 확장, 종량 과금, 짧은 실행 단위, 관리형 백엔드 활용, 무상태(Stateless) 처리 지향성이다. 함수는 일반적으로 짧은 시간 동안 실행되며, 상태 저장은 외부 DB나 캐시, 스토리지에 위임된다. 요청량이 증가하면 플랫폼이 함수 인스턴스를 자동으로 늘리고, 요청이 없으면 자원 사용량이 0 또는 최소 수준으로 수렴한다. 이는 운영 민첩성과 비용 절감에 유리하지만, 반대로 콜드 스타트, 실행 시간 제한, 장기 연결 처리 한계, 분산 디버깅 어려움, 벤더 종속성 같은 새로운 고려사항도 함께 가져온다.

서버리스컴퓨팅 아키텍처는 서버 운영을 추상화하고 함수와 관리형 서비스를 이벤트 중심으로 결합하는 클라우드 네이티브 구조이다.
답안에서는 정의뿐 아니라 FaaS, BaaS, 이벤트 기반 실행, 자동 확장, 종량 과금, 무상태 처리, 운영상의 장단점을 함께 설명해야 완성도가 높다.

Ⅱ.구성도 및 구성요소

가. 서버리스 실행 생명주기형 구성도

나. 구성요소

구분	요소	설명
진입 계층	API Gateway	HTTP/REST/GraphQL 요청의 인증, 라우팅, 속도 제한, 요청 변환, 버전 관리 기능을 제공한다.
실행 계층	FaaS	이벤트에 의해 호출되는 함수 실행 환경으로, 자동 확장과 요청 단위 과금을 제공한다.
백엔드 서비스	BaaS	DB, 객체 스토리지, 캐시, 인증, 메시징, 검색 등 공통 기능을 관리형 서비스로 제공한다.
비동기 연계	Event Bus / Queue	서비스 간 결합도를 낮추고 비동기 이벤트 처리, 재시도, 버퍼링, 스파이크 완화를 지원한다.
오케스트레이션	Workflow Engine	다단계 함수 실행, 분기, 재시도, 병렬 처리, 상태 관리가 필요한 업무 흐름을 제어한다.
보안	IAM / Secret	최소권한, 역할 기반 접근 제어, 비밀키 관리, API 보호, 네트워크 정책을 담당한다.
관측성	Log / Metric / Trace	분산된 함수 호출 흐름을 추적하고 지연, 오류율, 콜드 스타트, 비용을 분석한다.
배포 자동화	IaC / CI-CD	코드형 인프라, 함수 버전, 별칭, 롤백, 카나리 배포 등을 자동화한다.
데이터 상태	External State Store	무상태 함수의 상태를 외부 DB, 캐시, 스토리지, 세션 저장소에 유지한다.
운영 통제	Cost / Policy Governance	호출 수, 실행 시간, 메모리 설정, 동시성 제한, 예산 및 정책을 관리한다.

서버리스 아키텍처는 API Gateway, FaaS, BaaS, 이벤트 백본, 워크플로 엔진, 관측성, 보안, 배포 자동화로 구성된다.
구성도는 단순 계층도보다 이벤트 발생부터 함수 실행과 운영 거버넌스까지 연결되는 생명주기형으로 표현하면 이해도와 답안 완성도가 높아진다.

Ⅲ.동작방식 및 아키텍처

가. 기본 동작 절차

• 1단계 이벤트 발생: 사용자의 API 호출, 스케줄 이벤트, 파일 업로드, 큐 메시지, IoT 신호 등이 서버리스 워크로드의 시작점이 된다.
• 2단계 진입 처리: API Gateway 또는 이벤트 소스가 요청을 수신하고 인증, 권한 확인, 요청 검증, 라우팅을 수행한다.
• 3단계 함수 실행: FaaS 런타임이 적절한 함수 인스턴스를 할당하여 코드를 실행한다. 요청이 급증하면 동시 실행 인스턴스가 자동으로 확대된다.
• 4단계 상태 및 데이터 연계: 함수는 DB, 캐시, 스토리지, 메시지 큐, 인증 서비스 등 관리형 백엔드와 연동하여 필요한 상태를 조회하거나 저장한다.
• 5단계 비동기 후처리: 장시간 실행이 필요한 작업은 큐 또는 이벤트 버스로 전달되어 별도 함수나 워크플로에서 비동기 처리한다.
• 6단계 결과 반환 및 기록: API 응답을 반환하거나 결과 이벤트를 발행하고, 동시에 로그·메트릭·트레이스를 관측 플랫폼에 남긴다.
• 7단계 자동 축소: 요청이 समाप्त되면 사용된 컴퓨팅 자원은 반환되며, 요청이 없는 동안 비용은 최소화된다.

나. 아키텍처 원칙

원칙	설명	설계 포인트
이벤트 중심	요청, 메시지, 상태 변화가 함수 실행의 트리거가 된다.	동기·비동기 경계를 명확히 하고 이벤트 스키마를 표준화한다.
무상태 처리	함수 내부에 세션이나 장기 상태를 저장하지 않는다.	상태는 외부 DB, 캐시, 스토리지에 분리 저장한다.
관리형 서비스 우선	직접 구축보다 제공형 DB, 메시징, 인증, 검색 서비스를 적극 활용한다.	운영 부담은 줄지만 서비스 특성과 한계도 함께 검토한다.
세분화	기능을 작은 단위 함수로 분리하여 배포와 확장을 유연하게 한다.	과도한 분해로 인한 호출 복잡도와 분산 추적 비용을 주의한다.
자동화	배포, 테스트, 보안점검, 인프라 구성, 모니터링 설정을 자동화한다.	IaC와 CI/CD를 기본 전제로 설계한다.
권한 최소화	각 함수에 필요한 최소 자원만 접근하도록 설계한다.	함수별 IAM 역할 분리와 비밀정보 외부화를 수행한다.

다. 서버리스 세부 구조

서버리스 아키텍처는 크게 프런트엔드 진입 계층, 함수 실행 계층, 관리형 백엔드 계층, 이벤트 연계 계층, 운영 거버넌스 계층으로 나눌 수 있다. 프런트엔드 진입 계층은 API Gateway, 인증 서비스, CDN, WAF 등을 포함한다. 함수 실행 계층은 FaaS 런타임과 컨테이너 기반 서버리스 실행 환경으로 구성되며, 런타임 언어와 메모리·시간 제한 정책을 따른다. 관리형 백엔드 계층은 NoSQL, 관계형 DB, 스토리지, 캐시, 검색엔진, 메시징 서비스를 포함한다. 이벤트 연계 계층은 Queue, Pub/Sub, EventBridge, Scheduler, Workflow 서비스로 확장되며, 운영 거버넌스 계층은 관측성, 보안, 비용관리, IaC, 배포 전략, 버전 관리가 담당한다.

라. 콜드 스타트와 성능 이슈

콜드 스타트는 오랫동안 호출되지 않았던 함수가 새 실행 환경을 초기화하는 과정에서 발생하는 지연이다. 런타임 로딩, 라이브러리 초기화, 네트워크 설정, VPC 연결 등이 지연 요인이 될 수 있다. 이를 줄이기 위해 함수 크기를 작게 유지하고, 초기화 코드를 최소화하며, Provisioned Concurrency나 웜업 전략을 적용할 수 있다. 또한 고빈도 API에는 API Gateway 캐시, CDN, Edge 함수, 비동기 처리, 함수 메모리 튜닝 등을 조합하여 응답 시간을 개선한다.

마. 장애·복원력 설계

서버리스는 관리형 서비스 중심이므로 인프라 장애가 보이지 않는다고 해서 장애가 사라지는 것은 아니다. 함수 실패, 재시도 폭증, 중복 이벤트, 독성 메시지(Poison Message), 외부 API 장애, DB 동시성 한계, 이벤트 순서 불일치 문제가 발생할 수 있다. 따라서 재시도 정책, 백오프, DLQ(Dead Letter Queue), 멱등성(Idempotency), 타임아웃, 서킷 브레이커, 보상 트랜잭션, 관측성 확보가 중요하다. 특히 비동기 이벤트 처리에서는 “적어도 한 번(at least once)” 전달을 전제로 중복 처리 방지 설계를 해야 한다.

서버리스는 이벤트 발생, 진입 처리, 함수 실행, 데이터 연계, 비동기 후처리, 결과 반환, 자동 축소 흐름으로 동작한다.
실무 답안에서는 콜드 스타트, 멱등성, 재시도, DLQ, 상태 외부화, 최소권한, IaC 기반 자동화를 함께 설명해야 한다.

Ⅳ.실무적용 및 사례

가. 적용 분야

분야	적용 방식	적합 이유
모바일·웹 백엔드	API Gateway + FaaS + 인증 + NoSQL/스토리지로 사용자 API를 제공한다.	트래픽 변동 대응과 빠른 배포에 유리하다.
파일 처리	이미지 업로드 시 자동 리사이징, 썸네일 생성, OCR, 바이러스 검사를 실행한다.	이벤트 기반 비동기 처리에 적합하다.
데이터 파이프라인	로그 수집, ETL, 실시간 변환, 이벤트 분석, 알림 트리거를 함수 체인으로 구현한다.	작은 작업 단위의 반복 처리와 자동 확장에 유리하다.
IoT 백엔드	센서 이벤트 수신, 룰 평가, 이상 탐지, 알림 발송, 데이터 저장을 수행한다.	불규칙한 이벤트 처리와 관리형 메시징 연계가 쉽다.
업무 자동화	스케줄 기반 보고서 생성, 메일 발송, 승인 알림, 백업 처리 등을 실행한다.	상시 서버 유지 없이 정기 작업 자동화가 가능하다.
AI 연계 서비스	추론 요청 전처리, 이벤트 기반 모델 호출, 결과 후처리 및 저장을 담당한다.	짧은 요청형 서비스와 관리형 AI API 결합에 적합하다.

나. 도입 절차

• 업무 적합성 분석: 트래픽 패턴, 실행 시간, 상태 관리 필요성, 지연 민감도, 외부 시스템 연계 정도를 검토한다.
• 서비스 분해: 비즈니스 기능을 이벤트 단위 또는 API 단위 함수로 세분화하고 공통 기능은 관리형 서비스로 치환한다.
• 데이터 경계 정의: 무상태 함수와 외부 상태 저장소 간 경계를 명확히 설계한다.
• 보안 설계: 함수별 IAM 역할, 비밀정보 저장소, 네트워크 정책, API 보호, 로그 감사 체계를 수립한다.
• 배포 자동화: 템플릿, IaC, 테스트, 배포, 롤백, 버전·별칭 관리 체계를 만든다.
• 관측성 설계: 로그 상관관계 ID, 분산 추적, 사용자 정의 메트릭, 경보 임계치, 비용 리포팅을 준비한다.
• 장애 대응 시나리오 준비: 재시도, DLQ, 멱등성 키, 타임아웃, 폴백, 보상 처리 절차를 정의한다.
• 최적화: 콜드 스타트, 메모리, 동시성, 호출 횟수, BaaS 비용, API 응답 시간을 지속적으로 튜닝한다.

다. 장점과 한계

구분	내용	실무 해석
장점	인프라 운영 부담 감소, 빠른 배포, 자동 확장, 종량 과금, 관리형 서비스 활용	MVP, 비정형 트래픽, 이벤트 처리, 소규모 팀에 유리하다.
장점	기능 단위 개발과 배포가 가능하여 서비스 변경에 민첩하게 대응할 수 있다.	업무 모듈별 소유권 분리와 DevOps 문화에 적합하다.
한계	콜드 스타트, 실행 시간 제한, 장기 연결 및 대규모 상태 관리 제약이 존재한다.	실시간 초저지연 서비스나 대규모 세션 처리에는 주의가 필요하다.
한계	벤더 종속성과 분산 디버깅 어려움, 서비스 간 호출 추적 복잡성이 증가한다.	표준화, 추상화, 관측성 설계 없이는 운영 가시성이 낮아질 수 있다.
한계	호출 수가 매우 많아지면 예상보다 비용이 증가할 수 있다.	호출 최적화, 배치화, 캐싱, 아키텍처 재검토가 필요하다.

라. 실무 설계 포인트

실무에서는 모든 시스템을 서버리스로 전환하는 것이 정답은 아니다. 짧은 실행 시간, 간헐적 부하, 비동기 이벤트 처리, 빠른 서비스 출시가 중요한 영역에는 매우 적합하지만, 초저지연 실시간 게임 서버, 상태 유지가 많은 장기 연결 서비스, GPU 장시간 연산, 복잡한 레거시 모놀리식 업무에는 컨테이너 또는 VM 기반 구성이 더 적합할 수 있다. 따라서 서버리스는 “전체 전환”보다 “적합 업무 선별”이 중요하다. 또한 비용 절감 효과도 트래픽 패턴에 따라 달라지므로 호출량, 함수 실행 시간, API Gateway 비용, DB I/O 비용을 함께 산정해야 한다.

서버리스는 모바일 백엔드, 파일 처리, 데이터 파이프라인, IoT, 업무 자동화, AI 연계 API에 특히 적합하다.
도입 시에는 적합성 분석, 함수 분해, 상태 외부화, 보안, 관측성, 배포 자동화, 비용 통제를 함께 설계해야 한다.

Ⅴ.비교분석 및 발전전망

가. 전통적 서버 아키텍처와 서버리스 비교

구분	전통적 서버/VM	서버리스컴퓨팅
운영 책임	OS, 미들웨어, 패치, 스케일링을 조직이 직접 관리	실행 환경과 스케일링 대부분을 클라우드 제공자가 관리
확장 방식	사전 용량 계획과 오토스케일 그룹 기반	이벤트·요청 수에 따라 함수 인스턴스가 자동 확장
과금 구조	가동 시간, 인스턴스 크기 중심	호출 수와 실행 시간 중심의 종량 과금
배포 단위	애플리케이션 서버 또는 컨테이너 단위	함수 또는 작은 서비스 단위
상태 관리	세션 저장과 장기 프로세스 운영이 상대적으로 쉬움	무상태 함수와 외부 상태 저장소 분리가 기본
적합 업무	장기 실행, 상태 유지, 복잡한 레거시 시스템	이벤트 기반, 간헐 트래픽, 빠른 배포 중심 서비스

나. 컨테이너 기반 마이크로서비스와 서버리스 비교

구분	컨테이너 마이크로서비스	서버리스
실행 지속성	컨테이너가 상시 구동되며 장기 연결에 유리	요청 시 실행되고 종료되는 단기 실행 중심
제어 수준	런타임, 네트워크, 리소스, 사이드카 등 세밀한 제어 가능	제어 범위는 줄어들지만 운영 단순성이 높다
배포 속도	클러스터 운영과 이미지 관리가 필요	함수 단위 배포가 비교적 간단하다
비용 구조	항상 실행되는 리소스 비용이 발생	트래픽이 낮을 때 비용 절감 효과가 크다
관측성	도구 선택 폭이 넓고 표준화 용이	플랫폼 의존 도구와 분산 호출 추적이 중요하다
적합성	복잡한 서비스 메시, 장기 작업, 세밀한 튜닝	이벤트 처리, API 백엔드, 자동화, 비동기 워크로드

다. 발전전망

• 서버리스 컨테이너 확대: 함수형 모델과 함께 컨테이너 기반 서버리스 실행이 확산되어 실행 유연성이 높아질 것이다.
• 워크플로 자동화 고도화: 단일 함수 실행을 넘어 상태 기반 워크플로와 이벤트 오케스트레이션이 더욱 정교해진다.
• 엣지 서버리스 확장: CDN Edge, 브라우저 근접 지역에서 실행되는 함수가 늘어나 초저지연 서비스 구현이 쉬워진다.
• 관측성과 FinOps 중요성 확대: 호출량이 많은 대규모 서버리스 환경에서는 분산 추적과 비용 최적화 역량이 핵심 운영 요소가 된다.
• 보안 자동화 진전: 함수별 최소권한, 비밀정보 보호, 취약점 스캔, 정책 코드화가 표준 운영 방식으로 정착한다.
• AI·데이터 서비스와 결합: 이벤트 기반 전처리, 추론 API, 데이터 파이프라인, 배치 트리거에서 서버리스 활용이 더 증가한다.
• 멀티클라우드·벤더 추상화 수요 증가: 특정 플랫폼 종속을 줄이기 위한 오픈소스 프레임워크와 표준화 요구가 확대된다.

라. 기술사 답안 정리

서버리스컴퓨팅 아키텍처 답안은 “정의 → 등장배경 → 구성도 → 구성요소 → 동작 절차 → 아키텍처 원칙 → 실무 적용 → 장단점 → 비교분석 → 발전전망” 순서로 작성하면 안정적이다. 구성도에는 Trigger, API Gateway, FaaS, BaaS, Event Backbone, Observability, Security, DevOps를 포함해야 한다. 기술 포인트로는 이벤트 기반 처리, 무상태 설계, 자동 확장, 종량 과금, 상태 외부화, 콜드 스타트, 재시도·DLQ, IaC, CI/CD, 최소권한 설계를 정리하면 좋다. 마지막에는 컨테이너와의 비교, 엣지 서버리스, FinOps, 보안 자동화, AI 연계 활용 방향까지 연결하면 고득점형 답안이 된다.

답안 암기 포인트: “서버리스 = Trigger + API Gateway + FaaS + BaaS + Event + Observability + Security + Automation”으로 정리하면 된다.

서버리스컴퓨팅 아키텍처는 이벤트 기반으로 함수와 관리형 서비스를 결합하여 민첩성과 확장성을 확보하는 클라우드 네이티브 실행 구조이다.
향후 서버리스는 컨테이너형 서버리스, 엣지 실행, 워크플로 자동화, 보안 정책 코드화, FinOps, AI 서비스 연계와 함께 더욱 폭넓게 확산될 것이다.

블로그: 기술사 학습노트 · imt-log.tistory.com

← [시스템아키텍처] 목록