AI 코딩 생산성 24%를 읽는 법: PR 수와 업무 가치는 다르다
Microsoft의 CLI 코딩 에이전트 도입 연구에서 나온 PR 병합 증가 결과와 인과 추론의 한계를 살펴보고 팀에서 확인할 생산성 기준을 제안합니다.
PR이 늘면 일이 더 잘 끝난 걸까
에이전트 도입 이후 병합한 PR이 많아졌다. 좋은 신호처럼 보이지만, 변경을 더 작게 나눈 결과인지 가치 있는 기능이 늘어난 것인지 따져야 한다. 8월 9일 브리핑에서 언급한 생산성 연구는 이 질문을 꺼내기에 적절하다.
연구가 관찰한 것은 병합한 PR이다
Microsoft의 2026년 초 CLI 코딩 에이전트 도입 연구는 수만 명의 엔지니어를 대상으로 Claude Code와 GitHub Copilot CLI의 채택과 영향을 분석했다. 연구자들은 도입자가 에이전트를 쓰지 않았을 경우에 비해 약 24% 더 많은 PR을 병합했을 것으로 추정했다.
이 연구는 7월에 공개된 자료로, 8월 9일의 신제품 발표는 아니다. 특정 조직에서 관찰한 PR 지표를 전체 개발 생산성의 증가율로 바꿔 읽어서는 안 된다. 비교 방법과 채택자의 특성에 따라 해석 범위가 달라진다.
산출물의 개수만 보면 놓치는 것
PR이 작아지면 병합 수가 늘고 검토는 쉬워질 수 있다. 반대로 잦은 재수정으로 수가 늘 수도 있다. 같은 숫자에 서로 다른 상황이 담긴다.
그래서 팀의 평가에는 코드가 반영된 뒤의 결과를 넣는 편이 좋다. 장애, 되돌리기, 후속 수정, 검토시간을 함께 보면 에이전트가 어떤 작업에서 도움을 주는지 더 잘 보인다. 이 부분은 연구 결과를 실무에 적용하기 위한 제안이다.
도구를 평가할 때 작업도 구분하자
신규 기능, 테스트 이관, 문서 정리, 원인 불명 버그를 한 바구니에 담으면 판단이 흐려진다. 작업 종류를 나누고 비슷한 난이도의 사례를 비교하자.
- 완료 여부와 검토에 든 시간을 함께 기록한다.
- 실패하거나 포기한 세션도 남긴다.
- 병합 뒤 수정이 필요한 사례를 추적한다.
- 도입 전후에 작업 범위가 달라졌는지 확인한다.
생산성 연구는 도입을 검토할 근거를 준다. 우리 팀의 결과를 대신 계산해 주지는 않는다.
오늘의 트리거는 PR 숫자 하나에 만족하는 대신, 그 변경이 어떤 문제를 끝냈는지 묻는 일이다.
참고 자료
브리핑 표지 보기
