Doshi와 Vaishnav의 55.8% 생산성 수치는 사람들이 생각하는 것보다 훨씬 좁은 범위의 결과이다

Doshi와 Vaishnav가 Science (2023)에 AI 코드 완성 (AI code completion)에 관한 통제된 실험 결과를 발표했을 때, 어디에서나 퍼져 나간 헤드라인은 "55.8% 더 빠름"이었다. 이를 충분히 반복하다 보면 그것은 기정사실화된 지식이 된다. 실제 논문은 단일하고 잘 정의된 HTTP 서버 작업에 대한 완료 시간 (time-to-completion)을 측정했다. 이는 알려진 형태와 안정적인 목표, 그리고 특정 솔루션 경로에 보상을 주는 점수 함수 (scoring function)를 가진 문제였다. 55.8%의 향상은 해당 작업에 대해서는 실제였다. 또한 이는 소프트웨어 작업에서 "AI 생산성"이 의미하는 바를 가장 좁게 해석한 결과이기도 하다. HICSS-59 (Stray et al., 2026)에서의 더 신중한 후속 연구는 단일 벤치마크 작업 대신 몇 주에 걸친 지속적인 워크플로 통합 (workflow integration)을 살펴보았다. 수치는 압축되었다. 혼합된 작업(그린필드 (greenfield), 디버깅 (debugging), 리팩터링 (refactoring), 코드 리뷰 (code review)) 전반에 걸쳐 총 시간 절감 효과는 작업 유형에 따른 높은 분산을 보이며 10-20%에 더 가까웠다. 디버깅과 코드 리뷰는 거의 변화가 없었다. 그린필드 CRUD 작업이 가장 많이 움직였다. 단일 작업 실험실 벤치마크와 통합된 주간 워크플로 사이의 그 간극이 바로 대부분의 엔지니어링 조직이 AI 생산성 결정을 내릴 때 조용히 잘못하고 있는 지점이다.

메커니즘의 간극 (The mechanism gap)
코드 완성 모델은 한 가지 일만 수행한다: 로컬 컨텍스트 (local context)가 주어졌을 때 다음에 올 그럴듯한 토큰 시퀀스 (token sequence)를 예측하는 것이다. 컨텍스트가 명확한 시그니처를 가진 반쯤 완성된 함수이고 손실 함수 (loss function)가 표준적인 완성을 보상할 때는 환상적이다. 하지만 다음과 같은 작업이 포함될 때는 훨씬 약해진다:

• 세 개의 리포지토리 (repos)와 큐 (queue)를 통해 버그 추적하기
• 어떤 리팩터링이 수행할 가치가 있는지 결정하기
• 코드를 건드리기 전에 의도를 이해하기 위해 기존 코드 읽기
• 다른 팀과 스키마 (schema) 변경 협상하기
• 실제 실패 모드 (failure mode)를 잡아내는 테스트 작성하기
  이 중 그 어느 것도 다음 토큰 문제 (next-token problems)가 아니다.

이득이 실제로 복리로 쌓이는 지점
2025-26년에 프로덕션 AI 워크플로를 출시하는 빌더들은 실제 지속 가능한 향상을 경험하고 있지만, 이는 단순히 Copilot을 켜고 기다리는 방식이 아니다. 복리로 쌓이는 승리는 다음과 같은 모습이다:
스택 감소 (Stack reduction). 빌드 단계를 완전히 건너뛰기.

검증기 (Validator)를 신뢰할 수 있는 경우, 4단계의 ETL (Extract, Transform, Load) 과정을 단일 LLM 및 검증기 패스로 대체합니다. 컨텍스트 제거 (Context elimination). 문제를 작업 메모리 (Working memory)에 로드하는 데 걸리는 시간을 단축합니다. 생소한 코드베이스에 대한 빠른 오리엔테이션 쿼리, API 표면 (API surface) 조회, 에러 메시지 분류 (Triage). 경계에서의 보일러플레이트 (Boilerplate) 제거. 폼 검증기 (Form validators), 타입 매핑 (Type-mapping), 모의 데이터 (Mock data), 피스처 생성 (Fixture generation). 명세서에서 초안으로의 압축 (Spec to first-draft compression). 구조적으로 올바른 첫 번째 결과물을 얻은 다음, 절약된 시간을 안목 (Taste)이 필요한 부분에 투자합니다.

이것이 도구 결정 (Tooling decisions)에 의미하는 바:
단일 작업 벤치마크 (Single-task benchmarks)에 대한 AI 도구의 주장을 비교하지 마십시오. 벤더 (Vendor)에게 실제 엔지니어링 작업이 수 주간 지속되는 동안의 지속적인 워크플로우 시간 분포 (Sustained-workflow time-distribution) 데이터를 요구하십시오. 여러분 자신의 생산성 향상 (Lift)도 같은 방식으로 측정하십시오. 세 가지 작업 클래스를 선정하고, 4주의 기간 동안 머지 시간 (Time-to-merge)을 측정하여 기준점 (Baseline)과 비교하십시오. 타이핑 속도가 아니라 오케스트레이션 (Orchestration) 기술을 갖춘 인재를 채용하십시오. 병목 현상 (Bottleneck)이 이동했습니다.

요약
55.8%라는 수치는 틀린 것이 아니라, 범위가 좁은 것입니다. 지속적인 워크플로우 통합 데이터는 현실적인 총체적 생산성 향상이 특정 작업 클래스에 집중되어 낮은 두 자릿수 범위에 있음을 보여줍니다.

출처: Doshi and Vaishnav, Science 2023. Stray et al., HICSS-59 proceedings 2026.