✍️ 필사 모드: 오픈소스 펀딩 2026: GitHub Sponsors, Polar, Open Collective, Tidelift, Ko-fi — 메인테이너는 어떻게 돈을 받는가 (Deep Dive)

"오픈소스는 사랑의 노동이다. 하지만 사랑만으로 월세를 내지는 못한다."

전 세계 소프트웨어 인프라의 약 90%가 오픈소스 위에서 돌아간다. 그리고 그 오픈소스의 약 90%는 1% 이하의 메인테이너 손으로 유지된다. 이 비대칭이 2014년 Heartbleed, 2021년 log4shell, 2024년 xz-utils 백도어, 그리고 우리가 매년 마주치는 "이 핵심 라이브러리 메인테이너 한 명이 번아웃으로 잠적했다"는 뉴스의 구조적 원인이다.

이 글은 그 구조에 정면으로 부딪치는 메인테이너의 시점에서, 2026년 현재 사용 가능한 9개의 펀딩 채널을 비교한다. "월 100달러는 받지만, 그게 평생 갈지 모르겠다"는 사람들의 실전 데이터, 어떤 채널이 실제로 전환되는지의 솔직한 평가, 그리고 기업이 마침내 비용을 인정하기 시작한 Sentry의 Open Source Pledge 같은 흐름까지 정리한다.

프롤로그 — 메인테이너 번아웃과 무임승차 문제

2024년 xz-utils 백도어 사건은 한 줄로 요약된다. 한 명의 번아웃 메인테이너가 도움을 자처한 정체불명의 신규 기여자에게 권한을 넘겼고, 그 사람은 거의 모든 리눅스 배포판에 침투할 수 있는 SSH 백도어를 심었다. 이 사건의 진짜 원인은 백도어 코드가 아니라, 수십억 달러의 인프라가 한 사람의 무급 노동에 의존했다는 사실이다.

구조적 문제

• 포춘 500 기업의 약 96%가 직간접적으로 OSS에 의존한다 (Synopsys OSSRA 보고서).
• 그런데 그 의존성을 만드는 메인테이너의 75% 이상이 단 한 푼의 펀딩도 받지 못한다 (Tidelift 메인테이너 조사).
• 평균적으로 인기 OSS 패키지를 유지하는 메인테이너는 주당 5~10시간을 무급 노동에 쓴다.
• "잘 되는" 메인테이너가 후원금으로 받는 평균 월 수익은 자영업 최저 시급의 절반도 안 된다.

무임승차 (free-rider) 문제

오픈소스의 비극은 클래식한 공유지의 비극이다. AWS는 PostgreSQL 위에서 수조 원의 매출을 만들지만, PostgreSQL 핵심 개발자에게 직접 입금하지 않는다. 한 명이 의존성으로 인해 얻는 가치와 그 사람이 메인테이너에게 돌려주는 가치 사이의 거리는, 거의 항상 무한대에 가깝다.

이 글의 모든 채널은 그 거리를 좁히려는 시도다. 어떤 채널은 개인 후원자, 어떤 채널은 기업 라이선스, 어떤 채널은 자동 의존성 트래킹, 어떤 채널은 현상금을 메커니즘으로 쓴다. 메커니즘이 다르면 컨버전과 지속성도 다르다.

이 글의 약속

이 글은 후원 채널 회사들의 마케팅 자료가 아니다. 실제 메인테이너가 공개적으로 보고한 숫자, 채널 자체의 한계, 그리고 "내가 후원을 받기 시작하면 정말로 월세를 낼 수 있는가"라는 질문에 정직하게 답한다.

1장 · 채널 한눈에 — 9개 펀딩 옵션

깊게 들어가기 전에 전체 지도를 그리자. 채널은 크게 네 부류로 나뉜다.

각 채널은 (1) 수익 모델(누가, 왜 결제하는가) (2) 수수료 구조 (3) 세금/지급의 책임 소재 (4) 인구학적 컨버전에서 다르다. 이 글의 나머지는 이 네 축을 채널별로 파헤친다.

2장 · GitHub Sponsors — 기본값이지만 천장이 낮다

GitHub Sponsors는 2019년 베타로 시작해 지금은 사실상의 "기본" 채널이 됐다. 이유는 단순하다 — 메인테이너의 일터(GitHub) 안에 결제 버튼이 있다.

어떻게 작동하는가

• 메인테이너가 FUNDING.yml을 레포에 추가하면, "Sponsor" 버튼이 PR 옆에 자동으로 박힌다.
• 후원자는 정기 결제(매월) 또는 일회성으로 후원할 수 있다.
• 메인테이너는 등급(tier)을 만들 수 있고, 등급마다 다른 베네핏을 제공할 수 있다.
• GitHub는 2024년부터 0% 수수료를 유지한다 (결제 처리 수수료는 별도).
• 지급은 Stripe Connect 기반. 한국 메인테이너도 가능하지만 세금 처리는 본인 책임.

실제 데이터

공개된 데이터를 종합해 보면:

강점

• 마찰이 거의 없다: 후원자도 메인테이너도 GitHub 계정만 있으면 끝.
• 신뢰: 결제 인프라는 깃허브가 책임진다.
• 노출: 깃허브 프로필과 레포에 자연스레 노출된다.

한계

• B2B 전환이 약하다: 회사 결제팀은 깃허브로 사적 후원하는 워크플로를 안 좋아한다. 영수증, 부가세, 회계 항목으로 처리하기 까다롭다.
• 천장이 낮다: 후원자 한 명당 보통 $5~$25/월. 천 명 단위로 모으기 전엔 큰 돈이 안 된다.
• 베네핏 운영이 약하다: 후원 등급을 만들어도 등급별 자동화된 베네핏(다운로드, 사이트 접근 등) 제공은 빈약하다.

누구에게 맞는가

GitHub Sponsors는 "후원 채널을 한 개만 둔다면 이걸 둬라"의 정답이다. 다만 천장을 알고 시작하라. 대부분의 메인테이너는 GitHub Sponsors만으로는 풀타임을 만들 수 없다.

3장 · Polar.sh — 개발자 우선 MoR의 부상

Polar.sh는 2023년 등장 이후 2024~2026년 사이 개발자 친화적 결제 플랫폼의 강력한 대안으로 자리 잡았다. 핵심 차별점은 두 가지다.

1. Merchant of Record (MoR): Polar가 결제의 법적 판매자가 된다. 즉 부가세/판매세 신고, 인보이스 발급, 환불 처리를 Polar가 한다. 메인테이너는 그냥 입금만 받는다.
2. GitHub Sponsors와 통합: 2024년 후반 Polar는 GitHub Sponsors의 백엔드 결제를 처리하는 옵션을 제공하기 시작했다 — 한 곳에서 관리하면서 깃허브의 노출은 그대로 가져간다.

어떻게 작동하는가

• 구독 등급, 일회성 결제, 디지털 상품(파일, 라이선스 키), 베네핏(GitHub Issue 우선순위 등)을 자유롭게 구성.
• 수수료는 Stripe 대비 비슷한 수준이지만, MoR 비용이 포함되어 있다 (약 4% + Stripe 결제 수수료).
• GitHub 레포에 직접 후원 위젯을 임베드할 수 있다.
• 후원자가 PR을 열면 메인테이너가 우선 리뷰하는 식의 베네핏을 자동화할 수 있다.

강점

• B2B 친화: 인보이스 발급이 자동이다. 회사 회계팀이 행복하다.
• 유연한 가격책정: 등급, 한도, 기간 한정 캠페인 등 SaaS급의 가격책정 도구.
• 수익화 다변화: 후원만이 아니라 디지털 상품 판매 가능.
• 개발자 경험: API, Webhook이 잘 만들어져 있다. 자기 사이트에 통합하기 쉽다.

한계

• MoR 수수료: GitHub Sponsors의 "0% 수수료" 마케팅에 비해 명목상 비싸 보인다. 단, 세금/부가세 처리를 다 해주니 실질 비용은 다르다.
• 인지도: 일반 개인 후원자에게는 아직 GitHub Sponsors나 Ko-fi만큼 친숙하지 않다.
• 베네핏 자동화 의존: 베네핏 기반 모델이 잘 돌아가려면 SaaS 운영 마인드가 필요하다.

실제 사용 사례

Astro, Nuxt, Vercel이 후원하는 개별 메인테이너들, Yjs, Hono의 일부 메인테이너들이 Polar를 1차 채널로 쓴다. "GitHub Sponsors의 노출 + Polar의 결제 인프라" 조합이 사실상의 표준으로 굳어지는 중이다.

누구에게 맞는가

기업 후원자를 본격적으로 받으려는 메인테이너, 후원 외에 디지털 상품/유료 베네핏을 팔고 싶은 메인테이너, 세금 처리를 외주하고 싶은 메인테이너에게 강력하다.

4장 · Open Collective — 투명 회계와 그룹 자금

Open Collective는 단일 메인테이너보다는 단체/팀 OSS 프로젝트에 강한 채널이다. 핵심은 투명한 공개 장부다. 모든 수입과 지출이 누구나 볼 수 있는 페이지에 기록된다.

어떻게 작동하는가

• 프로젝트가 "Collective"를 만든다. 이건 법적 실체가 아니라, 호스팅 단체 아래에 있는 가상의 자금 풀이다.
• 후원자가 매월 또는 일회성으로 후원한다.
• 누군가 비용을 청구하면(예: "AWS 청구서 $50", "디자이너 외주비$200"), 그 자금 풀에서 지급된다.
• 모든 거래는 공개 페이지에 자동 기록된다.
• 재정 호스트(예: Open Source Collective 501(c)(6))가 법적/세무 책임을 진다.

강점

• 투명성: 후원자가 "내 돈이 어디에 쓰였는지" 정확히 본다. 작은 단체나 자선성 프로젝트에 강하다.
• 그룹 협업: 여러 메인테이너가 한 자금 풀을 공유하기 쉽다.
• 재정 호스팅: 법적 실체 없이도 후원을 받고 지출할 수 있다.

큰 변수 — 2024년 OCF 종료

2024년, Open Collective Foundation(OCF, 501(c)(3) 자선단체용 재정 호스트)이 운영 종료를 발표했다. 이로 인해 그 호스트 아래에 있던 600여 개 단체가 다른 호스트로 옮기거나 자금을 정리해야 했다.

이건 Open Collective 플랫폼 자체가 망한 것이 아니라 그중 한 호스트 단체의 종료다. 하지만 단체 OSS 프로젝트들이 "재정 호스트 종속 리스크"를 처음으로 진지하게 인식한 사건이었다.

2026년 현재, 개발자 OSS 프로젝트는 주로 Open Source Collective (501(c)(6) 무역협회) 아래에 있고 이 호스트는 안정적으로 운영 중이다. 하지만 옮길 곳이 적다는 구조적 리스크는 여전하다.

한계

• 단일 메인테이너에게는 오버킬: 1인 프로젝트에 투명 회계와 단체 자금 풀은 필요 없다.
• 수수료: 호스트 수수료 5~10% + 결제 처리 수수료가 보통이다. GitHub Sponsors보다 비싸다.
• 호스트 종속: 호스트 단체의 정책/생존이 프로젝트 자금에 영향을 준다.

누구에게 맞는가

여러 명이 함께 운영하는 OSS 프로젝트 — 예: webpack (다수의 메인테이너), Babel, Vue(과거), 그리고 미트업/콘퍼런스를 함께 운영하는 커뮤니티에 잘 맞는다. 단일 메인테이너 1인 라이브러리에는 GitHub Sponsors 쪽이 마찰이 적다.

5장 · Tidelift — 엔터프라이즈 구독료 모델

Tidelift는 다른 모든 채널과 근본적으로 다른 메커니즘을 쓴다. "후원"이 아니라 엔터프라이즈 구독료다.

어떻게 작동하는가

• 기업 고객이 Tidelift에 연 구독료를 낸다. 보통 본인들이 쓰는 OSS 패키지의 보안/라이선스 SLA를 받기 위함이다.
• Tidelift는 그 구독료를 사용 중인 OSS 패키지의 **lifter(메인테이너)**에게 분배한다.
• 메인테이너는 "lifter 계약"을 맺으면서 보안 패치 SLA, 라이선스 정보 정확성, 의존성 정리 같은 의무를 지고, 대가로 정기 수입을 받는다.

무엇이 다른가

• 선의 후원이 아니라 비즈니스 거래다: 고객이 SLA를 사는 것이고 메인테이너는 그 SLA를 제공한다.
• 기업 회계 친화: "오픈소스 보안 구독료"는 회사 회계 항목으로 명확하다.
• 메인테이너 수입이 안정적: 한 번 lifter가 되면 분기/연 단위로 수입이 들어온다.

실제 수입

공개된 데이터에 따르면 잘 깔린 패키지 메인테이너는 Tidelift만으로 $500~$3k/월 수준의 수입을 만든다. 다수의 인기 패키지 메인테이너이면 1만 달러 이상도 가능하다. 다만 신청-승인 과정이 있고 모든 패키지가 받아들여지지는 않는다.

강점

• 반복적 안정 수입: 분기/연 단위 계약이 기본.
• B2B 명확성: 회사 결제팀이 처리하기 쉬운 형태.
• 공급망 보안 트렌드와 정합: SBOM, 의존성 보안이 강조되는 시대에 부합.

한계

• 승인 게이트: Tidelift가 "이 패키지를 우리 카탈로그에 넣을지" 결정한다. 작거나 알려지지 않은 패키지는 등록이 안 될 수 있다.
• SLA 의무: 보안 패치를 정해진 시간 내에 내야 한다. 본업이 있다면 부담.
• 개인 후원 효과가 0이다: Tidelift는 개인 후원자에게 노출되는 채널이 아니다.

누구에게 맞는가

엔터프라이즈에서 깊게 쓰이는 라이브러리(보안 라이브러리, 핵심 인프라 라이브러리, 자주 인용되는 유틸리티)의 메인테이너에게 가장 강력하다. 컨슈머 앱 위주의 라이브러리에는 약하다.

6장 · Patreon / Ko-fi / Buy Me a Coffee — 소비자 후원의 미세 차이

이 세 채널은 종종 묶여서 언급되지만 사실 색깔이 꽤 다르다.

Patreon

• 원래 유튜버/팟캐스터/예술가 중심으로 자란 플랫폼.
• 등급(tier) 기반 멤버십 구독에 강하다.
• 수수료 8~12% + 결제 처리.
• OSS 메인테이너 중에는 콘텐츠를 곁들이는 사람들(블로그, 영상, 강의)이 주로 쓴다.

Ko-fi

• "커피 한 잔" 메타포의 일회성 팁이 자연스러운 톤.
• 정기 후원(멤버십)도 지원.
• 기본 0% 수수료 + Ko-fi Gold 유료 플랜.
• 디지털 상품 판매, 커미션 받기도 지원.
• 개발자 인디 메이커, 인디 게임 개발자, 디자이너에게 인기.

Buy Me a Coffee

• Ko-fi와 거의 비슷한 톤, 일회성 팁 중심.
• 5% 수수료, 그러나 깔끔한 UX와 강한 모바일 경험.
• 멤버십, 디지털 상품도 지원.

비교 매트릭스

OSS 메인테이너에게의 현실

이 세 채널 모두, "코드만 짜는" 메인테이너에게는 컨버전이 낮다. 후원자는 사람의 얼굴과 이야기를 후원하지, 패키지의 changelog를 후원하지 않는다. 콘텐츠(블로그, 영상, 트위터)가 강한 메인테이너에게는 강력하지만, 단순히 깃허브 활동만 있는 사람에게는 GitHub Sponsors보다 낫지 않다.

누구에게 맞는가

블로그/영상/Twitter(X) 같은 부수적 콘텐츠가 있고, 메인테이너 본인이 "퍼스널 브랜드"를 의식하는 경우. 그게 아니라면 GitHub Sponsors가 마찰이 적다.

7장 · Liberapay — 비영리 도네이션의 순수형

Liberapay는 다른 모든 채널과 가장 다른 운영 철학을 가졌다.

특징

• 비영리 (벨기에 ASBL) 단체가 운영.
• 자체 수수료 0% (결제 처리 수수료만).
• 정기 후원만 지원 (일회성 결제 없음).
• 익명 후원 가능.
• 자체도 Liberapay에서 후원을 받아 운영된다 ("개를 자기 사료로 먹이기").

강점

• 가장 "오픈소스 정신"에 가까운 채널 — 비영리, 투명, 익명성 보장.
• 수수료가 사실상 가장 낮다.
• 후원자의 개인정보 노출이 최소화된다.

한계

• 규모와 노출이 적다: 사용자 풀이 GitHub Sponsors보다 훨씬 작다.
• 일회성 후원 불가: "오늘 이 라이브러리 큰일 했네, 한 번만 후원할게"가 안 된다.
• 결제 인프라 의존: 결제 파트너 문제가 생기면 한동안 출금이 멈춘 적 있다.

누구에게 맞는가

이념적으로 비영리/투명한 채널을 우선하는 메인테이너, 그리고 익명 후원자 풀이 있을 만한 프라이버시/보안 도구 메인테이너에게 잘 맞는다.

8장 · Thanks.dev — 의존성 그래프 자동 분배

Thanks.dev는 후원의 "선택" 측면을 자동화하려는 시도다. 메인테이너 한 명씩 골라 후원 버튼을 누르는 대신, 레포의 의존성을 스캔해 자동으로 메인테이너에게 분배한다.

어떻게 작동하는가

• 기업이 Thanks.dev에 가입하고 월/연 예산을 정한다 (예: 월 $1,000).
• Thanks.dev가 그 회사 레포의 package.json, Cargo.toml, go.mod 등을 스캔한다.
• 의존성 가중치(직접/간접, 의존 패키지 수)에 따라 자동으로 예산을 메인테이너에게 분배한다.
• 메인테이너는 GitHub/Stripe 연동 후 입금만 받으면 된다.

강점

• 회사 입장: "어떤 OSS를 후원할지" 고민할 필요 없음. 우리가 실제로 쓰는 패키지의 메인테이너가 자동으로 보상받는다.
• 메인테이너 입장: 의존 그래프 깊숙이 있는 작은 패키지 메인테이너도 자동으로 보상받는다.
• 공급망 보안 정합: 우리가 의존하는 사람이 누구인지 자동으로 가시화된다.

한계

• 메인테이너 1인당 금액이 작다: 분배가 광범위해서 한 사람당 $1~$10/월 수준에 그치는 경우가 많다.
• 회사 측 인지도/예산 확보가 어렵다: "왜 OSS에 월 1,000달러를 써야 하는가"를 경영진에 설득하는 게 가장 큰 장벽이다.
• 메인테이너의 적극성 보상이 없다: 메인테이너가 활동을 멈춰도 분배는 계속될 수 있다.

Sentry의 Open Source Pledge 합류

Sentry는 2024년 시작한 Open Source Pledge의 일환으로, 풀타임 개발자 1인당 연 $2,000을 OSS 메인테이너 후원에 쓰겠다고 공약했다. 이 흐름에 합류하는 회사가 늘면 Thanks.dev 같은 자동 분배 채널의 임팩트가 커진다.

누구에게 맞는가

회사 측: 큰 OSS 의존 그래프를 가졌고 "보상 자동화"를 원하는 회사. 메인테이너 측: 깊은 의존성을 가진 작은 라이브러리(leftpad처럼 아래쪽에 있는 유틸리티) 메인테이너에게 새로 보이지 않던 수입을 만들어준다.

9장 · Algora — 현상금 + 후원의 결합

Algora는 두 가지를 동시에 한다. (1) 이슈 단위의 현상금(bounty) 마켓플레이스. (2) 회사 단위의 후원 채널.

어떻게 작동하는가

• 회사 또는 개인이 GitHub 이슈에 현상금을 건다 (예: "이 이슈를 해결하면 $500").
• 누구든 PR을 보내 머지되면 현상금을 받는다.
• 별개로 회사가 메인테이너/프로젝트에 정기 후원도 할 수 있다.
• 메인테이너는 자기 레포의 이슈에 회사 후원금에서 현상금을 직접 걸 수도 있다.

강점

• 결과 기반: 막연한 후원이 아니라 구체적 작업에 대한 결제.
• 신규 기여자 유인: 현상금이 있는 이슈는 신규 기여자를 끌어들이는 효과가 크다.
• 회사의 직접 영향력: "우리가 진짜 필요한 기능"에 직접 자금을 투입한다.

한계

• 메인테이너 시간 관점에서 위험: 현상금만 쫓는 기여가 늘면 메인테이너의 리뷰 부담이 커진다.
• AI 슬롭 위험 증가: 현상금이 큰 이슈에 AI로 대량 생성된 저품질 PR이 몰린다 (2025~2026년 가장 심각해진 현상).
• 메인테이너의 안정 수입은 아니다: 현상금은 한 번씩만 들어오는 수입이지 정기 수입이 아니다.

누구에게 맞는가

회사: 구체적 기능/버그 수정에 자금을 투입하고 싶을 때. 메인테이너: 안정 수입이 아닌 부수 수입 또는 신규 기여자 끌어들이기의 도구로.

10장 · 채널 vs 수입 매트릭스 — 솔직한 평가

지금까지의 9개 채널을, 메인테이너가 실제로 신경 쓰는 축에서 비교하자.

솔직한 추천 — 메인테이너 페르소나별

1인 라이브러리 메인테이너 (utility-belt 같은 작은 패키지)

• 1차: GitHub Sponsors (마찰 없음).
• 2차: Thanks.dev (의존 그래프 깊숙이 있다면 자동 수입).
• 3차: Algora 현상금 (의지 있는 회사가 있다면).

중규모 프레임워크/라이브러리 핵심 기여자

• 1차: GitHub Sponsors + Polar 통합 (노출 + B2B).
• 2차: Tidelift (보안 SLA 의무를 감당할 수 있다면).
• 3차: Open Collective (팀 단위로 운영한다면).

엔터프라이즈에서 깊게 쓰이는 인프라 라이브러리 메인테이너

• 1차: Tidelift (가장 정합).
• 2차: GitHub Sponsors (개인 후원자 보충).
• 3차: 직접 컨설팅/서포트 계약 (별개 글).

콘텐츠가 강한 메인테이너 (블로거, 영상 크리에이터)

• 1차: GitHub Sponsors + Patreon (콘텐츠 멤버십).
• 2차: Ko-fi / Buy Me a Coffee (일회성 팁).
• 3차: Polar (디지털 상품 판매).

11장 · 기업 측 — Open Source Pledge와 펀딩 모델

채널은 메인테이너 쪽 도구다. 기업 쪽에서도 변화가 있다. 2024~2026년의 핵심 흐름은 회사가 OSS에 정량적으로 돈을 쓰겠다고 공약하는 것이다.

Sentry의 Open Source Pledge

2024년 Sentry가 시작한 Open Source Pledge는 단순한 공식을 제안한다.

풀타임 개발자 1인당 연 $2,000을 OSS 메인테이너 후원에 쓴다.

100명의 회사면 연 $200,000, 1,000명의 회사면 연 $2M이다. 이게 모이면 메인테이너 풀에 의미 있는 자금이 들어간다.

2026년 현재 Sentry, Astral(uv/ruff), Vercel 일부 팀, Stripe 일부, 그 외 SaaS 회사 수십 곳이 합류했다. 운동의 임팩트는 합류한 회사 수가 1,000을 넘는지에 달려 있다. 2026년 현재는 100~수백 수준이다.

OpenJS, CNCF, Linux Foundation Europe

비영리 펀딩 모델도 진화 중이다.

• OpenJS Foundation: Node.js, Express, ESLint 등 JS 생태계의 OSS 프로젝트를 후원. 회사 회원비로 운영.
• CNCF: 쿠버네티스, Prometheus, etcd 등 클라우드 네이티브 프로젝트의 호스트. 인큐베이션과 졸업 단계로 프로젝트를 키운다.
• Linux Foundation Europe: 2022년 출범. 유럽 규제 환경에 맞춘 OSS 거버넌스 호스팅을 제공.

이 단체들이 후원하는 모델의 핵심은 "개인 메인테이너에게 직접 돈을 주기보다, 프로젝트 단위로 비용을 충당"하는 것이다. CI 인프라, 보안 감사, 콘퍼런스 운영비 등이 거기서 나간다.

VC 백 OSS 회사 — 다른 게임

Supabase, Tailscale, Vercel, Linear, Posthog 같은 VC 백 OSS 회사는 펀딩 구조 자체가 다르다.

• 시드/시리즈 자금이 메인테이너의 풀타임 월급을 처음부터 책임진다.
• 핵심 메인테이너는 회사 직원이고, 외부 기여자는 회사가 관리한다.
• 매출은 클라우드 호스팅 / SaaS / 엔터프라이즈 라이선스로 만든다.
• 후원은 거의 받지 않거나, 외부 기여자를 GitHub Sponsors 등으로 지원하는 정도.

이 모델은 OSS 회사이지 메인테이너 펀딩 채널이 아니다. Supabase의 메인테이너가 GitHub Sponsors로 받는 후원금은 회사 월급과 별개의 소액이다. 이 두 가지를 혼동하면 곤란하다.

12장 · "기업 돈 받아도 되는가" — 솔직한 논쟁

오픈소스 펀딩의 가장 큰 정치 논쟁은 "기업 돈을 받는 게 옳은가"다. 핵심 입장 세 가지를 정리해보자.

입장 1 — "기업 돈은 무조건 받아야 한다"

• 회사는 메인테이너의 노동에서 가치를 얻는다. 그 가치를 받는 게 정당하다.
• 메인테이너가 굶으면 OSS 자체가 위험해진다 (xz-utils 같은 사건).
• 어떤 회사 돈을 받든 메인테이너가 결정권을 가지면 된다.

입장 2 — "조건부로 받는다"

• 라이선스 결정권, 로드맵 결정권을 회사에 양보하지 않는 한 받아도 된다.
• 단, 한 회사의 비중이 너무 크면 위험하다. 후원자 풀이 다양해야 한다.
• 회사의 "스폰서 우선순위" 같은 베네핏은 신중히 설계해야 한다.

입장 3 — "기업 돈을 받으면 영혼이 팔린다"

• 회사 후원자는 결국 영향력을 행사한다. 명시적이지 않더라도 묵시적으로.
• 비영리 채널(Liberapay)만 쓰는 게 더 깨끗하다.
• "취미로서의 OSS"의 순수성을 지켜야 한다.

현실적인 절충안

대부분의 메인테이너는 입장 2(조건부)로 수렴한다. 실전 가이드라인은 이렇다.

• 한 후원자가 전체 수입의 30%를 넘지 않게 풀을 다양화한다.
• 라이선스/거버넌스 결정은 후원과 무관함을 명시한다.
• 후원자 베네핏은 "이슈 우선순위 같이 시간 효율" 위주이고, 코드 결정에 영향을 주는 형태(예: "스폰서가 요청한 기능 우선")는 피한다.
• 후원 내역을 공개한다. 투명성이 신뢰를 만든다.

13장 · 메인테이너 시점의 실전 — 풀타임 OSS는 가능한가

이제 가장 어려운 질문에 답할 차례다. "내가 풀타임 OSS 메인테이너가 될 수 있는가?"

풀타임 OSS의 두 가지 길

1. VC 백 OSS 회사에 합류한다: 직원이 되는 길. 가장 안정적이지만, 더 이상 "독립 메인테이너"는 아니다.
2. 다양한 채널의 후원으로 풀타임 수입을 만든다: 어렵지만 가능. 2026년 기준 풀타임 OSS로 사는 독립 메인테이너는 전 세계 수백 명 정도로 추정.

풀타임 후원 수입의 현실적 공식

대략적인 공식은 이렇다.

풀타임 후원 수입 = 
  GitHub Sponsors (개인 후원 합) 
  + Polar / 디지털 상품 / 베네핏
  + Tidelift (해당된다면)
  + 회사 직접 후원 (Sentry Pledge 등)
  + 컨설팅/스피킹 (별개 수입)

성공 케이스를 보면 한 채널에서 큰돈이 나오는 게 아니라 여러 채널의 합산이다. 각 채널이 월 $1k씩 5개면 $5k다.

시간 분배의 함정

풀타임 OSS 메인테이너의 실제 시간 분배는 종종 이렇게 된다.

• 코드 작성/머지: 30%
• 이슈 트리아지: 25%
• 후원자 관리/콘텐츠/뉴스레터: 20%
• 컨설팅/스피킹/세금/회계: 15%
• 휴식: 10%

"코드 짜는 시간"이 전체의 1/3 이하인 게 정상이다. 이걸 모르고 풀타임으로 전환하면 번아웃이 빠르게 온다.

안정성 — 다각화가 보험이다

한 후원자가 떠나도, 한 채널이 망해도, 한 회사가 망해도 수입이 유지되도록 분산하라.

• 채널 3~4개 병행 (GitHub Sponsors + Polar + Tidelift + Open Collective).
• 후원자 수십~수백 명 (특정 한 명에게 의존하지 않음).
• 별도 수입원 (강의, 책, 컨설팅).

14장 · 메인테이너의 첫 90일 — 실전 셋업

가장 자주 받는 질문은 "지금 막 인기가 생긴 라이브러리가 있는데, 후원 채널을 어떻게 시작하나"이다. 90일 플랜으로 정리한다.

Day 0~7 — 기본 셋업

1. GitHub Sponsors 등록. Stripe 연결.
2. 레포에 FUNDING.yml 추가, Sponsor 버튼 활성화.
3. 후원 등급 3개 정도로 시작: $5, $25, $100.
4. 등급별 베네핏은 처음엔 "감사 인사 + README에 이름"만으로 충분.

Day 8~30 — 메시지 만들기

1. 후원 페이지에 "왜 후원하면 좋은지" 명확히 쓴다.
2. 진행 중인 작업, 로드맵, 시간 투입을 정직하게 공개한다.
3. 첫 후원자에게 진심 어린 감사 메시지를 보낸다. 이게 다음 후원자를 만든다.

Day 31~60 — 채널 확장

1. Polar.sh 추가. GitHub Sponsors 통합 또는 독립 운영 결정.
2. 의존성 그래프가 깊다면 Thanks.dev 등록.
3. 인프라/보안 라이브러리라면 Tidelift 신청.

Day 61~90 — 측정과 조정

1. 어떤 채널이 컨버전되는지 측정한다.
2. 후원자에게 "무엇이 도움이 됐는지" 짧은 설문.
3. 첫 90일의 학습으로 다음 분기 계획을 짠다.

체크리스트 (첫 90일):
[ ] GitHub Sponsors 활성화 + Stripe 연결
[ ] FUNDING.yml 추가
[ ] 후원 등급 3개 설정
[ ] 후원 페이지에 메시지 작성
[ ] 첫 후원자에게 감사 메시지
[ ] Polar.sh 검토 (B2B 후원자 있다면)
[ ] Thanks.dev 등록 (의존성 깊다면)
[ ] Tidelift 신청 (인프라 라이브러리라면)
[ ] 측정 데이터 정리 (첫 90일)

에필로그 — 체크리스트와 안티패턴

오픈소스 펀딩은 결국 두 가지 능력의 결합이다. (1) 좋은 코드를 만드는 능력. (2) 그 코드에서 일하는 사람의 가치를 정직하게 전달하는 능력. 둘 중 하나만 있으면 풀타임은 어렵다.

메인테이너 펀딩 체크리스트

1. 내 라이브러리가 실제로 누구에게, 어떻게 쓰이고 있는지 안다.
2. GitHub Sponsors가 활성화되어 있다.
3. FUNDING.yml이 레포에 있다.
4. 후원 페이지에 "왜"가 명확하다 (단순한 "도네이트" 버튼이 아님).
5. B2B 후원 가능성이 있다면 Polar 또는 Tidelift를 검토했다.
6. 후원자 풀이 한 명/한 회사에 의존하지 않는다.
7. 후원과 코드 결정권은 분리되어 있다.
8. 후원 내역은 (적어도 합계는) 공개한다.
9. 풀타임이 목표라면 채널 3개 이상, 후원자 50명 이상이 보인다.
10. 번아웃 방지: 코드 외 시간(트리아지, 후원자 관리)을 30~50% 예산으로 잡는다.

안티패턴 모음

• "좋은 코드를 만들면 알아서 후원이 들어올 것"이라는 환상: 들어오지 않는다. 후원자에게 보이지 않으면 후원도 없다.
• 한 회사에 70% 의존: 그 회사가 정책을 바꾸면 수입이 한 번에 사라진다.
• 베네핏을 코드 결정과 묶기: "스폰서가 요청한 기능 우선"은 결국 영혼을 판다.
• 세금 무시: 메인테이너 책임 채널(GitHub Sponsors, Patreon, Ko-fi)을 쓰면서 세금 처리를 안 하면 나중에 큰 청구서가 온다.
• 수익화 콘텐츠로 메인테이너 활동 대체: 후원자가 늘면서 코드 작성 시간이 줄면 본말이 전도된다.
• 다채널 동시 시작: 9개 채널을 한 번에 시작하지 마라. 하나도 제대로 운영 못 한다. GitHub Sponsors부터.
• 번아웃을 숨기기: 후원자는 메인테이너의 정직한 상태 업데이트를 가장 신뢰한다. "번아웃 와서 한 달 쉽니다"가 "잠수 후 사과"보다 훨씬 낫다.

다음 글 예고

다음 글에서는 **"OSS 라이선스 2026 — MIT부터 AGPL, BSL, FSL, Elastic License까지 메인테이너의 선택"**을 다룬다. 펀딩 채널은 결제 메커니즘이지만, 라이선스는 메인테이너가 일하는 환경 자체를 결정한다. AWS의 무임승차 대응, Open Core를 가능하게 한 라이선스 진화, 그리고 "MIT는 정말 영원히 최선인가"라는 질문까지 정직하게 들여다본다.

오픈소스는 사랑의 노동이다. 하지만 사랑만으로는 안 된다. 메인테이너의 시간이 정당히 보상받는 구조를 함께 만들어 가는 것 — 그게 2026년 OSS의 가장 큰 숙제다. 그리고 그 숙제를 푸는 첫 단계는, FUNDING.yml을 레포에 추가하는 5분의 일이다.

참고 / References

• GitHub Sponsors
• GitHub Sponsors Docs
• Polar.sh
• Polar GitHub Integration
• Open Collective
• Open Source Collective (Host)
• OCF Sunset Announcement (2024)
• Tidelift
• Tidelift Lifter Program
• Patreon
• Ko-fi
• Buy Me a Coffee
• Liberapay
• Thanks.dev
• Algora
• Sentry Open Source Pledge
• Open Source Pledge — Member List
• OpenJS Foundation
• Cloud Native Computing Foundation
• Linux Foundation Europe
• Synopsys OSSRA Report
• Tidelift Maintainer Survey
• xz-utils backdoor analysis (Filippo Valsorda)
• Nadia Eghbal — Roads and Bridges
• Nadia Eghbal — Working in Public
• GitHub Octoverse 2024
• Stripe Atlas — OSS taxes guide
• Caleb Porzio — How I make OSS sustainable
• Sindre Sorhus — Sponsorship FAQ
• Evan You — Vue funding history
• Anthony Fu — OSS journey
• Open Source Pledge — Why $2,000