From AI-Assisted to AI-Native: Building a Frontier Development Team — Clare Liguori, AWS

한 줄 핵심

AI 도구를 기존 개발 흐름에 얹는 수준으로는 체감 생산성이 제한적이며, 에이전트 컨텍스트·검증 루프·업무 방식 자체를 바꾼 팀만이 4.5x~10x 이상의 성과를 냈다.

시간별 요약

1. 0:00
   네 단계와, 체감은 10%~20%뿐 코딩 보조는 인라인 완성, 채팅, 바이브 코딩을 거치며 진화했지만, 개인적으로 느껴지는 생산성 향상은 대체로 10%~20% 수준에 그친다. 반면 지금은 Amazon 내부에서 훨씬 큰 도약을 보이는 frontier development 단계가 나타나고 있다.
2. 1:22
   파일럿이 실제로 측정한 것 Amazon의 여러 팀 파일럿에서는 중앙값 기준 4.5x, 경우에 따라 10x가 넘는 생산성 향상이 관측됐다. 이 팀들의 공통점은 코드의 1~2%만 직접 쓰고, 에이전트를 오래 독립적으로 돌리며, 여러 에이전트를 병렬로 돌려 유휴 시간을 줄였다는 점이다.
3. 2:34
   30명 18개월, 혹은 6명 76일 Bedrock Mantle 팀은 원래 30명, 18개월이 필요하다고 본 inference data plane을 6명과 Kiro로 76일 만에 만들었다. 다만 이 팀은 Distinguished Engineer를 포함한 최고 수준의 전문가들로 구성돼 있어, 단순히 인원 축소만으로 재현 가능한 사례는 아니었다.
4. 3:43
   왜 그 팀은 재현되지 않았나 같은 수준의 성과를 다른 팀에도 적용할 수 있는지가 핵심 질문이었고, 이를 검증하기 위해 Prime Video에서 10일 스프린트 실험이 진행됐다. 이 실험은 큰 개선 가능성을 보여줬지만, 여전히 매우 구조화된 조건에서만 얻어진 결과였다.
5. 4:51
   10일 스프린트와 그 단서들 10일 스프린트에서는 6명의 엔지니어가 집중적으로 작업하며 90주로 예상되던 일정이 24주로 줄었다. 하지만 온콜, 회의, 잡무가 거의 없고, 사전에 아주 잘게 쪼갠 과제가 준비돼 있었기 때문에 실제 일상 업무와는 거리가 있었다.
6. 5:57
   평범한 50개 팀과 실제 격차 Amazon Stores의 50개 일반 팀을 보면, 기존 시스템과 기존 코드베이스에서 일하는 팀들 사이에서도 성과 차이가 크게 벌어졌다. 지표는 커밋 수가 아니라 production으로의 배포 속도였고, 절반의 팀은 3x 미만, 다른 팀들은 4.5x 이상을 달성했다.
7. 7:04
   같은 도구, 다른 일하는 방식 Kiro를 포함한 도구 자체가 성과를 만든 것이 아니라, 팀이 일하는 방식이 성과를 갈랐다. 기존 방식을 그대로 두고 도구만 얹은 팀은 성과가 작았고, 일하는 습관 자체를 바꾼 팀은 큰 도약을 만들었다.
8. 8:14
   습관 1: 에이전트 컨텍스트에 투자하기 사람이 머릿속에만 들고 있던 맥락을 skills files, steering files, 문서화된 지침으로 옮겨야 에이전트가 일관되게 움직인다. 모델이 실수할 때마다 어떤 정보가 빠졌는지 점검하고, 필요한 컨텍스트를 구조화해 넣는 습관이 중요하다.
9. 9:21
   모델이 좋아지면 컨텍스트를 덜어내기 모델 성능이 개선되면 예전에는 필요했던 금지 규칙이나 지시가 오히려 컨텍스트만 부풀릴 수 있다. 그래서 현재도 필요한지, 단순한 잡음인지 계속 점검하며 steering files를 정리해야 한다.
10. 10:31
    습관 2: 느리게 가서 더 빨리 가기 새로운 작업 방식으로 전환하는 초반에는 생산성이 오히려 떨어지는 경우가 많고, 그 전에 코드베이스와 도구를 에이전트 친화적으로 손봐야 한다. 오류 메시지 개선, 새 MCP 서버 추가, 코드 구조 재정비, 심지어 TypeScript나 Rust로의 전환까지도 이런 준비 작업에 포함된다.
11. 12:50
    에이전트를 돌보지 말고 먹이기 하루 종일 대화식으로 붙어서 코드 한 조각씩 확인하면 에이전트의 병렬 실행 이점을 얻기 어렵다. 필요한 목표·제약·자기검증 방법을 먼저 주고, 테스트와 컴파일을 통과할 때만 돌아오게 해야 진짜 생산성이 나온다.
12. 13:58
    코드 전에 의도를 명확히 하기 애매한 요구를 둔 채 코드를 먼저 만들면, 이후 대화는 잘못된 방향의 코드를 고치는 데 소모된다. 복잡한 기능일수록 코드보다 먼저 사양과 설계를 분명히 쓰는 편이, 문서를 중심으로 반복 수정하는 데 훨씬 유리하다.
13. 15:09
    로컬 모의로 테스트를 앞당기기 에이전트에게 빠른 피드백을 주려면 lint, unit test, integration test, performance test, security test를 초기에 붙여야 한다. 특히 모든 응답이 deterministic한 로컬 mock service를 두면 클라우드 의존 없이 반복 루프를 빠르게 돌릴 수 있다.
14. 16:15
    번아웃, FOMO, 인지 부하 에이전트를 밤새 돌리기 위한 과도한 프롬프트 실험은 번아웃으로 이어질 수 있고, 여러 에이전트를 동시에 다루면 인지 부하도 크게 늘어난다. 특히 경력 초반일수록 코드를 쓰는 것보다 AI 출력을 검토하는 일이 더 어렵게 느껴질 수 있다.
15. 17:23
    조직이 바꿔야 할 것 조직은 AI 도구를 주고 더 빨리 내기를 요구하는 방식에서 벗어나, 학습과 습관 형성을 위한 느린 전환을 허용해야 한다. 또한 모든 팀에 동시에 확산하기보다 점진적으로 best practice를 만들고, 새롭게 생긴 병목을 기준으로 운영 방식을 바꿔야 한다.
16. 19:41
    결정 속도가 병목이 될 때 코드 작성이 빨라지면 병목은 리뷰와 승인 같은 의사결정 과정으로 이동한다. 그래서 frontier engineering의 핵심은 코드를 더 빨리 쓰는 일이 아니라, 되돌리기 쉬운 결정을 빠르게 내릴 수 있는 조직으로 바꾸는 데 있다.

실무 인사이트

• AI 도구 도입 성과를 보려면 모델 선택보다 컨텍스트 문서화, 테스트 루프, 코드베이스 정비 같은 작업을 먼저 투자해야 한다.
• 팀 생산성 지표는 커밋 수보다 production 배포 속도로 잡아야 실제 고객 가치와 연결된 개선을 측정할 수 있다.
• AI 시대의 병목은 코딩이 아니라 의사결정과 조직 운영으로 이동하므로, 승인·리뷰 절차를 함께 재설계해야 한다.