9월 4일 금요일

같은 AI 코딩 도구를 받아도 왜 어떤 팀은 작은 개선에 머물고 어떤 팀은 배포 속도를 크게 끌어올렸을까?

핵심은 개발자가 코드를 조금 더 빨리 쓰는 데 있지 않았다. AWS 사례에서 같은 도구를 받은 Amazon Stores 50개 팀은 두 갈래로 나뉘었다. 절반은 프로덕션 배포 속도가 3배 미만으로 개선됐고, 다른 절반은 중앙값 4.5배의 향상을 보였다. 차이를 만든 것은 도구 사용 여부가 아니라 작업이 에이전트에게 넘겨질 수 있도록 준비됐는지였다. 높은 성과의 팀은 요구사항을 작게 쪼개고, 코드베이스와 오류 메시지를 정리하고, 테스트와 완료 조건을 에이전트가 따라갈 수 있게 만들었다. 그래서 사람의 역할은 모든 코드를 직접 쓰는 일에서 목표를 정의하고, 검증 기준을 세우고, 배포 결정을 내리는 일로 옮겨갔다. Bedrock 추론 데이터 플레인 사례는 이 차이를 더 선명하게 만든다. 원문은 30명이 18개월 걸릴 것으로 본 일을 6명이 76일에 완성한 Pathfinder 팀을 소개하되, 이 결과를 모든 팀의 평균으로 일반화하지 말라고 경고한다. 최고 수준의 분산 시스템과 대규모 언어 모델 전문성이 함께 있었기 때문이다. 그래서 이 사례는 “누구나 20배 빨라진다”가 아니라 “에이전트가 독립 실행할 수 있는 환경을 만든 팀에서 속도의 상한이 달라진다”는 증거로 읽어야 한다.

1. 01

   생산성의 단위

   개인 사용 경험에서는 자동완성, 채팅, 바이브 코딩이 10~20%의 체감 향상으로 설명됐다. 그러나 팀 실험은 커밋 수가 아니라 실제 고객에게 변경이 도달하는 배포 속도를 보았다. AI 도입의 성과를 말하려면 작성량보다 배포 가능한 변경이 늘었는지를 먼저 봐야 한다.

2. 02

   준비된 일감

   Prime Video 실험에서는 여섯 명이 열흘 동안 Kiro를 집중 사용했고 예상 기간은 90주에서 24주로 줄었다. 다만 그 앞에는 시니어 엔지니어가 3주 동안 작업을 잘게 나누고 요구사항을 정리한 준비가 있었다. 에이전트가 빨랐던 만큼, 사람이 먼저 모호함을 줄인 것이다.

3. 03

   조직 병목

   코드 작성이 빨라지면 병목은 곧바로 다른 곳으로 이동한다. 영상은 번아웃, 조직의 조급함, 의사결정과 출시 승인이라는 새 병목을 함께 짚었다. AI가 개발 속도를 높일수록 매니저와 리더는 더 많은 결과물을 더 빨리 검토할 운영 리듬을 갖춰야 한다.

4. 04

   도입 조건

   프론티어 개발은 에이전트가 몇 시간 동안 독립적으로 실행되고 컴파일, 테스트, 커버리지, 통합 검증까지 수행하는 흐름이다. 따라서 프롬프트만 바꿔서는 충분하지 않다. 문서, 테스트, 오류 메시지, 코드 구조, 사람의 대기 시간을 줄이는 의사결정 방식이 함께 바뀌어야 한다.

이 사례의 메시지는 “AI 도구를 사라”가 아니다. 팀이 무엇을 에이전트에게 맡길지, 어떤 상태가 완료인지, 실패하면 어디까지 스스로 고치게 할지 정하지 않으면 같은 도구도 작은 보조 기능에 머문다. 반대로 일의 단위와 검증 기준을 재설계하면 사람은 더 많은 코드를 쓰는 사람이 아니라 더 많은 변화가 안전하게 고객에게 가도록 조율하는 사람이 된다.