이 글은 자동 번역되었습니다. 원문은 여기에서 확인하세요.
지금 Azure에서 AI 기반 앱을 구축하고 있다면, 아마 한 가지 눈치챈 게 있을 겁니다: 클라우드 청구서가 예전과 다르게 보인다는 것입니다. 단순히 높아진 게 아니라 — 이상해졌습니다. 들쭉날쭉하고, 예측하기 어렵습니다.
Microsoft가 여전히 중요한 클라우드 비용 최적화 원칙에 대한 훌륭한 글을 방금 게시했는데, 솔직히 이보다 더 좋은 타이밍은 없었을 겁니다. AI 워크로드가 비용에 관한 게임의 규칙을 바꿔놓았으니까요.
AI 워크로드가 다른 이유
핵심은 이겁니다. 전통적인 .NET 워크로드는 비교적 예측 가능합니다. App Service 티어를 알고, SQL DTU를 알고, 월별 지출을 꽤 정확하게 추정할 수 있습니다. AI 워크로드는요? 그렇지 않습니다.
어떤 모델이 맞는지 여러 모델을 테스트하고 있습니다. 파인튜닝을 위해 GPU 지원 인프라를 올리고 있습니다. 프롬프트 길이와 사용자 행동에 따라 토큰 소비가 크게 달라지는 Azure OpenAI API를 호출하고 있습니다. 모든 실험에는 실제 비용이 들고, 올바른 접근 방식을 찾기까지 수십 번을 실행해야 할 수도 있습니다.
이 예측 불가능성이 바로 비용 최적화가 중요한 이유입니다 — 나중에 생각할 것이 아니라, 첫날부터.
관리 vs. 최적화 — 차이를 알아야 합니다
기사에서 개발자들이 간과하는 것 같은 구분이 있습니다: 비용 관리와 비용 최적화에는 차이가 있다는 것입니다.
관리는 추적과 보고입니다. Azure Cost Management에서 예산을 설정하고, 알림을 받고, 대시보드를 봅니다. 이건 기본 중의 기본입니다.
최적화는 실제로 결정을 내리는 곳입니다. 정말 S3 티어가 필요한 건지, S1으로 부하를 감당할 수 있는 건지? 항상 켜져 있는 컴퓨트 인스턴스가 주말에 놀고 있지는 않은지? 학습 작업에 스팟 인스턴스를 사용할 수는 없는지?
.NET 개발자로서 우리는 코드에 집중하고 인프라 결정은 “운영팀"에 맡기는 경향이 있습니다. 하지만 Azure에 배포하고 있다면, 그 결정은 여러분의 결정이기도 합니다.
실제로 효과가 있는 것
기사와 제 개인적인 경험을 바탕으로, 실제로 차이를 만드는 것들입니다:
무엇에 얼마를 쓰고 있는지 파악하세요. 리소스에 태그를 달아주세요. 진심입니다. 어떤 프로젝트나 실험이 예산을 잡아먹고 있는지 구분할 수 없다면, 아무것도 최적화할 수 없습니다. 적절한 태깅이 된 Azure Cost Management가 가장 좋은 친구입니다.
실험하기 전에 가드레일을 설정하세요. Azure Policy를 사용해 dev/test 환경에서 비싼 SKU를 제한하세요. Azure OpenAI 배포에 지출 한도를 설정하세요. 누군가가 주말 동안 GPU 클러스터를 켜둔 채 놔뒀다는 걸 청구서가 도착하고 나서야 알게 되는 일은 없어야 합니다.
지속적으로 적정 규모를 유지하세요. 프로토타이핑 중에 선택한 그 VM? 프로덕션에는 아마 맞지 않을 겁니다. Azure Advisor가 추천을 해줍니다 — 실제로 살펴보세요. 1년에 한 번이 아니라 매달 검토하세요.
라이프사이클을 생각하세요. 개발 리소스는 종료되어야 합니다. 테스트 환경이 24시간 돌아갈 필요는 없습니다. 자동 종료 정책을 사용하세요. AI 워크로드의 경우 특히, 컴퓨트를 계속 켜두는 대신 실행당 과금되는 서버리스 옵션을 고려하세요.
비용만이 아닌 가치를 측정하세요. 이건 잊기 쉽습니다. 비용은 더 들지만 훨씬 더 나은 결과를 제공하는 모델이 올바른 선택일 수 있습니다. 목표는 가장 적게 쓰는 것이 아니라 — 똑똑하게 쓰는 것입니다.
핵심 요약
클라우드 비용 최적화는 일회성 정리가 아닙니다. 습관입니다. AI 워크로드로 인해 지출이 그 어느 때보다 예측하기 어려워진 지금, 이 습관을 일찍 들이면 나중에 고통스러운 깜짝 놀랄 일을 방지할 수 있습니다.
Azure에서 구축하는 .NET 개발자라면, 클라우드 청구서를 코드 다루듯 대하기 시작하세요 — 정기적으로 리뷰하고, 지저분해지면 리팩토링하고, 비용을 이해하지 않은 채 절대 배포하지 마세요.
