[개발읽기 vol.6] 오픈소스 기여 방법 완벽 가이드 | 주니어·시니어 개발자가 얻는 이점

프론트엔드 개발자들의 이력서를 보면 종종 “오픈소스 기여 경험” 이라는 항목이 눈에 띄곤 합니다.
처음에는 단순히 대단해 보이는 한 줄이었지만, 곰곰이 생각해보면 “대체 어떻게 하는 걸까?”라는 의문이 생기더라고요.

 

회사 업무도 벅찬데, 오픈소스에까지 참여한다는 게 가능한 일일까 싶기도 하고요.
하지만 알고 보니 오픈소스 기여는 생각보다 특별한 일이 아니라, 작은 수정이나 문서화 개선부터 시작할 수 있다는 것을 알게되었습니다.

 

즉, 거창한 기능 개발이 아니라도 누구나 기여의 문을 열 수 있다는 거죠.
그 과정에서 얻는 경험과 배움은 단순히 ‘코드 몇 줄’ 이상이라는 사실이 매력적으로 다가왔습니다.

 

실제로 전 세계 개발자들과 협업하며 코드 리뷰를 받고, 더 나은 방식으로 문제를 해결하는 과정을 체험할 수 있습니다.
주니어 개발자라면 실무 경험을 쌓는 기회가 되고, 시니어라면 기술적 영향력을 넓히는 발판이 되기도 합니다.
또한, 나의 코드가 오픈소스 프로젝트에 반영되어 많은 사람들에게 쓰이는 경험은 개발자로서 큰 보람이죠.
그래서 오늘은 “오픈소스 기여하는 방법과 그 이점” 에 대해 이야기해보려 합니다.

 

 

 

오픈소스 기여? 뭐가 좋은데? 누가 알아주기나 해?

 

🟢 주니어 개발자에게 주는 도움

1. 실무 경험 대체
   • 회사 경험이 없더라도 대규모 프로젝트 코드와 협업 문화를 간접 체험할 수 있어요.
   • 코드 리뷰, 이슈 관리, PR 작성 방식 등을 배우면서 실제 기업의 개발 프로세스를 익히게 됩니다.
2. 포트폴리오 강화
   • 깃허브 기록 자체가 곧 이력서 역할을 해요.
   • "이 프로젝트에 이런 기능을 기여했다"라는 실질적인 사례는 면접에서 큰 강점이 됩니다.
3. 네트워킹
   • 오픈소스는 글로벌 커뮤니티라 전 세계 개발자들과 교류할 수 있습니다.
   • 멘토 같은 시니어 개발자와 자연스럽게 연결되기도 해요.
4. 실력 성장
   • 다양한 코드 스타일과 아키텍처를 보며 배우고, 내 코드가 리뷰를 받으면서 실력이 빨리 늘어요.

---

🔵 시니어 개발자에게 주는 도움

1. 리더십 / 영향력 확대
   • 단순히 코드 작성자가 아니라, 프로젝트 방향성 제안이나 리뷰를 통해 커뮤니티에 영향력을 줄 수 있습니다.
   • 기술 리더십을 증명하는 좋은 방법이에요.
2. 기술 깊이 확장
   • 자신이 주로 쓰던 영역이 아니라도 다양한 오픈소스에 참여하면서 시야가 넓어집니다.
   • 예를 들어 프론트엔드 시니어가 인프라 쪽 오픈소스에 기여하며 새로운 영역을 탐험할 수 있어요.
3. 커뮤니티 평판 & 브랜딩
   • 오픈소스에서 활발히 활동하면 커뮤니티에서 “이 분야 전문가”라는 인식이 생깁니다.
   • 이는 채용, 컨퍼런스 발표, 책 출판 등으로 이어질 수 있어요.
4. 회사의 기술 경쟁력에도 기여
   • 소속 회사가 사용하는 오픈소스에 기여하면, 회사의 기술적 문제 해결에도 직결됩니다.

 

 

많은 기업들이 오픈소스 기여에 적극적입니다. 🌍
관심 있는 프로젝트나 라이브러리를 직접 확인하고 참여해보고 싶다면, 아래 링크에서 오픈소스 활동을 살펴볼 수 있습니다. 🔗

 

카카오 오픈 소스 기여

https://kakao.github.io/docs/contribute/participate/

 

 

네이버 오픈소스 기여

https://naver.github.io/OpenSourceGuide/book/BetterContribution/why-contribute-to-open-source.html

 

https://www.sktenterprise.com/bizInsight/blogDetail/dev/2900

개발자가 오픈소스에 기여해야 하는 이유 | 개발자 Story | SKT Enterprise

 

 

그리고 다른 좋은 예로는,

토스 같은 곳에서는 토스의 오픈소스에 기여를 했던 분중에 채용으로까지 이어진 케이스도 있다고해요!

https://toss.tech/article/firesidechat_frontend_4

오픈소스에 기여하고 토스에 합격한.ssul | EP.4 모닥불

토스 오픈소스 라이브러리

👉 es-toolkit 👉 es-hangul 👉 suspensive 👉 overylay-kit 👉 use-funnel

 

인터뷰에 따르면, 한 토스 개발자님은 작은 개발 조직에서 다양한 프로젝트에 참여했지만, 프론트엔드 기술적으로 큰 성장을 느끼지 못하고 있던 중 오픈소스 활동을 알게 되었다고 합니다.

토스의 오픈소스를 보면서 “토스는 코드를 이렇게 작성하고, 이슈나 PR을 이렇게 커뮤니케이션하는구나”라는 생각을 하게 되었고, 이에 참여를 시작했다고 합니다.결국 매일 비슷한 방식으로 서비스를 개발하던 중, 새로운 경험을 통해 기술적으로 성장하고 싶다는 동기가 계기가 되었다고 합니다.

 

 

또 다른 개발자는 토스 입사 과정에서 세 번의 탈락을 경험한 후, 토스가 코드를 어떻게 작성하는지 궁금해서 오픈소스를 살펴보게 되었고, 이후 기여까지 이어졌습니다.
초기에는 문서(docs)부터 수정하다가 점차 코드 영역으로 확장했다고 합니다.
간단하게는 타입 정의와 테스트 코드부터 시작해, CI 관련 코드 등으로 참여 범위를 넓혔다고 합니다.
토스 개발자들과 무료로 코드리뷰를 할 수 있는 경험과 더불어 이미 구현되어 있는 코드를 보면서 빠르게 학습할 수 있는 환경이었기 때문에 지속적으로 참여하게 되었다고 합니다.

 

**CI(Continuous Integration): 코드가 항상 출시 가능한 상태를 유지할 수 있도록 확인하는 작업을 자동으로 실행해주는 도구

 

 

토스 내부에서도 오픈소스를 시작한 계기가 있었습니다. 모노리포 관리나 라이브러리 설계 등 다양한 베스트 프랙티스를 찾고 실제로 적용했지만, 토스 밖에서는 이러한 리소스를 찾기 어렵다는 점을 느꼈다고 합니다.
이에 실용적인 문제 해결 과정을 공개하고 공유하고 싶다는 마음으로, FEConf 컨퍼런스를 계기로 오픈소스를 시작하게 되었다고 합니다.

오픈소스 기여의 이점

오픈소스는 누가 사용할지 예측할 수 없기 때문에, 인터페이스 관점에서 “어떻게 하면 Breaking Change가 없을까?” “어떻게 하면 더 유연하게 설계할 수 있을까?”와 같은 고민을 깊게 할 수 있습니다.
많은 사람들이 사용하는 환경에서는 한 번 잘못된 설계가 되돌릴 수 없는 기술 부채로 남게 되므로, 인터페이스 설계를 더 신중하게 고민하게 됩니다.
그 과정에서 보다 깊이 있는 인터페이스 설계 능력을 배우고, 자연스럽게 전문성을 쌓을 수 있는 장점이 있다고 합니다.

**Breaking Change: 기존코드가 올바르게 동작하는 것을 보장하지 못하는 라이브러리 수정사항

 

 

새로운 라이브러리를 만드는 사람에게 가장 중요한 것은, 라이브러리가 진짜 해결하고자 하는 문제가 무엇인지 명확히 정의하는 것입니다.
이것이 명확해야, 사용자의 요청이나 기능 추가 제안이 들어왔을 때 단순히 무작정 수용하는 것이 아니라, 라이브러리의 목적에 맞게 선택적으로 반영할 수 있습니다.

 

 

실제로 인기 있는 라이브러리들을 보면 이런 기준이 잘 지켜집니다. 예를 들어 TanStack Query와 SWR, 또는 Jotai와 Recoil 같은 경쟁 라이브러리를 보면, 결국 살아남는 라이브러리는 사용자 피드백을 잘 반영하고, 목적에 맞게 진화한 라이브러리입니다.
즉, 단순히 기능이 많거나 최신 트렌드를 따른다고 해서 성공하는 것이 아니라, 문제를 정확히 정의하고 피드백을 체계적으로 반영하는 능력이 라이브러리의 생존력과 직결된다고 볼 수 있습니다.

 

https://meetup.nhncloud.com/posts/323

서비스 개발하다 오픈소스 기여한 썰 (1) : NHN Cloud Meetup

 

 

https://youtu.be/v4bFCpP9BWk?si=yhWXFnRHHP4RihK9

 

 

🐙 GitHub에서 작성한 '오픈소스에 기여하는 방법'

https://opensource.guide/ko/how-to-contribute/

오픈소스에 기여하는 방법

 

 

 

 

자, 그러면 이제 오픈소스에 기여하는 방법을 직접 체험해보겠습니다! 🚀
처음이라 조금 긴장될 수 있지만, 차근차근 따라가면 충분히 할 수 있어요. 😎

 

🪜 오픈소스 기여 방법

경험 많은 기여자들이 공통적으로 말하는 방법
1) 문서부터 읽기
   - README, CONTRIBUTING.md, 코드 구조 다이어그램이 있다면 먼저 확인합니다.  
   - 어떤 기능을 하는 프로젝트인지, 로컬에서 실행하는 방법은 무엇인지 파악합니다.

2) 작은 부분만 보기
   - 프로젝트 전체를 한 번에 이해하려고 하지 않습니다.  
   - 내가 수정하려는 이슈와 관련된 폴더나 컴포넌트만 집중해서 살펴봅니다.

3) 실행 먼저 해보기
   - 로컬에 설치하고 실행해서 실제 동작을 눈으로 확인합니다.  
   - 코드가 눈에 익지 않아도 “이 버튼이 여기구나” 하면서 기능과 코드를 연결하면 금방 익숙해집니다.

4) 이슈와 PR 읽기
   - 기존에 열린 이슈나 머지된 PR을 읽어보면, 코드베이스를 다루는 방식과 커뮤니케이션 스타일을 배울 수 있습니다.

 

 

🪜 오픈소스 기여 단계별 방법

1단계: 관심 있는 프로젝트 찾기

• GitHub, GitLab, Bitbucket 등에서 본인이 사용하는 라이브러리나 툴을 중심으로 찾아보세요.
• good first issue, help wanted 같은 라벨이 붙은 이슈는 초보자가 시작하기 좋아요.

주니어: 평소에 사용하는 라이브러리(React, Vue, Tailwind 등)에서 good first issue 라벨을 찾아보세요. 작은 버그나 문서 수정이 많아 시작하기 좋습니다.

시니어: 회사에서 실제로 사용하는 핵심 라이브러리나 인프라 툴을 골라보세요. 직접 기여하면 회사 업무에도 도움이 되고 영향력도 큽니다.

2단계: 프로젝트 이해하기

• README.md 파일을 먼저 꼼꼼히 읽어보세요.
• 설치 방법, 기여 가이드(CONTRIBUTING.md), 코드 구조를 파악하는 게 첫걸음입니다.

주니어: README, 설치 가이드, CONTRIBUTING.md를 꼼꼼히 읽고 구조를 익히는 것부터 시작하세요. “어떻게 돌아가는지 이해하기”가 첫 번째 목표입니다.

시니어: 단순 구조 파악을 넘어서 아키텍처, 코드 스타일, 테스트 방식까지 파악해두면 이후에 방향성 제안이나 코드 리뷰에도 참여할 수 있습니다.

3단계: 로컬 환경 세팅하기

• 해당 프로젝트를 fork → clone 해서 내 컴퓨터에 내려받습니다.
• 의존성 설치 후 프로젝트가 정상적으로 실행되는지 확인하세요.

주니어: 프로젝트를 fork → clone 후 실행해보면서 빌드가 잘 되는지 확인하세요. 환경 세팅에 익숙해지는 게 중요한 경험입니다.

시니어: 세팅 과정에서 발견한 불편함을 문서화하거나 개선하는 것도 좋은 기여 포인트가 됩니다.

4단계: 작은 기여부터 시작하기

• 오타 수정, 문서 보완, 코드 주석 추가처럼 작은 수정도 기여입니다.
• 점차 버그 수정이나 기능 개선 같은 실질적인 코드 기여로 확장해보세요.

주니어: 문서 오타 수정, 번역, 주석 보완 같은 작은 것부터 시작하세요. PR이 병합되는 경험이 동기부여가 됩니다.

시니어: 버그 픽스, 성능 개선, 코드 리팩터링 등 조금 더 복잡한 부분에 기여할 수 있습니다. 필요하다면 로드맵에 제안(PRD, Issue Discussion)을 남기는 것도 방법입니다.

5단계: 브랜치 생성 & 수정 반영

• 작업 전 새로운 브랜치를 만들고(git checkout -b feature/fix-typo) 변경 사항을 커밋합니다.
• 커밋 메시지는 의도와 수정 내용을 명확히 적는 게 좋아요.

주니어: 브랜치 네이밍, 커밋 메시지 작성 등 Git 사용에 익숙해지는 연습을 하세요.

시니어: 팀 내에서 통용되는 Git 컨벤션을 반영하거나, 커밋 메시지 스타일 가이드를 제안할 수도 있습니다.

6단계: Pull Request(PR) 올리기

• 원본 저장소에 PR을 생성합니다.
• PR 설명에는 변경한 이유, 테스트 방법, 참고한 이슈 번호를 정리하면 리뷰어가 이해하기 쉽습니다.

주니어: 변경 이유와 방법을 간단히 적어 리뷰어가 이해하기 쉽게 쓰는 게 중요합니다.

시니어: 관련된 이슈 번호, 변경 범위, 테스트 방법까지 상세히 작성하면 리뷰어와의 커뮤니케이션 비용이 크게 줄어듭니다.

7단계: 리뷰 반영 & 머지 기다리기

• 리뷰어가 피드백을 주면 적극적으로 반영합니다.
• 머지되면 드디어 공식적으로 오픈소스에 기여한 거예요 🎉

주니어: 리뷰에서 받은 피드백은 배움의 기회라고 생각하세요. 리뷰어의 코드 스타일과 사고방식을 배우는 과정입니다.

시니어: 단순 반영을 넘어서 리뷰어와 토론하면서 더 나은 해결책을 제안할 수도 있습니다. 커뮤니티 내에서 리더십을 보여줄 수 있는 부분이에요.

 

 

 

말로만 설명하면 막막할 수 있으니, 아주 간단한 실습을 같이 해보겠습니다.  

 

✅ 단계별 따라하기: 오픈 소스 첫 기여 해보기

1. [goodfirstissue.dev](https://goodfirstissue.dev/) 사이트에 들어갑니다.  
2. 관심 있는 기술 스택을 선택합니다. (예: JavaScript / TypeScript)  
3. 마음에 드는 프로젝트의 이슈를 하나 고릅니다.  
4. 레포지토리를 Fork → Clone 합니다.  
5. `README.md`에서 실행 방법을 따라 프로젝트를 띄워봅니다.  
6. 이슈와 관련된 부분의 코드를 찾아 작은 수정(예: 텍스트 변경, 문서 수정)을 합니다.  
7. 새로운 브랜치를 만들어 커밋 후 PR을 생성합니다.  
8. 리뷰어가 남긴 피드백을 반영하면 🎉 첫 오픈 소스 기여 완료!

 

 

 

 

한번 실습 해볼께요!

 

1. 우선 https://goodfirstissue.dev/  에 접속해 볼께요. 카테고리는 JavaScript로 해볼께요.

 

 

2. 프로젝트 선택하기 (Stylelint)

 

🧭 Stylelint 프로젝트 소개

Stylelint는 CSS 및 그 전처리기(SCSS, Less 등)의 코드 품질을 검사하고 일관성을 유지하는 데 도움을 주는 도구입니다. 전 세계의 개발자들이 함께 기여하고 있으며, 초보자도 참여할 수 있는 이슈들이 열려 있습니다.

 

🔍 'Good First Issue' 찾기

Stylelint GitHub 레포지토리의 이슈 중 'good first issue' 레이블이 붙은 이슈들을 확인해보세요. 이러한 이슈들은 초보자도 기여할 수 있도록 설계되어 있습니다.

 

'Good First Issue' 는 어떻게 찾나요?

1️⃣ GitHub 레포지토리 접속

• 브라우저에서 Stylelint 레포에 접속합니다.

2️⃣ Issues 탭 클릭

• 레포 상단 메뉴에서 Issues 탭을 클릭합니다.
• Issues 탭에서는 프로젝트에서 열려 있는 모든 이슈를 확인할 수 있습니다.

3️⃣ 레이블 필터링

1. Issues 화면에서 Labels 버튼(오른쪽 상단)을 클릭합니다.
2. 레이블 목록에서 good first issue를 찾아 클릭합니다.
   • 이 레이블이 붙은 이슈만 화면에 남게 됩니다.
   • Stylelint처럼 활발한 프로젝트에는 여러 ‘good first issue’가 동시에 열려 있어 초보자가 선택하기 좋습니다.

💡 Tip: 검색창 활용

Issues 검색창에 is:issue is:open label:"good first issue"를 입력하면, 열려 있는 good first issue만 필터링해서 바로 볼 수 있어요.

 

🛠️ 실습: 'good first issue'로 기여하기

1️⃣ 레포지토리 포크 및 클론

1. Stylelint GitHub 레포지토리에 접속하여 우측 상단의 Fork 버튼을 클릭합니다.
2. 본인의 GitHub 계정으로 포크한 후, 로컬에 클론합니다: 
3. git clone https://github.com/your-username/stylelint.git cd stylelint

2️⃣ 의존성 설치

프로젝트의 루트 디렉토리에서 다음 명령어로 의존성을 설치합니다:

npm install

 

 

3️⃣ 로컬 서버 실행

다음 명령어로 로컬 서버를 실행합니다:

npm start

 

브라우저에서 http://localhost:8080을 열어 프로젝트가 정상적으로 실행되는지 확인합니다.

 

 

4️⃣ 이슈 분석 및 수정

1. GitHub에서 'good first issue' 레이블이 붙은 이슈를 선택합니다.
2. 이슈의 내용을 분석하고, 수정이 필요한 부분을 파악합니다.
3. 필요한 파일을 수정합니다. 예를 들어, src/ 디렉토리 내의 관련 파일을 수정할 수 있습니다.

 

5️⃣ 브랜치 생성 및 커밋

1. 새로운 브랜치를 생성합니다:
2. git checkout -b fix-issue-1234
3. 변경된 파일을 스테이징합니다:
4. git add .
5. 커밋 메시지를 작성합니다:
6. git commit -m "Fix: Issue #1234 - 설명"

 

6️⃣ 원격 저장소에 푸시

변경 사항을 원격 저장소에 푸시합니다:

git push origin fix-issue-1234

 

 

 

7️⃣ Pull Request 생성

1. GitHub에서 포크한 레포지토리로 이동합니다.
2. "Compare & pull request" 버튼을 클릭하여 PR을 생성합니다.
3. PR 제목과 설명을 작성하고, "Create pull request"를 클릭합니다.

 

8️⃣ 리뷰 및 피드백 반영

PR에 대한 리뷰어의 피드백을 기다립니다. 피드백을 반영하여 코드를 수정하고, 변경 사항을 커밋하여 푸시합니다. 수정된 내용이 PR에 자동으로 반영됩니다.

 

 

 

9️⃣ 기여 완료

리뷰어가 PR을 승인하면, 기여가 완료됩니다. GitHub에서 기여 내역을 확인할 수 있습니다.

 

 

 

 

오픈소스 활동은 단순히 코드를 공개하는 것을 넘어, 개발자로서 성장할 수 있는 훌륭한 기회를 제공합니다.
토스 개발자들의 사례처럼, 일상적인 프로젝트만으로는 경험하기 어려운 다양한 개발 방식과 협업 문화를 배울 수 있습니다.
실제 코드를 보고, 이슈와 PR을 확인하며 다른 사람들의 사고 방식을 이해하는 과정 자체가 큰 학습이 됩니다.

 

작은 문서 수정이나 간단한 버그 해결부터 시작해도 충분히 의미 있는 기여가 될 수 있습니다.
조금씩 참여하며 경험을 쌓다 보면, 점점 더 복잡한 프로젝트에도 자신 있게 도전할 수 있습니다.
오픈소스를 통해 글로벌 개발자 커뮤니티와 연결되고, 다양한 사람들과 협업할 수 있다는 점 또한 큰 장점입니다.

 

리뷰와 피드백을 받는 과정은 스스로를 돌아보고 기술적 역량을 점검하는 좋은 기회가 됩니다.
자신이 작성한 코드가 실제로 많은 사람에게 도움이 된다는 점에서 큰 보람을 느낄 수 있습니다.
기술적 성장과 실질적인 경험을 동시에 얻고 싶다면, 오픈소스 참여는 최고의 선택이 될 수 있습니다.

 

결국, 오픈소스 활동은 배우고, 나누고, 성장하는 여정 그 자체임을 잊지 않는 것이 중요합니다.