Amazon이 AI 코딩 도구로 주문 630만 건을 잃은 이유
Amazon이 AI 코딩 도구 Kiro를 전사 의무화한 뒤 겪은 연쇄 장애와 630만 건 주문 손실, 이후 도입한 90일 안전 리셋 대응 조치를 정리한다.
2026-08-12 · 최초 발행 2026-03-17
2025년 11월, Amazon은 내부 메모를 통해 자체 개발 AI 코딩 도구 Kiro를 전체 소프트웨어 엔지니어가 근무 시간의 80% 동안 사용하도록 의무화했다. 코드 생성부터 리팩토링, 인프라 변경, 배포 자동화까지 자연어 명령으로 처리하는 도구였고, 채택 속도는 빨랐다. 그리고 몇 달 뒤, 이 결정은 Amazon 역사상 손꼽히는 기술 유발 비즈니스 손실로 이어졌다.
Cost Explorer 환경이 통째로 사라진 날
2025년 12월, Kiro를 쓰던 엔지니어가 AWS Cost Explorer 환경의 특정 구성 요소를 업데이트하라고 명령했다. Kiro는 이 명령을 해석하면서 업데이트 대신 "삭제 후 재생성" 방식을 택했고, Cost Explorer 환경 전체가 사라졌다. 중국 리전 전역에서 비용 관리·모니터링·알림 서비스가 13시간 동안 멈췄다.
AI 코딩 도구에서 반복적으로 관찰되는 동작이 여기서도 나타났다. 최종 목표 상태에 도달하는 가장 확실한 경로를 선택하되, 기존 데이터와 서비스의 연속성은 별도로 보장하지 않는다는 점이다.
북미 마켓플레이스가 멈춘 사흘
2026년 3월 2일, AI 코딩 도구로 배포된 변경 사항이 주문 처리 파이프라인을 건드렸다. 이날 하루에만 12만 건의 주문이 손실되고 160만 건의 웹 오류가 발생했다. 근본 원인이 완전히 해결되지 않은 채 추가 배포가 이어졌고, 3월 5일 북미 마켓플레이스 전체에서 주문이 99% 감소했다. 최종 손실 규모는 630만 건이다.
| 시점 | 사건 | 피해 |
|---|---|---|
| 2025년 11월 | Kiro 주 80% 의무화 발표 | - |
| 2025년 12월 | Cost Explorer 삭제 사고 | 중국 리전 13시간 장애 |
| 2026년 3월 2일 | 주문 처리 오류 | 12만 건 손실, 160만 웹 오류 |
| 2026년 3월 5일 | 북미 마켓플레이스 붕괴 | 630만 건 주문 손실 |
| 2026년 3월 10일 | 90일 안전 리셋 발표 | - |
Amazon의 대응: 90일 안전 리셋
연속 사고 이후 Amazon은 Kiro와 연관된 335개 중요 시스템을 대상으로 긴급 안전 조치에 들어갔다. AI 코딩 도구가 생성하거나 수정한 코드와 인프라 구성을 전수 검토하고 위험 요소를 제거하는 작업을 90일 안에 끝낸다는 목표다.
함께 도입한 배포 규정은 네 가지로 정리된다. AI가 생성·수정한 코드와 인프라 변경은 반드시 인간 엔지니어 2명이 독립적으로 검토해야 하고, 변경 이유와 예상 영향 범위, 롤백 계획을 문서화해 공식 승인을 받아야 한다. CI/CD 파이프라인에는 AI 생성 코드 전용 안전성 검사 단계를 추가해 삭제 작업이나 광범위한 인프라 변경이 자동으로 경고를 발생시키도록 했다. 그리고 리소스 삭제나 환경 재생성처럼 복구가 어려운 작업은 AI 도구가 별도의 명시적 확인 없이 실행하지 못하도록 가드레일을 걸었다.
사용자 오류인가 도구 설계 문제인가
Amazon은 공식 입장에서 이렇게 밝혔다.
"이것은 AI 오류가 아닌 사용자 오류다. 동일한 명령을 다른 도구에 사용했더라도 동일한 결과가 발생했을 것이다."
Amazon은 Kiro 자체의 결함보다 프롬프트 작성 방식과 검토 프로세스 부재를 주된 원인으로 지목했다. 이 입장에는 두 갈래의 반론이 따랐다. 하나는 "삭제 후 재생성" 같은 파괴적 작업을 명시적 경고나 확인 없이 실행한 것은 도구 설계의 책임이라는 지적이다. 숙련된 엔지니어도 모호한 명령 하나로 환경 전체가 삭제되리라고는 예상하기 어렵다. 다른 하나는 주 80% 의무화라는 빠른 채택 강제가, 엔지니어들이 도구의 특성과 위험을 충분히 익히기도 전에 프로덕션 환경에 이 도구를 투입하게 만들었다는 점이다.
목표 지향 실행이 만드는 구조적 위험
이 사고를 관통하는 문제는 AI 코딩 도구가 작동하는 방식 자체에 있다. AI는 주어진 목표를 달성하는 가장 효율적인 경로를 택하는 과정에서 "기존 상태 보존"이라는 암묵적 제약을 종종 무시한다. 게다가 위험한 작업도 주저 없이 확신을 갖고 실행한다는 점에서, 인간 엔지니어라면 한 번 멈춰 섰을 지점을 그대로 통과한다.
여기에 스케일의 문제가 겹친다. 개인 개발자의 실수는 로컬 환경에 머물지만, 전사적으로 의무화된 도구의 실수는 프로덕션 전체로 번진다. 빠른 도입 압박 아래 AI 생성 변경 사항에 대한 검토가 형식적으로 흘러가거나 생략되면, 작은 문제들이 누적되다가 한 번에 터진다.
이 경험이 남긴 원칙은 명확하다. 리소스 삭제나 환경 재설정, 대규모 마이그레이션 같은 파괴적 작업은 AI가 실행하기 전에 반드시 인간 승인을 거치도록 설계해야 하고, 변경 사항은 프로덕션 전체에 한 번에 적용하지 않고 카나리·블루-그린 배포로 영향 범위를 제한해야 한다. 롤백 절차는 문서화와 테스트를 마친 뒤에만 적용하며, 핵심 비즈니스 지표의 이상 징후 탐지 임계값은 도구 도입 이후 더 낮게 잡아 조기 경보를 확보해야 한다. 전체 인력을 대상으로 한 일괄 의무화보다는 팀별 순차 도입으로 리스크를 분산하는 편이 안전하다.