오픈소스 기여 어떻게 시작해야 되나요 ?

프로그래머라면 누구나 오픈소스를 자연스럽게 접하게 되고 한 번쯤은 "아 나도 저런 오픈소스에 기여해보고 싶다!" 라는 생각이 들기 마련이다.
필자도 과거에 "오픈소스에 기여를 하는것" 이 꿈일 정도로 오픈소스라는 세계를 높이 바라봤던거 같다.
어쩌면 그곳에 내가 닿을 수 있을까? 라는 생각도 많이 들었다.

장벽

오픈소스 환경에 익숙하지 않은 사람들에게 오픈소스의 진입장벽은 굉장히 높게 느껴진다.
사실 솔직히 말하면 주니어에게는 어느정도 높은것도 사실이다.
정확히 말하면 "생각보다 높지 않다" 는 것이다.
그리고 AI의 등장으로 이 진입장벽은 점점 낮아지고 있다.

저.. 영어 못하는데요 ..

대부분 오픈소스에서 모든 대화는 영어로 진행된다.
나의 의견, 생각들을 모두 영어로 표현 해야한다는건 한국인들에게 큰 진입장벽이다.
하지만 겁먹을필요 없다.
필자또한 이 부분에 대해서 겁을 먹었던 적이 있다.
한 번은 django에서 필드 검증과 패스워드 검증기 사이의 일관성과 관련하여 개선점을 제안한적이 있다.

이게 왜 개선되어야하는지에 대한 나의 논리를 설명하는게 필요했기 때문에 영어실력이 정말 중요한 순간이었다.
난 어떻게 했을까?
필자는 AI를 통해 내 생각을 먼저 전달하고 그 문장을 영어로 번역해달라 한 뒤에 AI가 생성한 메시지를 전달했다.
여기서 AI번역을 거친 나의 생각을 전달하는게 괜찮을까? 라는 의문이 들 수 있다.

지금까지 django에서 1년 반동안 했던 개선점(이슈), 작업, 리뷰, 토론, 디스코드 활동에서 단 한 번도 문제가 되었던적은 없다.
그렇기 때문에 지금 시대에 영어는 더 이상 오픈소스 기여의 진입장벽이라고 생각되지 않는다.
물론 영어가 가능하면 좋다.
특히 일반 기여자 이상으로 인정받기 시작하는 순간부터는 화상회의에 참여해야할 수도 있다 !!
하지만 이것또한 문제없다고 생각된다.
실제로 django 접근성팀은 매달 화상회의를 하지만 필자가 "영어로 의사소통이 어려운 사람은 어떻게 해야하나요?" 라고 물었을때 회의에 비동기적으로 참여해서 메시지만 전달해도 괜찮다는 답변을 받긴 했다.

낯선 코드베이스

오픈소스의 코드베이스를 익히는건 어렵다.
특히 아무래도 웹개발자가 매번 봐왔던 코드와는 조금 다른 코드의 형태일 수도 있다.
심지어 주니어에겐 경험해보지 못한 규모일 수도 있다.
django같은 경우를 예시로 들면 django의 소스코드는 테스트를 포함하면 100만줄 가까이된다.(테스트만 18000개가 넘는다.)
그렇기 때문에 처음 시작하는 사람에게 코드베이스 적인 측면에서 가장 어려움은 엔트리포인트인 기능의 진입점을 찾는것이다.

"난 어디를 수정해야 하는걸까.."
"테스트는 어디에 작성해야 할까.."

하지만 이 진입점을 찾아가는것도 AI 덕분에 많이 장벽이 낮아졌다.
예시로 django에서 claude-code를 통해 6.0에 새롭게 추가된 CSP Middleware기능과 관련된 파일, 함수를 찾아달라는 프롬프트를 전달했을때 다음과 같은 결과를 전달받을 수 있었다.

위 사진을 보면 알 수 있듯이 핵심 소스파일이 어디에 있는지 전달받을 수 있을 뿐만 아니라 파일 내에 있는 각 함수의 기능을 간단히 표현하고 심지어 테스트 파일의 위치도 알려준다.
이렇게 AI를 통하면 낯선 코드베이스에서 내가 특정 부분을 수정해야하는 진입점을 찾아내기 쉽다.

여기서 다음과 같은 궁금증이 들 수 있다.
"그러면 AI를 통해 문제도 해결할 수 있나요? 버그 수정이나 간단한 리팩토링 같은 작업이요 !"
답을 먼저 말하면 "가능하다" 이다.
하지만 "완전히 가능하다" 는 아니다.
필자의 경험에 의하면 AI를 통해 문제를 해결한 PR들의 변경사항은 대부분 문제는 해결했지만 효율적으로 해결하지 못한게 대부분이었다.
즉, 기존의 코드베이스를 활용하지 않은 불필요한 코드들을 만들어 해결하는걸 많이 봐왔다.
그렇기 때문에 결국 오픈소스 기여까지 가는데에는 코드베이스의 특정 부분을 익혀야하는 어려움이 존재한다.
하지만 앞에서도 말했듯이 AI의 등장으로 난이도가 굉장히 낮아진건 사실이다.
만약 코드베이스의 특정 부분을 이해하기 어렵다면 AI에게 설명서를 제공받는건 어떨까? 😏

심리적인 압박

오픈소스에는 대단한 개발자들이 널려있다.
가끔식 프로필을 눌러보면 Github Star, 팔로워 1k 이상, 유명한 서드파티 라이브러리의 메인테이너인 사람들을 보며 기가 죽기 마련이다.

"아... 내가 참여해도 되는 곳인가?"
"내 수준으로 가능할까?"
"만약 나의 변경사항으로 큰 문제가 생기면 어떡하지?"

위와 같은 생각들이 들고는 한다.
사실 이 생각들이 가장 큰 진입장벽이다.
어쩌면 오픈소스 세계로 진입하는건 이 생각들을 버리는것부터가 시작이다.

아... 내가 참여해도 되는 곳인가?

오픈소스는 누구에게나 열려있다!
애초에 오픈소스는 그 누군가에 의해서 유지된다.
그렇기 때문에 참여하려는 사람들을 아낌없이 환영한다.
물론 비신사적인 행동을 했을때는 아니긴 하다.

내 수준으로 가능할까?

가능하다!
필자는 지금도 엉터리지만 django에 처음 기여를 도전했을 당시에는 더 엉터리 였다.
하지만 내가 엉터리여도 오픈소스에는 주변에 뛰어난 개발자들이 정말 많다.
그렇기 때문에 적극성을 보여주고 도움을 많이 요청하면 된다.
결국 같이 해결해나가는게 오픈소스의 묘미라고 생각된다.

만약 나의 변경사항으로 큰 문제가 생기면 어떡하지?

이것또한 고민할 필요가 없는 문제다.
어차피 병합까지 가는길에는 많은 검토가 이루어지기 때문이다.
만약 문제가 생길지라도 다시 되돌리거나 해결하면 되지 않을까 ?
필자도 django에서 했던 작업중에 하나의 작업으로 인해 5개의 버그가 발생했던 적이 있다.
조금 슬프긴했지만 이 모든게 내 책임이라고 생각하지 않는다.
오픈소스는 "같이 해결해나가는 것"
그렇기 때문에 해당 작업에 참여한 모든 사람의 책임이다.
그리고 그 책임은 생각보다 무겁지 않다.

어떻게 시작해요 ?

오픈소스 어떻게 시작해야할까?
가장 먼저 기여할 리포지토리를 선정해야한다.
하지만 내가 좋아하고 정말 기여하고 싶은 라이브러리라도 초보자 입장에서는 난이도가 높을 수 있으며 아예 기여가 될 가능성이 완전히 낮은 리포지토리도 존재한다.
그렇기 때문에 기여가 목적이라면 리포지토리 선정단계에서 고려해야할 사항들이 몇가지에 대해서 소개하겠다.

이슈가 많은가요?

단순히 생각해보면 간단하다.
이슈가 많은 리포지토리일수록 기여자 입장에서 도전해볼 선택지가 많다는뜻 아닐까?

경량 JS 라이브러리인 alpineJS와 상태관리 라이브러리인 jotai는 훌륭한 라이브러리지만 초보자가 기여하기에 좋은 라이브러리라고 할 수 없다.
이유는 이미 너무 잘 관리가 되고 있어 이슈가 많지 않다는 점이다.
보통 작은 코드베이스를 가진 라이브러리의 경우에는 메인테이너가 제작자 한 명인 경우가 많으며 관리가 꽤나 잘 되는 상태인 경우가 많다.
물론 불가능한건 아니지만 본인이 사용자 입장에서 문제점을 찾아내야 한다.
기여에 처음 도전하는 사람 입장에서 문제점을 찾아내고 기여까지 도전하는건 다소 난이도가 높을 수 있다.
한 가지 팁이 있다면 보통 이런 라이브러리 기여에 도전할때는 리포지토리의 Issue탭을 보는것보다 메인테이너에게 이메일이나 디스코드를 통해 직접적인 연락을 하는게 더 낫다.

필자도 최근에 MSW라는 라이브러리에 관심을 가지게 되었고 해당 라이브러리도 jotai, alpineJS와 같이 메인테이너 한명이 유지보수를 하고 있고 유지보수가 잘 되고 있는 규모가 크지 않은 리포지토리다.

위와 같이 기여에 관심있다고 적극적으로 어필해보자 !
기여에 관심있다고 초보자가 시도해볼만한 이슈를 알려달라고 했을때 친절하게 답변을 하지 않은 메인테이너는 단 한 명도 보지 못했다.
코드베이스에 대한 이해도가 제일 높은건 메인테이너일 확률이 가장 높다. 어쩌면 메인테이너의 머릿속이 Github 이슈탭의 확장버전이라고 생각해도 괜찮다.

최근 커밋이 많은가요?

최근 커밋의 개수는 이 라이브러리가 얼마나 활동적으로 운영되고 있나? 의 지표이다.

텍스터 에디터 라이브러리인 editor.js는 이슈가 많다!
이전에도 말했듯이 이슈가 많다는건 기여자가 도전해볼 선택지가 많다는 뜻이다.
그러면 editor.js는 초보자가 기여하기 좋은 라이브러리일까?
답은 "아니요" 이다.

위 사진을 보면 알 수 있듯이 editor.js는 2026년에 기록된 커밋이 8개 밖에 존재하지 않는다.
즉, 라이브러리가 활동적이지 않다는 뜻이다.
활동적이지 않다는건 관리가 잘 안된다는걸 의미하며 내가 PR을 올려도 관심이 없을 영향이 크다.

필자의 경험에 의하면 예전에 drf-spectacular 라는 API 스키마 생성 도구에 문서 기여를 시도한적이 있다.

문서에 필요하지 않은 주석제거로 아주 간단한 기여였지만 반영되는데 10개월이 걸렸다.

커밋에 일반기여자가 많은가요?

커밋에 일반기여자가 많다는건 그만큼 일반 기여자에게 친화적이다 라는걸 의미한다.
보통은 큰 규모의 오픈소스는 일반 기여자에게 친화적이며 일반기여자들을 핵심적인 자원이라고 생각한다.
예시를 들면 django는 일반 기여자를 양성하는 djangonaut sapce라는 프로그램도 따로 운영한다.

그만큼 오픈소스의 규모가 커질수록 일반 기여자들의 역할은 중요해진다.
그렇기 때문에 오히려 큰 규모의 라이브러리 일 수록 기여에 도전하기 쉬울 수도 있다는걸 의미한다.

최근 커밋 프로필에 마우스를 호버해보면서 작업자가 해당 라이브러리의 멤버인지 일반 기여자인지 확인해보자.
만약 일반 기여자가 많다면 초보 기여자가 진입하기 좋은 신호다.

Feature Freeze 라이브러리 인가요?

기능이 동결된 라이브러리에 기여할 수 있을까?
더 이상 기능개발을 하지않고 간단한 버그나 의존성 업데이트만 이루어지는 라이브러리에서 말이다.
아무래도 기능을 개발하는 라이브러리에 비해 기회가 많지 않다.
필자도 이전에 django-rest-framework의 Composite 권한의 설계와 관련하여 잘못된 부분을 지적한 적이 있다.

메인테이너도 잘못된걸 인정하지만 수정되지 않는다 !
django-rest-framework는 이미 기능동결 상태인 라이브러리이기 때문이다.

그 라이브러리를 좋아하나요?

가장 중요한 포인트이다.
결국 "내가 기여할 라이브러리에 애정이 있는가" 가 가장 중요하다.
필자가 위에 여러 고려할 사항들을 서술했지만 이 사항 하나만으로도 모든 걸 이겨낼 수 있다.
"좋아한다는건" 불가능을 가능하게 만들 수 있는 가장 큰 무기이다.

어떤게 중요할까?

이제 오픈소스 세계에 발을 들일 준비가 다 되었다고 생각된다.
하지만 아직 들어가기 전에 필자가 생각하기에 중요한점 몇가지가 더 있다.
단순히 스킬적으로 더 좋은 해결법을 찾아내는 역량이라기 보다는 오픈소스라는 문화를 잘 이해하고 활용할 줄 아는 능력에서 비롯된다.

인내심

오픈소스는 언제나 긴 숨을 가지는게 중요하다!

작업을 하다보면 언제나 이런 생각이 드는 순간이 온다.

"아.. 내 코드 언제 검토해주는거지?"
"지금쯤이면 병합되어도 문제 없을거 같은데.."

이 생각들로 인해서 마음이 급해져, 작업자 본인이 심리적으로 힘들어지거나 메인테이너들을 재촉하게 되는 실수를 저지른다.

오픈소스에서는 절대 급해지면 안된다 🔥

필자의 첫 오픈소스 기여인 django에서 한 작업은 병합까지 1개월이라는 시간이 걸렸다.

병합까지 1년이 걸린 작업도 있다 !!

만약 내 작업이 이상하게도 진전이 없다면 가장 먼저 해당 라이브러리의 Contribution 가이드라인 문서를 읽어보길 권장한다.
내가 만약 모든 가이드라인을 지켰는데도 불구하고 진전이 되지 않는다면 그땐 메인테이너를 멘션하여 최대한 공손한 태도로 여쭤보자.

검토자를 배려하기

조금 슬플 수 있는 이야기를 먼저하겠다.
작업자 입장에서 검토자는 굉장히 중요하다.
왜냐하면 검토자들이 결국 작업의 진전여부나 방향성을 거의 결정한다.
그래서 조금 잘 보일 필요가 있다 .. 🥲

검토자를 배려하는 태도를 가지자.
검토자도 사람이기 때문에 마음가는 사람들에게 더 끌리기 마련이다.

배려하는 태도라면 어떤것들이 있을까?

1. PR을 제출했을때나 개선점을 제보할때 검토자들이 빠르게 재현해 볼 수 있는 예시를 제공(테스트 코드, 시각적인 변경인 경우 스크린샷)
2. 항상 감사함을 표현하기
3. 커밋을 코멘트별로 분리하고 메시지에 변경사항을 잘 드러내기

굉장히 사소한 부분들이지만 오픈소스외에 어딜가도 적용되는 중요한 포인트들이다.

모르면 물어보기

초보 기여자들에게는 작업을 어떻게 진행해야할지 그리고 방향성을 어떤식으로 잡아야할지 감이 안잡힐 수 있다.
참고로 이건 당연한거다 !
낯선 코드베이스에서 좋은 정답을 찾아내는건 어렵기 때문이다.
이런 부분들에 대해서는 고민하지 말고 메인테이너 분들에게 질문하자.
보통 메인테이너들은 깊은 코드베이스 지식을 갖춘 상태이기 때문에 이미 답을 알고 있을 가능성이 매우 높다.

필자도 처음 기여를 시작했을때나 지금이나 메인테이너 분에게 현재 방향성이나 제안해줄 방향성이 있는지 매번 정중하게 검토요청을 한다.
한 가지 문제를 해결함에 있어서 다른 사람들의 생각/의견을 들을 수 있다는게 오픈소스 세계가 가진 매력이라고 생각된다.
더군다나 그 다른 사람들은 특정 에코시스템에 권위자일 가능성이 높다.

기본 규칙 지키기

오픈소스의 규모가 큰 곳일수록 커밋 컨벤션, PR 템플릿 작성 가이드 처럼 해당 리포지토리만의 규칙이 존재합니다.
참고로 django에서는 이 규칙이 지켜지지 않으면 작업을 검토해주지 않거나 PR이 Auto Closing 됩니다.

그만큼 오픈소스 기여를 시작하기전에 대상 라이브러리의 Contributing 가이드라인을 꼭 읽고 시작하세요!
실제로 이 문서를 읽지 않아서 작업이 지연되는 사람들이 엄청 많습니다 😂
(하지만 작업자 본인은 무엇이 문제인지 모릅니다.)

소프트스킬

"오픈소스에 기여하려면 뛰어난 하드스킬을 가지고 있어야 할까요?"
필자인 저의 개인적인 생각은 아니라고 생각합니다.
오히려 오픈소스에서 뛰어나야할 스킬은 "소프트스킬" 입니다.
이전에도 말했듯이 오픈소스는 함께 작업하는 공간입니다.
그리고 이미 그곳에는 하드스킬이 뛰어난 사람들이 넘치거든요!

필자또한 하드스킬이 정말 좋지 않음에도 가능했던 이유를 생각해보면 "문제를 나 혼자 해결해 나가는게 아닌 함께 해결해 나간다는 태도" 를 가졌었기 때문인거 같습니다.
전세계 다양한 사람들이 참여하는 오픈소스는 나에게 부족한 걸 채울 수 있는 공간이며, 그 부분을 적극적으로 활용할 수록 좋습니다.

결국 오픈소스 세계를 이해하고 활용하는 능력이 정말 중요합니다.
그리고 그걸 활용하는 과정속에는 "소프트스킬" 이 빛을 발합니다.

마지막으로

오픈소스라는 세계를 너무 높이 바라보지 마세요 !
누구에게나 열려있는 공간이며 세계적으로 인정받은 훌륭한 동료들과 함께할 수 있는 공간입니다.
다양한 사람들과 함께할 수 있다는게 오픈소스 세계가 가진 가장 큰 매력 아닐까요 ?
너무 걱정하지 말고.. 지금 당장 뛰어드세요 😁