...

표 1 일반SW R&D와 공개SW R&D의 차이점

구분	일반SW R&D	공개SW R&D
개발 조직	주관기관 및 참여기관 개발조직으로 구성	주관기관 및 참여기관 개발조직(핵심 개발자), 프로토타입 공개 이후에는 자생적 코어 개발자 그룹과 커뮤니티로 조직 구성
분석 설계	과제의 규모에 따라 다르며, 주관기관의 개발 프로세스에 따른 분석 및 설계 과정	과제의 규모에 따라 다르며, 주관기관의 개발 프로세스에 따른 분석 및 설계 과정, 프로토타입 공개 이후에는 공식적인 분석, 설계 과정이 없으며, 코어 개발자 사이의 커뮤니케이션, 초기 소스의 스냅샷 릴리즈와 커뮤니티의 리뷰를 통한 간접적인 분석 설계
구현 리뷰 시험	선정된 개발팀에 의한 독자적인 개발 혹은 부족한 부분에 대한 위탁 개발. 주관기관의 개발 프로세스에서 정한 방식에 따라 조직 내부에서의 리뷰 및 시험, 과제의 요구에 따라 시범 사업에 의한 실제 환경에서 시험	코어 개발자 주도의 개발 및 내부 리뷰, 시험이 진행되며, 분석, 설계 단계와 마찬가지로 프로토타입 공개 이후의 모든 구현 결과 또한 공개되고 커뮤니티의 리뷰, 시험
릴리즈	과제 성격에 따라 매우 다양하나, 거의 소스를 공개하지 않음	일부 혹은 모든 소스 코드 및 문서가 해당 프로젝트가 채택하고 있는 라이선스에 따라 공개됨
평가	독립적인 평가위원회에 의해 기획 단계와 주관기관 선정 당시에 정의된 과제 목표와 성과를 비교하는 방식으로 평가	정부 발주 과제 평가는 일반 R&D와 동일하며, 일반적인 공개SW의 경우 공식적인 평가는 없으며 커밋 수, 다운로드 수, 민간 및 산업 활용, 커뮤니티 사용자에 의한 간접 평가
지원	과제 성격, 주관기관의 정책에 따라 다름	추가 기능 요구, 버그 리포트, 문서화 등이 커뮤니티에 의해 지속적으로 요청되고 지원 또한 커뮤니티에 의해 이루어짐. 새로운 소스 코드가 코어 관리자 그룹에서 새로운 릴리즈 형태로 다시 공개됨

3. 공개SW R&D 과제의 성장 단계

공개SW 연구개발과제는 결과물의 기술이전을 통해 사업화로 이어지던 기존의 연구개발 과제와 다르게 연구개발 결과물 공개단계와 연구개발 결과물 활용 확산을 위한 관리 및 지원 체계구축 단계로 발전하게 되는 특징을 가지고 있다.

그림 2 공개SW 연구개발과제 성장 단계

연구개발 결과물 공개단계는 공개SW 개발방식을 채택하여 연구개발을 수행하고 외부 기여자의 활용을 돕는 환경을 조성하여 개방형 혁신 연구개발 방식의 효율성을 극대화하는 과정이다. 이 과정에서는 공개SW 연구개발 결과물의 공개에 필요한 소스 코드 저장소 관리, 소프트웨어 형상 관리, 소프트웨어 배포 관리, 소프트웨어 품질 관리 등 다양한 활동을 수행하게 되며 공개SW 라이선스 및 보안 취약점의 검토 및 보완이 주로 수행된다.

...

2장. 공개SW　R&D 수행 가이드

1. 공개SW R&D 과제 수행 준비

가. 관리 정책 수립

공개SW 연구개발 과제의 수행자는 과제를 공개SW 방식으로 진행하는데 필요한 관리 정책을 수립하고 참여연구원 전원과 공유해야 수행과정에서 이슈가 있는 경우 참여연구원이 명확하게 대응할 수 있다.
과제 관리를 위한 정책이 조직 내부의 전사 정책으로 있는 경우는 전사 공개SW 관리 정책을 준수하면 되지만, 국내 대부분의 공개SW 연구개발 과제 수행자의 경우 공개SW 관리 정책이 제대로 갖춰지어 있지 않은 상황이므로 이 경우에는 다음과 같은 항목을 위주로 과제 수행에 적합한 정책을 수립하고 참여연구원 모두 수시로 확인할 수 있도록 공유되어야 한다.

...

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

나. 수행 조직 구성

공개SW 연구개발과제의 수행에 필요한 조직은 다음과 같이 각 부문의 전문성을 제공할 수 있는 전담 조직으로 구성되어야 한다. 마이크로소프트, Salesforce 같은 기업은 전사적으로 공개SW 전략을 일관되게 구현할 수 있도록 잘 정의된 정책 및 프로세스를 개발하는 조직으로 OSPO(Open Source Program Office) 조직을 구성하고 있으며, 국내 대표적인 연구기관인 한국전자통신연구원(ETRI), LG전자, 삼성전자 등의 기업들도 전사적으로 공개SW 전략을 명확하게 전달하고 전략 실행을 감독하여 효과적인 공개SW 사용 촉진을 목적으로 하는 전담 조직을 구성하고 있다.

...

조직	설명
공개SW 검토위원회	공개소프트웨어 정책 수행을 위한 핵심 기구
법무	라이선스와 계약 준수를 포함하여 법적 요구사항들을 준수해야 하는 조직의 제품과 솔루션에 대한 궁극적인 책임
개발	개발부서는 실제로 공개소프트웨어를 사용하고 공개소프트웨어와 결합한 제품 및 솔루션을 창출하는 조직
운영	조직의 개발시스템 운영 환경을 담당
마케팅	공개소프트웨어 컴포넌트들과 결합한 제품 및 솔루션을 위한 사업계획뿐만 아니라 해당 공개소프트웨어 라이선스 의무사항을 준수하기 위한 모든 필요 속성들을 확인하는 기구
재무/감사	조직의 특정 상태에 따라 준법성이 적절히 준수되고 있음을 증명해야 하는 책임

다. 개발환경 구축

공개SW 연구개발과제는 수행 컨소시엄 간의 협업뿐만 아니라 외부 기여자들의 과제 참여가 가능하도록 다음과 같은 개발환경을 구축해야 한다.

공개SW 연구개발과제 워크플로우(브랜치 전략)
소프트웨어 소스 코드 저장소(Github, Gitlab, Bitbucket 등)
소프트웨어 형상 관리 도구(Mantis, Jira, Github 등)
소프트웨어 테스트 자동화 도구(Catch, Junit, unittest 등)
소프트웨어 보안 취약점 점검 도구(Veracode Greenlight, Synopsys Code Sight 등)
소프트웨어 릴리즈 관리 도구(Travis, Hudson, Bamboo 등)
공개SW 라이선스 검증 도구(올리브, FOSSology, CodeEye, Clarity 등)
공개SW 라이선스 컴플라이언스 도구(Fosslight, Fossa, SW360, Black Duck, SPDX 등) https://github.com/NIPA-OpenUP/oss-governance-guide/blob/main/oss-governance-guide.md
공개SW 연구개발과제 이슈 및 버그 관리 도구(Github, Gitlab, Jira 등)
참여형 문서 협업 도구(Wiki, Confluence 등)

그림 3 공개SW 연구개발과제 개발환경

라. 참여연구원 교육

공개SW 연구개발과제의 수행에 참여하는 연구원들은 기본적인 공개SW의 이해와 공개SW 개발방식의 전문성이 요구된다. 이를 위해서는 조직 내 별도의 내부 교육프로그램을 통해 지속적인 공개SW 개발역량 강화가 필요하며, 만약 별도의 내부 교육프로그램이 없는 경우에는 공개SW 소프트웨어 통합지원센터에서 제공하는 다음과 같은 다양한 교육과정을 통해 필요한 역량을 강화할 수 있다.

...

구분	개요	운영
공개소프트웨어 매니지먼트 전문과정	공개소프트웨어 매니저 전문가 양성을 위한 선발제 집중 교육과정 운영	선발제
		10주 교육
공개소프트웨어 일반 교육과정	신청자(기업/기관/개인)의 수준에 따라 맞춤형 단기 교육과정 운영	신청시
		수시 교육
공개소프트웨어 기타 교육 지원	공공 SW사업 수발주자 및 공개SW 개발자대회 참가자 대상 라이선스 교육 지원	지정 일정
		11회 교육

2. 공개SW R&D 과제 분석

가. 요구분석 및 조사

공개SW 연구개발과제의 결과물이 모든 소프트웨어를 자체 개발하는 경우에는 소프트웨어 개발 프로세스의 첫 번째 단계인 요구분석은 일반적인 소프트웨어 개발과정(요구사항 도출, 요구사항 분석, 요구사항 명세)과 다르지 않다.
하지만 많은 연구개발과제는 외부의 라이브러리 또는 컴포넌트를 활용하는 경우를 포함하고 있으며, 만약 외부의 공개SW를 포함해서 개발하거나 외부의 공개SW를 개작하여 공개하는 유형의 과제의 경우라면 공개SW 조사, 분석, 평가, 계약의 활동이 추가로 필요하다.

...

그림 5 TensorFlow 와 Pytorch 공개SW 프로젝트 비교(Openhub.net)

나. 공개SW 분석 및 평가

이처럼 외부의 공개SW를 포함해서 개발하거나 외부의 공개SW를 개작하여 공개하는 유형의 경우라면 수행자는 조사한 다수의 공개SW 프로젝트의 속성과 커뮤니티 정보를 취합하여 해당 프로젝트의 성숙도와 적용성을 평가하는 과정을 통해 과제에 적합한 공개SW 프로젝트를 선정하고 활용할 수 있다.

공개SW 프로젝트를 선정하는 경우에는 단순히 소프트웨어의 기능이나 성능 같은 항목으로 평가하기보다 일반적인 소프트웨어의 품질속성과 공개SW의 특성을 반영한 품질속성과 함께 과제의 이해관계자 요구사항을 반영하여 복합적으로 고려하여 평가하는 것이 필요하다.

...

그림 6 외부 공개SW 활용을 위한 프로젝트 평가 예

공개SW 성숙도 및 적용성 평가 표준(한국정보통신기술협회)은 공개SW의 평가를 위해서 필요한 속성과 척도를 정의하고 평가항목을 정량화시켜 기능성, 이식성, 신뢰성, 사용성, 유지 보수성, 커뮤니티 영속성 등 공개SW의 수준과 가치를 평가하는 방법을 제공하므로 공개SW 연구개발과제의 수행자가 외부의 공개SW 성숙도를 평가하거나 자신이 공개할 과제에 대한 객관적 평가의 지표로 참고할 수 있다.

...

그림 7 공개SW 성숙도 및 적용성 평가 표준(한국정보통신기술협회)

공개SW 성숙도 및 적용성 평가 지침(TTA.KO-11.0133)은 ISO 9126의 일반적인 소프트웨어 품질요소와 공개SW 특성을 반영한 품질요소가 추가된 구성으로 국내에서 널리 사용되고 있는 전자정부 표준프레임워크의 공개SW 프로젝트 선정에도 사용된 지침이므로 신뢰할 수 있는 자료이다.

...

URL : https://openchain-project.github.io/OpenChain-KWG/guide/i-openchainproject

3. 공개SW R&D 과제 설계

가. 공개SW 연구개발과제의 소프트웨어 설계 방식

외부 기여자가 참여하여 소프트웨어의 개발이 이루어지는 공개SW 연구개발과제의 설계는 개발 영역을 나누어 개발자가 의사소통이 쉽게 이루어질 수 있도록, 소프트웨어 소스 코드의 응집도가 낮게 모듈화하는 설계를 고려해야 한다. 이런 설계는 각 기능 모듈이 다른 모듈에 영향을 주지 않고 개발을 할 수 있게 하며, 실험적인 코드들이 안전하게 수용될 수 있는 특징이 있다.

...

그림 8 모노리틱 아키텍처와 마이크로서비스 아키텍처의 비교

마이크로서비스는 분산형 개발을 통해 같은 애플리케이션 개발에 더 많은 개발자가 동시 참여할 수 있으므로 개발에 드는 시간을 단축할 수 있으며 여러 가지 프로그램 언어로 개발되고 서로 API를 사용하기 때문에 개발자들은 필요한 기능에 맞는 최적의 언어와 기술을 자유롭게 선택할 수 있는 장점이 있다.

나. 공개SW 연구개발과제의 소프트웨어 재사용에 대한 접근

수행자는 공개SW 연구개발과제의 설계 단계에서 공개한 소프트웨어가 재사용 될 수 있도록 모듈라 방식, 플러그인 아키텍처, 마이크로서비스 아키텍처 등 소프트웨어를 쉽게 확장할 수 있도록 설계하는 것이 중요하며, 일반적으로 소프트웨어 재사용을 위한 작업은 추상화(abstraction), 저장(storage), 재구성(recontextualization)의 세 단계를 통해 수행한다. (Essentials of Systems Analysis and Design, Joseph S Valacich, University of Arizona, Joey F. George, Iowa State University, 2015)

추상화(abstraction)는 기존의 소프트웨어 자산이나 소프트웨어 개발 첫 단계로부터 재사용이 가능한 소프트웨어 부분들을 정하는 것을 의미하며, 이 과정에서 공개SW 연구개발과제 수행자는 모든 소프트웨어를 직접 개발할지 또는 외부에서 획득한 공개SW를 활용할지를 결정하게 된다.

저장(storage) 단계는 사용자가 공개한 프로젝트에서 원하는 소프트웨어 기능들을 쉽게 찾을 수 있도록 결과물을 구성하는 소프트웨어 코어 부문, 확장 가능한 플러그인 부문 등으로 구분하고 각 부문의 주요 기능에 대하여 상세히 기술하는 과정이다.

마지막으로 공개한 프로젝트의 기능을 재사용하고자 하는 개발자가 이해할 수 있는 형태로 만드는 재구성(recontextualization) 작업을 통해 결과물의 재사용성은 개선될 수 있다. 플러그인 개발을 따라 할 수 있는 플러그인 개발 가이드라인 또는 API 활용을 돕는 API 활용 가이드라인 등의 문서를 추가로 준비하여 공개하고, 소프트웨어 데모나 플러그인을 쉽게 활용할 수 있는 플러그인 저장소 등을 구축하여 결과물의 활용을 적극적으로 지원할 수도 있다.

4. 공개SW R&D 과제 구현

가. 공개SW R&D 과제의 개발 방법론

공개SW 연구개발과제의 초기 단계는 외부 기여자와 협업이 없으므로 일반적인 소프트웨어 개발 방법론을 적용하면서 진행할 수 있지만, 결과물을 공식적으로 공개한 이후에는 다음과 같은 방식으로 개발이 진행된다.
공개SW 연구개발과제는 이처럼 외부 기여자의 이슈나 소스 코드 개선 요청을 상시 수용하면서 릴리즈를 관리해야 하므로, 점진적 개선이 가능한 XP, 스크럼, 칸반 등의 애자일 개발방법론을 적용하는 것이 좋다.

...

만약 외부의 공개SW 프로젝트를 활용하여 과제에 사용한 경우에는 업스트림(가지고 온 원래 프로젝트)에 기여하는 절차를 개발과정에 포함하는 것이 필요하다. 그냥 발견한 공개SW를 다운로드 후 과제에 사용하기가 더 쉬워 보일 수 있지만, 다음과 같은 이유로 업스트림에 기여하는 것이 더 유리하다. (https://github.com/todogroup/ospo101)

업스트림 프로젝트에 변경사항을 통합하면 완제품을 만드는 데 드는 노력이 줄어든다.
변경사항을 업스트림에 통합하면 다른 사람들이 변경사항을 인식하고 이에 대한 계획을 세울 수 있다.
제출한 변경사항에 대해 업스트림 프로젝트에서 기여자의 자원 활용(리뷰 또는 개선)이 가능하다.
자신의 코드가 우발적으로 파손될 위험이 감소한다.
업스트림 프로젝트와 호환되지 않는 로컬 변경을 수행하는 경우 해당 문제를 수정하는 데 시간과 자원이 더 소요된다.
업스트림 프로젝트에 기여는 향후 프로젝트 방향에 영향을 줄 기회를 제공한다.

그림 10 공개SW 프로젝트의 업스트림 개발 과정

나. 공개SW R&D 과제의 소프트웨어 형상 관리

공개SW 연구개발과제의 수행자는 소프트웨어 소스 코드의 형상을 관리하기 위한 도구를 준비하고 어떤 브랜치 전략으로 과제를 수행할지, 커밋 메시지를 작성하는 표준은 어떻게 할지 등을 결정하고 참여하는 모든 연구원이 이 절차를 준수하도록 관리해야 한다.
최근의 대부분 공개SW 프로젝트는 형상 관리 도구로 git을 사용하며 소스 코드 저장소는 github을 사용하며 gitlab 이나 bitbucket을 사용하여 과제를 위한 환경을 직접 내부에 구축하여 운영하기도 한다.

...

커밋 메시지는 크게 제목, 본문, 꼬리말 세 가지 부분으로 나누고, 각 부분은 빈 줄을 두어 구분하여 작성하자.

type : 어떤 의도로 커밋을 했는지 알 수 있도록 type에 명시.
subject : 최대 50글자가 넘지 않도록 하고 마침표는 찍지 않는다. 영문으로 표기하는 경우 동사(원형)를 가장 앞에 두고 첫 글자는 대문자로 표기.
body : 긴 설명이 필요한 경우에 작성. 어떻게 했는지가 아니라, 무엇을 왜 했는지를 최대 75자를 이내로 작성.
footer : issue tracker ID를 명시하고 싶은 경우에 작성.

그림 13 커밋 메시지 구조

이런 규칙을 적용하여 커밋 메시지를 작성하면 다음과 같이 작성할 수 있다.

그림 14 커밋 메시지 작성 예

다. 공개SW R&D 과제의 이슈 관리

공개SW 연구개발과제의 이슈 관리는 일반적인 소프트웨어 개발의 이슈 관리와 같이 다양한 이슈 관리 도구(Bugzilla, redmine, Jira, github, Gitlab 등)를 이용해서 진행된다. 일반적인 소프트웨어 개발과 차이점은 이슈를 등록하는 역할이 내부 개발팀의 연구원이 아니라 공개된 프로젝트를 사용하는 외부 사용자일 수 있으므로 이슈 관리를 통해 연구개발과제의 진행 과정이 투명하게 남는 점이다.
공개SW 연구개발과제의 수행자는 등록되는 이슈에 대하여 다음과 같은 절차를 준비하고 각 절차의 담당자를 배정하여 수행해야 한다.

...

이슈 관리 시스템은 사전에 정의된 이슈 템플릿을 생성하는 기능, 이슈의 유형을 식별하는 레이블 자동생성, 이슈의 담당자 지정 등 다양한 기능을 제공하고 있으므로 공개SW 연구개발과제의 수행자는 참여연구원 전체가 사용하는 이슈 관리 도구의 사용법을 미리 숙지할 수 있도록 교육하고 효율적으로 운영하는 것이 필요하다.

그림 15 이슈 템플릿 기능의 예

라. 공개SW R&D 과제의 릴리즈 관리

공개SW 연구개발과제의 결과물을 배포하기 위해서는 개발된 프로그램 소스 코드와 배포용 바이너리 파일을 함께 포함하여 배포하는 것이 일반적인 배포방법이다. 깃허브의 경우 소스 코드와 빌드된 바이너리 파일을 함께 포함하여 온라인에서 쉽게 릴리즈 할 수 있는 도구를 제공하고 있으며 다음과 같이 사용할 수 있다.

...

그림 18 Github Action을 이용한 지속적 통합 배포 환경의 구성 예

5. 공개SW R&D 과제 검증

가. 공개SW R&D 과제의 테스트

지속적 통합 환경을 구축하면 개발자가 Git 같은 버전 관리 제어 시스템을 사용하여 공유된 소스 코드 저장소에 빈번하게 변경내용을 병합하게 된다. 각 커밋에 앞서, 개발자는 통합 전에 검증을 위해 소스 코드에 단위테스트를 수행할 수 있다.

...

그림 19 코드 커버리지(Code Coverage) 보고서 예

나. 공개SW R&D 과제의 성과지표 관리

과제 수행자는 공개SW 연구개발과제를 제대로 평가하기 위해 공개SW 특성을 반영한 성과지표를 선정하고 관리하는 과정이 요구된다. 공개SW 연구개발과제의 성과지표를 구성하는 과제 수행자는 일반적인 연구개발과제에서 사용하던 소프트웨어의 성능 및 기능의 목표와 함께 공개할 과제 결과물의 공개SW 프로젝트 성숙도를 표현할 수 있는 다양한 지표를 추가하여 관리하는 것이 필요하다.

...

속성	변환 공식	적용 방법
나이 및 규모	변수 = {버전 번호, 연령} 지표 = 최종 버전 번호 x 나이 1 점: 0 <= 지표 < 12 2 점: 12 <= 지표 < 24 3 점; 24 <= 지표 < 72 4 점: 72 <= 지표 < 180 5 점: 180 <= 지표	지표는 최종 버전 번호와 월 단위의 커뮤니티 나이를 곱해서 산출함 버전 번호가 1.0 이상이고 커뮤니티 나이도 12개월 이상이 되어야 자생력이 있는 커뮤니티로 인정함 버전이 3.0 이상이고 연수가 5이상이면 최상위 수준으로 인정함
주체	변수 = { 후원 단체 유무} 1 점: 지원 없음 2 점: 하나의 중소기업 지원 3 점: 복수의 중소기업 지원 4 점: 하나의 대기업의 지원 5 점: 복수의 대기업의 지원	인력 및 자금에 대한 후원 단체의 유무로 측정함
접근성	변수 = {게시판, 포럼, 위키, 검색성, 인터넷} 지표 = 제공하는 접근방법의 종류 / 전체 접근방법의 종류 개수 1 점: 0.0 <= 지표 < 0.2 2 점: 2.0 <= 지표 < 0.4 3 점: 4.0 <= 지표 < 0.6 4 점: 6.0 <= 지표 < 0.8 5 점: 0.8 <= 지표 <= 1.0	전체 접근 방법의 종류 개수 = 5 1. 게시판 운영 2. 포럼 운영 3. 위키 운영 4. 인터넷 검색 시 첫 페이지 출력 5. 인터넷 사이트에서 정보 제공 외부에서 커뮤니티로 연락하거나 관련 정보를 얻을 수 있는 용이성 공개SW 커뮤니티에 대해 전문 정보를 제공하는 인터넷 사이트로는 ohloh.net, wikipedia.org 등이 있음
성숙성	변수 = {기간, 버전 출시, 관리 체제, 평가방법, 위원회 운영} 지표 = 충족하는 성숙지표의 종류 / 전체 성숙 지표의 종류 개수 1 점: 0.0 <= 지표 < 0.2 2 점: 2.0 <= 지표 < 0.4 3 점: 4.0 <= 지표 < 0.6 4 점: 6.0 <= 지표 < 0.8 5 점: 0.8 <= 지표 <= 1.0	전체 성숙 지표의 종류 개수 = 5 1. 최초 버전 출시 이후 3년 이상 지속적으로 신규 버전 출시 2. 최근 배포한 안정된 버전의 넘버가 1.0 이상 3. 관리 운영자(maintenance operator), 커미터(심의자), 개발자 등의 운영 체제 확립 4. 기여도 및 참여도에 따른 개발자의 등급 체제 확립 5. 이사회 운영 - 개인의 독단적 판단이 아닌 위원회에 의한 의사결정 방식

다. 공개SW R&D 과제의 라이선스 검증

공개한 수행자는 공개SW 연구개발과제의 라이선스 의무사항을 제대로 준수하고 있는지 검증하고 보완하기 위하여 소프트웨어 출시 전 반드시 검증 절차를 거쳐야 한다. 특히 과제 결과물에 위탁/용역 등 외부공급을 통해 포함된 소프트웨어가 존재하는 경우에는 해당 부문의 소프트웨어 결과물에 대한 공개SW 라이선스 검증을 필수로 수행하여 라이선스 의무사항의 위반이 없는지 확인하는 것이 중요하다.

...

그림 23 정보통신산업진흥원의 라이선스 검증 서비스

라. 공개SW R&D 과제의 보안 취약점 검사

공개SW 연구개발과제는 직접 개발한 소스 코드와 외부의 공개SW를 활용한 소스 코드가 함께 사용되어 외부로 배포되는 특징 때문에 보안 취약점에 대한 검사를 출시 시점에 1회 검사로 끝나는 방식이 아니라, 개발자의 개발환경부터 시작하여 소스 코드 저장소와 연동된 보안 취약점 검사 서비스를 연계하여 상시 보안 취약점이 검토되도록 다음과 같이 구성해야 한다.

...

그림 25 깃허브 소스 코드 정적 보안 검사 서비스

6. 공개SW R&D 과제의 커뮤니티 관리

가. 공개SW 커뮤니티의 이해

커뮤니티를 기반으로 형성되는 소프트웨어 개발에는 소프트웨어 릴리즈를 위한 활동을 중심으로 형성되는 개발자(공개SW 프로젝트) 커뮤니티와 공개된 소프트웨어에 대한 테스트, 버그에 대한 피드백, 신규요구사항, 의견제시 등을 중심으로 형성되는 사용자 커뮤니티가 존재하며, 이 두 커뮤니티의 상호 작용으로 지속적인 발전을 도모할 수 있다.

...

만약 공개SW 연구개발과제와 관련한 커뮤니티가 없어서 신규로 결과물 활용을 위한 기반으로 조성하기로 계획했다면 다음과 같은 준비가 필요하다.

나. 커뮤니티 거버넌스

커뮤니티는 자발적인 참여와 기여가 핵심 원동력이 되는 구조이므로 커뮤니티가 잘 유지되기 위해서는 커뮤니티 참여자를 어떻게 효과적으로 조직해낼 것인지의 문제를 해결해야 한다.

...

아파치 재단(Apache Foundation) : http://www.apache.org/foundation/governance/
이클립스 재단(Eclipse Foundation) : https://www.eclipse.org/org/documents/
SKT - HANU : https://github.com/openinfradev/community/blob/main/governance/README.md
하모니카 – Hamonize : https://github.com/hamonikr/hamonize/wiki/Governance

다. 커뮤니티 구성원의 고려사항

리눅스 재단(Linux Foundation)의 Todo Group에서 제시하는 공개SW 커뮤니티 참여를 위한 고려사항은 다음과 같다. https://github.com/todogroup/ospo101

...

작업 중인 내용 전달
커뮤니티를 위해 작업 중인 내용을 '비공개로' 작업하지 마십시오. '일찍 릴리스, 자주 릴리스'의 조언을 기억하십시오. 일반적으로 커뮤니케이션 채널을 확인하여 계획한 일이 이미 완료되었는지 확인하는 것뿐만 아니라 새로운 기능을 구축하거나 버그를 수정하려는 의도를 표시하여 커뮤니티(및 유지 관리자)가 기여를 수락하는 가장 좋은 방법을 계획하는 데 도움이 될 수 있습니다. 커뮤니티는 귀하가 성공하기를 원하므로 귀하가 기여를 준비할 때 도움을 받는 것이 좋습니다.

사용하는 사람과 자원을 인정
공개SW에 대한 기여는 대부분 다른 프로젝트의 코드를 포함하고 있습니다. 기여에 사용한 다른 작업/라이브러리/개발을 인정하고 커뮤니티가 전체 프로젝트에 도움이 될 수 있는 이러한 외부 자원도 찾도록 도와주세요.

커뮤니티에 환원
소스 코드의 명백한 기여 외에도 조직에서 하드웨어 선물을 주선하거나(가능한 경우) 팀을 위한 모임을 주선하거나 단순히 새 구성원을 위한 질문에 답하는 데 시간을 보내는 것과 같이 커뮤니티에 되돌릴 수 있는 다른 방법을 고려하십시오. 소스 코드는 확실히 중요하지만, 진정으로 성공적인 공개SW 프로젝트는 '코드가 아닌' 기여에서도 번창합니다.

출구 전략 계획
언젠가는 귀하의 조직이 커뮤니티를 종료해야 할 수 있습니다. 커뮤니티에 들어온 것보다 더 나은 상태로 커뮤니티를 떠나도록 노력하십시오. 이를 위해 할 수 있는 몇 가지 간단한 작업은 다음과 같습니다.

후임자 또는 코드를 인수할 사람 식별
그 후계자를 나머지 커뮤니티에 소개
귀하의 퇴장으로 인해 변경해야 할 사항에 대해 계획할 시간을 가질 수 있도록 가능한 한 빨리 커뮤니티에 알리십시오.
커뮤니티를 탈퇴하는 때도 귀하의 행동은 귀하 및/또는 귀하의 조직에 반영된다는 점을 기억하십시오.

라. 웹사이트 및 포럼

공개SW 연구개발과제의 결과물 확산을 위한 커뮤니티를 구축하기 위해서 처음 사용자를 위한 프로젝트의 소개를 담은 공식 웹사이트와 사용자와 개발자의 쉬운 커뮤니케이션이 가능한 게시판 형식의 포럼과 같은 커뮤니티 서비스 구축이 필요하다.
수행자는 과제 수행 환경에 따라서 직접 구축형(웹사이트 제작)으로 구성하거나 외부 호스팅 서비스(웹사이트 호스팅, github page 등)를 이용할 수도 있다.

마. 기여자 가이드라인

공개SW 연구개발과제의 수행자가 커뮤니티를 구축하는 경우, 우선 커뮤니티의 참여자들이 모두 볼 수 있도록 기여자 행동 강령 규약을 정의하고 분쟁이 일어나는 경우 어떻게 처리하는지 사전에 공표되어야 한다. (부록1. 기여자 행동 강령 규약 참고)

...

네이버 공개SW billboard.js 기여자 가이드라인 예 : https://github.com/naver/billboard.js/blob/master/CONTRIBUTING.md
카카오 공개SW buffalo 기여자 라이선스 동의서 예 : https://docs.google.com/forms/d/e/1FAIpQLSejX1wS1YCArZ7huZlKpuhWUWhGbLflOU93ZoTZiSR-ZPsm6w/viewform

바. 마일스톤 및 로드맵 공유

수행자는 외부 참여자가 공개SW 연구개발과제에 참여하는 결정을 하기 위해서 참고할 수 있도록 과제의 향후 마일스톤과 로드맵을 누구나 확인할 수 있도록 공개하는 것이 필요하다.
마일스톤 및 로드맵의 작성은 깃허브에서 제공하는 프로젝트 탭의 메뉴를 이용하거나 로드맵을 표시할 수 있는 별도의 문서 도구(Wiki, confluence 등)를 이용할 수도 있다.

사. 협력기업 관리

수행자는 공개SW 연구개발과제의 결과물을 확산할 수 있도록 공개한 소프트웨어를 사용하는 기업, 기술지원을 제공하는 기업, 교육이나 기타 서비스를 제공하는 기업을 커뮤니티의 멤버로 확보하고 참여기업들과 프로젝트가 함께 성장할 수 있도록 지속해서 파트너십을 관리해야 한다.

이를 위해서 협력기업 확보를 위한 다양한 온 오프라인 행사에 참여해야 하며, 협력기업의 솔루션 및 서비스를 적극적으로 홍보해야 하며, 주기적인 협의체를 운영하면서 협력기업의 비즈니스 전략을 커뮤니티에서 수용하는 태도가 필요하다.

아. 지적 재산권 관리

캐노니컬 재단(우분투)의 지적 재산권 안내문 : https://ubuntu.com/legal/trademarks

자. 모니터링

수행자는 외부 기여자의 참여 독려, 협력기업의 확보 또는 외부 홍보들에 사용할 수 있도록 프로젝트의 다양한 지표를 상시 확인할 수 있는 모니터링 환경을 준비해야 한다. 공개한 프로젝트의 다운로드 수, 커뮤니티 사용자 수, 일일 이슈 수 등의 다양한 지표를 별도의 대시보드로 구성하여 상시 프로젝트의 현황을 확인할 수 있는 체계를 구축하는 것이 좋다.

차. 홍보

단순히 결과물을 공개하는 것으로는 공개SW 프로젝트를 지속할 수 없으므로, 수행자는 공개SW 연구개발과제가 커뮤니티를 기반으로 지속할 수 있도록 다양한 채널을 통해서 결과물을 홍보해야 한다.

...

페이지 트리

버전 비교

이전 버전 5

새 버전 6

키

2장. 공개SW　R&D 수행 가이드