본문 바로가기

[기고] 오픈소스 거버넌스 구축을 위한 단계 및 구성요소

 

- 오에스비씨(주) 김병선 부사장 -

 

오픈소스 소프트웨어(이하 오픈소스)는 현재 ‘참여 및 공개’를 통한 소프트웨어 개발 효율성 향상을 넘어 많은 글로벌 기업 및 개발자들이 오픈소스라는 생태계 플랫폼을 통해 신기술을 개발하고 시장을 주도하는 새로운 산업 패러다임으로 전환되고 있다. 많은 기업은 이러한 새로운 패러다임 속에서 전략적 경쟁우위와 시장 선점을 위해 오픈소스를 적극적으로 활용하고 있으며 공공부문에서도 신기술 기반 IT 구축과 양질의 서비스를 위해 오픈소스 도입을 가속화하고 있다. 그러나 오픈소스의 확산과 성장을 통한 기회의 이면에는 오픈소스 거버넌스 부재로 인한 위험이 있다는 것을 간과해서는 안 된다. 본 글에서는 오픈소스의 확산과 성장과 함께 오픈소스 관리 부재로 인한 위험을 예방하기 위한 오픈소스 거버넌스의 개념과 오픈소스 거버넌스 수행을 위한 구성요소를 제시하고자 한다.

 

1. 오픈소스 거버넌스 개념

거버넌스(governance)란 용어는 다양한 분야에서 많이 사용되고 있는 반면에 사용하는 분야에 따라 다양한 개념으로 정의되어 있어 명확한 정의를 내리기가 쉽지 않다. 거버넌스의 정의에 있어 존 피에르(Jon Pierre)와 피터스(B. Guy Peters)는 “정책 결정에 있어 정부 주도의 통제와 관리에서 벗어나 다양한 이해당사자가 주체적인 행위자로 협의와 합의 과정을 통하여 정책을 결정하고 집행해 나가는 사회적 통치 시스템”으로 정의했다.1) IT 거버넌스의 정의에 있어서 ISO/IEC 38500에 따르면 “이사진이 조직의 IT 활용을 평가하고(evaluate), 지휘하고(direct), 모니터링(monitor) 하는데 활용할 수 있는 원칙의 프레임워크를 제공하여 원칙을 구현하기 위한 지침의 표준으로서 3가지 활동인 평가(Evaluate), 지시(Direct), 모니터링(Monitoring)2)”을 제시하고 있다. 이러한 맥락에서 오픈소스 거버넌스는 오픈소스의 도입, 활용, 참여를 위한 정책과 프로세스를 결정하여 집행해 나가는 관리 및 통제 시스템을 구축하고 원활한 수행을 위한 평가, 지시, 모니터링 활동이라고 할 수 있다.

 

2. 오픈소스 거버넌스의 단계별 구성요소

 

2.1. 오픈소스 라이선스 이해

오픈소스 거버넌스를 수행하기 위해서는 가장 기본적이면서도 중요한 오픈소스 라이선스에 대한 개념적 이해와 관리가 필요하다. 오픈소스 라이선스는 라이선스에서 요구하는 의무사항에 따라 퍼미시브(permissive), 위크 카피레프트(weak copyleft), 스트롱 카피레프트(strong copyleft)로 개념을 분류하며, 일반적으로 단순 고지의무만을 요구하는 라이선스 계열을 퍼미시브 라이선스, 수정 코드에 대한 공개를 요구하는 라이선스 계열을 위크 카피레프트, 결합된 모든 코드에 대한 공개를 요구하는 스트롱 카피레프트 라이선스로 분류한다. 또한 오픈소스 라이선스 검토에 있어서는 오픈소스 라이선스 간의 양립성(호환성)을 함께 검토하여야 한다. 아래 [그림 1]은 오픈소스 라이선스 개념 분류와 양립성에 대한 개념을 소개하고 있다.

 

오픈소스 라이선스 개념 분류와 양립성(호환성)

[그림1] 오픈소스 라이선스 개념 분류와 양립성(호환성)

 

2.2. 오픈소스 라이선스 의무사항 이해

오픈소스 라이선스는 사용 형태 및 범위별로 발생 되는 의무사항이 상이하다. 특히, 오픈소스 사용 시 수취 및 실행만 하는 경우는 의무사항이 발생 되지 않으며 배포 시에 해당 라이선스별로 코드 공개, 무상특허권리 허용, 사용 및 변경사항 고지 등 다양한 의무사항이 발생한다. 또한, 소스코드 공개 시에는 공개 방법 및 양립성에 대한 검토가 필요하게 된다. [그림 2]는 오픈소스 사용 형태 및 범위별 라이선스 의무사항에 대한 검토 프로세스를 설명하고 있다.

 

오픈소스 사용 형태 및 범위별 라이선스 의무사항

[그림2] 오픈소스 사용 형태 및 범위별 라이선스 의무사항

 

2.3. 오픈소스 라이선스 사용정책 수립

오픈소스를 사용 및 활용하는 조직은 개발 및 판매/서비스하는 솔루션 및 서비스별로 소스코드 공개 여부 및 공개 가능한 범위에서 명확한 오픈소스 라이선스 사용정책을 수립하여야 한다. 그림 3은 오픈소스 라이선스 계열별 소스코드 공개 범위를 제시하고 있다.

 

오픈소스 라이선스별 소스코드 공개 범위

[그림3] 오픈소스 라이선스별 소스코드 공개 범위

 

2.4. 오픈소스 비즈니스 모델 검토

오픈소스 라이선스에 대한 이해를 기반으로 오픈소스 라이선스 사용정책을 수립하였으면, 오픈소스 활용 대상이 되는 해당 솔루션 및 서비스의 비즈니스 모델을 검토해야 한다. 오픈소스로 공개하여 구독모델로 서비스를 제공할 것인지 상용 소프트웨어 개발에 있어 기능 및 성능 강화와 비용 절감이 목적인지에 따라 오픈소스에 적용된 라이선스를 검토해야 하기 때문이다. 아래 [표1]은 카네기멜론 대학의 Thony Waserman이 정의한 오픈소스를 활용한 10가지 비즈니스 모델이다.

 

[표 1] 오픈소스 비즈니스 모델

비즈니스 모델 설명 기업 예
구독 모델
(Subscription Model)
사용자가 소프트웨어를 무료로 다운로드 받고 제한 없이 사용할 수 있는 모델
사용자가 수동으로 소프트웨어 업데이트를 확인해서 설치하고 무료로 다시 기술적인 문제에 대한 답변을 토론 포럼을 통해 해결할 수 있음§사용자는 특정 문제를 도와줄 컨설턴트와 계약자를 고용할 수 있으며, 기업은 업데이트 및 지원의 수준을 가입제품 기준으로 제공하는 방식
RedHat, Canonical Ubuntu, CUBRID, SULinux, Uengine
상업 및 오픈소스 제품
(Offering Commercial and Open Source Products)
기업의 제품이 라이선스에 기반하여 지원을 받는 상용 제품과 완전히 무료로 제공되는 오픈소스 제품으로 제공되는 유형 CollabNet, SugarCRM, JasperSoft, RedHatJboss
지원 및 교육 모델
(Supportand Training Model)
공급업체가 제공할 수도 있고 공급업체가 아닌 해당 제품에 대한 지원이나 교육이 가능한 개발자 또는 개인일 수도 있는 모델§공급업체는 하나 이상의 오픈소스 프로젝트에 지원 서비스, 교육 또는 출판물을 제공하는 유형 Many, including O’Reilly, SpringSource(VMWare), CUBRID, SULinux, 다우기술, 락플레이스
컨설팅 모델
(Consulting and Integration Strategy)
공급업체가 직접 어떤 오픈소스 소프트웨어를 제공하지 않지만 고객이 오픈소스와 관련된 전략적 의사 결정과 투자를 하는데 도움이 되어주고, 공급업체는 컨설팅 비용을 고객에게 청구하는 방식 IBM Global Services, Accenture, Gartner, 오픈소스컨설팅, OSBC
듀얼라이선스 모델
(Dual License Model)
공급업체는 GPL 또는 아파치와 같은 오픈소스 라이선스의 오픈소스 소프트웨어를 제공하기도 하고, 재판매가 용이한 상업적 지원이 필요한 고객을 위해 상용 라이선스로 동일한 소프트웨어를 제공
호스팅 서비스
(Hosted Service)
기업이 오픈소스 소프트웨어를 사용하여 고객에게 판매할 수 있는 서비스를 제공 Yahoo, Google, KTH, KINX
광고 모델
(Advertising Model)
공급업체가 제품을 구축할 때 오픈소스 소프트웨어를 사용하여 개발한 후 서비스(클라우드)로 제공하며, 해당 서비스의 사용자에게 광고를 게재 Google, NHN
강화된 상용SW
(Commercial Enhancement)
공급 업체는 적절한 라이선스를 선정하여 오픈소스 소프트웨어를 사용하고 상업적으로 제공할 수 있는 새로운 제품을 개발하여 판매하는 방식 EnterpriseDBand SRA OSS (PostgreSQL-based), 레드블럭
시스템 모델
(Embedding Model)
벤더 하드웨어 제품에 오픈소스 소프트웨어를 사용하여 제품을 판매해서 수익을 생성하는 유형 Cisco (Linksys routers), TiVo
후원 모델
(Patronage Model)
수익을 직접적으로 기대하지 않고 오픈소스 소프트웨어, 돈, 장비, 또는 커뮤니티를 위한 시간 등을 제공 IBM, Google, NHN
패키지SW
(Packaging Model)
공급 업체는 한 개 이상의 오픈소스 제품을 통합하여 스택을구성하고 공급업체의 지원, 교육, 컨설팅과 가치를 창출할 수 있는 스택을 함께 제공 OpenLogic, SugarCRM, OrangeHRM, plus many system integrator, Uengine

* 자료출처 : Building a Business on Open Source Software Anthony I. Wasserman Carnegie Mellon Silicon Valley Mountain View, CA 94035 USA

 

2.5. 소프트웨어 라이선스 정책수립

오픈소스를 활용한 솔루션 및 서비스별 비즈니스 모델을 확립하였으면, 다음 단계로 해당 솔루션 및 서비스별 라이선스 정책을 수립하여야 한다. 만약 상용 소프트웨어를 개발 및 판매하기 위해서는 해당 비즈니스 모델에 부합하게 상용 라이선스 정책을 수립하고 오픈소스 활용 시 해당 오픈소스에 적용된 라이선스 조건과 양립성을 확인해야 한다. 반면에, 오픈소스로 공개하기 위해서는 반드시 라이선스와 함께 소스코드를 공개해야 함에 따라 공개하는 오픈소스의 라이선스와 사용된 오픈소스의 라이선스의 양립성을 확인하여야 한다. 아래 [그림 4]는 비즈니스 모델에 부합된 라이선스 정책수립 단계를 제시하고 있다.

 

솔루션 및 서비스별 라이선스 정책수립 단계

[그림4] 솔루션 및 서비스별 라이선스 정책수립 단계

 

2.6. 오픈소스 조직성숙도 5단계

 

조직의 전략에 따라 오픈소스를 사용 및 활용 또는 기여하기 위한 조직은 오픈소스의 사용 및 활용 또는 기여 정책에 따라 적절한 관리 활동을 수행하여야 한다. 오픈소스를 적절히 관리하고 있는지에 대한 조직성숙도는 그림 5와 같이 5단계로 분류될 수 있다. 이미 오픈소스를 사용하고 있지만 적절한 관리 활동이 수행되고 있지 않은 위험 노출 단계, 사용된 오픈소스 목록은 관리되고 있지만, 관련 정책 및 지침, 프로세스가 부재한 측정단계, 정책 및 지침, 프로세스에 따라 관리는 되고 있지만 매뉴얼 방식을 통한 관리로 효율적 거버넌스 체계가 수립되지 않은 관리단계, 오픈소스가 적절한 시스템 및 관리 절차에 따라 관리되고 조직내 커뮤니티를 통해 오픈소스 개발방식이 활성화 되고 있는 참여단계, 조직의 전략적 결정에 따라 외부 커뮤니티에 적극적으로 참여하며 오픈소스 생태계의 선순환을 구축하고 있는 활성화 단계가 조직성숙도의 5단계이다.

 

오픈소스 조직성숙도 5단계

[그림5] 오픈소스 조직성숙도 5단계

 

2.7. 오픈소스 거버넌스 현황진단

오픈소스 거버넌스를 추진하기 위해서는 먼저 우리의 조직이 오픈소스 조직성숙도 5단계 중 어느 단계에 있는지에 대한 현황진단을 수행하여 목표로 하는 조직성숙도 단계로 성장할 수 있도록 개선조치를 수행하여야 한다. 오픈소스 조직성숙도 현황진단은 오픈소스 발견, 검토와 선택, 공급망 관리, 코드 관리, 유지보수와 지원, 컴플라이언스 프로그램, 커뮤니티 상호작용, 의사결정자 검토의 8가지 관리 활동을 통해 수행될 수 있다. 그림 7은 현황진단 및 목표 단계로 성장하기 위한 갭분석 및 개선조치에 대한 이행 프로세스를 제시하고 있다.

 

오픈소스 거버넌스 조직성숙도 진단

[그림6] 오픈소스 거버넌스 조직성숙도 진단

 

2.8. 오픈소스 거버넌스 정책수립

오픈소스 거버넌스 구축에 있어 가장 중요한 단계는 관리 정책을 수립하는 것이다. 상기 현황진단과 조직 내·외부 환경 분석을 통한 목표 성숙도 단계로의 관리 활동을 수행하기 위해서는 조직의 임직원들이 공동의 목표와 이해를 통해 원활한 관리활동이 수행될 수 있도록 하는 명확한 관리 정책이 필요하게 된다. [표 2]는 일반적으로 검토될 수 있는 오픈소스 관리 정책의 예이다.

 

[표2] 오픈소스 거버넌스 정책 예시

정책예시 설명
오픈소스 사용 전사 소프트웨어에서의 오픈소스 사용 범위
소스 코드 공개 소스 코드 공개 범위, 자체 개발 커널 모듈, 자체 개발 펌 웨어, 소스 코드 공개 방법 등
라이선스 검증 검증 방법, 라이선스 별 조치 대상, 외부 오픈소스 라이선스 충돌의 해결,
외부 커뮤니티 활동 오픈소스 관련 외부 커뮤니티 활동을 지원하기 위한 사용 절차 및 주체 정책
커뮤니티 생성 및 운영 오픈소스를 위한 커뮤니티 수립 방안 및 이를 관리하기 위한 정책
오픈소스 라이프 사이클 또는 프로세스 오픈소스 도입에서 운영, 유지보수에서 폐기에 이르는 전체 라이프 싸이클을 관리하기 위한 절차
전사 R & R 오픈소스 라이프싸이클에서의 각 조직의 역할 및 책임 정립
오픈소스 평가 유사 항목에서의 우수 오픈소스를 선택하기 위한 평가 모델
오픈소스 교육 오픈소스를 도입, 사용하기 위한 교육
주요 라이선스별 적용 방안 오픈소스 라이선스별로 안전하게 사용 및 적용하기 위한 정책
조직별 오픈소스 활용 방안 조직의 특성에 따라 오픈소스를 도입, 개발 또는 유지보수하기 위한 정책
공급업체의 오픈소스 라이선스 의무 수행 오픈소스를 공급 받을시 공급업체로부터 받아야 하는 라이선스 준수 정책

 

2.9. 오픈소스 거버넌스 추진조직

오픈소스 거버넌스 정책에 반영될 수 있는 추진조직에 대한 R&R은 [표 3]과 같이 오픈소스 활용전략과 조직의 환경에 따라 법무, 개발, 운영, 마케팅, 재무/감사 부서 등과의 협업이 필요하며 다양한 부서와 임직원들의 참여를 통해 수행되어야 함에 따라 조직 전체에 대한 협의와 의사결정을 위해 오픈소스 검토위원회와 같은 협의체를 운영하는 것이 효율적이다.

 

[표 3] 오픈소스 거버넌스 추진 조직별 R&R(예)

조직 개요 및 R&R
오픈소스 검토위원회
(Open Source Review Board, OSRB)
오픈소스 정책 수행을 위한 핵심 기구
OSRB는 오픈소스사용에 대한 최후의 의사결정권한을 가지며 조직내 오픈소스사용에 대한 전문가 센터
OSRB는 조직 부서 및 구성원을 대표할 수 있는 대표자로 구성(법무, 개발, 운영, 마케팅, 재무 등)
법무(Legal) 라이선스와 계약 준수를 포함하여 법적 요구사항들을 준수해야 하는 조직의 제품과 솔루션에 대한 궁극적인 책임을 가지고 있음
개발
(Engineering/
Development)
개발부서는 실제로 오픈소스를 사용하고 오픈소스와 결합된 제품 및 솔루션을 창출하는 조직
어떤 오픈소스 컴포넌트들이 엔지니어링 프로세스에 포함되어 사용되어야 하는지에 대한 의사결정을 하는 그룹으로서 OSRB에서 매우 중요한 역할을 수행
운영
(Operations)
조직의 개발시스템 환경을 담당
이 그룹에 있어서 승인된 소프트웨어 스택의 구성은 매우 중요
개발 오픈소스 스택 및 컴포넌트가 내부적으로 사용된다면, 해당 소프트웨어 컴포넌트들이 승인되었는지 혹은 적절한 버전인지를 확인
개발 오픈소스 스택 및 컴포넌트가 외부 조직으로 서비스를 제공하는 데 사용된다면, 모든 소프트웨어 컴포넌트들이 라이선스 요구사항들을 준수하고 추적되고 있는지를 확인하는 것이 매우 중요
재무/감사
(Finance and/or Compliance)
경우에 따라 몇몇 조직들은 소프트웨어 스택 혹은 데이터 추적 준수사항들을 증명해야 되는 어떠한 규제 조건들을 따라야 할 경우가 있음
재무/감사 대표의 OSRB참여는 조직의 특정 상태에 따라 준법성이 적절히 준수되고 있음을 증명해야 하는 책임이 있음
마케팅(Marketing) 오픈소스 컴포넌트들과 결합된 제품 및 솔루션을 위한 사업계획뿐 아니라 해당 오픈소스 라이선스 의무사항을 준수하기 위한 모든 필요 속성들을 확인
마케팅 대표의 OSRB 참여는 오픈소스 의사결정에 대한 사업 영향에 대한 평가에 도움을 주고, 개발 그룹에서 생각하지 못하는 모든 요구사항을 준수할 수 있게 함
재무/감사
(Finance and/or Compliance)
경우에 따라 몇몇 조직들은 소프트웨어 스택 혹은 데이터 추적 준수사항들을 증명해야 되는 어떠한 규제 조건들을 따라야 할 경우가 있음
재무/감사 대표의 OSRB참여는 조직의 특정 상태에 따라 준법성이 적절히 준수되고 있음을 증명해야 하는 책임이 있음

 

2.10. 오픈소스 공급망 관리

소프트웨어 개발 생태계가 수많은 공급망을 구성하는 다양한 협력업체들과의 유기적 협력을 통해 구성되어 있는 만큼 오픈소스 거버넌스 범위에는 조직 뿐 아니라 다양한 공급망을 구성하고 있는 협력업체들도 포함되어야 한다. 이러한 공급망 관리를 위해서는 2020년 국제표준인 ISO 5230으로 등록된 오픈체인 2.1을 검토할 수 있다. 2016년 유럽의 한 오픈소스 콘퍼런스에서 퀄컴의 오픈소스 변호사인 데이브 머(Dave Marr)는 한 기업의 오픈소스 컴플라이언스 수준을 높이기 위해서는 소프트웨어 공급망 내의 모든 구성원이 오픈소스 컴플라이언스 수준을 높일 수 있도록 보장해야 함을 강조한 바 있다. 아울러 이를 위해서는 오픈소스에 대해 이해함과 동시에, 정책 및 프로세스를 앞서 구축하고 있는 기업들이 자신들의 자산과 노하우를 공개해 누구나 이를 참고할 수 있게 해야 한다는 의견을 제시했다. 콘퍼런스 참석자들은 “오픈소스 컴플라이언스는 기업의 이익을 차별화할 수 있는 분야가 아니다. 기업은 최소한의 리소스를 투입하여 적정한 수준의 리스크 관리를 원하기 때문에 기업들이 가진 자산을 공유하면 할수록 적은 비용으로 컴플라이언스를 달성할 수 있다”는 아이디어에 공감했다. OpenChain 프로젝트(당시에는 Work Group)는 그렇게 시작됐고, 퀄컴, 지멘스, Wind River, ARM, Adobe 등 다수 글로벌 기업들이 참여했다. 지난 2020년 12월, 오픈소스 컴플라이언스에 대한 국제 표준이 ISO에 등록되었다. ISO/IEC 523018은 기업이 오픈소스 컴플라이언스를 달성하기 위해 수행해야 할 최소한의 요구사항을 정의하고 있다. NIPA에서 출간한 기업 공개 소프트웨어 거버넌스 OpenChain 해설서에서는 이에 대한 자세한 내용 및 준수 방법을 설명한다. 가이드는 다음 페이지에서 내려받을 수 있다. : https://www.oss.kr/oss_guide/show/7050bff0-d06b-43f0-99a6-9975afcd486f

 

오픈체인 로고

[그림7] 오픈체인 로고

 

OpenChain프로젝트는 곧 OpenChainSpecification 2.1을 제작하여 배포했다. OpenChainSpecification은 오픈소스 컴플라이언스를 위한 핵심 요구사항을 정의한 12페이지 분량의 표준 규격으로, 기업의 규모나 업종과 관계없이 모든 분야의 회사에 적합하도록 고안되었다. 2019년 4월에는 버전 2.0의 규격(Specification)이 배포됐으며, 2021년에는 2.1을 배포하였다. 기업이 오픈소스 컴플라이언스 달성을 위해 꼭 수행해야 할 여섯 가지 주요 요건에 대한 설명과 기업이 이를 수행하고 있음을 입증할 수 있는 검증 자료 목록을 정의하고 있다. [그림 9]는 오픈체인 규격 원본이며 이를 번역하면 다음과 같다.

 

  • ⓵ 오픈소스 컴플라이언스를 관리하기 위한 프로그램
  • ⓶ 효과적인 리소스 제공을 위한 업무 정의 및 지원
  • ⓷ 오픈소스 검토 및 승인을 관리하는 프로세스
  • ⓸ 컴플라이언스 결과물 생성 및 제공을 위한 프로세스
  • ⓹ 오픈소스 커뮤니티 참여를 이해하고 관리하기 위한 정책
  • ⓺ OpenChain Specification 요건 준수

 

오픈체인 규격(원본)

[그림8] 오픈체인 규격(원본)
* 자료출처 : https://wiki.linuxfoundation.org/_media/openchain/openchainspec-2.0.pdf

 

2.11. 오픈소스 관리 프로세스

오픈소스 거버넌스 정책에 반영할 프로세스는 소프트웨어 개발 라이프사이클과 여러 관리활동이 유기적으로 운영될 수 있도록 조직의 전략, 정책, 관련 부서, 시스템 및 도구 등에 대한 정의와 역할 및 책임이 명확히 프로세스에 반영되어야 한다. [그림 9]는 Ibrahim Haddad가 제시하고 있는 오픈소스 거버넌스 프레임워크의 프로세스이다.

 

오픈소스 거버넌스 프레임워크
오픈소스 거버넌스 프레임워크

[그림9] 오픈소스 거버넌스 프레임워크
* 자료출처 : OpenSourceComplianceHandbook_2018_2ndEdition_DigitalEdition, IBRAHIM HADDAD, PHD

 

2.12. 오픈소스 보안취약점 관리 필요성

오픈소스 거버넌스에는 라이선스 관리 뿐 아니라 보안취약점에 대한 관리가 포함되어야 한다. 오픈소스 보안취약점은 알려진 취약점에 대한 일반 코드 보안과 달리 알려지지 않은 보안취약점에 대한 패치를 주 관리대상으로 하고 있다. 문제는 오픈소스 사용패턴이 다양하기 때문에 조치 방법 또한 사용패턴에 부합되게 조치되어야 한다. [그림 10]은 다양한 오픈소스 사용 패턴에 따른 조치방법의 예이다.

오픈소스 사용 패턴에 따른 조치방법

[그림 10] 오픈소스 사용 패턴에 따른 조치방법

 

2.13. 오픈소스 보안취약점 관리 프로세스

오픈소스는 생태계 특성상 버전별로 보안취약점이 발견되었다가 패치되는 순환을 하고 있기 때문에 조직에서 오픈소스를 사용 및 활용하는 생태계에 따라 조직의 자산에 대한 관리 우선순위와 이행계획을 수립하여 보안취약점을 적시에 발견하고 패치할 수 있는 정책 및 프로세스가 필요하다. [그림 11]는 오픈소스 보안취약점 관리 프로세스의 예이다.

 

오픈소스 보안취약점 관리 프로세스

[그림 11] 오픈소스 보안취약점 관리 프로세스

3. 결론

본 글에서는 조직에서 오픈소스를 활용한 기회와 함께 반드시 고려해야 할 위험 요인에 대한 예방을 위해 필요시 되는 오픈소스 거버넌스 수립을 위해 오픈소스 거버넌스 개념과 단계별 구성요소를 소개하였다. 먼저, 오픈소스 활용 및 기여 시 가장 기본적이면서도 중요한 오픈소스 라이선스 및 의무사항에 대한 이해와 사용정책 수립의 필요성과 함께 오픈소스 활용 대상인 솔루션 및 서비스별 비즈니스 모델 검토와 라이선스 정책수립의 필요성 및 방법을 소개하였다. 또한, 조직내 오픈소스 조직 성숙도 5단계 제시를 통해 현황진단 및 정책, 추진조직, 공급망관리, 프로세스 구축에 대한 필요성과 사례를 소개하였고 마지막으로 보안취약점 관리 필요성과 프로세스 사례를 소개하였다.

본 글에서 제시한 오픈소스 거버넌스 추진을 위한 단계 및 구성요소는 오픈소스를 활용한 소프트웨어 개발 조직이 일반적으로 검토할 수 있는 오픈소스 거버넌스 추진내용이며 조직의 오픈소스 사용 및 활용 또는 기여 현황과 특성에 따라 선별적으로 적용 및 활용할 수 있다. 본 글이 오픈소스를 적극적으로 활용하여 소프트웨어 경쟁력 향상은 물론, 시장을 선도하기 위한 많은 조직에게 오픈소스 거버넌스 구축 필요성과 전반적인 추진내용을 이해하는 데 도움이 되기를 바란다.

 

 

.
.
2021
공개SW 가이드/보고서 - 번호, 제목, 작성자, 조회수, 작성
번호 제목 작성자 조회수 작성
공지 [2024년] 오픈소스SW 라이선스 가이드 개정판 발간 file support 9076 2024-01-03
공지 [2024년] 기업 오픈소스SW 거버넌스 가이드 개정판 발간 file support 7102 2024-01-03
공지 [2024년] 공공 오픈소스SW 거버넌스 가이드 개정판 발간 file support 7016 2024-01-03
공지 공개 소프트웨어 연구개발(R&D) 실무 가이드라인 배포 file support 19631 2022-07-28
공지 공개소프트웨어 연구개발 수행 가이드라인 file OSS 18154 2018-04-26
396 [8월 월간브리핑] 메타버스 열풍 속 오픈소스 프로젝트 새로운 성장동력으로 기대 support 2314 2021-08-24
395 메타버스로 날개 단 오픈소스 프로젝트 support 6001 2021-08-23
394 [7월 월간브리핑]오픈소스 유니콘 기업 출연으로 OSS 인식전환 및 국내 창업 생태계 확산 기대 1 support 1904 2021-07-27
393 오픈소스로 유니콘 기업이 되다 support 3085 2021-07-27
392 [기고]오픈소스로 여행해보려는 창업가를 위한 안내서 support 2339 2021-07-27
391 [6월 월간브리핑]정부 소프트웨어 혁신안, 신기술 경쟁력 확보 위해 공개소프트웨어 지원 확대 support 1727 2021-06-28
390 [기고] 오픈소스 거버넌스 구축을 위한 단계 및 구성요소 support 6713 2021-06-28
389 [5월 월간브리핑]미래자동차를 위한 혁신과 오픈소스 기술 support 2509 2021-05-21
388 자동차의 미래와 오픈소스 support 4181 2021-05-21
387 오픈소스로 지구를 깨끗하게 만든다. support 4421 2021-05-21
맨 위로
맨 위로