AI 코드 리뷰 부채 측정 프레임워크: PR 점수화 5가지 신호

핵심 메시지

• AI 코딩 에이전트는 코드와 PR을 빠르게 만들어내지만, 사람이 같은 속도로 책임감 있게 검토하기는 불가능하다. 이 격차가 '리뷰 부채(review debt)'다.
• PR 수, PR 크기, 병합 시간 같은 지표는 대부분 '허영 지표'일 뿐이며, 신뢰가 쌓이는 속도는 알려주지 않는다.
• 리뷰 부채는 5개 신호 계열(변경 규모·결합도, 테스트 증거 격차, 디렉터리·소유권 확산, AI 저작 표시, 증거·근거 격차)로 측정하며, 각 계열은 LLM 없이 결정론적으로 계산한다.
• 다섯 신호를 합쳐 PR마다 0~100점을 매기고, 점수 구간에 따라 필요한 검토 강도를 정한다.
• 핵심은 도구가 아니라 습관이다. PR 하나에 논리적 변경 하나, 코드가 '해야 할 일'을 검증하는 테스트, 단일 소유 영역 유지 같은 규율을 지키는 것이다.

쉽게 이해하기

이 발표는 AI Engineer 컨퍼런스에서 eBay 소프트웨어 엔지니어 사친 굽타가 소개한 'ReviewDebt' 프레임워크를 다룬다. 발표자는 코딩 에이전트가 나쁘다거나 속도를 못 낸다는 주장을 하려는 것이 아니라, 아무도 측정하지 않는 종류의 부채가 쌓이고 있다는 점을 지적한다.

발표에서 인용한 데이터에 따르면, GitHub의 2025년 10월 보고서에서 커밋 수는 전년 대비 25% 늘었지만 같은 기간 리뷰 활동을 대변하는 댓글 수는 27% 줄었다. 코드 생산과 코드 검토가 서로 반대 방향으로 움직인 것이다. AI 도입이 앞선 팀들을 추적한 벤치마크에서는 PR 검토 시간 중앙값이 크게 늘고, 검토 없이 병합되는 PR이 더 많아졌다고 소개한다.

발표자는 이 격차를 '리뷰 부채'로 정의한다. 에이전트가 만든 코드와, 사람이 실제로 검토하고 신뢰하고 이해한 코드 사이의 누적된 차이다. 기술 부채와 이름은 비슷하지만 복리로 불어나기 때문에 오히려 금융 부채에 가깝고, 여기서 이자는 돈이 아니라 사람의 '주의력'이라고 설명한다.

측정 방법으로는 5개 신호 계열을 제시하며, 각 계열마다 10개의 검사를 둔다. 모든 검사는 PR과 저장소만으로 결정론적으로 계산할 수 있어 LLM이 필요 없다. 발표자는 LLM을 심판으로 쓰면 점수가 모델에 따라 흔들리고, 엔지니어링 리뷰에서 정당화하기 어렵기 때문이라고 강조한다.

발표자는 세 개의 공개 저장소에서 524개의 실제 PR을 크로스 리포지토리로 스캔한 결과도 소개한다. AI 저작 비율이 5~20%로 안정적이어도 검토 부담은 크게 달라졌고, 부담을 좌우한 진짜 변수는 'PR 물량'이었다고 정리한다.

주요 인사이트

• 지표를 늘리는 것과 신뢰를 쌓는 것은 다르다. PR 하나를 일곱 개로 쪼개면 PR 수가 늘고, 리뷰어가 반박을 멈추면 병합 시간이 짧아지지만, 어느 쪽도 코드 품질이 좋아졌다는 뜻은 아니다.
• 테스트가 늘어난 것 자체는 안심의 근거가 되지 못한다. 에이전트가 만든 테스트는 코드가 '실제로 하는 일'을 고정할 뿐, 코드가 '해야 할 일'을 검증하지 못해 버그까지 함께 굳어질 수 있다.
• 여러 팀의 파일에 걸친 PR은 조정 비용이 크다. 3시간 만에 생성된 변경이 여러 검토자의 주의를 요구하며, 그 주의력 비용이 곧 리뷰 부채의 경제적 실체다.
• AI 저작 표시(공동 저자 푸터, 브랜치 이름 패턴 등)는 비난용이 아니라 정보용 신호로 쓰인다. 발표자의 데이터에서 AI 표시가 점수에 기여한 비중은 작았고, 대부분의 부담은 변경 규모와 테스트 누락에서 나왔다.
• 도입은 단계적으로 한다. 최근 병합된 PR 200개에 역순으로 점수를 매겨 팀 경험에 맞게 가중치를 조정하고, 임계값을 정하고, 점수를 PR 댓글로 '차단 없이' 노출하며, 팀별 추세의 기울기를 회고에서 이야기하는 흐름이다.

자주 묻는 질문

관련 AI 소식