AI 기반 스케일링 vs. 규칙 기반 스케일링, 비용 절감에 더 효과적인 선택은?

Author: Thomas Mathew (opens in a new tab) Date: December 30, 2025

TL;DR: 규칙 기반 자동 확장(HPA/KEDA)은 소수의 서비스에서는 잘 작동하지만, 규모가 커지면 관리가 어려워집니다. 200개의 디플로이먼트는 200개의 설정을 의미하며 이를 지속적으로 조정하고 유지해야 합니다. 애플리케이션이 진화하면서 고정 임계값은 점점 현실과 멀어지고, 결과적으로 클러스터의 99%가 과도하게 프로비저닝되면서도 평균 사용률은 13%에 불과합니다. AI 기반 스케일링은 워크로드 패턴을 자동으로 학습하고, 드리프트를 감지하며, 서비스 간 최적화를 수행하여 수동 임계값 조정을 제거합니다.

핵심 요약

• 규칙 기반 스케일링은 초기에는 잘 작동하지만, 규모가 커질수록 임계값을 계속 관리하는 것 자체가 큰 운영 부담이 된다
• 대부분의 Kubernetes 클러스터는 임계값이 방치되며 과도하게 리소스를 할당한 상태로 유지된다
• KEDA와 같은 이벤트 기반 도구는 지표의 종류를 확장하지만, 여전히 고정 임계값에 의존한다
• AI 기반 스케일링은 설정 부담을 제거하고 실제 동작 데이터를 기반으로 지속적으로 적응한다
• Wave Autoscale은 예측 스케일링, SmartSizing, drift 감지, 서비스 간 최적화를 제공한다

모든 플랫폼 팀이 마주하는 스케일링의 딜레마

Kubernetes 자동 확장을 설정한 경험은 대부분 비슷합니다. CPU 사용률 70%에서 HPA가 작동하고, 파드가 부족하면 노드가 확장됩니다. 처음에는 잘 작동합니다.

하지만 서비스가 하나 둘 늘어나기 시작하면 상황이 달라집니다. 이제 50개 이상의 디플로이먼트를 관리하게 됩니다.

• API 게이트웨이는 CPU 중심
• 이미지 처리 서비스는 메모리 중심
• 큐 워커는 예측하기 어려운 스파이크 발생

각 워크로드마다 서로 다른 임계값, 안정화 구간, 스케일링 정책이 필요합니다. 그리고 이 설정들은 시간이 지나며 계속 조정되고 다시 조정되어야 합니다.

산업 전반의 수치는 이 문제를 분명히 보여줍니다.

Kubernetes 클러스터의 99.94%는 CPU를 과도하게 할당하고 있지만 (opens in a new tab), 평균 사용률은 13%에 불과합니다 (opens in a new tab).

문제의 핵심은 규칙 기반 스케일링이 잘못된 방식이어서가 아닙니다. 서비스 규모가 커질수록 이를 계속 유지하고 관리하는 일이 현실적으로 어려워지기 때문입니다.

이 글에서는 규칙 기반 스케일링이 확장 단계에서 어떤 한계에 부딪히는지, KEDA가 보완할 수 있는 영역과 그렇지 못한 영역은 무엇인지, 그리고 AI 기반 스케일링이 어떻게 운영 부담을 근본적으로 줄이는지를 살펴봅니다.

규칙 기반 스케일링은 어떻게 작동하며, 왜 확장되지 않는가

규칙 기반 스케일링

규칙 기반 스케일링은 매우 단순한 구조를 가집니다.

📊 지표 수집 → 📏 임계값 비교 → ⬆️ 확장 또는 ⬇️ 축소

단일 워크로드에서는 충분히 잘 작동합니다. 하지만 실제 환경에서 단일 워크로드만 운영하는 조직은 거의 없습니다.

규칙 기반 스케일링의 핵심 문제

문제 1. 설정의 폭발적 증가

모든 워크로드는 특성이 다릅니다.

• API 게이트웨이는 CPU 사용량 중심
• 이미지 처리 서비스는 메모리 사용량 중심
• 큐 워커는 입출력 스파이크 중심

각각에 맞는 HPA 설정이 필요하며, 이는 다음을 의미합니다.

• 디플로이먼트 200개
• 임계값 설정 200개
• 지속적인 프로파일링과 테스트
• 동작 변경 시마다 재조정

모든 워크로드의 맥락을 완벽히 이해하는 엔지니어링 팀은 존재하지 않습니다. 결국 대부분의 조직은 안전을 이유로 보수적인 고정 임계값을 선택하게 되고, 효율은 희생됩니다.

CNCF는 Kubernetes 비용 초과의 70%가 과도한 리소스 할당에서 발생한다고 분석했습니다. (opens in a new tab)

문제 2. 워크로드는 변하지만 임계값은 변하지 않는다

애플리케이션은 지속적으로 변화합니다.

새로운 기능이 추가되면서 메모리를 많이 사용하는 로직이 생기고, 데이터베이스 마이그레이션으로 쿼리 패턴이 달라지며, 의존성 업그레이드 하나로 CPU 사용 양상도 바뀝니다.

하지만 한 번 맞춰둔 임계값은 그대로입니다. 언제부터 잘못됐는지 알 수 없고, 사용자 불만이 터지거나 비용이 급증한 뒤에야 문제를 인식하게 됩니다.

그 결과, 피드백은 항상 뒤늦게 돌아옵니다.

플랫폼 팀은 선택을 강요받습니다.

• 끝없는 HPA 유지 관리에 시간을 쓰거나
• 대부분의 설정이 오래된 상태임을 감수하거나

Google SRE 원칙에서는 수동 운영 작업이 엔지니어링 시간의 절반을 넘지 않도록 권장합니다. (opens in a new tab) 그러나 수백 개의 디플로이먼트를 운영하는 환경에서는 자동 확장 설정만으로도 상당한 시간을 소모하게 됩니다.

문제 3. KEDA는 지표를 확장하지만 운영 문제는 해결하지 못한다

KEDA (opens in a new tab) (Kubernetes Event-Driven Autoscaling)는 이벤트 기반 지표를 확장합니다.

• 큐 길이
• 요청 수
• 데이터베이스 연결 수
• Prometheus 지표

KEDA는 외부 지표를 통해 HPA를 확장하지만, 스케일링 결정은 여전히 각 ScaledObject에 정의된 고정 임계값에 의해 이루어집니다.

이는 CPU 사용률보다 훨씬 의미 있는 신호일 수 있습니다. 예를 들어 API 앞단의 NGINX에서는 CPU 기준 스케일링이 항상 늦게 반응합니다. 요청이 이미 쌓인 뒤에야 확장이 일어나기 때문입니다.

KEDA의 Prometheus 스케일러 (opens in a new tab)를 사용하면 요청 수나 활성 연결 수를 기준으로 더 빠르게 반응할 수 있습니다. 하지만 근본적인 문제는 여전히 남아 있습니다.

AI 기반 스케일링이 규칙과 KEDA의 한계를 해결하는 방식

AI 기반 스케일링은 다음 흐름으로 작동합니다.

📈 과거 데이터 → 🧠 성능 모델 → ⚡ 실제 동작 기반 스케일링

KEDA는 더 나은 지표를 제공합니다. AI 기반 스케일링은 남아 있는 핵심 문제를 직접 해결합니다.

AI가 해결하는 문제 1. 임계값 선택

규칙 기반 방식은 사람이 숫자를 정해야 합니다. CPU 70%인가, 80%인가 등..

이 숫자들은 현실을 정확히 반영하지 못하는 경우가 대부분입니다.

머신러닝 기반 스케일링은

• 실제 워크로드 패턴을 관찰하고
• 정상과 비정상을 학습하며
• 최적의 확장 지점을 자동으로 도출합니다

Wave Autoscale의 Autopilot은 디플로이먼트 단위로 활성화할 수 있으며, 관측된 동작을 기반으로 최적의 스케일링 포인트를 스스로 학습합니다.

AI가 해결하는 문제 2. 수백 개 설정 유지 관리

200개의 디플로이먼트는 200개의 설정을 의미합니다. 대부분의 팀은 동일한 기본값을 적용하는 방식으로 타협합니다.

Wave Autoscale은 설치 즉시 모든 디플로이먼트를 자동으로 탐지하고 학습을 시작합니다. 워크로드별 설정은 필요하지 않습니다. 충분한 데이터가 쌓이면 Autopilot을 활성화하여 일부 워크로드부터 점진적으로 확장할 수 있습니다.

AI가 해결하는 문제 3. 임계값 드리프트

애플리케이션은 계속 변하지만 임계값은 스스로 갱신되지 않습니다.

머신러닝 모델은 정상 상태의 기준을 지속적으로 재학습합니다. 동작이 바뀌면 기준도 함께 업데이트됩니다.

Wave Autoscale이 제공하는 기능은 다음과 같습니다.

• SmartSizing을 통한 CPU와 메모리 요청량 자동 조정
• 메모리 누수 탐지를 통한 이상 조기 감지
• 클러스터 리소스 예측으로 7일에서 30일 단위 트렌드 분석

재조정 작업은 필요하지 않습니다.

AI가 해결하는 문제 4. 서비스 간 연계 최적화

규칙 기반 스케일링은 워크로드를 개별적으로 다룹니다. 하지만 실제로는 프론트엔드, API 게이트웨이, 백엔드 데이터베이스는 서로 강하게 연결되어 있습니다.

AI 모델은 이러한 상관관계를 학습합니다. 예를 들어 인그레스의 네트워크 트래픽 증가는 몇 초 뒤 하위 서비스의 CPU 부하를 예측할 수 있습니다.

Wave Autoscale의 Autopilot Scheduler를 사용하면 이벤트 단위로 여러 워크로드의 스케일링을 함께 제어할 수 있습니다.

예를 들어

• 제품 출시일 오전 9시
• 마케팅 메일 발송 시간 오전 9시 45분
• 동시에 부하가 예상되는 서비스 프론트엔드, API, 결제, 사용자 데이터베이스

수동으로 전날 확장할 필요 없이 Autopilot이 사전에 리소스를 준비하고, 실제 트래픽에 맞춰 조정한 뒤 자동으로 축소합니다.

AI 기반 스케일링으로의 전환

간단한 설치

Wave Autoscale은 하나의 Helm 차트로 실행됩니다.

• 노드 에이전트 없음
• 사이드카 없음
• 복잡한 리소스 정의 없음

설치 즉시 자동 탐지가 시작됩니다.

위험 없는 검증

Simulation 모드는 안심하고 도입할 수 있게 해주는 핵심 기능입니다.

• ✅ 실제 운영 데이터 기반의 전체 머신러닝 분석 수행
• ✅ 모든 스케일링 결정에 대해 근거와 함께 기록
• ✅ 사용자가 준비되기 전까지 클러스터 변경 없음
• ✅ AI 스케일링 추천 결과와 기존 HPA 동작 비교 가능

왜 AI 기반 스케일링은 선택이 아니라 필수가 되는가

규칙 기반 스케일링은 단순한 시대에 만들어졌습니다. 예측 가능한 워크로드에서는 충분히 합리적이었습니다.

하지만 지금은 다릅니다.

• 작은 효율 차이가 큰 비용 차이를 만들고
• 짧은 성능 저하도 사용자 이탈로 이어지며
• 유휴 파드는 그대로 비용이 됩니다

클라우드 비용을 효과적으로 관리하는 조직은 더 나은 임계값을 찾는 것이 아니라, 사람이 볼 수 없는 패턴을 기계에게 맡기고 있습니다.

Wave Autoscale은 머신러닝 기반 최적화를 통해 스케일링 반응 속도를 높이고 최대 40%의 비용 절감을 제공합니다. Autopilot 기능은 예측 기반 스케일링과 지능형 리소스 조정, 우선순위를 고려한 트래픽 제어를 통해 플랫폼 팀의 통제력을 유지하면서 운영 효율을 극대화합니다.