클라우드 서버 비용 절감, '덜 쓰기'가 아니라 '잘 쓰기'가 답이다

줄이기 전에 먼저 '보이게' 만들어야 한다

클라우드 서버 비용 절감 프로젝트에서 가장 흔히 저지르 는 실수가 있습니다. 청구서를 보자마자 "어떤 인스턴스를 줄일까"를 먼저 고민하는 것입니다. 인스턴스 타입 을 바꾸고예약 구매 를 해도, 정작 비용이 어디서 발생하는지 이해하지 못한 채로 는 근본 문제 가 해결되지 않습니다.

국내중소 IT 기업이 클라우드 비용 분석 에 처음 들어갈 때 마주치는 공통적인 장면이 있습니다. 오래전 개발용으 로 생성한 인스턴스가 수개월째 가동 중이고, 어느 팀 이 띄웠는지 아무 도 모르는 스냅샷이 수십 개 쌓여있으며, 각 팀이 각자 용도가 불분명한 리소스를 방치하고 있습니다. 이 상태에서 인스턴스 를 다운그레이드해 봐야 전체 낭비 구조는 그대로입니다.

비용이보여야 최적화할 수 있습니다. 비용 가시성 확보가 모든 절감 작업 의 전제 조건입니다.

태깅 전략: 비용 가시화의 첫 번째 조건

비용 가시성 은 리소스 태깅(tagging) 체계에서 시작합니다. 태그란 각 클라우드 리소스 에 부착하 는 메타데이터 레이블로, team:backend, env:production, service:auth-api 형태입니다.

태깅이 체계적으로 이루어지면 팀별·서비스별·환경별 비용을 분리해 볼 수 있습니다. AWS Cost Explorer에서 team 태그 로 필터링하면특정 팀 이 한 달에 얼마를 쓰는지 즉시 확인할 수 있고, NCP 비용 관리 콘솔에서 service 태그로 필터링하면 서비스 단위 인프라 비용을 산출할 수 있습니다.

실무에서 권장하는 필수 태그 4개 는 다음과 같습니다.

• env : production / staging / development — 환경별비용 분리
• team : 비용 책임 팀식별
• service : 어떤 서비스 에 귀속되는 리소스인지
• managed-by : terraform / manual / helm — IaC 추적 및 수동생성 리소스 식별

태깅 정책을 강제하려면 AWS의 경우 AWS Config 규칙, NCP의 경우 Sub Account 정책을 통해 태그 없는 리소스 생성 자체 를 차단할 수 있습니다. 신규 리소스는 IaC 코드에 태그 블록을 표준화하고, 기존리소스는 일회성 감사 스크립트 로 일괄 적용합니다.

아키텍처가 청구서를 결정한다

인스턴스 타입을 바꾸 는 것은 비용 절감의 시작일 뿐입니다. 더 큰 레버는 어떤 아키텍처 패턴 을 선택하느냐에 있습니다. 동일한 워크로드 를 어떻게 배포하느냐 에 따라 비용 구조가 근본적으로 달라집니다.

컨테이너 밀도 최적화: 같은 비용에 더 많이 실행하기

모놀리식 단일 서버 방식은 인스턴스가 24시간 가동됩니다. 피크 트래픽을 기준으로 인스턴스 크기를 결정하기 때문에 평균 CPU 활용률이 10~20%에 머무는 경우 가 많습니다. 청구서 는 피크 기준으로 나오지만, 실제로 그 성능 을 사용하 는 시간은 하루의 일부에불과합니다.

컨테이너(Kubernetes) 방식은 여러 서비스를동일 노드에 고밀도로 패킹합니다. Kubernetes의 requests와 limits 설정을통해 각 컨테이너의 리소스 상한을 정의하고, 노드의 빈 공간을 최대한 채웁니다. Horizontal Pod Autoscaler(HPA)는 트래픽이 증가할 때 파드를 늘리고, Karpenter나 Cluster Autoscaler는 노드 수를 자동으로 조절합니다.

실제 사례를 소개합니다. 국내 SaaS 스타트업 B사는 마이크로서비스 9개 를 각각 별 도 VM에서 운영했습니다. 대부분의 서비스 가 CPU 5% 미만으로 동작하고 있었지만, 서비스 간 격리 를 위해 VM을 분리한상태였습니다. 총 월클라우드 비용은 약 320만 원이었습니다.

k3s 기반경량 Kubernetes 클러스터로 전환 후 9개 서비스를 노드 3대 에 패킹했습니다. 각 서비스에 적절한 requests/limits를 설정하고 HPA를 구성한 결과, 전환 후월 비용은 94만 원으로 71%가 절감되었습니다. 서비스 격리는 Kubernetes Namespace와 NetworkPolicy로 유지하면서도 컴퓨팅 비용은 대폭 줄였습니다.

서버리스: 유휴 시간 과금을 완전히 제거하기

배치 처리, 이벤트트리거 API, 주기적 데이터 집계 작업은 서버리스 전환 이 가장 효과적입니다. AWS Lambda, NCP Cloud Functions는 요청 이 있을 때만 과금됩니다.

하루 10만 건 이하 의 가벼운 API라면 서버리스전환 시 월 비용이 수천 원 수준까지 낮아질 수 있습니다. 항시 기동 인스턴스 대비 유휴 시간 비용이 0이라는 것이 핵심 장점입니다. 단, 콜드 스타트 지연이 허용 가능한 워크로드인지 먼저 확인해야 합니다. 실시간 응답이 필요한 서비스나 실행 시간이 긴 배치 작업에 는 적합하지 않습니다.

데이터 전송 비용: 가장 조용한 청구서 도둑

컴퓨팅 비용에 집중하다 보면 **데이터 전송 비용(egress fee)**을 놓치기쉽습니다. 그런데 트래픽이 많은 서비스에서는 데이터 전송 비용이 컴퓨팅 비용과 맞먹거나 초과하는 경우도 발생합니다.

리전 간 전송, AZ 간 전송의 비용 구조

AWS 기준비용 구조를 살펴봅니다.

• 인터넷 아웃바운드 전송: GB당 약 90~108원 (리전 에 따라 상이)
• 리전 간데이터 전송: GB당 약 90원
• 동일리전, 다른 AZ 간 전송: GB당 약 10원
• 동일 AZ 내 전송: 무료

마이크로서비스 아키텍처에서 서비스 간 API 호출 이 빈번하다면, 서비스들을 동일 AZ에 배치하는 것만으로도 전송 비용을 크게 줄일 수있습니다. Kubernetes에서는 topologySpreadConstraints를 활용해 Pod를 특정 AZ에 집중 배치할 수 있습니다.

실전 데이터 전송 비용 최소화 체크리스트

① S3/Object Storage VPC 엔드포인트 설정 인터넷을 경유하지 않고 내부망으로 오브젝트스토리지에 접근하면 egress 비용이 제거됩니다. AWS의 경우 VPC Gateway Endpoint for S3는 무료로 설정할 수 있습니다.

② CDN 캐싱 적극화 정적 자원(이미지, JS, CSS)을 Cloudflare 또 는 NCP CDN을 통해 제공하면 오리진 서버 아웃바운드 트래픽을 80~90% 줄일 수 있습니다.

③ 로그·메트릭데이터 압축 전송 Prometheus metrics, 애플리케이션 로그 등 내부 데이터를 gzip 압축해전송하면 동일 정보를 60~70% 적은 대역폭으로 전달할 수 있습니다.

④ 불필요한크로스 리전 아키텍처 제거 개발팀 편의로 도쿄 리전 에 남아있는 스테이징환경, 글로벌 확장 계획 없 이 미국 리전 을 사용하 는 서비스 등 을 서울 리전으로 통합합니다.

스토리지 비용: 시간이 지날수록 커지는 함정

컨테이너화 와 데이터 전송 최적화 다음으로 주목해야 할 영역이 스토리지입니다. 서비스가 운영되는 동안 데이터는 계속쌓이고, 정리 정책이 없으면 스토리지 비용 이 컴퓨팅 비용을 추월하는 상황도 발생합니다.

스토리지 티어링: 데이터 온도에 따른 분류

AWS S3, NCP Object Storage 모두 데이터접근 빈도에 따른 스토리지 클래스를 제공합니다.

생명주기 정책 을 설정하면 이 이동이 자동으로 처리됩니다. 운영 초기 에 정책 을 설정해 두면 이후에는 별도 관리 없 이 비용이 자동으로 최적화됩니다.

EBS 스냅샷 정기 감사

EC2 인스턴스를 삭제했지만 EBS 스냅샷이 그대로 남아있는 경우가 빈번합니다. 스냅샷은 월 GB당 과금되므로 수백 GB의 스냅샷 이 수개월 방치되면 상당한 비용 이 됩니다.

분기마다 스냅샷 목록을 감사하고, 연결된 인스턴스 가 존재하지 않거나 불필요한 스냅샷은 즉시삭제합니다.

# 전체 스냅샷 목록 + 크기 확인 (AWS CLI)
aws ec2 describe-snapshots --owner-ids self \
  --query 'Snapshots[*].[SnapshotId,VolumeSize,StartTime,Description]' \
  --output table

AWS Trusted Advisor 무료 티어는 연결되지 않 은 EBS 볼륨 과 오래된 스냅샷 을 자동으로 감지해줍니다.

FinOps 성숙도 3단계: 1회성 절감을 지속 절감으로

인스턴스 최적화, 컨테이너 밀도, 스토리지 티어링을 모두 적용해도 한 번으로 끝나지 않습니다. 서비스가 성장하면서 새로운 리소스가 추가되고, 최적화된 리소스 도 시간이 지나면다시 비효율 이 발생합니다. 지속적인 클라우드 서버 비용 절감을 위해서는 FinOps(Financial Operations) 문화가 필요합니다.

FinOps Foundation이 정의한성숙도 3단계입니다.

1단계: Crawl — 가시성 확보

목표 는 "무엇이 얼마나 쓰이는지 보이게만드 는 것"입니다.

• 모든 리소스에 태깅 정책적용 (team, env, service)
• 팀·서비스별 비용 할당시작
• 월 단위비용 리뷰 미팅 도입 (30분, 전체 팀)
• 예산 알림 설정: 현재 월 지출 의 80%, 100% 도달시 자동 알림

이 단계 를 완전히 구현하지 않은 채 2단계로 넘어가는 팀이 많습니다. 가시성 없이 최적화를 시도하면 어디서 효과가 나는지도, 어디서 새는지도 알 수 없습니다.

2단계: Walk — 최적화 실행

• 예약 인스턴스 전환: 6개월 이상안정적으 로 사용한 베이스라인 워크로드
• 스팟인스턴스 활용: 중단 허용 가능한 배치·CI 워크로드 (온디맨드 대비 최대 70~90% 절감)
• 스토리지 생명주기 정책자동화
• 우측화(rightsizing) 정기실행: AWS Compute Optimizer 기반, 분기 1회

3단계: Run — 문화와 자동화

• 개발자가 직접 자기 팀 비용 모니터링 — 비용책임 분산
• PR에 인프라비용 변화 자동 코멘트 (Infracost 오픈소스 활용)
• 비용 이상 감지 자동 알림: 전주 대비 20% 이상 증가 시슬랙 알림
• 절감 성과를 팀분기 KPI에 포함

대부분의 팀이 Crawl 단계도 완전히 구현하지 않 은 채 Walk 단계의 최적화를 시도합니다. 순서가 성과를 결정합니다.

지금 당장 시작하는 3가지 액션

이론보다 실행입니다. 오늘 바로 시작할 수 있 는 세 가지 를 구체적으 로 정리합니다.

① 미사용리소스 5분 감사

AWS Console → Cost Explorer → 서비스별 지난 1개월 비용 확인. EC2, RDS, EBS, Snapshot, Elastic IP 항목 을 중심으로 삭제 가능한 리소스 를 표시합니다. 불분명한 리소스는 삭제전 review-by:2026-04-30 태그를 붙여 유예기간을 둡니다.

② 태그정책 1시간 내 적용

최소 env, team 두 개 태그 를 현재 실행 중인 인스턴스 전체에 추가합니다. IaC를 사용 중이라면 Terraform의 default_tags 블록 에 추가해 이후 생성 리소스에 자동 적용합니다.

# Terraform default_tags 예시
provider "aws" {
  default_tags {
    tags = {
      team       = "backend"
      managed-by = "terraform"
    }
  }
}

③ 예산알림 즉시 설정

현재 월 지출의 120%를 임계값으로 Budget Alert를 설정합니다. 비용 급증 이 발생했을때 몇 주 후 청구서 가 아닌 당일 에 인지할 수 있습니다. AWS Budgets는 무료, NCP는 비용 관리 콘솔에서 예산 알림 설정이 가능합니다.

클라우드 서버 비용 절감은 일회성 프로젝트가 아닙니다. 비용 가시성확보 → 아키텍처 최적화 → 지속적 모니터링 의 사이클이 반복될 때 비로소 지속 가능한 절감이 만들어집니다. 오늘 첫 번째 액션인 태그 정책 적용과 예산알림 설정부터 시작해 보세요.