▲

잇따른 장애 후, Amazon이 AI 지원 코드 변경에 시니어 엔지니어 승인 의무화

 (arstechnica.com)
15P by GN⁺ 20시간전 | ★ favorite | 댓글 6개
  • 최근 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 도입 확산 속에서 인적 검증 절차의 중요성을 다시 부각시키는 사례로 평가됨
▲
click 14시간전  [-]

AI 코드를 시니어가 리뷰하면 안전하다고 보장할 수 없죠
crowdstrike 사건 이 AI때문은 아니었고
heartbleed도 AI가 없던 시대의 사고죠

결론은 누군가에게는 책임을 지우겠다는 게 골자인데
법적으로 책임질 인간이 있어야해서 우리는 대체되지 않을거라고 하시던 세무사분들의 블랙유머가 떠오르네요

답변달기
▲
sea715 14시간전  [-]

그쵸 그래서 AI에이전트에 법적 서명같은걸 넣지 않는이상 지속될거 같아요..

답변달기
▲
click 13시간전  [-]

그럼 앤트로픽이나 openai 사용 비용이 천문학적으로 높아져야겠네요
API 한번 호출마다 보험료를 내야할테니

답변달기
▲
yeobi222 12시간전  [-]

세무사는 감방가는 역할이라고 했는데 보험사가 감방을 대신 가주진 않아서 결국은...

답변달기
▲
sea715 13시간전  [-]

으음.. 망상이긴하지만 iam처럼 뭔가 생기지 않을까라는.. 느낌입니다

답변달기
▲
GN⁺ 20시간전  [-]
Hacker News 의견들

  • 이번 “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는 품질 향상을 위한 보조 도구로 쓰일 가능성이 큼
답변달기