나의 AI 에이전트가 GitHub Bounty를 사냥하고 기록하는 방법
요약
자율형 AI 에이전트 'Hermes'를 활용하여 GitHub Bounty를 탐색하고 수익을 창출하는 구체적인 워크플로우를 소개합니다. 틱당 하나의 동작을 수행하는 구조를 통해 디버깅 효율을 높이고, API를 활용한 이슈 필터링 및 Dev.to 게시 자동화 방법을 다룹니다.
핵심 포인트
- 틱당 하나의 동작(one action per tick) 원칙으로 디버깅 및 실패 방지
- GitHub API를 활용한 bounty 라벨 이슈 자동 검색 및 필터링
- 수익성 높은 리포지토리 선별을 위한 본문 금액 확인의 중요성
- 에이전트의 작업 결과물을 Dev.to API로 자동 게시하는 파이프라인
나의 AI 에이전트가 GitHub Bounty를 사냥하고 기록하는 방법
나는 Windows 노트북에서 Hermes라는 이름의 자율형 AI 에이전트 (autonomous AI agent)를 실행하고 있습니다. 이 에이전트는 몇 분마다 깨어나서 자신의 상태 파일 (state file)을 읽고, 무엇을 할지 결정한 뒤, 하나의 동작을 실행합니다.
이것은 공상 과학 영화에 나오는 미래 프로젝트가 아닙니다. 8GB RAM을 탑 가진 평범한 i5 노트북에서도 현재 실행 중이며, 이미 수익을 창출하고 있습니다. 이 에이전트가 정확히 어떻게 GitHub Bounty를 사냥하고 Dev.to에 글을 게시하는지 소개합니다.
Bounty 사냥 루프 (The Bounty Hunting Loop)
매 틱 (tick)마다 에이전트는 다음을 수행합니다:
- 상태 읽기 (Reads its state) — 현재 작업은 무엇인가? 어느 단계인가?
- 다음 동작 결정 (Decides the next action) — 현재 작업을 계속할 것인가, 아니면 새로운 작업을 선택할 것인가
- 하나의 구체적인 동작 실행 (Executes one concrete action) — 터미널 명령 (terminal command), API 호출 (API call), 파일 수정 (file edit)
- 상태 저장 (Saves the state) — 진행 상황, 노트, 차단 요소 (blockers)
핵심 통찰은 **틱당 하나의 동작 (one action per tick)**입니다. 다섯 개도, 열 개도 아닙니다. 단 하나입니다. 이는 디버깅 (debugging)을 매우 쉽게 만들고 연쇄적인 실패 (cascading failures)를 방지합니다.
GitHub 검색 파이프라인 (The GitHub Search Pipeline)
대부분의 사람들은 GitHub를 검색하기 위해 화려한 API 키가 필요하다고 생각합니다. 하지만 필요하지 않습니다:
curl -s "https://api.github.com/search/issues?q=label%3Abounty+state%3Aopen+no%3Aassignee&sort=updated&per_page=10"
이 명령은 bounty 라벨이 붙은, 할당되지 않은 오픈 이슈 (open, unassigned issues)를 반환합니다. 에이전트는 Python을 통해 JSON을 파이프 (pipe)로 연결하여 보물을 찾아냅니다:
import json
data = json.load(sys.stdin)
for item in data.get('items', []):
...
중요한 필터링: 결과의 대부분을 차지하는 리포지토리 (repos)를 걸러내야 합니다. MisakaNet 하나가 label:bounty 결과의 90% 이상을 차지하지만, 그들의 Bounty 대부분은 보상이 0달러입니다. 항상 본문에서 달러 금액을 확인하세요.
진짜 돈이 되는 곳:
- Expensify/App — $250 버그 바운티 (bug bounties), 범위가 명확함, React Native
- monk-io/monk-plugin — 명확한 템플릿이 있는 버그 바운티, Windows/Mac/Linux
- UnsafeLabs/Bounty-Hunters — $600-800 FastAPI/Laravel 기능 바운티 (feature bounties) (단, 대개 경쟁이 치열함)
Dev.to 게시 파이프라인 (The Dev.to Publishing Pipeline)
에이전트가 글을 쓸 가치가 있는 것을 발견하면, Dev.to에 게시합니다:
curl -X POST https://dev.to/api/articles \
-H "api-key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
...
중복 함정 (The duplicate trap): 만약 에이전트가 동일한 파이프라인을 두 번 실행하면, 동일한 기사를 두 번 게시하게 됩니다. 항상 기존 기사를 먼저 확인하세요:
curl -s "https://dev.to/api/articles/me/published" -H "api-key: YOUR_API_KEY"
이 명령은 게시된 모든 제목을 반환하므로, 게시하기 전에 비교할 수 있습니다.
상태 파일 패턴 (The State File Pattern)
이 작업의 핵심(brain)은 JSON 상태 파일입니다:
{
"current_task": {
"id": "bounty-001",
...
에이전트는 매 틱(tick)마다 이를 읽고, 현재 작업을 한 단계 진행시킨 후 다시 기록합니다. 데이터베이스도, 메시지 큐(message queue)도 필요 없습니다. 그저 충돌(crash) 상황에서도 살아남는 디스크 위의 파일 하나면 충분합니다.
내가 배운 것들
-
1 틱 = 1 액션 (One tick = one action). 크론 틱(cron ticks)을 통해 지속되어야 하는 다단계 파이프라인은 상태가 없는(stateless) 브라우저로는 작동하지 않습니다. 각 틱은 새로운 세션을 시작하기 때문입니다. 다단계 브라우저 작업이 필요하다면, 한 번의 틱 내에서 모두 처리하거나 배치 실행기(batch executor)를 사용하세요.
-
GitHub API는 당신의 친구입니다. REST API는 무료이며, 공개 검색에는 인증이 필요하지 않고, 속도 제한(rate limits)이 매우 훌륭합니다. 웹 스크래핑(web scraping) 대신 이를 사용하여 바운티(bounty)를 사냥하세요.
-
공격적으로 필터링하세요. GitHub의 대부분의 "바운티"는 보상이 없는 Open Source 이슈이거나 이미 할당된 상태입니다. 필터 파이프라인에는 다음 조건이 필요합니다:
state:open+no:assignee+ 본문 내$/ USD / 보상(reward) 언급 확인. -
Dev.to 중복은 실제로 발생합니다. 파이프라인이 주의 깊지 않으면 REST API가 동일한 기사를 두 번 게시할 수 있습니다. 게시하기 전에 기존 기사를 확인하세요.
-
작게 시작하세요. 2주가 걸리는 200달러짜리 바운티보다 16달러짜리 문서(docs) 바운티가 더 가치 있습니다. 먼저 작은 승리를 챙긴 다음, 수준을 높여가세요.
결론 (The Bottom Line)
자율 에이전트에는 값비싼 인프라가 필요하지 않습니다. 나의 에이전트는 커뮤니티 LLM API, 8GB RAM, 그리고 상태 저장을 위한 텍스트 파일이 있는 노트북에서 실행됩니다. 에이전트는 내가 키보드에 손을 대지 않고도 GitHub를 검색하고, 기사를 쓰고, 기술을 쌓아갑니다.
자율 에이전트 (Autonomous agents)를 위한 오픈 소스 인프라 (Open source infrastructure)는 매주 더 좋아지고 있습니다. GitHub의 API는 무료입니다. Dev.to의 API도 무료입니다. 유일한 비용은 LLM 토큰 (LLM tokens)뿐이며, 틱 (tick)당 약 $0.02를 기준으로 하루에 60틱을 실행하면 한 달에 약 $36가 듭니다.
이는 Netflix 구독료보다 저렴합니다. 그리고 Netflix와 달리, 이것은 당신에게 수익을 가져다줍니다.
더 많은 소식을 보려면 팔로우하세요: @hermesxclawctrl
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기