[02.17] 오픈소스2

웹 개발 공부하기

[02.17] 오픈소스2

jooya-1009 2025. 2. 20. 22:08

💥 오픈소스 코드 공개 시(feat. 깃허브 가이드)

[ 오픈소스 가이드 사이트 ]
https://opensource.guide/

위에 적어놓은 오픈소스 가이드 사이트를 들어가보면 이렇게 궁금한 부분들이 다 적혀있다.

가장 궁금해할 부분인 "깃허브에 있는 프로젝트는 모두 오픈 소스인가?" 에 대한 답도 적혀있다.

"깃허브 프로젝트를 공개하는 것은 프로젝트에 라이센스를 부여하는 것관 다르다" 라는 답이 적혀있다.

외부인이 프로젝트를 보고 fork 를 할 순 있지만 그 외의 작업에 대한 권한은 없다는 것이다.

즉, 다른 사람이 내 프로젝트를 사용, 배포, 수정, 기여를 하도록 하고싶으면 오픈 소스 라이선스를 포함해야만 한다는 것이다.

그리고 마지막의 글을 보면 "공개된 코드일 지라도 귀하가 명시적으로 권한을 부여하지 않는 한 사용할 수 없다." 라고 적혀있다.

그러니 깃허브에 있는 프로젝트들이 다 public 되어있다고 코드를 가져와서 무단으로 사용하고 그러면 안 된다는 뜻이다🤐

💥 깃허브가 말아주는 오픈소스

오픈 소스 가이드 사이트를 보다보면 "GitHub에서 새로운 프로젝트를 생성하면 라이선스를 추가하라는 메시지가 표시됩니다." 라는 글이 있다.

엥? 내가 프로젝트 생성할 때마다 그런 게 없었던 것 같은데? 하는 생각이 들었다.

그래서 확인을해보니 보통 새 Repository 를 만들 때 Choose a license 라는 것이 뜬다는 것이다.

?? 진짜? 그럼 내가 여태 못 보고 지나갔다고? 에이 거짓말 하고 깃허브를 들어가서 Repository 를 만들어보았다.

ㅇㅇ.. 있었다... 지금껏 라이센스가 딱히 필요없었어서 신경을 안 썼던 것이다😲

이제는 알았으니까 license 를 넣어야한다면 꼭 추가를 해야겠다..

유명한 license 인 MIT, Apache 등등 있는 걸 볼 수 있다! 새로운 지식 굿🤗

💥 오픈소스 문서 구조

1) LICENSE.md/.txt

: 오픈소스 라이선스 전문에 대한 명시하는 문서

: 이 파일이 프로젝트에 있으면 이 프로젝트는 이 오픈 소스 라이선스 하에 배포된다(되어야 한다.).

: 오픈소스 프로젝트의 최상위 디렉토리에 존재해야함

2) README.md

: 프로젝트 코드의 목적, 사용 방법을 설명해주는 문서

3) NOTICE.txt(부가적인 문서)

: 오픈소스 개요 처럼 '이거 어떤 라이선스 사용한 오픈소스야!' 를 알려주는 느낌의 문서

4) COPYRIGHT.txt (부가적인 문서)

💥 추가 문서

1) CONTRIBUTING.md: 기여하는 것

: 프로젝트에 어떻게 기여할 수 있는 지에 대해 설명한 문서

: 해당 프로젝트에 기여하는 절차를 안내 => 모든 컨트리뷰션을 환영함!

1) 코드 수정 가능
2) 개선사항 가능
3) 오타 수정 가능
4) 기능 추가구현 가능

2) code of conduct(CoC): 코드 사용 규정

: 오픈소스 프로젝트(커뮤니티)에 참여하는 방법에 대한 표준

: 이 오픈소스를 사용할 때 이런 것들은 좀 지켜줬으면 좋겠어 🙏 라는 듯한 내용이 포함되어있다.

: 모든 기여 존중, 서로 존중, 호의적, 포용적인 환경, ... 으로 개발을 해 나가자!

: 커뮤니티 멤버 간에 이슈가 발생하면 문제 해결을 어떻게 할 지에 대한 내용도 있다! 완전 인간적인 내용들임👏

💥 커뮤니티 건전성 체크리스트

: 깃허브는 커뮤니티에 대한 행동 기준을 굉장히 중요하다고 생각하고 공정한 방식으로 즐겁게 생산하는 환경을 추구한다고 한다.

: 커뮤니티를 빌딩한다 = 오픈소스 프로젝트를 생성한다.

: 깃허브는 실제로 이 커뮤니티 상태 파일들이 잘 업로드 되어있는 지 체크리스트도 제공하고 있다.

이렇게 깃허브 자체에서도 Checklist 를 제공하고 있다.

README 파일은 있으니 초록색 체크로 표시하고 있고, 나머지는 없기 때문에 노란색? 갈색?으로 표시되고 있다.

말 그대로 저걸 업로드 하면 Checklist 가 올라가고 체크 표시가 된다.

오픈소스를 배포/사용 하면서 뭔가 덜 올린 거 같은데? 라고 생각된다면 Checklist 를 살펴보는 것도 좋을 것 같다!

💥 깃허브 이슈

: 프로젝트에서 발생할 수 있는 모든 활동에 대한 이슈를 나타낸다.

: 기획, 작업, 추가, 버그, 개선 등.. 프로젝트 내에서 작업을 하며 나타내는 모든 활동이 포함 되어 있다.

실제로 1차 팀 프로젝트를 하면서 이 이슈를 사용해본 적이 있다.

멘토님께서 추천하신 건, 본인의 역할 등을 작게 쪼개서 이슈를 먼저 등록을 해라.

그리고 그 이슈에 적힌 #21 등 넘버와 일치하게 Commit 을 해라. 그리고 마지막으로 끝난다면 Close 를 꼭 해줘라. 였다.

그래서 실제로 작업했던 깃허브 이슈들을 찍어와봤다.

Front Back 으로만 나눴었고 나는 Front 의 상세페이지 밑에 비딩로그 만들기 라는 이슈를 만들었었다.

물론 더 많은 이슈들이 있었지만 다른 멘티들의 아이디가 너무 적나라하게 나오길래 작게 캡쳐했다 ㅎ...

그럼 해당 이슈를 클릭하면?

이렇게 내가 등록한 이슈가 뜨고, 상세 내용을 적을 수도 있고, 누가 언제 이 이슈를 completed 를 했는 지 알 수 있다.

이렇게 하기 위해선 Commit 할 때 해당 이슈에 적힌 넘버를 꼭 포함해야한다.

멘티 중에서 커밋로그에 대한 파일을 공유해준 적이 있었는데 [FEAT] 으로 커밋을 할 때

어떤 내용에 대한 FEAT 인 지 같이 적고 마지막에 Close #22 를 같이 적어두면 해당 이슈가 Open 되어있다가 Close 된다고 했었다.

그래서 실제로 사용해봤을 때 굉장히 직관적이고 굳이 깃허브 들어가서 다 했으니까 close 누르자! 할 필요도 없었기 때문에 굉장히 편하다고 느꼈던 부분이었다.

멘토님의 의견 중에선 이슈를 작게작게 쪼개야 내가 오늘 어디까지 작업할 건지, 혹시 빠진 건 없는 지, 그리고 내일 어떤 걸 할 지 미리 정할 수도 있고, 다른 작업자들도 해당 유저가 어떤 일을 하고 있는 지 파악하기 좋기 때문에 꼭 이슈 등록을 버릇 들여놓으라고 하셨다. 그래서 이번 프로젝트도 이 이슈 등록하는 걸 같은 팀원들한테 공유해볼까 싶기도 하다!

💥 Pull Request

: Branch 가 Branch 에게 요청하는 것

: Pull -> 당기다 / Request -> 요청

사실 이 PR 을 1차 멘토님께서 엄청 강조하셨고 꼭 써보라고 하셨던 부분 중에 하나였다.

팀플 혹은 팀과제를 할 때 가장 중요하다고 말씀하셨는데 1차 땐, 정신이 없어서 Branch 를 나누지 않고 작업했었다.

3명이서 main Branch 하나로 작업을 하다보니 pull 땡기거나 push 할 때 한 번씩 충돌이 일어난 적이 많았다.

그래서 매번 다시 다운 받고 코드 수정, 추가하고 다시 업로드 하고.. 다시 다운받고 그랬던 기억이 난다.

초반이어서 다들 branch 에 집중을 못 했던 때라, 그냥 어쩔 수 없지 뭐ㅠ 하고 그냥 주르륵 지나갔던 것 같다.

그 때 멘토님께서 작업을 할 때 충돌이 일어날 수 있기 때문에 PR 은 중요하다.

꼭 PR 을 써라. 1인 1 Branch 까진 아니더라도, main branch 에서 다수의 사람이 작업을 하는 건 옳지 않다. 라고 하셨다.

그래서 그 때부터 약간 branch 에 대해 많은 생각을 했던 것 같다.

개발을 하면서 느끼는 건데 정말 일단 부딪혀봐야 뭐가 잘못됐고 어느 부분이 힘들고 어렵고를 느끼는 것 같다 ㅠ

1차 프로젝트를 하면서 깃허브 충돌이 너무 잦았어서 깃허브 branch 나누는 것, pull push commit 로그 의 중요성을 깨달았다.

그래서 다신 이 어려움을 반복하지 않으리라^^.. 마음을 먹게 된 사건이었던 것 같기도 하다.

실제로 이 PR 을 통해서 코드리뷰가 이루어진다. Pull Request 를 보내면 Merge 전에, 코드리뷰를 할 수 있다.

이 때, 수정 및 추가된 코드를 보면서 다른 개발자들이 코멘트를 남길 수 있는 공간도 있다.

이번 프로젝트를 시작 하기 전, 멘토님께서 꼭 꼭 신신당부 하신 부분이 있었다.

모든 작업은 PR 을 올릴 것! PR에 모두 본인을 리뷰어로 지정해줄 것!

이게 왜 중요할까? 라고 생각을 했었다. 지금 생각해보니 PR 을 매번 올려야 해당 PR 을 확인 후, 코드리뷰를 해줄 수 있는 것이었다 ㅎ...

물론 PR 만으로 코드리뷰를 할 수 있는 건 아니다. 머지 후에 해도 되긴 하지만, 실컷 머지 해놓고 코드 수정하고 다시 PR 하고.. 굉장히 번거로울 것 같다.

이 코드리뷰의 중요성을 이번 프로젝트에서 아마 느낄 수 있을 것 같은 느낌이 든다.. 내 코드... 진짜 쓰레기일텐데..🙄

하여튼 이번 프로젝트를 하면서 놓쳤던 branch 부분, PR 부분 꼭 확인하면서 잘 해봐야할 것 같다!