오픈소스 첫 기여를 시작하는 현실적인 경로 — 코드가 아니어도 된다
good first issue부터 찾는 방식이 잘 안 되는 이유. 이미 쓰는 도구에서 시작하는 방법.
good first issue부터 찾으면 잘 안 되는 이유
오픈소스 기여를 시작할 때 good first issue 라벨을 검색하는 방법이 흔히 권장된다. 그런데 실제로 해보면 잘 안 된다.
- 인기 저장소의 그런 이슈는 몇 시간 안에 선점된다
- 프로젝트 맥락을 모르는 상태라 쉬운 이슈도 시간이 오래 걸린다
- 관심 없는 프로젝트라 동기가 유지되지 않는다
이미 쓰는 도구에서 시작하기
더 현실적인 경로는 이미 사용 중인 라이브러리·도구에서 시작하는 것이다.
이유:
- 맥락을 이미 안다 (무엇을 하는 도구인지)
- 불편을 실제로 겪는다 (기여할 거리가 자연히 생긴다)
- 결과를 자신이 쓴다 (동기가 유지된다)
기여의 단계
코드부터 시작할 필요가 없다. 난이도 순으로:
1단계 — 이슈 재현 확인
누군가 올린 버그 리포트를 자기 환경에서 재현해보고 결과를 댓글로 남긴다. 재현 여부와 환경 정보는 유지보수자에게 실질적으로 유용하다.
```
같은 문제 재현됩니다.
- OS: macOS 15.2
- 버전: 2.4.1
- 재현: (절차)
- 추가로 확인한 것: 3.0 베타에서는 발생하지 않음
```
2단계 — 문서 수정
오타, 오래된 예제, 빠진 설명. 자신이 쓰다가 막혔던 지점이 대개 문서의 빈틈이다. 이 기여는 실제로 다음 사용자에게 도움이 된다.
3단계 — 재현 코드 제공
버그 리포트에 최소 재현 코드를 붙인다. 이것만으로도 수정 속도가 크게 올라간다.
4단계 — 테스트 추가
기존 코드에 빠진 테스트를 추가한다. 기능 변경이 없어 리뷰 부담이 적고, 코드베이스를 읽는 연습이 된다.
5단계 — 코드 수정
PR 전에 확인할 것
프로젝트마다 규칙이 다르다. 확인 항목:
CONTRIBUTING.md— 기여 절차, 커밋 규칙, 브랜치 전략- 기존 PR 몇 개 — 어떤 형식으로 올라오는지
- 이슈 선점 관행 — 먼저 댓글로 알리는 문화인지
- 테스트·린트 통과 여부 — CI가 있다면 로컬에서 먼저
특히 이슈 선점을 안 하고 큰 작업을 시작하면, 다른 사람과 겹치거나 방향이 안 맞아 통째로 버려질 수 있다.
영어에 대해
간단한 문장으로 충분하다. 필요한 것은 유창함이 아니라 정확한 정보다.
```
Steps to reproduce:
- Run
npm start - Click the export button
- Error appears in console
Expected: file downloads
Actual: TypeError: undefined is not a function
Version: 2.4.1 / Node 20.10
```
이 형식이면 문장이 단순해도 소통에 문제가 없다.
거절됐을 때
PR이 병합되지 않는 경우는 흔하다. 이유는 보통 셋 중 하나다.
- 프로젝트 방향과 안 맞음 → 이 경우는 코드 문제가 아니다
- 구현 방식에 대한 의견 차 → 논의하고 수정하거나 유지보수자에게 맡김
- 응답이 없음 → 활동이 뜸한 프로젝트일 수 있다
셋 다 개인 역량과 직접 관련이 없다. 첫 PR이 병합되지 않았다고 그만두는 경우가 많은데, 유지보수자 쪽 사정인 경우가 상당수다.
최종 수정 2026-08-28