50장. 비용을 아끼며 운영하는 법

첫 서비스에 필요한 것은 화려한 인프라보다 버티는 힘

처음 서비스를 만들면 이상하게도 코드보다 서버가 더 커 보여야 할 것 같은 기분이 듭니다. 뭔가 전문가처럼 보이려면 복잡한 클라우드 구조가 있어야 할 것 같고, 모니터링 도구도 여러 개 붙여야 할 것 같고, 데이터베이스도 처음부터 넉넉해야 할 것 같습니다.

그런데 첫 서비스에서 가장 무서운 건 트래픽 폭주보다 운영비가 먼저 마음을 꺾는 일입니다. 사용자는 아직 열 명인데, 매달 돈은 꾸준히 빠져나가면 서비스는 금방 부담이 됩니다. 이때 필요한 감각은 "크게 시작하기"가 아니라 "작게 시작해서 오래 버티기"입니다.

작은 서비스는 작은 구조로도 충분히 굴러갑니다. 오히려 처음부터 모든 것을 직접 관리하려고 하면 배보다 배꼽이 더 커집니다. 프론트 배포, 데이터베이스, 인증, 파일 저장, 버전 관리처럼 꼭 필요한 부분만 안정적으로 구성하고, 돈이 드는 구간은 늦게 여는 편이 훨씬 건강합니다.¹

운영비는 생각보다 여러 곳에서 새어나간다

초보자는 보통 운영비를 "서버비" 하나로 생각합니다. 하지만 실제로는 비용이 여러 통로로 나뉘어 나갑니다.

• 화면을 배포하는 호스팅 비용

• 데이터베이스와 인증, 파일 저장 비용

• 도메인, 메일, 외부 API 같은 부가 서비스 비용

• 로그, 분석, 모니터링 도구 비용

• Claude Code나 Codex 같은 AI 도구 사용 비용

즉, 비용을 아끼는 첫걸음은 "무엇이 돈을 먹는지"를 눈에 보이게 만드는 일입니다. 그래야 줄일 수 있습니다. 보이지 않는 새는 물은 막기 어렵지만, 새는 위치를 알면 수건 한 장으로도 버틸 수 있습니다.

작은 풀스택 서비스에 잘 맞는 저비용 기본 조합

입문자가 첫 서비스를 만들 때는 복잡한 조합보다 역할이 분명한 도구 조합이 좋습니다. 이 책의 흐름에 맞는 현실적인 저비용 구조는 다음과 같습니다.

이 조합이 좋은 이유는 단순합니다. 서비스 하나를 운영하는 데 필요한 핵심 기능이 흩어지지 않기 때문입니다. Supabase는 무료 플랜에서 데이터베이스와 인증, 파일 저장을 함께 제공하고, Vercel은 프론트 배포와 미리보기 배포에 강하며, GitHub는 코드 이력과 자동화의 중심 역할을 맡습니다.¹

작은 서비스라면 이 정도만으로도 꽤 오래 버틸 수 있습니다. 예를 들어 Supabase 무료 플랜은 초반 MVP에 필요한 수준의 데이터베이스 용량, 파일 저장, 인증 사용자 수를 제공하고, 한도를 넘겼다고 해서 몰래 과금하기보다 제한이 걸리는 방식이라 예산을 통제하기 쉽습니다.² 초보자에게 이 점은 매우 중요합니다. "나도 모르게 요금 폭탄"이 아니라 "한도에 닿았으니 정리하거나 업그레이드하라"는 신호가 오기 때문입니다.

공짜를 오래 공짜로 쓰는 운영 습관

무료 플랜은 마법이 아닙니다. 대신 좋은 습관과 만나면 꽤 오래갑니다. 초보자가 특히 효과를 크게 보는 습관은 몇 가지가 있습니다.

첫째, 이미지와 파일을 가볍게 다뤄야 합니다. 테스트용 이미지를 원본 그대로 올리고, 큰 첨부파일을 계속 저장하면 스토리지와 대역폭이 금방 닳습니다. 썸네일 크기를 줄이고, 꼭 필요한 파일만 남기면 체감이 큽니다.

둘째, 실시간 기능은 정말 필요한 곳에만 붙여야 합니다. 모든 화면이 실시간일 필요는 없습니다. 게시글 목록, 프로필 화면, 검색 결과처럼 조금 늦게 바뀌어도 괜찮은 정보는 일반 조회로 충분한 경우가 많습니다. 불필요한 실시간 구독을 줄이는 것만으로도 비용과 복잡도를 함께 낮출 수 있습니다.³

셋째, 캐시를 활용해야 합니다. 자주 바뀌지 않는 화면은 매번 서버에서 다시 계산하지 말고, 정적 페이지나 캐시된 응답을 우선 떠올리면 됩니다. 한 번 만든 결과를 여러 번 재사용하는 습관은 성능에도 좋고 비용에도 좋습니다.³

넷째, 로그를 욕심내지 않아야 합니다. 초반에는 모든 것을 저장하고 싶지만, 실제로는 "어떤 요청이 실패했는지", "어디서 에러가 났는지", "누가 어떤 버튼을 눌렀는지" 정도만 알아도 충분한 경우가 많습니다. 로그가 많다고 운영이 잘되는 것은 아닙니다. 중요한 로그가 보이는 것이 더 중요합니다.

무료 플랜의 한계는 실패가 아니라 신호다

무료 플랜을 쓰다 보면 언젠가 한계가 옵니다. 여기서 겁먹지 않아야 합니다. 한계는 서비스가 망했다는 뜻이 아니라, 이제 어디가 병목인지 보이기 시작했다는 뜻입니다.

예를 들어 데이터베이스 용량이 거의 찼다면, 당장 유료 플랜부터 결제하기 전에 먼저 이런 질문을 해볼 수 있습니다.

• 테스트 데이터가 너무 많이 남아 있지 않은가

• 삭제해도 되는 오래된 파일이 쌓여 있지 않은가

• 이미지나 첨부파일을 지나치게 크게 저장하고 있지 않은가

• 실제 사용자 데이터보다 개발 중 찌꺼기가 더 많은 것은 아닌가

Supabase 무료 데이터베이스가 한도를 넘으면 읽기 전용 상태로 전환되는 식의 제한이 걸릴 수 있습니다. 이때는 당황해서 결제부터 누르기보다, 무엇이 공간을 차지하고 있는지 먼저 살펴보는 편이 좋습니다.²

대역폭이 부족해질 때도 비슷합니다. 사용자가 갑자기 늘어서일 수도 있지만, 더 흔한 이유는 큰 이미지, 너무 잦은 요청, 불필요한 새로고침입니다. 문제를 정확히 보면 업그레이드가 필요한지, 아니면 정리가 필요한지 판단할 수 있습니다.

돈은 한 번에 쓰지 말고, 병목 하나에만 써라

초보 운영에서 가장 많이 하는 실수는 전체 업그레이드입니다. 데이터베이스가 살짝 답답해지면 모든 서비스를 유료로 바꾸고, 배포가 느려지면 또 다른 도구를 붙이고, 로그가 아쉬우면 분석 도구를 두세 개 더 붙입니다. 그러면 문제는 하나였는데 비용은 세 배가 됩니다.

좋은 업그레이드는 늘 병목 하나를 겨냥합니다.

예를 들어 이런 식입니다.

• 데이터가 부족하면 데이터베이스나 스토리지만 먼저 올린다.

• 배포 성능이 문제면 배포 쪽만 조정한다.

• 이미지가 많아졌다면 이미지 최적화나 저장 방식부터 손본다.

• 메일 발송량이 늘었다면 메일 서비스만 별도로 검토한다.

이 순서가 중요한 이유는, 첫 서비스의 핵심이 "가장 싸게 운영하기"가 아니라 "무엇이 진짜 문제인지 배우기"이기 때문입니다. 병목을 하나씩 해결하다 보면 서비스 구조를 이해하게 되고, 그 이해가 다음 서비스의 자산이 됩니다.

AI 도구 비용도 운영비다

요즘은 인프라 비용만 신경 쓰면 반쪽짜리 계산입니다. Claude Code나 Codex 같은 AI 도구를 자주 쓰면 이것도 분명한 운영비가 됩니다. 특히 Claude Code는 API 기반으로 사용할 때 토큰 사용량에 따라 비용이 달라지고, 코드베이스가 크거나 여러 번 반복 작업을 시키면 생각보다 빨리 사용량이 늘어날 수 있습니다. Anthropic 문서도 팀 환경에서 사용량을 측정해 기준을 잡고, /usage 같은 명령으로 추적하며, 필요하면 워크스페이스 지출 한도를 두라고 권합니다.⁴

비용을 줄이는 방법도 아주 현실적입니다. 대단한 비법이 아니라, 맥락을 줄이고 작업을 작게 나누는 것입니다.

• 관련 없는 작업으로 넘어갈 때는 세션을 비워 맥락 길이를 줄인다.

• 대부분의 코딩 작업은 더 비싼 모델보다 적절한 기본 모델로 처리한다.

• "전체 프로젝트를 개선해줘"보다 "로그인 폼 검증만 고쳐줘"처럼 범위를 좁힌다.

• 긴 로그나 테스트 결과를 그대로 다 읽히지 말고 필요한 부분만 보여준다.

AI에게도 "많이 시킨다"와 "잘 시킨다"는 전혀 다른 이야기입니다. 적게 말해도 정확히 시키면 품질은 유지하고 비용은 줄일 수 있습니다. 결국 이것도 운영 감각입니다.⁴

0원에서 시작하는 현실적인 운영 시나리오

작은 서비스는 아래처럼 단계적으로 운영하면 부담이 적습니다.

여기서 핵심은 "모든 것을 한꺼번에 유료화하지 않는다"입니다. 소개 페이지나 문서는 GitHub Pages로 분리하고, 실제 서비스 화면은 Vercel에 두는 식으로 역할을 나누면 같은 돈으로 더 오래 버틸 수 있습니다.¹

처음부터 거대한 운영 환경을 꾸리기보다, 사용자가 늘어나는 흐름에 맞춰 한 칸씩 넓혀가는 편이 낫습니다. 가게를 열자마자 백화점을 짓는 사람은 없습니다. 우선 손님이 문을 열고 들어오게 만드는 것이 먼저입니다.

매달 확인해야 할 숫자는 많지 않다

운영비를 잘 관리하려면 숫자를 매달 보는 습관이 필요합니다. 다만 숫자가 너무 많으면 오히려 손을 놓게 됩니다. 처음에는 아래 정도만 봐도 충분합니다.

• 월간 활성 사용자 수가 늘고 있는가

• 데이터베이스 용량과 파일 저장량이 얼마나 남았는가

• 가장 많은 트래픽을 먹는 페이지가 어디인가

• 실패한 요청이나 에러가 어느 구간에서 반복되는가

• AI 도구 사용량이 지난달보다 얼마나 늘었는가

이 다섯 가지만 꾸준히 봐도 "지금 돈을 써야 하나, 아니면 습관을 고쳐야 하나"를 구분할 수 있습니다.

아끼는 운영은 초라한 운영이 아니다

비용을 아끼는 운영은 대충 운영하는 것이 아닙니다. 오히려 서비스의 체력을 키우는 일입니다. 무료 플랜과 저비용 구조를 잘 활용하는 사람은, 나중에 유료 전환을 하더라도 어디에 돈을 써야 가장 효과적인지 압니다.

첫 서비스에서 중요한 것은 화려한 아키텍처가 아니라 끝까지 운영해본 경험입니다. 사용자 한 명이 들어오고, 글 하나가 저장되고, 수정과 삭제가 되고, 로그인을 하고, 검색이 되고, 배포된 주소로 다시 접속되는 경험. 그 흐름을 몇 달이라도 유지해보는 것이 가장 큰 공부입니다.

서비스는 크게 시작하는 사람보다 오래 운영한 사람이 더 많이 배웁니다. 그리고 그 배움은 대부분, 생각보다 소박한 한 문장에서 시작합니다.

"지금은 더 쓰지 말고, 있는 것으로 조금만 더 버텨보자."

참고

¹Supabase·Vercel·GitHub 조합과 무료 플랜 개요

²Supabase와 Neon 무료 데이터베이스 한도 비교

³React·Supabase·Vercel 스택의 비용 최적화 팁

⁴Claude Code 비용 관리 공식 문서