며칠 전, 제가 만든 첫 PR이 오픈소스 프로젝트에 머지되었습니다.
사소한 코드 수정이었지만, 제 깃허브 히스토리에 남은 그 '첫 커밋'은 제게 꽤 의미 있었습니다.
처음이라 낯설고 어렵게만 느껴졌던 오픈소스 기여, 어떻게 시작했고 어떤 과정을 거쳤는지 기록해봅니다.
오픈 소스 기여, 왜 시작했을까 ?
솔직히 말하면, 딱히 세상을 구하겠다는 원대한 꿈에서 시작한건 아니었습니다.
취업 준비를 하면서 제 잔디밭에 열심히 잔디를 심다 보니, 문득 다른 잔디밭은 어떻게 생겼는지 궁금해지더라고요.
그렇게 관심은 자연스럽게 오픈소스라는 거대한 잔디밭으로 옮겨갔습니다
하지만 막상 그 잔디밭을 구경하고, 거기에 물을 주려니 이런 생각이 들었습니다.
도대체 어디서부터 어떻게 시작해야 하지?
그래서 직접 방법을 찾아보기로 했습니다!
🌱 관심 있는 잔디밭 찾기
먼저, 내 취향에 맞는 오픈소스 프로젝트를 찾아야 했습니다.
누구나 한 번쯤 들어봤을 법한 유명한 프로젝트부터 "이런 것도 있었어?" 싶은 신기한 프로젝트까지, 세상엔 오픈소스가 정말 많습니다.
그래서 더욱더 어떤 프로젝트에 기여해야 할지 막막하고 답답했죠
... 그때까진요. Advanced Search를 알기 전까지는요.
👉 GitHub Advanced Search 바로가기
여기서 "Wtih the labels" 옵션에 "good first issue" 나 "beginner-friendly"를 입력하고,
스크롤 아래로 내려 주력 언어(Language)를 설정하면, 저처럼 오픈소스에 처음 기여해보려는 사람에게 적합한 이슈를 쉽게 찾을 수 있습니다.

그렇게 하나하나 살펴보며, 내가 도전해볼 수 있는 잔디밭을 고르게 되었죠.
⚡️ 본격적으로 오픈소스에 기여하기
기여하고 싶은 이슈를 찾았다면, 먼저 해당 이슈에 작업 의사가 있다는 코멘트를 남기는 것이 좋습니다.
이렇게하면 담당자가 이슈를 나에게 할당할 수 있고, 다른 사람이 같은 이슈를 동시에 작업하는 상황도 방지할 수 있습니다.
대부분에 오픈소스 프로젝트에는 이런 식으로 작업을 시작하길 권장하고 있습니다.

본격적인 작업에 들어가기 전에 프로젝트의 README, CONTRIBUTING.md 를 꼭 확인해 보는 것이 좋습니다.
이 문서들에는 프로젝트의 설치방법, 코드 구조, 그리고 기여 규칙(코딩 스타일, 커밋 메세지 작성법 등)이 자세히 안내되어 있습니다.
저 같은 경우에는 처음에는 문서 분량이 많다보니, 한 번에 다 읽으려다가 오히려 앞부분이 기억나지 않는 일이 많았습니다.
그래서 방향을 바꿔, 필요할 때 마다 찾아보는 방식으로 접근했습니다.
예를 들어 환경 설정에서 막히면 설치 관련 부분만 찾아보고,
PR을 보낼 때는 커밋 메세지 규칙이나 PR 템플릿 부분을 집중해서 읽는 식이었죠.
이렇게 작업 흐름에 맞춰 필요한 부분을 참고하다 보면, 자연스럽게 문서 내용도 익숙해지고 이해도 더 높아집니다.
처음부터 모든 내용을 완벽히 숙지하려 하기 보다는, 실제로 작업하면서 점진적으로 익혀가는 방식도 충분히 좋은 방법이라고 생각합니다.
🎬 작업 과정
먼저, 기여할 오픈소스 프로젝트의 원본 저장소를 포크(Fork) 해서 내 GitHub 계정으로 복제합니다.

그런 다음, 내 계정에 복제된 저장소를 git clone 명령어를 사용해 로컬 환경으로 내려 받습니다.
git clone https://github.com/계정명/프로젝트명.git
코드 작업을 시작하기 전에는 새로운 브랜치를 생성합니다.
처음에는 브랜치 이름을 어떻게 지어야 할 지 고민이 많았는데,
보통은 작업하려는 이슈 번호나 간단한 설명을 조합해 만드는 경우가 많습니다.
만약 프로젝트에 브랜치 네이밍 규칙이 있다면 그 규칙을 따르는 것이 가장 좋고,
별도의 규칙이 없다면 작업 내용을 한번에 알 수 있도록 간결하고 명확하게 작성하는 것이 좋습니다.
이제 본격적으로 코드를 수정하거나 필요한 기능을 추가합니다.
작업이 완료되면, 작은 단위로 커밋을 남기고 커밋 메세지는 해당 프로젝트에 규칙에 맞춰 작성합니다.
커밋 메세지 규칙은 CONTRIBUTING.md 문서나 기존 커밋 기록을 참고하면 도움이 됩니다.
이후, 정리한 작업 내용을 원격 저장소로 push 합니다.
PR 만들기
코드 작업이 끝났다면, 변경 사항을 오픈소스 프로젝트에 반영하기 위해 Pull Request(PR)을 생성 합니다.
대부분에 프로젝트에는 미리 정의된 PR 양식(템플릿)이 존재합니다.
양식이 있다면 그에 맞춰 내용을 채워주면 되고, 만약 없다면 기존 PR들을 참고하거나
리뷰어가 작업 내용을 빠르게 파악할 수 있도록 간격하고 명확하게 작성해주면 됩니다.
이때 관련 이슈 번호가 있다면 #이슈번호 도 꼭 함께 작성해 주면 좋습니다.
(GitHub)에서는 자동으로 해당 이슈와 PR이 연결 되거든요.
PR을 등록한 후에는 리뷰어의 피드백을 기다립니다.
만약 수정 요청이 들어온다면, 코드를 다시 수정하고 추거 커밋을 작성한 뒤 push하면 PR에 자동으로 반영됩니다.

🎉 머지(Merge)와 컨트리뷰터 등록
리뷰어가 제 PR을 확인하고 승인해주면, 제 코드가 프로젝트 Main 브랜치에 머지(Merge) 됩니다.
이 순간, 제가 수정한 코드가 공식적으로 오픈소스 프로젝트의 일부가 되는 것이죠.
PR이 머지되고 나면, Contributor 가 등록된 것을 확인할 수 있었습니다.
작고 사소한 기여였지만, 내 이름이 오픈소스 프로젝트에 기록된 걸 보니 뿌듯했습니다.
🙇♂️ @apache

📌 정리
처음 오픈소스에 기여해보겠다고 마음먹었을 땐 막막했습니다.
하지만 한 단계씩 차근차근 따라가다 보니, 어느새 첫 PR을 만들고 머지까지 경험할 수 있었죠.
작은 기여였지만, 포기하지 않고 끝까지 해냈다는 성취감은 생각보다 컸습니다.
이 경험은 단순히 코드를 수정한 걸 넘어서, 스스로 한 걸음 나아간 느낌이었습니다.
처음부터 완벽하려고 하기보단, 가볍게 시작해서 끝까지 해보는게 더 중요한 것 같더라고요
한 번의 완주 경험이, 다음 도전을 더 가볍게 만들어 주는 것 같아요.
혹시 지금 막막한 마음으로 망설이고 있다면, 일단 한번 해보자는 마음으로 도전해 보시길 바랍니다.
처음엔 어렵게 느껴질 수 있지만, 분명 어느 순간 여러분들도 자신만에 PR을 만들고 머지되는 그 짜릿한 순간을 마주하게 될꺼에요 🙌
'개발' 카테고리의 다른 글
| Spring 빈 후처리기(BeanPostProcessor)? (2) | 2025.05.29 |
|---|---|
| Spring AOP의 시작, ProxyFactory 이해하기 (2) | 2025.05.27 |
| JDK 동적 프록시, CGLIB (0) | 2025.05.26 |