"AI 쓰면 빨라진다"는 믿음이 흔들리고 있다
솔직히 말할게요. 저도 처음엔 의심 없이 믿었습니다. AI 코딩 도구를 팀에 붙이면 속도가 오른다고. 그런데 METR이 올해 발표한 무작위 대조 실험(RCT) 결과를 보고 잠깐 멈췄습니다.
숙련 오픈소스 개발자들에게 최신 AI 코딩 도구를 줬더니—속도가 19% 느려졌습니다. 주니어도 아니고, 코드베이스를 처음 보는 사람도 아닙니다. 자기가 잘 아는 프로젝트에서, 자기가 고른 도구를 쓴 베테랑들이요. 그리고 그 베테랑들은 자신이 24% 빨라졌다고 느꼈습니다.
인지와 현실의 갭이 43퍼센트포인트. 가장 잘 판단할 수 있는 사람이 가장 크게 틀렸다는 게 이 연구의 진짜 섬뜩한 부분입니다.
왜 숙련자가 더 느려지는가
이 역설의 메커니즘은 생각보다 단순합니다. 숙련 개발자의 가장 큰 자산은 암묵적 지식입니다. 어떤 패턴을 팀이 선호하는지, 저 이상한 아키텍처 결정 뒤에 어떤 역사가 있는지, 코드베이스의 어느 부분이 취약한지—이런 것들이 머릿속에 켜켜이 쌓여 있죠.
그런데 이 지식은 AI 에이전트에게 단 한 줄도 전달되지 않습니다. 숙련 개발자가 AI 도구를 아무 준비 없이 쓰는 순간, 코드베이스는 읽었지만 조직의 문화는 전혀 모르는 인턴에게 일을 맡기는 셈이 됩니다. 거기다 베테랑은 자기 판단을 믿기 때문에 생성된 코드를 꼼꼼히 검토하지 않습니다. 대략적인 형태가 맞아 보이면 승인하고 넘어갑니다.
이걸 50번 반복하면 코드베이스가 흔들립니다. 500번이면 사람도 에이전트도 방향을 잃습니다.
처방 1: 암묵지를 파일로 만들어라—AGENTS.md
문제의 근원이 명확해지면 해법도 명확합니다. 암묵적 지식을 명시적 문서로 바꾸는 것. METR 연구를 분석한 한 컨설턴트는 AI 도구를 전면 도입했지만 버그가 세 배로 늘어난 팀과 함께 딱 하나의 파일을 만들었습니다—AGENTS.md.
이 파일은 프롬프트가 아닙니다. 프레임워크도 아닙니다. 완벽한 기억력을 갖고 있지만 조직의 역사는 전혀 모르는 동료를 위한 온보딩 문서입니다. 기술 스택, 도메인 용어 정의, 코딩 컨벤션, 에이전트가 자주 저지르는 실수 목록—이것들을 리포 루트에 두면 에이전트의 출력 품질이 즉시 달라집니다.
예를 들어 보험 청구 처리 백엔드라면 이런 내용이 들어갑니다: "claim은 case도 ticket도 아니다", "상태 머신을 절대 우회하지 마라", "Express 미들웨어를 추가하려 하는데 우리는 Fastify다". 사람 신입에게 당연히 알려줄 것들인데, AI에게는 지금까지 아무도 알려주지 않았던 거죠.
이를 체계화한 스타터 리포(dev-starter-kit)는 한 걸음 더 나아갑니다. AGENTS.md(범용), CLAUDE.md(Claude Code 세션용), .cursor/rules/*.mdc(파일 타입별 스코프), .github/copilot-instructions.md까지—주요 AI 도구 각각에 맞는 컨텍스트 파일을 세트로 제공하고, CI/CD 워크플로우와도 연동됩니다. AI 도구가 생성한 코드가 CI를 통과하도록 도구와 파이프라인이 같은 기준을 바라보게 만드는 설계입니다.
처방 2: "빠름"이 아니라 "완성"을 측정하라
AI ROI를 측정해온 개발자들의 공통된 고백이 있습니다. "AI가 나를 빠르게 만들어준다고 생각했는데, 메트릭이 동의하지 않았다."
코드가 나오는 속도는 분명히 빨라집니다. 그런데 검증 비용이 함께 올라갑니다. 출력을 신뢰하기 어려워서 더 꼼꼼히 읽고, 컨벤션에 맞추려고 추가 프롬프트를 날리고, 뭔가 이상한 느낌에 테스트를 더 돌리고, 불필요하게 큰 diff를 정리하는 커밋이 쌓입니다. 타이핑은 줄었지만 배포는 더 늦어지는 역설이 생깁니다.
실제로 의미 있는 메트릭은 이 네 가지입니다:
- 리드 타임: 티켓 시작 → 배포 완료
- 리워크 타임: AI 초안을 고치는 데 쓴 시간
- 결함 탈출률: 머지 후(특히 7일 이내) 발견된 버그
- 리뷰 부담: 변경 사항을 검증하는 데 쓴 인간의 시간
여기서 핵심 통찰이 하나 있습니다. "AI는 한 명의 개발자를 빠르게 느끼게 만들면서 나머지 팀원을 느리게 만들 수 있다." 리뷰 부담이 팀 전체로 퍼지면 개인의 체감 속도 향상이 팀 전체의 속도 저하로 전환됩니다.
처방 3: AI 리뷰어에게 승인권을 주지 마라
AI 코드 리뷰 도구를 시니어 엔지니어처럼 대우하는 실수가 많습니다. AI 리뷰어는 무한한 자신감을 가진 주니어에 가깝습니다—패턴 매칭은 탁월하지만 도메인 로직의 깊이, 성능 현실(N+1, 쿼리 동작), 보안 경계, 아키텍처 적합성은 놓칩니다.
효과적인 원칙은 간단합니다: 에이전트는 승인하지 않는다. 에이전트는 잡일을 한다. null 체크 누락 지적, 불일치 패턴 발견, 누락 테스트 제안, diff 요약—여기까지는 탁월합니다. 빌링 규칙이 맞는지, 이 컴포넌트가 여기 있어야 하는지는 사람이 판단해야 합니다.
그리고 AI가 나쁜 출력을 냈을 때 패치로 때우는 행동을 멈춰야 합니다. 90%는 맞으니까 나머지 10%만 고치자는 유혹이 강렬하지만, 그 10%의 오류가 코드베이스에 영구히 남습니다. 그리고 그 코드베이스가 다음 에이전트 실행의 컨텍스트가 됩니다. 품질은 위로 가거나 아래로 가거나 둘 중 하나—중간 상태는 없습니다.
나쁜 출력이 나오면 멈추고 진단하세요. 스펙이 모호했나? AGENTS.md에 빠진 컨벤션이 있나? 에이전트의 범위가 너무 넓었나? 근본 원인을 고친 뒤 처음부터 다시 돌리는 게 훨씬 효율적입니다.
처방 4: 코드 전에 계획을 리뷰하라—Patch Letter 패턴
한 가지 더. AI에게 코드를 바로 짜달라고 하기 전에, 패치 레터(Patch Letter)를 먼저 받는 습관이 효과적입니다. PR 커버레터처럼—무엇이 바뀌는지, 어떤 파일을 건드리는지, 무엇을 건드리지 않는지, 리스크는 무엇인지, 테스트 계획은 무엇인지를 코드 없이 텍스트로 먼저 받는 겁니다.
계획이 리뷰 가능해지면 실행 전에 방향을 바로잡을 수 있습니다. AI 코딩 실패의 대부분은 모델 품질 문제가 아니라 계획 실패입니다. 문제가 충분히 구체화되기 전에 코드 작성이 시작되는 거죠. 패치 레터 하나가 리뷰 시간을 아끼고 예상치 못한 리팩토링을 막습니다.
시사점: AI-First는 도구 도입이 아니라 워크플로우 재설계다
이 모든 연구와 실전 경험이 가리키는 방향은 하나입니다. AI 도구를 기존 워크플로우에 그냥 얹으면 숙련자의 암묵지가 오히려 부채가 된다. 이것이 METR 결과의 진짜 의미입니다.
AI-First 팀 리빌딩에서 제가 강조하는 것도 이겁니다. 도구 선택보다 먼저 해야 할 일은 팀의 암묵지를 명시적 문서로 끄집어내는 것, 생산성 지표를 체감 속도가 아닌 리드 타임과 결함 탈출률로 재정의하는 것, AI 리뷰어의 권한 범위를 명확히 하는 것입니다.
아이러니하게도 이건 수십 년 전부터 엔지니어링 매니저들이 팀에 요청해온 것들입니다—문서 써라, 컨벤션 정의해라, 코드 리뷰 기준 세워라. AI는 그 숙제를 더 이상 미룰 수 없게 만들었습니다. 문서화와 코드베이스 위생이 이제 팀 문화의 문제가 아니라 AI 에이전트 출력 품질의 직접 변수가 됐으니까요.
전망: 측정하지 않으면 개선할 수 없다
앞으로 AI 코딩 도구의 ROI는 팀마다 극명하게 갈릴 겁니다. 준비된 팀—AGENTS.md가 있고, 코드베이스가 일관되고, 메트릭으로 실제 속도를 측정하는 팀—과 그렇지 않은 팀 사이의 격차가 벌어질 것입니다.
"AI 쓰면 빨라진다"는 믿음은 절반만 맞습니다. 정확한 문장은 이겁니다: 준비된 코드베이스와 올바른 워크플로우 위에서, AI는 팀을 빠르게 만든다. 그 준비를 건너뛰면 METR이 측정한 19% 속도 저하가 여러분 팀에도 재현됩니다—아마 팀원들이 24% 빨라졌다고 느끼면서.