오픈소스 기여는 단순한 자기계발을 넘어 일종의 스펙이 되고 있다. 기업들이 오픈소스 활용/기여 경험이 있는 개발자를 선호한다는 사실이 알려지면서 이력서에 한 줄이라도 새겨넣고 싶어하는 취준생이나 신입 개발자들이 많아졌다.
마음 같아서는 리눅스 커널이라도 뚝딱 만들어내고 싶지만 처음부터 큰 일을 해낼 순 없다. 오늘은 오픈소스 기여에 입문할 수 있는 쉬운 방법을 소개한다.
참고로 나는 다음의 프로젝트에 기여를 한 바 있다.
- Promscale(Prometheus와 postgreSQL을 결합하는 프로젝트)
- Yorkie(CRDT 자료구조를 이용한 분산 데이터 저장소)
- Kubernetes Website(쿠버네티스의 문서를 볼 수 있는 웹사이트)
- memtier_benchmark(redis와 memcached의 벤치마크 도구)
기여를 위한 기여는 비효율적
취준생 시절에는 아무 오픈소스에나 기여를 하려고 눈을 부릅뜨고 찾아다녔다. 운 좋게 기여를 몇 번 하긴 했지만 비효율적이고 무의미한 방식이었다. 오픈소스의 주된 기여 방식은 사용자가 직접 불편한 점을 개선하는 것이다. 해당 프로젝트를 사용하지도 않으면서 기여할 거리를 찾는 것은 아주 어렵다.
기여에 욕심낼만한 유명한 프로젝트일수록 이런 방식은 더욱 어렵다. 이미 개발된 분량이 방대해서 이해하기가 어렵기 때문이다. 기여 자체를 목적으로 하는 방식은 특수한 경우가 아니라면 자제하는 것이 좋다. 특수한 경우에 대해서는 후술하겠다.
입문자를 위한 기여 방법들
이슈 등록
사용자로서 불편함을 느꼈거나 문제점을 발견했을 때 이슈를 등록하는 것도 굉장히 중요한 기여 방식이다. 특히 버그를 발견하였다면 웬만한 코드 기여보다 더 큰일을 해낸 것이다. 발견한 문제점이 꼭 거창할 필요는 없다. 사소한 불편함의 예로 내가 대학생 시절에 khaii 프로젝트에 게시했던 이슈를 보여주겠다.
해당 프로젝트의 빌드 문서에는 리눅스나 맥에서만 정상 작동한다는 언급이 없었다. 당시 사용하던 데스크탑에 Cmake, gcc 등이 있었으므로 빌드를 시도하였으나 자꾸 실패하였다. 이슈를 검색해보니 나처럼 빌드를 실패했던 사람이 또 있었다. 문서를 수정하는 것이 어떻겠냐고 이슈를 올렸고 곧 반영되었다. (지금 생각해보면 직접 수정해서 PR했어도 됐을 것 같다.)
문서 기여
서문에 쓴 쿠버네티스에 기여 내역을 보고 놀란 독자가 있을 것이다. 예상하는대로 구글이 개발하는 대규모 프로젝트에 기여하는 것은 쉽지 않은 일이었다. 다음은 내가 한 PR의 캡처이다.
내 PR은 '는'을 '은'으로 수정하는 것이었다. 가성비 면에서 최고의 기여였다.
유명한 프로젝트이더라도 문서에 오타가 있거나, 한국어 번역이 없는 등 개선할 여지가 있는 경우가 많다. 문서를 찾아보다가 오타나 잘못된 점을 찾는다면 바로 fork해서 수정하자. 코드를 수정했을 때와는 달리 웬만해선 한번에 받아준다. promscale에 한 기여도 마크다운 링크에 오타가 있길래 수정한 것이었다.
쿠버네티스는 아직도 한국어 번역이 되지 않은 문서가 많다. 영어에 어느 정도 자신이 있다면 기여할 거리가 아주 많으니 도전해보자.
유닛 테스트 작성
개발한지 얼마 되지 않은 프로젝트라면 테스트 케이스가 부족한 경우가 있다. 이 중 coveralls와 같은 툴로 테스트 커버리지를 측정하고 있는 프로젝트는 어느 코드가 테스트 되지 않고 있는지 찾기가 매우 쉽다. 만약 그렇지 않다면 커버리지를 측정하기 위한 기여를 하면 된다. 어쨌거나 테스트는 철저할수록 좋기 때문에 이 유형의 PR은 대체로 환영받는다.
'간단한' 리팩토링, 가독성 개선
정적 검사 툴에서 찾아줄만한 간단한 리팩토링 사항을 기여하는 것도 쉬운 방법이다. 주의 사항은 어디까지나 간단해야 한다는 것이다. 추상화 방식을 바꾸는 복잡한 리팩토링은 리뷰하기가 어렵기 때문에 받아들여질 확률이 낮다.
내가 memtier_benchmark 프로젝트에 했던 PR은 잘못 들어간 공백 문자(trailling whitespace)를 지우는 것이었다. 에디터의 찾아 바꾸기 기능을 이용하니 몇 분 걸리지 않았다.
Dockerfile 작성 및 개선
개발한지 얼마되지 않은 프로젝트라면 Dockerfile이 아예 없을수도 있고, multi-stage build 같은 진보된 방식이 적용되지 않았을 수도 있다. 이미 Dockerfile이 잘 작성되었다면 docker-compose 파일은 있는지 살펴보자.
CICD 연동
github action이나 travis CI 같은 도구가 연동되지 않았다면 시도해보자. 프로젝트 전체의 생산성을 끌어올릴 수 있는 기여이다.
빠른 시간 내에 기여할 거리를 찾고 싶다면
위에 소개한 방법들은 오픈소스 프로젝트를 사용하다가 문제점을 발견했을 때 직접 수정해내는 방식이다. 그러나 빠른 시일 내에 목표를 이루고 싶어하는 사람들에게는 다소 답답한 방법이다. 기여를 위한 기여는 비효율적이라고 했지만, 정 하고 싶다면 다음의 방법을 추천한다.
초보자용 이슈 해결
프로젝트마다 'low-haning fruit', 'good first issue'등의 태그를 붙여 초보자용으로 남겨놓는 경우가 있다. 다음의 키워드로 검색해 기여할만한 프로젝트가 있는지 찾아보자.
오픈소스 컨트리뷰션 아카데미(구 컨트리뷰톤) 참여
OpenUP(오픈소스 통합지원센터)에서는 매년 오픈소스 컨트리뷰션 아카데미를 주최한다. 특정 오픈소스 프로젝트에 대해 잘 알고 있는 멘토와 함께 직접 기여를 해보는 행사이다. 우수한 멘토의 도움을 받을 수 있기 때문에 혼자서 기여하는 것보다는 훨씬 쉽다. 2020 컨트리뷰톤이 아니었다면 Yorkie와 같은 어려운 프로젝트에 기여하지는 못했을 것이다. 오픈소스에 기여하고 싶은 개발자에게는 최고의 기회라고 해도 과언이 아니다.
단점이 있다면 경쟁을 거쳐서 선정이 되어야 한다는 것이다. 올해는 다행히 클라우드 바리스타라는 프로젝트에 지원해 선정되었지만 내년에 또 참가할 수 있다는 보장은 없다. 좋은 행사라는 점이 알려지면서 경쟁이 점점 치열해지는 느낌이다.
마치며
오픈소스 기여는 어려운 일이라는 인식이 있다. 그러나 굳이 어려운 싸움을 하지 않는다면 얼마든지 쉬운 길이 있다. 재미면에서도 코딩 테스트나 면접 준비보다는 훨씬 낫다. 오픈소스 기여 경험이 없다면 한번쯤 시도해보는 것을 적극 추천한다.
