이 책을 처음 알게된건 '회의문화'에 대한 사내메일이었습니다. '회의를 효율적으로 하자.'는 메일이었고 책을 소개하는 슬라이드 내용이 괜찮아 보여서 샀는데 알고보니 이 책의 저자들이 37Signals의 창립자들이네요. 특히 데이비드 하이네마이어 핸슨이라면 Ruby on Rails의 개발자로 더 유명합니다.
이쯤되니 뭔가 내가 잘못생각하고 책을 샀구나 하는 생각이 들었습니다. 읽다보니 이 책은 새로운 일을 시작하고 싶은 사람들을 위한 책이구나 하는 생각이 들었습니다. 부연하자면 기업가정신(Entrepreneurship)을 가진 사람에게 딱이라고 이야기 하고 싶네요.
책은 처음부터 끝까지 기존 틀을 깨기 위해 어떻게 행동해야 하는지를 명확하게 제시합니다. 책 전체를 통털어서 이 잭이 말하는 핵심을 몇가지 키워드로 정의해 본다면
p31 남들보다 오래 일한다고 해서 꼭 남들보다 더 열심히 일하거나 더 많은 일을 하는 건 아니다.
p77 반쪽자리 제품을 만드느니 제품을 반만 만들어라.
p123 유도해법이란 최소의 노력으로 최대의 효과를 거둘 수 있는 해법을 말한다. ... 해법이 완벽하지 않더라도 핵심적인 문제를 해결할 수 있으면 충분하다. 완벽한 문제를 찾을때까지 한없이 기다리는 것은 비효율적이다.
"시간,돈,인력,경험이 부족해."질질 짜는 소리는 이제그만.
오히려 적을수록 좋다.
제약은 저주의 가면을 쓴 축복이다.
자원이 부족하면 현재 가진 것을 최대한 활용해야 한다. 다시 말해, 낭비가 사라진다.
그리고 제약 속에서 창의적인 아이디어가 나온다.
내용 설명 옆에는 내용과 이어지는 삽화가 이어지는데 책을 보는데 지루하지 않게 해줍니다. 이 내용을 요약해서 발표한다고 했을때 이 삽화들만 모아놓아도 훌룡한 발표자료가 될거 같네요.
책 끝까지 단편적인 조언이 나열되는 점이 약간은 지루하다고 느꼈습니다. 뭔가 스토리가 이어졌으면 더 좋았을걸 하는 생각이 드네요.
요즘 개발 감에 많이 떨어졌다는 것을 새삼 느낍니다. 그래서 수련을 한다고 생각하고 옆에 있는 동료의 책을 빌려서 읽어봤습니다. 책을 빌려주신분 왈 "큰 감동은 없던데요.!" ^^;
디버깅에 대해 참 많은 내용을 담고 있습니다. 뭐 이런것까지 할만한 소소한 부분에서 버전관리나 CI와 같은 관련 내용까지. 그러다 보니 책이 분량에 비해 약간 지루했습니다. 책에 등장하는 여러 팁중에 제게 신선한 몇 가지만 옮겨 봤습니다.
p74 '차이점에 집중한다.' - 사소한 차이점 때문에 문제를 재현할 수도 있다.
p75 '오캄의 면도날Occam's Razor' 다른 모든게 같다면 가장 쉬운 설명이 가장 좋다.
p76 '디버깅은 순간이지만 테스트는 남는다.' - 디버깅에서 TDD의 중요성을 강조하는 부분에 나온 말인데 자동화된 테스트에도 해당합니다.
p84 '문제를 설명하는 것이 생각을 정리하는데 도움이 된다.'
p113 '코드의 가독성'
p146 'SWAT 팀' - 특정 문제 해결을 위한 소규모 팀이 필요하다는 의미인데 직접 저런 팀을 이끌어 본 경험에 비춘다면 SI 같은 대규모 조직에는 꼭 필요하지 않나 생각합니다.
p203 'Assert' 을 이용한 코딩' - 스스로 디버깅 하게 만들기에 등장합니다. 얼마전 동료가 알려준 내용인데 여기서도 나오네요.
저도 큰 감동은 없었지만 개발자들이 한번 꼼꼼히 읽어보고 자기에 유용한 내용을 잘 익혀두면 디버깅이 어려울 때 요긴할거 같습니다.
책은 프롤로그와 사례연구로 시작합니다. 그런데 사례연구가 "덴버공항과 미국 항공 교통 통제시스템(AAS)"이어서 조금 실망했습니다. 국내 SI 프로젝트 사례가 나올거라 예상했거든요.
좀 더 책을 읽어봤습니다. 개념을 설명하는 부분에서 많은 인문학적 사유나 인용이 등장합니다. 메타포를 이용한 설명은 저도 좋아하는 편입니다만 해당 개념을 설명하는데 어떤 관련성이 있는건지 잘 이해가 안가서 다시 저자 이력을 봤습니다. "박사네" 솔직히 이쯤에서 책을 그만 읽을까도 고민했습니다. 개인적으로 코딩 한줄 못하는 아키텍트나 컨설턴트의 노가리가 아닌가 하는 생각이 들었거든요. 책 곳곳에 등장하는 저자 경험으로 비추어 보면 그건 아닌것으로 보여서 또 읽어봤습니다.
TDD에 대한 내용이 나옵니다. 조금 옮겨 봤습니다.
TDD로 여러 차례 개발을 진행해 봤다. 그때마다 느낀 것은 요구사항을 분석해야 한다는 무거운 짐으로부터 개발자들을 해방시킨다는 것이다. 개발자들은 단순히 사용자의 요구사항을 말로 듣고 그 순간부터 즉각 개발에 착수한다. 무엇을 개발할 것인가는 테스트 케이스로 간단하게 선언한다. 개발자가 선언한 테스트 케이스가 맞는 것인가는 2주일 후에 고객과 함께 작성한 프로그램을 검토함으로써 확인할 수 있다.
전 2가지 점을 이야기 하고 싶습니다. 첫째는 TDD에서 정의하는 Test Case가 요구사항을 대체할 수 있을정도로 크지 않습니다. TDD가 일정 수준의 디자인을 대체할 수 있지만 요구사항 자체를 TDD로 대체할 수 있을지는 의문입니다. 둘째로 고객이 TDD로 작성한 테스트 케이스가 맞는지 확인해 줄 수 없습니다.FitNesse와 같은 ATDD, BDD를 통해 유비쿼터스 언어로 Test Case를 작성하면 혹시 가능할 지 모르겠네요. SI 프로젝트 10년하면서 그런 고객은 본 적이 없습니다. 그런 고객이 있었다면 지금과 같은 SI 프로젝트 현실이 생겼을까요? 그러면 좋다는 의미로 이해하렵니다.
SI 프로젝트가 정치판이라는 의견에도 십분 공감합니다. 하지만 그렇다고 개발자도 꼭 정치적이 되어야 하는걸까요? 프로젝트에는 희생이 따른 다는 의견도 많이 보입니다. 맞는 말입니다만 그걸 피하기 위해서 정치적이 되어야 하는지는 잘 모르겠습니다. 저도 프로젝트에서 열심히 일하고 팀에서는 평가를 제대로 받지 못했던 적도 많았습니다. 오히려 고객이 걱정을 해준적도 있으니까요. 그런 경험을 통해서 저는 노력을 제대로 평가받는 방법을 배웠던것 같습니다. '포장술'이라고 하면 될까요.
'소프트웨어 개발은 프로세스라기보다 일종의 협동 작업이라고 봐야 한다.' 'WBS는 팀의 의욕을 떨어뜨린다. 작업 속도는 각 팀마다 고유한 것인데 WBS는 이것을 일정이라는 틀로 지시하려는 것이다.'
WBS에 대한 적절한 표현이라는 생각이 듭니다. 항상 WBS 작성에 대한 반박논리가 궁색했는데 좋은 무기를 얻은거 같아 기쁩니다.
'내가 하지 못할 일을 남에게 강요하지 말라' 지원 업무를 하면서 저자가 가졌던 원칙이라고 합니다. 100% 동감합니다. 저도 지원업무를 해봤고 지금도 하고 있습니다만 무슨 관리자인냥 행동하는 사람들을 많이 봤습니다. 꼴보기 싫습니다.
'소프트웨어의 품질관리에는 한계가 있으며 우리는 개발자를 신뢰하는 것 외에는 특별한 품질관리 방법이 없다.' 50% 공감합니다. 개발자마다 다를 수는 있다고 생각합니다. 스스로 품질관리를 할 수 있는 개발자라면 더 많은 자유를 주어야 하지만 능력이 안되는 개발자를 신뢰하는 것은 품질을 망칠수도 있습니다.
'긍정적인 사고방식이 우리의 적극적인 행동을 이끌어낼 것이라는 것은 분명해 보인다. 하지만 긍정적인 사고방식만으로는 일이 성공할 수 없다.' 저는 이 부분을 읽으면서 스크럼과 XP에 대해 생각했습니다. 스크럼을 도입하면 사람들이 긍정적으로 열심히 참여하게 만들지만 이것만으로는 부족합니다. 내가 맡은 업무가 실질적으로 개선되도록 해야 하는데 이때 XP의 실천법이 많은 도움이 됩니다.
맘에 드는 부분도 있고 수긍이 가지 않는 부분도 많았습니다. 저도 10년 넘게 일했던 분야고 저자가 경험한 분야를 대부분 겪어봐서 그런것 같습니다. 괜히 옛날 힘들었던 기억이 나서 두번 읽을거 같지는 않네요. ^^;
신년에 태어난 딸 덕분에 설을 집에서 보내게 되어 시간이 났습니다. 요즘 ATDD를 관심있게 보고 있어서 TDD를 좀 더 깊이있게 공부하고 싶어 집어든 책이 LG CNS 채수원님이 2010년에 집필하신 테스트 주도개발 TDD 입니다.
사실 TDD에 대한 책은 TDD를 처음 만든 켄트벡이 쓴 책도 있습니다.(내심 수원님 책 주제를 잡을때 힘들지 않았을까 하는 생각이 드네요. ^^;) 하지만 이 책은 다른 책과 비교했을때 다음과 같은 차별성이 있습니다.
처음 TDD를 시작하는 사람들의 눈높이에 잘 맞게 쓰여져 있습니다.
다양한 도구들에 대한 가이드가 알차게 들어가 있습니다.
TDD에 대한 다양한 생각과 경험이 잘 녹아 있습니다.
TDD에 대해 어느정도 지식을 가지고 있던 저에게는 아래와 같은 부분들이 참 좋았습니다.
Hamcrest와 같은 JUnit4의 새로운 기능을 더 깊이 이해할 수 있었다.
Test Double, Stub 등 TDD에서 흔히 사용되는 개념들이 명확해 졌다.
Mock 프레임워크에 대한 인식이 바뀌었다.
아쉬웠던 점은 TDD 프레임워크에 대한 설명에 비해 BDD나 다른 애자일 실천법과 TDD에 대한 다양한 시각(8장)에 대한 분량이 적은게 가장 아쉬었습니다. (블로그에 적어 주세요. ^^) 근래 TC를 작성하며 느낀 여러가지 생각들도 정리해 보면서 몇 가지 팁도 얻을 수 있는 좋은시간이었습니다.
뽀모도르 테크닉(Pomodore Technique)은 프란시스코 치릴로(Francesco Cirillo)가 1992년에 처음 소개한 시간 관리방법입니다. 뽀모도르(Pomodoro)는 이탈리아말로 토마토(Tomato)를 의미(출처:Wikipidia)하는데 그가 처음 사용한 주방시계가 토마토 모양이었던것에서 따왔다고 합니다.
25분간의 짧은 이터레이션(뽀모도르) 수행
1번 뽀모도로 수행후 5분 쉰다.
4번 뽀모드로 수행후 긴 휴식(30분)을 갖는다.
이 문서의 원본은 http://www.pomodorotechnique.com 에서 다운로드가 가능하며 치릴로가 쓴 뽀모도르 테크닉에 대한 책도 다운로드가 가능합니다. 아래 어떤분이 블로그 포스트 제목으로도 쓰신것처럼 스크럼과 매우 유사하구요. 일전에 애자일 컨퍼런스에서 이 기법을 발표하는 세션도 있었던것으로 기억합니다.
뽀모도르 테크닉을 잘 사용하기 위해서는 타이머가 필수입니다. PC에서 동작하는 괜찮은 타이머로 Focus Booster(http://www.focusboosterapp.com/)를 추천합니다. Adobe Air를 기반으로 간단하게 설치가 가능하며 설정메뉴도 타이머 시간과 휴식시간등으로 간단해서 좋습니다.
뽀모도로 테크닉을 직접 사용해보니 25분을 집중하는게 쉽지 않다는 사실을 깨달았습니다. 스스로 집중을 잘한다고 자부했는데 아니더군요. OTL 중간에 내부/외부 인터럽트가 이렇게 많이 발생하는지 몰랐습니다.
그리고 하기는 해야 겠는데 끝이 안보여서 하기 싫은 일을 할때도 효과가 좋다고 느꼈습니다. 일은 끝이 보이고 마무리가 되어야 신나서 하는데 그런 순간은 끝나기 직전 뿐이죠. (발표에서는 마감효과로 설명했던거 같네요.[2]) 25분만 열심히 하자를 외치면서 꾸역꾸역 했던거 같습니다. 뽀모도로가 일을 하다가 생기는 불안을 덜어준다고 느꼈습니다. 적어도 25분간은 계속 일을 할수 있겠지. 혹시 하는일이 딴짓(?)이어도 25분 쯤이야 하면서 걱정을 안하게 되는거 같습니다.
끝으로 집중하는 시간이 점점 길어지는것 같습니다. 25분에 끝내기 싫어지는 느낌. 더 오래하고 싶은데..^^; 아래 책의 저자는 일단 25분이라는 프레임을 지키라고 합니다만 가끔은 벗어나는 것도 좋은거 같네요.
일하는것 만큼 중요한게 휴식입니다. 휴식시간까지 타이머를 맞추는건 오히려 편안하지 못한거 같습니다. 그 보다는 좋은 음악을 1~2곡 듣는것도 좋네요.
뽀모도로의 원리나 더 잘하기 위해서는 어떻게 해야 하는지 궁금하신 분들은 인사이트에서 출간된 책을 보시는것도 좋을거 같습니다.
예쁜 일러스트와 마인드맵 그리고 짤막한 설명이 책을 술술 넘어가게 해주네요. 책의 각 장마다 등장하는 '오이와 양상추'의 대화도 참 재밌습니다.
책 앞쪽에 이런 구절이 나옵니다.
뽀모도드 테크닉은 유치원에 다니는 내 딸도 이해할 정도로 매우 사용하기 쉽다. 그럴듯한 도구도 필요하지 않고, 프로세스 산출물을 만드는 데 반나절이나 보내지 않아도 된다. 바로 옆에 붙어서 포괄적인 용어를 설명하는 프로세스 코치가 필요하지도 않다.
이 부분을 읽고 얼마전 진행한 스크럼 교육이 떠 올랐습니다. 몇 시간을 진행했는데 그게 정말 필요한 교육이었던 걸까? 어쩌면 별거 없는데 괜히 이러쿵 저러쿵 떠들어서 듣는 사람들에게 더 많은 혼란을 준건 아닐까? 가볍고 단순해서 이해하기 쉬운 스크럼을 돈벌이를 위해 괜히 어렵게 만들고 있는건 아닐까?
처음 컴퓨터라는 물건을 본것이 중학교 2학년때 입니다. 당시 최신기종이 8086 CPU에 20메가 하드 디스크, 5.25인치 플로피 디스크가 들어있는 XT 였는데, 한창 PC게임에 빠져 밤새던 기억이 나네요. ^^; 이 책 코드를 읽다가 어린시절이 떠올랐습니다. (19장 두가지 고전적인 마이크로프로세서들)
코드에 대한 또 다른 에피소드가 있습니다. 아래 그림을 한번 보시죠. 왼쪽에 있는게 코드 원서고 오른쪽에 있는게 번역서입니다. 3년전 어떻게 운이 좋아 가게된 레드먼드 마이크로소프트 캠퍼스 북샵에서 사왔습니다. 어떤 책인지도 모르고 책이 너무 예뻐서 집어온게 찰스페졸드의 책이었습니다. 그때 이야기가 궁금하신 분들은 아래 포스트를 읽어보세요.
역자서문에도 나오는 것처럼 찰스페졸드하면 윈도우즈 프로그래밍의 대가입니다. 저 역시 이분 책으로 윈도우 프로그래밍을 공부했으며, 몇년 전에는 이분의 책을 한권 번역했습니다. 1000페이지가 넘는데도 그 흔한 스크린샷 하나 없이 코드를 세밀하게 설명하는 덕분에 고생 무지 했네요.
교육과정 개발, 발표, 번역등 정신없이 지내다 보니 3월이후 제대로 책 한권을 읽지 못했네요. 그래서 큰 맘먹고 다른 일을 다 미룬채 인사이트에서 새로 출간된 『프로그래머의 길, 멘토에게 묻다』를 읽었습니다.
책은 판형도 작고 페이지수도 300페이지가 안되어 한 손에 쥐고 소파에 기대 느긋히 보기에 딱 좋게 만들었네요. 게다가 책 앞쪽에 60페이지 정도가 서문에 해당합니다. 이 부분을 제외한다면 본문은 240페이지 정도여서 단숨에 읽을 수 있습니다.
전 맨 앞에서부터 차근차근 읽어가는 스타일이라 서문이나 감사의 글까지 꼼꼼히 보는편인데 이 책은 그런 부분이 좀 많은것 같습니다. 왜 그런지는 본문을 읽다 보니 알거 같네요. 수 많은 사람들의 인터뷰가 각 패턴별로 실려 있다보니 감사할 사람이 많았던거 같습니다. ^^; 게다가 장인정신, 견습과정등에 대한 정의를 깊이 고민했던 흔적이 서문에 잘 나타나 있습니다.
제목에서도 알수 있듯이 이 책은 프로그래머의 견습과정에 대한 가이드를 제시해 주는 책입니다. 근데 왠지 견습생이라는 말을 들으니 도널드 트럼프의 Apprentice에 나오는 말이 떠 오릅니다.
You're fired.
각 패턴은 주제별로 그룹핑이 되어 관련 주제별로 패턴을 살펴보기 쉽게 되어 있으며, 각 패턴들은 여느 패턴들 처럼 자신만의 스타일을 가지고 있습니다.: 상황, 문제, 해결책, 실천방안
이 책이 이 네가지 요소만을 반복적으로 설명했다면 참으로 지루한 책이 되었을거 같습니다. 하지만 각 패턴마다 사람들의 경험이 묻어나는 인터뷰가 실려 있어서 이를 읽다보면 정말 멘토가 충고를 해주는 느낌을 받게 됩니다.
어떤 분야든지 탁월한 이들을 연구하는 데서 많은 것을 배울수 있다.
그런데 패턴의 제목만을 보고 "아 이건 나한테 필요 없겠는데" 하고 넘기지 말라고 충고하고 싶습니다. 원서를 안 봐서 잘은 모르겠습니다만 원서에 충실하다 보니 느낌이 안사는 패턴 제목들이 좀 있습니다. 몇 개 제목을 그냥 제 맘대로 다시 풀어봤습니다.
'예술 보다는 기예'패턴 -> '예술작품을 만들기 보다는 실용적인 도구를 만들어라'
'깊은 쪽'패턴 -> '한 분야를 깊이 파라'
'열정을 키워라'패턴 -> '비록 현실은 막장이어도 열정을 키우기 위해 노력하라.'
이런 생각 때문인지 패턴의 형식을 빌지 않고 조엘온 소프트웨어 처럼 편하게 풀어서 썼다면 더 좋지 않았을까 하는 생각도 들었습니다.
하지만 내용을 읽다보면 도움되는 이야기들이 많이 적혀 있습니다. 특히 열정을 키워라 패턴은 제 후배들이 꼭 봐야 하는 패턴이라는 생각이 듭니다. :-) '구체적인 기술' 패턴에 이런 말이 나옵니다.
우리가 당신을 채용한다면 출근 첫 날 회사에 어떤 기여를 할 수 있나요?
이력서를 자주 업데이트해야 합니다라는 충고보다, 멘티에게 이런 질문을 하나 던진다면 더 마음에 와 닿을거 같습니다.
역자서문에도 나옵니다만 IT를 3D, 4D로 분류하는 현실은 이미 누구나 다 알고 있습니다. 서울대 컴퓨터 공학과가 근 5년간 정원을 채우지 못했다는 기사를 읽은게 불현듯 생각나네요. 우수한 학생들이 IT를 기피하고, 그나마 잘하던 사람들도 관리자나 다른 업종으로 떠나면서 좋은 개발자 만나기는 정말 하늘에서 별따기처럼 어려워 진거 같습니다. 우수개 소리로 저희 회사 선임은 '산삼'이라고 부릅니다. ^^;
그렇지만 개발이 재밌고 좋아서 이 길을 선택한 사람들이 아직은 많이 있다고 믿고 있으며 저 스스로도 그런 사람이 되려고 노력합니다. 개발자들이 현실속에서 자신이 어떤 길로 나아가야 할지 고민할때, 슥 펴서 읽어보고 힘을 얻는 책이 될거 같습니다. 하지만 패턴이니 그대로 적용해서는 안된다는걸 잊지 마시길.
패턴은 기계적으로 적용하지 않고 자신의 상황에 맞게 변경해도 됩니다.
저도 언젠가는 이런 책을 한권 써야 할텐데...'긴 여정' 패턴이나 읽어야 겠네요. :-)
연휴를 맞아서 오랜만에 서점에 갔습니다. 평소 읽고 싶은 책을 아이폰에 적어놓는 덕분에 이제는 서점가서 무슨 책을 볼지/살지 고민할 필요가 없습니다.
일본의 실용서 답게 책도 얇고 읽기 좋게 구성되어 있습니다. 개인적으로 일본 번역서는 깊이가 얇다는 생각이 들어서 가끔 실용서만 보는 편입니다.
이 책 야근제로 업무 기술은 저자인 요시코시 고이치로 사장이 10년간 자신의 회사에서 어떻게 야근을 근절해 나갔는지를 정리해 놓은 책입니다. 이 책에서 말하는 야근의 가장 큰 폐혜는 바로 이겁니다.
야근의 가장 큰 폐혜는 문제를 가시화해서 개선할 수 있는 기회를 빼앗는 다는데 있다.
문제의 본질을 해결하려 하기 보다는 농업적 근면성으로 꾸역꾸역 해결해 나가는 겁니다.(어디서 많이 들어본 이야기 같네요.) 일본과 우리나라는 근무 강도가 높기로 유명합니다. 평균 근무시간이 서구권에 비하면 상상을 초월합니다. 그렇기 때문에 아시아 기업이 발전해 나가는게 과연 맞는 걸까요?
같은 조건으로 싸워서 이겨야 진짜 이기는 것이다.
책에서 이야기 하는 야근제로를 위한 여러 방법을 7개 팁으로 정리해 봤습니다.
팁1: 마감시한으로 스피드와 집중도를 높인다.
팁2: 문제해결에 집중하라.
팁3: 마감 관리상자
팁4: 아침회의
팁5: 야근에 대한 반성의 시간을 갖자.
팁6: 업무를 개인단위로 세분화 하라.
팁7: 야근 금지 데이 깃발을 도입하라.
각 방법들을 읽어보면서 애자일에서 말하는 기법과 유사하다는 생각이 많이 들었습니다. 팁3: 마감 관리 상자는 GTD나 백로그에서 남은 작업시간을 관리하는 것과 유사해 보입니다.
팁4: 아침회의는 그냥 아침에 회의를 하는게 아닙니다.
- 업무를 작게 쪼개고
- 한개 안건을 처리하는데 걸리는 시간을 2분으로 제한하며
- 회의를 정보 공유의 장으로 봅니다.
업무시작전에 하는거나 타임박싱을 이용하는것, 정보공유 측면에서 본다면 '일일 스크럼 미팅'과 비유할 수 있습니다.
팁2, 팁5는 과거를 반성하고 더 나은 방안을 찾아간다는 면에서 '회고'와 유사합니다.
팁6: 업무를 개인단위로 세분화하라는 의미는 중간에 인터럽트가 걸리면 업무효율이 떨어지니 미리 개인별로 업무를 잘 할당하라는 의미 입니다. 어느정도로? 다른 사람과 떨어져서 각자 자기방에서 일해도 업무가 가능할 정도로 해야 합니다. 백로그를 통해 각자 할일을 잘 정의해서 나누는 것과 유사하지 않나요.
굳히 연결고리를 찾으려 노력한건 아닙니다만 자연스레 그런게 보인걸 보면 애자일의 기법이나 원칙이 결국 일을 잘하고자 하는 고민에서 나왔기 때문이 아닐까 하는 생각을 해봤습니다.
야근을 없애기 위해서는 최고 경영자의 의지와 직원의 역량강화가 필요합니다. 무조건 야근을 하지말라고 한다고 되는게 아닙니다. 근무시간내에 업무를 끝낼 수 있는 환경이 조성되야 합니다. 과거 저희 회사가 7/4제를 도입했을때 갑자기 불을끄고 모두 나가라고 하니 나갔다가 나중에 다시 들어와서 일했다고 하던데요. 비슷한 일화가 책에도 나오네요.
끝으로 이 책은 이런 질문을 던집니다.
일하기 위해서 사는가, 살기 위해서 일하는가
(Life for work or Work for life)
고기도 먹어본 사람이 먹는다고 인생도 즐기기 위해서는 준비가 필요합니다. 즐거운 인생을 살기 위해 일하는 사람이 되어야 겠습니다.
사내에서 애자일을 통한 야근제로 운동이라도 벌여볼까 합니다. 그냥 하는것 보다 좀 더 먹히지 않을까요. 트위터에 #Yagndang 리스트가 있던데 #YagnZero 리스트 어떠세요? ^^
제목이 마음에 들어서 선택한 책입니다. '뭐 별 내용이 있을까? 잡스 이야기가 또 나오겠군' 하며 집어 들었는데 대박 이었습니다. 년초에 정말 괜찮은 책을 하나 건졌습니다. 책을 읽으면서 마음에 드는 구절을 적어 두는 습관이 있는데 포기했습니다. 구구절절 적어두고 싶은 내용이었습니다.
책의 편집도 적절한 사진을 전체 페이지로 배치에서 지루한지 모르고 책을 볼 수 있고, 경제학 초보자인 제가 봐도 읽는데 어려움이 없을 정도로 설명도 친절합니다. 적다가 포기했지만 몇 가지 적어놓은 마음에 남는 구절을 옮겨 봅니다.
동성애자와 보헤미안들이 경제 성장을 이끈다.
힘은 규칙을 준수하는 자(rule taker)에서 규칙을 깨트리는 자(rule breaker)와 규칙을 창조하는(rule maker)에게로 옮겨지고 있다.
이집트인들은 피라미드를 지었다. 그리스인은 아크로폴리스를 남겼다. 로마인들은 콜로세움을 남겼다. 현대의 대표적인 건축물은 쇼핑몰이다. 사람들은 특징적인 소비활동을 통해 자신들의 개성을 표현한다.
선진국들이 계속 성장하는 이유는 가장 강력한 통화인 지식을 통제하고 창출하기 때문이다.
현대인들은 일할 시간을 만들기 위해 가족을 아웃소싱하고 있다. 아이들을 봐줄 사람, 정원을 돌볼 사람, 청소를 담당할 사람, 그 밖의 가사일이나 가족과 관련된 일을 돌봐줄 사럼을 고용한다.
두려움은 자유에 대한 현기증이다. 자유는 중독성을 가지고 있으며, 책임은 자유의 부작용이다.
오늘날 희소자원은 투자액이 아니라 상상력이다. 능력은 당신에게 선택권을 선사해 준다. 능력은 정치가,자본가들보다 당신이 더 높은 힘을 가질수 있게 해 준다.
회사의 기술지식 중 20%가 매년 상업적으로 무가치한 것이 된다. 조직은 속도를 높여야 한다.
죽은 말을 타고 있다는 사실을 알았을 때, 가장 좋은 전략은 말에서 내리는 것이다.
성공적인 리더는 설득력 있는 단순성으로 자신들의 일을 보여준다. 간결함이 생명이다.
쇼팽의 '1분 왈츠'를 속도를 2배로 높여서 30초 안에 들어 봤자 소용없는 것처럼, 효율성으로 혁신을 평가할 수는 없다.
마시멜로 이야기에서 말하는 첫번째 화두입니다. 2005년 "Don't Eat the Marshmallow...Yet!'은 번역되자 마자 베스트셀러가 됐지만 정지영 아나운서 번역 파문이 일면서 논란이 됐습니다.
'선물','선택'등으로 유명한 스펜서 존슨의 우화집 처럼 이 책도 어릴적 마시멜로 실험에 참여한 적이 있는 조나단이 그의 운전시가 찰리에게 '눈 앞에 마시멜로를 먹지마라.'는 충고로 시작합니다. 책을 읽다 보면 자연스레 내가 무엇을 하며 살아야 할지 뚜렷해 지는 느낌입니다.
어떤 일을 결정해야 하는 순간에 섰을때 딱 30초만 더 생각하라.
망설이라는 의미가 아닙니다. 정말 그 결정이 옳은지 생각하는 30초는 잘못된 결정을 할 수 밖에 없는 상황에 여유를 갖게 해 줍니다.
조나단의 아버지는 조나단에게 '아프리카의 가젤과 사자' 이야기를 들려줍니다. 인터넷에 이 이야기를 동영상으로 만든게 있어 옮겨 봅니다.
더보기
아프리카에서는 매일 아침 가젤이 잠에서 깬다.
가젤은 가장 빠른 사자보다 더 빨리 달리지 않으면 죽는 다는 사실을 알고 있다.
그래서 그는 자신의 온 힘을 다해 달린다.
아프리카에서는 매일 아침 사자가 잠에서 깬다.
사자는 가젤을 앞지르지 못하면 굶어 죽는 다는 사실을 알고 있다.
그래서 그는 자신의 온 힘을 다해 달린다.
네가 사자이든, 가젤이든 마찬가지다.
해가 떠오르면 달려야 한다.
책에서 제일 중요한건 내용입니다. 하지만 그 만큼 중요한 것은 '컨셉'이라 생각합니다. 이 책의 컨셉을 잘 요약해서 알려주는 부분이 있습니다.
마시멜로라는 새로운 패러다임을 적용하고 나자 모든 것이 뚜렷하게 보였다.
프랭클린 플래너, GTD 등의 도구들을 쓰면서 게을러지는 자신을 붙잡기 위해 노력합니다만 이 책은 한 마디로 사람을 '훅'가게 만듭니다. ^^
2010년 1월1일 새해 첫날 우연히 이 책을 봤습니다.(글 보다는 사진이 많아 읽었다기 보다 봤다는 편이 더 맞는듯 합니다.)
이 책은 아티스트 미란다 줄라이와 해럴 플레처가 2002년 부터 7년간 진행했던 <나를 더 사랑하는 법> 프로젝트에 참여했던 많은 사람들의 과제중 일부를 책으로 엮은것 입니다. 프로젝트는 끝났지만 그 결과는 http://www.learningtoloveyoumore.com 에서 지금도 볼 수 있습니다.
유사한 프로젝트를 한국에서 진행했던 결과물들이 또 하나의 책으로 같이 제공됩니다. <나를 더 사랑하는 법> 한국 프로젝트는 여기에서 확인 가능합니다.
책을 번역하고 한국 프로젝트를 진행하신 분은 김지은 아나운서 입니다. 연예인 젬병이지만 출발 비디오 여행을 즐겨봤던 탓에 기억합니다. ^^ 15년간 아나운서로 활동했으며 <서늘한 미인>, <예술가의 방>이라는 책을 낸 이력이 있습니다.
책의 내용은 수행했던 과제를 순서대로 보여줍니다. 그런데 이 과제를 수행했던 방식이 사람마다 다양한게 많은 재미를 줍니다. 주제들도 한 번쯤 따라해보면 좋을만한 것들이 많이 보입니다.
과제10. 자신의 하루를 전단지로 만들어 보기.
과제14. 지금까지 살아온 이야기를 써보기.
과제50. 플래시 터트린채 침대 아래 사진찍기.
과제63. 응원의 게시물 만들기.
사람들은 이 과제들을 자기만의 방식으로 수행하고 그걸 사진으로 찍어 올렸습니다. 아래는 과제 63중 하나입니다.
자기 개발서에도 종류가 여러가지 있습니다만 이 책은 얼마전 나온 아웃라이어와 내용이 비슷합니다. (실제로 책중에 10,000시간의 법칙도 언급됩니다.) 이 책의 핵심은 심층연습입니다.
그럼 책에서 말하는 심층연습은 뭘까요?
심층연습은 역설을 바탕으로 한다. 바보같아 보일만큼 수없이 실수를 허용할수록, 즉 정확히 목적에 맞는 노력을 기울이면서 끈질기게 물고 늘어질수록 더 많이 향상된다.
하지만 무조건 연습한다고 되지 않습니다. 심층연습을 위한 조건이 두가지 있습니다.
정확성: 현재 능력보다 살짝위에 있는 목표를 선택하고, 정확히 목적에 맞는 노력을 기울이는것이 요령이다.
천천히: 얼마나 빨리 할 수 있느냐는 중요하지 않습니다. 얼마나 천천히 정확하게 할 수 있느냐가 중요하죠. 스킬의 내면적 청사진, 다시 말해 서로 맞물려 있는 스킬 회로들의 형태와 리듬을 효과적을 인식할 수 있게 된다.
이 조건을 읽다 생뚱맞게 일본 아니매 드래곤볼 Dragon Ball 이 생각났습니다. 샤이아인은 죽을 고비를 넘긴다음 엄청 세지는데 책에서 말하는게 딱 그 그상황에 들어맞습니다. ^^
좋은 코치는 학생에 맞는 적절한 양의 코칭을 하는 사람이라고 생각합니다.
책을 읽다 보니 프로젝트 생각으로 넘어갔습니다. 프로젝트에서 이슈를 찾는 효과적인 방법은 페어프로그래밍을 시키고 관찰하는 거라고 생각합니다. 대화를 듣고 행위를 살펴보면서 문제점을 찾고 거기에 집중합니다. 의외로 문제는 간단할 때가 많습니다.
소프트웨어 개발에 있어 가장 중요한 가치는 어디에 있는가? 누가 결정하는가?
이런 질문에 답을 줄 수 있는 사람은 고객뿐입니다. 하지만 이 책에서는 고객을 단순히 고객으로 보지 않고 이해관계자로 그 영역을 넓혀서 이야기를 진행하며 역할에 따라 상세하게 구분하고 있습니다.
내부관계자
주관계자
최종사용자
협력관계자
사실 책 자체는 조금 지루합니다. 어찌보면 당연한 이야기를 여러측면에서 설명하는데 그 답은 결국 하나로 귀결됩니다. 하지만 이해관계자의 시각에서 생각해야 할 내용들을 엿볼 수 있습니다. 소비가능성(consumability), 린 6시그마등에 대한 설명은 새로운 내용이어서 재밌게 봤습니다.
책중에 "이해 관계자의 관점에서 성공을 정의하라"는 부분이 나오는데 퍼뜩 이런 농담이 생각나더군요.
수술은 성공했습니다. 하지만 불행하게도 환자는 사망했습니다.
뭐가 성공했다는 걸까요? 환자의 병이 낫는것을 성공으로 봐야 하지 않을까요. 책에서 인용한 톰 포펜딕의 말로 마무리 합니다.
요구사항의 잦은 변경은 프로젝트 초기에 팀이 상세한 계획을 수립하려고 지나치게 구체적인 의사결정을 너무 일찍 내리기 때문이다. 이해관계자의 목표를 이해하고 내부관계자의 제약조건을 충족 시키기 위해 필수적으로 해야 할 피드백을 받기도 전에 말이다.
넛지는 사람들에게 어떤 선택을 금지하거나 경제적 인센티브를 크게 변화시키지 않고 예상 가능한 방향으로 그들의 행동을 변화시키는 것입니다.
이 넛지의 예는 여러곳에서 찾아볼 수 있는데 적절한 디폴트 옵션은 넛지의 부드럽고 강력한 힘을 보여줍니다. 하지만 '정크 푸드 금지' 와 같은것은 넛지가 아닙니다.
넛지를 잘 이용하면 큰 효과를 가져올 수 있습니다. 책에 등장하는 간단한 사례를 하나 소개하겠습니다.
어느 공항에서 남자 소변기 주변이 더러워지는 것 때문에 골치를 앓고 있었습니다. 문구를 붙여놔도 소용이 없던차에 간단한 아이디어로 이 문제를 멋지게 해결했습니다. 소변기 중앙에 검정색 파리를 그려 넣은 것이죠. 그러자 변기 밖으로 튀는 소변의 양이 80%나 감소했습니다.
선택을 설계하는 사람(Choice Architect)은 넛지의 본질을 알아야 합니다. 설득과 선택이 중요한 요즘에 한번 쯤 읽어볼 만한 책인거 같습니다.
임백준님이 2003년에 쓴 알고리즘에 대한 책입니다. 기존의 딱딱한 알고리즘 책과 달리 말랑말랑하게 풀어쓴 책입니다.
그렇다고 내용이 없는건 절대 아닙니다. DFS와 같은 가벼운 알고리즘에서부터 RSA까지, 다양한 알고리즘을 임백준님 특유의 스타일로 편안하게 풀어내고 있습니다.
p20 아무리 간단한 코딩이라고 해도 프로그래머는 '실수'로부터 자유롭지 못한 인간이기 때문에 꼼꼼한 테스트는 '선택'이 아니라 '필수'다. 간단한 테스트를 통해서 미리 발견할 수 있었던 버그를 실제 사용자가 발견하는 것은 비용의 손실이기 이전에 프로그래머의 수치다.
p46 버그를 찾는 것은 프로그램 언어의 문법적 측면에 대한 지식을 요구하기도 하지만 보다 근본적으로는 '논리'를 정확하게 끌어 나가는 힘을 필요로 한다.
p48 프로그래밍에서 발생하는 버그는 많은 경우에 특정한 알고리즘 자체가 품고 있는 논리적 결함보다는 프로그래머가 방어적 프로그래밍(defensive programming)을 게을리해서 발생하는 경우가 더 많다.
p53 버그를 찾는 일은 대부분 끈기와 집중력을 테스트하는 과정이다. 기발한 상상력이나 톡톡 튀는 아이디어보다는 복잡하게 꼬인 논리의 실타래를 한 올 한 올 끈질기게 풀어가는 끈질감이 가장 중요한 덕목이기 때문이다.
알고리즘 자체에 대한 관심은 사실 별로 없었는데 이 책을 읽으면서 더 나은 엔지니어가 되기 위해서는 논리적인 사고를 키워야 겠다는 생각이 들었습니다.
존 고든의 전작 '에너지 버스'의 후속작입니다. 전작을 너무 재밌게 봐서 그런가요. 전작에 비해 그다지 감동이 덜했습니다. (이래서 속편이 흥행에 성공하기 어려운거 같습니다. ^^)
학습된 무기력(Learned Helplessness) by 마틴셀리그먼
자신이 전혀 제어할 수 없다고 느끼는 특정한 환경에 지속적으로 놓여 있던 사람은, 그 환경을 바꿀 아주 쉬운 방법이 생겨도 결국 아무것도 시도하지 못하고 무기력한 상태에 머물게 된다.
이런 학습된 무기력에 빠진 회사를 '불평금지'라는 전략으로 구해내게 됩니다. 단순히 불평을 못하게 막는것이 아니라 불평을 해야 하는 상황에 긍정적 커뮤니케이션을 이끌어 내는 것 입니다.
무조건 적인 소통은 대안이 아니다. 강압적인 경쟁 부추기기도 대안이 아니다. 필요한건 신뢰와 희망을 바탕으로 한 공유이다.
어느 조직에나 무조건적인 반대를 일삼는 사람이 있습니다. 이런 사람들에게 일침을 가하는 이야기라 생각됩니다. 책을 읽다보면 UCLA의 유명한 농구팀 감독 존우든의 일화가 등장합니다. 이 감독은 '이기는 것'에 초점을 맞추지 않고 선수들을 '계발'하는것에 집중합니다. 기본기, 기술, 개성, 팀워크를 강조함으로서 UCLA 농구팀을 최고의 팀으로 키워내게 됩니다.
책을 읽고 느낀점을 정리합니다.
첫째, 저도 새로운 팀에서 역량강화를 맡고 있는데 어떻게 나아가야 할지 비전을 세우는데 도움이 될거 같습니다.
둘째, '불평금지'를 교육과정에서 그라운드룰로 정해도 좋을거 같다는 생각이 들었습니다.
ThePomodoroTechnique-CheatSheet.doc
