How BMW Group detects cost anomalies across 14,000 cloud accounts

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

BMW Group의 CLEA는 14,000개 이상의 클라우드 계정에서 서비스별 비용 이상을 매일 탐지하고, 다층 필터로 알림을 선별하며, 서버리스 환경에서 약 20분의 처리 시간과 월 약 50달러의 컴퓨팅 비용으로 운영된다.

📌 핵심 요약

• BMW Group이 Reply와 AWS 기반으로 구축한 FinOps 시스템 CLEA는 AWS Cost and Usage Reports를 주요 입력으로 사용하고 다른 공급자의 청구 데이터도 수집하며, 월 약 30억 행·500개 열의 데이터를 계정·서비스별 일일 비용으로 집계해 하루 지연(T-1)으로 분석한다.
• CLEA는 Meta의 오픈 소스 예측 라이브러리 Prophet으로 계정·서비스별 365일 비용 이력과 가산 계절성을 학습하고, 12개월 순환 예측과 일별 예상 비용을 생성한다. 실제 비용이 예측 신뢰구간을 벗어나면 잠재적 이상으로 분류하지만, 지속적인 비용 상승은 시간이 지나면서 새로운 기준선에 흡수될 수 있다.
• 일반 알림 기준은 예상 비용 대비 최소 40% 편차와 계정 규모별 최소 초과 비용을 함께 충족하는 것이다. 최근 3개월 평균 지출에 따른 4개 군집의 초과 비용 기준은 각각 300·500·750·1,000달러 초과이며, AWS Glue·Amazon Athena·Amazon EC2에는 60% 편차 기준을, 민감도 완화 대상 계정에는 표준 임계값의 3배를 적용한다.
• CLEA는 계정 소유자에게 예상·실제 비용, 이상 기간과 영향을 이메일로 제공하고, Amazon Quick Sight에서 작업과 사용 유형별 원인 분석을 지원한다. 비용 증가가 계획된 것인지는 계정 소유자만 판단할 수 있으므로 사용자 피드백으로 임계값을 조정한다.
• AWS Step Functions의 Distributed Map과 최대 500개 동시 AWS Lambda 실행으로 약 14,000개 계정의 일일 처리를 약 20분에 완료한다. 허용 실패는 5개 계정으로 실행별 요구 성공률은 99.96%이며, 컴퓨팅 비용은 월 약 50달러, 계정당 월 0.5센트 미만이다.

🧩 주요 포인트

1. 계정·서비스별 Prophet 기준선과 교체 가능한 예측 인터페이스 → 서로 다른 비용 패턴에 대응하면서 탐지·알림 계층을 유지할 수 있지만, 지속적인 비용 상승이 정상으로 학습되는 한계가 있다.
2. % 편차·계정 규모별 초과 비용·서비스 및 계정 예외를 결합한 필터 → 상대적 급증만으로 알림을 보내지 않고 비용 영향과 정상적인 변동성을 함께 반영한다.
3. 서버리스 일일 처리와 계정 소유자의 원인 분석·피드백 결합 → 대규모 탐지의 운영 부담을 낮추되 계획된 비용 증가인지에 대한 판단은 사람이 담당한다.

🧠 상세 정리

1. 지출 조회에서 매일 실행되는 이상 탐지로

BMW Group은 Reply와 함께 AWS 기반의 내부 FinOps 시스템 Cloud Efficiency Analytics(CLEA)를 구축해 그룹 전체의 14,000개 이상 클라우드 계정을 모니터링한다. CLEA는 처음에 Amazon Quick Sight 대시보드로 시작해 직원들이 클라우드 지출을 확인하도록 했지만, 대시보드는 누군가 열어 볼 때 이미 발생한 지출을 보여 주는 방식이었다. 이 간극을 줄이기 위해 현재는 매일 이상 탐지를 실행하고, 지출이 예상 패턴에서 벗어나면 계정 소유자에게 이메일을 보낸다. 글은 예측 기준선에서 출발해 편차를 걸러 내는 조건, 알림 엔진, 계정 소유자의 조사 방식과 서버리스 실행 구조를 차례로 설명한다. 핵심은 단순히 비용 변화를 찾아내는 데 그치지 않고, 많은 계정에서 발생하는 변화 중 소유자가 검토할 만한 대상을 선별하는 것이다.

2. 청구 데이터의 집계 단위와 분석 시차

CLEA는 AWS Cost and Usage Reports(CUR)를 주요 원천으로 삼고, BMW Group이 사용하는 다른 클라우드 공급자의 청구 내보내기 데이터도 매일 수집한다. 원시 데이터는 월 약 30억 행과 500개 열 규모이며, 공급자별 데이터를 계정·서비스별 일일 비용이라는 일관된 단위로 집계한다. 데이터에는 하루의 지연(T-1)이 있어 어제의 지출을 오늘 분석하고 알림을 보내며, 하루치 데이터가 불완전하게 들어오는 문제를 피하기 위해 AWS CUR 전달 완료를 확인한 뒤 파이프라인을 실행한다. 한 계정이 Amazon EC2, Amazon S3, AWS Lambda, Amazon RDS를 사용하면 4개의 비용 시계열이 생기고, 15개 서비스를 사용하면 15개의 시계열이 생겨 전체적으로 수십만 개의 계정·서비스 조합을 평가해야 한다. 예상 지출은 365일 이력에 기반한 특정 계정·서비스의 하루 예측 비용이고, 실제 지출은 같은 날의 청구 비용이며, 영향액은 실제 지출에서 예상 지출을 뺀 값으로 양수이면 예측 대비 초과 지출을 뜻한다.

3. Prophet 예측과 교체 가능한 실행 구조

CLEA는 단순성과 비용 시계열에서의 안정적인 성능을 이유로 Meta의 오픈 소스 예측 라이브러리 Prophet을 선택했다. 모델은 각 계정·서비스 조합의 일별 비용 이력 365일을 가산 계절성으로 학습하고, 12개월 순환 예측과 이상 탐지 기준선으로 사용할 일별 예측값을 생성한다. AWS Step Functions가 일일 실행을 조율하며, 준비 단계의 AWS Lambda 함수가 활성 계정을 찾아 목록을 JSON 형식으로 Amazon S3에 기록한다. 이후 Distributed Map이 최대 500개의 Lambda 함수를 동시에 실행하고, 각 함수가 한 계정의 서비스들을 예측해 전체 약 14,000개 계정을 약 20분 안에 처리한다. 예측 모듈의 입력은 계정·서비스별 일일 비용, 출력은 신뢰구간을 포함한 일별 예측값으로 정의되어 있어, 이 인터페이스를 유지하면 탐지와 알림 계층을 수정하지 않고 예측 엔진을 교체할 수 있다.

4. 개별 기준선의 장점과 지속 상승 탐지의 한계

일일 지출이 정해진 금액을 넘으면 알림을 보내는 고정 규칙은 계정이 성장하거나 새 서비스를 도입하고 의도적으로 작업량을 늘리는 상황을 이상으로 해석할 수 있다. 큰 계정에 맞춰 임계값을 높이면 작은 계정의 변화를 놓치기 때문에, CLEA는 중앙에서 정한 금액 하나 대신 각 계정·서비스가 실제로 보여 온 지출 추세를 학습한다. 매일 실제 비용과 예상 비용의 차이를 계산하고, 실제 비용이 Prophet의 신뢰구간을 벗어나면 잠재적 이상으로 표시한다. 모델의 불확실성이 커질수록 신뢰구간도 넓어져 계정·서비스별 특성에 따라 판정 범위가 달라지며, 이 단계에서 일상적인 비용 변동의 상당 부분이 제외된다. 다만 추세에 적응하는 모델은 지속적인 지출 상승도 결국 받아들이므로, 비용이 한 단계 높아진 뒤 유지되면 초기 며칠만 표시되고 학습 구간이 변화를 반영하면서 새 예상 수준으로 자리 잡을 수 있어 이러한 탐지는 급증에 가장 강하다.

5. 금액·편차·운영 특성을 결합한 알림 필터

탐지 전에 최근 3일 평균 지출이 0.10달러 미만인 서비스, 이력이 10일 미만인 서비스, 예측에 관련 없는 특정 청구 항목과 요금 유형을 제외하며, 이상으로 표시된 날에도 예상 지출 대비 최소 40% 편차를 요구한다. 평소 0.10달러를 쓰던 서비스가 1.00달러를 쓰면 900% 증가이지만 초과 금액은 작으므로, 상대적 편차와 계정 규모에 맞는 최소 영향액을 함께 적용한다. 최근 3개월 평균 지출에 따라 10만 달러 미만 계정은 300달러 초과, 10만~25만 달러는 500달러 초과, 25만~50만 달러는 750달러 초과, 50만 달러 초과 계정은 1,000달러 초과의 영향액을 요구한다. 정상적인 작업에서도 일별 비용 변동이 큰 AWS Glue, Amazon Athena, Amazon EC2는 일반 40% 기준에서 오탐이 많아 편차 기준을 60%로 높였다. 알려진 변동성 때문에 알림 축소를 요청한 팀의 계정은 민감도 완화 목록에 두고 표준 임계값의 3배를 넘어야 알림을 보낸다. 이처럼 공통 기준에 서비스·계정별 예외를 더해 Prophet이 표시한 넓은 이상 후보 집합을 실제 통지 대상으로 좁힌다.

6. 사람의 판단, 기간 묶음과 알림 전달

CLEA는 작업, 사용 유형과 비용을 볼 수 있지만 새 작업 배포나 마이그레이션에 따른 계획된 증가인지는 알 수 없으므로, 계정 소유자의 판단을 대신하지 않고 애플리케이션 버튼과 이메일의 피드백 요청을 통해 임계값을 조정한다. 연속해서 이상으로 표시된 날은 하나의 기간으로 묶으며, Prophet이 실행 사이에 특정 날짜를 재분류할 때 기간이 쪼개지지 않도록 최신 실행만이 아니라 모든 과거 모델 스냅샷을 참조한다. 탐지 후 별도 프로세스로 실행되는 알림 엔진은 당일 활성 이상을 조회하고 탐지 날짜를 현재 날짜와 대조해 중복 통지를 제거하며, 최근 4일 이내 시작된 이상은 알리고 더 오래된 이상은 계속 진행 중인 경우에만 알린다. 이메일에는 계정 ID와 이름, 소유자와 부서 계층, 영향받은 서비스, 이상 기간과 지속 일수, 예상·실제 지출, 절대 영향액과 편차율, 해당 계정에서 동시에 발생한 모든 이상의 누적 영향액을 제공하고 전체 표를 Excel 파일로 첨부한다. 예시 이메일의 Amazon EC2 이상은 하루 동안 예상 809.30달러에 실제 2,584.43달러가 발생해 초과 비용이 1,775.13달러, 편차가 219.34%였으며, 오탐 가능성을 알리고 상세 내역 검토와 피드백을 요청한다.

7. 계정 소유자가 직접 수행하는 원인 분석

알림을 받은 소유자는 플랫폼 팀을 거치지 않고 Amazon Quick Sight의 CLEA 이상 대시보드에서 이메일과 같은 항목을 확인하며 조사할 수 있다. 필터 범위를 넓히면 알림 대상으로 선별되지 않은 이상도 볼 수 있어 임계값 근처의 사례를 검토할 수 있다. 특정 이상을 선택하면 실제 일별 비용을 작업과 사용 유형으로 나눈 두 막대 차트가 열리고, 상세 표에는 EUC1-InstanceUsage:db.r6g.large 같은 사용 유형과 달러 기준 비용, 사용량이 표시된다. 작성자들은 과거 사례 검토에서 작업과 사용 유형을 함께 살펴보는 것이 원인의 대다수를 설명했다고 밝히며, 이 때문에 두 차원을 상세 분석의 앞부분에 배치했다. 예시 차트는 2026년 5월 초부터 6월 중순까지의 비용을 보여 주며, RunInstances가 지배적인 가운데 평소 약 900달러 수준에서 하루 약 2,600달러로 오른 비용이 거의 전부 EUC1-BoxUsage:g6.48xlarge에서 발생해 급증을 일으킨 인스턴스 유형을 식별한다.

8. 서버리스 운영 규모와 제공 원문의 범위

일일 파이프라인은 AWS Step Functions의 Distributed Map 모드에서 최대 동시 실행 수를 500으로 설정해 동작한다. 약 14,000개 계정 중 허용되는 실패는 5개 계정으로 설정되어 있으며, 원문은 이에 필요한 실행별 성공률을 99.96%로 제시한다. 전체 주기는 약 20분에 끝나고 컴퓨팅 비용은 월 약 50달러로, 계정당 월 0.5센트 미만이라고 설명한다. 모든 구성 요소가 서버리스이므로 실행 사이에 유휴 인프라 비용을 지불하지 않는다는 점이 이 운영 구조의 비용상 이점이다. 이 수치는 컴퓨팅 비용으로 명시되어 있어 전체 시스템의 모든 비용을 합친 수치로 확대해 해석해서는 안 된다. 제공된 원문은 그림 4의 세 영역을 소개하면서 CLEA 공급자 계정과 dbt를 언급하는 도중 끊기므로, 이후의 상세 데이터 흐름이나 후속 계획은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 상대적 편차와 절대 영향액을 함께 적용하는 CLEA의 방식은 증가율이 커도 금액은 작은 사례를 걸러 내며, 계정 규모와 운영 특성에 따라 알림 민감도를 달리할 필요성을 보여 준다.
• Prophet의 적응성은 개별 비용 패턴을 반영하는 장점이지만, 지속적인 비용 상승을 새로운 정상으로 받아들일 수 있다는 한계와 연결된다.
• 자동 탐지는 비용 변화의 발견과 원인 조사를 지원하지만 지출 의도까지 설명하지는 못하므로, 계정 소유자의 판단과 피드백이 시스템 운영의 지속적인 구성 요소가 된다.

✅ 액션 아이템

• CLEA의 이상 알림을 검토할 때 40% 편차, 계정 규모별 초과 비용 기준, 서비스·계정별 예외의 적용 여부를 함께 확인한다.
• Amazon Quick Sight에서 작업과 사용 유형별 비용을 살펴 원인을 분석하고, 계정 소유자가 계획된 비용 증가인지 판단해 피드백을 제공한다.
• Prophet의 지속적인 비용 상승 흡수 가능성을 고려해 급증 탐지 결과의 해석 범위를 검토한다.

❓ 열린 질문

• Prophet이 지속적인 비용 상승을 새로운 기준선에 흡수할 때, CLEA의 탐지 결과를 어떻게 해석해야 하는가?
• 40% 기본 편차와 AWS Glue·Amazon Athena·Amazon EC2의 60% 편차 기준은 사용자 피드백에 따라 어떻게 조정되는가?
• 약 14,000개 계정의 일일 처리에서 허용 실패 5개 계정을 넘으면 어떻게 대응하는가?