하버드 연구: AI 코딩 에이전트가 코드는 30% 더 생성하지만 소프트웨어는 늘지 않는다

700개 이상 기업의 엔지니어링 활동을 조사한 하버드 연구에 따르면, AI 코딩 에이전트는 코드 출력을 급격히 증가시킨다—코드 줄 수 30% 증가, 커밋 20% 증가, 풀 리퀘스트 23% 증가—하지만 해결된 이슈나 에픽에는 통계적으로 유의미한 증가가 없었다. 그 이유는 인간의 코드 리뷰가 그 이득을 흡수하기 때문이다: 평균 풀 리퀘스트 리뷰 시간이 49% 증가하고, 변경이 요구되는 풀 리퀘스트의 비율은 거의 두 배가 된다.

하버드 대학 연구원 Fiona Chen과 James Stratton이 수행한 이 연구는 Jellyfish 분석 데이터를 기반으로 하며, fion.ac/jellyfish.pdf에서 PDF로 제공된다. Ars Technica의 Kyle Orland는 2026년 10월 9일 "AI 코딩 에이전트가 더 많은 코드를 생성하지만 더 많은 소프트웨어는 아니다"라는 제목과 "연구 결과 코딩 효율성 이득이 인간 리뷰 '병목'에 '흡수'된다"는 부제로 이를 보도했다.

연구 데이터는 2021년부터 2026년 3월까지의 3억 건의 작업 이벤트를 포함한다

이 연구는 엔지니어링 팀의 세부 출력을 측정하는 플랫폼인 Jellyfish의 집계 분석을 활용한다. Ars Technica에 따르면, 데이터셋은 커밋, 풀 리퀘스트 및 유사한 산출물을 포함한 3억 건의 개별 "작업 이벤트"와 이슈 관리 소프트웨어 데이터를 포함하며, 2021년부터 2026년 3월까지 700개 이상의 소프트웨어 개발 회사의 70만 명 이상의 직원을 대상으로 한다. 논문을 직접 인용한 한 댓글 작성자는 회사 수를 718개로 언급했다.

각 기업의 워크플로에 AI 도구가 도입된 시점을 식별하기 위해, 연구자들은 직접 측정된 AI 사용량과 GitHub 활동 분석을 결합하여 AI 코딩 어시스턴트(주로 인간이 작성한 코드를 자동 완성하는 도구)와 AI 코딩 에이전트(프롬프트에서 자율적으로 코드를 작성하고 제출하는 도구)를 구분했다. 그런 다음 서로 다른 조직에서 도구 도입 전후의 주요 변수에 대해 "이중 차이" 회귀 분석을 실행했다.

코드 양은 급격히 증가하지만, 출시되는 기능은 그렇지 않다

원시 출력 효과는 크고 일관적이다. Ars Technica는 기업에 AI 코딩 에이전트를 도입하면 다음과 같은 결과가 발생한다고 보도한다:

생성된 총 코드 줄 수 30% 증가
총 커밋 수 20% 증가
풀 리퀘스트 23% 증가

연구자들은 전달된 작업에서 비슷한 움직임을 발견하지 못했다. Jira와 같은 도구에서 추적되는 이슈 및 에픽의 해결률—연구에서 소프트웨어 기능 전체의 대리 지표로 사용—은 AI 도구 도입 후 통계적으로 유의미한 변화가 없었다. 연구자들은 또한 AI 도입 전후로 Jira에서 추적되는 이슈의 크기나 복잡성에 "구성적 변화"가 없다는 것을 발견했는데, 이는 평평한 해결률이 팀이 더 크거나 더 어려운 티켓을 처리하기 때문이 아님을 의미한다.

코드 리뷰는 생산성 이득을 흡수하는 병목이다

연구는 누락된 출력을 리뷰 단계에서 찾는다. AI 코딩 에이전트 도입 후:

평균 리뷰 프로세스 시간—풀 리퀘스트 제출부터 병합까지—이 49% 급증
변경이 요청된 풀 리퀘스트의 비율이 거의 두 배가 됨
풀 리퀘스트당 댓글 수가 35% 증가
코드 리뷰를 수행하는 작업자 비율이 14% 증가

논문의 틀에서, 코딩 단계에서 얻은 효율성은 "생산 프로세스의 하류 제약에 흡수"되며, "코드 리뷰 프로세스가 상당히 길어지고, 풀 리퀘스트가 수정을 요구할 가능성이 높아지며, 리뷰어가 더 많은 댓글을 남긴다." 연구는 이러한 도구를 채택함으로써 "기업이 소프트웨어 출력을 늘리거나 고용을 줄인다는 증거가 거의 없다"고 결론을 내린다.

AI 코드 리뷰는 아직 부하를 흡수하지 못하고 있다

연구된 대부분의 기업에 AI 지원 리뷰가 존재하지만, 작업의 소수만 처리한다. 2026년 3월까지 측정된 기업의 80%가 어떤 형태의 AI 코드 리뷰를 사용했지만, AI 에이전트는 전체 리뷰 댓글의 23.3%와 전체 풀 리퀘스트의 10.8%만 담당했다. 인간이 여전히 리뷰 작업의 대부분을 수행했다.

연구는 유의미한 고용 효과를 발견하지 못했다

Jellyfish 데이터의 총 활성 작업자와 동일 기업의 LinkedIn 데이터를 교차 참조한 결과, 연구자들은 "AI에 기인한 유의미한 고용 변화를 귀속시킬 수 없다"고 썼다. 코드 리뷰를 수행하는 작업자 비율의 14% 증가는 순 고용 변화가 아니라 기존 노력의 재배분이다.

비판 1: 데이터는 대부분 2025년의 것이며, 모델은 오래되었다

Hacker News 토론에서 가장 반복된 반론은 연구가 이미 지나간 세계를 설명한다는 것이다. 댓글 작성자 jefftk는 다음과 같이 썼다:

학술 논문의 표준적인 방식대로, 이것은 연구를 수행한 시점의 세계 상태를 설명하려는 시도입니다. 그러나 그 후에 작성하고 발표하는 데 시간이 걸리고, 신문은 그것을 현재 사건으로 보도합니다. 이 경우, 우리는 2025년의 그림을 보고 있습니다. 주요 에이전트 결과에 관련된 모델은 주로 Claude 3.5에서 Sonnet 4.5, GPT-4.1에서 GPT-5, Gemini 2.5였습니다. 그리고 논문의 설계상, 회사가 좋은 리뷰 프로세스를 개발하기 전의 초기 배포 효과를 주로 보게 됩니다.

댓글 작성자 hyperpape는 자신의 디렉터가 논문을 공유했다고 말하며, 같은 요점을 위해 특정 기준 수치를 인용했다: 작업자 월당 기준 평균 5,017줄의 코드와 추정 증가 1,494줄, 월간 5.34개의 풀 리퀘스트 기준이 1.22 증가, 기준 평균 코드 리뷰 시간 7.03일. 그들은 작은 백분율 증가가 데이터가 오래되었음을 확인한다고 주장했고, 별도로 평균값 사용을 비판했다:

평균 풀 리퀘스트가 7일 동안 대기한다면, 당신은 분명히 무엇이든 출시하는 것에 신경 쓰지 않는 것이며, 에이전트가 그것을 바꾸지 않을 것입니다.

비판 2: "더 많은 소프트웨어"는 닫힌 티켓으로 측정된다

댓글 작성자 dcre는 종속 변수를 직접 지적했다:

그들이 "더 많은 소프트웨어"를 "더 많은 티켓 닫힘"으로 정의한다는 점에 주목하세요. 그 의미는 각자 해석하세요. 그들은 티켓의 범위가 증가하지 않았기 때문에 이것이 좋은 측정치라고 주장합니다. 이것이 그들이 주장하는 바를 포착하는지 고려할 가치가 있습니다. 코딩 에이전트 덕분에 작성한 추가 테스트가 작업 티켓에 반영됩니까?

비판 3: 표본은 정확히 혜택을 받을 가능성이 가장 높은 팀을 제외한다

데이터셋이 Jellyfish를 사용하고 측정 가능한 작업 이벤트 발자국을 생성하는 기업에서 비롯되었기 때문에, 여러 댓글 작성자는 연구가 구조적으로 개인 개발자, 소규모 스타트업, 개인 프로젝트를 놓친다고 주장했다. 댓글 작성자 dolebirchwood는 다음과 같이 썼다:

Jellyfish를 사용하지 않는 다른 모든 사람들이 구축하는 소프트웨어는 어떻습니까? 대기업과 같은 운영 병목이 없고 실제로 더 많은 것을 구축하는 소규모 회사는 어떻습니까? AI 없이는 결코 만들지 않았을 소프트웨어를 만들고 회사를 시작하는 솔로 창업자는 어떻습니까?

댓글 작성자 joshheitzman은 구체적인 예를 제시했다—Kilo Code로 시작한 FluxImp라는 프로젝트로, 나중에 자체 수정이 가능해졌고 주로 개인 서버에서 Mercurial로 개발되어 "GitHub 활동이 거의 없다"고 말했다. 그들은 "비소프트웨어 엔지니어가 자신에게 유용한 작은 소프트웨어를 만드는 모든 이야기도 쉽게 연구되기 어려운 종류의 발자국을 생성할 가능성이 낮아 보인다"고 덧붙였다.

댓글 작성자 KumaBear는 더 간결하게 같은 요점을 말했다: "집에서 만든 개인용 소프트웨어는 확실히 급증했습니다. 시간이 없을 거라고 생각했던 프로젝트가 이제 가능해졌습니다." 댓글 작성자 juliendorra는 이 순간을 HyperCard에 비유하며, 제한된 범위의 개인 소프트웨어 붐을 설명했다—디자이너가 프로젝트마다 도구를 만들고, 개발자가 아트 소프트웨어를 만들고, 파워 유저가 플러그인과 맞춤 워크플로를 요청하는 것.

비판 4: 병목은 인지적이 아니라 조직적일 수 있다

여러 댓글 작성자는 코드 리뷰가 실제 제약이 아니라고 주장했다. 댓글 작성자 blauditore는 레이싱 비유를 제시했다: 엔진이 결국 타이어를 능가하므로, 슈퍼연료는 랩 타임 이득을 미미하게 만든다. 댓글 작성자 gchamonlive는 의사소통이 소프트웨어 생산에서 가장 어려운 부분이며 "소프트웨어 생산은 이미 그랬던 것보다 더 언어학의 자매 분야가 되었다"고 말했다. 댓글 작성자 jmward01은 병목이 명확한 비전과 올바른 다음 단계로 제품을 진화시키는 팀의 능력이며, "이 업계의 프로세스는 AI와 무관하게 형편없다"고 주장했다.

댓글 작성자 forgotaccount3는 리뷰보다 계획 의식을 지적하며, 충분히 정확하게 작성된 스토리가 "AI 에이전트에 복사해서 구현하게 할 수도 있다"고 설명하고, 스토리 포인트와 스프린트 용량 제한 때문에 2주 동안 백로그에 앉아 있다고 말했다.

실무자들은 연구 결과가 자신의 경험과 일치하는지에 대해 의견이 분분하다

일부 댓글 작성자는 연구가 자신의 직장 생활과 일치한다고 보고했다. Ars Technica의 스태프 픽인 사용자 metavirus의 댓글은 단호했다:

저는 직장에서 AI를 사용해야 하며 이것은 10000% 사실입니다. 수많은 슬롭 코드가 분지로 흘러 들어가고, 수십 명의 사람들이 그것을 걸러내고, 찌꺼기를 걸러낸 다음, 결국 눈을 감고 야생에 풀어 놓습니다. 왜냐하면 이제 새로운 SLA가 있어서 우리가 진보의 병목으로 보이지 않기 때문입니다.

댓글 작성자 PacificSpecific는 친구가 Claude 제출물을 리뷰하는 일이 작업의 80%였기 때문에 직장을 떠났다고 보고했다. 댓글 작성자 atleastoptimal은 새로운 리뷰 부하의 산술을 설명했다: "하루에 1,000줄을 리뷰하는 대신 이제 하루에 10,000줄을 '리뷰'합니다. 제 뇌는 10배 빠르지 않습니다."

다른 사람들은 반대를 보고했다. 댓글 작성자 keithnz는 자신의 팀이 더 많은 소프트웨어를 생산하고 더 야심차게 작업하고 있으며, 사양, 아키텍처, 코딩, 성능, 테스트 지침에 대한 과감한 사전 투자 덕분이라고 말했다. 댓글 작성자 tdhz77는 "AI 이후로 더 완전한 소프트웨어를 만들었습니다. 이것은 미친 생각입니다."라고 썼다. 댓글 작성자 mrieck는 테스트, 리뷰, 개선이 이제 더 많은 시간이 걸리는 이유는 정확히 생산되는 소프트웨어의 양이 더 많기 때문이며, 스타트업이 이전보다 약 10배 더 많은 것을 검증할 수 있다고 주장했다.

코드 리뷰가 자동화되더라도 사라지지 않는 이유

댓글 작성자 zmmmmm은 코드 품질과는 별개의 책임성 논거를 제기했다:

자동화된 리뷰는 코드가 의도한 대로 동작하는지 확인하는 데 도움이 되지만, 의도가 올바른지 확인하지는 않습니다. 백도어를 삽입하거나, 테스트를 우회하거나, 작업을 더 빨리 끝내기 위해 설계 결정을 "속이는" 직원은 변경을 주도하는 사람이 AI에게 그것이 의도된 결과라고 말하면 식별되지 않을 것입니다.

그들은 지속적인 보호는 "'이 변경을 이해하고 승인합니다'라고 말하며 자신의 평판을 걸 의향이 있는 인간"이라고 결론지었다.

댓글 작성자 staminade는 리뷰 문화의 변화가 먼저 올 곳을 예측했다: 기존 팀이 아니라 "처음부터 인간 리뷰 없는 정책을 채택하고 성숙하면서 유지하는 스타트업"이며, 이는 현재 연구에서는 거의 보이지 않을 것이라고 말했다. 그런 회사가 훨씬 빠르게 출시한다면, 나머지 업계는 따라야 할 것이라고 staminade는 주장했다.

연구가 해결하지 못하는 것

이 논문은 이미 엔지니어링 분석을 갖춘 기업을 2026년 3월에 끝나는 기간 동안 측정하며, Jira 이슈 해결을 출시된 소프트웨어의 정의로 사용한다. 개인 프로젝트, 솔로 창업자, 또는 풀 리퀘스트 워크플로를 완전히 대체한 팀은 측정하지 않는다. 또한 대부분의 조직이 AI 생성 코드에 대한 리뷰 관행을 정착시키기 전의 에이전트 코딩 초기 배포 기간을 포착한다.

Ars Technica가 지적했듯이, 연구의 기업 중 95%가 데이터 마감 시점까지 AI 코딩 에이전트를 구현했으며, 에이전트 기능은 이후 계속 변화해 왔다. 연구가 문서화한 "코딩 시간 대 리뷰 시간" 트레이드오프는 팀이 문제를 에이전트에 넘길 때와 넘기지 않을 때를 배우면서 바뀔 수 있다. 현재로서는 측정된 결과는 양날의 검이다: 더 빠른 코드 생성이 인간 리뷰 시간과 노력의 상당한 증가로 상쇄된다.