기술 실사가 밝혀내는 것: 덱이 70% 자동화라고 말할 때

원문 제목: What Technical Due Diligence Finds When the Deck Says “70% Automated” — Soukaïna Abelhad URL: https://www.youtube.com/watch?v=gDRCpTMCqEU 날짜: 2026-10-14 채널: aiDotEngineer

📌 핵심 질문 / 기술 실사의 핵심 논점

==“70% 자동화”라는 인상적인 숫자가 실제 노동 제거와 경제적 가치로 이어졌다는 주장을 기술 실사(technical due diligence)가 어떻게 검증할 것인가?==

• 산술: AI 도입 뒤 처리량과 완전부하 인건비가 함께 어떻게 변했는지 비교한다.
• 정의: AI 기여(attributed)와 사람 개입 없는 완전한 자동화(autonomous)를 분리하고, straight-through processing의 경계를 이름 붙인다.
• 평가와 경제성: 자동 채점기가 아니라 전문가가 인정한 품질을 기준으로 삼고, 검토·에스컬레이션·재작업 비용을 반영한 단위경제성(unit economics)만 의사결정에 사용한다.

진짜 위험한 숫자는 반드시 조작된 숫자가 아니다. 실제 측정값이 측정이 지지할 수 없는 결론으로 운반될 때 위험해진다. 따라서 구매자나 투자자는 데모가 아니라 메모를 위해 만들어진 시스템인지, 그리고 운영 지표가 실제로 어떤 노동·품질·비용 구조를 뜻하는지 확인해야 한다.

0. 출발점: 측정값과 결론 사이의 간극

0.1. AI를 만드는 쪽과 평가하는 쪽을 함께 보기

1. 양쪽에서 쌓은 경험

   1. 투자 전문가용 시스템 구축: Soukaïna Abelhad는 AI tech lead로서 투자 전문가들이 사용하는 AI system을 구축했다.
   2. 프로덕션 평가: 현재는 production AI evaluation을 이끌며 executives에게 전달되는 숫자를 만드는 일도 돕는다.
   3. 경험의 폭: AI를 만드는 쪽과 평가하는 쪽을 모두 8년 이상 경험했다.

2. 진짜 위험한 숫자의 성격

   1. 조작만이 문제는 아니다: 위험한 숫자는 반드시 fabricated된 숫자가 아니며, 실제 측정값이 그 측정이 지지할 수 없는 결론으로 운반될 때도 위험해진다.
   2. 구매자 관점의 기준: Chun Chan이 제시한 “Built for the memo, not for the demo”라는 기준을 operational metrics에도 적용해야 한다.

1. 산술 검사: 처리량 증가가 노동 제거를 뜻하는가

AI 도입률만 보지 말고, 시스템 안으로 들어온 업무량과 그 업무를 감당하는 완전부하 인건비를 같은 기간에 놓아야 한다.

1.1. 관찰 데이터가 보여주는 처리량과 검토 부담

1. Faros 관찰 데이터의 세 가지 변화

   1. Pull request 처리량: AI 활용도가 높은 팀은 pull request를 98% 더 많이 병합했다.
   2. 검토 시간: Pull request review time은 91% 증가했다.
   3. 변경 규모: 평균 pull request는 154% 더 커졌다.

2. 표본의 범위와 해석 한계

   1. 규모: 표본은 1,255개 팀의 개발자 10,000명 이상을 포함했다.
   2. 관찰 연구의 한계: 이 결과는 AI가 headcount를 늘렸다는 사실이나 인과관계를 증명하지 않는다. 통제된 노동 연구가 아니라 관찰 telemetry이기 때문이다.
   3. 실사상 경고: 더 많은 일이 시스템에 유입되면 downstream review burden도 함께 커졌다는 신호는 분명하다.

1.2. 회사 자체의 18개월 이론을 검증하는 법

1. 업무량과 노동을 한 화면에 놓기

   1. 회사 설명 요구: 회사가 주장하는 자동화 효과가 성립하는 18개월짜리 이론(theory)을 제시하게 한다.
   2. 비교 단위: workload volume을 fully loaded human labor와 나란히 놓고 같은 기간의 변화율을 비교한다.

2. AI 때문에 생긴 모든 사람의 일을 세기

   1. 운영 인력: AI가 만든 결과를 운영하는 operators의 시간을 포함한다.
   2. 검토·학습 인력: reviewers와 trainers의 노동을 포함한다.
   3. 실패 처리: escalation과 rework에 투입되는 사람의 노동도 자동화 비용에 넣는다.

3. 지원과 제거를 가르는 기준

   1. 노동량의 추적: human labor가 workload volume을 따라가면 자동화가 노동을 제거한 것이 아니라 작업을 보조한 것이다.
   2. 주장의 조건: 처리량이 커져도 완전부하 인건비가 줄었다는 증거가 있어야 labor removal 주장이 성립한다.

2. 정의 검사: AI 기여와 자율 실행을 분리하기

자동화율은 무엇을 자동화의 완료로 간주하는지에 따라 전혀 다른 숫자가 되므로, 측정 경계를 먼저 고정해야 한다.

2.1. 70% AI-attributed pull request의 빈틈

1. Uber 수치가 말하는 것과 말하지 않는 것

   1. 공개된 주장: Uber는 pull request의 70%가 AI-attributed라고 말한다.
   2. 남은 질문: 이 수치는 인상적이지만 full autonomous rate를 알려주지 않는다.
   3. 공개 정보의 부족: 측정 기간과 전체 pull request 수(total count)도 공개되지 않았다.

2. 자동화 주장에 붙는 개입 단계

   1. AI drafted: AI가 초안을 만들었을 뿐인 경우다.
   2. Human edited: 사람이 AI 결과를 편집한 경우다.
   3. Human approved: 사람이 결과를 승인한 경우다.
   4. No human intervention: 사람의 개입 없이 끝까지 처리된 경우다.

2.2. Straight-through processing으로 경계 이름 붙이기

1. 금융권의 유용한 기준

   1. 용어: finance에서는 마지막 단계처럼 사람 개입 없이 끝까지 처리되는 것을 straight-through processing이라고 부른다.
   2. 실사 정의: 이름 붙인 업무 경계 안에서 end-to-end가 완성되고 human intervention이 전혀 없는 상태로 정의해야 한다.

2. 완료 지점에 따른 숫자의 변화

   1. 초안 기준: code가 drafted된 순간을 끝으로 보면 자동화율이 높게 나온다.
   2. 승인 기준: pull request가 approved된 순간을 끝으로 보면 사람 검토와 승인 과정이 포함된다.
   3. 배포 기준: change가 production에 도달한 순간을 끝으로 보면 테스트, 운영, 롤백, 장애 대응까지 포함된다.

3. 핵심 구분

   1. AI-attributed: AI가 어느 단계에 기여했다는 주장이다.
   2. Autonomous: 명시한 경계 안에서 사람 없이 업무가 완료됐다는 더 강한 주장이다.
   3. 질문: “여기서 경계는 code draft, pull request approval, production 도달 중 어디에서 끝나는가?”를 물어야 한다.

3. 평가 검사: 자동 채점기가 품질을 대신할 수 있는가

정의가 정확해도 측정 도구가 실제 전문가의 수용 판단과 맞지 않으면 자동화율은 의사결정에 쓸 수 없다.

3.1. Meta 연구가 드러낸 자동 평가의 낙관 편향

1. 연구 설계

   1. 차이: Meta는 human baseline을 조정한 뒤 automated grader와 merge decision 사이에 24 percentage-point gap을 발견했다.
   2. 전문가 표본: 세 저장소(repository)의 maintainer 네 명이 참여했다.
   3. 패치 표본: 서로 다른 이슈에서 생성된 AI pull request 296개를 검토했다.
   4. 블라인드 조건: maintainer들은 각 patch가 AI에서 왔는지 사람에게서 왔는지 알지 못했다.

2. 자동 채점과 실제 수용의 간극

   1. 낙관성: automated grader는 실제 작업을 수용할 책임이 있는 사람보다 상당히 낙관적이었다.
   2. 실무적 의미: 자동 validation을 통과한 출력이 곧 merge 가능한 품질이라는 뜻은 아니다.

3.2. 평가 성숙도를 판별하는 질문

1. Ground truth의 출처

   1. 라벨러: ground truth를 누가 라벨링했는지 묻는다.
   2. 전문가 일치: expert가 그 판단에 동의하는지 확인한다.
   3. 일치도 측정: 사람과 자동 판정의 agreement를 측정하는지 확인한다.

2. 자동 judge의 검증과 누락된 실패

   1. 검증 기준: automated judge가 무엇과 대조되어 검증됐는지 묻는다.
   2. 탈출한 실패: 어떤 bad output이 자동 평가를 빠져나갔는지 묻는다.
   3. 신뢰도 신호: evaluation maturity가 자동화 주장의 첫 번째 credibility signal이다.

3. 현장 경험이 주는 경고

   1. 자동 검증만 통과한 결과: 실제 프로젝트에서 10개 중 10개의 output이 automated validation을 통과했다.
   2. 전문가 검토 뒤의 결과: 전문가를 참여시키자 살아남은 결과는 손에 꼽을 정도로 줄었다.
   3. 실사 결론: 자동 채점 통과율은 전문가 수용률과 별도 지표로 취급해야 한다.

4. 의사결정과 경제성: 살아남은 숫자를 가치로 변환하기

산술·정의·평가를 통과한 주장도 실제 비용과 수익을 견디지 못하면 투자나 구매 결정을 지지할 수 없다.

4.1. Builder.ai 사례에서 얻는 프로세스 교훈

1. 인과관계와 실사 교훈을 분리하기

   1. 과도한 주장 금지: 약한 AI positioning이 Builder.ai의 붕괴를 일으켰다고 단정할 수 없다.
   2. 복합 원인: insolvency에는 AI 주장 외에도 revenue와 financing 문제가 있었다.

2. 경고가 있었던 시간선

   1. 2019년: Wall Street Journal은 AI capability 주장에 공개적으로 의문을 제기했다.
   2. 2025년 5월: Financial Times는 2024년 revenue estimate가 2억 2,000만 달러에서 약 5,500만 달러로 수정됐다고 보도했다.
   3. 2025년 6월 2일: 회사는 Chapter 7을 신청했다.
   4. 프로세스 실패: 경고는 존재했지만 그것을 의사결정의 gate로 바꾸는 절차가 작동하지 않았다.

4.2. Accepted autonomous task의 비용 계산

1. 가치에서 비용으로 내려가기

   1. Eligible workflow value: 실제로 자동화 대상이 될 수 있는 업무의 가치를 산정한다.
   2. Actual adoption: 고객이나 조직이 실제로 사용하는 비율을 적용한다.
   3. Straight-through success: 이름 붙인 workflow가 사람 개입 없이 끝나는 성공률을 적용한다.
   4. Accepted quality: 전문가가 받아들이는 품질을 적용한다.

2. 빠뜨리면 안 되는 공제 항목

   1. AI 비용: 모델·도구·인프라 비용을 뺀다.
   2. 사람의 검토 비용: human review와 운영 인력 비용을 뺀다.
   3. 실패 비용: escalation과 rework 비용을 뺀다.

3. 가장 유용한 단위 지표

   1. 정의: cost per accepted autonomous task, 즉 승인된 자율 처리 업무 한 건의 비용을 계산한다.
   2. 실패도 비용에 포함: task가 실패하거나 escalation되거나 rework가 필요하면 그 비용을 해당 지표에 넣는다.
   3. 결정 기준: 단순 자동화율이 아니라 받아들여진 결과 한 건을 얼마에 만들었는지가 경제성 판단의 기준이다.

5. 다음 미팅에 가져갈 세 가지 검사 카드

5.1. 세 가지 질문을 하나의 순서로 묶기

1. Arithmetic

   1. workload volume을 fully loaded human labor와 비교한다.
   2. 처리량 증가를 노동 제거로 오인하지 않는다.

2. Definition

   1. named workflow의 경계를 정한다.
   2. AI-attributed와 straight-through rate를 구분한다.

3. Evaluation

   1. 누가 quality를 정의하는지 묻는다.
   2. 전문가가 동의하는지, 어떤 output이 평가를 빠져나갔는지 확인한다.

5.2. 최종 의사결정 규칙

1. 검증된 주장만 경제성으로 번역하기: 세 검사를 모두 통과한 주장만 실제 비용·품질·채택률을 반영한 unit economics로 바꾼다.
2. 검증 결과가 약할 때: 숫자가 인상적이라는 이유로 결론을 내리지 말고, 검증하거나 거래를 포기한다.
3. 실무 도구: 세 검사 카드는 vendor meeting이나 investment discussion에서 바로 사용할 수 있도록 printable card 형태로 제공되며, source notes와 함께 웹사이트에 공개되고 QR 코드로 접근할 수 있다.

주요 발언 모음

“The dangerous number is not always fabricated. It's often a genuine measurement carried into a conclusion it cannot support.”

“Built for the memo, not for the demo.”

“AI-attributed and autonomous are two different claims.”

“The job of diligence is not to ask whether the number is impressive. It's to ask what must be true for the number to matter.”

“Believe it, test it, or walk away.”

핵심 데이터 & 수치

• 55.8% faster: 95명의 professional developer가 참여한 controlled experiment에서 제시된 수치다.
• 실험 범위: template에서 만든 JavaScript HTTP server 한 개와 visible test 12개를 대상으로 했다.
• Faros 표본: 개발자 10,000명 이상, 1,255개 팀을 포함한 observational telemetry다.
• Faros 변화: AI 활용도가 높은 팀에서 병합한 pull request는 98% 증가했고, review time은 91% 늘었으며, 평균 pull request 크기는 154% 커졌다.
• Uber 주장: pull request의 70%가 AI-attributed이지만 측정 기간과 total count, full autonomous rate는 공개되지 않았다.
• Meta 연구: 세 repository의 maintainer 네 명이 서로 다른 이슈의 AI-generated pull request 296개를 검토했고, automated grader와 merge decision 사이에 24 percentage-point gap이 나타났다.
• Builder.ai 시간선: 2019년 WSJ의 공개 문제 제기, 2025년 5월 Financial Times의 revenue estimate 수정 보도, 2025년 6월 2일 Chapter 7 신청이 이어졌다.

결론 및 시사점

1. AI 자동화 주장은 처리량·인건비의 산술부터 검증해야 한다.
2. “AI가 기여했다”는 사실과 “사람 없이 끝났다”는 사실을 분리해야 한다.
3. 자동 채점기의 성공률보다 전문가가 수용한 결과의 비율을 우선해야 한다.
4. 실패·에스컬레이션·재작업을 포함한 accepted autonomous task의 비용을 계산해야 한다.
5. 산술·정의·평가를 통과한 주장만 unit economics와 투자·구매 결정으로 연결해야 한다.

20줄 핵심 요약

“70% 자동화”라는 숫자는 무엇을 자동화의 완료로 간주했는지 밝히지 않으면 의미가 없다. 55.8% faster라는 수치는 95명의 전문 개발자가 참여한 통제 실험에서 나왔다. 그 실험은 템플릿 기반 JavaScript HTTP server 한 개와 공개 테스트 12개만 다뤘다. 실험 결과를 조직 전체의 노동 제거로 일반화하려면 추가적인 검증이 필요하다. Faros 관찰 데이터에서 AI 활용도가 높은 팀은 pull request를 98% 더 많이 병합했다. 같은 팀의 pull request review time은 91% 증가했다. 평균 pull request 크기도 154% 커져 downstream 검토 부담이 늘었다. 관찰 telemetry는 인과관계를 증명하지 않지만 처리량과 검토량이 함께 커졌다는 경고를 준다. 실사는 회사의 18개월 이론과 workload volume 및 fully loaded human labor를 함께 요구해야 한다. 운영자·검토자·트레이너·에스컬레이션·재작업 인력의 노동도 자동화 비용에 포함해야 한다. 사람의 노동이 업무량을 따라가면 자동화는 노동 제거가 아니라 지원에 가깝다. Uber의 70% AI-attributed pull request는 full autonomous rate와 다른 주장이다. 자동화 경계가 초안·승인·production 도달 중 어디인지 명시해야 한다. Meta 연구는 automated grader와 실제 merge decision 사이에 24 percentage-point 차이를 보였다. 전문가가 ground truth를 만들고 자동 judge와의 일치도를 측정하는지가 평가 성숙도의 핵심이다. Builder.ai 사례는 약한 AI 포지셔닝의 인과관계보다 경고를 의사결정 gate로 만들지 못한 절차를 보여준다. 경제성은 eligible workflow value에 실제 채택률·straight-through 성공률·수용 품질을 적용해 계산해야 한다. AI·검토·에스컬레이션·재작업 비용을 빼야 accepted autonomous task의 실제 비용이 나온다. 산술·정의·평가를 통과한 주장만 unit economics로 번역할 수 있다. 실사의 핵심 질문은 숫자가 인상적인지가 아니라 그 숫자가 중요해지려면 무엇이 참이어야 하는지다.