웹게임 서버 비용, 서버와 DB 기본요금을 월 54달러로 맞춘 구성
웹게임을 오픈베타로 열기 직전에 서버 견적을 다시 봤다. 처음 잡아 둔 구성이 한 달에 206달러쯤이었다. 접속자는 많아야 수십 명일 텐데 이 돈을 매달 내야 하나 싶었다.
먼저 답만 적으면, 지금 이 게임은 AWS Lightsail 서울에서 돌아간다. 게임 서버 24달러, 관리형 PostgreSQL DB 30달러라 둘의 월 기본요금은 54달러. 부가세랑 스냅숏 비용은 별도고, 1달러 1,400원으로 치면 기본요금이 약 7.6만 원이다. 서버와 DB 크기를 낮추고 DB 이중화를 뺐다. 저장 암호화랑 자동 백업 같은 보안, 백업 항목은 그대로 뒀다.
처음 잡은 웹게임 서버 비용은 월 206달러
처음 견적은 단계별로 짜 놨었다. 운영자만 들어가는 기술 시험 단계는 54달러쯤, 그다음 단계는 106달러, 오픈베타는 206달러. 오픈베타 구성은 4 vCPU 8GB 계산 최적화 서버 84달러에 DB 4GB 이중화 120달러였다. 그 뒤에 비공개 기술검증이랑 배포 예행은 거치고, 클로즈드는 생략한 채 오픈베타로 바로 공개하기로 했다. 그래서 처음 공개할 단계의 견적이 206달러쯤이었다.
근데 숫자를 다시 보니까 이상했다. 텍스트 게임이라 그림 많은 게임처럼 무거운 것도 아니고, 처음엔 사람도 적다. 비싼 건 대부분 DB 이중화랑 큰 서버였다. 큰 서버는 사람이 늘 때 올리면 된다. DB 이중화는 장애 때 중단을 줄이는 장치인데, 초기 베타에서는 그 비용 대신 수동 복구와 중단을 감수하기로 했다.
그래서 원칙을 한 줄로 다시 정했다. 보안과 백업 항목은 줄이지 않고 크기만 제일 작게 시작해서, 사람이 늘면 그때 올린다.
웹게임 서버 비용을 줄인 24달러 서버
게임 서버는 Python 웹 앱 하나. 앞에 HTTPS 를 붙여 주는 웹 서버 하나, 앱 프로세스, 예약 작업 러너가 돈다. 로컬에서 부하 시험을 해 보니 앱 프로세스 하나가 초당 80~100 요청쯤 받았다. 원래는 프로세스 4개를 띄우려 했는데 2개로 줄였다.
Lightsail 요금표를 보면 4GB 메모리, 2 vCPU, 80GB SSD 서버가 한 달 24달러다. 그 아래 2GB 서버는 12달러다. 2GB 에서 앱 2개랑 러너를 돌려도 되는지는 확인을 못 해서 4GB 를 골랐다. 12달러로 내려도 되는지는 실제로 돌려 보고 정하기로 미뤄 뒀고, 아직 확인 못 했다.
하나 알아 둘 건 Lightsail 일반 서버가 버스트형이라는 거. CPU 를 기준선보다 적게 쓰면 버스트 잔량이 쌓이고, 그 위로 쓰면 쌓인 잔량을 깎아 먹는 식이다. 24달러 서버의 기준선은 vCPU 당 20%다. 그래서 감시 항목에 CPU 사용률 말고 버스트 잔량도 넣었다.
15달러 DB 를 안 쓴 이유
DB 는 Lightsail 관리형 PostgreSQL 16 표준 2GB, 30달러짜리로 골랐다. 제일 싼 건 1GB 15달러였는데 요금표에 데이터 암호화가 No 로 나와 있었다. 2GB 는 Yes. 이용자 계정이 들어가는 DB 라 15달러 아끼자고 암호화를 포기할 순 없었다. 2026년 10월 15일에 Lightsail 요금표를 다시 열어 봤는데 지금도 같다.
관리형 DB 는 자동 백업이랑 7일 안 시점 복원이 기본으로 붙고, 이건 따로 돈을 안 받는다. 자동 백업이 붙어 있어도 배포 전 수동 스냅숏이랑 별도 백업 스크립트는 따로 뒀다.
이중화를 뺀 대가
206달러에서 제일 크게 빠진 건 DB 이중화였다. 이걸 빼면 DB 가 죽었을 때 자동으로 넘어가 줄 예비가 없다. 수동으로 복구해야 하고, 그동안 게임은 멈춘다. 시점 복원 뒤에 생긴 변경은 잃을 수도 있고.
이 판단은 한 번 더 확인받고 싶어서 구성안을 정리해 ChatGPT 에 교차 확인을 맡겼다. 틀린 곳, 빠진 안전 항목, 더 싸면서 안전한 대안이 있는지. 돌아온 답은 54달러 구성을 초기 베타 후보로 두되, 프로세스 수랑 사양은 실제 서버에서 부하 시험을 해 보고 정하라는 거였다. 이중화를 뺄 거면 장애 때 수동 복구와 중단을 감수한다고 분명히 적어 두라는 말도 있었다.
같이 짚어 준 것도 몇 개 있었다. 표준 DB 는 수동 스냅숏을 뜨는 동안 잠깐 못 쓸 수 있고, DB 를 지우면 자동 백업도 같이 지워지고, DB 를 키울 땐 쓰기를 멈추고 접속 주소를 바꿔야 한다는 것. 셋 다 배포 문서에 절차로 넣었다.
DB 연결 수는 한도의 70% 안으로
마지막으로 본 건 DB 연결 수. 작은 DB 일수록 동시에 붙을 수 있는 연결 수가 적다. 앱 프로세스 2개랑 러너 2개가 각자 연결을 잡으니까, 처음엔 하나당 10개로 쳐서 최대 40개로 잡았다.
나중에 운영 DB 를 읽기 전용으로 확인해 보니 max_connections 가 191이었다. 그 뒤 프로세스당 활성 연결 상한을 20으로 바꿨고, 관리용 여유 10을 더해 계산하면 (2 + 2) × 20 + 10 = 90. 191의 70%는 133.7이라 정수로는 133개 이하, 90은 그 안이다. 70%로 선을 그은 건 배포나 점검 때 잠깐 연결이 더 붙어도 넘치지 않게 하려는 거다.
웹게임 서버 비용 54달러에 남은 숙제
돈만 보면 견적의 기본 경우(54.4달러)에 부가세 10%를 붙여도 한 달 8.4만 원쯤. 스냅숏을 몇 개 쌓아 두면 몇 달러가 더 붙는다. DB 수동 스냅숏이 실제 사용량으로 과금되는지 할당 용량 80GB 기준인지는 견적 때 확인 못 했고, 그래서 견적 때는 보관 개수를 2개 이하로 잡았다. 도메인 DNS 는 Cloudflare 무료로 돌린다.
키우는 순서도 미리 정해 놨었다. 서버는 스냅숏을 떠서 큰 서버로 새로 만들고 고정 IP 를 옮긴다. DB 는 쓰기를 멈추고 스냅숏에서 큰 요금제로 새로 만든 다음 접속 주소를 바꾸는 순서. 올릴 신호로는 CPU 버스트 잔량, 메모리, 응답 지연, DB 연결 수를 본다.
나는 웹게임 서버 비용을 다시 잡을 때 서버 크기랑 DB 이중화 비용부터 다시 봤다. 이중화를 빼면 장애 때 멈추는 걸 감수해야 하니까, 그걸 받아들일 수 있는 단계인지 먼저 따져야 한다. 대신 저장 암호화랑 백업은 크기를 줄여도 남겨 뒀다. 처음 서버에 올리던 날 얘기는 첫 배포의 밤에 적어 뒀다.
다음엔 Claude Code 랑 Codex 를 같이 쓸 때 역할을 어떻게 나눴는지 적으려고 한다.