많은 기업이 구독 비용 대비 가치를 입증하기 위해 코드 생성량이나 티켓 완료 수 같은 정량적 수치에 의존하지만, 이러한 지표는 실제 소프트웨어 품질과 정반대의 방향을 가리킬 때가 많다. 답이 갈리는 이유는 측정 도구가 '산출물'과 '가치'를 동일시하는 오류를 범하기 때문이다. AI 코딩 도구 도입 후 늘어난 코드 줄 수와 수락률을 그대로 생산성 지표로 믿기에는 위험 요소가 너무 많다.

LLM 보조 코딩의 가치 자체보다 더 위험한 것은 그 효과를 측정하는 방식이 너무나 쉽게 왜곡될 수 있다는 점이다. 특히 코드 줄 수의 증가가 생산성 향상이 아닌 '장황함'의 결과일 수 있다는 점, 그리고 높은 수락률이 정확성이 아닌 '그럴듯함'의 반영일 수 있다는 사실은 실무자들에게 중요한 경고를 던진다. 여기에 더해, 통제군이 없는 전후 비교나 자발적 사용자를 대상으로 한 실험 설계는 선택 편향을 제거하지 못해 결과값을 부풀리는 경향이 있다. 이제는 단순한 활동량 측정을 넘어, 리뷰 부하와 기술 부채라는 시스템적 관점에서 AI의 실질적 기여도를 다시 정의해야 할 시점이다.

수락률 33%와 코드 줄 수 40% 증가의 실체

LLM 도입 이후 개발자당 코드 줄 수가 40% 증가했다는 사례가 보고되었으나, 이는 생산성 향상이 아닌 코드의 장황함이 늘어난 결과일 가능성이 크다. 뒤엉킨 로직 2000줄을 깔끔한 200줄로 대체하는 개선 작업은 코드 줄 수 지표에서 오히려 손실로 기록된다. 반면 기업 연구 결과에 따르면 평균 제안 수락률은 33%를 기록했다. 주목할 점은 이 수락률이 생성된 코드의 정확성이나 보안성을 추적한 결과가 아니라는 사실이다. 시간 압박을 받는 개발자가 탭 키를 눌러 제안을 수락한 행위가 곧 코드의 무결성이나 유지보수성을 보장하지는 않는다.

AI가 작성한 커밋 30만 개를 분석한 결과, 15% 이상에서 최소 하나 이상의 품질 문제가 발견되었으며 이 중 4분의 1은 수정되지 않고 코드베이스에 장기적으로 잔존했다. 그러나 이러한 경향은 최신 모델에서도 반복되는 양상을 보인다. 2025년 주요 LLM 5개 모델을 대상으로 평가를 진행한 결과, 단 하나의 모델도 산업 보안 표준을 충족하는 웹 애플리케이션 코드를 생성하지 못했다. 이는 AI가 생성한 코드의 양적 팽창이 오히려 잠재적인 보안 취약점을 양산하고, 미래의 개발자가 처리해야 할 기술 부채를 은폐하고 있음을 보여준다.

McKinsey는 커밋, PR(Pull Request, 풀 리퀘스트), 코드 리뷰 횟수 같은 활동 기반 지표를 통해 개인 개발자의 생산성을 측정하는 방식을 제안했지만, 이는 측정값이 목표가 되는 순간 더 이상 좋은 지표로 작동하지 않는다는 Goodhart의 법칙과 정면으로 충돌한다. 커밋 수가 성과 지표로 추적되면 개발자는 작업을 인위적으로 쪼개어 커밋 횟수를 늘리는 방식으로 대응하며, 티켓 수가 추적되면 티켓 자체를 세분화한다. 결국 활동량이라는 수치는 상승하지만, 그것이 곧바로 소프트웨어의 가치나 산출물의 품질 개선으로 이어지지는 않는다. 활동은 산출물이 아니며, 산출물 또한 곧바로 비즈니스 가치가 되지 않는다는 사실을 간과한 결과다.

'장난감 과제' 55% 단축 vs 실무 생산성 19% 하락

JavaScript로 HTTP 서버를 처음부터 구현하는 90분짜리 통제된 과제에서 GitHub Copilot 사용자는 비사용자보다 55% 빠르게 작업을 완료했다. 당시 개발자에게는 다른 업무 의무가 없는 상태였으나, 이러한 그린필드 장난감 과제의 속도는 실제 소프트웨어 엔지니어링 환경의 생산성을 예측하지 못한다. 반면 숙련된 오픈소스 개발자를 대상으로 진행한 무작위 대조 시험에서는 AI 도구 접근권을 부여받은 집단의 과제 완료 시간이 오히려 19% 증가했다. 실제 업무는 자신이 작성하지 않은 거대한 코드베이스를 탐색하고 모호한 티켓 요구사항을 해석하며 동료와 끊임없이 조율하는 복잡한 과정이 포함되기 때문이다.

시니어 개발자의 개인 생산성이 19% 하락한 지점은 AI가 생성한 코드를 검토해야 하는 리뷰 부하가 6.5% 증가하면서 병목이 발생한 단계에서 명확히 드러난다. 전문 개발자 대상 실증 연구에 따르면 AI 도구는 경험이 적은 기여자의 단순 산출물 양은 늘렸으나 시니어 개발자에게는 심각한 부하를 초래했다. 주목할 점은 파이프라인의 한 단계인 코드 작성만 최적화하고 나머지 검토 과정을 무시한 시스템 사고의 실패다. AI가 코드의 양만 늘리고 이를 검증할 리뷰 역량을 함께 높이지 못한다면 전체 사이클 타임은 악화될 수밖에 없으며 이는 결국 기술 부채의 누적으로 이어진다.

대형 IT 조직에서 Copilot 사용자를 2년간 추적한 종단 연구 결과, 초기 도입자들은 도구 도입 전부터 이미 비도입자보다 지속적으로 더 활동적인 성향을 보였다. 많은 산업계 보고서가 AI 도입 전후를 단순 비교하거나 자발적 사용자와 비사용자를 대조하지만 이는 전형적인 선택 편향을 내포한다. 즉 관찰된 성과 차이가 AI 도구의 성능이 아니라 사용자의 개인적 역량이나 성향에서 기인했을 가능성이 크다. 반면 AI 보조 개발자를 아무 도구도 쓰지 않는 통제군과 비교하는 방식은 실제 업무에 존재하지 않는 가공의 기준선을 설정하는 오류를 범한다. 개발자는 이미 공식 문서 탐색이나 동료와의 협업이라는 유효한 대안을 가지고 있으며 AI가 이러한 기존 대안보다 실제로 더 나은 가치를 제공하는지에 대한 엄밀한 비교는 거의 이루어지지 않는다.

Cursor 도입 후의 일시적 가속과 지속적 복잡도 증가

Cursor를 도입한 807개 오픈소스 저장소를 분석하자 초기에는 개발 속도가 눈에 띄게 증가했지만, 시간이 흐를수록 코드 복잡도와 정적 분석 경고는 지속적으로 상승했다. 이러한 가속은 일시적인 현상에 그쳤다. 이는 AI가 빠르게 작성한 코드가 단기적인 산출물 양은 늘릴 수 있으나, 정교한 설계 없이 추가된 로직이 장기적으로는 유지보수 비용을 높이는 기술적 부채로 작용함을 의미한다.

개발자의 87%가 생산성 향상을 체감했다는 설문 결과는 실질적 효용보다 호손 효과나 사회적 바람직성 편향이 반영된 심리적 상태에 가깝다. 이러한 수치는 관찰받고 있다는 인식으로 인해 성과가 일시적으로 변하는 현상과 새로운 도구에 대한 호기심이 결합된 결과일 가능성이 크다. 응답자가 경영진이나 조직이 도구 도입을 결정했을 때, 그들이 듣고 싶어 하는 긍정적인 답변을 선택하는 경향이 수치에 강하게 반영되었을 확률이 높다. 주관적인 만족도는 도구의 실질적 효용보다 심리적 상태를 반영하는 지표에 가깝다.

대부분의 AI 생산성 연구가 4주 단위의 단기 관찰에 그치면서 데이터의 왜곡이 심화되는 양상을 보인다. 개발자는 초기 도입 단계에서 새 도구에 더 강하게 몰입하므로 관찰된 성과가 장기적인 기준선보다 부풀려지기 쉽다. 반면 AI에 과도하게 의존하며 발생하는 기술 퇴화나, 틀린 제안을 무비판적으로 수용하며 쌓이는 기술 부채, 그리고 팀 내 협업 방식의 변화 같은 핵심 지표는 수개월 이상의 장기 관찰 없이는 포착되지 않는다. 단기적인 속도 향상만을 탐지하도록 설계된 연구는 연구 종료 이후 코드베이스에 어떤 품질 저하가 발생하는지 설명하지 못한다.

AI 도구가 개발자의 코드 작성 속도를 30% 높였더라도 티켓 발행부터 프로덕션 배포까지의 전체 리드타임이 변하지 않는다면 작성 단계는 원래 시스템의 병목 지점이 아니었던 셈이다. 시스템적 관점에서 볼 때 개별 단계의 최적화는 전체 리드타임 단축을 보장하지 않는다. 오히려 생성된 코드의 양이 늘어나면 시니어 개발자가 리뷰해야 할 코드의 양도 함께 증가하며, 이는 리뷰 부하를 높여 전체 사이클 타임을 악화시키는 결과를 초래한다. 개별 개발자의 타이핑 속도라는 지엽적 지표보다 시스템 전체의 흐름을 제어하는 능력이 생산성의 실질적 척도가 된다.