코드를 여러 번 고치고 다시 살펴보는 과정을 AI가 얼마나 잘 따라가는지 시험하는 자료집을 만든 연구입니다.

코드를 여러 번 고치고 다시 살펴보는 과정을 AI가 얼마나 잘 따라가는지 시험하는 자료집을 만든 연구입니다.

무엇이 문제였나 — 기존 시험은 대개 코드 변경을 한 번 보고 문제를 찾는 방식이었습니다. 어떻게 풀었나 — 이 연구는 실제 코드 변경과 검토 기록을 여러 차례 이어 붙이고, 문제마다 새로 발견됐는지, 남아 있는지, 해결됐는지 표시했습니다. 그래서 뭐가 좋아졌나 — 시험 결과, AI는 앞서 나온 문제를 잊거나 이미 해결된 문제를 다시 문제라고 말하는 경우가 있었습니다.

수리 기록을 보며 고장 난 곳이 고쳐졌는지 확인하는 것과 비슷합니다. 이 시험은 코드의 문제마다 처음 발견된 때와 이후의 수정 기록을 함께 보여 주고, AI가 문제의 변화를 제대로 따라가는지 살펴봅니다.

논문 정보

Dewu Zheng, Yanlin Wang, Xiwen Wang, Kefeng Duan, Hongyu Zhang, Xilin Liu, Yuchi Ma, Zibin Zheng · Sun Yat-sen University; Chongqing University; Huawei Cloud Computing Technologies Co., Ltd. · Proceedings of the ACM on Software Engineering (Proc. ACM Softw. Eng.), ISSTA · 2026

왜 중요한가

실제 코드 검토는 문제를 찾고, 코드를 고치고, 다시 확인하는 과정으로 이어집니다. 한 번만 보고 답하는 시험으로는 AI가 이 흐름을 잘 따라가는지 알기 어려워, 여러 차례의 검토 과정을 평가할 자료가 필요합니다.

핵심 지표

어떻게 동작하나

MCR-Bench는 38개 GitHub 저장소에서 수집한 2,269개 실제 PR 리뷰 태스크로 구성되며, Python, Java, JavaScript, TypeScript, C#를 포함한다. 태스크는 최소 2라운드, 평균 3.8라운드, 최대 10라운드다. 저장소는 별 수, 활동성, 기여자 수, PR 수, 허용 라이선스 등을 기준으로 선정했다. 병합된 PR 중 코드 변경이 있고 사람 간 commit→discussion→revision 반복이 있는 사례를 수집했으며, SZZ-2 분석에서 이후 결함 유발이 확인된 PR은 제외했다. 주석 파이프라인은 각 라운드에서 결함 후보를 찾는 1단계와 후보를 합쳐 라운드별 상태를 추적하는 2단계로 구성된다. 이 과정을 태스크마다 세 번 독립 실행해 결과가 완전히 일치하는 태스크만 남긴 후, 경력 5년 이상 개발자 6명이 검증하고 불일치는 제3자가 중재했다. 두 1차 검증자의 Cohen’s kappa는 0.87이었다. 실험은 7개 LLM과 PR-Agent, Hybrid-Review를 비교했다. 주 평가에는 사람의 판단과 가장 높은 일치도(QWK 0.73)를 보인 GPT-5.2-pro 기반 LLM-Hit-Judge를 사용했다. 직접 프롬프트 모델 중 Claude Haiku 4.5가 결함 탐지 F1 0.551과, 맞게 탐지한 결함에 한정한 상태 추적 정확도 79.69%를 기록했다. 논문은 결함 종류와 심각도에 따른 성능 차이, 라운드가 깊어질 때의 성능 변화, 오탐·누락 원인, 리뷰 의견의 품질도 분석했다.

핵심 수식:

P = TP/(TP+FP); R = TP/(TP+FN); F1 = 2PR/(P+R); Acc_state = N_correct-state/N_TP; κ = (Po−Pe)/(1−Pe)

P는 정밀도, R은 재현율, F1은 두 값의 조화평균이다. TP는 맞게 찾은 결함, FP는 결함이 아닌데 있다고 한 경우, FN은 놓친 결함이다. Acc_state는 맞게 탐지한 결함(TP) 중 상태도 맞힌 비율이다. κ는 두 검증자의 실제 일치율 Po와 우연히 일치할 것으로 예상되는 비율 Pe를 사용한 Cohen’s kappa다.

한계와 주의할 점

• 공개 GitHub 저장소만 포함하므로 비공개 기업 저장소의 검토 관행이 충분히 반영되지 않을 수 있다.
• 세 번의 주석 결과가 완전히 일치하는 태스크만 남겨, 어려운 사례가 데이터에서 빠질 수 있다.
• 병합된 PR과 사람 간 반복 검토에 한정되어, 거부된 변경이나 자동화된 검토 흐름은 다루지 않는다.
• PR-Agent와 Hybrid-Review는 단일 라운드용으로 설계됐으며, 논문은 다중 라운드 평가를 위해 최소한으로 조정했다.
• 평가한 모델 수가 한정적이며, 논문은 모델 간 유의성 검정이나 지연 시간·비용을 보고하지 않았다.
• State–Temporal Misalignment: 오탐의 32.5%. 이미 해결된 문제를 새 문제로 다시 보고하는 오류.
• Over-reviewing: 오탐의 27.8%. 실제 결함이 아닌 제안이나 추측을 결함으로 보고하는 오류.
• Lack of Domain Knowledge: 오탐의 22.4%. 프로젝트별 관행을 몰라 정상적인 구현을 문제로 판단하는 오류.
• Cross-round Defect Forgetting: 누락의 25.1%. 해결되지 않은 문제를 뒤 라운드에서 더 이상 추적하지 않는 오류.
• Long-range Dependency Miss: 누락의 23.4%. 파일 사이의 연결이나 변경의 하류 영향을 놓치는 오류.

시스템 적용 아이디어

논문의 기법을 비슷한 구조를 가진 시스템에 옮길 때의 적용 지점이다.

PR별 문제 상태 기록으로 여러 라운드의 기억 유지

각 리뷰 결과에 문제 식별자, 위치, 상태, 근거 라운드와 마지막 확인 라운드를 기록한다. 다음 라운드에서는 미해결 또는 다시 열린 문제와 현재 변경을 함께 확인한다. 논문의 라운드별 후보 탐지와 전체 이력 병합 방식을 참고해 같은 문제를 연결하고, 해결 근거가 불분명하면 미해결 상태로 둔다. 논문은 이 방식의 실제 개선 효과를 측정하지 않았다.

적용 지점 — 여러 차례 이어지는 PR 리뷰 에이전트의 문제 기억

기대 효과 — 논문에서 오탐의 32.5%는 시간·상태 불일치, 누락의 25.1%는 이전 결함 추적 실패와 관련됐다. 이 아이디어의 개선 효과는 검증되지 않았다.

라운드별 문제 탐지 후 전체 이력에서 연결

각 라운드의 코드 변경과 검토 의견에서 후보 문제를 찾고, 이를 문제 설명과 위치를 기준으로 연결한다. 이후 작성자의 수정과 과거 검토 의견을 참고해 라운드별 상태를 판단한다. 논문의 주석 방식에서 가져온 아이디어이며, 캐싱이나 입력 분할이 성능을 개선한다는 실험 결과는 보고되지 않았다.

적용 지점 — PR 리뷰의 후보 탐지와 문제 통합 단계

기대 효과 — 긴 이력에서 라운드 경계와 문제 연결을 다루기 쉽게 할 수 있다. 논문은 처리 시간이나 비용 절감 효과를 측정하지 않았다.

미해결 문제를 검토 완료 전 다시 확인

각 라운드가 끝날 때 미해결 또는 다시 열린 문제가 있는지 확인하고, 남아 있으면 수정과 재검토를 요청한다. 해결 여부가 불분명하면 미해결로 유지한다. 이는 논문의 문제 상태 구분을 제품 흐름에 적용하는 아이디어이며, 자동 병합 게이트의 효과는 논문에서 검증되지 않았다.

적용 지점 — PR 검토 완료 판정과 재검토 절차

기대 효과 — 논문에서 가장 흔한 상태 판정 오류는 이미 해결된 문제를 새 문제로 보는 경우(38.29%)였다. 제안한 절차의 개선 효과는 측정되지 않았다.

LLM-Hit-Judge로 결함 적중 여부 평가

생성된 검토 의견이 기준 결함을 찾아냈는지 판정하고, 맞게 찾은 경우에만 상태 추적을 별도로 평가한다. 논문은 사람의 판단과 비교해 GPT-5.2-pro 기반 LLM-Hit-Judge가 QWK 0.73을 기록했고, 후속 실험의 주요 평가 지표로 채택했다. ClearCRC는 의견의 관련성, 정보성, 표현을 별도 평가한다.

적용 지점 — 코드 리뷰 모델의 평가와 회귀 점검

기대 효과 — 논문에서 Human Hit Rate와의 QWK는 LLM-Hit-Judge GPT-5.2-pro가 0.73이었으며, BLEU-4는 0.27, ROUGE-L은 0.21이었다. 평가 루프가 모델 성능을 높이는지는 논문에서 측정하지 않았다.

단계별 도입 로드맵

원문 PDF: 2026-08-28-from-static-to-dynamic-benchmarking-real-world-code-review-with-mcr-benc.pdf