오픈비 : 삽질은없다

이 책은 최근 한달동안 읽은 십여권의 도서 중 유일한 비 기술도서인데, 책 두께가 얇기도 하지만 내용도 흥미있는 이야기로 전개되어서 한번에 쭈욱 읽게 되었습니다. 책의 내용을 요약하면 제목에서 직관적으로 유추가 되는 것처럼 세계 기아에 대한 문제인식을 재조명 하는 내용입니다.

유엔 인권위원회 식량특별조사관으로서 활동해본 저자(장 지글러)는 우리가 외면하고 있던 사실을 묻습니다.

오늘 날 지구는 현재보다 두 배나 많은 인구도 먹여 살릴 수 있는 식량을 보유하고 있습니다.
즉, 식량 자체는 풍부하게 있는데도, 가난한 사람들에게는 그것을 확보할 경제적 수단이 없고, 그런 식으로 식량이 불공평하게 분배되는 바람에 매년 수백만의 인구가 굶어 죽는 현실이 반복된다는 것이죠. 왜 그런지 아시나요?

왜 세계의 절반은 굶주리는가 라는 질문에 대한 대답으로 막연하게 식량부족을 원인으로 생각하고 있었던 저에게 이 책은 다른 사실을 알려주었습니다. 시카고 곡물거래소의 투기, 사람은 굶고 소는 배를 채우는 현실에 대하여 관심을 가지게 하였다는 점에서 집필의 의미를 잘 전달하고 있는 책이라고 할 수 있겠네요.

다 읽고 책장을 덮으며 가장 먼저 든 생각은 제가 한국에서 태어난 것에 대한 안도감이었습니다.

911테러에 묻혀서 사람들이 잘 모르는 아옌데의 칠레 911 , 서아프리카 사하라 남단 부르키나파소의 상카라와 친구들의 이야기가 우리나라의 이야기가 아닌것이 다행이었습니다.

그리고 세계 사회의 기아에 대한 의식을 다시 한번 일깨우게 되었습니다.

바로 보면 아프지만 피해서는 안되는 사실인 기아.

해결의 희망은 공동이 관심을 모은 전 지구적인 민간단체에 있다고 저자는 말하고 있습니다.

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

운영 환경

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

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

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

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

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

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

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

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

이번 글은 설치된 레드마인을 Eclipse와 연동하는 방법에 대해서 작성하려고 합니다.
기본적으로 레드마인 공식사이트에서 제공하는 아래의 링크에서 읽으면 되지만, 오픈소스 프로젝트들은 환경이 각각 다르기 때문에 한번에 쉽게 되는 법이 없죠 :-)
http://www.redmine.org/projects/redmine/wiki/HowTo_Mylyn

설치 환경

OS : CentOS 6.x

Version : Redmine 2.2.0

Eclipse : STS

이 글은 레드마인이 설치된 상태에서 시작하기 때문에

레드마인이 설치되지 않은 경우는 이전글을 참고하세요 - http://yes.imhappyo.com/403

저는 CentOS 6.x 를 사용중이고 Redmine 2.2.0 버전을 설치한 상태입니다.
레드마인 사이트의 공식 가이드나, 구글링에서 나오는 Eclipse 연동을 위한 예전의 글은
낮은 버전의 레드마인을 위한 설명이 대부분이라 적당한 문서를 찾지 못해서 기록해둡니다.

설치는 크게 2단계로 나누어집니다.
1단계 - 서버에 설치된 레드마인에 mylyn 플러그인을 추가하는 단계입니다.
2단계 - 이클립스가 설치된 개발용 PC에서 이클립스 플러그인을 깔고 설정하는 단계입니다.

1단계) Redmine 서버에 Mylyn Plugin 설치

Redmine 2.2.0 설치된 서버에 redmine_mylyn_connector plugin을 설치합니다
http://danmunn.github.com/redmine_mylyn_connector/

redmine_mylyn_connector를 설치하는 과정에서 libxml-ruby 의존성 문제 발생하네요
- 의존성문제는 다음과 같이 해결 (http://michael.f1337.us/2009/08/26/172339834/)

의존성을 해결했으니 이제 플러그인을 설치합니다.

 - 저는 postgresql sqlite을 사용하지 않기에 --without 옵션에 추가되었습니다

설치를 완료했으면, 설치한 레드마인의 관리자> 환경설정> 플러그인 에서 아래의 화면이 있는지 확인합니다.

2단계) PC에 eclipse plugin 설치

Eclipse PC에 Mylyn Connector for Redmine 설치(저는 STS로 설치확인)
Window > Install New software > Update Site 에 아래주소를 추가합니다.

주소를 추가하면 아래와 같은 화면이 나옵니다. 체크박스를 모두 체크한 후 설치를 진행합니다.

이클립스 플러그인설치를 마쳤이니 이제 이슈를 가져오는 설정을 합니다.

New > Task 를 생성합니다.

화면처럼 설정이 다 되었으면 Validate Settings 를 눌러서 접속을 확인해 봅니다.

정상적으로 접속이 되었다면 이제 이슈를 가져오는 Query 생성 과정을 진행합니다.

Task List 윈도우에서 마우스 오른쪽 버튼을 누르고 새 쿼리를 생성합니다.

기타 유용한 도구
Third Party Tools - http://www.redmine.org/projects/redmine/wiki/ThirdPartyTools
윈도우용 Tortoise SVN 클라이언트에 플러그인으로 동작하는 프로그램인데, 컨텍스트 메뉴로 Redmine에 입력하는 설정을 할 수 있게 해줍니다.

* turtlemine(Tortoise Redmine Plugin) - http://code.google.com/p/turtlemine/wiki/BugTraqConfiguration

아시는 분이 많으시겠지만, IP 접근제한에 대해서 물어보는 팀원이 있어서 정리했습니다. 최근에는 보안인식이 고취되어서 많은 사람들이 관심이 있네요. 많이 사용되는 Apache, Tomcat 환경에서 IP 기반 접근제어 방법은 다음과 같습니다.

Apache IP 접근제한

Order Deny,Allow 의 경우

Allow 를 평가하기 전에 먼저 Deny 를 평가하고, 그 다음 Allow 에 override 함. 그리고 여기에 매치되지 않는 나머지 호스트 모두 Allow 됨. 따라서 이 Order 의 기본정책은 첫번째 Deny 지시자에서 결정함

Order Allow,Deny 의 경우

Deny 를 평가하기 전에 먼저 Allow 를 평가하고, 그 다음 Deny 에 override 함. 그리고 여기에 매치되지 않은 나머지 호스트는 모두 Deny 됨. 이 Order 의 기본정책은 첫번째 Allow 지사자에서 결정함.

참고 : http://httpd.apache.org/docs/2.2/howto/access.html

Tomcat IP 접근제한

참고 : http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html

IPTABLES IP 접근제한

hosts.deny, hosts.allow IP 허용/차단

오늘은 팀원과 서로가 원하는 이상적인 팀의 운영이란 어떤것인지 팀 운영방식에 대한 이야기를 할 기회가 있었습니다.

좋은 팀이란 무엇보다도 상대에 대한 이해를 기반으로 해야 하는데, 대화를 해보니 팀 리딩에 있어서 팀원들과 함께 팀의 미래에 대한 비젼을 공유하지 못하고 있는 것 같아서 좋은 팀에 대한 제 생각을 한번 정리해 보려고 합니다.

지난 몇년간 애자일하게 일하는 SW기업이 되고자 이런저런 고민을 많이 하고 있습니다.

그 중 'Self-Organizing Team' 이라는 키워드는 매력적이었고 제가 원하던 모델이었죠.

저는 전통적인 조직운영 방식에서 보이는 강력한 중앙집중형 리더십이 조직을 이끌어가는 형태가 아니라

통제가 적고 구성원의 자유도가 높은 리더십으로 운영이 되는 애자일한 조직운영을 하고 싶었습니다. 

Source : http://blogs.seapine.com

제가 이해한 'Self-Organizing'은 멋진 용어이지만, 실제 현업에서 몇년간 해보니

자율적인 업무결정권을 자유로운 업무방식으로 오해하는 팀원이 생기고 그로인해 갈등이 심해지는 경우들이 발생되었습니다.

프로젝트에서 너무 적은 리더십을 가진 스크럼마스터는 팀원이 상호작용하여 협업이 되도록 하기에는 부족하였고

팀원에게 많은 결정사항을 위임하는 자율적 결정방식은 수동적이 지시에 의존해온 팀원들에게 괴로움만 가중시키게 되었습니다.

'서툰 목수가 연장을 탓한다'고 하더니 이게 그런 모습이네요. ㅎㅎ

사실 이것은 리딩을 제대로 못한 저의 무능력 때문이지, 자기조직적팀(Self-Organizing Team)이 잘못된 것은 아니라고 생각합니다.

제가 생각하는 자기조직적인 좋은 팀이란?

프로젝트의 핵심가치를 위반하지 않고 유연하게 해당 업무를 수행할 수 있는 능력이 충분한 사람들의 모임.

- 상호간 업무수행에 있어서 친화력(affinity)이 있을 것.

- 핵심가치를 달성하기 위하여 충분한 자격(competent)을 가질 것

- 팀의 공동문화에 대한 이해와 지지

- 리뷰는 각각의 일정에서 가장 높은 우선순위로 처리하는 태도

- 핵심가치의 달성이라는 목표의 업무안에서는 자체적인 활동

- 중앙집중형 의사결정이 아니라 팀에 의사결정 권한을 분산하고 결과에 대한 책임도 공유

- 개개인은 문제해결을 위하여 능동적인 대응

최근에는 운영방식을 좀 변경했는데 최종결정을 내리는 의사결정프로세스를 명확하게 하여 팀원의 책임을 덜어주면서

팀원들이 능력을 최대한 발휘할 수 있도록 독려하는 형태를 유지하려고 하고 있습니다.

모든 일을 잘하는 슈퍼개발자를 원하는 것은 아니지만 분석, 설계, 코딩, 테스트, 배포를 할수 있는 스크럼 팀원이 다수 있어야 하는데 자원의 확보(항상 팀원이 부족합니다 ㅎㅎ)부터 교육이나 인적자원 관리 등의 이슈가 많아서 팀 리딩이 어려운것은 여전합니다. 하지만, 팀원들이 모두 잘 따라주어서 예전 보다는 훨씬 나아졌으니 앞으로 점점 좋아질거라고 믿습니다.

이 책은 제작년쯤 개발자 세미나에서 경품으로 받은 책입니다.

그때 분명히 재미있게 읽었는데 

기억력이 쇠퇴해서 그런지 지금 책을 다시 보니 기억나는게 몇가지 안되네요.

책 제목은 누워서 읽는 퍼즐북이지만 

문제의 해답을 찾느라 잠을 잘 수 없는 경우도 예상이 되기 때문에

자기전에 읽는 건 비추천입니다. ㅋ

저는 이 책에서 흥미를 느낀 부분이 Edward Adelson의 그림입니다.

이 그림에서 우리가 인지하는 감각과 판단의 오류에 대해서 다시한번 생각하게 되었죠.

그림의 A와 B는 같은색입니다.

믿기시나요? 

요즘 잉여시간이 없어서 포스팅을 못하고 있었는데 오늘 이메일로 팀원중의 한명이 다음과 같은 질문을 해왔습니다.

처음에는 재미있고 열정이 가득했던 일이 시간이 지나면서 점점 단조로워지고 예전처럼 재미가 없어서 열정이 줄어드는 문제에 대해서 어떤 해결책이 있을까요?

이와 비슷한 문제를 저도 예전에 고민했던 기억이 나서 답변을 위해서 좀 생각을 해보았는데 딱히 정답이 있는 것이 아니니 제가 생각해 왔던 이야기를 해주는 것이 좋을 것 같아서 글로 정리를 해보았습니다.

어느 조직에서나 조금 경력이 쌓이고 후임자들을 관리해야 하는 자리에 가게되면 팀원들 효율적 생산성 제고 방안에 대하여 생각하게 되죠. 저 역시 SW기업의 좋은 팀워크에 대한 고민이 항상 많습니다. 

개인의 욕구와 동기부여를 위한 이 부분의 설명을 위하여 가장 알려진 것은 매슬로우의 욕구5단계입니다. 매슬로우는 인간의 내부에는 다섯가지의 욕구단계가 존재한다는 논리(인간의 동기와 성격-Motivation and Personality)를 주장하는데 개인에게 동기를 부여하기 위해서는 단계별로 상승하는 인간의 욕구를 제대로 이해해야 한다는 것이죠.

이 5단계는 다시 1~4단계의 결핍욕구와 5단계의 성장욕구로 나눌수 있습니다. 결핍욕구는 주로 연봉이나 근무시간 등의 외부요인으로 충족이 되는 반면 자아실현의 욕구는 자신의 내부요인에 의해서 충족될 수 있다고 합니다. 이 논리가 문화적 차이가 있는 외국에서 정립된 것이므로 우리의 조직문화에서 정답이 되기는 어려울 수 있지만, 제가 팀원들에게 동기를 부여하여 자기실현을 위한 코칭을 할 때 판단기준으로 잘 사용하고 있습니다.

이메일로 받은 질문에 대한 저의 답변은 "아래의 순서대로 해 보세요" 입니다. 

1) 현재의 상태를 진단해본다

2) 자기실현문제가 아니라면 외부환경을 개선해서 해결해 본다

3) 자기실현의 문제라면 자기실현에 성공한 사람들의 특징을 이해하고, 자신의 삶에 적용해 본다

4) 잘 안되었으면 다시 해본다.

음.. 쓰고보니 자주 보시던 점진적 SW개발방법론과 비슷하네요.

저의 경우에는 자기실현의 문제가 있어서 고민을 했었고 제가 이 경우에 적용해본 방법은 팀 스터디를 하거나 오픈소스SW 프로젝트에 참여하거나 특정한 문제를 해결하는 능력을 배양하거나 하는 등의 '최대한 많은 것을 알고 경험하기(peak experiences)' 입니다. 

자기실현에 성공한 사람들의 특징에는 사생활을 즐길수도 있고, 인간관계를 깊이 하는 것도 있고 여러가지 공통된 특징이 발견되었으며 이런 특징을 모두 가지고 있다고 해서 반드시 멋진 인생을 살게 된다고 할수도 없습니다. 따라서 제가 적용한 이 방법이 모든 경우에 적용가능한 은총알이 될 수 없겠죠. 그렇지만 "어떤 인생을 살 것인가"에 대한 고민이 될 때 이런 방법을 고민해 보는 것도 좋을거라고 생각합니다.

워낙 화제의 책이라 주위의 많은 사람들이 들고다니는 걸 보았다.

나도 관심 많은 분의 이야기라 차근차근 책갈피를 접어가면서 읽었다.

오랜만에 읽는 위인전이다. 읽고 나니 위인전이라고 표현할 수 밖에 없다.

성공을 위한 처세술이 아니라 깊은 사고와 그로 인한 통찰력이 고개를 끄덕이게 만드는 내용.

살아오며 나도 고민하던 문제들에 대한 다른 해석들이 내 사고를 자극해서 좋다.  

앞으로 저자가 정치적으로 활동할지 어떨지는 모르지만, 모든 사람들이 주의 깊게 들어야 하는 좋은 생각들이 많은 양서임은 분명하며, 우리나라의 미래에 보탬이 되는 생각이 많았다.

수 년간 지켜봤고 믿고 싶은 사람이다.  

안철수 원장이 생활신조로 삼고 있다는 문구는 정말 공감한다.

어떤 문제에 부딪히면 나는 미리 남보다 시간을 두세 곱절 더 투자할 각오를 한다. 그것이야말로 평범한 두뇌를 지닌 내가 할 수 있는 유일한 방법이다 - 히로나카 헤이스케

기계든 사람의 관계든 지나치게 빠르면 꼭 문제가 생기게 되어있어.

달리지 않으면 넘어진다고만 생각했지, 달리다 힘들면 멈출 수도 걸어갈 수도 있다는 걸 뒤늦게 알았어. 어느 순간, 뭔가에 둘러싸여 둥둥 떠밀려 간다는 느낌을 떨쳐버릴 수가 없었네. 그것을 알아 챈 순간 아주 기분 나빴어. 내가 가야 하는데 누군가에게 등 떠밀려 간다고 생각해보게. 죽을 때가 되니까 정신이 든거지. 허허허”

최근 클라우드 분야에서 오픈소스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기술이 클라우드 분야에서 확산되기 위해서는 우선 기업의 의사결정을 돕는 다양한 자료가 필요하겠습니다.