오픈소스 메인테이너 되기 완전 가이드: 첫 PR부터 프로젝트 소유, 스폰서십, 번아웃까지 (2025)

들어가며 — "내 프로젝트에 스타 1000개 찍혔는데 돈이 안 벌려요"

오픈소스 개발자 K:

"깃허브 프로젝트가 5,000 스타인데 월 GitHub Sponsors 수입은 $200이에요. 회사 관두고 OSS 전업해도 될까요?"

답: 대부분의 경우, No. OSS로 생계 유지하는 사람은 전 세계 0.1% 미만이고, 그들조차 대부분 회사 후원 또는 OSS 기반 스타트업이다. Faker.js 메인테이너가 "기업이 공짜로 쓰면서 지원 안 한다"며 코드를 고의로 망가뜨린 2022년 사건은 OSS 지속 가능성의 근본 문제를 드러냈다.

그럼에도 OSS는:

커리어 부스터 (Staff+ 승진의 증거)
학습 엔진 (코드 리뷰 = 최고의 성장)
글로벌 네트워크
창업 기반 (MongoDB, HashiCorp, Supabase)

이 글은:

첫 PR부터 메인테이너까지의 실전 경로
수입 모델 (GitHub Sponsors, Open Collective, Tidelift, OSS 창업)
라이선스 선택 — MIT/Apache/GPL/AGPL/BSL/Elastic
번아웃과 Faker.js/XZ 백도어 교훈
거버넌스 모델 (BDFL, Foundation, 기업 지원)
한국 OSS 씬 현실과 글로벌 기여 전략

을 다룬다. Season 3 Episode 6. 지난 편에서 "외부 브랜드"를 Staff+의 체크리스트로 뒀는데, OSS가 그 가장 강력한 수단이다.

Chapter 1: OSS 참여의 단계 — 5단계

1.1 Level 0 — 사용자

그냥 씀. Issue도 안 읽음.

1.2 Level 1 — Issue 리포터

버그 발견 → 재현 가능한 Issue 등록
질문은 GitHub Discussions 또는 Stack Overflow로

좋은 Issue의 구성:

재현 경로 (최소한 코드)
기대 동작 vs 실제 동작
환경 정보 (OS, 버전)
에러 메시지 전문

1.3 Level 2 — 첫 PR

"Good First Issue" 라벨 활용:

GitHub 검색: is:issue label:"good first issue" language:typescript
goodfirstissue.dev

첫 PR의 공식:

작은 범위 (오타 수정도 OK)
테스트 포함
CONTRIBUTING.md 엄수
작성 후 리뷰 기다리며 다른 일

1.4 Level 3 — 정기 기여자

여러 PR 머지
Issue 트리아지 도움
커뮤니티 Q&A 응답

이 단계에서 메인테이너가 당신을 인지한다. 정기성이 핵심.

1.5 Level 4 — 메인테이너

리뷰/머지 권한
릴리스 주기 관여
로드맵 결정
신규 컨트리뷰터 멘토링

메인테이너가 되는 법: 메인테이너가 먼저 초대. 요청한다고 주는 경우 드묾. 증명이 먼저.

1.6 Level 5 — 프로젝트 오너

자신의 프로젝트 시작
커뮤니티 구축
거버넌스 설계
장기 지속 가능성

Chapter 2: 첫 PR의 실전 팁

2.1 프로젝트 선택

좋은 첫 프로젝트:

자신이 실제 쓰는 도구
메인테이너 활발 (최근 30일 내 커밋)
친절한 커뮤니티 (Code of Conduct 있음, 답변 친화적)
최소 100~1000 스타 (너무 작으면 커뮤니티 없음, 너무 크면 첫 진입 어려움)

피해야 할 프로젝트:

메인테이너 무반응 (6개월 이상)
열린 PR 수백 개 (처리 안 됨)
단일 기업 완전 통제 (기여 받아도 내부 결정만)

2.2 프로젝트 이해

README 읽기: 프로젝트 목적
CONTRIBUTING.md: 기여 가이드
Architecture 문서: 있으면 필독
Issue 목록 읽기: 어떤 문제가 중요한가
최근 머지된 PR 5개: 리뷰 스타일 감 잡기
로컬에서 빌드/테스트: 돌려봐야 이해됨

2.3 PR 체크리스트

Issue 링크 또는 이유 명시
작은 범위 (PR 하나에 기능 하나)
테스트 추가/수정
린트/포맷 통과
커밋 메시지가 Convention 따름
CI 그린
스크린샷/예시 (UI 변경 시)

2.4 리뷰 받기

피드백 대응:

감사 인사 후 빠르게 수정
의견 다르면 기술적 근거로 논의
개인 감정 배제
빨리 못 해도 "언제까지 할게요" 소통

피해야 할 태도:

"왜 이렇게 쓸데없이 꼼꼼히 보나"
무반응 (7일 이상)
오해의 "왜 이렇게 느리냐" 태그

Chapter 3: 메인테이너의 일상

3.1 시간 배분

1,000 스타 프로젝트:

주 5~10시간
Issue 트리아지 40%
PR 리뷰 30%
본인 코드 작성 20%
커뮤니티 Q&A 10%

10,000+ 스타:

주 20~40시간
Issue 트리아지 20% (봇 도움)
PR 리뷰 30%
거버넌스/로드맵 20%
컨퍼런스/블로그 15%
본인 코드 15%

3.2 Issue 트리아지

들어오는 Issue 유형:

버그 리포트 — 재현 → 확인 → 라벨
기능 요청 — 로드맵 적합성 판단
질문 — Discussions로 이동, 또는 답변
중복 — 기존 Issue로 링크 후 닫음
스팸/노이즈 — 닫음

도구:

Probot: 자동화 봇
Stale bot: 오래된 Issue 자동 닫기
CODEOWNERS: 자동 리뷰어 지정

3.3 릴리스 주기

Semantic Versioning (MAJOR.MINOR.PATCH):

MAJOR: 파괴적 변경
MINOR: 하위 호환 기능
PATCH: 버그 수정

릴리스 전 체크:

CHANGELOG 업데이트
마이그레이션 가이드 (MAJOR)
테스트 커버리지 유지
보안 감사 (Dependabot, Snyk)
태그 + GitHub Release
npm/PyPI/Maven 퍼블리시

3.4 Discord/Slack 커뮤니티

장점: 실시간 Q&A, 커뮤니티 성장 단점: 지식이 사라짐(검색 불가), 메인테이너 시간 소모

절충: Q&A는 GitHub Discussions로 유도. 채팅은 가볍게.

Chapter 4: 수입 모델 — 8가지

4.1 GitHub Sponsors

2019년 런칭
개인/기업이 월정액 후원
GitHub이 2026년까지 수수료 0%
평균: 유명 메인테이너 월 $200~$ 5,000
탑 티어 (예: Evan You, Vue.js): 월 $30K+

4.2 Open Collective

투명한 재정 관리
다수 기여자 팀에 적합
스폰서 로고, 리워드
예: Webpack, Babel

4.3 Tidelift

기업 구독 모델
여러 OSS 메인테이너를 묶어 기업에 판매
메인테이너 수입 안정
보안/라이선스 책임

4.4 Patreon

구독 모델 (Tier별)
Content creator에 적합
예: 일부 블로거형 OSS 개발자

4.5 컨설팅

OSS 저자가 해당 기술로 컨설팅
시간당 $200~$ 1,000+
예: Rust Consulting, Kubernetes Expert

4.6 서적/강의

O'Reilly, Manning 책
Pluralsight, Udemy 강의
YouTube 채널
예: Kent C. Dodds (Epic React)

4.7 기업 고용

기업이 OSS 메인테이너 채용
"당신이 유지보수하는 그 OSS를 계속 해 주세요"
예: React (Meta), Go (Google), Rust (Mozilla 초기)

흔한 구조: 유명 OSS → 해당 기업 DevRel/Principal 포지션으로 흡수.

4.8 OSS 기반 회사

Commercial Open Source 모델
예: MongoDB, Elastic, HashiCorp, Supabase, Vercel
다음 챕터에서 상세히.

Chapter 5: Commercial Open Source — 회사 만들기

5.1 Open Core 모델

구조:

코어 기능: 오픈소스 (무료)
엔터프라이즈 기능 (SSO, RBAC, 감사): 유료

예: GitLab, Elastic, Confluent(Kafka).

5.2 Service 모델

구조:

코드: 오픈소스
매니지드 호스팅: 유료

예: MongoDB Atlas, Elastic Cloud, Supabase, PlanetScale, Vercel.

5.3 SSPL/BSL — 라이선스 전환 논란

MongoDB (2018): AGPL → SSPL 전환. 이유: AWS가 MongoDB를 "DocumentDB"로 매니지드 서비스 판매 → MongoDB는 수익 없음.

Elastic (2021): Apache 2 → Elastic License + SSPL. AWS와 전면전.

HashiCorp (2023): MPL → BSL. 경쟁사 매니지드 막기 위해.

Redis (2024): BSD → SSPL + RSAL. → 커뮤니티 반발 → Valkey 포크 탄생.

교훈: OSS 회사가 클라우드 경쟁에 직면하면 라이선스 강화 유혹. 커뮤니티는 배신감.

5.4 성공 사례 — Supabase

PostgreSQL 기반 Firebase 대안
완전 오픈소스 (Apache 2)
2020 창업, 2023년 Series C
전략: "OSS 그대로 쓰되 매니지드 하세요"

5.5 Vercel의 전략

Next.js를 만든 회사
Next.js는 MIT (완전 오픈)
Vercel = 최적의 Next.js 호스팅
2024년 기준 ARR $100M+ 추정

핵심: OSS가 무료라도, **"가장 잘 돌리는 법"**을 파는 모델.

Chapter 6: 라이선스 완전 가이드

6.1 Permissive 라이선스

MIT (가장 흔함):

사용, 수정, 배포 자유
소스 공개 의무 없음
예: React, Vue, Rails

Apache 2.0:

MIT + 특허 보호 조항
기업 선호
예: Kubernetes, Kafka, Android

BSD:

MIT와 유사
BSD 2-clause, 3-clause
예: Go, PostgreSQL

6.2 Copyleft

GPL v3:

수정본도 GPL로 공개 의무
"Strong copyleft"
예: Linux, GCC, Bash

AGPL:

GPL + 네트워크 사용도 포함
SaaS 회사 기피
예: MongoDB (과거)

LGPL:

라이브러리 동적 링킹 시 제한 완화
예: glibc

MPL 2.0:

파일 단위 copyleft
중간 타협
예: Firefox

6.3 "Source Available" (OSI 비승인)

BSL (Business Source License):

4년 후 Apache로 전환
"초기 4년만 상업 제한"
예: MariaDB 초기, HashiCorp Terraform

SSPL (Server Side Public License):

MongoDB 제안
서비스로 판매 시 전체 스택 공개 의무
OSI: "Open Source 아님"
AWS-like 매니지드 차단

Elastic License 2.0:

관리형 서비스 판매 금지
Elasticsearch 7.11+

RSAL (Redis Source Available License):

Redis 7.4+
서비스로 판매 금지
→ Valkey 포크 촉발

6.4 선택 가이드

목적	추천
최대 확산	MIT
기업 안심	Apache 2.0
수정본도 공유 강제	GPL v3
SaaS 보호	AGPL 또는 BSL
라이브러리	MIT 또는 LGPL
상업화 염두	Apache 2.0 (나중에 변경 가능)

6.5 CLA vs DCO

CLA (Contributor License Agreement): 기여자가 기업에게 라이선스 양도 동의. 미래 재라이선스 가능.

DCO (Developer Certificate of Origin): 커밋 메시지 Sign-off만. 양도 없음.

Linux는 DCO. 대부분 기업 OSS는 CLA (라이선스 유연성 위해).

Chapter 7: 거버넌스 모델

7.1 BDFL (Benevolent Dictator For Life)

한 사람이 최종 결정
예: Python의 Guido van Rossum (2018년 은퇴), Linux의 Linus Torvalds, Vue의 Evan You

장점: 일관된 비전, 빠른 결정 단점: 버스 팩터 1 (그 사람이 사라지면?)

7.2 Foundation 모델

비영리 재단이 프로젝트 소유
기업 후원, 중립적 거버넌스
예: Linux Foundation, Apache Foundation, CNCF, Eclipse

장점: 기업 신뢰, 지속 가능성 단점: 느림, 관료화

7.3 기업 주도 오픈소스

특정 기업이 주요 메인테이너 + 로드맵
예: React (Meta), TypeScript (Microsoft), Flutter (Google)

장점: 자원 풍부, 빠른 개발 단점: 기업 방향 변경 시 프로젝트 방향 바뀜

7.4 Core Team (민주적)

수 명 코어 팀이 결정
투표 또는 합의
예: Kubernetes SIG (Special Interest Groups)

7.5 RFC 프로세스

Rust의 RFC:

누구나 RFC 작성 가능
GitHub PR로 제출
커뮤니티 토론
Core team 합의 → Merge

예: async/await 추가, GAT(Generic Associated Types) 추가.

Python도 PEP (Python Enhancement Proposal) 유사.

Chapter 8: Faker.js, colors.js, XZ 백도어 — 교훈

8.1 Faker.js 사건 (2022.01)

메인테이너 Marak Squires:

"기업들이 공짜로 쓰면서 지원 안 한다"
코드를 의도적으로 망가뜨림 (무한 루프)
GitHub이 계정 정지

영향:

수많은 프로젝트 빌드 실패
커뮤니티가 즉시 포크 → 공식 유지
Supply Chain 취약성 노출

8.2 colors.js 사건 (2022.01)

같은 메인테이너:

colors.js에 무한 루프 인식 → 수많은 Node.js 프로젝트 장애
주간 다운로드 2000만+ 패키지

8.3 교훈 1: Supply Chain 감사

package-lock.json 검토: 얼마나 많은 단일 메인테이너에 의존하는가
Signed commits: GitHub/Sigstore
SBOM (Software Bill of Materials): 의존성 목록 관리

8.4 XZ Utils 백도어 (2024.03)

Linux 필수 라이브러리 XZ 백도어 심어짐
"Jia Tan"이라는 이름의 기여자가 2년간 신뢰 쌓기
sshd 인증 우회 가능한 백도어 삽입
Andres Freund가 우연히 발견 (SSH 로그인 0.5초 느림 이상)

충격:

"사회공학 × OSS" 결합
메인테이너 번아웃 틈새로 침투
피해 회피는 운이 좋았다

8.5 교훈 2: 메인테이너 지원 필수

핵심 인프라 의존 OSS는 기업이 유지해야.

Google, Microsoft, AWS 등은 OSS 보안에 투자 시작:

Google OSS-Fuzz
GitHub Advanced Security
OpenSSF (Open Source Security Foundation)
Sigstore (공급망 서명)

8.6 교훈 3: 번아웃 사전 예방

혼자 끌지 말 것
Co-maintainer 초대 빠르게
긴 휴식 필요 시 선언
커뮤니티에 솔직히 소통

Chapter 9: 본인 OSS 프로젝트 만들기

9.1 시작 체크리스트

9.2 초기 스타 얻기 전략

실제 문제 해결: 본인 pain point → 남들도 공감
Hacker News/Reddit 포스팅
Twitter/블로그로 공유
Show HN
Awesome- 목록에 PR*
컨퍼런스 Lightning Talk

9.3 성공 사례 — Tailwind CSS

2017년 Adam Wathan 시작
"CSS 유틸리티 우선" 컨셉
초기: 개인 프로젝트, 강의 사이드
2021년: Tailwind Labs 회사 설립, Tailwind UI 판매
현재: 연 수백만 달러 규모

비결: 명확한 메시지, 공식 문서 품질, 유료 UI 라이브러리.

9.4 성공 사례 — Docusaurus

Meta 내부 도구 → OSS
2017년 공개
Meta가 유지 (전담 엔지니어)
수많은 프로젝트의 문서 사이트

9.5 성공 사례 — SWR / Zustand (Vercel의 Jamie Kyle, Daishi Kato)

단일 파일, 제한된 범위
"작은 것"의 힘
유명 OSS 개발자의 여러 작은 프로젝트 전략

Chapter 10: Rust, Kubernetes, Node.js — 대형 프로젝트 기여법

10.1 Rust

거버넌스: Rust Foundation (기업 후원) + Core Team
RFC 프로세스 활발
"Working Group" 단위 기여 (async, WASM, compiler)
초심자 가이드: The Rustonomicon, rustc-dev-guide
Good First Issue 풍부

10.2 Kubernetes

CNCF 졸업 프로젝트
SIG (Special Interest Group) 구조
SIG Node, SIG Network, SIG Auth 등 30+
기여: 먼저 SIG 참여 → 점진적 책임
도구: Prow, Tide (자체 CI)

10.3 Node.js

OpenJS Foundation
TSC (Technical Steering Committee)
Core/Commits/Collaborators 단계
면밀한 semver 관리

10.4 Python

Python Software Foundation
PEP 프로세스
Steering Council (2018 이후)
기여 난이도 높음 (코어는 C)
pip, setuptools 등 주변 도구 기여가 진입점

10.5 대형 프로젝트 기여 팁

Documentation 먼저: 오타, 예시 추가
테스트 추가: 기존 기능의 테스트 커버리지 향상
Issue 트리아지: 메인테이너 시간 절약
좋은 PR 분리: 하나의 목적
인내심: 리뷰 수 주 걸림

Chapter 11: 한국 OSS 씬

11.1 한국 발 글로벌 OSS

카카오 오픈소스: Ray, Khaiii, khan
네이버 오픈소스: ngrinder, Arcus
LINE: Armeria, CentralDogma
우아한형제들: 다양한 Java 라이브러리
토스: es-toolkit, next-route-handler-pipe
당근: mini, react-native 관련 도구
삼성: Tizen (규모 크지만 활성도 낮음)
개인 프로젝트: 김영한(JPA), 박재성(오픈뱅킹 라이브러리), 이응준 외 다수

11.2 한국 OSS의 어려움

영어 장벽: Issue/PR 모두 영어
시간대 차이: 미국/유럽 메인테이너와 비동기 지연
회사 승인: 기업 소속 시 공개 승인 어려움
문화: "드러나는 것" 기피 경향

11.3 글로벌 기여 시작 팁

자신이 쓰는 도구에 기여: 한국어 번역부터
Good first issue 검색: 작게
한국 OSS 활동가와 네트워크: GeekNews, 커피숍 밋업
당분간은 PR보다 Issue + 번역: 언어 적응기

11.4 한국 OSS 커뮤니티

파이콘 한국: Python 커뮤니티
JavaScript Seoul: 프론트엔드
FEConf: 프론트엔드 대형 컨퍼런스
GopherCon Korea: Go
GDG/Mozilla/공식 지부

Chapter 12: 12항목 OSS 메인테이너 체크리스트

Chapter 13: 10가지 OSS 안티패턴

1) "내가 다 해야 해"

모든 PR을 혼자 리뷰, 모든 Issue를 혼자 대응. 번아웃의 지름길. 공동 메인테이너 필수.

2) 스타 개수에 집착

1만 스타가 목표. 실제 사용자/기여자 없음. 실제 사용 케이스가 지표.

3) 라이선스 안 붙임

4) Breaking Change 남발

매 마이너 버전마다 API 변경. 사용자 이탈. Semver 엄수.

5) 1인 프로젝트 기업에 판매

1인 OSS → 기업 매각 → 메인테이너 잠적. 커뮤니티 대참사. 투명한 인수/이관 계획.

6) 새 기능만 만들고 버그는 방치

Issue 수백 개. PR 수백 개. 아무도 리뷰 안 함. 유지보수 > 신규.

7) 라이선스 급 전환

MIT → SSPL 하루아침에. 커뮤니티 신뢰 파괴. 사전 논의, 투명한 이유.

8) "일본어 이슈는 영어로 써주세요"

다국어 기여자 배제. 영어 1차, 모국어도 OK의 유연성.

9) Trademark 갈등

Elastic vs AWS, Akka vs Lightbend. 이름 분쟁. Trademark 등록 / 재단 이관.

10) 번아웃 신호 무시

몇 달째 답 안 함. 갑자기 "다 중단합니다". 초기에 도움 요청.

마치며 — OSS는 선물 경제

원칙 1: OSS는 선물이다

당신이 쓰는 수많은 OSS는 누군가의 무료 시간. 감사하고, 가능하면 갚아라.

원칙 2: 기여는 커리어

Staff+ 승진의 명확한 신호. "외부 브랜드"의 가장 강력한 수단.

원칙 3: 작게 시작

2,000 스타 프로젝트가 200,000 스타보다 기여하기 쉽다.

원칙 4: 지속 가능성이 답

혼자 영웅 되려 하지 말 것. 3명 메인테이너가 1명보다 20배 안정적.

원칙 5: 회사에 협상

회사에서 OSS에 시간 쓰는 협상을 하라. 20% time, OSS Friday, sponsored contribution.

원칙 6: 원본을 읽어라

다음 글 예고 — "개발자 글쓰기 완전 가이드: Design Doc, RFC, Blog, 책"

Season 3 Ep 7은:

Design Doc의 구조와 좋은 예
RFC (Request for Comments) 프로세스
기술 블로그 시작하고 키우는 법 (Stratechery, Dan Luu, Julia Evans 분석)
기술서 쓰기 (O'Reilly, Manning, 자가 출판)
컨퍼런스 발표 — 초안부터 본 발표까지
GitHub README의 품질 올리기
AI 시대의 글쓰기 (Copilot/Claude 활용)
한국 개발자의 글쓰기 — 한글 vs 영어
Staff+ 승진 패킷 쓰는 법

다음 글에서.