2026년 AI 에이전트를 활용한 GitHub 바운티 헌팅 완벽 가이드 (실제 수익, 실제 코드, 실제 교훈)

GitHub 바운티를 24시간 내내 사냥하는 자율형 AI 에이전트를 구축한 방법 — 아키텍처(Architecture), 도구, 혹독한 교훈, 그리고 오늘 바로 복제할 수 있는 정확한 플레이북(Playbook)을 소개합니다.

요약 (TL;DR)

저는 24시간 내내 작동하며 GitHub에서 유료 오픈 소스 바운티(Bounties)를 검색하고, 이를 평가하며, PR(Pull Request)을 제출하고, 수익을 추적하는 ZKA라는 AI 에이전트를 구축했습니다. 100시간 이상의 실험 끝에, 실제로 작동하는 것과 그렇지 않은 것, 그리고 여러분이 자신만의 바운티 사냥 에이전트를 구축하거나 전략을 수동으로 사용하는 방법은 다음과 같습니다.

주요 발견 사항:

• 공개 바운티 시장은 에이전트로 완전히 포화 상태입니다. 새로운 바운티에는 몇 시간 내에 8~158개의 시도가 이루어집니다.
• **인내심 수확(Patience harvesting)**이 속도 중심의 사냥보다 효과적입니다. 14일 이상 방치된 포기된 클레임(Claims)을 찾으세요.
• 코드를 짜기 전에 먼저 댓글을 남기세요 — 코드를 작성하기 전에 접근 방식을 제안하십시오. 이것만으로도 저의 PR 수락률이 두 배로 뛰었습니다.
• 진짜 돈은 경쟁이 낮은 프라이빗 프로그램(HackerOne, Bugcrowd)과 **니치 레포지토리(Niche repos)**에 있습니다.
• 저는 여러 레포지토리에 걸쳐 40개 이상의 PR을 제출했습니다. 각 PR에 어떤 일이 일어났는지 정리했습니다.

목차

1. 바운티 사냥 AI 에이전트를 구축한 이유
2. 아키텍처: ZKA의 작동 방식
3. 2026년의 바운티 환경
4. 고가치 플랫폼 순위
5. 인내심 수확 전략
6. PR 제출 플레이북
7. 실제 결과: 40개 이상의 PR 분석
8. 사기 탐지: 가짜 바운티를 식별하는 방법
9. 자신만의 에이전트 구축하기 (단계별 가이드)
10. 혹독한 교훈
11. 향후 계획

바운티 사냥 AI 에이전트를 구축한 이유

단순한 질문에서 시작되었습니다: AI 에이전트가 실제로 돈을 벌 수 있을까?

이론적으로만 가능한 것이 아닙니다. 데모 수준도 아닙니다. 실제 레포지토리에 병합되는, 실제 바운티를 통한 실제 돈 말입니다.

저는 2026년 Claude Code, Cursor, GitHub Copilot Workspace, Devin, OpenHands와 같이 AI 에이전트 분야가 폭발적으로 성장하는 것을 지켜보고 있었습니다. 모든 데모는 에이전트가 코드를 작성하고, 버그를 수정하며, 기능을 구축하는 모습을 보여주었습니다. 하지만 거의 아무도 명백한 다음 단계에 대해서는 이야기하지 않았습니다. 만약 에이전트가 유료 작업을 찾아내고, 이를 수행하며, 보상을 받을 수 있다면 어떨까요?

그래서 저는 다음과 같은 기능을 수행하는 자율 시스템인 ZKA (Zero Knowledge Agent)를 구축했습니다:

1. 검색 (Searches): 30분마다 GitHub에서 열려 있는 바운티 (Bounties)를 검색합니다.
2. 평가 (Evaluates): 각 바운티의 난이도, 경쟁 정도, 신뢰성을 평가합니다.
3. 수행 (Works): 가장 좋은 기회에 대해 작업합니다 — 레포지토리 (Repos)를 클론하고, 버그를 수정하며, 테스트를 작성합니다.
4. 제출 (Submits): 전문적인 설명과 적절한 이슈 (Issue) 링크를 포함한 PR (Pull Requests)을 제출합니다.
5. 추적 (Tracks): 결과를 추적하고 거절된 사례로부터 학습합니다.

목표는 인간 개발자를 대체하는 것이 아니었습니다. 바운티 헌팅 (Bounty-hunting) 워크플로우를 증강 (Augment) 하는 것이었습니다. 즉, 반복적인 80%의 작업(검색, 평가, 상용구 PR 작성)을 처리하여 제가 인간의 판단이 필요한 20%에 집중할 수 있도록 하는 것이었습니다.

아키텍처: ZKA의 작동 방식

ZKA는 자율 AI 에이전트를 구축하기 위한 프레임워크인 Hermes Agent 위에서 실행됩니다. 상위 수준의 아키텍처는 다음과 같습니다:

┌─────────────────────────────────────────────────────────┐
│                    ZKA Money Printer                     │
├─────────────────────────────────────────────────────────┤
...

검색 모듈 (The Search Module)

검색 모듈은 다음 쿼리들을 순환하며 실행합니다:

# 기본 바운티 검색
gh search issues "bounty" --state open --sort created --limit 50
gh search issues "reward" --state open --sort created --limit 30
...

각 쿼리는 제목, URL, 댓글 수, 라벨 (Labels), 생성 날짜와 같은 메타데이터가 포함된 이슈를 반환합니다. 에이전트는 블랙리스트에 등록된 레포지토리(이에 대해서는 나중에 자세히 설명하겠습니다)를 필터링하고 후보들을 평가 모듈로 전달합니다.

평가 모듈 (The Evaluation Module)

여기가 마법이 일어나는 지점입니다. 모든 바운티가 추구할 가치가 있는 것은 아닙니다. 평가 모듈은 세 가지 차원에서 각 바운티의 점수를 매깁니다:

1. 신뢰성 점수 (Legitimacy Score) (0-10)

• 해당 리포지토리에 실제 활동이 있는가? (stars, commits, issues)
• 바운티(Bounty)가 실제로 지급되고 있는가? (merged PRs, 지급 내역 확인)
• 이슈(Issue)가 자동 생성되었는가, 아니면 수동으로 생성되었는가?
• 바운티 설명이 진실해 보이는가?

2. 경쟁 점수 (Competition Score) (0-10)

• 이슈에 달린 댓글 수는 얼마인가? (< 3 = 낮음, 3-10 = 중간, > 10 = 높음)
• 이 이슈를 참조하는 기존 PR(Pull Request)은 몇 개인가?
• 이슈가 생성된 지 얼마나 되었는가? (오래되었으나 PR이 없는 경우 = 기회)
• 누군가 활발하게 작업 중인가?

3. 난이도 점수 (Difficulty Score) (0-10)

• 이슈에 어떤 라벨(Label)이 붙어 있는가? (good first issue, bug, feature 등)
• 기술 스택(Tech stack)은 무엇인가? (우리의 역량과 일치하는가?)
• 수정 작업의 복잡도는 어느 정도일 것으로 예상되는가?
• 테스트가 필요한가?

바운티를 추적하려면 합산 점수가 20점을 넘어야 합니다. 에이전트는 보상은 높고, 경쟁은 낮으며, 난이도는 중간 정도인 바운티를 우선순위에 둡니다.

작업 모듈 (The Work Module)

바운티가 평가를 통과하면, 에이전트는 다음 단계를 수행합니다:

1. 리포지토리 클론 (Clones the repo): 로컬 워크스페이스로 복제합니다.
2. 이슈 정독 (Reads the issue): 철저하게 읽습니다 (이 단계는 매우 중요하며, 생략할 경우 위험이 따릅니다).
3. 코드베이스 탐색 (Explores the codebase): 아키텍처를 이해하기 위해 코드를 살펴봅니다.
4. 수정 제안 (Proposes a fix): 댓글을 통해 수정 방안을 먼저 제안합니다 (comment-first approach).
5. 수정 구현 (Implements the fix): 적절한 테스트와 함께 수정을 구현합니다.
6. 로컬 CI 실행 (Runs CI locally): 제출 전 실패를 잡아내기 위해 로컬에서 CI를 실행합니다.
7. PR 생성 (Creates a PR): 전문적인 설명을 포함하여 PR을 생성합니다.

에이전트가 사용하는 PR 템플릿은 다음과 같습니다:

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

...

2026년의 바운티 환경 (The Bounty Landscape in 2026)

솔직하게 말씀드리겠습니다. 공개 바운티 시장은 포화 상태입니다.

AI 에이전트가 어디에나 존재합니다. 인기 있는 리포지토리에 올라오는 모든 새로운 바운티는 몇 시간 내에 8~158개의 시도를 받습니다. 경쟁 상대는 단순히 다른 에이전트만이 아닙니다. 다음과 같은 주체들이 혼재되어 있습니다:

• 수동으로 바운티를 사냥하는 개인 개발자 (Solo developers)
• 속도를 높이기 위해 Copilot/Cursor를 사용하는 AI 증강 개발자 (AI-augmented developers)
• 인간의 검토 없이 PR을 제출하는 ZKA와 같은 완전 자율 에이전트 (Fully autonomous agents)
• 여러 에이전트를 24시간 내내 가동하는 바운티 파밍 운영 조직 (Bounty farming operations)

이는 "바운티를 찾아서, 빠르게 수정하고, 가장 먼저 제출한다"라는 과거의 전략이 인기 있는 저장소(repos)에서는 더 이상 통하지 않음을 의미합니다. 당신은 11번째 PR(Pull Request)이 될 것이고, 메인테이너(maintainers)들은 이미 업무 과부하 상태일 것입니다.

여전히 유효한 전략

1. 인내심 수확 (Patience harvesting) — 원래의 헌터(hunter)가 포기한 방치된 클레임(claims)을 찾으세요.
2. 니치 저장소 (Niche repos) — 잘 알려지지 않았거나 틈새 시장인 프로젝트는 경쟁이 적습니다.
3. 프라이빗 프로그램 (Private programs) — 속도보다 품질이 중요한 HackerOne, Bugcrowd 등을 활용하세요.
4. 댓글 우선 접근 방식 (Comment-first approach) — 코딩을 시작하기 전에 메인테이너의 동의(buy-in)를 먼저 얻으세요.
5. 콘텐츠 바운티 (Content bounties) — 기사, 튜토리얼, 문서화 작업 (에이전트 간의 경쟁이 적습니다).

고가치 플랫폼 순위

저는 2026년의 모든 주요 바운티 플랫폼을 조사했습니다. 솔직한 순위는 다음과 같습니다:

1. Tenstorrent (tt-metal) — $500 ~ $10,000 USD

난이도: 어려움 (Hard)
지급 방식: 은행 송금을 통한 USD
참고 사항: 하드웨어/ML(머신러닝) 중심입니다. 많은 바운티가 Wormhole 보드(특수 하드웨어)를 요구합니다. 만약 하드웨어를 보유하고 있다면, 이것들은 이용 가능한 공개 바운티 중 가장 보상이 높습니다.

바운티 예시:

• fp32용 exp(x) 최적화 — $5,000
• TT Nix 패키지 유지보수 — $2,500
• sinh/cosh (fp32/bf16) 최적화 — $10,000

2. WarpSpeed (warpspeedopen.org) — $330 ~ $960 USD

난이도: 중간 (Medium)
지급 방식: USD
참고 사항: React Native/TypeScript 앱입니다. warpspeedopen.org에서 가입이 필요합니다. 보상이 좋지만 플랫폼의 승인이 필요합니다.

바운티 예시:

• 첨부 파일 요약 서비스 (Attachment Summarizer Service) — $960
• 이메일 스레드 API (Email Threads API) — $750
• 오디오 노트 녹음 (Audio Note Recording) — $750
• 인라인 이미지 편집 (Inline Image Editing) — $660

3. MergeOS — MRG 토큰

난이도: 쉬움 ~ 중간 (Easy to Medium)
지급 방식: MRG 토큰 (가치 불확실)
참고 사항: 명확한 구조를 가진 활발한 바운티 프로그램입니다. 포트폴리오를 구축하기에 좋습니다. 토큰 가치는 프로젝트의 성공 여부에 따라 달라집니다.

바운티 예시:

• 공개 테스트 모드 게시 설정 구축 (Build public test-mode Publish Settings) — 5000 MRG
• 로그인 후 프로젝트 뷰 수정 (Fix project view after login) — 2000 MRG
• 제출된 PR 테스트 및 증거 검증 (Test submitted PRs and verify evidence) — PR당 300 MRG

4. RustChain (Scottcjn/rustchain-bounties) — 1 ~ 200 RTC

난이도 (Difficulty): 쉬움에서 어려움까지
보상 (Payout): RTC 토큰 ($0.10 참조 환율)
참고 사항 (Notes): DePIN (탈중앙화 물리적 인프라 네트워크) 블록체인 프로젝트입니다. 보상은 단순한 콘텐츠 작업부터 복잡한 보안 작업까지 다양합니다. 커뮤니티가 매우 활발합니다.

보상 예시 (Example bounties):

• Harden the Forge — Security Season — 750 RTC 풀 (pool)
• Localization — Docs 번역 — 5 RTC
• Hardware Pioneer — 구형 하드웨어에서 채굴 — 10 RTC

5. Algora.io — 다양함

난이도 (Difficulty): 다양함
보상 (Payout): USD/USDC
참고 사항 (Notes): 보상 마켓플레이스 (Bounty marketplace)입니다. 로그인이 필요합니다. 여러 프로젝트의 보상을 잘 모아두었습니다.

6. Immunefi — $1K에서 $10M 이상

난이도 (Difficulty): 전문가 (Expert)
보상 (Payout): USD/USDC
참고 사항 (Notes): Web3 보안 버그 바운티 (Bug bounties)입니다. 깊은 보안 전문 지식이 필요합니다. 보상이 가장 높지만 진입 장벽도 가장 높습니다.

인내심 수확 전략 (The Patience Harvesting Strategy)

이것은 제가 발견한 가장 중요한 사실입니다. 몇 주 동안 보상 시장을 관찰한 결과, 한 가지 패턴을 발견했습니다.

대부분의 바운티 헌터(Bounty hunters)는 마라톤 선수가 아니라 단거리 선수입니다.

상황은 다음과 같이 진행됩니다:

1. 새로운 보상이 게시됩니다.
2. 몇 시간 이내에 8~15명의 헌터가 이를 수락(claim)합니다.
3. 며칠 이내에 3~10개의 PR (Pull Request)이 제출됩니다.
4. 메인테이너 (Maintainer)가 검토 후 하나를 병합(merge)합니다.
5. 나머지 헌터들은 자신의 작업을 포기합니다.
6. 하지만 포기된 PR들이 이슈를 종료시키지 않기 때문에 이슈는 계속 열려(open) 있습니다.

이로 인해 열려 있는 이슈(open issues)에는 **부분적으로 완료된 작업 (partially-completed work)**들이 무덤처럼 쌓이게 됩니다. 바로 여기서 '인내심 수확 (patience harvesting)'이 빛을 발합니다.

포기된 요청(Abandoned Claims)을 찾는 방법

# bounty 라벨이 붙어 있고, 14일 이상 지났으며, 최근 댓글이 적은 이슈 찾기
gh search issues "bounty" label:bounty --state open --created "<2026-05-16" \
  --sort updated --limit 50 --json repository,title,url,number,commentsCount,updatedAt
...

접근 방식

포기된 요청을 발견했을 때:

1. 원본 이슈(Issue)를 철저히 읽으세요
2. 기존 PR(Pull Request)을 확인하세요 — 다른 사람들은 무엇을 시도했나요? 왜 실패했나요?
3. 먼저 댓글(Comment)을 남기세요 — "이전 PR들이 X를 해결하지 못한 것을 확인했습니다. 저의 접근 방식은 Y입니다. 이를 구현한 PR을 제출해도 될까요?"
4. 메인테이너(Maintainer)의 응답을 기다리세요 — 이 과정은 인내심이 필요합니다.
5. 승인 후에만 구현하세요 — 이제 당신은 선호되는 기여자(Contributor)가 되었습니다.

이 전략은 다음과 같은 이유로 성공 확률이 더 높습니다:

• 다른 50명의 헌터들과 경쟁하며 속도전을 벌일 필요가 없습니다.
• 메인테이너는 이미 좋지 않은 PR들을 보았기에 무엇을 원하는지 알고 있습니다.
• 타인의 실수로부터 배울 수 있습니다.
• 경쟁자들은 이미 더 새로운 바운티(Bounty)로 떠났습니다.

PR 제출 플레이북 (PR Submission Playbook)

40개 이상의 PR을 제출한 후, PR을 머지(Merge)시키기 위해 제가 배운 것들은 다음과 같습니다:

규칙 1: 코딩보다 댓글이 먼저

이것은 단 하나의 가장 중요한 규칙입니다. 코드를 작성하기 전에, 제안하는 접근 방식에 대해 이슈에 댓글을 남기세요. 이를 통해 다음과 같은 효과를 얻을 수 있습니다:

• 메인테이너의 조기 동의(Buy-in)를 얻을 수 있습니다.
• 잘못된 접근 방식으로 인한 노력 낭비를 방지합니다.
• 당신이 문제를 이해하고 있음을 보여줍니다.
• 단순히 한 번 찔러보는 식의 PR 제출자들과 차별화됩니다.

규칙 2: 그들의 스타일을 맞추세요

기존 코드를 읽으세요. 컨벤션(Convention)을 정확히 따르세요:

• 동일한 들여쓰기 (탭 vs 공백)
• 동일한 명명 규칙 (camelCase vs snake_case)
• 동일한 임포트(Import) 스타일
• 동일한 테스트 패턴
• 동일한 커밋 메시지 형식

규칙 3: 작고 집중된 PR

PR 하나당 하나의 이슈만 다루세요. 수정 사항을 섞지 마세요. 관련 없는 코드를 리팩터링(Refactor)하지 마세요. 리뷰어가 검토하기 쉽게 만드세요.

규칙 4: 테스트를 포함하세요

거의 모든 프로젝트는 테스트를 요구합니다. 이슈에서 테스트를 언급하지 않더라도 테스트를 추가하세요. 이는 당신이 품질에 신경 쓰고 있음을 보여줍니다.

규칙 5: 몇 시간 이내에 응답하세요

속도가 바운티를 결정합니다. 메인테이너가 당신의 PR에 댓글을 달면, 며칠이 아니라 몇 시간 이내에 응답하세요. 알림 설정을 해두세요.

규칙 6: 적절한 이슈 연결

PR 설명에 Fixes #N을 사용하세요. 이는 머지될 때 이슈를 자동으로 종료(Close)해 줍니다. 메인테이너들이 매우 선호하는 방식입니다.

규칙 7: 로컬에서 CI 실행

실패하는 CI (Continuous Integration)로 메인테이너의 시간을 낭비하지 마세요. 푸시(Push)하기 전에 로컬에서 테스트를 실행하십시오:

npm test
npm run lint
npm run build

실제 결과: 40개 이상의 PR 분석

제가 제출한 PR (Pull Request)들에 대한 솔직한 분석 결과입니다:

Merged (성공)

• 문서 개선 (Documentation improvements) — 가장 높은 성공률을 보였습니다. 리스크가 낮고 가치가 명확합니다.
• 테스트를 포함한 버그 수정 (Bug fixes with tests) — 수정 사항이 집중되어 있고 테스트가 잘 이루어졌을 때 높은 성공률을 보였습니다.
• 작은 기능 추가 (Small feature additions) — 중간 정도의 성공률을 보였습니다. 기능의 범위(Scope)가 명확할 때 가장 효과적입니다.

Open (리뷰 대기 중)

• SolFoundry #1361 — 바운티 마감 기한을 위한 카운트다운 타이머. 모든 CI 통과, 리뷰 대기 중.
• MergeOS #146 — 읽음/읽지 않음 상태를 포함한 알림 센터. 메인테이너가 참여 중이며, 시각적 증거가 필요함.
• gittensor #1416 — int/str github_id 수정. 머지 가능, 아직 리뷰 없음.
• cloudflare/speedtest #106 — 커스텀 apiUrl의 중복된 '?' 수정. 머지 가능, 아직 리뷰 없음.
• govtool #343 — SSRF 수정 (CWE-918, CVSS 9.1). 머지 가능, 아직 리뷰 없음.

Closed (거절됨)