오픈소스 프로젝트 공개하기

오픈소스 프로젝트를 공개하고 운영하는 것은 단순히 소스 코드만을 공개하는 것에 그치지 않고, 같은 문제로 고민하고 있는 외부 개발자들과 소통하고 더 나은 소프트웨어를 만들기 위해 노력하는 모든 활동을 의미합니다.

오픈소스 프로젝트를 공개할 때 알아 두어야 할 내용을 살펴보겠습니다.

이 글은 "Starting an Open Source Project"와 "The Legal Side of Open Source"의 내용을 기반으로 작성되었습니다.

오픈소스로 프로젝트를 공개하는 이유

개인이나 기업이 프로젝트를 오픈소스로 공개하고 운영하는 데는 여러 가지 이유가 있습니다.

원래 사용하던 오픈소스의 새로운 버전을 시작하거나 중단된 운영을 이어가기 위해

오픈소스를 사용하다가 필요한 기능을 직접 추가했을 때 보통 새로 만든 기능을 프로젝트에도 반영하고 싶어 합니다. 하지만 추가한 내용이 유용해도 커뮤니티의 비전이나 프로젝트의 작업 우선순위에 따라 컨트리뷰션이 받아들여지지 않을 수 있습니다. 이런 경우에 원래의 오픈소스를 포크(fork)해서 직접 새로운 기능을 추가하고 별도의 프로젝트로 운영할 수 있습니다.

또는 사용하고 있던 오픈소스의 운영이 중단되어 해당 프로젝트를 포크한 다음 운영을 이어갈 수도 있습니다.

네이버의 billboard.js 프로젝트는 차트 라이브러리인 C3 프로젝트를 포크해서 운영하는 프로젝트입니다.

오픈소스 라이선스 의무를 지키기 위해

GPL(GNU General Public License)이나 AGPL(Affero General Public License), MPL(Mozilla Public License) 등의 라이선스로 배포되는 오픈소스를 사용하면 라이선스 조항에 따라 산출물로 나온 소프트웨어의 소스 코드를 공개해야 할 때도 있습니다.

Xiaomi kernel 프로젝트는 GPL 의무 조항을 준수하기 위해 공개한 Xiaomi의 커널 코드입니다.

더 나은 소프트웨어로 성장하기 위해

누구나 개발에 참여할 수 있도록 프로젝트를 공개하면 외부 개발자들과 함께 문제를 공유하고 해결할 수 있습니다. 소스 코드에 대한 컨트리뷰션 외에도 다양한 테스트 환경과 오류 신고 등으로 소프트웨어의 품질을 높일 수 있습니다.

대규모 분산 시스템용 APM(Application Performance Monitoring) 도구인 Pinpoint는 네이버 내에서 사용하던 버전을 공개한 이후 외부 개발자들의 컨트리뷰션을 받으며 글로벌 오픈소스로 성장해나가고 있습니다.

사회 공헌을 위해

일반적으로 서비스나 제품에 필요한 소프트웨어를 만들기 위해서는 오픈소스 기술이 반드시 필요합니다. 이렇게 오픈소스 생태계에서 얻은 혜택을 다시 오픈소스 생태계에 돌려주기 위해 오픈소스를 운영하는 경우도 있습니다.

네이버도 이런 이유로 내부에서 개발한 다양한 도구를 오픈소스 프로젝트로 공개해서 운영하고 있습니다.

오픈소스 공개를 위한 준비

프로젝트가 어떤 단계이든 다른 사람들의 피드백을 받을 준비가 되어 있다면 오픈소스로 공개할 수 있습니다. 아직 아이디어를 구상하는 단계의 프로젝트일 수도 있고, 이미 실제 제품에 적용된 소프트웨어일 수도 있습니다.

단, 소스 코드의 완성도와 관계없이 프로젝트를 오픈소스로 공개할 때에는 최소한 다음 2개의 문서를 갖추고 있어야 합니다.

• README 문서: 프로젝트의 목적과 사용법을 설명하는 문서입니다.
• LICENSE 문서: 프로젝트의 사용 범위와 조건을 명시한 문서입니다.

이 문서는 다른 사람들이 프로젝트를 잘 이해하고, 적절하게 사용하며, 컨트리뷰션을 하는 데 도움을 줍니다. 또한 메인테이너의 부담을 덜어 프로젝트를 보다 원활하게 운영할 수 있게 해 줍니다.

만약 GitHub에서 오픈소스를 운영한다면 README 문서와 LICENSE 문서를 최상위 디렉터리에 생성하세요. GitHub에서 자동으로 이 파일들을 인식해 사용자에게 보여 줍니다.

• GitHub에서 README 문서를 만드는 방법은 "Commit your first change"에서 확인할 수 있습니다.
• GitHub에서 라이선스를 선택하고 적용하는 방법은 "Licensing a repository"에서 확인할 수 있습니다.

라이선스 선택

오픈소스 라이선스는 소스 코드를 사용하기 위한 조건과 사용 가능한 범위를 명시합니다. 이를 통해 다른 사람들이 프로젝트 운영자에게 일일이 허가를 받지 않고 오픈소스 프로젝트를 사용, 복사, 수정, 재배포할 수 있게 합니다.

따라서 오픈소스 프로젝트를 공개할 때에는 항상 라이선스가 포함되어 있어야 합니다.

다행히 표준화된 오픈소스 라이선스가 있어 라이선스 본문을 저장소에 복사해서 붙여 넣는 것만으로도 라이선스 고지를 할 수 있습니다. 쉽고 간단하게 미래에 발생할 수 있는 불필요한 법적인 문제가 방지됩니다.

오픈소스 라이선스에 관해서는 "오픈소스 바르게 사용하기"의 '오픈소스 라이선스'에서 자세하게 설명하고 있습니다.

프로젝트 의존성 확인

프로젝트를 어떤 라이선스로 배포할지 선택할 때에는 우선 프로젝트에 포함된 다른 오픈소스 프로젝트들의 라이선스를 확인해야 합니다.

만약 프로젝트에 포함된 라이브러리의 라이선스가 모두 'permissive 라이선스'(라이선스 승계 조건 없이 사용, 수정, 공유가 가능하다고 허용한 라이선스)라면 제약없이 원하는 라이선스를 사용할 수 있습니다. 보편적인 permissive 라이선스에는 MIT 라이선스, Apache 2.0 라이선스, ISC 라이선스, BSD 라이선스등이 있습니다.

반면에 라이브러리 중 하나라도 'copyleft 라이선스'(동일한 라이선스로 재배포하는 조건 하에 사용, 수정, 공유가 가능하다고 허용한 라이선스)라면 그 라이브러리와 동일한 라이선스로 프로젝트를 배포해야 합니다. copyleft 라이선스로 배포되는 소스 코드를 사용할 때는 라이선스 승계 의무를 준수해야 하기 때문입니다. 잘 알려진 copyleft 라이선스에는 GNU GPLv2, GNU GPLv3, GNU AGPLv3 등이 있습니다.

프로젝트에 적합한 라이선스 고르기

프로젝트 내부에 사용된 라이브러리 확인이 끝나고 특별한 제약 사항이 없다면 프로젝트의 목적이나 프로젝트를 주로 사용할 커뮤니티의 성격을 고려해 배포 라이선스를 결정할 수도 있습니다.

오픈소스가 다른 프로젝트에서 사용되기를 바란다면 오픈소스와 관련된 커뮤니티에서 선호하거나 유사한 오픈소스가 가장 많이 사용하는 라이선스를 채택하는 것이 좋습니다. 예를 들어 npm 라이브러리에서 가장 많이 사용하는 라이선스는 MIT 라이선스이므로, Node.js 프로젝트를 공개한다면 MIT 라이선스를 채택하는 것이 일반적입니다.

오픈소스를 기업이 사용하기를 바란다면 특허에 관한 내용이 포함되어 있는 라이선스를 채택하는 것이 좋습니다. 기업은 특허에 대해 불명확한 오픈소스를 꺼려할 가능성이 높기 때문입니다. 이때는 Apache 2.0 라이선스가 적합할 것입니다.

오픈소스의 커뮤니티가 기여한 내용이 계속 공개되기를 원한다면 GNU GPLv3 또는 GNU AGPLv3을 추천합니다.

만약 아무것도 고려할 내용이 없다면 MIT 라이선스로 시작하는 것이 가장 간단합니다. MIT 라이선스는 간결해서 이해하기 쉽고, 저작권 고지를 포함한 라이선스만 유지한다면 누구나 사용할 수 있기 때문입니다.

README 문서 작성

README 문서는 다른 사람들이 프로젝트를 발견했을 때 제일 처음 접하는 문서입니다. 대부분의 사용자는 README 문서를 읽는 것만으로 이 프로젝트를 좀 더 탐색할지, 다른 프로젝트를 찾아볼지 결정합니다. 그렇기 때문에 README 문서 작성은 오픈소스 공개를 준비하는 데 있어서 매우 중요한 과정입니다.

README 문서를 작성할 때 특별히 준수해야 하는 규칙은 없지만 사용자의 이해를 돕기 위해 다음과 같은 내용은 필수로 포함하는 것이 좋습니다.

• 프로젝트의 목적 및 용도: 프로젝트에 대해 간단하게 설명하는 내용을 포함합니다.
  • 이 프로젝트는 무엇을 위한 것인가?
  • 어떤 문제를 해결할 수 있는가?
  • 왜 이 프로젝트가 유용한가?
  • 어떤 사람들이 이 프로젝트를 사용하면 좋은가?
  • 이 프로젝트는 어떻게 작동하는가?
• 프로젝트를 시작하는 방법: 프로젝트를 처음 사용하기 위해 필요한 내용을 포함합니다.
  • 프로젝트를 설치, 사용하기 위해 필요한 전제조건이 있는가?
  • 어떻게 설치, 사용, 테스트하는가?
  • 설치 가이드 문서는 어디에 있는가?
• 저작권, 라이선스 정보: 프로젝트의 사용 범위 및 조건을 설명하는 내용을 포함합니다.
  • 어떤 라이선스로 배포되는가?
  • 상세한 라이선스 정보는 어디에서 확인할 수 있는가?
  • 프로젝트를 사용함에 있어 제약 조건이 있는가(특허, 상업적 사용)?
• 외부 리소스 정보: 프로젝트 내에 포함된 외부의 코드나 리소스의 정보를 포함합니다.
  • 각각의 출처 및 배포 라이선스는 무엇인가?

이러한 질문 이외에도 컨트리뷰션 진행 방법이나 버그 신고 방법, 사용자 질문을 올리는 방법 등에 대한 정보를 포함할 수도 있습니다.

아직 프로젝트의 완성도가 낮다고 생각하거나 외부의 컨트리뷰션을 받고 싶지 않다는 이유로 README 문서를 포함하지 않는 경우가 있는데, README 문서를 통해 사용자들에게 이런 의도를 안내하면 좀 더 편하게 프로젝트를 운영할 수 있습니다.

최근에는 전 세계를 대상으로 오픈소스 프로젝트를 공개하면서 다양한 언어로 README 문서를 제공하기도 합니다. 만약 외국어로 README 문서를 작성할 수 있는 시간이 부족하다면, 오픈소스로 공개한 이후에 다른 언어로 번역하는 도움이 필요하다고 알려서 외부로부터 컨트리뷰션을 받을 수도 있습니다.

"컨트리뷰션 시작하기"의 '컨트리뷰션의 유형'에서 소개한 웨일 확장앱 프로젝트의 README 문서 사례가 영어로 된 README 문서를 한국어로 번역하는 도움을 받은 사례입니다.

프로젝트 이름 정하기

오픈소스의 이름은 다른 사람들이 기억하기 쉽고 프로젝트의 내용을 나타낼 수 있어야 합니다.

명확한 이름 붙이기

만약 기존 오픈소스를 기반으로 하는 프로젝트라면 기존 오픈소스의 이름을 앞이나 뒤에 붙여서 좀 더 명확한 이름을 만들 수도 있습니다. 예를 들어 Node.js에 window.fetch API를 추가한 오픈소스 프로젝트의 이름은 'node-fetch'입니다.

재미있는 이름을 붙일 수도 있지만 그런 이름은 다른 문화권의 사용자 또는 비슷한 경험이 없는 사용자에게는 의미가 제대로 전달되지 않을 수 있음을 명심해야 합니다.

충돌하는 이름 피하기

비슷한 이름을 가진 오픈소스가 있는지 확인해야 합니다. 특히 개발 언어나 생태계가 동일한 오픈소스에서 비슷한 이름이 있는지 확인해야 합니다. 만약 기존의 유명한 오픈소스와 같은 이름을 사용한다면 사용자가 혼란스러워하거나 새로운 오픈소스가 제대로 노출되지 않을 수 있습니다.

또한 프로젝트 이름이 기존 제품의 상표권을 침해하지 않는지도 확인해야 합니다. 나중에 기업에서 오픈소스의 이름을 바꾸거나 프로젝트를 삭제하라고 요구하지 않도록 미리 확인하는 것이 좋습니다.

Google에서 프로젝트 이름을 검색해서 다른 사람들이 쉽게 프로젝트를 찾을 수 있는지, 검색 결과에 미처 고려하지 못한 결과가 함께 노출되는지도 확인하기를 권장합니다.

공개 전 마지막 확인

오픈소스로 프로젝트를 공개할 준비가 모두 끝났다면 다음 항목들을 한 번 더 확인해 봅시다. 모두 확인했다면 이제 프로젝트를 오픈소스로 공개하고 다른 사람들의 피드백을 받을 수 있습니다.

문서화

• 프로젝트의 목적과 사용 방법을 설명한 README 문서를 작성했다.
• 오픈소스 라이선스를 명시한 LICENSE 문서를 작성했다.
• 프로젝트의 이름이 기억하기 쉽고, 기존의 프로젝트나 상표권과 혼동되지 않는 것을 확인했다.

코드

• 소스 코드에 코드의 목적과 예외 처리를 명확하게 설명한 주석이 있다.
• 명확한 코딩 컨벤션에 따라 함수 이름, 메서드 이름, 변수 이름을 사용하고 있다.
• 수정한 작업 목록이나 이슈, Pull requests 등에 개인 암호나 공개되어서는 안 되는 정보가 남아 있지 않다.
• 외부에서 가져온 오픈소스 프로젝트 코드에 대해 출처와 저작권, 라이선스 정보를 주석으로 명시했다.

기타

개인 프로젝트의 경우

• (만약 어딘가에 채용된 상태라면) 회사의 오픈소스 정책 관련 팀과 지적 재산권 관련 팀, 법무팀에 프로젝트를 공유했다.

업무로 공개하는 프로젝트의 경우

• 사내 오픈소스 관련 팀과 법무팀에 프로젝트를 공유했다.
• 커뮤니티 관리(이슈 대응 및 Pull requests 관리)를 책임질 담당자가 있다.
• 최소 2명의 담당자가 프로젝트의 관리자 권한을 가지고 있다.

이제 시작입니다!

이제 오픈소스의 메인테이너가 되었습니다.

오픈소스를 운영하는 일은 단순히 버그를 수정하고 기능을 추가하는 것이 아니라, 프로젝트를 널리 알리고 사용자와 소통하며 궁극적으로 프로젝트의 품질을 높일 수 있는 모든 범위의 활동을 의미합니다. 공개된 오픈소스는 누군가의 문제를 해결하는 데 도움이 될 것입니다. 이렇게 도움을 받은 사람들이 사용자가 되고, 때에 따라 컨트리뷰터로 오픈소스에 참여할 것입니다.

오픈소스 활동을 통해 전 세계의 개발자와 의견을 나누고 다양한 경험을 쌓기를 바랍니다.