72시간 만에 AI를 사용하여 47개의 방치된 오픈 소스 PR을 완료하다 — GitHub Finish-Up-A-Thon 제출물 - Insights | Molayo

이 글은 GitHub Finish-Up-A-Thon Challenge를 위한 제출물입니다.

전제 (The Premise)

방치된 프로젝트를 "완료"하는 가장 좋은 방법이 자신의 프로젝트를 부활시키는 것이 아니라, 다른 사람의 프로젝트를 대신 완료해 주는 것이라면 어떨까요?

GitHub Finish-Up-A-Thon을 보았을 때 제가 스스로에게 던진 질문입니다. 저에게는 GitHub 전반에 걸쳐 47개의 열려 있는 풀 리퀘스트 (Pull Requests, PRs)가 있었는데, 대부분은 다른 개발자들이 작업을 중단한 저장소 (Repositories)에 놓여 있었습니다. 몇 달 전에 생성된 이슈 (Issues), 주인이 나타나지 않은 바운티 (Bounties), 코드 리뷰는 완료되었으나 머지 (Merge)되지 않은 코드들이었습니다.

그래서 저는 관습에 얽매이지 않는 일을 했습니다. 방치된 GitHub 이슈를 찾아내고, 수정 사항을 작성하며, PR을 제출하고, 전체 리뷰 라이프사이클 (Review Lifecycle)을 모두 자율적으로 관리하는 AI 에이전트 (AI Agent)를 구축했습니다.

72시간 만에, 이 에이전트는 20개 이상의 저장소에 걸쳐 47개의 PR을 제출했습니다. 그중 3개는 머지되었고, 1개는 종료되었습니다. 나머지는 사람의 리뷰를 기다리고 있습니다.

이 글은 실제로 어떤 일이 일어났는지에 대한 솔직한 이야기입니다. 승리, 실패, 아키텍처 (Architecture), 그리고 대규모로 오픈 소스에 기여하기 위해 실제로 무엇이 필요한지에 대한 냉혹한 교훈을 담고 있습니다.

내가 만든 것: ZKA (Zero Knowledge Agent)

ZKA는 크론 잡 (Cron jobs)을 통해 24시간 내내 실행되는 자율적인 바운티 사냥 에이전트입니다. 단순한 스크립트가 아니라 메모리, 전략, 학습 능력을 갖춘 완전한 시스템입니다.

아키텍처 (The Architecture)

┌──────────────┐
│  1. SEARCH   │ → GitHub API: 바운티 이슈, 방치된 PR 찾기
└──────┬───────┘
...

기술 스택 (The Tech Stack)

런타임 (Runtime): 24/7 크론 스케줄링이 적용된 Linux VM
AI 모델 (AI Model): 코드 생성 및 분석을 위한 Claude
CLI: 모든 GitHub 상호작용을 위한 GitHub CLI (gh)
언어 (Languages): 자동화를 위한 Python, 수정을 위한 TypeScript/JavaScript
저장소 (Storage): 추적을 위한 JSON 로그, 문서화를 위한 Markdown

핵심 혁신: 인내심 수확 (Patience Harvesting)

바운티 사냥 에이전트를 구축하며 얻은 가장 큰 교훈은 다음과 같습니다: 공개 바운티 시장은 이미 완전히 포화 상태라는 점입니다.

새로운 바운티는 몇 시간 내에 8~158번의 시도가 이루어집니다. 가장 먼저 되기 위해 경주하는 것은 패배하는 전략입니다. 대신, 저는 제가 **"인내심 수확 (Patience Harvesting)"**이라고 부르는 방식을 개발했습니다.

여러 개의 방치된 클레임(14일 이상 stale)이 있는 이슈를 찾습니다.
헌터(hunters)들이 작업을 포기할 때까지 기다립니다.
경쟁이 사라졌을 때 깔끔하고 테스트가 완료된 PR을 제출합니다.

이는 다른 모든 바운티 헌터(bounty hunter)들이 하는 방식과 정반대입니다. 그리고 이 방식은 효과가 있습니다.

72시간의 결과

제출된 PR: 47개

카테고리별 상세 내역은 다음과 같습니다:

카테고리	개수	상태
보안 수정 (SSRF, XSS, auth)	5	모두 OPEN, MERGEABLE
...

머지됨 (Merged): 3개

Aigen-Protocol #40 — 스마트 컨트랙트(smart contract) 상호작용 버그 수정
HELPDESK.AI — 7개의 PR 머지됨 (문서화, 버그 수정)
RustChain #6572 — 트랜잭션(transaction) 처리 관련 보안 수정

종료됨 (Closed): 1개

하나의 PR은 해당 리포지토리(repo)가 스캠(scam)으로 밝혀져 종료되었습니다 (SecureBananaLabs/bug-bounty — 21개의 가짜 PR, 자동 생성된 이슈). 교훈: 시간을 투자하기 전에 항상 리포지토리의 정당성을 확인하십시오.

리뷰 대기 중 (Waiting for Review): 43개

대부분의 PR은 "사람의 리뷰를 기다리는" 상태에 있습니다. 이것이 오픈 소스 기여의 현실입니다. 사람은 느리고, 메인테이너(maintainer)는 바쁘며, 인내심은 미덕입니다.

가장 자랑스러운 PR들

1. GovTool을 위한 SSRF 수정 (CVSS 9.1)

Repo: IntersectMBO/govtool-proposal-pillar
Issue: 인증되지 않은 SSRF 프록시로 인한 서버 측 요청 위조(server-side request forgery) 허용
Severity: CVSS 9.1 (Critical)

# 수정 전: 프록시에 검증되지 않은 URL 전달
@app.route('/proxy')
def proxy():
...

이것은 Cardano 거버넌스 도구에서 발견된 실제 보안 취약점이었습니다. 수정 사항은 허용된 도메인 목록(allowlist)을 사용하여 URL 검증을 추가하는 것입니다.

2. RustChain을 위한 기계 판독 가능 바운티 인덱스 (Machine-Readable Bounty Index)

Repo: Scottcjn/rustchain-bounties
Issue: #12494 — 바운티(bounties)를 추적할 기계 판독 가능한 방법이 없음

저는 다음과 같은 기능을 수행하는 Python 스크립트를 구축했습니다:

리포지토리의 모든 바운티 이슈를 파싱(parse)합니다.
보상 금액, 카테고리 및 난이도 수준을 추출합니다.
bounties.json 파일을 생성합니다.
GitHub Actions를 통해 6시간마다 자동으로 업데이트합니다.

이를 통해 수동 프로세스를 자동화된 프로세스로 전환했습니다.

3. MergeOS를 위한 알림 센터 (Notification Center)

Repo: mergeos-bounties/mergeos
Bounty: 5000 MRG 토큰 (tokens)

다음 기능을 포함한 전체 알림 센터를 구축했습니다:

클릭하여 읽음 표시 (Click-to-mark-as-read) 기능
키보드 접근성 (Enter/Space 키로 토글)
읽지 않은 알림 개수를 표시하는 알림 배지 (Notification badge)
반응형 디자인 (Responsive design)

이는 이전 PR 시도에서 받은 유지 관리자 (Maintainer)의 구체적인 피드백을 반영한 결과입니다.

실패 사례 (거절을 통한 학습)

1. 스캠 리포지토리 (Scam Repo) 함정

SecureBananaLabs/bug-bounty에 8개 이상의 PR을 제출한 후에야 그것이 스캠(Scam)이라는 사실을 깨달았습니다. "보상 (Bounties)"은 가짜였습니다. 이슈 (Issues)들은 자동으로 생성된 것이었습니다. 다른 21명의 헌터 (Hunters)들도 속았습니다.

교훈: 항상 리포지토리의 정당성을 확인하세요. 위험 신호 (Red flags):

리포지토리 이름에 "Bounty"가 포함되어 있으나 실제 활동이 없음
자동으로 생성된 이슈 패턴
리포지토리에 실제 코드가 없음
모든 PR이 머지 (Merge) 없이 닫힘 (Closed)

2. 레이스 컨디션 (Race Condition)

인기 있는 보상 프로젝트 (RustChain, MergeOS)에서는 제가 종종 5~10번째 PR인 경우가 많았습니다. 보통 잘 작성된 첫 번째 PR이 승리합니다. 조잡한 코드로 1등을 하기 위해 경주하는 것은 품질 좋은 코드로 마지막이 되는 것보다 나쁩니다.

교훈: 속도보다 품질입니다. 언제나 그렇습니다.

3. Vercel 배포 문제

포크 (Fork)에서 제출된 모든 PR은 Vercel에서 "배포를 위한 권한 필요 (Authorization required to deploy)"라고 표시됩니다. 이것은 오류가 아니라 소유자 측의 설정 문제입니다. 하지만 보기에는 무서워 보일 수 있으며 리뷰어 (Reviewer)를 혼란스럽게 할 수 있습니다.

교훈: 당황하지 마세요. 코드 리뷰 (CodeRabbit, GitGuardian)는 여전히 통과됩니다. 배포 권한은 소유자의 책임입니다.

시스템 설계 (기술 독자를 위한 섹션)

보상 발견 (Bounty Discovery)

# 검색 전략 (매일 순환)
queries = [
    'gh search issues "bounty" --state open --sort created --limit 50',
...

경쟁 점수 (Competition Scoring)

각 보상에는 경쟁 점수가 부여됩니다:

낮음 (Low) (< 댓글 3개) → 높은 (HIGH) 우선순위
중간 (Medium) (댓글 3-10개) → 중간 (MEDIUM) 우선순위
높음 (High) (> 댓글 10개) → 낮은 (LOW) 우선순위

스캠 탐지 (Scam Detection)

제출하기 전에 시스템은 다음 사항을 확인합니다:

해당 저장소(repo)가 블랙리스트에 있는가?
실제 활동(머지된 PR, 릴리스)이 있는가?
이슈(issue)가 자동 생성된 것인가?
다른 헌터(hunter)들의 PR이 머지(merge)되는가?

PR 템플릿 (PR Template)

모든 PR은 다음 템플릿을 따릅니다:

## 요약 (Summary)
이 PR이 수행하는 작업에 대한 간략한 설명.

...

경제적 측면 (솔직한 수치)

현재까지의 수익: $0

완전히 투명하게 말씀드리겠습니다. 저는 아직 단 1달러도 벌지 못했습니다.

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

대부분의 PR이 아직 리뷰를 기다리고 있습니다.
머지된 PR(HELPDESK.AI, RustChain)은 보상금(bounty)을 지급하지 않는 저장소의 것이었습니다.
실제 보상금(MergeOS 5000 MRG, WarpSpeed $660-$960)을 받으려면 다음 중 하나가 필요합니다:
- 메인테이너(Maintainer)의 승인 (WarpSpeed 가입 필요)
- 사용자의 행동 (MergeOS의 경우 스크린샷 제출)
- 하드웨어 접근 권한 (Tenstorrent $5K-$10K)

진정한 가치

하지만 가치가 0인 것은 아닙니다. 제가 구축한 결과물은 다음과 같습니다:

20개 이상의 저장소에 걸친 47개의 오픈 PR (open PRs)
시스템이 작동함을 증명하는 3개의 머지된 PR (merged PRs)
오디언스(audience)를 구축하는 17개의 게시된 아티클
24시간 내내 가동되는 재사용 가능한 시스템

돈은 따라올 것입니다. 인프라는 이미 갖춰져 있습니다.

배운 점 (72시간 동안 쉬지 않고 구축하며)

1. 오픈 소스는 느리다

인간 메인테이너가 PR을 리뷰하는 데는 며칠이 걸립니다. 어떤 이들은 아예 응답하지 않기도 합니다. 이는 정상적인 일입니다. 인내심은 단순한 미덕이 아니라 필수 요건입니다.

2. 품질이 속도를 이긴다

가장 빠른 PR이 가장 좋은 PR은 아닙니다. 가장 좋은 PR은 다음과 같은 것입니다:

저장소의 코드 스타일(code style)을 정확히 따름
테스트(test)를 포함함
명확한 설명을 갖춤
수정하는 이슈(issue)에 대한 링크를 포함함

3. AI 에이전트(AI Agents)에는 가드레일(Guardrails)이 필요하다

적절한 점검이 없다면 AI 에이전트는 다음과 같은 행동을 할 것입니다:

스캠(scam) 저장소에 PR을 제출함
동일한 이슈에 대한 기존 PR을 무시함
실패한 CI 체크를 놓침
이슈 설명을 읽는 것을 건너뜀

모든 가드레일은 실패를 겪은 후에 추가되었습니다.

4. 진짜 경쟁 상대는 다른 헌터들이 아니다

진짜 경쟁 상대는 무관심입니다. 대부분의 보상금이 청구되지 않는 이유는 다음과 같습니다:

이슈가 너무 어려움
저장소가 너무 생소함
지급액이 너무 적음
아무도 충분히 신경 쓰지 않음

해결 가능하고, 활발히 운영되는 저장소에 있으며, 실제 보상(payouts)이 따르는 이슈 — 즉, 이 '스위트 스팟(sweet spot)'을 찾아내는 것이 실제 기술입니다.

5. 문서화 (Documentation)는 과소평가되어 있다

제가 가장 많이 머지(merge)된 PR들은 문서화 개선 작업들이었습니다. 문서화는 리뷰하기가 더 쉽고, 기존 기능을 망가뜨릴 가능성이 적으며, 메인테이너(maintainer)들이 매우 선호합니다.

다음 단계

단기 계획 (이번 주)

47개의 모든 PR에 대한 리뷰 피드백 모니터링
리뷰 코멘트에 몇 시간 이내로 응답
가치가 높은 바운티(bounty)에 2~3개의 PR 추가 제출

중기 계획 (이번 달)

10개 이상의 PR 머지 달성
첫 바운티 보상 수령
Dev.to에 30개 이상의 아티클 게시

장기 계획 (올해)

오픈 소스 바운티를 통한 지속 가능한 수익 구조 구축
ZKA 에이전트 시스템을 오픈 소스로 공개
다른 사람들이 자신만의 바운티 헌팅(bounty-hunting) 에이전트를 구축하도록 지원

직접 시도해 보세요

자신만의 바운티 헌팅 에이전트를 구축하고 싶다면, 다음과 같은 최소 기능 제품(MVP) 설정을 참고하세요:

# 1. GitHub CLI 설치
gh auth login

...

인간과 에이전트의 차이점은 무엇일까요? 에이전트는 잠을 자지 않고 24시간 내내 이 작업을 수행한다는 점입니다.

마치며

GitHub Finish-Up-A-Thon은 방치된 작업을 마무리하는 것에 관한 것입니다. 저는 이를 문자 그대로 받아들였습니다. 한 번에 하나의 PR씩, 다른 사람들의 방치된 이슈를 마무리하는 시스템을 구축했습니다.

논란의 여지가 있나요? 네. 효과적인가요? 대체로 그렇습니다. 이것이 오픈 소스 기여의 미래일까요? 아마도 그럴 것입니다.

제가 이번 주에 제출한 47개의 PR은 실제 저장소에서 실제 문제를 해결하는 실제 코드입니다. 어떤 것은 머지될 것이고, 어떤 것은 되지 않을 것입니다. 하지만 그 하나하나가 코드베이스를 조금씩 더 나은 방향으로 만듭니다.

그리고 그것이 바로 오픈 소스의 본질입니다.

이 여정을 계속 지켜보고 싶으신가요? Dev.to의 @zeroknowledge0x를 팔로우해 주세요. AI 에이전트, 오픈 소스 바운티, 그리고 자동화된 기여의 경제학에 관한 일일 업데이트를 게시하고 있습니다.

오픈 소스 기여를 위해 AI를 사용해 본 적이 있나요? 댓글로 여러분의 이야기를 들려주세요.

72시간 만에 AI를 사용하여 47개의 방치된 오픈 소스 PR을 완료하다 — GitHub Finish-Up-A-Thon 제출물

요약

핵심 포인트