자신의 구현 속도가 올라갔다는 실감은 나는데, 팀에서 출시되는 양이 그만큼 늘어나고 있다는 느낌이 들지 않는다. 이 위화감이 나만의 착각인지 확인하고 싶어서, 공개되어 있는 측정 데이터를 하나씩 찾아 나열해 보았다.

가장 명확하게 나타난 것은 이것이었다. AI 채택이 진행된 팀에서는 개발자당 태스크 완료(Task Completion)가 33.7% 증가했고, 그 이면에서 리뷰 중인 시간은 중앙값 기준으로 441.5% 늘어났으며, 배포 빈도(Deployment Frequency)는 주당 11.7% 감소했다 (이 배포 빈도만은 데이터셋의 약 10% 팀에서만 측정되었다).

AI 採用が低い時期から高い時期にかけての指標変化。Epic 完了数 +66.2%、タスクスループット +33.7%、PR マージ率 +16.2% が増えた一方、レビュー中の時間（中央値）+441.5%、PR あたりの障害 +242.7%、in progress の時間 +225.2%、開発者あたりのバグ +54%、未レビューでマージされた PR +31.3%、デプロイ頻度 −11.7%

Faros AI 「AI Engineering Report 2026」 (22,000명 / 4,000개 팀, 2년 치 텔레메트리)의 공개 수치로부터 작도

양의 지표(위의 3개)는 두 자릿수 증가에서 멈춰 있는데, 질과 정체의 지표(아래의 6개)는 자릿수가 하나 다르다. 그리고 마지막으로 고객에게 전달되는 양인 배포 빈도만이 마이너스로 기울어져 있다.

숫자를 나열하기

대조한 조사 내용을 목록으로 만든다. 표본과 방법론이 제각각이라 가로로 나열해도 엄격한 비교는 되지 않는다. 「상류(Upstream)만 빨라지고 있다」는 방향성 자체는 모두 일치한다. 갈리는 지점은 그 이후의 해석이며, DORA와 Faros는 심지어 정반대의 결론을 내고 있다.

서두에 제시한 Faros 2026의 수치는 「같은 회사 내에서, AI 채택이 가장 낮았던 2분기와 가장 높았던 2분기를 비교한 변화율」이다. Spearman의 순위 상관계수(Rank Correlation)로 p < 0.05인 것들만 실었다. 회사 간의 차이를 제거한 사내 비교이므로 단순한 상관관계보다는 타당성이 높다. 다만 상관관계일 뿐 인과관계는 아니다.

구현만 빨라졌을 때, 전체는 몇 배가 되는가

나열한 숫자 중 나에게 가장 와닿았던 것은, Bain의 「코드 작성과 테스트는 구상부터 출시까지의 25~35%를 차지한다」는 내용이었다. 이 정도로 구체적인 비율이 나와 있다면, 암달의 법칙(Amdahl's Law)으로 상한선을 직접 계산할 수 있다.

구현이 전체 비율 p를 차지하고, 구현만 s배 빨라졌을 때, 전체 소요 시간은 p/s + (1-p)이다. 전체 속도 배율은 그 역수다. Bain의 25~35%를 대입하여 그렸다.

実装工程の速度倍率を横軸、全体の速度倍率を縦軸に取った曲線。実装比率 25%/30%/35% の3本とも早い段階で寝てしまい、それぞれ 1.33 倍・1.43 倍・1.54 倍の上限に漸近する。30% の線では実装 5 倍で 1.32、10 倍で 1.37 にしかならない

Bain의 비율을 대입하여 직접 계산한 값을 플롯한 것

세 가지 경우 모두, 구현을 5배로 만들었을 즈음에 수치가 완만해진다. 수치로 나타내면 다음과 같다.

구현이 순식간에 끝나는 지점까지 몰아붙여도, 전체는 1.33~1.54배에서 한계에 부딪힌다. 구현을 5배에서 10배로 늘려도 전체적으로는 0.05배만큼밖에 움직이지 않는다. 이 부분이 가장 직관에 반한다. 구현 공정 안에 있는 인간의 체감이 「분명히 빨라졌다」 하더라도, 외부에서 본 팀의 출력(Output)이 1.3배 전후라면, 그 차이는 그대로 사내 기대치와의 괴리가 된다.

Swarmia가 같은 취지를 더 직설적인 표현으로 쓰고 있다. 「Coding 3x faster only translates into 2-5% on the org level」. 다른 것이 아무것도 변하지 않는다면, 코딩이 3배 빨라져도 조직 레벨에서는 2~5%에 불과하다는 뜻이다. 전제 조건이 다르기 때문에 위의 표와 숫자는 맞지 않지만, 말하고자 하는 바는 같다.

게다가 이 표는 「구현 이외에는 변하지 않는다」는 낙관적인 전제로 계산하고 있다. 실제 측정은 그렇지 않다. Faros 2026에서는 태스크가 진행 중(in progress)인 시간이 +225.2%, 대기 시간이 +81.8%, 리뷰 중인 시간이 +199.6%였다. 하류(Downstream)는 변하지 않는 것은커녕 느려지고 있으며, 서두의 배포 빈도 -11.7%도 이 방향과 일치한다.

리뷰할 수 있는 속도의 상한은 움직이지 않았다

하류에서 가장 먼저 막히는 곳은 리뷰였다. 공정 순서에 Faros 2026의 변화율을 붙여보면, 가속된 부분과 막힌 부분이 나뉜다.

인간이 제대로 리뷰할 수 있는 양으로 자주 인용되는 것은 SmartBear가 Cisco에서 수행한 조사다. 10개월 동안 2,500건의 리뷰, 320만 행을 분석했다. 도출된 권장 사항은 3가지이며, 각각 기준이 다르다.

그곳에 입력 측만 늘어났다. Faros 2026에 따르면 PR(Pull Request) 크기 +51.3%, 1 PR당 편집 파일 수 +59.7%이다 (2025년 보고서에서는 PR 크기 +154%. 데이터셋이 다르므로 직접 비교는 불가능하지만, 방향성은 일치한다). Faros가 말하는 PR 크기는 "하나의 PR에서 추가 또는 삭제된 행 수"이므로, 위의 표와 그대로 대조할 수 있다. 1회 400행 미만이라는 상한선도, 시간당 500행이라는 속도 상한선도 변하지 않은 채, 건당 행수만 늘어났다.

결과로 나타난 수치 중, 내가 가장 심각하다고 생각한 것은 이것이었다.

"The 31.3% increase in PRs merged without any review is the most urgent finding in this section."

(리뷰를 전혀 거치지 않고 머지(merge)되는 PR이 31.3% 증가한 것이 이 절에서 가장 시급한 발견이다)

— Faros AI, AI Engineering Report 2026

리뷰가 늦어진 결과, 리뷰가 건너뛰어지고 있다. 품질 게이트(Quality Gate)로서 기능하던 것이 대기열(queue)에 파묻혀 열리지 않게 되었다는 이야기로 읽힌다. 동일 보고서에서는 PR당 장애가 +242.7%, 개발자당 버그가 +54%(이전 보고서에서는 +9%)까지 나타났다.

생성 측의 품질이 올라가 이 문제가 자연스럽게 소멸할 전망도 현재로서는 희박하다. Veracode는 80개의 코딩 태스크를 고정하고 모델을 교체하며 동일한 검사를 지속하고 있다. 2025년 7월 시점에 100개 이상의 LLM(Large Language Model)을 측정했을 때, 코드의 45%가 OWASP Top 10 취약점을 포함하고 있었다. 2026년 3월 업데이트에서는 누적 150개 이상의 모델까지 확대되었다. 구문(syntax) 통과율(pass rate)은 2023년 약 50%에서 95%로 상승한 반면, 보안 통과율은 45~55%로 정체되어 있었다. 쓸 수 있게 된 양만큼 안전해지지는 않았다.

조사와 텔레메트리(Telemetry)에 따라 결론이 갈린다

지금까지의 수치는 모두 타인의 측정값이므로, 자신의 현장에 적용될지는 알 수 없다. 그렇다면 자신의 체감을 근거로 삼을 수 있는가 하면, 그 또한 미심쩍다.

METR의 무작위 대조 시험(RCT)에서는 숙련된 OSS(Open Source Software) 개발자 16명이 246건의 이슈(issue)를 처리했는데, AI 도구를 사용할 수 있는 조건이 19% 더 느렸다. 동일한 개발자들은 사전에 "24% 빨라질 것"이라고 예측했고, 실험 후에도 "20% 빨라졌다"고 답했다. 실측치와의 차이는 약 39포인트다.

METR 스스로도 "자신들의 개발자나 리포지토리(repository)가 개발 업무의 대부분을 대표한다고 주장하지 않는다"라고 명시하고 있다. 대상은 평균 22k 스타(stars) 초과, 100만 행 초과의 리포지토리에 수년간 커밋해 온 사람들이다. 익숙한 코드베이스에서는 AI에게 설명하는 비용이 직접 쓰는 비용보다 높아지기 쉬운 조건이다. 그럼에도 "나는 빨라진 느낌이 든다"를 측정값 대신 사용할 수는 없다는 재료로는 충분했다.

그리고 이 39포인트의 격차는 개인의 착각으로 끝나지 않았다.

DORA 2025는 AI를 "증폭기(amplifier)"로 규정한다. 조직의 기존 강점과 약점을 확대하므로, 테스트와 플랫폼이 갖춰진 팀은 AI로 성장하고, 분절된 팀은 부채 생성이 가속화된다. 강력한 기초가 방어 수단이 된다는 함의가 있다.

Faros 2026은 이 지점에 대해 직접적으로 반론한다.

"Our telemetry data, drawn from engineering systems across thousands of teams, does not support that as a protective factor. High-performing engineering organizations are experiencing the same downstream deterioration as everyone else."

(수천 개의 팀에 걸친 엔지니어링 시스템에서 추출한 우리의 텔레메트리 데이터는, 그것이 방어 요인이라는 점을 뒷받침하지 않는다. 고성과 엔지니어링 조직들도 다른 모든 조직과 마찬가지로 동일한 하류(downstream)의 악화를 경험하고 있다.)

（수천 개 팀의 개발 시스템에서 가져온 텔레메트리 (Telemetry)는 그것이 방어 요인이 된다는 설을 뒷받침하지 않는다. 고성과 조직도 다른 조직과 마찬가지로 동일한 하류(downstream)의 악화를 경험하고 있다.)

Faros가 이유로 꼽는 것은 방법론의 차이다. DORA는 조사 기반으로 개발자가 어떻게 느끼는지를 측정한다. 현재 개발자는 개인 수준에서는 실제로 빨라지고 있기 때문에 "생산적이 되었다"고 느낀다. 반면 리뷰 대기 정체나 운영 환경의 장애가 체감될 때까지는 수개월이 걸린다.

perception lags reality, while telemetry does not

(인식은 현실보다 뒤처지지만, 텔레메트리는 그렇지 않다)

METR가 실험실에서 측정한 39포인트를 Faros는 수천 개 팀 규모로 다시 말하고 있다. 이 부분이 이번에 나란히 비교한 내용 중 가장 흥미로우면서도 논리적이다. 다만 Faros는 텔레메트리를 판매하는 회사이므로, "조사보다 자사의 계측이 더 정확하다"는 결론에는 이해관계가 얽혀 있다. DORA 측도 Google Cloud의 리포트로서 AI 활용 추진에 이해관계가 없지 않다. 어느 한쪽을 채택하기보다는, "같은 현상을 측정해도 결론이 갈릴 정도로 아직 결론이 나지 않았다"고 읽는 것이 지금으로서는 정확하다고 생각한다.

하류를 개선한 쪽의 숫자

하류를 개선하면 어떻게 되는지를 자사 데이터로 공개한 사례가 Findy Tech Blog에 있었다. 동일한 조건에서 2024년과 2025년을 비교한 첫 번째 페이즈는, 위에 언급한 대로 상류(upstream)만 빨라진 전형적인 형태를 띠고 있다.

그로부터 개선을 반복한 후, 2025년과 2026년 전반기를 비교하면 다음과 같다.

리뷰 소요 시간을 악화시키지 않으면서 PR 수만 1.5배가 되었다. 한 회사의 숫자이기에 외부에서 검증할 수는 없으며, 이 사이에 무엇이 효과를 발휘했는지 분해된 형태로 공개되지는 않았다. 그럼에도 "하류가 받아낼 수 있게 되면 스루풋 (Throughput)이 움직인다"는 방향성을 보여주는 실데이터로서, 찾아본 범위 내에서는 이것이 가장 구체적이었다.

전부 읽을 수 없다는 전제하에, 어디를 읽을 것인가

그렇다면 하류를 어떻게 받아들일 것인가. 여기서부터는 출처가 있는 이야기가 아니라, 위의 숫자를 보고 내가 어떻게 생각했는지에 대한 정리이다.

재료는 3가지가 갖춰져 있다. 인간이 제대로 읽을 수 있는 양은 1회 400행 미만에서 멈춰 있다. 1 PR당 분량은 늘어났다. 그리고 미리뷰 머지 (Unreviewed merge)가 31.3% 증가했다. "전부 인간이 읽는다"는 것은 이제 성립하지 않는다. 파탄의 방식이 "나도 모르는 사이에 읽히지 않고 통과된다"로 변했다. 읽을 대상을 선택하지 않으면, 선택되는 방식이 랜덤해질 뿐이다.

선택한다면 리스크에 따라 계층화하는 것이 솔직한 방법이라고 생각한다. 인증·권한·결제·스키마 변경·의존성 추가를 건드리는 PR은 인간이 읽는다. 그 외에는 자동 체크와 머지 후의 관측에 맡긴다. CODEOWNERS를 이 계층에 맞춰 설정해 두면, 선별이 사람의 기분이 아니라 규칙이 된다. 아울러 "새로운 PR을 내기 전에 리뷰 대기 중인 것을 하나 소화한다" 정도의 재고 제한은 필요하다고 본다. 생성 속도가 빠른 팀일수록 재고를 쌓는 속도도 빠르다.

읽지 않는 쪽으로 돌린 PR에서 확인해야 할 것은 코드 작성 방식이 아니라 다음 4가지다.

"올바르게 작성되었음을" 육안으로 확인하는 것을 그만두고, "틀렸다면 알아차릴 수 있고 되돌릴 수 있음"에 거는 것으로 대체하는 것이다.

다만 이것이 무조건 성립하는 이야기는 아니다. Veracode의 45% 수치가 리뷰를 소홀히 해도 된다는 근거는 될 수 없으며, 결제·권한·사라지면 복구할 수 없는 데이터를 건드리는 코드는 계층 외부에 두어야 한다. DORA가 말하는 불안정성은 안전망이 얇은 상태에서 리뷰만 완화했을 때 나타난다. 머지 큐 (Merge queue)·플래그 (Flag)·차분 테스트 (Differential testing)가 우선이며, 리뷰의 계층화는 그다음이다. 순서를 뒤바꾸면 평범하게 사고가 난다.

각사가 제시하는 대응책

처방전으로서 각 리포트가 기술하고 있는 내용을 출처와 함께 정리해 둔다. 직접 시도하여 효과를 측정한 것이 아니므로, 그 점을 유의하며 읽어주길 바란다.

• Bain은 AI가 코딩을 빠르게 만든다면 코드 리뷰(Code Review)·통합(Integration)·릴리스(Release)도 동시에 빨라지지 않으면 병목 현상이 발생할 것이라고 기술하고 있다. 예로 든 곳이 Netflix인데, 생성된 코드가 느린 테스트 앞에서 대기하지 않도록 테스트와 품질 체크를 이전 공정으로 옮겼다. AI를 라이프사이클(Lifecycle) 전체에 적용한 조직은 30% 이상의 효율 개선을 보인 반면, 코드 생성에만 사용한 조직은 10~15%에 그치는 차이를 보였다.
• PR(Pull Request)을 작게 유지하기 위한 도구로서, GitHub가 2026-04-10에 Stacked PRs를 발표했다. 이는 큰 변경 사항을 의존 관계가 있는 작은 PR들의 연속으로 나누는 것이다. 다만 현시점에서는 대기 명단(Waitlist) 기반의 프라이빗 프리뷰(Private Preview) 상태이며, 일반 제공(GA)은 아니다.
• Faros 2026은 QA를 강화하거나 장애 대응을 빠르게 하는 것은 증상에 대한 처치일 뿐이며, 리뷰 단계의 정체 그 자체를 살펴볼 필요가 있다고 기술하고 있다.
• DORA 2025의 입장은 도구 그 자체보다 내부 플랫폼의 품질·워크플로우(Workflow)의 명확성·팀의 정렬(Alignment)에 투자하는 것이 더 효과적이라는 것이다.
• 측정 대상으로 DORA는 5가지 지표(변경 리드 타임, 배포 빈도, 실패한 배포로부터의 복구 시간, 변경 실패율, 배포 재작업률)를 정의하여 공개하고 있다. 과거에는 4가지 지표로 불리며 MTTR이 포함되어 있었으나, 현재는 명칭이 변경 및 추가되어 이 5가지가 되었다. PR 수나 커밋(Commit) 수는 측정하기 쉬운 대신, 늘어난다고 해서 고객에게 무언가가 전달되는 것은 아니다. Faros의 데이터에서도 늘어난 것은 PR이었고, 줄어든 것은 배포였다.

모두 AI 이전부터 언급되어 온 내용이며, 새로운 것은 아니다. 변한 점은, 이를 뒤로 미뤘을 때 발생하는 손실의 크기라고 생각한다.

이 기사의 숫자를 읽을 때의 주의사항

직접 작성한 글이라 조심스럽지만, 여기에 나열된 숫자들은 모두 다룰 때 주의가 필요하다.

• Faros의 데이터는 상관관계(Correlation)이지 인과관계(Causality)가 아니다. AI 도입이 진행된 시기는 다른 변화(인원, 제품 단계, 조직 개편)와도 겹친다.
• Faros와 Swarmia는 개발 생산성(Development Productivity)의 측정·분석 솔루션을 판매하는 회사이며, DORA는 Google Cloud의 리포트다. 양측 모두 "측정해야 한다", "AI를 올바르게 사용해야 한다"라는 결론에 이해관계가 있다.
• METR는 16명·246개 이슈(Issue)를 대상으로 하며, 대상은 성숙한 대규모 리포지토리(Repository)의 숙련자이다. METR 스스로도 일반화하는 것을 부정하고 있다.
• Faros 2026의 배포 빈도 -11.7%는 데이터셋의 약 10% 팀에서만 측정된 결과이다.
• Findy는 단 1개사의 사례이며, 개선책과 수치 변화 사이의 대응 관계는 외부에서 검증할 수 없다.
• SmartBear/Cisco의 400행 미만 데이터는 2000년대의 조사로, 당시와 지금의 리뷰 대상 코드의 성격은 달라졌을 가능성이 있다.

자신의 팀이 어떻게 되어 있는지는 스스로 측정할 수밖에 없다. 다만, 측정하기 전부터 "구현이 빨라진 만큼 팀도 빨라졌을 것이다"라고 생각하는 것은, 위의 표를 만든 후에는 어려워졌다. 구현이 0초가 되더라도 전체는 최대 1.5배 정도이며, 그마저도 하류(Downstream) 공정이 현재의 속도를 유지했을 경우의 이야기일 뿐이다.

진입 장벽은 낮다. 태스크(Task)가 in progress / in review / QA 상태에 머무는 시간은 대부분의 워크 매니지먼트(Work Management) 시스템에서 그대로 추출할 수 있다. PR 수를 세기 전에, 그 부분이 늘어나고 있는지를 먼저 살펴보면 된다.

참고 링크

• 2025년 초반 AI가 숙련된 오픈 소스 개발자 생산성에 미치는 영향 측정 — METR (2025-07-10)
• AI 생산성 역설 연구 보고서 — Faros AI (2025-07-23)
• AI 엔지니어링 보고서 2026: 가속도의 채찍질 (The Acceleration Whiplash) — Faros AI (분석 시점 2026-03)
• AI 보조 소프트웨어 개발 현황 2025 — DORA
• Accelerate DevOps 상태 보고서 2024 — DORA
• DORA의 소프트웨어 전달 지표 — DORA
• 기술 보고서 2025 — Bain & Company (코딩 비율은 p.62)
• AI 코딩 도구의 생산성 영향 측정 — Swarmia
• 2025 생성형 AI (GenAI) 코드 보안 보고서 — Veracode / 2026년 봄 업데이트 (2026-03-24)
• 동료 코드 리뷰 (Peer Code Review)를 위한 모범 사례 — SmartBear
• GitHub, 스택형 PR (Stacked PRs)을 통해 대규모 머지 문제 해결 — InfoQ (2026-04)
• AI 도입의 '기대 이하'를 극복하기 — 가시화와 개선의 사이클 — Findy Tech Blog (2026-07-24)

Discussion