오픈소스 프로젝트, 어떻게 기여하나요?

애플리케이션을 개발하다 보면 필요한 기능이 구현된 오픈소스 라이브러리를 사용하는 경우가 많습니다. 하지만, 일반적인 경우 릴리즈 되어 있는 그대로 사용하기만 하는 경우가 많죠.

그런데, 만약 라이브러리에 버그가 있어 수정이 필요하거나 혹은 더 나은 형태로 개선을 하고 싶다면 어떻게 해야 할까요? 이 글에서는 단순 사용자를 벗어나, 오픈소스 프로젝트 기여자(Contributor)가 되는 방법에 대해 알아봅니다.

기여할 프로젝트는 어떻게 찾아야 할까?

이 세상에 공개되어 있는 오픈소스 프로젝트는 그 수가 많을 뿐 아니라 규모, 언어, 플랫폼, 라이선스, 프로젝트가 추구하는 방향 등 다양한 특징을 가지고 있습니다.

기여할 프로젝트를 선택하는 기준은 여러 가지가 있겠지만, 가급적이면 자신이 현재 사용하고 있는 라이브러리 중 하나를 선택하는 것이 가장 좋습니다.

라이브러리를 직접 실무 또는 개인 프로젝트에 적용해 보아야만 개선이 필요한 부분을 찾기도 쉽고, 쉽게 해결할 수 있는 버그를 찾기에도 용이하기 때문입니다.

버그나 아쉬운 점은 내가 혼자 고쳐 쓰면 되지 않나요?

어느 프로젝트가 되었던 간에 버그나 개선이 필요한 점이 있기 마련입니다. 버그의 경우 일부 코드를 추가하여 해당 문제를 회피하기도 하고, 개선이 필요한 경우 해당 라이브러리의 코드를 모두 가져와 직접 수정 후 빌드하여 사용하기도 합니다.

라이브러리를 수정하여 사용하는 경우, 오픈소스 라이브러리에 따라 다르지만 특별한 제약이 없는 경우가 많습니다. 하지만, 이러한 수정사항을 자신이 사용하는 프로젝트에만 적용한다면 이는 ‘오픈소스’를 ‘닫힌 소스(Closed source)’로 만들어버리는 꼴이 됩니다.

그렇다면, 왜 기여해야 하나요?

오픈소스 프로젝트에 기여하면 다음과 같은 장점을 누릴 수 있습니다.

다른 사람의 노하우 습득

오픈소스 프로젝트에 기여하기 위해선 필연적으로 다른 사람의 코드를 많이 봐야 합니다.

이를 통해 자연스레 다른 사람의 노하우나 코딩 스타일을 접할 수 있으며, 이를 통해 자신의 코드 스타일을 만들어 가는 데에도 큰 도움이 됩니다.

임시 방편이 아닌 근본적인 해결책을 찾는 습관 체득

버그가 있어 라이브러리를 수정해야 하는 경우, 자신만 사용할 라이브러리라면 임시방편을 통해 특정 경우만 피할 수 있는 코드를 짜기 쉽습니다.

하지만, 오픈소스 프로젝트로 진행되는 라이브러리에 기여하는 경우 각종 경우를 모두 대비할 수 있어야 하기 때문에 더 탄탄한 코드를 작성하는 습관을 갖출 수 있습니다.

커뮤니케이션 능력 향상

기여 활동을 제대로 하려면, 특정 문제에 대한 상세한 정보나 개선점에 대해 프로젝트 소유자나 기여자들과 함께 토론해야 합니다.

이를 통해 여러 사람과 협업하는 프로젝트에서 어떤 방법으로 대화를 해야 하는지, 어떤 내용들이 오고가는지 알 수 있으므로 추후 실무에서 팀 내 개발자들과 의견을 조율할 때에도 큰 도움이 됩니다.

추가로, 대부분의 오픈소스 프로젝트 내 의사소통이 영어로 이루어지므로 의도치 않은(?!) 영어 능력의 향상을 기대할 수도 있습니다.

오픈 소스 프로젝트의 개발 흐름

일반적으로 대부분의 오픈소스 프로젝트는 크게 다음과 같은 흐름으로 개발이 진행됩니다.

각 항목에 대해 조금 더 상세히 알아보겠습니다.

Issue

버그 및 개선사항을 제보하는 단계입니다. 이슈의 유형에 따라 작성하는 내용이 다르지만, 상세하게 적을 수록 좋습니다.

• 버그 리포팅: 자세한 증상 및 재현 조건에 대해 기술합니다.
• 기능 개선 요청: 개선되었으면 하는 기능에 대해 기술합니다. 프로젝트가 지향하는 목표에 따라 개선 방향은 달라질 수 있습니다.

PR (Pull Request)

버그나 기능개선이 적용된 코드를 프로젝트 코드에 반영 요청하는 단계입니다. 기능 개선의 경우 이슈 단계에서 충분한 논의를 거쳐 개선 방향에 대해 합의한 후 PR을 제출하는 것이 좋습니다.

Github이 아닌 다른 리뷰 시스템(예: Gerrit)에서는 이를 Change라 부르기도 합니다.

Check

제출한 PR에 문제가 없는지 검사하는 단계입니다.

보통 CI 서버를 통해 PR 제출시 자동으로 수행되며, 일반적으로 다음과 같은 항목을 검사합니다.

• 테스트 (유닛 테스트 등) 통과 여부
• 테스트 커버리지 변화
• 코드 스타일 준수 여부

Review & Feedback

제출한 변경사항을 해당 프로젝트 담당자가 직접 검토하는 단계입니다.

Check 단계에서는 코드에 대한 기계적인 검증을 수행했다면, 이 단계에서는 제출한 변경사항의 구현 방법에 대해 검토합니다.

프로젝트 담당자는 이 단계에서 제출한 코드에 대한 수정을 요청할 수 있으며, 토론을 통해 변경이 필요한 부분이나 방법에 대해 논의가 이루어집니다.

변경이 필요한 경우, 코드 수정 후 수정사항을 다시 커밋하면 Check 단계를 거쳐 다시 리뷰 단계로 진행됩니다.

Merge

리뷰가 완료된 변경사항 중 원 코드에 반영하기로 결정된 변경사항은 프로젝트 담당자에 의해 원 코드에 합쳐집니다.

일반적으로 master 브랜치에 이를 반영하며, 반영된 코드가 릴리즈되는 시점은 프로젝트에 따라 다릅니다.

환영 받는 기여자가 되려면?

앞에서는 오픈 소스 프로젝트에 기여하는 방법과 진행 절차에 대해 알아보았습니다. 그렇다면, 환영 받는 기여자가 되려면 어떻게 해야 할까요?

해야 할 것

프로젝트 가이드라인 준수

프로젝트에서 지켜야 하는 코드 스타일, 혹은 기여시 지켜 주었으면 하는 절차가 있다면 꼭 준수하세요. 가이드라인은 프로젝트 저장소 내 README 혹은 CONTRIBUTING 파일 내에 주로 기재되어 있습니다.

원 코드의 스타일 준수

프로젝트 가이드라인이 따로 정해져 있지 않다면, 일관성을 유지하기 위해 가급적 원 코드에 작성된 스타일에 맞춰 코드를 작성하세요. (인덴트, 변수 네이밍 등)

사소한 것 부터 시작하자

프로젝트 가이드 문서나 소스 코드 내 문서의 사소한 오타를 발견했다면, 망설이지 말고 수정 요청을 보내보세요.

오픈소스 프로젝트에 참여할 수 있는 가장 쉬운 방법입니다. :)

이슈는 언제나 자세하게

이슈는 자세히 작성할 수록 좋습니다. 코드를 잘 짜는 것도 중요하지만 여러 사람과 협업이 필요한 만큼 무엇이 문제인지, 이를 해결하기 위해 어떤 것을 고민했는지 등을 함께 적어 주면 이를 리뷰하는 다른 사람에게도 큰 도움이 됩니다.

더불어, 핵심 사항은 맨 앞에 간략하게 적고 자세한 내용은 뒤에 보충하여 적는 형태가 좋습니다.

하지 말아야 할 것

내 스타일대로 코드 짜기

오픈소스 프로젝트는 여러 사람이 함께 작업하는 만큼, 코드의 일관성 유지가 중요합니다. 그러므로 코드의 일관성을 해치는 일을 해선 안 됩니다.

무리한 요청

내가 겪고 있는 문제가 빨리 수정되었으면 하는 마음은 누구나 같습니다. 프로젝트 담당자에게 무리하게 빨리 문제를 해결해 달라고 요청하거나, 특정 문제가 해결된 버전을 빨리 배포해달라고 하는 일은 하지 않아야 합니다.

또한, 개선사항이 포함된 PR은 프로젝트 담당자와 사전에 충분한 논의를 거친 후 제출하는 것이 좋습니다. 프로젝트 담당자가 생각하는 방향과 기여자가 생각하는 방향이 다른 경우 충돌이 발생할 여지가 있기 떄문입니다.

모호하게 이슈 등록하기

버그 리포팅을 하는 경우 최대한 자세하게 내가 겪고 있는 증상을 기록해야 합니다.

자세하지 않은 버그 리포트 (예: 사진이 안 나와요)는 문제 해결에 큰 도움을 주지 않을 뿐 아니라 문제 해결에 소요되는 시간을 증가시킵니다.

새로운 개발자는 언제나 환영이야!

이것으로 오픈소스 프로젝트에 기여하는 방법에 대해 알아보았습니다.

‘내가 과연 프로젝트에 기여할 수 있는 실력이 될까?’ 하며 망설이는 분들도 많겠지만, 오픈소스 커뮤니티는 그리 야박하지 않습니다. :)

앞에서 안내한 절차를 숙지하고, 몇 가지 지켜야 할 사항만 지킨다면 자신도 모르는 사이에 어느덧 오픈소스 커뮤니티의 일원이 되어 있는 자신을 발견할 수 있을 것입니다.

버그 리포트 및 PR의 실제 예가 궁금하신 분들은 다음 링크를 참고하셔도 좋습니다.

• 버그 리포트: fresco#840
• PR: fresco#1461