서버리스라면서요? 서버 비용은 왜 저한테 오나요

서버리스라면서요? 서버 비용은 왜 저한테 오나요

serverless-but-bill-arrives

소개

서버리스라는 말을 처음 들으면 마음이 편해집니다. 서버를 관리하지 않아도 되고, 인스턴스 크기를 고르지 않아도 되고, 운영체제 패치도 직접 하지 않아도 된다고 합니다. 사용한 만큼만 비용을 낸다는 설명까지 들으면 거의 클라우드의 복지 정책처럼 느껴집니다. 그런데 며칠 뒤 청구서를 보면 묘한 생각이 듭니다. “서버가 없다면서요? 그런데 왜 비용은 제 계정으로 오나요?”

서버리스는 서버가 정말 사라졌다는 뜻이 아닙니다. 사용자가 서버를 직접 관리하지 않는다는 뜻에 가깝습니다. 어딘가에는 여전히 컴퓨팅 자원이 있고, 네트워크가 있고, 저장소가 있고, 로그가 있고, 데이터베이스가 있습니다. 다만 클라우드 제공자가 그 운영 부담을 많이 가져가고, 우리는 함수 실행 시간, 호출 횟수, 데이터 전송량, 로그 저장량, 연결된 서비스 사용량에 따라 비용을 냅니다. 서버는 보이지 않지만 계산서는 아주 선명하게 보입니다.

이 글에서는 서버리스 비용이 왜 생기는지, 초보자가 특히 놓치기 쉬운 비용 지점은 무엇인지, 그리고 서버리스 구조를 더 안전하게 쓰기 위한 점검표를 정리하겠습니다. 서버리스를 쓰지 말자는 글이 아닙니다. 오히려 서버리스는 잘 쓰면 훌륭한 선택입니다. 다만 이름만 믿고 들어가면 “서버리스”가 아니라 “예상리스”가 될 수 있습니다. 예상하지 못한 비용이 빌려 간 마음의 평화는 생각보다 큽니다.

서버리스는 무료가 아니라 관리 방식이 다른 것입니다

서버리스의 핵심 가치는 서버 운영 부담을 줄이는 데 있습니다. 직접 가상 머신을 만들고, 운영체제를 관리하고, 런타임을 설치하고, 확장 정책을 구성하고, 장애 복구를 설계하는 일을 상당 부분 줄일 수 있습니다. 작은 API, 이벤트 처리, 파일 변환, 알림 발송, 간단한 자동화 작업에는 특히 유용합니다.

하지만 관리 부담이 줄어든다고 비용 구조가 사라지는 것은 아닙니다. 오히려 비용 항목이 잘게 나뉘는 경우가 많습니다. 함수 실행 시간, 메모리 설정, 호출 횟수, API 게이트웨이 요청 수, 로그 수집량, 객체 저장소 요청, 데이터베이스 읽기와 쓰기, 외부로 나가는 트래픽이 모두 비용과 연결될 수 있습니다. 가상 머신 한 대 요금처럼 단순하게 보이지 않을 뿐입니다.

서버리스는 전기요금과 비슷합니다. 콘센트 뒤에 발전소가 보이지 않는다고 전기가 무료가 되지는 않습니다. 우리는 전기 사용량에 따라 비용을 냅니다. 서버리스도 마찬가지입니다. 서버가 화면에서 사라졌을 뿐, 사용량은 아주 성실하게 기록됩니다. 클라우드는 이런 기록을 매우 잘합니다. 가끔 너무 잘해서 서운할 정도입니다.

서버리스 비용은 어디서 생길까요

서버리스 비용을 이해하려면 함수 하나만 보면 부족합니다. 함수는 중심에 있지만, 실제 애플리케이션은 여러 관리형 서비스와 함께 움직입니다. 사용자는 API를 호출하고, API 게이트웨이가 요청을 받고, 함수가 실행되고, 데이터베이스를 읽고, 객체 저장소에 파일을 쓰고, 로그를 남기고, 응답을 돌려줍니다. 이 과정의 각 단계가 비용 후보입니다.

비용 항목	왜 비용이 생기나요?	초보자가 놓치는 지점
함수 실행	호출 횟수, 실행 시간, 메모리 크기에 따라 비용이 생길 수 있습니다.	짧은 함수라도 호출이 많으면 비용이 커질 수 있습니다.
API 게이트웨이	외부 요청을 받아 함수로 연결하는 요청 처리 비용이 생깁니다.	함수 비용만 보고 API 요청 비용을 놓칠 수 있습니다.
로그	실행 로그 수집, 저장, 조회에 비용이 붙을 수 있습니다.	디버그 로그를 오래 켜 두면 로그가 조용히 자랍니다.
저장소	파일 저장, 읽기, 쓰기, 데이터 전송 비용이 생깁니다.	임시 파일이나 업로드 테스트 파일을 지우지 않는 경우가 많습니다.
데이터베이스	읽기, 쓰기, 저장량, 연결 방식에 따라 비용이 생깁니다.	함수 호출마다 불필요한 쿼리가 반복될 수 있습니다.
네트워크	외부로 나가는 데이터 전송이나 리전 간 통신에 비용이 생길 수 있습니다.	이미지, 파일, API 응답 크기를 과소평가하기 쉽습니다.

서버리스 비용은 한 항목이 크게 터지기도 하지만, 작은 항목들이 모여 커지는 경우도 많습니다. 함수는 저렴해 보이는데 로그와 API 요청과 저장소가 함께 붙으면 전체 비용이 달라집니다. 그래서 서버리스 비용을 볼 때는 “함수 하나”가 아니라 “요청 하나가 지나가는 전체 경로”를 봐야 합니다.

함수 실행 시간은 짧을수록 좋습니다

서버리스 함수는 보통 실행 시간과 메모리 설정에 따라 비용이 달라집니다. 메모리를 크게 잡으면 함수가 더 빠르게 동작할 수 있지만, 단위 시간 비용이 커질 수 있습니다. 반대로 메모리를 너무 작게 잡으면 함수가 오래 실행되어 전체 비용과 응답 시간이 나빠질 수 있습니다. 결국 적절한 설정을 찾아야 합니다.

초보자가 자주 놓치는 부분은 함수 안에서 너무 많은 일을 하려는 습관입니다. 요청을 받고, 파일을 읽고, 외부 API를 호출하고, 데이터베이스에 쓰고, 이미지를 변환하고, 로그를 길게 남기고, 알림까지 보내면 함수 하나가 작은 회사처럼 일하게 됩니다. 함수가 많은 일을 할수록 실행 시간이 길어지고 실패 가능성도 커집니다.

서버리스에서는 작업을 작게 나누고, 시간이 오래 걸리는 일은 큐나 비동기 처리로 분리하는 것이 좋습니다. 사용자 응답이 필요한 작업과 뒤에서 처리해도 되는 작업을 구분해야 합니다. 모든 일을 한 요청 안에서 끝내려 하면, 서버리스 함수가 갑자기 야근을 시작합니다. 함수에게도 퇴근 시간이 필요합니다.

호출 횟수는 생각보다 빨리 늘어납니다

서버리스 비용에서 호출 횟수는 중요한 요소입니다. 작은 함수라도 많이 호출되면 비용이 커질 수 있습니다. 특히 프론트엔드에서 자동 새로고침을 자주 하거나, 사용자가 입력할 때마다 API를 호출하거나, 재시도 로직이 과하게 설정되어 있으면 호출 수가 빠르게 늘어납니다.

예를 들어 검색창에서 사용자가 글자를 입력할 때마다 함수를 호출한다고 생각해 보겠습니다. 한 사용자가 한 번 검색하는 동안 여러 번 호출될 수 있습니다. 사용자가 많아지면 호출 수는 예상보다 크게 늘어납니다. 여기에 실패 재시도까지 붙으면 호출은 더 늘어납니다. “잠깐 테스트한 기능”이 어느 날 청구서에서 자기소개를 할 수 있습니다.

호출 횟수를 줄이려면 입력 지연 처리, 캐시, 요청 묶기, 중복 요청 방지, 재시도 횟수 제한이 필요합니다. 서버리스는 호출이 쉬운 만큼 호출을 줄이는 설계도 중요합니다. 버튼 하나에 연결된 함수가 있다면, 그 버튼이 몇 번 눌릴 수 있는지 생각해야 합니다. 사용자는 우리가 예상한 것보다 버튼을 더 많이 누릅니다. 특히 화면이 느리면 더 열심히 누릅니다.

로그는 문제 해결 도구이면서 비용 항목입니다

서버리스 환경에서는 로그가 매우 중요합니다. 서버에 직접 접속해서 상태를 보는 방식이 아니기 때문에, 함수가 무엇을 했는지 로그와 지표로 확인해야 합니다. 그런데 로그도 비용이 될 수 있습니다. 수집량, 저장 기간, 조회량이 늘어나면 비용이 생깁니다.

개발 중에는 자세한 로그가 필요합니다. 하지만 운영 환경에서 모든 요청과 응답을 그대로 남기면 위험하고 비쌀 수 있습니다. 특히 디버그 로그를 켜 둔 채 배포하면 로그가 빠르게 쌓입니다. 처음에는 “문제 생기면 봐야 하니까요”라는 마음이었지만, 나중에는 로그가 문제 자체가 될 수 있습니다. 로그가 너무 많으면 비용도 늘고, 중요한 오류도 묻힙니다.

• 운영 환경에서는 디버그 로그를 제한합니다.
• 비밀번호, 토큰, 개인정보는 로그에 남기지 않습니다.
• 로그 보관 기간을 설정합니다.
• 오류와 주요 이벤트 중심으로 로그를 남깁니다.
• 요청 식별자를 남겨 추적 가능하게 만듭니다.

로그는 적게 남기자는 뜻이 아닙니다. 필요한 로그를 남기자는 뜻입니다. 서버리스에서는 로그가 눈이 되어 줍니다. 다만 눈이 너무 많으면 어디를 봐야 할지 모르게 됩니다. 운영자는 관측 가능성을 원하지, 로그 폭포수 아래에서 명상을 하고 싶은 것이 아닙니다.

API 게이트웨이와 이벤트 트리거도 비용을 만듭니다

서버리스 함수는 보통 혼자 호출되지 않습니다. API 게이트웨이, 이벤트 버스, 메시지 큐, 스케줄러, 객체 저장소 이벤트 같은 트리거가 함수를 실행합니다. 이 트리거들도 비용과 운영 조건을 가질 수 있습니다. 함수 실행 비용만 보고 전체 비용을 판단하면 실제 청구서와 차이가 납니다.

API 게이트웨이는 외부 요청을 받는 데 유용하지만 요청 수가 많으면 비용이 커질 수 있습니다. 인증, 라우팅, 제한, 로깅 같은 기능이 붙으면 더 많은 설정을 이해해야 합니다. 이벤트 기반 구조에서는 한 이벤트가 여러 함수를 호출할 수 있습니다. 설계가 잘못되면 이벤트 하나가 함수 여러 개를 깨우고, 그 함수들이 다시 이벤트를 만들 수 있습니다. 이쯤 되면 자동화가 아니라 호출 축제가 됩니다.

이벤트 흐름을 설계할 때는 한 요청이 몇 개의 함수와 서비스를 지나가는지 그려 보는 것이 좋습니다. 흐름을 그림으로 그리면 비용과 장애 지점이 보입니다. 머릿속으로만 생각하면 대개 단순해 보입니다. 클라우드 아키텍처는 머릿속에서는 늘 착합니다. 실제로 배포하면 성격이 드러납니다.

데이터베이스 연결은 특히 조심해야 합니다

서버리스 함수와 데이터베이스를 연결할 때는 주의가 필요합니다. 함수는 필요할 때 여러 개가 동시에 실행될 수 있습니다. 각 함수가 데이터베이스 연결을 새로 만들면 연결 수가 급격히 늘어날 수 있습니다. 데이터베이스가 감당하지 못하면 함수는 늘어나는데 전체 시스템은 느려집니다.

서버리스에 맞는 데이터베이스 연결 방식을 검토해야 합니다. 연결 풀링, 프록시, 관리형 서버리스 데이터베이스, 요청당 쿼리 수 제한, 캐시 사용 등을 고려할 수 있습니다. 특히 짧은 함수 안에서 같은 데이터를 반복 조회하는 구조는 비용과 성능을 동시에 악화시킬 수 있습니다.

서버리스는 애플리케이션 서버를 줄여 주지만 데이터베이스 설계를 대신 해 주지는 않습니다. 함수가 귀엽게 작아 보여도, 동시에 많이 실행되면 데이터베이스 입장에서는 꽤 시끄러운 손님들입니다. 손님이 많을 때 계산대가 하나면 줄이 생깁니다. 이 비유는 클라우드에서도 놀라울 정도로 자주 맞습니다.

저장소와 데이터 전송은 조용히 비용을 키웁니다

파일 업로드, 이미지 변환, 백업, 보고서 생성 같은 서버리스 작업에서는 객체 저장소를 자주 사용합니다. 저장소 자체는 저렴해 보일 수 있지만, 저장량, 요청 수, 데이터 전송, 보관 정책에 따라 비용이 달라집니다. 특히 테스트 파일을 지우지 않거나, 변환 결과물을 계속 쌓아 두거나, 큰 파일을 자주 외부로 전송하면 비용이 생깁니다.

이미지나 문서를 다루는 서버리스 앱이라면 입력 파일, 중간 파일, 결과 파일의 생명주기를 정해야 합니다. 임시 파일은 언제 지울 것인지, 원본과 결과물을 얼마나 보관할 것인지, 사용자가 다운로드할 때 데이터 전송량은 어느 정도인지 봐야 합니다. 저장소는 조용합니다. 조용해서 더 위험할 때가 있습니다. 아무 말 없이 계속 쌓입니다.

데이터 전송도 중요합니다. 같은 리전 안에서 처리되는지, 외부 인터넷으로 나가는지, 다른 리전이나 다른 서비스로 이동하는지에 따라 비용이 달라질 수 있습니다. 서버리스 비용을 볼 때는 “계산”뿐 아니라 “이 데이터가 어디로 이동하는가”를 함께 봐야 합니다.

서버리스 비용을 줄이는 기본 습관

서버리스 비용 관리는 어렵게 시작할 필요가 없습니다. 먼저 눈에 보이게 만드는 것이 중요합니다. 함수별 호출 수, 실행 시간, 오류율, 로그 수집량, API 요청 수, 데이터베이스 쿼리 수, 저장소 사용량을 확인할 수 있어야 합니다. 보이지 않는 비용은 줄이기 어렵습니다.

관리 영역	확인할 것	개선 방법
함수 실행	실행 시간, 메모리, 호출 수	작업 분리, 메모리 튜닝, 불필요한 호출 제거
재시도	실패 시 몇 번 다시 실행되는지	재시도 횟수와 대기 시간을 제한
로그	수집량, 보관 기간, 디버그 로그 여부	로그 수준 정리, 보관 정책 설정
API	요청 수, 중복 요청, 인증 실패 반복	캐시, 입력 지연 처리, 요청 제한
데이터베이스	쿼리 수, 연결 수, 느린 쿼리	캐시, 연결 관리, 쿼리 최적화
저장소	임시 파일, 오래된 결과물, 전송량	수명 주기 정책, 파일 크기 최적화

또한 예산 알림을 반드시 설정해야 합니다. 서버리스는 작은 단위로 비용이 생기기 때문에 초반에는 티가 잘 나지 않을 수 있습니다. 하지만 호출 수가 늘거나 로그가 쌓이거나 재시도가 반복되면 비용이 빠르게 변할 수 있습니다. 예산 알림은 클라우드 초보자의 안전벨트입니다. 안전벨트가 운전을 대신해 주지는 않지만, 없으면 마음이 불안합니다.

서버리스가 잘 맞는 경우와 아닌 경우

서버리스는 모든 상황의 정답이 아닙니다. 짧고 이벤트 중심인 작업, 트래픽이 들쭉날쭉한 서비스, 작은 API, 자동화 작업, 파일 처리 파이프라인에는 잘 맞을 수 있습니다. 반대로 장시간 실행 작업, 지속적인 연결이 필요한 서비스, 예측 가능한 고정 부하, 매우 낮은 지연 시간이 중요한 시스템에는 다른 구조가 더 적합할 수 있습니다.

서버리스가 잘 맞는지 판단할 때는 트래픽 패턴, 실행 시간, 상태 관리, 데이터베이스 연결, 비용 예측 가능성, 디버깅 난이도를 함께 봐야 합니다. “서버를 관리하기 싫다”는 이유만으로 서버리스를 선택하면 나중에 다른 형태의 운영 부담을 만날 수 있습니다. 서버 관리는 줄었는데 이벤트 흐름과 비용 분석이 늘어나는 식입니다.

• 요청이 가끔 발생하고 짧게 끝나는 작업에는 잘 맞습니다.
• 이벤트가 들어올 때만 처리하면 되는 자동화에 유용합니다.
• 항상 켜져 있어야 하는 장시간 작업에는 신중해야 합니다.
• 데이터베이스 연결이 많은 구조는 별도 설계가 필요합니다.
• 비용이 매우 일정해야 하는 서비스는 고정 인프라와 비교해야 합니다.

서버리스는 “좋다” 또는 “나쁘다”로 나눌 수 없습니다. 문제에 맞으면 훌륭하고, 맞지 않으면 복잡합니다. 클라우드 서비스는 대체로 그렇습니다. 도구는 죄가 없습니다. 다만 우리가 너무 낙관적으로 클릭할 때가 있을 뿐입니다.

배포 전에 확인할 서버리스 비용 점검표

서버리스 기능을 배포하기 전에는 아래 질문을 확인해 보세요. 이 점검표만으로 모든 비용을 막을 수는 없지만, 초보자가 자주 놓치는 지점을 상당히 줄일 수 있습니다.

1. 함수별 예상 호출 수를 계산했나요?
2. 함수 실행 시간이 어느 정도인지 측정했나요?
3. 메모리 설정을 실제 실행 시간 기준으로 조정했나요?
4. 실패 시 재시도 횟수와 대기 시간을 제한했나요?
5. API 요청이 중복으로 발생하지 않도록 처리했나요?
6. 로그 수준과 보관 기간을 정했나요?
7. 민감한 정보가 로그에 남지 않도록 확인했나요?
8. 데이터베이스 연결 수와 쿼리 수를 확인했나요?
9. 임시 파일과 결과 파일의 삭제 정책을 정했나요?
10. 예산 알림과 사용량 알림을 설정했나요?

이 질문에 답하기 어렵다면 아직 배포 준비가 부족할 수 있습니다. 물론 모든 것을 완벽히 예측할 수는 없습니다. 그래서 작은 트래픽으로 시작하고, 사용량을 보며 조정해야 합니다. 서버리스는 빨리 시작할 수 있는 장점이 있지만, 빨리 방치해도 된다는 뜻은 아닙니다.

자주 묻는 질문

서버리스는 정말 서버가 없는 건가요?

아닙니다. 서버는 존재합니다. 다만 사용자가 직접 서버를 만들고 관리하지 않을 뿐입니다. 클라우드 제공자가 실행 환경을 관리하고, 사용자는 함수 실행이나 요청 처리 같은 사용량 기준으로 비용을 냅니다.

서버리스가 항상 더 저렴한가요?

항상 그렇지는 않습니다. 트래픽이 적거나 들쭉날쭉하면 유리할 수 있지만, 계속 높은 부하가 유지되는 서비스라면 고정 인프라가 더 예측 가능하거나 저렴할 수 있습니다. 실행 시간, 호출 수, 연결 서비스 비용을 함께 비교해야 합니다.

서버리스 비용이 갑자기 늘어나는 가장 흔한 이유는 무엇인가요?

호출 수 증가, 무한 재시도, 디버그 로그 과다, 큰 파일 처리, 데이터베이스 반복 조회, API 중복 호출이 흔한 원인입니다. 특히 실패한 작업이 계속 재시도되는 구조는 빠르게 비용을 키울 수 있습니다.

초보자는 서버리스를 쓰지 않는 편이 좋나요?

그렇지 않습니다. 오히려 작은 자동화나 간단한 API에는 좋은 선택이 될 수 있습니다. 다만 예산 알림, 로그 보관 기간, 호출 수 제한, 데이터베이스 연결 방식은 처음부터 확인하는 것이 좋습니다.

마무리

서버리스는 서버가 사라지는 기술이 아니라, 서버 관리 방식이 바뀌는 기술입니다. 관리할 서버 화면은 줄어들지만, 비용을 만드는 요소는 여전히 존재합니다. 함수 실행, API 게이트웨이, 로그, 저장소, 데이터베이스, 데이터 전송, 재시도 정책이 모두 청구서와 연결될 수 있습니다.

서버리스의 장점은 분명합니다. 빠르게 만들 수 있고, 작은 기능을 효율적으로 운영할 수 있으며, 트래픽 변화에 유연하게 대응할 수 있습니다. 하지만 그 장점을 제대로 누리려면 사용량을 봐야 합니다. 보이지 않는 서버 대신 보이는 지표와 예산 알림을 믿어야 합니다.

다음에 “서버리스라서 비용 걱정이 적겠지”라는 생각이 든다면 잠깐 멈춰 보세요. 함수는 몇 번 호출되나요? 로그는 얼마나 쌓이나요? 데이터는 어디로 이동하나요? 실패하면 몇 번 재시도하나요? 이 질문에 답할 수 있다면 서버리스는 꽤 좋은 동료가 됩니다. 답하지 못하면, 어느 날 청구서가 아주 친절하게 대신 설명해 줄 수 있습니다.