Serverless는 애플리케이션 개발자가 서버 관리(프로비저닝, 확장, 패치 등)를 직접 하지 않아도 되도록 클라우드 제공자가 인프라 운영을 추상화해주는 컴퓨팅 모델입니다. 이름은 “서버가 없다”는 의미가 아니라, 서버를 신경 쓸 필요가 없도록 서버 운영을 투명하게 숨긴다는 뜻입니다. 주요 개념 - FaaS(Function as a Service): 개발자가 개별 함수(또는 작은 코드 단위)를 배포하고, 이벤트가 발생할 때만 실행되는 형태. 예: AWS Lambda, Azure Functions, Google Cloud Functions. - BaaS(Backend as a Service): 인증, 데이터베이스, 스토리지, 푸시 알림 등 백엔드 기능을 관리형 서비스로 제공. 예: Firebase Auth/Firestore, Auth0, Amazon Cognito 등. - 이벤트 기반: HTTP 요청, 메시지 큐, 파일 업로드, 타이머 등 이벤트에 의해 함수가 트리거됨. - 무상태(stateless) 및 단기 실행: 함수는 요청 간 상태를 유지하지 않고, 일반적으로 실행 시간이 제한됨(플랫폼별 제한 있음). - 자동 확장: 트래픽에 따라 인스턴스가 자동으로 생성/소멸되어 확장과 축소를 자동으로 처리. - 사용량 기반 과금: 실제 실행 시간이나 호출 수에 따라 과금되어 유휴 자원에 대한 비용이 없음. 장점 - 운영 부담 감소: 서버 프로비저닝, 패치, 운영체제 관리 등을 신경 쓰지 않아도 됨. - 비용 효율성: 사용한 만큼만 비용을 지불하므로 저활용 워크로드에 유리. - 빠른 개발 속도: 작은 단위로 개발·배포 가능하며, 관리형 서비스와의 통합이 쉬움. - 자동 확장성: 갑작스러운 트래픽 증가에 대해 탄력적으로 대응. 단점 및 고려사항 - 콜드 스타트: 오랫동안 유휴 상태였던 함수가 처음 호출될 때 지연이 발생할 수 있음(프로비저닝 등으로 완화 가능). - 실행 시간/리소스 제한: 긴 실행 작업에 부적합한 경우가 있음(백그라운드 작업은 별도 설계 필요). - 상태 관리: 지속적 상태가 필요한 경우 외부 데이터 저장소(데이터베이스, 캐시)를 사용해야 함. - 벤더 락인: 클라우드 제공자 고유 기능을 많이 사용하면 다른 플랫폼으로의 이식이 어려울 수 있음. - 디버깅·관측성: 분산된 작은 함수들의 로그·트레이스 추적이 복잡해질 수 있음(분산 추적·로깅 도구 필요). - 비용 예측의 어려움: 불규칙한 호출 패턴에서는 비용이 급증할 수 있음. 사용 사례 - API 백엔드(경량 REST/GraphQL 엔드포인트) - 이벤트 처리(파일 업로드 후 처리, 메시지 소비) - 실시간 데이터 처리(스트림 처리의 일부) - 예약 작업(크론) - 프로토타입 및 빠른 MVP 개발 - 인증·파일 스토리지·푸시 알림 같은 관리형 백엔드 기능 실제 서비스 예 - 컴퓨팅(FaaS): AWS Lambda, Azure Functions, Google Cloud Functions - 관리형 백엔드(BaaS): Firebase(인증, DB), DynamoDB(관리형 NoSQL), Auth0 - 컨테이너 기반 대체: AWS Fargate 등으로 서버 관리는 줄이되 컨테이너 실행 방식 유지 가능 요약 Serverless는 서버 자체가 사라진 개념이 아니라 서버 관리를 개발자 대신 클라우드 제공자가 맡아주고, 개발자는 이벤트 중심의 작은 코드 단위와 관리형 서비스를 조합해 애플리케이션을 빠르고 비용효율적으로 운영할 수 있게 해주는 아키텍처 패러다임입니다. 용도와 제약을 고려해 적절히 선택하면 운영 비용과 개발 시간을 크게 줄일 수 있습니다.
