AI 코딩 에이전트는 코드를 더 만들지만, 소프트웨어를 더 만들지는 않습니다

700여 개 소프트웨어 기업의 엔지니어링 데이터를 분석한 연구에서 AI 코딩 에이전트 도입 후 코드 줄 수는 평균 30%, 커밋은 20%, 풀 리퀘스트는 23% 늘었습니다. 하지만 Jira에서 추적한 이슈와 에픽의 해결률은 통계적으로 유의하게 변하지 않았으며, 연구진은 코드 리뷰가 생산 과정의 병목으로 남았다고 분석합니다.

주제: AI 개발 도구 소프트웨어 공학

에디터 노트

이 연구가 뒷받침하는 주장은 기업에서 코드 작성 활동이 늘었지만 추적 대상 업무의 해결률은 유의하게 달라지지 않았다는 데까지입니다. 코드 리뷰 시간이 늘고 수정 요청과 댓글이 많아졌다는 결과는 작성 속도만 높여도 전체 산출이 늘지 않는다는 병목 설명과 맞닿습니다. 댓글에서는 개인 프로젝트의 생산성 증가와 기업 조직의 성과를 구분해야 한다는 반응이 나옵니다. 일부는 데이터가 주로 2025년 이전이라 최신 모델과 도입 절차를 반영하지 못한다고 지적합니다. 이는 연구 결과의 현재 적용 범위를 묻는 반론이지, 제시된 기업 자료의 관측 결과를 뒤집지는 않습니다. 이 자료만으로 개인 개발자의 효용이나 이후 모델의 효과까지 판단할 수는 없습니다.

AI 요약

AI 코딩 도구가 코드 작성량을 늘려도 기업 차원의 소프트웨어 산출 증가로 이어지지는 않는다는 연구 결과입니다. Harvard University의 Fiona Chen과 James Stratton은 Jellyfish가 수집한 엔지니어링 업무 데이터를 분석했습니다. 자료에는 2021년부터 2026년 3월까지 700곳이 넘는 소프트웨어 기업, 70만 명이 넘는 직원의 커밋과 풀 리퀘스트 등 3억 건의 업무 이벤트와 이슈 관리 데이터가 포함됐습니다.

도입 전후의 기업 데이터 비교

연구진은 기업별 AI 사용량과 GitHub 활동을 살펴 AI 코딩 보조 도구와 코딩 에이전트를 도입한 시점을 추정했습니다. 코딩 보조 도구는 주로 사람이 작성하는 코드의 자동 완성을 돕고, 코딩 에이전트는 프롬프트를 바탕으로 코드를 작성하고 제출하는 방식으로 구분했습니다. 각 기업의 도입 전후를 다른 시점에 도입한 기업들과 비교하는 차분의 차분 회귀 분석을 적용했습니다.

AI 코딩 에이전트를 도입한 기업에서는 생성된 코드 줄 수가 평균 30% 늘었습니다. 전체 커밋 수는 20%, 풀 리퀘스트 수는 23% 증가했습니다. 하지만 Jira 같은 도구에서 추적한 이슈와 에픽의 해결률은 통계적으로 유의한 변화를 보이지 않았습니다. 이슈의 크기나 복잡도가 달라져 결과가 가려진 것도 아니라고 연구진은 밝혔습니다.

연구진은 코드 작성 단계에서 생긴 효율 향상이 이후 생산 과정의 제약에 흡수됐다고 설명합니다. 코드 리뷰에 걸리는 시간이 길어졌고, 풀 리퀘스트가 수정 요청을 받는 경우가 늘었으며, 리뷰어가 남기는 댓글도 많아졌습니다. 따라서 코드와 변경 요청의 증가만으로 실제 기능이나 해결된 업무가 늘었다고 볼 수는 없습니다.

Hacker News 반응

@staminade — 2026년 3월 자료이지만, 제 직장 경험과 맞습니다. 코드 리뷰는 원래 큰 병목이었고 에이전트 코딩이 늘면서 더 심해졌습니다. 자동 리뷰에 더 의존하는 방안도 논의했지만 아직 실질적인 개선으로 이어지지 않았습니다.
@hgowietoi — 제 팀은 시간의 약 10%를 코딩에, 90%를 설계와 분석에 씁니다. AI가 코드 작성 속도를 두 배로 높여도 전체 업무는 5% 빨라지는 데 그칩니다.
@jefftk — 학술 논문은 연구 시점의 상황을 설명합니다. 이 연구의 에이전트 결과는 주로 Claude 3.5부터 Sonnet 4.5, GPT-4.1부터 GPT-5, Gemini 2.5를 사용한 시기의 모습입니다. 기업이 도입한 뒤 리뷰 절차를 갖추기 전 초기 효과에 가깝습니다.
- @omellet — 에이전트 코딩 시대에 맞춰 연구를 갱신했지만 기본 결과는 같습니다. 코드를 더 빨리 만들면 병목이 리뷰로 이동합니다.
@CharlieDigital — 에이전트는 반복적인 테스트 코드를 대량으로 작성하면서도 명시적으로 지시하지 않으면 중복을 정리하지 않는 경향이 있습니다. 실제 배포 코드보다 테스트 코드가 몇 배 더 많아지기도 합니다.
@jedberg — 예전에는 모두 어셈블리로 코드를 작성했습니다. C처럼 추상화 수준이 높은 언어가 나왔을 때도 CPU에서 멀어진다며 반대하는 사람이 있었습니다. 시간이 지나면 특별한 경우를 빼고는 코드를 거의 보지 않게 될 것이라고 봅니다. 코드가 좋지 않아도 작동하고 테스트를 통과하면 된다는 관점입니다.
@KumaBear — 개인용 소프트웨어는 확실히 크게 늘었습니다. 예전에는 시간을 낼 생각조차 못 했던 프로젝트를 이제 만들고 있습니다.
- @jimbokun — 표본이 한 명인 이야기인가요?
@sroerick — 코드 리뷰가 줄 단위로 버그를 잡아내는 과정이라고 실제로 기대한 사람이 있었나요? 저는 기본적인 타당성 확인과 모범 사례 적용, 주니어 개발자 교육에 가깝다고 생각했습니다.
- @DanHulton — 코드 리뷰에서 버그를 잡기도 하지만, 이상한 코드 패턴이나 중복, 잘못된 추상화처럼 버그가 생기기 쉬운 구조를 막는 역할도 큽니다. 모델은 아직 이런 판단에 필요한 프로젝트 맥락을 충분히 갖추지 못합니다.
@hyperpape — 데이터 수집 기간은 2026년 3월까지지만 대부분은 2025년 이전 자료입니다. 이 점은 연구 결과가 현재 상황을 얼마나 잘 반영하는지 따져볼 때 중요합니다.
- @geraneum — 연구를 반박하려면 수치와 통계를 제시해야 합니다.

원문: Ars Technica / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗