아마존이 6시간에 잃은 630만 건

6시간, 그리고 99퍼센트

2026년 3월 5일, 아마존 북미 마켓플레이스에서 주문의 99%가 사라졌다. 화면은 멀쩡히 떠 있었다. 그런데 장바구니에서 결제로 넘어가는 길목이 끊겼다. 정상으로 돌아오기까지 약 6시간이 걸렸다. 그 사이에 놓친 주문은 630만 건으로 추정된다. 이 숫자는 언론이 인용한 유출 내부 추정치일 뿐, 아마존이 공식으로 확인한 값은 아니다. 그런데 이번이 처음도 아니었다. 사흘 전인 3월 2일에도, 장바구니에 엉뚱한 배송 예정일이 뜨면서 약 12만 건이 이미 날아간 뒤였다. 그때 주요 원인으로 지목된 것이 바로 아마존의 AI 코딩 도구 Q였다.

3월 5일 사고의 사후 분석은 근본 원인을 딱 한 줄로 적었다. 프로덕션에 들어간 변경이 정식 변경관리(Modeled Change Management) 승인도, 배포 전 검증도 없이 그대로 나갔다는 것이다. 다시 말해, 버그가 든 코드 한 줄이 진짜 문제가 아니었다. 그 코드를 배포 직전에 멈춰 세울 사람이 아무도 없었다는 것이 문제였다.

"사용자 실수였습니다"

아마존 대변인의 공식 설명은 짧고 단호했다. "이번 사건은 사용자 실수, 구체적으로는 잘못 설정된 접근 권한 때문이며 AI 탓이 아니다." 사실 회사는 전에도 같은 말을 한 적이 있다. 2025년 12월, AWS Cost Explorer가 중국에서 13시간 멈췄을 때다. 그때도 설명은 똑같았다 — "user error, misconfigured access controls", 즉 사용자 실수이자 잘못 설정된 접근 권한. 그런데 그 12월 사고를 실제로 당긴 방아쇠는 따로 있었다. Kiro라는 AI 도구가 스스로 "환경을 삭제하고 다시 만들기로" 결정했고, 엔지니어들은 그 AI 에이전트가 개입 없이 알아서 문제를 풀도록 내버려 두었다.

같은 시기 아마존 내부 문서의 온도는 대변인의 말과 사뭇 달랐다. 문서는 생성형 AI가 "의도치 않게 취약점을 노출하고 있다(accidentally exposing vulnerabilities)"고 경고했다. 그리고 지금의 안전장치를 두고 "완전히 부적절하다(completely inadequate)"고 적었다. 밖으로는 사용자 실수, 안으로는 부적절한 안전장치. 두 문장은 사실 서로 다른 곳을 가리키고 있다. 하나는 실수를 저지른 사람의 손가락을 가리킨다. 다른 하나는 그 손가락을 붙잡아 줄 난간이 없다는 사실을 가리킨다.

코드가 아니라 계기판

이 사고를 '코드 품질' 문제로만 읽으면, 처방은 뻔해진다. "AI가 코드를 더 잘 짜게 만들자"가 된다. 그런데 각도를 조금 틀어서 조직의 계기판을 들여다보면, 전혀 다른 게 보인다.

이 기간에 아마존이 무엇을 '측정'했는지 보자. Kiro 주간 사용률 목표 80%. AI 에이전트 21,000개 배치. 20억 달러 절감. 이 숫자들은 하나같이 얼마나 많이, 얼마나 빨리 만들어 냈는가를 재는 숫자다. 그리고 회사는 이 숫자들을 밀어 올리는 동안, 2025년 10월부터 이어진 감원으로 약 3만 명을 줄였다. 그 감원 명단 어딘가에는, 만들어진 것을 '검토'하던 사람들도 있었다.

생성하는 쪽에는 도구가 있었고, 목표치가 있었고, 대시보드가 있었다. 반대로 검증하는 쪽에는 아무 숫자도 붙지 않았다. 조직은 재는 것을 향해 달린다. 재지 않는 것은 조용히 사라진다. 3월 5일에 사라진 건, 주문만이 아니었다.

AI는 당신이 이해하는 속도보다 빠르게 코드를 만들 수 있다. 그 간격이, 검증이 끝나기 전에 소프트웨어를 프로덕션으로 밀어 넣는다.

"AI can generate code faster than you can understand it. That gap allows software to move toward production before validation occurs."

— 베르너 포겔스(Werner Vogels), 아마존 CTO

바이브 코딩과 증강 코딩 사이

AWS CEO 매트 가먼(Matt Garman)은 비슷해 보이는 두 단어를 딱 갈라 놓았다. 하나는 바이브 코딩이다. AI가 뱉어낸 결과물을 그대로 받아들이는 방식이다. 다른 하나는 증강 코딩(augmented coding)이다. AI가 속도를 올려 주는 동안에도, 품질에 대한 판단만큼은 사람이 계속 쥐고 있는 방식이다. 쓰는 도구는 똑같다. 갈리는 지점은 딱 하나, 사람이 여전히 개입하느냐다.

가먼은 여기서 한 발 더 나갔다. "AI로 주니어 직원을 대체하자"는 발상을 두고, 그는 "들어본 것 중 가장 멍청한 아이디어의 하나"라고 잘라 말했다. 이건 감정이 아니라 구조의 문제다. 오늘의 주니어는 검토를 배우면서 자란다. 그리고 내일의 시니어 검토자가 된다. 그런데 검토를 배울 사람을 지금 잘라 버리면 어떻게 될까. 몇 년 뒤, AI가 쏟아내는 코드를 읽어 낼 사람이 거의 남지 않는다. Kiro 사용률은 강제로 끌어올릴 수 있어도, 그 결과물을 이해하는 능력은 강제로 배포할 수 없다.

1.7배라는 숫자의 함정

AI가 짠 코드가 부실하다는 근거는 넉넉하다. CodeRabbit 조사는 AI가 생성한 코드에 사람이 짠 코드보다 약 1.7배 많은 문제가 있다고 봤다. Apiiro 분석(Kusari 인용)은 AI의 도움을 받은 팀이 보안 이슈를 약 10배 더 들여왔다고 했다. ICSE 2026의 한 연구는, 바이브 코딩이 기술부채를 전통적 개발의 약 3배 속도로 쌓고 QA는 "자주 생략된다"고 지적했다.

이 숫자들은 다 사실이다. 그런데 이 숫자들만으로는 3월 5일을 설명할 수 없다. 그날의 사후 분석은 "코드에 버그가 1.7배 많았다"고 적지 않았다. "승인과 검증 단계를 건너뛰었다"고 적었다. 산술적으로 말하면 이렇다. 검토 게이트를 통과한 코드의 결함률이 몇 배든 상관없다. 게이트 자체가 없으면, 애초에 곱할 대상이 없다. 1.7배는 코드를 묘사하는 숫자다. 630만은 검토자의 부재를 묘사하는 숫자다. 둘은 아예 다른 층위에 놓여 있다.

열어야 할 것은 코드가 아니라 대시보드

그래서 이 글을 읽은 사람이 오늘 당장 할 수 있는 일은, 코드 리뷰 규칙을 하나 더 만드는 게 아니다. 먼저 자기 팀의 계기판부터 열어 보는 것이다.

아마존이 내놓은 처방도 뒤늦게나마 이 방향을 인정한다. 3월 10일, 이커머스 서비스 수석부사장 데이브 트레드웰(Dave Treadwell)이 정례 스토어 기술 회의를 '딥다이브'로 열겠다고 사내에 알렸다. "파급 반경이 큰 사고와 위험한 관행의 흐름"을 다루기 위해서였다. 그렇게 90일짜리 임시 안전 지침이 나왔다. 소비자와 직접 맞닿는 약 335개 'Tier-1' 시스템은, 프로덕션에 배포하기 전에 반드시 2인 동료 검토를 거쳐야 한다. 주니어와 미드레벨 엔지니어가 AI의 도움을 받아 바꾼 코드는, 시니어의 서명을 받아야 한다.

두 사람

주목할 건 바로 그 숫자다. 335개 시스템마다 두 사람씩. 불과 몇 달 전만 해도, 회사가 강제한 지표는 Kiro 사용률 80%였다. 그리고 검증하는 사람의 수를 세는 지표는 0이었다. 사고가 터지고 나서야, 그 빈칸에 처음으로 숫자가 들어갔다.

그런데 트레드웰의 또 다른 발언은, 이 처방이 임시방편이라는 걸 스스로 안다. "우리는 결정론적이면서 에이전트적인 안전장치를 포함해 더 견고한 해법에 투자할 것이다." 2인 검토는 증상을 눌러 줄 뿐이다. 생성 속도가 검증 능력을 앞질러 버린 구조는 그대로 남아 있다. 다음 분기, Kiro 사용률 목표가 다시 올라가고, 검토 부하 지표가 대시보드에서 조용히 내려가는 순간 — 630만이라는 숫자는 다시 계산될 자리를 찾아 나설 것이다.