난 cocos2d-x, fingerprintjs2, create-react-app에 기여했었고, 오픈소스에 기여해보며 오픈소스에 기여하기 위해서 유의해야 할 점이 무엇이 있는지 여러 생각을 하게 되었다. 내 생각이 절대적인 정답은 될 수 없지만 오픈소스를 기여는 하고 싶지만 앞으로 어떻게 해야할 지 잘 감이 안잡히는 사람에게 도움이 되었으면 하는 글이다.
이 글은 구체적으로 PR을 날리는 방법이나, Issue를 올리는 법, git을 다루는 법에 대해 나와있지 않다. 전체적인 오픈소스 기여 과정에 있어서 어떤 것들을 유의해야 할지 가이드하는 글이다.
오픈소스란?
위키에 따르면 오픈 소스는 소프트웨어 혹은 하드웨어의 제작자의 권리를 지키면서 원시 코드를 누구나 열람할 수 있도록 한 소프트웨어 혹은 오픈 소스 라이선스에 준하는 모든 통칭을 일컫는다고 한다.
대표적인 오픈소스 프로젝트로는 리눅스(Linux)가 있고, 오픈소스의 주 원격저장소는 github이나 bitbucket 등이 있다.
오픈소스 기여의 과정과 가이드
오픈소스를 기여하기 위해서는 다음의 과정을 거친다.
1. 기여하고자 하는 오픈소스를 선정한다.
오픈소스에 기여하는 가장 쉬운 방법은 자신이 하고 있는 프로젝트에서 오픈소스를 응용해보는 것이다. 프로젝트를 하다보면 오픈소스에 있지 않은 기능을 필요로 하거나, 숨은 버그들을 자연스레 발견하게 된다. 그 중에서도 django나 linux 같은 오랜 기간 이미 많은 사람들의 리뷰를 거친 프로젝트들은 진입장벽이 높다. 최신 프로젝트이면서 규모가 적당히 큰 프로젝트가 초반에 기여하기에 가장 적합한 오픈소스라 생각한다.(너무 큰 규모의 프로젝트는 전체적인 흐름을 파악하기가 쉽지 않고, 너무 작은 규모의 프로젝트는 허점을 찾기가 쉽지 않다.) 기여하려는 오픈소스가 가장 최근에 커밋한 이력이 6개월 이상이 되었을 경우에는 프로젝트가 유지되지 않고 있을 가능성이 커서, 오픈소스를 수정해 Pull Request(이하 PR)를 날리더라도 응답이 없을 수 있다. 따라서 최근에 활발히 진행되고 있는 프로젝트를 선정하는 것이 좋다.
2. 기여하고자 하는 오픈소스에 대한 분석과 이해를 한다.
사람마다 성향이 다를 수 있지만, 나는 전반적인 큰 그림을 먼저 그리고 필요한 부분을 집중적으로 분석하는 것을 선호한다. 전반적인 그림을 그리는 과정에서 오픈소스의 코드 스타일을 파악할 수 있고, 미처 보지 못한 부분에 새로운 내용이 들어가는 것이 더 적절할 수도 있기 때문이다. 나는 전체 과정 중 분석하는 과정에서 가장 많은 것을 배운다고 생각한다. 읽기 쉬운 코드는 어떻게 작성해야 하고 같은 기능을 어떻게 더 효율적으로 쨜 수 있는지 그 코드 스타일을 익히다 보면 자연스레 좋은 코드를 작성하는 습관이 생긴다. 전 세계에서 많은 사람들이 정성스레 다듬어 놓은 코드를 내 것으로 만드는 것은 많은 배움이 된다.
3. 분산 버전 관리 시스템(git, svn 등)과 원격 저장소(github, bitbucket 등)에 대해 이해한다.
오픈소스에 기여하기 위해서는 자신의 로컬 저장소에 fork한 후 branch를 따고 소스코드를 변경해 PR을 날리는 것이 일반적이다. 이 과정을 이해하기 위해서는 기여할 오픈소스의 분산버전관리 시스템(git, svn 등)을 알아야 기여할 수 있게된다.
4. 오픈소스에 대한 결함/새로운 feature를 발견한다.
결함을 발견하기 위해 오픈소스를 찾는 것보다 오픈소스를 적극적으로 사용해보는 것이 결함을 찾는 것이 좋다고 느껴졌다. 오픈소스를 사용해보지 않고 어떻게든 기여하는 것이 목적이라면, 해당 저장소의 Issue에 올라온 것들을 살펴보자. 도움을 필요로 하는 많은 이슈들이 나와있고, 이슈를 해결할 수 있도록 소스코드를 변경해 PR을 날리면 된다. 새로운 feature를 만들었을 경우 이에 대응하는 테스트 코드를 작성해야 한다.
5. Issue를 등록한다.
PR을 바로 날리는 경우도 있지만, 대개 Issue를 먼저 등록하고 그 Issue를 해결하는 PR을 날리는 것이 일반적이다. 문제를 인식만 하고 해결하는 방법을 잘 모르겠을 경우 Issue만 등록하기도 한다.
6. PR(Pull Request)을 날린다.
PR은 내가 변경한 내용 혹은 Issue를 해결한 내용을 실제 코드에 반영해달라는 요청이다. PR에는 요청을 날린 사람이 변경한 코드와 그 코드를 설명하는 코멘트가 포함된다. 코어 개발자는 PR을 보며 코드의 컨벤션, 목적, 프로그램이 오작동 하는지(이는 보통 CI로 자동화한다) 등을 보고 해당 PR에 코멘트를 남겨준다. 코멘트를 통해 대화를 하며 더 나은 코드로 점차 변경하게 된다.
7. 오픈소스에 변경된 내용이 반영된다.
코멘트에 따라서 다시 소스코드를 변경하고 PR을 날리게 되면 코어 개발자가 실제 오픈소스에 반영(Merged) 하거나 거절(Closed) 한다. PR이 Merged가 되었을 경우 contributor의 목록에 이름을 올리게 된다.
그림. 상단 두 줄이 PR이 Merge된 상태이고, 하단 두 줄이 PR이 Close된 상태이다.
결론
이런 과정을 거친다는 의미는 오픈소스에 기여하게 되면 위의 과정들을 거쳐서 프로젝트를 했다는 것을 증명할 수 있다는 것이다. 이 말은 즉, 적어도 기여한 부분에 대해서 완전히 이해하고 있고, 큰 프로젝트를 분석할 수 있는 능력과 올바르게 수정할 수 있는 능력이 된다는 것을 증명할 수 있다. 또한 git과 github을 능숙하게 다룬다는 것을 의미하기도 하며, 프로젝트에서 요구하는 컨벤션을 알맞게 따를 수 있다는 것이기도 하다. 따라서 많은 기업에서는 오픈소스에 기여했을 시 가산점을 부여하는 경우가 많아서, 기여하는 것 자체가 좋은 이력으로 남는다. 하지만 그만큼 어려운 방법이기도 하니 성급하게 하지 않고 천천히 하는 것이 좋을 것이라 생각한다.