오픈소스 기여 처음 해봤을 때의 솔직한 후기

개발자 현직자 솔직 경험담

오픈소스 기여 처음 해봤을 때의
솔직한 후기

오타 수정 PR도 손이 떨렸던 그날, 그리고 두 달 뒤 첫 기능 기여까지.

처음 오픈소스에 PR을 올린 건 부끄럽지만 오타 수정이었다. README에 있는 "recieve"를 "receive"로 고치는, 코드 한 줄도 안 건드리는 PR이었는데도 제출 버튼을 누르기까지 30분을 망설였다. "이런 걸로 PR 올려도 되나", "괜히 민폐 아닐까" 같은 생각이 계속 들었다. 그날의 소심함부터 두 달 뒤 실제 기능을 기여하기까지의 과정을 솔직하게 정리해봤다.

오픈소스 기여 처음 해봤을 때의 솔직한 후기

30분첫 오타 PR 제출까지 망설인 시간

2개월첫 기능 기여까지 걸린 기간

6건이후 3개월간 누적 PR 수

1. 첫 PR — 오타 수정도 손이 떨렸던 이유

평소 즐겨 쓰던 UI 라이브러리의 문서를 읽다가 오타를 발견했다. 별거 아닌데도 PR을 올리기 전에 별의별 생각이 다 들었다.

나 이거 진짜 사소한 오타인데... 이런 것도 PR로 올려도 되는 걸까?

개발자 커뮤니티 지인 당연하죠, 오히려 오타 수정 같은 작은 PR이 오픈소스 기여의 정석적인 시작이에요. 메인테이너 입장에서도 부담 없이 반가워요.

이 말을 듣고서야 용기를 냈다. PR을 올리고 몇 시간 뒤, 메인테이너가 "Thanks for the fix!"라는 짧은 코멘트와 함께 바로 머지해줬다. 그 순간의 기쁨이 생각보다 컸다. 내 이름으로 된 커밋이 유명한 오픈소스 프로젝트 히스토리에 남는다는 것이 신기했다.

PR #1204 · docs: fix typo in README Merged

메인테이너 Thanks for the fix! Small contributions like this really help. 🙌

💡 처음 시작하려는 분들에게 오타 수정이나 문서 개선 같은 작은 기여는 절대 부끄러운 시작이 아니다. 오히려 오픈소스 기여 프로세스(포크, 브랜치, PR 규칙)에 익숙해지는 가장 안전한 방법이었다.

2. 두 번째 시도 — 진짜 코드 기여를 시도했다가 겪은 좌절

오타 수정에 자신감을 얻고, 이번엔 실제 버그를 고쳐보기로 했다. Issue 목록에서 "good first issue" 라벨이 붙은 이슈를 찾아서 도전했다. 근데 생각보다 훨씬 어려웠다.

// 내가 처음 제출한 수정안 function formatDate(date) { return date.toISOString().split("T")[0]; } // 리뷰어 코멘트: 타임존 문제로 날짜가 하루 밀리는 케이스가 있어요. // 프로젝트 전체에서 쓰는 date-fns 유틸을 사용해주실 수 있을까요?

내 나름대로는 완벽하다고 생각한 코드였는데, 리뷰에서 타임존 이슈를 지적받았다. 게다가 이미 프로젝트에서 쓰고 있던 유틸 함수가 있다는 걸 몰랐다. 코드베이스 전체를 제대로 살펴보지 않고 급하게 접근한 게 문제였다.

첫 시도

즉흥적으로 구현

프로젝트 컨벤션, 기존 유틸 확인 없이 작성

두 번째 시도

기존 코드 먼저 탐색

CONTRIBUTING.md와 기존 유틸부터 확인 후 작성

⚠ 그때 배운 것 오픈소스 기여는 내 코드 실력을 보여주는 자리가 아니라, 그 프로젝트의 기존 방식에 맞춰 들어가는 작업이었다. 코드를 짜기 전에 CONTRIBUTING.md와 유사한 기존 코드를 먼저 찾아보는 습관이 필요했다.

3. 리뷰를 받으며 가장 크게 배운 것

수정한 PR을 다시 올렸는데, 이번엔 또 다른 지적을 받았다. 처음엔 당황스러웠지만, 리뷰어의 태도가 예상과 달리 굉장히 친절했다.

PR #1289 · fix: date formatting timezone issue Changes requested

리뷰어 좋은 접근이에요! 다만 이 프로젝트는 date-fns의 format 함수를 표준으로 쓰고 있어서, 일관성을 위해 그쪽으로 맞춰주시면 좋을 것 같아요. 관련 예시는 src/utils/date.js 40번째 줄 참고해보세요.

리뷰어가 단순히 "틀렸다"고 말하지 않고, 왜 그런지와 참고할 코드까지 짚어준 덕분에 방어적인 마음 없이 수정할 수 있었다. 낯선 사람들과의 협업에서 리뷰 코멘트를 어떻게 주고받아야 하는지를 실전에서 배운 셈이었다.

1주 차

오타 수정 PR 첫 성공. 오픈소스 기여 프로세스에 대한 심리적 장벽이 낮아짐.

3주 차

첫 버그 수정 PR 제출, 두 차례 수정 요청 받음. 프로젝트 컨벤션 파악의 중요성을 체감.

6주 차

두 번째 버그 수정 PR, 이번엔 한 번의 리뷰 만에 승인. 확실히 컨벤션 파악 속도가 빨라짐.

8주 차

메인테이너로부터 직접 "이 기능 추가해볼래요?"라는 제안을 받고 첫 신규 기능 기여 시작.

4. 예상 못 했던 부수 효과들

단순히 코드 실력이 는 것 외에도, 예상하지 못한 변화들이 있었다. 특히 영어로 기술 문서를 읽고 쓰는 것에 대한 두려움이 크게 줄었다. PR 설명과 리뷰 코멘트를 영어로 주고받다 보니, 자연스럽게 실전 영작 연습이 됐다.

기여 전 — 영어 기술 문서 작성 자신감3 / 10

 

2개월 후 — 자신감6.5 / 10

 

3개월 후 — 자신감7.5 / 10

 

또한 실제로 이력서에 오픈소스 기여 이력을 추가한 뒤, 면접에서 이 부분에 대한 질문을 받으며 이야기할 거리가 하나 늘었다는 것도 체감할 수 있는 효과였다.

3개월 후 결론

오타 수정에서 시작한 첫 기여가 두 달 만에 실제 기능 기여로 이어질 줄은 몰랐다. 완벽한 코드를 준비해서 시작하려 했다면 아마 아직도 시작 못 했을 것이다. 작은 것부터, 부끄러워하지 않고 시작하는 게 가장 중요했다.

"완벽한 첫 기여는 없었다. 오타 수정이라도 시작한 게 전부였다."

2026년 현재도 대부분의 오픈소스 프로젝트는 "good first issue"라는 라벨로 초보자용 이슈를 따로 표시해두는 경우가 많다는 이야기를 자주 듣는다. 다만 프로젝트마다 기여 문화와 리뷰 속도가 크게 다르므로, 처음이라면 커뮤니티가 활발하고 CONTRIBUTING 문서가 잘 갖춰진 프로젝트부터 시작하는 걸 추천한다.

결론

오픈소스 기여는 거창한 코드 실력이 아니라, 작은 시작에서 출발해도 충분하다는 걸 직접 겪어보고 알게 됐다. 오타 수정 하나에도 손이 떨렸던 나 자신이 두 달 만에 실제 기능을 기여하게 된 건, 완벽을 기다리지 않고 일단 시작했기 때문이었다. 오픈소스 기여를 망설이고 있는 개발자가 있다면, 아주 작은 오타 수정부터라도 가볍게 시작해보길 권하고 싶다.

여러분의 첫 오픈소스 기여는 어떠셨나요?

오픈소스 기여를 시작하며 겪은 경험이나 노하우가 있다면 댓글로 공유해주세요. 지금 시작을 망설이고 있는 다른 개발자분들께 큰 힘이 될 것 같습니다.