AWS, GCP 등 클라우드의 숨은 비용 정리: 요금 폭탄의 이유

AWS나 GCP 같은 클라우드 서비스를 처음 쓰면 "성능에 대한 요금과 스토리지/트래픽 요금 정도만 보면 되겠지" 라는 생각을 하고 이용을 하는 경우가 많습니다.

그런데 실제로 클라우드 기반 운영이 시작되면, IP 비용, 아웃바운드(egress) 트래픽, NAT/게이트웨이, CDN, 로드밸런서, 로그/모니터링, 백업/스냅샷, 관리형 서비스의 '요청 단위 과금' 같은 것들이 슬금슬금 붙습니다.

과거 여러 업체에서 제공하던 공유 호스팅이 "표시 가격이 곧 결제 금액"인 경우가 많았다면, 클라우드의 경우 표시 가격은 시작점에 불과한 경우가 많습니다.

오늘 포스트에서는 클라우드 이용 시 쉽게 알아보기 힘든 여러 가지 비용 구조에 대해 알아보겠습니다.

숨은 비용이 생기는 구조: 잘 안 보이는 네트워크/운영 비용

클라우드 서비스에서 리눅스 같은 운영체제를 돌려서 웹서비스를 운영할 때의 과금은 크게 두 부류로 나뉩니다.

• 눈에 보이는 비용: VM 인스턴스(EC2/GCE), 저장 공간(EBS/Persistent Disk), DB 인스턴스(VM 인스턴스 내에 포함하기도 하지만, 속도를 위해 별도 이용하는 경우가 많음)
• 잘 안 보이는 비용: 네트워크(특히 외부로 나가는 아웃바운드 트래픽), NAT, 공인 IPv4, 로드밸런서/게이트웨이, 로그/모니터링, 백업/스냅샷, 관리형 서비스의 요청 과금

개념 검증 초기 단계나 소규모 서비스에서는 후자(숨은 비용)가 작아서 크게 와닿지 않지만, 서비스 이용량이 늘어 트래픽이 상승하거나 보안이나 가용성을 위해 정석적인 아키텍처(멀티 AZ, 프라이빗 서브넷, NAT, WAF, 많은 로깅)로 가면 숨은 비용이 원래 예상 비용을 추월하는 순간이 옵니다.

사용하다 보면 생각보다 많은 요금이 발생하고, 청구서를 보면 "이런 것까지 돈을 받아?" 싶은 항목들이 생기죠.

가장 흔한 비용 지표들

공인 IPv4

AWS는 공인 IPv4 주소에 대해 2024년 초부터 시간당 과금을 하기 시작했습니다. 중요한 건 이 IP 주소를 사용 중이든 사용하지 않고 있든 시간당 비용이 계속 발생할 수 있다는 점입니다.

GCP 역시 요금을 받고있으며, 마찬가지로 실제 할당하지 않은 IP 역시 과금을 합니다.

이는 전세계에서 할당 가능한 IPv4 수가 무한하지 않고, 그 수가 많은 웹/앱 서비스로 인해 빠르게 소진되고 있기 때문입니다.

테스트용으로 붙여둔 IP 몇 개를 제때 해제하지 않아 발생하는 비용 누수처럼, 계정이나 리전 수가 많아질수록 이런 비용도 점점 누적됩니다. AWS와 GCP 모두 월 3.65달러 수준의 과금을 하니, 사용하는 IPv4 주소가 많을 경우 생각보다 큰 비용 지출이 있습니다.

클라우드 서비스를 이용하는 요즘 시기에는 사용 고정 IP를 줄이는 것이 곧 비용 최적화의 일부가 되었습니다. 가능하면 로드밸런싱과 내부 서비스, 또는 프록시/게이트웨이 단일 진입 IP 형태로 사용하는 게 좋습니다.

아웃바운드 트래픽(egress)

클라우드에서 가장 악명높은 것이 바로 아웃바운드 트래픽 비용입니다.

• 인바운드 트래픽: 외부에서 우리 서비스로 데이터를 받는 경우. 예를 들어 HTTP POST 요청을 할 경우 POST 요청 바디가 전부 인바운드 트래픽이 됩니다. 파일 업로드 시 파일의 용량이 5MB라면 5MB + 메시지 내용이 트래픽 용량이 되겠죠.
• 아웃바운드 트래픽: 우리 서비스에서 외부로 데이터를 보내는 경우입니다. 예를 들어 서버에 저장된 5MB의 파일을 1,000명이 요청한다면 약 5GB의 아웃바운드 트래픽이 발생합니다.

AWS도 GCP도 인바운드 트래픽 자체는 무료지만, 아웃바운드 트래픽은 과금된다는 점을 공식 문서에서 얘기합니다.

서비스가 커지고 사용자가 많아질 수록 거의 정직하게 트래픽의 양은 비례해서 늘어납니다. 특히 다운로드/스트리밍/이미지 호스팅/백업 파일 배포 등의 상황에서는 아웃바운드 트래픽을 어떻게 조절하는지가 핵심 변수입니다.

또한 우리나라의 경우 다른 나라에 비해 트래픽이 비교적 비싼 편인데요, 국내 사용자를 대상으로 서비스할 경우 이 트래픽 비용에 대해 잘 계산해야 합니다.

NAT/게이트웨이

VPC에서 워커나 서버를 프라이빗 서브넷에 두고 외부로 나갈 때 NAT를 쓰면 보안 상 좋습니다만, 문제는 클라우드의 경우 NAT도 시간당 비용과 처리 데이터(GB) 당 비용을 과금한다는 것입니다.

AWS NAT Gateway와 GCP의 Cloud NAT 모두 과금 체계를 가지고있고, NAT 로그는 별도의 네트워크 텔레메트리, 로깅에 따른 과금이 된다고 안내합니다.

로드밸런서

로드밸런서(ALB/ELB, Cloud Load Balancing)나 API Gateway 같은 서비스는 단순히 중간 서버를 한 대 더 사용하게 해주는 개념이 아니라 시간 당 + LCU/요청량/처리량 단위 과금이 섞여있는 경우가 많습니다.

운영이 안정화될 수록 이런 관리 계층이 늘어나고 결과적으로 고정비 구조가 만들어지는데요, 재무/운영 관점에서 서비스 규모에 대비하여 어떤 계층을 관리용으로 구매할지 결정해야 합니다.

작은 팀일 수록 이런 관리 서비스가 값어치를 하기도 하지만, 트래픽이 커지면 직접 운영하는 설계가 유리해지기도 합니다.

로그/모니터링: "가장 조용하게, 가장 꾸준히 새는 돈"

작은 서비스는 사실 서비스 서버 자체에서 로깅을 해도 됩니다. 하지만 반드시 지켜야할 로그는 별도 로그 서버에 이중화 구조로 저장하죠. 그런 면에서 클라우드 로그는 편리합니다.

다만 디버그 로그를 좀 더 찍거나 접속 로그를 가능한 많이 남기고, 보안 감사를 위해 장기 보관을 하거나 로그 중앙화를 하는 등 목표가 많아질 수록 로그 수집, 저장, 검색/쿼리 비용이 꾸준히 나갑니다. 그것도 계속해서 누적되기 떄문에 로그의 규모가 커질 수록 증가 폭이 커집니다.

잘못된 설정(예를 들면 Retention을 "Never Expire"로 설정)이나 구조 설계로 인해서 고정비가 점점 커지는 증상이 로그/관측성 부문에서 나올 수 있으니, 이 부분도 잘 설계하는 게 좋습니다.

CDN

CDN 서비스를 사용하면 아웃바운드 트래픽 비용을 줄이는 데 도움이 됩니다만, 당연히 그만한 대가가 따릅니다.

• 자체 전송비
• 요청 수 단위 과금
• 상황에 따른 원본 조회 비용

이 모든 것이 CDN 서비스 사용 시 고정적으로 붙습니다. CDN이 아무리 좋다지만 이걸 붙인다고 또 무조건 저렴해지는 것이 아닙니다. 캐시 히트율이 낮으면 CDN과 원본 아웃바운드 비용이 함께 나가는 상황을 겪을 수도 있습니다.

실제 100개 이상의 청구 비용 예시

위 표는 저희가 일부 API 서비스를 위해 사용했던 GCP의 결제 비용에 대해 보여주고 있습니다. 저희가 사용한 건 Google Compute Engine(컴퓨팅 인스턴스)과 Cloud Run Functions(서버리스 함수 서비스) 두 개 서비스이고, 모두 무료 티어 내에서 사용중이었습니다. 그렇기 떄문에 비용이 우선 나오고 거기에 대해서 무료 티어 할인이 그만큼 적용되는 방식으로 표에 나옵니다.

이걸 보면 저희는 단 2개의 서비스를 썼을 뿐인데 청구 항목(SKU)은 100가지가 훌쩍 넘게 쪼개져 나옵니다. 우리가 왜 클라우드 비용을 예측하기 힘든지가 이 표에 고스란히 담겨 있습니다.

1. 전 세계로 흩어지는 네트워크 파편화 비용

가장 당혹스러운 부분은 네트워크 비용입니다. 단순히 '트래픽' 하나로 잡히는 게 아니라, Jakarta, Seoul, Madrid, Paris, Melbourne 등 데이터를 주고받은 전 세계 리전 별로 항목이 다 쪼개져 있습니다. 이 항목은 0.001GB, 심지어 0.000002GB 단위까지 계산되어 청구됩니다.

2. 요청한 적 없는 분석 서비스의 비용 표시

저희 비용 항목들을 보면 Network Intelligence Center 항목이 보입니다. 네트워크 분석기(Network Analyzer), 토폴로지(Topology) 등 성능 모니터링 기능들입니다. 이런 기능은 저희가 따로 요청한 것이 아니고, 기본 설정에 따라 리소스 시간 단위로 과금 항목이 잡히게 됩니다. 본인이 신청한 서비스가 일부만 있더라도 클라우드 서비스에서는 그 서비스를 유지하기 위한 지능형 네트워크 관리 비용을 계산하고 있는 것입니다. 물론 현재로서는 할인 대상이긴 하나 나중에 이 정책이 바뀔 가능성은 있습니다.

3. 서버리스의 함정: CPU/메모리 외의 비용들

서버리스 함수를 쓰면 단순히 실행 시간에 대해서만 돈을 낸다고 생각하기 쉽습니다. 하지만 실상은 다릅니다.

• Artifact Registry Storage: 함수 코드를 배포하기 위해 빌드된 이미지를 저장하는 공간 비용이 따로 붙습니다.
• Invocations: 실행 시간과는 별도로 '호출 횟수' 자체에 대한 비용이 카운트됩니다.
• External IP Charge: 인스턴스를 띄우기만 해도 할당되는 공인 IPv4 IP 비용은 무료 티어 할인 항목에 포함되지 않는 경우(SKU C054-7F72-A02E 등)가 많아 의외의 지출이 될 수 있습니다.

숨은 비용을 잡는 체크리스트

"인스턴스 몇 대냐"보다 아래 질문이 더 중요할 때가 많습니다.

1. 필요한 공인 IPv4 주소 개수 (테스트/스테이징 포함)
2. 아웃바운드 트래픽은 월 몇GB로 예상되며, 피크 시의 트래픽은 어느 정도인지
3. 프라이빗 서브넷에서 외부로 나가는 트래픽이 NAT를 타는지 여부
4. 로그 수집량(GB/일)과 보관 기간 정책
5. 로드밸런서/게이트웨이 계층이 몇 개인지와 멀티 AZ 세트 수
6. CDN 캐시 히트율(예상)과 동적/정적 비율
7. 백업/스냅샷/아카이브 정책

온프레미스 NAS/스토리지 TCO가 매력적인 이유

클라우드의 장점은 분명합니다: 민첩성, 확장성, 글로벌, 매니지드 운영이 있죠.

하지만 SMB/현업 구축 관점에서 보면, 아래 조건에서는 온프레미스가 이길 때가 많습니다.

1) 비용 예측 가능성: "고정비가 선명하다"

NAS/스토리지는 기본적으로 아래 항목 정도로 비용 발생 항목이 명확합니다.

• 장비 메인 유닛
• 디스크 드라이브(HDD, SSD)
• 유지보수/추가 액세서리(선택 사항)
• 전기/공간
• 백업 매체

클라우드처럼 "사용량 기반으로 조용히 새는 항목"이 상대적으로 적은 편이라 비용 예측이 굉장히 용이합니다. 특히 로그/아웃바운드 트래픽/NAT 같은 변동비가 TCO를 흔드는 워크로드에서는 온프레미스가 강합니다.

2) 데이터가 무겁고, 밖으로 자주 나가는 서비스일수록 유리

• 대용량 파일 서버
• 영상/이미지 원본 저장
• 백업 저장소(특히 장기 보관)
• 내부 업무 시스템(외부 다운로드가 잦지 않은 경우)

위와 같은 유형은 클라우드에서 저장 비용 자체보다 아웃바운드 트래픽이나 운영 비용이 더 커지는 경우가 많습니다. 온프레미스 장비를 구축하면 이 부분에서 큰 이득을 볼 수 있습니다.

간단하게 TCO 계산하기: 3년 기준

아주 러프하게라도, 3년 기준으로 아래를 비교해보면 감이 옵니다.

클라우드 예시

• 인스턴스(24/7) + 디스크 + 스냅샷
• 트래픽(월 X TB)
• NAT(시간당 + 처리량)
• 로드밸런서/게이트웨이
• 로그/모니터링(일 Y GB, 보관 Z일)

온프레 예시

• NAS 본체 + 디스크 드라이브 + UPS
• 백업(2차 NAS 또는 외장/테이프/오브젝트)
• 전기/공간
• 유지보수(방문/모니터링)

마무리: 클라우드 사용 시 비용 구조 이해는 필수

정리하면 이렇습니다.

• 클라우드는 유연함과 편리함을 돈으로 사는 서비스
• 비용 폭탄은 대부분 네트워크 + 관측성(로그/모니터링)에서 온다
• 온프레미스 NAS/스토리지는 장기 비용 예측이 쉽고, 데이터가 무거운 워크로드에 강하다

이 글을 잘 읽어보신 뒤 "우리가 사용하는 서비스의 어느 부분에서 숨은 비용이 나올지"를 체크해 보시면, 다음번 청구서가 나올 때는 정확하게 어느 부분에서 비용이 새는지 잘 이해하고 대처하실 수 있을 것입니다.

NAS/스토리지로 TCO를 낮추는 설계, 견적/구축 상담이 필요하다면

온프레미스 NAS/스토리지로 장기 비용을 안정화하거나, 클라우드와 하이브리드로 설계해서 트래픽이나 로그 비용을 줄이는 방향이 필요하면 아래로 문의 주세요.