오픈비 : 삽질은없다

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

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

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

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

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

오픈소스 커뮤니티 현황 

오픈소스 커뮤니티[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

서비스를 운영하다보면 서버에서 이메일을 발송할 일이 있을때 여러가지 이유로(보안상 계정 관리, 발송한 메일을 확인 등) 지메일 계정으로 쓰고 싶은 경우가 종종 있습니다. 지메일은 메일사본을 보관해주고 웹인터페이스를 제공하기 때문에 저는 중요한 고객서비스를 제공할때 자주 사용하고 있습니다. 

이번에 신규서버에 설정할 일이 생겨서 설정 과정을 공유합니다.

이번에 제가 테스트한 환경은 Linux Mint 18.3 입니다. 

하모니카 커뮤니티 에디션, Linux Mint 18.3, Ubuntu 16.04 등은 모두 동일한 방법을 사용해서 적용하시면 됩니다.

패키지 설치

필요한 모든 패키지 설치는 다음과 같이 실행합니다.

sudo apt-get install postfix mailutils libsasl2-2 ca-certificates libsasl2-modules

처음 설치하시는 경우 postfix 설정 도우미가 어떤 용도로 사용할지 물어보게 됩니다. 이때 Internet Site 를 선택하세요.

postfix 환경설정

postfix 설정파일 편집

sudo vi /etc/postfix/main.cf 명령으로 설정파일을 편집합니다. 

항상 편집을 시도하기 전에 원본을 복사해서 보관해두는 것을 잊지마세요.

파일의 내용은 아래내용을 그대로 사용합니다.

# gmail smtp setting

relayhost = [smtp.gmail.com]:587

smtp_sasl_auth_enable = yes

smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

smtp_sasl_security_options = noanonymous

smtp_tls_CAfile = /etc/postfix/cacert.pem

smtp_use_tls = yes

CAfile 생성

postfix 서비스 재시작

테스트

만일 mailutils 가 설치되지 않은 경우에는 이 명령어가 동작하지 않습니다. 설치가 되지 않은 경우에는 다음과 같이 설치해줍니다.

sudo apt install mailutils

메일발송을 다음과 같이 테스트 해 봅니다. 붉은색 부분을 자신이 확인할 수 있는 이메일계정으로 변경해주세요.

echo "postfix로 발송한 메일입니다" | mail -s "Postfix 메일 테스트" 수신이메일주소

디버깅

문제가 발생하여 로그를 확인하고 싶은 경우는 

tail -f 10  /var/log/mail.log 명령어로 postfix의 작업과정 확인합니다.

지메일 환경설정

2단계 보안인증

게정 로그인 정보가 정상임에도 불구하고 다음과 같은 오류가 로그파일에 남는 경우에는 지메일에서 추가적인 환경설정이 필요합니다.

postfix/smtp[21326]: CF7CE24225C: SASL authentication failed; server smtp.gmail.com[108.177.125.109] said: 535-5.7.8 Username and Password not accepted. Learn more at?535 5.7.8  https://support.google.com/mail/?p=BadCredentials k24sm23509527pfj.32 - gsmtp

이 이유는 지메일의 보안설정때문에 발생합니다.

먼저 아래 링크에서 2단계 인증을 사용하도록 변경합니다. 이때 보안코드를 받을 수 있는 휴대폰이 있어야 합니다.

https://myaccount.google.com/u/2/security

앱 비밀번호 생성

인증을 마쳤으면 다음과 같이 앱 비밀번호를 생성해줍니다. 새로운 앱을 원하는 이름으로 만들고 이때 발급되는 비밀번호를 복사해둡니다.

다음과 같이 이전에 설정한 파일의 비밀번호 대신 복사한 비밀번호를를 사용하도록 변경합니다.

sudo vi /etc/postfix/sasl_passwd 

테스트 및 확인

다음과 같이 테스트 해봅니다.

echo "postfix로 발송한 메일입니다" | mail -s "Postfix 메일 테스트" 수신이메일주소

오랜만에 포스팅입니다.

얼마전 소프트웨어 기업을 대상으로 강의요청이 있어서 교육을 진행했습니다. 5시간 정도 교육을 마치고 교육 수강하신 분들을 대상으로 회고를 해보니 의미있었던 내용이었다는 이야기를 듣고 한번 정리해야 겠다는 마음이 들었습니다.

오늘 주제는 Waterfall, Agile, Scrum, Kanban 이라는 용어에 대해서 알아보고, 어떤 경우에 어떤 방법을 사용하는 것이 좋은지 이야기 하려고 합니다. 상세한 내용은 별도로 공유하는 자료를 참고하시기 바랍니다.

저는 소프트웨어 개발방법론 맹신자는 아니지만 개발방법론의 효용가치에 대해 인정하는 편입니다. 중요한 것은 방법론이 아니라 적절한 방법론을 적절한 곳에 사용하지 않는 사람이 문제 아닐까요. 

학교에서 배우는 소프트웨어 공학에 요즘 스크럼, 칸반이 들어있는지 모르겠지만 최근의 소프트웨어 개발방법론은 애자일 방식을 채택하는 경우가 많습니다. 

주변에서 요즘은 애자일 개발방법론을 사용하고 있다는 회사들을 종종 접하게 됩니다. 아래의 애자일 개발방식을 사용하고 있다는 사람들에게 물어본 조사결과를 보면 58%는 Scrum을 사용하고 10%는 Scrum과 XP의 하이브리드 형태를 사용하고 있습니다. 그리고 8%는 multiple methodologies를 사용하고 있죠. 7%는 Scrumban 5%는 Kanban을 사용하고 있습니다.

이 이야기는 애자일 개발방식을 사용하는 사람들이 저마다의 환경에서 적합한 방법을 채택하고 있다는 의미입니다. 하지만 아직 국내에서는 실제 현업에서 다양한 적용사례를 만나기 어려운 현실입니다. 현업에서 이야기를 하다보면 애자일과 스크럼을 동일시 하는 경우도 자주 보게 되는데 스크럼은 애자일의 서브셋 입니다.

애자일이란?

소프트웨어 개발의 기초 원칙과 정신을 선언한 철학입니다. 소프트웨어를 개발하는 더 나은 방법들에 대한 이야기를 담은 문서가 2001년 Agile Alliance 라는 그룹에서 만들어지는데 12가지의 원칙을 담고 있습니다.

애자일 철학을 반영하는 개발방법론들

Scrum?

Scrum은 Agile을 구현하는 가장 보편적 인 방법 중 하나입니다. 스크럼은 변하지 않는 일련의 역할, 책임 및 회의를 따르는 반복적인 소프트웨어 모델입니다. 

Kanban?

일본에서 '시각적 기호'또는 '카드'를 의미하는 Kanban은 Agile을 구현하는 시각적 프레임 워크입니다. 현재 시스템에 대한 작고 지속적인 변경을 촉진합니다. 그 원칙은 다음과 같습니다 : 워크 플로우를 시각화하고, 진행중인 작업을 제한하고, 플로우를 관리 및 강화하고, 정책을 명시적으로 만들고 지속적으로 향상시킵니다. 

XP(Extreme Programming)?

익스트림 프로그래밍 (Extreme Programming)은 진화하는 고객 요구 사항에 대한 품질과 응답성을 개선하기 위한 소프트웨어 개발 유형입니다. XP의 원칙은 피드백을 포함하고, 단순성을 가정하고, 변화를 수용합니다.

기타 Feature-driven development (FDD), Adaptive system development (ASD), Dynamic Systems Development Method (DSDM), Crystal Clear 등의 방법론도 애자일 개발 방법으로 사용됩니다.

그럼 모든 소프트웨어 프로젝트에 지금까지 우리가 잘 알고 있는 Waterfall을 버리고 애자일 철학을 반영한 방법론을 사용하는 것이 필요할까요? 언제 이런 애자일 개발 방법을 선택하면 좋을까요?

Waterfall 이 필요한 경우

- 범위의 변경은 기대하지 않고 고정된 가격 계약으로 작업하고 있는 경우 

- 프로젝트는 매우 간단하거나 여러 번 해본 적이 있는 경우

- 요구 사항은 잘 알려져 있고 고정되어 있을 때

- 고객이 원하는 것을 정확하게 미리 알고 있는 경우

- 질서 정연하고 예측 가능한 프로젝트로 작업하고 있는 경우

- 프로젝트 요구사항이 바뀌고 진화하는 경우

- 지속적인 피드백이 필요한 경우

- 프로젝트 팀이 자율성을 원하는 경우

- 정기적으로 소프트웨어를 제공해야 하는 경우

- 언제든지 배포 할 수 있는 것을 원하는 경우

- 팀이 변화를 선호할 때

- 팀의 배포 흐름을 개선하고 싶을 때

- 이해하기 쉬운 시스템을 찾고 있을 때

No silver bullet.

모든 프로젝트를 해결할 수 있는 유일한 소프트웨어 개발방법론은 없습니다. Waterfall, Scrum, Kanban, XP 등 다양한 소프트웨어 개발방법을 알고 우리팀에 좋은 방법을 찾아보고 서로 피드백하며 실행해가는 과정을 통해 조금씩 나아지는 것이 좋은 소프트웨어를 만들기 위해 필요한 것이며 저는 이것을 애자일이라고 부릅니다.

20180318_언제 애자일을 써야 좋을까.pdf

최근 국가연구개발사업이 오픈R&D 형식으로 전환되는 움직임이 많아지면서 기존의 연구개발방식을 수행하던 사람들이 여러가지 질문을 하는데 그 중 자주 묻는 질문이 "오픈R&D를 하면 특허는 어떻게 하나요"라는 질문이다.

이 질문에 대한 결론부터 말하자면 "오픈소스로 배포하는 기술이라도 특허는 등록할 수 있다"이다.

이에 관련하여 공개SW역량프라자에서 얼마전 배포한 오픈소스 라이선스 해설서를 보면 다음과 같이 설명하고 있다.

우선 오픈소스 소프트웨어 진영에서는 모든 프로그램을 자유롭게 사용할 수 있도록 한다는 철학이기 때문에 특허를 반기지 않는다. 많은 오픈소스 커뮤니티는 소프트웨어의 일부 아이디어를 해당 특허로 등록한 후 특허 소송에 관여 시켜 소프트웨어 사용을 막아 수익을 올리려 하거나, 오픈소스 소프트웨어 개발을 법적으로 금하게 하는 특허, 오픈소스 개발자의 오픈소스 원칙을 약화 시키는 특허 등록에 대해서 걱정한다.

그러나 소프트웨어 특허에 대항하려는 오픈소스 소프트웨어 커뮤니티의 시도와 관계없이 소프트웨어 특허법은 존재하는 것이 현실이며 법을 준수하려면 특허 제약사항을 알고 대응해야 한다. 오픈소스 라이선스들은 이 필요성을 인식하고 존중하는 입장이며 오픈소스 라이선스들의 전문에는 특허조항이 권한부여 또는 권한취소에 대하여 여러 문장으로 표현되어 있다.

• 권한부여 라이선스(granting license)의 문맥에는 소프트웨어 일부분에 기여하고 배포하는 행위는 기여자, 배포자의 모든 특허가 전체 소프트웨어(다소 깊게 내포된 라이브러리를 포함) 사용에 필요한 “주어진 자유”라는 상황을 불명확하게 유발한다는 점을 고려해야 한다는 내용이 있다. 따라서 특허 포트폴리오의 핵심 특허 일부가 특허조항에 의해 피해를 받는지, 그리고 이에 따라 해당 오픈소스 소프트웨어 일부를 사용 또는 배포하지 말아야 하는지를 점검하고 싶다면 삽입된 라이브러리 역시 반드시 점검해야 한다.

• 권한부여 라이선스의 문맥에는 특허조항에 근거하여 ‘배포된 소프트웨어를 사용 가능하게 하기 위한 사용을 허용한다.’는 취지로 특허 사용만 허가되는지를 고려해야 한다. 특허조항은 일반적으로 특허를 양도하지 않는다. 이 때문에 오픈소스 소프트웨어에 의해 (고의적이지 않은) 특허 양도의 위협이 크지 않을 때(특허의 사용이 단지 소프트웨어의 결합에서만 부여되는 경우)도 있다. 특허 사용은 소프트웨어와 결합될 때만 권한이 주어진다. 한편 오픈소스 소프트웨어가 대규모의 프로세스에 내포 여부에 상관없이 오픈소스 소프트웨어를 사용하기 위해서는 특허 사용이 필요하기 때문에, 특허 사용 권한을 얻지 못하고는 오픈소스 소프트웨어를 사용하지 못할 수 있다. 반면 오픈소스 라이선스에 근거하여 허가된 오픈소스 소프트웨어가 없이 오픈소스 라이선스의 특허조항에 의해 양도된 특허를 사용할 수는 없다. 그 이유는 특허조항만이 오픈소스 소프트웨어 사용가능 여부를 나타내기 때문이다.

• 권한취소 라이선스에 의한 취소 형태는 어떤 경우에는 소프트웨어 사용 취소를, 또 어떤 경우에는 특허 사용 취소를 나타내는 것인지를 언급해야 한다. 그러나 자비로운 오픈소스 소프트웨어 사용자의 실용적 관점에서 볼 때 두 번째 경우의 특허 취소는 암묵적으로 소프트웨어 사용 권한을 해지한다고 판단할 수 있다. 특허 사용이 소프트웨어의 일부분을 법적으로 사용하기 위해 필요하다면 역시 특허 사용 권한을 갖지 않고 소프트웨어 사용이 허용될 수는 없다(그리고 특허 사용이 소프트웨어를 사용하는데 필요하지 않다면 이 특허는 특허조항이 적용되지 않는다). 따라서 이 유형의 특허조항은 소프트웨어 사용/배포 또는 수정하는 권한을 해지하는 것으로 보인다. 이런 이유로, 기업 또는 조직뿐만 아니라 단일 사용자들은 오픈소스 소프트웨어를 확실히 법률을 준수하면서 사용하고자 한다면 그런 특허조항을 중시해야 한다.

• 따라서 오픈소스 기여자와 배포자는 오픈소스 라이선스를 허가하는 것이 법적으로 소프트웨어를 사용하는데 필요한 모든 권한을 명시하지 않으면서도 저절로 허가하고 있는지, 권한취소 라이선스의 경우, 특허조항에 금지로 이해될 수 있는 부정적 조건이 있는지 고려해야 한다.