AI 코딩 도구는 빠른가: 서로 반대인 연구를 함께 읽는 법

GitHub 연구가 답한 질문

GitHub는 초기 Copilot 사용자를 대상으로 설문과 통제된 과제 실험을 진행했습니다. 반복 작업의 부담, 몰입 유지, 만족도와 과제 완료 속도를 여러 방식으로 살폈다는 점이 중요합니다.

이 결과는 보조 도구가 짧고 명확한 코딩 과제에서 도움을 줄 수 있다는 근거입니다. 다만 특정 제품의 초기 사용자를 포함한 연구라는 점, 실제 장기 프로젝트 전체를 그대로 재현한 것은 아니라는 점도 함께 봐야 합니다.

METR 연구가 다른 결과를 낸 이유

METR은 경험 많은 오픈소스 개발자가 자신이 오랫동안 다룬 대형 저장소의 실제 이슈를 해결하도록 했습니다. 초기 2025년 도구를 허용한 작업에서 완료 시간이 더 길게 나타났고, 개발자들은 실제 측정과 달리 자신이 빨라졌다고 느꼈습니다.

연구진은 이 결과를 모든 개발자와 모든 작업에 일반화하지 말라고 분명히 적었습니다. 또한 해당 페이지는 2026년에 더 최신 도구를 다룬 후속 결과가 나와 초기 결과가 현재 상태를 그대로 대표하지 않는다고 표시합니다. 오래된 수치를 현재 제품의 고정된 성능처럼 인용하면 안 되는 이유입니다.

서로 다른 연구를 비교하는 다섯 질문

이 질문에 답하지 않은 채 퍼센트만 옮기면 서로 다른 연구가 충돌하는 것처럼 보입니다. 실제로는 각 연구가 다른 업무 환경을 측정하고 있을 가능성이 큽니다.

• 참가자는 초보자인가, 숙련자인가, 해당 코드베이스에 익숙한가
• 과제는 새 파일 작성인가, 기존 대형 시스템의 수정인가
• 시간만 재는가, 리뷰·테스트·재작업까지 포함하는가
• 설문 인식인가, 실제 행동 기록인가
• 어떤 시점의 모델과 도구 버전을 사용했는가

팀에서는 무엇을 측정해야 하나

코드 생성량이나 도구 활성 사용자 수는 도입 현황을 보여주지만 사업 성과를 직접 말해주지는 않습니다. DORA가 강조해 온 흐름 지표처럼 변경이 배포되기까지 걸리는 시간, 실패와 복구, 안정성을 함께 봐야 합니다.

AI 도구 전후를 비교할 때는 일정 기간 같은 종류의 작업을 묶고, 코드 리뷰 시간과 수정 요청 횟수, 테스트 실패, 운영 장애까지 기록해야 합니다. 처음 한두 주의 학습 비용과 이후 효과도 분리해서 보는 편이 좋습니다.

실무 적용: 전면 도입보다 작업별 실험

자동 완성, 테스트 초안, 문서화, 낯선 코드 탐색, 대규모 리팩터링은 서로 다른 작업입니다. 팀 전체에 하나의 목표치를 적용하기보다 업무별로 허용 범위와 검증 항목을 정하는 편이 현실적입니다.

도구가 잘하는 작업은 더 넓히고, 리뷰 비용이 커지는 작업은 제한할 수 있어야 합니다. 생산성은 ‘AI를 썼는가’가 아니라 최종적으로 안전한 변경을 더 빠르게 전달했는가로 판단해야 합니다.