Younghoe.Info v3

지하철과 코코넛

영회 — Thu, 18 Mar 2010 09:00:00 +0900

상세한 설명을 읽으며 조금 지루했지만 흥미롭고 기억할만한 주장을 담고 있다.

이하는 기억하고 싶은 표현

여기서 환자를 위한 교훈은 무엇일까? 간단하다. 뜻밖의 검사 결과가 나오면 검사를 다시 한 번 해보라는 것이다. 검사가 연속해서 두 번씩 잘못되지는 않을 테니까 말이다. 또 하나의 교훈은 의사들과 그들을 교육시킨 사람들을 위한 것이다. 단적으로 일반화해서 말한다면, 그들은 자신의 직업에 따르는 불확실성을 올바로 이해하고 통계학에 관한 교육을 더 받을 필요가 있다.

지하철과 코코넛 48~49쪽

의학을 너무 믿지는 말자.

테리어 뷔르츠바허 박사의 권고대로 의사의 진찰을 받기 전에 먼저 자신의 건강에 관해 중요한 질문을 모두 던져보라. <중략> 현재 복용하는 약이나 영양 보충제가 있는가? 식이요법 중인가? 주량은 얼마나 되는가? 운동량은 얼마인가? 현재 스트레스를 받고 있는가, 아니면 과거에 심한 스트레스를 받은 적이 있는가? 알레르기가 있는가? 가족들 중에 어떤 병력을 가진 사람이 있는가? 의사가 이런 정보 등을 쉽게 얻을 수 있다면, 환자의 현재 증세를 논의하고 유용한 여러 가지 치료법의 장점과 단점을 설명하는 데 집중할 수 있다.

지하철과 코코넛 90쪽

치료 결과의 정확성을 높이기 위한 상식

장기적으로 모든 주식과 채권의 연평균 수익률은 상당히 일관성 있고 전망이 밝다. 그리고 채권보다 주식의 수익률이 높다.
중, 단기적으로 주식과 채권에 대한 수익 예측은 거의 불가능하다.
전문가들과 안목이 높은 모범 투자자들도 그들이 속한 시장의 평균 수익률을 앞서지 못한다.

지하철과 코코넛 143쪽

주식 관련 기사는 한 발 떨어져서 참고만 하자.

4가지 투자 지침

평균 수익률을 목표로 삼아라. 인덱스펀드나 상장지수펀드 등에 투자하라.
인내하라. '완벽한' 시점에 팔려는 생각을 버려라. 거래를 자주 할수록 수익률이 낮아진다.
균형을 취하라. 목표를 제대로 유지하려면 먼저 포트폴리오를 정기적(최대한 일 년에 한 번씩)으로 재조정하라.

경험적인 방법은 포트폴리오 가운데 채권의 비율을 자신의 나이와 비슷하게 맞춰야 한다는 것이다.

지하철과 코코넛 144쪽

4가지 투자 지침 중에 3가지 메모하고 기억하라.

마흔 살을 위한 균형 잡힌 포트폴리오 소개

15% S&P 500 (상당히 안전한 미국의 대기업 중심)
10% 가치주 (다소 투기적)
10% 소형주 (일부 소기업은 진정한 승자가 될 수 있음)
15% 국제 대형주 (미국 경제가 파탄 나는 경우에 대비해)
10% 신흥 시장주 (10%의 스릴을 즐기기 위한)
20% 단기채권 (긴급 상황에 대비해)
20% 장기채권 (즐겁고 편안하고 안전한 기분을 위해)

지하철과 코코넛 146쪽

통계이니만큼 투자할 때 참고하자.

투자에 적합하지 않은 8가지 노래 (중에서 몇 가지 메모)

1. 부화뇌동 하는 것. 불행하게도 통계를 보면 일반 투자자는 주가가 높을 때 매입하는 것으로 나타나 있다. <중략> 오늘의 스타 펀드매니저가 내일의 실패자가 되는 경우가 아주 많다.
3. 신문 기사를 믿는 것. 문제는 언론인들이 따분한 진실보다 흥미 있는 이야기에 더 관심을 기울인다는 사실이다.
7. 소망적 사고. 가망 없는 스포츠팀의 헌신적인 팬은 누구나 낙관주의가 필요하다는 것을 이해할 것이다. 시카고컵스 팬에게 물어보라.

지하철과 코코넛 147~149쪽

투자할 때 피할 사항 세 가지.

도박의 몇 가지 오류

다시 말해 지난번의 결과에 상관없이 매번 검은색이 나올 확률은 '동일하다'. <중략> 미래의 모든 결과는 이전의 결과와 아무런 관련이 없다.

지하철과 코코넛 226~227쪽

근거 없는 착시 현상을 피하자.

사람이 범할 수 있는 오류에는 두 가지 유형이 있다. 하나는 존재하지 않는 패턴을 실재한다고 가정하는 것이다. 다른 하나는 실제적인 패턴을 우연한 것으로 취급하는 것이다.

지하철과 코코넛 234쪽

당장 와 닿는 표현은 아니지만 기억하자.

평균화가 효과를 발휘하는 상황

우리가 의존하는 자료들은 기본 패턴과 소음이 결합된 것이다. 평균화 방식의 큰 장점은 소음을 제거하는 것이다. 소음은 저마다 왜곡하는 방향이 다르다. 평균화 과정에서 소음은 서로 상쇄되어 기본 패턴이 드러난다. <중략> 평균화가 그 힘을 유지하려면 예측의 다양한 오류가 서로 아무런 연관이 없어야 한다. 전문적인 용어로 이것을 '독립성 가정 independence assumption'이라고 한다.

지하철과 코코넛 267~268쪽

이해관계자가 여럿인 의사결정 모델.

미래 완료형 사고 future-perfect thinking

어떻게 이런 일이 일어났을까? <중략> 이런 연습을 몇 차례 한다면 다양한 미래에 대한, 그리고 그 미래가 모두 개연성이 있다는 사실에 대한 감각을 계발하게 될 것이다. <중략> 자신이 얻은 통찰력으로 적절한 위험 예방 전략을 계발할 수 있을 것이다. <중략> 자신이 얻은 통찰력으로 적절한 위험 예방 전략을 계발할 수 있을 것이다. <중략> 미래 완료형 사고란 소 읽고 외양간 고치는 일을 능숙하게 이용해서 미래를 좀 더 분명하게 파악하는 것이다. 그것은 현재 일어나고 있는 코코넛형 사건에 대한 평가를 확대하는 방법일 뿐만 아니라 그 사건에 미리 대처하기 위한 계획을 세우는 방법이기도 하다. <중략> 우리가 할 수 있는 것은 삶이 그리 간단치 않다는 깨달음으로 불확실성을 받아들이고, 우리의 운을 합리적으로 평가하고, 그 평가를 확대하는 것이 전부다.

지하철과 코코넛 298~303쪽

이 책의 핵심인데 아쉽게도 공감은 겨우 고개 끄덕이는 수준이다.

고수의 조건

'블링킹 blinking(신속하게 결정을 내려야 할 때 첫 2~3초 동안 무의식에서 섬광처럼 일어나는 순간적인 판단)'은 예술적인 판단에만 한정되지 않는다. <중략> 카파블랑카는 "한 수밖에 보지 못하지만 항상 정확하다"라고 말했다고 한다. <중략> 고수의 첫 번째 핵심 요건은 최선의 수에 '직관적으로' 초점을 맞추는 것이다. 두 번째 차별화 요소는 패턴 인식력(또 하나의 순간 판단력)이다. 세 번째 가장 중요한 것으로 '연습 요소'가 있다.

지하철과 코코넛 310~311쪽

120% 공감.

자폐적 석학의 기묘한 사례

자폐적 석학들 autistic savant (특정 분야에서 천재성을 발휘하는 자폐아로, 정치적으로 올바르지 않았던 시절에는 '천재 백치 idiot savant'로 알려졌다.) <중략> 사람의 정신은 유연하다. 처음에는 불가능해 보였던 일도 결국에는 할 수 있게 된다. <중략> 우리가 활동하는 이 세계는 더욱 복잡하다. 타협과 실수가 불가피하다. <중략> 우리 정신은 눈 깜짝할 사이에 제한된 정보로 결정을 내리는 데 지름길을 이용해야 할 때가 많다. 이렇게 내린 결정 중에 잘못된 것이 있다면 어쩔 수 없는 노릇이다.

지하철과 코코넛 313~314쪽

나는 블링킹한다, 고로 나는 존재한다.

오히려 반대로 그 결정은 아무런 분석 없이 순식간에 무의식적으로 이루어진다.

지하철과 코코넛 315쪽

항상 실수를 인정할 수 있는 마음 자세가 필요한 이유. 어느 때고 절대 그럴 리 없다고 말하지는 말자.

10년 동안 연습, 연습, 또 연습

적어도 10년 동안 효과적인 피드백이 따르는 계획적 훈련을 할 의지가 있다면, 어느 분야에서도 체스 고수처럼 전문가 수준에 도달할 수 있다. <중략> 계획적 훈련은 기존의 기량 수준을 넘어서는 것을 목표로 삼는다. 하지만 적절하면서도 측정 가능한 피드백을 받아야만 비로소 그 수준을 넘어설 수 있다. <중략> 그러나 뭐니 뭐니 해도 가장 큰 어려움은 우리의 오랜 숙적인 통제감의 착각일 것이다. 통제감의 착각은 피드백을 평가할 때 큰 장해물이 될 수 있다. <중략> 사실임에도 증거를 받아들이려 하지 않는 '부정적인 사람'도 많고, 항상 성공이 눈앞에 와 있다고 믿는 구제 불능의 낙관주의자도 많다.

지하철과 코코넛 320~321쪽

실천 과제.

결정의 순간

당신이 아무리 똑똑하고 강한 동기가 있을지라도 당신만큼 지적이고 열심히 노력하는 사람들이 항상 있다는 사실을 명심하라. <중략> 어떤 분야에서 어떤 일을 하든지 더 나은 인물이 되는 것은 그리 어렵지 않다.

지하철과 코코넛 326~328쪽

타인과 비교하지 말고, 더 나아지려고 노력하자.

모든 결정에 처방을 내릴 수 있는 사람은 아무도 없다. 우리가 할 일은 결정의 두 가지 유형과 결정을 내리는 4가지 방법을 구분하는 지침을 제시하는 것이다. 두 가지 유형이란 일련의 비슷한 판단으로 이루어지는 '반복적인' 결정과 '유일한' 또는 일회성 결정을 말한다. <중략> 4가지는 '블링킹(또는 본능적인 반응)'과 싱킹(주도면밀한 과정을 통한 결정), 스밍킹 sminking (단순한 모형 simple model이나 결정 기준 decision rule을 이용하는 방법), 타인(되도록이면 '진정한' 전문가)의 의견 이용하는 것이다. <중략> 반복적인 결정은 단순한 모형이나 결정 기준을 이용하는 이른바 '스밍킹'이 적합하다. <중략> 신용 평가에서는 일반적으로 소유주든 아니든 간에 한 집에 얼마나 오래 거주해왔는지, 현재의 직업을 얼마나 오래 유지해왔는지, 그리고 가계 소득 총액은 얼마나 되는지 등의 요소는 변수가 된다.

지하철과 코코넛 332~336쪽

스밍킹을 자주 활용하자.

행복의 가격

건강이 단연코 가장 가격이 높다. 상대가 배우자든, 아니면 파트너나 친구, 이웃, 친척이든 간에 좋은 관계가 행복한 삶에 아주 중요한 부분임이 분명하다.

지하철과 코코넛 383쪽

모든 일을 제쳐놓고 건강부터 챙기자. 그리고 관계를 회복하고 유지하자.

30년 후

우선 무엇보다 경험적 증거를 받아들여라. 경험적 증거는 통제감의 착각을 떨쳐버리고 우연과 함께 춤을 추는 것이 최선임을 입증해준다. 역설적으로 그렇게 함으로써 우리는 삶의 여러 측면에 대한 통제력을 강화시키게 된다. <중략> 몸이 아프지(또는 임신하지) 않는 한 의사를 멀리하는 것이 최선이다. <중략>경제학과 재정학은 의학보다 훨씬 더 부정확한 과학이다. 이 두 분야의 전문가들은 과거의 성과를 설명하는 데 있어 능숙하지만, 어떤 증권이 최고의 수익을 올릴 것인지를 예측하는 데 있어 원숭이보다 나을 것이 없다. 그러므로 전문가의 조언을 구하기보다 무작위로 주식을 고르거나 평판 좋은 증권들만 추적하는 인덱스펀드에 가입하는 방법으로 저축금을 투자하는 편이 훨씬 나을 것이다. <중략> 문제를 잘 아는 개인의 견해를 평균화하거나 단순한 통계 모형을 이용하는 것이 좀 더 정확할 것이다. <중략> 유일한 해결책은 경영자들이 경영 환경의 예측 불가능성을 받아들이고 좀 더 벤처 캐피털리스트처럼 운영하는(소수의 엄선된 아이디어에 '투자하는') 것이다. <중략>

미래는 결코 과거와 같지 않다.
'복잡한' 통계 모형은 과거 자료에는 적합하지만, 미래를 예측하지는 못한다.
'단순한' 모형은 복잡한 모형보다 과거 자료에는 적합하지 않지만 미래 예측에는 더 낫다.
통계 모형과 사람은 모두 미래의 불확실성을 충분히 파악할 수 없고, 미처 생각지 못한 큰 오류와 사건들로 놀라지 않을 수 없다.
전문가의 판단은 보통 단순한 통계 모형에 미치지 못한다.
평균화는 (모형이든 전문가의 견해든) 일반적으로 예측의 정확도를 높여준다.

지하철과 코코넛 387~389쪽

와! 마지막 요약이 무척 마음에 든다. 정리를 하고 보니 책에 대한 막연한 느낌과 달리 엄청난 지혜를 준다.

지하철과 코코넛 -
로빈 호가스 외 지음, 김정수 옮김/비즈니스맵

자주 틀리는 표현

영회 — Thu, 18 Mar 2010 02:04:24 +0900

가능성이 높다 → 가능성이 크다
(의지를) 가지고 → (의지를) 갖추고
감싸인 → 둘러싸인
★ 감안해 → 고려해, 참작해, 살펴, 생각해
★ 갖고 있는 → 가진
(~을/를) 갖고 있지만 → (~가) 있지만
갖아보면 → 가져 보면
갖지 → 느끼지
검색을 할 → 검색할
결국 → 결국,
고민을 했다 → 고민했다
관심을 갖는 → 관심을 두는
구비한 → 갖춘
★★★★★ 그러나, → 그러나
★★★★★ 그리고, → 그리고
근자에는 → 요즘에는
금새 → 금세
(능력이) 급성장하다 → 급향상하다
기반한 → 기반을 둔
기여할 → 이바지할
꺼림직한 → 꺼림칙한
꺽인다 → 꺾인다
꽤나 → 꽤
나눠지고 → 나뉘고
나올라나 → 나오려나
★ 난데 없이 → 난데없이
난이도도 높고 → 어렵고
남탓에 → 남 탓에
내역 → 내용
너무 좋아서 → 아주/매우 좋아서
노하우 → 비결, 비법
누구말대로 → 누구 말대로
다달을수록 → 다다를수록
단초 → 실마리
담고 있는 → 담은
대개의 경우 → 대개
대기한다 → 기다린다
대부분의 (작업을) → (작업) 대부분을
더 이상 → 다시는, 더는
데드락 → 교착상태
데자뷰 → 데자뷔
도식화 한다 → 도식화한다
도처에서 → 곳곳에서
되더라구요 → 되더라고요
동일하게 → 같이
뒤 이어는 → 뒤이어는
뒷풀이 → 뒤풀이
들여다 보면 → 들여다보면
띄며 → 띠며
맞냐 → 맞느냐
머지 않아 → 머지않아
몇 일 → 며칠
모양을 띈다 → 모양을 띤다
못지 않게 → 못지않게
무리배 → 무뢰배
무엇이었냐 → 무엇이었느냐
바꾼 후 → 바꾸고, 빼앗긴 후 → 빼앗기고
반감을 가진 → 반감을 품은
박발을 하다 → 반박하다
방치했다 → 버려뒀다
별 생각 → 별생각
병기하기 → 함께 적기
보내다보니 → 보내다 보니
보여질 → 보일
부르짓던 → 부르짖던
부합하는 → 맞는
★ 분명 → 분명히
불러지는 → 불리는
블로그스피어 → 블로고스피어
빽빽히 → 빽빽이
뿐만 아니라 → 그뿐만 아니라
사랑스런 → 사랑스러운
사용할 수 있는 방법은 → 사용하는 방법은
새 집으로 → 새집으로
수 밖에 → 수밖에
쉽상인 → 십상인
스스로도 → 자신도
아니기 때문에 → 아니므로
악세사리 → 악세서리
안좋은 → 안 좋은
않는가 → 않은가
얼마전 → 얼마 전
얼핏보면 → 언뜻 보면
옥의 티 → 옥에 티
와닿는다 → 와 닿는다
왠만한 → 웬만한
★ ~의 경우 → ~는
의례 → 으레
의지 박약 → 의지박약
이런 저런 → 이런저런
이로 인해 → 이 때문에, 이로 말미암아, 이 탓에, 이 덕분에
이를 테면 → 이를테면
이야기 하고 → 이야기하고
이와 같이 → 이처럼
있냐 → 있느냐
익숙치 → 익숙지
~인 반면 → ~이지만
일괄로 → 한꺼번에
일체 없다 → 일절 없다
입각해서 → 따라서
제3자 → 제삼자
제쳐두고 → 제쳐놓고
족하다 → 충분하다
주눅들어하는 → 주눅이 들어하는
주제 넘게 → 주제넘게
중생으로써 → 중생으로서
중에 하나 → 중의 하나
증가 뿐 → 증가뿐
지나고 있는 → 지나는
지는거다 → 지는거다
지불한 → 지급한, 낸
지져분하게 → 지저분하게
짐작컨대 → 짐작건대
짖굳게도 → 짓궂게도
짜투리 → 자투리
짧막하게 → 짤막하게
쪽팔리게시리 → 쪽팔리게끔
차용한 → 빌린
촉진시켜 → 촉진해
최선을 다하지 → 온 힘을 다하지/기울이지
추스리고 → 추스르고
컨퍼런스 → 콘퍼런스
컬럼 → 칼럼
큰 경우에 → 크면
타고 나는 → 타고나는
트랜젝션 → 트랜잭션
폄하하여 → 깎아내려
프록시 → 프락시 (외래어 표기법 at NARAINFOTECH 2009.06.11(v4.01))
피같은 → 피 같은
필요로 하는 → 요구하는
필요로 할 → 필요할
하고 있는 → 하는, 한
하길래 → 하기에
~하기 위해서는 → ~하려면, ~하려고
(발행)하는데 → 하는 데
하다보니 → 하다 보니
★★★★★★ 하지만 → 하지만,
한 가운데 → 한가운데
한가지 → 한 가지
한김에 → 한 김에
한 두 → 한두
해외여행 → 외국/재외/국외여행
향후 → (순화용어) 앞으로
현자들이 → 현자가
현혹시킬 → 현혹할
혼돈스럽게 → 혼란스럽게
휴대폰 → 휴대전화
휴우 → 후유
흥망성쇄 → 흥망성쇠
흥미로와서 → 흥미로워서
★★★★★ 힘든 → 어려운
100 여 → 100여

수집 동기: 한국어 맞춤법/문법 검사기 쓰기에 따른 개선 활동

들을만한 스프링 교육이나 유사 세미나 정보

영회 — Wed, 17 Mar 2010 09:00:00 +0900

확정적인 내용은 아니지만 아는 내용을 미리 털어놓는다.
혹시 관심 있는 분께서 궁금한 사항 있으면 소통 바랍니다. 댓글 아니라 왼편 주소로 메일 주셔도 좋아요.

일단 4월
찬욱이가 강의하는 인기폭발 폴리텍 강좌를 4회차를 4월에도 이어간다.
예상 개강일자는 10일이나 17일 정도다.
중소기업 재직자 대상이라 모두에게 기회를 주지는 않지만 무료다. :)
KSUG 메일링에서 선착순 모집하는데 보통 2시간 정도면 마감하니
듣고자 하는 분은 4월초부터 KSUG 메일링을 주시해야 한다.

4월 17일 토요일에 KSUG에서 세미나를 준비하고 있다. (기억력이 좌절이라 날짜는 장담 못하지만...)
세션 하나를 배당(?) 받았는데 이번에는 스프링 이야기보다는
개발자 경력 개발에 대한 고민을 나누는 시간이나 개발자 사이에서 진취적인 연대의 필요성과 방안에 대해 이야기 하고 싶은데... 아직 구체적인 내용은 없다. :)

4월 착수로 협상 중인 프로젝트가 결렬되면 4월이나 5월에 실전 노하우를 추려서 유료 세미나를 열 생각이다.
내일 박재성님을 만날 짬이 생길 수도 있는데 함께 논의할 생각이다.

가정의 달 5월엔
Toby 일민형이 세계 최초(아마도)로 스프링 3.0 서적을 출간할 예정이다.
역시 4월 착수로 협상 중인 프로젝트가 결렬되면 내 맘대로(?) 저자 직강을 기획할 생각이다.

더워지는 6월
고객 사이트에서 스프링 교육 의뢰가 들어왔다.
함께 다룰 다른 일이 많아 개설 자체도 지금은 확실치 않다.
개설하면 부끄럽지 않은 준비를 해야겠다.

들을 만한 스프링 교육

영회 — Tue, 16 Mar 2010 09:00:00 +0900

"들을 만한 스프링 교육"이 없다고 많은 사람이 이야기한다.
시장수요에 따라 국내 교육기관이 개설한 스프링 강좌는 있다.
하지만, EJB의 기술적 제약 극복을 위한 노하우를 쌓아온 교육 기관이 아니라면
하루아침에 높은 수준의 스프링 교육을 만들 수 없을 것이다.

레퍼런스를 통해 익힌 사용법 정도만 익혀도 교육을 만들 수는 있지만
그 정도라면 시중에 나와 있는 책이나 인터넷에서 찾을 수 있는 내용을 참조하여
실습을 하면서 고민과 시행착오를 겪는 일로 대신할 수 있다.

생업이 있어 스프링만 연구할 수는 없고 우리나라에도 쓸만한 스프링 교육이 있었으면 하는 마음에
작년 JCO 컨퍼런스에 맞춰 SpringSource 컨설턴트를 초청해 스프링 공식 교육을 시도했었다.
당시 환율 상황도 안 좋아서 4일에 300만 원(?) 정도였던 교육은 최소 수강인원(6명) 미달로 열리지 못했다.

이제는 개인적으로나 기술 수요측면에서나 때가 되었다는 생각에 스프링 교육을 다시 시도하려고 한다.
단순히 스프링 사용법이 아니라 응용력에 초점을 맞춘 첫 번째 시도를 슬슬 기획하면서
소통을 하고 싶어 글을 올렸더니 의미 있는 댓글이 달려 생각을 더 풀어놓는다.

우리가 스프링에 투자해서 무엇을 얻었나

개발 보다 운영의 일정부분은 책임을 져야 한다는 책임 의식

충분히 공감하지만 당장은 스프링에 대한 응용력 교육이 선행되어야 한다는 생각이다.
4월 첫 번째 스프링 교육을 기획하는 지금 처음 이프릴 세미나를 준비할 때가 떠오른다.
90분 라이브 코딩을 위해 연습할 때 가졌던 긴장감이 필요한 시점이다.

프로젝트를 마치고, 새로운 시작을 준비하며

영회 — Mon, 15 Mar 2010 09:30:00 +0900

꼬박 9달 반을 이어온 프로젝트를 마치는 날이다.
컨설턴트라는 위치상 운영업무를 경험할 일이 많지는 않은데
이번 프로젝트에서는 운영팀장이 책임자인 프로젝트여서인지 운영자의 마음을 헤아릴 일이 많았다.
더구나 시스템 오픈 후에는 운영자 역할을 하면서 새로운 경험을 했다.

사실 무엇보다 놀라운 사실은 전혀 비합리적인 동기로 시작한 일이
가장 짧은 시간에 엔지니어로서의 보람을 느끼게 해주고
진심으로 기뻐하는 고객을 만나게 해주었다.

7개월 동안 근처도 가지 못했던 일을 몇 주 만에 해낸 일종의 기적을 맛보았다.
현실적으로 불가능한 일이지만 상황에 쫓겨 '나 죽었소'라는 심정으로 덤벼든 일이다.
결과는 오랫동안 맛보지 못했던 새로운 세계로 입장한 듯한 착각을 일으키게 해주었다.

즐거운 여정을 마치고, 열심히 일했으니 스스로 충분한 휴식을 주고 싶다.
휴식을 떠나기 전에 해놓은 일을 정리하면서 새로운 일에 대해 구상한다.
늘 하고 싶던 일이 있었기 때문에 새로운 생각은 아니다.
다만, 다른 일에 우선순위가 밀려서 혹은 때가 일러서 접어두었던 일이다.

작년부터 올해에 걸쳐 세 사람에게 국내 유수 교육기관의 스프링 교육에 대한 힐난을 들었다.
작년에는 가장 가까운 지인 둘에게 들었다.
준비한 실습을 자신도 실행하지 못한 강사를 5일간 겪고 화가 치밀어 다른 교육에 대한 바우처를 받았다고 하고
다른 한 친구는 사실에 따라 비판하는 글을 블로그에 공개했다가 강사가 사정해서 글을 내렸다.

올해는 기획을 담당하는 고객에게 간접적으로 비난을 들었다.
작년에 역시 유명 교육기관에 의뢰해서 사내 직원 교육을 위탁했는데 결과가 매우 좋지 않아서
교육을 요청하려고 프로젝트 중인 나를 찾아오셨다.
거듭 '실습 위주' 교육을 해달라고 한다.

또한, 스프링을 기반으로 한 전자정부 프레임워크를 사용하는 프로젝트가 꽤 많다고 들었다.
유명 교육기관의 스프링 교육도 한심한 수준인데 전자정부 프레임워크 교육은 어떨까?

먼 길을 찾아오신 고객을 위해 휴가를 마치고 열심히 교육을 준비하면서
스프링 도입을 기화로 국내 개발문화의 질적 향상이 일어날 수 있는 시대 상황에 걸맞은
교육훈련 방법과 교육과정 공급 방안을 고민해봐야겠다.

ThoughtWorks의 버전 관리 툴에 대한 조사

영회 — Tue, 09 Mar 2010 09:41:45 +0900

조사 결과에 관심이 가는 이유는 선호하는 제품과 꺼리는 제품 사이의 큰 차이다.

그래프가 아니라 수치로 보면 또 다른 느낌이 든다.

Tool	Best	OK	Problematic	Dangerous	No Opinion	Active Responses	Approval %
Subversion	20	72	6	1	0	99	93%
git	65	19	1	0	14	85	99%
Mercurial	33	27	2	0	36	62	97%
ClearCase	0	3	14	41	41	58	5%
TFS	0	0	32	22	44	54	0%
CVS	0	14	59	11	15	84	17%
Bazaar	1	13	3	0	80	17	82%
Perforce	1	26	16	1	54	44	61%
VSS	1	1	11	64	22	77	3%

이 수치를 보면 몇 가지 화두를 꺼낼 수 있다. 상투적이지만 오픈소스의 위력을 떠올려볼 수도 있다. 하지만, 거의 꼴찌에 놓인 ClearCase에 관심이 간다. 국내 현장에서 널리 쓰이는 상용 제품이기에 그렇다. ClearCase를 쓰는 고객과 무슨 이야기를 할 수 있을까 생각해봤지만, 안타깝게도 공감대가 형성되기 어려울 듯하다. 고객이 소스 코드 버전 관리에 대해 실제적인 경험이 적어 이해하는 부분이 적다고 치부할 수도 있지만, 반대로 아직 내가 버전 관리 도구(와 프로세스)의 개선이 줄 수 있는 파급력을 설명할 능력이 없다고 하는 편이 좋겠다.

물론, 개발자 메일링 조사이니 공신력에 의문을 품을 수도 있고, 외국 현실(I conducted the survey from February 23 2010 until March 3 2010 on the ThoughtWorks software development mailing list)이니 국내 현실과 차이는 있다.

출처: VcsSurvey

규모 가변성(Scalability)에 대한 감상

영회 — Tue, 23 Feb 2010 08:30:00 +0900

학부 때 소프트웨어 공학 과목 시험에서 Scalability에 대해 논하라는 문제가 나왔다. '확장성'으로 풀어야 하나 '규모 신장성'으로 풀어야 하나 고민했던 기억이 난다. 결국, 답으로 무얼 적었는지는 모르겠다.

지금 생각해보면 결국 투자 대비 수익(Return on Investment)이라 정리할 수 있다. 하드웨어든 가상화나 그리드 솔루션이든 돈을 들이는 만큼 더 많은 고객을 포용할 수 있어야 한다. 그러나 소프트웨어 산업 초창기인 터라 실제 구현해내는 일은 그리 만만치가 않다. InfoQ 등을 보면 선형적 규모 가변성(Linear Scalability)을 이야기하지만, 국내 현장에선 남의 나라 이야기다. 민감한 시스템 구축 프로젝트에서 이를 언급했다가는 5년 전 일이 데자뷔로 다가오지 않을까. 2005년 대규모 프로젝트에서 스프링(Spring Framework) 도입할 때, '멋 모르는 신출내기' 취급을 받았던 때가 떠오를 듯하다.

바쁜 와중에 갑자기 Scalability에 대해 이야기하는 이유는 얼마 전 스프링로드가 자랑스레 트윗했던 뉴스를 읽었기 때문이다. 영국 최대의 언론사에서 하드웨어 추가에 따른 웹 로직 도입 비용에 부담을 느껴 오픈소스로 눈을 돌린 모양이다. 그러다가 긴급 지원이 가능한 tc 서버로 눈을 돌렸고, 스프링로드의 레퍼런스가 만들어졌다. 구글이 형광등처럼 하드디스크를 소모품으로 여기듯이 하드웨어는 단순 소모품으로 전락할 가능성이 크다. U(Ubi~)라는 키워드가 곳곳에서 쓰이는 현실을 고려하면 점점 하드웨어를 묶어 사용하는 가상화 환경은 기본으로 자리 잡을 가능성이 크다. 이미 포탈에서는 관계형 데이터베이스의 한계를 이야기하고 있고, 서비스를 수행하는 기업은 하드웨어 가용성에 대한 고민을 위탁할 가능성이 매우 크다.

결국은 클라우드가 순식간에 피부에 와 닿을 날이 떡국 몇 그릇 먹기 전에 올 듯하다. 최근에 IDC를 완공한 SI 업체가 측은하게 느껴지는 것은 지나친 걱정일까?

창조적 괴짜가 세상을 움직인다 (하)

영회 — Mon, 22 Feb 2010 08:30:00 +0900

* 기업 경영에 대한 필자의 조언

고객과 시간을 보내는 것이 관리의 핵심이다. 시스코 시스템스의 존 체임버스는 고객과 대화를 나누는 데 업무 시간의 80%를 할애하며, 모든 경영자들에게 고객들을 직접 만나는 데 최소한 업무 시간의 50%를 할애할 것을 요구한다. 이것이 아마도 고객 관계 관리(CRM)를 이해할 수 있는 가장 값싼 방법이 될 것이다.

창조적 괴짜가 세상을 움직인다 131쪽

전통적인 기업이 어떻게 생각하든 많은 소비자들은 다음과 같은 것들을 원한다.

실질적인 구매 결정을 내리기 전에 기업이 제시하는 상품을 '확인(checkout)'한다.
기업의 상품을 '컴포넌트화(componentize)'해서 조금씩 조각조각 구매한다.
적당하다고 생각되는 방법을 동원해서 이런 상품을 여러 번 '조합(combine)'한다.
상품을 자신들의 마음에 더 드는 것으로 '바꾼다(change)'
이런 상품을 '모방(copy)'해서 친구들과 공유한다.
상품에 대해 다른 사람들과 '의사소통(communicate)'한다.
이런 상품을 개인적인 개조물이나 재조합물과 '공동 브랜드(co-brand)'화한다.

창조적 괴짜가 세상을 움직인다 132쪽

당면 과제는 분해가 아니라 재구성의 원칙에 입각해서 조직 구조를 설계하는 것이다.

창조적 괴짜가 세상을 움직인다 164, 165쪽

계급 조직은 잊어라. 레고 모델이 효력을 발휘한다.

창조적 괴짜가 세상을 움직인다 167쪽

창조는 음침한 곳에서 울려 나오는 하나의 목소리가 아니라 의견 공유와 발견의 과정인 대화에서 비롯된다. 단기 처방을 내리는 대신 꾸준히 노력하며 다양한 방법을 시도해 봐야 한다. 실험은 상상력만큼 끈기도 요구한다.

창조적 괴짜가 세상을 움직인다 171쪽

조직은 직원을 소유한 것이 아니며, 소유할 수도 없고, 소유해서도 안 된다. 직원들은 언제 어느 때건 일어나서 사무실 밖으로 걸어 나갈 자유가 있다.

창조적 괴짜가 세상을 움직인다 174쪽

모든 직원이 자신만의 강점을 기를 수 있는 비옥한 토양을 조성해 주는 것은 혁신 주식회사 곳곳에 존재하는 리더가 책임져야 할 문제이다. 위대한 리더는 차이를 자본화한다.

창조적 괴짜가 세상을 움직인다 181쪽

생산성이 조직의 생존을 도와주듯, 교란성은 조직의 번영을 도와준다. <중략> 혁신에 대한 중요한 전망을 얻으려면 기업들은 다음가 같은 두 가지를 갖춰야 한다.

전략적 의사 결정 과정에 일탈자들을 포함하고 참가시켜야 한다.
힘의 분산을 관리해야 한다. 능력이 있는 곳을 중심으로 의사 결정이 이뤄지도록 해야 한다.

창조적 괴짜가 세상을 움직인다 185쪽

상황 파악에서 솔루션 마련, 실행까지 걸리는 시간이 단축되어야 한다. <중략> 예상 능력을 높이기 위해 기업들은 조기 경보 시스템을 발동해야 한다. <중략> 좀 더 분산적이고 비계층적인 접근 방법이 필요하다. <중략> 칼 웨이크 교수가 말하길, 소방서나 핵 발전소 등 고신뢰 조직(HRO)의 경영자들은 최전방에 관심의 초점을 맞춘다. HRO들은 또한 전문가의 의견을 존중하고, 현실을 단순화하려 하지 않는다. <중략> 한 가지 위대한 아이디어를 얻기 위해서는 수천 직원들의 생각과 꿈을 소유해야 한다.

창조적 괴짜가 세상을 움직인다 189, 191쪽

애플의 스티브 잡스는 이렇게 말한다. "똑똑한 사람들을 고용해서 그들에게 무엇을 하라고 말하는 것은 말이 안 된다. 우리가 똑똑한 사람들을 고용한 이유는 그들에게 무엇을 해야 할지 듣기 위해서이다." <중략> 창의적인 기업들은 다음의 세 가지가 필요하다.

공통된 생각
명확한 아이덴티티
행동 방식을 형성하는 동기

창조적 괴짜가 세상을 움직인다 192, 193쪽

성공적인 리더는 종종 설득력 있는 단순성으로 자신들의 일을 보여 준다. 간결함이 생명이다. <중략> '새로운 프로틴 경력 계약(the New Proteam Career Contract)'의 저자들은 이렇게 말한다. "기업은 직원들의 경력을 관리하는 대신, 그들이 아이덴티티와 적응 능력을 발전시켜서 자신의 경력을 스스로 지배할 수 있도록 기회를 제공할 것이다."

창조적 괴짜가 세상을 움직인다 196쪽

기업은 유지가 아닌 공유에 보상을 해 줘야 하며, 지식 활용뿐 아니라 지식 창조에도 보상을 해줘야 한다.

창조적 괴짜가 세상을 움직인다 200쪽

조직은 다음과 같은 세 가지 구성 요소로 이루어진 프로세스상의 플랫폼을 마련해야 한다.

조직적인 메모리
공통의 언어
정교한 의사소통 채널

<중략> 혁신적인 기업은 많든 적든 모든 직원이 사람, 지식, 방법, 장소를 알 수 있는 일터를 설계해야 한다. 즉 전체가 모든 부분에 반영되는 입체적인 조직을 건설해야 한다.

창조적 괴짜가 세상을 움직인다 202, 203쪽

기업은 잊는 법을 배워야 한다. 기업은 발전을 위해 지워야 하며, 건설을 위해 파괴해야 한다.

창조적 괴짜가 세상을 움직인다 205쪽

기업은 다음을 개발해야 한다.

일상 속의 실험화
실패에 대한 관용
신뢰의 풍토

창조적 괴짜가 세상을 움직인다 212쪽

혁신을 완수하려면 기업은 실수 '제로'를 강조하는 풍토에서 새로운 실수를 강조하는 풍토로 변해야 한다.

창조적 괴짜가 세상을 움직인다 215쪽

톰 스튜어트가 말하듯, 아마도 기업에는 사명서(mission statement) 외에 허가서(permission statement)도 필요하다. 실패는 발생하게 마련이다. 아마존의 제프 베조스는 이렇게 덧붙인다. "치료, 다시 말해 직원들에게 항상 허가를 구하게 하는 치료는 질병보다 더 나쁘다." <중략> 리처드 파슨과 랠프 키즈는 실패에 관용적인 리더(FTL, failure-tolerant leader)들은 자신들과 다른 사람들을 구분 짓는 장벽을 부수고 직원들과 개인적 차원에서 같이 일한다고 말한다. 그들은 칭찬이나 비난을 하는 대시 분석한다. <중략> 오늘날 대다수의 조직은 신뢰의 사원이 아니라 두려움의 공장이다.

창조적 괴짜가 세상을 움직인다 216, 217쪽

새로운 경제 환경에서 수직적 통합 기업은 즉시 부적합한 기업으로 전락해 버린다.

창조적 괴짜가 세상을 움직인다 243쪽

모델의 구성
공급 사슬(supply chain)을 통제하는 대신 수요 사슬(demand chain)을 설계한다. <중략> 다음과 같은 네 가지 중요한 질문에 대해 창의적인 해답을 생각해 낼 수 있어야 한다.

어떤 고객을 위해 어떤 일을 하기를 원하는가?
자기 힘으로 해낼 수 있는 세계 일류의 행동은 무엇인가?
세계 일류의 파트너들이 우리보다 잘하는 것은 무언인가?
어디에 어떤 성장 잠재력이 존재하는가?

창조적 괴짜가 세상을 움직인다 244, 245쪽

급변하는 컴퓨터 산업에서 재고는 생선과 유사성이 많다. 곧 가치 손실이 빠르게 발생한다. <중략> 선택할 수 있는 옵션의 수를 제한하기에 고객 맞춤(customization)의 영업 방식을 잘 관리할 수 있다. <중략> 우위 사이클의 끝이 새로운 우위 사이클의 시작과 연결되는 나선형의 전략을 창조해야 한다. <중략> 독점성이 대체로 모델의 효과와 내구성에 관련되어 있다. <중략> 실행성은 꼭 필요한 전략을 조직의 적재적소에 배치하는 것을 의미한다. <중략> 탄력성은 시간과 공간, 규모에 대한 모델의 가변성과 적응성에 대한 것이다. <중략> 슈퍼모델의 리더는 변화시키지 말아야 할 것을 결정한 다음 그 외에는 어느 것이든 자유롭게 바꾼다.

창조적 괴짜가 세상을 움직인다 249, 253, 258, 260쪽

기업 내부의 영구 컬렉션인 역사적 자원과 활동을 보호하는 대신, 특정한 성격의 가치 제시가 주어질 경우 누구인지 어디서 일하는지에 상관없이 최고의 참가자들을 끌어모으는 역할을 맡는다. <중략> 무가치란 투명성 향상으로 드러난 부가 가치가 없는 활동을 의미한다. <중략> 표준화된 상호 작용이 필요하다.

창조적 괴짜가 세상을 움직인다 254~256쪽

이지젯은 먼저 구매하는 사람들에게 싼 가격을 제공한 다음, 조금씩 가격을 올린다.

창조적 괴짜가 세상을 움직인다 259쪽

영역에서 성장은 새로운 유형의 고객에게 문을 열고 <중략> 응용성에서의 성장은 콘텐츠와 관련이 있다.

창조적 괴짜가 세상을 움직인다 261쪽

접속을 활용한다는 것은 새로운 마케팅 채널이 추가됨을 의미한다.

창조적 괴짜가 세상을 움직인다 263쪽

너의 똑똑함과 아름다움을 과시하기 위해 깃털을 내보이지 말지어다. <중략> 위대한 리더는 자신감과 자의식의 균형을 유지하면서 결실을 일궈야 한다.
눈을 가린 채 황무지로 걸어가지 말지어다. 너는 물론이고 다른 사람들도 눈을 떠야 한다.
성공적인 리더에게 돈은 올바른 행동에서 생기는 부산물이다.
가치관을 중시하며 매일 순수하고 명료하게 가치관대로 살아갈 지어다. <중략> CEO의 역할은 기업의 문화와 가치관을 유지한는 것이다. <중략> 문화는 위에서부터 온다.
모두를 사랑할지어다. 그러면 모두가 너를 사랑할 것이다. <중략> 경영자나 그의 보좌관들은 여러 부서를 도는 흥미로운 과정을 여러 부서를 도는 흥미로운 과정을 겉치레적인 것으로 현실시켜 버리죠. <중략> 리처드 브랜슨 경은 버진의 직원들 모두에게 자신의 개인 전화번호를 알려 주었으면, 문제가 있거나 아이디어가 생각날 경우 언제든 전화하라고 말한다.
다양한 직급의 경영자들도 고객들과 대화의 장을 마련해야 한다. 다양한 직급의 경영자들도 고객들과 대화의 장을 마련했다.
관료주의 규정서는 집어던질것이다.
자화자찬하지 말지어다. <중략> 랜들 토비아스는 한 해 동안의 실패에 대한 보상 제도를 도입해서

창조적 괴짜가 세상을 움직인다 306~314쪽

창조적 괴짜가 세상을 움직인다 -
요나스 리더스트럴러.첼 노오스트롬 지음, 조성숙 옮김/황금가지

창조적 괴짜가 세상을 움직인다 (상)

영회 — Fri, 19 Feb 2010 08:30:00 +0900

k16wire님 추천에 의해 읽은 책이다. 인상에 남는 구절을 짧은 감상과 함께 메모.

좋아하는 오렌지색을 넣은 편집도 그렇지만, 시종일관 신선한 내용과 흥미로운 전개가 돋보이는 책이다. 300쪽을 넘어가 슬슬 지루할 즈음에 이어지는 마지막은 정말이지 임팩트 있는 만점 마무리다.

성공하려면 다른 사람들을 보는 것부터 멈춰야 한다. 우리의 경쟁 상대는 우리 자신이다. 모방은 어떤 것도 이뤄주지 못한다. 자신의 내부를 들여다보라. <중략> 당신의 영혼을 통과해야 하며 당신의 가치관을 거쳐야 한다는 사실이다.

창조적 괴짜가 세상을 움직인다 344쪽

성공의 가장 흥미롭고 중요한 측면은 그것이 우리에게 사회에 대해 그리고 미래에 대해 알려 준다는 점이다.

창조적 괴짜가 세상을 움직인다 320쪽

타인을 모방하는 데에서 이류가 되기 보다는 자신을 나타내는 데에서 일류가 되는 것이 언제나 더 낫다.

형제자매여, 동화되지 마라. 무시하라. 그러지 않으면 사라진다. 모방을 인정하지 마라. 한계를 인정하지 마라. 당신이 이곳에 있는 데에는 이유가 있다. 당신은 힘과 권리를 지니고 있다. 이것이 당신의 삶이다. 당신이 결정한다. 자신의 권리를 대변하라. 당신이 지배권을 쥘 수 있다.

창조적 괴짜가 세상을 움직인다 345쪽

읽으면서 온통 밑줄을 그었고, 곁에 두고 가끔 참고해야 할만한 책이란 생각이 드는 책이다. ^[각주:1]

* 변화에 대처하는 자세에 대한 필자의 견해 메모

우리가 경험하는 변화에 대해, 그리고 어떤 종류의 미래를 만들고 싶은지에 대해 자신만의 의견을 가져야 한다.

창조적 괴짜가 세상을 움직인다 7쪽

사람과 기업과 국가는 불확실성을 줄이고 원본을 모방하기 위해 노력할 수도 있지만, 다른 한편 불확실성을 포용해서 미래의 걸작을 창조할 수도 있다.

창조적 괴짜가 세상을 움직인다 29쪽

항상 그래 왔듯이 변화를 추진하는 것은 기술, 제도, 가치, 다시 말해 도구와 규칙, 규범이라는 세 가지 힘이다. 좋든 싫든 우리가 이런 변화의 힘을 형성하지 못하면 그들이 우리를 형성한다.

창조적 괴짜가 세상을 움직인다 35쪽

프랑스의 비즈니스 스쿨 인시아드(INSEAD)의 폴 에반스는 사람들은 변화를 싫어하는 것이 아니라 변화당하는 것을 싫어한다고 말했다.

창조적 괴짜가 세상을 움직인다 64쪽

힘은 규칙을 준수하는 자(rule-taker)에서 규칙을 깨뜨리는 자(rule-breaker)와 규칙을 창조하는 자(rule-maker)에게로 옮겨지고 있다.

창조적 괴짜가 세상을 움직인다 65쪽

변화를 관리할 수는 없다. 단지 변화에 앞서 갈 뿐이다. <중략> 앤디 워홀은 말했다. "내 그림이 예상했던 대로 그려지는 적은 한 번도 없다. 그러나 나는 결코 놀라지 않는다."

창조적 괴짜가 세상을 움직인다 168, 169쪽

* 현대 사회의 지식/기술을 이해하는 틀에 대한 필자의 인식 메모

정보의 민주화를 힘의 민주화와 착각하지 마라. 정보는 그 정보를 이해할 능력이 있을 때에만 진정한 가치를 지닌다. 힘은 정보를 통제하는 사람들에서 지식을 통제하는 사람들에게로 옮아간다.

창조적 괴짜가 세상을 움직인다 33쪽

무엇보다 기술에 대한 비난을 멈춰야 한다. 기술은 결정을 내리지 않는다. 결정은 인간이 내린다.

창조적 괴짜가 세상을 움직인다 40쪽

새로운 것을 창조하려면 종종 기존의 것을 새로운 방식으로 결합해야 한다. 즉 하이픈으로 연결해야 한다. <중략> '애드버게임스(Advergames)'는 햄버거 식당에서 세트 메뉴를 판매하듯, 광고와 게임을 결합한다.

창조적 괴짜가 세상을 움직인다 159쪽

스토리(또는 내러티브)는 우리가 사물을 기억하는 방식이다. 스토리는 정보를 감정으로 바꾼다.

창조적 괴짜가 세상을 움직인다 175쪽

"기술은 당신의 어리석음을 덜어 주지 않는다. 어리석어지는 속도를 더 빨라지게 만들 뿐이다." - 손턴 A. 메이

창조적 괴짜가 세상을 움직인다 228쪽

CEO(Chief Emotional Officer, 감성 경영자) <중략> 알베르토 알레사는 자신의 기업은 제조 업체가 아니라 창의성과 인간의 심금을 울리는 현실 세계 사이의 중재자

창조적 괴짜가 세상을 움직인다 271쪽

다윈이 옳았다. 성공하려면 강한 동시에 섹시해야 한다. 본질과 형식을 결함하고 가능성과 패션을 결합해야 한다. 강함은 적응의 문제이다. <중략> 섹시함은 매력에 대한 것이며, 감성적으로 연결하는 것이다.

창조적 괴짜가 세상을 움직인다 297쪽

* 정치/근대사에 대한 필자 인식 메모

20세기에 논쟁의 초점은 대량 생산으로 생겨난 부의 재분배였다.

창조적 괴짜가 세상을 움직인다 40쪽

독재자들은 항상 정보의 원천을 통제할 방법을 모색한다.

창조적 괴짜가 세상을 움직인다 44쪽

평등은 종종 특성을 희생시켰다. <중략> 국제 연합이 아니라 개인 연합(United Individuals)과 부족 연합(United Tribes)을 창조하는 방법을 알아야 한다.

창조적 괴짜가 세상을 움직인다 335, 336쪽

* 현대 사회의 트윈 픽스(Twin Peaks)

우리는 조직으로 가득 찬 사회에 있지만, 여전히 공동체에 굶주려 있다.

창조적 괴짜가 세상을 움직인다 60쪽

워싱턴 D.C.의 유아 사망률은 1,000명당 16.2명이며, 이것은 스리랑카와 같은 수치이다. 유럽의 유아 사망률은 9.4명이다. 미국의 수도에서 저체중으로 태어나는 아기의 수는 잠비아와 맞먹거나 심지어 웃돌기도 한다.

창조적 괴짜가 세상을 움직인다 83쪽

수십만 명의 사람들이 경제적 불평등과 정치 부패, 전쟁으로 인한 식량 부족에 시달리는 반면에, 수십만 명의 사람들은 과체중으로 식단과 관련된 위험할 정도의 만성 질환에 시달리고 있다.

창조적 괴짜가 세상을 움직인다 85쪽

부자들을 위한 보호 구역과 가난한 사람들을 봉해 놓는 장소가 공존한다.

창조적 괴짜가 세상을 움직인다 86쪽

이런 트윈 픽스(Twin Peaks) 세상은 서구 사회에서 가장 빠르게 성장하는 사업인 보안 회사들에게 천국이나 다름없다. 격차가 벌어질수록 보호도 더 많이 필요하다.

창조적 괴짜가 세상을 움직인다 87쪽

* 시장/경제에 대한 필자 인식 메모

영국의 경영 철학자인 찰스 핸디는 시장은 능률적인 사람과 비능률적인 사람은 구분 짓는 메커니즘에 불과하다고 말했다. 시장은 책임을 대신해 주지는 않는다.

창조적 괴짜가 세상을 움직인다 56쪽

과거에 충성은 저절로 주어지는 것이었다. 하지만 이제 개인의 삶에서든 비즈니스에서든 충성은 획득해야 하는 것이 되었다.

창조적 괴짜가 세상을 움직인다 60쪽

인격이 없는 자본주의는 위험하다. <중략> 자본주의 시장 구조는 단지 무언가의 가격을 결정하는 방법에 불과하다.

창조적 괴짜가 세상을 움직인다 331, 332쪽

* 일반적인 지혜

활용은 필연적으로 남용을 낳는다.

창조적 괴짜가 세상을 움직인다 41쪽

리처드 파스칼은 자연에서 생존은 돌연변이와 변종이 충분히 존재하느냐에 달려 있다고 말한다.

창조적 괴짜가 세상을 움직인다 185쪽

사람들이 언어적 합의가 아니라 언어적 충돌에 의해 더 잘 결속됨을 알 수 있다.

창조적 괴짜가 세상을 움직인다 206쪽

광기에 대한 아인슈타인의 정의를 생각해 보라. "똑같은 일을 계속 반복하면서 다른 결과가 나오기를 바라는 것이 바로 광기이다." <중략> 혁신은 완벽이 아니라 끈기를 요구한다. "내가 영리해서가 아니라, 남들보다 더 오래 문제에 집작했기 때문이다."라고 한 아인슈타인

창조적 괴짜가 세상을 움직인다 212, 213쪽

혁신은 대부분 한 번의 빅뱅이 아니라 마일리지와 같다. <중략> 라이너스 폴링이 지적하듯 "훌륭한 아이디어를 많이 가질 수 있는 가장 좋은 방법은 무수한 아이디어를 취한 뒤 나쁜 아이디어를 버리는 것이다."

창조적 괴짜가 세상을 움직인다 216쪽

창조적 괴짜가 세상을 움직인다 -
요나스 리더스트럴러.첼 노오스트롬 지음, 조성숙 옮김/황금가지

고백하자면 다른 책을 읽으면서도 그런 생각을 했지만, 곁에 두어봐야 다시 보는 일은 별로 없었다. [본문으로]

EJB 3.1 에서 흥미로운 부분

영회 — Thu, 18 Feb 2010 08:30:00 +0900

InfoQ 기사 Java EE6: EJB3.1 Is a Compelling Evolution 를 읽고 인상에 남는 내용 메모

EJB 3.1은 JSR 318로 최근 발표한 Java EE 6 에 포함되어 있다. Josh Long 은 EJB의 새로운 특징(features)으로 Singletons와 The EJB Timer, No-Interface Views, Asynchronous Services, Simplified Deployment 등을 들었다. EJB 2.x 사용자라면 생소하겠고, EJB 3.0 사용자라면 편하게 느낄 테지만, 사실 스프링(Spring Framework) 사용자에겐 전혀 새로운 내용이 아니다. 그럼에도 불구하고 No-Interface Views와 Asynchronous Services 등은 눈에 띈다.

No-Interface Views는 일종의 암묵적 인터페이스 지원이다. 스프링은 애초부터 인터페이스를 강제하지는 않았기 때문에 예전부터 지원하던 기능이다. 파일 숫자를 줄일 수 있어서 복잡도를 낮출 수는 있지만, 인터페이스 기반 프로그래밍(Programming to Interfaces)의 이점과 더불어 일관성 저하를 낳아 큰 매력은 없다.

스프링에서도 3.0부터 지원하는 Asynchronous Services는 쓰임새를 잘 찾아내면 매우 요긴할 듯하다. 내부 메커니즘이야 구현 제품에 따라 다르겠지만, 스프링과 차이는 애노테이션이다. 스프링은 @Async 이고, EJB 3.1은 @Asynchronous이다. 스프링에서도 @Asynchronous 사용이 가능하다.

스프링의 발전이 "J2EE development without EJB" 였다면 프로그래밍 모델로서의 EJB 발전 방향은 "POJO-driven Java EE development without Spring and Hibernate"에 맞추는 듯하여 격세지감을 느낄 수 있다. EJB 3.1에 대한 보다 상세한 기사는 이미 TSS에서 다섯 편으로 연재한 바 있다.

Google App Engine for Java 와 스프링(Spring Portfolio) 호환성

영회 — Wed, 17 Feb 2010 08:30:00 +0900

Will it play in App Engine에서 확인 가능. 스프링뿐 아니라 Java Enterprise Edition (Java EE) Technologies와JVM-based Languages, Miscellaneous Java™ Libraries and Frameworks의 세 개 분류로 자바 기술 스택의 주요 구성 요소와의 호환성을 확인할 수 있다.

Spring MVC
Version: 2.5.6
Status: COMPATIBLE

To see Spring's MVC framework running on App Engine, check out the autoshoppe sample application.
If you're using Spring forms (e.g. using the spring-form.tld tag library and subclassing SimpleFormController), you will need to register custom editors for your properties. This is covered in http://groups.google.com/group/google-appengine-java/browse_thread/thread/d93fd7385bf85bf7.

Spring ORM
Version: 2.5.6
Status: COMPATIBLE

To get Spring working with the App Engine-provided JPA interface, follow the instructions at http://objectuser.wordpress.com/2009/05/19/spring-jpa-in-google-app-engine/, which discusses a workaround to the dependency on javax.naming needed for @PersistenceContext. A more complex workaround is available at http://groups.google.com/group/google-appengine-java/browse_thread/thread/187d41712ec1d394.

Spring Security
Version(s): ?
Status: SEMI-COMPATIBLE

To work around a ClassNotFoundException, you can use a re-compiled version of the library which adds a StringInsensitiveComparator class -- the download is provided at http://www.google-app-engine.com/blog/post/Spring-security-fix-for-google-app-engine.aspx.
See http://www.dotnetguru2.org/bmarchesson/index.php?p=1100 for tips on how to get Spring Security running with App Engine and GWT (in French).
See http://groups.google.com/group/google-appengine-java/browse_thread/thread/964e7f5e42840d9c for discussion on the integration.

Grails
Version: 1.1.1
Status: SEMI-COMPATIBLE

A plugin has been made available which integrates the App Engine SDK with Grails, adding features to upload Grails application automatically and run the local dev server. To download this plugin or see a screencast and tutorial, see http://grails.org/plugin/app-engine.
As of now, you have to use the "grails app-engine run" command rather than "grails run-app", which blocks other plugins that extend run-app including the GWT plugin. More incompatibilities noted in this thread.

첫 번째 GWT over GAE/J 애플리케이션 코드 감상

영회 — Tue, 16 Feb 2010 08:30:00 +0900

GUI 기반 프로그래밍 전형이다. SDK가 제공하는 인터페이스 구현(implements)를 통해 이벤트 핸들러를 정의한다.

        class MyHandler implements ClickHandler, KeyUpHandler {
            /**
            * Fired when the user clicks on the sendButton.
            */
            public void onClick(ClickEvent event) {
                sendNameToServer();
            }

            /**
            * Fired when the user types in the nameField.
            */
            public void onKeyUp(KeyUpEvent event) {
                if (event.getNativeKeyCode() == KeyCodes.KEY_ENTER) {
                    sendNameToServer();
                }
            }

실제 비즈니스 로직은 모아 두었다.(sendNameToServer() 메소드)

            private void sendNameToServer() {

               <중략>

                greetingService.greetServer(textToServer,
                        new AsyncCallback<String>() {
                            public void onFailure(Throwable caught) {
               <중략>
                            }

                            public void onSuccess(String result) {
               <중략>
                            }
                        });

GAE/J 가 원격 통신을 추상화시켜주겠지. 직관적인 콜백 메소드 이름(onFailure, on Success)탓에 쉽게 코드를 이해할 수 있다.

다른 GUI 프로그래밍과 다른 부분은 아래 코드다.

        RootPanel.get("nameFieldContainer").add(nameField);
        RootPanel.get("sendButtonContainer").add(sendButton);
        RootPanel.get("errorLabelContainer").add(errorLabel);

RootPanel 클래스의 add() 메소드로 HTML의 특정 영역을 지정하고, GWT 컴포넌트를 삽입한다. HTML 영역지정 코드는 다음과 같다.

이번에는 GAE/J Eclipse 개발환경의 특징이다. SDK로 서버가 배포되는 점에서 GAE/J의 포지션을 알 수 있는 부분이지만, 편리해서 마음에 든다.

The development server is part of the SDK. You can‘t use your own development server for App Engine debugging and testing. The App Engine JRE differs from other implementations.

얏호! 수 초의 작업 후에 배포에 성공했다.

http://ahnyounghoe.appspot.com/

JsDoc 삽질기 ... @return 주석 유의

영회 — Fri, 12 Feb 2010 12:30:00 +0900

마이플랫폼 스크립트도 자바스크립트와 거의 같은 문법을 사용하므로 JsDoc 적용 가능.

D:\jsdoc>perl.exe jsdoc.pl lib
Loading sources from lib/bad.js
Loading sources from lib/irucl001.js
Loading sources from lib/iruco001.js
Loading sources from lib/iruco002.js
Loading sources from lib/iruco003.js
Loading sources from lib/irumn001.js
Loading sources from lib/irumn002.js
Loading sources from lib/irumnSSO.js
Function 'iruFormOnKeyDown' already declared
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in string eq at jsdoc.pl line 1490.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
HTML::Template->output() : fatal error in loop output : HTML::Template::param()
: attempt to set parameter 'method_returns' with an array ref - parameter is not
a TMPL_LOOP! at C:/Perl/lib/HTML/Template.pm line 3068
at jsdoc.pl line 179

문제가 있는 파일을 고르기 위해 개별 실행한다.

D:\jsdoc>perl.exe jsdoc.pl lib/iruco001.js
Loading sources from lib/iruco001.js
Use of uninitialized value $name in string eq at jsdoc.pl line 1490.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
HTML::Template->output() : fatal error in loop output : HTML::Template::param()
: attempt to set parameter 'method_returns' with an array ref - parameter is not
a TMPL_LOOP! at C:/Perl/lib/HTML/Template.pm line 3068
at jsdoc.pl line 179

D:\jsdoc>perl.exe jsdoc.pl lib/irumn001.js
Loading sources from lib/irumn001.js
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
Use of uninitialized value $name in hash element at jsdoc.pl line 1512.
HTML::Template->output() : fatal error in loop output : HTML::Template::param()
: attempt to set parameter 'method_returns' with an array ref - parameter is not
a TMPL_LOOP! at C:/Perl/lib/HTML/Template.pm line 3068
at jsdoc.pl line 179

로그만으로 알기 어려워 Perl 문법도 모르지만 일단 jsdoc.pl 파일을 열어 봤으나 코드만 보아선 알 수 없다. printf 명령을 넣어서 해시의 키라도 출력해보려고 했으나 암호(?)가 나온다. 구글 검색에 무언가 있는 듯하더니 페이지로 가보면 사라졌다. JsDoc 메일링 리스트 검색해도 답이 없다.

로그 문장을 보고 return 관련해서 의심스러운 코드를 bad.js로 저장해서 테스트해보니 같은 오류가 난다.

/**
* MainFrame이 Active될때 발생되는 Event
* @param obj - global
* @return
*/
function _OnAcivate(obj)
{
}

@return 뒤에 공백 문자 이외의 문자가 있거나 @return 구문을 아예 없애버리면 오류가 나지 않는다.

/**
* @param obj - global
* @return N/A
*/
function _OnAcivate(obj)

/**
* @param obj - global
*/
function _OnAcivate(obj)

한참 삽질을 했기에 기록을 남겨둠

소프트웨어 아키텍트의 일에 대한 메모 (하)

영회 — Fri, 12 Feb 2010 08:30:00 +0900

InfoQ 글(Are You a Software Architect?)에 메모를 추가함

이젠 앞서 정의한 아키텍처를 제대로 구현해내는 일(Delivery of the software architecture)이다.

Ownership of the bigger picture
아키텍트의 책임감을 요구하는 부분이다. 임무 완수(through to a successful conclusion)를 위해선 영업사원 마냥 개발팀 여러 구성원에게 아키텍처를 이해시키고 동조를 얻어야 한다.(sells the vision throughout the entirety of the software development lifecycle) 단기 프로젝트가 아니라면 개발 과정에서 얻어진 새로운 정보(혹은 요구사항)에 의해 변경도 필요하다.(evolving it throughout the project if necessary)

If you've defined an architecture, it makes sense to remain continuallyengaged and evolve your architecture rather than choosing to hand itoff to an "implementation team"

위 글은 두 가지 관점에서 볼 수 있다. 하나는 아키텍트의 책임감 측면이다. '아키텍트'라는 사람이 구현기술에 대한 상세한 내용은 내 일이 아니라며 미루는 모습을 자주 볼 수 있다. 물론, 본인 스스로 모든 것을 해결할 수도 없고, 그럴 필요도 없다. 하지만, 적어도 '아키텍트'가 아키텍처 이슈(시스템 전반에 영향을 미치는 사항)를 개발팀에 떠넘기는 것은 문제가 있다. 또 다른 측면은 '아키텍트'의 높은 몸값 때문에 프로젝트 초반에만 고용하는 점이다. 만일 아키텍트가 철수한다면 어떻게 아키텍처를 지켜나갈지 방책을 마련해둬야 한다.

Leadership
아키텍처는 역할에 의해 권위를 갖지만 기술적 결정과 가이드(providing technical guidance, making technical decisions) 책임 역시 갖는다. 아키텍트의 권위는 당연한 이야기처럼 들리지만 실제로 충부한 권위를 갖지 못하는 경우가 많다.(The software architect position is inherently about leadership and while this sounds obvious, many project teams don't get the technical leadership that they need ...)

Coaching and mentoring
국내 현실에서는 아키텍처 구현을 위한 가이드를 하다 보면 자바 문법이나 디버깅 방법까지 묻는 경우가 발생하고, 새로운 기술에 대한 거부감/저항/두려움을 갖은 인력을 만나는 일이 잦다. 게다가 설계 결정까지 개발자에게 넘겨서 난감한 구현을 만들어내는 일이 흔하다. 개발인력을 일시적인 노동력으로만 보는 현상과 지나치게 개발 절차 자체를 강조하는 경우, 코드가 아닌 문서 형태의 중간 산출물로 진척을 확인하는 현상과 관계가 있는 듯하다.

Quality assurance
품질보증(QA)을 위해서 보통 '표준화'라는 추상적인 이름으로 코딩 표준이나 설계 원칙(coding standards, design principles)에 대한 리뷰가 필요히다. 리뷰는 시간과 노력이 많이 필요한 작업으로 CI 도구나 테스트 지원 도구(continuous integration, automated unit testing and code coverage tools)의 지원이 필요하다. 개발자 테스트 없는 CI 도구를 이용한 자동화 빌드만으로도 아주 기본적인 통합은 보장할 수 있다. 최근에도 형상 불일치 문제로 오픈을 못한 사이트 소문을 듣곤 하는데 일부 개발자의 변화에 대한 초기 저항감만 누르면 쉽게 적용할 수 있다. 하지만, 자동화 테스트는 조금 다르다. 현실적인 기준선(baseline)으로 DAO에 대한 테스트에 초점을 맞추는데, 테스트 품질을 높이려면 다양한 현실적 사례(가령, 조회 요청에 대한 테스트라면 복잡한 조회 조건의 현실적인 경우의 수를 뽑아내 모두 테스트케이스로 수렴해야 함)를 테스트에 담아야 하는데 능동적으로 이를 이행하기란 아웃소싱이 기본인 SI 현실에서 불가능이라고 할 수 있다. 현실적 제약을 인정하면, '모 아니면 도'식 접근 대신 중요한 코드(architecturally significant, business critical, complex or highly visible) 테스트로 범위를 좁히는 것도 실용적인 접근이다.

국내 SI 프로젝트에서 자동화 테스트는 높은 ROI(투자 대비 수익)를 뽑을 수 있다고 생각한다. 일각에서는 이를 인지하고 실천하는 움직임이 보인다. 하지만, 여전히 대다수의 프로젝트에서 QA하면 절차(프로세스)에 대해서만 고민하고, 지나치게 문서에 매달리며 시간을 낭비한다. 소프트웨어도 제조물과 마찬가지로 제품에 대한 품질이 최우선이다.

Design, development and testing
Simon Brown와 내 생각은 거의 비슷하다. 그가 아키텍트의 몸값 탓("too valuable to undertake that commodity work")에 조직에서 코딩을 못하게 하는 점을 지적했는데, 외국이나 우리나 현실이 비슷한 모양이다. But generally speaking, an architect that codes is more effective and happier than an architect that watches from the sidelines. 라는 말에 동의하지만, 게다가(In addition)로 부연한 내용이 더 중요하게 생각된다.

아키텍트가 꼭 코딩을 할 필요는 없다고 생각하지만, 만일 코딩을 하지 않으면 실제로 개발자 입장(the architect can experience the same pain as everybody else on the team, which in turn helps them better understand how their architecture is viewed from a development perspective.)을 이해하지 못할 수도 있다. 최근에 고객 업무에 깊이 관여하면서 일치감을 느껴 신규 업무 설계와 화면을 만든 짜릿한 경험을 했는데, 개발자에 대해서도 마찬가지다. 유명한 국내 아키텍트 중에도 실제 구현 과정에서 겪는 어려움을 무시해서 모두를 어렵게 만드는 이에 대해 듣곤 한다.

개발자에게 아키텍트 역할에 대한 강연을 준비하던 글인 듯한데.. 마무리가 인상 깊다.

Most developers don't wake up on a Monday morning and declare themselves to be a software architect. I certainly didn't and my route into software architecture was very much an evolutionary process. Having said that though, there's a high probability that those same developers are already undertaking parts of the software architecture role, irrespective of their job title.

사이먼 말처럼 개발자이지만 이미 아키텍트의 역할을 (일부라도) 수행하는 이도 있다. 반대로 지겨운 개발(?)을 그만두기 위해 아키텍트를 꿈꾼다는 이해하기 어려운 사람도 어렵지 않게 만날 수 있다.

관련 글:

소프트웨어 아키텍트의 일에 대한 메모 (상)

영회 — Thu, 11 Feb 2010 08:30:00 +0900

InfoQ 에서 흥미로운 글을 올렸다.

Are You a Software Architect?

Software architecture is all about having a holistic view and seeing the bigger picture to understand how the software system works as a whole.

아키텍처는 시스템이 전체적으로 어찌 구동하는가를 이해하는 큰 그림에 대한 것이라는 일반적인 이야기를 해놓고, 이것만으로는 부족하다며 말을 잇는다.

그리고 바로 중요한 두 가지 사실을 꺼내 놓는다.

Becoming a software architect isn't something that simply happens overnight or with a promotion. It's a role, not a rank.

하나는 아키텍트는 경험이 필요하며 하루아침에 만들어지는 것이 아니라 서서히 키워지는 것이란 점(It's an evolutionary process where you'll gradually gain the experience and confidence that you need to undertake the role.)

두 번째는 아키텍트는 역할이지 등급이 아니란 점. 사실 이 말이 피부에 와 닿으려면 아키텍트보다 높은 대가를 받는 고급 개발자가 있어야 하지 않을까?

점차 심도 있는 이야기를 꺼내는데 아키텍트가 행해야 하는 다양한 행위(involvement, influence, leadership and responsibility)를 설명하기 위해 아키텍처를 정의하는 측면과 구현하는 측면으로 나눠(Broadly speaking, the software architecture on most projects can be broken down into two phases; the architecture is defined and then it's delivered.) 부연을 시도한다.

Definition of the software architecture

떡 하니 다섯 개 영역으로 나눈 그림을 제시한다. 그림을 보고 문득 이런 생각이 든다. 만일 암기에 의해서가 아니라 경험에 의해서 아키텍트로 프로젝트에 참여했을 때 해야 할 일이 아래 그림처럼 자명하게 떠오르고, 프로젝트 규모와 기간, 해당 시스템의 업무적 특성, 그리고 사용 조직의 특성 등을 고려해 각각 방법을 만들어낼 수 있다면 스스로 전문적인 아키텍트라 칭해도 좋겠다는 생각을 한다. (반대로 그렇지 못하다면?)

Management of non-functional requirements
기능 요구사항과 달리 고객이 요구사항을 매우 모호하게('빠르게', '불편하지 않게') 주거나 아니면 아예 주지 않는다. 온라인 애플리케이션은 예상 사용자 규모에 따라 성능을 산정해야 하는 기술적 어려움이 따르고, 업무 프로세스와 관계된 배치(batch) 업무는 실제 업무 방식을 모르면 성능 기준을 수립조차 하기 어렵다. '잘하는 법'을 교육하기는 어렵지만, 잘 다듬어진 템플릿과 예제가 도움을 주긴 한다. 종종 몇몇 조직에서 EA나 프로세스 관련 프로젝트를 수행하고 나서 (다른 산출물은 유명무실하게 버려두지만) 비 기능 요구사항에 대한 체크리스트를 널리 재사용하는 경우를 본다.

Architecture definition
적절한 수준으로 비 기능 요구사항의 설정하면(captured) 아키텍처를 정의한다. 아키텍처 정의를 이루는 활동을 간략히 언급(Architecture definition is about introducing structure, guidelines, principles and leadership to the technical aspects of a software project.)하고 설명하는 글에서 두 가지 사항이 눈에 띈다.

모든 시스템이 (정의을 하든 아니든) 아키텍처를 갖기는 하겠지만 항상 아키텍처를 정의하는 것은 아니란 점
It's fair to say that every software system has an architecture, but not every software system has a defined architecture.

그리고 신규 시스템이냐 기존 시스템 수정이냐에 따라 크게 다르다는 점

there's a big difference between designing a software system from scratch and extending an existing one.

Technology selection
기술 선택을 할 때 고려할 다양한 사항을 열거한다. cost, licensing, vendor relationships, technology strategy, compatibility, interoperability, support, deployment, upgrade policies, end-user environments. 또, 기술 선택에는 위험이 따르기 때문에 검토와 평가가 필요하다. (need to be reviewed and evaluated)

위에 열거한 항목 외에도 흔한 일은 아니지만, 법적 문제나 기술 제공 업체(vendor)의 경제력이 문제가 되는 일도 있다. 국내 솔루션이 외산 솔루션 복제 소송에 휘말린 경우가 있고, 직원 월급을 지급하지 못해 솔루션 커스터마이징 인력이 안정적으로 일하지 못하는 경우가 발생한 바 있다.

역시 신규 시스템이냐 기존 시스템 수정이냐에 따라 기술 선택도 달라진다.

Again there's a big difference between evaluating technology for a new system versus adding technology into an existing system.

Architecture evaluation
소프트웨어가 갖는 복잡함과 추상적 성격 탓에 이해관계자에게 '구현할 소프트웨어가 어떤 것'인지 보여주기 어렵다. 시스템뿐 아니라 아키텍처도 테스트해야 한다. 요즘은 많은 프로젝트에서 파일럿을 통해 아키텍처를 검증한다. 주어진 제약(기간, 자원, 예산)하에서 무엇을 검증하느냐가 결국 관건이다. 막연히 잘 되기를 바라지 말고, 위험요소에 대해 적극적으로 대처해야 한다.(And if you can do this as early as possible, you can reduce the overall risk of project failure rather than simply hoping for the best)

Architecture collaboration
아키텍처는 개발자 관점뿐 아니라 다양한 측면(a security, database, operations, maintenance, support)에서 긴밀한 협업을 이끌어야 한다. 규모가 커질수록 서로 다른 많은 회사나 팀이 참여하게 되니 실천이 쉽지 않다.

관련 글: Architects architect architecture!

다른 관점의 프레임워크

영회 — Wed, 10 Feb 2010 08:30:00 +0900

개념도 그릴 일이 생겨서 검색하다가 찾은 그림들... 평소 익숙한 애플리케이션 프레임워크 외에 조금 생소한 관점의 프레임워크 그림을 남겨본다. 새로운 것을 배우기 위해 가끔은 익숙지 않은 관점을 이해해야 한다.

감리 프레임워크(?)
출처: http://checkerslab.com/18

출처 미상인데, 방송통신쪽 서비스 프레임워크인 듯

출처: http://column.inews24.com/php/news_view.php?g_menu=041011&g_serial=90577

점차 친근한 녀석으로 바뀌지만... 그림이 이뻐서..

출처 미상

다시 생소한 프레임워크

기업내ㆍ기업간 가치사슬을 고려한 지원 정책 프레임워크
출처: http://mctwide.kmac.or.kr/c/portal/layout?p_l_id=PUB.1.982

매킨지 7S 프레임워크/모델
출처: http://ahntaehyuck.tistory.com/188

이벤트 처리 시스템(Event Processing Systems) 개념도

영회 — Tue, 09 Feb 2010 10:28:44 +0900

IBM DW의 A Conceptual Model for Event Processing Systems 에서 그림만 발췌

이벤트 처리의 개요

이벤트 처리 핵심 개념 아키텍처

이벤트 처리 컴포넌트 수준 개념 아키텍처

이벤트 처리 아키텍처와 이벤트 처리 네트워크

생각의 좌표를 읽고

영회 — Tue, 09 Feb 2010 08:30:00 +0900

기업하기 좋은 나라?

삼성일반노조 위원장 김성환씨는 그 흔한 특별사면에서도 빠진 채 3년 8개월 징역을 꼬박 살고 나와야 했다. 그가 한 일이라곤 불법과 비리로 얼룩진 삼성왕국에 맞서 싸운 것밖에 없지만, 검찰, 사법, 정치, 언론 권력 중 그를 대변해줄 '힘 센' 사람이 이 사회엔 없었다.

생각의 좌표 123쪽 중에서

새로운 정부는 '기업하기 좋은 나라'를 지향하고 있다. 그래서인지 최근 이건희 전총수는 사면되었다. 보수 언론의 찬양(?)만 보아도 그를 대변해줄 '힘 센' 사람이 줄은 선 듯하다. 나는 비정규직 문제에 대해 남의 일로만 여겼는데, 수 년간 정규직과 같은 일을 하는 비정규직 비중이 늘어가는 모습을 보면서 사회 문제 즉, 내가 사는 환경의 문제로 인식하지 않을 수가 없게 되었다. 그러던 차에 사회적 기업을 이야기하는 지인을 만났다. 딱히 근거를 제시할 수는 없지만, 생존을 위해서는 (기업은) 그래야만 한다는 생각을 갖게 되었다. 물론, "사회적"이란 표현에 대해서도 해석은 가지각색 일테지만.

톨레랑스

볼테르의 말처럼 "우리들의 부싯돌은 부딪혀야 빛이 난다." 서로 다른 견해가 표현되어 부딪힐 때 진리가 스스로 드러난다는 것이다.
...

차이를 차별, 억압, 배제의 근거로 삼지 말라는 성찰 이성의 요구가 톨레랑스
...

왜 이 땅에서는 분풀이나 가학성에 비해 연대의식과 이해심은 부족한가. 왜 여론몰이는 하면서 지혜를 모으지 못하는가.

생각의 좌표 -
홍세화 지음/한겨레출판

시민의 기본 자세

무지와 무관심은 중립이 될 수 없으며, 사회불의보다 사회정의를, 사익보다는 공익을, 몰상식보다는 상식을 원하는 사회구성원이라면 사회 현안들에 적극적으로 참여하고 개입하지 않으면 안 된다.
...

인간성의 발현은 베풀수록 스스로 충만해지고 베풀지 않을 때 오히려 그 샘이 마른다.
...

삶의 진정한 의미는 자아실현에 있지 기름진 생존에 있는 것이 아니기 때문이다.
...

그대는 앞으로 살아가면서 끊임없이 물질의 크기로 비교당할 것이다. 그것에 늠름하게 맞설 수 있으려면 일상적 성찰이 담보한 탄탄한 가치관이 요구된다. 그리고 자기성숙의 모색을 게을리 하지 말라. 자아실현을 위한 능력을 갖추기 위해서다. 그리고 성찰 이성의 성숙 단계가 낮은 사회에서 그대는 자칫 의식이 깨어났다는 이유만으로 인간에 대한 연민에 앞서 오만함으로 무장하기 쉽다. 만약 그대가 진정한 자유인이 되려고 한다면 죽는 순간까지 자기성숙의 긴장을 놓지 않아야 한다.

메이븐(Maven) 3, 기반 IoC 컨테이너로 구글 주스(Guice) 채택

영회 — Mon, 08 Feb 2010 08:30:00 +0900

InfoQ에 기사가 올라왔다. 메이븐 2까지는 Plexus DI container 라는 넘을 쓴 모양이다. 글을 올린 InfoQ의 Josh Long의 요약에 따르면 메이블 플러그인 개발이 Plexus에 종속적인 면(Plugin authors need to understand Plexus)과 부족한 문서(the poor documentation)를 들었다. 다른 이유로 메이블 프로젝트와 소나타입(Sonatype) 창립자인 Jason Van Zyl의 말을 인용했다.

Van Zyl cites many reasons for the migration from Plexus to Guice,besides the poor documentation. He describes the need to reduce thecommitment to the Plexus project, saying that the Maven project didn'tintended to build and support a DI container, but to promote and buildtools and infrastructure supporting developers and builds.

얼핏 읽어보면 기반 솔루션(IoC 컨테이너)보다는 핵심 역량(개발 지원 및 빌드 도구)에 집중한다는 듯하다. 하지만, Jason Van Zyl 이 JSR 330: Dependency Injection for Java Expert Group 구성원란 점을 안다면 다르게 해석할 수 있다. 그가 작성한 글을 보면 Guice의 기능 때문에 오랜 친구(?)를 버린 듯하다.

제이슨이 직접 스프링(Spring)이 아닌 이유를 언급하진 않았는데, 메이븐 개발자인 Stuart McCulloch이 나와 같은 궁금증이 있던 방문자의 글에 답을 달았다.

The main reason for using Guice was its support for programmatic bindings: ie. Modules and the binding DSL. This really helped us mapPlexus metadata to Guice bindings at runtime while still providing alevel of type-safety. I know Spring has JavaConfig, but this wouldrequire an annotated method per-bean (@Bean) which means you'd need todynamically create binding classes using CGLIB or ASM, etc. I'm surethe core Spring container can be configured directly using method calls(ie. no XML/annotations) but I don't believe it would be as easy as theGuice binding DSL.

OSGi In Action의 저자이기도 한 Stuart McCulloch가 Felix에 참여한다는 점을 고려하면 Spring을 선호할 가능성은 매우 낮아 보이기도 한다.^[각주:1] 현재 메이븐3 버전은 알파 6에 머물러 있다. 메이븐3은 메이븐을 시도하면서 겪었던 거부감을 완화하고 편리함을 느끼게 해줄 수 있을까?

기업용 OSGi 서비스 구현 경쟁 참조 [본문으로]

TDD/Eclipse 학습을 위한 Bowling Game Kata

영회 — Sat, 06 Feb 2010 08:27:16 +0900

Bowling Game Kata With Eclipse Keys.ppt

현재 클래스 구조로는 통과시키기 어려운 구조 개선을 하려는 경우에 테스트 코드를 주석 처리(comment out)하고 구조를 변경한다. 이렇게 하면 구조 개선 과정에서 지금까지 되던 기능(기존 테스트)은 보장(회귀 테스트)할 수 있다. 이후에 주석 처리를 풀고 테스트를 다시 시작한다.
for 등 반복문 괄호 범위 안에 넣어야 하는 로직을 밖에 넣었을 때 나타나는 오류도 빨리 포착할 수 있다. 다른 로직과 엉켜 원인을 알기 힘들게 되기 전에

Ctrl+C, Ctrl+V 가 타이핑보다 유리할 수 있다. 복사 + 붙여넣기 하는 과정에서 자연스럽게 중복을 인지할 수 있으니 테스트 성공 후에는 기억/메모해두었다가 리팩토링한다.

SSO 개념도

영회 — Fri, 05 Feb 2010 08:00:00 +0900

출처: http://www.brainkeeper.com/products/feature/feature-api-single-sign-on.php

컨설팅에 '유감' 많습니다 편집본

영회 — Thu, 04 Feb 2010 08:30:00 +0900

'컨설팅에 유감 많습니다'라는 글에서 인상적인 내용만 발췌해봅니다.

첫 번째 질문은, 컨설팅 서비스에 대한 만족도를 물어보는 것이었습니다. 80%가 넘는 사람이 ‘보통(3점)’에 체크했고, ‘만족한다’와 ‘불만이다’가 비슷한 비율로 나왔습니다. 반면 ‘매우 만족한다’는 대답은 전무했지요. 컨설팅 서비스가 특별히 감동적인 수준까지는 아니라는 의미일 겁니다.

요즘의 컨설팅사들은 고객들이 ‘대신 해주었으면 하는' 서비스를 일임하는 외주업체로 포지션되는 느낌입니다. 고객들은 더 이상 컨설팅을 특별한 전문서비스로 '추앙'하지 않습니다. 그저 세무와 회계와 같이 아웃소싱 가능한 일상품(Commodity) 서비스 업체로 여기는 추세입니다.

두 번째 질문은 첫 번째 질문과 연계된 것인데 ‘컨설팅사에 대한 가장 큰 2가지의 불만요소가 무엇이냐’는 질문이었습니다. 가장 빈도가 높은 항목은 컨설팅 결과물의 품질 문제, 컨설턴트의 역량과 자세 문제, 과도하게 높은 수수료, 컨설팅 범위의 지나친 제한, 애프터서비스 부재 등이었습니다. 특히 컨설팅 결과물의 품질에 문제가 많다라는 대답이 35%로 가장 많았죠.

'한국식 경영 방식으로는 안 된다, 미국식 최첨단 경영기법을 도입해야 살 수 있다'는 약간의 패배주의와 사대주의가 섞인 사회 분위기 속에서 시류를 잘 탄 컨설팅 사들은 높은 수익을 올릴 수 있었죠. 그들 대부분 외국계 회사였는데, 그래서 어마어마한 돈이 그들의 본사로 흘러 들어갔습니다. 그러나 시간이 흐를수록 고객들은 컨설팅에 대해 회의감을 느끼기 시작했습니다. 지나치게 높은 수수료와 그에 비해 턱없이 빈약한 컨설팅 결과물들, 남의 옷을 빌려 입은 듯 우리의 정서와 현실에 맞지 않는 경영기법들로 인해 엄청난 시행착오를 경험했습니다. 급기야 ‘컨설팅 무용론’까지 주장하는 기업들이 상당히 많아졌습니다.

컨설팅 사 역시 이런 상황을 모르는 바는 아닙니다. 하지만 새로운 유행을 불러 일으킬 ‘상품’만 개발해 내면 상황을 쉽게 타개할 수 있다고 생각하는 모양입니다.

세 번째 질문은, ‘컨설팅사를 선정할 때 가장 중요하게 보는 2가지 판단 요소가 무엇이냐’는 질문이었습니다. 설문하기 전에 저는 ‘브랜드와 명성’ 또는 ‘유사산업에 대한 경험’에 고객들이 가장 많은 표를 던지리라 추측했습니다. 그러나 결과는 예상 밖이었습니다. ‘브랜드와 명성’, ‘유사산업에 대한 경험’, ‘수수료 수준’은 모두 합해 15%도 안 되었죠. 반면에 ‘컨설팅 품질’과 ‘컨설턴트의 개인능력’이라는 대답이 73%나 되었습니다.

컨설턴트의 개인 역량은 컨설팅의 성패에 매우 중요한 요소입니다. 그러나 현실은 다릅니다. 적합한 인력이 아닌데도 불구하고 매출을 늘리기 위해서 함량 미달의 컨설턴트를 그럴듯하게 포장하여 투입시킨다든지, 한 명의 컨설턴트를 두 개 이상의 프로젝트에 겹치기로 투입시키는 바람에 집중력을 떨어뜨린다든지, 이로 인해 컨설팅의 품질이 저하되는 관행이 많이 벌어지고 있는 게 현실입니다.

설문 말미에 컨설팅 사에게 바라고 싶은 말을 자유롭게 써 달라고 요청하였습니다. 다양한 말들이 나왔는데, 그 중 제 가슴에 팍 꽂히는 말이 하나 있었습니다. 바로 “유행을 좇아 상품을 파는 장사꾼이 되지 말아 달라.”는 글이었습니다. ERP, CRM, SCM, KMS, BPR… 소위 Three-Letter Word(3글자로 된 경영기법들) 상품을 만들어 내다 파는 컨설팅 사를 통렬히 꼬집는 말이었습니다.

이 글은 5년 전에 기고한 칼럼을 고쳐쓴 것입니다(유사한 내용이 제가 쓴 '컨설팅 절대 받지 마라'란 책에도 실렸지요). 컨설팅의 실태가 5년 전과 크게 다르지 않아 보여 여기에 재차 포스팅합니다. 반성할 일입니다. 저도 마찬가지구요.

IT에서도 비슷하게 적용할 수 있는 듯...

자바 스크립트 프레임워크 기능 분류

영회 — Wed, 03 Feb 2010 12:30:00 +0900

IBM DeveloperWorks가 소개한 자바 스크립트 프레임워크 비교(Framework comparison)는 풍성한 내용을 담고 있다. 최근에는 자바 스크립트 쓸 일이 없어 내용 자체에는 관심이 없었는데 기능 분류가 마음에 들어 발췌해둔다.

Selectors
DOM traversal
DOM manipulation
Utility functions
Event handling
Ajax

비교를 할 때 대상을 선정하는 일도 쉽지는 않지만, 조사를 통해 수집할 수 있지만, 비교 기준을 뽑는 일은 해당 분야에 대한 경험과 통찰력 없이는 불가능하다.

클라우드 서비스의 효과를 함축해서 보여주는 그림

영회 — Wed, 03 Feb 2010 08:30:00 +0900

MSDN을 볼 때마다 느끼지만, MS가 그림은 정말 잘 그린다. 표현력도 뛰어나지만 시각적 아름다움까지 탑재한 그림이다. (출처: http://blogs.msdn.com/dachou/archive/2009/01/13/cloud-computing-and-the-microsoft-platform.aspx)

다양한 클라우드 서비스 제공 벤더에 대해 압축하여 정리한 그림은 다른 블로그(http://setandbma.wordpress.com/category/trend/)에서 발견할 수 있었다.

블로그 저자는 클라우드에 눈 뜨려면 다음 세 가지 전통적 패러다임을 버리라고 말한다.

…sequential processing
…relational storage
…the physical boundary of a machine

And, I think Google App Engine is in the best position to provide solution for the new paradigm.

아침 미팅(Daily Standup) 팁

영회 — Tue, 02 Feb 2010 12:43:55 +0900

Daily Standup Tips - a Roundup 을 읽고 공감하는 내용에 대해 곱씹는 잠깐의 메모

자칫 주간보고를 매일 하는 꼴이 될 수 있으니 주의하라며 Joakim이 권하는 내용

Focus on the goal – sharing information with fellow team members that will help the whole team get to done in the iteration
Focus on the team – sharing information with everyone and not just a single manager.
Discuss Elsewhere – don’t to solve problems in the standup instead schedule the time to solve later, when anyone who is interested may join.
Come Prepared – to keep the standup short team members need to know what you’ve accomplished and what is left.
Focus on Accomplishments – Joakim found that: “talking about accomplishments made provides a more positive attitude than just providing information on what parts of the system was worked on.”
Make Commitments – instead of mechanical saying what they will work in the next 24 hrs, he gets people to commit to the rest of the team what they will achieve.
Raise Impediments – did you have to touch 60 files to make small change?

요약하면, 짧은 시간에 진척사항과 문제점 공유(보고 아님)를 위해 쓰고 가능한 성취 위주로 긍정적인 분위기를 유지하기 정도?

Daily Standup 에 적용할 내용은 아니지만, 팀원 상호 작업 인지를 위해 맥락도 작성으로 큰 효과를 보았다.

이외에도 (집중하기 위해) 작업 보드 앞에서 진행할 것
8명 이내의 팀 인원
10 ~ 15분의 시간 제약

등이 유익한 팁이다.

(인터뷰) 답변의 정석

영회 — Tue, 02 Feb 2010 08:30:00 +0900

잉글랜드 대표팀의 주 공격수 웨인 루니의 인터뷰 기사를 보다가 흥미 위주의 교묘한 유도 심문을 피해가는 모습이 경외로와 옮겨둔다.

Q. 간단한 질문 드립니다. 리오넬 메시와 호날두 중 누가 더 낫다고 생각하세요? 그리고 그 이유는 무엇인가요? (요가, 인도네시아)

A. 호날두는 모든 걸 해내는 선수입니다. 골을 넣고, 프리킥을 차고, 크로스를 공급하고… 그야먈로 최고의 선수죠. 레알 마드리드에서도 잘하고 있습니다. 메시는 공이 발에 붙어 다니는 것 같아요. 매우 영리한 선수이고 축구에 대한 열정도 대단합니다. 저도 메시의 플레이를 보는 걸 좋아해요.

그렇지만 둘은 서로 다른 선수이기 때문에 제가 둘을 비교할 일은 아닌 것 같네요. 그냥 이렇게만 말해두죠. 두 선수 모두 맨유로 온다면 환영입니다.

Q. 2010 남아공 월드컵에서 공격 파트너를 한 명 고른다면 누가 좋으세요? (마르시우, 브라질)

A. 그건 파비오 카펠로 감독이 결정할 일입니다. 저는 에밀 헤스키나 저메인 데포 중 누구와 뛰게 되더라도 만족합니다. 이 답변은 제가 할 수 없을 것 같고요. 카펠로 감독이 마지막 순간까지 저를 포함해 모두를 궁금하게 만들 거라는 것만은 알겠네요.

Q. 맨유를 떠나야만 한다면 어떤 팀에서 뛰고 싶은가요? 잉글랜드 내의 다른 팀에서 뛸 수 있을 것 같나요? (알레스, 스웨덴)

A. 맨유가 저를 방출하지 않는다면 저는 언제나 맨유 선수입니다. 집도 훈련장 근처이고 즐겁게 생활하고 있어요. 저를 믿어주는 퍼거슨 감독에게 좋은 활약으로 보답하고 싶을 뿐입니다. 저는 이제 제 감정과 열정을 올바른 곳에 쏟기 시작했습니다. 이제 저는 어린애가 아니라 남자니까요. 지난 몇 년간 성장할 수 있었던 건 퍼거슨 감독 덕분이라고 생각합니다.

출처: http://news.naver.com/sports/index.nhn?category=worldfootball&ctg=news&mod=read&office_id=216&article_id=0000032989

아바타의 삶으로 한 발 더

영회 — Mon, 01 Feb 2010 08:30:00 +0900

종종 내 PC에 원격에서 접근해서 파일을 저장하는 방식 대신 비용을 내고 언제나 접근 가능한 저장소를 사용하는 이른바 클라우드 서비스 사용자가 되어야겠다는 충동을 느끼곤 한다. 꼭 필요한 일은 아니고 아직 큰 불편함을 못 느껴 생각에만 그친다.

인터넷에 의존적인 삶의 한 부분을 확실히 느낄 때가 있다. 한번은 보안 때문에 인터넷을 쓸 수 없는 곳에 노트북을 들고 갔더니 무기력함을 느꼈다. 마치 아바타와 링크하기 전 제이크 설리(샘 워싱턴)가 쿼리치 대령의 공격을 받을 때처럼 말이다. 지메일만 열면 자료와 필요한 URL이 있는데, 인터넷을 쓸 수 없으니 할 수 있는 일이 무척 제한되었다.

갑작스레 언론 통제를 강화하는 정부에서 살다 보니 인터넷을 '판도라'로 보는 인사도 있겠구나 싶다. 미네르바 사건만 떠올려봐도 그렇지 않은가? 그리고 판도라를 이용해 이익을 취하려는 이도 있다. 개콘에서도 소개했지만, 요즘 웬만한 인터넷 신문 테두리는 뽀르노(?)급 광고물이 횡행한다. 심지어 청소년 보호를 언급하는 기사 주변에도 '뜨거운 밤' 운운하는 광고가 번쩍인다. 사행성 게임이나 OOOO 알바(?) 등을 보면 묘하게 아바타가 떠오르고, 잘 지켜야겠다는 마음이 생긴다.

이미지 출처: http://extmovie.com/zbxe/hreview/2022361

[펌] Unix 계열 구조도

영회 — Sun, 31 Jan 2010 02:00:00 +0900

출처: http://develop.sunshiny.co.kr/367

Role 모델을 찾았다.. 아니 주저하다가 결정했다

영회 — Sat, 30 Jan 2010 08:30:00 +0900

요즘 무모하고 서툰 행동
그리고 과거의 잘못때문에 곳곳에서 난타를 당했다.
죽는소리 조금 보태면 포기하기 직전까지 당도했다.
타고난 한량기질 탓인지
남에게 가혹했던 태도가 이제는 자신도 겨누고 있다.
많은 사람이 도움을 주지만
그래도 살면서 행하는 시도는 늘 쉽지 않다.
그리고 피로감도 쌓인다.

오랫동안 주저하다가 결국 '고무고무'를 무기로 삼는 몽키 디 루피를 롤 모델로 삼기로 마음을 먹는다.

이미지 출처: http://www.wisia.com/pdh74/mystory