에이전트 경제: AI 에이전트가 오픈 소스에서 실제로 돈을 버는 방법 (그리고 대부분이 실패하는 이유)

GitHub 바운티(Bounty)를 24시간 내내 사냥하는 자율형 AI 에이전트를 30일 동안 운영한 결과, 저는 80개 이상의 풀 리퀘스트(Pull Request, PR)를 제출했고, 500달러 이상의 바운티를 벌었으며, AI와 돈에 대한 제 생각을 완전히 바꿔놓은 교훈들을 얻었습니다. 좋은 점, 나쁜 점, 그리고 잔혹할 정도로 솔직한 모든 것을 공개합니다.

농담처럼 시작된 실험

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

"코드를 제안하는" 수준의 돈이 아닙니다. "시간을 아껴주는" 수준의 돈도 아닙니다. 진짜로, 당신의 지갑에 입금되는 돈 말입니다. 자고 일어났을 때 잔액을 확인해보니 잠들기 전보다 높아져 있는 그런 종류의 돈 말이죠.

저는 Hermes Agent를 사용하여 자율형 에이전트를 구축했습니다. 이는 AI에게 지속적인 메모리(Persistent Memory), 도구 접근 권한(Tool Access), 그리고 지속적으로 실행될 수 있는 능력을 부여하는 프레임워크입니다. 계획은 간단했습니다. 에이전트를 GitHub에 풀어놓고, 바운티(Bounty)가 표시된 이슈를 찾아, 이를 해결할 코드를 작성하고, 풀 리퀘스트(Pull Request)를 제출하여, 대금을 수령하는 것이었습니다.

1일 차 결과: 12개의 풀 리퀘스트 제출. 머지(Merge) 0건. 거절 2건. 무시 8건.

30일 차 결과: 84개의 오픈 PR, 59개의 머지, 500달러 이상의 수익, 그리고 오픈 소스 기여의 경제학이 실제로 어떻게 작동하는지에 대한 완전히 다른 이해.

이 글은 수치, 아키텍처(Architecture), 실패, 그리고 실제로 수익을 창출하는 에이전트와 그저 소음만 만들어내는 에이전트를 구분 짓는 패턴에 대한 솔직한 분석입니다.

수치: 30일간의 투명한 장부

모두가 알고 싶어 하는 것부터 시작하겠습니다: 돈입니다.

지표	횟수
제출된 풀 리퀘스트 (Pull Requests Submitted)	84
...

하지만 이 수치들이 말해주지 않는 것이 있습니다: 분포가 터무니없이 집중되어 있다는 점입니다.

머지된 59개의 PR 중, 말 그대로 단 3개의 저장소(Repo)가 전체 머지의 90% 이상을 차지했습니다:

HELPDESK.AI — 28개 머지된 PR (단위 테스트, 버그 수정)
Aigen-Protocol — 22개 머지된 PR (번역, 사양 구현)
mobile-money — 9개 머지된 PR (API 통합, 모의 엔드포인트)

그 외의 다른 저장소들은요? 머지 0건. 수십 개의 저장소에 30개 이상의 PR을 제출했음에도 불구하고 말입니다.

이것이 에이전트 경제(agent economy)의 첫 번째 잔혹한 교훈입니다: 오픈 소스 바운티(open source bounties)는 멱법칙(power law)을 따릅니다. 아주 적은 수의 저장소만이 당신의 작업물을 수락할 것입니다. 대다수는 당신을 무시하거나, 거절하거나, 혹은 아예 응답하지 않을 것입니다.

아키텍처: 자율 에이전트(Autonomous Agent)는 실제로 어떻게 작동하는가

교훈을 깊이 파고들기 전에, "자율 바운티 헌팅(autonomous bounty hunting)"이 기술적으로 실제로 무엇을 의미하는지 설명하겠습니다. 이는 단순히 "AI가 코드를 작성한다"는 것보다 훨씬 더 미묘한 차이가 있기 때문입니다.

파이프라인 (The Pipeline)

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   DISCOVER   │ ──▶ │   EVALUATE   │ ──▶ │   IMPLEMENT  │
│              │     │              │     │              │
...

탐색 계층 (The Discovery Layer)

에이전트는 30분마다 다음 검색 쿼리를 실행합니다:

# 바운티(Bounty) 관련 검색
gh search issues "bounty" --state open --sort created --limit 50
gh search issues "reward" --state open --limit 30
...

하지만 여기서 중요한 통찰이 있습니다: 대부분의 "bounty" 검색 결과는 노이즈(noise)입니다. 에이전트는 알려진 4개 이상의 사기/비정상 저장소 블랙리스트를 유지하며, 다음과 같은 항목을 평가하는 분류 점수 시스템(triage scoring system)을 운용합니다:

저장소 신뢰도 (Repo credibility) (스타 수, 생성 시기, 머지(merge) 이력)
경쟁 수준 (Competition level) (동일한 이슈에 대한 기존 PR 존재 여부)
우리의 실적 (Our track record) (이곳에 머지된 PR이 있는가?)
결제 신뢰도 (Payment reliability) (USD/암호화폐 vs 불확실한 토큰)

평가 계층 (The Evaluation Layer)

모든 바운티가 추구할 가치가 있는 것은 아닙니다. 에이전트는 각 기회를 100점 만점으로 점수를 매깁니다:

점수 >= 40: 즉시 제출 (신뢰할 수 있는 저장소, 경쟁 없음)
점수 20-39: 더 나은 대안이 없을 경우 제출
점수 < 20: 건너뜀 ($1 미만인 경우 제외, $1 = 가스비(gas)와 같으므로)

점수 산정 요소에는 블랙리스트 확인, 저장소 스타 수, 라이선스, 플랫폼 가치, 그리고 경쟁 분석이 포함됩니다. 이미 우리의 PR이 3개 이상 거절된 저장소는 자동으로 -50점을 받습니다.

구현 계층 (The Implementation Layer)

여기서부터 흥미로워집니다. 에이전트는 단순히 "코드를 작성"하는 것이 아니라, 특정 워크플로우(workflow)를 따릅니다:

저장소 복제 (Clone the repo) (또는 기존 복제본 업데이트)
이슈 읽기 (Read the issue) — 요청 사항을 정확히 이해하기
기존 코드 읽기 (Read existing code) — 코드베이스 스타일과 정확히 일치시키기
경합 중인 PR 확인 (Check for competing PRs) — 이미 다른 사람이 작동하는 솔루션을 제출했다면 건너뛰기
수정 사항 구현 (Implement the fix) — 집중적이고 최소한의 변경 사항 적용
테스트 작성 (Write tests) — 거의 모든 프로젝트에서 테스트를 요구함
로컬에서 테스트 실행 (Run tests locally) — 결함이 있는 코드는 절대 제출하지 말 것
적절한 템플릿으로 PR 생성 (Create PR) (요약, 변경 사항, 테스트, Fixes #N 포함)

냉혹한 교훈: 30일 동안 배운 것들

교훈 1: 공개 바운티(Bounty) 시장은 이미 에이전트로 포화 상태이다

이것은 가장 고통스러운 깨달음이었습니다. Algora나 인기 있는 저장소(repo)에 가치가 높은 바운티가 나타나면, 몇 시간 내에 8~158개의 시도가 이루어집니다. 며칠이 아니라, 몇 시간 만에 말이죠.

저는 이를 실시간으로 지켜보았습니다. 별(star) 3.8만 개를 보유한 저장소에 500달러 규모의 바운티가 올라왔습니다. 4시간 만에 14개의 경합 PR이 생겼고, 8시간째에는 23개까지 늘어났습니다. 결국 메인테이너(maintainer)는 이슈가 게시된 지 47분 만에 제출된 3번째 제출물을 선택했습니다.

공개 바운티에서는 품질보다 속도가 더 중요합니다. 그리고 AI 에이전트는 빠릅니다. 하지만 모두가 AI 에이전트를 가지게 되면, 속도 또한 흔한 상품(commodity)이 되어버립니다.

교훈 2: 신뢰할 수 있는 저장소(Credibility Repos)가 전부다

PR을 머지(merge)시키는 데 있어 가장 중요한 단일 요소는 코드 품질이 아니라, 바로 메인테이너와의 관계입니다.

저희의 가장 상위 저장소(HELPDESK.AI)는 28개의 머지된 PR을 보유하고 있습니다. 어떻게 가능했을까요? 저희는 다음과 같이 행동했기 때문입니다:

작고 집중된 PR 제출 (PR 하나당 이슈 하나)
포괄적인 테스트 포함
리뷰 코멘트에 몇 시간 내로 응답
기존 코드 스타일과 정확히 일치
미완성된 작업은 절대 제출하지 않음

처음 3~4개의 머지가 이루어진 후, 메인테이너는 저희의 PR을 더 빠르게 머지하기 시작했습니다. PR 10번째에 이르러서는 리뷰를 기다리지 않고도 제출할 수 있었습니다. 신뢰는 복리로 쌓입니다.

교훈 3: 번역은 치트 코드(Cheat Code)다

오픈 소스 신뢰도를 빠르게 쌓고 싶다면, 문서(documentation)를 번역하세요. 그 이유는 다음과 같습니다:

낮은 난이도 (Low difficulty) — 번역은 직관적입니다.
낮은 경쟁 (Low competition) — 대부분의 개발자는 번역을 원하지 않습니다.
항상 필요함 (Always needed) — 모든 프로젝트는 국제화 (i18n) 지원을 원합니다.
검토가 용이함 (Easy to review) — 메인테이너(maintainer)가 품질을 빠르게 확인할 수 있습니다.
높은 머지율 (High merge rate) — 우리의 번역 PR (Pull Request)은 약 95%의 머지율을 기록했습니다.

우리는 사양 문서 (spec documents)를 일본어, 독일어, 스페인어, 프랑스어, 포르투갈어, 중국어로 번역하는 것만으로 600개 이상의 AIGEN 토큰 (Aigen-Protocol의 통화)을 벌었습니다. 각 번역에는 30~45분이 소요되었으며, 번역당 50 AIGEN을 획득했습니다.

레슨 4: "뿌리고 기도하기 (Spray and Pray)" 방식의 처참한 실패

초기에 저는 에이전트가 "바운티 (bounty)" 라벨이 붙은 모든 리포지토리 (repo)에 PR을 제출하도록 했습니다. 그 결과는 다음과 같았습니다:

30개 이상의 리포지토리가 PR을 받았습니다.
단 3개의 리포지토리만이 무언가를 머지 (merge)했습니다.
27개 이상의 리포지토리는 무시하거나, 거절하거나, 아예 응답하지 않았습니다.

이는 단순히 낭비일 뿐만 아니라, 평판을 해치는 행위입니다. 수십 개의 프로젝트에 걸쳐 동일한 계정이 저품질 PR을 제출하는 것을 보는 리포지토리들은 당신을 스패머 (spammer)로 간주하기 시작합니다.

해결책: 이미 신뢰도를 쌓은 리포지토리에 집중하세요. 우리는 새로운 리포지토리에서의 0% 머지율에서, 기존 관계가 형성된 곳에서의 70% 이상의 머지율로 전환했습니다.

레슨 5: 자동화된 코드 리뷰 (Automated Code Review)는 당신의 친구입니다

현재 많은 리포지토리가 자동화된 리뷰 봇 (CodeRabbit, Cubic, GitGuardian)을 사용하고 있습니다. 저는 처음에 이것들을 소음 (noise)으로 치부하며 무시했습니다. 큰 실수였습니다.

자동화된 리뷰는 실제 문제를 잡아냅니다. 다음과 같은 것들입니다:

잘못된 이슈 연결 (예: Fixes #832여야 하는데 Fixes #824로 작성된 경우)
테스트에서의 엣지 케이스 (edge cases) 누락
업스트림 의존성 (upstream dependency) 업데이트 후의 타입 불일치 (type mismatches)
보안 취약점 (XSS, SSRF, injection)

CodeRabbit이 무언가를 지적하면, 즉시 수정하세요. 봇이 다시 리뷰하고 종종 승인(approve)을 해줍니다. 이는 머지 프로세스의 속도를 극적으로 높여줍니다.

레슨 6: AI 에이전트의 독특한 실패 모드 — 자신감 넘치는 환각 (Confident Hallucination)

가장 위험한 실패는 에이전트가 작업을 거부하는 것이 아닙니다. 에이전트가 틀린 출력을 자신 있게 생성하는 것입니다.

실제 사례: 에이전트가 HELPDESK.AI의 알림 서비스 테스트(notification service tests)에 관한 이슈를 작업하고 있었습니다. 에이전트는 25개의 테스트를 작성했고, 로컬 환경에서는 모두 통과했습니다. CodeRabbit이 이를 리뷰하며 다음과 같이 말했습니다: "이 PR은 notification_service.py를 참조하고 있지만, 이 브랜치에는 해당 파일이 존재하지 않습니다. 테스트는 NotificationService가 아니라 NotificationRoutingMiddleware를 위한 것입니다."

에이전트는 이슈 제목을 바탕으로 파일 이름을 환각 (Hallucination) 했고, 잘못된 모듈에 대한 테스트를 작성하여 제출했습니다. 그러면서도 "테스트 통과, PR 깨끗함"이라고 보고했습니다.

적용된 수정 사항:

테스트를 작성하기 전에 항상 파일 존재 여부를 확인합니다.
제목뿐만 아니라 실제 이슈 본문(issue body)을 읽습니다.
코딩하기 전에 grep 및 find 명령어로 교차 검증합니다.

레슨 7: 진짜 돈은 바운티(Bounties)가 아니라 관계에 있다

30일이 지난 후, 가장 가치 있는 결과물은 벌어들인 500달러가 아닙니다. 그것은 바로 메인테이너(maintainers)들과의 관계입니다.

HELPDESK.AI 메인테이너는 이제 몇 시간 이내에 우리의 PR을 머지(merge)합니다.
Aigen-Protocol 메인테이너들은 우리의 번역 품질을 알고 있습니다.
mobile-money 메인테이너는 우리에게 이슈를 직접 할당했습니다.

이러한 관계는 그 어떤 단일 바운티보다 가치가 있습니다. 이는 다음과 같은 결과로 이어집니다:

가치가 높은 이슈에 대한 직접적인 할당
더 빠른 머지(merge) 시간
프라이빗 프로그램으로의 초대
다른 프로젝트로의 추천

경제성: 이것이 실제로 가치가 있는가?

솔직하게 계산을 해보겠습니다.

비용

항목	비용
AI 추론 (AI Inference, 30일)	~$45
...

수익

출처	금액
AIGEN 토큰 (번역)	~$200-400
...

결론

시간당 수익률: 약 $12-24/hour (관리 시간 포함)

이것은... 시니어 개발자에게 그리 좋은 수준은 아닙니다. 하지만 중요한 점은 다음과 같습니다: 그 시간의 대부분은 첫 일주일 동안 시스템을 설정하고, 분류(triage) 알고리즘을 조정하며, 블랙리스트를 구축하는 데 소비되었다는 것입니다. 3~4주 차에 접어들면서 에이전트는 최소한의 개입만으로 거의 자율적으로 실행되었습니다.

실제 경제성은 다음과 같은 모습에 더 가깝습니다:

1주 차: 시간당 $5 (과도한 설정, 많은 실패)
2주 차: 시간당 $15 (시스템 최적화, 신뢰 구축)
3~4주 차: 시간당 $30-50 (복리 수익, 더 빠른 머지 (Merge))

곡선은 선형이 아니라 지수적입니다. 그리고 계속해서 개선됩니다.

사기 문제: 대부분의 바운티 (Bounty) 플랫폼이 망가진 이유

모두가 알고 있지만 말하기 꺼려하는 문제, 즉 **사기 리포지토리 (Scam repos)**에 대해 이야기해 보겠습니다.

30일간의 실험 동안 우리는 다음과 같은 사례를 접했습니다:

UnsafeLabs/Bounty-Hunters — 31개의 PR (Pull Request)이 머지 (Merge) 없이 종료됨. 자동 생성된 이슈 (Issue), 실제 리뷰 없음.
SecureBananaLabs/bug-bounty — 21개의 PR이 머지 없이 종료됨. 무료 코드를 수집하기 위한 허니팟 (Honeypot).
OFFER-HUB/offer-hub-monorepo — 4개의 PR이 머지 없이 종료됨. 유지 관리자 (Maintainer) 활동 없음.
다수의 "바운티 보드 (Bounty board)" 리포지토리 — 기여를 유도하기 위해 이슈를 게시하지만, 절대 머지되지 않으며 토큰도 배분되지 않음.

패턴은 항상 동일합니다:

이름에 "bounty"가 포함된 리포지토리를 생성한다.
토큰 또는 USD 바운티가 걸린 이슈를 게시한다.
AI 에이전트들이 PR을 쏟아내는 것을 지켜본다.
모든 PR을 종료하거나 아예 리뷰하지 않는다.
이러한 "기여 (Contributions)"를 이용해 리포지토리 활동 지표를 부풀린다.

탐지 휴리스틱 (Detection heuristics):

리포지토리 생성 기간이 3개월 미만인데 이슈가 50개 이상인 경우
실제 코드 커밋 (Commit)은 없고 이슈 생성만 있는 경우
유지 관리자가 댓글에 전혀 응답하지 않는 경우
이슈가 자동 생성된 템플릿인 경우
"바운티" 금액이 믿기지 않을 정도로 과도하게 높은 경우

내가 다르게 했을 방법: 최적화 프레임워크

만약 내가 오늘 이 실험을 다시 시작한다면, 정확히 다음과 같이 바꿀 것입니다:

1. 양이 아닌 신뢰성부터 시작하기

30개의 리포지토리에 제출하는 대신, 3개의 리포지토리를 선정하여 각각 10개의 고품질 PR을 제출하겠습니다. 먼저 머지 (Merge) 이력을 쌓은 다음 확장하겠습니다.

2. "코드 작성 전 댓글 먼저" 전략 사용하기

코드 한 줄을 쓰기 전에 이슈에 다음과 같이 댓글을 남깁니다:

"이 작업을 수행하고 싶습니다. 제 접근 방식은 다음과 같습니다: [간략한 설명]. 이렇게 진행해도 괜찮을까요?"

이 방식은 세 가지 효과를 거둘 수 있습니다:

시간을 투자하기 전에 메인테이너(Maintainer)의 동의를 얻을 수 있습니다.
이미 누군가 맡기로 한 이슈(Issue)에 노력을 낭비하는 것을 방지합니다.
전문성을 보여줄 수 있습니다 (메인테이너는 이를 기억합니다).

3. 번역에 먼저 집중하기

번역 PR(Pull Request)은 머지(Merge) 비율이 가장 높고 경쟁은 가장 낮습니다. 코드 변경을 시도하기 전에 5~10개의 번역 PR을 통해 신뢰를 쌓으세요.

4. "인내심 수확(Patience Harvesting)" 전략 실행하기

(몇 시간 내에 15개의 에이전트가 제출되는) 새로운 바운티(Bounty)에서 경쟁하는 대신, 다음과 같은 **방치된 클레임(Abandoned claims)**을 찾으세요:

이슈가 생성된 지 14일 이상 경과한 경우
기존 PR이 정체된 경우 (7일 이상 업데이트가 없는 경우)
최초 제출자가 리뷰 코멘트에 응답하지 않은 경우

이것들은 노다지입니다. 경쟁자들은 이미 포기했고, 메인테이너는 작동하는 해결책을 간절히 원하고 있습니다.

5. 조기에 분류 점수 시스템(Triage Scoring System) 구축하기

모든 바운티를 수동으로 평가하며 시간을 낭비하지 마세요. 점수 산정을 자동화하십시오: