이번 달 developerWorks 서평은 '자바 프로그래밍 구현 관련 내용'을 다루는 서적 두 권이다.
힌트 한 가지: 'Clean Code'는 조만간 한국어판이 나올거다. ;)
빨간색이니 파란색이니 왼쪽이니 오른쪽이니 난리칠까봐 읽은지 오래된 이 책 서평을 뒤늦게 올릴까말까 고민하다가 그냥 올리기로 했다(사실상 특별한 내용이 없다). 빨/파, 좌/우를 따지고 싶은 분은 지금이라도 늦지 않았으니 Back 버튼을 누르시라. 낄낄...
이 책이야 워낙 유명하니 온라인 서점이나 구글 검색해보면 온갖 종류의 서평이 나오니 B급 프로그래머는 일반적인 서평을 쓰지 않겠다. 그 대신 88만원 세대가 나올 수 밖에 없는 몇 가지 사회적인 현상에 대해 고민해보겠다.
3년 전에 친분있는 H 은행 부행장이 아주 흥미로운 이야기를 해주셨다. 신입 사원 공채 면접에 들어갔다가 겪은 일화였다. 후보자 다섯 명이 들어왔는데, 1번 타자가 중국어로 자기 소개를 하더라 이거지... 그러자 2번 타자도... 3번 타자도... 4번 타자는 미국에서 대학을 마친 모양이던데, 중국어 대신 유창한 영어로 자기 소개를... 마지막 5번 타자 역시 중국어로... 뭐 중국 대사관 직원 선발하는 것도 아닌데 모두 막강 외국어 실력을 자랑하는 자리가 되어버렸다. 문제는 5명 중에 스펙(?)상 떨어뜨릴(일반 은행원에게는 너무 과할 정도로 오버 스펙이니) 사람은 없다는 데 있다.
비슷한 무렵 모 대학교 전산과 교수님과 저녁을 함께할 시간이 있었는데, 학생들 진로 관련해서 아주 흥미로운 이야기를 들었다. 요즘 학생들 상위 10%는 S전자에 입사하고, 차상위 10%는 S전자에 입사하기 위해 재수하며, 차차상위 10%는 S전자에 유리하게 입사하도록 그룹사에서 운영하는 캠퍼스에 들어간다는 말이었다. 뭐 일단 30%는 S전자에 간다고 치고, 나머지 학생들도 상당수 L사, K사, 또 다른 S사에 들어가버린다. 결국 남은 학생은 대학원에 가거나(우짜다 대학원이 이 모양으로... T_T), 그나마 중견 중소기업에 들어간다는 이야기다. 중간 중간에 의치한으로 이동하는 인력은 빼고 생각한게 이 정도다.
갑자기 삼천포로 빠지는 듯한 사례라고 보여지기 쉽지만... 이게 바로 한국의 자화상이며 88만원 세대를 일으키는 문제의 시초다. 사교육이니 뭐니하면서 사람에게 어마어마한 돈/시간/노력을 아끼지 않는 학부모들이 아주 투텁게 뒷받침하고 있기 때문에 한국에서 개인이 특별나게 두각을 나타내기란 결코 쉽지 않다. 따라서, 돈, 명예, 안전함이 걸리는 직종과 분야라면 진입하려면 치열한 경쟁을 벌여야한다. 취약한 사회 보장 제도로 인해 사회가 아니라 개인이 전적으로 위험 관리를 해야하기 때문이며, 안전판을 쌓으려면 결국 경쟁에서 승리해야 한다. 이런 피튀기는 경쟁에서 뒤진 사람들은 88만원 세대로 가는 편도 차편을 끊을 수 밖에 없으며, 일단 한번 들어간 이상 빠져나올 가능성은 극히 희박하다.
설상가상으로 요즘 정책들이 후손들에게 짐을 지우는(green 사업(?)한다고 국채를 왕창 발행하면 누가 갚지? 국민연금 펑크나면 누가 떼울까?) 방향으로 가고 있기에 더더욱 짙은 그림자를 드리운다는 생각도 든다. 세금 좀 깎아주는 얄팍한 서민 살리기(?) 정책이 나중에 부메랑으로 돌아오는 후손 죽이기(?) 정책이 될지도 모르니 88만원 세대 입장에서는 당황이 아니라 황당한 상황이다. 애비가 애를 들고 패니 얻어맞던 애가 "니 새끼 죽지 내 새끼 죽나?"라고 한마디 했다는 농담도 요즘 시절에는 씨도 안 먹히는 듯이 보인다. 하지만 이 책을 읽고나서도 느끼는 바이지만 이런 현상을 극복하거나 아니 완화할만한 뚜렷한 대책이 없다는 점이 더 큰 문제다. 사회 성원의 합의를 이끌어 개인의 위험을 분산해서 사회가 떠 맡도록 해주는 튼튼한 시스템을 구축하지 않는 이상 아주 풀기 어려운 숙제라 하겠다. 독자 여러분들도 88만원 세대를 읽으면서 각자 현상과 해법에 대해 고민 한 번 해보시길...
지난 달에 종합주가지수가 1500을 돌파하고 나서 친구 하나가 거의 3년 가까이 부은 펀드가 가까스로 본전치기 했으니... 환매하겠다고 이야기를 꺼냈다. 이 이야기를 듣고서 부분 환매를 권했다. 시장이 계속해서 상승세를 보일지 하강세로 돌아설지는 아무도 모르지만 펀드 환매 기본 규칙은 변하지 않기 때문이다. 세 번으로 나눠서 일단 1/3을 지금 팔고, 기회 보면서 나머지도 환매해라고 조언했다. 하지만 결론은? 맘 고생하기 싫다는 이유로 그 자리에서 바로 펀드를 모두 털어버렸다. 지금은 종합주가 지수가 1700선을 넘보고 있으므로 아마 B급 프로그래머 말을 잘 들었으면 상당한 수익을 거둘 수 있지 않았을까 하는 아쉬움이 든다.
이런 현상이 왜 일어날까? 미래의 투자 저자인 마이클 모바신은 다음과 같이 설명한다.
합리적인 의사결정과 일치하지 않는 경제적 행동을 규명하는 '전망이론'의 가장 중요한 통찰 가운데 하나는 사람들이 위험한 결과들 사이에서 어떤 결정을 내려야 할 때 그 크기가 아무리 작더라도 손실을 강하게 회피하려 한다는 것이다. 실제로 손실이 주는 정신적 충격이 같은 크기의 이익에서 오는 만족감보다 2.5배 더 크다는 사실을 발견했다. 즉, 사람들은 비슷한 크기라고 하더라도 이익에서 얻는 기쁨보다는 손실에서 오는 충격을 훨씬 더 심각하게 느낀다는 뜻이다.
와우! 손실 회피 성향으로 인한 투자 손실을 시원하게 설명하고 있다. 내친 김에 조금 더 살펴보자.
투자자들은 자신의 주식이 상승하기를 바라지 떨어지기를 원하지 않는다. 실전 투자에서 전망 이론의 핵심적인 사항은, 투자자들이 올바른 결정을 내렸다는 것에만 만족해 일찍 상승 종목을 팔아치운다는 것이다. 반면에 손실을 내서는 안 된다며 주가는 곧 반등할 것이라는 희망에 의존해 손실 종목을 지나치게 오랫동안 붙들고 있다는 것이다.
뭐 늘 그렇지만 말은 쉽다. 그렇다면 해법은? 버핏 파트너인 찰리 멍거에 따르면 버핏은 모든 투자 기회를 기대 값의 개념으로 생각한다고 한다. 버핏 말을 들어볼까?
이익의 날 확률에 가능한 이익규모를 곱한 것에서 손실이 날 확률에 가능한 손실규모를 곱한 것을 뺀다. 이것이 늘 우리가 하려는 것이다. 물론 이런 방법도 완전하지는 않다. 그러나 이것이 우리가 하는 일의 전부다.
버핏이 정말 대단한 사람인 이유는 자기가 한 말을 늘 지키기 때문이다. 평범한 사람들은 감히 넘보기 어려운 아주 특별한 재주임에 틀림없다. 심지어 총알이 두둑한 연기금 조차도 수익 높일 기회 놓치다니… 연기금 '좌불안석'이라는 기사 제목처럼 헛발질을 할 정도면 개인들이야 눈물 앞을 안 가리면 그게 더 이상한거다.
'미래의 투자'는 단순히 종목을 짚어주거나 차트 읽는 방법을 설명하는 책이 아니다. 이 책은 어떻게 보면 창의력을 토대로 투자 철학을 설명하는 책이다. 바로 실무(?)에 적용이 불가능하다는 점에서 버럭(!)하는 독자들이 있을지도 모르겠지만, 그만큼 생각해볼 거리도 많고 자다가 떡이 생길 훌륭한 조언들도 많다. 주식이나 펀드나 기타 투자(?)라는 행위를 하고 있는 독자라면 꼭 이 책을 읽어보기 바란다. '때늦은 지혜'(즉 자기 기만)를 피하기 위한 방법을 소개하는 부분을 정리하며 마무리하겠다.
자기 기만은 우리가 어떻게, 왜 특정한 결정을 내렸는지 돌아보게 만드는 반성의 기회를 차단한다. 한 가지 해결책은 당신이 결정을 내릴 때마다 왜 그런 판단을 했는지 기록으로 남기는 것이다. 이 기록들은 객관적인 반성을 할 때 훌륭한 자료가 될 것이며, 미래의 의사결정을 예리하게 만드는 데 도움을 줄 것이다.
머리도 식힐겸 간만에 웹 마케팅 책을 손에 들었다. 책도 얇고 어려운 내용도 없어서 금방 읽어버렸네?
오픈 브랜드는 회사 중심이 아닌 고객 중심의 브랜드 기법을 소개하는 책이다. 입문서 성격이 짙기 때문에 구체적이고 실질적인 행동 강령이 아니라 전반적인 개괄과 포괄적인 사례를 주로 다룬다. 따라서, 대상 독자는 주로 초급 마케팅 담당자으로 보여진다.
위키북스 블로그 소개글에도 나와있지만, 이 책은 O.P.E.N.이라는 키워드를 중심으로 돌아간다.
이 책 주제를 한 문장으로 요약하자면, 브랜드 자체를 기업이 좌지우지 하지 말고(닫힌 브랜드), 소비자와 함께 만들어 가자(열린 브랜드)다. 이렇게 하기 위해 필요한 기초 지식을 본문에서 다룬다고 보면 틀림없겠다.
독자 수준에 따라 호불호가 갈릴 가능성이 높은 책이므로(예: 웹 2.0을 어느 정도 이해하는 독자라면 이 책은 요약정리 수준으로 여길지도 모르겠다), 서점에서 한번 훑어보고 구매하면 좋겠다. 참고로 편집이랑 번역 상태는 나쁘지 않다(형광색이 들어가서 밝은 대낮에 읽기에는 조금 힘들지도...).
뱀다리: 블록 쌓고 보니 삼성경제연구소의 ‘소비자와의 직접소통과 인터넷’라는 글이 눈에 들어온다. 참고하시길... ;)
한 동안 경제/경영서 리뷰 블로그(?)라는 명성에 걸맞지 않게 엉뚱한 IT 서적만 잔뜩 선전해서 뿔이 난 독자들이 계실테다. 반성 좀 하고, 금주부터는 가을을 맞이하여 다시 경제/경영서 리뷰를 개시할테니 기대하시라. 그러면 1번 타자 나가신다.
다양한 기질을 타고 나고 다양한 환경에서 자라는 사람들 사이에 함께 뭔가를 하면서 갈등이 없다면 그게 더 이상할 노릇이다. 작년 여름에 소개한 Love: 사랑에 대해 알아야 할 모든 것에서 소개했겠지만, 사람들은 서로에게 상처주는 측면에 빠져서 사랑을 시작한 다음 이를 극복함으로써 스스로를 치유한다. 그렇다면 기업을 이끌어나가는 리더 사이에서 일어나는 여러 가지 복잡한 갈등과 불협화음을 어떻게 치유해야 하나?
리더 간의 갈등 관리은 1부에서 애플의 스티브 잡스와 존 스컬리의 사랑(?)이야기부터 시작한다. 두 거물이 어떻게 서로에게 콩깍지가 씌였고 어떻게 서로를 증오하게 되었고 어떻게 갈라서게 되었는지 차근차근 사례를 들어가며 분석을 시작한다. 그리고 나서 1부와 2부에서는 가상적인 사례를 잡아 관계를 분석하고, 관계 복원에 필요한 열쇠를 찾고, (서로에게 악영향을 주는) 상호 작용 패턴을 해체하고, 사로를 바라보는 프레임을 (긍정적으로) 재구성하고, 진실이라고 알고(아니 착각하고) 있는 가짜 사실을 바꾸는 방법을 설명한다. 마지막 3부는 실질적으로 관계 변화를 이끌어내기 위해 변화를 위한 노력 집중, 올바른 변화 전력, 동기 부여를 소개하며 마무리한다. 이 책의 사실상 하이라트인 4부는 링컨의 예를 들어 감수성이 관계 변화에 어떤 놀라운 영향을 미치는지 설명한다. 감수성은 B급 프로그래머 창의력 세미나에 참석하신 분들께는 이미 이야기했지만 모순되는 상황을 다루는 강력한 무기이므로 감수성의 중요성은 아무리 강조해도 지나치지 않다.
이 책은 부록도 재미있다. 특히 부록 B는 반성의 사다리라는 제목으로 상황을 해석할 때 자신의 마음을 들여다보는 창으로 사용할 수 있는 강력한 방법을 소개한다. 이 내용이 아주 낯익어서 곰곰히 생각해보니 비폭력 대화에서 사용하는 생각을 배재하고 먼저 객관적인 관찰에 집중하라는 충고와 상당히 유사하다는 사실을 깨달았다. 부록 B 본문 중 가장 감명 깊게 읽은 부분을 소개한다.
저명한 물리학자 리처드 파인만의 아버지는 깃털을 바삐 쪼고 있는 새를 가리키며 파인만에게 이렇게 말했다. "저 새의 이름을 전 세계 모든 언어로 안다고 해도 그 새 자체를 아는 것은 아니란다. 너는 단지 전 세계 다양한 사람들이 저 새를 어떤 이름으로 부르는지만을 알게 된 것뿐이란다. 저 새를 보고 그 새가 무엇을 하는지 보는 게 더 중요하단다."
파인만은 나중에 이것을 이런 교훈으로 표현했다. "나는 아주 어릴 적부터 사물의 이름을 아는 것과 그 존재 자체를 아는 것은 전혀 다른 문제라는 사실을 배웠습니다."
"객관적으로 파악한 상황에서 숨겨진 욕구를 발견한다"는 비폭력대화 기본 원칙을 다시 한번 깨닫게 만드는 정말 훌륭한 통찰력이다. 여러 가지 심리학적이고 사회학적인 배경이 들어가 있기에 내용이 다소 어려움에도 불구하고 직장 생활에서 갈등을 경험한 분이라면(안 그런 사람 있나? 낄낄) 꼭 한번 읽어보기 바란다. 강력 추천한다!
지난번 [일상다반사] SOS! 죽어가는 프로젝트 재난 복구 대작전 예약 판매 개시 이벤트에 참여하신 여섯 분을 대상으로 이벤트 추첨을 해보았다. 원래 다섯 분만 모시기로 했는데, 에이콘 출판사 이벤트 결과 글인 '리더 간의 갈등 관리'와 '프로젝트 생명연장'의 해법을 읽다보니 좋은 생각이 떠올랐다. 다섯 분께는 '하드 코드'를 나머지 한 분께는 『기업을 죽이고 살리는 리더 간의 갈등 관리』를 선물로 드리기로 했다. '리더 간의 갈등 관리'는 조금 어렵긴 하지만 상당히 좋은 내용을 담고 있는 책이다(독후감 곧 올릴테니 기다리시라.). 책을 협찬해주신 에이콘 출판사에게 감사를!
자, 그러면 추첨 결과를 공표한다. 그림 세 개를 차례로 보시기 바란다.
당첨된 여섯 분께서는 저에게 email로 책 받으실 주소, 전화번호, 성함을 보내주시면 감사하겠다. 앞으로도 많은 성원 부탁드리겠다.
하지만 책 행진은 여기서 끝나지 않는다. 거의 2년 반을 끌어온 리눅스 관리 서적 중의 최강자인 Linux Administration Handbook (2nd Edition) 한국어판이 조만간 나올 예정이므로, 시스템 관리에 떡실신한 개발자 분들은 조금만 더 참고 기다리시랏!
특정 소프트웨어를 개발하기 위해 누가 얼마나 오래동안 얼마나 많은 코드를 작성하는지 궁금한 경우가 있다. 예를 들어, 마이크로소프트 윈도우 개발에 몇 명이 투입되어 어느 정도 규모의 코드를 작성할까? 유감스럽게도 상업적인 소프트웨어를 개발하는 대다수 회사들은 이런 극비 정보를 꽁꽁 감춘다. 이런 정보 자체가 상대편 회사에게 프로젝트 일정을 예측하도록 도와주는 중요한 힌트가 되기 때문이다. 하지만 오픈 소스라면 상황이 달라진다. 통계자료를 제대로 만들어서 배포하면 오픈 소스 공동체에 도움을 주기 때문이다.
이번에 리눅스 파운데이션에서 발표한 Linux Kernel Development: How Fast it is Going, Who is Doing It, What They are Doing, and Who is Sponsoring It: An August 2009 Update은 리눅스 커널 개발 과정에서 나타나는 여러 가지 흥미로운 통계자료를 담고 있다.
바쁜 여러분을 위해 몇 가지 흥미로운 사실을 정리해보았다.
운영체제 만드는 작업이 후반부로 갈수록 인력 투입이 집중되고 코드 변경이 급격하게 일어난다는 사실은 그리 놀랍지 않다. 초반에 전체 아키텍처를 잡기 위해 핵심 코드를 작성하는 상황에서 벗어나 다양한 디바이스 드라이버를 추가하며, 그 동안 등한시했던 리펙터링 작업을 집중하기 때문이다. 여러분이 현재 수행하고 있는 프로젝트는 상태가 어떤가? 아무리 바쁘더라도 오후에 잠깐 코딩을 멈추고 SVN과 TRAC 통계자료를 한번 뒤적여보자.
EOB
드디어 기대하고 고대하던 재난 복구(원제: Catastrophe Disentanglement: Getting Software Projects Back on Track) 한국어판이 SOS! 죽어가는 프로젝트 살리기: 프로젝트 재난 복구 10단계 실천 전략이라는 이름으로 예약 판매가 시작되었다. YES24 등에서 구매 가능하니까, 프로젝트 때문에 머리가 아파 쓰러질 지경에 놓인 관리자분들께서는 당장 장바구니에 이 책을 넣으시길...
SOS! 죽어가는 프로젝트 재난 복구 대작전 +출간이벤트라는 제목으로 에이콘 출판사 블로그에 올라온 글이 너무 좋아서 B급 프로그래머 필력으로 도저히 따라가기 어려운 관계상 이번에는 묻어가기 위해 저자(not 역자) 서문을 잠깐 인용하겠다.
몇 년 전, 식인종에게 잡힌 러시아, 프랑스, 일본, 미국 포로에 대한 이야기를 들었다. 펄펄 끓는 물에 집어 넣기 앞서, 추장은 포로들에게 마지막 소원을 말할 기회를 줬다.
러시아 포로는 마지막으로 보드카 한 잔을 요청했다. 프랑스 포로는 아리따운 식인종 처녀와 마지막 키스를 원했다. 일본 포로는 마지막으로 품질에 대해 한마디 하겠다고 했다. 그러자 미국 사람이 다음과 같이 말했다.
"저를 끓는 물에 제일 먼저 넣어주세요. 품질 이야기는 듣고 싶지 않아요."
모 든 것에는 때와 장소가 있는 법이고, 소프트웨어 프로젝트가 난관에 봉착했을 때, 개발 조직이 듣고 싶어하는 마지막 조언은 프로젝트를 어떻게 운영했어야 하는지 설명하는 뒷북이다. 하지만 소프트웨어 프로젝트가 심각한 문제에 부딪혔을 때, 따를 만한 PMI, IEEE, SEI, ISO 복구 절차는 시실 거의 없다고 보면 맞다. 이런 조직은 구제책이라기보다는 예방 차원에서 프로세스를 제공하기 때문이다. 프로젝트가 점점 끓는 물에 가까워져질수록 마지막 요청은 "다시 문제에 빠지지 않는 방법을 보여주세요"가 아니라 "살려주세요"가 된다.
이 책은 "살려주세요"를 다룬다. 실패하는 소프트웨어 프로젝트를 회복하고 정상으로 되돌리는 방법을 설명한다. 물론 간혹 예방 차원의 설명으로 빠져들기도 한다. 하지만 이 책은 기본적으로 실패하는 소프트웨어 프로젝트(또는 재난)에서 회복(또는 복구)하는 10가지 단계를 기술한다. 소프트웨어 개발자, 프로젝트 관리자, 선임 관리층, 소프트웨어 프로젝트 이해관계자(소프트웨어 프로젝트에 관심이 많은 모든 사람) 등 많은 사람에게 도움을 줄 것이다.
저자 서문을 읽어보면 알겠지만 이 책은 실패 직전 소프트웨어를 잠깐 멈춘 다음에 정상 궤도로 올리는 내용을 담고 있다. 지금까지 시중에 나온 대다수 소프트웨어 공학 책은 모두 프로젝트가 망가지기 전까지 사전에 예방조치를 취할만한 훌륭한 이야기를 담고 있는데, 사실상 소프트웨어가 망가지기 시작하면 아무 쓸모도 없다. 정부나 기업에서 비상사태에 대비하는 매뉴얼을 만들어 만반의 준비를 갖추고 있지만 IT 소프트웨어 개발 조직에서 이런 비상 매뉴얼을 보유하고 경우는 드물기에 이 책으로 시작하면 상당히 많은 도움을 받으리라는 생각이다.
이 책 주요 대상 독자는 최소한 경력 5년 이상 팀리더, 팀장, 프로젝트 관리자, 연구소장, 상부 관리층이다. 일반 개발자들도 이 책을 읽으면 좋긴 하겠지만 당췌 무슨 소리인지 모를 가능성이 높아서 조금 걱정이긴 하다. 하지만 향후 팀장이 되기 전에 미리 백신을 맞는다는 기분으로 읽어보면 살이 되고 피가 되리라...
자, 여러분이 기대하는 이벤트 시간이 다가왔다. 일단 출판사 이벤트는 SOS! 죽어가는 프로젝트 재난 복구 대작전 +출간이벤트를 참조하시기 바라며, B급 프로그래머가 출판사 협조를 받아 펼치는 이벤트는 다음과 같다.
아무쪼록 성공적인 프로젝트 진행에 도움이 되기 바라며, 블로그 애독자 여러분을 위해 기회가 되면 재난복구 오프라인 세미나도 한번 진행해볼 예정이오니 계속해서 뜨거운 관심을 부탁드리겠다.
오늘도 삶의 지혜(?)를 다루는 글을 준비해보았다. 한두 장씩은 모두 지갑에 들어있는 신용카드 이야기다.
남편 카드 분실했다고 전화했더니...라는 기사를 읽다보니 며칠 전에 신용카드를 잃어버려서 재발급 받았던 기억이 주마등처럼 뇌리를 스치고 지나갔다.
뭐 지갑을 잃어버린 정도로 큰 사고는 아니었고, 밤에 지하철 타고 가다 버스로 환승하는 도중에 신용카드가 흘러버렸던 모양이다. 개찰구에서 카드가 없어졌음을 인지하고 역무원에게 상황을 설명해서 나온 다음에 바로 카드사에 전화를 걸어서 신고를 했다. 여기서 몇 가지 사항을 주의 깊게 지켜야 한다.
자, 이제 신용카드를 잃어버려도 당황하지 말고 차근차근 대응하자.
지난 번에 2007년 17회 졸트 상 생산성 우수상을 획득한 재난 복구 번역서 관련 소식을 전했었다. 이번에 전할 소식은 2009년 19회 졸트상 일반 서적 부문 최고상을 수상한 Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior 번역서 소식이다. 모든 원고를 다 남겼기에 출판사에서 최종 마무리 작업이 한창이므로 조만간 독자 여러분에게 선보이지 않을까 싶다. 아, 인사이트 출판사에서 소개한 내용도 참고하면 좋겠다.
이 책 역시 아직 번역서 제목이 정해져 있지 않은 관계상 원서 표지를 그대로 올려보았다. 프로젝트 성공을 다루는 패턴과 실패를 다루는 안티 패턴 86개를 싣고 있는 이 책은 톰 디마르코, 팀 리스터 등 아틀란틱 시스템즈 길드 소속 여섯 분이 머리를 짜내어 만든 멋진 책이다. '피플웨어'와 '소프트웨어 프로젝트에서의 리스크 관리'를 재미있게 읽으신 분들이라면 이 책을 놓치면 땅을 치고 후회할지도 모르겠다.
이 책 특성을 잘 나타내는 아마존 서평을 일부 소개하겠다.
이 책은 신랄한 유머와 함께 통찰력을 발휘한다. 이 책은 프로젝트에서 특별히 무능한 역할을 하는 사악한 인물을 그림으로써 즐거움을 선사한다. 목표를 향한 작업 진행 상황이나 마감일을 하나도 언급하지 않고 항상 낙관적이고 장미빛 미래만 이야기하는 무드 링을 낀 관리자를 만나보지 않은 사람이 있을까? 프로젝트에 책임을 지지 않은 채 프로젝트에 돌을 던지는 평론가는 어떤가? 모든 사람의 능력이 평균치 이상인 워비곤 호수 이야기는 또 어떤가?
86가지 패턴을 차분하게 읽어보면서 프로젝트 성공과 실패에 드러나는 패턴과 안티 패턴을 머리 속으로 정리해보면 많은 도움이 될 것이다. 프로젝트 성공을 위해 관리자와 개발자 모두가 꼭 읽어야 할 필독서라는 생각이다.
뱀다리: 어쩌다 보니 재난 복구와 출간 시기가 맞물려 2007년 졸트 상 vs 2009년 졸트 상 대결 구도가 되어버렸다. 한국에서는 누가 더 인기를 끌지 벌써부터 궁금해진다.
조금 늦은 감이 있지만, 미국 거주하시는 분을 위한 특별 이벤트에 당첨된 분들 주소와 책 목록을 간략하게 정리해보았다. 다행히도 응모하신 분들 중에서 주소가 중첩되는 경우는 없었으므로 충분히 구분 가능할 것이다.
당첨되신 분들께 박수를...
B급 프로그래머가 소리소문없이 숨어서 트윗질(?)을 하고 있음에도 불구하고 어떻게 알았는지 followers가 계속해서 조금씩 늘고 있는 상황이다. 따라서 커밍아웃할 시점이 왔다는 생각이다. 관심있는 분들께서는 http://twitter.com/jrogue를 한번 방문해보시기 바란다.
이번 달 developerWorks 서평은 '리버싱과 문제 해결'을 다루는 서적 두 권이다.
연재물 마지막에서 소개한 '제1회 해킹 And 리버스 엔지니어링 대회'에 나오는 예제는 리버싱에서도 다루는 전통적인 암호 풀이 응용이다. 하지만 난독화기로 이리저리 꼬아놓았을테니까 쉽게 풀리지는 않으리라고 본다. B급 프로그래머야 차카고 순진하므로 이런 리버싱을 못하기에 주변 해커(동물 애칭이 붙는...) 몇몇을 찔러보았지만, 다들 바쁘단다. T_T
2007년 17회 졸트 상 생산성 우수상(Productivity Winners)에 빛나는 "Catastrophe Disentanglement"(by E. M. Bennatan, Addison-Wesley Professional) 번역서가 최종 마무리 작업에 들어간 상황이다. 재난 복구를 다루는 이 책 제목이 아직 안 정해졌기에(발음도 어렵지? ㅋㅋ), 원서 표지를 그대로 올렸다(실제로 번역서 표지도 원서 표지를 그대로 따를 계획이다).
이 책은 일정/예산/품질을 놓고 벌이는 프로젝트 게임에서 재난이 닥치거나 근일 닥치리라고 예상되는 시점에 어떻게 하든 통제력을 장악해서 마무리하는 작업에 초점을 맞춘다. 배구에서 3단으로 넘겨서 위험을 벗어난 다음에 다시 공격할 찬스를 잡는 경우와 비슷하다고 볼 수 있겠다. 책 내용을 살짜쿵 열어보자면...... 프로젝트 복구 10단계를 제시한 다음에 각 단계에서 수행할 내용과 주의 사항을 다룬다. 궁금해하시는 분을 위해 복구 10단계를 그림(미안하지만 급히 그림을 수배하느라 영어 버전이다)과 글자로 정리해보았다.
저자인 베나탄은 상기 10단계를 번개불에 콩볶듯 끝내야 한다고 속력을 무지 강조한다. 그도 그럴 것이 상기 재난 복구 과정에서 기존 프로젝트가 완전히 멈춘 상태가 되기 때문이다(all-stop). 과연 한국 실정에 이런 발칙한 이론이 맞아 떨어질지는 B급 프로그래머조차 무지 염려스럽긴 하지만 책을 읽다보면 확실히 끌리는 면이 있다. 목이 빠지도록 기다리는 애독자 여러분을 위해 늦어도 8월 말이면 서점에 배포되도록 노력할 계획이며, 책이 나오는 시점을 기념해서 특별 세미나도 기획하고 있다. 조금만 더 기다려주시라.
뱀다리) 재난 복구 번역서가 나오기 전에 (조만간 선보일) "IT 기업의 타산지석: 일등회사가 주는 교훈"과 (이미 선보인) "소프트웨어 크리에이티비티 + 컨플릭트" 시리즈를 먼저 읽고 계시면 좋겠다. 아무쪼록 휴가 기간 동안 시리즈 4권 모두 통독한 독자에게 행운이 있기를...
맥용 오피스 2008 사용자라면 반드시 이번에 새로 나온 업데이트를 설치하기 바란다. 이유는? 공포의 워드 화살표 키 버그가 드디어(!!!!!) 잡혔기 때문이다.
솔직히 맥용 오피스 수준이 너무 떨어져서 비싼 돈 주고 사기가 아까웠지만, 혹시 B급 프로그래머라도 한 카피 정품을 사주면 감격(?)해서 한글화에 좀더 신경쓰지 않을까 싶어서 2004와 2008 두 버전을 모두 제 돈 주고 구매했었다. 하지만, 뭐 맥용 오피스를 사용해보신 분이라면 누구나 수긍하시겠지만... 눈물이 앞을 가리는 심각한 버그가 몇 가지 있다(사소한 불편사항/버그는 열거하기도 귀찮다. 오죽했으면 윈도우랑 윈도우용 오피스를 많이 팔기 위해 일부러 이렇게 만들었을거라는 이야기도 시중에 떠 돈다.).
한국어 철자 교정기, 메뉴 한글화, 맑은 고딕 폰트까지는 바라지도 않았지만, 당장 사용에 불편한 문제점은 해결해야 할 것 아닌가? 하지만 이번에 업데이트 설명을 읽다보니... 다음과 같은 문구가 아주 크게 눈에 확 들어왔다.
향상된 한국어 문자를 사용할 때 편집입니다.
화살표 키의 누를 때 잘못 표시할 문서를 한국어 문자를 야기하는 문제를 해결합니다.
오오오... 결국 민원을 해결했구나. 업데이트를 설치해서 테스트해보니 워드 화살표 문제가 사라졌다! 괘씸한 지고... 이 버그 하나 수정하기 위해 도대체 몇 년을 야루고 시룬거야? T_T
뱀다리: 워드 버그 수정보다 더 놀랄만한 이야기 하나. 오늘 소개한 마이크로소프트 기술 지원 문서가 사람 개입 없이 기계로 번역된 내용이라는 사실! 처음에는 번역을 급히 하느라 서둘렀구나... 라고 생각했을 정도니, 기계 번역 결과 치고는 상당히 쓸만하다.
B급 프로그래머와 함께 번역 작업을 동고동락하신 해님이 미국 거주하시는 분을 위한 특별 이벤트를 마련해주셨다. 바로 애독자를 위한 특급 도서 이벤트!
위에 열거한 책 중에서 필요한 책을 고른 다음에(복수 개도 가능하다), 이름, 우편물 받을 집주소(거듭 주의: _미국_ 주소 only!)와 함께 B급 프로그래머 전자편지(jrogue 에뜨 쥐메일.컴)로 보내주시면 _선착순_으로 책을 보내드리겠다.
아무쪼록 많은 성원 부탁드린다.
주말마다 SK 주유소에 기름을 넣으러 가는데 어느 순간부터 Happy Auto Member라는 요상한 카드를 자꾸 만들어라고 귀찮게 한다. 연 12회 무료 세차에 엔진오일 1회 교체, 신용카드와 별개로 20원 추가 적립 등 겉으로 보기에 아주 멋진 혜택을 주는 이 카드는 연회비(가장 낮은 등급의 경우 3만원!)를 내도록 만드는 사실상 SK 주유소와 스피드메이트 lock-in용 떡밥 카드다.
이렇게 자꾸 이 카드를 권하는 이유가 있는데, 바로 OK 캐쉬백 점수다. 결제 과정에서 OK 캐쉬백 카드를 제출하므로, OK 캐쉬백 점수를 확인한 주유원이 가입을 적극적으로 유도하는 셈이다. 물론 연회비 이야기는 하지 않다가 결정적인 순간(즉 신청서를 다 꾸미고 나서...)에 차액을 결재하기 위해 신용카드를 달라고 하면서 이야기를 한다. B급 프로그래머야 혜택을 앵무새처럼 읊을 때 바로 물어봤다. 잘 알겠으니 연회비가 얼마냐구... ㅉㅉ
매번 거절하기도 귀찮아서, OK 캐쉬백 점수를 소진해버리기로 했다. 여러 가지 방법이 있는데 필요없는 물건을 구매하거나 다다음달 이동전화 요금 형태로 캐쉬백을 받으면 된다. 하지만 현금화 기간이 너무 오래 걸리거나 사용 금액에 제약이 있는 경우가 많아서 사실상 제대로 쓰기가 무척 난감하다(OK 캐쉬백을 써본 사람은 무슨 말인지 알거다). 예를 들어, 바로 현금으로 OK 캐쉬백을 교환하려면 3만점 이상 되어야 하고 신청 절차도 복잡하고 현금화 기간도 무척 길다. 그 기간 동안 이자 놀이하는 거다. ㅋㅋ
하지만... 손가락 몇 번이면 OK 캐쉬백 점수를 바로 현금화하는 방법이 있다. 물론 준비물이 조금 까다롭긴 하지만 한번만 고생(?)하면 그 다음부터는 쌓이는 족족 현금으로 전환이 가능해진다. 준비물부터 볼까?
자 준비 끝났다. 이제 마이캐쉬백에서 자신의 캐쉬백 점수를 확인한 다음에 OK 캐쉬백 점수를 사용해서 MMF에 추가 불입을 한다. 그러면 MMF 쪽으로 입금 신청이 들어가면서 현금 세탁(?)이 이뤄진다. 별도 수수료도 없고 복잡한 절차나 기간이나 최소 점수 제한도 없다.
여기까지 말하면 MMF 입금과 출금 사이에 벌어지는 '하루'라는 시간 간격에 대해 투덜거리는 분도 계실거다. 여기서 엄청난 꼼수가 존재하는데, 신청하는 OK 캐쉬백 점수보다 MMF에 입금하는 금액을 작게해보자. 낄낄... 남는 돈은 일반통장에 그대로 입금된다. 아마 이 글 때문에(비밀을 폭로해서 미안하다) 이런 방식이 더 이상 먹히지 않을지도 모르겠지만, 그래봐야 실제 현금화하는데 걸리는 시간은 단 하루다.
이렇게 해서 주기적으로 OK 캐쉬백을 0원으로 만든 다음에 주유소에 가면 귀찮은 카드 호객 행위에 걸리지 않는다. 푼돈도 생기고 귀찮은 상황도 피하고, 일석이조다.
사실상 정치, 경제, 사회, 문화, 전방위에 걸쳐 돈이 지배하는 사회에서 필사적으로 살아남자. 자기 주먹이 최고인 세상이니...
약속했듯이 오늘은 재앙에 가까웠던, 아니 재앙 그 자체였던 마이크로소프트 워드 포 윈도우 프로젝트를 살펴봄으로써 과거가 우리에게 주는 몇 가지 교훈을 생각해보자.
마이크로소프트 사는 영웅 숭배 시스템을 창조해서 심지어 빌이 만나보지 조차 않은 직원에게까지 빌 게이츠의 의지가 영향을 미치도록 만들었다. 북한의 김일성과 마찬가지로, 시애틀 근교에 있는 회사에도 이런 방식이 통했다.
'김일성'이라는 단어를 보자마자 히스테리를 일으켜서 바로 댓글을 달려는 분들도 있겠지만, 잠깐만 참자. 위 인용구(!)는 Accidental empires를 지은 Robert X Cringely가 한 말이다. 낄낄... 요즘이야 상당히 안정적으로 돌아가는 마이크로소프트 사지만 초기에는 구둣발 문화가 어떠했는지 안봐도 DVD가 아닌가?
이런 시스템의 중심에는 '메타 프로그래밍' 이론을 만들어낸 찰스 시모니가 버티고 있었다. 시모니는 한 명이 대규모 소프트웨어 개발 팀을 제어하도록 만드는 계층적인 구조를 마음 속에 그리고 있었다. 빌은 이런 구조를 "소프트웨어 공장"이라고 마음에 들어했다.
유감스럽게도 이런 방식은 성공하지 못했다. 그래도 '하드 코드'에 나오는 아키텍트와 프로젝트 관리자라는 제도가 자리잡히도록 만들었으니 절반의 성공이긴 하다. 나머지 절반의 실패란? 초기에 이런 절대 군주 구조에 따른 피해는 심각했다. 마이크로소프트 워드 포 윈도우 1.0이 대표적인 예다.
워드 포 윈도우 프로젝트는 원래 리차드 브로디가 이끌었다. 제록스 팔로 알토 연구소의 인턴이었던 브로디는 찰스 시모니의 지도 하(?)에 신형 워드 프로세스 개발에 나섰지만, 엄청난 타격을 입고 작가(마인드 바이러스를 집필했다)이자 프로 포커 선수로 전향한다. 브로디 말을 직접 들어볼까?
1983년 10월에 워드가 출시되었을 때, 지금은 응용 부문이라고 불리는 조직에 프로그래머 30명에 마케팅 1명이었다. 문제는, 멀티플랜(찰스 시모니가 만든 스프레드 시트)이 이미 나와 있었으며, 사용자 인터페이스가 완성되어 있었다. 나는 워드를 멀티플랜과 호환되도록 만들어야만 했다. 내 임무는 다음과 같았다. "스프레드시트 사용자 인터페이스를 탑재한 세상에서 첫번째 워드 프로세스를 만든다."
피해를 복구하기까지 5년이 걸렸다.
이런 생기 발랄한 아이디어를 내고 이를 승인한 사람이 누군지는 독자 여러분들도 알고 계시리라...
스티브 맥코넬이 쓴 Rapid Development 책 9장 '일정'을 보면 지나치게 낙관적인 일정의 대표적인 예로 마이크로소프트 워드 포 윈도우 1.0가 나온다. 잠시 살펴볼까?
윈도우즈용 워드, 줄여서 '윈워드'는 개발 기간 5년과 개발 인력 600월-인원을 들여서 만든 코드 249,000줄짜리 시스템이다. 최종 일정 5년은 원래 계획한 일정보다 대략 5배가 길었다. 1984년 9월에 시작해서 1989년 11월에 끝났다.
앞서 브로디가 말한 잃어버린 5년이 의미하는 바가 슬슬 이해되기 시작할 것이다. 빌게이츠가 비전 문을 어떻게 꾸몄을까?
'역사상 가장 우수한 문서 작성기'를 '가능한 빨리, 가급적이면 12개월 안에' 만들자.
무리한 일정 때문에 계획을 정확하게 세울 수 없었으며, 예측을 10번이나 변경했다. 프로젝트 중도 이직율도 장난이 아니라서, 5년 동안 브로디를 비롯해 개발 수석이 4번이나 바뀌었다. 2명은 일정 압력 때문에, 1명은 건강 문제로 그만두었다고 하니 그 당시 프로젝트 심각성을 미뤄 짐작이 가능하다. 게다가 일정 압력 때문에 개발자들은 기능을 대충 구현했다. 품질이 낮고 미완성이라는 사실을 알면서도 '완료'로 보고했다. 결국 3개월 정도 걸린다고 예상했던 안정화에만 12개월이 걸렸다.
다들 인정하겠지만, 막연한 기대가 주의깊은 계획수립을 대신할 수는 없다. 문제는 요즘도 윈워드 같은 일정 수립이 유행(?)이라는 사실이다.
워드 포 윈도우즈 프로젝트에서 나온 신조어 중에 "무한 결함"이 있다. 무한 결함? 개발자가 버그를 수정하는 속력보다 테스터가 버그를 찾아내는 속력이 더 빠르며, 버그를 하나 수정할 때마다 다른 버그가 어김없이 튀어나오는 현상이다. 이런 조건 하에서는 일정과 출시 일정 예측이 모두 무의미하다. 셀 수도 없는 버그를 수정하기 위해 코드 상당수를 다시 작성했지만, 복구하는 만큼 오류가 생겼다. 마이크로소프트 사의 테스트 감독인 로저 셔만이 이런 어두운 시기를 어떻게 회상했을까?
사람들은 '망했다'라는 메시지를 받았다... 이는 경주용 자동차 운전과 유사하다. 벽에 충돌하고 나면 벽이 어디에 있는지를 알게 된다.... 사람들은 얼마나 상상력이 풍부한지 얼마나 창의적인지에 무관하게 코드를 통채로 버리지 못하리라는 사실을 알게 되었다. 워드와 쌍 벽을 이루는 엑세스 프로젝트도 교훈이 될만하다. 엑세스 버그 데이터베이스는 덩치가 너무 커서 단일 서버로 처리하지 못했다. 너무나도 많은 활성 버그가 있어서 테스트 팀은 사실상 손을 놓고 있었다. "뭐가 문제야? 개발자들은 이미 우리(테스터)를 따라오려면 2년 어치 백로그부터 처리해야 할테니..." 그래서 테스터들은 모든 시간을 투입해서 자동화와 자동화 도구 개발에 힘썼다.
워드 개발자들이 테스터들을 시험한답시고 폰트 크기를 돌려주는 함수에 항상 12pt 값을 반환하게 만들었다는 이야기가 진실인지 아닌지는 모르겠지만, 위 회고문을 읽어보면 진실일지도 모르겠다는 공포가 엄습한다.
어찌되었거나 마이크로소프트 워드 프로젝트는 행복한 결말로 끝났다. '초난감 기업의 조건'에 아주 잘 나오지만, 경쟁사들이 정신줄을 놓고 있는 사이에 마이크로소프트 사는 완성도가 아주 높은 오피스 슈트를 준비했으며 일단 제국의 역습이 시작된 이래 한 번도 오피스 시장에서 선두를 빼았긴 적은 없다.
리눅스 시스템 프로그래밍 이벤트 당첨자를 발표하겠다. 응모하신 모든(?) 분들께 책을 보내드릴테니 B급 프로그래머에게 책 받으실 우편 주소를 알려주면 감사하겠다. 당첨자 두 분께서는 아무쪼록 열심히 읽으시고 즐거운 방학 생활 되시기 바란다.
이벤트 참여자가 예상대로 상당히 적은데... 그렇다고 해서 요즘 대학생들은 공부를 안 한다는 둥 책을 안 읽는다는 둥 IT 업계 미래가 어둡다는 둥 .... 이런 상투적인 이야기는 꺼내고 싶지도 않다(B급 프로그래머는 그렇게 밴댕이 소갈머리가 아니다. 낄낄...). 대학생 여러분들은 방학 맞이해서 평소에 하고 싶었던 활동을 하시라. 경험에 따르면 리눅스 시스템 호출을 몰라도 살아가는 데 큰 지장이 없다. (물론 당신이 리눅스 프로그래머를 지향할 경우라면, 시스템 호출에 대한 지식 부족은 재앙이 시작될 징조다.)
또 다른 각도로 바라보니 리눅스도 이제 안정적인 주류 기술로 편입되었다는 생각이다. 마이크로소프트 서적의 가장 큰 적이 codeguru와 MSDN이듯이 리눅스 서적의 가장 큰 적은 source forge와 LDP/man 페이지가 되버린 느낌.
한 숨 돌리셨나? 하지만 요즘 한창 뜨는 쟁점(?)에 맞춰 적시에 등장한 또 다른 블록버스터급 책이 여러분을 주머니를 남김없이 털어 버리려고 접근 중이므로 바짝 긴장하시기 바란다. 원서 '크리' 맞지 않도록 미리 알려드렸으니, 조금만 참으시며 7월 말을 기대하시라!
공지 사항: 소프트웨어 크리에이티비티 세미나에 참석하셨던 heegoo님께서는 저에게 전자편지로 우편물 받으실 주소를 알려주세요. 두 차례 편지를 보내드렸는데, 답장이 없으시네요. T_T
어제 거의 희비극에 가까웠던 티맥스 윈도우 발표를 원거리에서나마 모니티링하면서 웃지도 못하고 울지도 못하는 아주 희한한 경험을 했다. 황XX 줄기세포 건이나 심XX D 워 때야 생명공학과 영화를 모르기에 B급 프로그래머는 구석에 찌그러져 얌전히 구경만 했지만, 이번 경우에는 다르다. B급 프로그래머도 나름 '프로그래머'이기 때문에 민감한 부분을 건드리더라도 할 말은 하고 넘어가야겠다.
RTM까지는 바라지 않지만 아직 RC, 아니 베타, 아니 알파 수준도 안 되는 제품을 들고 나와서 태극기 휘날리는 가운데 애국심과 개발자들의 열과 성과 투입한 자금과 놀라운 기술력(!)을 집중 강조해서 혹시나 하고 지켜본 B급 프로그래머를 정신적으로 아주 피곤하게 만든 점 용서해준다. 기존 legacy IE조차도 화면 렌더링에 문제를 노출한 점 용서해준다. 스타크래프트도 힘들게 동작하는 호환성을 보여준 점 용서해준다. 프린터를 연결해서 인쇄 한 장 안 한 점 용서해준다. 자사 운영체제가 아닌 남의 운영체제에서 오피스랑 웹 브라우저 시연한 점 용서해준다. 제품 구경하러 온 고객을 일괄적으로 학생 취급해 지루하고 따분하고 졸리는 강의로 때운 점 용서해준다. 월화수목금금금에 이혼당하고 아파서 쓰러지고 쇠진(burn-out)해버린 기술자들의 영웅(?)담을 들러주는 만행도 용서해준다(도대체 이런 영웅은 누가 만들었는지 짚고 넘어가야 한다). 다 용서해준다. 하지만 반드시 다음 질문에 대한 대답은 듣고 넘어가야겠다.
기업 비밀이라서 상기 네 가지 질문을 답하기 곤란하다고 말한다면 개발 자체가 정말 곤란한 상황임을 입증하는 꼴이다. 이 블로그 독자 중에서 T사 소속이 있다는 사실을 확실하게 알고 있다. 익명으로라도 제보를 해주면 감사하겠다.
박 회장에게 한 가지 부탁이 있다. 마이크로소프트 욕하고 까대기 전에 마이크로소프트 내부 반성문인 하드 코드부터 읽어보시라. 어제 발표회장 분위기를 보아하니 반성은 없고 자랑만 난무하는데, 치열한 자기 성찰과 반성이 없는 조직은 반드시 망한다.
