서버리스 컴퓨팅이란 무엇이고, 함수 요금은 어떻게 매겨지나

게시 2026.07.15 · 약 5분 분량

핵심 요약 서버리스 컴퓨팅은 서버 관리 없이 함수 코드만 올려 쓴 만큼 내는 실행 방식이다. AWS 공식 요금 기준 Lambda 무료 한도 100만 요청, 기본 타임아웃 3초와 콜드 스타트, AWS·클라우드플레어·구글의 무료 한도 차이를 개발자 관점에서 짚었다.

서버리스 컴퓨팅은 서버를 직접 준비하거나 관리하지 않고 함수 단위 코드만 올려 두면, 요청이 들어올 때만 클라우드가 실행하고 쓴 만큼만 비용을 매기는 실행 방식이다. 2026년 7월 기준 AWS 공식 요금 페이지에 따르면 대표 서비스인 AWS Lambda는 매달 요청 100만 건과 연산 40만 GB-초를 영구 무료로 제공한다. 이 글은 개발자 입장에서 서버리스란 무엇인지, 함수가 어떻게 실행되고 요금이 매겨지는지, AWS·클라우드플레어·구글 클라우드의 무료 한도가 어떻게 다른지를 다룬다. 특정 프레임워크 설치법이나 배포 실습은 범위 밖이다.

서버리스란 정확히 무엇인가

서버가 없다는 뜻이 아니라, 서버 운영을 개발자가 신경 쓰지 않는다는 뜻이다. 코드는 여전히 어딘가의 서버에서 돌지만, 그 서버를 언제 몇 대 띄우고 언제 내릴지는 클라우드가 결정한다.

기술적으로 서버리스는 두 조각으로 나뉜다. 하나는 FaaS(Function as a Service, 함수 단위로 코드를 올려 이벤트가 올 때만 실행하는 서비스)이고, 다른 하나는 BaaS(Backend as a Service, 인증·데이터베이스·저장소처럼 이미 만들어진 백엔드 기능을 API로 빌려 쓰는 서비스)다. 흔히 말하는 "서버리스 함수"가 바로 FaaS다. UC 버클리가 2019년 낸 보고서 'Cloud Programming Simplified'는 서버리스를 이 둘의 조합으로 정의했다.

시작점은 분명하다. 아마존이 2014년 공개한 AWS Lambda가 함수 단위 실행이라는 FaaS 모델을 대중화했고, 뒤이어 마이크로소프트 Azure Functions, 구글 Cloud Functions(현재 Cloud Run functions로 통합), 클라우드플레어 Workers가 같은 흐름을 이었다.

함수 실행 방식과 요금이 매겨지는 원리

요청이나 이벤트가 도착한 순간에만 함수가 깨어나 실행되고, 일이 끝나면 사라진다. 그래서 요금도 서버를 켜 둔 시간이 아니라 함수가 실제로 실행된 횟수와 시간으로 매긴다.

과금 단위는 크게 두 가지다. 하나는 호출 횟수, 다른 하나는 실행 시간에 할당 메모리를 곱한 GB-초다. 예를 들어 512MB(0.5GB)를 할당한 함수가 2초 동안 돌면 1 GB-초를 쓴 셈이다. AWS 공식 문서에 따르면 Lambda 함수의 메모리는 128MB에서 10,240MB 사이로 설정할 수 있고, 할당 메모리를 키우면 CPU도 비례해 늘어난다.

이 구조 덕분에 트래픽이 없는 시간에는 요금이 0에 수렴한다. 반대로 한 함수가 초당 수천 번씩 꾸준히 호출되는 서비스라면, 항상 켜 두는 상시 인스턴스(예: EC2)가 오히려 더 쌀 수 있다. 요금 모델이 유리한 구간은 평소엔 한가하다가 가끔 몰리는 트래픽이다.

AWS·클라우드플레어·구글의 무료 한도 비교

세 서비스의 영구 무료 한도를 나란히 두면 차이가 분명하다. 아래 수치는 각 사의 공식 문서와 요금 페이지 기준이며, 요금제와 지역에 따라 달라질 수 있다.

눈여겨볼 점은 클라우드플레어 Workers 공식 문서 기준 무료 한도가 월이 아니라 하루 단위(UTC 자정 초기화)이고, 요청당 CPU 시간이 10ms로 묶인다는 것이다. 이 10ms는 순수 연산 시간이라 외부 API 응답을 기다리는 대기 시간은 빠진다. 한편 구글 클라우드 공식 문서 기준 Cloud Run functions는 HTTP 함수를 최대 60분까지 돌릴 수 있어, 오래 걸리는 배치 작업에는 Lambda의 15분보다 여유가 있다.

서버리스 아키텍처의 장점과 콜드 스타트라는 함정

서버리스 아키텍처의 가장 큰 이점은 운영 부담이 줄어든다는 점이다. OS 패치, 오토스케일링 설정, 용량 산정을 클라우드가 맡고, 트래픽이 튀면 함수 인스턴스가 알아서 늘어난다.

대신 콜드 스타트(cold start, 한동안 안 쓰던 함수를 다시 깨울 때 붙는 초기화 지연)라는 대가가 따른다. 호출이 뜸했던 함수는 실행 환경이 이미 종료돼 있어서, 다음 요청 때 코드를 다시 로드하고 준비하는 시간이 응답에 얹힌다. AWS 공식 문서도 유휴 상태가 이어지면 실행 환경이 정리되고 다음 호출에서 콜드 스타트가 생긴다고 설명한다. 지연에 민감한 API라면 이 첫 응답 지연을 반드시 측정해 봐야 한다.

실무에서 자주 발목을 잡는 또 다른 지점은 타임아웃이다. AWS 공식 문서 기준 Lambda의 기본 타임아웃은 3초이고, 콘솔에서 최대 900초(15분)까지 늘릴 수 있다. 기본값 3초를 모른 채 배포했다가 조금 무거운 작업에서 함수가 중간에 잘리는 일이 흔하다. 다음은 AWS Lambda의 가장 기본적인 Node.js 핸들러다.

exports.handler = async (event) => {
 return {
 statusCode: 200,
 body: JSON.stringify({ message: "Hello from Lambda" }),
 };
};

함수가 어디서 느려지는지 짚으려면 요청 흐름을 구간별로 들여다보는 관측 도구가 필요하다. 서버 쪽 요청 지연을 추적하는 접근은 Swift 서버 요청이 어디서 느려지는지 추적한 글에서 구체적으로 다뤘다.

언제 서버리스를 고르고 언제 피하나

모든 워크로드에 서버리스가 답은 아니다. 실무에서 쓰는 판단 기준을 간추리면 이렇다.

• 잘 맞는 경우: 웹훅 처리, 이미지 리사이징, 예약 배치, 프로토타입처럼 평소엔 한가하다가 가끔 몰리는 작업.
• 다시 생각할 경우: 콜드 스타트가 곧 장애로 이어지는 초저지연 실시간 처리, 초당 호출이 늘 매우 높은 상시 서비스(상시 인스턴스가 더 저렴할 수 있음), 한 번 실행이 15분을 넘는 장시간 배치.

결국 서버리스는 서버를 없애는 기술이 아니라, 서버 운영 책임을 클라우드로 옮기고 쓴 만큼만 내는 실행 모델이다. 무료 한도 안에서 작은 함수부터 올려 콜드 스타트와 타임아웃을 직접 측정해 본 뒤 범위를 넓히는 편이 안전하다.