당신의 AI 코딩 ROI가 사라지고 있으며, 대시보드는 이를 알려주지 않을 것입니다

대시보드는 훌륭해 보이지만, 실제 인도(delivery) 수치는 그렇지 않습니다.

당신의 AI 코딩 대시보드는 아주 멋져 보입니다. 승인율(Acceptance rate)은 올라갔고, 생성된 코드 라인(Lines generated)도 늘어났습니다. 개발자 만족도 점수도 상승했습니다. 팀은 열광하고 있고, 경영진은 감명받았습니다. 발표용 슬라이드 데크는 거의 저절로 만들어지는 수준입니다.

이제 다른 질문을 던져보십시오. 사이클 타임(cycle time)이 개선되었습니까? 병합 후 결함률(post-merge defect rate)이 낮아졌습니까? PR(Pull Request)당 리뷰 부담(review burden)이 감소했습니까?

만약 이 질문들에 대한 답을 모른다면, 당신은 AI가 실제로 도움이 되고 있는지 알지 못하는 것입니다. 당신은 단지 팀의 기분이 좋아졌다는 것만 알고 있을 뿐입니다. 그것은 다른 문제입니다.

엔지니어링 리더들은 잘못된 도구로 AI 코딩 ROI(투자 대비 효율)를 측정하고 있습니다. 포착하기 쉬운 지표들은 아주 좋아 보입니다. 하지만 AI가 실제로 팀을 더 효과적으로 만들고 있는지 알려줄 지표들은 대부분 측정되지 않고 있습니다. 그리고 바로 그 격차 속에서 AI 투자금이 사라지고 있습니다.

모두가 사용하는 지표 (그리고 그것이 오해를 불러일으키는 이유)

**생성된 코드 라인(Lines of code generated)과 자동 완성 승인율(autocomplete acceptance rate)**은 대부분의 AI 코딩 대시보드에서 기본 시작점으로 사용됩니다. 이 지표들은 추출하기 쉽고, 추세를 파악하기 쉬우며, 분기별 경영 검토(QBR)에서 보여주기에도 쉽습니다. 하지만 생산성 신호로서는 거의 완전히 무용지물입니다.

이러한 지표들은 품질이 아닌 양에 보상을 줍니다. 두 수치를 10배로 늘리면서도 오히려 팀의 속도를 늦출 수 있습니다. 코드에 있어서는 '더 많은 것'이 '더 나은 것'이 아닙니다 (

**개발자 만족도 (Developer satisfaction)**는 이 세 가지 지표 중 가장 교묘하게 오해를 불러일으키는 지표입니다. 사람들은 빠르게 작업하고 있다는 느낌을 좋아합니다. 코드가 타이핑하는 속도보다 더 빠르게 나타나는 감각은 정말 놀랍고 (중독적이기까지 합니다... 농담이 아니라 코딩 에이전트 사용자들을 위한 12단계 프로그램(12-step program)을 시작해야 할지 고민해 본 적도 있습니다... 제 데스크톱에 서로 '다른' 프로젝트를 수행 중인 터미널 창이 17개나 열려 있는 것을 확인했습니다. 잠들어야 할 시간이 한참 지난 후에도 '딱 하나만 더' 프로세스를 시작하고 싶어 하는 것은 드문 일이 아닙니다... 이건 다른 포스트에서 다룰 주제네요!) 생산성처럼 느껴지지만, 실제로는 그렇지 않은 경우가 많습니다.

여기에는 잘 알려진 인지 편향 (cognitive bias)이 작용하고 있습니다. 도구가 초기 단계의 작업을 수월하게 느껴지게 만들면, 사람들은 후속 비용 (downstream costs)이 이득을 갉아먹고 있음에도 불구하고 자신의 전반적인 생산성을 체계적으로 더 높게 평가합니다. DORA 2025 데이터는 이를 대규모 수준에서 구체적으로 보여줍니다. 팀들의 PR 병합률 (PR merge rate)은 거의 두 배로 증가했고 AI 도구에 대한 높은 열의를 보고했지만, 조직의 인도 지표 (delivery metrics)는 정체 상태를 유지했습니다 [1]. 만족도 점수는 그 '느낌'을 포착했지만, 인도 수치들은 다른 이야기를 하고 있었습니다.

**첫 커밋까지의 시간 (Time to first commit)**은 세 번째 흔한 함정입니다. 이는 잘못된 결승선을 측정합니다. 생성하는 데는 10분이 걸렸지만, 검토하는 데 3시간이 걸리고 그로 인해 발생한 버그를 찾아 수정하는 데 2일이 걸린 커밋은 시간을 절약한 것이 아닙니다. 그것은 비용을 후속 단계로 전가했을 뿐이며, 추적 중인 지표에서는 그 비용을 보이지 않게 만들었습니다. 프런트엔드 (front end)에서는 빨라 보이지만, 백엔드 (back end)에서는 시스템이 느려집니다. 아무도 이 둘을 연결 짓지 않습니다. 저는 몇 달 전에 이 "워터베드 문제 (waterbed problem)"에 대해 글을 쓴 적이 있습니다. 더 자세히 읽고 싶으시다면 기사 끝에 링크를 포함하겠습니다.

당신이 무시하고 있는 숫자들

연구 결과는 이 문제에 대해 매우 명확하게 지적하고 있습니다.

DORA의 2025 State of DevOps 보고서에 따르면, AI 도구는 완료된 작업(tasks completed)을 21% 증가시켰고 PR(Pull Request) 병합(merged)을 98% 증가시켰습니다 [1]. 이러한 수치들은 AI 벤더의 사례 연구(case study)에 주로 포함되는 내용입니다. 하지만 포함되지 않는 사실이 있습니다. 바로 조직의 전달 지표(delivery metrics)는 정체되어 있었다는 점입니다. 더 많은 PR이 병합되었지만, 전달 성능(delivery performance)은 동일했습니다. 처리량(throughput)은 증가했지만, 결과(outcomes)가 이를 따라가지 못했습니다.

이 발견은 잠시 주목할 가치가 있습니다. 조직들은 PR 병합률을 거의 두 배로 높였음에도 전달 측면에서는 개선을 보지 못했습니다. 시스템 내의 무언가가 모든 이득을 흡수하고 있었던 것입니다. 코드는 파이프라인(pipeline)으로 더 빠르게 이동하고 있었지만... 파이프라인 자체가 빨라지지는 않았습니다.

품질에 관해서는: CodeRabbit은 2025년 12월에 470개의 실제 PR을 분석했으며, AI가 생성한 코드가 사람이 작성한 코드보다 전체적으로 1.7배 더 많은 이슈를 발생시키고, 심각한(critical) 이슈는 1.4배 더 많이 발생시킨다는 것을 발견했습니다 [2]. Veracode의 데이터는 더욱 날카롭습니다. AI가 생성한 코드는 보안 취약점(security vulnerabilities)을 2.74배 더 많이 포함하고 있으며, 전체 보안 결함률(security flaw rate)은 45%, Java 코드만 검토했을 때는 72%에 달했습니다 [3].

그리고 신뢰도에 관해서는: 개발자의 단 3.8%만이 낮은 환각(hallucination) 비율과 높은 신뢰도를 동시에 보고하며, 인간의 검토 없이 AI가 생성한 코드를 배포(shipping)한다고 답했습니다 [4]. 나머지 96.2%는 최소한 확신이 없는 상태입니다. 많은 개발자가 어디에서도 측정되지 않는 상당한 양의 검토 작업(review work)을 수행하고 있습니다.

아무도 이야기하지 않는 PR 크기 문제

DORA 2025는 AI 도구가 PR 크기를 지속적으로 154% 증가시켰음을 발견했습니다 [1].

이것은 중요한 문제입니다. PR 크기는 중립적인 변수가 아닙니다. PR이 커질수록 검토(review)하기가 더 어려워집니다. PR 크기가 증가함에 따라 검토 품질은 저하됩니다. 검토자들은 변경 사항을 실제로 이해하는 것에서 벗어나, 명백한 오류를 찾아내기 위한 패턴 매칭(pattern-matching)으로 전환하게 됩니다. 버그가 통과되는 이유는 검토자가 업무를 못 해서가 아니라, 인간의 주의력에는 한계가 있으며 600라인짜리 PR은 400라인짜리 PR과는 다른 인지적 과업(cognitive task)이기 때문입니다.

당신은 더 빠르게 코딩하지만, 파이프라인은 막힙니다. AI는 세션당 더 많은 코드를 생성합니다. 그 코드는 더 커진 PR (Pull Request)로 이어집니다. 그 PR들은 리뷰하는 데 더 오랜 시간이 걸리고, 더 덜 주의 깊게 리뷰됩니다. 더 많은 이슈가 머지 (merge) 단계까지 통과합니다. 머지 후 결함률 (post-merge defect rate)이 상승합니다. 장애 발생률 (incident rates)도 뒤따릅니다.

이것은 시스템의 문제입니다. 당신은 파이프라인의 한 노드 (node)를 최적화했지만, 하류 노드 (downstream nodes)들을 저하시켰습니다. 당신이 지켜보던 지표 (생성된 라인 수, 머지된 PR 수)는 상승했습니다. 하지만 당신이 지켜봤어야 할 지표 (사이클 타임 (cycle time), 결함률 (defect rate))는 그렇지 않았습니다.

병목 현상 (bottleneck)은 사라진 것이 아닙니다. 이동했을 뿐입니다. 그리고 대부분의 팀은 그것이 어디로 이동했는지 확인할 수 있는 측정 인프라를 갖추고 있지 않습니다.

대신 측정해야 할 것들

네 가지 지표입니다. 이 지표들은 생소한 것이 아닙니다. 대부분의 엔지니어링 팀은 이를 측정할 수 있습니다.

커밋에서 배포까지의 사이클 타임 (Cycle time, commit to deploy). 커밋에서 커밋까지가 아니라, 작업 시작에서 PR 오픈까지도 아닙니다. 커밋에서 배포까지입니다. 이는 리뷰 시간, CI/CD 대기 시간, 그리고 모든 재작업 루프 (rework loops)를 포함한 전체 파이프라인 비용을 포착합니다. 만약 AI가 진정으로 전달 속도를 가속화하고 있다면, 이 수치는 움직여야 합니다. 만약 PR 볼륨이 증가하는 동안 이 수치가 정체되거나 증가한다면, 당신은 DORA가 기록한 것과 동일한 문제를 겪고 있는 것입니다.

AI 지원 코드와 인간 작성 코드로 세분화된 머지 후 결함률 (Post-merge defect rate, segmented by AI-assisted versus human-authored code). 이것은 자동 완성 수락률 (autocomplete acceptance rate)이 완전히 놓치고 있는 품질 신호입니다. 기능 및 수정 사항에 대해 접수된 버그를 추적하고, 해당 PR을 태깅하며, 코드 출처별로 결함률을 비교하십시오. CodeRabbit과 Veracode의 수치들은 당신이 유의미한 차이를 발견하게 될 것임을 시사합니다. 그 차이는 이제 당신이 수치화할 수 있는 비용이 됩니다.

PR당 리뷰 부담 (Review burden per PR). 첫 리뷰까지 걸리는 시간, 리뷰 반복 횟수, 그리고 리뷰어가 소비한 시간입니다. 이는 리뷰 단계에 들어온 코드가 리뷰할 준비가 되었는지를 알려줍니다. 만약 AI가 생성한 PR이 리뷰어의 주의력을 불균형하게 소비하고 있다면, 그것은 현재 당신의 대시보드 어디에도 나타나지 않는 실제 비용입니다.

30일 이내 재작업률 (Rework rate). AI가 생성한 코드 중 머지 (Merge) 후 한 달 이내에 실질적으로 다시 작성되는 비율은 얼마나 됩니까? 다시 작성해야 하는 코드는 비용 절감이 아닙니다. 그것은 비용의 유예일 뿐입니다. 초기 PR (Pull Request)은 속도 (Velocity)처럼 보였을 것입니다. 하지만 재작업은 그 비용을 이자와 함께 되갚는 과정입니다.

변화의 실행 (Implementing the Shift)

이를 위해 새로운 플랫폼이 필요한 것은 아닙니다. 태깅 (Tagging)이 필요할 뿐입니다.

먼저 AI 관여도에 따라 PR을 태깅하는 것부터 시작하십시오. 가장 간단한 방법은 개발자가 PR을 AI 보조 (AI-assisted), AI 생성 (AI-generated), 또는 사람이 작성 (Human-authored)으로 표시하는 것입니다. 신호를 포착하기 시작하는 데 완벽한 세분화가 처음부터 필요하지는 않습니다.

그다음, 위에서 언급한 네 가지 지표에 대해 해당 태그별로 세분화하여 60일간의 베이스라인 (Baseline)을 실행하십시오. 아마도 연구 결과가 예측하는 바를 보게 될 것입니다. 즉, AI 보조 코드는 파이프라인 (Pipeline)에 더 빠르게 진입하지만, 더 많은 다운스트림 (Downstream) 작업을 생성한다는 점입니다. 사이클 타임 (Cycle time)에 미치는 순 효과는 귀하의 특정 팀과 코드베이스가 그 트레이드오프 (Tradeoff)를 어떻게 흡수하느냐에 달려 있습니다.

핵심은 AI가 효과가 없다는 것을 증명하는 것이 아닙니다. 어떤 팀들은 AI가 명확하고 측정 가능한 방식으로 효과가 있다는 것을 발견할 것입니다. 핵심은 가치가 어디에 있고 비용이 어디에서 발생하는지에 대해 정직해지는 것입니다. 현재 대부분의 엔지니어링 리더들은 결과 (Outcomes)가 아닌 활동 (Activity)을 측정하는 계기판을 보고 비행하고 있습니다. 측정하지 않는 것은 최적화할 수 없습니다.

PR 볼륨 (Volume)을 축하하는 것을 멈추십시오. PR 이후에 어떤 일이 일어나는지를 측정하기 시작하십시오.

하나의 실질적인 시작점은 다음과 같습니다. 한 팀, 한 스프린트 (Sprint)를 선정하여 PR 태그별로 사이클 타임과 머지 후 결함 (Post-merge defects)을 측정하십시오. 이 단 한 번의 실험에서 얻는 신호가 3개월간의 승인율 (Acceptance rate) 데이터보다 더 많을 것입니다.

동일한 기간 동안 추적해야 할 또 다른 요소는 토큰 볼륨 (Token volume)과 비용입니다 (두 가지 모두 추적하십시오. 볼륨당 비용은 하락했지만, OpenAI가 상장을 준비하고 보조금이 지급되는 토큰 비즈니스 모델의 지속 가능성이 점점 낮아짐에 따라 그 궤적은 곧 변할 수 있습니다). 비용을 추적하면 정당한 ROI (투자 대비 수익) 논의가 가능해집니다. 토큰 수를 추적하면 비용 지표가 변하더라도 시간에 따른 비교가 가능해집니다.

결론 (The Bottom Line)

대부분의 팀이 AI 코딩 ROI (투자 대비 수익)를 측정하기 위해 사용하는 지표들은 노력 (effort)과 감정 (sentiment)을 측정하고 있습니다. 이 지표들은 인도 성능 (delivery performance)을 측정하지 않습니다. 품질 (quality)을 측정하지 않습니다. 엔지니어들이 통합되어 있는 시스템이 더 빨라지고 있는지 아니면 느려지고 있는지를 측정하지 않으며, 실제적인 개선이 측정 가능한 ROI를 창출하고 있는지도 추적하지 않습니다.

DORA는 PR (Pull Request) 병합률 (merge rate)이 두 배로 증가했음에도 인도 결과 (delivery outcomes)는 정체되어 있음을 발견했습니다 [1]. CodeRabbit은 AI가 생성한 코드에서 1.7배 더 많은 이슈를 발견했습니다 [2]. Veracode는 2.74배 더 많은 보안 취약점 (security vulnerabilities)을 발견했습니다 [3]. 개발자 만족도 점수는 상승했지만 사이클 타임 (cycle time)은 정체되어 있었습니다. 대시보드는 훌륭해 보였습니다. 수치는 거짓말을 하지 않았습니다. 단지 잘못된 것을 측정했을 뿐입니다.

사이클 타임 (cycle time)을 측정하십시오. 병합 후 결함 (post-merge defects)을 측정하십시오. 리뷰 부담 (review burden)을 측정하십시오. 재작업 (rework)을 측정하십시오. 만약 AI가 팀이 더 나은 소프트웨어를 더 빠르게 인도하도록 돕고 있다면, 이 수치들이 그것을 알려줄 것입니다. 만약 AI가 비용을 하류 (downstream)로 전가하면서 팀이 생산적이라고 느끼게만 만들고 있다면, 이 수치들 역시 그 사실을 알려줄 것입니다.

토큰 수 (token count)와 비용을 측정하십시오. 이것이 실제 ROI를 결정할 수 있는 유일한 방법입니다.

당신이 듣고 싶어 하는 말만 해주는 대시보드는 모니터링 시스템이 아닙니다. 그것은 보도 자료 (press release)일 뿐입니다.

• AI 코딩이 엔지니어가 실제로 해야 하는 일을 어떻게 변화시키는지에 대하여: "우리 코드의 100%가 AI에 의해 작성되었다"는 말이 실제로 의미하는 것 | Substack
• 단 하나의 팀만 속도를 높일 때 AI 도입이 어떻게 다운스트림 혼란 (downstream chaos)을 초래하는지에 대하여: AI 채찍 효과 (The AI Bullwhip): 비어 게임 (The Beer Game)이 불균형한 AI 도입에 대해 우리에게 가르쳐 주는 것 | Substack
• AI 코딩이 소프트웨어 개발 프로세스 자체를 어떻게 재편하고 있는지에 대하여: AI 개발의 아이러니: 컨텍스트 엔지니어링 (Context Engineering)이 어떻게 우리를 폭포수 (Waterfall) 모델로 되돌리고 있는가 | Substack
• AI를 통해 엔지니어를 실제로 생산적으로 만드는 기술은 무엇인지에 대하여: 최고의 AI 엔지니어는 프로덕트 매니저 (Product Managers)이다 | Substack

참고 문헌

1. 2025 DORA AI 지원 소프트웨어 개발 현황 — Google/DORA
2. AI vs. 인간 코드 생성 현황 보고서 — CodeRabbit
3. 2025 GenAI 코드 보안 보고서 — Veracode
4. 2025 AI 코드 품질 현황 — Qodo

당신의 조직에서는 AI 코딩 도구를 평가하기 위해 어떤 지표 (metrics)를 사용하고 계신가요? 팀들이 활동 지표 (activity metrics)와 인도 결과 (delivery outcomes) 사이에서 동일한 괴리를 경험하고 있는지 궁금합니다. 여러분의 경험을 댓글로 남겨주세요.