출연연의 공개소프트웨어 연구개발 프로젝트 관리

PBS 중심과제 수행기관(출연연)의
공개소프트웨어 연구개발과제 관리
1

강사 소개
현) 개방형 OS 하모니카 프로젝트 리더 / ㈜인베슘 대표이사
- 한국정보통신기술협회(TTA) 공개소프트웨어 표준화 분과위원
- 한중일 오픈소스활성화 포럼 표준화분과 한국위원
• 공개SW 분류 체계 및 프로파일: TTAK.KO-11.0110
• 공개SW 성숙도 및 적용성 평가 지침: TTAK.KO-11.0133/R1
• 공개SW 교환명세: TTAK.KO-11.0182
• 공개SW 거버넌스 프레임워크: TTAK.KO-11.0176
• 비공개SW의 공개SW 전환 가이드
• 오픈소스 소프트웨어 활성화를 위한 성숙도 및 적용성 평가모델 (OSMAAM)의 설계 및 구현에 관한 연구
• 공개SW Governance v1.0
• 공개SW 정보화전략계획(o-ISP)
• 오픈소스 기업의 서비스수준 평가모델
김 형 채
hckim@invesume.com
오픈소스 프로젝트 하모니카로 국민 누구나 사용할 수 있는 공개소프트웨어 운영체제를 무료로 공급하고 있으며,
국내 공공기관 및 기업의 개방형 OS 도입을 지원하여 공개소프트웨어 확산을 위하여 노력하고 있습니다.
2

오픈소스 프로젝트 - 개방형 OS 하모니카
일반 윈도우 데스크탑 사용자들이 개방형OS를 사용하는데 별도의 학습이 필요 없이 다양한 PC 사용 환경에서 사용할 수 있도록 범용성에 초점을
맞춘 데스크톱 운영체제 입니다. 하모니카는 오픈소스 소프트웨어 프로젝트로 운영되며 사용 중 개선점이 발견되는 경우 커뮤니티
(https://hamonikr.org)를 통해 누구나 프로그램의 개선에 참여할 수 있습니다.
하모니카는 기존의 윈도우 사용자에게 쉬운 사용성을 제공하기 위해 윈도우와 친숙한 인터페이스를 구성하였으며 오피스 프로그램, 백신, 이미지 편
집 프로그램, 웹 브라우저, 동영상 플레이어 등의 주요 프로그램을 포함하여 무료로 제공됩니다. 하모니카 OS는 글로벌 사용자들이 가장 선호하는
데스크톱 배포판을 기반으로 한글 키보드, 스마트폰, 프린터, 스캐너, 웹캠, 블루투스, 태블릿 등의 국내 실정에 맞는 다양한 주변기기를 사용할 수
있도록 지원하고 있습니다. 업스트림으로 Ubuntu 18.04를 채택하고 있으며 LTS(Long term support) 정책에 의해서 2028년 까지 하모니카 사
용자에게 주요 업데이트 및 보안 패치를 무료로 제공합니다.
타 분야 대비 공개소프트웨어 활용이 저조한 국내 운영체제 분야에서 누구나 사용할 수 있는 개방형 운영체제 하모니카OS를 무료로 제공하여, 현재
12만건 이상의 다운로드를 제공하였으며, 국방부, 경찰청 등 국내 22개 공공기관 및 지자체, 학교에 개방형 운영체제 이용환경을 제공
3

4

공개소프트웨어는 기술의 특성상 커뮤니티의 지속성이 가장 중요
한 요소이며, 자사는 국내에서 일반 사용자가 활용할 수 있는 공개
소프트웨어 커뮤니티가 유지하기 위하여 2015년부터 커뮤니티 전
담관리 인력을 배정하여 운영 중이며, 하모니카 커뮤니티
(https://hamonikr.org/)는 월간 평균 방문자 1만3천명 이상이
이용하고 있음
5

공개소프트웨어 역량강화 교육 및 컨설팅
서울대학교
오픈R&D
컨설팅
KAIST
오픈R&D
컨설팅
IITP
오픈R&D
역량강화교육
ETRI
오픈소스
거버넌스 교육
[오픈소스 역량강화 교육과정]
• 오픈소스SW 개요 및 오픈소스SW 라이선스
• 라이선스 컴플라이언스와 도구 활용(실습)
• 오픈소스 거버넌스 실무
• 오픈소스 개발방법론
• 오픈소스 프로젝트 실습
• 오픈소스 커뮤니티 구축 및 운영
• 오픈R&D 성과관리
6

1. 오픈소스 프로젝트 이해하기
7

오픈소스의 프로젝트의 특징
8
개방
참여공유
• 자동차 동호회 회원들이 모여여 취미로 만든 자동차 제작 프로젝트가
전세계 시장에서 현대기아차와 동등하게 경쟁한다면?
• 자본주의 경제에서 자본주의 교리와 반대되는 방식으로 성공
• 리눅스, 위키피디아의 경우 좋은 오픈소스 방식의 성공 사례
• 피라미드식 계층 구조가 없다
• 경제적 인센티브를 제공하지 않는다.
• 자발적인 구성원의 참여에 의존한다.
유다시티 자율주행자동차 : https://www.udacity.com/course/self-driving-car-engineer-nanodegree--nd013

성공한 개방형 협업 모델
9
오픈소스 협업 모델이 상업적 기업보다 뛰어날 수 있다는 걸 증명한 리눅스
1991년 공개된 커널 프로젝트. 이전에는 오픈소스 이더라도 핵심 개발자 집단이 개발 과정을 독점하고 완성도가 있다고 판단된 후에 소스를 공개하
는 방식을 사용했지만, 리눅스는 누구나 소스를 읽은 후 수정한 코드를 보낼 수 있도록 하고 수정한 코드가 받아들여지면 그 사람은 기여자
(Contributor)가 되어 다음 버전에 이름이 기재되어 배포되었다. 이 시스템이 묘한 과시욕을 충족시켰고, 개발자들은 돈을 받지 않고도 커널 버그
수정과 기능 추가에 매달렸고 점점 더 많은 사람들이 개발에 참여하게 되며 리눅스는 더 정교하게 발전했다. 28년이 지난 지금 리눅스는 서버와 모
바일에서 가장 많이 쓰이는 운영체제가 되었다. (안드로이드OS는 리눅스 커널, 전세계 슈퍼컴퓨터 500개의 90%는 리눅스 기반)
브리태니커를 밀어내고 오픈소스 협업 모델로 세계 최고의 사전이 된 위키피디아
1995년 워드 커닝햄은 텍스트를 읽는 그 자리에서 텍스트를 작성할 수 있는 방식의 위키를 개발하여 공개, 2001년 위키피디아는 소스코드 대신 지
식을 개방형 협업 모델로 생성하여 공유하는 서비스를 제공하여 현재 전세계에서 6번째로 방문자가 많은 웹사이트가 되었음. 현재 400 여개의 서버
가 운영되며 300명에 달하는 직원으로 운영 중. 매달 페이지 뷰가 150억 건 이상이지만 광고를 받지 않는 비영리 원칙을 고수하고 민간 기부와 연
간 모금활동에 힘입어 양호한 재무 상태를 유지하고 있음. (https://blog.lgcns.com/1175)

대세는 오픈소스
10
• 모든 IT 기업이 알파벳(구글), 아마존, 텐센트, 페이스북, 알리바바
들은 지난 10년에 새로이 순위권에 진입한 기업들로 텐센트를 제
외하고는 모두 깃허브에서 오픈소스 활동을 적극하고 있음
너도 나도 오픈소스를 도입하는 이유는 영리 기업들이 수십조의 연구개발비를 들여서도 만들지 못한
혁신을 오픈소스가 만들어내고 있기 때문
오픈소스 활동을 하는 대표적인 기업들 : https://www.datamation.com/open-source/35-top-open-source-companies-1.html

대표적인 오픈소스 프로젝트들
11
출처 : 공개소프트웨어 산업의 이해 – 소프트웨어정책연구소 2018.10

대표적인 오픈소스 프로젝트들
12
프로젝트 공개 년도 기간
Linux 1991 28
Apache 1995 24
VirtualBox 2007 12
MySQL 1995 24
Eclipse 2001 18
HYPERLEDGER 2015 4
Docker 2013 6
React 2013 6
Vscode 2015 4
TypeScript 2012 7
0
5
10
15
20
25
30
기간

오픈소스 프로젝트의 성공이란?
13
http://blog.newrelic.com/wp-content/uploads/Docker_Infographic_FINAL-1.jpg

14
http://blog.newrelic.com/wp-content/uploads/Docker_Infographic_FINAL-1.jpg

15
https://www.zdnet.com/article/docker-is-in-deep-trouble/
Docker needs more money.

16
https://royal.pingdom.com/ubuntu-linux-losing-popularity-fast-new-unity-interface-to-blame/
https://blog.linuxmint.com/?p=3736
Linux Mint는 매월 총 1,251 달러로 233 명의 후원자
2019년 2월 485 명의 기부자가 기부 총 11,225 달러 모금

스타트업이 실패하는 이유들
17
https://www.cbinsights.com/research/startup-failure-reasons-top/
제품·서비스 문제, 시장조사 소홀
스타트업이 실패하는 가장 큰 이유는 '시장이 원하지 않는 제품·서비스를 생산해서'인 것으로 파악됐다. 즉, 소
비자에 대한 철저한 분석 없이 창업자 자신이 원하는 제품·서비스를 만든 경우다. 보고서에 따르면 조사대상
중 절반에 가까운 스타트업이 이 원인으로 실패했다.
자금 부족
스타트업이 실패하는 두번째 이유는 '자금 부족'으로 나타났다. 보고서에 따르면 조사 대상 스타트업의 3분의
1이 자금이 부족해서 실패했다고 답했다. 보통 스타트업은 투자자의 관심을 계속 끌지 못하면서 자금을 조달에
실패, 결국 폐업 신고하는 경우가 일반적이다. 일부 스타트업은 지나치게 빨리 성장하면서 현금흐름(cash
flow)에 문제를 겪기도 한다.
인적 문제
스타트업이 필요한 인재를 구하지 못했거나 팀워크에 문제가 생겨서 실패하는 경우도 상당히 높은 것으로 조
사됐다. 또 사업을 진행하면서 인맥이나 멘토를 적절히 활용하지 못해 실패하는 경우도 있었다. 팀원이 아니라
창업자가 열정이 부족하거나 역경을 이기지 못해(탈진) 실패하기도 한다.

오픈소스 프로젝트의 성공 요인
18
시장과 커뮤니티가 원하는 소프트웨어
• 사용자를 최우선으로 고려해야 한다.
• 프로젝트를 이용하는 사람이 쉽게 활용할 수 있는 환경을 준비하고, 친절한 기술문서와 테스트 결과를 제공
• 오픈소스 프로젝트는 모든 사람이 보는 것이기 때문에 이 프로젝트를 처음 보는 사람도 잘 이해할 수 이슈 트레킹, 풀 리퀘스트, 이슈 레이블 기능,
마일스톤 기능 등을 이용해 프로젝트를 깔끔하게 정리해 둬야 한다.
지속 가능한 환경 확보
• 프로젝트를 홍보할 수 있는 다양한 방법 시도
• 오픈소스의 성공을 담보하기 위해서는 별도의 자금 관리가 필수
• 프로젝트 관련 기업들과 네트워크 구축 및 지원방안 마련
커뮤니티 관리 (기여자, 사용자)
• 시장과 커뮤니티의 현황을 파악하고, 제한 없는 의견을 수렴하여 투명한 의사결정 체계를 기반으로 프로젝트의 방향 수립에 반영
• 신규 사용자와 기여자를 소중하게 관리

출연(연) PBS 중심과제의 어려움
• 기관 설립 목적 및 고유의 임무 수행에 필요한 장기․기초연구보다는 단기적이며 가시적인 성과에 치중
• 연구책임자의 전문성 연구보다는 연구수주를 위한 대외활동이 증가함에 따라, 질 위주의 연구보다는 양 위주의 연구를 하는 부작용을 초래함
(연구책임자 1인당 다수의 연구과제를 수행하게 되어 전문분야의 심도 있는 연구수행이 곤란)
• 연구비 총액은 증가되었으나, 단기사업 위주의 조직운영이 이루어짐 으로서 기관 차원에서 인력, 시설, 연구비를 전략적으로 투입할 수 있는 재
량권의 부족
• 출연(연)이 국가 차원에서 필요한 연구사업에 대한 임무 또는 역할을 부여 받기 보다는 시장의 메카니즘(정부수탁)에 의거하여 운영되고 있어 출
연(연)의 장기적인 발전방향을 정립하는데 있어 한계
• 연구과제 수주를 쉽게 할 수 있는 경력직 연구원을 선호함으로써 신규 연구자의 육성이 어렵고, 또한 출연(연)을 신진 연구자들이 기피함에 따라
우수한 연구인력의 확보에 어려움
19
1년차
프로젝트 준비
2년차
연구개발
3년차
완료보고

2. PBS 중심과제에서 오픈소스 프로젝트 수행
20

참고 : 공개소프트웨어 거버넌스 프레임워크
21
공개SW활용 라이프사이클
순차적 공개SW거버넌스
활동요소 (18)
비 순차적 공개SW거버넌스
활동요소 (3)
TTAK.KO-11.0176 - 공개소프트웨어 거버넌스 프레임워크
공개 소프트웨어를 효과적으로 사용하기 위해서는 소프트웨어를 개발하는 내부 사용자 입장에서, 소프트웨어를 개발해서 외부로 배포하는 공
급자 입장에서 그리고 외부에 설치된 공개 소프트웨어에 대해서 기술 서비스를 제공하는 서비스 업체의 입장에서 적법성과 활용성을 점검

참고 : 오픈소스 라이선스 해설
22
도이치텔레콤의 소프트웨어 개발자 및 프로젝트 관리자들이 직면한 과제에 대응하기 위하여 작성된 문서로, 오픈소스 프로젝트의 다양한 유형
의 라이선스 사용 경우에 해야 할 일을 정리하여 실무적인 지침을 제공
https://www.oss.kr/oss_guide/show/7eba9fa1-af46-4b72-b7b0-3f5e8ab78e26

참고 : 공개소프트웨어 연구개발 수행 가이드라인
23
공개SW 연구개발 사업 또는 과제를 수주하거나, 수주된 사업을 수행하고자 하는
기관(기업)에서 알아야 할 절차 및 내용을 안내
연구개발 수행 중 공개SW 특성을 고려하여야 하는 부분을 중심으로 설명.

1) 오픈소스 프로젝트의 성과지표 설정
24

25
• 라이선스 정책
• 잘 동작하는 SW
• 프로그램 데모
• 프로그램 적용사례
• Third Party 도구 지원

26
• 프로젝트 문서
• 라이선스 관리
• 커밋과 버그 트래킹 관리
• 코드 관리 및 안정화
• 요구사항관리
• 프로젝트 로드맵 관리
• 기여자 관리
• 의사결정 절차

27
• 비즈니스 협의체 구성
• 공식 파트너사 관리
• 파트너 조직 전략 반영
• 기술지원 파트너 기업관리
• 목표 시장 홍보
• 다양한 적용 사례 제공

28
• 비즈니스 협의체 구성
• 공식 파트너사 관리
• 파트너 조직 전략 반영
• 기술지원 파트너 기업관리
• 목표 시장 홍보
• 다양한 적용 사례 제공

29

2) 오픈소스 프로젝트 수행에 필요한 팀 구성
30
담당자 수행 업무
총괄 책임자 목표관리, 기술검증, 의사결정
오픈소스 코치 라이선스, 커뮤니티, 성과측정, 거버넌스 등 지원
연구원(메인테이너) 소스코드 형상관리, 이슈관리, PR관리
연구원(컨트리뷰터) 개발, 테스트, 이슈트래킹
연구원(커뮤니티 매니저) 사용자, 개발자 가이드, 메일링리스트, 포럼 등
오픈소스 프로젝트에 대한 경험자 또는 교육 수료자로 포함된 팀을 구성하고 오픈소스 프로젝트에 필요한 각 구성원의 역할과 책임을 분장하는
수행체계를 구성 (오픈소스 코치, 커뮤니티 매니저, 파트너쉽 관리자 등)

31
R&R 수행 업무
오픈소스 코치
라이선스, 커뮤니티, 성과측정, 거버넌스
등 지원
연구원(커뮤니티
매니저)
사용자, 개발자 가이드, 메일링리스트,
포럼 등

32
R&R 수행 업무
오픈소스 코치
라이선스, 커뮤니티, 성과측정, 거버넌스
등 지원
연구원(커뮤니티
매니저)
사용자, 개발자 가이드, 메일링리스트,
포럼 등
• 오픈소스SW 개요 – 오픈소스 생태계, 오픈소스SW 라이선스
• 라이선스 컴플라이언스와 도구 활용 - 실습
• 오픈소스 거버넌스 실무 - 오픈소스SW 거버넌스 프레임워크의 실무 적용
• 오픈소스 개발방법론 – Agile, Scrum, Kanban
• 오픈소스 프로젝트 실습 - Github 이클립스, Git, 소스트리, DevOPS
• 오픈소스 커뮤니티 구축 및 운영 - 오픈소스 커뮤니티 거버넌스, 오픈소스
커뮤니티 구축,
• 오픈R&D 성과관리 - 성공적인 오픈R&D 로드맵, 오픈R&D의 핵심역량,
오픈R&D 성과관리
Open Source Product Operator 양성과정

3) 오픈소스 프로젝트 소스코드 개발 및 관리
33
프로젝트의 메인테이너를 중심으로 부문별 개발되는 소스코드의 형상을 관리하고, 소스코드의 라이선스를 정책에 적합하게 사용하고 있는지
검증한 후 사용자에게 필요한 문서를 포함하여 공개하고 관리
license framework 구성 예
오픈소스 프로젝트 소스코드 관리 절차 예

34
오픈소스SW 프로젝트 사이트
참여
활용
참여
활용
최종 결과물 배포
오픈 R&D 수행 컨소시엄
기업 연구소 대학
오픈 R&D 환경 구축
커뮤니티 구축, 운영
오픈 R&D 워크플로우
라이선스, 보안 검증

35
분산 버전 관리 시스템 (DVCS) branch-per-issue workflow

36
백로그 수정 / 정리 : 한 스프린트가 끝나면 팀과 제품 소유자가 만나서 다음 스프린트 준비가 되었는지 확인한다. 팀은 관련이 없는 사용자 스토리를 제거하거나, 새
로운 스토리를 작성하거나, 스토리의 우선 순위를 재평가하거나, 사용자 스토리를 작은 태스크로 분리 할 수 있습니다. 이 '그루밍'회의의 목적은 관련성이 높고 상세
한 항목을 포함하고 프로젝트의 목표를 충족시키는 항목 만 백 로그에 포함 되도록 하는 것입니다.
Daily Scrum meetings : Daily Scrum은 15 분간의 스탠딩 미팅으로 각 팀 구성원이 자신의 목표와 쟁점에 관해 이야기합니다. 데일리 스크럼은 매일 스프린트
중에 발생하며 팀을 계속 추적하도록 도와줍니다.
스프린트 검토 모임 : 각 스프린트가 끝날 때 팀은 스프린트 검토 회의에서 완료 한 작업을 제공합니다. 이 회의에는 보고서 또는 PowerPoint 프레젠테이션이 아닌
실시간 데모가 있어야 합니다.
Sprint 회고 : 각 스프린트가 끝날 때 팀은 Scrum이 얼마나 잘 작동하고 있는지 파악하고 다음 스프린트에서 변경해야 할 사항에 대해 이야기합니다. 팀은 스프린트
중에 무엇이 잘되었는지, 무엇이 잘못되었는지, 어떻게 다르게 할 수 있는지에 대해 이야기 할 수 있습니다.

37

38
Maintainer 활동
• 프로세스 문서화 - 사용자, 기여자, 개발자를 위한 최신의 문서를 제공
• 공평하게 작성되고 집행되는 규칙 준비 – 프로젝트의 유지관리 상태를 투명하게 공유
• 기여를 검토하고 수용하는 방법, 수락할 기여의 유형, 적절한 후속 조치, 프로젝트에 소요하는 시간 등
• 커뮤니케이션 공개 – 가능한 모든 커뮤니케이션을 공개
• 대화를 친절하게 유지
• 멘토링 수용 – 품질이 낮은 기여를 제출하는 경우 인내심을 가지고 기여할 수 있도록 지원
• 커뮤니티의 기여자 활용 – 공개적으로 필요한 요청을 제시하고 반복적인 기여자에게 더 많은 책임을 부여
• 다른 사람이 필요한 솔루션 구축을 지원 (API)
• 자동화 도구를 적극 활용 – 모든 제출에 대해 최소 품질 표준을 설정하고 코드 품질 향상을 위한 테스트를 자동화
• 릴리즈를 자동화 - https://github.com/semantic-release/semantic-release
• 위험 코드 검토를 자동화 - https://github.com/danger/danger
• 작성자가 추가 정보 요청에 응답하지 않은 문제를 해결. - https://github.com/probot/no-response
• 이메일 알림을 관리하기 위해 이메일 필터를 설정하여 우선 순위별로 구성 - https://github.com/settings/notifications

4) 오픈소스 프로젝트 커뮤니티 관리
39
커뮤니티 매니저를 중심으로 오픈소스 프로젝트의 공개를 홍보하고, 유입되는 프로젝트의 사용자 및 기여자에 대한 자세한 문서를 준비하여,
투명한 의사결정 과정을 통해 커뮤니티와 소통
•Wiki
•Blog
•Homepage
•Facebook
•Twitter
•JIRA
•Redmine
•Trac
•Git
•SVN
•CVS
저장소
이슈
관리
지식
관리
SNS
커뮤니티 활동을 위한 도구

40
커뮤니티 매니저 활동 (1)
• 커뮤니티의 모임 장소를 제공
• 공통의 관심사를 가진 커뮤니티 구성원이 서로 알 수 있도록 이야기 할 수 있는 장소를 제공
• 커뮤니케이션이 공개되고 접근 가능한 경우 누구나 과거의 게시물을 읽고 속도를 높여 참여 가능 (커뮤니티 사이트, 포럼, 메일링리스트)
• 개인적인 대화를 공개 채널로 안내해서 전환하도록 유도
• 커뮤니티의 이슈에 대한 빠른 대응
• 48시간 내에 코드 검토를 받은 기여자들은 매우 높은 충성도(모질라 재단 연구)
• 인터넷 상의 다른 곳(Stack Overflow, Twitter, Reddit, Google)에서 프로젝트가 언급될 수 있기 때문에 알림을 받을 수 있도록 설정
• 공개 커뮤니케이션에 대한 보안 문제, 민감한 행동 규범 위반 등의 예외적 상황을 커뮤니티 구성원이 개인적으로 보고할 수 있는 방법 제공
• 행동 규범을 준비하여 나쁜 영향을 미치는 커뮤니티 구성원을 최소화 – 문제가 지속되면 떠나도록 요청해야 할 수 도 있음.
• 커뮤니티 내부에서 기여자를 발굴하기
• CONTRIBUTING.md 파일에서 새 기여자에게 시작하는 방법을 제시
• https://github.com/firstcontributions/first-contributions/blob/master/translations/README.ko.md
• 기여자를 환경하는 특별한 페이지 - https://github.com/django/django
• 이슈에 다양한 유형의 제공자에서 적합한 레이블 사용 – good first issue, help wanted

41
• 친절한 문서를 사용해서 사람들이 모든 단계에서 환영 받는 느낌을 받도록 제공
• 예) 사용해 주셔서 감사합니다. 이 프로젝트는 많은 노력을 기울이고 있으며 버그를 발견하고 성능을 개선하며 문서화를 도와주는 모든
사용자에게 감사합니다. 모든 기여는 의미가 있으므로 참여해 주셔서 감사합니다. 그러나 문제를 성공적으로 해결하기 위해 따라야 할
몇 가지 지침이 있습니다.
• 커뮤니티와 최대한 소유권을 공유할 수 있는 방법을 준비 - 사람들은 소유권을 느낄 때 기쁘게 기여합니다.
• 예) 커뮤니티 사용자 중 이슈에 적합한 레이블을 붙이는 담당자를 지정해서 관리하도록 구성
• 예) 프로젝트에 기여한 모든 사람을 나열하는 CONTRIBUTORS 또는 AUTHORS 파일을 제공 -
https://github.com/sinatra/sinatra/blob/master/AUTHORS.md
• 예) 뉴스레터를 보내거나 기여자에게 감사하는 블로그 게시물을 작성
• 예) 모든 기여자에게 커밋 접근 권한을 부여
• 예) 한명 이상의 백업 관리자를 커뮤니티 사용자에서 추가
• 갈등 해결 – 친절한 커뮤니케이션에 대한 기준을 설정해서 구성원간 강한 의견이 있는 경우 중재자의 입장을 취할 것
• https://hamonikr.org/index.php?mid=Free_Board&search_keyword=nimf&search_target=title_content&document_srl
=63139

42
• 투표를 통한 주요 결정을 내리기 보다는 대화를 듣고 토론을 먼저 하기
• 답변 보다는 과정에 집중하는 것이 커뮤니티를 건강하게 만듭니다.
• 커뮤니티 구성원들이 충분히 들을 수 있을 때까지 주요 관심사에 대해 논의합니다.
• 조용한 커뮤니티 사용자를 고려하는 것을 잊지 않아야 합니다.
• 커뮤니티에서 행동의 우선 순위를 식별 – 순위 결정은 최후의 수단으로 사용해야 함
• GOVERNANCE 파일에서 순위 결정 및 관련 프로세스를 식별 한 후에 사용
• 커뮤니티 거버넌스 모델은 프로젝트 참여자가 수행할 수 있는 역할과 프로젝트 내 의사결정 프로세스를 설명.
• 또한 프로젝트 참여 및 프로젝트 팀 및 커뮤니티 내 의사소통 및 공유 프로세스에 대한 기본규칙을 설명.
• 즉, 오픈소스 프로젝트가 혼란으로 빠져나가는 것을 방지하는 관리모델. (Social framework)
• https://www.apache.org/foundation/governance/
• https://eclipse.org/org/documents/
• https://wiki.openstack.org/wiki/Governance
• http://www.linuxfoundation.org/collaborate/workgroups/cgl/governance

43
• 다양한 기업의 참여와 지속적 지원, 그리고 잘 준비된 거버넌스
Ref : OW2 Open Source Workshop 2015

5) 프로젝트 수행을 위한 역량 점검 및 개선
44
• https://goo.gl/C3sGaE
표준종류 정보통신단체표준(TTAS)
표준번호 TTAK.KO-11.0133/R2 구 표준번호
제개정일 2016-12-27 총 페이지 18
한글 표준명 공개SW 성숙도 및 적용성 평가 지침
영문 표준명
The Guideline of maturity and applicability assessment for open soft
ware
한글 내용요약
공개 소프트웨어라 함은 저작권이 존재하지만 저작권자가 소스 코드를 공개하
여 누구나 자유롭게 설치, 복제, 수정, 재 배포 등을 할 수 있는 자유로운 소프
트웨어를 의미한다. 그러나, 현존하는 공개 소프트웨어의 수는 수십만 종에 이
르며 나날이 새로운 프로젝트(제품)가 생성되기 때문에 막상 사용하고자 할 경
우에는 어떤 종류가 있는지, 제품의 품질이 어떠한 수준인지, 상용으로 사용하
기에는 문제가 없는지를 판단하기에 상당한 어려움이 따른다. 본 표준은 이러
한 문제를 해결하기 위해 본 표준은 공개 소프트웨어의 평가를 위해 반드시 필
요한 속성을 공통 속성으로 선정하고, 더 나아가 상업적 용도에 맞는 공개 소프
트웨어를 선별하기 위해 추가적으로 필요한 확장 속성을 제시한다. 또한 표준
과 확장 속성을 정의함으로써 평가에 대한 근거와 정보를 제공하고 있다.

45
속성군 표준 속성 설명
기능성
기능 적합성
분류 체계의 해당 카테고리에서 마땅히 제공해야 하는 목표 기능을 충실히 수행하는 수
준
지원성
설치 툴, 패치, 관리, 모니터링 등 목표 기능을 최상의 조건으로 수행하는데 필요한 보
조 기능을 다양하게 제공하는 수준
상호운용성 다양한 운영체제(Linux, Unix, Windows)에서 설치 및 작동이 가능한 수준
이식성
대체성
동일한 기능의 다른 오픈 소스 제품에서 전환 및 대체(migration)를 용이하게 수행할
수 있는 수준(표준 수용성)
대체후기능성 유사 오픈 소스 제품으로 대체한 이후에도 동일한 기능을 수행할 수 있는 수준
설치성
다양한 플랫폼에 이식될 수 있도록 구성 파라미터(configuration parameter)의 조작
이 용이하고 설치가 간단하고 편리한 수준
신뢰성
가용성 에러, 버그, 정지, 종료 등 비정상적인 동작이 없이 정상적으로 운영되는 정도
회복성 문제 및 장애 발생 시 복구 및 대응이 잘 되는 정도
최신성 최근 일정 기간 동안 신속하게 발전하는 정도
성숙성
커뮤니티의 인력 구성, 역할 분배, 운영 및 관리 체제가 얼마나 안정적이고 체계적인지
나타내는 수준
사용성
이해성 매뉴얼, 가이드, 튜토리얼 등 제품 사용 및 이용에 필요한 문서 및 자료의 제공 수준
학습성
제품 구성, 설치, 운영에 필요한 자문, 컨설팅, 교육, 인증(자격증) 등에 관련된 서비스
를 제공하는 수준
운용성 사용, 운영, 관리에 편리한 기능 수준 (예 GUI 환경)
유지보수성
분석성
에러 또는 문제를 해결하는데 도움이 되도록 원인과 상태를 상세히 분석할 수 있는 메
일링, 버그 리포팅, 이슈 트랙킹 등 소통 수준
전문기술 해당 오픈 소스에 대해서 전문 업체 또는 커뮤니티의 기술 지원 서비스가 가능한 수준
시험성 패치 또는 업그레이드 버전에 대한 품질 측정 수준
속성군 확장 속성 설명
커뮤니티
나이 및 규모
오랫동안 활동이 왕성하게 지속되고 최근에도 활동이 활발하여 발전하고 있
는 수준
주체
커뮤니티가 쇠약하지 않고 발전할 수 있도록 기업 및 단체로부터 지속적인 경
제적, 인력적, 사업적 지원이 있는 정도
접근성
상위의 인터넷 검색이 가능하고, 커뮤니티 참여와 지적 자산의 공유에 편리한
인터페이스를 제공하고 있는 수준 (이메일, 게시판, 패이스북)
관리체계
커뮤니티 내에서 프로그램 개발, 소스 코드 기여, 수용 여부 심사, 품질 테스
트, 로드맵 수립 등 개발과 품질에 관련된 활동이 체계적으로 진행되고 있는
수준
라이선스
이슈
라이선스 충돌 배포된 버전에 대해서 라이선스 문제가 있는 정도
면책 서비스 저작권 문제 발생 시 법적 위험으로부터 고객을 보호할 수 있는 수준
특허 침해성 특허 침해 문제가 있는 정도
고객 충실도
SLA 충실도 고객 서비스가 수준 별로 정의되어 있고 지원되는 정도
문제해결 능력만족도 문제가 발생했을 시 신속한 기술지원을 제공할 수 있는 수준
기술보증 기술 지원을 통해 제품의 품질이 보증되는 수준
선호도 고객이 선호하는 정도

46
Education Monitoring
Establish policy Acquisition Adoption
Operation and
Maintenance
Continuously improve
Compliance
Contract
Development
Packaging
Test
Deployment
Diagnosis or
consulting
Create policy
Build
Organization
Requirements
Analysis
Research
Analysis
Evaluation
Installation
Operation
Maintenance
Technical
Support
Community
Design
TTAK.KO-11.0133/R1
공개 소프트웨어 성숙도 및 적용성 평가
지침
TTAK.KO-11.0182
공개소프트웨어 정보교환명세
TTAK.KO-11.0110
공개소프트웨어 분류 체계 및
프로파일
TTAK.KO-11.0176
공개소프트웨어 거버넌스
프레임워크
TTAK.KO-11.0246
공개소프트웨어 기반 개방형
혁신 연구개발 역량 성숙도 모델

47
25개 오픈R&D 활동요소
공개SW의 거버
넌스의 이해
공개SW
전담조직 구성
공개SW
거버넌스 정책
공개SW 획득을
위한 공식절차
공개SW 프로젝
트의 평가방법
공개SW 성숙도
관리 활동
공개SW
개발 경험
공개SW 개발을
위한 개발환경
공개SW
개발 워크플로우
공개SW
품질관리
공개SW
개발 로드맵
공개SW의 특성
이해
공개SW 비즈니
스 모델의 이해
공개SW
비즈니스 전략
소프트웨어 공급
망 관리 정책
공개SW
라이선스 검증
공개SW 보안취
약점 점검
커뮤니티
거버넌스
커뮤니티 관리
커뮤니티
협업 환경
공개SW
기술지원 체계
커뮤니티 발전
로드맵
공개SW
성과지표 계획
공개SW
성과지표 관리
공개SW 성과지
표 개선활동
공개SW 거버넌스 프레임워크

48
개방형 혁신 연구개발의 역량 성숙도를 평가하고 개방형 혁신 연구개발 활동의 능력 수준을 개선하기 위해 필요한 성숙도 모델을 정의. 이를 위
해, 역량 성숙도 등급(Capability Maturity Level), 성숙도 모델 프로세스가 적용되는 도메인(Domain), 도메인별 세부 등급 기준 포함
진단항목 (1단계)초기 (2단계)정의 (3단계)관리 (4단계)확산 (5단계)최적화
비즈니스 전략 공개SW 비즈니스 전략 부재
공개SW 비즈니스 전략이
문서로 존재
담당자에 의해 측정되어 관리
전사적 전략으로 관리됨
지속적으로 개선됨
정책 및 조직 공식적 정책 및 조직 없음 공식 정책과 담당자 보유
오픈R&D 정책이 전담자에
의해 측정되어 관리
정책의 결과에 대한 성과가
전사적으로 측정되어 관리
지속적 관리 활동으로 개선
프로젝트 평가 평가방법 부재 평가방법이 문서로 존재함
평가방법이 담당자에 의해
측정되어 관리
공개SW 프로젝트
평가활동이 전사적으로 관리
공급망 관리 ad hoc
유입된 컴포넌트들은
확인되고 추적됨
명확한 정책과 프로세스
검토위원회에 의한 검토와
예외 처리
컴플라이언스를 위한
자동화된 프로세스
커뮤니티 커뮤니티 기반 환경 부재
커뮤니티 거버넌스 문서와
담당자 존재함
커뮤니티 운영활동이
전담자에 의해 측정되어 관리
커뮤니티 성과가 전사적으로
평가되고 관리
주요 커뮤니티와의 적극적
참여와 관심을 보이는
공개소프트웨어 공급자 생성
개발환경 개발환경 부재
개발환경이 존재하고
교육자료 보유
담당자에 의해 측정되어 관리 전사적 표준화된 절차로 관리 지속적 관리 활동으로 개선
성과관리 ad hoc 문서로 존재함 담당자에 의해 측정되어 관리 전사적 표준화된 절차로 관리 지속적 관리 활동으로 개선
TTAK.KO-11.0246 – 공개소프트웨어 기반 개방형 혁신 연구개발 역량 성숙도 모델

49
백로그 수정 / 정리 : 한 스프린트가 끝나면 팀과 제품 소유자가 만나서 다음
스프린트 준비가 되었는지 확인한다.
Daily Scrum meetings : Daily Scrum은 15 분간의 스탠딩 미팅으로 각 팀
구성원이 자신의 목표와 쟁점에 관해 이야기합니다.
스프린트 검토 모임 : 각 스프린트가 끝날 때 팀은 스프린트 검토 회의에서 완
료 한 작업을 제공합니다.
Sprint 회고 : 각 스프린트가 끝날 때 팀은 Scrum이 얼마나 잘 작동하고 있는
지 파악하고 다음 스프린트에서 변경해야 할 사항에 대해 이야기합니다.

3. 오픈소스 프로젝트의 다양한 지표 관리
50

오픈소스 프로젝트의 활동 분석
51
성공을 측정하고 추적하여 오픈 소스 프로젝트가 번창 할 수 있도록 올바른 결정
을 내려야 합니다. 데이터를 사용하면 오픈 소스 관리자로서 더 나은 의사 결정을
내릴 수 있습니다.
• 사용자가 새로운 기능에 어떻게 반응하는지 이해할 수 있습니다.
• 신규 사용자의 출처 파악
• 특이한 사용 사례 또는 기능을 식별하고 지원할지 결정
• 프로젝트의 인기도를 정량화해서 홍보합니다.
• 프로젝트 사용 방법 이해하고 개선할 수 있습니다.
• 후원 및 보조금을 통해 돈을 모을 때 사용할 데이터가 필요합니다.
• https://help.github.com/en/articles/about-repository-
graphs#traffic

52
사용자들이 우리 프로젝트를 잘 찾을 수 있는가?
• 프로젝트에 기여하기 이전에 먼저 프로젝트가 존재하는지
알아야 합니다.
• 사람들이 우리 프로젝트를 찾을 수 있습니까?
• GitHub의 경우 저장소에서 ‘Insights＇를 클릭 한 다음
‘Traffic’ 을 클릭
• GitHub – 얼마나 많은 사람들이 우리에게 주목하는가
Stars
• 프로젝트를 발견 한 사람들의 수에 비해 사용량이 적으면
프로젝트가 잠재 고객을 성공적으로 전환하지 못하거나 잘
못된 잠재 고객을 끌어 들이고 있는 상황.
• 잠재 고객이 어디에서 왔는지 파악하고 프로젝트 페이지에
서 다른 사람에게 피드백을 요청하여 개선

53
하모니카 프로젝트의 활동 분석
• 총 페이지 조회수 : 프로젝트를 조회 한 횟수를 알려
줍니다
• 총 순 방문자수 : 얼마나 많은 사람들이 프로젝트를
보았는지 알려줍니다
• 추천 사이트 : 방문자가 어디에서 왔는지 알려줍니
다. 이 측정 항목은 잠재 고객에게 도달 할 수 있는
위치와 프로모션 노력이 효과가 있는지 파악하는 데
도움이 됩니다.
• 인기있는 콘텐츠 : 방문자가 프로젝트에서 방문한
위치를 페이지 뷰와 순 방문자수로 나눕니다.

54
정기적으로 추적 할 수 있는 커뮤니티 지표의 예
• 기여자 당 총 기여 수 및 커밋 수
• 기여자 수와 활동중인 사람 수를 알려줍니다.
• GitHub의 'Insights'- 'Contributors＇에서 이를 확인할 수 있습니다.
• 현재 이 그래프는 리포지토리의 기본 분기에 커밋한 기여자 만 계산합니다.
• 처음, 일시적이고 반복적 인 기여자
• 새로운 기여자를 받고 있는지 여부와 그들이 다시 왔는지 여부를 추적 할 수 있습니다. 새로운 기여자가 없으면 프로젝트 커뮤니티가 정
체 될 수 있습니다.
• 이슈 및 요청 수
• 이 수치가 너무 높으면 문제 심사 및 코드 검토에 도움이 필요할 수 있습니다.
• 미해결 이슈 및 풀리퀘스트 요청 수 :
• 누군가 프로젝트를 이슈를 관리해야 한다는 것을 의미합니다. 시간이 지남에 따라 그 수가 증가하면 사람들이 프로젝트에 관심이 있음을
나타냅니다.
• 컨트리뷰션 유형 : 예를 들어 커밋, 오타 또는 버그 수정 또는 문제에 대한 의견

55
이슈 또는 풀 요청이든 관계없이 기여자 (또는 다른 관리자)가 기여에 응답하는 데 걸리는 시간을 추적
- 컨트리뷰션 프로세스의 단계간에 이동하는 데 걸리는 시간을 측정 할 수 있습니다.
• 문제가 열려 있는 평균 시간
• PR에 의해 이슈가 종결되는지 여부
• 부실 문제가 종결되는지 여부
• 풀 리퀘스트를 병합하는 데 걸리는 평균 시간

56
하모니카 프로젝트 모니터링 시스템
전체 다운로드 수
사용자 수
이슈 생성 통계 일일 다운로드 추이
배포서버상태
어플리케이션
사용자 수

57
Codebase Reporting System
- 예) https://projects.apache.org/statistics.html

Summary
58
1. 오픈소스 프로젝트 이해하기
- 오픈소스는 더 이상 취미가 아닌 대세
2. PBS 중심과제에서 오픈소스 프로젝트 수행
- 수행 가능한 목표를 성과지표로 설정하는 것이 매우 중요
3. 오픈소스 프로젝트의 다양한 지표 관리
- 데이터를 기반으로 지속적으로 측정하고 관리해야 성공적인 커뮤니티가 가능

59
• 오픈소스SW 개요 – 오픈소스 생태계, 오픈소스SW 라이선스
• 라이선스 컴플라이언스와 도구 활용 - 실습
• 오픈소스 거버넌스 실무 - 오픈소스SW 거버넌스 프레임워크의 실무 적용
• 오픈소스 개발방법론 – Agile, Scrum, Kanban
• 오픈소스 프로젝트 실습 - Github 이클립스, Git, 소스트리, DevOPS
• 오픈소스 커뮤니티 구축 및 운영 - 오픈소스 커뮤니티 거버넌스, 오픈소스 커뮤니티 구축,
• 오픈R&D 성과관리 - 성공적인 오픈R&D 로드맵, 오픈R&D의 핵심역량, 오픈R&D 성과관리
Open Source Product Operator 양성과정

Q&A
인베슘 김형채
hckim@invesume.com

출연연의 공개소프트웨어 연구개발 프로젝트 관리

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 출연연의 공개소프트웨어 연구개발 프로젝트 관리

Similar to 출연연의 공개소프트웨어 연구개발 프로젝트 관리 (20)

More from Kevin Kim

More from Kevin Kim (14)

출연연의 공개소프트웨어 연구개발 프로젝트 관리