2025년 METR의 실험 결과는 불편하다. 숙련 개발자들이 AI 도구를 사용했을 때 오히려 19% 느려졌다. 더 빠른 코드 생성이 아니라, 더 느린 완성이었다. AI를 도입한 팀이 기대했던 것과 정반대의 결과다. 원인은 모델 성능이 아니었다. 비구조적이고 얕은 사용이 컨텍스트 스위칭을 늘리고, '다 된 것 같다'는 착각을 심었기 때문이다.
문제의 핵심은 여기 있다. AI 도구를 쓰는 것과 AI 도구를 잘 쓰는 것은 전혀 다른 행동이다. dev.to에 올라온 한 글은 이를 두 개발자의 대비로 정확히 짚는다. Developer A는 "대시보드 만들어줘"라고 프롬프트를 날리고, 에러가 나면 조용히 멈춘다. Developer B는 같은 모델을 써서 실제 배포 실패의 원인을 추적하고, 단 한 명의 유저에게라도 작동하는 최소 흐름을 찾는다. 같은 토큰, 완전히 다른 결과. 차이는 AI가 아니라 드라이빙 방식이었다.
나는 이걸 '얕은 사용의 함정'이라고 부른다. 얕은 사용은 피곤하지 않다. 그게 문제다. 계획을 하나 더 생성하고, 곧 버릴 파일을 리팩터링하고, 이미 반쯤 알던 답을 확인하는 것—이 과정이 일을 한 것처럼 느끼게 만든다. 탭을 닫을 때 뭔가 했다는 감각이 남는다. 하지만 레포에는 80% 완성된 채로 멈춘 브랜치만 쌓인다. 가장 강력한 도구로 '거의 완성'만 반복하는 것, 이것이 진짜 낭비다.
스킬 측면에서 보면 상황은 더 복잡해진다. Anthropic의 Shen과 Tamkin이 수행한 RCT(arXiv 2601.20245)는 AI 보조를 받은 그룹이 코드 이해도 퀴즈에서 17점포인트 낮은 점수를 기록했다고 보고한다. 특히 디버깅, 코드 읽기, 개념 이해—AI가 생성한 결과물을 검증하는 데 필요한 바로 그 역량들이 가장 크게 감소했다. 눈길을 끄는 건 속도 이점조차 흐릿했다는 점이다. 완전히 낯선 태스크에서 일부 참여자는 프롬프트를 구성하는 데만 전체 시간의 30%를 썼다. 익숙한 작업에서 AI는 빠르다. 새로운 것을 학습하면서 쓸 때는 오버헤드가 이득을 잡아먹는다.
이 연구가 '도om 장르'와 다른 지점이 있다. AI를 쓴다고 반드시 스킬이 줄지는 않는다는 것이다. 같은 그룹 안에서도 어떻게 사용했느냐에 따라 점수가 갈렸다. 스킬 감소는 AI 사용 자체의 결과가 아니라, 인지 참여가 없는 외주화(outsourcing)의 결과다. 계산을 덜어놓는 것(offloading)과 생각 자체를 맡기는 것(outsourcing)은 다르다. 전자는 생산성 도구이고, 후자는 역량 침식이다. 문제는 현재 대부분의 기본 워크플로우가 이 둘을 구분하도록 설계되어 있지 않다는 것이다.
테크 리드 입장에서 이걸 팀 문제로 번역하면 이렇다. AI를 도입한 팀이 느려지는 가장 흔한 패턴은 세 가지다. 첫째, 목적지 없는 운전이다. AI라는 차는 있는데 어디로 가는지 아무도 정하지 않는다. 둘째, 책임 없는 생성이다. 코드는 나오는데 그것이 실제로 작동하는지 누군가 확인하는 구조가 없다. 셋째, 완성 기준의 부재다. '거의 다 됐어'가 팀의 상태가 되고, 배포는 늘 다음 주로 밀린다. AI가 이 세 가지를 해결해주지는 않는다. 오히려 각각을 더 쉽게 방치하도록 만든다.
해결은 도구를 더 추가하는 것이 아니다. 구조를 설계하는 것이다. 구체적인 완성 조건, 실제 마감, 그리고 진행 상황을 확인하는 사람. dev.to의 글에서 소개된 30일 스프린트 방식—매일 구체적 행동 하나를 실제 사람에게 보고하는—은 과장처럼 보이지만 원리는 정확하다. AI가 90%를 하더라도, 나머지 10%는 그 90%를 제대로 쓰게 만드는 인간의 구조에서 온다. 봇이 파싱하는 로그가 아니라, 사람이 읽는 체크인이 코스팅을 막는다.
앞으로 AI 도구는 더 강력해질 것이다. 에이전트는 더 많은 것을 자동으로 처리할 것이다. 그 방향이 맞다면, 개발자에게 남는 역할은 더욱 명확해진다. 목적지를 정하고, 드라이빙 내내 핸들을 놓지 않고, 결과물이 실제로 작동하는지 판단하는 것. 이 역량들—문제 정의, 비판적 검증, 완성에 대한 집요함—은 AI가 잘할수록 더 희소해지고, 더 중요해진다. AI-First 팀이 진짜로 빨라지려면 도구보다 먼저 이 구조를 설계해야 한다. 도구는 이미 충분히 강하다. 부족한 것은 그 도구를 깊게 쓰게 만드는 팀의 설계다.