Amazon이 AI 지원 코드 변경에 시니어 엔지니어 사전 승인을 의무화했다. Ars Technica 보도에 따르면, 아마존 전자상거래 부문은 올해 초 약 6시간짜리 웹사이트·쇼핑앱 다운을 포함해 복수의 서비스 장애를 겪었다. 원인으로 지목된 건 "아직 완전히 확립되지 않은 새로운 GenAI 활용"이었다. AI 코딩 어시스턴트 Kiro가 환경을 삭제·재생성하면서 13시간 장애를 낸 사건도 포함됐다. 내부 브리핑 노트는 이를 "고위험도(high blast radius) 사고의 트렌드"라고 명시했다.
이 뉴스를 보고 "역시 AI는 위험해"라고 읽으면 핵심을 놓친다. Amazon이 말하는 건 'AI 코드는 나쁘다'가 아니라 '감시 없는 AI 코드가 나쁘다'는 것이다. 실제로 AI가 생성한 코드의 가장 위험한 특성은 틀렸을 때 명백히 틀려 보이지 않는다는 점이다. 패턴 매칭으로 만들어진 코드는 표면이 깔끔하고, 리뷰어는 깔끔해 보이는 코드를 무의식적으로 신뢰한다. 버그는 그 안에 숨어 있다가 엣지 케이스에서 터진다. 이게 지금 AI-First 팀들이 직면한 실질적 위험이다.
그렇다면 시니어 승인 의무화는 답인가? 솔직히 말하면 절반짜리 답이다. Hacker News 커뮤니티에서도 이 정책의 한계를 정확히 짚었다. "시니어가 코드를 완전히 검증하려면 직접 작성하는 데 드는 시간과 비슷하다." 리뷰가 병목이 되면 AI가 10분 만에 만든 기능이 사람 리뷰 대기열에서 몇 시간씩 묶인다. AI의 속도 이점이 사라지는 구조다. 인력을 줄이면서 AI를 도입한 조직이라면 이 모순은 더 빠르게 드러난다. 시니어 한 명이 주니어 여럿의 AI 생성 PR을 전부 책임지는 구조는 지속 불가능하다.
품질 실패의 진짜 원인을 한 단계 더 파고들면, 컨텍스트 부재가 나온다. dev.to에 소개된 pi-reviewer 프로젝트가 정확히 이 문제를 건드린다. 대부분의 AI 코드 리뷰 도구가 실패하는 이유는 모델이 나빠서가 아니다. 도구가 팀의 컨텍스트를 모르기 때문이다. AI 리뷰 봇은 diff를 읽고 기술적으로 맞는 지적을 쏟아낸다. 변수명 개선, try-catch 누락, 메모이제이션 제안. 하지만 그 팀이 에러 처리를 전역 바운더리에 위임하기로 결정했다는 사실, fetchUser가 의도적 네이밍 컨벤션이라는 사실을 모른다. 결과적으로 리뷰어는 노이즈를 처리하느라 지치고, 실제로 중요한 이슈를 놓친다.
pi-reviewer의 접근법은 AGENTS.md와 REVIEW.md를 사전에 읽어 팀 컨벤션을 에이전트에게 주입하는 것이다. 이 원리는 도구를 불문하고 AI 코드 리뷰를 설계할 때 반드시 고려해야 할 레이어다. Anthropic의 Claude Code Review가 CLAUDE.md와 REVIEW.md를 읽는 방식도 같은 철학이다. 리뷰 품질은 모델 성능보다 컨텍스트 설계에 더 크게 달려 있다. 좋은 REVIEW.md 하나가 비싼 모델 업그레이드보다 실질적 효과가 크다.
이 세 신호—Amazon의 사후 통제, AI 리뷰의 컨텍스트 실패, 멀티 에이전트 검증 도구의 등장—를 연결하면 하나의 설계 원칙이 보인다. 품질 실패는 AI 도구의 문제가 아니라 통제 레이어 설계의 빈틈에서 온다. 시니어 승인은 사람 레이어, REVIEW.md는 컨텍스트 레이어, 멀티 에이전트 검증은 자동화 레이어다. 어느 하나만으로는 충분하지 않다. Amazon이 시니어 승인만 추가한 건 가장 쉬운 레버를 잡은 것이고, 그게 지속 가능한 해법이 아님을 그들도 알 것이다.
팀 리드 입장에서 내일 당장 할 수 있는 건 세 가지다. 첫째, REVIEW.md를 지금 만들어라. 팀이 항상 체크해야 할 항목과 명시적으로 건너뛰어야 할 항목을 분리해서 기록하라. 이 파일이 AI 리뷰의 정확도를 즉시 올린다. 둘째, AI 생성 코드를 위한 PR 템플릿에 self-review 체크리스트를 추가하라. 단순한 버튼 하나지만, 작성자가 자신이 제출하는 코드를 실제로 읽게 만드는 마찰이 된다. 셋째, 시니어 승인을 모든 PR에 의무화하기 전에 리스크 등급을 먼저 분류하라. 프로덕션 데이터 접근, 인프라 변경, 외부 API 연동처럼 blast radius가 큰 변경에만 사람 게이트를 걸면 병목 없이 통제를 유지할 수 있다.
Amazon의 한 내부 문서는 이렇게 적었다. "GenAI 사용은 가드레일이 없는 모든 곳의 날카로운 엣지를 가속화해서 노출시킬 것이다." AI 도구의 잠재력에 낙관적이면서도 이 문장을 동시에 믿어야 한다. AI는 팀의 프로세스 빈틈을 찾아내는 속도를 올린다. 빈틈이 있었다면 AI 없이도 언젠가 문제가 됐을 것이다. AI는 그 시점을 앞당길 뿐이다. 통제 설계를 먼저 하지 않고 AI 속도만 올린 팀은 결국 Amazon처럼 사고 후에 설계를 시작하게 된다. 순서가 중요하다.