LabHub

블로그

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

2026-04-15 · 24 분 읽기 · #open-source#maintainer#github#sponsorship#licensing#community#oss-career#commercialization#burnout#deep-dive

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

오픈소스 개발자 K:

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

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

그럼에도 OSS는:

이 글은:

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

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

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

1.1 Level 0 — 사용자

그냥 씀. Issue도 안 읽음.

1.2 Level 1 — Issue 리포터

좋은 Issue의 구성:

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

1.3 Level 2 — 첫 PR

"Good First Issue" 라벨 활용:

첫 PR의 공식:

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

1.4 Level 3 — 정기 기여자

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

1.5 Level 4 — 메인테이너

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

1.6 Level 5 — 프로젝트 오너

Chapter 2: 첫 PR의 실전 팁

2.1 프로젝트 선택

좋은 첫 프로젝트:

피해야 할 프로젝트:

2.2 프로젝트 이해

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

2.3 PR 체크리스트

2.4 리뷰 받기

피드백 대응:

피해야 할 태도:

Chapter 3: 메인테이너의 일상

3.1 시간 배분

1,000 스타 프로젝트:

10,000+ 스타:

3.2 Issue 트리아지

들어오는 Issue 유형:

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

도구:

3.3 릴리스 주기

Semantic Versioning (MAJOR.MINOR.PATCH):

릴리스 전 체크:

3.4 Discord/Slack 커뮤니티

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

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

Chapter 4: 수입 모델 — 8가지

4.1 GitHub Sponsors

4.2 Open Collective

4.3 Tidelift

4.4 Patreon

4.5 컨설팅

4.6 서적/강의

4.7 기업 고용

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

4.8 OSS 기반 회사

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

5.1 Open Core 모델

구조:

예: 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

5.5 Vercel의 전략

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

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

6.1 Permissive 라이선스

MIT (가장 흔함):

Apache 2.0:

BSD:

6.2 Copyleft

GPL v3:

AGPL:

LGPL:

MPL 2.0:

6.3 "Source Available" (OSI 비승인)

BSL (Business Source License):

SSPL (Server Side Public License):

Elastic License 2.0:

RSAL (Redis Source Available License):

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)

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

7.2 Foundation 모델

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

7.3 기업 주도 오픈소스

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

7.4 Core Team (민주적)

7.5 RFC 프로세스

Rust의 RFC:

  1. 누구나 RFC 작성 가능
  2. GitHub PR로 제출
  3. 커뮤니티 토론
  4. 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:

영향:

8.2 colors.js 사건 (2022.01)

같은 메인테이너:

8.3 교훈 1: Supply Chain 감사

8.4 XZ Utils 백도어 (2024.03)

충격:

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

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

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

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

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

9.1 시작 체크리스트

9.2 초기 스타 얻기 전략

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

9.3 성공 사례 — Tailwind CSS

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

9.4 성공 사례 — Docusaurus

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

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

10.1 Rust

10.2 Kubernetes

10.3 Node.js

10.4 Python

10.5 대형 프로젝트 기여 팁

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

Chapter 11: 한국 OSS 씬

11.1 한국 발 글로벌 OSS

11.2 한국 OSS의 어려움

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

11.3 글로벌 기여 시작 팁

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

11.4 한국 OSS 커뮤니티

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

Chapter 13: 10가지 OSS 안티패턴

1) "내가 다 해야 해"

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

2) 스타 개수에 집착

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

3) 라이선스 안 붙임

GitHub에 코드 올렸는데 LICENSE 없음. → 법적으론 "저작권 모두 유보" → 아무도 못 씀. 반드시 LICENSE 파일.

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은:

다음 글에서.

원문 보기: https://www.youngju.dev/blog/culture/2026-04-15-open-source-maintainer-path-complete-guide-first-pr-to-ownership-sponsorship-burnout-deep-dive-guide-2025

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다