AI가 낸 PR, 사람만큼 합쳐지고 있나
실제 깃허브 PR을 추적한 논문이 에이전트 코드의 수명주기를 살폈다.
AI 코딩 에이전트가 만든 풀 리퀘스트(PR)는 사람이 만든 PR과 얼마나 다를까. 캐나다 폴리테크니크 몬트리올 연구진이 실제 오픈소스 저장소 데이터를 장기간 추적해 이 질문에 답한 논문을 아카이브(arXiv)에 공개했다. 논문은 7월 23일 등록됐고, 개발 주기 전반에 걸쳐 에이전트 기여의 성격이 어떻게 변해 왔는지를 다룬다.
무슨 일인가 / 배경
연구진(이렌 마즐룸자데 외 2인)은 에이전트 PR을 모아 둔 에이아이데브(AIDev) 데이터셋을 사용했다. 분석은 세 갈래다. 첫째, 에이전트 PR과 사람 PR의 병합률 차이가 시간에 따라 어떻게 벌어지거나 좁혀졌는가. 둘째, 에이전트가 주로 어떤 종류의 개발 작업에 투입되며 그 분포가 분기별로 어떻게 이동했는가. 셋째, 두 집단의 PR이 소프트웨어 품질 측면에서 어떤 특성 차이를 보이는가.
중요한 건 관점이다. 지금까지 코딩 에이전트 평가는 대부분 벤치마크 문제를 몇 퍼센트 풀었는가로 이뤄졌다. 이 논문은 벤치마크가 아니라 '실제로 저장소에 합쳐졌는가'를 성적표로 삼았다. 사람 리뷰어의 승인이라는, 현장에서 가장 까다로운 관문을 통과 기준으로 쓴 셈이다.
핵심 짚어보기
해외 개발자 커뮤니티에서 이 논문이 화제가 된 건 병합률 수치 때문이다. 공유된 요약에 따르면 클로드 84%, 코덱스 74%, 데빈 43%, 사람 85%로 정리된다. 다만 아카이브 초록 자체에는 이 숫자들이 명시돼 있지 않으므로, 정확한 표본 범위와 기간은 본문에서 확인해야 한다. 인용할 때는 이 점을 함께 밝히는 편이 안전하다.
수치를 그대로 받아들이더라도 해석은 신중해야 한다. 병합률이 높다는 건 코드가 훌륭하다는 뜻이 아니라, 에이전트에게 맡겨진 작업이 애초에 합의가 쉬운 종류였을 가능성도 함께 담고 있다. 논문이 '작업 유형의 분포와 그 변화'를 따로 분석한 이유도 여기에 있다. 오타 수정과 의존성 갱신을 주로 맡는 에이전트와, 설계 변경을 시도하는 에이전트의 병합률을 같은 자로 재면 안 된다.
논문이 던지는 진짜 질문은 성능 순위가 아니라 지속성이다. 도입 초기에 반짝 높았던 병합률이 시간이 지나며 어떻게 움직이는지, 에이전트 기여가 개발 수명주기의 어느 단계에 자리를 잡는지가 본론이다.
1인기업 실전 적용 포인트
- 에이전트에게 맡길 일을 '리뷰가 쉬운 것'부터 잘라내라. 테스트 추가, 문서 갱신, 의존성 업데이트, 반복 리팩터링처럼 정답 판정이 명확한 작업이 실제로 통과율이 높은 영역이다.
- 혼자 일한다면 병합률 대신 '되돌린 횟수'를 세라. 리뷰어가 없는 1인 개발에서는 승인 지표가 무의미하다. 대신 커밋 후 되돌리거나 다시 손댄 비율을 기록하면 같은 정보를 얻는다.
- 작업 단위를 작게 끊어라. 한 번에 파일 20개를 고치는 변경은 사람도 리뷰를 못 한다. 에이전트에게도 한 PR당 목적 하나를 강제하면 검토 시간이 줄고 사고도 준다.
- 모델별 강점을 감이 아니라 기록으로 남겨라. 어떤 작업을 어느 도구에 맡겼고 몇 번 만에 통과했는지를 한 줄씩 적어 두면, 반년 뒤 도구를 바꿀 때 이 기록이 유일한 근거가 된다.
전망 / 주의점
이런 연구의 한계는 분명하다. 오픈소스 저장소는 대체로 공개 코드이고, 에이전트를 적극 도입한 프로젝트일수록 병합에도 관대할 수 있다. 사내 비공개 코드베이스나 규제 산업의 결과가 같으리라고 보기는 어렵다.
그럼에도 방향은 읽힌다. 논쟁의 축이 'AI가 코드를 짤 수 있는가'에서 '짜 놓은 코드가 실제로 채택되는가'로 옮겨 갔다. 도구를 고르는 기준도 그쪽으로 따라가야 한다. 데모에서 인상적인 모델보다, 내가 실제로 손을 덜 대는 모델이 좋은 모델이다.
출처: arXiv (https://arxiv.org/abs/2607.21832)
이 시스템이 실제로 돌아가는 모습은 유튜브에서 공개 중입니다.
채널 보기 ↗