한 하버드 워킹 페이퍼 는 흔한 생산성 주장을 점검할 유용한 근거를 제공한다. AI로 더 많은 코드를 작성하면 더 많은 소프트웨어를 제공할 수 있다는 주장이다. Jellyfish 엔지니어링 분석 플랫폼을 사용하는 718개 기업에서 Fiona Chen과 James Stratton은 코딩 에이전트 도입 후 활성 직원 1인당 코드 줄 수가 30%, 커밋 수가 20%, 풀 리퀘스트 수가 23% 늘어난 것으로 추정했다. 이들이 측정한 완료된 Jira 이슈와 에픽은 통계적으로 유의한 증가를 보이지 않았다. 논문의 최신 버전 날짜는 2026년 8월 4일이며, 업무 이벤트 데이터는 2026년 3월까지다.

이 차이는 엔지니어링 리더에게 중요하다. 풀 리퀘스트는 검토, 테스트, 수정 가능성이 있는 대기열에 들어가기 때문이다. 같은 연구에서 에이전트 도입 후 풀 리퀘스트 제출부터 병합까지 걸린 시간이 49% 늘어난 것으로 추정됐다. 변경 요청이 더 흔해졌고 풀 리퀘스트당 댓글도 늘었다. 이러한 결과는 검토 업무가 늘었음을 시사하지만, 에이전트가 작성한 모든 변경 사항이 부실하다거나 결함률이 측정됐다는 뜻은 아니다.

핵심 변화

  • 무엇이 달라졌나:이 기업 단위 연구에서 코딩 에이전트 도입은 코딩 활동의 큰 증가 및 더 까다로운 풀 리퀘스트 검토와 함께 나타났지만, 해결된 이슈나 에픽은 통계적으로 유의하게 증가하지 않았다.
  • 왜 중요한가:코드 줄 수, 커밋, 풀 리퀘스트는 생산 과정에 들어오는 업무를 측정한다. 해결된 업무는 그보다 뒤 단계의 지표다. 코드 양만으로 에이전트를 평가하는 팀은 검토 단계에 쌓이는 부담을 놓칠 수 있다.
  • 지켜볼 점:기업이 검토 역량을 늘릴 수 있는지, 이후 데이터에서 완료된 업무가 증가하는지 살펴봐야 한다. 이 워킹 페이퍼는 2026년 3월까지 초기 도입을 추적하므로 장기적인 영향을 확정할 수 없다.

어시스턴트와 에이전트의 추정치는 달랐다

저자들은 어시스턴트와 에이전트를 구분한다. 어시스턴트는 개발자가 작업하는 동안 코드 제안을 제공하고, 에이전트는 더 높은 수준의 작업을 맡아 개발자가 결과를 승인하기 전까지 여러 단계를 수행할 수 있다. 어시스턴트 도입은 GitHub Copilot 및 Cursor 기업용 라이선스 활성화로 측정했다. 에이전트의 경우 Claude Code 사용 데이터와 커밋 또는 풀 리퀘스트의 봇 계정, 도구 서명 같은 신호를 결합했다. 일부 개인 사용이나 통합되지 않은 도구는 이 측정에서 빠질 수 있다. 에이전트 추정치는 이전 어시스턴트 도입 기간과 비교한 에이전트 도입의 추가 연관성이지, 에이전트를 사용하는 개인별 추정치가 아니다.

어시스턴트의 결과는 더 작았다. 코드 줄 수는 12%, 커밋은 9%, 풀 리퀘스트는 5% 증가한 것으로 추정됐다. 논문의 주요 추정치에서 통계적으로 유의한 것은 커밋 결과뿐이었다. 에이전트 도입은 세 가지 코딩 활동 지표 모두에서 유의한 증가를 보였다. 커밋은 코드 업데이트를 기록하고, 풀 리퀘스트는 검토를 위해 변경 사항을 제출한다. 어느 쪽도 기능이 사용자에게 도달했음을 입증하지는 않는다. 논문은 검토, 테스트, 배포 후 팀이 업무를 완료로 표시하는 추적 절차를 바탕으로 완료된 Jira 이슈와 대형 에픽을 후속 단계의 산출 지표로 사용한다. Jira 상태는 여전히 제공된 결과에 대한 독립 측정이 아니라 전달의 대리 지표다.

에이전트의 경우 해결된 이슈 증가는 직원 1인·월 기준 0.12건으로 추정됐고, 기준치는 3.67건, 표준오차는 0.17이었다. 이 결과는 통계적으로 0과 구별되지 않는다. 에픽 완료 역시 유의한 변화가 없었다. 저자들은 신뢰구간이 연구 기간 동안 기준 평균의 12%를 넘는 이슈 완료 증가를 배제한다고 보고한다. 이는 에이전트가 유용한 소프트웨어를 전혀 만들지 못한다는 말보다 범위가 좁은 결론이다. 작은 개선은 여전히 가능하며 이슈 수로는 가치나 품질의 모든 변화를 포착할 수 없다. 저자들은 예측된 작업 소요시간 지표로 이슈 크기의 변화를 확인했으며, 표본에서 그런 변화의 증거를 찾지 못했다.

검토자에게 더 많은 업무가 도달했다

검토 지표는 산출 격차의 그럴듯한 원인을 제시한다. 에이전트 도입 후 풀 리퀘스트 제출부터 병합까지 기준치 7.03일에 더해 3.45일이 늘어 49% 증가했다고 논문은 추정한다. 이는 검토 과정의 달력상 기간이지, 한 사람이 실제로 검토한 시간을 초시계로 잰 값이 아니다. 공식 변경 요청을 받은 풀 리퀘스트 비율은 기준치 13%에서 약 12%포인트 늘었고, 요청당 댓글은 기준치 1.66개에서 0.58개, 즉 35% 증가했다. 한 달에 한 건 이상 풀 리퀘스트를 검토한 직원 비율은 기준치 29%에서 약 4%포인트 늘어 상대적으로 14% 증가했다. 비교 가능한 어시스턴트 추정치에서는 검토 기간, 변경 요청 또는 댓글의 유의한 증가가 나타나지 않았다.

이 메타데이터만으로는 검토자가 왜 변경을 요청했는지 논문이 알 수 없다. 제출물이 늘면 고정된 검토 대기열이 압박을 받을 수 있고, 코드 품질이나 검토 기준의 변화도 더 면밀한 검토로 이어질 수 있다. 저자들은 평균 풀 리퀘스트 크기의 유의한 증가를 발견하지 못했으며, 이는 댓글 증가에 대한 한 가지 단순한 설명을 약화한다. 코드 내용을 직접 살펴보거나 에이전트 생성 작업의 결함을 직접 세지는 않았다. 두 단계 생산 모델은 코드 작성이 빨라지고 초안별 검토 요구가 달라지는 일이 함께 완료 산출을 제한할 수 있는 경로를 설명한다. 이 모델은 관찰 결과에 대한 해석이며, 어느 메커니즘이든 분리해 검증하는 별도 실험은 아니다.

AI 검토 도구도 표본 기업에 확산됐다. 2026년 3월까지 거의 80%가 이를 사용했다. 그러나 논문은 검토 댓글의 23.3%를 AI에 귀속하고, 풀 리퀘스트의 10.8%에서 AI 댓글이 하나 이상 발견됐다고 보고한다. 따라서 검토 도구 도입이 이 기업들의 검토 자동화를 뜻하지는 않는다.

연구 설계로 알 수 있는 것

연구진은 동의한 Jellyfish 고객사 718곳의 2021년 1월부터 2026년 3월까지 업무 이벤트 약 3억 건을 분석했으며, 직원 725,938명을 포함한다. 단계적 차이의 차이 설계를 사용해 어시스턴트나 에이전트를 도입한 기업의 도입 전후 결과를 나중에 도입했거나 아직 도입하지 않은 기업의 결과와 비교한다. 기업 및 달력 월 통제 변수는 일부 안정적인 차이와 공통 시간 추세를 다룬다. 추론은 도입이 없었을 때 이 기업들의 경로가 얼마나 비슷했을지에 달려 있다. 대기업이 더 일찍 도입했고, 관찰되지 않은 변화가 도입과 엔지니어링 업무 모두에 영향을 줬을 수 있다. 관찰 연구이므로 추정치를 무작위 시험이나 모든 소프트웨어 팀에 대한 예측으로 읽어서는 안 된다.

고용 결과에도 같은 신중함이 필요하다. LinkedIn과 연계한 전체 고용 및 Jellyfish의 활성 직원을 엔지니어링 고용 지표로 사용했을 때, 저자들은 관찰 기간 중 에이전트 도입에 따른 유의한 변화를 확인하지 못했다. 그렇다고 더 긴 조정 기간 이후나 더 넓은 노동시장에서 채용이 어떻게 될지 알 수 있는 것은 아니다.

이전 BIG CHANGE 보도 에서는 AI 코딩과 안정적인 제공에 관한 별도의 엔지니어링 사례를 살펴봤다. 이번 연구는 여러 기업을 살펴보고 코딩 활동, 검토, 해결된 업무를 서로 다른 지표로 측정한다. 실무적 교훈은 에이전트를 평가할 때 이 단계들을 함께 추적하라는 것이다. 첫 초안이 빨라지면 후속 단계에서 기다리는 업무량이 달라지며, 이 논문은 아직 완료된 이슈나 프로젝트의 그에 상응하는 증가를 보여주지 않는다.

출처 및 추가 자료