오픈소스와 거버넌스

2016.11.
김형채이사
인베슘 김형채
hckim@invesume.com
유다시티의 오픈소스 자율주행 자동차 프로젝트

INVESUME
>>
강사 소개
현) 인베슘 이사
한중일 오픈소스활성화 포럼 표준화분과 한국위원
한국정보통신기술협회(TTA) 오픈소스 표준화 분과위원
• 오픈소스 분류 체계 및 프로파일: TTAK.KO-11.0110
• 오픈소스 성숙도 및 적용성 평가 지침: TTAK.KO-11.0133/R1
• 오픈소스 교환명세: TTAK.KO-11.0182
• 오픈소스 거버넌스 프레임워크: TTAK.KO-11.0176
• 비오픈소스의 오픈소스 전환 가이드
• 오픈소스 소프트웨어 활성화를 위한 성숙도 및 적용성 평가모델 (OSMAAM)의 설계 및 구현에 관한 연구
• 오픈소스기반 Governance v1.0
• 오픈소스 정보화전략계획(o-ISP)
• 오픈소스기업의 서비스수준 평가모델
• 오픈소스도입가이드라인
“저는 오픈소스기술과 Agile SW개발방법론을 이용하여 기업의 비즈니스 전략
과 잘 연계하는 성장모델에 관심이 많습니다.”
김 형 채
2

INVESUME
>>
프로그래머
3
GW Basic >> CGI CrazyBoard >> PHP게시판 이니보드 >> WebCMS >> …

INVESUME
>>
오픈소스 거버넌스
5

INVESUME
>>
하모니카 오픈소스 커뮤니티
6
우리는 비슷한 문제를 풀고 싶어하는 다른 이들과 협업을 즐기고, 개발하는 내용을
오픈소스화하고 커뮤니티와 정보를 공유하며, 애자일한 고객접근을 통해 고객의
만족도를 높이려고 노력합니다.
활기찬 커뮤니티를 지원하고자 인베슘에서는 하모니카
오픈소스 프로젝트의 필수 기반 시설을 제공하고 이 목적
에 기여하는 그 밖의 노력을 합니다.
http://hamonikr.org/

INVESUME
>>
목 차
1
오픈소스
2
시장현황
3
거버넌스
7

1
오픈소스
문화와 기술의 관점

INVESUME
>>
오픈소스
• 1984년 시작된 자유소프트웨어 운동에서 기원을 찾을 수 있다. 이후 1998년 오픈소
스 소프트웨어(Open Source Software)라는 용어의 등장을 거쳐 국내에서는 누구
나 소스코드를 접근할 수 있는 소프트웨어를 오픈소스라 분류하고 있다.
• 현재 국내에서는 FOSS, OSS, 자유소프트웨어, 오픈소스 소프트웨어, 오픈소스라는
용어가 현재 함께 사용되고 있어 다소 혼란이 있을 수 있으나, 이 용어들은 소스코드를
공개하고 공유하자는 근본취지와 그 사상적 근원은 같다.
• 소프트웨어 사용의 라이선스 비용이 없으며 소프트웨어의 소스코드가 공개되어 있는
소프트웨어로서 누구나 자유롭게 사용할 수 있고, 활용할 수 있으며 배포할 수 있는 소
프트웨어를 의미.

INVESUME
>>
Revolution OS
• 오픈소스, 자유소프트웨어 운동의 20년을 추적한 다큐멘터리
• https://www.youtube.com/watch?v=4ZHloJVhcRY
공개된 정보와 기술의 자유로운 교환을 통하여 컴퓨터 사용자를 해방시키려는 목적의 운동.

INVESUME
>>
위키백과 탄생에 대한 이야기
• 위키피디아 창시자 지미 웨일스의 TED 강연
• https://www.ted.com/talks/jimmy_wales_on_the_birth_of_wikipedia?lan
guage=ko#t-554074
저희는 사람들이 원하는 모든 활동을 할 수 있도록 하기 위해서 공짜 모델을 선택했습니다.
원하는 사람이면 누구나 우리 백과사전의 내용으로 상업적, 비상업적 모든 용도로 이용할 수 있습니다

INVESUME
>>
MOOC
• MIT, 하버드, 스탠포드 학생 백만명 시대 - 학교가 필요 없어진다?
• http://juhokim.com/talkscape/v/juhokim-mooc
Massive Open Online Course, MOOC)은
웹 서비스를 기반으로 이루어지는 상호참여적, 거대규모의 교육

INVESUME
>>
AI Class Experiment of Stanford University
• 160,000 signed up
• 23,000 finished
• 200 Stanford students (170 online)
• 411: the top Stanford student
• $1 per student per class
2012년 미국에서 시작된 후 영국, 프랑스, 독일, 중국, 일본 등 주요국들로 점차 확산
• 미국의 Udacity, edX, Coursera 등이 대표적이며, FutureLearn(영국),
FUN(프랑스), Iversity(독일), XuetangX(중국), Gacco(일본) 등
신규 플랫폼도 활발히 출현 중
• 국내에서도 2015년 10월부터 K-MOOC를 시범운영 중

INVESUME
>>
오픈소스의 문화적 관점
참여와 공유를 통한 발전방향에 대한 믿음

INVESUME
>>
오픈소스의 기술적 장점
15
The 2016 North Bridge & Black Duck
http://www.slideshare.net/North_Bridge/2016-future-of-open-source-study-61431845

INVESUME
>>
16

INVESUME
>>
17

INVESUME
>>
오픈소스의 기술적 관점
18
품질 보안
표준비용
•오픈소스는 비용 절감에 도움을 준
다.
•하지만 기업은 더 이상 비용 때문에
오픈소스를 선택하지 않는다.
•오픈소스는 ＇사실상의 표준(de
factor standard)＇을 만드는 모델
•성공을 거둔 오픈소스는 특정 업체
에 종속될 염려 없이 동일한 기능을 제
공할 수 있다.
•보안은 한때 오픈소스 소프트웨어의 단
점이었지만 조사결과 72%는 보안 때문
에 오픈소스를 선택했다고 대답.
•오픈소스는 투명성 때문에 사용자가 잠
재적인 보안 취약점을 찾기 위한 목적으
로 코드를 점검할 수 있다.
•과거와는 다르게 최근의 오픈소스를
선택하는 첫 번째 이유는 품질.
•프로젝트가 지지를 받으면서 더 많
은 사람들이 안정성을 개선하고, 버그
를 찾아 수정하며, 인터페이스를 효율
화 하는데 도움을 주고 있기 때문

2
시장 현황
오픈소스의 활약

INVESUME
>>
오픈소스의 활용분야

INVESUME
>>
레드햇
21
• 레드햇은 1993년 설립되어 오픈소스 소프트웨어 에코시스템을 기반으로 클라우드 컴
퓨팅, 미들웨어, 가상화 및 모바일 등 다양한 분야에서 오픈협업 비즈니스 모델과 서브
스크립션 모델을 사용하여 연 매출 20억 달러 이상의 성공을 거듭하고 있다.
• 오픈소스 분야에 대한 신뢰성을 보증하는 서브스크립션 모델과 지속적인 교육을 통해
오픈소스 생태계에 참여하고 있으며, 오픈소스 커뮤니티에 대한 지속적인 지원을 하고
있는 대표적인 글로벌 오픈소스 기업이다.

INVESUME
>>
마이크로소프트
22
• 마이크로소프트는 세계 최대의 다국적 소프트웨어 및 하드웨어 개발 및 판매 업체이며
가장 유명한 제품으로는 MS 윈도우 운영체제가 있다. 전통적인 소프트웨어 대표적 기
업이던 마이크로소프트 역시 다른 기업들과 마찬가지로 기존의 비즈니스 전략을 오픈
소스 소프트웨어를 활용하는 전략으로 변경하고 있다.
• 마이크로소프트는 오픈소스에 적극적인 기여를 위해 직원들의 오픈소스 참여 활동을
독려하고 있으며, 2009년 OSCON에서 2만여 줄의 리눅스 드라이버 소스코드를 공개
하고 아파치 재단에 10만 달러를 기부하는 등 적극적인 오픈소스 커뮤니티 협력 활동
을 하고 있으며, 2015년에는 대표적 오픈소스 기업 레드햇과 파트너쉽을 체결하여 협
업을 모색하고 있다.

INVESUME
>>
오라클
23
• 오라클은 Linux, PHP, Apache, Eclipse, Berkeley DB 및 InnoDB 등 오픈소스 소
프트웨어 기술을 개발, 테스트, 최적화하고 지원하는데 막대한 자원을 투자함으로써,
오픈소스 솔루션을 개발 및 배포하는 활동을 지원하는 제품으로 비즈니스를 하고 있다.
• 많은 고객들이 미션 크리티컬 환경에서 저비용, 관리 가능성 향상, 가용성 증대 및 신뢰
성, 성능, 확장성 증가 등의 이유로 오라클과 오픈소스 기술을 함께 사용하고 있다.

INVESUME
>>
IBM
24
• IBM은 컴퓨터를 아는 사람이라면 누구나 아는 개인용 컴퓨터를 개발한 회사이다. 메인
프레임용 시장과 PC 하드웨어에 이르기까지 컴퓨터와 관련한 모든 시장에서 승승장구
하던 IBM은 마이크로소프트가 등장하면서 운영체제 시장에서의 몰락을 맞게 된다.
• 이후 IBM은 오픈소스 프로젝트 아파치를 지원하고 싶다는 의사를 밝히고 자사의 웹스
피어 제품군에 아파치를 도입하며 순항을 시작했다. 아파치 프로젝트의 성공을 발판으
로 2000년부터는 서비스 산업에 포커스를 맞추며 컨설팅, 소프트웨어 및 서비스 비즈
니스의 매출 비중을 향상시키며 통합 솔루션 회사로 변신하였다.
• IBM은 최근 빅데이터 분석 기술 아파치 스파크를 10년간 지원하기로 결정했다. 자사
의 분석 플랫폼에 스파크를 통합하고 블루믹스 서비스 플랫폼으로 스파크를 제공한다.
IBM은 이 프로젝트에 3500여명의 연구원과 개발자를 투입하고 향후 오픈소스 기술
스파크를 중심으로 빅데이터 분석 시장에 활용할 예정이다.

INVESUME
>>
구글
25
• 구글은 매일 10억건 이상의 검색을 처리하는 세계 최대 인터넷 검색 서비스 회사로서
오픈소스 커뮤니티 오픈스택, 아파치 재단 등의 플래티넘 후원사로 활동하며 매년 큰
비용의 후원금을 지원하는 회사이며 현재 세계에서 가장 많이 사용되는 모바일 운영체
제 안드로이드를 2005년 569억원에 인수하여 오픈소스로 제공했다.
• 구글은 안드로이드 이외에도 한중일이 사용할 수 있는 글꼴, 웹브라우저 크롬, 로열티
없는 고화질 영상 압축 포맷 WebM, 인공지능 엔진 Tendor Flow 등을 공개하여 오픈
소스 생태계의 활성화를 위하여 노력하는 대표적인 기업이다.

INVESUME
>>
시사점
모든 기업이 오픈소스를 사랑한다.

INVESUME
>>
기업의 오픈소스를 활용한 비즈니스 전략들
27
전통적 SW개발 기업이 자사의 기술이나 서비스를 오픈소스 모델로 전환하여 타
사와 경쟁.
전통적인 SW개발 모델이 아닌, 고객을 위한 분산된 컴포넌트의 통합을 교육훈
련과 기술지원으로 돕는 오픈소스 전문 비즈니스 전략
오픈소스 개발, 배포모델을 기업 비즈니스 목표달성을 위해 활용
오픈소스의 부가적인 가치를 기업 경영에 활용

INVESUME
>>
자사의 기술을 오픈소스 모델로 전환
28
• 듀얼 라이센싱 모델이나 코어 오픈모델을 사용하는 등 지적 산출물에 대한 접근 통제를
가치로 파는 전략
• MySQL과 sleepycat(버클리 DB)가 듀얼 라이센싱으로 유명. 즉, GPL 버전은 무료
로 쓰지만, non-GPL버전을 쓰려면 돈을 내야 한다. 소프트웨어를 Embed 해서 재판
매 하려는 회사에 해당된다.
• Xen, SugarCRM 과 같은 회사에서는 코어 오픈모델을 사용. 즉, 코어는 공짜로 풀고
부가기능은 돈을 받고 파는 모델이다. 여기서 “판매가치”는 “특화 기능
(Differentiated Features)”들이 만들어 낸다.
• 보통 듀얼라이센싱을 하기 위해서는 오픈소스에 대한 판권을 가져야만 한다. 즉, 코어
개발자를 직접 고용해야 한다는 것을 의미한다. 즉, 개발력이 내재화되어 있으면, 코어
를 오픈소스로 풀기도 하고 GPL버전을 만들어서 뿌리는 것도 자유롭다.

INVESUME
>>
오픈소스 사용 고객사를 돕는 비즈니스
29
• 소프트웨어 회사들은 자사의 개발과 산출물들이 조직 밖으로 나와도, 여전히 회사가치
가 남아 있는가에 대한 불안이 존재한다.
• 하지만 Dixon, Pentaho, RedHat, OpenGeo 등의 회사들은 오픈소스 커뮤니티가
만들어내는 소프트웨어를 팔릴만한 물건으로 만들기 위해 가치를 더해줌으로써 선순
환 구조를 완성시킨다. 그리고 그 이익으로 다시 개발자와 스태프를 고용하고 오픈소스
커뮤니티가 새로운 가치를 계속 만들어내도록 지원한다.
• 이런 기업들은 실질적인 코어 개발자들을 물리적으로 보유함으로써 지적 자산을 보호
해준다.

INVESUME
>>
오픈소스 개발모델을 기업 목표달성에 활용
30
• 기업의 이익을 위해 선별적으로 오픈소스 소프트웨어를 선택하는 이른바 체리 피킹
(cherry-picking:선별적 경쟁) 전략을 의미.
• 근간 기능(Commodity Features) 소프트웨어 개발을 위한 프레임워크와 유사한 기
능은 소프트웨어의 프레임워크로 뼈대를 형성하는 것이므로 전체 소프트웨어의 중요
부분을 차지하는 경우가 많다. 일반적으로 근간 기능(Commodity Features)은 비용
과 시간 절감 및 OSS 사용층 유입의 장점이 있기 때문에 OSS로 구현되는 경우가 많다.
(예) 빅데이터 플랫폼 Apache Hadoop)

INVESUME
>>
오픈소스의 부가적인 가치를 경영에 적용
31
• 오픈소스에 대한 공유와 협업으로 기업 이미지 마케팅 가시성 확보
• 기업 내 조직운용의 실용성을 오픈소스를 통해 확보.
• 오픈소스를 활용한 소프트웨어 개발의 변화
아직 관련 매출을 발표한 적이 없음에도 불구하고 오픈소스 계획을 발표한 후로는
1억 달러로 우리가 얻을 수 있었던 것보다 더 많은 마케팅 가시성을 확보하게 됐다.
- 아이오나 CEO 피터 조토(Peter Zotto)
오픈소스는 소프트웨어 산업에서 오랜 시간 논의 되었던 재사용, 재공학 등의 문제
를 신뢰도 높은 소프트웨어의 재활용, 개발자의 전문성 강화 등 상당 부분 해결해주
고 있다. 또한 기업들은 공유와 협업이라는 오픈소스 문화의 적극적 도입으로 소프
트웨어 개발문화도 애자일, 린 개발법 등 다양하게 변화되고 있다.

INVESUME
>>
요즘 개발자의 이력서
32
• Social Reputation based Assessment

3
거버넌스
바른 사용의 길잡이

INVESUME
>>
오픈소스 사용자 유형
200,000 개 이상의
오픈소스프로젝트
34
• 소프트웨어 제작사, 소프
트웨어 판매사
• 전자제품 제작사, 전자제
품 사용자
• 오픈소스 커뮤니티
• 클라우드 SaaS 기업
• 오픈소스에 기술 지원
서비스 기업
• ICT 기업 또는 연구소
• 학교 또는 정부 기관 등

INVESUME
>>
오픈소스 라이선스 준수의무
35
출처 : 정보통신산업진흥원

INVESUME
>>
오픈소스 사용에 대한 준비
Source: 2016 Future of Open Source Survey Results - Blackduck
36

INVESUME
>>
NEA OSS PF WG3
37
Education Monitoring
Establish policy Acquisition Adoption
Operation and
Maintenance
Continuously improve
Compliance
Contract
Development
Packagin
g
Test
Deployment
Diagnosis or
consulting
Create policy
Build
Organization
Requirements
Analysis
Research
Analysis
Evaluation
Installation
Operation
Maintenanc
e
Technical
Support
Community
Design
TTAK.KO-11.0133/R1
Open Source Software Maturity
and Applicability Assessment
Model(OSMAAM)
TTAK.KO-11.0182
Open source software
package data
exchange
specification(SPDX)
TTAK.KO-11.0110
Open Source Software
Categorization & Profile
TTAK.KO-11.0176
The Governance
framework for Open
Source Software

INVESUME
>>
Future Work Overviews of WG3
38
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
The open source community
management techniques of
enterprises in China.
Ex) HUAWEI, ALIBABA …
The open source projects
monitoring method of
enterprises in Japan.
Ex) FUJITSU big data FOSS
projects monitoring method
Open Source
Organization Maturity
Diagnostic Model.
The Competency
management method for
open source software
engineers

INVESUME
>>
오픈소스 거버넌스 프레임워크 보급
39
• Everyone can download pdf file of the FOSS governance framework at the link below.
• http://www.oss.kr/oss_repository12/628521 (Korean version)

INVESUME
>>
40
오픈소스 거버넌스에 대한 국내의 인식

INVESUME
>>
Governance
41
정부 뉴 거버넌스
• 시민사회를 정부의 활동 영역에 포함시켜 새로운 파트너로 인정함으로써 정부조직, 기업, 시민사회, 세계체제
등 이들 모두가 공공서비스와 관련하여 신뢰를 통한 네트워크(연계, 상호작용)를 구축하는 것을 강조하면서 시
장논리보다는 협력 체제를 강조하는 것 (위키피디아)
기업 거버넌스
• 경영자원의 조달과 운용 및 수익의 분배 등에 대한 의사결정과정과 이에 대한 감시기능의 총칭으로 정의되기도
하며, 기업의 경영을 감시, 규율하는 것 또는 이를 행하는 기구를 뜻하기도 한다. (위키피디아)
IT 거버넌스
• IT 사용에 있어 바람직한 행위를 촉진하고 유도할 수 있도록 의사 결정 권한과 책임을 정립하는 것 (가트너)
• IT 및 프로세스에 대한 투자 회수와 Risk간의 균형유지 및 가치를 부가 시켜 기업 목표 달성을 위한 방향을 제시
하고 통제하는 관계와 프로세스 들의 구조 (IT Governance Institute)
거버넌스
• 1980년대부터 대두된 통치 시스템의 개념으로 아직 정의에 대한 학문적 합의는 이루어지지 않았다 (위키피디아)

INVESUME
>>
Open source software Governance
42
Open-source governance
• Open-source governance (also known as open politics) is a political philosophy which
advocates the application of the philosophies of the open-source and open-content
movements to democratic principles to enable any interested citizen to add to the creation of
policy, as with a wiki document. (https://en.wikipedia.org/wiki/Open-source_governance)
• 오픈소스 거버넌스는 위키백과의 방식과 같이 관심이 있는 사람들이 민주적 원칙에 의해 정책 형성을 가능하게
하는 오픈 소스와 오픈 컨텐츠 운동을 옹호하는 정치 철학.
Open Source Governance
• Open source governance is the way an organization controls the use of open source software
within their products and services, supply chains and business management activities, and the
associated business and legal processes. (blackduck)
• 오픈소스 거버넌스는 오픈소스 소프트웨어를 제품과 서비스, 공급망과 비즈니스 관리활동, 그리고 비즈니스 협
력과 법적 활동 등의 조직 관리 방법

INVESUME
>>
오픈소스 거버넌스의 범위
Corporate Governance
Information
Technology
Governance
Information
Security
Governance
Open Source Software
Governance
43

INVESUME
>>
오픈소스 거버넌스 프레임워크 개요
“오픈소스를 기업이 안전하게 사용·적용 및 배포하기 위해 필요한 사항을 다양한 관점에서
활용할 수 있도록 기업 적용의 단계별로 제시한 틀”
44
위험노출
측정
관리
참여
활성화
오픈소스 관리 성숙도 모델

INVESUME
>>
오픈소스 거버넌스 프레임워크 구성
45
오픈소스활용
라이프사이클
순차적
오픈소스거버넌스
활동요소 (18)
비 순차적
오픈소스거버넌스
활동요소 (3)

INVESUME
>>
오픈소스 거버넌스 프레임워크 기반 성숙도 관리
46
조직수준
생명주기
위험노출 측정단계 관리단계 참여단계 활성화 단계
검색(발견)
공식적 가이드라인 혹은
프로세스가 없음
약간의 가이드라인 제공
수용 가능한 소스와 속성에 대
한 명확한 정책이 있음
교육된 개발자
오픈소스속성의 검증과 빠른
검색을 위한 도구가 있음
기업의 요구사항을 추진하기
위한 주요 커뮤니티참여
검토와 선택
및 공급망관리
ad hoc
유입된 콤포너트들은 확인
되고 추적됨
명확한 정책과 프로세스
검토위원회에 의한 검토와 예
외 처리
컴플라이언스를 위한 자동화된
프로세스
주요 커뮤니티와의 적극적 참
여가 관심을 보이는 오픈소스
공급자 관계 생성
코드관리
오픈소스가 독점코드에 포
함되어 관리됨
오픈소스가 개별적으로 추
적됨
내부정책기반의 개별 컴포넌트
에 대한 담당과 책임을 수립
오픈소스 저장소
추적 사용
자동화된 프로세스는 컴플라
이언스 요구사항들과 사용, 속
성, 소스를 추적
오픈소스저장소는 외부 릴리
즈를 지원하는 것으로 확장됨
유지보수와 지원 ad hoc
버그수정과 신규 출시에
대한 약간의 모니터링
내부정책기반의 개별 컴포넌
트 담당자에 대한 책임 정의
강화된 지원 모델
자동화된 프로세스는 버전, 버
그수정,이슈를 추적
외부로 확장된 지원모델
외부지원을 처리하기 위해 확
장된 자동화된 프로세스
준법 프로그램 ad hoc, 필요할 경우
사용된 컴포넌트의 목록
관리
컴플라이언스 요구사항들
은 수작업으로 처리
잠재위험을 방지하기 위한 검
토와 코드 관리
자동화된 제품 출시 검사
문서화를 통한 컴플라이언스
프로세스
컴플라이언스 기능과 코드관
리,검토를 통합하는 자동화된
프로세스
관리와 고객을 위한 자동화된
보고서
기여 검토와 검사를 위한 정책
과 자동화된 프로세스
커뮤니티 상호작용 코드 다운로드 코드 다운로드
코드다운로드
업데이트추적
사용 주체확인 없이 포럼에 참
여
사용 주체특성에 부합된 포럼
에 참여
버그수정 참여
신규 프로젝트/콤퍼넌트 참여
주요 커뮤니티 후원
의사결정자 감독 없음
의사결정자는 사용 오픈
소스컴포넌트 목록을 받
음
법무&관련부문이 검토위원회
에 참여
컴퓨니티 참여를 위한 정책
버그수정 참여를 위한 프로세
스
컴포넌트 기여를 위한 정책과
프로세스
프로젝트 후원
출처 : Black Duck Software

4
거버넌스 실무
실제 기업에서의 적용과정

INVESUME
>>
개발대상 소프트웨어
48
웹 브라우저 기반의 영상 및 음성 통신 SW, 별도의 설치 없이 구글 크롬, 파이어폭스, 오페
라 웹 브라우저와 안드로이드, iOS와 같은 모바일 기기에서도 서비스 이용이 가능.
Caller Answer

INVESUME
>>
오픈소스 활용 영역
49
시그널링 서버, 릴레이 서버는 오픈소스 기술 활용, 각각의 피어에서 접속하는 클라이언트
는 직접 개발, 모바일 클라이언트는 SDK 구매 후 활용.
직접
개발
오픈소스
획득 후 수정
외부SDK
사용

INVESUME
>>
오픈소스 거버넌스 프레임워크
기업 가치를 극대화시키고 저작권 침해 및 컴플라이언스 위험을 극소화시키기 위하여 기업 내의 오픈소스
활용과 기업 간의 협업 체계에 대한 지침을 수립하는 활동
50
1) 정책 수립
필수 구성 요소 구성 예
• 오픈소스 사용 시 조직이 준수해야 하는 준
법 요구사항
• 오픈소스 사용 혹은 활동을 위한 승인 절차
• 오픈소스 관리를 위한 조직 자원의 역할과
책임 정의

INVESUME
>>
51
1) 정책 수립
정책??
오픈소스를 사용
하면서 지킬 원칙
의사결정체계
전략, OSS 선정, 타당성 분석, 기타 의사결정은 총괄관리
자 미래전략본부 본부장이 전결
분석 및 평가 오픈소스 성숙도 및 적용성 평가 표준(OSSMAAM) 적용
소스코드 형상관리 제품 릴리즈 시점까지는 내부 CI 사용, git 와 jenkins
소스코드 공개 Git hub 사용
라이선스 검증 사용 OSS 라이선스 전문가 검토
커뮤니티 구축 및 운영
소극적 사용 우선(획득한 소스코드에 대한 사용), 향후 점
진적 개방
기술교육 페어로 구성된 도제식 교육방식 적용
유지보수 프로젝트 모니터링 담당자 배정 및 이슈관리시스템 운영
보고 및 검토 데일리 미팅

INVESUME
>>
서비스 제공자가 오픈소스를 원활히 도입, 활용, 관리할 수 있도록 조사, 진단, 분석, 개선 방안, 전략, 로드맵,
방법론 등을 고객에게 서비스로 제공하는 활동. 수준 진단, 문제 분석, 해결방안 도출, 실행방안 제시 등의 활
동
52
2) 컨설팅
• 사업 환경 및 전략 확인
• 오픈소스 현황 분석
• 오픈소스 도입원칙 수립
• 오픈소스 추진과제 정의
• 오픈소스 도입계획 수립
필수 구성 요소 구성 예

INVESUME
>>
53
2) 컨설팅
주요 파트너 주요 활동 핵심가치 정의 고객관계 대응 고객 세분화
핵심 자원 채널
가격 구조 수익 분석
• 공공 SI 사업자, 개
방형OS 보급기업을
주요 파트너로 확보
필요
• 미디어 필터 개발
• 성능 개선 작업
• 확장가능 아키텍처
• WebRTC 코어엔진
분석 부문
• 아이폰 WebRTC 개
발 부문
• 플러그인 설치가 필
요 없는 화상통신.
• 낮은 도입비용
• 미디어 필터(보안,
분석, 감지)
• 1차 고객응대는 SI기
업을 활용
• 2차 는 OS보급 기업
이 응대
• SI 채널을 중심으로
화상회의가 필요한
공공업무시스템 개
선사업에서 낮은 도
입비용으로 영업
• 공공기관 화상회의
시스템
• 기업 다자간 미팅 시
스템
• IoT 산업기기 커뮤니
케이션 채널
• 일체형 제품으로 SI에 공급, 최소가격 500
만원 (서버1식 포함, 동시사용 50User)
• 초기도입비용은 낮게 유지, 유지보수 비용
확보 및 사용자 증가에 따른 고도화 비용

INVESUME
>>
오픈소스에 관련된 조직 간의 역할 정의 및 분담, 책임 소재 명시, 협업 체계 수립 등 단체 인력의 집합적 활용
활동. 오픈소스 활용의 사업목적과 조직의 수준에 부합되는 오픈소스 거버넌스를 구축하고 운영해야 함.
54
3) 조직구성
• 비즈니스 전략
• 조직 필수 요구사항
• 적합한 조직 구조
• 조직 운영 시스템
• 구성원
• 조직문화
• 조직의 공유가치
고려 사항 구성 예
조직 개요및업무내역
오픈소스 검토위원회 오픈소스 정책 수행을 위한 핵심 기구
법무
라이선스와 계약 준수를 포함하여 법적 요구사항들을 준수해
야 하는 조직의 제품과 솔루션에 대한 궁극적인 책임
개발
개발부서는 실제로 오픈소스를 사용하고 오픈소스와 결합된
제품 및 솔루션을 창출하는 조직
운영 조직의 개발시스템 운영 환경을 담당
마케팅
오픈소스 컴포넌트들과 결합된 제품 및 솔루션을 위한 사업계
획 뿐 아니라 해당 오픈소스 라이선스 의무사항을 준수하기 위
한 모든 필요 속성들을 확인하는 기구
재무/감사
조직의 특정 상태에 따라 준법성이 적절히 준수되고 있음을 증
명해야 하는 책임

INVESUME
>>
55
3) 조직구성
R&R 수행 업무 담당자
총괄 비즈니스 전략, OSS 선정, 타당성 분석 김형채
기술총괄 OSS PoC, BMT, 아키텍처 설계 류경문
소스코드 형상관리 소스코드 획득, OSS 모니터링, 구현 이욱
커뮤니티 채널, 모바
일
이슈트래킹, Q&A, 아이폰 App 탄냥
테스트 단위테스트, 성능테스트 김태웅
UI 사용자 웹 UI, 모바일 UI 김소현
프로젝트의 비즈니스 전략적 가치가 중요하게 인식되는 이유로, 전담부서로 조직을 구성하고 각 구성원의
역할과 책임을 분장하는 수행체계를 구성

INVESUME
>>
오픈소스 사용을 위해 사용자 및 개발자의 고민과 요구를 기반으로 기능, 성능, 연동, 호환, 보안 등의 관점에
서 필요한 사항을 분류하고 해석하는 활동
56
4) 요구분석
• 서비스 이해관계자 식별
• 오픈소스가 활용되는 시스템 기능 및 특성
• 제약사항
• 오픈소스 커뮤니티의 활동성
• 오픈소스 커뮤니티와의 협력 가능성
구분 내용
사용자 및
인적요소
누가 사용하는가 기관 내 근무자
사용자 유형은 다양한가 팀별로 권한 설정
시스템을 사용 교육이 필요한가 접속 방법
시스템 기능
및 특성
어떠한 운영체제를 사용하는가 Window/ Unix
시스템이 하는 일은 무엇인가 파일 서버
시스템은 어떻게 운영, 관리되는가 사용자 및 그룹별 접근 제한
제약 사항
오픈소스 기반에서 불편사항은 없는가?
전환할 때 주의해야 할 사항은 없는가?

INVESUME
>>
57
4) 요구분석
비즈니스 요구
• GPL/LGPL, Apache, BSD등 오픈소스 라
이센스 기반의 소프트웨어 사용
• 웹 표준 준수
• 멀티 디바이스 지원
• 영상 보안 기능 필수
기술적(물리적) 요구
• Linux
• HTML5, Javascript
• WebRTC
• OpenCV
• OpenSSL
• 시스템장비구성 요구사항
• 기능 요구사항
• 성능 요구사항
• 인터페이스 요구사항
• 데이터 요구사항
• 테스트 요구사항
• 보안 요구사항
• 품질 요구사항
• 제약사항
• 프로젝트 관리 요구사항
• 프로젝트 지원 요구사항
요구사항 도출 요구사항 분석 요구사항 명세

INVESUME
>>
오픈소스의 속성과 커뮤니티 정보를 취합하는 활동이다. 이 활동을 통해서 반드시 취합해야 하는 속성으로
는 기능, 용도, 라이선스, 프로그래밍 언어, 적용 분야, 연동 및 연계 소프트웨어, 유스케이스 등이 있으며 오
픈소스 자체의 특성에 대한 정보를 획득해야 함.
58
5) 조사
• 오픈소스의 기능 및 용도
• 라이선스 제약사항
• 개발언어 및 운영환경
• 컴포넌트 간 연계방식
• 오픈소스 커뮤니티 운영 주체
• 오픈소스 커뮤니티 활동성
• 오픈소스 커뮤니티 발전성
단계 활동 내용
탐색
초기에 급성장하는 오픈소스를 관찰하고 미래
사업에 핵심적인 기술 후보를 발견한다.
감지
기술 흐름과 고객 니즈에 따른 기술 적정성과
시장성을 파악한다.
육성
사업 가능성이 있는 기술을 비즈니스 모델과
연결시키고 육성시킨다
확보
필요한 인력을 확보하고 커뮤니티를 통해 기술을
확보한다.

INVESUME
>>
59
5) 조사
오픈소스 프로젝트 등록현황 (2014.12)
Enterprise Open Source Directory 오픈소스 솔루션 목록(공개SW역량프라자)

INVESUME
>>
60
5) 조사
•오픈소스의 기능 및 용도
•라이선스 제약사항
•개발언어 및 운영환경
•컴포넌트 간 연계방식
•오픈소스 커뮤니티운영주체
•오픈소스 커뮤니티활동성
•오픈소스 커뮤니티발전성
OS -> 하모니카
•군 장병의 클라이언트로써 사용 될 OS로, 오픈소스 라이센스, 한글화, 사용 편이성, 기반 OS의
성숙도 및 활성화, 레퍼런스(경찰청, 클래스메이트-학교전산실 적용)등을 고려하여 우분투 기
반의 하모니카(HamoniKR) OS를 사용.
미디어 서버 -> 아키텍처 변경
•통신 중계 및 실시간 스트리밍 영상 처리를 위해 소프트웨어 방식의 미디어 서버로 매우 활발히
개발되고 있는 MSA(마이크로 서비스 아키텍쳐)기반의 Kurento 오픈소스 프로젝트를 사용하
려 했으나 프로젝트 기간이 짧고 베타 수준의 상태로 버그가 많고 안정화 되어있지 않아 개발 중
뿐만 아니라 향후 납품 후에도 초기에 리스크가 발생 할 우려가 있어 제외함.
통신 중계 서버 및 통신 클라이언트용 SDK -> 오픈소스 easyRTC 활용
•미디어 서버를 사용하지 않기로 한 대신에 선택한 방안으로 WebRTC 기술에서 핵심적 요구사
항인 시그널링 서버 및 서버와의 통신에 사용되는 클라이언트용 SDK중 다양한 오픈소스 프로젝
트를 면밀히 검토.
미디어 중계 서비스 -> 오픈소스 coturn 활용
•WebRTC 영상통신에서 미디어 데이터의 중계가 필요한 경우가 있는데 이 서비스의 경우, We
bRTC 관련사이트나 커뮤니티에서 조금만 검색해봐도 이미 널리 알려진 유명한 coturn이라는
오픈소스 프로젝트가 있었기에 해당 제품을 선택.
웹 클라이언트 및 관리자 사이트 파트 -> Spring 3 오픈소스 프레임워크 활용 직접 개발
•군 부대별로 관리가 가능한 형태의 관리자 사이트가 필요로 했으며 웹 기반으로 제공되어야 했
다. 또한 관리에 의해 운영되는 회원 전용의 사이트가 필요했으며 모두 현시점에서 웹 개발에 가
장 많이 사용되는 스프링 3 프레임워크 기반의 자바 웹 프로젝트를 진행했다.

INVESUME
>>
오픈소스의 성숙도와 적용성을 평가하기 위해서 필요한 속성과 척도를 정의하고 평가 항목을 정량화시켜 기
능성, 이식성, 신뢰성, 사용성, 유지 보수성, 커뮤니티 영속성 등 오픈소스의 수준과 가치를 알아 낼 수 있는
데이터를 취합하고 정리하는 활동
61
6) 분석
• 오픈소스의 신뢰성
• 오픈소스의 현업 적용 가능성
• 오픈소스의 기능성
• 오픈소스의 사용성
• 오픈소스의 유지보수성
• 라이선스 제약사항
• 오픈소스 커뮤니티 영속성
중분류 세부항목
사용지원
이해성
학습성
운용성
분석성
전문기술
시험성
관리체계
기능지원
대체성
대체후기능성
설치성
지원성
상호운용성
커뮤니티
나이 및 규모
주체
접근성
성숙성
신뢰성
적합성
가용성
회복성

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

INVESUME
>>
63
오픈소스 성숙도 및 적용성 평가 지침의 사용 예
나이 및 규모
변수 = {버전 번호, 연령}
지표 = 최종 버전 번호 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. 인터넷 사이트에서 정보 제공
외부에서 커뮤니티로 연락하거나 관련 정보를 얻을 수 있는 용이성
오픈 소스 커뮤니티에 대해 전문 정보를 제공하는 인터넷 사이트로는
ohloh.net, wikipedia.org 등이 있음

INVESUME
>>
64
오픈소스 성숙도 및 적용성 평가 지침을 활용한 개방형 클라우드플랫폼 선정

INVESUME
>>
65
6) 분석(계속)
사용기술
•웹 표준을 준수하기 위해 HTML5 기술만으로 클라이언트를 개발해야 하는 이유로 통신
클라이언트에 사용되는 SDK는 Javascript를 사용해야 하며 어떤 플러그인도 요구되어
선 안됨.
비즈니스 적합성
•단순히 WebRTC 클라이언트가 아니라 각종 통신 서버를 포함한 전체 시스템이며 운영
상에 별도의 요금이 부과되지 않아야 했으므로 클라이언트 SDK만 제공하는 클라우드 형
태의 서비스는 이 프로젝트에 적용 할 수 없었다. 또한 소스상의 취약점에 대해서도 분석
이 가능해야 하므로 소스가 공개되고 수정 할 수 있는 오픈소스이어야만 했다.
활성도
•커밋, 포크(fork), 이슈 발생 빈도가 많다고 하여 활성화가 되었다고 판단하기 보다는 SI
프로젝트에서 사용되는 만큼 개발이 안정화 된 상태로 많은 사이트에서 사용하고 있는 오
픈소스이자 해외 블로그등을 통해 소개된 이력이 있고 개발자 커뮤니티 사이트(예, 스택
오버플로우) 또는 자체 포럼, Github의 이슈트래커에 질답등이 원활히 이뤄지고 있는지
확인 할 필요가 있었다.
커뮤니티 성숙도
•오픈소스화 시점 이후 릴리즈 횟수와 기간을 참고하였고 로드맵이 –어딘가에는, 예를
들면 개발문서, 포럼, 이슈트래커등– 분명히 명시되어있는 오픈소스 프로젝트를 선택하
고자 했다. 또한 Change Log등을 확인하여 발견된 버그와 미해결 버그등을 파악 할 수
있어야 했으며 문제점과 해결책을 명시하고 검색을 통해서 그러한 사항들을 확인 할 수
있는 프로젝트인지도 중요한 검토 사항이었다. 즉, 기술적 성숙도 보다는 오픈소스 프로
젝트에 대한 운영 방식과 시장 방식의 개발 철학을 잘 이해하고 있는지를 주요하게 검토
•오픈소스의 신뢰성
•오픈소스의 현업적용 가능성
•오픈소스의 기능성
•오픈소스의 사용성
•오픈소스의 유지보수성
•오픈소스 커뮤니티 영속성

INVESUME
>>
66
6) 분석
•오픈소스의 신뢰성
•오픈소스의 현업적용 가능성
•오픈소스의 기능성
•오픈소스의 사용성
•오픈소스의 유지보수성
•오픈소스 커뮤니티 영속성
학습 난이도
•SI 프로젝트에서 납품 기일을 맞추는 것이 중요하였으므로 현실적으로 가장 중요한 검토
항목이었다. 또한 프로젝트 멤버들의 기술 이해가 극명하게 나뉘어져 있어 되도록 학습해
서 적용하기 쉬운 오픈소스 프로젝트를 선택하였다.
보안성
•납품처 및 검수자가 보안성에 매우 민감하였다. 요구사항 역시 통신 전 구간에 걸쳐 암호
화 통신이 이뤄져야 했으므로 SSL 적용 여부 및 보안 강화를 위한 모듈을 개발 시 결합이
가능한지에 대한 검토가 이뤄졌다.
라이센스
•오픈소스 라이센스중 수정 및 배포에 심각한 제약이 없어야 하나 무료/유료 여부는 상관
이 없었다. (예, 오픈소스이면서 커머셜 라이센스도 있는 비즈니스 모델을 채택한 솔루션
인 경우)
기술지원 여부(유료)
•일반적인 질문뿐 아니라 기술적 지원이 공개된 포럼이나 이슈트래커 외에도 이메일 지원
여부, 온디멘드 서비스 지원여부가 가능한지 검토하였다. SI 프로젝트 진행 중에 발생 할
수 있는 문제에 대해 신속하고 정확한 응대가 필요한 경우가 종종 발생하였으므로 리스크
관리 차원에서 이점을 무시할 수 없었다.

INVESUME
>>
오픈소스의 도입, 개발, 대체, 전환, 기술지원, 유지 보수, 컨설팅, 교육 등을 목적으로 성숙도와 적용성을 수
치로 산출하는 활동
67
7) 평가
• 타 제품 이식성
• 라이선스 이슈
• 고객 충실도
비오픈소스의 품질속성
오픈소스의 품질속성 이해관계자 요구사항
오픈소스의 성숙도 모델의 설계

INVESUME
>>
68
7) 평가
비오픈소스의 품질속성
오픈소스의 품질속성 이해관계자 요구사항
• 타 제품 이식성
• 라이선스 이슈
• 고객 충실도
오픈소스 명 /
평가 항목
jitsi easyrtc skylink peerJS kurento
사용기술 10 10 10 10 10
비즈니스 적합성 9 9 0 9 9
활성도 7 8 7 5 8
성숙도 9 9 5 7 8
학습 난이도 8 10 10 8 3
보안성 9 8 * 7 9
라이센스 8 9 0 9 9
기술지원여부(유료) 10 10 10 0 5
결과 합(80점 만점) 70 73 42 55 61
최고 의사결정자(PD), 프로젝트 개발 매니저(PM), 프로젝트 개발 리더(PL) 세 사람의
의견이 가장 많이 반영되었고 프로젝트 멤버들의 조사도 있었으며 의견 또한 일부 반영

INVESUME
>>
오픈소스의 사용 조건과 의무사항 이행을 약속하는 활동. 오픈소스는 상용 제품과 다르게 라이선스에 대한
비용 청구 조건이 없으며, 배포 받고 사용하는 순간부터 해당 라이선스의 의무사항 준수에 동의한 것으로 간
주되므로 주의필요.
69
8) 계약
• 오픈소스 권리와 의무의 식별
• 오픈소스 보증(Warranty) 방안
• SLA 기반 품질 관리
• 장애로 인한 손실에 따른 손해보상
• 오픈소스 활용에 따른 지적재산권의 분쟁
• 계약의 목적
• 저작권 인정 및 라이선스 준수
• 계약효력 및 범위
• 용어의 정의
• 계약목적물
• 주문
• 계약이행 보증
• 지급이행 보증
• 납품
• 납기지체의 보상
• 납품의 변경 및 중지
• 검수 및 인도
• 대금청구 및 지급
• 하자이행 보증
• 계약의 해지
• 권리 및 의무의 양도
• 위험부담
• 손해보상
• 기술지원
• 지적재산권
• 비밀유지
• 분쟁의 해결
오픈소스의 계약의 필수 검토항목

INVESUME
>>
70
8) 계약
오픈소스 결합형태 라이선스 기능(사용목적) 비고
EasyRTC
웹클라이언트 SDK
라이브러리 BSD 2 통신
EasyRTC Server
백그라운드 서비스
/ 라이브러리
BSD 2
시그널링 서버,
미팅룸 관리 기능
구현
coturn 백그라운드 서비스 BSD 3 미디어중계서비스
OpenCV 라이브러리 BSD
얼굴인식, 워터마킹,
문자인식
이미지프로세싱
영역에만 사용
Jasypt 라이브러리 Apache 2
PBE(패스워드기반
암호화)
EasyRTC
iOS SDK
SDK Commercial iOS App 개발 계약필요
가격, 보증(Warranty)방안, 활용에 따른 지적재산권의 허용 범위 여부 확인
개발 소스에는 일부 라이센스의 정책에 따라 라이센스와 Copyright를 별도 파일로 만들어 고지.

INVESUME
>>
오픈소스 사용자 및 개발자를 통해 도출된 요구 사항을 충족시킬 수 있도록 컴포넌트, 모듈, 함수 등 기능 구
현 단위의 스펙을 정의하고 기능 구현 단위 간의 호출 관계, 파일 간의 의존 관계, 서비스 레이어, 공통 파라
미터 등 소프트웨어 구조 및 절차를 작성하는 활동
71
9) 설계
• 오픈소스 활용 장점을 반영하는 아키텍처
• 커뮤니티에 공개할 설계영역과 내부에서 관
리할 설계영역의 구분
• 내부개발자에 의한 기능의 구현
• 내부 조직에 의한 기능테스트 및 시험
• 알려진 버그에 대한 수정
마이크로 서비스 아키텍처의 예
Source : http://www.popot.kr

INVESUME
>>
72
9) 설계
• 책임의 분리를 통한 변경으로
발생되는 문제(Side effect)
를 최소화.
• 하지만 서비스 간의 통신에 대
한 처리가 별도로 필요
• 실제 개발에 앞서 설계 검증 및
기능 테스트를 위해 별도의 파
일럿 프로젝트를 수행
(Django REST Framework,
OpenCV/Python, Docker-
coturn, Docker-nodejs)
오픈소스 활용의 장점을 살리기 위해서는 모놀리틱 아키텍처 보다는 마이크로 서비스 아키텍처를 지향하
고 각 서비스 간 조합(Orchestration)에 유의하는 설계가 필수.
REST API
REST API

INVESUME
>>
73
마이크로 서비스 아키텍처
출처 : http://bcho.tistory.com/948 (마이크로 서비스 아키텍처의 이해, 조대협)
마이크로 서비스 아키텍처는 SOA 사상에 근간을 두고, 대용량 웹서비스 개발에 맞는 구조로 사상이 경량
화 되고, 대규모 개발팀의 조직 구조에 맞도록 변형된 아키텍처.

INVESUME
>>
74
마이크로 서비스 아키텍처 장점
• 각각의 마이크로서비스는 심플하며, 각각의 비즈니스 요구사항에 특화되어 있다
- 개발자가 관리하는 스코프가 명확해지게 되며, 이를 토대로 소프트웨어의 복잡성을 제어하는것이 가능해진다.
• 각각의 마이크로서비스는 다른 프로그래밍언어, 다른 도구를 사용하여 개발 할 수 있다
- 요구사항을 구현하기 위해 최적화된 언어와 아키텍처의 선택이 가능
마이크로 서비스 아키텍처 고려사항
• 서비스 범위 설정 문제 : 각각의 마이크로 서비스를 구성하는 범위는 어느 정도가 적절할까.
• 레거시 시스템과의 공존에 대한 고려
• 운영오버헤드 : 마이크로서비스는 엄청나게 많은양의 배포작업이 수반
• 인터페이스 불일치 : 마이크로서비스에서는 서비스간의 통신에 사용되는 인터페이스에 의존하게 되는데, 각각의 서비
스의 인터페이스를 변경하는것에 대한 영향범위를 파악하는것은 때에 따라서 만만치 않은 작업
• 코드 중복 : 단일한 언어나 프레임웍을 사용하여 개발된다고 하면 공유 라이브러리를 통해서 코드의 중복을 해결 할 수
있지만 여러 언어를 사용하여 개발이 진행되는경우 코드중복은 필연적으로 발생할 경우도 있다
• 테스트의 까다로움 : 비동기로 동작하는 마이크로서비스의 특성상 개별 서비스에 대한 테스트는 만들기가 수월하지만
런타임 환경상에서 비동기 상호작용을 테스트하기는 무척이나 까다롭다.
출처 : http://www.moreagile.net/2014/10/microservices.html

INVESUME
>>
설계 단계에서 정의된 기능 구현 단위의 소스코드를 작성하고 각 구성 요소를 묶어서 하나의 통합 소프트웨
어를 만드는 활동이다
75
10) 개발
• 오픈소스커뮤니티의 개발방법론
• 의사소통 수단
• 버전 관리
• 버그 추적 방안
• 테스트 및 디버깅
• 패키지 관리
• TDD, 코드리뷰 등
업스트림(upstream) 기반의 작업 패턴

INVESUME
>>
76
10) 개발(계속)
Git의 표준화된 Pull Request 방식에서 코드 리뷰는 의무적으로 하지 않았고, 매주 금요일마다 개발에 관
한 개인 별 주제를 정해서 발표하고 어떻게 코드에 적용하였는지 팀 내부 세미나를 진행. 애자일 프랙티스
중 조직에 적합한 스탠드 업 미팅, 스프린트 회고 등을 채택하여 개발.
 우분투 14.04 : 하모니카 OS와 유사하고
개발자들이 익숙한 OS
 Docker : PaaS
 Redmine : 할 일 관리, 이슈 관리
 Gitlab : 소스 저장소, 버전 관리
 Jenkins : 단위 테스트 자동화, 빌드 자동
화, 개발서버로 배포 자동화
개발 환경

INVESUME
>>
77
10) 개발
프로젝트에 사용 된 모든 소프트웨어들이 오픈소스인 관계로 대부분의 정보는 매뉴얼과 커뮤니티에 올라
온 질답을 참고하여 개발을 진행 하였으며 직접 질문을 올리기도 하였다. 안타깝게도 이 프로젝트에 사용된
기술들에 대해서 국내에선 온라인 상으로 문의 할 만 곳을 찾기 어려웠으며 기술적 아티클도 예제 수준에
지나지 않아 모든 정보 획득과 커뮤니케이션은 해외 사이트에서 할 수 밖에 없었다.
 Slack : 훅킹을 사용하여 저장소의 이벤
트 알림, 팀원간 커뮤니케이션
 데일리 스탠드업 미팅
 오픈소스 프로젝트와 커뮤니케이션 : 국
내 기술 문의처 없음.
 해외 커뮤니티와 직접 소통을 위한 커뮤
니케이션 담당자 배정 필요
커뮤니케이션

INVESUME
>>
오픈소스의 설치, 복제, 업데이트 등이 편리하도록 관련된 요소 프로그램을 모으고 구성에 필요한 보조 프로
그램 또는 유틸리티를 추가하는 작업. 이 단계에서 직접 개발한 소스코드와 외부에서 획득한 오픈소스를 결
합
78
11) 패키징
• 지원대상 운영체제 및 최소 환경
• 패키지 관리 방식
• 소스코드 저장소
• 지속적 업데이트 제공 방안
구분 패키지 방식
플랫폼 배포
Dpkg, RPM, tgz, pacman, IPS, OpenPKG,
ports, portage/emerge, apt-build, ABS 등
어플리케이션
배포
Composer, PEAR, CPAN, CRAN, Easyinstall,
PyPI, RubyGEms, Ivy, Maven 등

INVESUME
>>
79
11) 패키징
아키텍처 상에서 서비스로써 동작되는 구성요소들은 Docker 이미지로 만들었으며, 오픈소스 라이브러리
를 사용하여 개발 된 독립적 컴포넌트들은 자바 웹사이트의 경우 war, 영상보안 모듈의 경우는 다운로드,
컴파일, 빌드, 시스템 환경설정 수정 등을 자동화 시킨 스크립트를 추가로 개발
• 오픈소스를 그대로 가져다가 백그라운드 서비스로 운영하는
coturn의 경우는 Docker 이미지를 만들어 관리하였고
EasyRTC Server(시그널링 서버)가 요구하는 nodejs 환경
의 경우도 Docker로 관리.
• 실 통합 테스트에서 실제 운영 환경과 마찬가지로 물리적으로
다른 서버와 다른 네트워크에 위치시키기 용이하고 개발에서는
하나의 물리적 환경에서 관리하는 방식을 사용했기 때문에 백
그라운드 서비스를 Docker로 컴포넌트화 시켜 사용.
• 그 외 개발소스는 모두 maven을 사용하여 개발,테스트, 운영
서버용으로 패키지화 시키고 각 구동환경마다 환경설정을 변수
화 하였으며 maven 플러그인을 통해 CI 서버에서 매일 정해진
시간에 빌드가 자동화 되어 개발 서버로 배포.패키징 프로세스

INVESUME
>>
시험은 요구 사항 반영 여부와 설계 단계에서 정의한 사양이 오류나 장애가 없이 정상적으로 동작하는지 오
픈소스의 기능과 성능 그리고 품질 등을 확인하고 규명하는 활동
80
12) 시험
• 테스트 프로세스
• 테스트 통합 아키텍처
• 테스트 유형 (설치, 호환성, 단위, 회귀, 기능
/비기능 , 성능, 이용성, 국제화 테스트 등)
• 테스트 자동화
http://d2.naver.com/helloworld/87523
네이버 모바일 뉴스서비스 테스트

INVESUME
>>
81
12) 시험
웹 기반의 애플리케이션의 경우, 실행 즉시 서비스 페이지 동작 여부, 지속적인 부하 테스트가 필요로 했으
며 이를 위해 오픈소스 프로젝트인 http://locust.io 테스트 도구를 사용.
미디어중계서버의 경우는 자체 테스트 유틸리티가 제공되었으며 udp 통신, 멀티 클라이언트 통신, STUN
통신 등에 대한 테스트를 서버 내에서 수행.

INVESUME
>>
오픈소스를 외부 사용자에게 전달해 주는 활동으로서 전달 매체(인터넷, 저장소, 문서), 배포물의 형태(소
스코드, 실행 코드), 사용자 유형(고객, 불특정 개인·단체) 등에는 제한이 없다.
82
13) 배포
• 라이선스 의무 준수사항
• 배포의 유형
• 소스코드의 공개 방식
• 소스코드 저장소
• 지속적 배포가 가능한 아키텍처
지속적 통합 아키텍처

INVESUME
>>
83
13) 배포
• 백그라운드 서비스로 제공되는 EasyRTC Server, STUN/TURN 서버는 OS 및 라이브러리 종속성
이 강하며 컴파일, 빌드 과정이 복잡한 관계로 스크립트로 해결 될 문제가 아니라고 판단하여 Docker
이미지를 만들 수 있는 파일(Dockerfile)을 배포하는 방식을 채택
• 웹 클라이언트는 war 파일로 패키징하여 해당 사업 담당자에 우선 전송하고 검수를 거친 뒤, 내부 지
정된 PC를 사용하여 보안 클라이언트를 실행한 뒤 고객사 데이터센터에 있는 서버에 접속하여 개발
자가 수동으로 배포
• 모바일의 경우는 애플 앱스토어, 구글 앱스토어에 제출
컨테이너 이미지
생성파일 배포
WAR 배포 앱스토어 배포

INVESUME
>>
공급 계약된 오픈소스를 최초 구동할 수 있도록 서비스 제공자가 직접 작업을 수행하거나 최초 구동에 필요
한 소프트웨어 또는 관련 문서를 고객에게 제공하는 활동
84
14) 설치
• SW 설치 유형
• 설치 용이성
• 필수 환경변수
• 설치 가이드
• 사용 가이드
구분 상세설명
소스코드
컴파일은 가장 기본적인 설치 방법이다. 소프트웨어
개발자가 패키징을 해놓지 않았다면 제공되는 README
파일 또는 INSTALL 파일에 기재된 설치 방법을 보고
그대로 설치
바이너리
소스 컴파일의 과정은 없지만 해당 바이너리 파일이
구동되기 위한 라이브러리 버전을 맞춰 줘야 하고, 설치
후의 환경설정 과정도 소스 컴파일 방식과 동일
패키지 매니저
패키지 파일은 압축 파일로서 배포되는 소스 파일들 외에
설치 전 실행 스크립트, 설치 후 실행 스크립트 등을 가지고
있어서 사용자가 어플리케이션을 사용하기 위해 해야 하는
일들을 자동으로 해준다 (RPM, DPKG 등)
원격저장소
사용자가 패키지 간에 발생 했던 의존성을 해결하기 위하여
일일이 패키지를 찾아 다니지 않고, 명령어 한 줄로
간단하게 시스템에 어플리케이션을 설치. (YUM, APT-
GET 등)

INVESUME
>>
85
14) 설치
사용자 직접 설치가 어려운 SW아키텍처의 구성이므로 컨테이너 이미지와 동일한 환경의 서버 환경구축,
war 파일을 통한 웹 클라이언트 설치, 패키징 단계에서 개발 된 설치 스크립트를 활용하여 고객사 직접 방
문 설치 수행.
Dockerfile Bash script

INVESUME
>>
오픈소스를 원활히 사용할 수 있도록 인프라, 하드웨어, 네트워크, 소프트웨어 등 제반 환경을 구성하고 설
치된 오픈소스의 목적 기능을 제공하는 활동
86
15) 운영
• 운영 유형별 역할과 책임(R&R) 구성
• 내부운영조직의 전문성과 기술수준
• 운영기술 교육훈련 체계
• 외부업체와의 운영계약 경우 SLA
시스템 운영부문 역량체계

INVESUME
>>
87
15) 운영
• 운영 유형별 역할과 책임(R&R) 구성
• 내부운영조직의 전문성과 기술수준
• 운영기술 교육훈련 체계
• 외부업체와의 운영계약 경우 SLA
N/A

INVESUME
>>
오픈소스를 최고의 운영 상태로 구동시키기 위해서 버전 업데이트 및 패치, 버그 수정, 보안 취약점 개선, 설
정 변경 등 보완과 개선을 지속하는 활동
88
16) 유지보수
• 유지보수 유형별 유지보수 전개 모델
• 유지보수 조직 구성
• 사용된 오픈소스 프로젝트 모니터링 체계
• 결함관리 시스템과 프로세스
• 유지보수 업무별 관리 지침
• 외부위탁계약 경우 아웃소싱 관리방안
ITIL Service Lifecycle
출처 : ITILv3 mapping for PPM and SM Centers, Michael Yang, HP Software World 2008

INVESUME
>>
89
16) 유지보수
http://www.nextree.co.kr/p2581/
이슈관리 시스템 유지보수 문제해결 프로세스
사용된 오픈소스 기술은 매우 빠르게 변경되는 경우가 발생하였으며 이를 지속적으로 모니터링하여 변경
사항을 쉽게 확인 할 수 있어야 했다. 특히 WebRTC의 경우는 브라우저마다 표준의 구현 범위가 다르거나
최신 표준을 따르지 않는 경우가 발생하여 간혹 기능의 오류가 발견되기도 하였음.
Github Watch 등록 후 변화된 내용을 감지, 추적
하여 발생 할 미래의 문제에 대한 예비책을 강구하고
향후 업그레이드시 적용 할 태스크로 관리

INVESUME
>>
서비스 제공자가 오픈소스를 사용하는 고객에게 성능 개선, 장애 해결, 오류 수정, 추가 요구 사항 반영 등 오
픈소스 기술 기반의 서비스를 제공하는 활동. 가입자 계약에 의해서 제공되는 운영 및 유지 보수 서비스뿐만
아니라 요청 기반의 단기 서비스도 포함.
90
17) 기술지원
• 기술지원 업무유형별 조직구성
• 내부운영의 경우 관리기술, 분석도구, 관리
담당자
• 서비스데스크 및 관리 지침
• 외부위탁계약 경우 아웃소싱 관리방안
기술지원 업무 프로세스

INVESUME
>>
91
17) 기술지원
요청자
기술지원 담당자
메일
전화
웹폼
서비스
데스크
문제관리
오픈소스
커뮤니티
요청등록
(접수)
변경관리
릴리즈관리
(반영)
구성관리
(CMDB)
통계, 완료,
보고, 기록
내부
이슈관리
시스템
이슈트래킹
기술지원 요청이 접수되면 사용된 오픈소스와 관련된 이슈를 해결하기 위하여 이슈트래커를 통하여 오픈
소스커뮤니티와 소통하고 처리결과를 내부 지식DB로 축적.

INVESUME
>>
개발에 참여하여 사양을 정하고 소스코드를 기여하며 문제를 해결하는 것 뿐만 아니라 , 재정적 지원, 교류
참여 등도 포함. 어떤 수준의 활용 전략을 수립하는 지에 따라서 다양한 참여 방식이 가능.
92
18) 커뮤니티
• 커뮤니티 참여 정책과 전략의 연계 (단순사
용, 적극적 참여, 전략적 사용)
• 커뮤니케이션 담당자 또는 전담 조직
• 커뮤니티 참여 정책에 따른 업무 지침
• 커뮤니티 활동 업무 평가
• 지속적 관심과 참여
• 커뮤니티 활동 홍보 방안
오픈소스커뮤니티 활용 전략의 예

INVESUME
>>
93
18) 커뮤니티(계속)
초기 기술 도입 단계이므로 ‘단순 사용’ 전략으로 시작, 프로젝트에 사용된 기술은 기업주도형으로 발전된
커뮤니티의 유형이므로 주도 기업으로 부터 기술지원을 받을 수 있는 채널을 확인. 모바일 SDK 구매 계약
의 과정에서 향후 기술지원의 가능성과 범위에 대한 상호 협의를 진행.

INVESUME
>>
94
18) 커뮤니티
오픈소스 기술을 ‘전략적 커뮤니티 사용’ 정책으로 운영되는 경우도 다수.
예) 개방형OS 하모니카 커뮤니티의 경우 커뮤니케이션 담당자가 배정되어 있으며 커뮤니티에서 발생되는
여러 이슈에 대한 적극적 대응을 하고 있음.
• 한글화서비스 : http://hamonikr.org/tr/korean_bs.php
• 소스 저장소 : git.hamonikr.org
• 빌드시스템 : http://jenkins.hamonikr.org:8080/
• 빌드(Compiler)서버 : 내부망 운영
• S3-1 키아나 : 내부망 /
• S3-2 레베카 : 내부망 /
• S3-3 라파엘라 : 내부망 /
• 패키지저장소 : http://packages.hamonikr.org/
• packages.hamonikr.org:80
• 이슈관리 : http://git.hamonikr.org:3000/redmine
• 모니터링 : http://hamonikr.org/cubemon
일 평균 900명 방문

INVESUME
>>
오픈소스가 피배포자에게 전달되는 과정에서 배포자가 라이선스 의무사항을 준수하는 활동으로서 오픈소
스의 프로젝트 명칭, 원저작자 표기, 저작권 선언, 라이선스 명칭, 파일 경로, 결합 방법, 충돌 여부 등 준법에
관련된 정보를 제공
95
19) 컴플라이언스
• 사용권 고지의 의무
• 저작권 고지의 의미
• 소스코드 공개의 의무
• 특허 포기의 의무
오픈소스 컴플라이언스의 핵심 단계 (Samsung OSS Group)
https://blogs.s-osg.org/7-steps-to-strengthen-your-open-source-compliance/

INVESUME
>>
96
19) 컴플라이언스
오픈소스
발견 및 획득
오픈소스 활용
검토 및 승인
오픈소스 라이선
스 의무사항의
준수
http://www.oss.kr/oss_license/519476
• 사용권 고지의 의무
• 저작권 고지의 의미
• 소스코드 공개의 의무
• 특허 포기의 의무
오픈소스 소스코드 제공
•모든 오픈소스 BSD 및 Apache2 라이선스
오픈소스 라이선스 고지
•서비스 구성요소마다 배포단위로 모두 라이
센스와 Copyright를 고지한 별도의 파일을
포함하여 설치 시 배포.

INVESUME
>>
서비스 제공자가 오픈소스를 사용하는 고객에게 오픈소스에 관련된 제반 기술, 노하우, 기술, 경험, 유스케
이스, 교훈, 샘플, 패턴 등을 현장 또는 온라인 환경에서 제공하는 활동. 내부 교육활동과 외부 교육서비스로
구분.
97
20) 교육
• 내부 교육활동의 경우 사내 교육전문가
• 내부 오픈소스 역량강화 체계
• 교육 대상별 세분화된 교육내용(내부 개발
자, 내부 정책 결정자, 공급망 관계자 등)
• 오픈소스 역량 평가 모델
SW 역량관리 맵 – SW 구현 부문

INVESUME
>>
98
20) 교육
오픈소스의 도입, 활용, 배포에 대한 이해력을 높이기 위해 도제식 내부 기술교육을 통하여 지식을 전달하
고 오픈소스 활용 역량을 향상시킴. 자사의 경우 직무역량을 관리할 수 있는 교육훈련 체계를 보유하고 있
으므로 오픈소스 활용을 위한 직무교육계획에 따라 수행.
SW엔지니어 직무 교육 맵

INVESUME
>>
협의의 의미에서 사용자가 사용하는 오픈소스의 상태를 주기적으로 점검하고 기록하는 활동과, 광의의 의미
에서 향후 안정적인 운영과 유지 보수를 보장하기 위해서 해당 오픈소스 커뮤니티의 동향, 진행 현황 및 주요
이슈 등을 주기적으로 추적하고 검토하는 활동까지 포함.
99
21) 모니터링
• 사용중인 오픈소스 메일링리스트 가입
• 모니터링 업무 프로세스 및 지침
• 모니터링 활동 및 피드백
• 모니터링 결과 전사적 공유
모니터링 업무 수행과정
정보수집
전사공유

INVESUME
>>
100
21) 모니터링
라이선스 정책 변화 및 신규 버그 등에 관한 것은 각 프로젝트의 이슈트래커, 메일링 리스트, 포럼 회원 가입
을 통해 메일로 알림을 받고 있다. 심각한 버그가 아니라면 다음 릴리즈때 반영 하거나 향후 업그레이드시
고려해야 할 사항으로 소스상에 주석으로 기재하고 있음.
Github
watch
메일링
리스트
오픈소스
이슈트래
커

101
김형채 이사 (hckim@invesume.com)
같은 문제에 대해고민하는 사람들과 이야기하는 것을좋아합니다.
관련하여 기타 의견이나 문의사항이 있으신 경우 언제든지 연락주세요.
교육자료 다운로드 : http://www.slideshare.net/chaeya
블로그 : http://yes.imhappyo.com/

오픈소스와 거버넌스

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to 오픈소스와 거버넌스

Similar to 오픈소스와 거버넌스 (20)

More from Kevin Kim

More from Kevin Kim (13)

오픈소스와 거버넌스