월 1만 원으로 개인 서비스 운영하기 — 인프라 비용 다이어트

개인 서비스를 만들 때 저는 기능보다 예산 상한을 먼저 정합니다. 월 1만 원. 이 숫자에 특별한 근거가 있는 것은 아니고, 커피 두어 잔 값이라 서비스가 잘 안 되더라도 감정 없이 계속 둘 수 있는 금액이기 때문입니다. 유지비가 이 선을 넘기 시작하면 판단에 감정이 섞입니다.

상한을 먼저 정하면 설계가 달라집니다. 상시 켜둘 서버가 정말 필요한지, 이미지를 서버에서 변환해야 하는지, 로그를 얼마나 오래 둘지가 전부 비용 문제로 바뀝니다. 기능을 다 만든 뒤에 요금을 줄이려 하면 대개 구조를 뜯어야 해서 잘 줄지 않습니다.

이 글에서는 구체적인 가격을 적지 않습니다. 요금제는 자주 바뀌고 지역과 계정 상태에 따라서도 달라지므로, 지금 적어두면 얼마 못 가 틀린 글이 됩니다. 대신 비용이 어떤 단위로 매겨지는지와, 어디서 갑자기 튀는지를 정리합니다. 이 구조만 알면 어떤 서비스를 고르든 판단이 됩니다.

요금표가 아니라 과금 단위를 봅니다

개인 개발자가 쓰는 인프라는 대부분 무료 티어를 제공합니다. 중요한 건 무료냐 아니냐가 아니라 무엇을 세어서 유료로 넘기느냐입니다. 제 경험상 과금 단위는 대체로 다음 네 종류로 나뉩니다.

• 시간 단위: 인스턴스가 켜져 있던 시간, 함수가 실행된 시간, 빌드가 돌아간 시간. 사용자가 없어도 켜져 있으면 계속 쌓인다는 점이 핵심입니다.
• 용량 단위: 저장된 데이터의 크기, 데이터베이스 행 수, 파일 보관량. 지우지 않으면 한 방향으로만 늘어납니다.
• 전송량 단위: 밖으로 나간 데이터의 양. 들어오는 트래픽은 무료여도 나가는 트래픽은 유료인 경우가 흔합니다.
• 건수 단위: API 호출 수, 발송한 메일 수, 처리한 이미지 수, 수집한 로그 줄 수. 사용자가 늘면 가장 먼저 반응하는 항목입니다.

어떤 서비스를 검토할 때는 요금 페이지의 숫자보다 이 네 가지 중 무엇으로 세는지를 먼저 확인합니다. 그리고 내 서비스가 그 단위를 얼마나 빠르게 소모하는지를 가늠합니다. 예를 들어 원고를 다루는 서비스는 용량보다 전송량이 빨리 늘고, 이미지를 다루는 서비스는 건수와 용량이 동시에 늘어납니다.

항목별로 줄이는 방법

아래는 제가 항목마다 잡는 기본 전략입니다. 무료 티어를 제공하는 곳이 많지만, 유료로 넘어가는 기준선은 항목마다 다릅니다.

항목기본 전략유료로 넘어가는 신호

호스팅	상시 구동 인스턴스 대신 요청이 있을 때만 뜨는 방식으로 시작	첫 응답 지연이 사용자 이탈로 이어질 때
데이터베이스	관리형 무료 등급이나 파일 기반 DB로 시작하고 스키마를 작게 유지	동시 접속 수나 저장 용량 한도에 반복해서 닿을 때
스토리지	정적 파일은 CDN이 붙은 곳에 두고 원본과 가공본을 분리	월 전송량이 한도를 넘기 시작할 때
도메인	고정비로 인정하고 자동 갱신만 켜둠. 서브도메인으로 프로젝트를 나눠 재사용	프로젝트마다 새 도메인을 사고 싶어질 때
메일 발송	가입 인증과 오류 알림만 보내고 마케팅 메일은 처음부터 제외	발송 건수가 무료 한도에 가까워질 때
모니터링	오류 수집만 붙이고 지표는 관리자 화면에서 직접 계산	보관 기간을 늘리거나 팀원을 추가해야 할 때

이 표에서 가장 크게 절약되는 칸은 첫 번째입니다. 상시 구동을 피하는 것만으로 대부분의 개인 서비스는 무료 범위 안에 들어옵니다. 대신 첫 요청이 느려지는 문제가 생기는데, 사용자가 적을 때는 이 정도 지연이 실제 문제로 이어지는 경우가 드뭅니다. 메리톡톡도 초기에는 이 방식으로 버텼습니다.

도메인만은 줄이려 하지 않는 편이 낫습니다. 금액이 크지 않고, 무료 서브도메인을 쓰다가 나중에 옮기면 검색 유입과 링크가 전부 끊깁니다. 대신 프로젝트마다 새로 사지 말고 하나의 도메인 아래 서브도메인으로 나누면 개수가 늘지 않습니다.

비용이 갑자기 튀는 네 가지

월 요금이 조용히 유지되다가 어느 달 갑자기 뛰는 경우가 있습니다. 제가 겪었거나 주변에서 본 원인은 대체로 이 넷 중 하나였습니다.

• 이그레스 트래픽: 밖으로 나가는 데이터 양입니다. 이미지 몇 장이 무거운 상태로 올라가 있고 그 페이지가 어딘가에 소개되면, 방문자 수가 조금만 늘어도 전송량은 크게 뜁니다. 원본 이미지를 그대로 서빙하지 않는 것이 가장 확실한 대비입니다.
• 이미지 변환: 요청할 때마다 크기를 바꿔 내려주는 기능은 편하지만 건수로 과금되는 경우가 많습니다. 같은 이미지가 목록에서 반복 호출되면 숫자가 빠르게 오릅니다. 변환 결과를 캐시하거나, 업로드 시점에 몇 가지 크기를 미리 만들어두는 편이 예측 가능합니다.
• 로그 보관: 로그는 지우지 않으면 계속 쌓입니다. 게다가 사용자가 늘어서가 아니라 버그 하나 때문에 하루 만에 폭증하는 일도 있습니다. 보관 기간을 짧게 잡고, 반복되는 경고는 원인을 고쳐 로그 자체를 줄입니다.
• 상시 구동 인스턴스: 테스트하려고 하나 띄워두고 잊은 인스턴스, 잠깐 쓰려고 만든 데이터베이스, 실험용 컨테이너. 이것들은 아무도 안 쓰는데 시간 단위로 계속 계산됩니다. 개인 계정에서 가장 흔한 낭비입니다.

네 가지의 공통점은 사용자가 늘어서 생기는 비용이 아니라는 점입니다. 사용자가 늘어서 요금이 오르는 건 반가운 신호지만, 위의 넷은 그냥 새는 돈입니다. 순서를 따지자면 이 넷을 먼저 막고 나서 요금제를 비교하는 게 맞습니다.

상한을 지키는 습관

구조를 잘 잡아도 확인하지 않으면 새기 마련입니다. 저는 이 세 가지를 습관으로 두고 있습니다.

1. 예산 알림을 먼저 겁니다: 서비스를 만들자마자 계정에 금액 알림을 설정합니다. 상한의 절반과 상한, 두 단계면 충분합니다. 이걸 나중에 하겠다고 미루면 대개 첫 청구서를 보고 나서 하게 됩니다.
2. 월 1회 자원 목록을 훑습니다: 콘솔에서 실행 중인 항목을 쭉 보고, 무엇에 쓰는지 즉시 설명되지 않는 것은 끕니다. 정말 필요했다면 다시 만들면 됩니다. 이 점검에 드는 시간은 십 분 남짓입니다.
3. 비용을 기능 결정에 넣습니다: 새 기능을 넣을 때 "이 기능은 어떤 단위를 소모하는가"를 한 줄 적어봅니다. 시간·용량·전송량·건수 중 무엇이 늘어나는지가 보이면, 만들기 전에 구조를 바꿀 기회가 생깁니다.

마치며

요금표를 외우는 대신 과금 단위를 시간, 용량, 전송량, 건수로 나눠 봅니다. 항목별로는 상시 구동을 피하는 것이 가장 크고, 도메인만은 고정비로 인정합니다. 비용이 튀는 원인은 대개 이그레스 트래픽, 이미지 변환, 로그 보관, 잊힌 인스턴스 넷 중 하나입니다.

지금 할 수 있는 한 가지는 이겁니다. 쓰고 있는 클라우드 계정에 들어가 예산 알림을 하나 설정하는 것입니다. 금액은 지금 내는 돈의 두 배로 잡으면 됩니다. 그 알림이 울리는 날은 대개 뭔가 잘못된 날이고, 미리 알수록 고치기 쉽습니다.