시간을 낭비하는 부분 없이, 기여가 전혀 없는 상태에서 첫 번째 머지된 PR(Pull Request)까지 가기 위해 알아야 할 모든 것입니다.

첫 오픈 소스 기여를 머지하는 것은 직접 시도해 보기 전까지는 매우 간단해 보이지만, 튜토리얼 버전과 현실 사이의 간극을 발견하게 되는 일 중 하나입니다. 저는 그 간극을 메우고 싶습니다.

이 가이드는 제가 처음 시작했을 때 원했던 가이드입니다. 구체적이고, 무엇이 어려운지에 대해 솔직하며, 이론적으로 좋아 보이는 것보다는 실제로 효과가 있는 것에 집중합니다.

코드 한 줄을 쓰기 전에, 올바른 프로젝트를 선택해야 합니다. 대부분의 첫 기여 시도가 실패하는 이유는 기술적인 문제 때문이 아니라 프로젝트가 잘못되었기 때문입니다. 프로젝트가 너무 크거나, 너무 비활성 상태이거나, 새로운 기여자를 환영하지 않는 경우입니다.

제가 적용할 구체적인 기준은 다음과 같습니다: 프로젝트는 지난 30일 이내에 커밋(Commit)이 있어야 합니다. 최근 활동이 없는 프로젝트는 PR을 적극적으로 검토하지 않는 유지 관리자(Maintainer)가 있다는 뜻이며, 여러분의 기여는 몇 달 동안 검토되지 않은 채 방치될 수 있습니다. 프로젝트에는 "good first issue" 또는 "beginner friendly"라고 라벨(Label)이 붙은 이슈(Issue)가 있어야 합니다. 이 라벨은 유지 관리자가 새로운 기여자가 해결할 수 있는 작업임을 명시적으로 식별했다는 것을 의미합니다. 그리고 프로젝트는 최근의 이슈나 PR에 대해 침묵 이외의 반응을 최소한 몇 번이라도 보여주어야 합니다. 기여자의 질문을 무시하는 프로젝트는 시작하기에 좋은 환경이 아닙니다.

GitHub에서 "good-first-issues" 필터를 사용하여 자신의 기술과 관련된 주제를 검색하세요. 하나를 결정하기 전에 5~6개의 후보 프로젝트를 훑어보세요. 최근 이슈에서 유지 관리자의 답변 톤을 살펴보세요. PR을 거절할 때조차 명확하고 건설적인 피드백을 주는 유지 관리자는 여러분이 배우고 싶어 할 만한 사람입니다.

프로젝트를 찾았다면, 다른 무엇을 건드리기 전에 개발 환경 (Development Environment)을 먼저 설정하세요. README 또는 CONTRIBUTING.md에 있는 설정 지침을 정확히 따르고, 여러분의 환경에서 기존 테스트가 통과하는지 확인하며, 변경 사항을 만들기 시작하기 전에 코드베이스의 기본 구조를 파악하여 각 요소가 어디에 위치하는지 충분히 이해해야 합니다.

이 설정 단계는 느리게 느껴질 수 있습니다. 하지만 그렇지 않습니다. 여기서 소비하는 시간은 첫 기여 (First-contribution)에서 가장 흔히 발생하는 실패 모드, 즉 여러분의 환경이 예상되는 설정과 미세하게 달라서 유지 관리자 (Maintainer)가 재현할 수 없는 PR (Pull Request)을 제출하는 상황을 방지해 줍니다.

기여를 작성할 때 가장 중요한 단 한 가지는, 여러분이 생각하는 것보다 더 작게 만드는 것입니다. 저는 이 말을 거의 예외 없이 강조합니다. 적절한 테스트와 함께 명확하게 한 가지를 변경하는 PR은, 작업하는 동안 개선할 다른 사항들을 발견했다는 이유로 다섯 가지를 한꺼번에 변경하는 PR보다 머지 (Merge)될 확률이 훨씬 더 높습니다.

그 이유는 실무적입니다. 집중된 PR은 유지 관리자가 리뷰하기 더 쉽고, 그 영향력을 추론하기 더 쉬우며, 확신을 가지고 승인하기 더 쉽습니다. 반면 방대한 PR은 유지 관리자가 여러 개의 독립적인 변경 사항을 동시에 고려해야 하고, 이들이 예상치 못한 방식으로 상호작용하지 않는지 확인해야 하며, 여러 개의 별개 사안에 대해 리뷰 코멘트를 작성해야 합니다. 이러한 인지적 부하 (Cognitive overhead)는 유지 관리자가 PR을 분할해 달라고 요청할 가능성을 훨씬 높이며, 이는 더 많은 왕복 과정 (Round-trips)과 더 긴 머지 시간을 의미합니다.

문제를 해결하는 가장 작은 규모의 변경 사항만을 작성하세요. 작업 중에 발견한 다른 개선 사항들은 첫 번째 PR이 머지된 후 별도의 PR로 남겨두세요.

변경 사항에 대한 테스트를 작성하세요. 만약 프로젝트에 테스트가 있다면 — 그리고 진지한 프로젝트라면 반드시 테스트가 있을 것입니다 — 당신의 기여(Contribution)에는 당신이 추가하거나 변경한 동작을 검증하는 테스트가 포함되어야 합니다. 기존 테스트를 살펴보고 프로젝트가 사용하는 테스트 패턴을 이해한 뒤, 그에 맞추세요. 테스트가 존재하는 프로젝트에서 테스트가 없는 PR(Pull Request)을 올리는 것은, 당신이 기여 가이드라인(Contribution guidelines)을 읽지 않았거나, 검증 없이 당신의 변경 사항을 신뢰해 달라고 유지 관리자(Maintainer)에게 요구하는 것과 같습니다. 둘 중 어느 것도 좋은 시작은 아닙니다.

명확한 PR 설명을 작성하세요. 변경 사항이 무엇을 하는지, 왜 필요한지, 그리고 어떻게 테스트했는지를 설명하세요. 해결하려는 이슈(Issue)가 있다면 해당 이슈에 대한 참조를 포함하세요. PR 설명은 유지 관리자와의 소통 수단입니다. 유지 관리자가 추가적인 질문을 던질 필요 없이 당신의 변경 사항을 검토하는 데 필요한 모든 정보를 제공해야 합니다.

리뷰 피드백을 받으면, 신속하고 구체적으로 응답하세요. 리뷰어에게 감사 인사를 전하고, 각 피드백 사항에 대해 직접적으로 답변하며, 요청 사항이 무엇인지 이해되지 않을 때는 명확한 질문을 하세요. 리뷰 프로세스는 대화이며, 유지 관리자들은 방어적인 태도보다는 건설적으로 참여하는 기여자(Contributor)를 높게 평가합니다.

당신의 첫 번째 머지(Merge)된 PR은 이후의 PR들보다 더 오래 걸릴 것입니다. 두 번째는 더 빠를 것입니다. 동일한 프로젝트에 5~6번 정도 기여하고 나면, 유지 관리자가 무엇을 가치 있게 여기는지, 그리고 코드베이스(Codebase)가 어떻게 구조화되어 있는지에 대한 직관이 생겨 이후의 각 기여가 더욱 자연스러워질 것입니다. 이러한 복리 효과는 실재하며, 바로 그 첫 번째 머지로부터 시작됩니다.VISIT