
지난 시간에는 깃허브에서 오픈 소스를 다루는 방식에 대해 알아보았습니다. 이번 시간에는 오픈 소스 생태계의 구성원과 프로젝트에 기여하는 컨트리뷰션(Contribution) 의 전반적인 내용을 정리했습니다.
오픈 소스 프로젝트를 이끌고 참여하는 사람들은 역할에 따라 크게 다섯 가지로 구분할 수 있습니다.
| 역할 | 설명 |
|---|---|
| 저작자 | 프로젝트를 처음 만들고 코드를 공개한 사람입니다 |
| 메인테이너 | 프로젝트의 방향성을 잡고 유지·관리하는 컨트리뷰터입니다. 규모에 따라 없을 수도 있습니다 |
| 커미터 | 제출된 코드나 PR을 리뷰하고 프로젝트에 반영할지 결정하는 권한을 가진 컨트리뷰터입니다 |
| 컨트리뷰터 | 프로젝트에 어떤 방식으로든 기여 활동을 하는 모든 사람입니다 |
| 사용자 | 해당 오픈 소스를 사용하는 사람들입니다 |
컨트리뷰터들이 오픈 소스에 기여하는 방식은 매우 다양합니다. 단순히 코드를 작성하는 것 외에도 많은 활동이 포함됩니다.
코드를 직접 수정하지 않고 이슈를 통해 개선 사항을 제안하는 것만으로도 훌륭한 기여 활동으로 인정받을 수 있습니다. 리액트 같은 대형 프로젝트들도 공식 문서를 통해 어떻게 기여할 수 있는지 상세한 가이드를 제공하고 있습니다.
오픈 소스 기여는 프로젝트 저작자와 참여자 모두에게 긍정적인 영향을 줍니다.
저작자 입장에서는 수많은 컨트리뷰터들이 버그를 대신 찾아주고, 다양한 환경과 관점에서 개선 사항을 제안해 주기 때문에 프로젝트의 품질을 크게 높일 수 있습니다.
사용자 및 참여자 입장에서는 다음과 같은 혜택이 있습니다.
오픈 소스 프로젝트에 기여하기 전에 반드시 확인해야 할 주의 사항이 있습니다.
커뮤니케이션 — 다양한 문화와 배경을 가진 사람들이 텍스트로 소통하는 공간이므로 상호 존중하는 태도가 필요합니다.
소스 코드 충돌 방지 — 내가 작업하려는 내용이 이미 다른 사람에 의해 진행 중인지, 혹은 프로젝트 방향성과 맞지 않아 반려되었던 건인지 이슈나 디스커션을 통해 미리 확인해야 합니다.
사전 질문 — 기능을 본격적으로 개발하기 전에, 해당 기능이 프로젝트에 정말 필요한지 메인테이너에게 먼저 물어보고 방향성을 맞추는 것이 좋습니다.
템플릿 확인 — 해당 프로젝트에서 요구하는 이슈나 PR 템플릿이 있다면 규격에 맞게 작성해야 합니다.
일반적으로 깃허브를 통한 컨트리뷰션은 다음과 같은 순서로 진행됩니다.
1. Fork — 원본 레포지토리를 내 개인 계정으로 복제합니다
2. Clone — 복제된 내 레포지토리를 로컬 컴퓨터로 다운로드합니다
3. 커밋 규칙 확인 — 해당 프로젝트의 커밋 컨벤션·코드 스타일 가이드를 확인합니다
4. 구현 — 규칙에 맞게 실제 코드나 문서를 수정합니다
5. Push & PR — 작업 내용을 내 레포지토리로 Push 후 원본에 PR을 생성합니다
6. CLA — 기여 코드에 대한 권리·라이선스 동의 절차를 진행합니다
7. Review — 메인테이너·커미터에게 코드 리뷰를 받고 필요 시 수정합니다
8. Merge — 최종적으로 원본 프로젝트에 병합되고 컨트리뷰터 리스트에 등록됩니다
특히 6번 CLA(Contributor License Agreement) 는 처음 기여할 때 생소하게 느껴질 수 있는 단계입니다. 내가 기여한 코드의 권리를 프로젝트에 양도하거나 라이선스 사용을 허락한다는 동의 절차로, 대부분의 대형 오픈 소스 프로젝트에서 요구합니다.