AI 도입 효과를 물어보면 팀마다 숫자가 다르다. 어떤 팀은 "3배 빨라졌다"고 하고, 어떤 팀은 "별 차이 없다"고 한다. 그 격차가 도구의 품질 차이라면 간단하다. 하지만 최근 나온 세 가지 사례를 나란히 놓고 보면, 그 격차는 도구가 아니라 측정과 설계의 차이에서 비롯된다는 걸 알 수 있다.
8%라는 불편한 숫자
DX가 400개 이상의 엔지니어링 조직을 대상으로 16개월간 진행한 종단 연구에서 AI 도구 사용률은 65% 증가했지만, 중간값 PR 처리량 증가는 겨우 8%에 그쳤다. 대부분의 조직이 5~15% 범위에 머물렀다. 벤더들이 약속한 3배, 10배와는 거리가 멀다.
왜 이런 결과가 나왔을까. 마이크로소프트에서 개발자 생산성 연구를 이끄는 Brian Houck의 설명이 핵심을 찌른다. 코딩은 개발자 주당 업무의 약 14%에 불과하다. 나머지 86%—리뷰, 기획, 디버깅, 컨텍스트 전환, 스테이크홀더 커뮤니케이션, 이해되기 전에 만들어진 기능의 재작업—는 코드 작성 속도가 빨라진다고 해서 함께 빨라지지 않는다. 코딩 도구만 도입하고 나머지 86%를 그대로 두면, 아무리 잘 만든 AI 어시스턴트도 팀 전체 생산성에 기여할 수 있는 상한선이 14%다.
Scrum을 12개 에이전트로 대체한 팀의 선택
이 14% 문제를 정면으로 건드린 사례가 dev.to에 공개된 'Agent-Driven Development(ADD)' 실험이다. 저자는 스프린트 플래닝, 스탠드업, Jira 보드, Confluence 위키를 모두 12개의 전문화된 AI 에이전트로 교체했다. Mac mini 한 대 위에서 돌아가는 이 시스템은 Intake, 요구사항 분석, 설계, 기술 스펙, 개발, 코드 리뷰, 테스트, 배포, 상태 보고, 학습, 스킬 프로파일링까지 전 단계를 커버한다.
가장 인상적인 부분은 "코드가 곧 위키다"라는 아키텍처 원칙이다. 문서는 작성 직후부터 거짓말을 시작한다. 아무도 최신 상태를 유지하지 않기 때문이다. 이 시스템은 PR이 머지될 때마다 저장소에서 지식을 자동 추출하고, 콜 그래프·모듈 경계·커밋 히스토리를 벡터 검색 가능한 형태로 인덱싱한다. Slack에서 "P3 백로그 진행 상황은?"이라고 물으면 누군가가 지난 화요일에 입력한 숫자가 아니라 지금 코드베이스의 실제 상태가 답으로 돌아온다.
스탠드업도 다르다. 매일 오전 8시 30분 크론으로 실행되는 Status 에이전트는 누구에게도 "어제 뭐 했어요?"를 묻지 않는다. 대신 실제 PR, 커밋, 버그, 채팅 활동을 읽고 리스크 플래그와 함께 요약을 만든다. 보드는 사람이 업데이트하지 않아도 작업 자체가 반영된다. 이것이 "코딩 도구"가 아니라 "프로세스 도구"에 AI를 적용한 결과다.
12년 경험을 AI에 패키징한 뒤 해고당한 엔지니어
같은 dev.to에서 전혀 다른 방향의 사례가 나왔다. 한 시니어 인프라 엔지니어는 3개월간 자신의 12년 경험을 AI Skill로 패키징하는 작업에 협력했다. 역사적 장애 시나리오 312건에 대해 96.8% 진단 정확도를 달성했고, 그 직후 그는 해고됐다.
문제는 다섯 달 뒤 찾아왔다. 새벽 3시 47분, 결제 시스템 P99 레이턴시가 80ms에서 12초로 폭증했다. AI Skill은 즉시 진단을 내렸다. 450ms 백오프 재시도 로직 적용. 이 처방은 312번 연속으로 옳았다. 313번째는 달랐다.
450ms 재시도 윈도우는 RabbitMQ 시절 Erlang VM GC 사이클에 맞춰 2주간 부하 테스트로 도출한 값이었다. 그런데 팀은 3년 전 Kafka로 마이그레이션했다. Kafka의 컨슈머 그룹은 폴링 프로토콜을 쓴다. 60개 메시지 × 450ms = 27,000ms가 5,000ms 폴 타임아웃을 초과하면서 리밸런스가 연쇄적으로 발생했다. AI는 어제의 아키텍처에는 완벽하게 옳았다. 오늘의 아키텍처에는 불을 끄러 갔다가 기름을 부었다.
오전 4시 12분, 전 CTO가 그에게 전화를 걸었다. 컨설턴트 시급은 퇴직 당시 연봉의 5배였다. AI Skill이 96.8%의 정확도를 달성했던 그 순간부터, 나머지 3.2%의 비용을 누가 감당할지는 설계되어 있지 않았다.
측정해야 할 세 가지
세 사례를 합치면 AI 도입 전에 반드시 짚어야 할 질문 세 가지가 나온다.
첫째, 코딩이 실제 병목인가. 14% 문제를 직접 확인하라. 팀의 한 주를 구간별로 분해해보면 코딩·리뷰·기획·컨텍스트 전환·재작업이 각각 얼마나 되는지 보인다. 코딩이 병목이 아닌 팀에 코딩 AI를 도입하면 14%의 상한 안에서 맴돈다. 스프린트 회고에 메트릭을 결합한 에이전트 접근처럼 나머지 86%를 겨냥해야 생산성 곡선이 달라진다.
둘째, 지식의 유효기간을 추적하고 있는가. Confluence 페이지가 마지막으로 편집된 날짜를 확인해보라. 팀이 실제로 결정을 내리는 근거가 얼마나 오래된 정보인지가 드러난다. ADD 사례의 핵심은 에이전트 12개가 아니라 "코드가 유일한 권위 있는 문서"라는 원칙이다. 지식이 얼마나 빠르게 부패하는지 측정하지 않으면 어떤 도구를 써도 조직은 잘못된 전제 위에서 일한다.
셋째, AI가 옳지 않은 경우의 비용이 설계되어 있는가. 96.8% 정확도는 인상적인 숫자다. 그런데 나머지 3.2%가 새벽 4시 결제 시스템 장애라면 그 비용은 숫자가 아니다. AI가 학습한 아키텍처와 현재 운영 중인 아키텍처 사이의 드리프트를 누가, 얼마나 자주 검증하는지 설계하지 않은 자동화는 96.8%의 안전과 3.2%의 재앙을 동시에 배포하는 것이다.
도구 이전에 설계가 먼저다
AI-First 워크플로우 전환에서 내가 반복적으로 목격하는 실패 패턴은 하나다. 도구를 먼저 켜고, 측정은 나중에 한다. 코딩 어시스턴트를 팀 전체에 배포하고 6개월 후 "생각보다 효과가 없다"는 결론에 도달한다. 그때쯤이면 이미 변경 비용이 쌓여 있다.
ADD 사례는 12개 에이전트의 화려함 때문에 주목받지만, 실제 교훈은 그 전 단계다. 어떤 프로세스가 실제로 팀을 느리게 하는지, 어디서 지식이 부패하는지, 자동화 실패의 경계가 어디인지를 먼저 진단했기 때문에 에이전트가 올바른 위치에 배치될 수 있었다. 해고된 엔지니어의 사례는 그 반대다. 측정은 96.8% 정확도에서 멈췄고, 아키텍처 드리프트 검증은 설계되지 않았다.
AI-First로 팀을 리빌딩할 때 가장 먼저 해야 할 일은 새 도구를 평가하는 게 아니다. 지금 팀의 시간이 어디로 사라지는지, 어떤 지식이 얼마나 빠르게 부패하는지, 자동화의 경계 조건이 어디인지를 측정하는 것이다. 그 세 가지를 먼저 확인한 팀만이 AI 도구를 8%가 아닌 다른 숫자로 전환시킬 수 있다.