품질을 희생한 속도: 오픈소스 프로젝트에서 Cursor AI 사용에 관한 연구 (2025)

Who Should Read

AI 코딩 도구(Cursor, Claude Code 등)를 팀에 도입했거나 도입을 검토 중인 개발자 또는 엔지니어링 매니저. 특히 코드 품질 관리 프로세스를 어떻게 가져가야 할지 고민하는 사람에게 유용하다.

Core Mechanics

• 이 연구는 Cursor AI 도입이 개발 속도와 소프트웨어 품질에 미치는 인과적 영향을 측정했다. GitHub에서 Cursor를 도입한 프로젝트 806개를 Cursor를 쓰지 않는 유사 프로젝트 그룹과 비교하는 '차이의 차이(difference-in-differences)' 설계를 사용했다.
• Cursor를 도입하면 프로젝트 수준의 개발 속도가 통계적으로 유의미하게 크게 올라가지만, 이 효과는 일시적(transient)이다. 즉, 초반에는 빠르게 치고 나가지만 그 효과가 오래 지속되지 않는다.
• 반면 정적 분석 경고(SonarQube로 측정)와 코드 복잡도(cyclomatic complexity 등)는 Cursor 도입 후 상당히 그리고 지속적으로 증가했다. 일시적인 속도 이득과 달리 품질 저하는 계속 남아있는 것이다.
• 패널 GMM(Generalized Method of Moments, 패널 데이터에서 인과관계를 추정하는 통계 기법) 분석 결과, 정적 분석 경고 증가와 코드 복잡도 상승이 장기적인 개발 속도 감소의 주요 원인으로 밝혀졌다. 결국 초반에 빌린 속도를 나중에 기술 부채로 갚는 구조다.
• 연구 데이터는 2024년 1월부터 2025년 3월 사이에 Cursor를 도입한 프로젝트를 대상으로 했고, 분석 시점은 2025년 8월이다. 즉, 비교적 초기 Cursor 사용자들의 데이터이며 최신 모델의 행동을 반영하지 않는다.
• 연구진은 품질 보증(Quality Assurance)이 Cursor 초기 도입자들의 주요 병목이라고 결론 내리며, QA가 AI 코딩 도구와 AI 기반 워크플로우 설계에서 '일등 시민(first-class citizen)'이 되어야 한다고 주장했다.
• 흥미롭게도 코드 중복(duplication) 지표는 유의미한 증가를 보이지 않았다. 연구진은 인간에게 기술 부채인 것이 에이전트에게는 오히려 유리할 수 있다는 점도 언급했다. 예를 들어 의존성 라이브러리 코드를 재사용하는 것보다 코드를 새로 써서 에이전트가 직접 볼 수 있게 하는 게 더 나을 수도 있다.

Evidence

• 데이터 시점이 2025년 8월이라는 점을 들어 연구의 시의성에 의문을 제기하는 댓글이 많았다. '2025년 4월 데이터면 지난 세기 얘기나 마찬가지'라는 반응도 있었고, 연구 대상 기간(2024년 1월~2025년 3월)은 코딩 에이전트 능력이 지금보다 훨씬 낮았던 시절이라 결과가 당연하다는 의견도 있었다.
• 코딩 에이전트가 복잡도를 높이는 건 맞지만 동시에 그 복잡도를 다루는 비용도 크게 낮춘다는 흥미로운 반론이 있었다. 모듈이 감당하기 어려울 만큼 복잡해지면 Claude에게 질문하고, 테스트와 스크립트를 작성하게 해서 동작을 실증하고, 최악의 경우 해당 코드를 통째로 갈아엎고 더 나은 것으로 교체하는 데 예전보다 훨씬 적은 시간이 든다는 실사용 경험이 공유됐다.
• 속도를 코드 라인 수(LoC)로 측정한 방법론에 대한 비판도 있었다. AI가 생성한 코드는 인간이 작성한 코드보다 훨씬 verbose(장황)한 경향이 있는데, LoC가 같은 문제를 같은 줄 수로 해결한다고 가정한다면 연구 전제 자체가 흔들린다는 지적이었다. 또한 LoC 자체가 속도의 신뢰할 만한 지표가 아니라는 것은 개발자들 사이의 상식이라는 의견도 있었다.
• SonarQube 경고가 프로젝트에 통합되지 않아 에이전트에게 피드백으로 전달되지 않았다는 점이 중요하다는 댓글이 있었다. 만약 이 경고들이 에이전트에게 실시간으로 전달됐다면 에이전트가 자동으로 수정했을 가능성이 높다는 것이다. 또한 AI는 기존 품질 보증 프로세스의 증폭기(amplifier)라는 DORA 2025 연구와의 연결을 지적하며, 피드백 루프와 검증 루프가 더욱 중요해졌다고 강조했다.
• 전통적인 개발 방식(빌드→테스트→리팩토링→커밋)과 달리 AI 지원 개발은 AI 생성→테스트→바로 커밋하는 경향이 있다는 의견이 있었다. Clean Coder에서도 먼저 지저분하게 짜고 나중에 정리하는 방식을 권장하는데, AI 보조 코딩에도 이 전통적인 방법을 그대로 적용해야 한다는 주장이었다.

How to Apply

• Cursor나 GitHub Copilot 같은 AI 코딩 도구를 팀에 도입했다면, SonarQube나 ESLint 같은 정적 분석 도구를 CI/CD 파이프라인에 통합하고 그 경고를 에이전트의 컨텍스트(예: AGENTS.md, .cursorrules)에 포함시켜라. 에이전트가 자신이 만든 경고를 바로 피드백받아 수정하게 하면 품질 저하를 상당 부분 막을 수 있다.
• AI가 생성한 코드를 바로 커밋하는 대신, '생성→테스트→리팩토링→커밋'의 전통적 사이클을 유지하는 팀 규범을 만들어라. 특히 PR 리뷰 시 cyclomatic complexity(코드의 분기/경로 수를 세는 복잡도 지표)나 정적 분석 경고를 체크하는 자동화 게이트를 추가하면 장기 속도 저하를 예방할 수 있다.
• AI 도구 도입 초기에 단기 속도 향상에 고무되어 QA 프로세스를 느슨하게 하지 마라. 이 연구에 따르면 속도 이득은 일시적이고 품질 저하는 지속되므로, 오히려 도입 초기에 코드 리뷰 기준을 더 엄격하게 유지하는 것이 장기적으로 팀 전체의 속도를 지키는 방법이다.
• 모듈이 AI 생성 코드로 인해 너무 복잡해진 경우, 해당 모듈에 대한 테스트와 동작 검증 스크립트를 AI에게 먼저 작성하게 한 뒤 리팩토링하거나 통째로 재작성하는 전략을 사용해라. AI 덕분에 리팩토링 비용 자체가 낮아졌기 때문에 복잡한 코드를 오래 끌고 가는 것보다 빠른 재작성이 더 효율적일 수 있다.

Terminology

Related Resources

• https://arxiv.org/abs/2511.04427
• https://dora.dev/research/2025/
• https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=LLM+code+quality