3줄 요약
- MIT와 와튼의 경제학자 셋이 NBER에 낸 워킹 페이퍼다. GitHub 개발자 10만 명 이상의 활동 기록과 Microsoft 내부 사용 데이터를 결합하여, 세 세대의 AI 코딩 도구가 개발자 생산성을 얼마나 끌어올렸는지 측정했다. 세 세대란 코드 자동완성(GitHub Copilot 같은 것), 동기식 에이전트(Claude Code처럼 개발자 옆에서 함께 일하는 도구), 비동기식 에이전트(GitHub Async Agent처럼 일을 맡겨 두고 결과를 받는 도구)다.
- 주간 커밋(코드 변경 기록) 수가 얼마나 늘었는지로 보면 효과가 세대마다 커진다. 자동완성 +40%, 거기에 동기식 에이전트를 더하면 +140%, 비동기식까지 합치면 +180%다. 그러나 같은 도구가 “코드 라인 → 파일 → 커밋 → 풀 리퀘스트 → 저장소 → 릴리스” 순서로 위 단계로 갈수록 효과가 줄어든다. 동기식 에이전트의 경우 코드 라인은 +741%지만 풀 리퀘스트는 +65%, 실제 릴리스는 +20%까지 떨어진다.
- 왜 그럴까. AI가 코드 작성 단계는 잘 해내지만, 그 위에서 검토하고 통합하고 출시를 결정하는 사람의 일은 여전히 사람 손에 남아 병목이 된다. 저자들은 AI와 사람 노력이 서로를 얼마나 강하게 필요로 하는지를 0.25로 추정했다(1보다 작을수록 둘이 서로를 강하게 필요로 한다는 뜻이다). 같은 패턴이 앱 마켓플레이스에서도 보인다. iOS, Android, Chrome에서 새 앱은 빠르게 늘었지만 사용자가 실제로 쓰는 양은 늘지 않았다.
자료 정보
- 저자: Mert Demirer (MIT Department of Economics & NBER), Leon Musolff (UPenn Wharton & NBER), Liyuan Yang (MIT)
- 출처: NBER Working Paper No. 35275, May 2026 (DOI: 10.3386/w35275)
- JEL 코드: D24(생산), L86(소프트웨어 정보산업), O33(기술 변화와 확산)
- 자금: Mack Institute (Wharton), Chicago AI Incubator
- 데이터: 2022~2026, 공개 GitHub 활동 + Microsoft 내부 사용 텔레메트리, 10만+ 개발자
- 분량: 본문 45p + 온라인 부록 약 50p
분석 설계
저자들은 채택자와 비채택자를 한 시점에서 단순 비교하지 않고 매칭 사건 연구(matched event study)를 쓴다. 어떤 개발자가 AI 코딩 도구를 채택한 주를 사건 0주로 잡고, 그 개발자가 채택 직전 12주 동안 보였던 활동 수준과 정확히 1년 전 같은 활동 수준을 보인 대조군 개발자를 짝지운다. 1년 전 대조군을 쓰는 이유는 두 가지다.
- 동시점 대조군 오염: 같은 시점의 비채택자도 AI를 쓰고 있을 가능성이 높다. 공개 저장소에서 흔적이 남지 않은 사용자가 많다.
- 선택 편향 완화: 같은 해의 비채택자는 활동성이 낮은 개발자로 쏠릴 수 있다. 1년 전 대조군은 채택 풀에서 끌어오기 때문에 이 편향이 줄어든다.
추적하는 도구는 6종이다.
- 자동완성: GitHub Copilot (2022년 6월 출시)
- 동기식 에이전트: GitHub Copilot Sync, Claude Code, OpenAI Codex (동기식 모드)
- 비동기식 에이전트: GitHub Async Agent (2025년 5월), OpenAI Codex Async
위약 비교를 위해 AI가 아닌 도구인 GitHub Pro 구독과 Docker 도입도 같은 설계로 측정한다. 결과가 활동성 편향(activity bias) 때문이 아닌지 가르기 위해서다.
생산 계층을 6단계로 분해한다
이 페이퍼의 개념적 출발점은 소프트웨어 산출을 수직 계층으로 본다는 것이다. 한 줄을 작성하는 데 드는 노력이 모여 파일이 되고, 파일이 모여 커밋이 되고, 커밋이 모여 풀 리퀘스트가 되고, 풀 리퀘스트가 모여 저장소가 되고, 저장소가 모여 릴리스가 된다. 위로 갈수록 단위가 커지고 사람의 검토와 결정이 더 많이 개입한다.
| 단계 | 단위 |
|---|---|
| 6 (가장 위) | 릴리스 (Releases) |
| 5 | 저장소 (Projects) |
| 4 | 풀 리퀘스트 (Pull Requests) |
| 3 | 커밋 (Commits) |
| 2 | 파일 (Files) |
| 1 (가장 아래) | 코드 라인 (Lines of Code) |
각 단계는 아래 단계의 산출과 그 단계의 유효 투입(사람 노력 + AI 산출의 합)을 CES 생산함수로 결합한다. 핵심 매개변수는 두 단계 사이의 대체탄력성 σ다. σ가 1보다 작을수록 아래 단계 산출과 그 위 단계 사람 노력은 보완재가 된다. 한쪽만 풍부해져도 다른 쪽 병목이 가로막아 산출이 제한된다. 이것이 Kremer(1993)의 오링(O-ring), Jones(2011)의 약한 연결(weak-link) 논리를 단일 생산 공정 안으로 가져온 형태다.
AI 도구는 이 사다리에 두 가지 방식으로 개입한다.
- 증강(augmentation): 그 단계 사람 노력의 단위당 생산성을 높인다. 자동완성이 코드 작성 단계에 하는 일이다.
- 부분 자동화(partial automation): 그 단계 사람 노력을 일부 대체하지만 위 단계의 사람 검토는 여전히 필요하다. 동기식과 비동기식 에이전트가 커밋과 풀 리퀘스트 단계에서 하는 일이다.
세대별 작업 단위 생산성
각 세대 도구가 주간 커밋 수에 미친 효과. (a) Copilot 자동완성 2022년 채택자 코호트, (c) 동기식 에이전트 풀, (e) 비동기식 에이전트가 작성한 커밋. 우측 열은 채택 전 활동 분위별 효과. — NBER WP 35275, Figure 5.
각 세대의 21~30주 시점 효과는 분명하다.
- 자동완성: 주간 커밋 +36%. 2022년 Copilot 채택자 기준. 채택 전 활동이 가장 낮은 1사분위는 +85%, 가장 높은 4사분위는 +21%. 모든 분위에서 양의 효과를 유지한다.
- 동기식 에이전트: 사람이 작성한 커밋 기준 +109%. 자동완성의 약 3배다. Claude Code가 +199%로 가장 크고 OpenAI Codex(동기식) +94%, GitHub Sync +43% 순이다. 도구별 차이에는 도구 자체의 성능 차이와 어떤 개발자가 그 도구를 채택했는지의 선택 효과가 섞여 있다.
- 비동기식 에이전트: 에이전트가 작성한 커밋 기준 +34%. 이는 사람 커밋 위에 덧붙는 효과다. 채택 전 활동이 낮은 사분위에서 +105%, 가장 높은 사분위에서 +7%로, 활동량 분포 전 구간에서 효과를 보인다.
세대가 쌓이면 채택자의 주간 커밋은 평균적으로 약 2.8배까지 늘어난다. 이 효과는 채택 후 30주까지 안정적으로 유지된다.
AI 아닌 위약은 5주 안에 사라진다
활동성 편향이 결과를 만든 게 아닌지 확인하기 위해 AI가 아닌 두 도구를 같은 설계로 돌렸다.
- GitHub Pro 구독 (AI 기능 없는 유료 구독, 순수 위약): 채택 직후 +137% 급등 → 5주 안에 0%로 수렴
- Docker 도입 (그 자체로 생산성을 올릴 수 있는 도구, 비교 상한선): 채택 직후 +413% 급등 → 23%에서 안정
반면 AI 도구의 동기식 효과는 30주 내내 109% 수준에서 유지된다. 단발성 활동 급등이 아니다.
Claude Code의 효과는 학습이 아니라 모델 업데이트가 끌어올린다
동기식 에이전트는 사건 시간에 따라 효과가 증가하는 패턴을 보인다. 두 가지 가설이 가능하다. (a) 사용자가 도구 활용법을 학습하면서 효과가 누적됐거나, (b) 도구를 받치는 최첨단 모델이 그 사이 개선됐거나. 두 가설을 가르기 위해 저자들은 출시 직후 3주 안에 채택한 조기 코호트만 떼어냈다. 이 하위 표본에서는 사건 시간이 곧 캘린더 시간이라, 모델 출시일을 가로축에 직접 표시할 수 있다.
결과는 명확하다. Claude Code 효과는 Anthropic의 Opus 4 → 4.1 시기에 정체하다가 Opus 4.5가 최첨단으로 자리잡자 가파르게 상승한다. 반면 2022년 채택자의 Copilot 자동완성은 초기 급등 이후 줄곧 평평하다. 그 시기 모델이 거의 갱신되지 않았다는 사실과 일치한다. 동기식 에이전트의 장기 효과를 끌어올리는 것은 사용자의 학습이 아니라 바탕 모델의 개선이다.
생산 계층을 따라가는 감쇠
세 세대 AI 코딩 도구가 생산 계층 6단계에 미친 누적 효과(채택 후 평균 % 변화). — NBER WP 35275, Figure 1.
이 페이퍼의 두 번째이자 핵심 기여는 같은 도구가 위 단계로 올라갈수록 효과가 얼마나 줄어드는지를 추적한 데 있다. Table 5의 21~30주 추정치를 보자.
| 도구 | 코드 라인 | 파일 | 커밋 | 풀 리퀘스트 | 저장소 | 릴리스 |
|---|---|---|---|---|---|---|
| 자동완성 | +228.2% | +50.8% | +35.9% | +11.0% | +13.6% | +10.2% |
| 동기식 효과 (풀) | +741.3% | +187.0% | +109.1% | +65.5% | +25.5% | +20.3% |
| Claude Code (동기식) | +981.2% | +288.4% | +199.2% | +145.5% | +49.2% | +29.2% |
| GitHub Sync | +470.9% | +106.2% | +42.7% | +21.4% | +11.3% | +1.3% |
| Codex (동기식) | +792.6% | +186.4% | +94.3% | +61.8% | +14.6% | +0.2% |
| 비동기식 효과 (풀) | +658.3% | +52.4% | +33.6% | +71.8% | +13.8% | — |
여러 사실이 이 표 한 장에 모여 있다.
- 단조 감쇠: 자동완성은 6단계를 따라 거의 단조감소한다. 동기식 에이전트도 큰 틀에서 단조감소다.
- 첫 단계의 감쇠가 가장 가파르다: 코드 라인이 파일로 모일 때 효과가 절반 이하로 압축된다. 사람의 검토, 통합 노력이 필요하기 때문이다.
- 비동기식은 풀 리퀘스트 단계에서 도드라진다: 비동기식 에이전트의 풀 리퀘스트 효과(+71.8%)는 커밋 효과(+33.6%)보다 크다. 비동기식 도구가 풀 리퀘스트 자체를 자율적으로 만들어 그 단계에 직접 산출을 더하기 때문이다. 모델 예측과 정확히 일치한다.
- GitHub Sync, Codex 동기식의 릴리스 효과는 통계적으로 거의 0: 표준오차 범위 안에 들어간다. 코드 작성 단계에서는 수백 퍼센트 효과를 내는 도구가 출시 단계에서는 흔적이 사라진다.
CES 보정
저자들은 자동완성 추정치만으로 두 구조 매개변수 (θ, σ)를 보정한다. 자동완성이 코드 작성 단계에만 개입한다는 깨끗한 가정 덕분에 윗단계 효과는 모두 전달 공식(pass-through formula)으로 예측 가능하다. 최적합값은 θ ≈ 0.75, σ ≈ 0.25다.
- θ ≈ 0.75: 각 단계 산출에서 아래 단계 입력의 출력 탄력성이 약 75%, 그 단계 사람 노력은 약 25%.
- σ ≈ 0.25: 1보다 한참 작다. 아래 단계 산출과 그 위 단계 사람 노력은 강하게 보완재다. 둘이 거의 고정 비율로 결합돼야 한다.
이 동일한 (θ, σ)를 동기식과 비동기식 에이전트에 반사실적으로 적용한 그림 10이 흥미롭다. 두 에이전트가 코드 작성 단계에만 개입했다면 라인-풀 리퀘스트 사이 효과가 어떻게 되었을지 예측한 곡선과 실제 관측치를 겹쳐 본다. 결과는 이렇다. 동기식 에이전트의 파일, 커밋, 풀 리퀘스트 효과가 모델 예측보다 약 2/3가 더 크다. 비동기식 에이전트는 풀 리퀘스트 효과가 예측을 크게 상회한다. 두 패턴 모두 두 에이전트가 위 단계까지 직접 개입하고 있음을 보여준다.
동기식 에이전트 채택의 생산 계층 6단계별 사건 연구. 코드 라인 +741%에서 릴리스 +20%까지 단조 감쇠. — NBER WP 35275, Figure 8.
앱 마켓플레이스
4대 앱 마켓플레이스의 월별 새 앱 수(위), 코호트 누적 사용량(가운데), 소규모 사용자 도달 앱 비중 변화(아래). 음영 영역은 에이전트형 코딩 시대(2025년 2월~). — NBER WP 35275, Figure 12.
개발자 수준 결과가 산업 전체의 산출로 이어졌는지 확인하기 위해 저자들은 4대 앱 마켓플레이스 데이터를 모았다. Apple App Store(iOS), Google Play Store(Android), Chrome Web Store, SourceForge다. 각 마켓플레이스에서 (a) 새 앱 출시 수와 (b) 출시 후 첫 3개월 누적 사용량을 추적한다.
새 앱 출시는 가속됐다
- iOS: 2023~2025 초반 월 30,000~50,000개에서, 2026년 4월 월 100,000개로 가속.
- Android: 2020년 중반 월 120,000개 → 2025년 1월 월 42,000개로 감소 추세였으나 2025년부터 안정과 회복. 2026년 중반 월 60,000개.
- Chrome 확장: 2023년 월 5,000개 → 2026년 중반 월 13,000개로 약 2배. 가속 시점이 iOS보다 빨라 자동완성 시기부터 효과가 누적됐을 가능성이 있다.
- SourceForge: 변화 없음. AI 도구를 덜 쓰는 개발자 기반이 반영된다.
GitHub 공개 저장소 차원에서도 같은 패턴이 보인다. 월간 머지된 풀 리퀘스트 수와 새로 생긴 (비-fork) 저장소 수가 2025년 초부터 그 이전 추세에서 명확하게 이탈한다. 풀 리퀘스트 가속이 새 저장소 가속보다 크다는 점도 생산 계층상 풀 리퀘스트가 저장소보다 한 단계 아래라 더 큰 효과를 보인다는 감쇠 패턴과 일치한다.
사용량은 그렇지 않다
문제는 그 다음이다. 각 월 코호트의 첫 3개월 누적 사용량(iOS는 평점 수, Android와 Chrome은 다운로드 수)을 모두 더해도 평탄하거나 줄어든다. iOS 코호트 평점 합, Android 코호트 다운로드 합 모두 2024년과 2025년이 거의 같다. Chrome은 이미 감소 중이었다. 더 많은 앱이 나왔지만 그것이 사용량으로 옮겨지지 않는다.
저자들은 두 가설을 모두 점검한다.
- 롱테일 가설(소수 사용자×많은 앱): 누적 사용량이 평탄하므로 이 설명은 어렵다. Amazon의 AI 책 출판에서는 관찰됐지만(Reimers and Waldfogel, 2026) 소프트웨어 마켓플레이스에서는 보이지 않는다.
- 매칭 개선 가설(니치 앱이 사용자에게 더 잘 맞춰진다): 출시 후 3개월 안에 최소 사용자에도 닿지 못한 앱 비중을 본다. iOS에서 평점 10개 미만 앱 비중이 79% → 86%, Chrome에서 다운로드 10개 미만이 18% → 31%로 상승. 매칭이 좋아진다면 이 비중은 떨어져야 한다. 결과는 반대다.
남은 해석은 두 가지다. 한계 앱들의 품질이 낮거나(공급 측), 사용자의 발견과 채택이 추가 공급을 흡수할 만큼 빠르게 늘지 못하거나(수요 측). 데이터만으로는 둘을 가르지 못한다. 다만 한 가지는 분명하다. 코드 작성 단계의 생산성 폭증이 도달 사용량으로 자동 환산되지는 않는다.
내가 붙잡은 대목
이 페이퍼가 단순한 정량 추정으로 멈추지 않는 이유는 결론부의 한 문장에 있다. “the binding constraint appears to be shifting from writing code to reviewing, integrating, and ultimately distributing it.” 곧 병목이 코드 작성에서 검토, 통합, 배포로 옮겨가고 있다는 말이다.
여기서 중요한 점은 두 가지다.
첫째, 자동완성은 코드 작성 단계에만 들어왔다. 동기식 에이전트는 코드 라인, 파일, 커밋 단계까지 함께 들어왔다. 비동기식 에이전트는 풀 리퀘스트 단계까지 진입했다. 도구가 진화하면서 AI 개입이 깊어진다. Figure 1에서 더 뒤 세대 도구일수록 오른쪽 단계까지 효과가 살아남는 것은 그 결과다.
둘째, 그럼에도 σ = 0.25는 그대로 남아 있다. 각 단계의 사람 노력은 여전히 보완재로 작동한다. AI가 한 단계를 부분 자동화해도 그 위 단계에서 사람의 검토와 결정이 필요하다. 그래서 매번 새 세대 도구가 등장할 때마다 효과가 한 단계씩 위로 살아나는 패턴이 나타난다. 다시 말해 다음 병목은 풀 리퀘스트 리뷰와 릴리스 결정이다. 이 단계까지 AI가 들어와 σ가 높아지면 다음 세대의 릴리스 효과는 +20%보다 훨씬 클 수 있다.
이 모델은 또 하나의 관찰을 가능하게 한다. 사람들이 자주 갖는 의문이 있다. “내가 AI로 코딩이 빨라졌는데 왜 출시는 그만큼 빨라지지 않는 걸까?” 그 질문에 대한 구조적 답이 여기 있다. 코드 라인 +741%가 풀 리퀘스트 +65%로 압축되는 데에는 개발자 개인의 시간 배분 문제만이 아니라, 팀이라는 생산 사다리 전체의 보완성이 작동하고 있다. 한 사람의 코드 작성 단계 생산성이 7배가 되어도, 그 위에서 코드 리뷰, 통합, 릴리스를 담당하는 사람들의 처리량이 그대로면 출시 처리량은 그 비율만큼 따라오지 않는다.
거시 성장 문헌의 약한 연결 가설(Kremer 1993, Jones 2011, 2026)이 보통 작업과 작업 사이의 보완성을 가리켰다면, 이 페이퍼는 그것을 단일 생산 공정의 수직 계층 내부에 적용한 첫 실증이다. 같은 논리가 의료(진단 → 처치 → 처방), 법무(서면 작성 → 검토 → 제출), 콘텐츠(스크립트 → 편집 → 배포)에도 그대로 적용된다면, “AI로 X가 빨라졌으니 X가 만드는 산출도 빨라질 것"이라는 단순 외삽은 거의 항상 과대 추정일 것이다.
한계
저자들이 직접 밝힌 한계가 셋이다.
- 소프트웨어 품질을 직접 측정하지 못한다. 평점과 다운로드 같은 간접 지표에 의존한다. 무료 앱의 사용자 가치를 평점이 정확히 반영하지 않을 수 있다.
- 포착 범위가 일부에 그친다. GitHub과 4개 마켓플레이스는 큰 단면을 보여주지만 기업 내부 소프트웨어와 엔터프라이즈 소프트웨어는 빠진다.
- 다른 영역으로의 외삽이 보장되지 않는다. 소프트웨어 개발은 현재 생성형 AI의 가장 앞선 응용 영역이다. 이 정량 추정치를 다른 영역에 그대로 옮기긴 어렵다.
내가 덧붙이고 싶은 한계는 하나 더 있다. 공개 저장소 활동만 본다는 점이다. 저자들이 2025년 11월 GitHub 내부 데이터로 비교한 결과, 공개 저장소 측정치는 비동기식 에이전트 사용자의 24.2%를 식별하고, 이 사용자들의 활동량 중 72.9%를 포착한다. 활동량 측정치는 큰 그림에서는 대표성을 갖지만, 비공개 엔터프라이즈 환경의 AI 사용 패턴이 다를 가능성은 남는다.
출처
Demirer, M., Musolff, L., and Yang, L. (2026). Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools. NBER Working Paper No. 35275. National Bureau of Economic Research.
