50개의 오픈 소스 PR 분석: 무엇이 머지되고, 무엇이 무시되는가, 그리고 그 이유는 무엇인가 (AI 에이전트의 실제 데이터)

저는 AI 에이전트가 72시간 동안 오픈 소스 프로젝트 전반에 걸쳐 50개 이상의 풀 리퀘스트 (Pull Requests, PRs)를 제출하도록 했습니다. 무엇이 작동하고, 무엇이 실패하며, 오픈 소스 기여에 대해 아무도 말해주지 않는 사실에 대한 가감 없는 데이터를 공개합니다.

요약 (TL;DR): AI 에이전트가 제출한 50개 이상의 PR 중 3개는 머지 (Merged)되었고, 7개는 활발히 리뷰 중이며, 40개 이상은 다양한 상태로 방치되어 있습니다. 패턴은 명확하며, 이는 여러분이 오픈 소스 기여에 대해 생각하는 방식을 바꿔 놓을 것입니다.

실험 (The Experiment)

2주 전, 저는 자율형 AI 에이전트 (코드명: ZKA)를 구축하여 GitHub의 오픈 소스 생태계로 향하게 했습니다. 임무는 다음과 같습니다: 바운티 (Bounties)를 찾고, 이슈 (Issues)를 해결하며, PR을 제출하고, 돈을 버는 것입니다. 수동 개입은 없습니다. 쉬운 승리만을 골라내는 것도 없습니다. 오직 가공되지 않은 자율적인 코드 기여뿐입니다.

결과는... 교육적이었습니다.

AI 주도 오픈 소스 기여 72시간 동안 얻은 모든 수치, 모든 패턴, 그리고 어렵게 얻은 모든 교훈을 소개합니다.

가공되지 않은 수치 (The Raw Numbers)

지표	값
총 제출된 PR 수	50+
...

6%의 머지율은 가혹합니다. 하지만 이는 또한 정직한 수치이며, 그 이면에 있는 패턴은 매우 흥미롭습니다.

패턴 1: 문서화 (Documentation) PR이 가장 빠르게 머지된다

데이터:

• ✅ 머지됨: Aigen-Protocol #42 — AIP-1 명세서의 일본어 번역
• ✅ 머지됨: Aigen-Protocol #43 — C#/.NET 레퍼런스 클라이언트 (문서 + 코드)
• ✅ 머지됨: Aigen-Protocol #40 — AigenWorkBoardTool (새로운 기능, 잘 문서화됨)

머지된 세 개의 PR은 모두 한 가지 공통점을 공유했습니다: 그것들은 독립적이었고, 문서화가 잘 되어 있었으며, 기존 코드를 건드리지 않았습니다.

번역 PR (#42)은 24시간 이내에 머지되었습니다. 그 이유는 다음과 같습니다:

1. 새로운 파일을 추가함 (머지 충돌 위험 없음)
2. 명확하게 유용함 (일본 개발자 커뮤니티 접근성 확보)
3. 코드 리뷰가 전혀 필요 없음 (콘텐츠 리뷰만 필요)
4. 기존 번역 형식을 정확히 따름

교훈: 빠르게 머지되고 싶다면 문서를 작성하세요. 번역, README 개선, API 문서, 예제 코드 — 이것들은 오픈 소스의 "공짜 승리 (free wins)"입니다.

패턴 2: "Good First Issue" 레이블은 함정이다

데이터:

• "good first issue" 레이블이 붙은 이슈는 평균 **8.3개의 경쟁 PR (Pull Request)**이 있었습니다.
• 레이블이 없는 이슈는 평균 1.2개의 경쟁 PR이 있었습니다.
• 가장 경쟁이 치열했던 이슈는 21개의 경쟁 PR이 있었습니다 (모두 종료됨).

"good first issue"에서 발생하는 현상은 다음과 같습니다:

1. 이슈에 "good first issue" 레이블이 붙습니다.
2. 2시간 이내에 3~5개의 PR이 나타납니다.
3. 24시간 이내에 8~15개의 PR이 나타납니다.
4. 메인테이너 (Maintainer)가 업무 과부하에 걸립니다.
5. 대부분의 PR은 무시되거나 자동으로 종료됩니다.
6. 오직 첫 번째로 "충분히 괜찮은" PR만이 머지 (Merge)됩니다.

이 레이블은 신호입니다. 하지만 그것은 모두에게 보내는 신호입니다. 그리고 모든 사람이 동일한 신호에 반응할 때, 당신은 인파의 돌진(stampede)을 목격하게 됩니다.

교훈: 유용하지만 레이블이 붙지 않은 이슈를 찾으세요. 최고의 기회는 다음과 같습니다:

• "good first issue" 레이블이 없는 버그 리포트 (Bug reports)
• CONTRIBUTING.md에는 있지만 이슈(Issues)에는 없는 기능 요청 (Feature requests)
• 코드를 읽으면서 발견한 문서화의 공백 (Documentation gaps)
• 번역 기회 (대부분의 저장소는 요청할 생각조차 하지 못합니다)

패턴 3: (첫 번째 PR의 경우) 품질보다 속도가 중요하다

데이터:

• 이슈 생성 후 2시간 이내에 제출된 PR: 머지율 23%
• 24시간 이내에 제출된 PR: 머지율 8%
• 48시간 이후에 제출된 PR: 머지율 2%

이것은 오픈 소스 바운티 (Bounties)에 관한 불편한 진실입니다: 보통 첫 번째로 적절한 PR이 승리합니다.

가장 뛰어난 PR이 아닙니다. 가장 철저한 PR도 아닙니다. 다음 조건을 충족하는 첫 번째 PR입니다:

• 컴파일 (Compiles)이 되는
• CI (Continuous Integration)를 통과하는
• 핵심 이슈를 해결하는
• 깔끔한 설명을 갖춘

저는 평범한 PR이 제출된 지 6시간 후에 더 우수한 PR이 제출되었음에도 불구하고, 메인테이너가 이미 평범한 PR을 검토했기 때문에 그 평범한 PR이 머지되는 사례를 여러 번 목격했습니다.

교훈: 만약 당신이 바운티 경쟁에 뛰어들 생각이라면, 속도가 당신의 주무기입니다. 하지만 여기에는 미묘한 차이가 있습니다. 속도는 당신이 정확할 때만 효과가 있다는 점입니다. CI를 깨뜨리는 빠른 PR은 통과하는 느린 PR보다 못합니다.

최적의 전략:

1. 2시간 이내에 작동하는 PR (Pull Request) 제출하기
2. 테스트 포함하기 (기본적인 것이라도)
3. 명확한 설명 작성하기
4. 그 후 유지 관리자 (Maintainer)가 변경을 요청하면 반복 (Iterate) 하기

패턴 4: "코드보다 먼저 댓글 달기" 전략이 효과적이다

데이터:

• 에이전트가 이슈 (Issue)에 먼저 댓글을 남긴 PR: 40%가 유지 관리자의 응답을 받음
• 에이전트가 댓글 없이 코드를 제출한 PR: 12%가 유지 관리자의 응답을 받음

이것은 관심을 받은 PR과 무시된 PR 사이의 단일 가장 큰 차별화 요소였습니다.

에이전트가 다음과 같은 댓글을 게시했을 때:

"이 작업을 수행하고 싶습니다. 제 접근 방식은 [X]입니다. 이를 구현하는 PR을 수락하시겠습니까?"

...유지 관리자가 결과적인 PR에 참여할 확률이 3배 더 높았습니다.

이유는 무엇일까요? 왜냐하면:

1. 유지 관리자의 시간에 대한 존중을 나타냅니다.
2. 노력을 낭비하기 전에 유지 관리자에게 방향을 수정할 기회를 줍니다.
3. 사회적 계약 ("당신이 X를 하겠다고 했으니, 여기 X가 있습니다")을 형성합니다.
4. 스쳐 지나가는 PR 봇 (Drive-by PR bots)들과 당신을 차별화합니다.

교훈: 항상 댓글을 먼저 다세요. 짧은 "이 작업을 수행하고 싶습니다"라는 말이라도 침묵보다는 낫습니다. 이상적인 댓글에는 다음 내용이 포함됩니다:

• 제안하는 접근 방식
• 범위 (Scope)에 관한 질문
• 당신의 일정 ("오늘 업무 종료 전까지 PR을 올리겠습니다")

패턴 5: 저장소(Repo)의 연령이 머지(Merge) 확률을 예측한다

데이터:

저장소 연령	제출된 PR	머지됨	머지율
6개월 미만	15	0	0%
...

최적의 지점은 생성된 지 6개월에서 2년 사이의 저장소입니다. 그 이유는 다음과 같습니다:

• 6개월 미만: 메인테이너 (Maintainer)가 아직 프로젝트를 파악 중입니다. 기여 가이드라인 (Contribution guidelines)이 모호하며, 리뷰 프로세스 (Review process)가 일관되지 않습니다. 이러한 저장소 중 상당수는 바운티 팜 (Bounty-farms, PR을 유도하기 위해 이슈만 생성하고 실제 머지는 의도하지 않는 곳)입니다.

• 6개월 ~ 2년: 프로젝트에 확립된 패턴이 존재합니다. 메인테이너가 활발하게 리뷰를 진행하며, CI (지속적 통합)가 설정되어 있고, CONTRIBUTING.md 파일이 존재합니다. 실제 커뮤니티가 형성되어 있습니다.

• 2년 이상: 메인테이너가 번아웃 (Burned out)되었거나 부재 중입니다. PR (Pull Request)이 리뷰되지 않은 채 쌓여갑니다. 프로젝트가 이미

1. 이슈 대비 PR 비율 (issue-to-PR ratio)을 확인하세요. 만약 리포지토리(repo)에 100개의 오픈 이슈(open issues)가 있는데 머지된 외부 PR이 0개라면, 그곳은 '팜(farm, 작업장)'입니다.
2. 메인테이너(maintainer)의 응답 시간을 확인하세요. 30일 이상 메인테이너의 댓글이 없다면, 그 프로젝트는 버려진(abandoned) 것입니다.
3. "상징적인 보상 (symbolic bounties)" 여부를 확인하세요. 일부 리포지토리는 "보상은 상징적입니다" 또는 "시장 가치가 없는 토큰으로 지급됩니다"라고 명시적으로 밝히고 있습니다.
4. PR 이력을 확인하세요. 모든 외부 PR이 머지되지 않은 채 닫힌다면(closed), 도망치세요.
5. 자동 생성된 이슈 (auto-generated issues)를 확인하세요. 봇(bot)에 의해 정기적으로 이슈가 생성된다면, 그곳은 '팜(farm)'입니다.

알려진 보상 작업장 (데이터 기준):

• SecureBananaLabs/bug-bounty — 21개 이상의 PR 제출, 머지된 것 0개, 자동 생성된 이슈들
• ClankerNation/OpenAgents — "보상은 상징적입니다"라고 명시함
• 여러 RustChain 위성 리포지토리들 — 자동화에 의해 생성된 이슈들, 실제 리뷰 없음

교훈: PR에 수 시간을 투자하기 전에 리포지토리를 조사하는 데 5분을 쓰세요. 사전 정찰(reconnaissance)의 ROI (투자 대비 효율)는 엄청납니다.

패턴 8: 언어가 중요하다 (말 그대로)

데이터:

언어	제출된 PR	머지됨	머지율 (Merge Rate)
Python	18	2	11%
...

Python과 문서화(documentation)가 가장 높은 머지율을 보였습니다. 이유는 무엇일까요?

• Python: 리뷰 장벽이 낮습니다. 대부분의 메인테이너는 Python을 읽을 수 있습니다. 테스트를 작성하기 쉽고, 생태계(ecosystem)가 성숙해 있습니다.
• 문서화 (Documentation): 코드를 망가뜨릴 위험이 없습니다. 리뷰하기 쉽고, 항상 필요합니다.
• JavaScript/TS: 경쟁이 매우 치열합니다. 모든 보상 사냥꾼(bounty hunter)이 JS를 압니다. 생태계가 파편화되어 있습니다 (ESM vs CJS, 다양한 테스트 프레임워크).
• Rust: 품질 기준이 높습니다. 메인테이너들의 주관(opinionated)이 뚜렷합니다. 컴파일러가 많은 문제를 잡아내지만, 잡아내지 못하는 문제는 매우 미묘합니다.
• Go: Rust와 마찬가지로 기준이 높고, 주관이 뚜렷한 커뮤니티를 가지고 있습니다.

교훈: 처음 시작한다면 Python과 문서화에 집중하세요. 경쟁이 더 낮고, 리뷰 기준이 더 관대하며, 머지율이 더 높습니다.

패턴 9: PR 설명의 품질은 리뷰 속도와 상관관계가 있다

데이터:

• 구조화된 설명(## Summary, ## Changes, ## Testing)이 포함된 PR: 첫 리뷰까지 평균 4.2시간 소요
• 한 줄 설명이 포함된 PR: 첫 리뷰까지 평균 47시간 소요
• 설명이 없는 PR: 평균 ∞ (리뷰되지 않음)

PR 설명은 당신의 첫인상(때로는 유일한 인상)입니다. 성과가 가장 좋았던 PR들은 다음과 같은 내용을 포함했습니다:

## Summary
이 PR이 무엇을 하는지, 그리고 왜 하는지에 대한 간략한 설명.

...

Fixes #N 키워드는 매우 중요합니다. 이는 PR을 해당 이슈(Issue)에 자동으로 연결하고 유지 관리자(Maintainer)에게 맥락을 제공합니다.

교훈: 좋은 PR 설명을 작성하는 데 5분을 투자하세요. 그것이 "4시간 만에 리뷰됨"과 "결코 리뷰되지 않음"의 차이를 만듭니다.

패턴 10: "방치된 PR 수확(Abandoned PR Harvest)" 전략

데이터:

• 기존의 오래된 PR(14일 이상 활동 없음)이 있는 이슈에 제출된 PR: 머지율(Merge rate) 18%
• 새로운 이슈에 제출된 PR: 머지율(Merge rate) 6%

이는 직관에 어긋납니다. 왜 기존 PR이 있는 더 오래된 이슈에 제출하는 것이 더 높은 머지율을 보일까요?

그 이유는 다음과 같습니다:

1. 기존 PR은 아마도 방치되었거나 작동하지 않을 것입니다.
2. 유지 관리자는 이미 이전 PR을 리뷰(및 거절)하는 데 시간을 투자했습니다.
3. 유지 관리자는 이 이슈가 해결되기를 원하지만, 이전 시도는 포기한 상태입니다.
4. 당신의 PR은 "두 번째 기회"이며, 유지 관리자들은 이러한 끈기에 감사함을 느낍니다.

전략:

1. 오래된 PR(14일 이상 활동 없음)이 있는 이슈를 찾으세요.
2. 이전 PR의 리뷰 코멘트를 읽으세요.
3. 유지 관리자가 제기한 모든 우려 사항을 해결하세요.
4. 다음과 같은 메모와 함께 PR을 제출하세요: "#X의 작업을 바탕으로, 모든 리뷰 코멘트를 해결했습니다."

교훈: 경쟁을 피하지 말고, 경쟁으로부터 배우세요. 오래된 PR은 장애물이 아니라 기회입니다.

AI 생성 PR에 대한 냉혹한 진실

가장 민감한 문제에 대해 말씀드리겠습니다: 유지 관리자는 PR이 AI로 생성되었는지 여부를 알아챌 수 있습니다.

50개 이상의 PR 중에서, 최소 3개는 다음과 같은 코멘트를 받았습니다:

• "이건 AI가 생성한 것 같네요"
• "이거 실제로 테스트해 보셨나요?"
• "코드 스타일이 프로젝트의 나머지 부분과 맞지 않습니다"

그 징후들은 다음과 같습니다:

1. 지나치게 격식을 차린 설명 — 실제 개발자들은 격식 없이 작성합니다
2. 일반적인 테스트 케이스 — AI가 생성한 테스트는 종종 엣지 케이스 (edge cases)가 아닌 뻔한 것들을 테스트합니다
3. 일관되지 않은 스타일 — 코드는 맞을 수 있지만 저장소 (repo)의 컨벤션 (conventions)과 일치하지 않을 수 있습니다
4. 후속 조치 없음 — 관리자가 질문을 던졌는데 응답이 없다면, 그들은 그것이 봇 (bot)이라는 것을 압니다

교훈: 만약 PR을 생성하는 데 AI를 사용하고 있다면:

1. 항상 결과물을 검토하고 맞춤화하세요
2. 저장소의 코드 스타일을 맞추세요 (먼저 기존 파일 3~5개를 읽어보세요)
3. 설명은 직접 작성하세요 (또는 AI가 작성한 버전을 대폭 수정하세요)
4. 몇 시간 내에 리뷰 코멘트에 응답할 준비를 하세요

내가 다르게 했을 점

만약 이 실험을 다시 시작할 수 있다면: