AI로 코딩하는 활동은 240% 증가했지만, 배포는 30% 증가: GitHub 대규모 연구에서 본 개발의 병목 현상

AI 코딩 에이전트에게 일을 맡기면 약간 신기한 느낌을 받습니다.

먼저 “이 기능을 추가해 줘”라고 전달합니다. 그러면 AI가 관련 파일을 찾고, 구현하고, 테스트를 작성하며, 때로는 풀 리퀘스트(Pull Request) 설명문까지 준비해 줍니다. 사람이 하나씩 진행하던 작업이 놀라운 속도로 앞으로 나아갑니다.

이렇게 되다 보니 자연스럽게 기대하게 됩니다. ‘코드를 작성하는 활동이 3배 이상 된다면, 배포할 소프트웨어도 똑같이 늘어나지 않을까’ 하고요.

하지만 현실은 그렇게 단순하지 않은 것 같습니다. 2026년에 발표된 NBER의 워킹페이퍼 Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools는 AI 코딩 효과를 ‘코드를 작성하는 곳’뿐만 아니라, ‘배포되어 사용되는 곳’까지 추적했습니다.

※NBER―Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools

분석 결과, AI 도구 도입 후 코드를 작성하는 활동은 크게 증가한 것으로 추정되었습니다. 반면, 그 효과는 프로젝트 수, 릴리스 수와 같이 하류 공정으로 갈수록 작아지고 있습니다.

커밋(commit) 활동은 누적 최대 약 240% 증가했지만, 개발자가 접촉한 프로젝트(repository) 수는 약 80% 증가에 그쳤고, 릴리스 수는 약 30% 증가로 머물렀습니다. 여기서 ‘누적’이란 시간 경과에 따라 커밋이 쌓였다는 의미가 아니라, 코드 자동 완성부터 동기형(synchronous), 비동기형(asynchronous) 등 후속 세대 도구를 조합하여 사용했을 때의 효과를 의미합니다.

이 수치가 ‘결국 AI는 쓸모없다’라는 의미는 아닙니다. 오히려 코드를 작성하는 공정에서는 매우 강력한 효과가 나타나고 있음을 보여줍니다. 하지만 동시에, 소프트웨어를 세상에 내놓는 일은 단순히 코드만 작성해서 끝나는 것이 아님을 보여주고 있습니다.

이 글에서는 이 논문의 내용을 소개하고, 이전에 쓴 세 편의 기사—‘코드는 썩지만 생명은 흐른다’, ‘기술의 추상화와 ‘새어 나가는’ 현실’, ‘부하직원에게는 맡길 수 있어도 AI에는 완전히 맡길 수 없는 것’—와의 연결고리를 생각합니다.

먼저 결론부터 말하자면, 이번 논문이 이 기사들의 주장을 전부 증명하는 것은 아니지만, 여기에 공통으로 흐르던 질문, 즉 AI가 코드를 대량으로 만들게 되었을 때, 누가 이해하고, 선택하고, 정리하며, 배포할 것인가에 대해 대규모 데이터로부터 현실적인 모습을 부각시키고 있습니다.

AI 코딩은 무엇을 변화시켰는가

이 논문은 50만 명이 넘는 GitHub 개발자의 공개 활동 데이터와 AI 이용 텔레메트리(telemetry)를 결합하여, AI 도구 사용이 개발 활동에 미친 영향을 조사했습니다. 대상은 코드 자동 완성, 대화형 에이전트, 자율형 에이전트라는 세 가지 세대입니다.

흥미로운 점은 논문이 ‘개발 속도가 얼마나 빨라졌는지’만 보고 있지 않다는 것입니다. 코드를 작성하고 커밋하며 풀 리퀘스트로 정리하고, 프로젝트로 키우고, 릴리스하여 사용되는 곳까지, 생산의 계층별로 추적했습니다.

이 발상이 중요합니다. AI가 코드 작성 속도를 높여도, 그 효과가 하류 공정까지 같은 비율로 도달한다고 보장할 수 없습니다. 어느 한 과정만 빨라지면, 그 다음 과정에 병목 현상(bottleneck)이 생길 수 있기 때문입니다.

코드를 작성하는 AI와 대열의 하비

이것을 생각했을 때, 공장 개선의 고전으로 유명한 엘리아후 골드라트(Eliyahu Goldratt)의 『제한요소설계 (The Goal)』를 떠올렸습니다. 작품 속에서 주인공은 보이스카우트 하이킹에 참가하고, 발이 빠른 아이는 앞서 나아가고, 느린 아이 뒤에는 줄이 늘어지는 모습을 목격합니다. 그 느린 아이가 바로 하비입니다.

LitCharts―The Goal

빠른 아이를 더 빨리 걷게 해도, 대열 전체의 도착 시간은 그다지 빨라지지 않습니다. 전체 속도를 결정하는 것은 가장 빠른 아이가 아니라, 가장 느린 하비이기 때문입니다. 이것이 바로 제약 이론(TOC)의 직관적인 설명입니다.

이번 논문은 AI 코딩으로 인해 코드 작성 아동들의 속도가 급격히 빨라진 상황을 포착하고 있다고 생각하면 이해하기 쉽습니다. AI는 여러 파일 변경, 테스트 코드 추가, 리팩토링 초안, 풀 리퀘스트 초안까지 지원 및 자동화하며, GitHub상의 커밋 활동도 AI 도구 세대가 진행됨에 따라 크게 증가하고 있습니다.

하지만 그 너머에는 다른 '하베(Hurry)'가 남아 있었습니다. 리뷰, 설계 일관성 확인, 품질 보증, 릴리스 판단, 사용자에게 가치를 제공할 수 있는지 판단하는 것입니다. 커밋 활동은 최대 약 240% 증가했지만, 릴리스는 약 30% 증가에 그쳤다는 결과는 바로 그러한 상황을 보여줍니다.

AI가 '하베'를 없앤 것은 아닙니다. 코드를 작성하는 과정이 크게 가속화되면서, 리뷰, 통합, 판단, 출하와 같은 후속 공정이 상대적으로 두드러지게 눈에 띄게 된 것입니다.

하베는 개발팀 안에만 있는 것은 아니다

여기부터는 논문이 직접 조사한 내용이 아니라, 기업 시스템 현장에 적용해 본 고찰입니다. 실제로 AI 코딩을 업무에 깊숙이 통합하고 있는 현장을 살펴보면, 릴리스가 늘지 않는 이유는 개발팀 내부의 리뷰나 판단 때문만은 아닙니다.

통합 테스트를 시작하고 싶어도, 연동처와의 통신에 필요한 통신 허가 설정을 인프라 팀에 요청해야 하고, 거기서 대기 시간이 발생합니다. 클라우드 설정을 바꾸고 싶어도, 기반 팀 측에도 우선순위가 있고 바로 대응해 주지 않습니다. 사내 서버의 API를 호출하는 사양이 추가되었기 때문에, 서비스를 관리하는 다른 팀과의 조율이 필요하게 됩니다. 이러한 일은 기업 시스템 현장에서는 드문 일이 아닙니다.

즉, '하베'는 개발팀 안에만 있는 것은 아닌 것입니다. 도중에 별도 팀이 관리하는 문이나 다리가 있고, 그곳을 통과하려면 순서 대기나 확인이 필요합니다. AI로 구현만 빨라지면, 종래 개발 작업에 숨어 있던 그 대기 시간이 갑자기 눈에 띄게 됩니다.

이는 AI의 능력 부족 문제가 아니라, 기업 시스템이 안정 운영, 보안, 감사, 책임 경계를 지키기 위해 의도적으로 설정한 경계 때문입니다. 대기 시간 중에는 확실히 줄일 수 있는 것도 있지만, 필요한 통제(control)를 위해 존재하는 것도 있습니다.

즉, 중요한 것은 모든 대기 시간을 악으로 간주하는 것이 아닙니다. AI 도입 후의 생산성을 본다면, 코드 생성뿐만 아니라 인프라 변경, 권한 신청, 통합 테스트 환경, 연동처 조율, 변경 관리와 같은 조직 전반적인 흐름 전체를 봐야 합니다.

덧붙여, 이 논문의 주요 데이터는 GitHub상의 개발 활동이며, 기업 내부의 비공개 시스템 개발을 충분히 반영하지 못합니다. 저자들 역시 기업 내 소프트웨어에 대해서는 충분히 다루지 못했다고 주의하고 있습니다. 소규모 오픈소스 팀보다 기업 시스템이 조직적 마찰의 영향을 받기 쉽기 때문에, 인프라 변경이나 타 팀과의 조율이 새로운 제약(constraint)이 된다는 현장 감각은 논문 결과를 기업에 적용할 때 중요한 관점이 됩니다.

'하베를 빠르게 걷게 하는 것'만으로는 부족하다

『더 골(The Goal)』의 중요한 점은, 병목 지점(bottleneck)을 찾았다고 해서 단순히

이전에는 시도할 수 없었던 아이디어를 단시간에 시험해 볼 수 있게 되었다면, 채택되지 않거나 버려지는 아이디어가 늘어나는 것은 자연스러운 일입니다. 탐색 비용이 낮아지면서, 이전에는 시도하지 않았던 아이디어까지 시험해 볼 수 있게 되었을 가능성이 있습니다.

문제는 시제품(試作) 자체가 늘어난 것에 있는 것이 아닙니다. 시제품이나 후보가 늘어난 후에, 어떤 것을 남기고, 무엇을 버리고, 무엇을 다듬어서 다음 단계로 연결할 것인가입니다.

이 점에서 이전 기사 「코드는 썩지만, 생명은 흐른다」에서 생각했던 소프트웨어의 동적 평형(動的平衡)이라는 비유가 다시 현실성을 갖습니다. 생물이 합성뿐만 아니라 분해와 재구성으로 질서를 유지하듯이, 소프트웨어도 기능 추가뿐만 아니라 삭제, 정리, 리팩토링(refactoring), 의존성 검토를 통해 건전함을 유지합니다.

zenn―코드는 썩지만, 생명은 흐른다

AI가 생성량을 늘린 시대에는 이 ‘부수고 다듬는 과정’이 상대적으로 중요해집니다. AI가 만든 코드를 전부 보존하는 것이 정답이 아닙니다. 오히려 다음 변경을 수용할 수 있도록 불필요한 것을 버리고, 구조를 정리하며, 의도를 업데이트하는 것이 필요합니다.

추상화는 진행된다. 하지만 현실은 여전히 새어 나온다

또 다른 연결점은 이전 기사 「기술의 추상화와 ‘새어 나오는’ 현실」에서도 찾을 수 있습니다. AI 코딩은 새로운 추상화 레이어입니다. 요구사항을 자연어로 전달하면, 구현 세부 사항의 상당 부분을 숨긴 채 코드가 나옵니다.

zenn―기술의 추상화와『새어 나오는』현실

하지만 추상화는 편리해질수록, 곤란할 때 그 아래에 묻혀 있던 현실이 새어 나오게 됩니다. 성능, 장애, 기존 설계와의 충돌, 비기능 요구사항(non-functional requirements), 보안, 책임 분계 등은 자연어 문장 하나만으로는 숨길 수 없습니다. 논문이 코드 품질 자체를 직접 측정한 것은 아니지만, 코드 생성 증가가 곧바로 릴리스 증가로 이어지지 않았다는 사실은, 리뷰, 통합, 판단이라는 현실이 아직 강하게 남아있음을 보여줍니다.

AI가 코드를 작성한다는 추상화는 이미 상당히 강력합니다. 하지만 개발 현장에서는 그 너머에 있는 조직적 또는 운영상의 현실까지 완전히 투명하게 만들어주지는 못합니다.

AI 시대에 남는 인간의 역할

마지막으로, 「부하직원에게는 맡길 수 있지만, AI에게는 온전히 맡기지 못하는 것」에서 논했던 주제와의 연결입니다. AI 에이전트는 매우 빠르게 많은 것을 해줍니다. 하지만 AI가 내놓은 ‘거의 완성된 결과물’을 정말 채택해도 되는지, 어디까지 수정해야 하는지, 지금 배포해야 하는지를 결정하는 데는 인간의 판단이 필요합니다.

zenn―부하직원에게는 맡길 수 있지만, AI에게는 온전히 맡기지 못하는 것

게다가 실제 시스템에서는 그 판단이 코드 안에서만 끝나지 않습니다. 연계처, 인프라, 보안, 운영, 승인 플로우와 같은 경계 역시 배포 가능 여부에 영향을 미칩니다. 즉, AI 시대의 리더에게 필요한 것은 대량의 코드를 직접 구현하는 능력뿐만이 아니라, 가치가 어디에 정체되어 있는지를 찾아내고 개발팀 내부와 외부를 넘나들며 흐름 자체를 다듬는 힘이라고 할 수 있습니다.

AI는 코드 작성 능력을 증가시켰습니다. 하지만 그 가치를 사용자에게 전달하기 위해서는 읽기, 의심하기, 고치기, 버리기, 정리하기, 조정하기, 배포하기, 그리고 사용되는 방식을 보고 다시 만들기라는 순환이 필요합니다.

커밋은 240% 늘었지만, 릴리스는 30% 증가에 그쳤습니다. 이 차이는 AI가 미숙하다는 것만은 아닙니다. 여기에는 기술과 비즈니스, 설계와 책임, 개발팀과 주변 조직 사이를 연결하는 인간의 노동이 남아있기 때문입니다.

AI 시대에 필요한 것은 빠른 아이를 더 빠르게 달리게 하는 것만이 아닙니다. 지금 대열 어디에 하비(Harvey)가 있는지 찾아내고, 팀 전체 그리고 조직 전체가 목적지에 빨리 도착할 수 있도록 흐름 자체를 다듬는 것입니다.

논의 (Discussion)