아마존 50개 팀 1년 실험: 같은 AI 도구도 일하는 방식을 바꾼 팀은 4.5배, 도구만 추가한 팀은 3배 미만. 프론티어 개발의 핵심 습관 5가지와 새로운 문제들을 공개합니다.
AI 도구로 진짜 생산성을 10배 높이는 방법
핵심 요약
- 같은 도구, 다른 결과: 아마존의 50개 팀 중 절반은 4.5배 이상 빨라졌지만, 나머지는 3배 미만 증가
- 차이점은 도구가 아니라 방식: 도구를 기존 방식 위에 얹은 팀 vs 일하는 방식 자체를 바꾼 팀
- 프론티어 개발의 정의: 엔지니어가 직접 코드 작성은 2% 미만, 에이전트가 몇 시간씩 자동 실행
- 5가지 습관: 에이전트 콘텍스트 투자, 지속적 규칙 정제, 자동 검증 조건 제공, 의도 명시, 테스트 최우선
- 새로운 병목: 코드가 빨라지자 결정과 승인 프로세스가 가장 느린 막대가 됨
아마존이 본 두 가지 다른 결과
아마존은 지난해 50개 팀을 관찰했습니다. 신입부터 시니어까지 평범하게 섞인 팀들이 모두 동일한 AI 코딩 도구(Kiro)를 받았습니다.
1년 후 결과는 명확히 두 종류로 나뉘었습니다.
- 25개 팀: 코드 배포 속도가 2~3배 증가
- 나머지 25개 팀: 4.5배 이상, 10배를 넘는 팀도 있었습니다
같은 도구인데 왜 이렇게 차이가 났을까요? AWS 시니어 프린시팔 엔지니어 클레어 리고올은 단순했습니다: 한쪽은 도구만 새로 꽂았고, 다른 한쪽은 일하는 방식을 통째로 바꿨거든요.
프론티어 개발: 에이전트가 주도하는 방식
리고올이 정의한 프론티어 개발 이란 무엇일까요?
엔지니어가 직접 작성하는 코드는 전체의 2% 미만입니다. 나머지는 에이전트가 생성합니다. 그리고 에이전트는 엔지니어의 개입 없이 수 시간씩 자동으로 실행됩니다.
이를 처음 증명한 것은 베드록(Bedrock) 팀이었습니다. 이 서비스는 AWS에서 AI 모델을 호스팅하는 핵심 플랫폼입니다. 원래 계획은:
- 30명의 엔지니어
- 18개월 소요
- 기존 고객 마이그레이션 포함
대신 이 팀은 6명으로 76일 안에 완성했습니다.
다만 한계가 있었습니다. 이 6명은 회사의 최고 엔지니어들이었고, 분산 시스템과 LLM 아키텍처 전문가들이었습니다. 그래서 아마존은 두 번째 실험을 했습니다.
실제 팀에서 검증: 프라임 비디오 프로젝트
프라임 비디오 조직에서 일반적인 수준의 엔지니어 6명을 선발했습니다. 10일간 키로를 마음껏 사용하게 한 결과:
- 예상 일정: 90주 → 실제 완성: 24주 (73% 단축)
- 커밋 수: 이전 기준 96개 → 10일간 556개 (5.8배)
하지만 리고올은 중요한 조건을 명시했습니다.
- 온콜(긴급 대응) 담당이 없었습니다
- 회의가 거의 없었습니다
- 팀의 시니어 엔지니어가 사전 3주간 작업을 명확히 분해하고 요구 사항을 모두 작성했습니다
즉, 이것도 이상적인 조건에서의 스프린트 였습니다. 그래서 아마존은 평범한 일상 을 보기로 했습니다.
평범한 팀, 평범한 일상에서 확인한 습관
아마존 스토어 조직(Amazon.com과 각국 리테일 사이트 담당)에서 50개 팀을 1년간 관찰했습니다.
- 팀 구성: 신입, 중간 연차, 시니어가 자연스럽게 섞여 있음
- 작업: 기존 시스템의 코드베이스 위에서 진행
- 측정 지표: 배포 속도(얼마나 빨리 고객에게 변경사항을 전달하는가)
결과: 정확히 반으로 갈렸습니다. 절반은 3배 미만, 절반은 4.5배 이상의 향상을 보였습니다.
인터뷰를 통해 아마존이 찾은 것은 5가지 습관 이었습니다.
프론티어 팀의 5가지 습관
1. 에이전트를 위한 콘텍스트를 문서화하기
우리 머릿속에는 코드에 적혀 있지 않은 것들이 많습니다. 지금까지는 이를 슬렉 대화, 온보딩, 코드 리뷰, 스탠드업을 통해 전달했습니다.
프론티어 팀들은 이 모든 것을 글로 작성 했습니다. 그리고 두 가지 질문을 습관화했습니다.
- 에이전트가 실수하면: "내 스킬 파일에 뭐가 빠졌나?"
- 새 모델이 나오면: "이 규칙이 아직 필요한가?"
이것이 중요한 이유는 모델이 빠르게 발전하기 때문입니다. 작년 초 Claude 3.7 시절의 규칙들은 이제 컨텍스트 낭비가 될 수 있습니다.
2. "느려져야 빨라진다" — 코드베이스 개선 투자
거의 모든 팀이 처음에 생산성이 일시적으로 떨어졌다 고 말했습니다. 왜냐하면:
에이전트가 기존 코드베이스에서 효율적으로 일하려면 먼저 할 일이 있기 때문입니다.
- 에이전트 콘텍스트 구축
- 기존 도구의 에러 메시지 개선 (모델이 실패 원인을 이해할 수 있도록)
- 새로운 도구나 MCP 서버 작성
- 코드베이스 구조 개선
- 심지어 프로그래밍 언어 변경 (Python/JavaScript의 타입 없음이 문제라면 TypeScript나 Rust로 전환)
이 모든 작업은 실제 엔지니어링이기에 시간이 걸립니다. 하지만 이를 감수한 팀만 나중에 4배 이상의 효과를 봤습니다.
3. 에이전트가 "자동 검증"하도록 하기 — Baby-sitting을 떼어내기
이것이 리고올이 가장 큰 깨달음을 얻은 부분입니다. 왜 4.5배가 나오는지의 산수가 여기서 풀립니다.
Baby-sitting 방식 (낮은 생산성):
- 에이전트에게 "이 API에 인가를 붙여줘"
- 30초~1분 기다림
- 결과 검토 후 "테스트 추가해줄래?"
- 또 기다림
- 계속 루프 안에 있음
자동 검증 방식 (높은 생산성):
- "이 API에 인가를 붙이고, 유닛 테스트를 추가해서 돌리고, 코드 커버리지가 90%가 될 때까지 하고, 통합 테스트로도 검증해. 그리고 다 했으면 내 슬랙으로 알려줘."
핵심: 에이전트에게 할 일 과 스스로 확인하는 방법 을 함께 제시합니다.
이렇게 하면 에이전트는 수 시간씩 자동으로 실행되고, 당신은 다른 일을 할 수 있고, 여러 에이전트를 동시에 돌릴 수 있습니다.
4. 코드 전에 의도를 명시하기
아마존은 스펙 주도 개발을 기본으로 합니다. Baby-sitting 코딩의 전형은 이렇습니다.
- 대략적인 프롬프트를 줌
- 에이전트가 코드를 생성
- "아, 그 뜻이 아니었는데" → 다시 요청
- 반복
문제는 의도 자체가 틀렸는데 코드를 놓고 왕복하는 것 입니다. 비효율의 극치입니다.
해결책: 복잡한 기능은 코드 전에 스펙을 작성합니다.
- 목표가 무엇인가
- 누가 어떻게 사용하는가
- 핵심 기능은 무엇인가
- 기술 요구사항은 무엇인가
스펙 문서 한 장을 놓고 왕복하는 것이 코드베이스 여기저기 흩어진 변경을 놓고 왕복하는 것보다 훨씬 쌉니다.
5. 테스트를 최우선으로 — 빠른 피드백 루프
에이전트가 수 시간 자동 실행되는 조건은 빠른 피드백 루프 입니다.
팀들이 붙인 테스트들:
- 린터
- 유닛 테스트
- 통합 테스트
- 성능 테스트
- 보안 테스트
그리고 가장 효과적이었던 것: 외부 서비스를 목으로 교체
기존: 통합 테스트 시 실제 서비스까지 모두 연결
개선: 정해진 응답을 주는 가짜 서비스로 대체하고 로컬에서 실행
한 바퀴가 빨라지면 에이전트는 같은 시간에 더 많이 실행됩니다.
문제: 프론티어 개발의 새로운 병목들
하지만 리고올은 발표 후반을 이 부분에 할당했습니다. 습관 5개를 모두 따르면 모든 문제가 해결되는 것은 아니라고.
문제 1: 번아웃 (Burnout)
엔지니어들이 밤새 완벽한 프롬프트를 만들어서 에이전트를 밤새 돌려 아침에 코드 변경을 받으려 합니다.
인지 부하도 증가합니다. 여러 에이전트를 병렬로 실행하면서 터미널 탭을 계속 전환해야 합니다.
또한 AI 결과물 리뷰가 직접 작성보다 어려울 수 있습니다. 특히 주니어 엔지니어들은 커리어 대부분을 코드 리뷰에 쓰지 않았기 때문에 이 "근육"이 없습니다.
문제 2: 조직의 조급함
팀 습관을 바꾸는 데 보통 2개월이 걸립니다.
하지만 리더들의 질문은:
"AI 도구도 있고 모델도 이렇게 좋아졌는데 왜 더 안 빨라져?"
2개월 동안 매달 기능을 내놓으라는 압박을 받으면, 팀은 도구를 기존 방식 위에 얹는 쪽으로 돌아갑니다. (3배 미만 팀이 되는 경로)
아마존의 교훈: 50개 팀에서 먼저 배운 후, 2026년에 다음 2,000개 팀으로 넓힐 계획입니다. 너무 빨리 펼치면 팀들은 뭘 해야 할지 모르고, 자신의 콘텍스트를 찾을 시간이 없습니다.
문제 3: 결정이 새로운 병목이 됨
예전에는 코드 작성이 병목이었습니다.
- 제품 1개: 9~12개월
이제 코드는 1~2개월이면 됩니다.
그러면 이전에 티 안 났던 것들이 눈에 띕니다.
- 제품 개발 결정: 2개월
- 출시 승인: 2개월
병목이 사라진 게 아니라 자리를 옮긴 것입니다.
리고올의 관찰:
프론티어 엔지니어링 팀은 코드 작성하는 시간보다 결정하는 시간이 더 깁니다.
이제 새로운 기술이 필요합니다: 어떤 결정을 빨리 내려도 되고, 어떤 결정은 돌려야 하는지 구분하기.
결론
아마존의 결론은 한 줄입니다.
도구는 모두 같았습니다. 갈린 것은 일하는 방식을 의도적으로 바꿨는가였습니다.
오늘 밤부터 바로 할 수 있는 것은 세 번째 습관입니다:
다음 번 에이전트에게 일을 줄 때, 할 일 옆에 한 줄을 더 적으세요.
"이게 됐다는 걸 넌 어떻게 확인할 건지?"
이 한 줄이 당신을 루프 밖으로 꺼내는 시작입니다.
원문출처: https://www.youtube.com/watch?v=O9iL08X9zMo
powered by osmu.app