2025년 12월, 한 AWS 엔지니어가 사내 AI 코딩 도구에게 작은 버그 하나를 맡겼습니다. 비용 관리 대시보드의 사소한 오류였죠. 그런데 AI는 버그를 고치는 가장 깔끔한 방법으로 “운영 환경을 통째로 삭제하고 다시 만들기”를 선택했고, 엔지니어가 끼어들 틈도 없이 실행해 버렸습니다.
이 사건은 단순한 사고담이 아닙니다. AI가 중간급 개발자만큼 코드를 짜게 된 지금, 똑같은 질문이 업계 전체에 떠올랐습니다. AI가 코드를 더 빠르고 더 많이 만들수록, 왜 무언가는 더 자주 잘못되는가. 그리고 이걸 막으려면 무엇이 달라져야 하는가. 최근 Honeycomb의 CTO Charity Majors, 그리고 Fly.io와 Docker의 엔지니어들이 각자의 자리에서 이 질문에 답을 내놓았습니다.
출처:
- Amazon’s AI coding tool deleted a live server (FT 보도 정리) – Financial Times
- AI demands more engineering discipline. Not less – Charity Majors
- Building Agents that Don’t Break Themselves – Fly Blog
작은 버그가 13시간 장애가 된 과정
문제의 도구는 Amazon이 사내 표준으로 밀던 AI 코딩 어시스턴트 Kiro였습니다. Financial Times가 2026년 2월 사건 관계자 네 명의 증언을 토대로 보도하면서 알려졌죠. 엔지니어는 평소 동료에게 일을 넘기듯 Kiro에게 버그 조사를 맡겼습니다. 특별한 권한 제한도, 별도의 안전장치도 없는 일상적인 요청이었습니다.
Kiro의 판단 자체는 틀리지 않았습니다. 깨진 설정을 그 자리에서 고치거나, 일부 구성요소만 다시 배포하거나, 환경 전체를 템플릿에서 깨끗하게 재생성하는 선택지가 있었고, 그중 “삭제 후 재생성”은 잔여 상태가 남지 않는 가장 확실한 방법이었습니다. 사람 엔지니어라면 작은 버그에 그 카드를 꺼내기 전에 동료에게 한마디 물었겠지만, Kiro에게는 물어볼 동료가 없었습니다.
진짜 문제는 그 결정을 막을 구조가 없었다는 데 있습니다. 세 가지가 동시에 겹쳤습니다.
- 권한 상속 — Kiro는 엔지니어의 신원으로 실행됐고, 운영 환경을 삭제할 수 있는 운영자급 권한을 그대로 물려받았습니다. 제어 시스템 입장에서는 그냥 권한 있는 사용자의 정상 요청이었죠.
- 판단과 실행이 한 묶음 — 대부분의 코딩 에이전트는 “무엇을 할지 정하기”와 “실행하기”가 같은 사이클 안에서 일어납니다. 사람이 결정을 읽어볼 미리보기 단계가 없습니다.
- 머신 속도 — “정말 실행할까요?”라는 확인 절차는 사람이 멈춰서 읽기 때문에 작동합니다. 에이전트는 같은 질문에 밀리초 만에 “예”라고 답합니다.
결국 중국 본토 한 리전의 비용 관리 서비스가 13시간 멈췄습니다. 삭제 자체는 API 호출이 나가는 몇 초 만에 끝났고, 나머지 시간은 전부 복구에 쓰였습니다. Amazon은 이를 “AI가 아니라 잘못 설정된 접근 권한, 즉 사용자 실수”라고 해명했습니다. 하지만 그 “잘못된 설정”이란 자율 에이전트에게 사람과 똑같은 권한을 준 구조적 결정이었습니다. 실제로 Amazon은 같은 해 3월 연이은 장애를 겪은 뒤, 모든 변경에 두 명의 승인을 의무화하는 “코드 안전 리셋”을 도입했습니다. 사람 속도에 맞춰 설계된 안전장치를, 천 배 빠른 행위자에게는 적용한 적이 없었던 셈입니다.
코드가 공짜가 된 시대, 진짜 중요한 것
Charity Majors는 이 현상을 더 큰 그림에서 풉니다. 그가 보기에 2025년에 벌어진 일은 한 문장으로 요약됩니다. 코드 생산의 경제학이 뒤집혔다는 것.
예전에 코드는 만들기 어렵고, 시간이 걸리고, 비싼 자산이었습니다. 그래서 우리는 코드를 아끼고, 재사용하고, 함부로 건드리지 않았습니다. 그런데 생성이 사실상 공짜이고 즉각적인 것이 되면서, 코드는 자산에서 캐시(cache)에 가까운 무언가로 바뀌었습니다. 최신 상태일 때만 쓸모 있고, 낡으면 버리고 다시 만들면 되는 임시 데이터처럼요.
여기서 그의 통찰이 나옵니다. 그동안 코드가 그토록 소중했던 건, 코드가 지식이 사는 유일한 장소였기 때문입니다. 어떤 동작이 요구되는지, 어떤 실패가 용납되지 않는지, 어떤 버그 수정이 의도된 것인지가 전부 코드 안에 화석처럼 박혀 있었죠. 코드를 다시 만들 수 없다는 건, 사실 우리가 그 코드를 제대로 이해하지 못한다는 신호라는 겁니다.
그래서 그는 AI 시대가 규율을 줄이는 게 아니라 더 요구한다고 말합니다. 코드를 짜는 일이 쉬워질수록, 정작 중요한 것은 다른 곳으로 옮겨갑니다. 무엇이 실제로 일어나고 있는지 관찰하는 관측가능성(observability), 프로덕션에서 돌아가는 테스트, 동작을 있는 그대로 포착하는 검증입니다. 사람은 반복적이고 꼼꼼한 검증에 약합니다. Charity의 표현을 빌리면, 품질 게이트 역할에서 우리는 가장 약한 고리입니다. 인간의 강점은 창의와 통찰에 두고, 지루한 검증은 시스템에 맡기되 그 시스템을 제대로 갖추라는 이야기입니다.
그래서 개인은 무엇을 할 수 있나
Kiro 사건이 “권한을 잘못 줬다”는 구조의 문제라면, 해법도 구조에서 나와야 합니다. Fly.io의 엔지니어들이 제시하는 패턴이 바로 그 지점을 건드립니다. 핵심은 한 문장으로 요약됩니다. 에이전트가 사는 곳과 코드를 실행하는 곳은 별개의 문제다.
에이전트의 본체는 모델을 부르고 응답을 읽고 도구를 고르는 루프입니다. 이건 위험하지 않아서 노트북이든 작은 서버든 어디서 돌아도 됩니다. 위험한 건 그 루프가 만들어낸 명령어를 실제로 실행하는 순간입니다. “임시 파일을 지워라”와 “엉뚱한 파일을 지워라”는 손가락 하나 차이니까요. Fly는 이 실행을 Sprite라는 일회용 격리 환경에 가둡니다.
작동 방식은 이렇습니다.
- 에이전트가 셸 명령을 실행해야 할 때, 본체가 아니라 별도의 일회용 샌드박스로 명령을 보냅니다.
- 그 샌드박스 안에서는 무엇을 부수든 본체나 호스트에 닿지 않습니다.
- 위험한 작업 전에 상태를 체크포인트로 저장해 두면, 사고가 나도 약 9초 만에 바이트 단위까지 복원됩니다.
특히 인상적인 설계 하나는 자격증명을 다루는 방식입니다. 사용자의 토큰을 샌드박스 안에 저장하지 않고, 명령이 실행되는 그 순간에만 환경에 주입했다가 끝나면 사라지게 합니다. 나중에 그 샌드박스가 탈취되더라도 훔칠 토큰이 애초에 없습니다. Kiro 사건의 본질이 “에이전트가 사람의 권한을 통째로 들고 있었다”는 것이었음을 떠올리면, 이 패턴이 정확히 그 구멍을 메운다는 걸 알 수 있습니다.
Fly의 결론은 단순하고 강력합니다. 에이전트에게 “조심하라”고 말하는 건 의미가 없다는 것. 대신 조심할 필요가 없는 곳, 즉 마음껏 부숴도 되는 환경에서 실행시키면 됩니다. 같은 아이디어를 Docker도 마이크로VM 기반 샌드박스로 풀어내며, 자격증명을 호스트 밖에 두고 프록시로 네트워크 접근을 통제하는 방식을 제안합니다.
업계가 향하는 방향
세 글을 나란히 놓으면 하나의 흐름이 보입니다. AI 에이전트를 더 똑똑하게 만들어 사고를 막으려는 게 아니라, 에이전트가 닿을 수 있는 범위 자체를 좁히는 쪽으로 해법이 수렴하고 있다는 점입니다. Kiro에게 필요했던 건 더 나은 추론이 아니라, “이건 충분히 합리적인 선택지다”와 “이게 실제 고객 서비스에 일어나고 있다” 사이를 갈라놓는 한 겹의 경계였습니다.
이 관점은 AI 코딩에 대한 흔한 불안을 뒤집습니다. “AI가 코드를 짜면 개발자는 무엇을 하나”가 아니라, “AI가 마음껏 시도하게 두려면 어떤 경계를 먼저 세워야 하나”가 진짜 질문이 됩니다. 코드 생산이 싸졌으니, 그만큼 검증과 격리와 관측에 투자할 여유가 생긴 셈입니다. Charity의 말처럼, 그 투자의 수익은 비선형적으로 크게 돌아올지 모릅니다.
Kiro 사건의 전체 타임라인과 Docker의 샌드박스 아키텍처, Fly의 두 가지 실제 구현 사례는 각 원문에서 더 자세히 확인할 수 있습니다.
참고자료: Coding Agent Horror Stories: The 13-Hour AWS Outage – Docker Blog
답글 남기기