오픈 소스 기여자 생존 가이드: 240개의 PR을 통해 배운 인간 본성, 프로젝트 정치, 그리고 머지(Merge)의 기술

50개 이상의 저장소(Repository)에서 발생한 240개의 풀 리퀘스트(Pull Request, PR)로부터 얻은 실제 데이터입니다. 과장도, 이론도 아닙니다. 대규모로 오픈 소스에 기여하려고 할 때 실제로 어떤 일이 벌어지는지에 대한 이야기입니다.

아무도 요청하지 않은 실험

3주 전, 저는 단순한 질문에 답하기 위해 나섰습니다. 2026년에 풀 리퀘스트(PR)를 머지(Merge)시키려면 실제로 무엇이 필요할까?

이론이 아닙니다. "첫 기여를 하는 방법"과 같은 튜토리얼도 아닙니다. 인터넷상의 낯선 사람들에게 코드를 제출할 때 실제로 어떤 일이 일어나는지에 대한 진짜, 거칠고, 때로는 불편한 진실입니다.

저는 50개 이상의 저장소(Repository)에 걸쳐 240개의 풀 리퀘스트(PR)를 제출했습니다. 72개는 머지(Merge)되었습니다. 90개 이상은 거절되거나 닫혔습니다. 나머지는 여전히 오픈(Open) 상태로 유지 관리자(Maintainer)의 편지함이라는 공허 속에 떠돌고 있습니다.

제가 배운 것들은 다음과 같습니다. 그리고 이것은 그 어떤 가이드에서도 말해주지 않을 내용입니다.

아무도 말하지 않는 숫자들

가공되지 않은 데이터부터 시작하겠습니다. 체리 피킹(Cherry-picking)이나 생존 편향(Survivorship bias)은 없습니다.

전체 통계

총 제출된 PR 수: 240+
머지(Merge)된 PR 수: 72개 (수락률 30%)
거절/닫힌 PR 수: 90개 이상 (37.5%)
여전히 오픈(Open)된 PR 수: 약 78개 (32.5%)
대상 저장소(Repository) 수: 50개 이상
실제로 머지(Merge)가 일어난 저장소 수: 8개 (저장소의 16%)
기간: 30일

파레토 분포(Pareto Distribution)는 실재한다

저를 놀라게 했던 분포는 다음과 같습니다:

저장소(Repository)	머지(Merge)된 PR	제출된 PR	수락률
HELPDESK.AI	28	45	62%
...
8개의 저장소가 머지(Merge)된 PR의 100%를 차지했습니다. 나머지 42개 이상의 저장소는요? 머지가 단 하나도 없었습니다. 제로입니다.

이것은 우연이 아닙니다. 이것이 2026년 오픈 소스 기여의 근본적인 현실입니다: 대부분의 저장소는 외부의 PR을 머지(Merge)하지 않습니다.

오픈 소스 기여의 7가지 죽음의 함정

240개의 PR을 거치며, 저는 리뷰가 시작되기도 전에 PR을 죽게 만드는 7가지 패턴을 식별했습니다. 이것들을 피한다면 수백 시간을 아낄 수 있을 것입니다.

죽음의 함정 #1: 유령 저장소 (The Ghost Repository)

겉모습: 활발한 이슈 (Issues), 최근 커밋 (Commits), "기여를 환영합니다!"라는 문구가 적힌 친절한 README.

실체: 유지 관리자 (Maintainer)의 PR만 머지 (Merge)되는 저장소. 외부 기여는 몇 달 동안 방치되다가, "감사합니다, 저희는 이 기능을 다른 방식으로 구현했습니다"라는 정중한 답변과 함께 닫혀버립니다.

탐지 방법: 최근 머지된 20개의 PR을 확인하세요. 만약 모두 동일한 1~2명의 기여자로부터 온 것이라면, 이곳에서 외부 PR은 머지되지 않습니다. 그것으로 끝입니다.

실제 사례: 저는 2,000개 이상의 스타 (Stars)를 보유한 저장소에 5개의 PR을 제출했습니다. 5개 모두 기술적으로 정확했고, 기여 가이드라인 (Contributing guidelines)을 준수했으며, 테스트 (Tests)도 포함되어 있었습니다. 하지만 5개 모두 2주 이상 방치되었습니다. 확인해 보니, 최근 머지된 50개의 PR은 모두 동일한 유지 관리자의 것이었습니다.

죽음의 함정 #2: 바운티 미끼 (The Bounty Honeypot)

겉모습: 달러 금액이 적힌 "bounty" 라벨이 붙은 이슈 (Issues). "이 버그를 수정하고 500달러를 버세요!"

실체: 무료 노동을 얻어내기 위해 설계된 미끼 (Honeypot). 바운티 (Bounty)는 존재하지 않거나, 불가능한 조건을 요구하거나, 유지 관리자가 당신의 PR을 거절할 온갖 이유를 찾아낼 것입니다.

탐지 방법:

저장소가 실제로 바운티를 지급한 적이 있는지 확인하세요 ("bounty paid" 댓글 검색)
경쟁하는 PR의 수를 확인하세요 (10명 이상이 제출했다면, 이는 최저가 경쟁과 같습니다)
"interview를 위해 예약됨 (reserved for interview)" 라벨이 있는지 확인하세요

실제 사례: 한 저장소에는 동일한 바운티 이슈에 대해 15개 이상의 오픈된 PR이 있었습니다. 유지 관리자는 3개월 동안 그중 어떤 것도 리뷰 (Review)하지 않았습니다. 바운티는 실제 보상이 아니라 트래픽을 끌어모으기 위한 자석이었습니다.

죽음의 함정 #3: 스타일 경찰 (The Style Police)

겉모습: 50페이지가 넘는 스타일 규칙이 담긴 CONTRIBUTING.md. "탭 (Tabs)을 사용하세요, 스페이스 (Spaces) 말고. 아니 잠시만요, 스페이스를 쓰세요. 사실, VSCode 버전 1.73.2에서만 작동하는 저희 전용 포맷터 (Formatter)를 사용하세요."

실체: 기능성보다 스타일 준수가 더 중요한 저장소. 당신의 PR에는 줄 바꿈 (Line endings)에 대한 15개의 리뷰 댓글이 달리겠지만, 실제 코드에 대한 댓글은 단 하나도 없을 것입니다.

감지 방법: 최근 5개의 코드 리뷰 (Code reviews)를 읽어보세요. 만약 리뷰의 90%가 스타일 관련 지적 (Nitpicks)이고 실질적인 내용 (Substance)이 10% 미만이라면, 도망치세요.

죽음의 함정 #4: 움직이는 타겟 (The Moving Target)

겉모습: 명확한 요구사항이 있는 이슈 (Issue). "다크 모드 지원을 추가해 주세요."

실체: 코드를 푸시 (Push)할 때마다 요구사항이 바뀝니다. "사실, 시스템 설정 감지 (System preference detection) 기능이 필요해요.", "이제 기기 간 동기화가 필요합니다.", "아, 다른 색상 체계 (Color scheme)를 사용하기로 결정했습니다."

감지 방법: 해당 이슈가 여러 번 수정되었는지 확인하세요. 이전의 PR (Pull Requests)들이 "방식을 변경했습니다"라는 이유로 닫혔는지 확인하세요.

죽음의 함정 #5: AI 에이전트의 무덤 (The AI Agent Graveyard)

겉모습: 명확한 지침이 포함된 "초보자를 위한 좋은 이슈 (Good first issue)".

실체: 이미 15개의 AI 에이전트가 PR을 제출한 이슈입니다. 메인테이너 (Maintainer)는 업무 과중에 시달리고 있고, PR들은 모두 동일한 해결책의 미세하게 다른 변형들뿐이며, 메인테이너가 15개의 PR을 모두 검토할 수 없기 때문에 그 중 어느 것도 머지 (Merge)되지 않을 것입니다.

감지 방법: 해당 이슈에 열려 있는 PR의 개수를 확인하세요. 만약 3개보다 많다면 건너뛰세요. 메인테이너는 이미 허우적거리고 있습니다.

실제 사례: 한 인기 있는 저장소 (Repository)에 23개의 열린 PR이 달린 "초보자를 위한 좋은 이슈"가 있었습니다. 메인테이너는 다음과 같이 댓글을 남겼습니다: "이 이슈에 대해 더 이상 PR을 제출하지 말아 주세요. 순서대로 검토 중이며 몇 주가 걸릴 예정입니다."

죽음의 함정 #6: 죽은 이슈 (The Dead Issue)

겉모습: 6개월 전부터 열려 있는 이슈. "이 작업에 도움을 주시면 감사하겠습니다!"

실체: 메인테이너가 조용히 방치한 이슈입니다. 이론적으로는 여전히 필요하다고 생각하기 때문에 이슈를 닫지는 않겠지만, 실제로 그에 대한 PR을 검토하는 일은 절대 없을 것입니다.

감지 방법: 메인테이너의 댓글 없이 3개월 이상 지난 이슈라면 죽은 이슈입니다. 다른 곳으로 넘어가세요.

죽음의 함정 #7: 범위 확장 함정 (The Scope Creep Trap)

겉모습: 간단한 버그 수정 (Bug fix). "README의 오타를 수정해 주세요."

실제 모습: 메인테이너 (Maintainer)는 당신의 PR (Pull Request)을 15가지의 다른 변경 사항을 요청할 기회로 삼을 것입니다. "하는 김에 문서도 업데이트하고, 테스트도 추가하고, 모듈을 리팩터링 (Refactor)하고, 로고도 다시 디자인해 줄 수 있나요?"

감지 방법: 메인테이너가 PR 범위를 확장해 온 이력이 있는지 확인하세요. 만약 그들이 닫은(Closed) PR들에 20개 이상의 리뷰 코멘트가 달려 있다면, 그들은 스코프 크리프 (Scope Creep) 유발자입니다.

PR이 실제로 머지(Merge)되는 5가지 패턴

이제 좋은 소식을 전해드리겠습니다. 240개의 PR을 거치며, 저는 머지될 확률을 극적으로 높여주는 다섯 가지 패턴을 발견했습니다.

패턴 #1: 신뢰도 저장소 전략 (The Credibility Repository Strategy)

통찰: 무작위 저장소 (Repository)에 제출하지 마세요. 외부 PR을 실제로 머지해 주는 2~3개의 저장소를 찾아 정기적인 기여자 (Contributor)가 되십시오.

효과가 있는 이유: 메인테이너는 자신이 인지하고 있는 기여자의 PR을 머지할 가능성이 더 높습니다. 3~4번째 PR이 머지되고 나면 당신은 "신뢰할 수 있는 기여자"가 되며, 당신의 PR은 더 빠르게 리뷰됩니다.

실제 데이터: 제가 머지시킨 PR의 100%는 단 8개의 저장소에서 나왔습니다. 나머지 42개 이상의 저장소에서의 머지율은 0%였습니다.

찾는 방법:

외부 기여자의 최근 머지된 PR이 있는 저장소를 검색합니다.
내부 기여자와 외부 기여자의 PR 비율을 확인합니다.
PR 리뷰에서 메인테이너의 참여가 활발한 저장소를 찾습니다.

패턴 #2: 번역 파이프라인 (The Translation Pipeline)

통찰: 번역 PR은 모든 기여 유형 중 수락률이 가장 높습니다.

효과가 있는 이유: 번역은 다음과 같은 특징이 있습니다:

검증이 쉽습니다 (메인테이너가 구글 번역기로 확인할 수 있음)
리스크가 낮습니다 (기능을 변경하지 않음)
가치가 높습니다 (프로젝트의 도달 범위를 확장함)
논쟁의 여지가 적습니다 (맞거나 틀리거나 둘 중 하나임))

실제 데이터: 저의 번역 PR 수락률은 88%였던 반면, 코드 PR의 수락률은 30%였습니다.

예시: 저는 Aigen-Protocol에 22개의 번역 PR을 제출했습니다. 22개 모두 머지되었습니다. 각 PR은 30~45분이 소요되었고, 각각 50개의 AIGEN 토큰을 벌어다 주었습니다.

패턴 #3: 테스트 스위트 전략 (The Test Suite Strategy)

통찰 (The insight): 만약 어떤 저장소(Repository)에 코드는 있지만 테스트가 없다면, 테스트를 추가하는 것이 당신이 할 수 있는 가장 가치 있는 기여입니다.

작동 원리 (Why it works): 메인테이너(Maintainer)들은 테스트가 있어야 한다는 사실을 알고 있지만, 이를 작성할 시간이 없습니다. 당신이 테스트를 추가할 때, 당신은 다음을 수행하는 것입니다:

그들의 기술 부채 (Technical debt)를 줄여줌
코드베이스 (Codebase)를 더 유지보수하기 쉽게 만듦
당신이 코드를 이해하고 있음을 증명함
그들이 향후 PR을 수락하기 더 쉽게 만듦 (당신의 테스트를 실행할 수 있기 때문)

실제 데이터 (Real data): 나의 테스트 PR은 62%의 수락률을 기록했으며, 기능(Feature) PR보다 3배 더 빠르게 리뷰되었습니다.

패턴 #4: 버그 수정 + 테스트 조합 (The Bug Fix + Test Combo)

통찰 (The insight): 단순히 버그만 수정하지 마세요. 수정 사항이 작동함을 증명하는 테스트를 추가하세요.

작동 원리 (Why it works): 이는 메인테이너가 갖는 가장 큰 우려 사항인 "이 수정이 다른 무언가를 망가뜨리지는 않을까?"라는 질문을 해결합니다. 테스트를 포함함으로써 당신은 다음과 같이 말하는 것입니다: "저는 문제를 해결했을 뿐만 아니라, 문제가 해결되었으며 다시 발생하지 않을 것임을 증명했습니다."

실제 데이터 (Real data): 수정과 테스트를 모두 포함한 PR은 75%의 수락률을 보였습니다. 수정만 포함된 PR의 수락률은 40%였습니다.

패턴 #5: 문서화의 공백 (The Documentation Gap)

통찰 (The insight): 대부분의 저장소에는 문서화의 공백이 존재합니다. 이를 찾아 메우는 것은 리스크는 낮고 가치는 높습니다.

작동 원리 (Why it works): 문서화 PR은 다음과 같은 특징이 있습니다:

리뷰하기 쉬움 (테스트할 코드가 없음)
영향력이 높음 (개발자 경험 (Developer experience)을 개선함)
리스크가 낮음 (무언가를 망가뜨릴 수 없음)
환영받음 (메인테이너들은 문서 작성을 싫어함)

실제 데이터 (Real data): 문서화 PR은 70%의 수락률을 기록했으며, 평균 48시간 이내에 머지(Merge)되었습니다.

메인테이너의 심리학 (The Psychology of Maintainers)

50명 이상의 메인테이너와 상호작용하며, 나는 오픈 소스에서의 인간 본성에 관한 몇 가지 불편한 진실을 배웠습니다.

진실 #1: 메인테이너들은 압도당해 있다

평균적인 메인테이너는 주당 10~20개의 PR을 받습니다. 그들에게는 본업이 있고, 가족이 있으며, 코드 외의 삶이 있습니다. 당신의 PR은 다음 요소들과 그들의 주의력을 두고 경쟁합니다:

그들 자신의 기능 개발 작업
사용자들의 버그 리포트 (Bug reports)
보안 취약점 (Security vulnerabilities)
다른 PR들 (AI가 생성한 PR 포함)

당신에게 주는 시사점: PR (Pull Request)을 검토하기 최대한 쉽게 만드세요. PR 하나당 하나의 변경 사항만 담으세요. 명확한 설명을 작성하세요. 테스트를 포함하세요. 범위 확장 (Scope creep)을 하지 마세요.

진실 #2: 첫인상이 중요하다

메인테이너 (Maintainer)들은 30초 이내에 당신의 PR에 대한 의견을 형성합니다. 만약 PR 설명이 불분명하거나, 커밋 메시지 (Commit messages)가 지저분하거나, 코드가 그들의 스타일을 따르지 않는다면, 그들은 다음 PR로 넘어가 버릴 것입니다.

당신에게 주는 시사점: PR 설명에 10분을 투자하세요. 그것은 코드보다 더 중요합니다.

진실 #3: 신뢰는 시간이 흐르며 쌓인다

특정 리포지토리 (Repository)에 제출하는 첫 번째 PR이 머지 (Merge)되기에 가장 어렵습니다. 열 번째 PR은 가장 쉽습니다. 메인테이너들은 다음과 같은 기여자 (Contributor)들에게 신뢰를 쌓습니다:

깔끔한 코드를 제출하는 사람
피드백에 빠르게 응답하는 사람
스타일 관련 사소한 지적 (Nitpicks)에 논쟁하지 않는 사람
꾸준히 나타나는 사람

당신에게 주는 시사점: 2~3개의 리포지토리를 선택하여 정기적인 기여자가 되세요. 여기저기 뿌리고 기도하는 방식 (Spray and pray)은 피하세요.

진실 #4: 메인테이너에게는 숨겨진 의도가 있다

모든 메인테이너에게는 말로 표현되지 않은 우선순위가 있습니다. 어떤 이들은 코드 품질을 중요하게 생각합니다. 어떤 이들은 사용자 경험 (User experience)을 중요하게 생각합니다. 어떤 이들은 자신의 개인적 브랜드 (Personal brand)를 중요하게 생각합니다. 어떤 이들은 그저 이슈 (Issue)를 닫고 싶어 할 뿐입니다.

당신에게 주는 시사점: 그들의 최근 PR 리뷰들을 읽어보세요. 그들이 무엇을 중요하게 여기는지 이해하세요. 당신의 PR을 그들의 우선순위에 맞추세요.

진실 #5: 리포지토리가 클수록 머지는 더 어렵다

별 (Star) 개수가 10K개 이상인 리포지토리는 기여하기 가장 어렵습니다. 그곳들은 다음과 같은 특징을 가집니다:

엄격한 CI (Continuous Integration) 요구사항
다수의 리뷰어 (Reviewer)
긴 리뷰 주기 (Review cycles)
높은 기준

별 개수가 100~1K개 사이인 리포지토리가 가장 적절한 지점 (Sweet spot)입니다. 그곳들은 다음과 같은 특징을 가집니다:

활발한 메인테이너
합리적인 리뷰 주기
환영하는 커뮤니티
해결해야 할 실제적인 문제들

AI 에이전트 요인

모두가 궁금해하는 문제를 짚고 넘어갑시다. 저는 이 PR들을 제출하는 데 AI 에이전트 (AI agent)를 사용했습니다.

AI 에이전트가 잘한 점

속도 (Speed): 30일 동안 240개의 PR을 제출 (일일 평균 8개 PR)
일관성 (Consistency): 모든 PR이 동일한 템플릿을 준수함
범위 (Coverage): 50개 이상의 리포지토리 (repositories)에서 이슈를 식별함
번역 (Translations): 거의 완벽한 정확도로 22개의 번역 PR을 처리함

AI 에이전트가 잘 못한 점

맥락 (Context): 때때로 메인테이너 (maintainer)가 원하는 더 큰 그림을 놓침
창의성 (Creativity): 해결책이 기술적으로는 정확했으나 항상 우아했던 것은 아님
관계 (Relationships): PR을 더 빠르게 머지 (merge) 시키는 데 도움이 되는 개인적인 유대 관계를 구축할 수 없음
판단 (Judgment): 외부 PR을 머지하지 않는 것이 명확한 리포지토리 (repositories)에 제출하는 경우가 가끔 있었음

인간-AI 협업 패턴

가장 효과적인 패턴은 다음과 같았습니다: