지난 시간에 이어 오픈 소스에 대해 살펴보고, 깃허브(GitHub)에서 제공하는 관련 기능들을 정리했습니다.
1. 깃허브 오픈 소스 가이드
깃허브에서 직접 제공하는 오픈 소스 가이드 웹사이트가 있습니다. 오픈 소스와 관련된 법적 측면이나, 깃허브에서 오픈 소스 프로젝트 운영을 위해 어떤 기능들을 제공하고 있는지 등 다양한 정보를 확인할 수 있습니다.
오픈 소스를 처음 접하거나 직접 프로젝트를 운영해보고 싶다면 이 가이드를 먼저 읽어보는 것을 추천합니다.
2. 오픈 소스 문서 구조
오픈 소스 프로젝트를 구성할 때 기본적으로 포함되어야 하는 문서들이 있습니다.
| 파일명 | 역할 |
|---|---|
LICENSE.md | 오픈 소스 라이선스 전문을 명시하는 기본 문서. 최상위 디렉토리에 위치합니다 |
README.md | 프로젝트의 목적 및 사용 방법을 설명하는 문서입니다 |
COPYRIGHT.txt | 저작권 정보가 명시되어 있는 문서입니다 |
NOTICE.txt | 오픈 소스 라이선스의 개요를 나타내는 문서입니다 |
CONTRIBUTING.md | 외부 개발자가 프로젝트에 기여할 수 있는 방법을 설명한 문서입니다 |
CODE_OF_CONDUCT.md | 프로젝트 참여자들이 지켜야 할 행동 지침을 명시한 문서입니다 |
이 파일들이 잘 갖춰진 프로젝트일수록 외부 기여자들이 참여하기 쉽고 신뢰도도 높아집니다.
3. 커뮤니티 체크리스트
깃허브는 건전한 커뮤니티 환경을 만드는 것을 추구하기 때문에 이를 돕기 위한 체크리스트를 제공합니다. 레포지토리의 Insights 탭 내에 있는 Community Standards 메뉴를 통해 해당 프로젝트가 오픈 소스 권장 기준을 얼마나 충족하고 있는지 확인할 수 있습니다.
위에서 언급한 README, CONTRIBUTING, CODE_OF_CONDUCT, 이슈 템플릿, PR 템플릿 등의 항목이 체크리스트에 포함되어 있습니다.
4. 깃허브 이슈 (Issue)
깃허브에서 이슈(Issue) 는 프로젝트 내에서 발생하는 모든 활동을 의미합니다. 기획, 작업 할당, 기능 추가, 버그 제보, 개선 사항, 질문 등 다양한 종류의 주제를 다룹니다.
이슈의 상태는 크게 두 가지로 분류합니다.
- Open — 진행 중이거나 계획 단계에 있는 열려있는 이슈입니다.
- Close — 해결되었거나 중단되어 닫혀있는 이슈입니다.
이슈는 다양한 사람들에 의해 생성되기 때문에 작성 형식을 통일하는 것이 중요합니다. 이를 위해 커뮤니티 체크리스트에도 Issue Templates(이슈 템플릿) 설정 항목이 존재합니다. 템플릿을 미리 만들어두면 버그 리포트, 기능 요청 등 유형별로 일관된 형식의 이슈를 작성할 수 있습니다.
5. 풀 리퀘스트 (Pull Request)
특정 브랜치에서 작업한 내용을 다른 브랜치로 병합해 달라고 요청하는 것을 풀 리퀘스트(PR) 라고 합니다. 주로 기여자가 원본 프로젝트를 포크(fork) 해서 새로운 기능을 만들거나 문제를 수정한 뒤, 프로젝트 관리자에게 자신의 코드를 반영해 달라고 요청할 때 사용합니다.
이슈와 마찬가지로 PR도 형식을 통일하기 위해 Pull Request Templates 를 만들어 활용할 수 있습니다. 또한 제출된 PR이나 커밋된 코드에는 특정 라인마다 의견을 남길 수 있는 코드 리뷰 기능이 제공되어 협업 시 유용하게 쓰입니다.
# 일반적인 오픈 소스 기여 흐름
1. 원본 레포지토리 Fork
2. 로컬에 Clone
3. 새 브랜치 생성 후 작업
4. 변경 사항 Commit & Push
5. 원본 레포지토리에 Pull Request 제출
6. 코드 리뷰 및 피드백 반영
7. Merge6. 깃허브 토론 (Discussions)
오픈 소스 프로젝트에서는 코드뿐만 아니라 다양한 질문이나 정보를 나눌 수 있는 전용 공간이 필요합니다. Discussions 탭은 마치 스택오버플로우처럼 사용자들끼리 자유롭게 질문을 올리고 답변을 공유하거나, 관리자가 프로젝트 공지사항을 전파하는 공간으로 활용됩니다.
각 참여자 이름 옆에 Maintainer, Collaborator 등 역할이 표시되어 책임 소재와 권한을 명확히 식별할 수 있다는 특징이 있습니다.
