오늘은 오픈소스에 기여하는 실제적인 방법이 어떤 것이 있는지에 대해서 설명하도록 하겠습니다.

대표적인 오픈소스인 리눅스만 하더라도 리누스 토발즈가 처음 그 코드를 공개했을 때 세계 최대 규모의 오픈소스 소프트웨어가 될 거라는 생각조차 못했을 것입니다. 여전히 토발즈는 커널의 승인 여부를 혼자 결정하고 있지만 누구나 개선될 수 있는 소스코드를 보내게 되고 그것이 도움이 된다고 판단되면  해당 소스코드의 저자(Author) 항목에 기여자(Contributor)가 되어 다음 릴리즈 되는 버전에 이름이 나오게 되었습니다. 이는 유명해지려는 사람들의 욕구(과시욕)를 충족시켜 주었을 뿐더러 개발자들에게 돈 한푼 주지 않고도 커널의 버그 수정, 드라이버 개발, 기능 추가를 할 수 있는 중요한 원동력이 되었습니다.

화끈한 창시자

리누스 베네딕트 토발즈(Linus Benedict Torvalds, 1969년 12월 28일 ~ )는 스웨덴 핀란드 소프트웨어 개발자이다. 리눅스의 아버지 로 유명하며, 분산 버전 관리 시스템 Git 등을 만들었다. 그의 종특은 맘에 안드는 것은 뭐든지 까는 것으로, 거친 언사도 서슴지 않으며, 일반인들과도 뉴스그룹, 이메일 등지에서 욕설섞인 배틀을 자주 뜨는 현장을 목격 할 수 있

다. 특히 리눅스 개발 커뮤니티의 분위기를 살벌하게 만드는 일등 공신이 리누스 본인인데, 오픈소스 개발이라고 하면 누구나 편하게 자신의 코드를 커밋할 수 있을 것 같지만 현실은 시궁창으로, 리눅스에 함부로 손을 댄 사람은 리누스에게 쌍욕을 먹고 멘붕을 하게 되기 일쑤다. 소스 코드 리뷰에서 심각하게 결함이 있는 부분이나 마음에 안드는 부분을 가차없이 까내리는 모습이 거의 고든 램지 급.


기여의 1단계로 보자면 우선 내가 사용하고 있는 오픈소스에 대한 관심과 그것이 가진 기능을 활용해 보는 것이 첫번째일 것입니다. 어떤 업무시스템 또는 소프트웨어를 개발하고자 하는 경우 개발하고자 하는 기능에 대한 충분한 분석을 한 뒤, 이미 존재하는 오픈 소스 소프트웨어 프로젝트들이면 내가 원하는 요구 사항을 만족하는 것이 있는지 확인하는 작업부터가 시작일 것입니다.


1.  기여 #1 - 있는거 참여할래!

가. 오픈소스 프로젝트 검색

현재 오픈소스 프로젝트는 셀 수 없을 정도로 많으며, 해당 프로젝트가 관리되고 있는 저장소도 각각 다릅니다. 이렇게 많은 프로젝트들 중 특정 프로젝트를 찾기 위해 다음과 같은 방법을 사용할 수 있습니다.


(1) 구글링

잘 알려진 유명한 오픈소스 프로젝트들은 타이틀만으로도 구글링을 통해 충분히 검색할 수 있습니다.

[그림 1-1 구글링을 이용한 프로젝트 검색]


(2) 오픈소스 저장소 내 검색

GitHub, SourceForge, Bitbucket, Google Code 등 오픈소스 저장소에 접속하여 직접 검색합니다.

[그림 1-2 오픈소스 저장소 내 프로젝트 검색] - 아이고 많기도 하여라!


(3) 오픈소스 재단 내 검색

아파치 재단, 리눅스 재단, 모질라 재단 등 오픈소스 재단에 접속하여 직접 검색할 수 있습니다.

[그림 1-3 오픈소스 재단 내 프로젝트 검색]

그 밖에 http://www.findbestopensource.com , https://www.openhub.net/ 등의 사이트에서도 검색할 수 있습니다.


나. 오픈소스 프로젝트 참여


오픈소스 프로젝트에 참여하는 방법은 다음과 같이 아주 다양합니다.

  • 버그 리포트
  • 커뮤니티 활동을 통한 의견 교류
  • 프로젝트 문서 수정 또는 번역
  • 기능 등록 및 수정 요청
  • 패치 요청
  • 커미터 또는 컨트리뷰터 활동
  • 한글 번역

* 커미터(Committer) : 프로젝트내에서 직접 코드를 push할 수 있는 권한을 가진 사람

* 컨트리뷰터(Contributter) : 패치 등의 소스 코드를 제공하는 사람

즉, 반드시 코드를 수정, 작성해야만 프로젝트에 참여하는 것이 아니고 자신이 할 수 있는 부분에서 꾸준한 관심과 희생정신을 가지고 활동하는 것이 바람직합니다.

개발자에게 있어 커미터 또는 컨트리뷰터가 되는 것이 가장 이상적인 참여 방법이 될 수 있으며, 일반적인 과정은 다음과 같습니다.

(1) 기술 및 사용법 습득과 개발환경 구축


오픈소스 프로젝트에서 사용하는 언어 및 프레임워크 등의 기술을 습득하고 해당 오픈소스 프로젝트를 활용할 수 있어야 하며 개발가이드를 통한 자신만의 개발 환경을 구축합니다.

GitHub의 경우 개발환경 구축 시 프로젝트를 개인 저장소로 복제하기 위해 Fork를 수행합니다.

[그림 1-4 GitHub 소셜 메뉴]


Watch, Star, Fork는 GitHub의 소셜 기능으로써 Watch는 해당 프로젝트를 지속적으로 관찰하겠다는 의미로 이 기능을 활성화 시키면 해당 프로젝트가 처리하고 있는 이슈들에 대해서 알림이 오게 됩니다. Star는 해당 프로젝트에 관심을 나타내는 것으로 별점과 비슷하며, Star가 많은 프로젝트들은 월간, 주간, 일간으로 분류하여 인기 프로젝트로 선정되며 Explore 메뉴에서 보여집니다. 마지막으로 Fork는 해당 프로젝트를 내 계정에 그대로 복사하는 기능으로 해당 프로젝트에 Push 권한이 없다면 복제된 프로젝트에 기능을 추가, 수정하고 Pull Request로 변경사항을 적용 요청할 수 있습니다.

(2) 메일링 리스트 구독 및 커뮤니티 활동

메일링 리스트를 구독함으로써 프로젝트 관련 정보를 받아볼 수 있으며, 커뮤니티 활동으로 구성원들과의 의견 교류를 활발히 합니다. 본인이 해당 컴포넌트에 대한 장단점을 파악하고 이에 대한 설명이 가능한 상태에서 영어 작문이 능통하다면 StackOverflow를 활용 하여 꾸준히 활동하는 방법도 정말 좋습니다.

(아 영어!) - 영어의 중요성!!


(3) 버그 리포트 & 기능 제안

재현할 수 있는 버그에 대해 상황과 상태를 자세히 기술하며, JIRA나 GitHub 이슈 등의 공식 이슈 트래커를 사용하여 리포트합니다. 단, 버그 리포트를 등록하기 전 유사한 버그가 있는지 확인하고 이미 존재한다면 기존 내용에 코멘트 등으로 부가 설명 후 vote나 watch 등으로 관심을 표현하는 것이 좋겠죠! 기능 제안도 버그 리포팅과 마찬가지고 이슈 트래커를 사용하며, 유사한 이슈가 있는지 확인 후 등록하면 더욱 좋습니다.


(4) 패치 등록 / Pull Request

버그, 기능 개선, 신규 기능 등을 위해 등록된 이슈에 패치를 첨부하면 커미터들이 패치를 검토한 후 적용하게 됩니다. GitHub가 사실상 오픈소스 코드 저장소의 표준이 되었기 때문에 요즘은 패치를 보내는 일은 많지 않고 대부분 GitHub의 Pull Request를 이용하면 됩니다. 자세한 설명은 인터넷에 무지하게 널렸으니 참고하여 주셔도 됩니다.

[그림 1-5 GitHub Pull Request]


(5) 이도 저도 안되겠다?!

그러면 우선 번역하는데 참여하겠다로 시작하는 방법도 최고의 시작점이 아닐까 합니다.

국내 오픈소스 커미터 현황

2019년 2월 기준* 총 500여 의 국내 커미터가 OS, Cloud, Mobile, BigData, IoT, AI, Network, Web, Embedded, Development Environment 등의 10개의 분야의 총 1,398 글로벌 오픈소스 프로젝트*에 참여하고 있습니다.

* 글로벌 커미터 현황은 프로젝트의 기여도와 코드의 정성적 평가 등을 거쳐 30 ~90 일 간격으로 신규 커미터를 추가하며 , 기존 커미터도 지속적인 소스코드 개발과 기여가 없으면 커미터 자격이 유지되지 않음

ㅇ 국내 커미터들이 가장 많이 개발에 참여하고 있는 글로벌 오픈소스 프로젝트는 구글 안드로이드(Google Android)이며, 총 86명의 국내 커미터가 분포되어 있음

- 구글 안드로이드 다음으로는 Google Chromium 프로젝트에 46명, WebKit 프로젝트와 Rust 프로그래밍 언어에 각각 18명의 국내 커미터가 개발하고 있음

국내 커미터가 참여하는 글로벌 프로젝트 분야 Top 3는 ① Development Environment* 분야 119명 ② Mobile 분야 105명 ③ Web분야에 80명이 참여하여 Top 3를 형성하고 있음

* 개발환경 분야는 Programming Language, Testing Tool, Simulator, Compiler, Build system, Library, Framework 등을 포함하고 있음

2. 기여 #2 - 아니야! 내가 새로 만들래!

새로운 오픈소스 소프트웨어 프로젝트의 시작은 요구 사항을 만족하는 기존 프로젝트를 발견하지 못한 경우나 기존의 유사 프로젝트에 새로운 기능에 대한 수용 요구가 받아들여지지 않은 경우 등에 내리는 최후의 선택이라고 볼 수 있습니다. 그 밖에 자주 발생하는 새 프로젝트 시작 요인으로는 개인적 취향에 따른 것인데, 기존 프로젝트에 사용된 개발 언어가 마음에 들지 않는 경우도 많습니다.

실제 오픈 소스 소프트웨어들은 다양한 라이선스 정책을 가지고 있지만, 거의 대부분은 기존의 코드에서의 브랜치가 문제가 되는 경우는 많이 없습니다. 자신이 순환 구조에의 참여가 어렵다고 느끼는 경우, 프로젝트 결과물의 설계 구조에 전혀 동의 할 수 없는 경우, 마지막으로는 기존 프로젝트의 핵심 개발자, 관리자 그룹을 개인적으로 선호하지 않는 경우 등이 있을 수 있습니다.

일단 여러 동기에 의하여, 새로운 프로젝트가 시작되면, 상용 소프트웨어의 개발과 유사한 과정을 거치게 되는데, 이 과정은 같은 동기와 목표 의식을 가진 핵 심 개발자들로 개발팀을 구성하고, 요구 분석을 더욱 견고하게 한 뒤, 각종 위험 요인 분석, 일정 만들기 등의 절차적인 작업들로 시작됩니다.

그 가운데 위험 요인 분석에는, 이 새로운 프로젝트가 기존 프로젝트들 에 비하여 경쟁력을 가질 수 있는지, 개발과 추후 관리를 위한 충분한 자원자를 확보할 수 있는지, 개발에 필요한 장비가 확보 가능한지 등을 포함하고 있습니다.

프로젝트의 시작 단계에서부터 소스의 관리, 버그의 관리, 개발자들 간의 원활한 의사소통을 위하여 Github와 같은 오픈소스 소프트웨어 개발자 사이트를 이용할 수 있지만, 많은 초기의 프로젝트의 경우, 프로젝트의 시작 동기, 요구 사항, 설계 등이 기술된 공식적 문서의 부족이나, 다운로드가 가능한 소프트웨어 릴리즈가 없다는 이유로 개발자 지원 사이트에 등록된다 해도 커뮤니티 형성 등의 파급 효과를 기대하기는 어렵긴 합니다.


첫번째 할 일. 프로토타입 구현


소프트웨어가 커뮤니티의 관심을 끌기 위한 최소한의 작업은 고품질의 프로토타입을 완성하는 일입니다. 프로토타입의 개발은 비교적 소수의 폐쇄적인 핵심 개발자 그룹을 중심으로 이루어집니다. 따라서 개발자들 사이의 의견 교환 및 의사 결정을 위한 시스템의 존재 여부는 크게 문제가 되지 않지만, 프로토타입 구현이 진행되면서, 최초의 요구 사항이 일부 수정되고 그 결과가 설계의 변경을 필요로 하는 경우도 많아, 구성원 사이의 의사소통 방법과 최소한의 문서 화는 노력이 반드시 필요합니다.

많은 오픈 소스 소프트웨어 프로젝트에서는 상용의 대형 소프트웨어 개발 방식에서 사용되는 소프트웨어 공학적 개발 방법론이 사용되지 않으며, 설계 방식과 참여한 개발자들의 취향에 따른 개발 방식이 사용되는게 일반적입니다. 하지만, 오픈 소스 개발의 가장 중요한 특징인 분산 개발을 효과적으로 수행하고, 소스 코드의 재사용 가능성을 높이기 위하여 모듈화, 계층화된 소프트웨어 설계를 하는 것이 중요합니다.

설계는 이전에 있던 유사 프로젝트의 설계를 바탕으로 이루어지기도 하며, 더 많은 경우는, 개발자들의 혁신 의지에 따라, 새로운 설계를 추구하게 됩니다. 프로토타입 구현의 완성도와 설계 특징들은, 프로젝트의 동기와 목표에 수긍하는 개발자들을 커뮤니티에 끌어들이고, 그들의 적극적인 피드백을 유도하는 중요한 원동력입니다.

따라서 프로토타입은 기본적인 기능 요구를 만족하며, 안정적인 동작을 해야 하며, 단순 명료한 소프트웨어 구조를 유지 하는 것이 바람직하며. 또한 기능적인 부분을 포함하여 개선할 여지도 있어야 개발자들이 많이 참여를 하게 될 것입니다.


프로토타입의 배포 이전에 반드시 거쳐야 하는 단계는 내부 시험입니다. 이 단계는 커뮤니티 참여자를 끌어 들이기 위하여, 최초로 오픈되는 소프트웨어가 그럴 듯하게 보여야할 뿐만 아니라 높은 수준의 안정성도 확보되어야 한다는 관점에서 매우 중요합니다. 대개의 프로젝트에서  별도의  QA, 테스팅 도구나 정교한 방법론은 잘 사용되지 않으며, 최근에는 가상 머신을 이용하여, 다양한 시스템 환경에서의 테스팅을 이전 보다는 더 용이하게 할 수 있다는 특징이  있습니다. 주로 모듈 단위로 설계, 구현되는 소프트웨어 구조 때문에 오픈 소스 프로젝트에서는 기존의 라이브러리들을 적극적으로 활용하게 되며, 많은 경우 각 모듈 또한 라이브러리 형식으로 개발되는 게 일반적입니다.  사실 개발되는 많은 오픈소스 소프트웨어들이 패키지 형태의 완성품보다는 라이브러리 형태의 모듈이 상당히 많습니다.

프로토타입 개발자들은 오픈 소스 프로젝트로서 성공적인 정착을 위해 배포 전에 호환성, 가이드, 편의성 문제의 해결에 많은 노력을 기울여야 하며,  다양한 빌드도구를 활용하여 개발자들이 손쉽게 우리가 만든 소프트웨어를 개발하고 테스팅할 수 있는 환경을 만들어주는 것이 중요합니다.

두번째. 결과물 배포

프로그램 배포는 완성된 프로토타입을 공개함으로써, 프로젝트를 오픈소스 소프트웨어 순환 구조 안에서 발전 하도록 만들기 위한 단계입니다. 프로젝트의 오픈과 소프트웨어의 배포는 BitBucket, GitHub과 같은 오픈소스 프로젝트 사이트를 이용할 수 있습니다. 하지만 GitHub만 따져도 현재 등록된 프로젝트의 수가 이미 수십만 개를 넘었기 때문에 , 초기 단계의 프로젝트가 검색 단계에서 발견되어 커뮤니티의 주목을 받기는 쉽지가 않은 상황입니다.

허걱! 1억개!

배포를 통해 성공적인 커뮤니티 기반 오픈 소스 프로젝트가 되기 위해서는 프로젝트 관리 구조에 대한 프로세스 등의 여러 가지 중대한 결정들이 필요합니다. 프로젝트 관리 구조는 개발자 그룹과 최종적으로 프로젝트의 방향을 결정하는 의사 결정 그룹, 그리고 의사 결정 과정을 의미하는 것입니다. 즉, 배포를 통해서 프로젝트의 소유가 초기의 핵심 개발자 그룹에서 커뮤니티로 바뀐다는 점을 바탕으로, 프로젝트에 더 많은 사람들이 참여할 수 있는 구조와 의사 결정 과정을 만드는 것인데, 이 관리 구조는 프로젝트 결과물의 성격에 따라 다르게 결정되어야 합니다. 예를 들어 운영체제의 커널 또는 그의 일부와 같이 기술적 위험이 수반되는 프로젝트의 경우에는 보수적 관점에서의 관리를 추구하여야 합니다.

새로운 기능의 수용, 소스 코드의 수정 등에 매우 신중한 결정을 해야 하며, 시험 및 새로운 릴리즈에 관한 중앙집중형 통제권을 유지하는 것이 바람직합니다. 반면에 GUI와 같은 사용자 편의 위주의 프로젝트는 다양한 기능적 요구를 빠르게 수용하기 위한 관리 스타일이 좋다. 초기의 프로젝트에서는 메일링 리스트, 뉴스그룹, 포럼 등을 이용 한 의견 교환과 묵시적인 합의에 의하여 프로젝트가 진행될 수 있으나, 프로젝트가 점차 명성을 얻어 커뮤니티가 커지면, 공개적이면서도 좀 더 명확한 의사 결정 구조를 요구합니다.


여러 관리 스타일에도 불구하고 커뮤니티를 기반으로 발전하는 오픈 소스 프로젝트에서는 개발자, 사용자들의 모든 형태의 기여(기능 추가, 버그 수정, 버그 리포팅, 새로운 기능 요구, 등)가 반드시 권장되야 하며, 개발자들의 기여 내용이 빠르게 프로젝트에 반영되어야 합니다. 배포 전에 결정해야 할 또 다른 중요한 사항은 공개될 소스의 라이선스를 결정하는 것입니다.

OSI(Open Source Initiative)의 오픈 소스 정의는 오픈 소스 에 대한 명확한 가이드라인으로 사용되고 있으며, 라이선스가 이 가이드라인을 만족하면, 오픈소스 소프트웨어라고 할 수 있습니다. 많은 오픈 소스 소프트웨어들이 GPL(Generic Public Licence) 또는 LGPL(Lesser GPL) 라이선스를 가지고 있지만, GPL 버전들 사이의 차이를 비롯하여, OSI에 등록된 다양한 오픈소스 라이선스들의 미묘한 차이점은 오픈소스 개발자 들이 프로젝트에의 참여 여부를 결정하는 한 요인이 되기도 합니다.

기타 결정 사항에는 커뮤니티 참여자들의 주 통신 방법과 소스 코드로의 접근방법 등이 있습니다.


세번째! 개발자간 의사소통

개발자간 소통 방법에는 커뮤니티 참여자의 성격(개발자, 관리자, 사용자 등)에 따른 메일링 리스트, 포럼과 그들의 아카이브, 버그 리포트, 프로젝트 관련 문서, FAQ 등이 있습니다. 버그 리포트는 사용자와 개발자의 공식적인 통신 방법으로, 오픈 소스 소프트웨어 개발자 사이트들이 공통으로 제공하는 버그 트래킹 시스템을 이용합니다. 별도의 홈페이지를 이용하여 프로젝트를 공개한다면, Bugzilla, Trac, Redmine과 같은 버그 트래킹 시스템을 설치하여 이용할 수 있으며, 아틀라시안의 JIRA를 오픈소스 개발자용 버전으로 받아 사용하는 방법도 있습니다.(아틀라시안 강추!!)

버그 트래킹 시스템은 버그를 등록 하고, 누가 그것을 담당하여 수정할 지를 할당하고, 현재 처리 상태는 어떤지, 그리고 그 버그에 대한 의견 교환을 하는 등, 버그의 발생부터 해결까지의 전 과정에 대한 체계적인 관리 방법을 제공합니다. 소스 코드의 경우 안정된 배포 버전, 흔히 베타 버전라고 하는 외부용 시험 버전, 그리고 현재 개발이 진행 중인 소스 코드 스냅샷, 세 가지를 모두 공개하는 것이 보통입니다.

소스 코드 스냅샷 공개는 개발자들 이 소스의 버전 관리를 위하여 사용하고 있는 소스 코드 버전 관리 서버에 로그인하여 소스에 읽을 수 있도록 하는 것입니다. 소스 코드의 공개는 오픈소스 소프트웨어의 가장 큰 미덕으로 누구나 쉽게 다운로드, 리뷰, 빌드를 할 수 있도록 하고, 궁극적으로 패치를 만들어 프로젝트 관리자에게 보낼 수 있어야 합니다.

많은 오픈 소스 프로젝트들은 홈페이지 또는 배포된 소스에 프로젝트 컨트리뷰터(기여자)와 커미터들을 나열함으로써, 그들의 기여에 감사하고, 동시에 그 목록에 없는 개발자, 사용자들에게 동기를 부여하고 있으며 커리어 개발의 도구로도 활용되고 있습니다.


네번째, 커뮤니티 기반 개발

일단 프로젝트의 프로토타입, 소스가 공개되어, 점차 알려지고, 사용자,  개발자 등의 관심을 끌어, 커뮤니티가 형성되면 오픈소스 순환 구조에 의해 프로젝트는 진화하는 게 일반적입니다. 공개에 앞서 결정된 의사 결정 구조 등에 의거하여 수정 버전의 릴리즈, 기능이 대폭 강화된 버전업 등이 이루어지며, 사용 중에 발생하는 버그의 리포팅 및 수정, 기능 추가 요구 등이 커뮤니티 측에서도 이루어지며, 그 결과가 프로젝트 관리자 그룹에 의해 반영됩니다.

이 순환 구조가 얼마나 원활하게 운영되는지가 결국 오픈소스 소프트웨어 프로젝트의 성패를 결정하게 되며, 이 구조의 원활한 순환과 효율성은 모든 참여자 사이의 의사소통 및 의사 결정 과정 등, 배포 전에 내려진 여러 결정에 의해 좌우됩니다. 오픈소스 소프트웨어가 커뮤니티에 의해 진화한다는 일반적인 인식에도 불구하고, 그 프로젝트를 처음 시작하고, 많은 경우 결국 관리하게 되는 코어 개발자 그룹의 지속적인 관심과 개선 의지는 프로젝트 성공의 가장 중요한 요인이 됩니다.

많은 오픈 소스 소프트웨어 프로젝트 참여의 동기가 ‘재미’로 시작되는 경우입니다. 하지만, 오픈소스 순환 구조에 안정적으로 들어선 아주 성공적인 프로젝트들(예: 빅데이터 프로젝트, NoSQL 등)은 그 결과가 상업적인 활동에 점차 많이 적용되면서, 기술 지원과 새로운 기능 요구에 대하여 시기적절한 대응이 요구되며, 프로젝트의 핵심 개발자, 관리자 그룹에게는 더 빠른 진화를 할 수 있는 추가적인 동력이 필요하게 되고, 이 과정에서 많은 경우 기술 지원에 대한 대가로서 금전적 보상이 따르는 경우가 많아져 많은 개발자들이 이러한 오픈소스 개발에 관심을 가지게 되었습니다.


간략하게나마 오픈소스에 기여하는 방법에 대해 살펴보았는데 읽을만 하셨나요? 사실 바쁘게 업무 시스템관리하면서 오픈소스하기가 쉽지 않습니다. 대부분의 오픈소스 개발자들이 재미로 본인의 여가시간을 활용하여 시작한 경우가 대부분입니다. 앞으로 조금만 시간을 들여서 유튜브 동영상, 게임하시는 시간 조금 줄이고 간단한 오픈소스 활용부터 하시는 건 어떨까요?

이런 소프트웨어 엔지니어가 되선 안되잖아요. ^^

jchoi's profile image

jchoi

2020-03-26

Read more posts by this author