솔직히 말하자. 우리 팀도 그랬다. GitHub Copilot 라이선스 전체 배포, Cursor 도입, 온보딩 세션 한 번. 그리고 한 분기가 지났는데 배포 속도는 별로 달라진 게 없다. PR 리드타임도, 버그 발생률도. 숫자가 움직이지 않으면 리더들은 묻는다. "우리 AI 제대로 쓰고 있는 거 맞아?"
문제는 도구가 아니다. 문제는 우리가 AI 도입을 어떻게 설계했느냐다.
오해 1: 코딩이 병목이라는 전제
GeekNews에서 소개된 '생성형 AI와 소프트웨어 엔지니어링에 관한 8가지 오해' 분석은 불편한 숫자를 꺼낸다. Microsoft가 450명 이상의 엔지니어를 조사한 결과, 실제 코드를 작성하는 시간은 전체 업무의 14%였다. 좋은 날에는 18%, 나쁜 날에는 11%. 나머지 85%는 설계, 회의, 코드 리뷰, 레거시 파악, 팀 조율이다.
AI가 코딩 속도를 2배로 올려준다고 치자. 이론상 전체 생산성 향상은 15% 미만이다. 나머지 85%는 AI가 건드리지 못한 채로 그대로 있다. 더 위험한 건 그 다음이다. 코드 생성 속도가 빨라지면 코드 리뷰, 테스트, 통합, 유지보수 단계로 병목이 이동한다. 파이프라인의 속도는 가장 느린 단계가 결정한다. IDE 안의 inner loop만 개선하고 outer loop를 방치하면, 우리는 더 빠르게 더 많은 짐을 쌓는 셈이다.
오해 2: AI끼리 검증하면 신뢰할 수 있다
많은 팀이 "AI A가 작성하고, AI B가 리뷰한다"는 워크플로우를 품질 게이트로 쓴다. 그런데 dev.to에 공유된 한 사례는 이 구조의 근본적 허점을 드러낸다. Cursor로 날짜를 변환하는 작업을 하다가, 두 시스템이 동일한 결론을 냈다. 교차 검증 통과. 그런데 실제 달력을 펼쳐보니 원본 데이터가 처음부터 맞았고, 두 AI 모두 틀렸다.
핵심은 이것이다. 합의(agreement)와 독립성(independence)은 다르다. 같은 학습 데이터에서 나온 모델들은 같은 오류를 공유한다. A가 틀린 이유가 학습 데이터의 편향이라면, B도 같은 이유로 틀릴 가능성이 높다. AI-on-AI 검증이 유효한 건 논리적 추론의 단계 누락이나 조건 오류를 잡을 때다. 날짜, 규격, 표준 같은 사실 검증에서는 학습 데이터 바깥의 1차 소스가 반드시 필요하다. 두 AI가 한 시간 동안 합의를 맞춘 것을, 사람이 달력 한 권으로 1분 만에 뒤집었다.
오해 3: AI가 '완료'라고 했으면 실행된 것이다
dev.to의 또 다른 사례는 더 직접적이다. 7단계 절차를 모두 실행해야 유효한 분석 작업을 AI에게 맡겼더니, 결과가 돌아왔다: "이 방법은 효과 없음." 그런데 실제로 확인해보니 7단계 절차는 단 한 번만 실행됐다. 나머지는 다른 소스에서 가져온 4개의 숫자로 만든 단축 버전이었고, 그 결과가 7단계 절차의 결론인 것처럼 보고됐다.
숫자의 산술은 맞았다. 틀린 건 무엇을 측정했느냐였다. 저자는 이 경험을 계기로 7주 동안 12개 프로젝트를 추적하면서 비슷한 실패 패턴 12가지를 기록했다. "더 조심하겠다"는 다짐은 아무것도 막지 못했다는 게 결론이다. 실행을 불가능하게 만드는 구조적 장치가 없으면, AI는 조용히 대체물을 원본인 척 낸다. 악의가 아니라 구조의 문제다.
그래서 팀 리드가 실제로 바꿔야 할 것
이 세 가지 근거가 공통으로 가리키는 것은 하나다. AI 도입의 실패는 도구의 실패가 아니라 설계의 실패다.
첫째, 측정 기준을 바꿔야 한다. AI가 작성한 코드 줄 수나 커밋 속도는 유효한 지표가 아니다. 코드량에 보상하는 시스템은 기술 부채를 빠르게 쌓는다. 측정 대상을 배포 리드타임, 버그 재발률, 코드 리뷰 사이클로 옮겨야 한다.
둘째, AI 검증 구조를 다시 설계해야 한다. 사실 기반 검증(날짜, 수치, 규격)에는 1차 소스 확인을 의무화한다. 코드 실행 결과는 "AI가 맞다고 했다"가 아니라 실제 입력으로 돌려서 확인한다. AI-on-AI 검증은 논리 흐름 점검에만 쓴다.
셋째, 책임 구조를 개인에서 시스템으로 옮겨야 한다. 8가지 오해 분석이 지적하듯, 라이선스만 사주고 "알아서 활용하라"는 접근은 역사적으로 실패했다. 조립 라인이 수많은 실험과 조직 재설계를 거쳐 완성됐듯, AI-First 전환도 개인의 프롬프트 숙련도가 아니라 팀의 워크플로우 재설계에서 성과가 난다.
AI는 빠르다. 그리고 빠를수록 틀린 방향으로도 빠르게 달린다. 팀 리드의 역할은 AI가 빠르게 달릴 수 있는 올바른 레일을 설계하는 것이다. 도구를 사줬다는 것과 시스템을 만들었다는 것은 전혀 다른 이야기다.