24시간 내내 GitHub Bounty를 사냥하는 AI 에이전트를 구축했습니다 — 아키텍처, 코드, 그리고 100시간 이상의 혹독한 교훈

AI 에이전트에게 GitHub 계정의 모든 권한과 터미널, 그리고 단 하나의 지시 사항인 "돈을 벌어라"를 주면 어떤 일이 벌어질까요? 제가 직접 확인했습니다. 작동하는 아키텍처, 작동하지 않는 코드, 그리고 자율적인 Bounty 사냥의 $0짜리 진실에 대한 모든 것을 공개합니다.

모든 것의 시작이 된 질문

새벽 2시였습니다. bounty 태그가 달린 GitHub 이슈들을 훑어보던 중 한 가지 사실을 깨달았습니다. 이 이슈들 대부분은 몇 주, 심지어 몇 달 동안 열려 있었다는 점입니다. 실제 현금이 걸린 채 누군가 해결해주기를 기다리며 그 자리에 머물러 있었습니다.

어디에는 50달러, 저기에는 500달러. 복잡한 이슈에는 수천 달러가 걸려 있었습니다.

그리고 Bounty를 발견하는 모든 개발자가 느끼는 것과 똑같은 생각이 머릿속을 스쳤습니다. "이 과정을 자동화할 수 있다면 어떨까?"

단순히 검색하는 것뿐만이 아닙니다. 전체 과정 말입니다. Bounty 검색, 코드 분석, 수정 코드 작성, 테스트 실행, PR (Pull Request) 제출, 리뷰 추적, 그리고 대금 수령까지 말이죠.

3주 후, 저는 정확히 그 작업을 수행하는 시스템을 24시간 내내 가동하게 되었습니다. 제가 배운 것들, 그리고 왜 현실이 꿈보다 훨씬 더 미묘한 차이를 보이는지에 대해 말씀드리겠습니다.

아키텍처: 협력하는 7개의 에이전트

제가 구축한 시스템은 단일 에이전트가 아닙니다. 중앙 스케줄러 (Scheduler)에 의해 조율되는 7개의 특화된 에이전트로 구성되어 있으며, 각 에이전트는 Bounty 파이프라인의 서로 다른 단계를 담당합니다.

┌─────────────────────────────────────────────────────────────────┐
│                    ZKA MONEY PRINTER                            │
│                   (Orchestrator / Scheduler)                     │
...

에이전트 1: Bounty Radar (바운티 레이더)

Bounty Radar는 30분마다 실행되며, 순환되는 GitHub 검색 쿼리 세트를 수행합니다:

# 검색 순환 전략 — 각 쿼리는 서로 다른 Bounty 유형을 포착합니다
SEARCH_QUERIES = [
    'bounty is:open',           # 직접적인 Bounty 언급
...

각 결과는 세 가지 축을 기준으로 점수가 매겨집니다:

def competition_score(issue):
    """낮을수록 좋습니다 — 경쟁자가 적다는 의미입니다."""
    comments = issue.get('comments', 0)
...```

핵심적인 통찰: **Bounty 사냥은 속도전입니다**. 보통 첫 번째로 제출된 유효한 PR (Pull Request)이 승리합니다. 2시간이 지나면 5~10명의 다른 사냥꾼들과 경쟁하게 됩니다. 24시간이 지나면 당신은 수정 사항을 제출하는 15번째 사람이 되어 있을 것입니다.

### 에이전트 2: 코드 분석가 (Code Analyst)

단 한 줄의 코드도 작성하기 전에, 코드 분석가는 저장소(Repository)를 클론(Clone)하고 제가 "컨텍스트 수확 (context harvest)"이라고 부르는 작업을 수행합니다:

코드 분석가가 조사하는 항목

1. 저장소 구조 (ls -la, find . -name "*.py" | head -50)
2. 최근 커밋 (git log --oneline -20)
   ...

이 작업은 2~3분이 소요되지만, 거절당하는 PR (Pull Request)로 인해 낭비될 수 있는 수 시간을 아껴줍니다. PR이 닫히는 가장 큰 이유는 코드가 나빠서가 아니라, 프로젝트의 컨벤션 (Conventions)을 따르지 않았기 때문입니다.

### 에이전트 3: PR 엔지니어 (PR Engineer)

여기가 실제 작업이 이루어지는 단계입니다. PR 엔지니어는 다음을 수행합니다:

1. 기능 브랜치(Feature branch) 생성: `git checkout -b fix/issue-{number}`
2. 수정 사항 구현
3. 테스트 작성
4. 로컬에서 테스트 스위트 (Test suite) 실행
5. 적절한 템플릿을 사용하여 PR (Pull Request) 생성

실제로 머지(Merge)되는 PR 템플릿은 다음과 같습니다:

요약 (Summary)

이 PR이 수행하는 작업과 그 이유에 대한 간략한 설명.

...

### 에이전트 4: 아티클 발행가 (Article Publisher)

Bounty 사냥이 백그라운드에서 돌아가는 동안, 아티클 발행가는 Dev.to에 기술 콘텐츠를 생성합니다. 이는 독자를 확보하고 권위를 쌓을 수 있는 병렬적인 수익원입니다.

전략은 다음과 같습니다: Bounty 사냥 시스템을 구축하는 "과정"에 대해 글을 쓰는 것입니다. 독자에게 유용하면서도 에이전트의 능력을 홍보할 수 있는 메타 콘텐츠 (Meta-content)를 만드는 것입니다.

### 에이전트 5-7: 리뷰 트래커 (Review Tracker), 사기 탐지기 (Scam Detector), Bounty 트래커 (Bounty Tracker)

이들은 모니터링 에이전트입니다:

- **리뷰 트래커 (Review Tracker)**: 6시간마다 PR 리뷰를 확인하고 댓글에 응답합니다.
- **사기 탐지기 (Scam Detector)**: 가짜 Bounty 저장소의 블랙리스트를 유지합니다 (이에 대해서는 나중에 자세히 다룹니다).
- **Bounty 트래커 (Bounty Tracker)**: 수익, 승인율을 추적하고 패턴을 식별합니다.

## 기술 스택 (Tech Stack): 실제로 작동하는 것들

### 인프라스트럭처 (Infrastructure)

실제 설정

런타임 (Runtime): Linux VM (Ubuntu 22.04)
AI 모델 (AI Model): Claude/GPT-4 급 (코드 생성용)
...

### GitHub CLI는 당신의 가장 친한 친구입니다

`gh` CLI 도구는 전체 시스템의 중추입니다. 중요한 명령어들은 다음과 같습니다:

바운티 (Bounties) 검색

gh search issues "bounty" --state open --sort created --limit 50

...

### AI 코드 생성 파이프라인 (The AI Code Generation Pipeline)

코드 생성을 구동하는 실제 프롬프트 엔지니어링 (Prompt Engineering)은 다음과 같습니다:

SYSTEM_PROMPT = """당신은 시니어 오픈소스 컨트리뷰터 (Senior open-source contributor)입니다.

규칙 (RULES):
...

핵심 통찰: **최소한의 변경 사항이 머지 (Merge)됩니다.** 만약 이슈에서 특정 함수 내의 버그 수정을 요구한다면, 모듈 전체를 리팩토링 (Refactor)하지 마세요. 건드리지 않은 파일에 타입 힌트 (Type hints)를 추가하지 마세요. 잘 작동하는 코드를 "개선"하려 들지 마세요.

## 실제 결과: 100시간 이상의 데이터

실제 수치를 공유하겠습니다. 유리한 것만 골라내거나 (Cherry-picking) 미화하지 않았습니다.

### 스캔된 바운티 (Bounties Scanned)

| 지표 (Metric) | 수치 (Count) |
| --- | --- |
| 총 스캔된 이슈 (Total issues scanned) | 2,500+ |
| ... | |

네, 제대로 읽으신 게 맞습니다. 100시간 이상의 자율 운영 후 수익은 0달러였습니다.

### PR이 거절된 이유 (Why PRs Got Rejected)

| 이유 (Reason) | 수치 (Count) |
| --- | --- |
| "면접용으로 예약됨" ("Reserved for interview") | 2 |
| ... | |

### 스캠(Scam) 문제

이것이 가장 큰 놀라움이었습니다. **"바운티" 이슈의 상당수가 가짜입니다.**

저는 다음과 같은 특징을 가진 `SecureBananaLabs/bug-bounty` 같은 리포지토리 (Repos)들을 발견했습니다:

- 서로 다른 헌터(Hunters)들로부터 온 21개의 오픈된 PR
- 해당 리포지토리 히스토리 내 머지 (Merge) 기록 0건
- 바운티 라벨이 붙은 자동 생성 이슈
- 실제 코드베이스 (Codebase) 없음 — 오직 README만 존재

스캠 패턴: 리포지토리를 생성하고, 이슈에 "bounty" 라벨을 추가한 뒤, 헌터들이 무료 노동을 위해 PR을 제출하게 만들고, 아무것도 머지하지 않습니다. 헌터들은 아무것도 얻지 못하고, 리포지토리 소유자는 무료 코드를 얻습니다.

저는 현재 `/root/.hermes/scripts/bounty-blacklist.txt`에 블랙리스트를 관리하고 있습니다:

스캠 리포지토리 — PR을 제출하지 마세요

SecureBananaLabs/bug-bounty
ClankerNation/OpenAgents

### 실제로 작동했던 것 (What DID Work)

현재까지 열려 있고 (머지 가능한) 유일한 PR은 `IntersectMBO/govtool-proposal-pillar`에 제출한 것이었습니다. 이는 실제 관리자가 존재하는 실제 프로젝트였습니다. 저는 실제 SSRF 취약점 (CWE-918, CVSS 9.1)을 발견하여 수정 사항을 제출했습니다.

이 PR이 달랐던 점은 다음과 같습니다:

1.  **실제 버그였다** — 단순한 외관상의 문제나 기능 요청이 아니었습니다.
2.  **리포지토리(Repo)가 활발했다** — 최근 커밋이 있었고, 관리자들의 응답이 빨랐습니다.
3.  **경쟁이 낮았다** — 제가 가장 먼저 보고하고 수정했습니다.
4.  **코드 품질이 높았다** — 그들의 스타일과 일치했으며, 테스트를 포함했습니다.

## 2026년의 Bounty 지형: 냉혹하고 솔직한 평가

100시간 이상의 사냥 끝에, 실제 지형은 다음과 같습니다:

### Tier 1: 실제 자금, 높은 진입 장벽

| 플랫폼 | 지급액 | 현실 |
| --- | --- | --- |
| **Immunefi** | $1K-$10M+ | Web3 보안. 깊은 전문 지식이 필요함. 자동화 불가능. |
| ... | | |

### Tier 2: 실제 자금, 포화 상태

| 플랫폼 | 지급액 | 현실 |
| --- | --- | --- |
| **Algora.io** | 다양함 | 바운티당 10-20명의 사냥꾼. 첫 번째 유효한 PR이 승리함. |
| **Direct GitHub** | $50-$500 | 찾는 것 자체가 어려운 부분임. |

### Tier 3: 토큰/미검증

| 플랫폼 | 지급액 | 현실 |
| --- | --- | --- |
| **MergeOS** | MRG 토큰 | 토큰 가치 불명. 0달러의 가치일 수도 있음. |
| ... | | |

### 포화 문제 (The Saturation Problem)

제 생각을 바꾼 수치는 다음과 같습니다: **바운티 생성부터 첫 번째 PR 제출까지의 중앙값(Median time)은 47분입니다.**

어떠한 자동화 시스템이 스캔하고, 분석하고, 제출할 때쯤이면, 인간 사냥꾼(및 다른 AI 에이전트들)이 이미 바운티를 차지한 상태입니다. 유일한 경쟁 우위는 다음과 같습니다:

1.  **속도 (Speed)** — 다른 모든 이들보다 빨라야 합니다.
2.  **품질 (Quality)** — 거절할 수 없을 정도로 훌륭한 것을 제출해야 합니다.
3.  **니치 전문성 (Niche expertise)** — 다른 이들이 해결할 수 없는 바운티를 찾아야 합니다.
4.  **인내심 (Patience)** — 다른 사냥꾼들이 포기한 버려진 클레임(Claims)을 찾아야 합니다.

## 배운 교훈: 내가 다르게 할 것이라면

### 교훈 1: 코드를 짜기 전에 먼저 댓글을 달 것 (Comment First, Code Second)

가장 효과적인 단일 전략은 코드를 제출하는 것이 **아닙니다**. 이슈에 먼저 댓글을 다는 것입니다:

"안녕하세요! 이슈를 분석하여 근본 원인(root cause)을 파악했습니다. 
제가 제안하는 접근 방식은 다음과 같습니다: [간략한 설명]. 
PR (Pull Request)을 제출해도 될까요?"

이렇게 하면 세 가지 효과를 얻을 수 있습니다:

- 시간을 투자하기 전에 메인테이너(maintainer)의 동의를 얻음
- 코드를 보여주지 않고도 역량을 입증함
- 단순한 거래가 아닌 관계를 형성함

### 교훈 2: "인내의 수확 (Patience Harvest)" 전략

새로운 보상(bounty)을 향해 경주하는 대신, 저는 **방치된 클레임 (abandoned claims)**을 찾는 것이 더 성공적이라는 것을 발견했습니다:

마지막 PR이 14일 이전에 제출되었고

PR에 해결되지 않은 CI 실패나 머지 충돌(merge conflicts)이 있는 보상 이슈를 찾습니다

gh search issues "bounty" --state open --updated "<2026-05-16" --limit 50

이것들은 다른 사냥꾼들이 포기한 보상들입니다. 메인테이너는 여전히 유효한 수정 사항을 기다리고 있습니다. 경쟁은 적고, 보상은 동일합니다.

### 교훈 3: 스캠(Scam) 탐지는 필수적입니다

스캠 저장소(repo)에 소비하는 시간은 실제 보상에서 빼앗긴 시간입니다. 저의 탐지 기준은 다음과 같습니다:

```python
def is_scam_repo(repo_data):
    """보상 저장소가 가짜일 가능성이 있는지 확인합니다."""
    red_flags = [
...

교훈 4: 콘텐츠는 보상보다 더 신뢰할 수 있습니다

보상(bounty)으로는 0달러를 벌었지만, 보상 사냥과 병행하여 게시한 Dev.to 기사들은 점점 늘어나는 독자층을 만들어냈습니다. 10개의 기사를 작성한 후:

• 총 조회수 32회
• 증가하는 참여도 (engagement)
• AI/자동화 분야에서의 권위(authority) 구축

콘텐츠는 복리 효과를 가집니다. 보상은 일회성입니다. 하지만 기사는 영원히 조회수를 만들어냅니다.

교훈 5: 인간적인 요소는 대체 불가능합니다

AI 에이전트는 다음을 할 수 있습니다:

• ✅ 보상 검색
• ✅ 코드 분석
• ✅ 수정 사항 생성
• ✅ 테스트 작성
• ✅ PR 제출

AI 에이전트는 다음을 할 수 없습니다:

• ❌ 메인테이너와의 관계 구축
• ❌ 보상 협상
• ❌ 미묘한 리뷰 피드백 처리
• ❌ 저장소의 신뢰 여부에 대한 판단

병목 구간은 코드 생성이 아닙니다. 바로 인간적인 터치(human touch)입니다.

코드: 최소 기능 보상 사냥꾼 (Minimal Viable Bounty Hunter)

직접 구축하고 싶다면, 여기 최소한의 아키텍처가 있습니다:

bounty_radar.py

#!/usr/bin/env python3
"""GitHub에서 바운티 (bounties)를 스캔하고 경쟁 수준에 따라 점수를 매깁니다."""

...

scam_detector.py

#!/usr/bin/env python3
"""시간 낭비를 피하기 위해 가짜 바운티 저장소 (repos)를 탐지합니다."""

...

경제성: 이것은 가치가 있는가?

솔직하게 계산해 봅시다.

시간 투자 (Time Investment)

활동	주당 시간
시스템 개발	20시간 (첫 달)
...

수익 잠재력 (Revenue Potential)

출처	월간 추정치
바운티 (현실적 수치)	$0-$200
...

솔직한 비교

동일한 25시간의 개발 시간을 사용한다면, 당신은 다음과 같은 일을 할 수 있습니다:

• Upwork에서 5개의 프리랜서 작업에 지원 ($각각 $200-$1000)
• 하나의 대규모 오픈 소스 프로젝트 (Open-source project)에 기여 (커리어 자산)
• SaaS 도구 구축 (잠재적으로 월 $1000+)
• 5개의 고품질 기술 아티클 작성 (장기적인 독자층 확보)

바운티 사냥 에이전트는 개발자로서 돈을 버는 가장 효율적인 방법은 아닙니다. 하지만 다음과 같은 가치가 있습니다:

1. 믿을 수 없을 정도로 교육적임 — AI 에이전트 (AI agents), 자동화 (automation), GitHub API, 그리고 오픈 소스 문화에 대해 배울 수 있습니다.
2. 다른 것들을 위한 토대 — 이 아키텍처 (architecture)는 모든 자동화된 워크플로우 (automated workflow)에 적용 가능합니다.
3. 재미 — 당신이 잠든 동안 에이전트가 작동하는 것을 지켜보는 것은 깊은 만족감을 줍니다.

다음 단계: 앞으로의 경로

시스템은 여전히 실행 중입니다. 제가 개선하고 있는 사항들은 다음과 같습니다:

단기 계획 (이번 달)

• 머신러닝 분류기 (ML classifiers)를 사용한 더 나은 스캠 탐지
• "댓글 우선" 워크플로우 (코딩 전 접근 방식 제안)
• 바운티 발견을 위한 Algora.io 연동
• $330-$960 규모의 바운티를 위한 WarpSpeed 가입

중기 계획 (향후 3개월)

• 다국어 지원 (현재는 Python/JS 중심)
• 제출 전 자동 코드 리뷰 (Automated code review)
• 바운티 예측 모델 (어떤 바운티가 지급될 가능성이 높은가?)
• AI 지원 트리아지 (AI-assisted triage)를 원하는 메인테이너 (maintainers)들과의 파트너십

장기 계획 (6개월 이상)

• PR 피드백으로부터 학습하는 자기 개선형 에이전트 (Self-improving agent)
• 블랙리스트를 공유하는 바운티 사냥 에이전트 커뮤니티
• 플랫폼에 구애받지 않는 바운티 발견 (GitHub뿐만 아니라)

결론: 진짜 가치는 아직 돈이 아닙니다

100시간 이상의 시간 끝에 직접적인 수익은 0달러입니다. 하지만 진짜 가치는 결코 돈만이 아니었습니다. 그것은 바로:

1. AI가 할 수 있는 것과 할 수 없는 것을 이해하는 것 — 코드 생성 (Code generation)은 쉽습니다. 판단 (Judgment)은 어렵습니다.
2. 작동하는 시스템을 구축하는 것 — 경제성 (Economics)이 아직 확보되지 않았을지라도, 아키텍처 (Architecture)는 견고합니다.
3. 오픈 소스에 기여하는 것 — 머지(merged)된 단 하나의 PR이 실제 프로젝트가 실제 보안 문제를 해결하는 데 도움을 주었습니다.
4. 콘텐츠를 만드는 것 — 이 글들은 시간이 흐를수록 복리로 쌓이는 독자층을 형성하고 있습니다.

오픈 소스 기여의 미래는 인간과 AI의 협업 (human-AI collaboration)이 될 것입니다. AI가 인간을 대체하는 것이 아니라, 인간이 판단, 관계 형성, 그리고 창의적인 문제 해결을 담당하는 동안 AI가 지루한 부분들을 처리하는 방식입니다.