'AI가 개발 생산성을 높인다'는 말은 이제 거의 공리처럼 쓰인다. 그런데 나는 이 문장을 들을 때마다 묻고 싶어진다. 누구의 생산성인가? 어느 단계의 생산성인가? 코드를 생성하는 속도가 빨라졌다는 사실과, 좋은 소프트웨어가 더 빠르게 만들어진다는 사실은 전혀 다른 이야기다.
최근 세 편의 글이 이 질문에 각자의 방식으로 답하고 있다. 한 달간 Cursor, GitHub Copilot, Claude Code를 실무에 투입한 비교 실험(dev.to), Claude Code 도입 전후 8개월 커밋 데이터 분석(dev.to), 그리고 AI 코드가 시니어 리뷰어의 시간을 갉아먹고 있다는 현장 고백(dev.to)이다. 세 편을 나란히 읽으면 '생산성'이라는 단어 뒤에 숨어 있던 비용 구조가 선명하게 드러난다.
도구마다 빛나는 자리가 다르다
한 달간의 페어 프로그래밍 실험에서 가장 먼저 깨달은 것은, 세 도구 모두 '코드 생성'은 잘 한다는 사실이다. 차이는 그 다음 단계에서 나타났다. 실험자는 단순한 함수 구현, 디버깅, 리팩토링, 테스트 작성, 멀티파일 변경이라는 다섯 가지 실제 업무 시나리오로 도구를 평가했다.
결론부터 말하면 이렇다. GitHub Copilot은 에디터 안에서 손이 가는 부분을 빠르게 채워주는 데 탁월하다. 자동완성, 보일러플레이트, 단일 함수 구현처럼 '내가 무엇을 원하는지 이미 알고 있을 때' 가장 유용하다. Cursor는 멀티파일 변경처럼 관련 파일을 함께 보면서 인터랙티브하게 수정 범위를 조율해야 할 때 강점을 드러낸다. AI 전용 에디터 환경이 주는 맥락 통합이 핵심이다. Claude Code는 레포지토리 수준의 이해가 필요한 작업, 특히 버그의 진짜 원인이 에러가 발생한 파일이 아닌 다른 곳에 있을 때 빛을 발한다.
이 차이를 가장 극명하게 보여준 건 디버깅 실험이었다. 단순히 "이 에러 고쳐줘"가 아니라, 컴포넌트와 API 함수와 데이터 구조를 함께 넘기고 "근본 원인을 찾아줘"라고 물었을 때, Copilot은 현재 편집 중인 파일 근처에서 빠르게 답을 찾지만 원인이 다른 파일에 있으면 한계를 드러냈다. Claude Code는 데이터 흐름 전체를 추적해 크래시가 '마지막 증상'이라는 사실을 짚어냈다. 에러 메시지가 떨어진 줄이 아니라, 잘못된 데이터가 시작된 지점을 가리키는 것. 이게 실무에서 체감 차이를 만드는 지점이다.
멀티파일 피처 작업도 비슷한 패턴을 보였다. "유저 리스트에 페이지네이션을 추가하되, 기존 API 응답 포맷과 필터를 유지하고 테스트도 써줘"처럼 여러 파일에 걸친 요청을 던지면, AI가 먼저 해결해야 할 것은 코드 작성이 아니라 '어디를 바꿔야 하는가'다. 이 사전 조사 단계에서 컨텍스트를 얼마나 잘 다루느냐가 세 도구의 가장 본질적인 차이였다.
숫자가 드러낸 이면: 커밋이 4.5배 늘었다는 것의 의미
HRPulsar의 창업자 Max Berg는 9년치 커밋 히스토리를 직접 분석했다. AI 없이 9년: 하루 평균 3.8커밋. Claude Code와 함께한 8개월: 하루 평균 17커밋. 숫자만 보면 생산성이 폭발한 것처럼 보인다. 104번의 릴리스, 빠른 출시 속도. 창업자로서 코딩보다 경영에 낮 시간을 쓰는 맥락을 감안해도 인상적인 수치다.
그런데 그가 함께 공개한 다른 숫자들이 더 흥미롭다. 근무 시간 외 커밋 비율이 22%에서 36%로 올랐다. 업계 평균(Multiples 조사)도 비슷하게 19.6% 상승했다. 에이전트가 작업 제한선을 제거하자, 사람들은 더 오래 일하게 됐다. Hacker News에는 "Claude Code 중독을 어떻게 끊나"라는 글까지 올라왔다. 저녁이 되면 코드를 읽기를 멈추고 그냥 'continue'를 누르는 '바이브 코딩' 상태로 미끄러진다는 고백이다.
Berg는 이걸 이렇게 표현했다. "마찰이 하중을 지탱하고 있었다. 코드를 타이핑하는 행위가 하루 작업량을 제한했고, 코딩 전에 계획하게 했고, 이해하게 했다. 에이전트가 그 마찰을 제거했고, 아무도 그 마찰이 제한선이기도 했다는 사실을 알아채지 못했다." 생산성 도구가 자연스러운 작업 리듬의 브레이크까지 함께 제거해버린 것이다. 커밋 수가 4.5배 늘었다는 건, 그만큼 더 많이 만들었다는 뜻인 동시에 그만큼 더 오래 작업했다는 뜻이기도 하다.
리뷰어의 고통: 빠르게 생성된 코드가 느리게 검증된다
세 번째 시각은 시니어 개발자의 자리에서 온다. 주니어 개발자가 AI로 만들어온 PR을 리뷰하는 데 세 시간을 썼고, 결국 머릿속으로 전부 다시 쓴 경험. 이 고백이 데이터와 만나면 개인의 푸념이 아닌 구조적 문제가 된다.
Faros AI가 2025년 7월에 1만 명 이상의 개발자를 모니터링한 결과: PR 수 98% 증가, PR 크기 154% 증가. 그리고 리뷰 시간 91% 증가. Uplevel Data Labs는 Copilot 도입 후 PR 사이클 타임에 유의미한 변화가 없었지만 버그는 41% 더 많이 코드베이스에 들어갔다고 분석했다. Sonar의 2026년 1월 조사에서는 IT 전문가 96%가 AI 생성 코드를 완전히 신뢰하지 않는다고 답했고, 40%는 AI 코드 리뷰가 사람이 쓴 코드보다 더 많은 노력이 든다고 말했다.
Purdue 대학의 연구가 이 신뢰 문제의 뿌리를 짚는다. ChatGPT가 Stack Overflow 기술 질문 517개에 답한 결과, 52%가 사실상 틀렸다. 그러나 39%의 경우 사람들은 자신감 있게 쓰인 AI 답변을 더 믿었고 실제로 코드를 돌려보기 전엔 오류를 발견하지 못했다. 이게 핵심이다. 주니어가 틀릴 때는 망설임이 보인다. AI가 틀릴 때는 확신이 보인다. 리뷰어가 경계를 풀게 만드는 건 자신감이다.
결국 비용이 이동한 것이다
세 편의 이야기를 엮으면 하나의 패턴이 보인다. AI 코딩 도구는 코드를 작성하는 비용을 낮췄다. 그 비용은 사라진 게 아니라 다른 곳으로 이동했다. 더 오래 일하는 개발자 자신에게로, 코드를 검증해야 하는 리뷰어에게로, 그리고 빠르게 쌓이는 기술 부채로.
GitClear의 분석에서 코드 처벌(code churn, 금방 수정되거나 삭제되는 코드 비율)이 AI 이전 3.3%에서 2025년 7.1%로 두 배 이상 증가했다는 수치가 이걸 상징한다. 35년 경력의 API 에반젤리스트 Kin Lane은 "이렇게 짧은 기간에 이만큼의 기술 부채가 쌓이는 걸 본 적이 없다"고 말했다.
그렇다고 AI 도구를 쓰지 말라는 말이 아니다. 세 도구를 비교 실험한 필자도, 커밋 수가 4.5배 늘어난 창업자도, AI를 계속 쓰고 있다. 핵심은 어디에 쓰느냐다. 컨텍스트를 내가 충분히 갖고 있고 결과를 내가 빠르게 검증할 수 있는 영역에서는 AI가 실질적인 가속을 만든다. 컨텍스트를 AI에게 넘기고 결과를 무비판적으로 수용하는 순간, 비용은 숨어들기 시작한다.
실험 필자가 테스트 작성에서 얻은 교훈이 이 전체를 압축한다. "이 함수의 테스트를 써줘"가 아니라 "아래 명세된 기대 동작을 기준으로 테스트를 써줘. 현재 구현이 맞다고 가정하지 마"로 프롬프트를 바꿨을 때 결과가 달라졌다. AI에게 무엇을 위임하느냐가 아니라, 어떤 맥락과 제약을 함께 넘기느냐가 도구의 실제 생산성을 결정한다.
속도가 아닌 맥락의 싸움. AI 코딩 도구가 정말 생산성을 높이는지는, 근무 시간 외 커밋 비율을 확인하기 전엔 알 수 없을지도 모른다.