이전 편에 이어, 새로운 오픈소스 프로젝트를 시작하는 방법에 대해서 설명하고자 합니다.
새로운 오픈소스 소프트웨어 프로젝트의 시작은 요구 사항을 만족하는 기존 프로젝트를 발견하지 못한 경우나 기존의 유사 프로젝트에 새로운 기능에 대한 수용 요구가 받아들여지지 않은 경우 등에 내리는 최후의 선택이라고 볼 수 있습니다. 그 밖에 자주 발생하는 새 프로젝트 시작 요인으로는 개인적 취향에 따른 것인데, 기존 프로젝트에 사용된 개발 언어가 마음에 들지 않는 경우도 많습니다.
실제 오픈 소스 소프트웨어들은 다양한 라이선스 정책을 가지고 있지만, 거의 대부분은 기존의 코드에서의 브랜치가 문제가 되는 경우는 많이 없습니다. 자신이 순환 구조에의 참여가 어렵다고 느끼는 경우, 프로젝트 결과물의 설계 구조에 전혀 동의 할 수 없는 경우, 마지막으로는 기존 프로젝트의 핵심 개발자, 관리자 그룹을 개인적으로 선호하지 않는 경우 등이 있을 수 있습니다.
일단 여러 동기에 의하여, 새로운 프로젝트가 시작되면, 상용 소프트웨어의 개발과 유사한 과정을 거치게 되는데, 이 과정은 같은 동기와 목표 의식을 가진 핵 심 개발자들로 개발팀을 구성하고, 요구 분석을 더욱 견고하게 한 뒤, 각종 위험 요인 분석, 일정 만들기 등의 절차적인 작업들로 시작됩니다.
그 가운데 위험 요인 분석에는, 이 새로운 프로젝트가 기존 프로젝트들 에 비하여 경쟁력을 가질 수 있는지, 개발과 추후 관리를 위한 충분한 자원자를 확보할 수 있는지, 개발에 필요한 장비가 확보 가능한지 등을 포함하고 있습니다.
프로젝트의 시작 단계에서부터 소스의 관리, 버그의 관리, 개발자들 간의 원활한 의사소통을 위하여 Github와 같은 오픈소스 소프트웨어 개발자 사이트를 이용할 수 있지만, 많은 초기의 프로젝트의 경우, 프로젝트의 시작 동기, 요구 사항, 설계 등이 기술된 공식적 문서의 부족이나, 다운로드가 가능한 소프트웨어 릴리즈가 없다는 이유로 개발자 지원 사이트에 등록된다 해도 커뮤니티 형성 등의 파급 효과를 기대하기는 어렵긴 합니다.
소프트웨어가 커뮤니티의 관심을 끌기 위한 최소한의 작업은 고품질의 프로토타입을 완성하는 일입니다. 프로토타입의 개발은 비교적 소수의 폐쇄적인 핵심 개발자 그룹을 중심으로 이루어집니다. 따라서 개발자들 사이의 의견 교환 및 의사 결정을 위한 시스템의 존재 여부는 크게 문제가 되지 않지만, 프로토타입 구현이 진행되면서, 최초의 요구 사항이 일부 수정되고 그 결과가 설계의 변경을 필요로 하는 경우도 많아, 구성원 사이의 의사소통 방법과 최소한의 문서 화는 노력이 반드시 필요합니다.
많은 오픈 소스 소프트웨어 프로젝트에서는 상용의 대형 소프트웨어 개발 방식에서 사용되는 소프트웨어 공학적 개발 방법론이 사용되지 않으며, 설계 방식과 참여한 개발자들의 취향에 따른 개발 방식이 사용되는게 일반적입니다. 하지만, 오픈 소스 개발의 가장 중요한 특징인 분산 개발을 효과적으로 수행하고, 소스 코드의 재사용 가능성을 높이기 위하여 모듈화, 계층화된 소프트웨어 설계를 하는 것이 중요합니다.
설계는 이전에 있던 유사 프로젝트의 설계를 바탕으로 이루어지기도 하며, 더 많은 경우는, 개발자들의 혁신 의지에 따라, 새로운 설계를 추구하게 됩니다. 프로토타입 구현의 완성도와 설계 특징들은, 프로젝트의 동기와 목표에 수긍하는 개발자들을 커뮤니티에 끌어들이고, 그들의 적극적인 피드백을 유도하는 중요한 원동력입니다.
따라서 프로토타입은 기본적인 기능 요구를 만족하며, 안정적인 동작을 해야 하며, 단순 명료한 소프트웨어 구조를 유지 하는 것이 바람직하며. 또한 기능적인 부분을 포함하여 개선할 여지도 있어야 개발자들이 많이 참여를 하게 될 것입니다.
프로토타입의 배포 이전에 반드시 거쳐야 하는 단계는 내부 시험입니다. 이 단계는 커뮤니티 참여자를 끌어 들이기 위하여, 최초로 오픈되는 소프트웨어가 그럴 듯하게 보여야할 뿐만 아니라 높은 수준의 안정성도 확보되어야 한다는 관점에서 매우 중요합니다. 대개의 프로젝트에서 별도의 QA, 테스팅 도구나 정교한 방법론은 잘 사용되지 않으며, 최근에는 가상 머신을 이용하여, 다양한 시스템 환경에서의 테스팅을 이전 보다는 더 용이하게 할 수 있다는 특징이 있습니다. 주로 모듈 단위로 설계, 구현되는 소프트웨어 구조 때문에 오픈 소스 프로젝트에서는 기존의 라이브러리들을 적극적으로 활용하게 되며, 많은 경우 각 모듈 또한 라이브러리 형식으로 개발되는 게 일반적입니다. 사실 개발되는 많은 오픈소스 소프트웨어들이 패키지 형태의 완성품보다는 라이브러리 형태의 모듈이 상당히 많습니다.
프로토타입 개발자들은 오픈 소스 프로젝트로서 성공적인 정착을 위해 배포 전에 호환성, 가이드, 편의성 문제의 해결에 많은 노력을 기울여야 하며, 다양한 빌드도구를 활용하여 개발자들이 손쉽게 우리가 만든 소프트웨어를 개발하고 테스팅할 수 있는 환경을 만들어주는 것이 중요합니다.
프로그램 배포는 완성된 프로토타입을 공개함으로써, 프로젝트를 오픈소스 소프트웨어 순환 구조 안에서 발전 하도록 만들기 위한 단계입니다. 프로젝트의 오픈과 소프트웨어의 배포는 BitBucket, GitHub과 같은 오픈소스 프로젝트 사이트를 이용할 수 있습니다. 하지만 GitHub만 따져도 현재 등록된 프로젝트의 수가 이미 수십만 개를 넘었기 때문에 , 초기 단계의 프로젝트가 검색 단계에서 발견되어 커뮤니티의 주목을 받기는 쉽지가 않은 상황입니다.
배포를 통해 성공적인 커뮤니티 기반 오픈 소스 프로젝트가 되기 위해서는 프로젝트 관리 구조에 대한 프로세스 등의 여러 가지 중대한 결정들이 필요합니다. 프로젝트 관리 구조는 개발자 그룹과 최종적으로 프로젝트의 방향을 결정하는 의사 결정 그룹, 그리고 의사 결정 과정을 의미하는 것입니다. 즉, 배포를 통해서 프로젝트의 소유가 초기의 핵심 개발자 그룹에서 커뮤니티로 바뀐다는 점을 바탕으로, 프로젝트에 더 많은 사람들이 참여할 수 있는 구조와 의사 결정 과정을 만드는 것인데, 이 관리 구조는 프로젝트 결과물의 성격에 따라 다르게 결정되어야 합니다. 예를 들어 운영체제의 커널 또는 그의 일부와 같이 기술적 위험이 수반되는 프로젝트의 경우에는 보수적 관점에서의 관리를 추구하여야 합니다.
새로운 기능의 수용, 소스 코드의 수정 등에 매우 신중한 결정을 해야 하며, 시험 및 새로운 릴리즈에 관한 중앙집중형 통제권을 유지하는 것이 바람직합니다. 반면에 GUI와 같은 사용자 편의 위주의 프로젝트는 다양한 기능적 요구를 빠르게 수용하기 위한 관리 스타일이 좋다. 초기의 프로젝트에서는 메일링 리스트, 뉴스그룹, 포럼 등을 이용 한 의견 교환과 묵시적인 합의에 의하여 프로젝트가 진행될 수 있으나, 프로젝트가 점차 명성을 얻어 커뮤니티가 커지면, 공개적이면서도 좀 더 명확한 의사 결정 구조를 요구합니다.
여러 관리 스타일에도 불구하고 커뮤니티를 기반으로 발전하는 오픈 소스 프로젝트에서는 개발자, 사용자들의 모든 형태의 기여(기능 추가, 버그 수정, 버그 리포팅, 새로운 기능 요구, 등)가 반드시 권장되야 하며, 개발자들의 기여 내용이 빠르게 프로젝트에 반영되어야 합니다. 배포 전에 결정해야 할 또 다른 중요한 사항은 공개될 소스의 라이선스를 결정하는 것입니다.
OSI(Open Source Initiative)의 오픈 소스 정의는 오픈 소스 에 대한 명확한 가이드라인으로 사용되고 있으며, 라이선스가 이 가이드라인을 만족하면, 오픈소스 소프트웨어라고 할 수 있습니다. 많은 오픈 소스 소프트웨어들이 GPL(Generic Public Licence) 또는 LGPL(Lesser GPL) 라이선스를 가지고 있지만, GPL 버전들 사이의 차이를 비롯하여, OSI에 등록된 다양한 오픈소스 라이선스들의 미묘한 차이점은 오픈소스 개발자 들이 프로젝트에의 참여 여부를 결정하는 한 요인이 되기도 합니다.
기타 결정 사항에는 커뮤니티 참여자들의 주 통신 방법과 소스 코드로의 접근방법 등이 있습니다.
개발자간 소통 방법에는 커뮤니티 참여자의 성격(개발자, 관리자, 사용자 등)에 따른 메일링 리스트, 포럼과 그들의 아카이브, 버그 리포트, 프로젝트 관련 문서, FAQ 등이 있습니다. 버그 리포트는 사용자와 개발자의 공식적인 통신 방법으로, 오픈 소스 소프트웨어 개발자 사이트들이 공통으로 제공하는 버그 트래킹 시스템을 이용합니다. 별도의 홈페이지를 이용하여 프로젝트를 공개한다면, Bugzilla, Trac, Redmine과 같은 버그 트래킹 시스템을 설치하여 이용할 수 있으며, 아틀라시안의 JIRA를 오픈소스 개발자용 버전으로 받아 사용하는 방법도 있습니다.(아틀라시안 강추!!)
버그 트래킹 시스템은 버그를 등록 하고, 누가 그것을 담당하여 수정할 지를 할당하고, 현재 처리 상태는 어떤지, 그리고 그 버그에 대한 의견 교환을 하는 등, 버그의 발생부터 해결까지의 전 과정에 대한 체계적인 관리 방법을 제공합니다. 소스 코드의 경우 안정된 배포 버전, 흔히 베타 버전라고 하는 외부용 시험 버전, 그리고 현재 개발이 진행 중인 소스 코드 스냅샷, 세 가지를 모두 공개하는 것이 보통입니다.
소스 코드 스냅샷 공개는 개발자들 이 소스의 버전 관리를 위하여 사용하고 있는 소스 코드 버전 관리 서버에 로그인하여 소스에 읽을 수 있도록 하는 것입니다. 소스 코드의 공개는 오픈소스 소프트웨어의 가장 큰 미덕으로 누구나 쉽게 다운로드, 리뷰, 빌드를 할 수 있도록 하고, 궁극적으로 패치를 만들어 프로젝트 관리자에게 보낼 수 있어야 합니다.
많은 오픈 소스 프로젝트들은 홈페이지 또는 배포된 소스에 프로젝트 컨트리뷰터(기여자)와 커미터들을 나열함으로써, 그들의 기여에 감사하고, 동시에 그 목록에 없는 개발자, 사용자들에게 동기를 부여하고 있으며 커리어 개발의 도구로도 활용되고 있습니다.
일단 프로젝트의 프로토타입, 소스가 공개되어, 점차 알려지고, 사용자, 개발자 등의 관심을 끌어, 커뮤니티가 형성되면 오픈소스 순환 구조에 의해 프로젝트는 진화하는 게 일반적입니다. 공개에 앞서 결정된 의사 결정 구조 등에 의거하여 수정 버전의 릴리즈, 기능이 대폭 강화된 버전업 등이 이루어지며, 사용 중에 발생하는 버그의 리포팅 및 수정, 기능 추가 요구 등이 커뮤니티 측에서도 이루어지며, 그 결과가 프로젝트 관리자 그룹에 의해 반영됩니다.
이 순환 구조가 얼마나 원활하게 운영되는지가 결국 오픈소스 소프트웨어 프로젝트의 성패를 결정하게 되며, 이 구조의 원활한 순환과 효율성은 모든 참여자 사이의 의사소통 및 의사 결정 과정 등, 배포 전에 내려진 여러 결정에 의해 좌우됩니다. 오픈소스 소프트웨어가 커뮤니티에 의해 진화한다는 일반적인 인식에도 불구하고, 그 프로젝트를 처음 시작하고, 많은 경우 결국 관리하게 되는 코어 개발자 그룹의 지속적인 관심과 개선 의지는 프로젝트 성공의 가장 중요한 요인이 됩니다.
많은 오픈 소스 소프트웨어 프로젝트 참여의 동기가 ‘재미’로 시작되는 경우입니다. 하지만, 오픈소스 순환 구조에 안정적으로 들어선 아주 성공적인 프로젝트들(예: 빅데이터 프로젝트, NoSQL 등)은 그 결과가 상업적인 활동에 점차 많이 적용되면서, 기술 지원과 새로운 기능 요구에 대하여 시기적절한 대응이 요구되며, 프로젝트의 핵심 개발자, 관리자 그룹에게는 더 빠른 진화를 할 수 있는 추가적인 동력이 필요하게 되고, 이 과정에서 많은 경우 기술 지원에 대한 대가로서 금전적 보상이 따르는 경우가 많아져 많은 개발자들이 이러한 오픈소스 개발에 관심을 가지게 되었습니다.
간략하게나마 오픈소스에 기여하는 방법에 대해 살펴보았는데 읽을만 하셨나요? 사실 바쁘게 업무 시스템관리하면서 오픈소스하기가 쉽지 않습니다. 대부분의 오픈소스 개발자들이 재미로 본인의 여가시간을 활용하여 시작한 경우가 대부분입니다. 앞으로 조금만 시간을 들여서 유튜브 동영상, 게임하시는 시간 조금 줄이고 간단한 오픈소스 활용부터 하시는 건 어떨까요?
이런 소프트웨어 엔지니어가 되선 안되잖아요. ^^
