서버리스 아키텍처 장단점

FaaS는 클라우드 컴퓨팅의 한 형태로, 개발자가 서버 인프라를 프로비저닝하거나 관리할 필요 없이 개별 함수 단위의 코드를 실행할 수 있게 해주는 서비스 모델이다. 이 모델에서 클라우드 제공자는 컨테이너나 가상 머신과 같은 실행 환경을 완전히 추상화하여 관리한다. 개발자는 특정 이벤트나 요청에 의해 트리거될 함수 코드만 작성하고 업로드하면, 플랫폼이 코드 실행, 확장, 로드 밸런싱, 패치 적용 등 모든 운영 작업을 자동으로 처리한다.

FaaS의 핵심 작동 원칙은 이벤트 기반 실행과 스케일 투 제로이다. 함수는 HTTP 요청, 메시지 큐의 메시지, 클라우드 스토리지의 파일 업로드, 데이터베이스 변경 사항 등 다양한 이벤트에 반응하여 실행된다. 요청이 없을 때는 함수 인스턴스가 완전히 종료되어 리소스가 할당되지 않으며, 트래픽이 증가하면 플랫폼이 자동으로 필요한 만큼의 함수 인스턴스를 생성하여 병렬로 처리한다. 이는 전통적인 서버 기반 모델과 근본적으로 다른 차이점이다.

주요 FaaS 플랫폼의 함수 실행 수명 주기는 일반적으로 다음과 같은 단계를 거친다.

FaaS는 마이크로서비스 아키텍처를 구현하는 한 방식으로 간주되며, 각 함수는 매우 작고 단일 책임을 가진 서비스로 설계된다. 이를 통해 애플리케이션 로직을 더 작고 독립적인 구성 요소로 분해할 수 있어, 개발, 테스트, 배포의 유연성을 높인다. 그러나 함수 간 통신, 상태 관리, 장기 실행 작업 처리 등에는 설계상의 제약이 따르므로 주의가 필요하다.

BaaS는 애플리케이션 개발에서 필요한 백엔드 기능을 API 형태로 제공하는 클라우드 서비스 모델이다. 개발자는 인증, 데이터베이스, 파일 스토리지, 푸시 알림 등 공통적인 서버 측 로직을 직접 구축하고 유지 관리할 필요 없이, 서비스 공급자가 제공하는 SDK와 API를 통해 통합하여 사용한다. 이는 FaaS가 특정 이벤트에 반응하는 함수 단위의 실행 환경을 제공하는 것과는 차별화된다. BaaS는 주로 모바일 앱과 웹 애플리케이션의 백엔드 인프라를 빠르게 구성하는 데 활용된다.

주요 BaaS 서비스는 다음과 같은 범주로 나눌 수 있다.

BaaS를 도입하면 개발 팀은 핵심 애플리케이션 비즈니스 로직에 집중할 수 있어 개발 속도가 크게 향상된다. 또한, 서버 프로비저닝, 운영 체제 관리, 소프트웨어 패치와 같은 인프라 운영 부담이 거의 제거된다. 그러나 특정 BaaS 벤더의 서비스와 SDK에 깊이 의존하게 되어 벤더 종속성이 발생할 수 있다는 점은 중요한 고려사항이다. 또한, 제공되는 서비스의 기능과 제약에 맞춰 애플리케이션 아키텍처를 설계해야 하므로 유연성이 일부 제한될 수 있다.

서버리스 아키텍처의 실행 흐름을 정의하는 핵심 메커니즘이다. 이 모델에서 애플리케이션 코드는 함수 (프로그래밍) 단위로 패키징되며, 미리 정의된 특정 이벤트 (컴퓨팅)가 발생할 때만 실행된다. 함수는 서버나 인프라를 프로비저닝하거나 관리할 필요 없이, 플랫폼에 의해 자동으로 인스턴스화되고 실행된다.

이벤트의 종류는 매우 다양하다. 대표적인 예로는 HTTP 요청, 클라우드 스토리지 버킷의 파일 업로드/변경, 메시지 큐나 스트리밍 데이터 서비스에 새로운 메시지 도착, 데이터베이스 업데이트, 예약된 크론 작업 등이 있다. 예를 들어, 사용자가 웹 애플리케이션에서 버튼을 클릭하면 API 게이트웨이가 HTTP 이벤트를 수신하고, 이는 특정 함수를 트리거하여 비즈니스 로직을 실행하고 응답을 반환한다.

이 모델은 애플리케이션을 이벤트 생산자, 이벤트 소비자(함수), 그리고 이를 연결하는 이벤트 라우터로 구성된 느슨하게 결합된 시스템으로 구조화하게 한다. 이는 반응형 프로그래밍 패러다임과 잘 맞으며, 시스템의 각 부분이 독립적으로 확장되고 유지 관리될 수 있도록 한다. 실행은 순간적이며, 함수가 작업을 완료하면 일반적으로 실행 환경이 종료되므로, 지속적인 상태를 함수 내부에 저장하는 것은 권장되지 않는다.

서버리스 아키텍처의 비용 효율성은 운영 비용 모델의 근본적인 변화에서 비롯된다. 전통적인 서버 기반 아키텍처에서는 사용량과 관계없이 프로비저닝된 서버 인스턴스에 대해 지속적으로 비용을 지불해야 한다. 이는 트래픽이 적은 시간대에도 리소스가 유휴 상태로 남아 있어 비효율을 초래한다. 반면, 서버리스 모델에서는 실제로 코드가 실행된 시간과 그에 소비된 리소스(예: 메모리 할당량, 실행 시간)에 대해서만 비용이 청구된다. 이는 '사용한 만큼만 지불한다'는 종량제 모델로, 미사용 용량에 대한 비용을 제거한다.

비용 구조는 일반적으로 실행 횟수와 실행 시간(밀리초 또는 기가바이트-초 단위)을 기반으로 한다. 예를 들어, 하루에 수천 번만 호출되는 배치 작업이나 이벤트 핸들러의 경우, 비용이 거의 무시할 수 있을 정도로 낮다. 다음 표는 전통적 가상 머신 방식과 서버리스 방식의 비용 차이를 간략히 비교한다.

이러한 모델은 변동성이 크거나 예측하기 어려운 트래픽 패턴을 가진 애플리케이션에 특히 유리하다. 피크 시간에는 자동으로 확장되어 요청을 처리하고, 사용량이 낮을 때는 비용이 급격히 감소한다. 또한 개발 팀은 서버 프로비저닝, 운영 체제 유지 관리, 용량 계획과 같은 인프라 관리 작업에서 해방되어, 이에 투입되던 인적 자원과 시간을 애플리케이션 비즈니스 로직 개발에 집중할 수 있다. 이는 간접적인 인건비 절감 효과로 이어진다.

그러나 비용 효율성은 애플리케이션의 특성에 따라 달라질 수 있다. 지속적으로 높은 부하가 걸리고 안정적인 트래픽을 유지하는 애플리케이션의 경우, 장기적으로 예약된 가상 머신 인스턴스를 사용하는 것이 더 경제적일 수 있다[2]. 또한 함수 실행 시간이 길어지거나 실행 빈도가 매우 높아지면 비용이 기하급수적으로 증가할 수 있어, 비용 모델을 정기적으로 검토하고 최적화하는 것이 중요하다.

서버리스 아키텍처는 이벤트 기반 실행 모델과 FaaS의 특성으로 인해 뛰어난 확장성과 탄력성을 제공한다. 이는 애플리케이션이 트래픽 변동에 자동으로 대응할 수 있게 한다. 서비스 공급자의 플랫폼이 인바운드 요청이나 이벤트의 수에 따라 함수 인스턴스를 실시간으로 생성하고 관리하기 때문이다.

확장은 거의 즉시 이루어지며, 개발자가 별도의 용량 계획이나 서버 프로비저닝을 할 필요가 없다. 트래픽이 급증하면 플랫폼이 자동으로 더 많은 함수 인스턴스를 병렬로 실행하여 부하를 분산한다. 반대로 트래픽이 감소하면 사용되지 않는 인스턴스는 자동으로 종료되어 리소스를 확보한다. 이는 주문형 확장성으로, 애플리케이션이 수요에 맞춰 탄력적으로 늘어나거나 줄어드는 것을 의미한다.

이러한 탄력성은 비용과도 직접적으로 연결된다. 사용자는 실제로 실행된 함수의 횟수와 실행 시간에 대해서만 비용을 지불한다. 따라서 리소스가 유휴 상태일 때의 비용이 발생하지 않아, 예측 불가능하거나 간헐적인 트래픽 패턴을 가진 애플리케이션에 특히 효율적이다.

그러나 이러한 확장 모델은 콜드 스타트 지연이라는 트레이드오프를 동반한다. 요청을 처리할 준비가 된 인스턴스가 없을 때 새 인스턴스를 시작하는 데 발생하는 초기 지연 시간이 그것이다. 또한, 각 함수 인스턴스는 일반적으로 스테이트리스하게 설계되어야 하며, 장기 실행 작업에는 적합하지 않을 수 있다.

서버리스 아키텍처의 핵심 장점 중 하나는 개발팀이 서버의 운영 및 관리에 대한 부담을 크게 덜 수 있다는 점이다. 전통적인 방식에서는 애플리케이션을 호스팅하기 위해 가상 머신이나 컨테이너를 프로비저닝하고, 운영 체제를 패치하며, 런타임 환경을 관리하고, 서버의 가용성과 성능을 지속적으로 모니터링해야 했다. 반면 서버리스 모델에서는 이러한 인프라 관리 책임이 클라우드 서비스 공급자로 완전히 이전된다. 개발자는 애플리케이션 코드, 즉 비즈니스 로직에만 집중할 수 있으며, 서버의 프로비저닝, 용량 계획, 운영 체제 유지보수, 보안 패치 적용 등은 모두 플랫폼 제공자가 담당한다.

이로 인해 데브옵스 팀의 작업 범위와 복잡성이 줄어들고, 조직의 운영 효율성이 향상된다. 특히 24시간 서비스를 유지해야 하는 시스템에서 발생하는 야간 또는 주말의 긴급 대응 업무 부담이 경감된다. 서버의 확장성과 가용성도 플랫폼 차원에서 보장되므로, 트래픽 급증 시 수동으로 서버를 추가하거나 스케일링 정책을 세밀하게 튜닝할 필요가 없다. 이는 인프라 관리에 투입되던 인력과 시간을 핵심 애플리케이션 개발과 기능 개선에 재할당할 수 있게 함으로써, 더 빠른 시장 출시와 혁신에 기여한다.

개발자는 인프라스트럭처 프로비저닝, 서버 관리, 운영 체제 패치, 용량 계획과 같은 저수준 운영 작업에 시간을 소모하지 않고, 순수한 애플리케이션 로직과 비즈니스 기능 개발에 집중할 수 있다. 이는 개발 주기를 단축하고 혁신에 더 많은 리소스를 투입할 수 있게 만든다.

서버리스 환경은 마이크로서비스를 함수 단위로 구현하는 데 매우 적합하다. 각 함수는 단일 책임 원칙에 따라 특정 이벤트에 응답하는 독립적인 단위로 설계된다. 이는 코드베이스를 작고 관리하기 쉬운 조각으로 분해하여 모듈성을 높이고, 팀별 독립적인 배포와 확장을 가능하게 한다. 또한 API 게이트웨이와 통합되어 전체 백엔드 서비스를 빠르게 구성할 수 있다.

대부분의 서버리스 플랫폼은 다양한 프로그래밍 언어와 프레임워크를 지원하며, 배포 프로세스가 단순화되어 있다. 개발자는 코드를 작성한 후 플랫폼에 업로드하기만 하면 배포와 운영이 자동으로 처리된다. 이는 개발부터 프로덕션 환경 출시까지의 시간을 극적으로 줄여준다.

콜드 스타트는 함수가 요청을 처리하기 위해 초기화되는 과정을 가리킨다. 이 과정에는 함수 코드를 다운로드하고, 런타임 환경을 시작하며, 필요한 라이브러리를 로드하는 작업이 포함된다. 함수가 일정 시간 동안 호출되지 않아 비활성 상태였다가 새로운 요청을 받으면, 플랫폼은 이러한 초기화 과정을 처음부터 수행해야 한다. 이로 인해 발생하는 첫 번째 요청의 응답 지연을 콜드 스타트 지연이라고 한다.

콜드 스타트 지연 시간은 사용하는 프로그래밍 언어, 함수 코드의 크기 및 복잡성, 연결된 라이브러리의 수, 그리고 클라우드 벤더의 특정 구현에 따라 크게 달라진다. 일반적으로 컴파일 언어(예: Go, Java)는 인터프리터 언어(예: Python, JavaScript)보다 초기화 시간이 더 길다. 또한, 함수가 VPC(Virtual Private Cloud)에 배치되거나 대용량의 파일을 포함하는 경우 지연이 더욱 두드러질 수 있다.

이러한 지연을 완화하기 위한 여러 전략이 존재한다. 정기적으로 함수를 호출하는 워밍 기법을 사용하거나, 함수의 메모리 할당량을 늘려 초기화 성능을 높일 수 있다. 또한, 함수 코드를 최소화하고 불필요한 의존성을 제거하며, 가능하면 경량화된 런타임을 선택하는 것이 중요하다. 일부 벤더는 프로비저닝된 동시성[3] 같은 기능을 제공하여 특정 함수 인스턴스를 미리 준비된 상태로 유지함으로써 콜드 스타트를 효과적으로 제거한다.

서버리스 아키텍처를 채택할 때, 애플리케이션의 핵심 로직이 특정 클라우드 공급자의 FaaS 플랫폼, BaaS 서비스, 그리고 해당 플랫폼의 고유한 이벤트 트리거, API 게이트웨이, 개발 도구 및 런타임 환경에 깊이 의존하게 되는 현상을 벤더 종속성이라고 한다. 이는 서버리스의 주요 단점 중 하나로 지적된다.

벤더 종속성은 여러 측면에서 문제를 일으킬 수 있다. 첫째, 플랫폼 간 이식성이 매우 낮아진다. 예를 들어, AWS Lambda에 최적화된 함수 코드, Amazon DynamoDB와의 통합 로직, Amazon API Gateway의 설정은 Google Cloud Functions나 Azure Functions로 쉽게 옮겨갈 수 없다. 각 공급자는 고유한 SDK, 트리거 메커니즘, 배포 및 구성 방식을 가지고 있기 때문이다. 둘째, 비용 구조와 서비스 한도가 플랫폼에 종속되어, 공급자가 가격 정책을 변경하거나 특정 서비스를 중단할 경우 애플리케이션 운영에 직접적인 영향을 미친다.

이러한 종속성을 완화하기 위한 몇 가지 접근법이 존재한다. 하나는 서버리스 프레임워크나 Terraform과 같은 인프라 코드 도구를 사용하여 배포와 구성을 추상화하는 것이다. 또 다른 방법은 핵심 비즈니스 로직을 플랫폼 특정 코드로부터 분리하고, 공급자 중립적인 인터페이스 뒤에 숨기는 설계 패턴(예: 어댑터 패턴)을 적용하는 것이다. 또한, Knative나 OpenFaaS와 같은 오픈소스 서버리스 플랫폼을 온프레미스나 여러 클라우드에 배포하는 것은 종속성을 근본적으로 피할 수 있는 대안이 될 수 있다. 그러나 이러한 접근들도 완전한 이식성을 보장하지는 않으며, 추가적인 설계와 관리 복잡성을 수반한다는 점을 고려해야 한다.

서버리스 환경에서의 디버깅은 함수가 단일 목적을 위해 짧게 실행되고 종료되며, 인프라가 완전히 추상화되어 있다는 점에서 고유한 어려움을 가진다. 개발자는 전통적인 서버 환경처럼 SSH로 직접 접속하거나 지속적인 프로세스 상태를 실시간으로 점검할 수 없다. 대신 로그, 추적 데이터, 그리고 플랫폼이 제공하는 모니터링 도구에 전적으로 의존해야 한다. 함수의 실행 실패는 복잡한 이벤트 기반 호출 체인 속에서 발생할 수 있으며, 특정 이벤트를 재현하거나 실패한 함수 인스턴스의 메모리 상태를 포착하는 것이 매우 어렵다.

모니터링 측면에서는 분산 추적의 필요성이 크게 부각된다. 하나의 비즈니스 요청이 여러 FaaS 함수와 BaaS 서비스를 거쳐 처리될 경우, 전체 요청 흐름을 통합적으로 관찰하는 것이 필수적이다. 이를 위해 AWS X-Ray, Azure Application Insights와 같은 클라우드 공급자의 분산 추적 서비스나 OpenTelemetry 같은 오픈소스 도구를 도입해야 한다. 또한 함수의 실행 빈도, 지연 시간, 에러율, 콜드 스타트 빈도 등 다양한 지표를 수집하고 시각화하여 성능 병목 현상을 파악해야 한다.

주요 모니터링 및 디버깅 과제는 다음 표와 같이 정리할 수 있다.

이러한 복잡성을 극복하기 위해서는 로깅과 모니터링을 애플리케이션 설계 초기부터 고려해야 한다. 함수 코드에 구조화된 로깅을 명시적으로 포함하고, 모든 중요한 비즈니스 로직과 예외 처리가 적절한 로그로 출력되도록 해야 한다. 또한 서버리스 애플리케이션의 상태를 종합적으로 볼 수 있는 대시보드를 구축하여 운영 부담을 줄이는 것이 중요하다.

서버리스 컴퓨팅 플랫폼은 일반적으로 함수의 최대 실행 시간에 제한을 둔다. 예를 들어, AWS Lambda의 경우 단일 함수 호출은 최대 15분 동안만 실행될 수 있다[5]. 이는 장시간 실행되는 배치 작업이나 복잡한 계산을 처리하는 데 제약이 될 수 있다.

함수의 성능은 콜드 스타트 외에도 할당된 메모리 크기와 밀접한 연관이 있다. 대부분의 플랫폼에서는 사용자가 함수에 할당할 메모리를 선택할 수 있으며, 이 메모리 크기에 비례하여 CPU 성능과 네트워크 대역폭도 함께 할당된다. 따라서 계산 집약적인 작업은 더 많은 메모리를 할당하여 성능을 높여야 하지만, 이는 비용 증가로 이어진다.

실행 환경은 일시적이며, 함수 실행이 종료된 후에는 로컬 스토리지에 저장된 모든 데이터가 사라진다. 이는 파일 시스템을 사용하는 전통적인 애플리케이션과는 다른 접근 방식을 요구한다. 또한, 동시 실행 수준에도 플랫폼별 제한이 존재할 수 있어, 급격한 트래픽 증가 시 스로틀링이 발생할 위험이 있다.

이벤트 기반 마이크로서비스는 서버리스 아키텍처의 가장 대표적인 사용 사례 중 하나이다. 이 패턴에서는 각 마이크로서비스가 독립적인 함수로 구현되며, 특정 이벤트가 발생했을 때만 실행된다. 이러한 이벤트의 예로는 HTTP 요청, 메시지 큐에 도착한 메시지, 데이터베이스 변경, 파일 업로드, 예약된 시간 등이 있다. 각 함수는 단일 책임을 가지며, 이벤트 소스에 의해 트리거되면 짧은 시간 동안 실행된 후 종료된다.

이 접근 방식은 시스템을 느슨하게 결합된 구성 요소들로 분해한다. 예를 들어, 사용자 등록 이벤트는 하나의 함수를 트리거하여 사용자 레코드를 생성하고, 이어서 환영 이메일 발송 함수와 분석 데이터 기록 함수를 별도의 이벤트로 연쇄적으로 실행할 수 있다. 이러한 이벤트 드리븐 아키텍처는 서비스 간의 직접적인 호출을 최소화하며, 확장성과 회복 탄력성을 높인다.

서버리스 환경에서 이벤트 기반 마이크로서비스를 구현할 때의 주요 이점은 다음과 같다.

그러나 이 모델은 분산 시스템의 복잡성을 내포한다. 트랜잭션 관리, 분산 추적, 데이터 일관성 보장이 더 어려워질 수 있으며, 함수 간 통신이 비동기 이벤트를 통해 이루어지기 때문에 디버깅과 테스트가 복잡해질 수 있다. 따라서 신중한 이벤트 스키마 설계와 강력한 모니터링 체계가 필수적이다.

서버리스 아키텍처는 ETL 및 데이터 처리 파이프라인 구축에 매우 적합한 모델이다. 이 접근 방식은 데이터가 발생하는 이벤트에 반응하여 함수를 실행하는 이벤트 기반 아키텍처를 기반으로 한다. 예를 들어, AWS S3에 새로운 파일이 업로드되거나, Apache Kafka 스트림에 메시지가 도착하거나, 데이터베이스에 변경이 발생할 때 이를 트리거로 하여 특정 데이터 처리 함수가 자동으로 실행된다. 이는 데이터의 흐름과 처리를 자연스럽게 연결하며, 지속적으로 실행되는 서버 인스턴스가 필요 없어 비용을 절감한다.

주요 사용 패턴은 데이터 변환, 정제, 집계, 그리고 다른 시스템으로의 이동을 포함한다. 일반적인 파이프라인은 데이터 수집, 변환 단계, 그리고 최종 저장소나 데이터 웨어하우스로의 적재 단계로 구성된다. 각 단계는 독립적인 FaaS 함수로 구현되어, 특정 작업만을 수행하고 결과를 다음 단계의 트리거로 전달한다. 이는 파이프라인의 각 구성 요소를 느슨하게 결합하고, 개별적으로 확장 및 유지 관리할 수 있게 한다.

서버리스 데이터 처리의 장점은 명확하다. 첫째, 사용한 컴퓨팅 시간에 대해서만 비용을 지불하므로, 배치 작업이 간헐적으로 실행되거나 데이터 유입량이 변동성이 큰 시나리오에서 매우 경제적이다. 둘째, 클라우드 제공자가 자동으로 처리량에 맞춰 함수 인스턴스를 확장하므로, 갑작스러운 데이터 폭증을 처리하는 데 탄력성이 뛰어나다. 마지막으로, 인프라 프로비저닝, 서버 패치, 런타임 관리와 같은 운영 부담이 크게 줄어든다.

그러나 몇 가지 설계상의 고려사항이 존재한다. 장시간 실행되는 데이터 처리 작업은 서버리스 함수의 최대 실행 시간 제한에 걸릴 수 있다. 이를 해결하기 위해 큰 작업을 더 작은 청크로 나누거나, 단계적 처리를 설계해야 한다. 또한, 함수 간에 상태를 전달하거나 중간 결과를 저장하기 위해 Amazon S3나 Redis 같은 외부 지속성 저장소를 활용해야 한다. 데이터 일관성과 오류 처리, 재시도 메커니즘을 신중하게 설계하는 것도 성공적인 파이프라인 구현의 핵심이다.

서버리스 아키텍처는 API 백엔드와 웹 애플리케이션을 구축하는 데 효과적인 패러다임이다. FaaS를 활용하면 각 API 엔드포인트를 개별 함수로 구현할 수 있으며, HTTP 요청, 파일 업로드, 데이터베이스 변경과 같은 이벤트에 의해 함수가 실행된다. 이를 통해 개발자는 서버 프로비저닝이나 운영 체제 관리 없이 비즈니스 로직에 집중할 수 있다. 또한, API 게이트웨이와 통합되어 요청 라우팅, 인증, 속도 제한 등의 기능을 제공받으며 완전한 RESTful API 또는 GraphQL 서비스를 구성할 수 있다.

웹 애플리케이션의 경우, 정적 파일 호스팅(S3, Cloud Storage)과 서버리스 백엔드 함수의 조합이 일반적인 아키텍처다. 사용자 인터페이스는 HTML, CSS, JavaScript 파일로 구성되어 CDN을 통해 제공되고, 모든 동적 기능(사용자 인증, 폼 제출, 데이터 조회)은 서버리스 함수를 호출하여 처리한다. 이는 전통적인 웹 서버가 항상 실행 중이어야 하는 모델과 달리, 실제 요청이 있을 때만 컴퓨팅 리소스가 소비되도록 한다.

이 접근 방식의 주요 장점은 탄력적인 확장성과 비용 효율성이다. 트래픽이 급증하는 시간대에 자동으로 함수 인스턴스가 추가되어 성능을 유지하며, 사용량이 없는 시간에는 비용이 전혀 발생하지 않는다. 또한, BaaS 서비스(인증, 데이터베이스, 파일 스토리지)와 쉽게 연동되어 전체 백엔드 인프라를 빠르게 구축할 수 있다.

그러나 장기 실행 작업이나 WebSocket과 같은 지속적 연결이 필요한 실시간 애플리케이션에는 적합하지 않을 수 있다. 대부분의 서버리스 플랫폼은 함수 실행 시간에 제한을 두기 때문이다. 따라서 세션 상태는 외부 저장소에 관리하고, 배치 작업은 더 작은 함수로 분할하는 등의 설계가 필요하다.

AWS Lambda는 아마존 웹 서비스가 제공하는 대표적인 FaaS 플랫폼이다. 2014년에 출시된 이후 서버리스 컴퓨팅의 대중화를 주도했다. 사용자는 자바, 파이썬, Node.js, Go, .NET 등 다양한 런타임으로 코드를 패키징하여 람다 함수로 업로드한다. 함수는 Amazon S3 버킷에 파일이 업로드되거나, Amazon API Gateway를 통한 HTTP 요청, Amazon DynamoDB의 테이블 변경, Amazon CloudWatch 이벤트 등 다양한 이벤트 소스에 의해 트리거되어 실행된다.

AWS Lambda의 주요 특징은 사용한 컴퓨팅 시간만큼만 비용을 지불하는 종량제 모델이다. 함수 실행 시간은 1밀리초 단위로 과금되며, 매월 일정량의 무료 요청을 제공한다. 플랫폼은 실행 요청이 증가하면 자동으로 함수 인스턴스를 복제하여 확장하며, 트래픽이 없을 때는 자원을 0으로 축소한다. 이는 예측 불가능하거나 간헐적인 트래픽 패턴을 가진 워크로드에 매우 효율적이다.

함수 구성 시 메모리 할당량(128MB ~ 10GB)을 설정하면, AWS Lambda가 그에 비례하는 CPU 성능과 네트워크 대역폭을 자동으로 할당한다. 최대 실행 시간은 15분으로 제한되어 있다. 함수는 AWS Identity and Access Management 정책을 통해 세밀하게 접근 제어할 수 있으며, Amazon CloudWatch Logs와 통합되어 실행 로그와 지표를 자동으로 수집한다.

주요 사용 사례로는 실시간 파일 처리, 백엔드 API 구축, 예약된 작업 실행, 챗봇 구현 등이 있다. AWS Lambda는 Amazon SQS, Amazon Kinesis, AWS Step Functions 등 다른 AWS 서비스와 긴밀하게 통합되어 복잡한 서버리스 애플리케이션을 구성하는 핵심 요소로 작동한다.

Azure Functions는 마이크로소프트의 클라우드 컴퓨팅 플랫폼인 Microsoft Azure에서 제공하는 서버리스 컴퓨팅 서비스이다. FaaS 모델을 구현하여 개발자가 인프라를 관리할 필요 없이 이벤트에 반응하는 코드를 실행할 수 있게 한다.

Azure Functions는 다양한 프로그래밍 언어를 지원하며, 트리거와 바인딩 시스템이 특징이다. 지원 언어에는 C#, JavaScript, Python, Java, PowerShell 등이 포함된다. 함수는 HTTP 요청, Azure Storage의 큐나 Blob 변경, Azure Service Bus 메시지, 타이머 이벤트 등 다양한 트리거에 의해 실행될 수 있다. 바인딩을 통해 함수에 입력 데이터를 선언적으로 제공하거나 출력 데이터를 다른 서비스에 전송하는 작업을 단순화한다.

Azure Functions는 여러 호스팅 플랜을 제공하여 유연성과 비용 효율성을 제공한다. 소비 플랜에서는 실제 사용량에 따라 과금되며 자동 확장이 지원된다. 프리미엄 플랜은 더 강력한 인스턴스와 VNet 통합, 콜드 스타트 감소 등의 기능을 제공한다. 전용(App Service) 플랜은 기존 Azure App Service 계획에서 함수를 실행하여 예측 가능한 성능과 장기 실행 작업을 가능하게 한다.

이 플랫폼은 Azure DevOps 및 GitHub Actions와의 통합, 내장된 모니터링 도구, 그리고 Docker 컨테이너를 통한 함수 배포도 지원한다. 이를 통해 개발부터 배포, 모니터링에 이르는 전체 생명주기를 관리하는 데 도움을 준다.

Google Cloud Functions는 구글 클라우드 플랫폼(GCP)에서 제공하는 완전 관리형 FaaS 서비스이다. 이 서비스는 개발자가 서버 프로비저닝, 관리, 패치 적용 등의 인프라 운영 부담 없이 코드를 실행할 수 있게 한다. 함수는 HTTP 요청, 클라우드 스토리지 버킷의 파일 변경, 퍼브/섭 메시지, 파이어스토어 문서 업데이트 등 다양한 이벤트에 의해 트리거된다.

주요 특징으로는 다중 프로그래밍 언어 지원, 다른 GCP 서비스와의 긴밀한 통합, 그리고 사용한 컴퓨팅 시간과 호출 횟수만큼만 지불하는 종량제 가격 모델을 들 수 있다. 지원되는 언어에는 Node.js, Python, Go, Java, .NET, Ruby, PHP 등이 포함된다. 또한 Cloud Run 및 App Engine과 함께 GCP의 서버리스 제품군을 구성하여 다양한 워크로드 요구사항에 맞는 배포 옵션을 제공한다.

다음은 Google Cloud Functions의 핵심 구성 요소와 트리거 유형을 정리한 표이다.

주요 트리거 유형은 다음과 같다.

* HTTP 트리거: 표준 HTTP 요청을 통해 함수를 호출한다. RESTful API 또는 웹훅을 구축하는 데 적합하다.

* 백그라운드 트리거(이벤트 기반): GCP 서비스에서 발생한 이벤트에 반응하여 함수를 실행한다. 대표적인 이벤트 소스로는 Cloud Storage(파일 업로드/삭제), Cloud Pub/Sub(메시지 수신), Firestore(문서 생성/수정) 등이 있다.

이 서비스는 내장된 모니터링, 로깅, 추적 기능을 통해 운영 가시성을 제공하며, Cloud Build를 통한 지속적 배포와 통합 IAM(Identity and Access Management)을 통한 보안 정책 관리도 지원한다.

함수 설계는 단일 책임 원칙을 엄격히 적용하여 각 함수가 하나의 명확한 작업만 수행하도록 구성하는 것이 중요하다. 함수의 크기는 작고 집중적으로 유지하며, 복잡한 비즈니스 로직은 여러 개의 협력하는 함수로 분해하는 것이 바람직하다. 이는 함수의 재사용성을 높이고, 테스트를 용이하게 하며, 개별적인 배포와 확장을 가능하게 한다.

함수 간의 결합도를 낮추기 위해 이벤트 기반 아키텍처를 적극 활용한다. 함수는 직접적인 호출보다는 메시지 큐나 이벤트 버스를 통해 간접적으로 통신하도록 설계한다. 이는 시스템의 탄력성과 내고장성을 향상시키는 핵심 패턴이다. 함수의 입력과 출력은 가능한 한 단순한 데이터 구조를 사용하고, 플랫폼에 특화된 객체나 무거운 컨텍스트를 전달하는 것을 피해야 한다.

상태 관리 측면에서 서버리스 함수는 기본적으로 무상태성을 가정한다. 따라서 지속적인 상태 정보는 외부 저장소인 데이터베이스나 캐시 서비스에 위임해야 한다. 세션 상태를 함수 내부에 보관하려는 시도는 확장성과 내구성에 문제를 일으킬 수 있다. 함수의 실행 시간과 메모리 할당량은 비용과 성능에 직접적인 영향을 미치므로, 예상되는 워크로드에 맞게 적절히 설정해야 한다.

보안 설계에서는 최소 권한 원칙을 적용하여 각 함수에 필요한 최소한의 권한만 부여하는 역할 기반 접근 제어를 구성한다. 함수가 접근하는 외부 서비스와 API에 대한 인증 정보는 환경 변수나 전용 비밀 관리 서비스를 통해 안전하게 관리해야 한다. 공용 네트워크에 노출될 필요가 없는 함수는 프라이빗 서브넷 내에서 실행되도록 네트워크 구성을 검토한다.

서버리스 아키텍처에서 함수는 기본적으로 무상태성을 가정한다. 각 함수 실행은 독립적이며, 이전 호출의 상태를 보존하지 않는다. 이는 확장성과 내결함성을 보장하는 핵심 원리이지만, 애플리케이션이 상태를 유지해야 할 때는 외부 상태 저장소를 활용해야 한다. 일반적으로 Amazon DynamoDB, Azure Cosmos DB, Redis와 같은 관리형 데이터베이스나 캐시 서비스를 사용하여 상태를 외부화한다.

데이터 일관성을 보장하는 것은 서버리스 환경에서 주요 과제 중 하나이다. 이벤트 기반 아키텍처와 분산된 함수 실행은 최종 일관성 모델로 동작하는 경우가 많다. 여러 함수가 공유 데이터를 순차적이 아닌 병렬로 처리할 때, 트랜잭션의 ACID 속성을 완전히 보장하기 어렵다. 이를 해결하기 위해 사가 패턴과 같은 분산 트랜잭션 관리 패턴을 적용하거나, 이벤트 소싱 방식을 통해 상태 변경을 일련의 불변 이벤트로 기록하여 일관성을 유지하는 방법을 사용한다.

상태 관리 접근 방식은 다음과 같이 요약할 수 있다.

따라서 설계 시에는 함수의 무상태성을 유지하면서, 필요한 상태는 적절한 외부 서비스에 위임하고, 데이터 일관성 요구사항에 맞는 패턴(강한 일관성 vs 최종 일관성)을 선택하는 것이 중요하다. 특히 분산 시스템의 특성을 이해하고, 재시도 메커니즘과 멱등성을 고려한 함수 설계가 필수적이다.

서버리스 아키텍처에서 보안은 공유 책임 모델에 기반한다. 클라우드 제공자는 인프라, 플랫폼 런타임, 물리적 보안을 책임지는 반면, 개발자는 애플리케이션 코드, 함수 구성, 데이터 보안, 그리고 세분화된 접근 제어 정책을 관리할 책임이 있다. 이 모델은 운영 부담을 줄여주지만, 애플리케이션 계층의 보안 책임이 개발팀으로 완전히 이전된다는 점을 인지해야 한다.

접근 제어는 최소 권한 원칙을 적용하여 구성하는 것이 핵심이다. 각 FaaS 함수는 실행에 필요한 최소한의 권한만 부여받아야 한다. 예를 들어, AWS Lambda에서는 IAM 역할과 정책을, Azure Functions에서는 관리 ID를 통해 함수별 권한을 세밀하게 제어할 수 있다. 함수 간 통신 시에는 공용 인터넷을 노출하지 않고 프라이빗 엔드포인트나 VPC 내부 네트워크를 활용해야 한다. 또한, API 게이트웨이를 통한 모든 외부 요청에는 인증(OAuth, JWT) 및 권한 부여 메커니즘이 필수적으로 적용되어야 한다.

보안 위협에 대한 대응으로는 입력 데이터의 유효성 검증을 통해 인젝션 공격을 방지하고, 함수 코드와 의존성 라이브러리에 대한 정기적인 취약점 점검을 수행해야 한다. 민감한 구성 정보는 환경 변수에 평문으로 저장하기보다 시크릿 관리 서비스를 활용하여 안전하게 관리한다. 로깅과 모니터링을 통해 비정상적인 실행 패턴이나 접근 시도를 실시간으로 탐지할 수 있는 체계를 마련하는 것도 중요하다.

서버리스 아키텍처와 모놀리식 아키텍처는 근본적으로 다른 애플리케이션 구성 및 운영 방식을 나타낸다. 모놀리식 아키텍처는 모든 비즈니스 로직이 단일, 통합된 코드베이스 내에 패키징되어 하나의 프로세스로 실행되는 구조이다. 반면 서버리스 아키텍처, 특히 FaaS는 애플리케이션을 작고 독립적인 함수 단위로 분해하여, 각 함수가 특정 이벤트에 의해 트리거될 때만 실행되도록 설계한다. 이 차이는 배포, 확장, 리소스 관리에 직접적인 영향을 미친다.

운영 및 관리 측면에서 두 방식은 극명한 대조를 보인다. 모놀리식 애플리케이션은 개발팀이 서버나 가상 머신의 프로비저닝, 운영 체제 관리, 런타임 환경 유지, 애플리케이션의 지속적인 모니터링과 패치 등 전체 인프라 스택에 대한 책임을 진다. 확장은 일반적으로 애플리케이션 전체를 복제하는 수직 또는 수평 확장 방식을 취한다. 서버리스 모델에서는 클라우드 공급자가 서버 관리, 용량 계획, 패치 적용, 기본적인 가용성 보장을 책임지므로, 개발자는 비즈니스 로직 구현에 더 집중할 수 있다. 확장성은 완전히 자동화되어 트래픽 증가에 따라 개별 함수 인스턴스가 동적으로 생성되고 소멸된다.

비용 구조와 자원 활용도에서도 중요한 차이가 존재한다. 모놀리식 아키텍처는 애플리케이션이 24시간 365일 실행되는 서버 또는 컨테이너 인스턴스에 배포되므로, 사용량에 관계없이 인프라 비용이 지속적으로 발생한다. 서버리스 아키텍처는 이벤트 기반 실행 모델을 채택하여, 함수가 실제로 요청을 처리하는 실행 시간과 할당된 메모리 양에 대해서만 비용을 지불한다. 유휴 상태일 때는 비용이 발생하지 않아 변동성이 큰 워크로드에 매우 경제적이다. 다음 표는 핵심 차이점을 요약한다.

결론적으로, 모놀리식 아키텍처는 제어력이 높고 내부 통신이 간단하며 초기 구성이 비교적 직관적이라는 장점이 있지만, 확장성과 민첩성에 한계가 있다. 서버리스 아키텍처는 운영 부담을 줄이고 탁월한 탄력성과 비용 효율성을 제공하지만, 분산 시스템 고유의 디버깅 난이도와 벤더 종속성 같은 새로운 도전 과제를 안겨준다.

서버리스 아키텍처와 전통적인 마이크로서비스 아키텍처(MSA)는 모두 분산 시스템을 구축하는 패러다임이지만, 인프라 관리와 실행 모델에서 근본적인 차이를 보인다.

전통적 MSA는 각 서비스가 독립적으로 배포 가능한 애플리케이션으로, 개발팀이 서비스의 런타임 환경(컨테이너 또는 가상 머신)을 프로비저닝, 관리, 패치 및 확장해야 한다. 이는 오케스트레이션 도구(예: 쿠버네티스)에 대한 전문 지식과 지속적인 운영 부담을 수반한다. 반면 서버리스 아키텍처, 특히 FaaS는 인프라 관리 책임이 거의 완전히 클라우드 제공자로 이전된다. 개발자는 비즈니스 로직(함수)만 작성하며, 플랫폼이 실행, 확장, 가용성 보장을 자동으로 처리한다.

아키텍처 구성과 비용 모델도 대비된다. 전통적 MSA는 일반적으로 서비스가 항상 실행되는 상태를 유지하는 상시 실행 모델을 사용하며, 사용량에 관계없이 할당된 인프라에 대한 비용이 발생한다. 서버리스는 이벤트 기반 실행 모델로, 함수가 트리거될 때만 인스턴스가 생성되고 실행된 시간과 리소스 사용량에 따라 정밀하게 과금된다[6]. 이는 변동성이 큰 트래픽 패턴에서 비용 효율성이 뛰어나다.

다음 표는 주요 차이점을 요약한다.

그러나 서버리스는 실행 시간 제한, 콜드 스타트 지연, 분산 모니터링의 복잡성, 특정 제공자의 API 및 서비스에 대한 종속성 증가 등의 한계를 가진다. 따라서 장기 실행 프로세스나 매우 예측 가능한 부하를 가진 안정적인 서비스에는 전통적 MSA가 더 적합할 수 있다. 선택은 애플리케이션의 특성, 팀의 운영 역량, 비용 구조 등 종합적인 요인에 따라 결정된다.