클라우드 요금 폭탄을 피하는 현실적인 인프라 전략

클라우드가 왜 '조용한 카지노'가 되는가

월말 청구서를 보고서야 클라우드 비용을 자각한 경험이 있는 사람들이 의외로 많습니다. 한 번에 큰 비용이 빠져나가는 것이 아니라, 로그 몇 기가바이트, 이미지 최적화 몇 만 건, 데이터 전송 몇 백 기가바이트처럼 잘 보이지 않는 조각이 계속 쌓이기 때문입니다. 그래서 클라우드는 카드값처럼, 늦게 깨닫는 청구 구조가 가장 큰 리스크가 됩니다.

클라우드워치 로그와 좀비 리소스, 안 보이니 더 위험하다

AWS를 쓰는 순간 거의 자동으로 따라오는 것이 로그와 각종 부가 리소스입니다. 새로 람다를 만들거나 RDS 인스턴스를 켜면 로그 그룹이 자동으로 생기고, 기본 보존 기간은 사실상 영구 보관입니다. 문제는 로그 저장이 무료가 아니라는 점입니다. 한 번 저장된 로그는 매달 저장 용량 기준으로 임대료를 내는 구조라서, 몇 년 전 디버깅하던 텍스트 로그에도 계속 비용을 지불하는 셈이 됩니다. 여기서 많이들 놓치는 부분이 바로 이 "과거 로그 임대료"입니다.

저라면 로그 시스템을 두 단계로 나눕니다. 조회가 자주 필요한 최근 로그는 7일 이내만 남기고, 그 이후는 아예 외부로 옮기는 방식입니다. 예를 들어 저렴한 VPS에 그라파나를 올리고, 주기적으로 AWS 로그를 끌어와 자체 보관하도록 구성한 뒤, AWS 로그 보존 기간을 하루로 줄이는 식입니다. 국내 환경에서는 이 정도 VPS 비용이 한 달 몇 천 원 선에 머무는 경우가 많기 때문에, 장기 로그를 클라우드에 그대로 두는 것보다 구조적으로 유리합니다.

비슷한 맥락에서, 인스턴스만 지우고 로드밸런서와 EBS 볼륨은 남겨둔 채 잊어버리는 "좀비 리소스"도 자주 등장합니다. 대시보드에 잘 보이지 않기 때문에, 서비스는 종료했다고 믿는데 청구는 계속 나오는 구조입니다. 이럴 때는 콘솔에서 하나씩 찾기보다, 리전 전체와 모든 리소스 타입을 한 번에 조회하는 리소스 뷰를 주기적으로 확인하는 습관이 훨씬 안전합니다. 제 기준에서는 신규 프로젝트를 닫을 때 "마지막으로 리소스 전체 리스트를 훑어보는 것"을 체크리스트에 넣어두는 편이 현실적입니다.

이미지·비디오 최적화가 어떻게 수익을 갉아먹는가

요즘 프론트엔드 프레임워크는 이미지와 비디오를 자동으로 최적화해주는 컴포넌트를 기본 제공합니다. 문제는 이런 "마법 같은 편의 기능"이 종종 사용량 기반 과금과 연결된다는 점입니다. 한국에서 많이 쓰는 Vercel 같은 서비스는 이미지 변환 횟수, 대역폭 사용량을 기준으로 요금이 오르는 구조라서, 예쁜 랜딩 페이지를 만들수록 비용 리스크가 커집니다.

백그라운드 비디오 하나가 10MB라고 가정해도, 방문자 천 명이면 10GB, 십만 명이면 1TB 대역폭을 소모합니다. 한두 번 바이럴만 터져도 프로 플랜 기본 포함 용량을 넘기기 쉽고, 이후부터는 기가바이트 단위로 요금이 붙습니다. 저라면 이런 대용량 미디어는 처음부터 애플리케이션 서버와 분리해 생각합니다. 단순 홍보 영상이라면 유튜브나 비메오에 올려 임베드하는 방식이 가장 싸게 먹히고, 네이티브 HTML 비디오 태그를 고집하고 싶다면 대역폭 무료 정책을 가진 오브젝트 스토리지를 별도로 두는 편이 낫습니다.

이미지의 경우에도, 모든 화면 크기에 맞춰 실시간 리사이즈를 해주는 컴포넌트를 무조건 쓰기보다, 빌드 단계에서 한 번에 WebP로 변환해 "적당한 해상도 한 장"으로 통일하는 전략이 의외로 효율적입니다. 5G와 기가 인터넷이 보편화된 국내 환경에서는, 정교한 반응형 이미지 최적화로 줄일 수 있는 몇 십 밀리초보다, 그 기능을 위해 지불하는 매달 사용량 과금이 더 뼈아플 수 있습니다. 속도 지표를 끝까지 끌어올리는 집착이, 수익 구조를 좀먹는 숨은 비용이 되기 쉽다는 점을 한 번쯤 계산해볼 필요가 있습니다.

'언더독' 인프라가 가져오는 비용 구조의 차이

많은 개발자가 대형 클라우드를 선택하는 이유는 "안정성과 편의성"입니다. 하지만 어느 정도 트래픽 패턴이 읽히는 서비스라면, 같은 돈으로 더 단순하고 예측 가능한 인프라를 구성할 여지도 충분히 생깁니다. 특히 국내에서 소규모 SaaS나 부트스트랩 스타트업을 하는 사람에게는, 매달 변동성이 큰 과금 구조보다 "한 번 정하면 크게 흔들리지 않는 비용 구조"가 훨씬 유리합니다.

리전, 데이터베이스, 대체 스토리지의 현실적인 선택지

많은 사람이 자신이 사는 곳과 가까운 리전을 고릅니다. 한국에서는 서울 리전을 선택하는 경우가 많습니다. 지연 시간 측면에서는 이해할 만한 선택이지만, 리전마다 요금 단가가 크게 다를 수 있다는 점을 간과하기 쉽습니다. 세금, 전기 요금, 인프라 환경에 따라 같은 스펙의 서버라도 미국 동부가 더 싸고, 일부 지역은 체감상 30~50% 비싸게 느껴질 때도 있습니다. 법적 규제가 없는 서비스라면, 저라면 핵심 워크로드는 저렴한 리전에 두고, 정말 지연이 민감한 일부 API만 국내 쪽에 프록시 형태로 두는 하이브리드 구성을 고민해보겠습니다.

데이터베이스도 마찬가지입니다. 트렌드만 보면 서버리스 NoSQL로 가야 할 것 같지만, 읽기·쓰기·스캔 요청마다 과금되는 구조는 비즈니스가 자주 바뀌는 초기 서비스와 궁합이 좋지 않습니다. 스키마를 자주 바꾸고, 새로운 조회 패턴을 계속 실험해야 하는 시기에는, 쿼리가 조금 비효율적이어도 고정 비용으로 버틸 수 있는 전통적인 PostgreSQL이나 MySQL이 훨씬 관대합니다. 국내 스타트업 환경에서 "쿼리 최적화를 잘못해서 요금이 갑자기 튄다"는 불안감은 개발 속도를 떨어뜨리는 심리적 부담으로 이어지기 쉽기 때문입니다.

스토리지는 더 노골적입니다. 대형 클라우드는 스토리지 요금뿐 아니라 외부로 나가는 트래픽에도 비용을 매깁니다. 반대로 일부 신규 사업자는 저장 공간에는 요금을 부과하지만, 외부 전송에는 비용을 받지 않는 조건을 내세워 차별화를 시도합니다. 피크 트래픽이 있는 콘텐츠 서비스라면, 이런 "언더독 스토리지 + 글로벌 CDN" 조합이 종종 가장 공격적인 비용 구조를 제공합니다. 기존 S3 스타일만 떠올리던 사람에게는 발상의 전환이 필요합니다.

셀프 호스팅, 누구에게는 독이고 누구에게는 약이다

한편, 아예 클라우드를 떠나 자체 서버나 VPS로 옮기는 선택도 있습니다. 이 방식은 인프라에 손을 직접 대는 것이 부담스럽지 않은 사람에게는 매우 매력적입니다. 월 몇 만 원으로 제법 괜찮은 사양의 서버를 오래 띄울 수 있고, 로그, 미디어, 데이터베이스를 한곳에서 통제할 수 있기 때문입니다. 인코딩 작업이나 배치 처리처럼 예측 가능한 워크로드에는 특히 강합니다.

반대로, 이런 방식은 인프라 운영 경험이 거의 없고, 24시간 장애 대응이 어려운 1인 개발자에게는 독이 될 수 있습니다. 백업, 모니터링, 보안 패치까지 직접 챙겨야 하니, 개발 시간 대신 운영 부담이 늘어납니다. 그래서 셀프 호스팅은 "주당 몇 시간은 인프라를 만지며 보내도 괜찮은 사람"에게 유리하고, "코드만 쓰고 싶고, 장애는 돈 주고라도 맡기고 싶은 팀"에게는 오히려 비효율적입니다. 이 구분을 하지 않은 채 단순히 "클라우드가 비싸니 다 나가자"는 식의 선택은 위험합니다.

저라면 핵심 비즈니스가 빠르게 변하고 있는 초기 1~2년에는, 완전한 셀프 호스팅보다 "대형 클라우드 최소 구성 + 특정 비용 센 영역만 언더독 서비스로 분산"하는 전략을 우선적으로 검토하겠습니다. 예를 들어, 애플리케이션과 데이터베이스는 관리형 서비스를 쓰되, 로그와 미디어, 장기 백업은 가격 경쟁력이 좋은 언더독 쪽으로 빼는 식입니다. 이렇게 보면 언더독 전략은 올인보다는 부분 도입이 현실적인 선택입니다.

시작 전 반드시 체크할 것

많은 사람이 클라우드 비용 문제를 깨닫는 시점은 이미 요금 폭탄을 맞은 뒤입니다. 그 이전에 몇 가지만 점검해두면, 같은 인프라라도 비용 구조가 완전히 달라집니다.

누구에게 중요한 이슈인가

클라우드 과금 구조에 민감해야 하는 사람은, 매출 대비 인프라 비중이 높을 수밖에 없는 초기 서비스 운영자, 그리고 트래픽 패턴이 불규칙한 콘텐츠 서비스 담당자입니다. 이들에게는 몇 만 원의 고정비보다, 한 번의 이벤트로 요금이 튀어 오르는 구조가 훨씬 치명적입니다. 반대로, 이미 연 매출 규모가 충분하고, 트래픽도 안정된 기업이라면, 굳이 언더독 서비스를 찾아 헤매느라 운영 복잡도를 높일 이유가 크지 않습니다. 이 경우에는 장애 대응과 보안 책임을 분산할 수 있는 대형 클라우드의 장점이 더 크기 때문입니다.

국내 환경에서는 특히, 인력 비용이 인프라 비용보다 훨씬 비싸다는 점을 잊기 쉽습니다. 엔지니어 한 명의 연봉을 감안하면, 서버 비용을 극단적으로 줄이기 위해 운영 복잡도를 높이는 전략이 항상 이득이 되지는 않습니다. 그래서 제 기준에서는 "월 수십만 원 단위의 비용을 줄일 수 있는가, 아니면 몇 만 원을 아끼려다 사람 시간을 더 쓰게 되는가"를 먼저 따져보는 편을 권하고 싶습니다.

현실적 제약과 첫 행동

여기서 중요한 현실적 제약은, 대부분의 팀이 인프라 전략을 한 번에 갈아엎을 여유가 없다는 점입니다. 그래서 첫 행동은 거창한 마이그레이션이 아니라, 지금 쓰고 있는 계정 안에서 "눈에 안 보이는 새는 구멍"을 막는 것부터 시작하는 편이 낫습니다. 저라면 가장 먼저 로그 보존 기간을 재점검하고, 리소스 전체 리스트를 한 번 훑어보겠습니다. 그다음 대역폭을 많이 쓰는 이미지와 비디오를 분리 호스팅할 수 있는지 검토하겠습니다.

여기까지 진행해본 뒤에도 여전히 클라우드 비용이 부담스럽고, 기술적으로 인프라를 직접 만지는 것이 두렵지 않다면, 그때 셀프 호스팅이나 언더독 스토리지로의 점진적 이전을 고민해도 늦지 않습니다. 클라우드는 이미 거스를 수 없는 기본 인프라가 되었지만, 그렇다고 해서 항상 가장 비싼 선택이어야 할 필요는 없습니다. 어느 지점까지는 "편의를 돈 주고 사는 것"이지만, 그 이후에는 "습관 때문에 과금 구조를 방치하는 것"이 됩니다. 그 경계가 어디인지 스스로 한 번 짚어보는 것, 그게 이 글을 읽고 바로 할 수 있는 첫 번째 행동이라고 생각합니다.

출처 및 참고 :