오픈소스에서 어떻게 행동하면 안 되는가

Source: Dev.to

카운터에 다가가 매니저를 만나 달라고 요구하고, 레스토랑이 비건 친화적인 옵션을 제공하도록 요구하며, 매니저에게 비건 친화 레시피가 가득한 요리책을 건네고, 거절당한 뒤 레스토랑을 나와 1성 리뷰를 남긴다.

평범한 사람에게는, 당신의 시간, 작업, 예산을 전혀 고려하지 않는 개인의 구체적인 요구를 들어주는 것이 터무니없게 들립니다. 반면에, 평범한 사람은 다른 사람의 시간, 작업, 예산을 고려하지 않습니다.

저 역시 오픈소스 유지보수자로서, 제가 서 있는 어깨 위의 거인들이 하는 힘든 작업을 깊이 이해하게 되었습니다. 이 사람들이 얼마나 많은 일을 하고 있는지 드러내고 싶으며, 여러분이 가능한 한 마찰 없이 이를 인식하고 기여할 수 있도록 돕고 싶습니다.

Who is this article for?

Whether you are getting started in open source, a “vibe coder,” or an opencl*w instance, hopefully this article will do you some good.

This article assumes you have a basic understanding of a version‑control system like git, and that you have some familiarity with a git‑hosting provider such as GitHub or GitLab.

유지보수자를 골칫거리로 만드는 방법

오픈소스 유지보수자에게 절대적인 고통이 되는 몇 가지 방법에 대해 이야기해봅시다.

부작용에는 소셜 미디어에서 나쁜 홍보를 받거나, 프로젝트에서 차단당하거나, 이슈나 풀 리퀘스트가 거절된 뒤에 기분이 상하는 것이 포함될 수 있습니다.

이슈가 거절되는 방법

1. 매우 모호한 버그 리포트를 제출한다

2. 다른 언어 / 프레임워크 / OS 로의 포팅을 요청한다

3. 대규모 기능 요청을 제안한다

4. 트롤링을 목적으로 모호한 PR을 연다

풀 리퀘스트가 거절되는 방법

1. 대규모 기능 구현을 Vibe‑code 하세요

2. README.md에 이름만 추가하는 PR을 열어보세요

Source: …

문명 있는 기여자 되기

이제 하지 말아야 할 일에 대한 전반적인 감을 잡았으니, 오픈소스 유지보수자와 기여자와 보다 원활하게 협업할 수 있는 방법들을 살펴보겠습니다.

일반 예절 (이슈와 풀 리퀘스트 모두 적용)

• 감사를 표현하세요 – 오픈소스 소프트웨어는 무료일 수 있지만, 시간은 그렇지 않습니다. 프로젝트가 여러분에게 중요하거나 도움이 되었다면, 유지보수자에게 감사를 표하세요—그것이 그들을 계속 움직이게 하는 원동력입니다. 여유가 된다면 프로젝트를 후원하는 것도 고려해 보세요.
• 검색하고 읽으세요 – 여러분과 같은 중복 이슈가 있나요? 해결 방법이나 우회책이 있나요? 정확히 같은 문제를 해결한 블로그 글이 있나요? 기존 해결책이나 우회책을 찾는 것이 답변을 기다리는 것보다 더 가치 있습니다.
• 자세히 적으세요 – 가능한 한 많은 정보를 제공하세요. 관련 이슈와 풀 리퀘스트를 교차 참조하세요. 유지보수자가 여러분을 도와주기 쉽게 만드는 것이 중요합니다.

이슈

이슈는 GitHub 그래프에 기여로 표시되는 이유가 있습니다. 이슈를 고객 지원으로 생각하지 말고, 프로젝트에 긍정적으로 기여하는 방법으로 생각하세요.

1. 이슈를 열기 전에, 현실적으로 가능한 엔지니어링 노력의 양을 고려하세요:

   • 활성 유지보수자는 몇 명인가요?
   • 프로젝트 소유자는 마지막으로 언제 활동했나요?
   • 이미 열려 있는 이슈는 얼마나 있나요?

2. 불필요한 부하를 만들지 마세요 – 여러분의 이슈가 해결되면 실제로 해결책을 제공하나요, 아니면 더 많은 문제와 부하를 초래하나요? 예를 들어, macOS 전용 애플리케이션에 Windows 지원을 요청하면 또 다른 도전 과제가 생깁니다.

3. 영향을 추정하세요 – 여러분의 이슈가 해결되면 사용자 기반의 상당 부분에 도움이 되나요, 아니면 아주 틈새적인 경우인가요?

풀 리퀘스트

1. 기여 가이드라인을 읽으세요 – 대부분의 프로젝트에는 CONTRIBUTING.md 파일이 있어 선호하는 워크플로, 코딩 스타일, 테스트 요구사항 등을 명시하고 있습니다.

2. 작게 시작하세요 – 잘 다듬어지고 집중된 PR이 거대한 “모든 것과 부엌 싱크까지” 변경보다 병합될 확률이 훨씬 높습니다.

3. 명확한 커밋 메시지를 작성하세요 – 무엇이 바뀌었고 왜 바뀌었는지 설명하세요.

4. 테스트를 추가하세요 – 프로젝트에 테스트 스위트가 있다면, 변경 사항을 커버하도록 테스트를 추가하거나 업데이트하세요.

5. 반응을 빠르게 – 유지보수자가 변경을 요청하면, 신속하고 정중하게 대응하세요.

TL;DR

• 고통을 주지 말라: 모호한 보고, 대규모 원치 않는 기능, 자기 홍보 PR을 피하세요.
• 시민 의식을 갖자: 감사 표시, 사전 조사, 철저함, 유지보수자의 시간을 존중하세요.
• 신중하게 기여하라: 작고 문서화된 변경과 충분히 조사된 이슈가 오픈소스 생태계를 모두에게 더 건강하게 만듭니다.

큰 영향

이 문제가 대부분의 소비자에게 영향을 미치고 있나요, 아니면 귀하에게만 매우 구체적인가요?
다음 버전이 출시될 때까지 몇 달을 기다리는 것보다, 워크어라운드, 저장소 포크, 혹은 의존성 패치를 적용하는 것이 더 효과적일지 고려해 보세요.

풀 리퀘스트 (모범 사례)

풀 리퀘스트를 열 때는 프로젝트에서 지정한 스타일 가이드와 규칙을 가능한 한 최대한 따르도록 노력하세요.

• 깨끗한 커밋 히스토리 유지 – 커밋을 스쿼시하고, 설명을 달고, 순서를 재배열하고, 리베이스하는 방법을 배우는 데 약 30분 정도 투자하세요.

  • 변경 사항을 작고 매우 상세한 커밋으로 나누고, 관련 이슈와 풀 리퀘스트를 교차 참조하세요.
  • 무엇을 하는지뿐만 아니라 왜 변경하는지를 설명하세요.

• 자동화 테스트 – 프로젝트에 테스트 환경이 있다면, 올바른 동작을 보장하기 위해 단위/통합 테스트를 작성하세요.

유지보수자로서

프로젝트 유지보수자 또는 소유자는 일련의 책임을 가지고 있습니다. 사람들이 사용할 수 있는 신뢰할 수 있는 소프트웨어를 만들고 싶다면, 그 상태를 유지하기 위해 시간과 노력을 투자해야 합니다.

• 기여 수락 – 테스트와 철저한 검토 없이 외부 기여를 무작정 받아들이지 마세요.

• 투명하게 – 기여를 수락, 거절, 혹은 코멘트할 때 왜 그런 결정을 내렸는지 설명하세요.

• 조직적으로 – 이슈, pull request, 커밋을 체계적으로 관리하세요.

  • 변경 사항을 PR과 커밋으로 나누고, 상세히 설명합니다.
  • 이슈와 pull request를 서로 참조합니다.
  • 실제로 완료되지 않은 이슈를 “완료”라고 닫지 마세요.

• “친절함”이 초점이 아닙니다 – 충분히 자세히 설명한다면 직설적인 표현도 괜찮습니다.

  • 모든 기여를 받아들일 것처럼 보이게 하지 마세요.
  • 기여를 거절하면 감정이 상할 수 있지만, 프로젝트에는 해가 되지 않습니다. “아니오”라고 말하는 것은 괜찮습니다.

• 필요할 때 작업을 위임 – OSS는 보통 생계를 유지해 주지 않으므로, 프로젝트에 전념하기 어려울 수 있습니다.

  • 과거 기여자나 이슈를 연 사람이 관심을 보이면, 나중에 검토할 PR을 제출하도록 요청하세요.

• 아카이빙 – 개인적인 사유로 더 이상 오픈소스 프로젝트를 진행할 수 없게 되면, 개발이 중단되었음을 알리기 위해 프로젝트를 아카이브하세요.

결론

이 글은 오픈‑소스 기여자와 유지보수자가 된다는 것이 무엇인지에 대해 표면만 살짝 긁어본 것입니다.

만약 이 글에서 얻은 것이 있다면, 시간을 내어 적용해 보시고 오픈‑소스 기여자와 유지보수자의 삶을 더 쉽게 만들어 주세요.

우리는 모두 함께 이 일을 하고 있습니다. 부담을 나눠 가집시다.