'AI 도입했더니 생산성이 올랐다'는 체감은 넘쳐난다. 그런데 All Hands 미팅에서 Cursor·Claude Code 코퍼레이트 라이선스를 자랑하는 경영진 앞에서, 개발팀 누군가가 실제로 숫자를 들고 나온 사례는 드물다. dev.to에 최근 올라온 한 프론트엔드 팀의 측정 실험이 눈길을 끄는 이유다.
측정 방법론: 조잡해도 일단 시작하라
해당 팀은 7개 프로젝트, 5명의 개발자를 대상으로 6개월 단위 4개 구간을 비교했다. 기준선(baseline)은 ChatGPT 3.5~4o 시절 스니펫 복사 정도로만 AI를 쓰던 구간이고, 가장 최근 구간은 Cursor와 Claude Code를 적극적으로 사용하는 시기다. 측정 지표는 단순히 커밋된 코드 라인 수. 저자 스스로 "조잡하다(crude)"고 인정하지만, 객관적으로 비교할 수 있는 현실적인 대안을 찾지 못했다고 솔직하게 밝힌다.
데이터를 믿을 수 있으려면 노이즈 제거가 핵심이다. 팀이 제거한 항목들을 보면 왜 대부분의 '생산성 측정'이 엉터리로 끝나는지 알 수 있다. package-lock.json, 자동 생성 목 파일, ESLint 룰셋 적용 커밋(한 프로젝트에서만 20만 줄이 잡혔다), 리버트 체인, 포맷터 일괄 적용—이것들을 걷어내지 않으면 숫자는 아무 의미가 없다. 여기에 유닛 테스트 코드와 문서도 별도 집계했다. AI 도입 이후 테스트 작성량이 급증했는데, 그게 유저에게 전달되는 프로덕트 코드 증가와 뒤섞이면 비교가 불가능해지기 때문이다.
팀 구성 변화도 통제했다. 최근 2년간 재직한 사람, AI를 실제로 활용하는 사람만 코호트에 포함했다. AI를 잘 안 쓰는 개발자는 아예 제외했다—이건 측정의 정직함이다. 전체 평균에 희석시키면 AI의 효과를 과소평가하거나 오해할 수 있다.
결과: 2~3배, 그런데 뭘 더 쓴 건지 모른다
결과는 꽤 명확하다. 베이스라인 대비 테스트·문서 제외 순수 프로덕트 코드 기준으로, 2번째 구간(AI를 간간이 쓰기 시작) +36%, 3번째 구간(LLM 채팅 적극 활용) +107%, 4번째 구간(Cursor·Claude Code 본격 사용) +148%. 전체 코드로 보면 최대 +190%까지 올라간다. 숫자만 보면 2~3배 생산성 향상이라는 주장이 수치로 뒷받침된다.
그런데 저자가 스스로 던지는 반문이 더 중요하다. "코드를 3배 더 쓴다는 사실은 알겠다. 그런데 그 코드에 대해 우리가 아는 게 없다." 기술 부채가 늘었는지, 유저가 실제로 원하는 기능인지, 품질은 괜찮은지—이건 코드 라인 수로는 전혀 알 수 없다. 그리고 또 하나의 스포일러: 5명 중 2명은 AI를 쓰는데도 코드량이 2년 전과 변함없다. AI 도구를 주면 모두가 더 많이 쓰게 된다는 가정 자체가 틀렸다.
AI ROI 측정의 진짜 병목: 코드 리뷰
팀이 꺼낸 또 다른 관찰이 있다. 코드 생산 속도가 빨라지자 코드 리뷰가 병목이 됐다. 이건 AI-First 워크플로우를 도입하려는 팀이라면 반드시 대비해야 할 구조적 변화다. 생산은 자동화됐는데 검증 레이어가 그대로라면, 속도 증가분이 곧 품질 리스크 누적으로 전환된다. 생산성 향상의 실질 상한선은 결국 리뷰 처리량이 된다.
맥락 확장: Claude가 기업 채택률에서 OpenAI를 추월한 이유
이 측정 실험이 단순한 사례 하나로 끝나지 않는 이유는, 시장 데이터가 같은 방향을 가리키고 있기 때문이다. 기업 지출 추적 플랫폼 Ramp의 최근 AI 인덱스 보고서에 따르면, 앤트로픽의 기업 채택률이 4월 기준 34.4%로 OpenAI의 32.3%를 처음 추월했다. 1년 새 4배 성장이다. VC 지원 기업과 IT 분야에서는 격차가 더 크다. Claude Code가 단순 코딩 어시스턴트를 넘어 팀 워크플로우에 깊숙이 통합되고 있다는 신호다.
세컨드 브레인으로의 확장: 측정 가능성의 한계를 넘는 활용
한편 Claude Code의 활용 방식이 순수 코딩 어시스턴트를 넘어 확장되고 있다. 솔로프리너 Noah Brier의 사례처럼, 1,500개 Obsidian 노트를 Claude Code와 연결해 '세컨드 브레인'으로 쓰는 방식이 주목받고 있다. 코드 파일을 읽는 것과 마크다운 메모를 읽는 것은 AI 입장에서 같은 원리다—파일을 읽고 맥락을 파악한다. 이 활용법은 생산성 측정의 새로운 난제를 만든다. '코드 라인 수'라는 지표로는 포착되지 않는 지식 관리, 의사결정 품질 향상, 컨텍스트 복원 시간 단축 같은 효과들이 숫자 밖에서 발생한다.
팀에 실제로 적용할 수 있는 측정 설계
이 사례에서 뽑아낼 수 있는 실용적인 교훈은 세 가지다.
첫째, 측정을 시작하기 전에 노이즈 목록을 먼저 만들어라. 자동 생성 파일, 포맷터 커밋, 대규모 리팩토링은 AI 효과와 무관하다. 이걸 섞으면 측정 자체가 무의미해진다.
둘째, 코호트를 통제하라. AI를 실제로 쓰는 사람과 그렇지 않은 사람을 섞으면 효과가 희석된다. AI 적극 활용자만을 대상으로 측정하고, 나머지는 별도 트래킹해야 도구의 효과와 개인 습관 차이를 구분할 수 있다.
셋째, 1차 지표(코드량) 옆에 2차 지표를 반드시 붙여라. 버그 발생률, 코드 리뷰 사이클 타임, 기능 완료 리드타임—이것들이 함께 움직이지 않으면 코드량 증가는 속도가 아니라 부채 누적일 수 있다.
전망: 측정의 진화가 AI-First 팀의 다음 과제다
2~3배 코드량 증가는 경영진에게 보여줄 수 있는 숫자다. 하지만 테크 리드로서 더 불편한 질문을 직면해야 한다. 코드 리뷰 병목이 생겼다면 AI 리뷰어를 붙이는 게 다음 수순이다. 리뷰 자동화 없이 생산 속도만 올리면 팀은 조만간 자기가 만든 코드의 무게에 눌린다. 그리고 AI를 써도 생산량이 변하지 않는 2명—이들의 병목이 코드 작성 속도가 아니었다는 것, 이게 AI 도입 전에 먼저 파악했어야 할 사실이다.
AI-First 워크플로우의 ROI는 '도입했더니 빨라졌다'는 감각에서 출발하지만, 그 감각을 숫자로 만드는 순간 훨씬 복잡한 질문들이 따라온다. 그 질문들을 피하지 않는 팀이, 결국 AI 도구를 제대로 쓰는 팀이 된다.