• 「AI로 10배 빨라진다」는 주장은 1차 연구에서 확인되지 않는다. 엄밀한 RCT의 범위는 +55.8% ~ -19%이다.
• 75일·486 Issue(단독 오퍼레이터 관측)에서 변한 것은 태스크 단일의 속도가 아니라, 1명이 동시에 움직일 수 있는 작업 범위였다.
• 다만 그 범위가 넓어질수록, 사양의 미비함·리뷰 대기·의사결정 지연도 함께 늘어난다. 병목(Bottleneck)은 사라진 것이 아니라, AI에서 인간의 판단 처리량(Throughput)으로 옮겨갔다.

「AI를 사용하면 생산성이 10배가 된다」는 설은 2023년경부터 퍼졌지만, 1차 논문을 확인할 수 없다. 출처를 추적하면 기업 블로그나 CEO의 발언이 인용원이 되는 경우가 대부분이다.

엄밀한 RCT(무작위 대조 시험)가 내놓은 수치를 나열하면 사정은 상당히 다르다. +55.8%라는 숫자는 GitHub Copilot으로 JavaScript HTTP 서버를 구현한다는 단발성 태스크 실험의 값이며 (Peng et al., arXiv:2302.06590, 2023), 현실의 업무에 가까운 설정이 될수록 숫자는 작아진다. Microsoft·Accenture 등 3사의 필드 RCT에서는 n=4,867에서 +26%, 콜센터 업무의 자연 실험에서는 n=5,179에서 +14% (Brynjolfsson et al., NBER WP31161, 2023). 그리고 숙련된 OSS 컨트리뷰터를 대상으로 한 최근 RCT에서는, Cursor Pro를 사용한 그룹이 사용하지 않은 그룹보다 19% 느렸다 (METR, arXiv:2507.09089, 2025년 7월).

지각과 실측의 괴리: 이 METR 실험에서 개발자는 「24% 빨라질 것」이라고 예측했고, 종료 후에도 「20% 빨라졌다」고 답변했다. 하지만 실측은 19% 느렸다. 체감과 계측 사이에는 39포인트의 괴리가 있다.

여기서 의문이 남는다. 위임형(Delegation type)이라면 같은 함정을 피할 수 있다고 말할 수 있는가——솔직히, 이것은 검증되지 않았다. 가설로서 생각할 수 있는 것은, ①②와 같은 보완·대화형은 인간의 사고 흐름에 AI의 제안이 끼어드는 형태로 문맥의 단절을 발생시키는 반면, ④위임형은 Issue 단위로 묶인 문맥을 완전히 전달한 뒤 결과만 받기 때문에 인간 측의 작업 흐름이 단절되기 어렵다는 차이다. 다만 이는 필자의 추측이며, METR와 같은 엄밀한 검증을 거친 주장은 아니다. 이 질문에는 이후에도 명확한 답을 내놓지 못하고 있다.

「AI로 몇 % 빨라지는가」라는 질문이 헛도는 이유는 이용형(Usage type)을 혼동하고 있기 때문이다. 필자가 이 프로젝트의 경험을 통해 정리한 작업 프레임워크로서, AI 코딩 도구의 사용법을 6가지로 분류해 보았다. 이것은 외부에서 확립된 분류가 아니다. AI 도입 시 병목(Bottleneck)이 어디로 옮겨가는지 파악하기 위한 실무상의 렌즈로 사용한다.

유형	Human의 역할	AI의 역할	입도(Granularity)	연구
①보완형	구현자	보완	행·함수	풍부
...
여기서 주의해야 할 점은, ①③과 ④⑥은 축이 다르다는 점이다. ①~③은 인간과 AI의 책임 분담이 어디까지 깊게 들어가는가라는 그라데이션이지만, ③에서 ④로의 이행은 연속적인 단계 상승이 아니라, 인간이 직접 움직이는 모드에서 AI가 계획·실행을 주도하는 모드로의, 아키텍처별 단절이다. 나아가 ⑥병렬형은 책임 분담의 축이 아니라 「동시에 몇 개를 실행하는가」라는 운용 형태의 축이며, ④위임형을 여러 개 병렬로 실행해도 ⑥이 되고, ⑤자율형을 여러 개 실행해도 ⑥이 된다. 표로는 편의상 6개를 나열했지만, 실제로는 2개의 서로 다른 축이 혼재되어 있다.

자신이 어떤 유형에 있는지 먼저 확인해 두자. 코드를 쓰면서 Tab 키로 보완을 받고 있다면 ①보완형, 「~은 어떻게 해야 하나요?」라고 묻고 있다면 ②대화형, 자신이 쓴 것을 AI에게 보여주고 피드백을 받고 있다면 ③리뷰형이다. 「이 Issue를 구현해줘」라고 Issue 단위로 맡기고 있다면 ④위임형, 「이 기능을 만들어줘, 설계부터 맡길게」라고 넘기고 있다면 ⑤자율형, 여러 AI가 동시에 서로 다른 Issue를 처리하고 있다면 ⑥병렬형이 된다. 본고는 여기서부터, 필자가 이 75일간 주로 운용했던 ④위임형을 중심으로 살펴본다.

기존 연구가 거의 측정하고 있는 것은 ①과 ②이다. ④ 이후는 데이터가 거의 없다. 위임형 에이전트를 GitHub 공개 OSS 리포지토리에 도입했을 때의 효과를 분석한 연구(Agarwal, He & Vasilescu, arXiv:2601.13597, MSR 2026)에서는 커밋 수 +36.3% · 추가 LOC +76.6%라는 정(+)의 효과가 보고되었다. 다만 정적 분석 경고 +17.7% · 인지적 복잡성 (Cognitive Complexity) +34.9%라는 품질 저하도 동시에 기록되어 있으므로, 일면적으로만 읽어서는 안 된다. 이는 공개 OSS 리포지토리에서의 연구이며, 비공개·특정 도메인의 코드베이스(본 프로젝트 포함)에 그대로 일반화할 수 있다고는 할 수 없다.

흥미로운 점은 AI 도구를 만들고 있는 Anthropic이나 OpenAI, Google 3사가 자사의 개발에서는 ④위임형에 머물러 있으며 완전 자율형은 사용하지 않고 있다는 것이다(Anthropic 사내 엔지니어 132명 조사, 2025년). 설계·플래닝의 최종 판단은 인간이 계속해서 담당하고 있다.

①②보완형·대화형은 "인간(Human) 자신의 작업 시간이 단축된다"는 속도의 개선이다. 인간이 주체이고 AI가 보조한다. ④위임형부터는 구조가 바뀐다. 이슈(Issue)를 넘기면 AI가 계획·구현·테스트·PR(Pull Request)까지 실행한다. 인간이 다음 이슈를 생각하는 동안 AI가 이전 이슈를 진행한다.

이것은 엄밀히 말해 "속도와는 무관한 별개의 차원"이 아니다. 리틀의 법칙 (Little's Law, L = λW)에 따르면, 병렬로 처리할 수 있는 재공품(Work-in-Progress)의 수가 늘어나면 단위 시간당 완료량(Throughput, 처리량)은 올라간다. 이 또한 넓은 의미에서는 속도의 일종이다. 더 정확히 말하자면, 변한 것은 1개 태스크의 처리 속도가 아니라, 인간이 실행의 병목(Bottleneck)이 되지 않고 동시에 가질 수 있는 재공품의 수다. 전절에서 유보했던 METR의 질문(위임형은 동일한 함정을 피할 수 있는가)에는 아직 답하지 않았다. 아래 내용은 설령 1개 태스크당 속도가 METR의 실험과 마찬가지로 개선되지 않았더라도 성립하는 이야기로서 읽어주길 바란다.

이 프로젝트에서는 75일간 ClaudeCode와 Codex를 위임형으로 운용한 결과:

• 이슈(Issue) 생성: 486건
• 클로즈(Close): 336건
• 프로덕션 코드: 약 58,000 LOC
• 테스트 코드: 약 24,000 LOC
• 기존 개발 환산: 4~5인월 상당의 볼륨 (생산성의 양이 아니라, 재공품의 양에 대한 추정치)

적어도 나의 운용에서는, 보완형인 Copilot만으로 이 정도 양의 재공품을 동시에 보유하는 것은 현실적이지 않았다.

여기서 짚고 넘어가야 할 구분이 있다. METR가 문제 삼은 것은 "자신이 빨라졌다고 느끼는" 주관적인 지각이었다. 여기서 말하는 "4~5인월 상당"은 주관적인 체감이 아니라 이슈 수 · LOC라는 외형적으로 셀 수 있는 양이며, 종류가 다른 측정이다. 그렇다고는 해도, 이 숫자가 "가치"를 측정하지 못한다는 약점은 남는다. Anthropic의 사내 조사에서도 Claude 지원 태스크의 약 27%는 "AI가 없었다면 착수되지 않았을 잠재적 태스크"였다고 보고되었다(자사 조사 · 자기 보고 기반——이 또한 동일한 종류의 약점을 가진 출처임을 부언해 둔다).

또한, 이 숫자가 나타내는 것은 처리된 작업의 규모이지 품질을 나타내는 것이 아니다. 버그율 · 기술적 부채의 증감 · 복잡성의 변화는 이 프로젝트에서 추적하지 않았으며, 이는 본고의 한계이다. 전절의 Agarwal 등의 연구에서도 인지적 복잡성 +34.9%라는 품질 측면의 비용이 보고되었으므로, 나의 코드베이스에서 동일한 비용이 발생하지 않고 있다고 단언할 수 없다.

이 레버리지(Leverage)는 나쁜 방향으로도 작용한다. 이슈 사양이 모호하면 AI는 이를 해석하여 구현하고, 잘못된 해석인 채로 전속력으로 전진한다. 나중에 깨달았을 때는 대량의 코드가 쌓여 있다. 이는 보완형에서는 일어나기 어려운 규모의 손실이다. 규칙이 틀리면 모든 태스크에 일관되게 적용되며, 기술적 부채도 스케일(Scale)한다. 레버리지는 방향성을 증폭한다. 올바른 방향이라면 더 빠르고 멀리, 잘못된 방향이라면 더 빠르고 깊게, 라는 것이 감각적으로 가깝다. 실제로 어느 쪽으로 기울었는지는 다음 절에서 보는 병목의 실측이 답의 일부가 될 것이다.

75일간 운용하며 병목이 어디에 있는지 보이기 시작했다. 다만, 이는 단독 오퍼레이터인 나 한 명의 프로젝트에서의 관측이며, 팀 개발에 그대로 적용된다고는 할 수 없다. 여러 명의 팀이라면 이슈 투입은 팀에서 분담되기 때문에 이 구조는 성립하지 않을 가능성이 높다. 이슈를 투입하는 나 자신의 처리량(Throughput)이 상한선이 된다.

「4~5인월(Man-month) 상당의 볼륨이 있었다」는 것과 「병목 지점은 나의 의사결정 처리량(Throughput)이었다」는 것은 모순되지 않는다. 전자는 동시에 존재했던 재공(Work-in-progress, WIP)의 양이며, 후자는 그 재공이 검증 및 머지(Merge)까지 완료되는 속도에 관한 이야기로, 서로 다른 변수다. 검증되지 않은 채 쌓여가는 재공의 일부는 생산성이 아니라 부채의 재고(Inventory of debt)가 되어 있을 것이다. 어느 정도의 비율이 그러한지는 후술할 PR acceptance rate 수치가 하나의 단서가 된다.

「병렬화를 통해 벽시계 시간(Wall-clock time)은 O(√E)로 단축되지만, 누적 인적 노력은 O(E) 그대로 변하지 않는다」 — Jacky Liang, arXiv:2603.27438 「The Novelty Bottleneck」, 2026년 3월. 「10배 빠르다」와 「인원 1/10」은 수학적으로 별개의 주장이다.

이 왜곡은 아마 필자의 프로젝트에만 국한된 이야기는 아닐 것이다. LinearB의 2026년 리포트(810만 PR·4,800개 단체 조사. 단, 대상은 위임형에 한정된 데이터가 아니라 AI 생성 PR 전반의 통계라는 점에는 유의)는, AI 생성 PR의 최초 리뷰 대기 시간이 인간이 작성한 PR보다 4.6배 길어진 반면, 리뷰가 시작된 후에는 오히려 2배 빠르다(194분 vs 252분)는 것을 보여준다. 코드를 만드는 속도와 인간이 리뷰할 수 있는 속도는 별개의 문제다.

이 프로젝트의 현재 KPI (2026-07-02 기준):

KPI	값	의미
PR acceptance rate	79.5%	AI가 제출한 PR 중 머지된 비율
PR 평균 latency	7.5h (중앙값 2.6h)	PR 생성 → 머지까지의 시간
Issue cycle time	평균 14.9h (중앙값 6.4h)	Issue 투입 → 클로즈(Close)까지의 시간
Claude session 사용률	23%	최근 세션의 소비 상황

PR latency의 평균이 7.5h인데 중앙값이 2.6h라는 차이는, 일부 PR이 장시간 정체되어 있음을 나타낸다. 리뷰가 따라가지 못하는 상황이 이미 발생하고 있으며, 이것이 병목 지점의 실측값이다.

⚠️ 이 PR acceptance rate(79.5%)는 필자 자신의 수용 기준에 따른 수치이며, 외부 심사를 거친 객관적인 품질 보증이 아니다. 인간만으로 개발했을 경우의 PR 수용률이라는 비교 기준을 가지고 있지 않기에, 79.5%가 높은지 낮은지를 판단할 재료는 솔직히 없다. 적어도 100%는 아니라는 사실만큼은 여기에 적어둔다. 단일 프로젝트·단일 오퍼레이터의 관측값으로서 읽어주길 바란다.

따라서 나의 대답은 "AI 에이전트는 항상 개발을 10배 빠르게 만든다"가 아니다. 변한 것은 1개 태스크의 속도보다, 한 사람이 동시에 움직일 수 있는 작업 범위다. 다만, 그 범위가 넓어질수록 사양(Specification)의 허술함, 검증의 미흡함, 리뷰의 부실함도 커져서 돌아온다. 병목 지점은 사라진 것이 아니라, Human의 의사결정 처리량(Throughput)으로 이동했다.

자신이 어떤 유형으로 AI를 사용하고 있는지는 앞 절의 셀프 체크에서 확인한 바와 같다. 유형을 한 단계 높이는 것 자체는 지금의 과제를 해결하지 못한다. 오히려 먼저 필요한 것은, 현재의 유형 그대로 Human의 병목(의사결정·리뷰·사양 확정에 걸리는 시간)을 어떻게 줄일 것인가 하는 점이다. Issue 사양의 템플릿화, 테스트 자동화를 통한 판단 비용 절감은 유형을 높이는 것보다 먼저 효과를 발휘할 것이라는 게 지금의 실감이다.

Anthropic의 연구자 Nicholas Carlini는 16개의 에이전트로 약 2주에 걸쳐 C 컴파일러를 구축한 실험(Anthropic Engineering Blog, 2026년 2월)에서 "태스크 검증기(Task verifier)가 거의 완벽한 것이 중요하다. 그렇지 않으면 Claude는 잘못된 문제를 풀어버린다"라고 적었다. 이는 위임형 모델에도 그대로 적용되는 말이다.

AI 에이전트가 강력해질수록 마지막에 남는 것은 인간의 판단이다. 그러므로 다음에 측정해야 할 것은 "AI가 몇 배 빠른가"가 아니라, 자신이 어디에서 사양·리뷰·판단을 정체시키고 있는가이다. 그 부분을 측정하지 않은 채 자율성만 높인다면, 빨라지는 것은 생산성이 아니라 검증되지 않은 재공(WIP)이 쌓이는 속도일지도 모른다.

본 기사의 프로젝트 데이터는 2026년 7월 2일 기준입니다. 단독 운영자(필자 1인)에 의한 관측이며, 팀 개발로의 일반화는 검증되지 않았습니다. 벤더 자체 평가 수치(Devin 등)는 독립적인 검증이 없으므로 참조하지 않았습니다. 6가지 유형 분류는 필자의 작업 프레임워크이며, 확립된 외부 분류 체계(Taxonomy)가 아닙니다. 코드 품질(버그율, 기술적 부채, 복잡성 변화)은 이 프로젝트에서 추적하지 않았으며, 생산성에 관한 주장은 가동 범위와 처리량(Throughput)의 실측에 한정됩니다.

참고 문헌

• Peng et al. (2023) — GitHub Copilot RCT: arXiv:2302.06590
• Brynjolfsson et al. (2023) — 콜센터 자연 실험: NBER Working Paper 31161
• METR (2025년 7월) — 숙련된 OSS 개발자 RCT: arXiv:2507.09089
• Agarwal, He & Vasilescu (2026) — AI IDEs or Autonomous Agents? (MSR 2026): arXiv:2601.13597
• Liang (2026) — The Novelty Bottleneck: arXiv:2603.27438
• LinearB 2026 Software Engineering Benchmarks Report (810만 PR · 4,800개 단체): https://linearb.io/resources/software-engineering-benchmarks-report
• Huang, Seethor, Durmus, Handa, McCain, Stern & Ganguli (2025) — How AI Is Transforming Work at Anthropic (132명 조사): https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic
• Carlini / Anthropic 16개 에이전트 C 컴파일러 실험 (2026년 2월): https://www.anthropic.com/engineering/building-c-compiler