# 잇따른 장애 후, Amazon이 AI 지원 코드 변경에 시니어 엔지니어 승인 의무화 > Clean Markdown view of GeekNews topic #27395. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27395](https://news.hada.io/topic?id=27395) - GeekNews Markdown: [https://news.hada.io/topic/27395.md](https://news.hada.io/topic/27395.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-11T09:46:16+09:00 - Updated: 2026-03-11T09:46:16+09:00 - Original source: [arstechnica.com](https://arstechnica.com/ai/2026/03/after-outages-amazon-to-make-senior-engineers-sign-off-on-ai-assisted-changes/) - Points: 21 - Comments: 6 ## Summary AI 코딩 도구가 초래한 연속적인 서비스 장애 이후, 아마존은 **AI 지원 코드 변경에 시니어 엔지니어의 사전 승인 절차**를 의무화했습니다. 아직 확립되지 않은 **GenAI 활용 방식이 운영 리스크로 현실화**되자, 자동화보다 **인적 검증을 강화**하는 방향으로 전환한 것인데요. AI로 인원 감축을 하는 상황과 겹쳐서 여러가지 면에서 들여다보게 됩니다. ## Topic Body - 최근 **AI 코딩 도구 사용과 관련된 서비스 장애**가 잇따르자, 아마존이 모든 AI 지원 코드 변경에 대해 **시니어 엔지니어의 사전 승인 절차**를 도입 - 내부 노트에 따르면 장애의 원인으로 **"베스트 프랙티스와 안전장치가 아직 완전히 확립되지 않은 새로운 GenAI 활용"** 이 지목됨 - 이번 달 Amazon 웹사이트와 쇼핑 앱이 약 **6시간 동안 다운**되어 고객이 거래 완료, 계정 정보 확인, 가격 조회 등을 할 수 없었으며, 원인은 잘못된 소프트웨어 코드 배포 - AWS에서도 **AI 코딩 도우미 Kiro**가 환경을 삭제·재생성하는 바람에 **13시간 장애**가 발생하는 등, 최소 두 건의 AI 관련 사고가 보고됨 - **AI 코딩 도구의 프로덕션 적용에 따른 운영 리스크**가 현실화되며, 주니어·미드레벨 엔지니어의 **AI 지원 변경 사항에 시니어 엔지니어 서명을 의무화**하는 즉각적 조치 시행 --- ### 아마존의 내부 회의와 대응 조치 - 아마존 전자상거래 부문은 최근 발생한 **연속적인 서비스 중단**을 분석하기 위해 대규모 엔지니어 회의를 소집함 - 회의 안건에는 **AI 코딩 도구 사용과 관련된 사고**가 포함됨 - 내부 브리핑 노트에는 최근 몇 달간 “**고위험도(high blast radius)**” 사고가 늘었으며, “**Gen-AI 지원 변경**”이 주요 요인으로 언급됨 - 문서에는 “**아직 완전히 확립되지 않은 새로운 GenAI 사용 사례**”가 기여 요인으로 명시됨 - 시니어 부사장 **Dave Treadwell**은 이메일에서 “최근 사이트와 인프라의 가용성이 좋지 않았다”고 언급함 ### AI 관련 장애 사례 - 아마존 웹사이트와 쇼핑 앱은 이달 초 **약 6시간 동안 중단**되었으며, 원인은 “잘못된 소프트웨어 코드 배포”로 확인됨 - 이로 인해 고객들은 **거래 완료, 계정 정보 확인, 상품 가격 조회** 등을 할 수 없었음 - AWS에서도 **AI 코딩 어시스턴트 Kiro** 사용 중 문제가 발생함 - 12월 중순, Kiro가 환경을 “삭제 후 재생성”하도록 결정하면서 **13시간 동안 비용 계산기 서비스가 중단**됨 - 아마존은 이 사건을 “**중국 본토 일부 지역의 단일 서비스에 국한된 매우 제한적 사건**”으로 설명함 - 두 번째 사고는 “**고객 대상 AWS 서비스에는 영향이 없었다**”고 Amazon 측이 추가 설명 ### 새로운 승인 절차와 운영 개선 - Treadwell은 주간 회의 **‘This Week in Stores Tech (TWiST)’** 를 통해 문제 원인과 단기 개선 조치를 논의할 예정임 - 기존에는 선택 참석이었던 회의를 **전 직원 참석 권장**으로 변경함 - 앞으로 **주니어 및 미드레벨 엔지니어가 수행하는 AI 지원 코드 변경은 시니어 엔지니어의 서명 승인**을 받아야 함 - 아마존은 이번 검토를 “**정상적인 비즈니스 과정의 일부**”로 규정하며, **지속적인 개선**을 목표로 함 ### 인력 감축과 장애 증가 논란 - **Financial Times**는 일부 엔지니어들이 **인력 감축 이후 ‘Sev2’급 사고(신속 대응이 필요한 중간 수준 장애)** 가 늘었다고 언급했다고 보도함 - 아마존은 최근 몇 년간 **여러 차례 구조조정**을 단행했으며, **2026년 1월에만 16,000개의 기업직을 감축**함 - 그러나 회사는 **인력 감축이 장애 증가의 원인이라는 주장에 동의하지 않음** ### 향후 방향 - 아마존은 **웹사이트 가용성 검토와 운영 성과 점검**을 정례화하고 있음 - 회사는 **AI 코딩 도구의 안전한 활용과 장애 방지 체계 강화**를 병행 추진 중임 - 이번 조치는 **AI 도입 확산 속에서 인적 검증 절차의 중요성**을 다시 부각시키는 사례로 평가됨 ## Comments ### Comment 52826 - Author: click - Created: 2026-03-11T15:07:12+09:00 - Points: 3 AI 코드를 시니어가 리뷰하면 안전하다고 보장할 수 없죠 [crowdstrike 사건](https://news.hada.io/topic?id=16067) 이 AI때문은 아니었고 heartbleed도 AI가 없던 시대의 사고죠 결론은 누군가에게는 책임을 지우겠다는 게 골자인데 법적으로 책임질 인간이 있어야해서 우리는 대체되지 않을거라고 하시던 세무사분들의 블랙유머가 떠오르네요 ### Comment 52828 - Author: sea715 - Created: 2026-03-11T15:27:18+09:00 - Points: 1 - Parent comment: 52826 - Depth: 1 그쵸 그래서 AI에이전트에 법적 서명같은걸 넣지 않는이상 지속될거 같아요.. ### Comment 52832 - Author: click - Created: 2026-03-11T16:02:23+09:00 - Points: 1 - Parent comment: 52828 - Depth: 2 그럼 앤트로픽이나 openai 사용 비용이 천문학적으로 높아져야겠네요 API 한번 호출마다 보험료를 내야할테니 ### Comment 52835 - Author: sea715 - Created: 2026-03-11T16:34:02+09:00 - Points: 2 - Parent comment: 52832 - Depth: 3 으음.. 망상이긴하지만 iam처럼 뭔가 생기지 않을까라는.. 느낌입니다 ### Comment 52837 - Author: yeobi222 - Created: 2026-03-11T17:20:19+09:00 - Points: 1 - Parent comment: 52832 - Depth: 3 세무사는 감방가는 역할이라고 했는데 보험사가 감방을 대신 가주진 않아서 결국은... ### Comment 52802 - Author: neo - Created: 2026-03-11T09:46:16+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47323017) - 이번 “mandatory meeting”은 매주 열리는 **전사 운영 회의**임 지난주 큰 운영 사고가 있었기 때문에 이번 주 참석률이 높을 뿐임 언론이 너무 과장하고 있는 느낌임 - 내부 사정을 알고 있을 때 뉴스 보도를 보면 항상 **현실감**이 다르게 느껴짐 - 기사에서는 “보통은 선택 참석이지만 이번엔 참석 요청이 있었다”고 했는데, 그건 사실인지 궁금함 또 “주니어와 미드레벨 엔지니어의 AI 코드 변경은 시니어 승인 필요” 정책도 언급되었음 정기 회의라도 **새 정책 발표**가 있다면 뉴스 가치가 있다고 생각함 - 뉴욕에서는 지난 금요일 오후 내내 **Amazon 스토어프론트가 다운**되었음 가격이 표시되지 않고 장바구니에 담을 수도 없었음 Walmart 같은 경쟁사였다면 뉴스에 나왔을 텐데 이상함 - 이 스레드는 다른 제목의 글에서 합쳐진 것 같음. 댓글 시간대가 원글보다 훨씬 이전임 - “언론이 과장한다”는 말에 동의함. **케이블 뉴스**가 생긴 이후로 늘 그랬음 - “주니어와 미드레벨 엔지니어는 시니어 승인 없이 AI 코드 푸시 불가”라는 정책은 **시니어 리뷰**가 만능이라는 착각에서 비롯된 것 같음 실제로 시니어가 코드를 완전히 검증하려면 직접 작성하는 데 드는 시간과 비슷함 즉, 리뷰는 가치 있지만 나쁜 코드를 좋은 코드로 바꾸지는 못함 결국 “idiot proof” 시스템을 만들면 **‘idiot’을 고용해도 된다**는 오해가 생기는 게 문제임 - 경력 초반에 멘토가 “코드 리뷰는 버그 잡는 게 아니라 **맥락 공유**가 목적”이라고 했음 버그 발견은 부수 효과일 뿐이고, 진짜 중요한 건 테스트를 쉽게 만들고 **코드 복잡도**를 줄이는 일임 하지만 이런 일은 승진에 도움이 안 됨 - AI 코드가 쓸 만하려면 **전문가 리뷰**가 필수임 모델이 작업 중일 때부터 감시해야 효율적임 그렇지 않으면 AI는 **품질 낮은 코드 폭탄**을 쏟아냄 전문가가 5~15배의 시간을 들여 수정하면 괜찮지만, 그렇지 않으면 코드베이스가 망가짐 - 남의 코드를 리뷰하는 건 종종 직접 작성하는 것보다 **더 느리고 혼란스러움** 특히 나쁜 코드는 이해하는 데 시간이 배로 듦 - 엉성한 코드를 고치는 건 새로 쓰는 것보다 어렵다고 느낌 기존 코드와 새 해결책을 동시에 머릿속에 두고 비교해야 하므로 **인지 부하**가 큼 - AI가 주니어 생산성을 10배 높인다면, 시니어를 10배 늘릴지 주니어를 줄일지 고민해야 함 결국 기업이 **평균 성과 관리** 중심으로 변하는 자연스러운 진화 같음 - Amazon 내부에서는 대부분이 **해고되지 않기**와 **승진**만 신경 씀 개발자 평가는 “티켓 처리 속도”, “PR 코멘트 수”, “문서 작성”으로 결정됨 AI를 쓰지 않으면 경쟁에서 밀림 이런 구조에서 “AI 사용 자제” 요청은 현실적으로 작동하기 어려움 - PR에 코멘트가 너무 많아도, 남의 PR에 코멘트를 안 남겨도 **불이익**을 받음 - PR에 논의가 많다는 건 협업 없이 혼자 일했다는 신호일 수도 있음 잘 협업하는 팀일수록 PR 논의가 적음 - 결론: **헝거게임식 경쟁 문화**에서는 일하지 말아야 함 - 진짜 필요한 건 **self-review 프로세스**라고 생각함 AI가 작성한 코드를 그대로 푸시하는 건 위험함 GitHub 같은 곳에 “self-review 필수” 옵션을 추가해, 작성자가 직접 검토했음을 명시해야 함 - 단순히 AI 출력만 훑어보는 건 리뷰가 아님. **Heinlein식 ‘grok’ 수준의 이해**가 필요함 - 나는 git과 Sublime Merge를 쓰며 **편집과 리뷰를 분리**하는 습관을 들였음 로컬 UI가 빠르다 보니 프로젝트 흐름을 더 잘 파악하게 됨 - 자기 코드도 안 읽는 사람에게 버튼 하나 더 추가해봤자 소용없음 - self-review만으로도 **디버그 출력** 같은 실수를 잡을 수 있음 - 우리 팀은 PR 템플릿에 self-review 체크리스트를 넣었음 당연한 일 같지만 실제로는 도움이 됨 - Amazon의 **리더십 신뢰도**가 떨어지고 있음 베테랑 퇴사, **AI 품질 저하**, 잦은 장애로 인해 엔지니어링이 무너지는 인상임 - 오랜 시니어들이 **AI 코드 리뷰**만 하며 시간 보내고 싶지 않은 건 당연함 - 의사결정자들이 **파이프라인 병목**을 이해하지 못하는 듯함 AI가 10배 빠르게 diff를 만들어도 리뷰가 병목이면 전체 속도는 같음 결과적으로 **비용과 불확실성만 증가**함 - 다음 단계는 “AI가 AI 코드를 리뷰”하자는 아이디어일 듯함 - AI 코드 리뷰를 PR 단계에서 하게 되면 **생산성 이점이 사라짐** AI는 10분 만에 기능을 만들지만, 사람 리뷰는 10~20배 시간이 듦 진짜 어려운 건 “무엇을 왜 만드는가”와 “제대로 만들었는가”를 아는 것임 AI는 이 두 가지를 아직 못함 - CEO 입장에서 보면, 결국 사람이 직접 검토해야 한다면 **AI 속도 이점**이 무의미함 LLM이 생산과 리뷰를 모두 잘할 때까지는 **리스크만 커짐** - 시니어가 모든 PR을 승인해야 한다면 **전문 코드 리뷰어**가 되는 셈임 현실적으로 불가능한 정책임 - AI 옹호자들은 언젠가 모델이 개선되어 **리뷰 병목이 사라질 것**이라 믿음 그때는 테스트 후 바로 배포하는 시대가 올 것이라 함 - 리더십이 이런 현실을 모른다는 게 놀라움 - 사실 리더십도 알고 있을 것임. **코드 품질 저하**를 막기 위한 브레이크일 뿐임 - 코드 리뷰의 본질은 **에러 탐지**가 아니라 **팀 동기화와 학습**임 리뷰를 통해 설계와 표준을 공유하고, 주니어를 교육하며, 다양한 시각을 반영함 이런 과정이 에러 자체를 줄이는 핵심임 - 데밍의 말처럼 “검사는 품질을 개선하지 않는다”는 원칙이 소프트웨어에도 적용됨 잘못된 설계 방향으로 가면 되돌리기 어렵기 때문임 - **AI 열풍**에 쏟는 시간과 비용이 너무 큼 - 하지만 지금은 **쫓을 다른 대상이 없음** - 코드를 검증하지 않는 건 결국 **도박**과 같음 - 앞으로 **중요 인프라 소프트웨어**는 어떻게 될까 걱정됨 항공 소프트웨어도 이런 흐름에 휩쓸리면 **치명적 결과**가 날 수 있음 - 그래도 핵심 인프라 코드는 여전히 **사람 중심**으로 작성될 것임 AI는 품질 향상을 위한 **보조 도구**로 쓰일 가능성이 큼