오픈 소스로 돈을 버는 AI 에이전트를 만들었습니다 — 완전 가이드 (과장 없이, 실제 코드 포함)
요약
오픈 소스 기여를 통해 수익을 창출하는 자율형 AI 에이전트의 실제 아키텍처와 구축 과정을 다룬 가이드입니다. 단순한 데모가 아닌 바운티 스캐너, 트리아지 엔진, PR 파이프라인 등 실질적인 구성 요소를 통해 인간의 노력을 극대화하는 시스템을 소개합니다.
핵심 포인트
- GitHub 바운티 이슈를 탐색하는 크론 기반 스캐너 구축
- 신뢰도와 난이도를 고려한 6가지 차원의 트리아지 엔진 설계
- 자동화된 코드 수정 및 PR 제출 파이프라인 구현
- 기술 아티클 작성을 통한 콘텐츠 파이프라인 연동
이 글은 또 다른 "AI가 모든 것을 바꿀 것이다"라는 식의 과장된 글이 아닙니다. 실제 아키텍처 (Architecture), 실제 실패 사례, 그리고 실제 수치를 바탕으로 오픈 소스 기여를 통해 실제로 수익을 창출하는 AI 에이전트를 구축하는 방법에 대한 냉정하고 솔직한 단계별 가이드입니다.
내가 이것을 만든 이유
매주 "AI 에이전트가 개발자를 대체할 것이다"라고 주장하는 또 다른 기사가 나옵니다. 매주 "AI로 월 1만 달러를 벌 수 있다"고 약속하는 또 다른 Twitter 스레드가 올라옵니다. 그리고 매주 대부분의 개발자들은 이러한 방식들을 시도해 보고 정확히 0달러를 법니다.
나는 다른 것을 만들고 싶었습니다. 데모가 아닙니다. 개념 증명 (Proof-of-concept)도 아닙니다. 유료 오픈 소스 작업을 찾고, 풀 리퀘스트 (Pull Request)를 제출하며, 콘텐츠를 게시하는 실제 자율 시스템 — 하루 24시간, 일주일 내내 작동하는 시스템 말입니다.
100시간 이상의 구축, 테스트, 실패, 그리고 반복 과정을 거친 끝에, 제가 실제로 무엇을 만들었는지, 무엇이 실제로 작동하는지, 그리고 실제 수치가 어떤 모습인지 공개합니다.
요약 (TL;DR): 작동합니다. 하지만 당신이 생각하는 방식과는 다릅니다. AI가 자율적으로 "돈을 버는" 것이 아니라, 인간의 노력을 위한 승수 효과 (Force multiplier)를 만들어냅니다. 그 방법을 소개합니다.
아키텍처: 내가 실제로 구축한 것
솔직히 말씀드리면, 아키텍처는 대부분의 AI 에이전트 프레임워크가 필요하다고 암시하는 것보다 훨씬 단순합니다. 실제 시스템은 다음과 같습니다:
┌─────────────────────────────────────────────────┐
│ ZKA Money Printer │
│ (Cron 기반 오케스트레이터) │
...
핵심 구성 요소
1. 바운티 스캐너 (Bounty Scanner) — 크론 잡 (Cron job)을 통해 30분마다 실행됩니다. GitHub에서 "bounty", "reward", "$", "good first issue", "help wanted" 태그가 붙은 이슈를 검색합니다. 블랙리스트에 등록된 저장소(Repo)를 필터링합니다 (네, 가짜 바운티를 만드는 사기 저장소들이 실제로 존재합니다).
2. 트리아지 엔진 (Triage Engine) — 6가지 차원에서 각 기회의 점수를 매깁니다:
- Repository credibility (신뢰도: 별(stars), 생성 시기, 라이선스, 활동성)
- Competition level (경쟁 수준: 기존 PR 및 댓글 수)
- Payment reliability (결제 신뢰도: 플랫폼 기반 vs 직접 결제 vs 토큰 전용)
- Technical difficulty (기술적 난이도: 실제로 해결 가능한가?)
- Time investment (시간 투자: 시간 대비 보상 비율)
- Scam probability (사기 확률: 자동 생성된 이슈, 실제 코드 부재)
3. PR Pipeline (PR 파이프라인) — 트리아지(Triage) 점수가 40점 이상인 경우: 저장소를 클론(clone)하고, 이슈를 분석하며, 수정 사항을 작성하고, 테스트를 실행한 뒤 PR을 제출합니다. 해당 저장소의 CONTRIBUTING.md를 정확히 따릅니다.
4. Content Pipeline (콘텐츠 파이프라인) — Dev.to에 기술 아티클을 작성하고 게시합니다. 배치(Batch) 게시 방식(하루 1~2회)을 사용하며, 양보다 질에 집중합니다.
5. Tracking & Reporting (추적 및 보고) — 모든 활동을 마크다운(markdown) 파일에 기록합니다. PR이 제출, 병합(merged) 또는 종료(closed)될 때 Telegram으로 보고합니다.
The Code (Simplified) (코드 - 간략화 버전)
오케스트레이션(orchestration) 레이어는 이 워크플로우를 실행하는 예약된 작업(scheduled task)입니다:
# 실제 오케스트레이션의 간략화된 버전
def bounty_hunter_tick():
# 1. 새로운 바운티(bounties) 검색
...
진정한 복잡성은 triage()와 work_on_bounty() 함수에 있으며, 바로 이 부분에 대부분의 엔지니어링 노력이 투입되었습니다.
The Triage System: How I Score Bounties (트리아지 시스템: 바운티 점수 산정 방식)
이것이 시스템에서 가장 중요한 부분입니다. 트리아지가 없다면, 결코 보상을 받을 수 없는 바운티에 시간을 허비하게 됩니다.
Scoring Matrix (점수 산정 매트릭스)
| Factor (요인) | Weight (가중치) | How to Score (산정 방식) |
|---|---|---|
| Repo credibility (저장소 신뢰도) | 20pts | Stars > 100 = +10, MIT/Apache license = +5, Active commits = +5 |
| ... |
Thresholds (임계값):
- ≥40: 즉시 제출
- 20-39: 더 나은 대안이 없을 경우 제출
- 0-19: 건너뜀
- <0: 블랙리스트 — 절대 건드리지 않음
Real Examples from My Experience (실제 경험 사례)
HIGH SCORE (75) (높은 점수): Aigen-Protocol #42 — "AIP-1 명세서를 일본어로 번역"
- Repo: MIT 라이선스, Python, 활발한 유지관리자, 별(stars) 3개
- Competition: 기존 PR 0개
- Payment: 온체인 에스크로(on-chain escrow)를 통한 USDC
- Difficulty: 쉬움 (번역)
- Result: 24시간 이내에 병합(merged)됨 ✅
MEDIUM SCORE (45) (중간 점수): mergeos #146 — "알림 센터 구현"
- Repo (저장소): 활성 상태, bounty-labeled (보상 라벨이 붙음)
- Competition (경쟁): 댓글 2-3개
- Payment (결제): MRG 토큰 (가치 불확실)
- Difficulty (난이도): 중간 (Medium)
- Result (결과): PR 제출됨, 리뷰 대기 중 ⏳
LOW SCORE (15) (낮은 점수): RustChain bounties — 다양한 이슈들
- Repo (저장소): 이슈당 48-66개 이상의 댓글
- Competition (경쟁): 극도로 포화됨
- Payment (결제): RTC 토큰
- Result (결과): 건너뜀 — 경쟁이 너무 심함 ❌
BLACKLISTED (-100) (블랙리스트): SecureBananaLabs/bug-bounty
- 1900개 이상의 자동 생성된 이슈들
- 모든 PR이 병합(merge) 없이 종료됨
- 명백한 보상 농장 (bounty farm)
- Result (결과): 절대 건드리지 말 것 ❌
PR 제출 플레이북 (The PR Submission Playbook)
다양한 저장소(repo)에 50개 이상의 PR을 제출해 본 결과, 실제로 병합(merged)되는 방식은 다음과 같습니다:
규칙 1: 코드를 짜기 전에 먼저 댓글을 남겨라
코드 한 줄을 쓰기 전에, 제안하는 접근 방식에 대해 이슈(issue)에 댓글을 남기세요. 이를 통해:
- 시간을 투자하기 전에 메인테이너(maintainer)의 동의를 얻을 수 있습니다.
- 다른 사람이 이미 작업 중일 경우 중복 작업을 방지할 수 있습니다.
- 당신이 문제를 이해하고 있음을 보여줍니다.
안녕하세요! 이 이슈를 해결하고 싶습니다. 제 접근 방식은 다음과 같습니다:
1. [구체적인 기술적 접근 방식]
2. [테스트 방법]
...
규칙 2: 그들의 스타일과 정확히 일치시켜라
기존 코드를 읽으세요. 그들의 컨벤션(convention)을 따르십시오:
- 탭(Tabs) vs 공백(spaces) (
.editorconfig또는 기존 파일 확인) - 명명 규칙 (Naming conventions) (camelCase vs snake_case)
- 임포트(Import) 스타일 (상대 경로 vs 절대 경로)
- 커밋 메시지 형식 (conventional commits 등)
규칙 3: 하나의 이슈에는 하나의 PR만
여러 개의 수정을 하나로 묶지 마세요. 하나의 집중된 PR이 리뷰하기 더 쉽고 병합될 가능성도 높습니다.
규칙 4: 테스트를 포함하라
거의 모든 프로젝트는 테스트를 요구합니다. 만약 테스트 스위트(test suite)가 있다면, 당신의 수정 사항에 대한 테스트를 추가하세요. 없다면, 최소한 수동으로 테스트하는 방법을 설명하세요.
규칙 5: 마법의 단어를 사용하라
PR 설명에 다음과 같이 작성하세요:
Fixes #N
이렇게 하면 PR이 병합될 때 해당 이슈가 자동으로 종료됩니다. 메인테이너들이 매우 좋아합니다.
규칙 6: 몇 시간 이내에 응답하라
속도가 보상(bounty)을 결정합니다. 메인테이너가 질문을 하면 며칠이 아니라 몇 시간 이내에 응답하세요. 알림 설정을 해두세요.
실제 PR 설명 템플릿 (Real PR Description Template)
## 요약 (Summary)
이 PR이 수행하는 작업에 대한 간략한 설명.
...
콘텐츠 파이프라인: 하루에 5~10개의 글을 쓰는 방법
글쓰기는 제가 발견한 가장 신뢰할 수 있는 수동적 소득 (Passive Income) 흐름입니다. 저의 시스템은 다음과 같습니다:
1. 주제 선정 (Topic Selection)
저는 매일 Dev.to의 트렌딩 주제를 모니터링합니다. 가장 좋은 주제는 다음과 같습니다:
- 높은 참여도 (상위 게시물 기준 반응 50개 이상)
- 기술적 내용 (단순한 의견 제시가 아닌 것)
- 독특한 관점 (기존 콘텐츠를 단순히 재탕하는 것이 아닌 것)
- SEO 친화적 (해결책을 찾는 개발자들이 검색할 만한 내용)
2. 품질 기준 (Quality Standards)
모든 글은 반드시 다음 조건을 충족해야 합니다:
- 3,000단어 이상 — 짧은 글은 검색 순위가 잘 올라가지 않습니다.
- 데이터 기반 (Data-driven) — 실제 수치, 실제 사례, 실제 실패 사례를 포함해야 합니다.
- 실행 가능성 (Actionable) — 독자가 글을 읽은 후 무언가를 직접 해볼 수 있어야 합니다.
- 독창성 (Original) — 단순히 문서를 재구성하는 수준에 그쳐서는 안 됩니다.
3. 발행 파이프라인 (Publishing Pipeline)
def publish_article(article):
# 1. 마크다운(markdown) 형식으로 초안 작성
write_to_file(article)
...
4. 일괄 발행 (Batch Publishing)
저는 하루에 12회, 35개의 글을 묶어서 발행합니다. 이는 다음과 같은 효과가 있습니다:
- 속도 제한 (Rate Limiting) 방지 (Dev.to에는 API 제한이 있습니다)
- 각 글이 노출될 수 있는 시간 확보
- 양보다 질을 유지
실제 수치 (72시간 경과 후)
경제적 측면에 대해 완전히 투명하게 말씀드리겠습니다:
제가 구축한 것들
- GitHub 전반에 걸친 50개 이상의 오픈 PR (Open PRs)
- Dev.to에 게시된 20개 이상의 글
- Aigen-Protocol에서 3개의 머지된 PR (Merged PRs) (USDC 결제 가능성 있음)
- 총 10개 이상의 머지된 PR (HELPDESK.AI, RustChain 포함)
제가 벌어들인 것들
- 실제 USD 수익 $0 — PR은 검토 대기 중이며, 글들은 독자를 확보해 나가는 단계입니다.
- 잠재적 수익: Aigen-Protocol에서 약 $200~500 상당의 USDC (PR이 승인될 경우)
- 잠재적 수익: Dev.to 글 트래픽을 통해 월 약 $50~100 (SEO가 작동하기 시작하면)
숨겨진 비용 (The Hidden Costs)
- API 비용 (API costs): LLM 추론을 위해 하루 약 $10-20 소요 (유료 모델 사용 시)
- 시간 (Time): 100시간 이상의 개발 및 반복 작업 (Iteration)
- GitHub API 속도 제한 (GitHub API rate limits): 지속적인 도전 과제
- 유지 관리자 응답 시간 (Maintainer response time): 많은 PR (Pull Request)이 검토 없이 몇 주 동안 방치됨
실제로 효과가 있는 것들 (What Actually Works)
- 번역/문서화 PR (Translation/documentation PRs) — 병합률(Merge rate)이 가장 높고 경쟁이 가장 낮음
- 명확한 테스트 케이스를 포함한 버그 수정 (Bug fixes with clear test cases) — 두 번째로 높은 병합률
- 콘텐츠 제작 (Content creation) — 가장 신뢰할 수 있는 수동적 소득 (SEO가 작동하기 시작하면)
- 니치 레포지토리 (Niche repos) — 인기 프로젝트보다 경쟁이 적음
효과가 없는 것들 (What Doesn't Work)
- 1등을 향한 경주 (Racing to be first) — 에이전트가 포화된 시장은 몇 시간 내에 10-20개의 PR이 쏟아짐
- 복잡한 기능 PR (Complex feature PRs) — 높은 노력 대비 높은 거절률
- 토큰 전용 바운티 (Token-only bounties) — 대부분의 토큰은 가치가 없음
- 스캠 레포지토리 (Scam repos) — 시간 낭비이며 평판을 해침
스캠 탐지 시스템 (The Scam Detection System)
네
- 인간보다 더 빠르게 기회를 포착합니다
- 가치 높은 작업에 집중할 수 있도록 기회를 분류 (Triage) 합니다
- 반복적인 작업(PR 설명 작성, CI 확인 등)을 자동화합니다
- 콘텐츠를 지속적으로 발행합니다
하지만 인간은 여전히 다음의 역할을 수행해야 합니다:
- 시스템 설정
- 결과 모니터링
- 전략적 의사 결정
- 예외 케이스 (Edge cases) 처리
2. 속도가 유일한 강점은 아닙니다
처음 제출한 PR (Pull Request)이 반드시 머지 (Merge) 되는 것은 아닙니다. 메인테이너 (Maintainer)들은 다음 사항을 중요하게 생각합니다:
- 코드 품질 (Code quality)
- 테스트 커버리지 (Test coverage)
- 자신들의 스타일 준수
- 피드백에 대한 반응성
3. 진짜 수익은 콘텐츠에서 나옵니다
수백 개의 바운티 (Bounty)를 분석한 결과, 가장 신뢰할 수 있는 수익원은 콘텐츠 제작입니다:
- 기사가 시간이 지남에 따라 복리로 쌓입니다 (SEO 트래픽)
- 경쟁이 없습니다 (당신의 기사는 고유합니다)
- 거절당하지 않습니다 (한 번 발행되면, 그것으로 끝입니다)
- 수동적 소득 (Passive income) (잠자는 동안에도 수익을 창출합니다)
4. 오픈 소스는 장기전입니다
즉각적인 수익을 기대하지 마세요. 신뢰를 쌓아야 합니다:
- 관심 있는 리포지토리 (Repo)에 양질의 PR을 제출하세요
- 커뮤니티와 소통하세요
- 인내심을 가지세요 (메인테이너들은 바쁩니다)
- 머지된 PR들의 포트폴리오를 구축하세요
나만의 시스템 구축하기
유사한 시스템을 구축하고 싶다면, 다음 사항들이 필요합니다:
사전 요구 사항 (Prerequisites)
ghCLI가 설치된 GitHub 계정- API 키가 있는 Dev.to 계정
requests,httpx가 설치된 Python 3.11 이상- 텔레그램 봇 (Telegram bot, 알림용)
- LLM (로컬 또는 API) 접근 권한
1단계: 바운티 스캐너 (Bounty Scanner) 설정
# 블랙리스트 파일 생성
echo "# Scam repos" > /root/.hermes/scripts/bounty-blacklist.txt
...
2단계: 분류 시스템 (Triage System) 구축
def triage(bounty):
score = 0
...
3단계: PR 파이프라인 (PR Pipeline) 설정
def work_on_bounty(bounty):
# 리포지토리 클론 (Clone repo)
os.system(f"gh repo clone {bounty.repo} /tmp/{bounty.repo}")
...
4단계: 콘텐츠 파이프라인 (Content Pipeline) 설정
def write_and_publish_article():
# 트렌딩 주제 선택
topic = select_trending_topic()
...
5단계: 크론 잡 (Cron Job) 설정
# 30분마다 실행되는 크론 잡 (Cron Job) 생성
hermes cronjob create \
--name "bounty-hunter-24-7" \
...
솔직한 평가
100시간 이상의 구축과 72시간의 실행을 거친 후, 제 생각은 다음과 같습니다:
잘 작동하는 부분
- ✅ 보상 (Bounties) 자동 탐색
- ✅ 고가치 기회에 집중하기 위한 분류 (Triaging)
- ✅ 일관된 콘텐츠 작성 및 게시
- ✅ 풀 리퀘스트 (PRs) 추적 및 리뷰 모니터링
- ✅ 스캠 리포지토리 (Scam repos) 탐지
아직 작동하지 않는 부분
- ❌ 즉각적인 수익 창출 (PRs가 리뷰되는 데 시간이 걸림)
- ❌ 포화된 시장에서의 경쟁 (에이전트가 너무 많음)
- ❌ 복잡한 코드 변경 처리 (AI는 여전히 대규모 코드베이스 (Codebases)를 다루는 데 어려움을 겪음)
- ❌ 인간의 판단 대체 (전략적 결정을 위해서는 인간의 개입 (Human in the loop)이 필요함)
결론
이 시스템은 대체재가 아니라 역량 증폭기 (Force multiplier)입니다. 이 시스템은 다음과 같은 역할을 합니다:
- 인간보다 10배 빠르게 기회를 탐색합니다.
- 고가치 작업에 노력을 집중시킵니다.
- 반복적인 작업을 자동화합니다.
- 콘텐츠를 일관되게 게시합니다.
하지만 여전히 다음과 같은 요소가 필요합니다:
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기