오픈소스 소프트웨어는 인공지능(AI), 사물인터넷(IoT), 클라우드 빅데이터 등 다양한 분야에서 4차 산업혁명과 지능정보사회의 핵심 기술로 부상하고 있습니다. 글로벌 시장에서는 구글, 페이스북 같은 글로벌 대기업도 개방형 혁신활동을 중요하게 여기며 이를 위하여 자사의 기술을 외부에 공개하고 오픈소스 커뮤니티를 중심으로 핵심기술을 주도하려는 노력을 하고 있습니다.

전통적으로 기술혁신은 자체적인 우수 인적자원의 확보 및 효율적 내부자원의 활용을 중심으로 조직 내부의 연구개발을 통해 이루어져 왔습니다. 이러한 방식은 아이디어의 발굴에서 기초연구, 제품개발, 사업화에 이르는 모든 기술혁신의 과정을 기업 내부에서 독자적으로 수행하는 것을 의미합니다. 

그러나 기술의 복잡성이 증대하고 제품 수요가 다양해지고 시장경제의 글로벌화가 가속되며 기술혁신의 비용은 급증하는 상황을 맞이하여 조직의 연구개발 생산성을 제고하기 위해 기술혁신 과정에서 외부와 협력하는 현상이 확대되고 있는데 UC버클리 대학의 Chesbrough 교수가 주창한 개방형 혁신(open innovation) 이론에 따르면 개방형 혁신의 개념을 다음과 같이 요약하고 있습니다.

“개방형 혁신은 기업이 안으로의 지식 흐름(inflow)과 밖으로의 지식 흐름(outflow)을 적절히 활용하여 내부의 혁신을 가속화하고 혁신의 외부 활용 시장을 확대하는 것이다. 개방형 혁신은 기업들이 내부 아이디어뿐 아니라 외부 아이디어도 활용할 수 있고, 또 활용해야 하며, 자사의 기술을 상업화하여 시장에 진출할 때 내부뿐 아니라 외부 경로도 사용할 수 있고, 또 사용해야 함을 전제하는 혁신 패러다임이다. 개방형 혁신과정은 내부와 외부 아이디어를 결합하여 아키텍처와 시스템을 구현한다. 이 아키텍처와 시스템에 대한 요구 사항은 비즈니스 모델을 통해 정의된다. 비즈니스 모델은 내부와 외부 아이디어를 활용하여 가치를 창출하고 그 창출된 가치의 일부를 자사의 몫으로 전유하기 위한 내부 메커니즘을 정의한다. 개방형 혁신은 부가가치를 창출하기 위해 내부 아이디어가 외부 경로, 즉 기업의 기존 비즈니스 모델 밖에 있는 채널을 통해 시장으로 나갈 수 있음을 전제한다 (Chesbrough 2006b: 1)” 

이론에 따르면 개방형 혁신은 연구, 개발, 상업화에 이르는 일련의 기술혁신 과정에서 조직 내부와 외부 사이에 일어나는 모든 형태의 지식 교류 활동을 의미하며, 집단 지성을 활용한 지속적인 개선과 사용자 피드백을 반영한 기술혁신이 이루어지는 오픈소스 커뮤니티는 개방형 혁신 활동의 대표적인 예로 볼 수 있습니다.

우리나라도 최근 이런 흐름을 반영해서 전통적인 연구개발을 오픈소스 개발방식으로 진행하려는 오픈R&D에 대한 학교와 기업의 흐름이 증가하고 있죠. 

저는 리눅스 커뮤니티 하모니카(http://hamonikr.org)를 운영하고 있는데 최근에 활발하게 커뮤니티가 성장하고 있으며 현재 하모니카 커뮤니티는 월평균 만명정도의 방문자가 있습니다. [참고] 웹로그 분석 : http://hamonikr.org/board_aMBI05/49687

때문에 저 자신도 오픈소스 커뮤니티 운영에 고민이 있고 그러다 보니 오픈소스 커뮤니티의 구축과 운영을 어떻게 하면 좋을지에 대한 현장의 고민을 자주 듣습니다. 

오늘은 오픈소스 커뮤니티를 구축하고 운영하는데 무엇이 필요할지 정리해 보겠습니다.


오픈소스 커뮤니티 현황 

오픈소스 커뮤니티[5]란 누구에게나 프로그램의 소스코드에 대한 동등한 접근을 보장하고 책임과 권한을 공유하며 지속적인 개발자와 사용자의 기여에 의해서 프로젝트가 변하는 커뮤니티를 의미하며, 오픈소스 커뮤니티를 기반으로 형성되는 소프트웨어 개발 모델은 소프트웨어 릴리스를 위한 활동을 중심으로 형성되는 개발자 커뮤니티와 공개된 소프트웨어에 대한 테스트, 버그 제출, 의견 제시 등을 중심으로 형성되는 사용자 커뮤니티가 존재합니다.


그림 1 Open Source Development Model


정보통신산업진흥원의 최근 조사 자료에 의하면 전 세계 대표적인 오픈소스 소프트웨어의 소스코드 저장소인 깃허브(Github)에서는 약 38만 건의 프로젝트 개발이 활발히 진행 중이며, 약 2,000만 명이 약 16만 개의 오픈소스 커뮤니티에서 소프트웨어 개발 및 프로젝트 기여를 위해 사용자․개발자로 참여하고 있다고 합니다. 이에 비해 국내의 경우 총 248개의 오픈소스 커뮤니티가 운영중인 것으로 파악되어 글로벌 대비 0.1% 수준의 규모이며 그 중에서도 사용자 커뮤니티 214개(86%), 개발자 커뮤니티 34 개(14%)로 국내 오픈소스 커뮤니티의 다수는 오픈소스의 사용자 커뮤니티로 조사되었습니다. 


조사 결과에 따르면 해외에서는 여러 재단을 중심으로 커뮤니티에서 오픈소스 프로젝트의 개발 참여와 기여가 활발하지만 국내에서는 개발에 참여보다는 오픈소스 커뮤니티가 제공하는 결과물을 활용하거나 사용법을 묻는 것이 대부분으로 나타났으며 또한 국내 오픈소스 커뮤니티 중 해외 오픈소스 커뮤니티와 프로젝트를 공유하거나 국제 행사 참가를 통해 교류중인 커뮤니티는 14개로 파악되었습니다. 국내의 오픈소스 생태계는 생산자 관점의 오픈소스 커뮤니티 활용이 매우 저조한 실정임을 알 수 있습니다. 따라서 향후 국내 기업의 오픈소스 커뮤니티 기반 개방형 혁신을 확산하기 위해서는 현재의 사용자 커뮤니티 중심의 국내 오픈소스 커뮤니티를 글로벌 개발자 커뮤니티와 상호 협력할 수 있도록 지원하는 노력이 필요하다고 생각합니다.


오픈소스 커뮤니티의 구축 


직접 오픈소스 커뮤니티를 구축하기 전에 먼저 원하는 공개하려는 소프트웨어와 유사한 관심사에 대한 커뮤니티가 국내·외에 이미 존재하는지 검색하는 것이 중요합니다. 

만약 동일한 관심사의 커뮤니티가 이미 존재하는데 새로운 커뮤니티를 형성하려고 하면 참여자들의 커뮤니티의 신규 생성에 대한 당위성을 설득하기 어려우며 기존의 다른 오픈소스 커뮤니티의 지지를 얻기 힘들기 때문입니다. 따라서 만약 유사한 관심사를 다루는 오픈소스 커뮤니티가 이미 존재한다면 별도의 커뮤니티를 생성하여 새로운 기반을 형성하는 것 보다는 해당 커뮤니티에 참여하여 협업하는 것이 가장 좋습니다.

이 경우에는 이미 오픈소스 커뮤니티 활성화의 기반이 존재하기 때문에 공개하려는 소프트웨어를 해당 커뮤니티의 사용자들이 사용할 수 있도록 해당 기능을 추가로 제안하여 기존 공개된 소프트웨어의 기능을 강화하는  방식의 접근이 필요합니다.

기존의 커뮤니티 중 공개하려는 소프트웨어와 유사한 관심사를 가진 커뮤니티가 없는 경우 새로운 오픈소스 커뮤니티는 생성하게 되는데, 이렇게 생성되는 오픈소스 커뮤니티의 성장 단계는 Tech-nical Stage, Open Source Stage, Ecosystem Stage의 세 가지 단계로 구분할 수 있습니다.


그림 2 오픈소스 커뮤니티 성장단계


Technical Stage

Technical Stage는 오픈소스 커뮤니티의 참여자들 중 개발자들 보다는 사용자들을 대상으로 공개한 소프트웨어의 바른 사용 방법과 권한을 제공하는 것에 중점을 두는 단계이며 이 단계에서는 공개한 소프트웨어의 라이선스를 컴포넌트 별로 식별한 소프트웨어 라이선스 프레임워크를 통해 프로젝트의 라이선스 정책을 사용자들에게 배포하고 공개한 소프트웨어의 기능을 확인할 수 있는 프로그램 데모를 제공하는 것이 필요합니다. 프로젝트를 소개할 수 있는 웹사이트, 제공하는 소스코드를 다운로드 할 수 있는 공개된 저장소, 의사 소통을 위한 메일링 리스트와 커뮤니케이션 채널, 프로그램의 버그를 추적관리 할 수 있는 버그 트래킹 도구, 각종 문서를 쉽게 작성해 공유할 수 있는 문서화 도구 등이 필요하게 되며 사용자들이 공개된 소프트웨어를 활용할 수 있는 범위와 사용에 따르는 책임을 명확하게 인지할 수 있도록 준비해야 합니다.


Open Source Stage

Open Source Stage는 오픈소스 커뮤니티에 참여하는 사용자와 개발자를 대상으로 잘 구성된 오픈소스 커뮤니티 거버넌스 모델을 구축하는 데 중점을 두는 단계이며 이 단계에서는 커뮤니티 참여자들에게 프로젝트의 구조를 쉽게 설명하는 문서를 준비하고, 프로젝트의 로드맵을 제시하게 됩니다. 또한 커뮤니티 참여자가 어떻게 참여할 수 있는지를 개발자와 사용자로 구분하여 자세히 알려주고, 커뮤니티 내 분쟁이 일어나거나 의사결정이 필요할 때 어떤 방식의 의사결정과정을 따르게 되는지를 투명하게 공개해야 합니다.

오픈소스 커뮤니티의 전략적 방향에 따라 수많은 유형의 거버넌스 문서가 필요할 수 있으나 일반적인 오픈소스 커뮤니티 거버넌스 문서에 포함되어야 하는 공통적인 요소는 다음과 같습니다.

    • 개요 (overview)

    • 역할과 책임 (roles and responsibili-ties)

    • 지원 (support)

    • 기여 과정 (contribution process)

    • 의사결정 과정 (decision making pro-cess)


Open Source Stage 단계에서는 커뮤니티 참여자들의 역할과 책임에 따른 운영 조직이 구성되고 커뮤니티 운영 조직과 커뮤니티 참여자 간 투명한 합의를 기반으로 커뮤니티 운영이 이루어져야 합니다. 이를 위해서 프로젝트 마일스톤과 릴리스를 관리할 수 있는 프로젝트 관리도구, 개발자 및 사용자를 위한 포럼, 이슈관리, 자동화 빌드, 소프트웨어 품질 가시화, 문서 협업 도구 등이 필요하며 외부의 참여자들이 프로젝트에 어떻게 기여할 수 있는지 자세히 안내하는 문서를 준비하고, 커뮤니티의 참여자들과 지속적으로 소통을 유지하는 것이 중요합니다 


Ecosystem Stage

공개한 소프트웨어의 사용자의 수가 늘어나고 오픈소스 커뮤니티가 성장하면서 커뮤니티 참여자들에 의한 사용자 지원으로는 기업 사용자들이 요구하는 서비스 수준을 제공하지 못하는 문제가 발생하게 되는데 Ecosystem Stage는 오픈소스 커뮤니티의 확산과 지속가능성을 보장하기 위하여 공개한 소프트웨어를 이용하여 비즈니스에 활용하는 기업 멤버들과 다른 오픈소스 커뮤니티와 함께 상생협력을 중점으로 운영하는 단계입니다. 따라서 이 단계에서는 프로젝트를 지원할 수 있는 기업들로 구성된 비즈니스 협의체가 조직되고 공식 기술지원 파트너 기업이 커뮤니티에서 홍보되어 기업에서 공개된 소프트웨어를 사용하기 위한 신뢰성을 제공할 수 있도록 커뮤니티에 참여하는 기업들을 중심으로 긴밀한 관리가 필요합니다.

이클립스 재단의 경우 다음과 같이 사용하는 프로젝트의 파트너 기업들이 제공하는 제품을 소개하는 마켓플레이스를 직접 운영하며, 활용 사례를 소개하고, 공식적인 기술지원이 가능함을 홍보하여 프로젝트의 신뢰성을 확보하고 있습니다.


그림 3 Eclipse Foundation Marketplace


이처럼 오픈소스 커뮤니티가 원활한 지속적 운영을 보장하기 위해서는 공개한 소프트웨어를 기반으로 기술지원을 제공하는 파트너 기업을 발굴하고 기업 멤버를 커뮤니티에 흡수하여 커뮤니티의 발전방향이 커뮤니티 참여 기업의 비즈니스 전략에 영향을 미치는 관계가 형성되어야 자연스럽게 커뮤니티 지속을 위한 재원 확보가 이루어지고 향후 공개한 오픈소스 프로젝트를 중심으로 성공한 재단의 형태로 성장하는 것을 기대할 수 있습니다.


오픈소스 커뮤니티의 운영 


오픈소스 소프트웨어 프로젝트 및 커뮤니티 운영이 성공하기 위하여 가장 중요한 요소는 투명성과 문서화를 꼽을 수 있습니다. 

투명성은 프로젝트 관련하여 참여하는 사람들과 외부 참여자들에 대한 프로젝트 관련 도메인 및 기능을 어떻게 유지할 것 인가에 대한 명시를 의미하는데 오픈소스 소프트웨어의 특성상 투명성의 유지는 대단히 중요할 뿐 만 아니라, 기업에 의해서 주도되는 오픈소스 소프트웨어라면 투명성의 확보는 해당 오픈소스 소프트웨어 커뮤니티의 운명을 쥐고 있는 열쇠라고 해도 과언이 아닙니다. 

어떤 오픈소스 소프트웨어 개발자들도 보이지 않는 장막 뒤에서 펼쳐지는 오픈소스 소프트웨어에 참여하고 싶은 사람은 없으며 특히 기업이 오픈소스 소프트웨어 전환을 시도할 경우, 그 동안 기업 내부의 습관에 의해 투명성을 소홀히 하고 내부 프로세스를 공개하지 않는 경우가 있는데, 그런 경우 커뮤니티를 활성화하기란 매우 어려우며 오픈소스 소프트웨어 커뮤니티로의 전환의 실패로 이어질 확률 또한 매우 높습니다.

오픈소스 커뮤니티에 투명성이 필요한 요소는 공개한 소프트웨어의 비전, 로드맵, 릴리스 계획, 형상관리 계획, 커미터 자격 조건, 새 기능 추가 또는 소프트웨어 패치의 제출 과정 등이 대상입니다. 

오픈소스 커뮤니티 운영의 다른 한가지 중요한 요소는 문서화입니다. 실제로 오픈소스 소프트웨어는 자발적으로 참여하는 사람들이고 개발자 위주로 돌아가는 생태계이기 때문에, 문서화에 소홀하게 되는 경우가 많습니다. 

커뮤니티의 운영을 위해서 공개한 소프트웨어 자체에 대한 문서화와 오픈소스 커뮤니티의 구조 및 프로세스에 대한 문서화도 포함하여 작성해야 합니다. 문서를 통해서 커뮤니티 거버넌스 모델 명시, 커뮤니티 구조 및 프로세스 명시뿐만 아니라, 해당 소스코드에 대한 문서화도 명확하게 해두어야 많은 사람들이 참여하여 오픈소스 소프트웨어 커뮤니티를 활성화 시키게 되기 때문에 커뮤니티에 참여하는 개발자 및 사용자들이 쉽게 이해하고 도움을 받을 수 있으며, 참여자들이 쉽게 편집할 수 있는 수준의 문서화를 제공하는 노력이 중요합니다.


마치며


해외의 경우 Apache, Eclipse, Openstack, Linux 등 다양한 오픈소스 재단이 설립되어 클라우드, 빅데이터, 인공지능 등 분야에서 핵심 기술을 주도하고 있는데 비해 국내에서는 공개된 소프트웨어를 가져다 쓰는 사용자 커뮤니티를 중심으로 오픈소스 커뮤니티가 형성되어 있으며 글로벌에 영향력이 있는 개발자 커뮤니티는 찾아보기 힘든 실정입니다.

최근 우리 정부는 국가의 ICT R&D 경쟁력 강화를 위한 지속적인 정책적 노력과 집중 투자에도 불구하고, 창의적․선도적 혁신역량 제고와 성과확산에 한계를 인식하고 개방형 혁신의 장점을 반영한 핵심 원천기술의 오픈R&D를 추진하여 미래 유망기술을 글로벌 시장에서 선도하고 연구개발 결과물의 활용도를 제고하기 위하여 노력하고 있으나 외부의 참여자들과 협력하는 오픈소스 커뮤니티 기반의 개방형 혁신에 익숙하지 않은 연구기관들은 체계적인 관리모델의 부재로 인한 혼란이 가중되고 있습니다. 

오픈소스 커뮤니티를 중심으로 세계시장 기술 경쟁력 기반확보를 위해서 정부에서는 오픈소스 생태계를 이해하고 소프트웨어 기술 연구개발을 오픈소스 프로젝트를 방식으로 전환하고 오픈소스 커뮤니티를 통한 사용자 저변이 확산될 수 있도록 지속적인 노력을 기울여야 하며 기업의 경우 오픈소스 커뮤니티에 참여하는 내부 개발자에 대하여 비판적인 시각에서 벗어나 글로벌 오픈소스 프로젝트의 참여와 기여는 기업의 우수한 기술력을 홍보하는 효과적 수단임을 인식하고 내부 개발자의 오픈소스 커뮤니티 참여 활동을 적극 권장하고 기업의 비즈니스 전략에 오픈소스 커뮤니티와 연계한 개방형 혁신을 위한 노력이 필요합니다.


참고문헌

  • 김석관 : Chesbrough의 개방형 혁신 이론. 과학기술정책, 2008 

  • OW2 : open source software the governance makes the difference. https://www.slideshare.net/OW2/open-source-software-the-governance-makes-the-difference, 2015

  • 조재홍 : 공개SW 소비국을 넘어 기여국으로 성장을 위한 제언. NIPA, 2018









'오픈소스SW' 카테고리의 다른 글

무료 데스크톱 OS들  (1) 2019.04.18
개방형 데스크톱 OS 동향  (0) 2019.04.05
오픈소스와 특허  (0) 2017.07.10
공개SW R&D 추진전략  (0) 2017.03.22
해외 기업들의 오픈소스 활용 비즈니스 전략  (0) 2016.10.27

주말에 공개SW 개발자대회 참가자를 위한 멘토링이 토즈에서 있었습니다.

다른 참가자 분들에게도 도움이 될지 모르니, 제가 멘토링한 부분에 대해서 정리해서 공유해 두려고 합니다.



제가 준비해간 멘토링의 진행순서는 다음과 같습니다.


1) 참가자 현황분석

2) 대회를 위해서 준비할것 협의

3) 멘토링에서 얻고 싶은 목표 합의

4) 멘토링

5) 향후 멘토링 계획안 협의


제가 담당한 멘티들의 현황을 분석한 결과는 다음과 같습니다.


A팀)

 - 보안기술동향을 분석하지 않은 낮은 기술성

 - SW의 가시성 확보 필요

 - 불확실한 개발 일정 계획

 - 개발문서의 미흡


B팀)

 - 공개SW를 이용한 비즈니스시 위험관리

 - 공개SW 커뮤니티를 활용한 비즈니스 방법

 - 비즈니스를 위한 공개SW 라이선스 컴플라이언스 방안


C팀)

 - SW의 가시성 확보 필요

 - 개발문서의 미흡

 - SW품질에 대한 이해 부족


각각의 이슈에 대하여 제가 취한 조치는 아래와 같습니다.


기술동향 : 최근의 보안기술동향 및 관련사이트 소개

SW의 가시성 : 정적분석도구에 대한 소개 및 활용법, 테스트 커버리지에 대한 가이드, 유닛테스트 및 테스트자동화 안내

개발문서 : 개발방법론 소개 및 개발 산출물 관리방안 가이드

공개SW 비즈니스 위험관리 : 공개SW를 기반으로 외부서비스를 하는 기업의 경우에 필요한 거버넌스 체계소개

공개SW 커뮤니티 운영 : 공개SW 커뮤니티 운영유형 및 필수요소 가이드

라이선스 컴플라이언스 : SW 라이선스 유형 소개 및 활용방안 제시.


짧은 시간에 전달하기에는 내용이 많이 부족했기 때문에 각 팀별로 멘토링 내용을 메일로 전달해주고, 향후 멘토링 가능한 일정계획을 제시해주고 마무리했습니다.


부족한 시간때문에 멘토링에 대한 회고를 하지 못해서 아쉬움이 남네요.








오늘 페이스북 타임라인을 읽다보니 '리눅스 HWP 공개 라이브러리 개발' 건에 대한 라이선스 이야기를 하는 글들이 보이네요. 저도 예전에 FCKEditor를 적용한 제품때문에 LGPL의 정체가 뭔지 몰라서 어려웠던 기억이 납니다. 글타래를 읽다보니 LGPL에 대해서 애매한 이야기들이 좀 있는것 같아서 정리해봅니다. 


1. 공통적으로 지킬 것

일단 OSI(Open Source Initiative)에 등록되어 있는 오픈소스SW 라이선스는 GPL이건 LGPL 이건 상관없이 공통적으로 지켜야 하는 내용이 두가지 있습니다. 


가. 저작권 관련 문구 유지

- 가져다 쓰는 것은 자유롭게 하고 개발자의 정보는 삭제하지 않는 것이죠. 이것은 원 저작권자의 인격을 보호하기 위한 사항으로 마음대로 삭제하시면 안됩니다.


나. 제품명 중복 방지

- 아파치, 리눅스 같은 프로젝트명을 선택하면 안된다는 의미입니다.


두 가지 모두 무엇인가를 직접 만들어본 사람이라면 상식적인 수준에서 지켜야 하는 것이죠.


2. LGPL 라이선스를 가져다 쓰는데 소스코드를 공개해야만 하나요?

LGPL은 GPL의 조건이 너무 엄격해서 사람들이 쓰는 것을 꺼려할까봐 이를 감안해서 만든 라이선스 입니다. 따라서 GPL과는 다르게 LGPL 라이브러리에 응용프로그램을 정적 혹은 동적으로 링크시킨다고 해도 응용프로그램의 소스코드를 공개할 필요가 없습니다. LGPL 전문에 있는 ”라이브러리의 복제본을 무상이나 유상으로 배포할 경우에, 당신은 우리가 당신에게 부여한 모든 권리를 수취인에게도 그대로 부여해야 한다.“라는 내용으로 요구 조건만 준수한다면 상업적인 유상 배포도 허용하고 있습니다. 따라서 자기가 만든 소스코드의 공개없이 가격을 받는 상용제품으로 판매하셔도 됩니다.


다만, LGPL 라이브러리의 소스코드를 수정하였을 때에는 2차적 파생 저작물에 해당하므로 라이브러리의 소스코드를 제공해야 합니다.


3. LGPL을 가져와서 개발하고 GPL 라이선스로 변경해도 될까요?

대답은 변경해도 됩니다. 아래 내용을 보시면 "양도받은 라이브러리의 복제물에 본 라이선스 대신 GNU 일반 공중 라이선스의 규정들을 적용시킬 수 있다"라고 표기되어 있습니다. 하지만 GPL 소스코드를 가져와서 임의로 LGPL로 변경하는 것은 안됩니다.


http://olis.or.kr/ossw/license/license/detail.do?lid=1005&mapcode=&currentPage=

3.

 당신은 양도받은 라이브러리의 복제물에 본 라이선스 대신 GNU 일반 공중 라이선스의 규정들을 적용시킬 수 있다. 이를 가능케 하기 위해서는 본 라이선스를 언급하는 모든 사항들을 GNU 일반 공중 라이선스 버전2의 사항들로 대체시켜야 한다. (만약 GNU 일반 공중 라이선스 버전 2 이후에 신규 버전이 공표되었을 경우에는 원한다면 신규 버전을 사용할 수 있다.) 그 외에 다른 사항들은 변경할 수 없다.

복제물에 대해 이러한 수정이 이루어졌을 경우에는 라이선스를 다시 변경하는 것은 불가능하며, 따라서 해당 복제물을 기반으로 만들어진 모든 저작물과 복제물에는 GNU 일반 공중 라이선스가 적용되어야 한다.

이러한 선택 사항은 라이브러리의 코드 일부분을 라이브러리가 아닌 프로그램에 포함시키고자 할 경우에 유용하다.

하지만 LGPL을 제외한 나머지 라이선스는 원 저작자가 아닌 사람이 임의로 라이선스를 변경할 수 없습니다. LGPL은 명확하게 전문에 표기하였기 때문에 문제가 없지만 다른 오픈소스SW 라이선스는 이를 허용하지 않습니다. 


4. 더 궁금하시면

다른 오픈소스SW 라이선스에 대하여 궁금하시다면 아래의 링크를 이용하시면 됩니다.

- 한국저작권위원회 라이선스 설명 : http://olis.or.kr/ossw/license/license/list.do  

- 공개SW역량플라자 라이선스 설명 : http://www.oss.kr/45607

공개SW 라이선스 가이드 다운로드 http://www.oss.kr/?mid=oss_license&page=3&document_srl=70139 

오픈소스 라이선스 해설 http://www.oss.kr/oss_license/92922



그림출처 : http://terokarvinen.com/freehelia_licenses_and_the_definition_of_free_software.html




업무의 대부분이 이메일로 소통되고 있는데, 이슈를 따로 레드마인에 가서 등록하는 비효율적인 영역의 업무를 줄이기 위해서는 이메일을 통한 이슈등록이 필요합니다. 이번에는 레드마인의 이슈를 이메일로 등록하는 방법을 진행해볼까 합니다.


운영 환경

OS : CentOS 6.x

Version : Redmine 2.2.0


이 글은 레드마인이 설치된 상태에서 시작하기 때문에, 레드마인이 설치되지 않은 경우는 이전글을 참고해서 설치하시기 바랍니다. http://yes.imhappyo.com/403



레드마인 2.x 버전에서는 설정에 필요한 기본적인 내용이 모두 포함되어 있으므로 실제 우리가 설정해야 하는 것은 자동으로 pop3 또는 imap 이메일 서버에 접근해서 이슈를 가져오게 만드는 과정뿐입니다.


저는 redmine@abydos.co.kr 이라는 이메일 계정으로 보내는 내용을 자동으로 레드마인에 등록하는 시나리오를 구상하고 다음과 같이 설정했습니다.


1) 이메일로 받는 것이 가능하도록 레드마인 관리자로 로그인하여 설정을 변경.

관리-> 설정-> 수신메일-> 수신메일에 WS를 허용 하고 키생성을 눌러서 API키를 생성해 둡니다.





2) cron을 이용하여 주기적으로 이슈를 가져오도록 설정.

5분마다 레드마인이 redmine@abydos.co.kr 계정의 imap 서버를 접근하여 이슈를 가져오는 cron 설정은 다음과 같습니다. (pop3를 사용하신다면 아래의 예를 참고하세요)


Gmail imap 서비스 사용하는 경우 crontab -e

0,5,10,15,20,25,30,35,40,45,50,55 * * * * rake -f /opt/webRoot/redmine/Rakefile redmine:email:receive_imap RAILS_ENV="production" host=imap.gmail.com username=redmine@abydos.co.kr password=PASSWORD port=993 ssl=1 project=issue_repo tracker=Issue allow_override=project,tracker,priority


Gmail pop 서비스 사용하는 경우 crontab -e

0,5,10,15,20,25,30,35,40,45,50,55 * * * * rake -f /opt/webRoot/redmine/Rakefile redmine:email:receive_pop3 RAILS_ENV="production" host=pop.gmail.com username=redmine@abydos.co.kr password=PASSWORD port=465 ssl=1 project=issue_repo tracker=Issue allow_override=project,tracker,priority


설정이 끝났습니다. 이제 여러분이 redmine@abydos.co.kr 에게 쓰는 메일은 기본적으로 issue_repo 라는 프로젝트로 Issue 라는 tracker로 자동으로 등록됩니다. 너무 간단하죠 :-)

뒤의 옵션 중 allow_override 는 메일의 본문에서 적는 내용을 우선해서 등록하라는 의미입니다.


2) 이메일을 보내서 등록된 이슈 확인


지금부터 이메일 본문에 아래의 내용이 있으면 이슈가 등록됩니다.

Project: 프로젝트아이디
Tracker: Issue(결함, 새기능, 지원, Issue)
Priority: 보통(낮음, 보통, 높음, 긴급, 즉시)
Status: 신규(신규, 진행, 해결, 의견, 완료, 거절)
Category: 설정한 카테고리
Assigned To: 홍길동(또는 id)



문제가 생겨서 진행과정을 디버깅하는 경우에는 맨뒤에 --trace 를 붙여서 실행하시면 됩니다.



참고) 레드마인 공식사이트에서 제공하는 관련 링크
http://www.redmine.org/projects/redmine/wiki/RedmineReceivingEmails






최근 클라우드 분야에서 오픈소스SW의 활약이 대단하죠~

클라우드컴퓨팅지원센터, 공개SW클라우드협의회 등의 기관 및 단체들이 생겨나는 걸보면 

공개SW가 이제는 시장의 대세로 변하고 있는것은 느끼게 됩니다.


올해 개최된 OSCON 2012 발표 자료를 읽다보니 

오픈소스SW 클라우드 플랫폼 OpenStack, Eucalyptus, CloudStack, Ganeti 를 비교한 자료가 있어서 정리해 봅니다.



오픈스택 (www.openstack.org)

2010년 Rackspace 와 NASA 의 공동프로젝트로 시작해서 많은 기업들이 참여했습니다.

국내에도 최근에는 자주 세미나가 열려서 많은 분들이 관심을 가지고 있죠.

Nova, Swift, Glance, Keystone, Horizon 등의 컴포넌트로 구성되어 있습니다.



유칼립투스 (www.eucalyptus.com)

UC Santa Barbara 에서 연구프로젝트로 시작해서 2009년 상용으로 되었다가 

2012년 다시 오픈소스SW로 전환되었습니다.

Cloud Controlle, Walrus, Cluster Controller, Storage Controller, Node Controller 등으로 구성되어 있습니다.



클라우드스택(www.cloudstack.org)

Cloud.com 에 의해 개발되었고 2010년 5월에 오슨소스SW로 배포되었습니다.

Citrix 가 Cloud.com 을 인수하여 2012년 ASF(Apache Software Foundation)에 기증하여 현재 APLv2 입니다.

Management Server, Hypervisor Nodes, Storage Nodes, Layers(Zone, Pod, Cluster, Host, Primary Storage, Secondary Storage) 로 구성되어 있습니다.



가네티 (code.google.com/p/ganeti)

무중단 서버를 위하여 구글 내부에서 시작되어 내부 업무용 서버로 사용되다가 

2007년 8월 오픈소스SW로 공개되었습니다. 

Master daemon, Node daemon, Conf daemon, API daemon, Htools 로 구성되어 있습니다.



기업이 클라우드 플랫폼을 사용하기 위해서는 사용성, 서비스 가용성, 도입 및 관리 비용 절감, 성능, 이기종 호환성, 빠른 프로비저닝 등의 다양한 요소를 고려해야 하지만, 이런 의사결정을 바르게 할 수 있는 전문인력을 보유하고 있는 기업은 많지 않은것이 현실입니다. 향후, 공개SW기술이 클라우드 분야에서 확산되기 위해서는 우선 기업의 의사결정을 돕는 다양한 자료가 필요하겠습니다.


 



이미지 : http://www.oss.kr/oss_intro06

최근 오픈소스SW가 점점 다양한 분야에서 사용하게 되고 있는 추세이며, 따라서 오픈소스SW 라이선스에 대한 바른 정보와 함께 라이선스 준수에 대한 더 많은 생각이 필요합니다.  SW 라이선스 위반사례가 먼 나라의 이야기 같지만 얼마전 삼성전자, 휴맥스가 미국에서 GPL위반으로 제소당하고, MS도 GPL위반에 대한 제기를 받아서 소스코드를 공개하는 등 오픈소스SW 라이선스의 문제는 현실적으로 중요한 이슈입니다.

오늘은 오픈소스SW의 라이선스에 대한 기본 정보를 정리하고, 오픈소스SW 서버를 이용한 다양한 서비스(모바일, 클라우드 등)가 확산되는 최근에 주의깊게 생각해봐야할 AGPL에 대해서 이야기를 좀 해볼까 합니다.

1. 오픈소스SW 라이선스 기본정보 알기

오픈소스SW 라이선스는 전세계적으로 OSI에서 관리합니다.(영문)
http://www.opensource.org/licenses/alphabetical

오픈소스SW 라이선스에 대해서는 국문으로 한국저작권위원회와 공개SW역량플라자에서 좋은 정보를 제공하고 있으니
아래의 정보를 참고하시면 되겠네요.

(한국저작권위원회)

(공개SW역량플라자)
라이선스 비교 : http://www.oss.kr/oss_intro06 
라이선스 설명 : http://www.oss.kr/45607


2. AGPL?
 
최근의 동향에서 볼때 유의해서 지켜볼 라이선스는 서비스를 위해 소스를 수정한 경우에도 코드를 공개할 것을 요구하고 있는 Affero GPL(AGPL)이 아닐까 생각됩니다. AGPL은 기존의 SW개발의 범주를 초과하여 '서버 소프트웨어인 경우에도 반드시 소스 코드를 공개해야 한다'는 제약이 있으므로, 네트워크로 서비스를 하는 경우에도 적용되기 때문입니다.

예를들어, 클라우드서비스 사업자가 AGPL이 적용되는 오픈소스SW를 사용하는 경우 기존의 GPL처럼 생각하면 안됩니다. GPL의 경우 '사용자에게 소스 코드를 공개해야 하는' GPL 제약을 적용하면 서버의 사용자(자기)에게만 공개하면 되기때문에 소스코드공개를 피해갈 수 있으나, APGL은 이 경우에도 소스코드공개가 의무화 됩니다. 
 
즉, NHN, Google 같은 서비스 기업들도 AGPL의 영향을 받는다는 의미죠. 따라서 SaaS, Cloud Service 영역에서 오픈소스SW를 사용하는 경우에 AGPL은 반드시 확인해야 합니다.

AGPL 상세정보 : http://goo.gl/tUzaM

알쏭달쏭 오픈소스SW 라이선스에 대해서 의문사항이 있으시다면 아래의 정보를 이용하사기 바랍니다.


3. 오픈소스SW 라이선스 관련 문의처

오픈소스SW 라이선스에 대하여 궁금하시다면 아래의 링크를 이용하시면 됩니다.(좋은 정보가 있으시면 알려주세요)

1) 공개SW역량플라에서 제공하는 묻고답하기를 이용할 수 있습니다.

2) 아래의 한국저작권위원회를 통해서 상담을 받을 수도 있습니다.
한국저작권위원회 : http://www.olis.or.kr

3)  KOSS 법 센터
- 법무법인 에이팩스는 9월 1일 부설기관으로 `한국 오픈소스 SW(KOSS) 법센터`를 설립


4. 라이선스 검증서비스(무료)

자사의 SW에 대하여 오픈소스SW 라이선스 검증을 받고 싶은 경우는 아래의 서비스를 이용하실 수 있습니다.
공개SW역량플라자 : http://www.oss.kr/oss_news/7405
한국저작권위원회 : http://olis.or.kr/ossw/codeEye/introduction.do




들어가며

메일함에 공개SW사용기와 관련해서 한통의 메일이 왔습니다. 공모한 글이 적으니 많은 참여를 바란다는 메일인데, 내용을 살펴보니 이번에는 데스크탑에서 사용하는 공개SW의 사용기를 공모하네요. 아무래도 서버용 사용되는 공개SW는 많지만, 데스크탑에서 사용하는 공개SW은 사용자가 적기 때문에 참여자가 적은가 봅니다. 블로그 포스팅도 안한지 오래되고 해서 저도 사용기 하나를 작성하기로 했습니다.

그 덕분에 제 PC에서 사용하고 있는 공개SW를 한번 쭈욱 둘러보게 되었죠.
Cygwin, Vim, FileZilla, WinSCP, Cobian, 7zip, nmap, XAMPP, Eclipse, Aptana, Putty, Firefox, Chrome, tutories SVN, Spring STS ..
후아~ 꽤 많은 공개SW 사용하고 있네요.

많은 SW들이 PC를 재설치할 때마다 지워지고 삭제되고를 반복하는 가운데, 여전 저의 데스탑에서 오랫동안 살아남았으며, 지금도 즐겨 사용하고있는 공개SW는 WinSCP가 아닐까 합니다. 오늘은 WinSCP를 한번 살펴보겠습니다.

WinSCP 소개


요 즘은 대부분의 리눅스 서버에서 보안상 취약한 telnet,ftp를 사용하지 않고 ssh 서버를 운영합니다. ssh는 암호화된 패킷을 송수신하기 때문에 보안상 유리하고, scp 를 통한 파일전송도 가능하기 때문에 대부분의 리눅스 서버에 기본으로 사용하고 있습니다.

CLI 환경을 사랑하는 파워유저들에게는 껌정화면에 흰글씨가 아름다워 보이겠지만, 초급자에게는 ssh 접속과 파일관리가 만만한 일이 아닙니다. 내 컴퓨터의 파일하나를 원격지 리눅스서버에 전송하는것도 큰일이죠.
이런 경우에 바로 WinSCP를 사용할 수 있습니다.



WinSCP는 윈도우환경에서 GUI환경으로 FTP, SSH, SFTP 를 사용가능한 클라이언트 프로그램으로서 저의 데스크탑에서 가장 유용하게 사용하는 공개SW입니다. WinSCP를 이용해서 윈도우 탐색기처럼 원격지 서버와 파일을 쉽게 송수신 할 수 있고, 원격지의 파일을 손쉽게 편집도 가능합니다.



설치하기

1) 브라우저로 http://winscp.net/eng/download.php 에 접속합니다
2) 맨 위쪽에서 최신버전의 ‘Installation package’ 를 클릭하여 파일을 다운로드 합니다
3) 다운로드 받은 파일을 클릭하여 일반적인 윈도우 프로그램 설치과정과 동일하게 설치합니다.

한글지원여부)
최신버전의 파일을 다운로드 받으시면 WinSCP의 한글 버전을 사용할 수 있습니다.
프로그램 설치 시작 시 “한국어” 를 선택할 수 있으며, 프로그램의 한국어 버전이 설치됩니다.

만약 설치 프로그램에서 “한국어”를 선택할 수 없다면,
먼저 영문 설치 버전을 설치한 다음 아래의 translation page로 가서
“Korean” 언어팩을 다운로드 받아서 WinSCP가 실행되는 디렉터리에 ZIP 압축 파일을 풉니다.
translation page : http://winscp.net/eng/translations.php


특징


WinSCP는 영어뿐 아니라 한글을 포함한 다국어를 지원하는 GUI기반의 공개SW로서
많은 특징을 가지고 있습니다. 이미지와 함께 WinSCP의 많은 특징들을 한가지씩 이야기 해보겠습니다.

1) WinSCP를 이용해서 드래그 앤 드롭으로 원격 서버에 파일을 송수신 할 수 있습니다.



2) 바탕화면에 바로가기 아이콘을 생성해서 원클릭으로 서버접속이 가능합니다.



3) SSH-1과 SSH-2를 통한 SFTP 및 SCP 프로토콜 지원. 기존 FTP 프로토콜을 지원합니다



4) 배치파일을 통한 스크립트 실행과 CLI를 지원합니다.



5) 원격지 디렉토리와 PC의 디렉토리 간 동기화를 지원합니다.



6) 자주 쓰는 편집기를 등록해서 서버의 파일을 바로 수정할 수 있습니다.



7) 암호 입력 방식과 공개 키 인증방식을 지원합니다.

 


8) Windows 탐색기 및 Norton Commander 형태의 인터페이스 지원




고급활용


1. 에디트플러스와 WinSCP를 이용한 원격지 서버의 파일 직접수정

EditPlus는 프로그램 편집기로서 아주 강력하지만 ssh 기능이 없으므로 작업하는 도중
원격지의 서버에 파일관련 명령을 실행하기에는 불편합니다. 텍스트 편집기에게 이것저것 다 요구하는것은 너무 많은것을 바라는 것이겠죠?

이때 EditPlus를 WinSCP와 함께 사용하면 원격지의 서버를 윈도우의 탐색기처럼 브라우징 할 수 있고, 서버의 파일을 직접 열어서 항상 사용하는 편집기로 빠르게 편집할 수 있습니다.
물론 텍스트편집기의 원격서버 접속기능을 이용할 수 도 있지만, WinSCP와 함께 사용하면 좀 더 직관적인 인터페이스를 제공하므로 초보자도 리눅스 서버에 쉽게 접속해서 파일 수정이 가능합니다.




2. 디렉토리 동기화


이 기능은 서버의 소스코드를 자신의 PC에 특정폴더와 동기하도록 설정한 다음, PC에서 소스코드를 수정하면 자동으로 원격서버에 반영되는 기능입니다.
자신의 PC안에 있는 파일을 수정하면 원격지에 자동으로 반영되기 때문에 마치 서버의 소스코드를 수정하는 것과 같은 효과가 있습니다.



3. 공개키 인증방식 사용

Putty를 설치하면 인증키를 생성하는 PuTTYgen 프로그램을 사용할 수 있습니다.
1) 프로그램을 실행시키고 ‘Generate’ 버튼을 누른 후 ‘마우스’를 움직이면 키가 생성됩니다.
2) ‘Save private key’ 버튼을 눌러서 파일로 저장했다가 나중에 WinSCP에서 사용합니다.
3) 비밀문구 없이 저장할지를 물어보는데 그냥 저장하겠다고 '확인'버튼을 누릅니다.
4) 붉은 사각형 부분을 긁어서 클립보드에 복사했다가, 원격서버의 /사용자홈/.ssh/authorized_keys 파일에 한 줄로 복사해넣습니다.
5) 아래 화면과 같이 저장한 개인키를 WinSCP 접속정보에 입력해 줍니다
6) 접속을 시도하면 공개키 기반의 인증을 사용하여 접속됩니다.


트러블슈팅


- UTF-8환경에서 한글이 깨어지는 경우에는, 로그인화면 > 환경 > 파일이름을 UTF-8 인코딩
이라고 표시된 부분을 '자동'에서 '사용'으로 변경하신 후 접속하시면 UTF-8 형식을 사용합니다.






참고자료 및 링크


WinSCP Manual - http://winscp.net/eng/docs/start
WinSCP 스크립트 명령실행 활용 - http://calmmass.tistory.com/49
WinSCP 디렉토리 동기화 - http://goo.gl/jZeFv
WinSCP User Manual - http://infotech.adelphi.edu/pdfs/WinSCP_usermanual.pdf


마치며

WinSCP 의 기능을 정리하면서 생각해보니, 진짜 필수적인 기능들을 많이 제공하는것을 새삼 알게되었습니다. 특히 디렉토리 동기화같은 기능은 상용 프로그램에서도 흔히 볼 수 없는 좋은 기능이고, 이런 좋은 SW를 공개한 개발자들에게 고마운 마음이 듭니다. 저도 공개SW를 사용하는 사용자의 입장에서가 아니라 실력을 좀 키워서 좋은 공개W를 만들어서 다같이 사용할 수 있었으면 좋겠네요.

Source : MySQL-Replication-Tutorial, MySQL Conference and Expo

Replication?

MySQL Cluster가 동기화 (synchronous) 리플리케이션과을 수행하는것과는 다르게, MySQL은 단 방향, 즉 비동기 리플리케이션 (asynchronous replication)을 지원합니다. MySQL Replication은 하나의 서버가 마스터로 동작하고, 나머지 한 개 이상의 다른 서버들이 슬레이브로 동작하여 마스터의 Binlog를 이용하여 슬레이브가 복제를 수행하고, Relay Binlog에 기록하는 기술을 의미합니다. 즉, 마스터의 MySQL을 슬레이브가 똑같이 복사해서 가지고 있는것이죠.

MySQL Replication은 데이터 백업의 용도뿐만 아니라, 데이터베이스에 대한 입출력을 각서버에 나누에 수행시켜 부하를 분산시키거나, 여러개의 마스터를 이용한 고가용성의 확보등에 사용됩니다.


준비사항

마스터, 슬레이브에서 사용하는 MySQL의 버전을 확인하여 가능한 동일한 버전으로 일치시키는 것이 좋으며, 마스터보다는 슬레이브의 버전이 높아야 안정적인 작동을 보장합니다.
MySQL 이중화 상태에서 Replication Fail Bug 에 대한 최근의 자료(http://goo.gl/fSlxb)를 보면 PK가 없는 테이블의 Null값을 업데이트 하는 경우 Replication이 실패하는 경우가 있다고 하니, 버그가 해결된 최신버전을  업데이트한 후 사용하시기를 권고합니다.

CentOS 5.5 에서 MySQL 5.5.15 설치방법
1) Install Remi repository
rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-5.rpm

2) Check Available MySQL versions
yum --enablerepo=remi,remi-test list mysql mysql-server

3) Install MySQL
yum --enablerepo=remi,remi-test install mysql mysql-server


Master 에서 준비할 일

1) my.cnf 파일에 마스터의 설정 추가
server-id = 고유한상수값
binlog-do-db = 복제할 원본 DB명 A
binlog-do-db = 복제할 원본 DB명 B
binlog-ignore-db = 복제하지않을 원본 DB명 A
binlog-ignore-db = 복제하지않을 원본 DB명 B
log-bin = Binlog 파일명

예)
server-id = 1
binlog-do-db = testdb
log-bin=mysql-master-bin

2) 슬레이브에서 Replication을 위해 접속할 유저를 생성하고 권한부여
CREATE USER '사용자아이디'@'접속을 허용할 호스트주소' IDENTIFIED BY '사용자비밀번호';
GRANT REPLICATION SLAVE ON *.* TO '사용자아이디'@'접속을 허용할 호스트주소';

예)
mysql> CREATE USER 'repl_user'@'%' IDENTIFIED BY 'abc1234';
mysql> grant replication slave on *.* to 'repl_user'@'%' identified by 'abc1234';


3) 슬레이브에 적용할 데이터베이스의 스냅샵 덤프파일 준비
mysqldump -u root -p db명 > 파일명.sql

예)
mysqldump -u root -p testdb > testdb.sql


Slave 에서 준비할 일

1) my.cnf 파일에 슬레이브의 설정 추가
server-id = 고유한상수값
relay-log = Relay Binlog 파일명

예)
server-id = 2
relay-log = slave-relay-bin

2) master에서 덤프한 파일을 임포트
마스터에서 미리 덤프한 파일을 슬레이브로 복사하고, 그 파일을 이용하여 슬레이브의 MySQL DB에 임포트합니다.
mysql -u root -p db명 < 파일명.sql

예)
mysql -u root -p testdb < testdb.sql

3) 마스터에 대한 설정
MySQL 콘솔창에서 마스터의 호스트주소, 사용자명, 비밀번호, Binlog 파일명, Position 등을 아래와 같이 설정합니다.
(이때 사용하는 Binlog 파일명과 log position의 값은 마스터의 MySQL을 재시작하고, show master status 명령으로 확인합니다.)


mysql> CHANGE MASTER TO
    ->     MASTER_HOST='master_host_name',
    ->     MASTER_USER='replication_user_name',
    ->     MASTER_PASSWORD='replication_password',
    ->     MASTER_LOG_FILE='recorded_log_file_name',
    ->     MASTER_LOG_POS=recorded_log_position;

예)
mysql> change master to
    ->     master_host='192.168.10.10',
    ->     master_user='repl_user',
    ->     master_password='abc1234',
    ->     master_log_file='mysql-master-bin.000004',
    ->     master_log_pos=640;


결과 확인

이제 모든 설정을 마쳤으니, 마스터와 슬레이브의 MySQL 서버를 재구동 해주시고. 정상적으로 작동하는지 확인을 위하여 아래의 방법을 사용합니다.

1) 마스터의 상태확인을 위해서 아래의 명령을 이용합니다.
show master status;


2) 슬레이브의 상태확인을 위해서 아래의 명령을 이용합니다.
show slave status\G


모니터링

MySQL Replication을 구성하고 난 후, 정상작동여부를 모니터링하여 마스터와 슬레이브의 내용이 다른 경우 메일로 통보받는 것이 가능합니다. 아래 링크의 SW는 마스터의 Binlog와 Position을 가져와서 슬레이브의 상태와 비교하고 같지않은 경우에 메일로 통보하는 로직으로 구현된 SW입니다.

http://forge.mysql.com/tools/tool.php?id=6
http://datacharmer.blogspot.com/2011/04/refactored-again-poor-mans-mysql.html



고급활용

MySQL의 5.x대에 들어오면서 Replication은 row-based, semi-synch, delayed, Circular,  Master-Master Replication, SSL Turnnel, Proxy 등의 다양한 고급활용이 가능합니다. 고급활용에 대한 상세한 내용은 이번 글에서 다루지 않으니, 아래에 제시한 참고자료의 링크를 이용하시기 바랍니다.


참고자료





녹색성장이 국가에서 추진하는 정책이다 보니, 최근 탄소배출량을 줄이기 위한 에너지 절감에 대한 이야기가 자주 거론 됩니다. 많은 기업들이 에너지 절약에 주목하고 있는 것이 대세이고, 그 일환으로 마이크로소프트에서는 Windows 7 의 전원관리 기술에 대한 보도자료(http://www.microsoft.com/korea/events/2011/powersave/)를 통해 낮은 전력소비량을 이야기 하고 있습니다. 요약하면 Windows XP 보다는 Windows 7 을 사용하는 것이 에너지 절감에 유리하다는 내용이죠.

Source : http://www.microsoft.com/korea/events/2011/powersave/


저도 최근 업무상 미팅중에  오픈소스SW의 탄소배출량 절감효과 연구에 대한 의견을 나눈적이 있었습니다. 내친김에 자료를 좀 찾아보았는데, Ubuntu 와 Windows 7 을 비교한 자료(2011년6월29일 발표)가 있어서 공유합니다.

Surprising Power Consumption Of Ubuntu 11.04 vs. Windows 7
- Source : http://www.phoronix.com/scan.php?page=article&item=windows_ubuntu_pow&num=9

- 게임을 하는 동안은 우분투가 약간 높은 전력소모


- 부팅하는 동안은 윈도우7 이 약간 높은 전력소모


- HD 비디오를 재생하는 순간에는 우분투가 더 높은 전력소모

- 가벼운 데스크탑의 사용에서는 두 운영체제가 비슷비슷


내용을 요약하면, 마이크로소프트에서 이야기하는 자료를 근거로 보면 이전의 윈도우보다 Windows 7 이 에너지 절감에 도움이 되고, Ubuntu 11.04 vs. Windows 7 은 일장 일단이 있는 비슷비슷한 상태라는 이야기네요.

향후 오픈소스SW의 탄소배출량 절감에 대한 좀 더 심도있는 연구를 수행해서 현재의 운영체제 단위의 비교가 아니라 업무 도메인별로 오픈소스SW 스택 단위를 비교한다면 오픈소스SW에 대한 신뢰성을 제고할 수 있는 자료로 쓰일수 있겠습니다.



참고자료
- Ubuntu 9.04 vs Windows 7 Energy consumption test
http://blog.o-lab.se/2009/09/ubuntu-9-04-vs-windows-7-energy-consumption-test/

- Linux vs. Windows Power Usage
http://www.phoronix.com/scan.php?page=article&item=880&num=1

- Surprising Power Consumption Of Ubuntu 11.04 vs. Windows 7
http://www.phoronix.com/scan.php?page=article&item=windows_ubuntu_pow&num=9


어제 지인과 식사도중 개발자의 실력에 대한 안철수씨의 강연내용 이야기가 나왔습니다. (이런 주제를 이야기 할 수 있는 지인이 있다는건 참 행복한 일이죠)

“현대는 한 사람의 천재가 모든 것을 할수 있는게 아니라 한 사람이 못할 일을 여러 전문가가 함께 모여 만들어가는 시대다”며 “전문가의 실력은 전문 지식 곱하기 커뮤니케이션 능력이다”

Source : “고단한 SW개발자 생태계, 그래도 희망은 있다” - http://goo.gl/i12Z7

전문지식 곱하기 커뮤니케이션 능력이 실력이라니~
개발자는 제대로된 기능을 만들기도 벅찬데, 커뮤니케이션 능력도 배양해야 한다니 쉬운일이 아닙니다.
게다가 현업에서 보면 A개발자와 B영업간에 "뭔 말이 통해야 말을하지~" 하는 푸념을 종종 듣습니다.
하지만, 대부분의 개발자는 자신이 커뮤니케이션 능력이 부족하다고 생각하지 않습니다. 상대방이 논리가 빈약하고 실체가 없는 모호한 대화방식이 아니라, 좀 다른 대화방식으로 이야기하기를 바라는것 뿐이죠 :-)

그럼 개발자와 대화를 이끌어내기 위해서는 어떻게 해야할까요?

얼마전 트위터에서 웃음을 자아냈던 공대생 남친 관리법(http://goo.gl/qvBUC)에서도 보이듯이, 개발자는 개발자스러운 대화방식으로 접근해야 커뮤니케이션이 가능합니다. 개발자는 자신이 이해가능한 합리적인 결과물에 대해서는 큰 이견을 제시하지 않는다는 특성을 가지고 있죠. 꼭 개발자가 아니라도 합리적 내용물을 기반으로 이야기하면 쉬운 대화가 가능합니다.

제 생각에 개발자와 대화하기 가장 좋은 방법은 애자일 실천법 중 하나인 CTIP(Continuous Test & Intergration Platform) 라고 생각됩니다. 지난 몇년간 Agile 기법에 대한 학습과 현업에서 적용결과, 저는 애자일의 핵심이 사람과의 소통인것을 얼마전에야 깨닫게 되었습니다.

혼자 개발하는 문화에 익숙한 개발자는 무엇인가 함께 만들어야만 하는 상황을 만나면, 구성원간 커뮤니케이션에 어려움을 겪습니다. 이때 CTIP를 통한 정적분석도구를 활용한 결과물과 코드커버리지, 그리고 이슈관리도구를 통하여 문제점을 가시화하고 합리적 결과에 기반한 개발자와의 대화를 시도하면 SW개발자와의 쉬운 대화가 가능합니다.

저는 SW개발의 생산성을 향상시키기 위한 최선의 방법은, 좋은 개발문화를 형성하여 개발자간 커뮤니케이션능력을 배양하고, 협업을 통한 시너지가 창출될 수 있도록 유도해주는 것이라고 생각합니다.


Source : 2011 한국소프트웨어 아키텍트 대회
<지속적 테스트와 통합을 위한 SW개발 아키텍처>


<이슈관리시스템을 통한 문제제기>


<위키를 이용한 문서협업>




<SW개발을 위한 공개SW 기반의 지속적 테스트와 통합 아키텍처>


그리고, Agile 2011 Conference가 8월6일 열린다고 합니다. http://pragmaticstory.com/1776 에 트랙에 대한 설명을 해주셨네요. 언젠가는  가 볼 기회가 있겠죠?  :-)

+ Recent posts