[실전 서버리스 03] 비용의 진실, CPU 시간만 내는 과금이 바꾸는 것

개인 개발자가 서버리스에 끌리는 가장 현실적인 이유는 비용이다. 서버 한 대를 24시간 빌리면 놀고 있어도 돈이 나가지만, 서버리스는 쓴 만큼만 낸다. 그런데 그 쓴 만큼의 계산법이 플랫폼마다 다르고, 이걸 이해하면 왜 어떤 서버리스는 싸고 어떤 건 비싼지가 보인다. 이번 편은 서버리스 과금 구조, 특히 CPU 시간 과금의 의미를 파고든다.

비용은 개인 프로젝트의 생사를 가른다. 취미로 만든 사이트에 매달 수십만 원이 나가면 유지가 안 된다. 그래서 과금 구조를 정확히 아는 게 서버리스 선택의 핵심이다.

1. 전통 서버의 비용 문제

전통적인 서버는 시간당 혹은 월정액으로 빌린다. 문제는 이게 사용량과 무관하게 나간다는 것이다. 새벽에 방문자가 0명이어도, 서버는 켜져 있으니 그 시간만큼 요금이 붙는다. 트래픽이 없는 시간까지 다 돈을 내는 셈이다.

개인 사이트는 대부분 트래픽이 불규칙하다. 어쩌다 글 하나가 화제가 되면 몰리고, 평소엔 한산하다. 그런데 몰릴 때를 대비해 큰 서버를 빌려두면, 한산한 대부분의 시간에 그 큰 서버가 놀면서 돈만 먹는다. 반대로 작은 서버를 빌리면 몰릴 때 감당을 못 한다. 딜레마다.

서버리스는 이 딜레마를 없앤다. 요청이 있을 때만 실행되고 그때만 과금되니, 새벽에 아무도 안 오면 비용이 0에 수렴한다. 몰리면 알아서 늘어나 감당하고 그만큼만 낸다. 미리 용량을 정해두고 그 값을 내는 게 아니라, 실제로 처리한 만큼만 낸다. 불규칙한 개인 사이트에 딱 맞는 구조다.

전통 서버 비용의 비효율을 겪어본 사람은 안다. 트래픽 대비 과한 서버를 놀리며 돈을 내거나, 아끼려고 작은 서버를 썼다가 몰릴 때 사이트가 죽는 경험이다. 어느 쪽이든 손해다. 용량을 미리 정해야 한다는 것 자체가 불규칙한 트래픽에는 근본적으로 안 맞는 모델이었다.

조금 더 배경을 주면, 비용은 개인 프로젝트의 지속 가능성을 결정한다. 아무리 좋은 사이트도 매달 큰돈이 나가면 언젠가 접게 된다. 그래서 과금 구조를 이해하고 저렴하게 유지하는 능력은 기능 개발만큼 중요하다. 오래 살아남는 사이트는 대개 비용 관리를 잘한 사이트다.

2. 요청 수 과금과 CPU 시간 과금

서버리스 과금에서 핵심 개념이 무엇을 기준으로 재느냐다. 크게 두 가지가 있다. 하나는 요청을 처리하는 데 걸린 총 시간, 즉 벽시계 시간이고, 다른 하나는 실제로 CPU를 쓴 시간이다. 이 둘의 차이가 비용을 크게 가른다.

예를 들어 어떤 요청이 데이터베이스에서 응답을 기다리느라 2초가 걸렸다고 하자. 그런데 그 2초 중 실제로 CPU가 일한 건 5밀리초뿐이고, 나머지는 그냥 기다린 시간이다. 벽시계 시간으로 과금하는 플랫폼은 이 2초를 다 청구한다. 반면 CPU 시간으로 과금하는 플랫폼은 5밀리초만 청구한다.

웹 서비스는 데이터베이스나 외부 API 응답을 기다리는 시간이 대부분이다. 실제 CPU 연산은 짧고, 기다리는 시간이 길다. 그래서 CPU 시간 과금이 웹 서비스에 압도적으로 유리하다. 기다리는 동안은 공짜이기 때문이다. 내가 쓴 플랫폼이 이 CPU 시간 과금 방식이라, 데이터베이스를 많이 쓰는 커뮤니티에 특히 저렴했다.

요청 수와 CPU 시간 과금의 차이를 하나 더 강조하면, 이건 웹 서비스에서 특히 극적이다. 웹 요청은 데이터베이스나 외부 API를 기다리는 시간이 실제 연산보다 훨씬 길기 때문이다. 그 기다리는 시간이 공짜인지 아닌지가 청구서를 몇 배로 가른다. 그래서 웹 서비스라면 과금 기준을 반드시 확인해야 한다.

3. 구체적인 비용 감각

구체적인 숫자로 감을 잡아보자. 내가 쓴 플랫폼의 유료 요금제는 월 5달러 정도의 기본료에 요청 천만 건이 포함된다. 그걸 넘으면 백만 건당 몇십 센트 수준이 추가된다. 그리고 중요한 건, 대역폭 요금이 0이라는 점이다.

대역폭 요금이 0이라는 게 생각보다 크다. 전통적인 클라우드는 데이터가 밖으로 나갈 때, 즉 사용자에게 페이지나 이미지를 보낼 때 대역폭 요금을 매긴다. 이미지가 많은 사이트는 이 대역폭 비용이 상당하다. 그런데 이게 0이면 이미지를 아무리 많이 서빙해도 그 부분 비용은 안 나간다. 미디어가 많은 커뮤니티에 유리하다.

다른 플랫폼과 비교하면 차이가 더 뚜렷하다. 어떤 플랫폼은 사용자 자리당 월 20달러씩 받고 여러 항목을 각각 과금한다. 웹 API나 고트래픽 서비스 기준으로는 CPU 시간 과금 플랫폼이 대체로 절반 이하로 저렴하다는 비교가 많다. 물론 워크로드에 따라 다르니 단정은 위험하지만, 웹 서비스라면 CPU 시간 과금 쪽이 유리한 경우가 많다.

대역폭 0의 값어치를 조금 더 짚으면, 이미지와 동영상이 많은 커뮤니티에서 이건 결정적이다. 전통 클라우드에서 미디어가 많은 사이트는 대역폭 비용이 서버 비용을 넘기도 한다. 사용자가 이미지를 볼 때마다 돈이 나가는 구조이기 때문이다. 그게 0이면 미디어를 마음껏 서빙해도 그 부분은 걱정이 없다.

구체적 비용 감각에서 하나 더, 무료 요금제로도 상당한 규모까지 굴러간다는 점이 개인에게 크다. 시작 단계에서는 돈을 한 푼도 안 내고 사이트를 띄우고 키울 수 있다. 트래픽이 무료 한도를 넘길 즈음이면 이미 서비스가 자리를 잡은 뒤라, 그때 유료로 넘어가면 된다. 위험 없이 시작할 수 있는 것이다.

4. 데이터베이스 비용은 따로

주의할 게 있다. 코드 실행 비용이 싸다고 전체가 싼 건 아니다. 데이터베이스나 스토리지는 별도로 과금된다. 특히 데이터베이스는 뒤에서 자세히 다루겠지만, 잘못 쓰면 여기서 비용이 튈 수 있다. 코드 실행은 CPU 시간 과금이라 싼데, 데이터베이스에서 비효율적인 쿼리를 날리면 그쪽 비용이 커진다.

실제로 내가 겪은 것도, 코드 실행 비용은 거의 안 나오는데 데이터베이스 읽기가 폭증해서 한도에 부딪힌 적이 있다. 그래서 서버리스 비용을 관리한다는 건 코드 실행만이 아니라 데이터베이스와 스토리지까지 종합적으로 보는 것이다. 이건 뒤에서 D1 최적화와 비용 폭탄 편에서 실전으로 다룬다.

그래도 큰 그림은 분명하다. 각 부분이 쓴 만큼만 과금되고 놀 때는 0에 수렴하니, 트래픽이 적은 개인 사이트는 전체 비용이 매우 낮게 유지된다. 내 커뮤니티도 초기엔 사실상 공짜에 가까운 비용으로 굴렸다. 성장하면서 비용이 붙긴 했지만, 그마저도 전통 서버보다 훨씬 쌌다.

데이터베이스 비용이 따로라는 점은 아무리 강조해도 지나치지 않다. 코드 실행이 싸다고 방심하다가 데이터베이스에서 비용이 터지는 게 서버리스 초보의 흔한 함정이다. 나도 그랬다. 그래서 서버리스 비용은 코드, 데이터베이스, 스토리지를 한 묶음으로 봐야지 한 부분만 보면 안 된다.

5. 비용이 개인 개발을 가능하게 한다

이 비용 구조가 개인 개발자에게 주는 의미는 크다. 예전엔 전 세계에 서비스하는 사이트를 개인이 유지하기 어려웠다. 서버 비용, 여러 지역 인프라, 대역폭 비용이 만만치 않았기 때문이다. 그런데 서버리스와 엣지는 이 진입 장벽을 무너뜨렸다.

이제 개인이 취미로 만든 사이트도 전 세계에 빠르게 서비스하면서, 트래픽이 적을 땐 거의 공짜로 유지할 수 있다. 사용자가 늘어 비용이 붙기 시작할 땐, 이미 그만큼 서비스가 커진 뒤라 감당할 여력도 생긴다. 성장에 따라 비용이 자연스럽게 따라오는 구조라, 처음부터 큰돈을 걸 필요가 없다.

정리하면 서버리스는 쓴 만큼만 내고, 특히 CPU 시간 과금은 기다리는 시간이 공짜라 웹 서비스에 유리하며, 대역폭 0까지 더해져 개인 사이트를 저렴하게 유지시킨다. 여기까지가 왜 서버리스인가에 대한 답이다. 다음 편부터는 실전으로 들어가, 첫 번째 워커를 실제로 배포하고 라우팅을 짜는 이야기를 다룬다.

비용이 개인 개발을 가능하게 한다는 게 이 편의 진짜 메시지다. 예전이라면 엄두도 못 냈을 글로벌 서비스를, 지금은 개인이 취미로 시작해 거의 공짜로 굴리다가 성장에 맞춰 비용을 감당해간다. 이 낮은 진입 장벽이 개인 개발자에게 열어준 가능성이 이 시리즈 전체를 관통하는 배경이다.

비용이 개인 개발을 가능하게 한다는 이 편의 결론은, 사실 이 시리즈 전체를 관통하는 정신이기도 하다. 서버리스와 엣지는 예전에 대기업만 하던 것을 개인의 손에 쥐여줬다. 그 도구를 제대로 이해하고 쓰면, 혼자서도 전 세계에 서비스하는 사이트를 만들고 유지할 수 있다. 이 가능성이 이 시리즈를 쓰는 이유다.

덧붙이면, 이 CPU 시간 과금 구조를 제대로 활용하려면 코드를 그에 맞게 짜는 것도 중요하다. 무거운 연산을 요청 처리 안에서 오래 붙잡지 말고, 기다리는 작업은 비동기로 넘기는 식이다. 과금 구조를 이해하면 코드를 어떻게 짜야 저렴한지도 보인다. 이건 뒤에서 비동기 처리와 큐를 다룰 때 이어진다.