"AI를 도입했지만 아무런 성과가 없었다"와 "AI 덕분에 개발 속도가 극적으로 빨라졌다"라는 말이 같은 해에, 심지어 같은 회사 내에서도 동시에 나오고 있습니다. 이 격차는 어디에서 오는 걸까요?

Stanford Digital Economy Lab의 The Enterprise AI Playbook: Lessons from 51 Successful Deployments (2026년 4월)는 실제 데이터를 통해 이 질문을 추적합니다. 이 보고서는 41개 조직과 9개 산업 전반에 걸친 51개의 프로덕션 배포 (production deployments) 사례를 분석하며, 구조화된 인터뷰와 내부 문서를 활용하여 무엇이 배포를 성공하게 만들었는지, 그리고 무엇이 실패하게 만들었는지를 구분해냅니다.

지금까지의 대부분의 보도는 경영진의 관점에서 이 보고서를 다루어 왔습니다. 즉, AI 도입을 조직 변화 (organizational-change)의 문제로 보고, 프로세스 재설계 (process redesign)와 경영진의 의지 (executive commitment)의 중요성을 강조했습니다. 그러한 프레임워크는 정확합니다. 하지만 이 보고서는 고객 지원 (customer support), 소프트웨어 엔지니어링 (software engineering), 마케팅 (marketing) 등 다양한 분야를 다루고 있으며, 경영 중심의 관점에서는 거의 건드리지 않는 소프트웨어 엔지니어링에 관한 풍부한 내용이 담겨 있습니다.

엔지니어의 시각으로 이 보고서를 읽어보면 한 가지 역설이 눈에 띕니다. 고객 지원과 IT 운영 (IT operations)이 자율형 AI (autonomous AI)를 향해 나아가는 반면, 코딩 (coding)만은 여전히 "인간-AI 협업 (human-AI collaboration)" 상태에 머물러 있다는 점입니다. 이는 "AI 코딩이 최전선이다"라는 지배적인 분위기와 상충하는 결과입니다.

이 포스트는 바로 그 역설에서 시작합니다. 먼저 보고서의 방법론과 주요 발견 사항을 살펴본 후, 코딩을 협업 상태로 유지시키는 구조를 분석하겠습니다. 마지막으로 51개의 사례를 세 가지 관점, 즉 개별 엔지니어, 엔지니어링 리드 (engineering lead), 그리고 조직 수준의 개발을 책임지는 사람의 관점에서 다시 읽어보겠습니다. 저는 보고서의 발견 사항에 충실하면서도, 그 너머를 파고들어 보겠습니다.

51개 사례의 실체

나중에 해석이 제대로 이루어질 수 있도록 연구에 대해 빠르게 살펴보겠습니다.

저자 및 배경

저자는 Elisa Pereira, Alvin Wang Graylin, 그리고 Erik Brynjolfsson입니다. Brynjolfsson은 정보 경제학 분야에서 가장 많이 인용되는 연구자 중 한 명으로, IT 투자의 생산성 효과를 측정하는 초기 연구로 잘 알려져 있습니다. Brynjolfsson과 동료들이 2021년에 제시한 "생산성 J-곡선 (Productivity J-Curve)"은 이 연구의 기초 중 하나입니다.

J-곡선은 다음과 같습니다. AI와 같은 범용 기술 (General-purpose technology)은 단순히 배포된다고 해서 생산성을 높이지 않습니다. 프로세스 재설계, 교육, 조직 개편과 같은 무형 자산에 대한 보완적 투자 (Complementary investment)가 필요합니다. 이러한 투자 기간 동안 생산성은 실제로 하락합니다. 투자가 결실을 맺은 후에야 생산성이 급등합니다. 곡선이 튀어 오르기 전에 저점 (Trough)으로 떨어지기 때문에 "J" 형태를 띠게 됩니다. 조직이 기술보다 더 중요하다는 이 보고서의 반복되는 메시지는 바로 이 전제에 기반하고 있습니다.

방법론 (Method)

이 연구는 파일럿 (Pilot) 단계를 넘어 실제 운영 단계로 진입하고 측정 가능한 비즈니스 가치를 창출한 배포 사례만을 살펴봅니다. 선정 기준은 다음과 같습니다:

• 안정적인 운영, 실제 워크플로 (Workflows)에 통합됨
• 최소 3개월 동안 여러 팀의 의사결정에 사용됨
• 생산성, 매출 또는 고객 만족도 측면에서 명확한 결과가 나타남
• 다른 팀이나 지역으로 복제 가능함

인터뷰는 2025년 8월부터 2026년 2월까지 진행되었으며, 기업당 최소 1회의 60분 구조화된 인터뷰 (Structured interview)를 실시하였고, 내부 지표, 프로젝트 계획서 및 재무 서류를 통해 보완되었습니다. 표본은 제조업, 금융 서비스 및 기술 분야에 치우쳐 있습니다.

이 연구가 우리에게 말해주는 것

결론은 간단합니다. 동일한 목적을 위해 동일한 기술을 사용하더라도, 결과는 조직에 따라 크게 달랐습니다. 차이를 만든 것은 AI 모델이 아니었습니다. 조직이 얼마나 준비되어 있었는지, 어떤 프로세스를 보유하고 있었는지, 리더들이 어떻게 참여했는지, 그리고 실패를 용인하는 문화가 있었는지 여부였습니다.

엔지니어링 조직과 가장 관련이 깊은 연구 결과는 다음과 같습니다:

• 가장 어려운 과제의 77%는 무형의 비용(intangible costs)이었습니다: 변화 관리(change management), 데이터 품질(data quality), 프로세스 재설계(process redesign). 기술 그 자체는 일관되게 "가장 쉬운 부분"으로 평가되었습니다.
• 성공한 프로젝트의 61%는 성공하기 전 이전에 실패한 AI 프로젝트를 경험했습니다. 이러한 매몰 비용(sunk costs)은 성공 사례의 ROI(투자 대비 수익)에 결코 나타나지 않습니다.
• 유사한 유스케이스(use cases)에 대해, 어떤 기업은 몇 주가 걸린 반면 다른 기업은 몇 년이 걸렸습니다. 그 차이는 기술이 아니라 경영진의 참여(executive engagement), 기존 인프라, 그리고 사용자의 의지였습니다.
• AI가 80% 이상을 자율적으로 처리하고 인간은 예외 사항만 검토하는 "에스컬레이션 모델(escalation model)"은 중앙값(median) 생산성 향상이 71%로, 승인 기반 모델(approval-based models)의 30%를 훨씬 상회했습니다. (보고서는 이 격차가 과제 특성의 차이를 일부 반영할 수도 있다고 언급합니다.)
• 에이전틱 AI(Agentic AI) 구현은 여전히 사례의 20%에 불과했지만, 중앙값 생산성 향상은 71%로, 고자동화(high-automation) 접근 방식의 40%보다 높았습니다.
• 사례의 42%에서 모델 선택은 완전히 상호 교환이 가능했습니다. 지속 가능한 우위는 파운데이션 모델(foundation model)이 아니라 오케스트레이션 레이어(orchestration layer)에 있었습니다.

유의해야 할 선택 편향 (selection bias)

강조할 가치가 있는 점은, 이것이 성공적인 배포 사례만을 대상으로 한 연구라는 것입니다. 보고서는 선택 편향(selection bias)에 대해 명시적으로 밝히고 있습니다. 기업들은 과거의 실패와 중단된 파일럿 프로젝트에 대해서도 질문을 받았지만, 최종적으로 분석된 것은 가치를 창출한 사례들입니다.

따라서 이 연구는 "성공이 얼마나 흔한가"가 아니라 "성공이 어떤 모습이며 그곳에 도달하기 위해 무엇이 필요한가"를 보여줍니다. 보고서는 2025년 MIT의 NANDA 이니셔티브 연구인 "The GenAI Divide: State of AI in Business 2025"(생성형 AI 파일럿의 95%가 측정 가능한 재무적 영향을 미치지 못했다고 보고함)를 인용하며, 자신을 그 반대 측면, 즉 성공한 측면에 대한 심층적인 분석으로 포지셔닝합니다. 이러한 비대칭성을 염두에 두고 읽으시기 바랍니다.

코딩의 역설

여기에 핵심이 있습니다. 보고서의 제3장에는 비즈니스 기능별로 인간 참여(human-in-the-loop, HITL) 개입 정도를 정리한 표가 있습니다. 엔지니어의 관점에서 이 표를 읽으면 무언가 어색하게 느껴집니다.

세 가지 HITL 단계

보고서는 HITL을 세 가지 단계로 나눕니다:

• 에스컬레이션 (Escalation): AI가 80% 이상을 자율적으로 처리하며, 인간은 예외적인 경우(샘플링된 20% 이하)에 대해서만 검토합니다.
• 승인 (Approval): AI가 작업을 수행하며, 인간은 결과물이 실행되기 전에 각 출력물을 승인합니다.
• 협업 (Collaboration): 인간과 AI가 모두 작업 단위별로 직접 참여하여 업무를 수행합니다.

자율성(Autonomy)은 에스컬레이션 단계에서 가장 높고, 협업 단계에서 가장 낮습니다. 기능별 분류는 다음과 같습니다:

코딩은 협업(Collaboration) 계층에 속하는 유일한 기능입니다. 임상 문서화(Clinical documentation)는 의료 기록이 의사가 하나하나 서명해야 하는 법적 문서이기 때문에 승인(Approval) 단계에 머물러 있습니다. 보험 청구 처리(Claims processing)와 고객 지원(Customer support)은 처리량이 많고, 명확한 성공 기준이 있으며, 복구 가능한 실수를 허용할 수 있기 때문에 에스컬레이션(Escalation) 단계로 이동할 수 있습니다.

그렇다면 왜 코딩은 협업(Collaboration) 단계에 머물러 있을까요? AI를 구속하는 규제(Regulation)가 이 분야에 있는 것도 아닙니다. 그럼에도 불구하고 인간과 AI는 계속해서 작업 단위별로 함께 일하고 있습니다.

역할이 "작성"에서 "검토"로 전환되다

보고서는 코딩 현장의 변화를 다음과 같이 설명합니다. 엔지니어들이 전체 작업을 스스로 완료하기보다는, AI가 생성한 변경 사항을 검토하고, 미세한 조정을 거친 뒤, PR(Pull Request)을 병합(Merge)하는 비중이 점점 늘어나고 있습니다. 라틴 아메리카의 한 핀테크(fintech) 기업에서는 AI 에이전트가 1억 명 이상의 고객에게 서비스를 제공하는 시스템의 레거시 코드 수백만 줄을 마이그레이션했으며, 원래 18개월과 1,000명 이상의 인력이 필요할 것으로 예상되었던 작업을 단 몇 주 만에 압축하여 완료했습니다. 한 보험사에서는 5,000시간, 7명의 인력, 2027년 완료를 목표로 했던 레거시 재구축 작업이 3명의 인력으로 600시간 만에 끝났습니다.

따라서 코딩이 "빨라지지 않고 있는 것"은 아닙니다. 역할이 작성에서 검토로 이동했으며, 생산성은 54% 향상되었습니다. 단지 다른 기능들이 도달한 완전한 자율성(Full autonomy)에는 아직 이르지 못했을 뿐입니다. 여기에는 구조적인 이유가 있습니다.

에이전트적 성공을 위한 4가지 조건에 따른 코딩 검증

보고서는 에이전트형 AI(Agentic AI)가 성과를 내기 위한 네 가지 조건을 나열합니다:

• 대량의 반복적인 작업 (High-volume, repetitive tasks)
• 명확한 성공 기준 (Clear success criteria)
• 복구 가능한 오류 (Recoverable errors)
• 여러 시스템에 걸친 데이터 접근 권한 (Access to data across multiple systems)

코딩을 이 네 가지 조건에 비추어 보면, 왜 코딩이 협업의 영역으로 남아있는지 그 이유가 명확해집니다.

구매(Procurement)나 경보 분류(Alert triage)는 이 네 가지를 깔끔하게 충족합니다. 높은 작업량, 명확한 정답/오답 여부, 그리고 복구 가능한 실수들이 존재합니다. 따라서 이들은 완전한 자율성(Full autonomy) 단계로 넘어갑니다.

코딩은 어떨까요? 일상적인 리팩토링(Refactors), 테스트 생성(Test generation), 의존성 업데이트(Dependency bumps) 등은 이 네 가지를 충족하는 경향이 있습니다. 하지만 기능 구현(Feature work)이나 아키텍처 변경(Architectural change)은 이 조건들을 깨뜨립니다. 가독성, 유지보수성, 그리고 기존 설계와의 적합성이 관여할 때 "테스트 통과"는 충분한 성공 기준이 될 수 없습니다. 또한 프로덕션 마이그레이션(Production migrations)이나 스키마 변경(Schema changes)은 복구 불가능한 오류를 발생시킬 수 있습니다. 즉, "명확한 성공 기준"과 "복구 가능한 오류"라는 두 가지 조건이 광범위한 코딩 작업 전반에서 충족되지 못합니다.

보고서가 인용한 METR(AI 자율성을 측정하는 연구 기관)의 측정 결과에 따르면, 프런티어 모델(Frontier models)이 자율적으로 완료할 수 있는 소프트웨어 작업의 길이는 약 7개월마다 두 배씩 증가하여 2026년 초에는 인간 전문가 기준 약 15시간 분량에 도달할 것으로 보입니다. 한편, Anthropic은 작업 시간이 약 3.5시간 지점에 도달하면 API 성공률이 50% 미만으로 떨어진다고 경고합니다. 며칠 동안 자율적으로 실행되며 수만 줄의 코드를 생성하는 코딩 에이전트(Coding agents)는 더 이상 드문 일이 아니지만, 작업이 길어지고 복잡해질수록 프로덕션 신뢰성(Production reliability)은 떨어집니다. 이것이 바로 엔지니어의 검토(Engineer review)라는 인간의 개입이 여전히 품질을 지배하는 정확한 이유입니다.

엔지니어링이 협업에 자연스럽게 부합하는 이유

한 걸음 더 나아가 보겠습니다. 코딩이 협업 상태로 남아있는 이유는 AI가 약해서도, 엔지니어가 뒤처져서도 아닙니다. 소프트웨어 엔지니어링에는 이미 깊게 층을 이룬 검증(Verification) 문화가 자리 잡고 있기 때문입니다.

타입 시스템(Type systems), 단위 테스트(Unit tests), 코드 리뷰(Code review), CI, 정적 분석(Static analysis), 카나리 배포(Canary releases). 엔지니어링은 인간이 작성한 코드조차 불신하며 프로덕션에 투입하기 전 여러 단계의 검증을 거치는 문화를 구축하는 데 수십 년을 소비했습니다. AI가 작성한 코드 위에 리뷰를 추가하는 것은 그러한 문화의 가장 자연스러운 확장입니다.

반대 측면: 완전한 자율성 (Escalation)은 그러한 검증 문화와 정면으로 충돌합니다. "샘플의 20%만 인간이 리뷰한다"는 방식은 경보 분류 (Alert triage)에는 효과적일 수 있지만, 프로덕션 코드 (Production code)에 대해 "20%만 리뷰하라"는 것은 대부분의 엔지니어의 본능에 어긋납니다. 코딩이 협업 (Collaboration) 상태로 남는 이유는 부분적으로는 기술적 한계 때문이며, 부분적으로는 엔지니어링이라는 학문 자체가 검증 (Verification)을 중심으로 구축되어 있기 때문입니다.

이런 관점에서 볼 때, HITL (Human-in-the-loop) 수준은 "모델이 개선됨에 따라 자동으로 에스컬레이션 (Escalation) 단계로 넘어간다"는 단순한 문제가 아닙니다. 특정 도메인에서 검증 문화가 강할수록 협업 상태는 더 오래 지속됩니다. 코딩이 자율성으로 나아가는 경로는 모델의 성능뿐만 아니라, 검증의 얼마만큼을 AI 자체에 맡길 수 있는지, 구체적으로 AI가 테스트를 작성하고 AI가 리뷰하는 계층 (Layer)을 어떻게 설계하느냐에 달려 있습니다. 리뷰 자체를 AI에게 맡길 수 있는지 여부는 나중에 다시 다루겠습니다.

세 가지 관점에서의 재독해

코딩이 협업 상태로 남는다는 것이 무엇을 의미하는지는 당신이 어디에 서 있느냐에 따라 달라집니다. 세 가지 관점은 다음과 같습니다: 개별 엔지니어, 엔지니어링 리드 (Engineering lead), 그리고 조직 차원의 개발을 책임지는 사람입니다. 동일한 연구가 이들에게 각각 다른 과제를 부여합니다.

개별 엔지니어: 리뷰가 생산성의 전제 조건이 되다

보고서가 설명하는 변화는 개별 엔지니어의 일상 업무가 이미 변화하고 있음을 의미합니다. 처음부터 코드를 작성하는 대신, AI가 생성한 변경 사항을 읽고, 판단하고, 조정하고, 병합 (Merge)합니다. 코드를 작성하는 데 쓰는 시간은 코드를 평가하는 데 쓰는 시간으로 대체됩니다.

이 지점에서 협업 모델의 본질적인 특성이 드러납니다. 에스컬레이션 (Escalation) 체제하에서는 인간이 예외 상황만 확인합니다. 하지만 협업 (Collaboration) 체제하에서는 인간의 판단이 모든 개별 출력물의 품질을 관장합니다. 리뷰가 소홀해지면 생성된 코드의 결함이 프로덕션 (Production)으로 직행하게 됩니다.

난처한 지점은 AI가 더 뛰어날수록 리뷰가 더 어려워진다는 것입니다. 출력물이 더 "그럴듯하게(plausible)" 보일수록, 인간은 세부 사항을 건너뛰게 됩니다. 자동화 시스템을 과도하게 신뢰하여 주의력이 저하되는 현상인 자동화 안주 (Automation complacency) — 항공 및 공정 산업에서 오랫동안 알려진 현상 — 가 코드 리뷰에서도 나타납니다. 명백히 틀린 코드는 잡아내기 쉽지만, 90%는 맞고 미묘하게 10%가 틀린 코드는 대충 훑어보는 과정에서 빠져나가기 마련입니다. 기능 중 가장 완만한 상승폭을 보인 협업 (Collaboration) 54%는, 생산성 향상을 상쇄하는 이러한 "리뷰 비용(cost of review)"의 결과로 해석될 수 있습니다.

개별 엔지니어에게 던져진 질문은 무엇을 AI에 위임하고 무엇을 자신의 판단 아래 유지할 것인지 그 경계선을 어디에 그을 것인가 하는 점입니다. 데이터는 코딩이 여전히 협업 단계에 머물러 있음을 보여주며, 이는 인간의 판단이 품질과 직접적으로 연결되어 있음을 의미합니다. AI의 출력을 액면 그대로 받아들이지 않는 것, 리뷰를 형식적인 절차로 취급하지 않는 것, 이것들이 이 단계에서의 생산성을 위한 전제 조건이 됩니다. 기술의 방향성 또한 변화하고 있습니다. 무에서 유를 코드로 작성하는 능력보다, 타인(또는 AI)이 작성한 코드에서 결함을 찾아내고 설계 이면에 담긴 의도를 읽어내는 능력이 상대적으로 더 중요해지고 있습니다.