Claude Code와 Cursor가 우리 팀의 생산성을 실제로 얼마나 변화시켰는지 측정해 보았습니다

저는 AI가 우리 회사의 프론트엔드 개발 (Frontend Development)에 어떤 영향을 미쳤는지 평가해 보고자 했습니다. 저희의 모든 프로젝트 7개와 업무에 AI를 사용하는 개발자 5명을 조사했습니다. 전반적인 느낌은 코드를 더 빠르게 작성하기 시작했다는 것이었습니다. 하지만 그것은 단지 느낌일 뿐이었고, 저는 확인 혹은 반증을 원했습니다. 경영진은 AI가 얼마나 멋진지에 대해 매우 기뻐하고 있으며, 심지어 우리에게 Cursor와 Claude Code에 대한 기업용 액세스 권한까지 부여했습니다. 그들은 모든 전사 회의 (All Hands meeting) 때마다 이 이야기를 꺼내는 것을 좋아하지만, AI 도입이 사용자에게 유용한 코드를 배포하는 양에 실제로 어떤 영향을 미쳤는지에 대한 증거를 보여준 사람은 아무도 없었습니다.

지표 (Metric)
지표를 위해, 저는 단순히 작성된 코드의 양을 측정하기로 결정했습니다. 이것이 다소 투박하다는 것은 알고 있지만, 그렇지 않고 객관적으로 이를 측정할 방법을 찾지 못했습니다 (댓글로 제안을 환영합니다).

방법론 (Methodology)
네 개의 6개월 기간을 설정했습니다:

• 최근 6개월 (2025-10-01 → 2026-03-31) — 대부분의 개발자가 Cursor 및 Claude Code와 같은 도구를 활발하게 사용했습니다.
• 그 이전 6개월 (2025-04-01 → 2025-09-30) — 도구들을 사용했지만, 그렇게 활발하지는 않았습니다.
• 또 다른 6개월 전 (2024-10-01 → 2025-03-31) — 이 시기는 주로 LLM (Large Language Model)과 채팅하는 수준이었습니다. 콘솔에서 Claude Code를 실행하는 것과는 거리가 멀었으며, 모델들도 오늘날보다 현저히 성능이 낮았습니다.
• 또 다른 6개월 전 (2024-04-01 → 2024-09-30) — ChatGPT 3.5–4o 시대였으며, 누군가 코딩을 위해 AI를 사용했다 하더라도 채팅 모드에서 분리된 코드 조각 (snippets)을 위해서만 사용했습니다. 이 마지막 기간이 기준점 (baseline) 역할을 합니다.
  더 과거로 거슬러 올라가는 것은 가치가 없어 보였습니다.

코드 측정 시 주의사항 (Caveats in Counting Code)
작성된 코드의 양을 비교하지만, 몇 가지 주의사항이 있습니다:

• 자동 생성된 파일 (Auto-generated files). package-lock.json, 테스트 모크 (test mocks), 벤더링된 브랜딩 의존성 (vendored branding dependencies) 등은 제외해야 합니다.
• 단위 테스트 (Unit tests). 우리가 AI를 통해 더 많은 단위 테스트를 작성하기 시작했다는 실제 관찰 결과가 있습니다. 사실, 이제는 그것이 우리가 테스트를 작성하는 유일한 방법입니다. 물론 테스트는 훌륭하지만, 최종 사용자에게 중요한 것은 테스트가 아니라 제품 코드 (product code)입니다.

따라서 깔끔한 실험을 위해, 테스트는 비교 대상에서 제외해야 합니다 (테스트를 포함한 수치도 아래에 별도로 기재하겠습니다). 문서화 (Documentation). 우리는 또한 AI를 위한 계획과 온갖 종류의 지침 및 스킬 파일 (skill files)을 포함하여 더 많은 문서를 작성하기 시작했습니다. 이 코드/텍스트는 사용자에게 배포되지 않으므로, 이 또한 제외합니다. 노이즈 (Noise). 합리적으로 깨끗한 데이터셋을 얻기 위해서는 새로운 린터 (linter)/포맷터 (formatter) 규칙을 적용하는 커밋, 자동 생성된 코드의 실수로 인한 포함, 대규모 코드 이동, 연속적인 되돌리기 (reverts), 그리고 이와 유사한 온갖 종류의 쓰레기들을 제거해야 합니다. 개발자 수 고려하기. 반기별 수치를 비교하기 전에 한 가지를 더 처리해야 합니다. 단순히 개발자 수가 늘어났거나, 새로 온 사람들이 우연히 코드를 더 많이 작성하기 때문에 코드를 더 많이 작성하게 된 것이라면 어떻게 할까요? 우리의 경우, 지난 기간 동안 팀의 인원수가 실제로 증가했습니다 (AI가 우리 모두를 대체할 것이라고 주장하는 모든 분께 경의를 표하며). 따라서 비교 대상 코호트 (cohort)에는 지난 2년 동안 회사에 재직 중이었으며, 업무에 AI를 확실히 사용하는 사람들만 포함됩니다. AI에 대해 상당히 미온적이고 드물게 사용하는 직원들도 있는데, 이들은 계산에서 제외되었습니다. 미리 스포일러를 하자면, 5명의 개발자 중에는 업무에 AI를 사용하지만 지난 2년 동안 수치가 전혀 변하지 않은 사람이 두 명 있습니다. 그들은 쓸 것을 썼고, 여전히 같은 양을 쓰고 있습니다. 이것을 어떻게 해석하든 사실은 이렇습니다: 누군가에게 전자레인지를 주어서 음식을 데우는 데 드는 시간이 줄어들었다고 해서, 그들이 음식을 더 많이 먹기 시작한다는 뜻은 아닙니다. 어쩌면 이 사람들은 AI가 코드를 작성해 주는 동안 그냥 더 많이 쉬고 있는 것일지도 모릅니다. 또는 애초에 코드 생성 속도가 그들의 업무에서 병목 현상 (bottleneck)이 아니었을 수도 있습니다. 지표 (Metric)로는 전체 그룹의 작업일당 평균 코드량을 사용할 것입니다. 도구 (Tool). 이 모든 것을 위해 우리는 JetBrains IDE용 Git Insight 플러그인을 사용할 것입니다. 이 플러그인은 설명된 모든 기능을 수행할 수 있습니다.

데이터 준비
첫 번째 단계는 모든 대규모 기능 브랜치(feature branches)를 하나의 통합 브랜치(integration branch)로 병합하는 것입니다. 마침 저희 프로젝트에는 대규모 기능들이 몇 달 동안 개발되어 온 두 개의 기능 브랜치가 있는데, 통계가 왜곡되지 않도록 이 코드들도 반드시 포함하여 계산해야 합니다.

단계별 절차

1. 원치 않는 파일 확장자 제거
   플러그인을 열고 Project Statistics 탭으로 이동하여 파일 확장자 목록을 확인한 뒤, 통계에 포함되지 않아야 할 것들을 제외하십시오. 통계에 포함될 이유가 없는 XML 파일들이 즉시 눈에 띌 수도 있습니다. 이러한 파일들은 컨텍스트 메뉴(우클릭)를 통해 통계에서 바로 제거할 수 있습니다.

2. 의심스러운 대용량 파일 찾기
   확장자 목록을 훑어보며 각 항목을 상세히 확인(더블 클릭)하십시오. 크기순으로 정렬하여 의심스러울 정도로 큰 파일이 있는지 확인합니다. 프로젝트마다 다르겠지만, 저희의 경우 단위 테스트(unit tests)를 위해 자동으로 생성된 mock.json 파일들이 있었습니다. 이들은 통계에 포함되기를 원치 않습니다. 이 파일들은 동일한 컨텍스트 메뉴에서 하나씩이 아니라 글로브 패턴(glob patterns)을 사용하여 제거할 수 있습니다.

3. 폴더 및 파일 제외
   기본적으로 플러그인은 .gitignore에 이미 포함된 파일들과 package-lock.json, 아카이브(archives), 이미지와 같은 일부 파일들을 계산하지 않습니다. 하지만 프로젝트에 따라 라이브러리 코드가 포함된 브랜딩 의존성(branding dependencies) 폴더처럼 제외하고 싶은 폴더가 있을 수 있습니다. Settings 탭으로 이동하여 해당 파일/폴더를 제외하기 위한 글로브 패턴을 추가하십시오.

4. 의심스러운 커밋 처리
   Developer Statistics → Suspicious commits로 이동하십시오. 이 뷰는 플러그인이 의심스럽다고 판단하는 커밋들을 수집합니다. 즉, 너무 크거나, 포맷터(formatter)를 실행한 것처럼 보이거나, 되돌리기(reverts)인 커밋 등이 해당됩니다. 이 목록을 검토하는 것은 정말 가치가 있습니다. 통계에서 커밋 전체를 제외하거나, 커밋 내부의 개별 파일/폴더를 제외할 수 있습니다. 이 단계를 건너뛰지 마십시오! 저희 프로젝트 중 하나에서 새로운 ESLint 규칙 세트를 적용하는 커밋 체인을 발견한 적이 있습니다. 하나의 커밋, 그 되돌리기, 또 다른 커밋, 다시 또 다른 되돌리기, 그리고 마지막으로 새로운 커밋이 이어졌는데, 총 200,000라인의 변경 사항이 발생해 있었습니다.

저는 통계에서 이 모든 것들을 제거했습니다. 차트에서 이상 징후가 있는 막대를 클릭하여 해당 기간의 커밋을 살펴볼 수도 있습니다. 그러면 아마도 제외할 만한 다른 무언가를 찾을 수 있을 것입니다.

5. 설정(Settings)에서 테스트(Tests) 및 문서(Docs) 파일 카테고리 생성
   테스트와 문서를 포함한 경우와 포함하지 않은 경우의 통계를 모두 볼 수 있어야 합니다. 카테고리는 이름과 파일에 매칭되는 글로브 패턴(glob patterns)으로 구성됩니다. 저희 프로젝트의 경우, 테스트는 다음과 같습니다:
   *.spec.[tj]s
   *.spec.[tj]sx
   *.test.[tj]s
   *.test.[tj]sx

문서의 경우:
*.md

6. 첫 번째 결과
   우리가 얻은 결과는 다음과 같습니다:

전체 코드:
테스트와 문서가 없는 코드:

타임라인을 5명의 개발자가 모두 회사에 재직 중이었던 2023년까지 확장했습니다. 차트로 판단하건대, 전반적인 추세는 긍정적입니다. 남은 것은 실제 수치를 살펴보는 것입니다. 또한 처음 2년 동안 우리 개발자들이 상당히 안정적인 양의 코드를 생산했다는 것을 볼 수 있는데, 이는 적어도 이 방법론이 유효하다는 간접적인 신호입니다.

7. 수치

구분	프로젝트 기본 기간	2차	3차	4차
전체 코드	+249/-100	+327/-146 (+31%/+46%)	+472/-243 (+90%/+143%)	+721/-332 (+190%/+232%)
테스트 및 문서 제외	+193/-89	+263/-119 (+36%/+34%)	+399/-222 (+107%/+149%)	+479/-283 (+148%/+218%)

8. 결론
   코드 양이 꾸준히 상승하는 명확한 추세가 있습니다. 코드 리뷰(Code review)가 개발의 병목 현상(bottleneck)이 되고 있습니다. 전반적으로, 우리는 생산된 코드 양에서 최소 2배의 증가를 얻었습니다. 어쩌면 3배에 더 가까울 수도 있습니다.

반면에, 우리가 배운 전부는 우리가 코드를 세 배 더 많이 작성한다는 사실뿐입니다. 우리는 그 코드에 대해 실제로 아는 것이 없습니다. 어쩌면 지금 기술 부채(tech debt)가 더 많아진 것일까요? 어쩌면 고객이 실제로 필요로 하지 않는 기능을 위한 코드일까요? 아니면 정말로 견고하고 유용한 코드일까요? 그것은 훨씬 더 어려운 질문이며, 객관적으로 답하기 쉬운 문제가 아닙니다.

어느 쪽이든, AI 시대에 우리는 점점 더 많은 코드를 계속 작성하고 있습니다. 그 부분은 사실입니다. 지난 몇 년 동안 개발은 극적으로 변했으며, 지난 15년 동안 우리 업계에서 이와 같은 변화를 또 다른 사례로 기억해낼 수 없습니다.

이 모든 것이 우리를 어디로 이끌지 지켜보는 것은 흥미로운 일입니다.