Image generated by Gemini, edited in Figma

---

오픈소스 기여라는 게, 한 번만 해보면 쉬워진다더라

그래서 하고 왔다.

개발자라면 한 번쯤 해볼 만하지 않은가? 일주일이면 익숙해질 수 있다.

일주일 만 투자하고, 이력서 한 줄을 추가하자

PR보러가기 - https://github.com/clauderic/dnd-kit/pull/2020

이 글에서 소개할 내용은 3가지이다.

1. 가장 빠른 기여 방법
2. 최소한의 사전 지식
3. 기여할 오픈소스 고르기

이번 글에서는 오픈소스를 고르는 방법까지만 소개한다.

적절한 오픈소스만 잘 고르면 절반은 성공이다.

나머지 내용 (문제 상황 재현하기 + 수정하고 PR하기 + merge기다리기)은 다음 글에서 소개할지도?

시작하쟙!

가장 빠른 기여 방법

1. 이미 해본 친구를 찾아가서 배우자
2. 똑똑이들의 도움을 받자
   1. 오픈소스 컨트리뷰션 아카데미 (마감)
   2. 오픈소스 기여 모임 10기 (마감)
3. 다 필요없고 직접 몸통박치기

이제부터 몸통박치기 실력을 보여주겠다!

!!!

최소한의 사전 지식

우리는 깃허브에서 기여할 예정이다. (깃허브가 아니어도 된다)

React를 보자. - https://github.com/facebook

facebook(=Meta)이 운영하는 organization 에는

react를 비롯해, react-native, docusaurus… 여러 종류의 레포지토리가 있다.

전부 별개의 패키지이자, 별개의 레포지토리이다.

오픈소스 기여는 레포지토리 단위로 가능하다.

패키지와 레포지토리를 구분하자.

facebook/react 레포지토리에 방문해서 소스코드를 확인해 보면, packages 폴더가 있다.

내부에는 모노레포구조로 react, react-dom, react-devtools 등등 여러 종류의 패키지가 존재한다.

때문에,

“나는 react-dom 을 공부해서 react-dom에 기여할거야!” = facebook/react 레포지토리에서 하면됨.

“나는 react-devtools에 기여할거야!” = facebook/react 레포지토리에서 하면됨.

“나는 react 기여할거야!” = facebook/react 레포지토리에서 하면됨.

그래서 우리는, 기여할 오픈소스(레포지토리)를 골라야 한다.

기여할 오픈소스 고르기

기여하는 단계를 확인해보자. (이 글에서는 3단계까지 소개한다)

1. 나의 패키지 분류하기
2. 오픈소스 체크리스트 (오픈소스 고르기)
3. 이슈 고르기
4. 문제 상황을 나의 로컬에서 재현하기
5. 원인 찾아서 수정하기
6. CONTRIBUTING에 따라 commit + PR하기
7. 관리자의 merge 기다리기
8. 관리자의 댓글 보고 대응하기

Level 1. 내가 사용해 본 패키지 분류하기

우선 내가 했던 프로젝트 속 package.json 취합해서 사용한 패키지들을 모으자

• JS개발자 아니라면, Pipfile, pom.xml, build.gradle 뭐 그런거 아무튼 의존성파일 확인해봐라

취합한 패키지들을 레포지토리 단위로 구분해서 정리하자

// claude code prompt
// 폴더 속 package.json파일들에 포함된 모든 패키지를 GitHub 레포지토리 기준으로 묶어서 package정리.md 로 정리해줘.

정리 결과 예시

• facebook/react
  • react
  • react-dom
  • @types/react
• facebook/react-native
  • react-native
• expo/expo
  • expo
  • expo-blur
  • expo-constants

• 저 상태라면? 우리는 react, react-native, expo 레포지토리 깃허브를 확인하면 된다.
• 오픈소스의 규모가 크고 작음에 각각 장단점이 있으니, 관심있는 것 부터 확인하자.

Level 2. 오픈소스 체크리스트

각각의 레포지토리의 깃허브 링크에 방문하여, 기여할만한 오픈소스를 고르자

체크리스트 요약

1. 언어: 내가 사용하는 언어의 소스코드인지 확인하기
2. 업데이트: 최근까지 업데이트 중인지 확인하기
3. 기여 규칙: 규칙 문서인 CONTRIBUTING.md가 있으면 좋고 없으면 말고
4. PR: 나의 PR이 merge되어야 성공이다.
5. 이슈: 우리는 이슈 중 하나를 골라서 기여할 것이다.

Level 2-1. 언어: 내가 사용하는 언어의 소스코드인지 확인하기

⭐레포지토리 오른쪽 아래에서 확인 가능.

Level 2-2. 업데이트: 최근까지 업데이트 중인지 확인하기

⭐마지막 commit 이 최근이며, 이슈와 PR이 존재하긴 해야 함.

• 업데이트가 종료된 패키지도 있다.
• 이슈와 PR을 허용하지 않는 경우도 있다.
• 이런 오픈소스에는 기여할 수 없다.

Level 2-3. 기여 규칙: 규칙 문서인 CONTRIBUTING.md가 있으면 좋고 없으면 말고

⭐CONTRIBUTING.md 를 제공하거나, CONTRIBUTING 링크를 제공한다. (필수x)

• 해당 오픈소스에 기여를 원하는 기여자들을 위해 제공하는 기여 가이드라인이다.
• README에서 링크로 제공하는 경우도 있다.
• CODE_OF_CONDUCT.md 파일도 있다면 참고하자.
• 없다면? 다른 오픈소스의 CONTRIBUTING과, 해당 오픈소스의 merge된 PR들의 방식을 비교해본 뒤, 적당히 컨벤션 맞춰서 하자.

Level 2-4. PR: 나의 PR이 merge되어야 성공이다.

open된 PR과 closed된 PR 모두를 확인해야 한다. PR의 개수가 중요한 게 아니다. detail을 확인하자

open PR

1. PR 작성된 시점
   • 최신(1주일이내) PR이 한 페이지를 다 채움 = 인기 많구나하면 됨
   • ⭐최신 PR 5개쯤 + 그외 PR은 전부 한 달, 두 달 넘는것들
     • 이게 best 상태다. 관리자가 최신 PR을 빠르게 쳐내는 중이라서 최신 PR이 5개만 남은 상태
2. 라벨: PR별 해시태그
   • 관리자가 달아주니깐 신경 쓸 필요 없다. 처음 본 라벨들만 대충 확인해보면 된다.
   • 라벨에 마우스 올려두면, 어떤 라벨인지, 설명 나온다.
   • 레포지토리별로 사용하는 라벨들이 다르다. (주인장 맘인가보다)
   • 예를 들어 Meta의 경우 PR 하려면 동의 체크를 해야 한다. 동의하면, CLA Signed 라벨을 달아준다.
   • “이슈”에도 라벨이 있으며, 이슈의 라벨이 훨씬 중요하다.
3. link된 이슈: README에 이슈번호 적어두면, 깃헙이 자동 인식해서 이슈와 link됨을 알려준다.
   • 모든 수정작업 다 끝나고 PR작성할 때, AI로 작성한다면, 알아서 잘 작성해준다.
4. 댓글:
   • 댓글 많다 = ⭐관리자가 소통하는 구나!
   • 1개, 0개 = CI/CD 자동 봇 댓글

closed PR

1. ⭐⭐한 달 내의 외부인 merge 기록이 존재한다.
   1. Owner, Collaborator, Member 는 관리자라서 볼 필요 없다.
   2. ⭐배지가 없거나, Contributor 붙어있는 사람들이 외부인이다. 즉, 우리 같은 사람들
   3. merge 된 건지 확인. 언제 된 건지 확인.
2. 실패한 PR이 왜 이렇게 많아요???
   1. 잘 보면, 애초에 CONTRIBUTING 지키지 않았거나, 한 놈이 PR을 갈겨놓은 상태일 가능성이 있다.
   2. 혹은, CI/CD 테스트 실패가 원인이거나… 아무튼 작성자 문제다.
3. ⭐ 정상적 PR이 실패한 경우를 찾자
   1. CONTRIBUTING을 지킨 PR이 실패했다면, 댓글을 확인하자.
   2. ⭐관리자가 실패한 원인을 친절히 설명해 준다면 very good
   3. 설명 없이 PR만 닫아버리는 오픈소스들이 있다. 이 경우, 나의 PR이 실패하더라도, 원인을 찾을 수 없다.
4. 더하자면, PR이 작성된 시점과 merge된 시점을 비교해서, 나의 PR이 merge 되기까지 얼마나 걸릴지 예상해 볼 수 있다.

Level 2-5. issues: 우리는 이슈 중 하나를 골라서 기여할 것이다.

⭐open 이슈에 최신 이슈가 충분히 있어야 한다.

• 이슈란, 레포지토리에 버그, 기능 요청, 질문 등을 남기는 게시글이다.
• 이슈 중, 버그를 찾았다는 이슈를 우리가 고치면 된다.
• 내가 직접 버그를 찾았다면? 이슈부터 작성한 뒤, 고치면 된다.

클로드나 GPT에게 오픈소스 기여하는 방법 물어보면,
이슈 중 하나 고른 뒤, “제가 할게요!” 라는 식의 댓글을 남겨야만 한다고 알려줄거다.
근데, 나는 “제가 할게요!” 댓글을 본 적 없다.
그냥 빠르게 PR 갈기면 된다.

1. ⭐라벨를 확인할건데, 오픈소스마다 사용하는 라벨의 이름이 조금씩 다르다.
   1. ⭐triage 라벨: 관리자가 아직 확인 안 한 이슈라서 PR해도 승인될지 안될지 미지수
      • 관리자가 바빠서 그런지, 모든 이슈에 triage 가 달려있는 경우도 있다.
   2. feature request 라벨: 기능 추가 제안 이슈 = 새로운 기능 개발이 가능하다면 시도해봐라
   3. ⭐bug 라벨 (우리가 고를 이슈) : 제시한 이슈 내용 잘 읽고 bug 고치면 된다.
   4. docs 라벨: 문서만 수정하면 된다. 가장 쉽다. 쉬우니까 하지 말자.
   5. good first issue 라벨: 클로드나 GPT가 이 라벨 찾으라는데, 나는 본 적 없다.
   6. 그 외 라벨들은 오픈소스별로 확인하자.
2. ⭐link된 PR이 있다면, 늦은거다. 이미 다른 분이 PR을 올려둔 거니까 시도하지 말자
3. 여러 레포지토리의 여러 이슈를 비교해보자.

Level 3. 이슈 고르기

이슈에 실제 작성된 내용을 확인하자.

1. 내용 중 재현 코드가 있다면? very very good
   • (CodeSandbox, StackBlitz 링크 등)
   • 우리는 오픈소스를 나의 로컬 환경에 clone 해온 뒤, 수정해야한다.
   • 때문에, 문제상황을 나의 로컬 환경에 그대로 재현해야한다.
   • 재현 코드를 제공하는 이슈는 아주 좋다.
   • 없다면? 직접 이슈의 설명을 읽고 재현해야 한다.
2. 댓글 확인
   • 관리자 댓글 있으면 자세히 확인
   • 이 이슈를 해결하려는 사람이 있다면, 아쉽지만, 다른 이슈를 고르자
3. AI를 활용해라
   • AI에게 패키지명, 이슈제목, 이슈내용, 댓글을 보여주고 재현 가능성을 물어보자.
4. link된 PR이 있다면, 늦은거다. 이미 다른 분이 PR을 올려둔 거니까 시도하지 말자
5. 여러 레포지토리의 여러 이슈를 비교해보자.

내용 요약

1. 내가 사용해 본 패키지 분류하기
   1. package.json 취합해서 사용한 패키지들 모으기
   2. 레포지토리 단위로 구분하기
2. 체크리스트
   1. 내가 사용하는 언어의 소스코드 필수
   2. 마지막 commit 이 최근이며, 이슈와 PR이 존재함 필수
   3. CONTRIBUTING.md 있으면 good
   4. openPR: 최신 PR 5개쯤 + 그 외 PR은 전부 한 달 넘는 상태면 best
   5. openPR: 댓글이 2개 이상인 PR이 꽤 있으면 good
   6. closedPR: 한 달 내의 외부인(Contributor) merge 기록이 존재한다. 필수
   7. 이슈: 최신 이슈가 충분히 있다.
   8. 이슈: bug 라벨이며, link된 PR이 없는 이슈가 하나라도 존재한다. 필수
3. 이슈고르기
   1. 재현코드 있으면 good
   2. 댓글 있으면 good

:)

별거 아닌 것처럼 써뒀지만,

사실 오픈소스 기여가 쉽지는 않다.

그럼에도, 한 번만 해봐도 쉬워지긴 하더라.

배운 점도 상당히 많다. 낯선 코드베이스를 받아들이는 경험, 천재들의 설계 의도를 느껴보는 경험을 할 수 있다.

뭔가. 한 줄 한 줄의 코드들을 읽다 보면, 코드 한 줄에서도 깊은 고심의 흔적이 느껴지는 순간이 온다.

아무튼 그렇다.

그러니, 다 읽은 김에 오늘 바로 시작해 보는 건 어떨까?

도움이 필요하다면 내 손을 잡아!