아마존, 180만 달러 클로드 비용 초과: AI 지출 통제 실패를 막는 방법

서론

아마존의 내부 프로젝트 중 Anthropic Claude Sonnet을 사용한 프로젝트가 180만 달러의 청구서를 누적했으며, 계획된 예산을 860% 초과했고, 5개월 동안 발견되지 않았으며, 결국 출시에 실패한 것으로 보도됐다.

이 작업 자체는 매우 평범해 보인다: 저자 정보를 아마존 전자상거래 플랫폼의 상품 목록과 매칭하는 것이었다.

이 사건은 파이낸셜타임스가 아마존 시니어 엔지니어가 내부 직원 회의에서 AI 관련 비용 초과 사례 여러 건을 논의한 이후 보도했다. 이는 간헐적으로 챗봇을 사용하는 조직에서 매일 수천 또는 수백만 건의 유료 모델 호출을 생성할 수 있는 자동화 워크플로우로 전환하는 모든 조직에 유용한 경고가 된다.

전통적인 소프트웨어 결함은 종종 엔지니어링 시간을 낭비하거나 잘못된 출력을 생성한다. 그러나 사용량에 따라 과금되는 AI 워크플로우의 결함은 두 가지 문제를 동시에 일으킬 수 있으며, 활성화된 상태로 유지되는 매분마다 토큰, 도구, 스토리지, 컴퓨팅 비용을 지속적으로 발생시킨다.

교훈은 기업이 AI 사용을 중단해야 한다는 것이 아니라, 자율적이거나 대용량의 AI 프로세스에는 안전 및 품질 통제와 마찬가지로 명확한 재무 통제가 필요하다는 것이다.

아마존 내부에서 무슨 일이 있었나

소식통에 따르면 아마존은 저자 정보를 소매 플랫폼의 상품 목록과 매칭하는 프로젝트에 Claude Sonnet을 사용했다.

보고된 배포 결과:

180만 달러 지출
할당된 예산을 860% 초과
발견까지 5개월 소요
프로덕션 환경에 도달하지 못함

시니어 엔지니어들은 일부 AI 관련 코딩 오류를 "재앙적으로 비싼" 것으로 묘사했다.

아마존은 기술 사용 방식(비용 효율성 관리 방법 포함)을 실험하고 학습하며 개선 중이라고 응답했다. 또한 소수의 고립된 사례를 일반적인 관행으로 제시하는 것은 아마존의 더 큰 조직 전체에서 AI가 적용되는 방식을 정확히 반영하지 않는다고 밝혔다.

두 진술 모두 사실일 수 있다.

이 사건들은 아마존의 소수 팀에만 관련될 수 있지만, 동시에 다른 조직들이 진지하게 받아들여야 할 통제 문제를 드러낸다.

구체적인 코딩 결함은 아직 공개되지 않음

최초의 중국어 보도는 초과 지출을 호출 빈도 제한이 없는 프로그램이 지속적으로 루프 방식으로 요청을 보낸 데서 발생한 것으로 돌렸다.

이 설명은 그럴듯하지만, 현재 공개된 보도에 의해 확인되지는 않았다.

파이낸셜타임스는 코딩 오류, 취약한 지출 통제, 탐지 지연을 설명했다. 그러나 다음과 같은 기술적 사후 분석 보고서는 공개하지 않았다:

소스 코드
정확한 결함
프로세스가 무한 루프였는지 여부
모델 호출 횟수
입력 또는 출력 토큰 수
모델이 직접 액세스되었는지 Amazon Bedrock을 통해 액세스되었는지 여부
모델 버전
도구 사용 구성
비용을 발생시킨 인프라 구성 요소

가장 안전한 결론은 더 신중하다: 실패한 Claude Sonnet 배포가 막대한 청구서를 생성했고, 아마존의 통제 시스템은 5개월 동안 이를 발견하지 못했다.

아마존이 기술 사고 보고서를 공개하지 않는 한, 더 자세한 설명은 모두 추정으로 표시되어야 한다.

이것이 유일한 비용 문제가 아님

초과 지출

같은 내부 보고서에는 최소 두 건의 다른 사례도 논의된 것으로 알려졌다.

프로젝트	보고된 예상치 못한 비용
재무 감사 도구	약 541,000 달러
배송 속도 향상을 목표로 한 물류 프로젝트	약 134,000 달러

물류 초과 지출은 발견되기까지 2주 이상 걸린 것으로 알려졌다.

이 사례들은 180만 달러의 저자 매칭 프로젝트보다 규모는 작지만 동일한 패턴을 가리킨다: 기술적 장애로 프로세스가 강제 중단되지 않는 한, 사용량 기반 AI 시스템은 지속적으로 비용을 누적할 수 있다.

전통적인 배치 작업은 충돌하거나, 메모리를 소진하거나, 테스트를 통과하지 못할 수 있다.

반면 AI 프로세스는 기술적으로는 정상으로 보이지만 경제적으로는 붕괴된 상태일 수 있다.

프로젝트가 더 이상 유용한 결과를 생성하지 않더라도, 성공적인 API 응답을 계속 받고, 로그를 작성하고, 도구를 호출하고, 작업을 재시도하거나, 낮은 가치의 레코드를 처리할 수 있다.

AI 비용 장애가 다르게 나타나는 이유

전통적인 애플리케이션의 비용은 일반적으로 비교적 익숙한 단위와 연결된다:

서버 시간
데이터베이스 용량
스토리지
네트워크 전송
인력工时

반면 AI 워크플로우는 여러 사용량 기반 과금 계층을 동시에 증가시킬 수 있다:

입력 토큰
출력 토큰
캐시 및 비캐시 컨텍스트
추론 토큰
도구 호출
웹 검색
코드 실행 세션
벡터 검색
에이전트 재시도
병렬 워커
긴 대화 기록
클라우드 컴퓨팅 리소스
로그 및 스토리지 출력

이것은 승수 효과를 생성한다.

한 작업이 매우 긴 프롬프트를 보내고, 많은 응답을 생성하고, 두 개의 도구를 호출하고, 오류 후 재시도하고, 전체 기록을 다음 라운드로 전달한다고 가정해 보자. 애플리케이션이 수백만 개의 레코드를 처리한다면, 작은 설계 실수 하나가 극도로 비싸질 수 있다.

운영 관점에서 애플리케이션은 정상으로 보일 수 있다. 요청은 여전히 200 OK를 반환한다. 워커는 활성 상태를 유지한다. 큐는 계속 줄어든다. 청구서가 종종 문제가 처음 드러나는 곳이다.

AI 워크플로우의 간단한 비용 모델

자동화된 AI 프로세스를 시작하기 전에, 비즈니스 작업 하나를 완료하는 데 드는 비용을 먼저 추정하라.

간소화된 모델은 다음과 같다:

비용 구성 요소	계산 방법
입력 비용	입력 토큰 수 × 모델 입력 가격
출력 비용	출력 토큰 수 × 모델 출력 가격
도구 비용	도구 호출 횟수 × 도구 가격
재시도 비용	실패 또는 반복 시도 횟수 × 단일 시도 평균 비용
인프라 비용	컴퓨팅, 스토리지, 데이터베이스, 네트워크 및 로그
수동 검토 비용	검토 시간 × 인건비 포함 종합 요율

핵심 지표는 단순히 토큰당 비용이 아니다.

다음과 같다:

성공적으로 완료된 비즈니스 결과 하나당 총 비용

더 저렴한 요청이 실패율이 더 높거나, 반복 호출이 필요하거나, 더 많은 수동 검토를 생성한다면 여전히 더 비싼 워크플로우로 이어질 수 있다.

마찬가지로, 더 강력한 모델이 더 적은 단계로 작업을 완료한다면 전체 비용이 오히려 더 낮을 수 있다.

첫 번째 통제: 모든 AI 작업에 재무 책임자 지정

프로덕션 환경의 모든 AI 워크플로우에는 기술적 동작과 지출을 동시에 책임지는 지명된 담당자가 있어야 한다.

해당 담당자는 다음을 알고 있어야 한다:

예상 비즈니스 볼륨
사용 중인 모델
각 항목의 예상 비용
일일 및 월간 예산
단일 실행의 최대 비용
실행 중단 조건

워크플로우

알림을 받는 담당자
더 높은 한도를 승인하는 프로세스

한 명의 작업자가 지속적으로 요청을 보낼 수 있을 때, 모호한 프로젝트 수준 예산은 충분하지 않다.

예산은 여러 계층에 존재해야 한다:

계층	예시
조직	월간 AI 지출 상한
팀	하나의 비즈니스 단위에 대한 월간 할당량
애플리케이션	하나의 제품 또는 워크플로우에 대한 예산
환경	개발, 스테이징, 프로덕션 각각에 대한 한도
작업	하나의 배치에 대한 최대 비용
사용자 또는 테넌트	고객별 사용량 할당량
에이전트 세션	최대 토큰 수, 단계 수, 도구 수 및 소요 시간

더 낮은 계층이 가장 빠르고 효과적인 브레이크 메커니즘을 제공한다.

애플리케이션 내부에 하드 리미트 설정

클라우드 결제 알림은 중요하지만, 애플리케이션 수준 통제를 대체할 수는 없다.

애플리케이션은 설정된 경계에 도달하면 실행을 중단하거나 승인을 요구해야 한다.

유용한 제한 사항:

작업당 최대 요청 수
에이전트 최대 단계 수
최대 재시도 횟수
최대 입력 토큰 수
최대 출력 토큰 수
최대 컨텍스트 길이
최대 도구 호출 횟수
최대 병렬 워커 수
최대 소요 시간
작업당 최대 달러 비용
검토 전 최대 처리 레코드 수

이러한 통제는 기본적으로 꺼져 있어야 한다.

비용 추적 서비스를 사용할 수 없거나, 애플리케이션이 남은 예산을 확인할 수 없는 경우, 가장 안전한 동작은 무기한 계속하는 대신 일시 중지하는 것이다.

에이전트에 의존하지 않는 긴급 중단 스위치 사용

자율 에이전트는 자체 최종 지출 권한을 통제해서는 안 된다.

독립적인 서비스는 다음을 수행할 수 있어야 한다:

API 키 비활성화
모델 호출 거부
큐 일시 중지
워커를 0으로 축소
외부 도구 차단
역할 철회
예약 작업 중지
재개 전에 수동 승인 요구

에이전트가 재시도 루프에 빠지거나 잘못된 상태 메시지를 생성하더라도, 긴급 중단 스위치는 계속 사용 가능해야 한다.

프로덕션 환경 전에 테스트하라.

한 번도 사용되지 않은 통제는 이론에 불과하다.

모든 모델 호출 모니터링

Amazon Bedrock을 사용하는 조직은 지원되는 bedrock-runtime 호출에 대해 모델 호출 로깅을 활성화할 수 있다.

AWS는 이러한 로그에 요청 및 응답 데이터, 메타데이터, 모델 식별자, 요청 식별자, ID 정보 및 토큰 사용량이 포함될 수 있다고 밝혔다. 로그 대상에는 Amazon CloudWatch Logs 및 Amazon S3가 포함될 수 있다.

호출 로깅은 기본적으로 꺼져 있다.

팀은 관측에 필요한 데이터만 활성화하고 적절한 프라이버시, 보안, 보존 및 비식별화 제어를 적용해야 합니다. 프롬프트와 출력에는 민감한 회사 또는 고객 정보가 포함될 수 있습니다.

최소한 비용 모니터링 기록에는 다음이 포함되어야 합니다:

타임스탬프
애플리케이션
환경
팀 또는 비용 센터
모델
사용자 또는 테넌트
입력 토큰 수
출력 토큰 수
캐시 사용량
도구 호출
재시도 횟수
작업 식별자
예상 요청 비용
비즈니스 결과
오류 또는 에스컬레이션 사유

이렇게 하면 월간 재무 검토에서 거대한 총액을 발견하는 대신 청구서를 특정 작업과 연결할 수 있습니다.

AWS Budgets를 사용하여 Bedrock에서 Claude 비용 추적

AWS Budgets는 비용 또는 사용량을 설정된 임계값과 비교하여 추적하고 알림을 보낼 수 있습니다. 예산 작업은 임계값을 초과할 때 IAM 정책이나 서비스 제어 정책과 같은 제어 조치를 적용할 수도 있습니다. 구성에 따라 작업은 자동으로 실행되거나 승인을 기다릴 수 있습니다.

간과하기 쉬운 중요한 AWS 특정 세부 사항이 있습니다.

AWS Cost Anomaly Detection 문서에 따르면 이 서비스는 AWS Marketplace를 통해 판매되는 타사 제품을 모니터링하지 않습니다. 여기에는 Amazon Bedrock을 통해 제공되는 Anthropic Claude와 같은 타사 언어 모델이 포함됩니다.

이러한 비용은 여전히 Cost Explorer와 청구서에 표시되지만, AWS는 이러한 비용에 대한 알림을 위해 AWS Budgets를 사용할 것을 권장합니다.

예산은 결제 엔티티 필터를 사용하여 Marketplace 비용을 더 정확하게 추적할 수 있습니다.

이것은 바로 거짓된 안도감을 만들 수 있는 구성 세부 사항입니다. 회사가 이상 탐지를 활성화하고 모든 모델 비용이 포함되었다고 생각할 수 있지만, 특정 결제 범주는 포함되지 않습니다.

AWS Budgets를 실시간 차단 장치로 취급하지 마십시오

AWS 문서에 따르면 예산 상태는 하루에 여러 번 업데이트됩니다.

또한 문서는 알림이 도착하기 전이나 후에도 비용이 계속 증가할 수 있다고 경고합니다.

이는 AWS Budgets가 재무 거버넌스에는 유용하지만, 단독으로 사용할 경우 높은 처리량의 에이전트를 충분히 빠르게 차단하지 못할 수 있음을 의미합니다.

제어 스택에는 다음이 포함되어야 합니다:

애플리케이션 내 요청 수준 카운터
실시간에 가까운 사용량 지표
작업별 및 세션별 하드 상한
클라우드 예산 알림
적절한 경우 자동화된 예산 작업
고위험 출시 시 일일 재무 검토

워크플로우가 비용을 소비하는 속도가 빠를수록 제어 조치는 호출 지점에 더 가까워져야 합니다.

서비스 적용 범위 내 비용에는 이상 탐지 사용

AWS Cost Anomaly Detection은 기계 학습 모델을 사용하여 비정상적인 지출 패턴을 식별하고 가능한 근본 원인을 찾는 데 도움을 줍니다.

AWS에 따르면 이 서비스는 처리된 결제 데이터를 하루에 약 세 번 평가합니다.

AWS 서비스, 계정, 리전, 사용 유형 및 비용 할당 태그에서 예기치 않은 증가를 효과적으로 감지할 수 있습니다.

AI 시스템의 경우 컴퓨팅, 스토리지, 데이터베이스 또는 네트워크와 관련된 지원 비용 이상을 식별할 수 있습니다.

그러나 팀은 위에서 언급한 Marketplace 제한 사항을 기억하고 필요한 경우 타사 모델 비용에 대해 별도의 AWS Budgets를 생성해야 합니다.

Service Quotas를 예산이 아닌 안전 경계로 사용

Amazon Bedrock은 모델 추론에 서비스 할당량을 적용하며, 지원되는 모델 및 엔드포인트에 대한 토큰 기반 제한을 포함합니다.

할당량은 무제한 처리량을 방지할 수 있지만 정밀한 재무 예산으로 설계되지는 않았습니다.

할당량은 여전히 예상 프로젝트 한도를 훨씬 초과하는 지출을 허용할 수 있습니다. 반대로 프로덕션 용량 문제를 해결하기 위해 할당량을 높이면 의도치 않게 유용한 안전 경계가 제거될 수 있습니다.

따라서 할당량 변경에는 다음이 필요해야 합니다:

비즈니스 근거 설명
업데이트된 비용 예측
지정된 승인
업데이트된 알림 임계값
롤백 계획
트래픽 증가 후 검토

속도 및 토큰 제한은 단순히 확장의 장애물이 아니라 시스템 위험 설계의 일부로 간주되어야 합니다.

적절한 경우 Anthropic 사용량 및 비용 직접 추적

Anthropic을 직접 호출하는 애플리케이션의 경우 Anthropic 콘솔에서 비용 및 사용량 보고서를 제공합니다.

Anthropic의 API 제한에는 분당 요청 수, 분당 입력 토큰 수, 분당 출력 토큰 수, 사용 등급과 관련된 지출 제한이 포함될 수 있습니다.

이러한 제한은 통제되지 않은 처리량을 줄일 수 있지만 여전히 애플리케이션 계층 제어로 보완되어야 합니다.

무료 · We0 AI 사용하기

몇 분 만에 쇼케이스 사이트를 만들고 리드를 늘리세요

아이디어를 한 문장으로 입력하면 We0 AI가 쇼케이스 사이트, 페이지, CMS를 생성하고 출시 후 고객과 트래픽 확보를 돕습니다.

무료 등록을 위한 하나의 완전한 프로젝트 생성

하나의 완전한 생성 흐름을 시도하고 첫 번째 프로젝트 초안을 빠르게 보는 데 가장 적합합니다.

무제-1

공들여 나열한 것

채우다

반지름

생성 중

여러 팀이 있는 조직은 애플리케이션과 모델 제공자 사이에 LLM 게이트웨이를 배포할 수도 있습니다. 게이트웨이는 인증, 사용량 추적, 예산, 속도 제한, 모델 라우팅 및 감사 로그를 중앙에서 관리할 수 있습니다.

게이트웨이는 중요한 보안 구성 요소가 되므로 다른 프로덕션 액세스 계층과 동일한 수준의 주의로 운영되고 검토되어야 합니다.

소규모 대표 샘플로 시작

Amazon 프로젝트가 대규모 데이터 매칭 작업을 실행하려고 시도했다고 알려져 있습니다.

더 안전한 배포 패턴은 다음과 같습니다:

대표 레코드 100개 실행
정확성과 비용 측정
레코드 1,000개 실행
오류 및 토큰 분포 확인
최악의 경우 입력 테스트
중지 제어 확인
전체 처리 비용 추정
전체 데이터 세트를 처리하기 전에 승인 요청

평균 레코드만으로 추론하지 마십시오.

가장 긴 문서, 매칭 실패 레코드, 모호한 경우, 재시도 및 에이전트 루프가 총 비용을 지배하는 경우가 많습니다.

작업당 P50, P95, P99 비용과 같은 백분위수 추정을 사용하십시오.

유효한 결과당 최대 비용 상한 설정

추가 모델 호출이 경제적으로 합리적이지 않을 때 워크플로우는 중지되어야 합니다.

저자 매칭 시스템의 경우 유용한 지표는 다음과 같습니다:

성공적인 저자 매칭당 비용
인적 검토 레코드당 비용
자동 해결 레코드 비율
오매칭률
오매칭 비용
인적 처리 대비 절감 비용
수용된 결과당 필요한 모델 호출 수

요청당 0.02달러의 프로세스는 저렴해 보일 수 있습니다.

50번의 호출이 필요하고 절반의 레코드가 실패하며 나머지는 인적 검토로 넘어간다면 실제 경제성은 좋지 않을 수 있습니다.

단순 작업을 더 저렴한 방법으로 라우팅

모든 레코드에 최첨단 모델이 필요한 것은 아닙니다.

비용 의식이 있는 파이프라인은 다음을 사용할 수 있습니다:

정확한 매칭
데이터베이스 조인
규칙
임베딩 유사도
더 작은 모델
모호한 경우에만 더 강력한 모델 사용
고위험 결정에 대한 인적 검토

데이터 매칭 프로젝트의 경우 기존 소프트웨어가 더 낮은 비용과 더 높은 결정성으로 대부분의 경우를 해결할 수 있습니다.

LLM은 언어적 모호성이 실제로 필요한 경우에만 사용해야 하며 모든 행에 자동으로 적용해서는 안 됩니다.

Anthropic 자체 가격 가이드는 적절한 모델 선택, 반복 컨텍스트에 대한 프롬프트 캐싱, 긴급하지 않은 작업에 대한 배치 처리, 사용 패턴 모니터링을 권장합니다.

무제한 재시도 방지

재시도는 숨은 지출의 일반적인 원인입니다.

실패한 요청 하나가 애플리케이션, 큐 시스템, SDK, 게이트웨이, 작업자 관리자, 에이전트 또는 워크플로우 오케스트레이터에 의해 재시도될 수 있습니다.

여러 계층이 독립적으로 재시도하면 하나의 논리적 작업이 여러 개의 유료 요청을 생성할 수 있습니다.

다음을 포함하는 통일된 재시도 정책을 정의하십시오:

작은 최대 시도 횟수
지수 백오프
지터
재시도 불가 오류에 대한 명시적 처리
멱등성
데드 레터 큐
반복 실패에 대한 알림
재시도 횟수를 포함한 모든 관련 비용을 포함하는 작업별 예산

오류는 무한한 경제적 루프를 만들어서는 안 됩니다.

개발 및 프로덕션 자격 증명 분리

테스트 스크립트는 프로덕션 수준의 제한을 상속해서는 안 됩니다.

별도의 계정 또는 작업 공간, API 키, IAM 역할, 예산, 할당량, 로그, 데이터 소스 및 네트워크 권한을 사용하십시오.

개발 환경은 의도적으로 낮은 지출 상한을 설정해야 합니다.

우연히 루프에 빠진 프로토타입은 기업 수준의 프로덕션 할당량을 얻는 대신 소액의 청구서로 실패해야 합니다.

프로덕션 금융 인프라를 검토하듯 AI 생성 코드 검토

이 사건은 AI 지원으로 작성된 프로젝트와 관련이 있지만, 핵심 문제는 코드가 모델에 의해 생성되었는지 여부가 아닙니다.

중요한 문제는 코드가 비용을 발생시킬 수 있는지 여부입니다.

유료 모델 요청을 시작할 수 있는 모든 구성 요소는 다음에 대한 검토를 받아야 합니다:

루프 종료
재시도 동작
동시성
큐 확장
최대 컨텍스트
도구 호출 제한
타임아웃 처리
취소 메커니즘
비용 귀속
오류 경로
로깅
예산 실행
긴급 종료 동작

단위 테스트에는 경제적 실패 시나리오가 포함되어야 합니다.

예로는 모델이 유효한 답변을 반환하지 않는 경우, 반복적인 작업 전달, 유료 호출 후 작업자 프로세스 충돌, 반복적인 속도 제한 오류, 매 턴 도구 출력으로 컨텍스트가 계속 증가하는 경우, 비용 추정 서비스를 사용할 수 없는 경우가 있습니다.

기능적으로 올바른 정상 경로만으로는 충분하지 않습니다.

프로덕션급 AI 비용 제어 체크리스트

소유권 및 계획

지정된 기술 책임자가 지출에 대한 책임을 집니다.
성공적인 결과당 예상 사용량과 비용을 문서화합니다.
[

[ ] 개발, 프리프로덕션 및 프로덕션 환경에 각각 별도의 예산이 있다.

전체 규모 처리를 위해서는 명시적 승인이 필요하다.

애플리케이션 제어

각 태스크에는 최대 요청 수, 토큰 수, 단계 수, 재시도 횟수 및 소요 시간 상한이 있다.
각 에이전트 세션에는 달러로 책정된 예산이 있다.
비에이전트 서비스가 워크플로를 중지할 수 있다.
남은 예산을 읽을 수 없으면 태스크를 일시 중지한다.
멱등성을 통해 중복 작업을 방지한다.

모니터링

모든 모델 호출은 팀, 프로젝트, 사용자 및 태스크에 귀속된다.
입력, 출력, 캐시, 도구 및 재시도 사용량을 기록한다.
지출 속도와 총 지출 모두에 대해 알림을 설정한다.
초기 프로덕션 출시 기간 동안 일일 검토를 활성화한다.
팀은 이상 탐지가 적용되지 않는 비용 항목을 인지하고 있다.

품질 및 경제성

성공적인 비즈니스 결과 하나당 비용을 측정한다.
적절한 경우 일반 코드와 더 작은 모델을 사용한다.
최악의 경우 및 상위 백분위 비용을 테스트했다.
인간 검토 비용을 포함한다.
추가 호출이 더 이상 가치가 없을 때 워크플로가 중지된다.

거버넌스

AI 생성 코드는 인간 검토를 받는다.
예산 및 할당량 증액에는 승인이 필요하다.
비상 정지 스위치가 테스트되었다.
사고 대응에는 재무 및 기술 관련 이해관계자가 포함된다.
팀은 주요 모델 또는 프롬프트 변경 후 지출을 검토한다.

아마존 대응의 시사점

아마존 엔지니어들은 향후 AI 프로젝트를 위한 자동화된 보호 장치를 구축하고 있는 것으로 보도되었다.

이는 올바른 방향이다.

그러나 자동화는 여러 계층에 존재해야 한다.

성숙한 제어 시스템은 애플리케이션 하드 상한, 모델 및 게이트웨이 할당량, 클라우드 예산, 자동화된 조치, 사용량 로그, 재무 대시보드, 인간 승인 및 정기 검토를 결합해야 한다.

이 회사는 또한 직원들이 Kiro 개발 도구 사용을 극대화하도록 장려하는 내부 리더보드를 이전에 제거했다. 파이낸셜 타임스에 따르면, 이 리더보드는 직원들이 순위를 올리기 위해 토큰 소비를 늘리는 '토큰맥싱' 현상을 조장했다.

이는 인센티브가 비용 통제를 약화시킬 수 있다는 유용한 교훈이다.

직원들이 측정 가능한 비즈니스 가치를 창출하는 대신 AI를 더 많이 사용하는 것에 대해 보상을 받는다면, 산출물이 개선되지 않더라도 사용량은 증가할 것이다.

조직은 해결된 문제, 품질 개선, 절약된 시간, 창출된 수익, 감소된 위험 및 단위 산출당 비용 절감을 보상해야 한다.

토큰 수는 입력 지표이지 생산성 지표가 아니다.

자주 묻는 질문

아마존이 정말 Claude Sonnet에 180만 달러를 지출했나?

파이낸셜 타임스는 아마존 내부에서 Claude Sonnet을 사용하는 프로젝트가 누적 180만 달러의 청구액을 발생시켰다고 보도했다. 이 프로젝트는 작가 정보를 전자상거래 목록과 매칭하는 것을 목표로 했으며, 예산을 860% 초과했고 출시에 실패했다.

비용 초과가 왜 5개월 동안 발견되지 않았나?

공개 보도에 따르면, 아마존은 충분한 지출 통제 장치가 부족했으며 코딩 오류가 문제의 요인 중 하나였다. 아마존은 구체적인 결함이나 모니터링 실패를 식별하기 위한 기술적 사후 분석 보고서를 발표하지 않았다.

문제가 무한 AI 루프로 인해 발생했나?

이 설명은 일부 2차 보도에 등장했지만, 주요 보도에서는 확인되지 않았다. 정확한 요청 횟수, 재시도 로직, 토큰 규모 및 소스 코드 결함은 여전히 공개되지 않았다.

아마존에 다른 AI 비용 초과 사례가 있나?

그렇다. 동일한 내부 프레젠테이션에는 약 54만 1천 달러의 재무 감사 프로젝트 예상치 못한 비용과 13만 4천 달러의 물류 프로젝트 비용도 포함된 것으로 알려졌다.

AWS Cost Anomaly Detection이 Amazon Bedrock에서 Claude 비용을 모니터링할 수 있나?

AWS 문서에 따르면, Cost Anomaly Detection은 Bedrock의 Anthropic Claude 모델을 포함한 타사 AWS Marketplace 제품을 모니터링하지 않는다. AWS는 이러한 비용을 관리하기 위해 AWS Budgets를 사용하고, 필요에 따라 결제 엔터티 필터를 사용할 것을 권장한다.

AWS Budgets가 즉시 통제 불능 AI 지출을 차단할 수 있나?

단독으로는 불가능하다. AWS는 예산 정보가 하루에 여러 번 업데이트되며 알림 기간 전후로 비용이 계속 증가할 수 있다고 밝혔다. 트래픽이 많은 애플리케이션에는 요청 수준의 하드 상한과 별도의 비상 정지 스위치가 필요하다.

속도 제한이 지출 제한과 동일한가?

아니다. 속도 제한은 처리량을 통제하고, 예산 제한은 허용 가능한 비용을 통제한다. 워크플로는 속도 제한 내에서 실행되면서도 수주 또는 수개월에 걸쳐 계획된 지출을 크게 초과할 수 있다.

AI 에이전트에게 가장 중요한 통제 수단은 무엇인가?

각 에이전트 세션에 대해 요청, 토큰, 도구, 재시도 및 시간을 포함한 하드 예산을 설정하는 것이다. 에이전트 외부에서 이 예산을 강제하고, 워크플로를 즉시 중지할 수 있는 테스트된 방법을 제공해야 한다.

요약

보고서에 따르면 Claude Sonnet을 사용한 내부 Amazon 프로젝트가 180만 달러를 지출하여 예산을 860% 초과했으며, 5개월 동안 발견되지 않았고 결코 출시되지 않았습니다. 다른 AI 프로젝트에서도 수십만 달러의 예상치 못한 지출이 발생한 것으로 보고되었습니다.

공개 기록은 주요 사건이 무한 요청 루프로 인한 것임을 확인하지 못했습니다. 기록이 확인하는 것은 AI 워크플로우의 지출 속도와 조직이 문제를 감지하는 속도 사이에 격차가 있다는 점입니다.

기업은 단일 요청 추적, 작업 수준 예산, 토큰 및 도구 제한, 통제된 재시도, 모델 라우팅, 클라우드 예산, 자동화된 조치, 그리고 에이전트가 우회할 수 없는 긴급 중단 스위치를 결합해야 합니다.

가장 안전한 규칙은 간단합니다. 어떤 AI 프로세스도 여전히 유용하고, 예산 내에 있으며, 계속 승인되었음을 반복적으로 입증하지 않고서는 5개월 동안 실행되어서는 안 됩니다.