생산성 대시보드가 거짓말을 하고 있다
AI 코딩 어시스턴트를 도입하고 한 달 뒤, 대시보드에 PR 수 40% 증가라는 숫자가 뜬다. 경영진은 박수를 친다. 그런데 배포 주기는 그대로고, 리뷰 대기열은 두 배로 늘었다. 팀원들은 뭔가 이상하다고 느끼지만, 숫자가 좋으니 말을 꺼내기 어렵다.
이건 내가 상상한 시나리오가 아니다. AI-First 전환을 시도한 팀에서 반복적으로 목격되는 패턴이다. 그리고 그 원인을 정확하게 짚은 분석이 최근 세 방향에서 동시에 나왔다. 제약이론, 컨텍스트 인프라 부재, 프로세스 설계 실패—이 세 축을 합치면 'AI 도입 → 기대 이하 ROI'라는 실패 공식이 완성된다.
병목이 아닌 곳을 최적화하면 시스템은 느려진다
Eli Goldratt의 『The Goal』이 소프트웨어 개발 맥락에서 이토록 정확하게 들어맞을 줄은 몰랐다. andrewmurphy.io의 분석은 제약이론(Theory of Constraints)을 AI 도입 맥락에 직접 대입한다. 핵심 명제는 단순하다: 전체 처리량은 병목의 속도로 결정된다. 병목이 아닌 단계를 빠르게 만들면, 그 앞에 재고만 쌓인다.
소프트웨어 개발에서 코드 작성은 전체 프로세스의 약 20%에 불과하다. 나머지 80%는 요구사항 이해, 코드 리뷰, QA, 보안 검토, 배포 승인, 사용자 피드백 수집에서 소비된다. AI가 코드 작성 속도를 3배 높였다고 해도, 리뷰어 수가 그대로라면 리뷰 대기열만 3배로 늘어난다. 맥락 전환이 잦아지고, 리뷰는 형식적 승인으로 전락하고, CI 실패와 재시도가 반복된다. 결과적으로 더 많은 코드가 생산되지만 실제 가치 전달은 줄어드는 역설이 발생한다.
더 무서운 건 AI가 생성한 코드의 경우 작성자조차 완전히 이해하지 못한다는 점이다. 운영 중 장애가 터졌을 때 대응 능력이 떨어지는 건 당연한 수순이다.
실제 병목은 어디에 있나
팀을 느리게 만드는 진짜 병목은 대부분 다섯 곳에 숨어 있다.
첫째, 무엇을 만들어야 하는지 모른다. 영업팀 슬랙 메시지 하나로 6주를 개발했더니 실제 사용자가 11명이었다는 사례는 웃기지 않다. AI 코딩 속도가 빨라지면 잘못된 기능을 더 빠르게 만드는 결과로 이어진다. 코드 작성 속도를 높이기 전에 '무엇을 만들지'를 명확히 하는 것이 선행되어야 한다.
둘째, 코드 작성 이후의 정체. 리뷰, QA, 배포 승인에서 수주일이 사라진다. 대기 시간이 사이클 타임을 결정한다.
셋째, 배포 공포 문화. 불안정한 테스트와 낮은 가시성으로 인해 팀이 배포를 두려워한다. 결과적으로 대규모 배치 배포가 늘고, 위험은 더 커진다.
넷째, 피드백 부재. 기능이 출시된 후 성과 검증이 없으면 다음 기능도 추측 기반으로 개발된다. 빠른 코드 생산은 '만들고, 배포하고, 모른다'의 주기를 가속할 뿐이다.
다섯째, 캘린더 병목. 회의 의존적 의사결정, 승인자 부재, 부서 간 조율 지연—한 사람의 일정이 전체 릴리즈를 막는 구조는 기술 문제가 아니라 조직 문제다. AI 도구로는 해결되지 않는다.
컨텍스트 없는 AI 도구는 고급 자동완성일 뿐이다
dev.to에서 Dave O'Dell이 지적한 '라이선스 없는 효과' 문제는 또 다른 각도에서 같은 실패를 설명한다. 50명 엔지니어에게 AI 도구 라이선스를 뿌렸더니 실제 활용률이 15~20%에 그친다. 나머지 80%는 2주 안에 기존 워크플로우로 돌아간다.
왜 그럴까? AI 도구는 컨텍스트 없이는 작동하지 않는다. 팀의 아키텍처를 모르고, 코딩 컨벤션을 모르고, 결제 서비스의 레거시 통합이 이벤트 스키마를 건드리면 무너진다는 사실을 모른다. 45분짜리 CI 파이프라인을 모르는 AI 도구가 생성한 코드는 팀의 실제 맥락과 동떨어진 결과물을 낸다. 엔지니어는 '이 도구가 우리 코드에는 안 맞는다'고 결론 내리고 포기한다.
이건 교육 문제가 아니다. 런치-앤-런, 내부 위키, #ai-tools 슬랙 채널은 이 문제를 해결하지 못한다. 컨텍스트 인프라 문제다. AI가 시니어 엔지니어처럼 코드베이스를 이해하려면, 아키텍처 문서, 코딩 컨벤션, 프로젝트별 패턴이 AI 도구에 실시간으로 연결되는 '살아있는 문서화'가 필요하다.
게이트를 늘리지 말고, 프로세스를 고쳐라
Amazon에서 AI 보조 코드가 연쇄 장애를 일으킨 후 취한 조치는 시사적이다. 위원회를 만들거나 AI 도구 사용을 동결하지 않았다. 조치는 명확했다: AI 보조 코드임을 커밋에 명시하고, 고위험 시스템(결제, 체크아웃, 재고)에 한해 시니어 엔지니어의 전담 리뷰를 의무화했다.
dev.to의 Felix Ortiz가 정리한 대로, '프로세스가 존재하지만 지켜지지 않는다면 그것은 프로세스가 아니다.' DORA 연구가 10년간 반복해서 확인한 사실도 같다—중량급 승인 프로세스는 배포 성능을 가장 강하게 저하시키는 요인이다. 더 많은 게이트가 아니라, 올바른 위치의 올바른 게이트가 필요하다.
실행 가능한 원칙은 세 가지다. 코드 이전에 의도를 정의하라. '완료'의 기준이 구체적이고 검증 가능하지 않으면 아무리 빠른 AI 코딩도 엉뚱한 것을 빠르게 만들 뿐이다. 자동화된 가드레일을 쌓아라. AI가 테스트 작성을 극적으로 빠르게 만들었다. TDD, 통합 테스트, 보안 스캔을 '언젠가'가 아니라 지금 도입할 이유가 생겼다. 인간 게이트는 최소화하되, 머지 승인은 지키라. 위원회가 아니라 변경을 이해하는 엔지니어 한 명의 명확한 책임으로 충분하다.
테크 리드가 내일 당장 해야 할 것
이론을 현장으로 가져오면 우선순위는 명확해진다.
먼저 가치 흐름을 시각화하라. 아이디어에서 배포까지 모든 단계를 나열하고, 각 단계의 대기 시간을 기록하라. 사이클 타임의 대부분은 단계 사이 공백에서 발생한다. AI 도구 도입 전에 이 지도가 없다면, 무엇을 최적화하는지도 모르는 상태에서 비용을 지출하는 것이다.
코드 라인 수와 PR 수 대신 커밋-투-프로덕션 시간을 측정하라. 병목이 아닌 단계의 생산량 증가는 의미 없는 지표다.
AI 챔피언을 만들어라. 탑다운 명령은 실패한다. 실제 프로덕션 작업을 AI로 처리해서 결과를 보여주는 엔지니어 한두 명이, 전사 교육 프로그램보다 훨씬 강한 전파력을 가진다. 교육은 푸시(push)고 챔피언은 풀(pull)이다. 풀이 항상 이긴다.
CI 파이프라인과 배포 승인 흐름을 AI 도입과 동시에 개선하라. AI가 코드 속도를 3배 높였는데 CI가 45분이고 배포 승인이 3단계라면, 병목을 코드 작성에서 다음 단계로 이동시킨 것뿐이다. 속도는 전체 파이프라인에서 복리로 작용해야 의미가 있다.
속도 착각에서 벗어나는 법
결국 핵심 메시지는 하나다. 키보드가 아니라 병목을 고쳐라.
AI 도구의 잠재력에는 낙관적이다. 테스트 작성, 반복 구현, 엣지 케이스 처리—AI가 실질적으로 도움이 되는 영역이 존재한다. 하지만 도구 도입이 프로세스 재설계를 대체할 수는 없다. AI-First 팀 리빌딩은 라이선스 구매로 시작하는 것이 아니라, 가치 흐름 분석으로 시작해야 한다.
무엇이 느린지 알고 나서 그 부분을 AI로 가속하는 것—그것이 AI-First 워크플로우 설계의 올바른 순서다. 순서가 바뀌면 대시보드는 화려하고 배포는 줄어드는 역설을 반복하게 된다.