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