공개SW 거버넌스 실무

공개SW거버넌스실무
Governanceforopensourcesoftwareadoption
2016.10.
김형채이사

개요 및 목표
공개SW를 기업 내에서 도입 및 운영 관리하기 위한 원칙, 절차, 단계별 관리요소를 식별
하고 기업 현장에서 실무 적용을 어떻게 하는지 적용 사례를 중심으로 공개SW 거버넌스
프레임워크의 이해 및 활용에 대한 내용
목표
개요
• 공개SW 거버넌스 개요
• 공개SW 거버넌스 프레임워크의 이해
• 공개SW 거버넌스 프레임워크의 실무 적용 역량 강화
2

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

목 차
공개SW
거버넌스
개요
공개SW
거버넌스
프레임워크
공개SW
거버넌스
프레임워크 활용
4

Why Open Source Software?
5
https://www.ted.com/talks/jimmy_wales_on_the_birth_of_wikipedia?language=ko#t-554074

참여와 공유를 통한 발전
6
“저희는 세계적인 디지털의 분배와 빈곤문제와 모든 사람들이 그들이 올바른
결정을 내리는데 필요한 정보를 얻을 수 있는 방법을 만드는 것에 관심이 아주
많습니다.
그리고 그래서 저희는 사람들이 원하는 모든 활동을 할 수 있도록 하기 위해서
공짜 모델을 선택했습니다.
해당 지역의 기업들을 돕고, 원하는 사람이면 누구나 우리 백과사전의 내용으
로 상업적, 비상업적 모든 용도로 이용할 수 있습니다.
따라서 수많은 기회가 위키피디아 주변에서 생길 수 있습니다.”
- 지미 웨일스, 위키피디아 창시자

트렌드 및 전망
7
포레스터 리서치와 IDC의 미래전망 - http://www.itworld.co.kr/news/97250
1. 레거시 벤더들이 직면한 암울한 미래
• IDC는 보고서를 통해 "향후 5년 내 현존하는 IT 벤더들 가운데 30%가 사라지게 될 것이다"
• 이는 산업의 본질이 변화하고 있음을 드러내는 신호
2. 클라우드 공급업체들도 걸러질 것이다
• 포레스터는 '이제 클라우드 업체를 추려 낼 시점'이라고 진단
3. 더욱 커지는 빅데이터의 역할
• 빅데이터는 신약 발견, 헬스케어, 교육, 번역, 고용, 리크루팅 등등, 다양한 분야를 변화시키고 있음.
4. 소프트웨어 기업으로 변해가는 기업들
• 여러 IT기업들이 전통적인 벤더에서 클라우드 업체로 고개를 돌리고 있다. 또한 오픈소스 역시 점점 더 활용해가는 추세.
5. 개발자가 부족해진다
• 앞으로는 애플리케이션 개발과 관련된 모든 것이 변화한다. 사용하는 언어도, 데이터베이스도, 프레임워크도, 실행 환경도
다 달라진 애플리케이션 환경이 부상할 것이다.
• 다시 말해 거의 모든 것이 새롭게 변하며, 구세대 애플리케이션에 맞는 스킬들과는 다른 스킬들이 요구될 것.

글로벌 공개SW 사용 분야
63%
CLOUD/
VIRTUALIZATION
57%
CONTENT
MGMT
MOBILE SECURITY COLLABORATION NETWORK
MGMT
53% 51%
49% 48%
Source: 2014 Future of Open Source Survey Results - Blackduck
8
전 세계 78%는 공개SW를 사용 중 , 64%는 공개SW 프로젝트 참여 중,
75%의 기업이 공개SW를 통해 매출 증대

국내 공개SW 시장규모
9
• 한국공개SW 시장의 2009~2015년간 평균성장률(CAGR) 32.9%
• 2015 시장규모는2009년 대비 5.5배
• 2017년 1,000억 원 초과 예상

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

공개SW 라이선스 준수의무
11출처 : 정보통신산업진흥원

공개SW 관리에 대한 준비
12

Source : https://www.masterflexgroup.com/fileadmin/_migrated/pics/TopBild_696x224px_Group_CorporateGovernance.jpg
1. 공개SW 거버넌스
13

공개SW 거버넌스에 대한 인식
14

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

Open source software Governance
16
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)
• 오픈소스 거버넌스는 오픈소스 소프트웨어를 제품과 서비스, 공급망과 비즈니스 관리활동, 그리고 비즈니스 협
력과 법적 활동 등의 조직 관리 방법

공개SW 거버넌스의 범위
Corporate Governance
Information
Technology
Governance
Information
Security
Governance
Open Source Software
Governance
17

2. 공개SW 거버넌스 프레임워크
OSS Governance Framework?
18

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

공개SW 거버넌스 프레임워크 구성
20
공개SW활용
라이프사이클
순차적
공개SW거버넌스
활동요소 (18)
비 순차적
공개SW거버넌스
활동요소 (3)

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

Source : https://cdn4.iconfinder.com/data/icons/SOPHISTIQUE/web_design/png/400/our_process_2.png
3. 공개SW 거버넌스 프레임워크 활용
22

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

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

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

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

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

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

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

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

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

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

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

34
5) 조사
공개SW 프로젝트 등록현황 (2014.12)
Enterprise Open Source Directory 공개SW 솔루션 목록(공개SW역량프라자)

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

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

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

38
공개소프트웨어 성숙도 및 적용성 평가 지침의 사용 예
나이 및 규모
변수 = {버전 번호, 연령}
지표 = 최종 버전 번호 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 등이 있음

39
공개소프트웨어 성숙도 및 적용성 평가 지침을 활용한 개방형 클라우드플랫폼 선정

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

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

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

43
7) 평가
비공개SW의 품질속성
공개SW의 품질속성 이해관계자 요구사항
• 공개SW 커뮤니티
• 타 제품 이식성
• 라이선스 이슈
• 고객 충실도
오픈소스 명 /
평가 항목
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) 세 사람의
의견이 가장 많이 반영되었고 프로젝트 멤버들의 조사도 있었으며 의견 또한 일부 반영

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

45
8) 계약
공개SW 결합형태 라이선스 기능(사용목적) 비고
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를 별도 파일로 만들어 고지.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

69
18) 커뮤니티
공개SW 기술을 ‘전략적 커뮤니티 사용’ 정책으로 운영되는 경우도 다수.
예) 개방형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명 방문

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

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

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

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

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

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

본 교육에서 이야기한 공개소프트웨어 거버넌스 프레임워크
의 내용은 아래의 경로에서 PDF로 다운로드 가능합니다.
http://www.oss.kr/oss_repository12/628521

77
김형채 이사 (hckim@invesume.com)
같은 문제에 대해고민하는 사람들과 이야기하는 것을좋아합니다.
관련하여 기타 의견이나 문의사항이 있으신 경우 언제든지 연락주세요.

공개SW 거버넌스 실무

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 공개SW 거버넌스 실무

Similar to 공개SW 거버넌스 실무 (20)

More from Kevin Kim

More from Kevin Kim (13)

공개SW 거버넌스 실무