← 최신 논문
🤖 AI

Why Are AI Agent Involved Pull Requests (Fix-Related) Remain Unmerged? An Empirical Study

이 실증적 연구는 5개의 AI 코딩 에이전트로부터 추출한 8,000개 이상의 수정 관련 풀 리퀘스트를 분석하여, 빌드 실패는 드문 반면 테스트 케이스 실패와 중복된 이슈 해결이 머지에 있어 주요 장벽임을 식별함으로써, 현재 AI 에이전트의 핵심적인 한계와 소프트웨어 유지보수에서의 인간-AI 협업 개선을 위한 방향을 강조한다.

원저자: Khairul Alam, Saikat Mondal, Banani Roy

게시일 2026-02-03
📖 3 분 읽기☕ 가벼운 읽기

원저자: Khairul Alam, Saikat Mondal, Banani Roy

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

소프트웨어 프로젝트를 거대하고 북적이는 건설 현장이라고 상상해 보세요. "유지 관리자(maintainers)"는 어떤 설계도를 실제로 제작할지, 어떤 것을 쓰레기통에 버릴지 결정하는 현장 소장들입니다. 최근 이들은 수리 계획(이를 "풀 리퀘스트(Pull Request)" 또는 "PR"이라고 부릅니다)을 작성하기 위해 AI 에이전트(로봇 조수와 같은 존재)를 고용하기 시작했습니다.

이 논문은 마치 탐정 보고서처럼 다음과 같은 질문을 던집니다: "이 로봇 조수들이 제출한 수리 계획이 얼마나 자주 승인되는가? 그리고 승인되지 않는다면 그 이유는 무엇인가?"

다음은 연구 결과의 요약이며, 이해를 돕기 위해 쉬운 비유를 사용했습니다.

1. 큰 그림: 성공률

연구진은 다섯 가지 유형의 AI 로봇(OpenAI Codex, GitHub Copilot, Devin, Cursor, Claude Code)이 제출한 8,000개 이상의 수리 계획을 조사했습니다.

  • 좋은 소식: 현장 소장들이 "그래, 이걸로 만들어!"라고 말하며 수리 계획을 병합(merge)한 경우가 약 **65%**였습니다. 로봇들은 꽤 괜찮은 성과를 내고 있습니다.
  • 나쁜 소식: 약 **26%**의 경우, 소장들이 계획을 실행하지 않고 그냥 닫아버렸습니다. 또 다른 **9%**는 결정을 내리지 못한 채 대기실에 머물러 있습니다.
  • 로봇 간의 차이: 모든 로봇의 실력이 똑같지는 않았습니다.
    • OpenAI Codex는 우등생이었습니다. 승인율이 **81%**에 달했습니다.
    • Devin은 가장 고전했습니다. 승인율이 **43%**에 불과하여, 제출한 수리 계획의 절반 이상이 거절되었습니다.

2. "왜?": 왜 계획이 거절되는가?

연구진은 326개의 거절된 계획을 깊이 파고들어 정확히 왜 실패했는지 찾아냈습니다. 그들은 12가지 이유를 발견했으며, 이를 세 가지 카테리아로 분류했습니다.

A. "잘못된 해결책" 문제 (기술적 이슈)

때때로 로봇은 누수를 고치려 하지만, 실제로는 파이프를 망가뜨리기도 합니다.

  • 테스트 실패 (가장 흔한 기술적 이유): 로봇의 수정 사항이 로봇 자신의 논리로는 통과되었지만, 프로젝트의 엄격한 안전 테스트를 통과하지 못했습니다. 이는 마치 요리사가 음식을 만들었는데, 맛은 훌륭해 보일지 몰라도 위생 검사관(테스트 스위트)이 맛을 보니 엉망인 것과 같습니다.
  • 불완전하거나 잘못된 해결책: 로봇이 문제를 짐작은 했으나 엉뚱한 것을 해결했거나, 문제의 절반만 해결한 경우입니다.
  • 빌드/배포 실패: 드물게는 수정 사항이 너무 엉망이라 건물을 아예 조립조차 할 수 없는 경우(컴파일이 안 되거나 실행되지 않는 경우)도 있었습니다.

B. "타이밍" 문제 (프로세스 이슈)

때로는 해결책 자체가 훌륭함에도 불구하고, 타이밍이 맞지 않을 때가 있습니다.

  • 누군가 먼저 처리함 (#1 거절 사유): 이 사례는 **22%**를 차지했습니다. 로봇이 깨진 창문을 고치기 위해 열심히 노력하고 있었지만, 이미 사람(또는 다른 로봇)이 5분 전에 창문을 고쳐놓은 상태였습니다. 로봇의 계획은 단지 중복되었다는 이유만으로 거절되었습니다.
  • 활동 중단: 로봇이 계획을 제출했지만, 그 후 아무런 반응이 없었습니다. 소장들은 답변을 기다리다 지쳐서 티켓을 닫아버렸습니다.
  • 낮은 우선순위: 로봇이 고치려던 문제가 더 이상 중요하지 않게 되었거나, 프로젝트 매니저들이 해당 문제를 무시하기로 결정한 경우입니다.

C. "의사소통 단절" 문제

  • 검토 없음: 로봇이 검토를 요청했지만, 인간 소장이 한 번도 살펴보지 않은 경우입니다.
  • 설명 없는 거절: 계획이 왜 실패했는지에 대한 설명 없이 그냥 닫혀버려, 로봇(그리고 연구진)을 막막하게 만든 경우입니다.

3. "속도" 요소

연구진은 계획이 승인되기까지 얼마나 걸리는지도 측정했습니다.

  • 빠른 병합: 많은 양질의 수정 사항들이 매우 빠르게 승인되었습니다.
  • 느린 병합: 일부는 시간이 오래 걸렸습니다. 흥미롭게도, "우등생"인 OpenAI Codex는 가장 일관되고 빠른 승인 시간을 보였던 반면, 다른 로봇들은 훨씬 더 예측 불가능한 대기 시간을 보였습니다.

핵심 결론

이 논문은 코드를 작성하는 것만으로는 충분하지 않다고 결론짓습니다.

현장에서 수리 계획을 승인받으려면, 로봇은 다음을 수행해야 합니다:

  1. 단순히 보기 좋은 코드가 아니라, 엄격한 안전 테스트를 통과해야 합니다.
  2. 사람이나 다른 로봇이 이미 해놓은 일을 중복해서 작업하지 않아야 합니다.
  3. 인간 매니저와의 대화에 계속 참여해야 합니다.

현재 가장 큰 장애물은 로봇이 코드를 쓰지 못하는 것이 아닙니다. 그들은 종종 테스트에서 낙제하거나, 다른 사람들이 문제를 해결하는 데 선수를 빼앗기는 문제입니다. 이 연구는 AI가 진정한 "가상 팀원"이 되기 위해서는 단순히 코드 자체를 잘 쓰는 것을 넘어, 프로젝트의 맥락과 워크플로우의 타이밍을 더 잘 이해해야 한다고 제안합니다.

연구 분야의 논문에 파묻히고 계신가요?

연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.

Digest 사용해 보기 →