Pull Request를 올렸더니 AI 리뷰어가 코멘트 스무 개를 남겼다. 심각도 표시와 설명, 바로 적용할 수정안까지 붙어 있다. 몇 시간 동안 사람이 살핀 결과보다도 든든해 보인다.
문제는 어디까지 믿어도 되는지다. 코멘트가 많다고 리뷰까지 잘된 것은 아니다.
캐나다 퀸스대학교 연구진은 답을 찾으려고 300개 오픈소스 프로젝트의 인라인 코드 리뷰 대화 278,790개를 분석했다. AI와 사람이 무엇을 지적했는지, 대화가 어떻게 끝났는지, 제안한 코드가 실제로 반영됐는지까지 추적했다.
27만여 개 대화에서 역할 차이를 찾았다
연구진은 2022년부터 2025년 11월까지 이어진 Pull Request 54,330개를 조사했다. 별점이 100개 이상이고 매달 닫힌 Pull Request가 하나 이상이며, AI 리뷰가 100건 이상인 프로젝트만 골랐다. 잠깐 쓰이다 멈춘 저장소를 빼고 꾸준히 관리된 프로젝트를 보려는 조건이다. 특정 코드 변경에 붙은 인라인 대화만 분석한 것도 같은 이유다. 그래야 어느 코드에 어떤 제안을 했고 이후 커밋에 반영됐는지 확인할 수 있다.
첫 댓글과 Pull Request 작성자가 사람인지 AI인지에 따라 대화를 네 종류로 나눴다. 전체 대화의 55.7%는 AI가 리뷰를 시작했다. AI 계정이 직접 만든 코드에 관한 대화는 2.6%뿐이었다. AI가 만든 코드를 AI가 검토한 928개 대화 중 94.0%는 같은 에이전트의 자기 리뷰였다. 독립된 이중 검증이라고 부르기 어려운 수치다.
GPT-4.1-mini는 피드백을 코드 개선, 결함 탐지, 이해, 테스트, 지식 전달 등 아홉 가지로 분류했다. 사람이 다시 분류한 383개 표본과 비교한 Cohen의 카파 값은 0.85였다. 일치도는 높았지만 자동 분류가 완벽했다는 뜻은 아니다. 사람 계정으로 올린 코드에 외부 LLM의 도움이 있었는지도 데이터만으로는 알 수 없다.
AI는 문제를 찾고 사람은 이유를 물었다
AI가 시작한 리뷰의 95% 이상은 코드 개선과 결함 탐지에 몰렸다. 사람이 시작한 리뷰는 범위가 더 넓었다. 사람이 사람의 코드를 볼 때는 댓글의 31%가 구현 의도와 설계 이유를 묻는 ‘이해’ 유형이었다. AI가 만든 코드를 사람이 볼 때도 17%가 이 유형이었다.
AI는 눈앞의 코드에서 고칠 부분을 찾으면 곧장 수정안을 냈다. 사람은 왜 이렇게 썼는지, 테스트는 어디에 있는지, 지난번에 어떤 결정을 했는지부터 물었다. 코드 조각만 보면 이상해도 저장소 전체에서는 정상일 수 있다. 이런 경우를 가르려면 질문이 필요하다.
말의 양도 달랐다. 사람이 쓴 리뷰는 변경 코드 한 줄당 평균 4.1토큰이었고 AI 리뷰는 29.6토큰이었다. AI 코멘트에는 심각도, 요약 제목, 도구가 낸 근거와 관련 파일 목록이 자주 함께 들어갔다. 읽을 정보는 많아졌지만 정확도까지 높아졌다는 증거는 없다.
긴 리뷰가 정성스러운 리뷰처럼 보일 때는 한 번 더 의심할 필요가 있다. 사람에게는 문제와 근거를 짧게 보여 주고, 심각도나 관련 파일 목록은 자동화가 처리할 구조화된 데이터로 분리하는 편이 낫다.
수정안이 많아도 실제 채택은 적었다
AI 리뷰어는 코드 수정안 88,011개를 제시했다. 사람이 제시한 25,673개의 3배가 넘는다. 그러나 실제 코드에 반영된 비율은 AI가 16.6%, 사람이 56.5%였다. 결함 수정 제안만 비교해도 AI는 16.7%, 사람은 53.7%였다.
연구진은 같은 줄이 바뀌었다고 곧바로 채택으로 세지 않았다. 이후 코드가 원래 코드보다 제안한 코드에 가까워졌는지 비교하고, 되돌린 수정과 병합되지 않은 Pull Request는 제외했다. 판별법에는 한계가 있어도 반응 표시보다 실제 코드 변화를 보려 한 셈이다.
채택되지 않은 AI 제안 383개를 살펴보니 28.7%는 빌드를 깨뜨리거나 프로젝트 동작과 충돌했다. 24.0%는 문제 지적은 맞았지만 개발자가 다른 방법으로 고쳤다. 논문에는 AI가 네임스페이스 한정자가 없어 빌드가 실패한다고 지적했지만, 프로젝트의 다른 설정 덕분에 이름이 이미 올바르게 해석된 사례도 나온다. 일반 규칙에는 맞아도 해당 저장소에는 틀린 제안이 적지 않았다. 그러니 채택률 차이를 사람의 AI 거부감만으로 설명할 수 없다.
채택됐다고 언제나 더 좋은 코드인 것도 아니다. 소스 코드를 바꾼 인간 제안 1,257개와 AI 제안 2,125개에 정적 분석을 적용하자, 차이가 난 6개 지표에서 AI 제안은 코드 크기와 순환 복잡도를 더 많이 늘렸다. 이 분석은 파일 단위 지표에 그친다. 시스템 전체의 보안과 가독성까지 나빠졌다는 뜻은 아니다.
리뷰는 코멘트 한 번이 아니라 대화다
AI가 리뷰를 시작한 대화의 85.2~86.7%는 첫 코멘트 뒤에 응답 없이 끝났다. 사람이 사람의 코드를 리뷰한 경우에는 48.9%가 여러 차례 대화로 이어졌다. AI가 문제를 많이 남겨도 작성자가 답하지 않고 AI도 다시 확인하지 않으면 그 지적이 해결됐는지 알 수 없다.
사람이 AI 작성 코드를 리뷰하면 사람 작성 코드를 볼 때보다 평균 대화가 11.8% 길어졌다. 논문에는 AI가 별도 Pull Request를 만들겠다고 약속한 뒤 실제로는 그 작업을 할 수 없다고 답해 16차례 대화가 이어진 사례도 있다. 코드는 빨리 만들었지만 불가능한 약속을 바로잡는 데 사람의 시간이 더 든 셈이다.
AI가 마지막으로 답한 대화의 Pull Request 거절률은 평균 15.6%였고, 사람이 마지막으로 답한 경우는 7.8%였다. 이 수치만으로 원인과 결과를 말할 수는 없다. 어려운 변경이라 AI 대화가 길어졌을 수도 있고, 연구가 인라인 대화의 결과 대신 Pull Request 전체의 병합 여부를 썼다는 한계도 있다.
리뷰 완료 조건을 ‘AI가 코멘트를 남김’으로 두면 곤란하다. 제안이 현재 코드와 빌드 설정에 맞는지 확인하고, 수정 뒤 테스트가 통과했는지 본다. 대화 수와 Pull Request의 병합 또는 거절 사이에도 뚜렷한 관계는 없었다. 코멘트 수나 대화 길이보다 마지막 판단을 누가 남겼는지를 봐야 한 사이클이 끝난다.
사람을 빼기보다 마지막 판단에 집중시킨다
AI의 강점은 규모다. 반복되는 개선점과 결함 후보를 빠르게 모으는 역할에 잘 맞는다. 프로젝트의 오래된 결정과 구현 의도, 팀이 선호하는 해결책은 사람 리뷰에서 더 많이 나타났다.
실제 리뷰 절차에도 이 차이를 반영하면 된다. AI가 저장소의 빌드 설정과 관련 테스트, 최근 리뷰 결정을 먼저 읽게 한다. 별도 검증 단계에서 제안을 빌드와 테스트로 확인한 뒤, 통과한 문제와 짧은 근거만 사람에게 보여 준다. 사람은 의도와 유지보수 비용을 따져 병합 여부를 정한다.
같은 에이전트가 자기 판단을 되풀이하면 별도 검증이 아니다. 두 번째 검증자는 처음 문제를 찾은 과정과 떨어져 실제 저장소와 테스트를 기준으로 반박해야 한다. 첫 번째 모델의 자신감을 그대로 물려받으면 검증이라는 이름만 남는다.
AI 리뷰어를 판사보다 센서로 놓으면 장점과 한계가 함께 보인다. 센서는 넓고 빠르게 이상 신호를 모은다. 신호가 진짜 문제인지, 이 프로젝트에서는 어떤 해결이 맞는지, 수정이 끝났는지는 사람이 판단한다. 이 연구의 수치는 2022년부터 2025년 11월까지 공개 GitHub 프로젝트에서 관찰한 한 장면이다. 비공개 저장소와 작은 팀에서도 같은 비율이 나온다고 단정할 수는 없다. 그래도 코멘트 수보다 검증과 마지막 판단을 먼저 보라는 기준은 지금도 유효하다. 지금은 사람을 빼기보다 사람이 판단할 후보를 줄이는 데 AI를 쓰는 편이 낫다.
원문 논문: Human-AI Synergy in Agentic Code Review (Suzhen Zhong, Shayan Noei, Ying Zou, Bram Adams, 2026) / GeekNews 소개