AWS 비용 예상 버그 사태, 24억 달러 청구서가 남긴 클라우드 비용 관리

Table of Contents

안녕하세요! 성징어의 IT 잉크사이트(IT Ink-Sight) 성징어입니다.

지난달 0.11센트, 그러니까 한화로 70원 남짓을 썼던 한 개발자가 이번 달 24억 9000만 달러, 우리 돈으로 약 3조 4000억 원에 달하는 청구서를 받았습니다. 레딧 AWS 커뮤니티에 이 화면 캡처가 올라오자 순식간에 화제가 됐고, 비슷한 사례를 공유하는 글이 잇따랐습니다. 수백만 달러부터 수십억 달러까지, 평소와 전혀 다른 숫자가 찍힌 예상 청구액 화면을 본 이용자들은 당연히 패닉에 빠졌습니다. 이번 AWS 비용 예상 버그는 실제 과금으로 이어지지는 않았지만, 클라우드에 인프라를 맡긴 조직이라면 한 번쯤 짚고 넘어가야 할 질문을 남겼습니다. 우리는 우리가 쓰는 클라우드의 비용 데이터를 정말로 신뢰할 수 있는가 하는 질문입니다.

무슨 일이 있었나 — 사건의 타임라인

아마존웹서비스는 지난 7월 18일(현지시간) 서비스 상태 페이지를 통해 빌링 및 비용 관리 콘솔과 비용·사용량 보고서(CUR)에서 잘못된 예상 비용 및 사용량 데이터가 표시되는 문제가 발생했다고 공식적으로 밝혔습니다. 장애가 실제로 발생한 구간은 미국 서부 시간 기준 16일 오후 7시 38분부터 17일 오전 6시까지였고, 한국 시간으로 환산하면 17일 오전 11시 38분부터 같은 날 오후 10시까지에 해당합니다.

이 시간 동안 고객들은 실제보다 과도하게 부풀려진 예상 비용을 확인했을 뿐 아니라, AWS 예산(AWS Budget)과 비용 이상 탐지(Cost Anomaly Detection) 기능이 자동으로 예산 초과·이상 비용 경고까지 발송했습니다. 문제는 이 경고가 실제 위험 신호와 구분되지 않았다는 점입니다. 평소 월 몇십 원 수준의 서비스를 쓰던 개인 개발자부터 규모 있는 기업 계정까지, 아무런 사전 예고 없이 감당할 수 없는 규모의 청구 경고를 받은 셈입니다. 이번 AWS 비용 예상 버그가 유독 크게 회자된 이유도 여기에 있습니다. 서비스가 완전히 멈춘 장애가 아니라, 신뢰해야 할 숫자 자체가 흔들린 사건이었기 때문입니다.

AWS는 대다수 계정이 미국 서부시간 기준 18일 오전 6시, 한국시간 기준 18일 오후 10시까지 정상 상태로 복구됐다고 밝혔습니다. 다만 일부 소수 계정은 이후에도 후속 처리가 진행됐고, 관련 안내는 개인 상태 대시보드인 Personal Health Dashboard를 통해 개별 제공됐습니다. 하루하고도 반나절에 걸쳐 잘못된 숫자가 노출됐다는 점을 감안하면, 그 시간 동안 예산을 검토하거나 의사결정을 내려야 했던 담당자들이 얼마나 혼란스러웠을지 짐작할 수 있습니다.

원인은 단위 변환 로직의 설정 오류

AWS가 밝힌 원인은 비교적 단순합니다. 서비스별 요금을 계산할 때 활용하는 단위 변환(Unit Conversion) 데이터가 있는데, 관련 구성을 변경하는 과정에서 데이터 업데이트가 실패했고, 그 여파로 일부 비용 항목이 비정상적으로 부풀려졌다는 설명입니다. 실제 고객 청구서와 과금 내역에는 영향을 주지 않았고, 잘못된 데이터는 비용 분석 도구와 청구 콘솔 화면에만 반영됐다고 AWS는 강조했습니다.

여기서 제가 더 눈여겨보는 대목은 따로 있습니다. AWS 비용 예상 버그가 확산된 결정적인 이유는 원인 그 자체보다, 문제를 감지하고도 곧바로 대응하지 못한 내부 프로세스에 있습니다. AWS는 내부 경보 시스템이 비용 이상 현상을 감지했음에도 예상 청구 생성 프로세스를 자동으로 중단하거나 엔지니어링 조직에 즉시 경고를 전달하지 못했다고 인정했습니다. 결국 고객 문의가 먼저 접수된 뒤에야 엔지니어들이 문제를 인지하고 조사에 착수하는 순서로 흘러갔습니다. 이상 신호를 시스템이 스스로 잡아냈는데도 사람이 신고할 때까지 방치됐다는 점은, 아무리 정교한 모니터링 체계를 갖춘 빅테크라 해도 마지막 단계의 자동 차단 로직이 빠지면 무용지물이 될 수 있다는 걸 보여줍니다.

실제 청구는 멀쩡했다는데, 무엇이 문제였나

AWS는 이번 사고를 “실제 청구서에는 영향이 없었다”는 말로 정리하고 싶어 하지만, 저는 이 표현이 문제의 절반만 설명한다고 생각합니다. 클라우드 비용 관리 담당자, 특히 스타트업이나 중소 조직의 실무자에게 예산 초과 경고는 단순한 참고 정보가 아닙니다. 다음 달 지출 계획을 다시 짜야 할지, 당장 워크로드를 줄여야 할지를 판단하는 근거 자료입니다. 그런데 그 근거 자료 자체가 며칠 사이에 신뢰할 수 없는 숫자로 뒤바뀌었다면, 실제 손해가 발생하지 않았다 해도 조직의 의사결정 프로세스는 이미 흔들린 뒤입니다.

레딧 커뮤니티에는 사용하지 않은 서비스 비용까지 잡힌 것처럼 보였다는 주장도 여럿 올라왔습니다. 이런 사례들이 개별 화면에 표시된 금액이 실제 청구서로 확정됐다는 뜻은 아니지만, 이용자 입장에서는 화면에 뜬 숫자와 실제 청구액이 다르다는 사실을 나중에야 알게 됩니다. 그 사이의 불안과 혼란은 고스란히 이용자 몫으로 남습니다. 저는 이 지점이 이번 사건에서 가장 곱씹어봐야 할 부분이라고 봅니다. 클라우드 서비스의 신뢰는 가동률 숫자만으로 완성되지 않습니다. 비용 데이터의 정확성도 가용성 못지않게 핵심적인 신뢰 요소입니다.

여기서 놓치기 쉬운 비용도 있습니다. 바로 신뢰 훼손에 따르는 눈에 보이지 않는 비용입니다. 예산 담당자가 한 번 클라우드 콘솔의 숫자를 의심하기 시작하면, 그다음부터는 정상적인 이상 탐지 경고까지도 곧이곧대로 믿지 못하게 됩니다. 이른바 “경고 피로”라 부를 만한 현상인데, 진짜 위험 신호가 왔을 때도 “또 오류겠지”라며 넘겨버릴 위험이 커진다는 뜻입니다. 저는 이런 심리적 여파가 단기적인 해프닝보다 훨씬 오래 남는다고 봅니다. 청구 시스템에 대한 신뢰는 한 번 깨지면 복구까지 상당한 시간이 걸리는 자산이기 때문입니다.

개인 실수로 인한 요금 폭탄과는 결이 다른 사건

사실 AWS 이용자 커뮤니티에는 예상치 못한 고액 청구, 이른바 “요금 폭탄” 후기가 꾸준히 올라옵니다. 개발 블로그를 살펴보면 EC2 인스턴스를 종료하지 않고 방치해 300만 원가량이 청구된 사례, 액세스 키가 노출돼 공격자가 코인 채굴에 서버를 도용하면서 2억 원 넘는 금액이 부과된 사례, MFA(다단계 인증)를 설정하지 않은 계정이 탈취돼 감당하기 힘든 요금이 찍힌 사례까지 다양합니다. 이런 경우 대부분은 이용자 쪽의 설정 실수나 보안 관리 소홀이 원인이고, AWS에 문의하면 상황에 따라 감면이나 환불을 받을 수 있는 것으로 알려져 있습니다.

하지만 이번 AWS 비용 예상 버그는 이런 사례들과 근본적으로 다릅니다. 이용자가 무언가를 잘못 설정하거나 계정 보안을 소홀히 해서 벌어진 일이 아니라, AWS 내부의 청구 계산 시스템 자체가 오작동한 사건입니다. 이용자 입장에서는 아무리 계정 보안을 철저히 관리하고 자원을 꼼꼼히 정리해도 막을 방법이 없었다는 뜻입니다. 저는 이 차이가 이번 사고를 이전의 개별 요금 폭탄 사례들과 구분해서 봐야 하는 핵심 이유라고 생각합니다. 예방 가능한 이용자 과실과, 예방이 원천적으로 불가능한 벤더 측 시스템 결함은 조직이 대응해야 할 방식 자체가 다르기 때문입니다.

반복되는 대형 클라우드 사고, 우연이 아니다

이번 사건을 단발성 해프닝으로 넘기기 어려운 이유가 있습니다. 지난 2025년 10월 20일, 미국 버지니아 북부의 AWS US-EAST-1 리전에서 DynamoDB API 엔드포인트의 DNS 해결 문제로 대규모 장애가 발생했습니다. 스냅챗, 포트나이트, 코인베이스, 로빈후드, 퍼플렉시티를 비롯한 수십여 개 서비스가 몇 시간 동안 접속 불능 상태에 빠졌고, 인터넷 성능 모니터링 기업 캐치포인트는 이 장애로 인한 경제적 피해 규모가 수십억 달러에 달할 것으로 추정했습니다.

같은 해 11월 18일과 12월 5일에는 클라우드플레어에서도 연달아 장애가 발생했습니다. 11월 장애는 위협 트래픽을 관리하는 자동 생성 파일이 예상치 못한 크기로 폭증하면서 시스템 한계를 넘긴 게 원인이었고, 챗GPT와 X, 리그 오브 레전드 등 주요 서비스가 약 4시간 동안 마비됐습니다. 12월 장애는 웹 애플리케이션 방화벽 설정 변경 과정에서 발생해 16분 만에 복구됐지만, 국내 서비스인 배달의민족까지 영향을 받았습니다. 세 사건 모두 공통점이 있습니다. 외부 공격이 아니라 내부 설정 변경이나 자동화 로직의 결함이 원인이었다는 점입니다. 이번 사고도 같은 계열입니다. 서비스 가용성이 아니라 청구 시스템이라는 다른 영역에서 터졌을 뿐, 대형 클라우드 사업자의 내부 자동화가 예상치 못한 방식으로 어긋났을 때 벌어지는 파급력이라는 본질은 동일합니다.

2025년부터 반복된 대형 클라우드 사업자 장애 사례를 보여주는 타임라인 일러스트

구글 클라우드도 예외는 아니었다

세 번째로 짚고 싶은 사례는 구글 클라우드입니다. 2025년 6월 12일, 구글 클라우드는 서비스 컨트롤 정책을 변경하는 과정에서 정책 데이터에 의도치 않은 빈 필드가 삽입되는 오류가 발생했고, 이 여파로 시스템이 반복적으로 다운되면서 복구까지 최대 3시간이 걸렸습니다. 스포티파이, 디스코드를 포함한 다수의 인기 서비스가 이 장애로 접속 불가 상태를 겪었습니다. 구글 클라우드는 이후 API 관리 플랫폼의 오류 데이터가 장애로 번지지 않도록 차단 장치를 두고, 메타데이터가 전역으로 전파될 때 보호 장치를 강화하는 등 재발 방지 조치를 발표했습니다.

제가 이 사례를 함께 언급하는 이유는 간단합니다. AWS, 클라우드플레어, 구글 클라우드까지 세계 최상위권 클라우드 사업자들이 최근 1년 사이 나란히 내부 설정 변경 과정에서 비롯된 대형 장애를 겪었다는 사실은, 이런 사고가 특정 기업의 기술력 문제가 아니라 클라우드 인프라 자체가 안고 있는 구조적 리스크에 가깝다는 걸 보여줍니다. 이번 사고 역시 이 구조적 리스크 목록에 새로 추가된 사례로 봐야 합니다. 규모가 크고 자동화 수준이 높을수록, 작은 설정 변경 하나가 걷잡을 수 없이 커질 잠재력도 함께 커진다는 역설입니다.

세 사업자의 대응 방식을 비교해보면 공통된 패턴이 하나 보입니다. 사고가 벌어진 뒤에야 감시 체계의 빈틈을 메우는 사후 대응이라는 점입니다. 구글 클라우드는 API 관리 플랫폼의 오류 데이터 전파를 막는 차단 장치를, AWS는 예상 청구 계산의 자동 중단 로직을 각각 사고 이후에야 도입했습니다. 사전에 이런 안전장치를 갖췄더라면 피해 규모가 훨씬 작았을 사고들인 셈입니다. 저는 이 패턴을 볼 때마다, 클라우드 사업자의 기술력을 의심하기보다는 초대형 시스템일수록 예상하지 못한 실패 지점이 끝없이 새로 생겨난다는 현실을 받아들이는 편이 낫다고 생각합니다.

공공기관 클라우드 전환이 마주할 위험

저는 이번 사건을 보면서 공공기관 클라우드 전환 사업을 진행 중이거나 검토 중인 담당자들이 특히 눈여겨봐야 할 대목이 있다고 생각합니다. 국내 공공기관은 디지털서비스 이용계약 가이드라인에 따라 종량제, 정액제, 예치제 중 하나를 골라 민간 클라우드 이용료를 편성합니다. 종량제는 이용량 단위별로 단가를 적용해 지급하는 방식이라, 만약 이번처럼 비용 산정 시스템 자체에 오류가 생기면 실제 정산 시점에 예상치 못한 금액 분쟁으로 번질 여지가 있습니다.

저는 실제 제안서 작업을 할 때, 발주기관이 클라우드 비용 관련 리스크를 얼마나 구체적으로 인식하고 있는지가 사업 범위 협의 단계에서 종종 드러난다고 느낍니다. 가용성 SLA는 대부분의 발주기관이 익숙하게 다루지만, 비용 데이터의 정확성이라는 개념 자체를 생소하게 여기는 경우가 많습니다. 이런 상황에서 컨설턴트가 먼저 이슈를 짚어주지 않으면, 실제 운영 단계에 들어가서야 문제를 인지하게 되고 그때는 이미 계약 조건을 바꾸기 어려운 시점일 가능성이 큽니다.

특히 여러 시스템을 순차적으로 클라우드로 전환하는 대형 사업일수록 비용 데이터의 신뢰성이 더 중요해집니다. 시스템별로 예산이 쪼개져 있고 각각 다른 사업자가 운영을 맡는 구조라면, 비용 이상 신호 하나가 잘못 해석됐을 때 여러 부서가 동시에 혼란을 겪을 수 있습니다. 저는 이런 대형 전환 사업의 과업지시서를 검토할 때, 비용 모니터링 요건을 시스템 단위가 아니라 사업 전체 단위로 통합해서 관리하는 체계까지 요구하시길 권합니다. 개별 시스템 담당자가 각자 다른 방식으로 비용 이상 신호에 대응하면, 정작 사업 전체의 예산 흐름을 파악해야 하는 상급 관리자는 오히려 더 큰 혼란을 겪게 되기 때문입니다.

공공기관 예산은 회계연도 단위로 확정되고, 예산 편성 담당자는 정보화사업 낙찰차액 등 제한된 재원 안에서 부족분을 메워야 하는 구조입니다. 이런 환경에서 클라우드 비용 데이터를 신뢰할 수 없다면, 담당자는 실제 지출 여력과 무관하게 과도한 예비비를 확보해두거나, 반대로 이상 신호를 무시하다가 실제 예산 초과 상황에서야 뒤늦게 대응하는 두 갈래 중 하나를 택하게 됩니다. 둘 다 바람직한 결과는 아닙니다. 저는 이번 AWS 비용 예상 버그 사례를 공공 클라우드 사업 제안서에 비용 모니터링 요건을 구체적으로 명시해야 하는 근거로 활용할 수 있다고 봅니다. 단순히 “비용 대시보드를 제공한다”는 문구만으로는 부족하고, 비용 모니터링 요건을 구체적으로 명시해야 하며, 이상 비용 탐지 결과가 실제 청구와 어떻게 검증되는지, 오류 발생 시 통지·정정 절차가 무엇인지까지 과업 범위에 담아야 합니다.

한편 공공 클라우드 시장에서는 검증 체계 자체도 개편이 진행 중입니다. 과기정통부와 국정원은 그동안 이원화돼 있던 클라우드보안인증(CSAP)과 국정원 보안검증을 국정원 단일 체계로 통합하는 방안을 발표했고, 2027년 7월 시행을 목표로 관련 지침을 정비하고 있습니다. 저는 이런 검증 체계 개편이 진행되는 시점일수록, 가용성이나 보안 요건뿐 아니라 비용 데이터의 정확성 검증까지 포함한 종합적인 신뢰성 기준이 함께 논의돼야 한다고 봅니다. 인증 체계가 아무리 촘촘해져도 청구 데이터라는 영역이 사각지대로 남는다면, 이번 AWS 비용 예상 버그와 유사한 상황이 국내 공공 클라우드 환경에서도 재현되지 않으리라는 보장이 없습니다.

FinOps 관점에서 다시 보는 비용 거버넌스

클라우드 비용을 재무와 운영이 함께 관리하는 방법론인 FinOps는 최근 몇 년 사이 단순히 유휴 자원을 끄는 수준을 넘어, AI 기반으로 향후 지출을 예측하고 실시간으로 최적화하는 방향으로 진화하고 있습니다. 그런데 이번 AWS 비용 예상 버그는 FinOps 도구가 아무리 정교해져도 그 근간이 되는 원천 데이터 자체가 흔들리면 전체 체계가 무의미해질 수 있다는 걸 역설적으로 보여줬습니다. 업계에서는 여전히 클라우드 예산의 상당 부분, 많게는 3분의 1 가까이가 낭비되고 있다는 진단이 나오는데, 그 낭비를 줄이겠다고 도입한 이상 탐지 시스템 자체가 이번처럼 오작동한다면 오히려 담당자의 판단을 흐리는 요인이 됩니다.

저는 FinOps 문화를 도입하려는 조직이라면 이번 사례를 계기로 비용 데이터의 검증 체계를 이중, 삼중으로 갖춰야 한다고 봅니다. 개발팀, 운영팀, 재무팀이 각자 다른 소스에서 비용 데이터를 받아 교차 확인하는 절차를 두거나, 최소한 이상 수치가 감지됐을 때 자동으로 알람만 보내는 게 아니라 해당 데이터가 실제 청구 시스템과 정합성이 맞는지 재검증하는 단계를 프로세스에 넣어야 합니다. AWS 스스로도 이번 사고 이후 “유사한 문제가 발생할 경우 즉시 청구 계산을 중단하고 엔지니어링 팀에 알릴 수 있도록 내부 경보 체계를 개선했다”고 밝혔는데, 이는 거꾸로 말하면 사고 이전에는 그런 자동 차단 로직이 갖춰져 있지 않았다는 뜻이기도 합니다.

FinOps 관점에서 비용 데이터를 교차 검증하는 거버넌스 구조를 표현한 일러스트

SLA에 비용 데이터 신뢰성 조항이 빠져있지 않은가

클라우드 서비스수준계약, 흔히 SLA라고 부르는 문서를 실제로 검토해보면 대부분 가동률과 응답 시간 위주로 구성돼 있다는 걸 알 수 있습니다. 이번 사고처럼 서비스는 멀쩡히 돌아갔지만 청구 관련 데이터가 왜곡된 경우, 이게 SLA 위반에 해당하는지조차 명확하지 않은 계약서가 대부분입니다. 저는 공공기관을 포함한 여러 조직이 클라우드 계약을 맺을 때 가용성 지표에만 집중하고, 비용·청구 데이터의 정확성은 당연히 보장되는 영역으로 여기는 경향이 있다고 생각합니다.

가용성 지표는 시간 단위로 측정하기 쉽고 위반 여부도 명확히 가려지는 반면, 비용 데이터의 정확성은 애초에 측정 기준 자체가 계약서에 존재하지 않는 경우가 대부분입니다. 기준이 없으니 위반도 성립하지 않고, 위반이 성립하지 않으니 손해배상이나 보상 논의도 시작조차 되지 않습니다. 저는 이 공백이야말로 이번 사고가 계약 실무자들에게 던진 가장 실질적인 숙제라고 봅니다. 앞으로 클라우드 계약을 갱신하거나 새로 체결하는 담당자라면, 비용 데이터 오류에 대한 최소한의 정의와 대응 기준을 조문 형태로 남겨두시길 권합니다.

하지만 이번 사건이 보여주듯, 비용 데이터도 언제든 오류가 날 수 있는 하나의 시스템입니다. 공공 클라우드 이용 기준 고시나 디지털서비스 이용계약 가이드라인에도 비용 산정 오류 발생 시 정정·통지 절차를 구체적으로 명시하는 조항이 필요해 보입니다. 계약 체결 단계에서부터 “예상 비용 데이터에 중대한 오류가 발생할 경우 몇 시간 이내에 고지하고, 정정된 데이터를 다시 제공한다”는 식의 조건을 넣어두면, 이번처럼 예산 담당자가 영문도 모른 채 혼란을 겪는 상황을 줄일 수 있습니다.

벤더 종속과 멀티클라우드, 다시 떠오르는 오래된 질문

이번 사고가 다시 불을 지핀 논쟁이 하나 더 있습니다. 특정 CSP에 인프라 전체를 맡기는 게 과연 합리적인 선택인가 하는 질문입니다. 2025년 10월 AWS 리전 장애, 11월과 12월 클라우드플레어 장애, 6월 구글 클라우드 장애에 이어 이번 사고까지 겹치면서, 단일 벤더에 대한 의존이 서비스 가용성뿐 아니라 재무 데이터의 신뢰성까지 흔들 수 있다는 인식이 커지고 있습니다.

물론 멀티클라우드 전략이 만능 해법은 아닙니다. 여러 CSP를 동시에 운영하면 관리 복잡도가 늘고, 각 CSP마다 다른 비용 산정 체계와 API를 통합해야 하는 부담이 새로 생깁니다. 다만 최소한 핵심 업무 시스템이라면, 비용 모니터링 도구만큼은 CSP가 제공하는 네이티브 대시보드에만 의존하지 않고, 별도의 서드파티 비용 관리 플랫폼으로 교차 검증하는 이중 장치를 두는 편이 안전합니다. 저는 공공기관 클라우드 네이티브 전환 사업을 다룰 때도 이 원칙이 그대로 적용된다고 봅니다. 컨테이너 오케스트레이션 기반의 아키텍처가 벤더 종속을 줄이는 데 유리하다는 점은 이전 글에서도 다뤘는데, 비용 모니터링 체계 역시 같은 맥락에서 특정 CSP의 콘솔 하나에만 기대지 않는 이중화 설계가 필요합니다.

공공 IT 컨설팅 관점에서 챙길 것

여기까지 살펴본 내용을 실무 체크리스트로 정리해보겠습니다. 먼저 제안요청서나 과업지시서를 작성할 때 클라우드 비용 모니터링 요건을 가용성 요건과 동등한 수준으로 명시하시길 권합니다. 단순히 대시보드 제공 여부만 확인할 게 아니라, 이상 비용 탐지 결과와 실제 청구서 간의 정합성을 어떻게 검증하는지, 오류 발생 시 통지 시한이 얼마나 되는지까지 구체적인 문구로 담아야 합니다.

둘째, SLA 검토 단계에서 가동률 조항만 보지 말고 비용·청구 데이터의 정확성에 관한 조항이 있는지 함께 확인하시길 바랍니다. 이번 AWS 비용 예상 버그처럼 서비스는 정상 작동했지만 청구 관련 데이터만 왜곡된 사고는 기존 SLA로는 명확히 커버되지 않는 사각지대일 가능성이 큽니다. 셋째, 예산 편성 방식을 결정할 때 종량제와 정액제 각각의 리스크를 비교해두는 게 좋습니다. 종량제는 유연하지만 이번처럼 비용 산정 오류가 발생하면 정산 분쟁으로 이어질 수 있고, 정액제는 예측 가능하지만 실제 사용량과 괴리가 생길 수 있습니다.

넷째, 핵심 시스템이라면 CSP 네이티브 비용 대시보드 외에 별도의 검증 수단을 두는 이중 모니터링 체계를 설계 단계부터 반영하시길 권합니다. 다섯째, 감리 체크리스트에 클라우드 벤더의 최근 장애 이력과 재발 방지 대책을 포함시키는 것도 고려할 만합니다. 2025년 10월 AWS 리전 장애, 6월 구글 클라우드 장애, 11월과 12월 클라우드플레어 장애, 그리고 이번 AWS 비용 예상 버그까지, 대형 클라우드 사업자라 해도 내부 자동화 오류로부터 자유롭지 않다는 사실이 최근 1년 사이 반복적으로 확인됐기 때문입니다. 여섯째, 국내 공공 클라우드 검증 체계가 국정원 단일 체계로 개편되는 흐름도 함께 챙겨두시길 권합니다. 새 검증 체계가 자리 잡는 유예 기간 동안 발주기관과 사업자 사이에 책임 범위를 어떻게 나눌지 미리 협의해두면, 향후 유사한 사고가 발생했을 때 대응이 한결 수월해집니다.

마무리하며

70원짜리 사용량에 3조 원대 청구서가 뜨는 광경은 어찌 보면 우스꽝스럽고 금방 잊힐 해프닝처럼 보일 수 있습니다. 하지만 그 이면에는 아무리 정교한 자동화 시스템을 갖춘 빅테크라 해도, 이상 신호를 감지하고서도 곧바로 차단하지 못하는 빈틈이 있다는 사실이 드러나 있습니다. 서비스 가용성만큼이나 비용 데이터의 정확성도 클라우드 신뢰의 한 축이라는 점을, 이번 AWS 비용 예상 버그 사건이 다시 한번 확인시켜준 셈입니다. 공공이든 민간이든 클라우드에 인프라를 맡긴 조직이라면 이 기회에 비용 모니터링 체계와 SLA 조항을 한 번쯤 다시 들여다보시길 권합니다.

여러분이 관리하시는 클라우드 환경에서는 비용 이상 탐지 알람이 울렸을 때 이를 실제 청구 시스템과 교차 검증하는 절차가 마련돼 있으신가요? 아니면 이번 사건을 보고서야 그 빈틈을 처음 발견하셨다면, 어떤 부분부터 손보실 계획이신지 댓글로 공유해주시면 다음 글에서 더 깊이 다뤄보겠습니다.

AWS 비용 예상 버그 사태, 24억 달러 청구서가 남긴 클라우드 비용 관리 필수 체크리스트