우리는 이 책의 독자들이 오픈소스가 무엇을 제공할 수 있는지를 궁금해하고, 어쩌면 각자 가진 비지니스 요구를 해결할 수 있는 코드를 찾고 있다고 믿습니다. 이 절에서는 다른 사람의 오픈소스 코드를 성공적으로 사용하기 위해 도입해야 하는 주요 절차들을 요약합니다. 이 책의 앞부분에 인용된 자료들에는 이 절에서 언급할 내용들이 훨씬 더 자세하게 설명되어 있습니다.
개발팀은 어떤 오픈소스 코드가 어디에 사용 중인지 정확히 알고 있어야합니다. 이에 대한 관리는 OSPO나 OSPO가 아직 만들어지지 않은 경우 내부 직원들오 구성된 가상적인 팀이 수행하도록 합니다. 이 관리에는 두 가지 주요 목적이 있습니다. 코드를 올바르게 사용하고 있음을 입증하기 위한 감사 기록을 남기고, 사용된 외부 오픈소스가 가진 라이선스 의무들을 준수하는지 확인하고자 하는 것입니다. 이 정보를 수집하는 것은 여러 가지 이유로 매우 중요해서 대부분의 조직에서는 개발 사이클 안의 자동화된 도구를 이용하여 이 정보를 수집합니다.
전략 문서를 작성하는 것은 관리자와 직원을 교육할 때 유용합니다. 크게 생각하고 당신이 성취하고자 하는 최종 상태를 목표로 삼으십시오. 동시에 비지니스 성과 측면에서 광범위한 상위 목표를 수립하십시오. 다음은 오픈소스가 조직을 위해 할 수 있는 것을 잘 설명하기 위하여 언급되는 몇가지 사항입니다:
- 인재를 끌어들이고 유지합니다.
- 사업의 민첩성을 높이고, 혁신을 유도하며, 비지니스 가치 창출을 가속화합니다.
- 직원들이 쓸데없는 일에 낭비하는 시간을 제거하고 비지니스 로직 작성에 집중함으로써 비용을 절감하고 효율성을 향상시킵니다.
- 제품 또는 사고 리더쉽을 통해 수익을 창출하거나 시장 점유율을 높힙니다.
전략을 마일스톤 단위로 세분화하십시오. 이를 통해 필요한 각 프로세스의 책임자를 정하여 더 신속하게 프로세스들을 구동할 수 있습니다. 전략 측면에서 다음 사항을 고려하십시오.
- 회사 전체에서 오픈소스를 언제 어떻게 사용할 것인지를 명확하게 하는 오픈소스 거버넌스 및 정책
- 개발자가 외부 오픈소스 프로젝트에 기여할 수 있는 방법, 즉 역할 및 소요시간을 명시한 정책
- 기술 리더쉽 및 엔터프라이즈 아키텍처 그룹들의 적용 가능한 소프트웨어 프로젝트에 처음부터 오픈 정책을 사용할 것을 독려하기
- 내부 개발 프로젝트에 대하여 회사 전체에 걸친 오픈소스 개발 방법론을 적용하는 내부협동개발(InnerSource) 모델을 시작
오픈소스 개발방식의 채택은 조직 사이의 경계를 넘게 만들고 새로운 조직 구조를 유도하기 때문에, 회사 내부에서 개발자들이 그런 구조를 넘나들며 협력하는 것을 허용하는 새로운 정책을 만들기 위한 노력이 필요할 수 있습니다.
당신의 주장을 옹호하면서 경계를 허무는 것을 도와줄 고위층 후원자를 찾는 것이 중요합니다. 이 부분은 우리가 이 절에서 언급한 것 가운데 가장 어려운 작업일 수 있지만, 매우 중요합니다. 당신이 준비하는 이 과정을 지지해줄 후원자가 필요합니다. 전략 보고서를 설득력 있게 작성하면, 그들이 당신의 고차원적이면도 장기적인 비전을 받아들일 것입니다. CTO 또는 CIO의 지원을 목표로 삼되, 그렇게 되기까지 최선을 다해 준비해야 합니다.
법무팀의 직원들은 이전에 다루었던 것들과는 근본적으로 다를 수 있는 라이선스를 이해할 수 있도록 교육을 받아야 합니다. 또한, 마케팅 및 홍보팀은 오픈소스가 개발 방법, 품질 그리고 고객 반응에 미치는 영향을 살펴봐야 합니다. 오픈소스 사례를 학습하고, 커뮤니티와의 소통에 협력하며, 이 새로운 개발 방법을 고객과의 상호 작용으로 전환하는 일을 해야합니다. 어쩌면 당신이 거기에서 고용된 경우도 있겠지만 당신이 참여하고 있는 오픈소스 커뮤니티의 구성원들이 그 커뮤니티에서 개최하는 이벤트에 참석하고 지원하는 것의 중요성을 마케팅 팀에 설명할 시간을 마련하는 것도 좋습니다. 또한, 영업팀은 고객에게 솔루션을 제시할 때, 코드의 사용 및 확장에 대한 질문에 잘 대답할 수 있도록 라이선스를 충분히 이해해야 합니다.
명확한 프로세스가 없으면, 누군가 올바른 방법을 따르지 않고 비공식적으로 오픈소스를 우리 코드에 포함시킬 위험이 있습니다. 이것은 어쩌면 그 오픈소스가 가진 라이선스를 위반할 수도 있을 뿐만 아니라, 오픈소스를 올바르게 활용하여 얻을 수 있는 이득을 놓치게 할 수도 있습니다. 예를 들어, 중요한 버그 수정은 오픈소스 프로젝트에서 주기적으로 릴리즈되는데, 그 수정을 적용하기 위해서는 해당 코드가 어디에 사용되는지 알아야 합니다. 또한, 명확한 프로세스가 수립되면 당신 조직의 직원들이 커뮤니티의 소중한 구성원이 되는 것이 허용되며, 거기에서 조직의 요구사항을 대변할 수 있습니다. 마지막으로, 명확하고 잘 소통되는 정책은 회사 전체에 걸쳐 당신의 오픈소스 계획에 대한 참여와 인식을 훨씬 더 높여줍니다.
개발자들은 비공식적으로 오픈소스 커뮤니티의 일원으로 참여할 수 있지만, 회사가 그로부터 확실한 이득을 얻기를 원한다면 법률적 심사, 프로젝트 심사, 코드를 작성할 개발자를 채용하는 것, 프로젝트와 이벤트를 지원하는 것, 커뮤니테이션과 커뮤니티 릴레이션를 관리하는 것 등, 모든 오픈소스 지원을 위한 창구를 일원화해야 합니다. 따라서 오픈소스를 시작하는 대부분의 회사들은 프로젝트를 홍보하고 관련된 업무를 처리하기 위해서 OSPO(Open Source Program Office)를 만듭니다. 여러 OSPO의 책임자들과 리눅스 재단의 TODO 그룹이 협력해서 만든 오픈소스 템플릿과 정책 예제들이 이제 막 시작하는 회사들에게 유용하게 사용될 수 있을 것입니다. 당신의 OSPO는 다음 절들에서 서술되는 활동들을 지원할 수 있습니다.
정책을 수립한 뒤에는, 회사의 모든 개발자들이 이 정책을 숙지하도록 합니다. 여기에는 법무팀, 구매조달팀과 같은 회사의 여러 다른 영역들 또한 포함되어야 합니다.
먼저 회사 안에 오픈소스 실무자로 이루어진 지원 커뮤니티를 만드십시오. 경영진의 지원이나 가이드가 있든 없든, 개발자를 포함하여 오픈소스 커뮤니티에서 일해본 경험이 있는 사람들이 기본적으로는 지원 커뮤니티 활동을 할 수 있을 것입니다. 이들 지지자들은 정기적인 점심시간 세션, 웹 세미나, 그리고 팀 회의에서의 발표와 같은 활동들을 통해서 다른 직원들에게 오픈소스를 전파하고 교육할 수 있습니다.
회사에 있는 모든 개발자를 대상으로 진행하는 교육 과정은 오픈소스를 사용하고 기여하는데 있어서 모두가 같은 이해와 기대를 가지고 있도록 만들어 줍니다.
이와 같은 지원 활동은 오픈소스에 대한 이해를 돕고 직원들이 그 문화에 익숙해지도록 합니다. 더 중요한 것은, 이 활동이 잠재적인 역량을 가진 사람을 발굴하여 더 일찍 그들과 같이 일을 시작할 수 있게 해준다는 것입니다.
오픈소스를 찾을 수 있는 곳은 많이 있습니다. GitHub과 GitLab은 잘 알려진 오픈소스 호스팅 사이트입니다. (두 사이트 모두 Linus Torvalds가 개발하고 많이 사용하는 버전 관리 소프트웨어인 Git을 사용합니다). 필요한 키워드 (예를들어, "employee management")를 검색하면 보토 수 천개의 프로젝트가 검색됩니다. 따라서 관심이 가는 프로젝트가 우리 요구 사항에 잘 맞는지를 잘 살펴봐야합니다. 리눅스 재단의 오픈소스 활용 가이드는 프로세스에 중점을 두고 있으며 Dan Woods와 Gautam Guliani의 책 엔터프라이즈 오픈 소스(O'Reilly, 2015)는 프로젝트가 얼마나 쓸만한가를 판단하는 가이드 라인을 제시합니다. 다음은 평가시 확인할 사항에 대한 목록입니다.
코드 품질
코드를 직접 검사하거나, 프로젝트가 GitHub에 있다면 Stars 등급의 확인, 버그리포트의 수, 그 프로젝트에 대한 사람들의 평판을 온라인에서 확인함으로써 평가할 수 있습니다. 모든 코드에는 오류가 있기 마련이기 때문에, 사람들이 버그가 있다는 것을 보고한다는 사실은 그 프로젝트가 유망하다는 뜻입니다. 중요한 버그가 수정되고 있기만 한다면 말이죠.
개발 활성도
프로젝트가 최근에 새 릴리즈를 발표했거나 아니면 적어도 버그를 수정하고 있는가? 코드에 대한 관심을 나타내는 지표로서 풀-리퀘스트가 많이 있는가?
프로젝트 성숙도
프로젝트가 얼마나 오래된 것인가? 커뮤니티가 활성화되어 있는가? 코드를 관리하는 사람들이 많이 있는가? 프로젝트에 대한 펀딩이 이루어지고 있나? 책, 동영상이나 다른 교육 자료가 있는가?
지원 수준
소프트웨어의 설치, 유지 보수에 도움을 받을 수 있는가? 프로젝트에 관한 좋은 문서가 있는가?
커뮤니티 활성도
메일링 리스트가 활성화되어 있나? 버그리포트에 대하여 개발자들이 신속하고 긍정적으로 대응하는가? 제기된 이슈에 사람들이 예의바르고 생산적으로 대응하는가? 커뮤니티가 성장하는 좋은 징조이지만 반드시 그래야 할 필요는 없습니다. 작은 사용자 기반을 가진 프로젝트가 우리에게 딱 맞는 것일 수도 있기 때문입니다. 한편, 커뮤니티가 활성화되지 않았거나 줄어들고 있다면 그것은 일종의 경고 신호입니다.
의사 결정의 개방성
프로젝트의 모든 선택 사항들이 공개되어 논의되고 있는가? 리더들이 개인적으로 중요한 결정을 내리고 메일링리스트나 코드 저장소에 결과를 보고한다는 느낌을 받는다면, 그것은 당신이 프로젝트의 방향에 대한 영향력을 발휘하기 어렵다는 것을 나타내는 경고 신호입니다. 처음에는 그 영향력이 중요하지 않다고 생각할 수 있지만, 소프트웨어에 대한 의존성이 커진 나중에 뭔가 말해야 한다면 문제가 될 수 있습니다.
거버넌스와 커밋 권한
새로운 기여자가 커밋 권한을 얻게 되는 과정이 문서화되어 있는가? 프로젝트에 당신의 시간과 전문성을 투자하고 있다면, 당신이 원할 때 그 기여에 상응하는 책임을 프로젝트에서 맡는 것이 맞을 수도 있습니다.
보안 문제 보고 체계
프로페셔널한 프로젝트라면 보안상의 허점을 발견한 사람이 프로젝트 리더에게 개인적으로 연락하도록 하여, 보안 문제가 있다는 사실이 외부에 알려지기 전에 수정될 수 있어야 합니다.
OSPO 또는 조직 내에서 오픈소스 사용을 추적하는 팀은 라이선스가 준수되고 있는지 확인해야합니다. 라이선스의 기술적 의미를 이해하는 개발자들과 법무팀 모두 주의가 필요합니다. 오픈소스 커뮤니티 참여자들은 오픈소스 라이선스 정합성(compliance)을 보다 간단하고 일관성있게 만들고 더 많은 기업들이 오픈소스 소프트웨어를 사용하도록 권장하기 위해 OpenChain Project를 구성했습니다. 라이선스 또는 코드의 원저자 찾기 자체도 어려울 수 있기 때문에, ClearlyDefined라는 또 다른 오픈소스 프로젝트로 사용자들이 라이선스 정합성을 위한 정보를 찾고 유지 관리할 수 있도록 도움을 주고 있습니다. Ibrahim Haddad의 책 기업에서의 오픈 소스 준수(리눅스 재단, 2016)는 라이선스 정합성 문제를 깊이있게 다루고 있습니다.
법무팀과 관계를 잘 설정하고 협력하십시오. 그들은 오픈소스와 관련하여 발행하는 일들을 거의 확실하게 처리해 줄 것입니다. 예를 들어, 오픈소스 라이선스의 적용을 받는 작업을 승인해주며 회사의 개발자들이 코드를 외부 프로젝트에 제출할 때 필요한 기여자 동의서를 검토해줍니다. 이 과정은 오픈소스의 친숙하지 않은 측면에 대해 협력하고, 끈끈한 관계를 구축하고, 신뢰를 얻을 수 있는 기회입니다. 이 관계를 이용하여 개발 자체와 개발자들에게 보다 유리한 오픈소스 정책을 자리잡게 할 수 있습니다.
또한 구매조달팀과의 관계도 필요합니다. 오픈소스와 관련된 구매 계약에 필요한 추가적인 세부 항목들을 추천하거나 그 팀이 써드파티와의 계약을 검토하는 과정에서 도움을 줄 수 있습니다.
외부 조직에서 오픈소스 코드를 개발했다 하더라도, 우리 조직 내에서 사용하려면 그 코드를 관리해야 합니다. 외부 코드도 테스트되어야 하고, 백도어가 있는지 확인해야하고, 기타 결함에 대한 테스트를 해야합니다. 외부의 코드를 우리 코드와 통합하는 작업도 내부에서 회사 코드를 작성하는 것과 마찬가지로 목표와 기한을 설정하고 모든 것이 계획대로 진행될 수 있도록 리소스를 투입해야 합니다.
물론 외부에서 코드를 가져오는 경우 일부 작업은 다르게 진행됩니다. 우리 개발자들이 코드를 관리하는 커뮤니티의 일원이 되어야 합니다. 예를 들어, 우리 개발자들이 커뮤니티의 버전 관리 시스템 안에서 일을 해야 합니다. 커뮤니티에서 코드를 호스팅하는 GitHub 또는 GitLab의 계정이 필요합니다. 코드를 수정하려면 (뒤쪽의 "오픈 소스 프로젝트에 기여하기" 장에서 자세히 설명 됨), 버전 관리 시스템에서 수정을 위한 브랜치 만들거나, 작업을 위한 내부 버전 관리 시스템을 사용해야 합니다.
오픈소스 커뮤니티와 함께 일하는 개발자는 비공개 프로젝트에서와는 다른 방식으로 일하며 의사소통과 협의를 하는 과정에서 추가적인 역량이 필요합니다. 개발자에게 필요한 추가 작업이 반영된 보상 체계를 만들어야 합니다. 프로젝트에서 사용하는 도구를 배우고, 채팅 및 메일링 리스트에 참여하고, 경험이 부족한 동료를 멘토링하고, 다른 사람이 기여한 코드를 확인 및 수정하고, 오픈소스 프로젝트에 대한 컨퍼런스나 리더 미팅에 참석하기 위한 시간도 할당해 주어야 합니다.
특히 개발자들과 다른 직원들이 특정 팀의 직접적인 성과물과 관련이 적은 일에 시간을 투자해야 한다면, 해당 직원과 관리자에 대한 성과 평가 기준도 조정해야 합니다. 이는 성과보너스를 지급하는 회사에 특히 해당됩니다. 오픈소스 프로젝트의 성공 요인과 회사 내부의 목표와 인센티브의 결을 맞추는 것이 중요합니다. 직원들이 컨퍼런스에서 발표하고 프로젝트 작업에 대한 블로그를 작성하고, 프로젝트의 거버넌스에 참여한다면, 그들의 기여가 회사의 명성에도 좋게 작용하며, 향후 개발자 채용과 같은 면에서 이득이 됩니다.
많은 직원들에 대한 광범위할 수도 있는 보상 계획을 수용하는 것과는 별개로, 관리자들은 소프트웨어 데드라인이 내부 직원뿐만 아니라, 커뮤니티의 활동에 의해서도 좌우될 수 있음을 알야야 합니다. 소프트웨어 프로젝트의 데드라인은 온전히 내부 팀에 의해 실행되는 경우에도 정확하게 설정하는 것이 거의 불가능에 가깝기 때문에 외부인에 의한 이 새로운 의존성은 관리자들이 현실을 인식하는데 도움이 될 수 있습니다. 커뮤니티가 우리가 필요로 하는 기능에 대한 우선순위를 낮게 설정했다면 자체 리소스를 투입하여 적시에 완료하고 개선 내용을 커뮤니티에 기여하십시오. 다른 회사도 비슷한 방식으로 일을 할 것이며 모두에게 이득이 됩니다.
창의적인 결과물에 자부심을 가지는 것은 자연스러운 일입니다. 소프트웨어는 더 이상 도널드 커누스(Donald Knuth)가 혼자서 독창적인 영감으로 TEX와 Metafont를 개발했던 것과 같은 방법으로는 개발되지 않습니다. 그러나 팀 단위로 개발을 하는 경우에도 긴밀한 협업을 통하여 개발이 진행된다면, 그 팀 고유의 정체성이 생깁니다. 나아가 팀으로 하는 작업을 통하여 개발자 개인의 요구 사항을 담아낼 수도 있습니다. 서로 긴밀하게 작업을 진행하는 팀에서는 서로의 역량을 쉽게 파악할 수 있습니다. 관리자는 누가 어떻게 기여를 했는지를 정확히 파악할 수 있기 때문에, 그 기여에 따라 연봉 인상 및 승진을 결정할 수 있습니다.
이러한 정신적, 실질적 보상 구조는 오픈소스로 인하여 많이 바뀌고 있습니다. 오픈소스 관점에서, 개발자 스스로 기여에 대한 개인적인 성취와 보상을 어떤 식으로 원하는지를 고려해야 합니다.
오픈소스 프로젝트를 시작하거나 참여할 때, 프로젝트를 인위적으로 관리하려 해서는 안되며, 서로 다른 목적을 가지고 참여했다 사라지는 불특정의 사람들과 함께 일하는 법을 배워야 합니다. 궁극적으로는, 기여한 내용을 세상 누구나 확인할 수 있기 때문에, 오픈소스 프로젝트에서는 개개인이 훨씬 더 빛이 날 기회를 가지게 됩니다. 상상하지도 못했던 엉뚱한 프로젝트에서 그런 일이 발생하기도 합니다. 또한 다른 여러 사람이 채택하는 확실한 기여를 하면, 취업의 기회가 놀랄만큼 확대됩니다. 코딩뿐만 아니라, 소통, 프로젝트와 인력의 관리, 디자인, 웹 개발, 문서화, 번역 등 많은 분야에서 오픈소스에 기여할 수 있습니다. 모든 기여가 프로젝트에는 중요합니다.
모든 것이 잘 노출되는 오픈소스 프로젝트의 특징 때문에, 관리자는 프로젝트의 최고 기여자를 높은 연봉이나 더 좋은 자리를 제안하는 경쟁사에게 빼았기지 않을까하는 우려를 할 수 있습니다. 이 문제를 해결하는 방법은 바로, 그 경쟁자가 되는 것입니다. 직원들이 지금 사용하고 있는 오픈소스 프로젝트에 개발자로 또 리더로 활동할 수 있는 기회를 주십시오. 그들에게 좋은 아이디어를 실현할 자유를 주고, 개발자나 개발팀에 유용한 도구를 만들어 낼 수 있는 자원을 제공하십시오. 만일 당신이 유명한 개발자들을 데리고 있다면, 그를 프로젝트 이사회에 참여시키고, 컨퍼런스를 통해 발표하도록 하십시오. 그들이 다른 최고의 개발자들을 자석처럼 당신 회사에 끌어올 수 있습니다.