AI 코딩 도구가 개발 속도를 높인다는 경험담은 많지만, 효과는 작업과 코드베이스에 따라 달라진다. METR의 2025년 실험에서는 익숙한 오픈소스 저장소를 다루는 숙련 개발자들이 AI 도구를 썼을 때 오히려 더 오래 걸렸고, 참가자들은 자신이 빨라졌다고 느꼈다. 이 결과는 코드 생성 속도와 작업 전체 시간을 따로 측정해야 한다는 점을 보여준다.
개발자가 느낀 속도와 실제 완료 시간
2025년 7월 METR은 숙련 오픈소스 개발자 16명을 대상으로 한 무작위 대조 실험 결과를 공개했다. 이들은 자기가 평균 5년간 다룬 성숙한 저장소에서 실제 작업 246건을 처리했고, 각 작업은 무작위로 AI 도구 허용 또는 금지 조건에 배정됐다. 허용된 쪽에서는 주로 Cursor Pro와 Claude 3.5/3.7 Sonnet을 썼다.
실험 전 개발자들은 AI가 작업 시간을 24% 줄일 것으로 예상했다. 실험 후에도 20% 줄었다고 추정했지만 측정된 완료 시간은 19% 늘었다. 이 수치는 해당 참가자와 저장소, 당시 도구에 한정된다. 다만 체감 속도와 실제 완료 시간이 다를 수 있다는 점은 분명히 보여준다.
METR도 이 결과를 모든 개발자와 현재 도구에 일반화하지 않았다. 참가자가 16명으로 적고, 이들이 오래 다룬 성숙한 오픈소스 저장소의 이슈가 대상이었으며, 도구도 2025년 초 시점의 제품이었다. 그럼에도 체감과 측정값이 크게 달랐다는 결과는 팀이 자체 작업 시간을 직접 재야 할 이유가 된다.
생성 이후의 검토 시간이 늘 수 있다
AI는 코드 초안을 빠르게 만들 수 있다. 대신 개발자는 출력을 읽고 기존 구조와 관례에 맞는지 확인하며 잘못된 부분을 수정해야 한다. 초안 시간이 줄어도 검토 시간이 늘면 전체 작업 시간은 줄지 않는다. 저장소를 오래 다룬 개발자일수록 이 검토 과정에서 기존 맥락과 생성된 코드의 차이를 많이 확인할 수 있다.
중복과 재수정도 함께 측정한다
GitClear의 2025년 보고서는 2020~2024년의 코드 변경 2억 1,100만 줄을 분석했다. 보고서 표에서 복사·붙여넣기로 분류된 줄의 비중은 2020년 8.3%에서 2024년 12.3%로 늘었고, 이동된 코드의 비중은 같은 기간 24.1%에서 9.5%로 줄었다. 이동된 코드가 모든 리팩터링을 뜻하지는 않으므로 이 수치는 보고서의 분류 기준과 함께 읽어야 한다.
이 지표는 같은 기간 코드 중복과 짧은 기간 안의 재수정이 늘었다는 상관관계를 보여준다. 이를 AI 도구만의 영향으로 단정할 수는 없지만, 생성량이 늘 때 재사용과 리팩터링이 함께 줄어드는지 확인할 필요는 있다. 중복된 코드는 같은 변경을 여러 곳에 적용하게 만들어 이후 유지보수 비용을 키울 수 있다.
생성 이후의 시간도 함께 재야 한다
코드 작성은 소프트웨어 작업의 한 단계다. 기존 구조를 이해하고, 변경을 검토하고, 테스트하고, 운영 중 문제를 고치는 시간도 전체 비용에 포함된다. AI가 초안 생성 시간을 줄여도 검토와 수정 시간이 늘면 작업 전체는 빨라지지 않을 수 있다. 따라서 생산성 지표는 생성된 코드 줄 수보다 작업 완료 시간과 결함, 재수정까지 포함해야 한다.
작은 팀에서 검증 부담을 줄이는 방법
혼자 개발과 운영을 맡으면 코드 검토, 테스트, 장애 대응도 같은 사람이 처리하는 경우가 많다. 초안이 빨리 나와도 이를 확인할 시간이 부족하면 미검토 변경이 쌓일 수 있다. 한 번에 생성하는 양과 실제로 검증할 수 있는 양을 맞출 필요가 있다.
작은 팀은 생성 속도와 함께 검증 비용을 줄여야 한다. 변경을 작은 단위로 나누고, 중요한 동작을 회귀 테스트로 고정하며, 타입과 스키마로 인터페이스를 분명히 하면 검토 범위를 줄일 수 있다. 생성량만 늘리고 검증 절차를 마련하지 않으면 한 사람이 확인해야 할 코드가 빠르게 쌓인다.
AI는 코드 초안을 만드는 시간을 줄일 수 있다. 전체 생산성을 판단하려면 검토, 테스트, 수정, 운영에 든 시간까지 함께 재야 한다. 팀과 작업에 맞는 실측값을 쌓아야 AI 도구를 어디에 쓰고 어떤 검증을 자동화할지 결정할 수 있다.