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

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


이번에 제가 테스트한 환경은 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


계정정보 파일 생성

sudo vi /etc/postfix/sasl_passwd 명령으로 계정정보 파일을 생성하고 아래의 붉은색부분을 자신의 지메일 계정 정보로 적습니다.

[smtp.gmail.com]:587    USERNAME@gmail.com:PASSWORD

postfix 에서 사용할 수 있는 db파일로 변환

다음의 명령으로 계정정보 파일을 루트만 접근하도록 변경하고 postfix에서 사용하는 파일형태로 변환해 줍니다.

sudo chmod 400 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd

CAfile 생성

환경설정에서 정의해준 CA파일을 다음과 같이 생성해 줍니다.

cat /etc/ssl/certs/thawte_Premium_Server_CA.pem | sudo tee -a /etc/postfix/cacert.pem


postfix 서비스 재시작


sudo /etc/init.d/postfix reload


테스트

만일 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 


[smtp.gmail.com]:587    USERNAME@gmail.com:발급받은앱비밀번호

저장해주고 다시 변경된 내용을 postfix에서 사용하는 파일형태로 변환해 줍니다. 저장이 안되는경우는 파일의 쓰기 권한 때문입니다. vi 에서는 저장할때 :wq! 하시면 강제 저장이 됩니다.

sudo postmap /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 이 필요한 경우

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

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

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

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

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


Scrume 이 필요한 경우

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

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

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

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


Kanban 이 필요한 경우

- 반복을 요구하지 않는 프로젝트

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

- 팀이 변화를 선호할 때

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

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


No silver bullet.

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


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


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

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

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


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

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

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

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

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

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



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

개방형 데스크톱 OS 동향  (0) 2019.04.05
오픈소스 커뮤니티 구축  (0) 2018.05.12
공개SW R&D 추진전략  (0) 2017.03.22
해외 기업들의 오픈소스 활용 비즈니스 전략  (0) 2016.10.27
오픈소스 거버넌스  (0) 2016.09.29

4차산업혁명이라는 단어가 정치, 마케팅, 기술 등 분야를 가리지 않고 확산되면서 국가 전체의 화두가 되어있습니다. 그러다보니 여러부처의 지원사업들이 4차산업혁명을 동반하고 쏟아지고 있죠.


4차산업혁명에서 활용가눙한 공개SW 기술이 다양하게 존재하는 덕분에, 여러 지원사업에서 공개SW라는 단어를 종종 만나게 되고, 요몇일동안은 공개SW R&D 추진전략에 대한 의견을 전달하게 되었습니다. 


다들 연구개발 지원사업을 오랫동안 해 온 전문가들 이지만, 공개SW R&D의 유형은 일반적인 연구개발의 유형과는 다른 특징을 가지게 되고 준비해야하는 내용도 다를 수 밖에 없습니다. 이번에 의견을 전달하면서 달라진 연구개발의 요구사항에도 불구하고 사업계획을 준비할 수 있는 기초 정보가 부족해서 많은 분들이 어려움을 겪는 것을 알게 되었고 그 과정에서 자료를 좀 정리해야할 필요성을 느끼게 되어서 새 글을 작성합니다.



https://www.slideshare.net/AhmadRb/iem2014-foss


일단 정부의 지원사업에서 공개SW R&D를 한다는 취지를 생각해보면, 1) 사업을 수행하는 동안 기존의 인하우스 개발방식이 아닌 참여와 공유를 통한 공개SW 개발방식을 경험하면서 공개SW 기술의 역량이 축적되고 2) 열심히 노력한 사업의 결과물을 공개SW로 누구나 사용할 수 있게 배포함으로서 산업 활성화에 기여하는 것을 기대하는 것이라 생각합니다.


먼저 지원사업을 발주하는 입장에서는 사업의 선정지표에 공개SW R&D에 대한 준비가 가능한 평가항목을 좀 더 구체화해야 할 것 같습니다. 단순히 '공개SW R&D에 대한 추진방안' 정도로 표현하면 공개SW R&D 사업의 경험이 없이 사업을 준비하는 입장에서는 의도를 파악하기가 어렵습니다. 따라서 어떤 지원자가 참여하면 좋을지 생각하고 있는 의도를 표현할 수 있도록 보다 구체적인 서술을 포함하는 것이 좋겠습니다. (공개SW에 대한 이해, 공개SW R&D 환경, 결과물의 공개SW 라이선스와 배포 방안, 공개SW R&D 관련 경험 등)


뿐만 아니라, 사업의 결과 평가 시점에서도 공개SW로 배포될 결과물에 대하여 평가할 항목을 선정하여 공개SW로 배포되는 사업결과물의 활용을 극대화 하려는 노력이 필요해 보입니다. 공개SW는 특성상 공개SW 커뮤니티를 통하여 배포되고 성장하기 때문에 다운로드수, 홈페이지 방문자수 같은 수치가 아닌 여러가지 공개SW 고유의 지표들을 이용할 수 있고, 공개SW 자체에 대한 성숙도 평가를 하고자 하는 시도 역시 Qualipso OMM, OpenBRR, QSOS, 공개SW 성숙도 및 적용성 평가지침 등이 존재합니다. 따라서 사업의 평가 시점에도 이를 반영하기 위한 노력이 필요하다고 생각됩니다.


또한 사업을 지원하는 입장에서는 어떠한 공개SW R&D 방식을 사용할지, 개발환경은 어떻게 준비할지, 개발과정에서 외부의 참여를 받아들일 준비는 어떠한지, 커뮤니티화 운영을 할때 필요한 거버넌스는 준비되어 있는지, 배포할 결과물에 대한 라이선스 관리전략은 무엇인지 등의 고민을 사전에 해보고, 특허나 기술이전으로 실적을 이야기하던 방식에서 벗어나 공개SW의 특성을 반영한 활용방안과 비즈니스 가능성을 고민하여 제시하는 노력이 필요합니다.


공개SW산업에서 일을 하는 입장에서 보면, 기존의 정부지원사업에서 혁신을 가져온 공개SW R&D 방식 시행되는 것을 대단하게 생각하고 있습니다. 여러가지 부정적인 결과들을 예상할 수 도 있지만, 그 또한 변화의 긍정적인 신호라고 생각합니다. 어찌되었던 이런 좋은 의도의 지원사업을 통해 많은 사람들이 쉽게 기술에 접근해서 아이디어를 구현해보기 좋은 세상이 되었으면 좋겠네요.

티스토리에 정착하여 글을 쓰기 시작한지 10년째 되었네요.

계속해서 매월 한 개 이상의 글을 적어왔는데, 최근 몇 년 동안은 포스팅을 거의 못했습니다.

시간이 지나고 업무경험이 쌓일수록 생각은 많은데 글을 쓰는 건 더 조심스러워 지네요.


오늘은 4차산업혁명에 대한 이해와 오픈소스는 어떤 역할을 하는지 생각해 보겠습니다.


마이클 포터 교수는 IT가 3번에 걸쳐 큰 변혁의 물결을 가져오고 있다고 이야기 합니다.

- 제 1 물결은 1960년대부터 70년대까지 주문처리나 경비지급, CAD, 생산관리 등 가치사슬의 개별활동을 자동화하면서 기존 수작업에 비해 비즈니스 생산성이 크게 향상.

- 제 2 물결은 1980년대 상용 인터넷이 탄생하고 90년대등러 고속 대용량화와 저가화가 진행되면서 인터넷을 통해 컴퓨터간 쉬운 연결이 가능.

- 제 3 물결은 최근에 나타나는 현상으로 제품에 센서와 프로세서, 소프트웨어, 연결 기능등이 내장되어 제품이 만들어 내는 데이터가 클라우드에서 수집, 분석되어 제품의 기능과 성능을 크게 향상.


이러한 제 3의 물결의 제품을 포터는 스마트 커넥티드 제품이라고 부르며 모니터링, 제어, 최적화, 자율성의 4단계로 구분되는 역량모델을 이야기합니다.



마이클 포터의 이러한 전망에 대해 PTC의 헤플만은 스마트 커넥티드 제품을 실현하기 위해서는 제품, 연결기능, 제품 클라우드, 보안기능, 외부 게이트웨이, 업무 시스템과 통합 등으로 구성된 새로운 기술 스택이 필요하다고 이야기 합니다.



제가 이해하고 있는 4차산업혁명은 온라인과 오프라인이 연결되는 온디멘드 서비스 유형에서 나아가, 모든것이 연결된 세상(IoT), IoT 로 수집되는 데이터의 CPS(Cyber-Physical System)에서 분석, 분석에서 나아가 기술과 사람의 의사결정력이 결합된 의사결정체계가 각 산업에서 분산을 통한 의사결정의 위임을 담당할때 성공적인 모습이라고 생각합니다. 따라서 많은 기업들이 자사의 제품 가치에 대한 높은 이해와 수집되는 데이터 분석기술에 대한 융합이 가능한 전문가를 요구하고 있으며 CDO(최고데이터책임자)를 둔 기업도 출현하고 있습니다.


IT 기업의 입장에서 보면 향후 4차산업혁명의 물결에 대응하기 위해서는 다양한 디바이스간의 연결이 가능한 기술(IoT framework, gateway, network protocol), 데이터를 수집하고 분석하는 기술(Bigdata analysis architecture, 분산파일시스템 응용기술), 데이터 기반 실시간 의사결정기술(AI, context decision making) 등이 중요하게 대두 될 것이라 생각됩니다.


현재 이러한 중요 기술들은 국내에서 원천기술을 확보하고 있는 경우가 거의 없으며, 대부분의 핵심기술은 오픈소스 프로젝트에서 제공됩니다. 따라서 앞으로는 시장에서 오픈소스를 활용한 기술개발이 더욱 심화될 것이고 기업에서 오픈소스 활용 거버넌스를 제대로 준비하고 않아서 발생되는 문제점도 커질 것입니다.  


때문에 향후 4차산업혁명의 성공을 위해서 조직은 오픈소스 기술에 대한 경험 축적과 함께 오픈소스 거버넌스의 조직 내 구축이 함께 되어야 할 것입니다.




최근 해외 기업들의 오픈소스 활용을 어떻게 하는지 살펴보면 모든 기업이 오픈소스 모델의 다양한 가치를 인식하고, 오픈소스 커뮤니티에 적극적으로 참여하고, 오픈소스 기반의 비즈니스 모델을 발견하려는 노력이 점차 강화되는 추세입니다. 이번에 자료를 정리하면서 여러 기업의 비즈니스 전략을 구분해 보았습니다.



기업들의 오픈소스 활용 전략들을 살펴보면 크게 4가지 유형으로 구분할 수 있습니다


1) 자사의 기술이나 서비스를 오픈소스 모델로 전환하여 타사와 경쟁할 수 있는 파괴적 전략으로 채택

2) 고객의 제품이나 서비스의 완성을 위한 전문성을 오픈소스 모델로 지원하는 전략

3) 오픈소스 개발, 배포모델을 기업 비즈니스 목표 달성을 위해 활용하는 전략

4) 오픈소스의 부가적인 가치를 기업 경영에 활용하는 전략


 

1) 전통적 SW개발 기업이 자사의 기술이나 서비스를 오픈소스 모델로 전환하여 타사와 경쟁.

 

- 듀얼 라이센싱 모델이나 코어 오픈모델을 사용하는 등 지적산출물에 대한 접근 통제를 가치로 파는 전략

- MySQL과 sleepycat(버클리 DB)가 듀얼 라이센싱으로 유명. 즉, GPL 버전은 무료로 쓰지만, non-GPL버전을 쓰려면 돈을 내야 한다. 소프트웨어를 Embed 해서 재판매 하려는 회사에 해당된다.

- Xen, SugarCRM 과 같은 회사에서는 코어 오픈모델을 사용. 즉, 코어는 공짜로 풀고 부가기능은 돈을 받고 파는 모델이다. 여기서 “판매가치”는 “특화 기능 (Differentiated Features)”들이 만들어 낸다.

- 보통 듀얼라이센싱을 하기 위해서는 오픈소스에 대한 판권을 가져야만 한다. 즉, 코어 개발자를 직접 고용해야 한다는 것을 의미한다. 즉, 개발력이 내재화되어 있으면, 코어를 오픈소스로 풀기도 하고 GPL버전을 만들어서 뿌리는 것도 자유롭다.

 

2) 전통적인 SW개발 모델이 아닌, 고객을 위한 분산된 컴포넌트의 통합을 교육훈련과 지술지원으로 돕는 오픈소스 전문 비즈니스 전략

 

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

- 이런 기업들은 실질적인 코어 개발자들을 물리적으로 보유함으로써 지적 자산을 보호해준다.

 

3) 오픈소스 개발, 배포모델을 기업 비즈니스 목표달성을 위해 활용

 

- 기업의 이익을 위해 선별적으로 오픈소스 소프트웨어를 선택하는 이른바 체리 피킹(cherry-picking:선별적 경쟁) 전략을 의미.

- 근간 기능(Commodity Features)은 소프트웨어의 프레임워크으로 뼈대를 형성하는 것이므로 전체 소프트웨어의 중요 부분을 차지하는 경우가 많다. 일반적으로 근간 기능(Commodity Features)은 비용과 시간 절감 및 OSS 사용층 유입의 장점이 있기 때문에 OSS로 구현되는 경우가 많다. (예) 빅데이터 플랫폼 Apache Hadoop)

 

4) 오픈소스의 부가적인 가치를 기업 경영에 활용

 

4-1) 오픈소스에 대한 공유와 협업으로 기업 이미지 마케팅 가시성 확보

 

- 최대 규모의 사유 소프트웨어 기업인 MS조차도 다양한 오픈소스 기여 활발하게 진행 중


아직 관련 매출을 발표한 적이 없음에도 불구하고 오픈소스 계획을 발표한 후로는 1억 달러로 우리가 얻을 수 있었던 것보다 더 많은 마케팅 가시성을 확보하게 됐다. - 아이오나 CEO 피터 조토(Peter Zotto)

 

4-2) 기업 내 조직운용의 실용성을 오픈소스를 통해 확보.

 

- 중소 벤처기업 아라스(Aras)는 MS기술로만 작성된 자사의 PLM(Product Lifecycle Management)기술을 오픈소스화 한 이후 영업직을 없애고 그 자리에 고객의 중요한 요구사항에 대한 서비스를 제공할 애플리케이션 엔지니어들을 추가했다.

 

4-3) 오픈소스를 활용한 소프트웨어 개발의 변화

 

- 오픈소스는 소프트웨어 산업에서 오랜 시간 논의 되었던 재사용, 재공학 등의 문제를 신뢰도 높은 소프트웨어의 재활용, 개발자의 전문성 강화, 오픈소스 개발프로세스의 활용 등 상당 부분 해결해주고 있다.

- 기업들은 공유와 협업이라는 오픈소스 문화의 적극적 도입으로 소프트웨어 개발 문화도 애자일, 린 개발법 등 다양하게 변화되고 있다.

 

최근의 기업 동향을 살펴보다 느끼는 점인데 예전과는 참 많이 달라진 모습이더군요. 저는 오픈소스가 시장에서 점점 더 많은 역할을 할 것을 기대하는 쪽이라 이런저런 재미있는 생각을 많이 하고 있습니다. 개발자에서 출발해서 지금은 개발보다는 다른 일을 더 많이 하는 자리가 되었지만 초심을 잃지 말고 제 나름대로의 방식으로 보다 좋은 세상을 위해서 기여하며 살고 싶다고 생각해봅니다.


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

오픈소스와 특허  (0) 2017.07.10
공개SW R&D 추진전략  (0) 2017.03.22
오픈소스 거버넌스  (0) 2016.09.29
공개SW 개발자대회 멘토링 이야기  (0) 2014.08.03
Vagrant 이용한 LAMP+Tomcat 개발환경구축  (0) 2013.11.04

지난 몇년간 오픈소스 거버넌스 이야기를 많은 분들과 나누면서 가장 많이 들은 이야기는 '그건 진정한 거버넌스가 아니죠, 제가 아는 거버넌스랑 다른데요' 였습니다. 그외에도 '그게 뭐예요' 또는 '괜히 그런 거 하지 마시지' 등의 이야기도 여러 번 있었습니다. ㅎㅎ


사무실에 혼자 앉아서 이런저런 자료를 만들다가 한번 정리해보고 넘어가야지 하는 생각에 또 글을 적네요.

위키피디아를 보면 거버넌스라는 단어는 1980년대부터 대두된 통치 시스템의 개념으로 아직 정의에 대한 학문적 합의는 이루어 지지 않았다고 합니다.


그래서인지 다양한 목적으로 다양한 분야에서 거버넌스라는 단어가 사용되고 있습니다. 

예를 들면, 뉴 거버넌스, 기업 거버넌스, IT 거버넌스, 정보보안 거버넌스 등이죠.

때문에 거버넌스에 대한 해석이 혹자는 정치 철학으로 혹자는 조직 관리 방법으로 해석하는 것도 당연한 일이겠죠. 


저는 몇년동안 여러 전문가 분들과 오픈소스를 기업과 공공이 어떻게 써야 좋을지에 대해서 고민해왔는데 그 결과물이 예전에는 도입가이드, 적용가이드 등에서 현재는 공개SW거버넌스가 되었습니다. 목적은 변하지 않았는데 좀 더 세련된 이름으로 불리게 되었죠.


지금의 저는 공개SW거버넌스를 이렇게 정의하고 있습니다.


공개소프트웨어를 안전하게 사용·적용 및 배포하기 위해 필요한 사항을 다양한 관점에서 활용할 수 있도록 소프트웨어 라이프 사이클 단계별로 제시한




거버넌스라는 단어가 아직 대중적이지 못한 단어이기에 정리해서 자료를 만들었습니다만, 그 이름이 무엇이라고 불리던 간에, 오픈소스를 사용하는 사람들에게 필요한 자료가 되기를 바랍니다.



일요일이라 밀린 일을 하러 사무실에 나왔다가 불현듯 셀프회고를 하게 되어서, 생각난 참에 예전 자료를 정리해봤습니다. 일하러 왔다가 딴길로 샌 하루네요 ㅎㅎ


예전에는 기술에 대한 관리업무가 저의 주 업무였는데 최근 몇년동안에 경영 전반에 대한 시야가 필요한 업무를 더 많이 하게 되었습니다. 지금 책상위의 내용을 보니 예전에 다루던 주제들이 많이 바뀌었다는걸 알 수 있네요.



사실 갑자기 애자일에 대한 기록을 돌아보게 된 것은 얼마전 링크드인을 통해서 모회사의 스크럼마스터 자리에 대한 제안이 있었습니다. 덕분에 정신없이 달려오던 지난 몇년을 돌아보게 되었죠. 


오늘은 애자일에서 제가 배운것과 여전히 남은 것에 대한 이야기입니다.


저의 애자일에 대한 시작을 더듬어보니 2006년 즈음에 켄트벡의 글을 만나면서 시작되었던 것 같습니다.



이 책을 통해 비슷한 고민에 대한 좋은 이야기를 접한 다음, 켄트벡, 김창준 이라는 키워드에서 TDD, 디자인패턴, 사용자스토리, 회고, xper 등으로 확산되었습니다.


애자일 프랙티스들을 여러 방식으로 적용해 보면서 익히고, 저의 주 업무가 변경되면서  그 과정에서 이런저런 현실적인 문제들을 만나서 현재 저에게 남은 것을 살펴보면 회고와 스크럼 보드 그리고 철학이네요.


우리는비슷한문제를풀고싶어하는다른이들과협업을즐기고, 개발하는내용을오픈소스화하고커뮤니티와정보를공유하며, 애자일한고객접근을통해고객의만족도를높이려고노력합니다


위의 글은 현재 회사의 웹사이트에 적어 둔 소개 내용입니다.


애자일이 저에게는 큰 영향을 주었던 것이 분명하고, 많은 것을 배웠습니다. 예전처럼 기술에 대한 고민은 자주 하지 못하지만 기업의 경영에서도 그 정신을 항상 잊지 않으려고 합니다.





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

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



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


1) 참가자 현황분석

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

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

4) 멘토링

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


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


A팀)

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

 - SW의 가시성 확보 필요

 - 불확실한 개발 일정 계획

 - 개발문서의 미흡


B팀)

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

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

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


C팀)

 - SW의 가시성 확보 필요

 - 개발문서의 미흡

 - SW품질에 대한 이해 부족


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


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

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

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

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

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

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


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


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








얼마전부터 IT 기획을 배우고 싶은 주변 사람들끼리 모여서 매주 스터디를 하고 있습니다. 스터디 첫날에 각자가 생각하는 기획이란 무엇인가에 대해서 이야기 하는 시간이 있었는데, 기획이라는 단어는 다양한 계층에서 다양한 관점으로 해석이 되고 있더군요. 


다음 중 누가 기획자로 적절한지 한번 골라보세요.

1) 계획을 세우는 사람이라는 의미의 플래너(Planner)

2) 팀원을 조직화하고 조율한다는 의미의 코디네이터(Coordinator)

3) 제품의 원형이 되는 아이디어를 내놓고 이를 구체적으로 설계한다고해서 디자이너(Designer)

4) 제품의 질적 기준을 제시하고 이를 감독한다고 해서 디렉터(Director)

5) 전체 프로젝트를 성공으로 이끌수 있도록 관리하고 총괄한다는 의미에서 프로듀서(Producer)

6) 제품을 총괄 관리한다는 의미의 프로덕트 매니저(Product Manager)


제품 기획 또는 서비스 기획을 IT 기획자라고 이야기 할 수도 있지만, 제가 생각하는 IT 기획은 그것보다는 좀 더 광의의 의미이며 그 내용을 정리해 보고 학습 로드맵을 정리해 보려고 합니다.



1. IT 기획의 정의


기획(企劃)이란 단어의 뜻을 네이버에서 확인하니 아래처럼 나오네요.


국어사전 : 일을 꾀하여 계획함.

행정학사전 : 어떤 대상에 대해 그 대상의 변화를 가져올 목적을 확인하고, 그 목적을 성취하는 데에 가장 적합한 행동을 설계하는 것을 의미


기획이란 보다 효과적이고, 효율적으로 목표달성을 하기위해 가장 적합한 행동을 설계하는 것을 의미한다고 할 수 있고, IT 기획이란 IT의 목표를 달성하기 위한 적합한 행동을 설계하는 것이라고 할 수 있겠죠. 


그럼 IT의 목표는 무엇일까요?

IT의 목표는 비즈니스를 돕는 IT와 IT 제품/서비스를 제공하는 IT 본연의 비즈니스 관점으로 생각해 볼 수 있습니다.


첫번째, 비즈니스를 돕는 관점에서 보면 기업은 업무를 지원하는 역할을 IT에 기대하고 MIS, EIS, SCM, CRM 등의 분야에 IT 기술을 활용합니다. IT 기술을 업무 지원에 사용하거나, 원가절감과 시간단축을 기대하고 IT를 사용하는 유형입니다.


두번째, IT 본연의 관점에서 보는 경우는 IT 기술을 이용하여 제품이나 서비스를 판매하거나, IT 서비스 또는 프로젝트 중심의 비즈니스를 통하여 수익을 발생시키는 유형입니다.


이 두가지 유형의 기업들은 IT를 통하여 새로운 비즈니스 창출을 통해 신규수익을 발생 시키거나, 경쟁우위 무기로 활용 기존의 매출을 증대시키거나, 내부혁신 촉매로 활용하여 업무 생산성을 증대하는 것이 주요 목적이 됩니다.


따라서 IT 기획이란 IT를 통한 신규 비즈니스의 창출, 경쟁우위로 활용, 내부혁신의 촉매로 활용하기 위한 적합한 행동을 설계하는 것을 의미합니다.



2. IT 기획의 대상


IT의 목표를 달성하기 위한 IT 기획업무의 대상은 아래의 3가지로 구분할 수 있습니다.


1) 전략

2) 사업

3) 제품/서비스


전략을 수립하기 위해서는 전체 경영진이 경영 목표를 명확하게 이해해야 하고, 그 전략을 토대로 각각의 사업이 기획되며, 제품/서비스도 사업에 적합하게 기획되어야 합니다. 각 영역에 필요한 기술과 지식이 별도로 필요하며 각 계층은 상호 긴밀하게 연관성이 있습니다. 


3. IT 기획 전문가 학습 로드맵

각 부문별 학습 로드맵은 다음과 같이 구성될 수 있습니다.

1) 전략 부문

- 어떻게 효과적으로 정보기술을 연계하고 적용할 것인가에 대하여 전략 및 해결책을 찾고 실행계획을 수립하는 과정 : 정보화 전략 계획 수립(ISP: Information Strategy Planning)

- IT 체계에 대한 효과적인 분석 및 활용 기법 : EA(Enterprise Architecture)

- 비즈니스 프로세스에 대한 효과적인 개선안 수립 기법 : BPR (Business Process Re-engineering), PI (Process Innovation)


2) 사업 부문

- 환경분석

- 업무분석

- 문제해결/이슈분석 기법

- 조사방법 활용

- 변화관리방법론

- 전략개발방법론

- 리스크 관리방법론


3) 제품/서비스 부문

- 제품/서비스 및 산업에 대한 이해

- 제품/서비스 기획 프로세스 지식

- 제품/서비스 기획 점검

- 제품/서비스 기획 리뷰

- 제품/서비스 기획 평가방법




+ Recent posts