클라우드 비용은 보통 “어느 회사가 더 싸냐”로 말하기 쉬워. 그런데 실제 청구서는 그렇게 단순하게 나오지 않아.
Microsoft가 Azure IaaS 비용 최적화 글에서 짚은 핵심은 이거야. 비용은 한 번의 큰 결정에서 생기기보다, 컴퓨트·스토리지·네트워크에서 매일 쌓이는 작은 설계 선택들이 누적된 결과라는 거야.1
이 말이 중요한 건 하이퍼스케일러의 AI 인프라 논쟁이 이제 “얼마나 많이 짓느냐”만으로 끝나지 않기 때문이야. 데이터센터를 크게 짓는 회사도, 그 위에서 AI 앱을 돌리는 고객도 결국 같은 질문을 만나. 성능과 복원력을 유지하면서 낭비를 어디서 줄일 수 있느냐.
무슨 일
Microsoft는 Azure IaaS 글에서 비용 효율을 compute, storage, networking 세 갈래로 나눠 설명했어. IaaS는 infrastructure as a service, 그러니까 서버·스토리지·네트워크 같은 기반을 클라우드에서 빌려 쓰는 방식이야.
글의 출발점은 단순해. 클라우드 비용은 단일 가격표의 문제가 아니다. 필요한 것보다 큰 가상머신을 고르고, 거의 안 보는 데이터를 비싼 저장 계층에 두고, 복원력을 높인다는 이유로 불필요하게 구성요소를 복제하고, 로그를 과하게 오래 보관하면 각각은 작아 보여도 시간이 지나며 비용이 된다.1
특히 AI 워크로드가 붙으면 이 문제가 더 커져. 학습·추론·데이터 처리·로그가 모두 커지고, 성능 요구와 복원력 요구도 같이 올라가니까.
컴퓨트는 싼 서버 고르기가 아니다
컴퓨트 비용에서 Microsoft가 강조한 건 “가장 싼 옵션”이 아니라 “일의 성격에 맞는 옵션”이야. 가상머신 크기, 프로세서 종류, 성능 프로필, 확장 방식이 워크로드와 맞아야 한다는 얘기지.1
여기서 비용 절감은 할인표를 찾는 일이기도 하지만, 그보다 먼저 과잉 배치를 줄이는 일이야. 계속 돌아가는 안정적인 업무라면 예약이나 savings plan이 맞을 수 있고, 변동성이 큰 업무라면 자동 확장이나 Spot VM이 맞을 수 있어. 대규모 배포에서는 Virtual Machine Scale Sets나 Compute Fleet처럼 용량·가용성·가격 대비 성능을 같이 조정하는 장치가 필요해.
즉 비용 최적화는 구매팀의 일이 아니라 아키텍처의 일이야. 서버를 얼마나 싸게 샀느냐보다, 애초에 필요한 만큼만 쓰도록 설계했느냐가 먼저야.
스토리지는 시간이 지나며 비싸진다
스토리지는 더 조용히 비용을 만든다. 처음에는 빠른 디스크와 넉넉한 용량이 필요해 보이지만, 데이터의 쓰임은 시간이 지나며 바뀌어. 자주 보던 데이터가 거의 안 열리는 보관 데이터가 되기도 하고, 임시로 만든 파일이 계속 남기도 해.
Microsoft는 이 지점에서 저장 서비스와 성능 계층을 워크로드에 맞추라고 말해. 낮은 지연시간이 필요한 업무에는 고성능 블록 스토리지가 맞고, 오래 보관하지만 자주 열지 않는 데이터에는 Blob Storage의 계층 관리가 더 맞을 수 있어.1
핵심은 한 번 고른 계층을 계속 두지 않는 거야. 자동 계층 이동과 수명주기 정책을 붙이면, 자주 쓰는 데이터는 빠른 곳에 두고 덜 쓰는 데이터는 더 싼 계층으로 내릴 수 있어. 클라우드에서는 “저장했다”보다 “어디에, 얼마나 오래, 어떤 성능으로 저장했나”가 비용을 가른다.
네트워크와 로그도 비용이다
네트워크는 더 헷갈려. 연결성, 성능, 복원력, 가시성을 동시에 챙겨야 하니까. 예전 방식으로 복원력을 높이면 같은 구성요소를 여러 벌 두게 되고, 그만큼 비용과 운영 복잡도가 늘어.
Microsoft가 ExpressRoute Metro, Zone Redundant NAT Gateway 같은 예를 드는 이유는 이거야. 복원력을 얻기 위해 무조건 복제하는 게 아니라, 필요한 수준의 복원력을 더 적은 복잡도로 만들 수 있는 구조를 찾아야 한다는 뜻이야.1
로그도 마찬가지야. 네트워크와 방화벽 로그는 장애 대응과 보안에 필요하지만, 모든 데이터를 다 모으고 오래 보관하면 저장 비용과 조사 비용이 같이 커져. “많이 모으면 안전하다”가 아니라, 실제 판단에 필요한 신호를 남기고 나머지는 줄이는 쪽으로 가야 해.
확인된 것과 Microsoft의 프레임
확인된 것은 Azure가 비용 최적화를 compute·storage·network의 운영 규율로 설명한다는 점이야. 이 글은 AI 워크로드 확장과 앱 현대화가 비용 효율 문제를 더 중요하게 만든다고 보고, 한 번의 마이그레이션이나 가격 결정으로 끝나는 일이 아니라고 말해.1
동시에 이 글은 Microsoft의 제품 프레임도 담고 있어. Azure VM, Blob Storage, ExpressRoute, Azure Copilot 같은 도구가 해결책으로 제시돼. 그러니 이 글을 “Azure가 가장 싸다”는 증거로 읽으면 안 돼. 더 정확한 읽기는 “클라우드 비용은 플랫폼 기능보다 운영 습관이 먼저 결정한다”에 가까워.
이 지점이 capex cycle 이야기와도 이어져. 하이퍼스케일러는 데이터센터를 짓는 데 막대한 돈을 쓰고, 고객은 그 위에서 다시 사용량 단위로 돈을 쓴다. 공급자 쪽에서는 설비투자 사이클이고, 고객 쪽에서는 설계 선택의 누적 비용이야. 같은 AI 인프라 붐이 양쪽 장부에 다른 이름으로 찍히는 셈이지.
다음에 볼 것
첫째, AI 워크로드의 단위 비용이 실제로 내려가는지 봐야 해. 모델이 커지고 사용량이 늘어도 자동 확장, 저장 계층, 로그 관리가 잘 붙으면 비용 증가 속도는 둔해질 수 있어.
둘째, FinOps가 말뿐인지 운영 방식인지 봐야 해. FinOps는 클라우드 비용을 재무팀만 보는 장부가 아니라, 엔지니어링·제품·재무가 함께 조정하는 운영 방식이라고 보면 돼. 이 단어가 실제 예산 권한, 알림, 자동화, 설계 리뷰로 내려오는지가 중요해.
셋째, Azure Copilot 같은 최적화 도구가 권고에서 실행으로 넘어가는지 봐야 해. 비용 낭비를 찾아주는 것과, 실제로 용량을 줄이고 저장 계층을 바꾸고 로그 정책을 고치는 것은 다른 일이야.
클라우드 비용의 진짜 질문은 "어느 서비스가 싸냐"보다 "낭비가 생기기 전에 설계가 그것을 잡아내느냐"에 가까워지고 있어.
댓글