GitVelocity: 5만 건의 PR에 대한 AI 점수 분석으로 드러난 코드 복잡성 인사이트

GitVelocity 작동 방식

GitVelocity는 GitHub, GitLab 또는 Bitbucket 저장소에 연결하고 Claude(비용이 낮으면서 Opus 4.6과 거의 동등한 성능을 보이는 Sonnet 4.6을 기본값으로 사용)를 사용하여 병합된 모든 풀 리퀘스트를 분석합니다. 각 PR은 여섯 가지 차원에서 0-100점의 점수를 받습니다:

• 범위 (0-20)
• 아키텍처 (0-20)
• 구현 (0-20)
• 리스크 (0-20)
• 품질 (0-15)
• 성능/보안 (0-5)

여섯 차원의 점수를 합산한 후, 변경 크기에 따라 승수를 사용하여 조정됩니다—동일한 복잡도라도 10줄 수정은 500줄 리팩터링보다 낮은 점수를 받습니다. 전체 공식은 gitvelocity.dev/scoring-guide에서 확인할 수 있습니다.

50,000개 이상의 PR에서 얻은 주요 발견

여러 언어의 50,000개 이상의 PR 분석을 통해 몇 가지 직관에 반하는 패턴이 드러났습니다:

• 큰 PR이 자동으로 높은 점수를 받는 것은 아닙니다: 낮은 복잡도의 800줄 마이그레이션은 200줄 아키텍처 변경보다 점수가 낮습니다. 크기는 전체 승수를 제공하지만, 기본 점수는 여전히 획득해야 합니다.
• 테스트 없이는 높은 점수를 받을 수 없습니다: 품질 차원(0-15)은 테스트 커버리지 없이는 점수를 주지 않습니다. 유사한 경험 수준에서 이는 엔지니어들 사이의 가장 명확한 차이점이었습니다.
• 주니어들이 일부 시니어들을 앞지르기 시작했습니다: 그들은 AI 도구를 더 빨리 도입하고 더 어려운 문제를 해결했습니다. 자신의 점수를 볼 수 있게 되자, 그들은 더 높은 목표를 설정했습니다.
• AI 생성 코드는 사람이 작성한 코드와 동일하게 평가됩니다: 코드는 코드입니다. AI를 사용하여 더 복잡한 작업을 더 빠르게 배포하는 엔지니어는 더 생산적이며, 그들의 점수는 이를 반영합니다.

기술 구현 세부사항

점수 일관성은 가장 어려운 기술 문제였습니다. 각 차원을 고정하는 참조 예제 없이 Claude의 점수는 실행 간에 15점 이상 변동했습니다. 팀은 18개의 보정된 기준점(각 차원당 낮음/중간/높음의 세 가지)을 생성하여 이 문제를 해결했으며, 동일한 PR에서 변동을 2-4점으로 줄였습니다.

이 도구는 BYOK(자체 Anthropic API 키 사용) 모델을 사용하며 PR당 몇 센트의 비용이 듭니다. 소스 코드는 저장되지 않으며—차이점이 분석된 후 즉시 폐기됩니다.

행동 영향 및 팀 기능

팀은 'Fitbit 효과'라고 부르는 현상을 관찰했습니다—이 도구가 더 나은 코드를 배포하게 만드는 것은 아니지만, 점수를 보는 것은 그렇게 합니다. 엔지니어들은 요청 없이도 1:1 미팅에서 자신의 점수를 언급하기 시작했는데, 숫자가 그들이 이미 자신의 작업에 대해 느끼는 것과 일치했기 때문입니다.

모든 점수는 PR을 작성한 엔지니어에게 완전히 공개되며, 차원별 분석과 근거가 제공됩니다. 관리자가 보고 엔지니어가 보지 못하는 숨겨진 대시보드는 없습니다.

GitVelocity는 최근 팀 벤치마크(gitvelocity.dev/demo/benchmarks)를 추가했습니다. PR을 평가하기 시작하면, 데이터셋 전체에서 다른 팀과 비교하여 팀의 성과를 볼 수 있습니다—현재 약 60개 팀의 1,000명 엔지니어가 포함되어 있습니다. 개인 점수에 회의적이었던 팀들도 필드에서 자신을 측정할 수 있게 되자 진정한 호기심을 보였습니다.