💻 computer science

AI Agent Pull Requests on GitHub: Frequency, Structure, and Merge Conflict Rates

이 논문은 AIDev-pop 데이터셋을 실증적으로 분석하여, 동시적인 AI 에이전트 제출이 매우 빈번하게 발생하며 주로 동일한 에이전트를 포함하고, 크로스 에이전트 쌍(cross-agent pairs)이 인트라 에이전트 쌍(intra-agent ones)에 비해 병합 충돌률이 현저히 높다는 것을 밝혀낸다.

원저자: George Xu, Arjun Subramanian, Nithilan Karthik

게시일 2026-07-08

📖 3 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: George Xu, Arjun Subramanian, Nithilan Karthik

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

거대한, 북적이는 건설 현장을 상상해 보세요. 그곳에는 인간 노동자 대신, 똑똑하지만 독립적인 수십 대의 고도로 숙련된 로봇(AI 코딩 에이전트)들이 정확히 같은 집을 동시에 짓거나 고치려고 애쓰고 있습니다.

이 논문은 이 로봇들이 서로 대화하지 않고 협업할 때 어떤 일이 벌어지는지에 대한 성적표입니다. 연구진들은 이 로봇들이 얼마나 자주 충돌하는지, 그 싸움이 어떤 모습인지, 그리고 결과가 얼마나 엉망이 되는지를 확인하기 위해 GitHub의 수천 개의 실제 프로젝트를 조사했습니다.

다음은 쉬운 비유를 사용한 연구 결과의 요약입니다:

1. 로봇들의 "교통 체증"

첫 번째 큰 질문은 다음과 같았습니다: 이 로직들은 얼마나 자주 같은 집을 동시에 작업하고 있는가?

답은 이렇습니다: 거의 항상 그렇습니다.

연구 결과: 프로젝트의 약 40%에서 두 대의 로봇이 정확히 같은 초(second)에 집을 작업하고 있었습니다. 만약 일주일이라는 시간 범위를 준다면, 그 수치는 거의 95%까지 치솟습니다.
비유: 10명의 요리사 중 9명이 같은 도마 위에서 동시에 채소를 썰고 있는 바쁜 주방을 상상해 보세요. 혼란스럽지만, 그것이 일반적인 상황입니다.
누가 싸우는가? 놀랍게도, 서로 다른 종류의 로봇(예: 'Devin' 로봇과 'Copilot' 로봇) 사이의 싸움은 드뭅니다. 대부분은 같은 종류의 로봇이 자기 자신과 싸우는 것입니다. 충돌 사례의 99.5%는 병렬로 작동하는 동일한 AI 모델의 두 인스턴스 간의 갈등이었습니다. 이는 마치 두 명의 쌍둥이가 서로 협력하지 않고 같은 벽을 칠하려고 하는 것과 같습니다.

2. "충돌" (병합 충돌/Merge Conflicts)

두 로봇이 동일한 파일에 변경 사항을 저장하려고 할 때, 컴퓨터는 어떤 버전을 유지할지 결정해야 합니다. 이를 "병합(merge)"이라고 합니다. 만약 그들이 같은 줄을 수정했다면, 컴퓨터는 혼란에 빠져 "충돌(Conflict)" 플래그를 띄웁니다.

연구진은 이러한 병합을 시뮬레이션하여 얼마나 자주 문제가 발생하는지 확인했습니다:

같은 로봇 vs 같은 로봇: 동일한 AI의 두 인스턴스가 병합을 시도했을 때, 약 **20%**의 확률로 충돌이 발생했습니다.
다른 로봇 vs 다른 로봇: 서로 다른 유형의 AI가 병합을 시도했을 때, 약 **42%**의 확률로 충돌이 발생했습니다.
시사점: 서로 다른 로봇은 동일한 로봇보다 서로 의견이 일치하지 않을 확률이 두 배 더 높습니다. 하지만 동일한 로봇들이 훨씬 더 자주 함께 작업하기 때문에, 전반적인 난장판은 주로 이들에 의해 발생합니다.

3. 무엇을 두고 싸우는가?

로봇들이 충돌할 때, 그 싸움의 본질은 무엇일까요?

위치: 대부분의 싸움은 "쇼핑 리스트"(의존성 파일)나 문서가 아닌, 소스 코드(소프트웨어의 실제 명령어)에서 발생했습니다. 충돌의 약 84%가 코드 자체에서 나타났습니다.
싸움의 유형:
- 내용 싸움 (58%): 두 로봇 모두 같은 문단의 같은 문장을 수정하려고 했습니다.
- 구조 싸움 (42%): 이것이 가장 기이한 부분입니다. 한 로봇은 파일을 삭제하기로 결정했는데, 다른 로봇은 그 파일을 수정하기로 결정했습니다. 또는, 두 로봇 모두 이름은 같지만 내용은 다른 새로운 파일을 생성하려고 했습니다.
- 비유: 이는 한 로봇은 "주방을 철거하겠다"라고 말하고, 다른 로봇은 "주방을 리모델링하겠다"라고 말하며, 세 번째 로봇은 "바로 여기에 새 주방을 짓겠다"라고 말하는 것과 같습니다. 그들 모두가 옳을 수는 없습니다.

4. 이것이 왜 중요한가? (숨겨진 비용)

논문은 우리가 "텍스트적" 싸움(코드 줄)만을 측정했지만, 실제 비용은 이보다 훨씬 높다고 지적합니다.

"시간 낭비" 비용: 로봇들은 다른 이들이 작업 중이라는 사실을 모르기 때문에, 결코 합쳐질 수 없는 기능을 만드는 데 시간을 허비합니다.
"인간의 정리" 비용: 결국, 인간이 개입하여 엉망이 된 상황을 바로잡아야 합니다. 인간은 어떤 로봇이 맞았는지, 어떤 파일을 남길지, 그리고 삭제된 것을 어떻게 복구할지를 결정해야 합니다. 이는 로봇에게 일을 시키는 본래의 목적을 퇴색시킵니다.

요약

이 논문은 현재의 AI 코딩 에이전트들이 공유된 방 안에서 작업하는 외로운 천재들과 같다고 결론짓습니다. 그들은 개별적으로는 매우 생산적이지만, (심지어 같은 모델일지라도) 서로 대화하지 않기 때문에 끊임없이 자신의 발에 걸려 넘어집니다.

빈도: 그들은 거의 항상 동시에 작업하고 있습니다.
충돌률: 동일한 로봇은 약 20%, 서로 다른 로봇은 약 42%의 확률로 충돌합니다.
난장판의 원인: 싸움은 단순한 오타보다는 코드 구조(파일 삭제 vs 추가)에 관한 것입니다.

연구진은 AI가 진정으로 소프트웨어를 구축하는 데 도움을 주려면, 이 로봇들에게 코드를 두드리기 전에 서로의 일정을 조정하고 대화하는 법을 가르쳐야 한다고 제안합니다.

기술 요약: GitHub 상의 AI 에이전트 풀 리퀘스트(Pull Requests)

문제 정의

AI 코딩 에이전트가 이슈를 분석하고, 수정안을 작성하며, 자율적으로 풀 리퀘스트(PR)를 제출하는 등 독립적인 운영 능력을 갖추며 진화해 왔으나, **동시적 에이전트 활동(concurrent agent activity)**의 함의를 이해하는 데에는 결정적인 격차가 존재한다. 기존 연구는 개별 에이전트 출력의 품질이나 단일 에이전트의 PR과 베이스 브랜치 간의 충돌에 초점을 맞추어 왔다. 그러나 여러 에이전트(또는 동일한 에이전트의 여러 인스턴스)가 동시에 동일한 저장소에서 작업할 때 어떤 일이 발생하는지에 대한 실증적 조사는 이루어지지 않았다. 구체적으로, 기존 문헌에는 다음 사항에 대한 데이터가 부족하다:

GitHub에서 동시적 에이전트 워크플로가 발생하는 빈도.
이러한 동시 워크플로가 서로 충돌할 가능성.
이러한 충돌의 구조적 성격 (예: 텍스트 대 시맨틱/의미론적 충돌).

본 논문은 자율적 개발에서 아키텍처와 텍스트 사이의 "조정 격차(coordination gap)"를 다룬다. 버전 관리 도구가 라인 단위의 텍스트 충돌은 감지할 수 있지만, 여러 자율 개발자 간의 충돌하는 의도(conflicting intents)를 본질적으로 해결할 수는 없다는 점에 주목한다.

방법론

본 연구는 33,596개의 PR과 2,807개의 저장소로 구성된 AIDev-pop 데이터셋을 활용한다. 저자들은 네 단계의 실증적 접근 방식을 채택한다:

공동 활동(Co-activity) 정형화: 저자들은 시간적 중첩을 기준으로 "공동 활동적(co-active)" PR을 정의한다. PR $P_i$ 는 저장소, 작성 에이전트, 오픈 시간( $T_{open}$ ), 종료 시간( $T_{close}$ )으로 정의된다. 두 PR은 활동 윈도우 $[T_{open} - k, T_{close} + k]$ 가 겹칠 경우 공동 활동적이라고 간주된다. 본 연구는 이를 네 가지 시간 패딩 임계값( $k \in \{0, 1, 3, 7\}$ 일)에 걸쳐 분석한다.
층화 추출(Stratified Sampling): 활발한 저장소로 인해 결과가 왜곡되는 것을 방지하기 위해, 저자들은 머지 리플레이(merge replay)를 위한 층화 샘플을 생성했다:
- 층 A (Intra-agent, 에이전트 내부): 625개 저장소 각각에서 동일한 에이전트로부터 생성된 한 쌍의 PR을 추출.
- 층 B (Cross-agent, 에이전트 간): 교차 에이전트 활동을 보이는 모든 122개 저장소로부터 서로 다른 에이전트에서 생성된 한 쌍의 PR을 추출.
- 총 샘플: 747개의 고유한 공동 활동 쌍.
대규모 머지 리플레이(Large-Scale Merge Replay): 저자들은 헤드리스 git merge-tree 기능을 사용하는 자동화된 멀티스레드 프로세스를 개발했다. 이는 작업 디렉토리를 건드리지 않고 메모리 내에서 3-way 머지를 시뮬레이션한다. 프로세스는 두 PR의 헤드 커밋을 가져오고, 공통 조상을 식별한 뒤 머지를 시도한다.
- 충돌 감지: 반환 코드 1은 텍스트 충돌을 나타낸다. 시스템은 충돌하는 파일 경로와 충돌 유형(예: content, modify/delete, add/add)을 추출한다.
- 범위: 본 연구는 엄격히 텍스트 충돌(Layer 1)에 집중한다. 저자들은 빌드(Layer 2) 및 시맨틱(Layer 3) 충돌은 성공적인 텍스트 머지 없이는 발생할 수 없으므로, 이 결과가 전체 시스템 마찰의 "보수적인 하한선(conservative lower bound)"을 제공한다고 언급한다.
분류 체계(Taxonomy) 분석: 충돌은 파일 유형(소스 코드, 의존성, 설정 등)과 구조적 유형(내용 중복 vs. 구조적 변경)에 따라 분류된다.

주요 기여 및 결과

1. 동시성의 빈도 (RQ1)

동시적 에이전트 활동은 만연해 있다.

엄격한 중첩 ( $k=0$ ): **40.2%**의 저장소가 적어도 하나 이상의 공동 활동적 PR 쌍을 포함한다.
PR 수준의 보편성: 에이전트가 작성한 모든 PR의 **79.4%**가 다른 에이전트 PR과 동시에 열려 있다.
확장된 윈도우: ±7일의 윈도우를 허용할 경우, **53.4%**의 저장소와 **95.0%**의 PR이 공동 활동성을 보인다.

2. 공동 활동의 구성 (RQ2)

동시성의 대다수는 교차 에이전트가 아닌 에이전트 내부(intra-agent) 활동이다.

에이전트 내부 (Intra-agent): 공동 활동 쌍의 **99.5%**가 동일한 에이전트 모델에 의해 작성되었다.
에이전트 간 (Cross-agent): 서로 다른 에이전트가 포함된 쌍은 단 **0.5%**에 불과하며, 이는 단 122개의 저장소(약 4.3%)에서 발생했다.
지배력: OpenAI Codex가 동시성의 주요 동력이며, 높은 볼륨 덕 인해 교차 에이전트 상호작용의 "다수 앵커(majority anchor)" 역할을 한다.

3. 머지 충돌율 (RQ3)

동시적인 에이전트 PR을 머지할 때 상당한 마찰이 발생하며, 에이전트 내부와 에이전트 간 시나리오 사이에 명확한 차이가 존재한다:

에이전트 내부 충돌율: 19.8% (119/601 쌍).
에이전트 간 충돌율: 41.7% (48/115 쌍).
통계적 유의성: 이 비율들의 95% 신뢰 구간은 서로 겹치지 않으며, 이는 두 범주 간의 충돌 가능성에 대한 명확한 차이를 나타낸다.

4. 충돌 구조 및 분류

충돌의 성격은 깊은 조정 실패를 드러낸다:

파일 유형: 충돌하는 파일의 **84.4%**가 소스 코드이며, 이는 의존성 매니페스트가 주요 충돌 원인일 것이라는 가설과 상반된다.
구조적 vs. 내용적:
- **57.6%**는 내용 충돌(동일한 라인의 서로 다른 업데이트)이다.
- **41.9%**는 구조적 충돌(modify/delete 26.8%, add/add 15.1%)이다.
함의: 에이전트들은 파일이 존재해야 하는지 여부에 대해 자주 이견을 보이거나, 동일한 새 파일을 독립적으로 생성한다. 이는 병렬 작업에 대한 인식이 결여되어 있음을 나타낸다.

5. 연관성 (RQ4)

처리량(Throughput): PR 수준의 공동 활동은 저장소 처리량에 따라 증가한다 (저처리량 저장소의 ~53%에서 고처리량 저장소의 ~90%까지).
에이전트: Devin(82.5%)과 OpenAI Codex(80.9%)가 가장 높은 PR 수준의 공동 활동률을 보인다.
언어: Go(92%)와 Ruby(87%) 저장소가 가장 높은 공동 활동률을 보였고, C++(56%)와 HTML(44%)은 가장 낮았다.

의의 및 주장

본 논문은 동시적 에이전트 제출에 대한 첫 번째 실증적 조사를 제공한다고 주장한다. 이 연구의 주요 의의는 다중 에이전트 오케스트레이션이 현재 이종 벤더 간의 조정 문제라는 이론적 가설에 도전한다는 점에 있다. 대신, 데이터는 단일 에이전트 프레임워크로부터 나오는 고빈도 출력의 관리가 지배적인 운영 이슈임을 보여준다.

저자들은 다음과 같이 주장한다:

인식 부족: 현재의 에이전트들은 동일한 파일을 수정하는 다른 에이전트(심지어 동일한 유형의 에이전트라도)에 대한 "수평적 인식(horizontal awareness)" 없이 고립되어 작동한다.
보수적 추정: 보고된 충돌율(19.8% 및 41.7%)은 보수적인 하한선이다. 이는 텍스트 충돌만을 나타내며, 실제 비용에는 측정되지 않은 빌드 실패, 시맨틱 모순, CI/CD 컴퓨팅 낭비, 토큰 예산 고갈 등이 포함된다.
구조적 불일치: 높은 구조적 충돌율(modify/delete, add/add)은 에이전트들이 단순히 라인을 편집하는 것이 아니라, 저장소의 구조에 대해 근본적으로 이견을 보이고 있음을 시사하며, 이는 단순한 코드 리뷰로는 쉽게 해결할 수 없는 문제이다.

본 연구는 조정되지 않은 반응적 개발 패러다임이 현대의 자율 엔지니어링에 불충분하다고 결론지으며, 미래의 연구는 통합 마찰을 완화하기 위해 프로그래밍 방식의 오케스트레이션과 라이브 워크스페이스 통신 프로토콜에 집중해야 한다고 제언한다.