GitHub Copilot and Developer Productivity: An Observational Dose-Response Analysis

당신이 새로운 하이테크 러닝화가 실제로 사람들을 더 빠르게 달리게 만드는지 알아내려고 한다고 상상해 보십시오.

가장 명백한 테스트 방법은 두 그룹을 비교하는 것입니다: 하이테크 신발을 신는 사람들과 일반 운동화를 신는 사람들 말이죠. 하지만 여기 문제가 있습니다. 하이테크 신발을 '선택'한 사람들은 이미 프로 운동선수일 수도 있고, 반대로 운동화 착용자들은 일반 조깅 애호가들일 수도 있습니다. 만약 신발을 신은 사람들이 더 빨리 달린다면, 그것은 신발 때문일까요, 아니면 애초에 그들이 더 뛰어난 러너였기 때문일까요?

이것이 바로 마이크로소프트 연구진이 소프트웨어 엔지니어가 코드를 작성하는 것을 돕는 AI 도구인 GitHub Copilot을 두고 직면했던 바로 그 퍼즐입니다. 그들은 알고 싶었습니다: AI를 사용하는 것이 실제로 엔지니어의 생산성을 높여주는 것일까, 아니면 AI를 가장 많이 사용하는 엔지니어가 원래부터 더 생산적인 사람인 것일까?

설상가상으로, 두 번째 혼란의 층위가 존재합니다. 어떤 엔지니어가 특정 주에 AI를 많이 사용하는 이유는 AI가 마법 같아서가 아니라, 그 주가 거대한 프로젝트를 수행하느라 하루 80시간씩 일해야 하는 '크런치 모드(crunch time)'였기 때문일 수도 있습니다. 이 경우, 그들은 AI 덕분에 더 '빨리' 일해서가 아니라, 단순히 더 '오래' 일했기 때문에 더 많은 작업(Pull Requests)을 완료하게 되는 것입니다.

해결책: "자기 비교(Self-Comparison)" 실험

연구진은 일부 엔지니어에게 도구 사용을 중단하도록 강제할 수 없었기에(그것은 비윤리적이며 업무를 방해할 것이기 때문입니다), "내부 엔지니어(Within-Engineer)" 분석이라는 영리한 트릭을 사용했습니다.

이렇게 생각해보십시오: 엔지니어 A(AI 사용)와 엔지니어 B(미사용)를 비교하는 대신, 그들은 엔지니어 A를 자기 자신과 비교했습니다.

그들은 동일한 엔지니어를 43주 동안 관찰했습니다.

• 1주 차: 엔지니어가 AI를 거의 사용하지 않았습니다.
• 2주 차: 엔지니어가 AI를 집중적으로 사용했습니다.

엔지니어를 자기 자신과 비교함으로써, 엔지니어 A와 B를 다르게 만드는 모든 요소(천부적인 재능, 직무 역할, 또는 팀 문화 등)를 자동으로 상쇄할 수 있었습니다. 그들은 이렇게 질문한 것입니다: "이 특정 인물이 AI를 더 많이 사용할 때, 사용하지 않을 때보다 더 많은 일을 해내는가?"

"효율성" 테스트: 더 열심히 일한 것인가, 더 똑똑하게 일한 것인가?

여전히 까다로운 변수가 하나 남아 있었습니다: 바로 **노력(Effort)**입니다.
만로 엔지니어가 AI를 많이 사용한다면, 그들은 단지 코딩을 위해 5시간이 아닌 10시간 동안 컴퓨터 앞에 앉아 있는 것일 수도 있습니다. 만약 그들이 더 많은 작업을 완료했다면, 그것은 단지 책상 앞에 머문 시간이 길었기 때문일 수도 있습니다.

이를 해결하기 위해 연구진은 코딩에 소비된 시간을 일정하게 유지하는 통계적 "필터"(PPML이라 불리는 모델)를 사용했습니다.

• 질문: "엔지니어 A가 정확히 8시간 동안 코딩한다고 가정할 때, AI를 집중적으로 사용할 때가 그렇지 않을 때보다 더 많은 코드를 작성하는가?"

결과: 그렇습니다. 코딩 시간이 정확히 동일할 때도, AI를 집중적으로 사용한 엔지니어들은 AI를 전혀 사용하지 않은 주에 비해 약 **40% 더 많은 코드 프로젝트(Pull Requests)**를 완료했습니다.

"위조 검증(Falsification)" 세트: 변명 차단하기

연구진은 회의론자들이 이 결과에 대해 다른 이유들을 제시할 것임을 알고 있었습니다. 그래서 그들은 결과가 단순한 우연이 아님을 확인하기 위해 7가지의 "거짓말 탐지기" 테스트를 실행했습니다.

1. "범용 AI" 테스트: 혹시 AI를 많이 사용하는 엔지니어들이 전반적으로 "기술 친화적"이라서 다른 AI 도구들(Word나 Excel 같은)도 많이 사용하고, 그 때문에 생산성이 높아진 것처럼 느껴지는 것일까?

   • 테스트: 코딩 외의 앱(PowerPoint 등)에서 AI를 사용하는 것이 코드 작성을 예측하는지 확인했습니다.
   • 결과: 아니었습니다. Word에서의 AI 사용은 코드 작성에 도움이 되지 않았습니다. 오직 코딩용 AI만이 중요했습니다.

2. "팀 하이프(Hype)" 테스트: 혹ende 전체 팀이 "열광적인(hype)" 주간을 보내고 있어서, 팀원 모두가 AI를 사용하고 모두가 코드를 더 많이 작성한 것은 아닐까?

   • 테스트: 한 엔지니어의 AI 사용량이 동료들의 코드 산출량을 예측하는지 확인했습니다.
   • 결과: 아니었습니다. 만약 그것이 단순한 팀 차원의 열기였다면, 당신의 AI 사용량이 옆 사람의 산출량을 예측해야 합니다. 하지만 그렇지 않았습니다.

3. "작업 전환" 테스트: 혹시 AI를 많이 사용하는 주간에 엔지니어들이 다른 사람의 코드를 검토하는 것을 멈추고 오로지 자신의 코드 작성에만 집중한 것은 아닐까?

   • 테스트: 코드를 더 많이 작성하는 것이 코드 리뷰를 적게 하는 것을 의미하는지 확인했습니다.
   • 결과: 아니었습니다. 엔지니어들은 AI를 사용할 때 코드를 더 많이 작성했을 뿐만 아니라, 리뷰도 더 많이 했습니다. 그들은 단순히 업무를 맞바꾼 것이 아니라, 모든 것을 더 많이 했습니다.

4. "슬라이싱(Slicing)" 테스트: 혹시 엔지니어들이 숫자를 좋게 보이게 하려고 큰 프로젝트를 아주 작은 조각들로 쪼개서 제출한 것은 아닐까?

   • 테스트: 코드 프로젝트의 크기를 조사했습니다.
   • 결과: 아니었습니다. 가장 큰 폭의 상승은 작은 조각이 아니라, 오히려 **가장 크고 복잡한 프로젝트(파일 7개 이상)**에서 나타났습니다.

5. "쉬운 작업" 테스트: 혹시 어려운 코딩 대신 쉬운 문서 작업(예: 텍스트 파일 업데이트)만 한 것은 아닐까?

   • 테스트: "쉬운" 설정 파일과 "어려운" 코드 파일을 분리했습니다.
   • 결과: 아니었습니다. 생산성 향상은 어려운 코드 파일에서 오히려 더 강력하게 나타났습니다.

6. "타이밍" 테스트: 혹시 1주 차의 AI 사용량이 2주 차까지 이어지는 "생산적인 기분"의 징후였던 것은 아닐까?

   • 테스트: 지난주의 AI 사용량이 이번 주의 산출량을 예측하는지 확인했습니다.
   • 결과: 아니었습니다. 생산성 향상은 AI가 사용된 바로 그 주간에만 발생했습니다.

결론

이 연구는 GitHub Copilot이 엔지니어를 진정으로 효율적으로 만든다고 결론짓습니다.

엔지니어가 이 도구를 더 집중적으로 사용할 때, 동일한 시간 내에 약 40% 더 많은 작업을 완수합니다. 이는 단순히 생산적인 사람들이 이 도구를 사용하는 것이 아니라, 도구 자체가 일종의 '힘의 증폭기(force multiplier)' 역할을 하여 엔지니어가 더 긴 시간을 일하지 않고도 더 많은 일을 할 수 있도록 돕는다는 것을 의미합니다.

하지만 연구진은 다음과 같이 주의를 기울입니다. 이 연구는 효율성(시간당 더 많은 일을 하는 것)을 측정하는 것이지, 총 절약된 시간을 측정하는 것이 아닙니다. 만약 AI가 당신의 작업을 1시간 대신 30분 만에 끝내도록 도와준다면, 당신의 "효율성"은 올라가지만, 당신은 그냥 일을 일찍 끝내고 퇴근할 수도 있습니다. 이 연구는 속도가 증가한다는 것을 증명하지만, 엔지니어가 그 남는 시간을 정확히 어떻게 사용하는지는 말해주지 않습니다.