90주 예상이 24주로 바뀌었다: AI 코딩 에이전트로 개발 조직을 바꾼 글로벌 기업들은 무엇을 쟀나

2025년 하반기부터 2026년 11월까지 AI 코딩 에이전트로 개발 방식을 바꿨다고 숫자를 공개한 글로벌 기업들은 대부분 레거시 마이그레이션, 반복 코드 수정, 코드 리뷰처럼 테스트로 맞고 틀림을 가릴 수 있는 일에서 성과를 냈습니다. Amazon Prime Video 재무 시스템(Financial Systems) 팀은 90주로 잡았던 프로젝트를 24주로 다시 잡았고, GitHub는 80만 줄이 넘는 Copilot 런타임을 개발자 한 명이 주도해 Rust로 옮겼습니다. 반면 하버드 연구진이 회사 655곳을 분석해 보니 에이전트를 들인 뒤 코드는 44% 늘었지만 끝낸 일은 13.7% 느는 데 그쳤고(둘 다 통계적으로 경계선), 병목은 코드 리뷰로 옮겨 갔습니다.

그림 1. 이 글에 나온 회사와 숫자를 한 장에 모은 포스터. 각 숫자와 출처는 본문에 다시 적었습니다.

요즘 개발팀 회의에서 한 번쯤 나오는 말이 있습니다. "그거 에이전트 돌리면 2주면 되지 않아요?" (예시입니다.) 글로벌 기업들이 직접 공개한 숫자를 원문으로 다시 열어 보니, 숫자가 큰 사례일수록 비교 기준이 "원래 걸릴 거라고 예상한 기간"이었습니다. 그 숫자를 하나씩 뜯어보고, 한국 개발팀이 시작할 순서를 LeanX 제안으로 붙였습니다.

Prime Video의 "2년을 2분기로"는 정확히 무슨 숫자인가요?

정확히는 "90주로 예상했던 프로젝트를 24주로 다시 예상했다"입니다. 90주는 약 1년 9개월, 24주는 약 5개월 반이라(LeanX 계산) 보도에서 "2년을 2분기로"라고 줄여 쓴 겁니다.

출처는 AWS의 Swami Sivasubramanian이 2026년 6월 10일 쓴 AWS 머신러닝 블로그 글입니다. Prime Video 재무 시스템(Financial Systems) 팀이 10일짜리 스프린트를 했습니다. 엔지니어 6명이 한 방에 모였고, 온콜도 다른 프로젝트도 없었고, 회의도 줄였습니다. 시작 전에 시니어 엔지니어 한 명이 3주 동안 일을 잘게 쪼개고 요구사항을 적어 뒀습니다.

결과는 10일 동안 커밋 556개였습니다. 평소 기준은 96개였고요. 회사는 이걸 "처리량 약 6배, 속도 4배"라고 불렀습니다. 팀은 자동 가드레일, 컴포넌트 테스트, 성능 테스트, 포매터에 먼저 투자했고, 코드 리뷰는 이름이나 스타일보다 인터페이스와 구조를 보는 쪽으로 바뀌었다고 합니다.

여기서 조심할 점이 있습니다. 24주는 스프린트 속도를 보고 다시 잡은 예상이지, 끝난 프로젝트의 실제 기간은 아닙니다. 온콜이 없는 특별한 조건이었고, 커밋 수로는 일의 양을 짐작할 수 있을 뿐입니다.

같은 글에 Amazon 팀 두 곳이 더 나옵니다. Amazon Bedrock 팀은 "개발자 30명이 12~18개월"로 잡았던 프로젝트를 엔지니어 6명이 76일 만에 끝냈고, 개발자 1인당 주간 커밋이 2개에서 40개가 됐다고 했습니다. Amazon Stores는 뽑지 않은 평범한 팀들이 평소 백로그로 시범 운영을 했는데, 스프린트당 배포한 기능 수가 중앙값 4.5배 늘었다고 했습니다. 제일 솔직한 문장은 이겁니다. "처음 2주는 더 느리게 느껴질 것"이고, 일하는 방식을 안 바꾸고 효과만 기대한 팀은 실망했다는 대목입니다.

레거시 마이그레이션은 어디까지 에이전트에게 맡겼나요?

가장 큰 사례는 GitHub입니다. 2026년 9월 16일 Stephen Toub가 쓴 GitHub 블로그 글에 따르면, Copilot CLI·앱·SDK가 함께 쓰는 에이전트 런타임을 TypeScript(Node.js)에서 Rust로 통째로 옮겼습니다. 결과물은 80만 줄이 넘는 Rust 코드이고, 코드 대부분은 AI 에이전트가 썼고, 128개 PR로 나눠 조금씩 배포했습니다. GitHub는 "에이전트 이전이라면 팀 전체가 1~2년 걸렸을 일을 주로 개발자 한 명이 몇 달 만에" 했다고 적었습니다. InfoQ 보도(2026-10-09)는 기간을 약 14.5주로 전했습니다.

숫자보다 방법이 더 쓸모 있습니다. 8월 21일 기준 Rust 단위 테스트만 46만 8,689줄이었습니다. 기존 E2E 테스트를 매 단계 새 코드에 돌렸고, 필수 테스트가 깨지는 PR은 들어가지 못했습니다.

실패담도 적혀 있습니다. 어떤 포팅에서는 에이전트가 SDK 콜백 기능을 빼먹고, 그 기능을 검사하던 E2E 테스트까지 지워 버렸습니다. 그 뒤로 "에이전트는 명시적 동의 없이 E2E 테스트를 바꾸면 안 된다"는 규칙이 생겼습니다. 테스트를 지우면 테스트는 통과하니까요. 웃기지만 꽤 무서운 장면입니다.

조금 앞선 사례도 같은 모양입니다. Airbnb는 React 테스트 파일 약 3,500개를 Enzyme에서 React Testing Library로 옮겼습니다. InfoQ(2025-03-28)에 따르면 재시도 10번 이내로 4시간 만에 75%를 옮겼고, 남은 약 900개는 파일당 50~100번 재시도가 필요했고, 4일 뒤 97%까지 갔습니다. 마지막 100개 미만은 사람이 직접 고쳤습니다. 회사는 1.5년으로 예상한 일을 6주에 했다고 했습니다. Google도 논문(2025-04-13)에서 마이그레이션 코드 변경의 74.45%를 LLM이 만들었고 시간이 50% 줄었다고 개발자들이 추정했다고 밝혔습니다.

2026년에는 Asana가 같은 Enzyme 이전을 끝냈습니다. 8월 7일 Asana 블로그에 따르면 지금 속도라면 끝까지 약 5년이 남은 일이었는데, OpenAI Codex 에이전트 최대 4개를 디렉터리별로 돌려 엔지니어 시간 약 1주 반(달력으로 2주)에 끝냈습니다. 비용은 모델 사용료 약 1만 1,000달러와 인프라 1,000달러였습니다. 프롬프트는 다섯 문장이었고, 티켓 쪼개기나 하위 에이전트 같은 더 복잡한 설정은 "거의 다 결과를 나쁘게 만들었다"고 합니다.

동남아 기업 Grab은 테스트를 먼저 만들었습니다. 6월 22일 Grab 엔지니어링 블로그에 따르면 컨테이너 이미지 교체(Distroless) 전에 서비스 약 400개에 통합 테스트(medium test)가 없었고, 손으로 만들면 400~1,200 엔지니어-일로 봤습니다. 에이전트를 쓰자 서비스당 약 0.1일로 줄었고, 약 1.5개월 동안 테스트 MR 100개 이상을 올렸습니다. 규칙은 "모든 MR은 초안이고, 에이전트가 제안하면 사람이 승인한다"입니다.

다섯 회사 모두 테스트나 컴파일러가 맞고 틀림을 판정해 주는 일을 골랐습니다. 그리고 큰 숫자는 모두 "원래 예상"과 비교한 값입니다.

반복 수정은 에이전트가 PR까지 올리나요?

네. Stripe와 Spotify는 사람이 옆에서 지켜보지 않는 백그라운드 에이전트가 PR을 만들어 올립니다. 사람은 리뷰와 승인만 합니다.

Stripe의 에이전트 이름은 Minions입니다. 2026년 2월 9일 Stripe 개발 블로그 1편에서 매주 병합되는 PR 중 1,000개가 넘는 PR을 Minions가 처음부터 끝까지 만들었고, 사람이 리뷰하지만 사람이 쓴 코드는 한 줄도 없다고 밝혔습니다. 열흘 뒤 2편(2026-02-19)에서는 주 1,300개가 넘었다고 했습니다. 엔지니어가 Slack에 일을 던지면, 에이전트가 CI를 통과한 PR을 만들어 돌려주는 식입니다.

눈여겨볼 장치가 두 개 있습니다. 하나는 격리입니다. 작업마다 10초 안에 뜨도록 미리 데워 둔 개발 서버(devbox)를 따로 주고, 실수해도 그 서버 하나에서 끝나게 했습니다. 다른 하나는 재시도 상한입니다. CI는 최대 두 번만 돌리고, 두 번째에도 실패하면 브랜치를 사람에게 돌려보냅니다.

Spotify는 사내 에이전트 Honk를 대규모 마이그레이션에 씁니다. 2025년 11월 Spotify 엔지니어링 블로그에서 에이전트가 만든 PR 1,500개 이상이 실제 코드베이스에 병합됐고, 이런 마이그레이션에서 손으로 짤 때보다 시간이 60~90% 줄었다고 했습니다. 기존 Fleet Management 흐름은 그대로 두고 변환 스크립트 자리에만 에이전트를 넣었습니다.

2026년 3월 QCon London 발표를 다룬 InfoQ 기사(2026-03-18)를 보면 속도가 더 붙었습니다. 반년 전엔 병합 PR 1,000개에 3개월이 걸렸는데 이제는 10일이면 된답니다. 그러자 발표자들이 꼽은 새 병목은 PR 리뷰였습니다. 그래서 마이그레이션 담당자의 자기 PR 승인, 리뷰 우선순위를 정하는 PR 인박스, 코드베이스 표준화로 대응했다고 합니다.

AI 코드 리뷰는 실제로 얼마나 쓸모 있었나요?

Uber가 숫자를 가장 자세히 공개했습니다. 2025년 8월 12일 Uber 블로그에 따르면 사내 AI 리뷰 도구 uReview는 매주 약 6만 5,000개 diff(PR에 해당)의 90% 이상을 봅니다. 도구를 써 본 엔지니어들은 코멘트의 75%를 "쓸모 있다"고 표시했고, 올라간 코멘트의 65% 이상이 실제로 반영됐습니다. 같은 글에서 사람 리뷰 코멘트는 작성자가 버그로 보고 같은 변경에서 반영한 비율이 51%였다고 합니다.

방법은 정밀도 우선입니다. 코멘트를 만든 뒤 다른 프롬프트로 품질 점수를 매겨 낮은 건 버리고, 비슷한 코멘트는 합치고, 과거에 개발자들이 별로 쓸모없다고 본 종류의 코멘트는 아예 숨깁니다. Uber는 주당 약 1,500시간을 아낀다고 했는데, 이건 커밋 하나에 사람 리뷰가 10분 걸린다고 가정하고 계산한 추정치입니다.

회사별 숫자는 무엇과 비교한 값인가요?

이 글에서 제일 중요한 비교입니다. 숫자 옆에 비교 기준을 같이 놓으면 읽는 법이 달라집니다.

회사	맡긴 일	공개한 숫자	비교 기준	날짜
Amazon Prime Video	재무 시스템 프로젝트(10일 스프린트)	90주 예상을 24주로, 10일 커밋 556개(기준 96개)	사전 예상, 커밋 수	2026-06-10
Amazon Bedrock	신규 프로젝트	30명×12~18개월 예상을 6명이 76일	사전 예상, 커밋 수	2026-06-10
Amazon Stores	평소 백로그	스프린트당 배포 기능 중앙값 4.5배	팀의 과거 기록	2026-06-10
GitHub	TypeScript를 Rust로 이전	80만 줄 이상, PR 128개, 약 14.5주	사전 예상(1~2년)	2026-09-16
Stripe	단발성 코드 작업	사람 코드 0줄인 병합 PR 주 1,300개 이상	실제 개수	2026-02-19
Spotify	대규모 마이그레이션	병합 PR 1,500개 이상, 시간 60~90% 절감	손으로 짤 때	2025-11
Uber	코드 리뷰	코멘트 유용 75%, 반영 65% 이상	사람 코멘트를 작성자가 반영한 비율 51%	2025-08-12
Airbnb	테스트 파일 이전	약 3,500개를 6주에	사전 예상(1.5년)	2025-03-28
Asana	테스트 파일 이전	엔지니어 시간 약 1주 반, 약 1만 2,000달러	기존 속도로 남은 약 5년	2026-08-07
Grab	서비스 약 400개 테스트 작성	서비스당 약 0.1일, 1.5개월간 MR 100개+	사람 추정 400~1,200 엔지니어-일	2026-06-22

실제로 잰 숫자(Stripe의 PR 수, Uber의 반영률)는 범위가 좁고 덜 극적입니다. 몇 배짜리 숫자는 대부분 사전 예상과 비교했습니다. 둘 다 회사가 스스로 낸 숫자이고, 독립 검증을 받은 건 없습니다.

그런데 왜 회사 전체로 보면 덜 빨라지나요?

코드를 쓰는 속도만 빨라지고, 리뷰와 검증은 그대로이기 때문입니다. 2026년에 나온 연구와 사고 기록이 같은 얘기를 합니다.

하버드 연구: 코드는 44%, 끝낸 일은 13.7%. Fiona Chen과 James Stratton의 연구 논문(2026년 11월 1일 판)은 개발 분석 플랫폼 Jellyfish 데이터로 회사 655곳, 직원 72만 542명의 작업 기록 4억 4,500만 건(2021년 1월~2026년 8월)을 봤습니다. AI 에이전트를 들인 뒤 추가된 코드 줄 수는 44.0%, 연 PR은 35.7% 늘었습니다. 그런데 끝낸 Jira 이슈는 13.7% 늘었고, 30.7%보다 크게 늘었을 가능성은 배제됐습니다. 다만 44%와 13.7% 모두 통계적으로 경계선이라 오차가 큽니다. 고용에는 눈에 띄는 변화가 없었습니다. 반면 PR을 올린 뒤 병합까지 걸리는 시간이 56.1% 늘었고, 변경 하나에 달리는 코멘트는 38.6% 늘었습니다. 회사 79.1%가 AI 코드 리뷰 도구를 쓰고 있었지만 여전히 사람이 승인합니다. 아직 학술지 심사를 거치지 않은 논문입니다.

논문 인터뷰에는 AI 커밋 때문에 장애가 난 뒤 AI 코드에 시니어 승인을 의무화해 리뷰 병목이 더 심해졌다는 증언도 나옵니다.

반대 사례도 있습니다. Replit은 2026년 7월 16일 Replit 블로그에서 같은 작성자 기준 코드가 6개월 새 2.9배가 됐는데 리뷰 지연은 그대로였다고 했습니다. 에이전트가 변경의 위험도를 매겨 필요할 때만 두 번째 사람 리뷰어를 부르게 했고, 그래서 사람 리뷰 시간 30%를 아꼈다는 설명입니다. 리뷰 쪽에 투자하면 병목을 늦출 수 있다는 회사 자체 발표입니다.

METR: 빨라졌는지 재는 것 자체가 어려워졌다. 2026년 2월 24일 METR 발표에 따르면, 2025년 초 실험에선 숙련 개발자가 AI를 쓰면 작업이 19% 더 오래 걸렸습니다. 2025년 말 후속 실험에선 같은 개발자들 기준 18% 빨라졌다는 추정이 나왔지만 오차 범위가 0을 포함합니다. 더 재미있는 건 참가자 30~50%가 "AI 없이 하기 싫어서" 일부 과제를 아예 안 냈다는 점입니다. METR은 실험 설계를 다시 짜고 있습니다.

DORA 2025: AI는 팀을 고치지 않고 증폭한다. Google Cloud가 2025년 9월 24일 발표한 DORA 보고서는 약 5,000명 설문에서 30%가 AI 코드를 거의 또는 전혀 믿지 않는다고 했습니다. 자동 테스트가 약한 팀은 변경량이 늘면 불안정해진다고 봤습니다.

AWS Kiro 사고: 권한 설정이 문제였다. The Register(2026-02-20)는 FT를 인용해 2025년 12월 AWS 서비스 하나가 13시간 멈췄고, 엔지니어가 맡긴 Kiro 에이전트가 "환경을 지우고 다시 만드는" 쪽을 택했다고 전했습니다. Amazon은 AI 탓을 부인했습니다. 중국 본토 리전 한 곳의 AWS Cost Explorer만 영향을 받았고, 원인은 "직원 실수, 정확히는 잘못 설정된 접근 권한"이라는 입장입니다. 그 뒤 운영 환경 접근에 동료 리뷰를 의무화했습니다. 누구 탓이든, 에이전트가 쓸 수 있는 권한이 사고 크기를 정했습니다.

한국 개발팀은 어떤 순서로 따라 하면 되나요? (LeanX 제안)

아래는 위 사례들의 공통점과 빈틈을 보고 LeanX가 제안하는 순서입니다. 위 회사들이 이 순서를 권했다는 뜻은 아닙니다.

1. 테스트가 판정해 주는 반복 작업 하나를 고르세요. 라이브러리 버전 올리기, 테스트 프레임워크 교체, 설정 파일 일괄 수정처럼 맞고 틀림을 테스트나 컴파일러가 알려 주는 일입니다. Spotify, Airbnb, GitHub가 모두 이런 일부터 했습니다.
2. 예상치 말고 실제 기록으로 기준선을 먼저 잡으세요. 비슷한 작업 10건을 사람이 했을 때 걸린 시간, 리뷰 대기 시간, 되돌린 횟수를 먼저 적습니다. 그래야 나중에 "90주가 24주로" 같은 예상 대 예상 비교를 피할 수 있습니다.
3. 에이전트에게 격리된 작업 공간과 좁은 권한을 주세요. Stripe처럼 작업마다 따로 쓰는 환경을 주고, 운영 환경 쓰기와 삭제 권한은 빼 둡니다. 권한 단계를 나누는 법은 AI 에이전트 권한 설계: 읽기·초안·실행에 적어 두었습니다.
4. 재시도 상한과 사람에게 넘기는 조건을 정하세요. Stripe는 CI 두 번, Airbnb는 쉬운 파일에 10번까지였습니다. 상한을 넘으면 사람에게 돌아오게 합니다.
5. 테스트는 에이전트가 못 고치게 잠그세요. GitHub가 겪은 것처럼, 테스트를 지우면 모든 게 통과합니다. 테스트 파일 변경은 사람 승인이 필요하다는 규칙을 처음부터 둡니다.
6. 리뷰 용량을 먼저 늘리고, 리뷰 대기 시간을 재세요. 하버드 연구와 Spotify 모두 병목은 리뷰였습니다. AI 리뷰 봇을 붙인다면 Uber처럼 코멘트 수를 줄이고 정확도를 먼저 봅니다. PR·테스트·리뷰를 묶는 운영 방식은 AI 코딩 에이전트 운영법: PR·테스트·리뷰 안전장치를 참고하세요.
7. 속도와 함께 안정성 숫자를 보세요. 처리한 PR 수 옆에 변경 실패율, 되돌린 PR 비율, 리뷰 대기 시간을 같이 둡니다. DORA가 말한 불안정성은 여기서 먼저 보입니다.

해외 개발팀들이 공식 문서 기준으로 에이전트를 어떻게 운영하는지는 해외 개발팀 AI 코딩 에이전트 운영 사례 6가지에, 개발 밖 업무에 에이전트를 쓴 기업 사례는 AI 에이전트 기업 도입 사례에 모아 두었습니다. 우리 팀은 어느 작업부터 맡기면 좋을지 궁금하다면 30문항 무료 AX 진단으로 먼저 점검해 볼 수 있습니다.

한계

이 글의 회사 숫자는 모두 회사가 스스로 공개한 것이고, 독립 기관이 검증한 숫자는 없습니다. Amazon(Kiro), GitHub(Copilot), Replit은 자기 에이전트 제품을 파는 회사이고, Asana 글은 OpenAI와의 협업으로 나온 것이라 모두 자체 발표로 읽어야 합니다. Airbnb와 Google 사례는 2025년 상반기 자료지만 방법을 비교하려고 넣었습니다. Airbnb 수치는 원문 접근이 막혀 InfoQ 보도로, AWS 사고는 The Register와 Amazon 입장문으로 확인했고 FT 원문은 보지 못했습니다. 한국 기업이 숫자와 함께 공개한 사례는 이번 조사에서 찾지 못했습니다.

출처

• AWS Machine Learning Blog, How frontier teams are reinventing AI-native development (2026-06-10)
• GitHub Blog, Migrating the GitHub Copilot runtime to Rust, using Copilot (2026-09-16)
• InfoQ, GitHub Migrates Copilot Runtime to Rust with AI-Assisted Rewrite (2026-10-09)
• Stripe, Minions: Stripe's one-shot, end-to-end coding agents (2026-02-09) / Part 2 (2026-02-19)
• Spotify Engineering, 1,500+ PRs Later: Spotify's Journey with Our Background Coding Agent (2025-11)
• InfoQ, QCon London 2026: Rewriting All of Spotify's Code Base, All the Time (2026-03-18)
• Uber Blog, uReview (2025-08-12)
• Asana, We migrated off Enzyme in 2 weeks. It should have taken five years (2026-08-07)
• Grab Engineering, Scaling out Distroless adoption with AI (2026-06-22)
• Replit, The Self-Driving Company (2026-07-16)
• InfoQ, How Airbnb Used LLMs to Accelerate Test Migration (2025-03-28)
• Ziftci et al., Migrating Code At Scale With LLMs At Google, arXiv 2504.09691 (2025-04-13)
• Chen & Stratton, Artificial Intelligence in the Firm: Bottlenecks in Software Production (2026-11-01 판)
• METR, We are Changing our Developer Productivity Experiment Design (2026-02-24)
• Google Cloud, Announcing the 2025 DORA Report (2025-09-24)
• The Register, Amazon denies Kiro agentic AI behind outage (2026-02-20)