AI 코딩 도구의 효과를 이야기할 때 가장 많이 인용되는 숫자가 있습니다. "55.8% 빨라졌다"는 GitHub의 실험 결과입니다. 이 숫자는 실재합니다. 다만 그 숫자가 무엇을 재고 무엇을 재지 않았는지까지 봐야 우리 조직에 적용할 수 있습니다.
통제 실험이 보여준 것
프리랜서 개발자를 두 그룹으로 나눠 같은 과제(HTTP 서버 구현)를 주고 한쪽만 Copilot을 쓰게 했습니다. 결과는 71분 대 161분, 55.8% 단축이었습니다 (원 논문). 통계적으로도 유의미했습니다.
- 각 그룹 35명이 과제를 완료했습니다
- 이후 3개 기업에서 진행한 대규모 현장 실험(4,867명)에서는 완료 과제가 26.08% 늘었습니다. 이쪽은 동료평가를 거쳐 학술지에 실렸습니다
- 유료 구독자는 2026년 1월 기준 470만 명으로, 전년 대비 75% 늘었습니다 (회사 발표) (MS 실적)
실험실 수치와 현장 수치가 다르다는 점에 주목할 만합니다. 말하자면 55.8%는 표준화된 단순 과제에서 나온 상한선에 가깝고, 실제 조직에서 기대할 값은 26% 쪽에 가까운 셈입니다.
그런데 정반대 결과도 있습니다
2025년 METR는 숙련된 오픈소스 개발자 16명에게 자신이 잘 아는 코드베이스의 실제 과제 246건을 맡겼습니다. AI를 썼을 때 오히려 19% 느려졌습니다 (METR 실험).
더 중요한 건 그다음입니다. 정작 개발자 본인들은 "20% 빨라졌다"고 느꼈습니다. 체감과 실측이 정반대로 나온 것입니다. 요컨대 만족도 조사만으로 도입 성과를 판단하면 반대 결론에 이를 수 있습니다.
품질 쪽 신호도 있습니다. GitClear는 코드 변경 6억 건 이상을 분석해 중복 코드가 늘고 리팩터링 비중이 줄어드는 흐름을 관찰했습니다 (LeadDev 보도). 다만 이것은 상관관계이지 인과관계가 입증된 것은 아닙니다.
무엇이 결과를 갈랐나
두 실험의 차이는 대상자와 과제였습니다.
- 이득이 큰 쪽: 신입·저숙련 개발자, 익숙하지 않은 영역, 정형화된 과제
- 손해가 나는 쪽: 숙련 개발자, 본인이 이미 훤히 아는 코드베이스, 맥락이 복잡한 과제
즉 효과는 숙련도에 반비례합니다. 그래서 전사에 일괄 배포하는 방식이 최선이 아닐지도 모릅니다.
우리 조직이라면
도입 자체보다 측정 설계가 어렵습니다. 그러니 세 가지를 먼저 정합시다.
- 속도만이 아니라 재작업률과 중복률을 같이 잽니다. 속도 지표만 KPI로 잡으면 품질 부채가 숨습니다.
- 도입 전 baseline을 측정합니다. 없으면 나중에 체감으로만 평가하게 됩니다.
- 대상군을 나눠 먼저 적용합니다. 신입 비중이 높은 팀에서 효과가 먼저 나타납니다.