(1) 오픈소스 코드 공개 시
어떤 라이선스가 적용되었는지 , 사용했던 코드의 깃허브 링크등을
하나의 폴더에 작성해서 넣어두면 되지 않을까 싶다.
/프로젝트폴더
├── src/ # 소스 코드
├── docs/ # 문서 (API 명세, 가이드 등)
├── LICENSE # 라이선스 파일 (MIT, Apache, GPL 등)
├── NOTICE # 저작권 및 라이선스 관련 추가 정보 (필요한 경우)
├── README.md # 프로젝트 소개 및 사용법
├── THIRD_PARTY_LICENSES/ # 사용한 외부 라이브러리의 라이선스 정리
├── dependencies.md # 사용한 오픈소스 목록 및 링크📌 (1) LICENSE 파일
- 프로젝트의 전체적인 라이선스를 명시하는 파일입니다.
- 예를 들어 MIT 라이선스를 사용할 경우, LICENSE 파일에 해당 내용을 포함하면 됩니다.
- 라이선스 선택이 어려우면 아래 사이트에서 프로젝트 성격에 맞는 라이선스를 고를 수 있습니다.
- https://choosealicense.com/
📌 (2) THIRD_PARTY_LICENSES 또는 dependencies.md
- 사용한 오픈소스 라이브러리와 해당 라이선스를 정리해두는 파일입니다.
- 보통 package.json(Node.js)이나 requirements.txt(Python)처럼 의존성 관리 파일을 보고 필요한 정보를 정리할 수 있습니다. 📌 예제 (dependencies.md)
# 사용한 오픈소스 목록 ## 1. Express.js - 공식 깃허브: https://github.com/expressjs/express - 라이선스: MIT ## 2. Lodash - 공식 깃허브: https://github.com/lodash/lodash - 라이선스: MIT ...
📌 (3) README.md
- 프로젝트 소개, 설치 방법, 실행 방법, 기여 방법 등을 적어놓는 파일입니다.
- 깃허브에 올릴 때 가장 중요한 파일이므로, 잘 정리하는 것이 좋습니다.
💡 결론
- 프로젝트 내 LICENSE 파일은 필수
- 외부 라이브러리 및 코드 출처 정리는 dependencies.md 또는 THIRD_PARTY_LICENSES/ 폴더에 별도 정리
- README.md에도 간단한 라이선스 설명 추가 가능
(2) 깃허브가 말아주는 오픈소스
라이선스 위치 결정에 대해서 깃허브가 알려주는 예제 URL이다.
https://github.com/hubotio/hubot/blob/main/LICENSE.md
위 페이지에서 읽다보면 아래와 같은 내용을 볼 수 있다.
✅ 깃허브에서 Repository를 생성하는 단계 중에서 라이선스를 추가할 수 있는 단계가 있다고한다.
✅ 그래서 레포지토리를 생성하는 페이지로 이동해 봤다.
✅ 당연하게도 Choose a license 를 확인 할 수 있었고
그동안 Add a README file 까지만 봤던거 같은데 ㅋㅋㅋㅋ;;
새로운 지식을 습득하게되었다.
더 자세한 내용은 아래 링크로 확인해서 내 소스코드에 라이선스를 추가해보도록 하자.
(3) 오픈소스 문서 구조
(1) 오픈소스 공개 시 에서 내용에서도 언급했지만
LICENSE.md/.txt는 오픈소스 라이선스 전문 명시해주는 문서로 정하자
즉, 이 프로젝트는 어떤 오픈 소스 라이선스 하에 배포된다.
또한 “오픈 소스 프로젝트 최상위 디렉토리”에 위치될 것
README.md : 해당 오픈소스 코드를 이용하여 작성한
프로젝트 소개, 실행, 기여 방법 등을 적어 놓는 파일일 것이다.
NOTICE.txt : 오픈소스 라이선스 개요 (?)
COPYRIGHT.txt : 저작권 (?)
(4) contribute 문서
Contribute = 기여하다
오픈소스 프로젝트에서 다른 사람들이 코드나 문서를 개선하고 기능을 추가하는 데 참여하는 것을 의미한다.
예를 들어, 내 깃허브에 오픈소스 프로젝트를 올려 놓으면 , 다른 개발자들이 :
- 버그를 수정
- 신 기능 추가
- 코드 리팩토링
- 문서(READ.md)를 개선
- 번역 작업 추가
등의 방식으로 내 프로젝트에 기여할 수 있다는 것이다.
그렇다면 contribute문서는 무엇일까 ?
→ 프로젝트에 어떻게 기여할 수 있는지 설명한 문서
https://docs.github.com/en/get-started/exploring-projects-on-github/contributing-to-a-project
위 URL은 contribute 관련한 깃허브 페이지입니다.
🔹 Contribute하는 방법
오픈소스 프로젝트에 기여하는 기본적인 방법을 알아보자.
✅ 1. 이슈(Issues) 확인하기
- 깃허브(GitHub)에서는 Issues 탭을 통해 프로젝트에서 발생한 문제(버그, 개선사항 등)를 확인할 수 있다.
- 기여하려면 먼저 해결할 수 있는 이슈가 있는지 확인하는 게 좋다.
✅ 2. 프로젝트 Fork 하기
- Fork는 프로젝트의 복사본을 내 깃허브 계정으로 가져오는 기능이다.
- 원본 프로젝트를 수정할 수 없기 때문에 내 계정에서 작업한 후, 원본 프로젝트에 다시 반영해야 된다.
✅ 3. 코드 수정 후 Pull Request(PR) 보내기
- Pull Request(PR)는 내 변경 사항을 원본 저장소(Repository)에 반영해달라고 요청하는 과정이다.
- PR을 보내면 프로젝트 관리자가 리뷰(검토) 후 코드를 병합(Merge)할지 결정해야 한다.
🔹 Contribute를 받는 방법 (오픈소스 운영)
네가 프로젝트를 오픈소스로 공개하고 다른 사람이 기여하도록 만들려면, 다음 내용을 정리하면 좋아.
- README.md
- 프로젝트 설명
- 설치 방법, 실행 방법
- 기여 방법(Contributing)
- CONTRIBUTING.md (선택 사항)
- 기여하는 방법을 자세히 설명
- 코드 스타일 가이드
- PR 작성 규칙
- LICENSE
- 프로젝트의 라이선스 명시 (MIT, Apache, GPL 등)
- Issues & Labels
- 초보자가 기여하기 쉬운 good first issue, help wanted 같은 라벨을 달아주면 좋아.
🔹 정리
- Contribute(기여): 오픈소스 프로젝트에 코드, 문서, 기능 등을 추가하는 것
- 기여하려면 Issues 확인 → Fork → 수정 → PR 보내기 단계를 거침
- 프로젝트 운영자는 README.md, CONTRIBUTING.md 등을 정리해서 기여를 쉽게 만들면 좋음
(5) code of conduct
Code of Conduct(CoC, 행동 강령) 은 오픈소스 프로젝트에서 기여자(Contributors)와 사용자(Users)가 지켜야 할 행동 규칙을 정리한 문서야.
그러니깐, 프로젝트에서 기여할때 어떤 태도와 행동이 허용되는지.. 또 어떤 행동이 금지되는지를 정의한 문서
🔹 왜 Code of Conduct가 필요할까?
✅ 기여 문화 조성
→ 기여자들이 서로 예의를 지키며 생산적인 환경을 만들기 위해 필요해.
✅ 갈등 방지
→ 개발자들 사이에서 논쟁이나 비방이 발생하지 않도록 미리 가이드라인을 정해둠.
✅ 오픈소스 커뮤니티 유지
→ 다양한 배경을 가진 사람들이 참여하는 만큼, 차별 없는 환경을 조성하는 것이 중요함.
🔹 Code of Conduct에 들어가는 내용
Code of Conduct 문서에는 보통 다음과 같은 내용이 포함돼.
📌 1. 목적 (Purpose)
- 프로젝트의 목표와 기여 문화에 대한 설명
- 모든 사람이 안전하고 환영받는 환경을 제공하려는 목적
📌 2. 허용되는 행동 (Expected Behavior)
- 예의 바르고 친절한 언어 사용
- 환영하는 태도와 적극적인 협력
- 차별, 괴롭힘, 혐오 표현 금지
📌 3. 허용되지 않는 행동 (Unacceptable Behavior)
- 공격적인 언행, 모욕, 비방
- 성차별, 인종차별 등 차별적인 행동
- 개인 정보 유출, 스팸 행위
📌 4. 문제 발생 시 대응 방법 (Enforcement)
- 문제가 발생하면 누구에게 신고해야 하는지
- 행동 강령을 위반한 경우 어떤 조치를 취할 것인지 (경고, 제재 등)
(6) 커뮤니티 건정성 체크리스트
이 페이지는 GitHub의 “Community Standards” (커뮤니티 표준) 체크리스트를 보여주는 화면이다.
GitHub는 오픈소스 프로젝트를 투명하고 협력적인 환경을 운영할 수 있도록 몇 가지 기본적인 문서를 제공한다.
위 페이지에서는 현재 프로젝트가 깃허브의 권장 커뮤니티 표준을 얼마나 잘 따르고 있는지를 확인할 수 있는데
📌 주요 항목 설명
✅ (초록 체크) : 완료됨
🟡 (노란색 점) : 아직 추가되지 않음
✔ 현재 완료된 항목
- Description: 프로젝트 설명이 작성됨
- README: 프로젝트 설명 및 사용법이 포함된 README.md 파일이 있음
- License: 오픈소스 라이선스가 지정됨
⚠️ 아직 추가해야 할 항목
- Code of Conduct (행동 강령) → 프로젝트 참여자의 행동 규칙을 정한 CODE_OF_CONDUCT.md가 없음
- Contributing (기여 가이드라인) → 프로젝트에 기여하는 방법을 정리한 CONTRIBUTING.md가 없음
- Security Policy (보안 정책) → 보안 취약점을 보고하는 방법에 대한 SECURITY.md가 없음
- Issue templates (이슈 템플릿) → 이슈 작성 시 기본 형식을 제공하는 템플릿이 없음
- Pull request template (PR 템플릿) → PR 생성 시 기본 형식을 제공하는 템플릿이 없음
- Repository admins accept content reports → 콘텐츠 신고 관련 설정이 되어 있지 않음
그래서 위 페이지의 역할은 ???
🔹 이 페이지의 역할
-
프로젝트가 깃허브의 권장 커뮤니티 표준을 따르고 있는지 확인
-
빠진 문서들을 추가하여 더 개방적인 프로젝트 운영 가능
-
기여자들에게 더 명확한 가이드 제공하여 기여 활성화
즉 , GitHub가 추천하는 프로젝트 관리 표준을 얼마나 잘 따르고 있는지 보여주는 페이지임
(7) 깃허브 이슈
GitHub의 Issue(이슈)는 프로젝트에서 발생한 버그, 기능 추가 요청, 문서 수정 요청, 일반적인 논의 등을 기록하고 관리하는 시스템이다.
쉽게 말하면 “할 일 목록(To-Do List) + 토론 게시판” 같은 개념이라고 생각된다.
(8) Pull Request
Pull Request 는 저장소(repository)의 코드에 변경 사항을 제안하고
이를 병합(merge)해달라고 요청하는 기능이다.
🔹 Pull Request를 쓰는 이유
- 협업을 쉽게 할 수 있음
→ 여러 개발자가 동시에 작업할 때, 서로의 변경 사항을 병합할 수 있도록 도와줌.
- 코드 리뷰 가능
→ 다른 개발자들이 코드 변경을 확인하고 피드백을 줄 수 있음.
- 버그 예방
→ 변경 사항을 미리 테스트하고 검토할 수 있어서, 직접 코드에 반영하기 전에 문제를 잡을 수 있음.
🔹 Pull Request 진행 과정
✅ 1. 브랜치 생성 (Fork & Branch)
- 변경 사항을 원본 코드에 직접 수정하는 것이 아님 X
- 새로운 브랜치에서 작업한 후 PR을 보냄
- 프로젝트의 포크(Fork)를 만든 후, 로컬에서 새로운 브랜치를 생성해서 수정함
- 포크(Fork)란 ? 다른 사람의 깃허브 저장소(repository)를 내 계정으로 복사(clone)하는 기능
✅ 2. 변경 사항 커밋 후 Push
- 코드를 수정한 후, 변경 사항을 커밋하고 원격 저장소에 올림
✅ 3. Pull Request 생성
- GitHub에 프로젝트 저장소 이동
- Pull request 탭 클릭
- New pull request 버튼 클릭
- 비교할 브랜치 선택
- PR제목과 설명 작성 후, Create Pull Request 버튼 클릭
✅ 4. 코드 리뷰 및 피드백
- 다른 팀원들이 PR을 확인하고 리뷰를 남길 수 있음
- 코드 수정이 필요하면 피드백 반영하여 재Push
✅ 5. PR 병합(Merge)
- 모든 리뷰가 끝나고 승인이 되면, Merge pull request 버튼을 눌러 변경 사항을 메인 브랜치에 병합.
🚀 결론
- Pull Request(PR) 는 코드를 변경하고 이를 반영해달라고 요청하는 기능
- 브랜치 생성 → 코드 수정 → PR 생성 → 코드 리뷰 → 병합(Merge) 과정으로 진행
- 팀원과 협업할 때 필수적인 기능이며, 코드 리뷰를 통해 품질을 높일 수 있음
- PR 템플릿을 사용하면 깔끔하게 정리 가능
👉 즉, PR은 오픈소스 협업과 팀 프로젝트에서 필수적인 코드 병합 요청 방식! 🚀
(9) 깃허브 Discussions
GitHub Discussions는 깃허브에서 제공하는 프로젝트 내 커뮤니티 게시판 같은 기능이다.
각 저장소(레퍼지토리)마다 Discussion 기능이 배치되어 있다.
기존의 Issues(이슈)는 버그나 기능 요청을 정리하는 공간인데, Discussions는 더 자유로운 토론, 질문, 아이디어 공유, 공지 등을 위한 공간이다.
✅ Discussions는 이런 경우에 사용해!
- 질문 & 답변 (Q&A) → “이 기능 어떻게 사용하나요?”
- 아이디어 공유 → “이 기능 추가하면 좋을 것 같은데?”
- 일반 토론 → “이 프로젝트 방향성을 논의해보자”
- 공지 사항 → “다음 릴리즈 일정은 언제?”
