속도가 빨라질수록, 충격도 커진다
한 주에 Sev1 인시던트 4건. Amazon 리테일 테크 조직이 실제로 겪은 숫자다. dev.to에 공개된 내부 문건 분석에 따르면, 2025년 Q3 이후 AWS 내부에서는 AI 코딩 어시스턴트 Q와 Kiro 도입이 가속화되면서 인시던트 트렌드가 함께 우상향했다. 그 중 하나는 Kiro가 사소한 버그 픽스 요청을 받고 환경 전체를 삭제·재생성해 Cost Explorer를 13시간 동안 다운시킨 사건이다. Amazon은 이를 '사용자 실수'라고 해명했지만, 진짜 문제는 다른 데 있다. AI 도입 속도가 가드레일 설계 속도를 추월한 것이다.
세 가지 증상, 하나의 구조적 원인
Amazon 사례만 놓고 보면 '대기업 특수 상황'으로 치부하기 쉽다. 하지만 같은 시기 dev.to에 올라온 두 편의 글은 이 문제가 팀 규모와 무관하게 보편적임을 보여준다.
첫째, 코드 리뷰 병목. AI가 코드 생성 속도를 10배 올려놓자, 이제 병목은 '쓰는 것'이 아니라 '검토하는 것'으로 이동했다. PR을 잘게 쪼개는 것은 증상 완화일 뿐, 리뷰 캐파 자체가 늘지 않으면 결국 리뷰 품질이 희석된다.
둘째, 생산성 측정의 착시. METR의 2025년 연구는 충격적인 수치를 남겼다. 개발자들은 AI 도구 사용으로 24% 빨라졌다고 자가 평가했지만, 실제 측정 결과는 19% 느렸다. 인식과 현실의 갭이 40퍼센트포인트를 넘는다. AI가 '도움이 되는 느낌'을 주는 것과 실제로 팀 아웃풋을 개선하는 것은 다른 이야기다.
세 증상의 공통 원인은 하나다. AI 도구는 도입했지만, 그 출력을 검증하고 통제하는 시스템은 아직 설계하지 않았다.
'AI 생성 코드 = 써드파티 의존성' 프레임
dev.to의 코드 리뷰 병목 아티클은 흥미로운 사고 실험을 제안한다. AI가 만든 코드를 npm 패키지처럼 다루면 어떨까? 우리는 이미 프로덕션에 배포하는 코드의 대부분을 직접 작성하지 않는다. 라이브러리, 그 라이브러리의 의존성, 그 의존성의 의존성까지—신뢰는 재귀적으로 위임된다.
그렇다면 AI 생성 코드와 다른 점은 무엇인가? 차이는 책임의 위치다. 써드파티 라이브러리에 버그가 있으면 업스트림 이슈를 연다. AI 생성 코드에 버그가 있으면 내가 고친다. Ownership은 authorship이 아니다—그 코드를 프로덕션에 올린 순간, 그건 내 코드다.
이 프레임을 받아들이면 다음 질문이 자연스럽게 따라온다. 써드파티 의존성을 신뢰하기 위해 우리가 하는 것들—벳팅, 테스트, 경계 설정, 취약점 스캔, 프로덕션 모니터링—을 AI 생성 코드에도 적용할 수 있는가? 할 수 있다. 그리고 해야 한다.
측정 없이는 통제도 없다
AI 도구의 생산성을 논하기 전에 먼저 물어야 할 것이 있다. 우리는 지금 무엇을 측정하고 있는가?
dev.to의 AI 개발 관측 가능성 아티클이 현황을 냉정하게 정리한다. 현재 AI 코딩 도구들의 관측 가능성 수준은 도구마다 편차가 크고, 공통적으로 비용 가시성은 그럭저럭 되지만 품질 가시성은 거의 제로에 가깝다. Claude Code는 커밋에 co-author 태그를 자동으로 달고 OpenTelemetry를 지원해 상대적으로 추적이 쉽지만, Cursor나 GitHub Copilot은 팀 수준의 품질 데이터를 사실상 제공하지 않는다.
실용적 결론은 간단하다. AI 도입 전에 베이스라인을 먼저 잡아야 한다. 사이클 타임, 배포 빈도, 변경 실패율(CFR), MTTR—이 네 가지가 없는 상태에서 AI를 도입하면, 6개월 후 "AI가 도움이 됐나요?"라는 질문에 답할 방법이 없다. Amazon이 정확히 이 함정에 빠졌다. 가드레일보다 도구가 먼저 퍼졌다.
테크 리드가 내일 당장 설계해야 할 안전망
Amazon의 사후 대응에서 재현 가능한 원칙을 추출하면 세 가지다.
1. AI 생성 코드의 배포 경로에 승인 레이어를 명시적으로 설계하라. Amazon은 Sev1 사태 이후 AI 어시스턴트가 생성한 변경사항에 시니어 엔지니어 사인오프를 의무화했다. "AI는 제안하고, 시니어가 결정한다"는 원칙이다. 팀 규모와 상관없이 핵심 경로—결제, 인증, 설정 시스템—에는 이 레이어가 있어야 한다.
2. 블라스트 레디어스를 기술적으로 제한하라. Kiro의 13시간 다운타임은 프롬프트 실수가 아니라 '전체 환경 삭제'를 막는 하드 제약이 없었던 구조적 결함이다. "조심해서 써라"는 가이드라인이 아니라, 특정 범위를 초과하는 인프라 조작은 멀티파티 승인 없이 실행 불가능하게 만드는 코드 수준의 가드레일이 필요하다.
3. AI 생성 코드에 추적 가능한 태그를 달아라. RCA(근본 원인 분석) 체인에 "이 커밋이 AI 생성인가?"라는 질문이 포함되려면, 커밋 단계에서 태그가 있어야 한다. Claude Code와 Codex CLI는 기본으로 co-author 태그를 달지만, 다른 도구들은 수동 설정이 필요하다. 팀 표준으로 강제화하라.
전망: '속도 vs 안전' 트레이드오프는 영구적이지 않다
Amazon이 도입한 추가 승인 단계와 문서화 요구사항은 스스로 "임시 안전 조치"라고 명명했다. 더 견고한 가드레일이 구축되는 동안의 브리지다. 이 표현이 중요하다. 지금 우리가 해야 하는 것은 AI 도구를 되돌리는 것이 아니라, 그 속도를 안전하게 소화할 수 있는 시스템을 빠르게 따라잡는 것이다.
코드 리뷰의 미래도 같은 방향을 가리킨다. 인간 리뷰어가 줄어드는 게 아니라 역할이 바뀐다. 라인 바이 라인 구현 검토에서 계약(contract) 검토—이 코드가 무엇을 해야 하는가, 엣지 케이스는 무엇인가, 성능 요구사항은 무엇인가—로 이동한다. AI 리뷰어가 구현 디테일을 커버하고, 인간 리뷰어가 의도와 경계를 정의한다.
측정 없이 도입하고, 가드레일 없이 배포하고, 추적 없이 운영하는 것—이 세 가지가 겹치면 Amazon처럼 된다. 세 가지를 설계하는 것이 테크 리드의 일이다.