AWS가 공개한 4.5배 생산성 팀의 에이전틱 개발 습관

URL: https://www.youtube.com/watch?v=O9iL08X9zMo 날짜: 2026-08-30 채널: AgentOS 발표 원출처: AWS 시니어 프린시펄 엔지니어 Claire Liguori의 AI Engineer World's Fair 발표

---

📌 핵심 질문 — 같은 AI 코딩 도구를 받고도 왜 팀의 생산성은 갈렸는가

==아마존의 실험에서 생산성을 가른 것은 AI 코딩 도구의 종류가 아니라, 에이전트가 일할 수 있도록 팀의 작업 방식과 코드베이스를 의도적으로 바꿨는지 여부였다.==

• 동일한 AI 코딩 도구를 받은 Amazon Stores 50개 팀 중 절반은 3배 미만, 다른 절반은 중앙값 4.5배의 프로덕션 배포 속도 향상을 보였다.
• 높은 성과를 낸 팀은 에이전트에 필요한 컨텍스트를 문서화하고, 코드베이스와 도구를 정리하고, 사람의 대기 루프를 줄였다.
• 코드 작성이 빨라진 뒤에는 번아웃, 조직의 조급함, 의사결정과 출시 승인이라는 새로운 병목이 생겼다.

이 영상은 AI를 기존 개발 과정 위에 얹는 것과 개발 시스템 자체를 에이전트 중심으로 다시 설계하는 것의 차이를 설명한다. 핵심은 에이전트에게 코드를 대신 써 달라고 부탁하는 것이 아니다. 에이전트가 긴 시간 독립적으로 일하고, 스스로 오류를 감지하고, 사람이 정한 품질 기준을 통과했을 때만 돌아오게 만드는 것이다. 이를 위해서는 프롬프트보다 코드베이스의 구조, 오류 메시지, 테스트, 의도 문서, 팀의 결정 속도가 함께 바뀌어야 한다.

1. 실험의 출발점 — 도구는 같았지만 결과는 두 갈래였다

1.1. AI 코딩 도구의 네 단계

1. 인라인 자동완성

   1. 다음 코드 제안: 초기 도구는 개발자가 입력하는 다음 줄이나 다음 함수를 예측해 작성했다.
   2. 작업 방식의 변화는 제한적: 개발자는 여전히 코드를 직접 입력하고, 자동완성은 타이핑 속도를 보조하는 수준이었다.

2. 코드베이스 질의형 채팅

   1. 코드에 대해 질문: 개발자는 자신의 코드 구조와 오류를 챗봇에게 물을 수 있게 됐다.
   2. 사람이 계속 루프에 남음: 모델에게 질문하고 답변을 읽은 뒤 다음 질문을 보내는 상호작용이 기본이었다.

3. 바이브 코딩

   1. 대략적인 의도와 대량 생성: 개발자가 원하는 결과를 자연어로 설명하면 AI가 많은 코드를 한 번에 생성한다.
   2. 검토와 왕복이 병목: 생성된 코드가 의도와 다르면 사람이 다시 설명하고, 테스트가 실패하면 다시 고쳐 달라고 요청하는 루프가 반복된다.

4. 프론티어 개발(Frontier Development)

   1. 에이전트가 장시간 독립 실행: 개발자는 코드의 1~2%만 직접 쓰고 나머지는 에이전트가 작성하도록 작업을 재구성한다.
   2. 여러 에이전트 병렬 운용: 에이전트가 몇 시간 동안 사람의 개입 없이 실행되며, 개발자는 여러 작업을 병렬로 맡긴다.
   3. 자기검증 조건 포함: 에이전트는 구현뿐 아니라 컴파일, 테스트, 커버리지, 통합 검증 같은 완료 조건도 수행한다.

1.2. 개인 사용 경험과 팀 실험의 차이

1. 혼자 쓴 AI 도구의 제한적인 개선

   1. 10~20% 정도의 체감 향상: Claire Liguori는 자동완성·채팅·바이브 코딩을 직접 사용했지만 작업 속도가 많아야 10~20% 빨라졌다고 설명했다.
   2. 배포 횟수의 작은 변화: 한 달에 열 번 배포하던 팀이 열한 번이나 열두 번 배포하는 정도의 변화로 표현된다.

2. 아마존 내부 팀의 큰 격차

   1. 절반은 3배 미만: 같은 도구를 받은 50개 팀 가운데 25개 팀은 프로덕션 배포 속도가 3배 미만 향상됐다.
   2. 절반은 중앙값 4.5배: 나머지 25개 팀은 중앙값 4.5배의 개선을 보였고, 일부 팀은 10배 이상 빨라졌다.
   3. 측정 대상의 차이: 단순히 커밋을 몇 개 만들었는지가 아니라, 코드 변경이 실제 고객에게 얼마나 빨리 도달하는지인 프로덕션 배포 속도를 측정했다.

3. 핵심 진단

   1. 도구를 추가한 팀: 기존 프로세스 위에 Kiro 같은 도구를 얹었다.
   2. 방식을 바꾼 팀: 에이전트가 독립적으로 일할 수 있도록 컨텍스트·코드베이스·테스트·요구사항 전달 방식을 바꿨다.
   3. 속도 향상이 아니라 작업의 종류가 바뀜: 한 사람이 조금 더 빨리 코딩한 것이 아니라, 사람이 직접 수행하던 작업 흐름이 에이전트가 병렬로 처리하는 흐름으로 바뀌었다.

2. 프론티어 개발이 실제로 작동한 사례

2.1. Bedrock 추론 데이터 플레인 — 30명이 18개월 걸릴 일을 6명이 76일에

1. 문제의 규모

   1. Amazon Bedrock: AWS에서 Claude·GPT 같은 대규모 언어 모델을 호스팅하는 서비스다.
   2. 추론 데이터 플레인: 사용자 요청을 받아 모델을 실행하고 응답을 반환하는 핵심 경로이며, Bedrock 전체에서 가장 무거운 부분 중 하나다.
   3. 기존 추정: 새 데이터 플레인을 만들고 고객과 모델을 이전하는 작업을 30명이 18개월 동안 해야 한다고 추산했다.

2. 프론티어 팀의 선택

   1. 규모를 줄임: 팀은 예상 인원과 기간을 그대로 받아들이지 않고, 6명을 선택해 Kiro를 이용한 개발에 들어갔다.
   2. 76일 만에 구축: 6명이 새 추론 데이터 플레인을 76일 만에 완성했다.
   3. 최대 20배 개선의 증거: 이 사례는 아마존 내부에서 처음으로 이 정도의 개선 가능성을 보여준 Pathfinder 팀으로 소개됐다.

3. 일반화할 때의 주의점

   1. 최고 수준의 인력: 6명 모두가 평범한 팀원이 아니었고, 회사의 최상위 엔지니어들이 포함됐다.
   2. 전문 분야: 분산 시스템과 대규모 언어 모델 아키텍처에 전문성이 있었으며, 그중에는 Distinguished Engineer도 두 명 있었다.
   3. 결론의 범위: 이 사례만으로 모든 팀이 20배 빨라진다고 말할 수 없다. 에이전트 도입 효과와 팀의 기본 역량을 분리해 봐야 한다.

2.2. Prime Video 실험 — 더 평범한 팀에 적용하기

1. 실험 설계

   1. 다른 여섯 명: 이번에는 회사 최고의 엔지니어로 구성된 Bedrock 팀이 아니라 Prime Video의 다른 여섯 명을 선택했다.
   2. 열흘간 Kiro 사용: 여섯 명에게 Kiro를 집중적으로 사용하게 하고 프로젝트 작업 결과를 관찰했다.
   3. 사전 준비: 팀의 시니어 엔지니어가 앞선 3주 동안 작업을 잘게 나누고 요구사항을 명확히 작성해 두었다.

2. 관찰된 수치

   1. 납기 추정: 프로젝트 예상 기간이 90주에서 24주로 줄어 73% 단축됐다.
   2. 커밋 수: 기존 기준 96개에서 열흘 동안 556개로 늘어 5.8배가 됐다.
   3. 높은 생산성의 형태: 에이전트가 구현을 이어 갈 수 있도록 작업 범위와 완료 조건이 먼저 정리되어 있었다.

3. 이 실험의 단서

   1. 온콜과 회의가 없었음: 여섯 명은 실험 기간에 온콜을 맡지 않았고 회의도 거의 없었다.
   2. 방해가 적었음: 일반적인 업무일처럼 긴급 요청과 업무 전환에 노출되지 않았다.
   3. 잘 설계된 스프린트: 이미 시니어 엔지니어가 일을 쪼개 두었기 때문에 여섯 명은 준비된 작업을 실행하는 데 집중할 수 있었다.
   4. 현실 업무와의 차이: 이는 일상적인 개발팀의 평균 생산성이라기보다, 방해가 통제된 스프린트 한 번의 결과였다.

2.3. Amazon Stores 50개 팀 — 기존 코드베이스에서의 일상 실험

1. 일반 팀을 선택한 이유

   1. 조직 범위: Amazon.com, 각국의 리테일 사이트, 오프라인 매장을 담당하는 Amazon Stores 조직을 관찰했다.
   2. 혼합된 경력: 신입·초기 경력자, 중간 경력자, 시니어가 자연스럽게 섞인 평범한 팀들이었다.
   3. 브라운필드 환경: 처음부터 새로 만드는 그린필드 프로젝트가 아니라, 이미 운영 중인 시스템과 기존 코드베이스에서 일했다.

2. 측정 방식

   1. 커밋 대신 배포 속도: 코드가 얼마나 많이 작성됐는지가 아니라, 변경 사항이 프로덕션과 고객에게 얼마나 빨리 나가는지 측정했다.
   2. 결과의 양극화: 50개 팀은 3배 미만 개선 그룹과 중앙값 4.5배 개선 그룹으로 나뉘었다.
   3. 도구보다 작업 방식: 약 90%의 팀이 Kiro를 포함한 내부 도구를 사용했지만, 도구를 사용했다는 사실 자체가 성과 차이를 설명하지 못했다.

3. 4.5배 팀을 만든 다섯 가지 습관

3.1. 습관 1 — 에이전트 컨텍스트에 투자한다

1. 사람의 머릿속에 있던 지식을 밖으로 꺼냄

   1. 암묵지의 문제: 코드의 역사, 팀의 선호, 하지 말아야 할 변경, 운영상 주의점은 대개 사람의 머릿속에 남아 있다.
   2. 기존 전달 방식: 이런 지식은 슬랙 대화, 온보딩 멘토링, 코드 리뷰, 스탠드업, 스프린트 계획을 통해 사람에게 전달됐다.
   3. 에이전트에는 문서가 필요함: 에이전트가 같은 맥락을 읽으려면 이 지식을 파일과 명시적인 규칙으로 정리해야 한다.

2. 실패를 컨텍스트 개선 신호로 사용함

   1. 첫 번째 질문: 에이전트가 실수하거나 내 방식과 다르게 행동할 때 “스킬 파일이나 스티어링 파일에 무엇이 빠졌는가?”를 묻는다.
   2. 두 번째 질문: 새 모델이 출시될 때마다 “이 규칙이 아직도 필요한가?”를 확인한다.
   3. 실패의 재사용: 한 번의 수정으로 끝내지 않고, 반복되는 실패를 에이전트가 다음 작업부터 예방하도록 컨텍스트에 반영한다.

3. 오래된 규칙도 부채가 됨

   1. 모델 세대에 따른 차이: Claude 3.7 시기에는 모델의 나쁜 습관을 막기 위해 “이것을 하지 말라”는 규칙을 많이 적어야 했다.
   2. 규칙의 감소: 영상에서는 2025년 11월 Opus 4.5 이후 이런 규칙의 필요성이 크게 줄었다고 설명한다.
   3. 정기적인 청소: 새 모델이 이미 해결한 문제에 대한 오래된 규칙은 품질을 높이지 않고 컨텍스트만 길게 만든다. Claude Code의 CLAUDE.md를 주기적으로 정리하는 것과 같은 원리다.

3.2. 습관 2 — 느려져야 빨라진다

1. 초기 생산성 하락을 받아들임

   1. 대부분의 4.5배 팀에서 공통 현상: 거의 모든 고성과 팀은 에이전트를 도입한 직후 생산성이 먼저 떨어졌다고 답했다.
   2. 코드베이스 정비: 에이전트가 기존 코드에서 일하려면 구조와 문서, 진입점이 먼저 정리되어야 한다.
   3. 오류 메시지 개선: 기존 도구가 모호한 오류를 내면 모델은 실패 원인을 추측한다. 에이전트가 다음 행동을 결정할 수 있도록 오류 메시지를 개선해야 한다.

2. 에이전트가 길을 찾도록 개발 시스템을 바꿈

   1. 새 도구와 MCP 서버: 필요한 작업을 수행할 수 있도록 도구와 MCP 서버를 추가한다.
   2. 코드베이스 재구조화: 에이전트가 파일과 의존성을 쉽게 탐색할 수 있도록 구조를 바꾼다.
   3. 언어 변경까지 고려: 일부 팀은 Python·JavaScript 같은 동적·비정형 언어에서 타입 언어로 옮기는 과감한 선택도 했다.

3. 컴파일러와 타입 시스템의 역할

   1. 동적 언어의 어려움: 타입 정보와 컴파일러 오류가 부족하면 에이전트가 동작을 추측해야 한다.
   2. TypeScript와 Rust 사례: 영상에서는 TypeScript로 이동한 팀과, 좋은 컴파일러 오류 메시지를 제공하는 Rust가 아마존 안에서 인기를 얻었다고 설명한다.
   3. 필수 처방은 아님: 모든 팀이 언어를 바꿔야 한다는 뜻이 아니라, 에이전트가 실패를 이해할 수 있는 피드백을 코드베이스에 마련해야 한다는 의미다.

3.3. 습관 3 — 에이전트를 돌보지 말고 먹이를 준다

1. 사람이 루프에 붙어 있는 바이브 코딩

   1. 짧은 생성 대기: 에이전트가 30초에서 1분 동안 코드를 만드는 동안 사람은 화면 앞에서 기다린다.
   2. 반복 요청: 결과가 나오면 읽고, 고쳐 달라고 요청하고, 다시 기다린다.
   3. 병렬 실행 불가: 사람이 계속 루프 안에 있으면 몸이 하나이므로 에이전트 두세 개를 동시에 제대로 운용하기 어렵다.

2. 의도와 자기검증을 한 번에 전달함

   1. 나쁜 지시: “이 API에 인증을 붙여 줘”, “테스트를 추가해 줘”처럼 할 일만 짧게 던진다.
   2. 좋은 지시: API 인증을 붙이고, 유닛 테스트를 추가하고 실행하며, 코드 커버리지가 90%가 될 때까지 보완하고, 통합 테스트에서 인증까지 검증하라고 지시한다.
   3. 완료 조건 명시: 무엇을 만들지뿐 아니라 어떻게 성공을 확인할지까지 주면 에이전트가 스스로 반복 실행하고 수정할 수 있다.

3. 사람의 역할 변화

   1. 품질 기준을 정함: 사람은 매 단계의 키보드 입력자가 아니라 완료 조건과 품질 바를 설계한다.
   2. 검증된 결과만 받음: 에이전트는 컴파일되고 테스트가 통과하며 정해진 커버리지와 검증 조건을 만족했을 때 돌아온다.
   3. 개입 빈도를 낮춤: 사람은 짧은 대화에 매달리는 대신 여러 에이전트의 결과를 검토하고 방향을 조정한다.

3.4. 습관 4 — 코드를 쓰기 전에 의도를 명시한다

1. 스펙 주도 개발

   1. 아마존의 기본 방식: Amazon은 스펙 주도 개발을 많이 사용하며 Kiro에도 이 접근이 기본으로 들어 있다.
   2. 코드보다 먼저 문서화: 애매하고 복잡한 기능은 코드를 만들기 전에 목표, 사용자, 핵심 기능, 기술 요구사항을 정리한다.
   3. 문서가 대화의 단위가 됨: 코드 곳곳에 흩어진 변경을 놓고 왕복하는 것보다 하나의 스펙 문서를 놓고 의도를 조정하는 편이 비용이 낮다.

2. 바이브 코딩과의 차이

   1. 대략적인 프롬프트의 문제: 대충 기능을 설명하고 코드를 먼저 생성하면, 나중에 “그 의미가 아니었다”고 되돌리는 비용이 커진다.
   2. 의도 오류는 코드 수정으로 해결되지 않음: 요구사항 자체가 틀렸다면 생성된 코드 위에서 수십 번 왕복해도 올바른 제품에 가까워지지 않는다.
   3. 모델을 문서 작성에 활용: 스펙을 사람이 처음부터 모두 쓰지 않고 모델에게 초안을 만들게 할 수 있지만, 최종 의도와 기준은 사람이 확인해야 한다.

3.5. 습관 5 — 테스트를 왼쪽으로 당긴다

1. 장시간 자율 실행의 조건

   1. 빠른 피드백 루프: 에이전트는 실수할 수 있지만, 실수했다는 신호를 빠르게 받으면 스스로 고치며 계속 진행할 수 있다.
   2. 테스트의 위치 이동: 테스트를 마지막 출시 직전에 두지 않고 개발 과정의 앞쪽에 둔다.
   3. 검증 가능한 작업: 에이전트가 혼자 몇 시간 일하려면 매 단계가 자동으로 판정 가능해야 한다.

2. 앞으로 당긴 검증 계층

   1. 린터: 기본적인 문법과 스타일 오류를 즉시 알려 준다.
   2. 유닛·통합 테스트: 작은 동작과 여러 구성요소의 연결을 자동으로 검증한다.
   3. 성능·보안 테스트: 기능이 동작하는 것뿐 아니라 속도와 보안 기준을 만족하는지 확인한다.
   4. 기존 위생의 투자 전환: 원래도 해야 했던 엔지니어링 위생 작업이 에이전트 시대에는 생산성 향상에 직접 연결되므로 투자 가치가 커졌다.

3. 외부 서비스를 목으로 대체함

   1. 기존 통합 테스트의 한계: 실제 외부 서비스까지 연결해 테스트하면 네트워크와 서비스 상태 때문에 반복 주기가 느려진다.
   2. 결정된 응답을 주는 가짜 서비스: 외부 의존성을 목(mock)으로 바꿔 노트북 안에서도 같은 조건을 재현하게 한다.
   3. 더 빠른 에이전트 루프: 클라우드나 외부 서비스에 매번 연결하지 않아도 되면 한 번의 피드백이 빨라지고, 같은 시간에 에이전트가 더 많은 반복을 수행한다.

4. 다섯 습관 뒤에 생긴 세 가지 문제

4.1. 문제 1 — 번아웃과 검토 피로

1. 완벽한 프롬프트를 만들려는 야간 노동

   1. 밤새 실행되는 에이전트: 엔지니어들이 아침에 코드 변경 결과를 받기 위해 밤늦게까지 에이전트를 몇 시간 돌릴 완벽한 프롬프트를 만들려고 한다.
   2. 새로운 노동 형태: 코드를 직접 쓰는 시간이 줄어도, 에이전트를 설계하고 여러 결과를 관리하는 인지 노동이 늘어난다.

2. 병렬 에이전트의 인지 부하

   1. 터미널 탭 전환: 여러 에이전트를 동시에 돌리면 사람이 계속 터미널과 작업 상태 사이를 오간다.
   2. 결과 검토가 더 어려울 수 있음: AI가 만든 결과를 읽는 일이 직접 코드를 쓰는 것보다 힘들게 느껴지는 경우가 있다.
   3. 양이 늘어난 검토: 생성량이 늘면 검토하지 않아도 되는 것이 아니라, 검토 시스템과 집중력 관리가 더 중요해진다.

3. 주니어와 시니어의 차이

   1. 시니어의 코드 리뷰 근육: 시니어 엔지니어는 커리어의 상당 부분을 다른 사람의 코드를 검토하며 보냈기 때문에 AI 출력 검토에 익숙하다.
   2. 주니어의 부담: 초기 경력 엔지니어는 아직 그 검토 능력이 충분히 발달하지 않아 같은 양의 AI 코드를 읽는 일이 직접 작성보다 더 어렵게 느껴질 수 있다.
   3. 도구만으로 해결되지 않음: 이는 프롬프트 습관만으로 해결되는 문제가 아니라 경험과 리뷰 훈련의 문제다.

4.2. 문제 2 — 조직이 두 달의 투자 시간을 견디지 못함

1. 속도가 바로 오르지 않는 기간

   1. 리더의 질문: AI 도구와 좋은 모델이 있는데 왜 아직 더 빨라지지 않느냐는 질문이 반복된다.
   2. 필요한 전환 시간: 코드베이스에 투자하고 팀에 맞는 방식을 찾고 습관을 바꾸는 데 약 두 달이 걸릴 수 있다.
   3. 단기 납기 압박: 그 기간에도 매달 기능을 출시하라고 하면 팀은 기반을 만드는 대신 기존 방식 위에 도구를 뿌리는 쪽으로 되돌아간다.

2. 점진적 확산의 필요성

   1. 전사 동시 전환의 위험: 아마존이 처음부터 모든 팀에 프론티어 팀이 되라고 했다면 Bedrock, Prime Video, Amazon Stores 실험에서 얻은 학습을 확보하지 못했을 것이다.
   2. 먼저 소수 팀에서 학습: 어떤 습관과 컨텍스트가 실제로 작동하는지 50개 팀에서 확인했다.
   3. 다음 확장 단계: 영상에서는 아마존의 2026년 과제가 이 학습을 다음 2,000개 팀으로 넓히는 것이라고 설명한다.
   4. 조직별 컨텍스트: 너무 빨리 확장하면 팀이 무엇을 바꿔야 하는지 모르고, 각 조직에 맞는 컨텍스트를 찾을 시간도 잃는다.

4.3. 문제 3 — 코드가 아니라 의사결정이 병목이 됨

1. 과거의 병목

   1. 코드 작성 시간: 하나의 제품을 만드는 데 9~12개월이 걸리던 시기에는 코드를 쓰는 일이 가장 긴 구간이었다.
   2. 상대적으로 가려진 승인 시간: 만들지 결정하는 데 두 달, 출시를 승인하는 데 두 달이 걸려도 전체 9~12개월에 묻혔다.

2. 코드 작성이 1~2개월로 줄었을 때

   1. 병목의 이동: 제품을 만들기 위한 코드가 1~2개월이면 작성되면서, 앞뒤의 결정과 승인 과정이 가장 긴 막대가 된다.
   2. 결정 속도가 새로운 병목: 코드가 빨라진 것이 병목을 없앤 게 아니라 병목을 의사결정·리뷰·출시 승인으로 옮긴 것이다.
   3. 프론티어 팀의 시간 배분: 프론티어 엔지니어링 팀은 코드를 쓰는 시간보다 무엇을 만들지, 언제 출시할지 결정하는 데 더 많은 시간을 쓸 수 있다.

3. 새로운 의사결정 기술

   1. 되돌릴 수 있는 결정과 없는 결정 구분: 모든 결정을 같은 무게로 검토하면 빠른 구현의 장점이 사라진다.
   2. 결정의 비대칭성: 되돌릴 수 있는 결정은 빠르게 내리고, 되돌리기 어려운 결정에는 더 많은 검토를 배정해야 한다.
   3. 엔지니어링의 범위 확장: AI 시대의 엔지니어링은 코드를 쓰는 일뿐 아니라 결정 구조와 출시 시스템을 설계하는 일을 포함한다.

5. 주요 발언과 핵심 데이터

5.1. 발표에서 반복된 핵심 문장

“도구는 다 같았고, 갈린 건 일하는 방식을 의도적으로 바꿨느냐였다.”

“느려져야 빨라진다.”

“에이전트를 돌보는 것이 아니라, 에이전트가 해야 할 일과 스스로 확인하는 방법을 함께 먹여야 한다.”

“프론티어 팀은 코드를 쓰는 시간보다 결정하는 시간이 더 길다.”

“프론티어 엔지니어링은 일하는 방식을 의도적으로 바꾸는 일이며, 어렵고 시간이 걸리고 새로운 습관을 만드는 일이다.”

5.2. 영상에서 제시한 수치와 맥락

• 50개 팀: Amazon Stores에서 평범한 경력 구성을 가진 50개 팀을 2025년 대부분 동안 관찰했다.
• 25개 팀 대 25개 팀: 절반은 3배 미만, 절반은 중앙값 4.5배의 프로덕션 배포 속도 개선을 보였다.
• 10배 이상: 일부 팀은 10배가 넘는 개선을 보였다.
• 1~2%: 프론티어 개발자는 자신이 직접 쓰는 코드가 전체 산출물의 1~2% 정도이고 나머지는 에이전트가 작성하는 방식으로 설명된다.
• 30명·18개월 대 6명·76일: Bedrock의 추론 데이터 플레인은 기존 30명·18개월 추정에서 6명·76일 구축 사례로 바뀌었다.
• 90주 대 24주: Prime Video 실험에서 프로젝트 납기 추정이 90주에서 24주로 줄었다.
• 96개 대 556개: 같은 실험에서 커밋 수가 96개에서 열흘 동안 556개로 늘었다.
• 73%: 90주에서 24주로의 납기 추정 단축률이다.
• 5.8배: 96개 대비 556개의 커밋 증가율이다.
• 약 90%: 50개 팀의 약 90%가 Kiro를 비롯한 내부 도구를 사용했지만, 성과 차이는 도구 사용 여부가 아니라 작업 방식에서 생겼다.

수치는 발표자가 소개한 아마존 내부 실험과 사례의 값이다. Bedrock 사례는 최고 수준의 전문가 6명이 참여했고 Prime Video 사례는 회의·온콜이 제한된 잘 준비된 스프린트였으므로, 모든 개발팀에 그대로 적용되는 일반적인 인과 효과로 해석해서는 안 된다. Amazon Stores의 50개 팀 관찰은 상대적으로 일상적인 브라운필드 환경을 다뤘지만, 영상은 관찰 결과의 통계적 방법론이나 팀별 세부 조건까지 제시하지 않는다.

6. 결론 및 실천 순서

6.1. 오늘 바로 적용할 최소 변경

1. 할 일 아래에 검증 한 줄을 쓴다

   1. 작업: 에이전트가 무엇을 만들어야 하는지 쓴다.
   2. 검증: “이게 됐다는 것을 어떻게 확인할 것인가?”를 한 줄로 추가한다.
   3. 효과: 이 한 줄이 사람을 생성 대기 루프에서 꺼내는 출발점이 된다.

2. 스펙부터 만든다

   1. 목표와 사용자를 먼저 적는다.
   2. 핵심 기능과 기술 제약을 적는다.
   3. 에이전트가 수행할 작업과 완료 조건을 분리한다.

6.2. 팀과 코드베이스에 적용할 순서

1. 컨텍스트 정리: 반복되는 실패와 팀의 암묵지를 파일로 남기고, 새 모델이 해결한 오래된 규칙은 제거한다.
2. 브라운필드 정비: 오류 메시지, 코드 탐색 경로, 도구와 MCP 서버를 에이전트가 이해할 수 있게 만든다.
3. 자율 루프 설계: 사람이 매번 “다시 해”라고 말하지 않도록 테스트·커버리지·컴파일·통합 검증을 지시에 포함한다.
4. 테스트 좌측 이동: 린터, 유닛·통합·성능·보안 테스트를 빠른 로컬 루프에 넣고 외부 의존성은 필요할 때 목으로 대체한다.
5. 조직의 대기 시간 확보: 기반을 정비하는 초기 두 달 동안 단기 기능 납기만으로 팀을 평가하지 않는다.
6. 병목 재측정: 코드 생산량이 아니라 프로덕션 배포 속도와 고객에게 도달하는 시간, 결정·승인 대기 시간을 함께 측정한다.
7. 번아웃 보호: 병렬 에이전트 수와 검토량을 관리하고, 주니어에게 결과 검토 훈련을 제공한다.

6.3. 최종 시사점

이 영상의 결론은 AI가 개발자를 대체한다는 선언이 아니다. 같은 도구를 사용해도 조직의 생산성은 에이전트가 독립적으로 움직일 수 있는 환경을 만든 정도에 따라 달라진다는 관찰이다. 에이전트 시대의 경쟁력은 모델 이름을 바꾸는 데서 끝나지 않는다. 컨텍스트를 관리하고, 코드베이스를 읽기 쉽게 만들고, 의도를 문서화하고, 스스로 검증하는 루프를 만들고, 새로 옮겨 간 의사결정 병목까지 줄이는 전사적 엔지니어링에 있다.

핵심 요약 (40줄)

1. 아마존은 같은 AI 코딩 도구를 받은 50개 팀의 1년간 생산성 차이를 관찰했다.
2. 25개 팀은 프로덕션 배포 속도가 3배 미만 빨라졌고 나머지 팀은 중앙값 4.5배 빨라졌다.
3. 일부 팀은 프로덕션 배포 속도가 10배 이상 향상됐다.
4. 이 차이를 만든 핵심 요인은 도구가 아니라 일하는 방식의 변화였다.
5. 평범한 팀을 포함한 Amazon Stores 실험은 커밋 수가 아니라 고객에게 변경을 내보내는 속도를 측정했다.
6. 아마존의 에이전틱 코딩 도구는 자동완성, 채팅, 바이브 코딩, 프론티어 개발의 네 단계를 거쳤다.
7. 프론티어 개발에서는 개발자가 코드의 1~2%만 직접 쓰고 나머지를 에이전트가 작성한다.
8. 프론티어 개발자는 에이전트를 몇 시간 동안 개입 없이 실행하고 여러 작업을 병렬로 맡긴다.
9. AWS Bedrock은 사용자 요청을 모델에 전달하고 응답을 돌려주는 추론 데이터 플레인을 새로 만들어야 했다.
10. Bedrock 팀은 30명이 18개월 걸릴 것으로 추정한 일을 6명이 Kiro로 76일 만에 구축했다.
11. Bedrock 사례의 여섯 명은 분산 시스템과 모델 아키텍처에 능숙한 최고 수준의 전문가들이었다.
12. Prime Video의 다른 여섯 명은 열흘 동안 Kiro를 사용해 프로젝트 납기 추정을 90주에서 24주로 줄였다.
13. Prime Video 실험의 커밋 수는 기존 96개에서 열흘 동안 556개로 5.8배 늘었다.
14. Prime Video 실험은 온콜과 회의가 거의 없고 시니어가 작업을 미리 쪼갠 조건에서 진행됐다.
15. 따라서 Bedrock과 Prime Video의 수치는 일반적인 모든 팀에 그대로 적용할 수 있는 결과는 아니다.
16. 첫 번째 습관은 사람의 머릿속에 있던 코드베이스 지식과 팀 규칙을 에이전트 컨텍스트에 문서화하는 것이다.
17. 에이전트가 실수할 때마다 스킬 파일이나 스티어링 파일에서 빠진 규칙이 무엇인지 확인해야 한다.
18. 새 모델이 나오면 기존 규칙이 여전히 필요한지 확인해 컨텍스트 부채를 줄여야 한다.
19. 두 번째 습관은 에이전트를 성공시키기 위해 먼저 코드베이스와 개발 도구에 투자하는 것이다.
20. 오류 메시지와 코드 구조가 불친절하면 에이전트는 실패 원인을 추측해야 한다.
21. 팀들은 에이전트를 돕기 위해 새 도구와 MCP 서버를 만들고 코드베이스 구조를 바꿨다.
22. 일부 팀은 타입과 컴파일러 오류가 부족한 언어에서 TypeScript나 Rust로 이동했다.
23. 초기 생산성 하락은 실패가 아니라 에이전트가 일할 기반을 만드는 투자 기간일 수 있다.
24. 세 번째 습관은 사람이 에이전트를 계속 돌보는 대신 할 일과 자기검증 방법을 함께 전달하는 것이다.
25. API 인증과 테스트를 추가하라는 지시보다 커버리지와 통합 인증 검증까지 요구하는 지시가 낫다.
26. 완료 조건을 받은 에이전트는 컴파일과 테스트를 스스로 반복하고 품질 기준을 통과할 때 돌아올 수 있다.
27. 네 번째 습관은 코드를 생성하기 전에 목표·사용자·기능·기술 요구사항을 스펙으로 명시하는 것이다.
28. 의도가 잘못된 상태에서 코드를 생성하면 사람이 수정 요청을 반복해도 올바른 결과에 도달하기 어렵다.
29. 다섯 번째 습관은 린터·유닛·통합·성능·보안 테스트를 개발 과정 앞쪽으로 당기는 것이다.
30. 외부 서비스를 결정된 응답을 주는 목으로 바꾸면 로컬 피드백 루프가 빨라진다.
31. 다섯 습관을 적용한 뒤에도 자동으로 최고의 조직이 되는 것은 아니며 새로운 문제가 생긴다.
32. 첫 번째 문제는 밤새 완벽한 프롬프트를 만들고 여러 에이전트 결과를 검토하는 번아웃이다.
33. 시니어는 코드 리뷰 경험이 많지만 주니어는 AI 결과를 읽고 검증하는 일이 더 어렵게 느껴질 수 있다.
34. 두 번째 문제는 기반 정비에 필요한 약 두 달을 조직이 기다려 주지 않는 것이다.
35. 아마존은 먼저 50개 팀에서 학습한 뒤 그 방식을 2026년에 2,000개 팀으로 확장하려 한다.
36. 세 번째 문제는 코드 작성이 빨라지면서 의사결정과 출시 승인이 새로운 병목이 되는 것이다.
37. 과거에는 제품 개발에 9~12개월이 걸려 결정과 승인에 걸린 두 달씩이 덜 눈에 띄었다.
38. 이제 코드 작성이 1~2개월이면 가능해져 무엇을 만들지와 출시할지 결정하는 시간이 가장 긴 막대가 된다.
39. 오늘 바로 할 수 있는 변화는 에이전트에게 할 일과 함께 성공 여부를 확인하는 방법을 적어 주는 것이다.
40. 프론티어 엔지니어링은 새 도구를 설치하는 일이 아니라 컨텍스트·코드·테스트·결정 구조를 바꾸는 습관이다.