AI 생산성 저하 기간은 더 길고, 깊으며, 격차가 벌어지고 있다

DORA의 AI ROI (투자 대비 수익) 계산기에서 한 가지 변수가 첫해의 승리를 첫해의 손실로 바꿉니다.

모델 비용도 아닙니다. 급여도 아닙니다. 채택률(Adoption rate)도 아닙니다.

바로 기간(Duration)입니다.

DORA의 AI 지원 소프트웨어 개발 샘플 모델은 3개월의 생산성 저하(Productivity dip)를 가정합니다. 이 가정하에 500명 규모의 엔지니어링 조직은 첫해에 약 330만 달러의 이익, 39%의 ROI, 그리고 1년 미만의 회수 기간(Payback period)을 창출합니다. Faros AI가 동일한 계산기를 3개월 대신 12개월의 저하 기간으로 스트레스 테스트(Stress-tested)했을 때, 결과는 반전되었습니다. 동일한 조직이 첫해 330만 달러의 이익에서 660만 달러의 손실로 돌아선 것입니다. 단 하나의 입력값으로 인해 990만 달러의 차이가 발생했습니다.

이 입력값은 단순한 세부 사항이 아닙니다. 그것이 바로 모델입니다.

_DORA_는 Google Cloud의 DevOps Research and Assessment 프로그램으로, 많은 엔지니어링 조직이 성능 벤치마킹을 위해 사용하는 소프트웨어 인도(Software delivery) 지표를 연구하는 그룹입니다. 기존의 DORA

AI 지원 소프트웨어 개발에 관한 2026 DORA 보고서는 단순한 유행을 따르는 메모가 아닙니다. 이는 경영진의 어려운 질문에 답하려는 진지한 시도입니다. 즉, 1차적 효과가 학습 비용 (learning costs), 검증 비용 (verification costs), 플랫폼 성숙도 (platform maturity), 품질 리스크 (quality risk), 그리고 조직 재설계 (organizational redesign)와 뒤엉켜 있을 때, 엔지니어링 리더들은 AI의 투자 수익률 (ROI)을 어떻게 판단해야 하는가에 대한 질문입니다. DORA ROI 보고서는 AI 도입을 역량 (capabilities), DORA 인도 지표 (delivery metrics), 그리고 궁극적으로 재무적 결과 (financial outcomes)로 매핑하는 ROI 프레임워크와 계산기를 제안합니다. 또한 이 보고서는 많은 실무자가 이미 느끼고 있는 패턴을 명시합니다. AI 도입은 _J-커브 (J-curve)_를 따른다는 것입니다. 생산성은 상승하기 전에 먼저 하락합니다.

이러한 하락에 대한 DORA의 설명은 타당합니다. 팀은 새로운 워크플로 (workflows)를 학습하는 데 시간을 소비합니다. 신뢰성은 공짜가 아니기 때문에 개발자는 AI가 생성한 코드를 반드시 검토해야 합니다. 다운스트림 시스템 (downstream systems)인 리뷰 (review), 테스트 (test), 보안 (security), CI/CD, 그리고 인시던트 대응 (incident response)은 더 많은 결과물을 수용해야 합니다. DORA ROI 보고서는 이를 "변화를 위한 수업료 (the tuition cost of transformation)"라고 부릅니다.

이러한 프레임워크는 유용합니다.

하지만 기본 설정된 타임라인 (timeline)이 위험한 부분입니다.

문제는 AI가 생산성 저하를 일으키느냐 아니냐가 아닙니다. 문제는 그 저하 기간이 3개월인지, 12개월인지, 아니면 조직이 상승 곡선을 타기 위해 필요한 보완적 투자 (complementary investments)를 완료하기도 전에 리더십이 예산을 삭감하거나, 인력을 감축하거나, 혹은 실패를 선언할 만큼 길어질 것인가 하는 점입니다.

DORA는 자신들이 연구하는 영역인 소프트웨어 개발을 중심으로 이 문제를 정의합니다. 하지만 비즈니스 프로세스 자동화 (Business process automation), 분석 파이프라인 (Analytics pipelines), 고객 운영 (Customer operations), 콘텐츠 생성 (Content generation), 재무 모델링 (Financial modeling) 등 AI가 실제 업무에 도입되는 모든 곳에서 동일한 역학 관계가 나타납니다. 메커니즘은 동일합니다. 조직이 AI 결과물을 수용하기 위해 필요한 검증 (Verification), 통합 (Integration), 거버넌스 (Governance) 시스템을 업그레이드하기도 전에 AI가 출력물의 양을 늘려버리는 것입니다. 코드는 이 이야기의 가장 계측화된 (Instrumented) 버전일 뿐이며, 유일한 버전은 아닙니다.

바로 이 지점에서 J-커브 (J-curve)는 갈림길이 됩니다.

DORA는 메커니즘에 대해 옳다

DORA의 가장 강력한 아이디어는 계산기가 아닙니다. 그것은 증폭 가설 (Amplifier thesis)입니다.

DORA는 2025 AI 지원 소프트웨어 개발 현황 보고서에서 AI가 기존의 조직적 조건을 증폭시킨다고 주장했습니다. 강력한 엔지니어링 시스템은 더 강력해집니다. 취약한 시스템은 기능 장애 (Dysfunction)를 더 빠르게 생산합니다. AI는 인도 성숙도 (Delivery maturity)를 대체하는 것이 아니라, 그것의 존재 여부를 확대합니다.

그것이 올바른 관점입니다.

강력한 자동화 테스트 (Automated tests), 빠른 CI (Continuous Integration), 규율 있는 리뷰 문화 (Review culture), 관측 가능한 운영 시스템 (Observable production systems), 소규모 배치 인도 (Small-batch delivery), 깨끗한 내부 문서화 (Internal documentation), 그리고 성숙한 개발자 플랫폼 (Developer platform)을 갖춘 조직은 AI가 생성한 결과물을 흡수할 수 있습니다. 이 조직은 증가된 물량을 처리할 수 있는 검증 표면적 (Verification surface area)을 가지고 있습니다.

그러한 기반이 없는 조직은 다른 것을 얻게 됩니다. 더 많은 코드, 더 커진 풀 리퀘스트 (Pull requests), 더 심한 리뷰 압박, 더 많은 재작업 (Rework), 더 많은 숨겨진 보안 노출, 그리고 "AI 도입"을 축하하는 대시보드 하류 (Downstream)에서 발생하는 더 많은 장애 (Incidents)입니다.

DORA의 계산기에는 이러한 개념이 포함되어 있지만, 샘플 가정들은 결과가 얼마나 비대칭적으로 변하는지를 과소평가하고 있습니다. 계산기의 기본 사례는 양(+)의 ROI를 보여줍니다. 하지만 Faros AI의 스트레스 테스트에 따르면, 생산성 저하(dip) 기간을 3개월에서 12개월로 변경할 경우 결과가 음(-)의 ROI로 뒤바뀝니다. 더 긴 적응 기간과 품질 저하를 결합한 Faros의 텔레메트리(Telemetry) 기반 시나리오 역시 첫해 ROI를 음수로 나타냅니다.

이것이 Faros의 분석이 보편적으로 옳다는 것을 증명하는 것은 아닙니다. Faros는 자사 고객층의 텔레메트리를 분석하는 벤더(Vendor)이며, 이는 모집단을 대표하는 인과 관계 연구(Causal study)와는 다릅니다.

하지만 이는 경영 측면의 핵심을 증명합니다. 즉, ROI는 생산성 저하 구간(trough)의 기간과 깊이에 매우 민감하다는 점입니다.

만약 리더십이 DORA의 기본 설정을 하나의 시나리오가 아닌 당연한 기대치로 취급한다면, 그들은 가장 힘든 부분에 대한 예산을 과소 책정하게 될 것입니다.

증거들은 단 하나의 이야기만을 말하지 않는다

AI 코딩 생산성에 관한 실증적 기록이 모순되는 이유는 연구자들이 무능해서가 아닙니다. 서로 다른 조건 하에서 서로 다른 작업들을 측정하고 있기 때문입니다.

DORA의 2024년 자체 데이터에서도 이러한 긴장 관계가 일찍이 나타났습니다. AI 도입이 25% 증가했을 때, 인지된 문서 품질, 코드 품질, 그리고 코드 리뷰 속도는 향상되는 것과 연관이 있었습니다. 그러나 동시에 전달 처리량(Delivery throughput)은 1.5% 감소했고, 전달 안정성(Delivery stability)은 7.2% 감소하는 것과도 연관이 있었습니다. 다시 말해, 개발자들은 일부 사항이 개선되고 있다고 느끼는 동시에 시스템 수준의 전달 결과는 악화되는 것을 경험했습니다. 2024 DORA 보고서를 참조하십시오.

METR의 통제 실험 (controlled experiment)은 그러한 인식의 격차를 명확히 드러냈습니다. 16명의 숙련된 개발자들이 자신의 오픈 소스 저장소(open-source repositories)에서 246개의 작업을 완료했으며, AI 도구 사용 여부는 무작위로 할당되었습니다. AI 도구를 사용했을 때, 작업 시간은 19% 더 오래 걸렸습니다. 연구 전, 그들은 AI가 시간을 24% 절약해 줄 것이라고 기대했습니다. 연구 후에도, 그들은 여전히 AI가 자신들의 속도를 약 20% 높여주었다고 믿었습니다.

이것이 METR 논문에서 가장 중요한 발견입니다. 단순히 AI가 이 개발자들의 속도를 늦췄다는 점이 아니라, 개발자들이 자신의 생산성을 잘못 읽었다는 점입니다.

주의 사항도 중요합니다. METR의 표본은 작았고, 개발자들은 숙련되었으며, 작업은 복잡했고, 작업 내용은 익숙한 실제 코드베이스(codebases) 내에서 이루어졌습니다. 또한 METR은 이후 연구 설계 및 선택 문제로 인해 후속 실험이 신뢰할 수 없는 추정치를 생성했다는 후속 보고서를 발표했습니다. 따라서 이 속도 저하 결과가 보편적인 법칙으로 취급되어서는 안 됩니다.

Microsoft, Accenture, 그리고 익명의 Fortune 100 기업에 걸쳐 수행된 Cui 등의 더 큰 규모의 현장 실험(field experiment)은 매우 다른 결과를 발견했습니다. AI 코딩 어시스턴트를 사용하는 4,867명의 개발자 사이에서 완료된 작업이 26% 증가했습니다. 이러한 효과는 신입 및 주니어 직원들에게 더 강력하게 나타났습니다.

두 가지 결과 모두 사실일 수 있습니다.

작업이 제한적이고, 컨텍스트(context)가 판독 가능하며, 코드베이스를 탐색하기 쉽고, 개발자가 축적된 도메인 특화적 이점이 적을 때 AI는 더 많은 도움을 줍니다. 반면, 작업이 깊은 로컬 컨텍스트(local context), 아키텍처적 판단(architectural judgment), 프로덕션 직관(production intuition), 그리고 복잡한 코드베이스로의 신중한 통합을 요구할 때 AI는 도움이 덜하며 오히려 해가 될 수도 있습니다.

그러한 차이가 중요한 이유는 대부분의 기업 엔지니어링이 그린필드 (Greenfield, 신규 구축) 데모 작업이 아니기 때문입니다. 그것은 레거시 시스템 (Legacy systems), 마이그레이션 (Migrations), 의존성 (Dependencies), 보안 제약 (Security constraints), 테스트 공백 (Test gaps), 절반만 문서화된 비즈니스 규칙 (Half-documented business rules), 그리고 아무도 건드리고 싶어 하지 않는 코드들로 이루어져 있습니다.

AI는 그럴듯한 코드를 생성하는 데 매우 능숙합니다.

기업의 문제는 검증 가능하고, 유지보수가 가능하며, 프로덕션 환경에서 안전한 변경을 수행하는 것입니다.

텔레메트리 (Telemetry)가 황색 경고를 보내고 있다

Faros AI의 텔레메트리는 이러한 트레이드오프 (Tradeoff)의 형태를 포착합니다. 4,000개 팀에 걸친 22,000명의 개발자를 대상으로 한 분석에서 산출량은 급격히 증가했습니다. 개발자당 태스크 처리량 (Task throughput)은 33.7% 증가했고, 개발자당 에픽 (Epics)은 66.2% 증가했으며, 팀당 풀 리퀘스트 (Pull requests)와 관련된 태스크는 210% 증가했습니다. 하지만 품질과 안정성 신호는 반대로 움직였습니다. 풀 리퀘스트당 인시던트 (Incidents)는 242.7% 증가했고, 월간 인시던트는 57.9% 증가했으며, 개발자당 버그는 54% 증가했습니다.

다시 말하지만, 이것이 AI가 모든 다운스트림 (Downstream) 문제를 일으켰다는 인과적 증거는 아닙니다. 이는 무작위 대조 실험 (RCT)이 아닌 벤더 (Vendor)의 텔레메트리입니다.

하지만 이는 엔지니어들이 다른 곳에서 보고하고 있는 내용과 방향성 측면에서 일치합니다. 즉, 조직이 해당 산출물을 흡수해야 하는 검증 시스템을 업그레이드하기 전에 AI가 산출량을 먼저 증가시킨다는 것입니다.

이어지는 벤더 텔레메트리도 Faros와 동일한 주의 사항을 포함합니다. 이 기업들은 코드 품질, 보안, 리뷰 도구를 판매합니다. 그들에게는 고객이 생성하는 코드에서 문제를 드러낼 상업적 인센티브가 있습니다. 그렇다고 해서 데이터가 틀렸다는 의미는 아니지만, 이 결과는 증거가 아닌 신호 (Signal)로 읽어야 함을 의미합니다.

Sonar의 2026 개발자 설문 조사에 따르면 개발자의 96%가 AI가 생성한 코드를 완전히 신뢰하지 않는 것으로 나타났지만, AI가 생성한 코드를 커밋 (Commit)하기 전에 항상 검증한다고 답한 비율은 48%에 불과했습니다. 또한 Sonar는 개발자의 53%가 AI가 올바르게 보이지만 신뢰할 수 없는 코드를 자주 생성한다는 점에 동의한다는 사실을 발견했습니다.

그것이 압축된 형태의 검증 비용 (verification tax)입니다. 개발자들은 결과물을 신뢰할 수 없다는 것을 알지만, 결과물을 내놓아야 한다는 압박 때문에 부분적인 검증에 그치게 됩니다.

보안 증거 또한 같은 방향을 가리키고 있습니다. Veracode의 GenAI Code Security Report는 일반적인 프로그래밍 언어 전반에 걸쳐 100개 이상의 대규모 언어 모델 (LLM)을 테스트했으며, 생성된 코드 샘플의 45%가 OWASP Top 10 취약점 클래스를 포함한 보안 테스트를 통과하지 못했다는 사실을 발견했습니다. 더 크고 최신인 모델이라고 해서 일관되게 더 안전한 코드를 생성하지는 않았습니다.

CodeRabbit의 470개 오픈 소스 풀 리퀘스트 (PR) 분석에 따르면, AI가 공동 작성한 PR은 사람이 작성한 PR보다 PR당 약 1.7배 더 많은 이슈를 포함하고 있었으며, 보안 취약점은 최대 2.74배 더 높았습니다.

Apiiro는 AI의 도움을 받는 개발자들이 3~4배 더 많은 코드를 작성하고 있으며, AI가 생성한 코드가 보안 탐지 건수를 10배 증가시켰다고 보고했습니다. 관찰된 저장소(repository)를 기준으로 2025년 6월까지 월간 신규 탐지 건수는 10,000건에 달했습니다. Apiiro의 속도 및 취약점 분석을 참조하십시오.

이 패턴은 "AI 코드가 나쁘다"가 아닙니다.

이 패턴은 "AI가 분모를 바꾼다"는 것입니다.

코드의 양이 리뷰 역량, 테스트 커버리지 (test coverage), 보안 스캐닝 (security scanning), 아키텍처 검토 (architectural scrutiny), 그리고 운영 피드백 루프 (production feedback loops)보다 더 빠르게 증가할 때, 개별 개발자가 더 빨라졌다고 느끼더라도 시스템은 덜 안정적이 됩니다.

검증 비용은 일시적인 것이 아닙니다

흔히 하는 실수는 검증을 개발자들이 도구에 익숙해지면 사라질 초기 도입 단계의 마찰로 취급하는 것입니다.

일부는 사라질 것입니다. 프롬프팅 (Prompting) 기술이 개선되고, 도구 (Tooling)가 개선될 것입니다. 개발자들도 AI가 어디에 유용하고 어디가 위험한지 배우게 될 것입니다.

하지만 핵심적인 검증 비용은 구조적인 문제입니다.