계기

DataProof CSV를 출시한 실험은 작은 디지털 상품을 만들어 반복 판매하는 수익 경로였다. 하지만 내가 원한 것은 한 가지 사업 모델을 계속 밀어붙이는 일이 아니었다. 누가 어떤 조건에서 무엇에 돈을 지급하는지 넓게 찾고, AI가 조사와 준비를 맡을 수 있는지도 시험하고 싶었다.

그중 하나가 돈이 걸린 GitHub 이슈였다. 오픈소스 프로젝트가 해결해야 할 문제에 보상을 걸고, 기여자가 코드를 제출해 수락되면 돈을 받는 방식이다. 흔히 OSS 바운티라고 부르지만, 처음 접하는 사람에게는 “보상이 붙은 GitHub 작업”이라는 설명이 더 직관적이다.

고객을 직접 찾지 않아도 요구사항과 보상 제안이 이미 공개돼 있다는 점은 매력적이었다. 내가 할 일은 조건에 맞는 작업을 골라 해결하는 것처럼 보였다.

무엇을 찾으려 했나

무작정 GitHub 이슈를 뒤지지는 않았다. 2026년 7월 19일, 다음 조건으로 최초 후보를 최대 10건만 조사했다.

• Python, Node.js·TypeScript, GitHub Actions, CLI 또는 테스트 자동화와 가까울 것
• 명목 보상이 최소 50달러일 것
• 최대 8시간 안에 끝낼 가능성이 있을 것
• 유료 API, GPU 또는 특수 장비가 필요하지 않을 것
• 보상, 요구사항과 제출 경로를 공식 자료에서 확인할 수 있을 것

이 기준은 “재미있어 보이는 이슈”가 아니라, 짧은 시간 안에 실제 보상으로 이어질 가능성이 있는 작업을 찾기 위한 것이었다.

플랫폼의 Open 표시만 믿지 않았다

바운티 플랫폼에서 Open 또는 Funded로 보이는 것만으로는 부족했다. 플랫폼 목록은 후보를 찾는 출발점일 뿐, 지금도 착수 가능한 작업이라는 증거는 아니었다.

코드를 쓰기 전에 다음 순서로 확인했다.

1. 원본 GitHub 이슈가 실제로 열려 있는가
2. 같은 문제를 해결한 PR이 이미 병합됐는가
3. 저장소가 보관 처리됐거나 사실상 멈추지 않았는가
4. 이미 작업 중인 사람이나 경쟁 PR이 많은가
5. 완료 조건과 유지관리자의 수락 의사가 분명한가
6. 보상 재원과 현재 지급 절차를 확인할 수 있는가
7. 내 시간 제한 안에 구현하고 검증할 수 있는가

하나라도 치명적으로 어긋나면 점수를 매기지 않고 바로 중단했다. 병합 확률이나 예상 시급을 정교하게 계산해도, 애초에 제출할 수 없는 작업이면 숫자만 그럴듯해지기 때문이다.

10건 모두 착수하지 않은 이유

조사 결과는 none_verified, 즉 조건을 모두 통과한 후보가 0건이었다.

살펴본 이슈	착수하지 않은 핵심 이유
nuclei #6674	원본 이슈가 닫혔고 해결 PR이 이미 병합됐다.
nuclei #6532	원본 이슈가 닫혔고 동일 CI 작업의 PR이 병합됐다.
forgecode #389	원본 이슈가 닫혔고 담당자와 병합된 해결 PR이 있었다.
graphql-benchmarks #272	이슈는 열려 있지만 저장소가 보관 처리되어 읽기 전용이었다.
SerenityOS #20744	보상 상세 페이지를 확인할 수 없었고, 부분 구현과 작업 경쟁이 있으며 8시간을 크게 넘길 가능성이 높았다.
SerenityOS #22179	이슈는 열려 있지만 같은 구현의 PR이 이미 병합됐다.
SerenityOS #21678	핵심 구현이 이미 병합됐고 남은 완료 범위가 불분명했다.
majo #9	오래된 이슈에 동일 문제를 다루는 경쟁 PR이 여럿 있었고 수락 조건이 명확하지 않았다.
BoostNote-App #1151	저장소가 보관 처리됐고 기존 해결 PR과 작업 선언이 있었다.
rapid-prereview #75	저장소가 보관 처리됐고 요구사항과 재현 범위도 불명확했다.

대표적인 함정은 “이슈는 열려 있다”와 “아직 해결할 일이 남아 있다”가 다르다는 점이었다. SerenityOS #22179는 원본 이슈가 지금도 열려 있지만 정확히 같은 기능을 구현한 PR은 2023년에 이미 병합됐다. 상태 라벨 하나만 봤다면 이미 끝난 일에 시간을 쓸 수 있었다.

반대로 graphql-benchmarks #272처럼 이슈가 열려 있고 문제도 남아 있어 보이지만, 저장소 자체가 보관 처리된 경우도 있었다. 새 코드를 제출해 병합될 정상 경로가 막혀 있으므로 보상 액수가 보여도 착수 후보로 볼 수 없었다.

착수하지 않은 것도 결과였다

이번 조사에서는 저장소를 복제하거나 선점 댓글을 달거나 PR을 만들지 않았다. 10건을 조사하고 코드 한 줄 쓰지 않은 결과만 보면 아무 일도 하지 않은 것처럼 보일 수 있다.

하지만 수익 목적의 작업에서는 구현 전에 보상 가능성을 반증하는 것도 중요했다. 닫힌 이슈, 이미 병합된 구현, 보관된 저장소에 몇 시간을 쓰는 일을 피했다. 다만 시간을 아꼈다는 사실을 수익으로 계산하지는 않는다. 실제로 지급받은 돈은 0원이고, 이번에 확인한 것은 후보 선별 절차뿐이다.

이 판단은 “오픈소스 바운티로 돈을 벌 수 없다”는 결론도 아니다. 이번 날짜에 이 조건으로 확인한 최초 10건 중, 바로 착수해도 된다고 증명할 수 있는 작업을 찾지 못했다는 뜻이다.

다음 조사에서 바꿀 점

오래된 플랫폼 목록을 대량으로 훑는 방식은 검색 결과는 많이 만들지만 적격 후보를 만들지는 못했다. 다음에는 다음 순서로 탐색 범위를 좁힐 생각이다.

1. 최근에 생성되거나 갱신된 원본 이슈를 먼저 찾는다.
2. 유지관리자가 지금도 활동하는 저장소만 남긴다.
3. 병합 기록과 경쟁 PR을 먼저 확인한다.
4. 보상 금액뿐 아니라 재원, 수락 주체와 지급 조건까지 확인한다.
5. 구현 범위를 로컬에서 재현한 뒤에만 선점이나 제출 승인을 검토한다.

좋은 후보가 나오면 그때 예상 시간과 병합 가능성, 기대 보상을 비교하면 된다. 그 전까지는 Open, $100 같은 표시보다 “지금 누가 어떤 완료 조건으로 돈을 지급하는가”를 먼저 확인해야 한다.

이 글의 GitHub 상태는 2026년 7월 20일에 다시 확인했다. 이슈, PR과 저장소 상태는 이후 달라질 수 있다.