“아마존이 AI로 작성한 코드에 시니어 승인을 의무화했다”는 문장은 강하다. 하지만 공개된 보도를 따라가면 조금 더 조심해서 말해야 한다. 최근 장애 뒤 내부 브리핑에서 생성형 AI를 이용한 변경과 큰 피해 범위가 함께 언급됐고, 일부 AI 보조 변경에 상급 검토를 두는 방향이 전해졌다. 모든 장애의 원인이 AI였다고 아마존이 공식 확인한 것은 아니다. 핵심은 AI를 금지한 사건이 아니라, 빨라진 코드 작성 속도에 검토 절차가 따라가지 못한 장면이다.
보도에서 확인되는 범위
TechRadar와 Tom’s Hardware 등은 아마존 내부에서 최근 장애의 반복과 큰 영향 범위를 다룬 회의가 있었다고 보도했다. 보도에는 생성형 AI가 보조한 변경이 언급됐고, 주니어·중급 엔지니어의 관련 변경을 시니어가 확인하는 절차가 포함됐다는 내용이 나온다. 대규모 서비스 회사가 코드 검토를 강화하는 일 자체는 낯설지 않다.
그래서 “AI가 사고를 냈다”로 끝내면 오히려 배울 점을 놓친다. 사람이 직접 쓴 코드도 장애를 만든다. 차이는 AI 도구가 그럴듯한 변경을 훨씬 많이, 훨씬 빨리 만들 수 있다는 데 있다. 오류 확률이 그대로여도 변경량이 늘면 검토해야 할 위험의 총량은 커진다.
왜 리뷰가 더 어려워졌나
AI가 만든 코드는 문법이 매끄럽고 테스트 이름도 그럴듯하다. 리뷰어가 “대충 맞아 보인다”고 지나치기 쉽다. 문제는 저장소 안의 규칙보다 운영 환경의 숨은 조건에서 나온다. 특정 지역에만 켜진 플래그, 오래된 배치 작업, 복구 시나리오, 예상보다 큰 트래픽이 코드 조각만 봐서는 드러나지 않는다.
한 번에 바뀌는 파일이 많아지는 것도 부담이다. 작은 변경 열 개를 따로 이해하는 대신 AI가 만든 큰 패치를 한 번에 받으면, 리뷰어는 어디가 중요한지 찾는 데 시간을 쓴다. 생성 속도가 빨라질수록 변경 단위를 작게 유지하는 규율이 더 필요하다.
시니어 승인의 함정
승인자를 한 명 더 넣는다고 안전이 자동으로 생기지는 않는다. 시니어 엔지니어가 매일 수십 건의 AI 패치를 빠르게 승인해야 한다면 도장은 남아도 검토는 얕아진다. 책임만 위로 올리고 작업 맥락을 전달하지 않으면 병목과 피로가 쌓인다.
좋은 리뷰는 “AI가 썼는가”보다 위험을 기준으로 강도를 나눈다. 결제·권한·데이터 삭제·배포 설정은 작은 변경도 두 사람이 보고, 문구 수정이나 내부 도구의 되돌릴 수 있는 변경은 자동 테스트로 빠르게 통과시킬 수 있다. 사람의 시간을 모든 코드에 똑같이 쓰지 말고, 실패했을 때 크게 번지는 곳에 집중해야 한다.
팀에서 바로 바꿀 수 있는 것
- AI가 만든 변경도 작성자가 한 줄씩 설명할 수 있을 때만 리뷰를 요청한다.
- 큰 패치를 기능 단위로 나누고 롤백 방법을 PR에 적는다.
- 테스트 통과뿐 아니라 운영 지표와 알람 변화를 확인한다.
- 배포 뒤 일정 시간은 변경 작성자가 직접 상태를 본다.
- 고위험 변경은 승인과 실제 배포 권한을 분리한다.
도구 사용 여부를 숨기지 않는 문화도 필요하다. AI를 썼다고 불이익을 받을까 봐 감추면 리뷰어는 코드가 만들어진 과정을 모른 채 결과만 본다. 반대로 “AI가 만들었다”는 말을 책임을 줄이는 핑계로 써서도 안 된다. 최종 변경을 제출한 사람이 설명과 복구를 맡아야 한다.
AI 코딩의 속도를 버리지 않으려면
AI 코딩 도구의 장점은 반복 작업과 탐색 시간을 줄이는 데 있다. 보일러플레이트, 테스트 초안, 문서 정리는 여전히 큰 도움을 준다. 운영 변경까지 같은 속도로 밀어붙일 때 문제가 커진다. 개발 단계의 속도와 배포 단계의 속도를 분리하면 둘 다 얻을 수 있다.
AI가 코드를 더 많이 만들수록 팀이 잘해야 하는 일은 작성이 아니라 선택, 검증, 복구다. 이번 논란을 특정 회사의 실수담으로만 보면 금방 잊힌다. 내 팀의 리뷰 대기 시간이 갑자기 늘었거나 한 PR의 크기가 커지고 있다면 이미 같은 문제의 초입일 수 있다.
확인한 자료: TechRadar 보도 · Tom’s Hardware 보도. 내부 보도에 기반한 내용과 아마존이 공식 확인한 사실을 구분해 적었다.