하버드 연구진은 회사에 AI가 들어온 뒤 소프트웨어 작업이 어떻게 바뀌었는지 연구하면서 엔지니어와 매니저들을 인터뷰했어요. 한 주니어 소프트웨어 엔지니어는 사람들이 커밋을 아주 많이, 빠르게 만들 수 있었지만 코드 리뷰는 여전히 병목이었다고 말했어요. 한 프로젝트에서는 그 코드베이스를 가장 잘 아는 시니어 엔지니어 한 명만 변경을 승인할 수 있었어요. 그 사람은 너무 바빠서 이 엔지니어의 코드를 일주일에 한 번밖에 보지 못했어요. 연구진이 회사 718곳의 작업 기록에서 얻은 숫자도 같은 쪽을 가리켜요. 코딩 에이전트를 들인 뒤 코드는 30% 늘었는데, 회사가 끝낸 일은 늘었다고 볼 수 없었어요.
견준 대상은 AI가 없던 때가 아니라, 코드 자동완성 AI만 쓰던 때였어요
하버드의 Fiona Chen과 James Stratton은 개발 분석 회사 Jellyfish의 고객사 가운데 연구 사용에 동의한 718곳, 725,938명의 기록을 분석했어요. 기간은 2021년 1월부터 2026년 3월까지이고, Jira 이슈 약 6,800만 건, 커밋 약 2억 건, PR(코드 변경 요청) 약 4,900만 건이 들어 있어요. 연구진은 커밋 안의 코드 내용을 보지 않았고, 누가 언제 무엇을 올리고 합쳤는지를 담은 기록만 봤어요.
비교에는 회사마다 도구를 들인 시점이 다르다는 점을 이용했어요. 한 회사는 구매 한 건에 소싱·법무·보안·IT 네 팀이 붙었고, ChatGPT가 나온 2022년 11월에서 거의 1년이 지난 2023년 가을에야 시험용 라이선스를 몇 개 샀어요. 다른 회사는 IT와 법무에 물어보면 보통 하루 안에 승인이 끝난다고 했어요. 연구진은 일찍 도입한 회사를 늦게 도입했거나 도입하지 않은 회사와 비교하는 시차 이중차분을 썼고, 회사 규모를 통제했어요.
비교 기준은 정확히 봐야 해요. 연구진은 코드 자동완성형 AI 어시스턴트(Copilot·Cursor)와 스스로 작업을 이어 가는 에이전트(Cursor Agent·Claude Code·Devin 등)를 따로 추정했어요. 에이전트 효과는 AI가 전혀 없던 상태와 비교한 값이 아니라, 어시스턴트를 쓰던 상태에 에이전트를 더했을 때 추가로 생긴 변화예요. 에이전트를 들인 회사 비율은 2024년 10월 거의 0%에서 2026년 1월 95% 이상으로 올라갔어요.
어시스턴트만 들였을 때 PR 증가는 5% 정도였고 통계적으로 유의하지 않았어요. 이 논문은 저자가 학계 채용 시장에 내는 job market paper이고, 동료 심사를 거쳤다는 표시는 없어요. 데이터는 개발 생산성 지표를 파는 Jellyfish에서 왔어요. 논문은 결론이 저자의 것이고, Jellyfish는 독점 정보가 드러나는지만 확인했으며 과학적 내용은 검토하지 않았다고 적었어요.
연구진이 “끝낸 일”로 센 것은 검토와 테스트를 거쳐 실제 서비스에 배포된 작업이었어요
연구진은 회사가 실제로 끝낸 일을 Jira 이슈 해결 건수로 봤어요. 이 논문에서 이슈가 해결됐다는 말은, 코드가 리뷰와 테스트를 거쳐 프로덕션에 배포됐다는 뜻이에요. 코드를 아무리 많이 써도 검토를 통과해 배포되지 않으면 이 건수에는 들어가지 않아요. 엔지니어 한 명이 한 달에 해결하는 이슈는 평균 3.67건인데, 에이전트 도입 효과는 +0.12건(표준오차 0.17)이었어요. 0과 구별되지 않는 값이에요. 기능이나 프로젝트 단위인 에픽에서도 유의한 효과가 없었어요.
원문은 95% 신뢰구간으로 보면 기준 평균의 12%를 넘는 효과는 배제할 수 있다고 적었어요. 같은 회사들에서 코드는 30% 늘었는데, 배포까지 끝낸 일은 늘었다 해도 12% 안쪽이라는 결과예요.
이슈 하나하나가 커져서 건수만 그대로인 것처럼 보였을 수도 있어요. 연구진은 이 가능성을 두 방법으로 점검했어요. 하나는 GPT-4o로 이슈 0.5%에 예상 소요 시간을 붙이고, 이를 학습시킨 모델로 전체 이슈에 넓힌 방법이에요. 다른 하나는 이슈 하나를 끝내는 데 걸릴 것으로 예상되는 기간(예측 사이클 타임)을 쓰는 방법이에요. 결론은 이슈 구성이 바뀌었다는 증거가 없다는 것이었어요. 연구진은 코드 줄 수와 커밋이라는 지표 자체에도 의문을 달았어요.
“Many managers rely on intermediate productivity metrics, such as lines of code or commits; however, these may not accurately capture the true gains from AI adoption.”
많은 관리자가 코드 줄 수나 커밋 같은 중간 지표를 보지만, 그 지표로는 AI를 들여서 얻은 실제 효과를 제대로 알 수 없다는 말이에요.
엔지니어가 올린 코드 변경이 사람의 검토를 거쳐 합쳐지기까지 걸린 기간은 7일에서 10.5일로 늘었어요
늘어난 코드가 어디에 쌓였는지 보려고, 연구진은 PR이 제출된 날부터 병합된 날까지의 일수를 봤어요. 에이전트 도입 뒤 이 기간은 평균 7.03일에서 3.45일 늘어 약 10.5일이 됐어요(표준오차 1.60). 통계적으로 유의하지만 추정 폭이 넓은 숫자예요. 어시스턴트만 쓴 회사에서는 이 기간에 유의한 변화가 없었어요.
추정 폭이 좁아 더 확실한 숫자는 리뷰 내용에서 나왔어요. 수정 요청을 받은 PR 비율과 PR 하나에 달리는 리뷰 댓글 수가 크게 늘었는데, PR 크기는 유의하게 변하지 않았어요. 따라서 PR이 커져서 댓글이 늘었다는 설명은 이 결과와 맞지 않아요.
| 지표 | 기준 평균 | 에이전트 도입 효과 | 읽는 법 |
|---|---|---|---|
| PR 제출부터 병합까지 | 7.03일 | +3.45일(표준오차 1.60) | 유의, 폭이 넓음 |
| 수정 요청을 받은 PR 비율 | 0.13 | +0.12(표준오차 0.01) | 거의 두 배 |
| PR당 리뷰 댓글 | 1.66개 | +0.58개(표준오차 0.11) | 35% 증가 |
| PR당 추가된 줄 수 | 1,167.97줄 | −67.99줄(표준오차 126.91) | 유의하지 않음 |
앞의 주니어 엔지니어는 인터뷰에서 이렇게 덧붙였어요.
“After some outages that were caused by AI-generated commits, there were also new rules requiring senior engineer approval for AI-generated code, which created even more review bottlenecks.”
AI가 만든 커밋 때문에 장애가 몇 번 난 뒤 AI 코드에는 시니어 승인을 받으라는 규칙이 생겼고, 검토 대기는 더 길어졌다는 이야기예요. 저자는 이 인용을 뜻이 분명하도록 가볍게 다듬었다고 밝혔어요.
수정 요청이 늘었다고 해서 버그가 늘었다고 단정할 수는 없어요. 논문 모델은 이 변화를 초안 품질이 떨어져 생긴 것(bug-rate channel)으로 읽지만, 버그·리버트·장애 건수는 논문에 없고 인터뷰 일화만 있어요. 이 해석은 데이터 제공사의 홍보와도 결이 달라요. Jellyfish는 2026년 1월 블로그에서 예비판(500곳, 10만 명)을 소개하며 “code quality doesn't seem to be suffering”이라고 썼어요. Hacker News에서는 병목의 정체가 처음부터 리뷰가 아니라 품질이었고, 리뷰는 그 품질 문제가 드러나는 자리일 뿐이라는 반론도 나왔어요.
같은 인원 안에서, 검토를 맡는 엔지니어의 비율이 0.29에서 0.33으로 늘었어요
회사 안에서 맡은 일도 움직였어요. 엔지니어 가운데 리뷰를 하는 사람의 비율은 0.29에서 0.04 늘어 14% 커졌고, 코드를 쓰는 사람의 비율(0.43)은 유의하게 변하지 않았어요. 고용 규모도 유의하게 변하지 않았어요. 에이전트 도입 뒤 전체 고용이 2.9% 넘게 줄었을 가능성과 엔지니어 고용이 13.8% 넘게 줄었을 가능성은 배제됐고, 주니어와 시니어 모두 유의한 변화가 없었어요. 사람을 더 뽑지 않은 상태에서, 같은 인원 안에서 리뷰를 맡는 사람의 비율이 늘었다는 결과예요.
AI 코드 리뷰 도구도 빠르게 퍼졌어요. 2026년 3월 기준 표본 회사의 거의 80%가 AI 리뷰 도구를 써 봤어요. 그런데 전체 리뷰 댓글 가운데 AI가 단 댓글은 23.3%였고, AI 댓글을 하나라도 받은 PR은 10.8%였어요. 나머지 댓글 76.7%는 사람이 달았어요. 원문은 AI 리뷰 도구를 들인 뒤에도 리뷰 병목이 남는다고 결론지었어요.
Hacker News의 한 개발자는 시니어 엔지니어들이 한 줄씩 보는 리뷰를 포기하기를 매우 어려워한다고 썼어요. 이 개발자는 처음부터 사람 리뷰를 두지 않는 스타트업에서는 다르게 흘러갈 거라고 했고, 그런 조직은 이번 연구 같은 표본에 잘 잡히지 않는다고 지적했어요. 논문의 공개 설명에는 이 점을 따로 분석한 내용이 없어요.
코드를 짜는 속도는 AI가 올렸지만, 회사가 끝내는 일의 양은 이제 코드가 사람의 검토를 통과하는 속도가 정해요
논문 부록에 실린 한 시니어 엔지니어는 이 구조를 이렇게 말했어요.
“There is only one bottleneck at a time. If you speed up coding, the bottleneck shifts somewhere else.... You can generate features much faster now, but they still need to be validated and approved by humans.”
Jellyfish 기록으로 추정하면 엔지니어는 근무 시간의 42.0%를 코드 쓰는 데, 18.6%를 리뷰에, 39.5%를 관리 업무에 써요. 에이전트는 이 가운데 코드 쓰는 부분을 빠르게 했어요. 그런데 코드가 배포되려면 사람의 검토를 거쳐야 해요. 코드가 늘자 리뷰 한 건에 드는 일도 늘었어요. 수정 요청을 받는 PR이 거의 두 배가 됐고, PR 하나에 달리는 리뷰 댓글도 35% 늘었어요. 회사 안에서는 같은 인원 가운데 리뷰를 맡는 사람의 비율이 14% 커졌는데, 새로 뽑은 사람이 아니라 리뷰로 옮겨 간 몫이에요.
사람을 리뷰로 옮기는 것으로 충분한지도 아직 알 수 없어요. 원문은 병목이 초안 품질에서 생긴 것이라면, 사람을 리뷰로 옮기는 것만으로는 풀리지 않고 기술 자체가 나아져야 한다고 봤어요. 수정 요청을 받은 PR이 거의 두 배가 된 것이 품질 문제의 신호인지는, 버그 기록이 없어서 이 논문만으로는 가를 수 없어요. 어느 쪽이든 늘어난 코드가 멈춘 곳은 사람의 검토 단계였어요.
이 결과에는 시점의 한계가 있어요. 데이터는 2026년 3월에 끝났고, Ars Technica는 그 뒤에도 에이전트가 크게 개선됐으며 많은 회사가 아직 쓰는 법을 배우는 중이라고 짚었어요. 데이터가 독점이라 외부에서 재현할 수 없고, 개인 라이선스로 쓴 에이전트는 도입 기록에 잡히지 않아요.
많은 관리자는 그동안 엔지니어가 코드를 얼마나 많이 쓰는지에 집중했어요. 코딩 에이전트가 코드 줄 수를 30% 늘렸지만, 배포까지 끝낸 일은 늘지 않았어요. 이제 관리자가 집중할 곳은 그 코드가 사람의 검토를 얼마나 빨리, 몇 번 만에 통과하는지예요.
