facts

전체 업무 시간 중 실제 코드 작성에 투입되는 비중은 14%로 나타났다. 2025년 Microsoft가 엔지니어 450명 이상을 대상으로 조사한 결과에 따르면, 코딩 시간은 근무 상태에 따라 11%에서 18% 사이로 측정됐다. 이 수치는 버그 수정이나 테스트 시간을 제외한 순수 코드 작성 시간이다. 이론적으로 AI가 코딩 속도를 2배로 높이더라도, 전체 생산성 향상 폭은 15% 미만에 그친다.

프롬프트의 미세한 문구 변화는 출력값의 큰 변동으로 이어진다. 의미가 동일한 프롬프트를 다시 작성했을 때, 생성되는 코드는 46%가 서로 달랐으며 정답 여부 또한 28%의 확률로 바뀌었다. 특히 2025년 숙련된 오픈소스 개발자를 대상으로 한 연구에서는 AI 도구 사용 후 오히려 구현 시간이 평균 18% 증가하는 결과가 관찰됐다.

도구의 보급률과 신뢰도 사이에는 큰 간극이 존재한다. 개발자의 80%가 AI 도구를 활용하고 있으나, 그 결과물의 정확성을 신뢰하는 비율은 29%에 불과하다. 다수의 개발자는 직접 코드를 작성할 때보다 AI가 생성한 코드를 디버깅하는 데 더 많은 시간을 소비하고 있다고 답했다.

how-it-works

IDE 내부에서 코드를 작성하는 '내부 루프(inner loop)'의 가속은 전체 소프트웨어 전달 주기인 '외부 루프'의 병목을 해결하지 못한다. 설계, 레거시 코드 분석, 개발 환경 설정, 코드 검토, 테스트 및 제품 통합 단계가 개선되지 않은 상태에서 코드 생성 속도만 높이면, 병목 지점은 후속 단계인 검토와 테스트로 이동한다. 즉, 입력(코드 생성)의 증가가 처리(검토 및 통합) 단계의 부하를 가중시키는 구조다.

2014년에 수행된 코드 줄 수(Lines of Code, LoC) 지표의 통계적 유효성 연구는 이 지표가 유효성 검사를 통과하지 못했음을 밝혀냈다. 그럼에도 불구하고 많은 조직이 AI 작성 코드 비율이나 LoC를 생산성 지표로 활용하고 있다. 하지만 코드량의 증가는 검토 대상의 확대로 이어지며, 이는 곧 기술 부채의 증가와 보안 취약점 노출 가능성을 높이는 결과로 이어진다.

스타트업과 대기업의 AI 활용 효율이 다른 이유는 데이터셋의 특성과 제약 조건의 차이에서 기인한다. LLM은 오픈소스 구성요소와 문서가 풍부한 프레임워크를 중심으로 학습되었기에, 신규 구축(greenfield) 환경인 스타트업에서 더 높은 효율을 보인다. 반면 대기업은 모델이 학습하지 못한 독점 도구와 레거시 코드베이스에 의존하며, 규정 준수와 하위 호환성 유지라는 추가적인 제약 조건을 처리해야 하므로 단순 가속이 어렵다.

implementation-impact

개별 엔지니어에게 AI 라이선스를 제공하는 것만으로는 조직 차원의 생산성 향상을 기대하기 어렵다. 생산성 저하의 원인 중 하나로 지목된 '역량 페널티(competence penalty)'는 여성과 고연령 엔지니어가 AI 지원 결과물을 냈을 때 더 가혹한 평가를 받는 사회적·인지적 장벽을 의미한다. 이는 도구의 성능 문제가 아니라 조직 내 신뢰와 수용 방식의 문제다.

AI 도입으로 인해 코드 생산 속도가 빨라질수록, 조직은 이를 검증할 테스트 자동화 인프라와 코드 리뷰 프로세스의 처리 용량을 동시에 확장해야 한다. 검증 능력이 뒷받침되지 않은 코드량의 증가는 유지보수 비용의 기하급수적 상승을 초래한다.

실무자는 AI 도입 성과를 측정할 때 'AI 작성 코드 비율'이나 '코드 줄 수'를 KPI에서 완전히 제외하고, 대신 코드 리뷰 소요 시간의 변화와 배포 후 결함률, 그리고 외부 루프의 병목 구간 해소 여부를 기준으로 도입 효과를 검증해야 한다.