이 책이 담고 있는 내용은 말 그대로 열악한 환경이 개선되길 바라는 동시에, 그 변화를 주도해야할 개발자의 처신(?)도 씌여져 있다. 자신이 겪어온 현실에 대한 이야기가 바탕이 되어 있는 탓에 은연 중에 공감이 되기도 하고, 현재 배우고 있는 부분이 가장 기초적이라는 것에 공감이 되기도 했다.

 하지만, 이 책을 읽고 나서 솔직히 이야기하라고 하면...

 "대한민국에서 IT 계열의 개발자로 남아있을 수 있을까? 아니, IT 계열의 개발자로 성장할 수 있을까?"라는 생각부터 들었다. 물론, 내가 처음 접하기 시작했을 때보다 오늘 날에 Program을 만드는 일이 훨씬 쉬워진 건 사실이다.

 강력한 IDE에, Program 개발을 지원해 줄 수 있는 Tool, 그리고 흩어져있는 Community등...

 그에 비례해서 하나의 Program을 만드는데 필요한 제반 지식의 폭과 깊이가 깊어졌다는 것도 알아야만 한다.

 혹시나 해서 이야기하는 거지만, 사칙연산의 Program을 작성할 수 있다고 해서 'Program 별 거 아냐'라고 이야기 안 해주었음 한다. 그건 Program의 기본적인 작성법을 아는 것이고, 그 사칙연산에서 적용이 되어야할 '우선순위'라던가, '0으로 나누었을 때의 처리', 사용자로부터 입력을 받았을 경우에 그 입력 범위를 어떻게 한정지을 것인가'등등... 소위 말해지는 '예외상황'이라는 것에 대한 처리가 되어서 사용자가 그 오류를 미쳐 인지하지 못할 정도로 짰을 때, 적어도 'Program을 작성할 줄 아는 것 같아요'라고 이야기할 수 있는 것이 아닐까(거기다, Windows Programming해보면... 이건 생각 구조를 다시 한 번 뒤집어야한다)?

 거기다, 이런 작업의 특성상 '시간과 결과'가 비례해서 나오는 것도 아니다. 8시간 동안 Debug해서 못찾아 좌절하고, 다음 날 3분 만에 해결하는 어처구니 없는 일도 발생한다. 또한, Computer가 사고하는 방법과 사람이 사고하는 방법이 다른 관계로 자신의 논리가 맞는데, Computer가 제대로 수행이 안된다고 난리를 피는 경우도 다반사다(실제로는 지식의 부족으로 잘못된 문법으로 작성하는 경우도 있고, 사용하는 IDE가 결함을 가지고 있는 경우도 있다).

 뭐 배우는 사람의 입장으로서는 더 배우면 되는 것이지만 말이다.

 하지만, 사회에서는 어떨까?

 유명한 해외 Game 개발 업체에서도 해당 Programmer를 붙잡아 놓고 괴롭히는 판국에, 국내 역시 더하면 더했지, 덜하지는 않을 것이다(거기다가 개발자라는 족속들이 가지고 있는 잘못된 습관도 있단다...).

 Passion만으로 극복하기에는... 위험부담이 너무 큰가?

 어찌되었든, IT 개발자를 지망하거나 현재 종사하는 사람이라면 읽어보고 생각하기에는 적당한 책이라고 생각한다.

 추신 : 이와 같이 읽기 좋은 책

 Joel On Software, 조엘 스폴스키(박재호 역), 에이콘출판, 2005/04/15

 소프트웨어 블로그 베스트 29선, 조엘 스폴스키(강유, 허영주, 김기영 역), 에이콘출판, 2006/02/02

    (그러고보니, 소프트웨어 블로그 베스트 두번째 이야기는 원서로 출간이 되었다는데... 한역은 아직인가보네...)

SI는 입찰조건으로 오더를 따는 수주산업인데 저가 경쟁이 난무해서 품질 저하의 악순환이 반복되는 문제점을 안고 있다. 그러다보니 현실적으로 개발하는데 필요한 적절한 팀웍을 구성하는데 어려움 점이 많아서 저가 프로젝트의 경우 한두사람이 프로젝트를 담당하는 경우는 흔한 일이 되버렸고 혼자서 시스템 분석, 아키텍처 설계, 디비 설계 및 튜닝, 코딩에 심지어 디자인까지 도맡아 하는 사례를 찾을 수 있는 건 어려운 일이 아니다.

전산전공 졸업자이거나 웹을 전문으로 가르치는 학원을 수료해서 이런 열악한 환경의 벤처기업에 들어가 몇년간 고되게 일하다보면, 개발자란 분야에 금새 매력을 잃어버릴지도 모르겠다. SI 개발을 전문적으로 수행하는 대기업의 프로젝트팀 역시 저가 입찰경쟁으로 인한 폐해를 보전하기 위해 복잡한 하도급 구조로 진행되어 잦은 인력교체, 프로젝트 통제의 모호성과 책임논란 여부를 둘러싼 휴우증은 어제 오늘의 일이 아니다.

이런 복잡한 모순 속에서 과연 희망은 존재할까?

이 책의 목차를 보면 1부 생존(IT업계에서 살아가기)에서 개발자의 현실과 반복되는 악순환에 대해 설명한다.

2부 정진(소프트웨어 개발 잘하기) 어떻게 하면 프로그램을 잘 짤수 있을까, 생산적인 개발을 위해 필요한 혁신기법들을 소개한다. 3부 도약(프로젝트 성공하기)는 개인의 프로그램 단위를 넘어 성공 프로젝트 비법을 제시한다. 4부 비전(IT전문가로 살아가기)는 IT 전반적인 체제를 검토해보는 시간과 커리어 패스를 예로 경력별 전문가 경력 관리에 관한 어드바이스를 제공한다.

프로젝트를 직접 체험한 개발자라면 1부에서 많은 위안을 얻을수 있을 것이고 2부에서 현실적인 도움을 많이 얻으리라 생각한다.

프로젝트 리더는 3부에서 프로젝트 관리에 관한 계획, 형상, 품질, 위험관리, 요구분석등에 관한 세밀한 조언을 얻을수 있다. 소규모의 프로젝트는 개발자가 거의 모든 케이스를 맡아서 진행하는 경우가 다반사라서 알아두면 도움이 될만 하다.

프로젝트 현실

42쪽의 8개의 건축 삽화는 우리가 직면한 프로젝트의 현실과 이해관계를 너무나 극명하게 보여준다.

팀 단위의 프로젝트는 협력관계가 매우 중요하다. 고객과 인터뷰한 요구사항을 잘못 파악하는 순간부터 가족오락관의 포복절도할만한 말잇기게임이 시작된것과 진배없다. 그런데 이것을 잘 알고 있음에도 이런 오류를 범하기 일쑤다.

프로젝트를 진행하면서 들쑥날쑥한 고객의 변경요청은 메마른 하늘의 청청벽력과 다름없고, 영업팀의 약속 남발 공약으로 어쩔수 없이 해야만 하는 아찔한 악순환의 고리가 이어진다. 밥먹듯이 하는 야근과 특근, 한정된 인원에 빠듯한 마감시간, 바람막이가 되어야 할 PM은 묵묵히 자리만 열심히 지키는 암울한 현실이 반복될 뿐이다.

그럼 어떻게 하란 말인가? 자 대안을 찾아보자.

1. 고객의 요구사항을 개발하라.(94쪽)

밑줄 좌악 별 5개 엄청 중요한 말이다. 이건 개인적으로 느끼는 바이기도 하다.

인터뷰를 통해 수집된 자료를 업무분석 하고 바로 명세서 작성으로 넘어가는 것으로 만족해선 안된다. 인터뷰때 대화를 나누고 채팅한 기록을 파일로 간직해도 아무 소용이 없다. 이거 고치면 안됩니다 못박고 넘어가도 절대 소용없다. 요구사항의 수집단계에서는 직접 사용하는 담당자와 만나 프로토타입으로 보여주면서 케이스 바이 케이스 시연을 하는 것이 적절하다.  

2. 씨줄과 낱줄 - 모델링의 중요성 (120쪽)

프로세스의 뼈대는 모델링에서 결정된다고 생각한다. 의례 ERD를 그리는 것만으로 모델링의 역할을 다했다고 생각하지만 프로세스를 업무영역, 업무기능, 프로세스, 단위 프로세스로 세분화하여 구체적인 프로세스를 예상하고 절대 쓰러지지 않을 버팀목을 잘 세우는 구실이 이 역할에 해당한다. 결국 업무를 세밀히 분석하고 흐름을 잡아낼수 있는 사람이 프로젝트의 중심이 된다.

프로세스 모델링과 데이타베이스 모델링의 통합은 이상적인 결합이다.

3. 명세는 프로그램의 어머니 (133쪽)

프로그램 명세화란 어떤 요구사항을 가져와 프로그래머가 자기 기술로 작업을 시작할 수 있는 시점까지 정리하는 과정이다. (132쪽) 퍽 찔린다. 나 역시 버전업이 될수록 반영해야 하는 귀찮은 문서 산출물이라 생각했기 때문이다. 하지만 명세를 작성하는 습관을 키우면 현업이 요청한 업무사항을 오보없이 프로그램에 적용하기에 적절한 도움이 된다고 생각한다.

팀단위의 프로젝트 일수록 프로그램 명세서 작성은 커뮤니케이션의 오류를 미연에 방지할수 있는 탁월한 선택이다.

4. 테스트 - 피도 눈물도 없이 인정사정 없어야 한다.(142쪽)

프로젝트 팀에서 실시하는 테스트는 한계가 있기 마련이다. 온라인 게임도 많은 수의 베타테스터 지원을 받아 개발과정에서 발생한 크리티컬한 문제를 비롯해 수많은 버그를 고치는 과정을 거친다. 개발자는 주로 화이트 박스 테스트를 진행하므로 화면단위와 그 이외의 의외적인 변수에는 상당히 약할 수밖에 없다. 따라서 개발자에게 테스트의 책임을 떠안기는 행위는 위험하다.

이 책에서 소개하는 전략을 간추려 인용하면, 첫째 테스트는 시점이 중요하므로 일찍, 자주, 자동으로 테스트할 것, 둘째 테스트 후에 오류를 고칠 시간을 염두할 것, 셋째 테스트는 개발자 이외 독립적인 조직이 수행할 것, 넷째 테스트 계획을 세워서 진행할 것을 조언하고 있다.(142쪽)

 이 책을 읽으면서 XP 프로젝트 방법론에 관해서 몰랐던 내용을 알게됐다. 어쩌면 저자가 말하는 희망이란 이것인지 모르다는 생각이 들었다. 결과적으로 익스트림 프로그래밍의 약자 XP(eXtreme Programming)는 성공적인 프로젝트를 위한 방법론인데, 개인차원이 아닌 팀단위의 소프트웨어 개발을 통해 생산성을 높이려는 혁신이라고 본다.

나의 실수를 다른 사람이 보완할수 있는 코드공유 방법, 두명이 한조가 되어 모니터를 보면서 개발하는 짝 프로그래밍 기법, 자동화 테스트 추천, 리펙토링, 시스템 통합과 릴리즈 진행방식등 XP를 실용적으로 접근해서 얻을만한 가치는 상당해 보인다.

무엇보다 사람이 부품화되어 조각화되어 지는 삭막한 현장에서 인간중심에 촛점을 맞춘 XP 프로젝트 방법론은 관심을 끌기에 손색이 없어보인다. 

내가 참여했던 프로젝트중 가장 인상에 남는 것은 전체 개발완료기간을 9개월 정도로 보고 달려들었던 CRM 프로젝트인데  5개월을 초과해서야 겨우 오픈할수 있었다. 그때의 경험을 떠올려 보면 결국 성공적인 프로젝트를 위해 제일 중요한 사항은 프로젝트를 구성하는 멤버간의 팀웍과 관리자의 리더십에 있다는 점을 주저없이 일순위로 올리고 싶다.  팀원에게 적절한 동기부여를 제공하고 서로간에 결속의 힘을 맺게 해주는 역할을 PM이 해야 한다. 긍정적인 마인드, 목표와 방향을 끊임없이 고민하고 적절한 제안을 제시하는 결단력, 문제해결능력과 팀원과의 자유토론을 통해 창의적인 대안을 도출할수 있는 중재자 역할 또한 관리자가 가져야 할 역량이다. 프로젝트의 실패는 리더십이 부족한 관리자의 능력 부재 때문이란 통계도 있다고 한다.

프로젝트를 경험하면서 느낀 건 프로젝트 관리자는 참 어려운 자리란 것을 실감한다.

프리에이전트 시대를 저술한 대니얼 핑크가 말했듯이, 평생직장이 사라지고 평생직업의 시대가 도래했다.

자신이 가진 직업적 기술의 특기를 살려 1인기업가로서 명성을 떨치는 사람들이 늘어나고 있고 조직형인간에서 프리에이전트가 대신하는 시대적 격변기에 있다고 생각한다. 저자는 희망이란 자신이 믿다고 생각되어지는 길을 걷고 있는 것이라고 했다.

원래 길이 없는 땅에 사람들이 오고가면서 생기는게 길이다. 밤새 내린 하얀 눈위를 처음 내딛는 설레이는 마음으로 다시 마음을 가다듬는 계기가 되었다. 

<책속의 책>

밑줄치며 읽은 인상적인 구절도 많았고 뇌리를 강하게 스쳐간 명언들도 많았지만 그가 책에서 남긴 편린의 조각을 모아보니 상당한 분량이 되었다. 읽어보지 못한 책이 태반이라 부끄러운 마음도 들었고, 이 책에 쏟아부은 저자의 열정이 남다르게 느껴졌다.

공학을 전공으로 졸업한 나도 글쓰기가 여간 미흡한게 아닌데 프로그래머의 글쓰기는 풀어야 할 숙제라고 생각한다.

글쓰기 명언에 관한 소개를 실은 글이 글쓰기 숙제를 풀수 있는 실마리가 되리라 본다. (202~203쪽)

저자가 먼저 읽고 스친 책들을 통해 나도 비슷한 영감을 따라서 느끼고 싶다. 

1.프레데릭 브룩스의 <The Mythical Man-Month : Essays on Software Engineering, Anniversary Edition> 

한달동안 프로젝트의 투입된 인력의 합을 맨먼스(Man Month)라고 한다. Man Month의 환상을 인용했다. (34쪽)

테크니컬 라이팅에 대한 소개 (200쪽)

2.피터 드러커 <프로페셔널의 조건> 40쪽, 74쪽

조직내부의 커뮤니케이션은 조직의 '수단'이 아니다. 커뮤니케이션은 조직의 존재 양식이다.

3.이어령의 <디지로그> 진정한 변화의 기술에 대한 단상을 인용  59쪽

4.스티브 맥코넬이 쓴 <Professional 소프트웨어 개발> 일단 짜보고 고치기 실례 66쪽

5. 앤드류 헌트& 데이비드 토머스의 <실용주의 프로그래머> 70쪽, 132쪽

프로그래머 필독서. 우연의 결과를 개선시키는, 의도적 프로그래밍에 관한 인용

6.에드워드 요든이 지은 <죽음의 행진> 프로젝트는 성공이 목적이 아니라 살아남는 것이 목적이다. 73쪽

7. 임백준의 <행복한 프로그래밍> 프로그래밍의 미학, 프로그래밍은 예술이다.  162쪽

8. <익스트림 프로그래밍> XP 소프트웨어 개발론,  팀플레이 프로그래밍에 관해 168쪽

9. 소프트공학 최초의 베스트셀러 와인버그의 <The Psychology of Computer Programming > 171쪽

10. 로리 윌리엄스 <Pair Programming Illuminated> 짝 프로그래밍 효과에 대해 설명 189쪽

11. 임재춘 교수 <한국의 이공계는 글쓰기가 두렵다> 테크니컬 라이팅에 대해 제안, 200쪽

12. 페란라몬-코르테스의 <등대> 효과적인 커뮤니케이션 기술, 5가지 원칙 서술 208쪽

13. 미작가 찰스 리치의 <의식혁명> 인간의 의식을 3단계로 구분, 213쪽

14. 로버트 L. 글래스의 <소프트웨어 공학의 사실과 오해> 254쪽

15. 존 G. 밀러의 <바보들은 항상 남의 탓만 한다> 실패를 통해서 배우자. 280 쪽

16. 구본형의 <월드클래스를 향하여> 기업이 추구하는 목적 291쪽

17. 최인훈의 <상도> "장사는 이문을 남기는 것이 아니라 사람을 남기는 것이다" 고객과의 이해관계 293쪽

18. 제프리 페퍼교수의 <숨겨진 힘, 사람> 사람중심의 경영방식에 관해 307쪽

19. 짐 콜린스의 <Good to Great> 경쟁력은 사람의 마음속에 310쪽

20. 톰 디마르코 <피플웨어> 단결된 팀에 관해 317쪽

21. 슈메르체크가 쓴 <정글세미나> 개인과 팀의 조화에 대한 생각을 동물이 등장하는 우화 형식으로 설명 319쪽

22. 신영복교수의 <감옥으로부터의 사색> 일의 명장. 전문가로 가는길 인용 337쪽

23. 김홍기의 <디지털 인재의 조건> 최고의 전문가는 십자형 인간이다. 343쪽

24. 폴 글렌 <IT 전문가를 위한 리더십> IT전문가에게 필요한 역량 12가지 소개 345쪽

25. 스티브잡슨 <iCON> 변화와 혁신을 추구하라. 351쪽

26. 안철수의 <지금 우리에게 필요한 것은> 자기경영을 위한 삶의 원칙 소개 353쪽

27. 히로나카의 <학문의 즐거움> 매사에 최선을 다하라. 354쪽

28. 제리 포라스의 <성공하는 기업들의 8가지 습관> 성공한 회사들의 공통적 특징 355쪽

29. 미국의 사회학자 윌리엄 새들러의 <서드 에이지, 마흔 이후 30년> 374쪽

30. 구본형 <익숙한 것과의 결별> 382쪽

직장에서 끝까지 남아 있기 위해 안간힘 쓰는 것은 자신을 갈라진 틈 속으로 자꾸 밀어 넣어 바위틈에서 오도 가도 못하게 된 겁먹은 암벽 등반가와 같다. 위험해 보이지만 자신의 손과 발을 마음대로 움직일 수 있는 바위 바깥쪽으로 나오지 않으면 그 바위를 오를 수 없다.

이 책은 요상한 책이다. 명색이 IT 전문가라는 사람이 내내 '사람'과 '소통'을 집요하다 못해 편집증적으로 외치고 있으니 말이다. 왜 그는 대한민국 개발자들에게 전혀 그들의 분야와는 어울릴 것 같지 않은 이야기(?)를 줄기차게 해대는 것일까? 이제 그 이유를 한번 차근차근 디벼보도록 하자.

IT는 신종 노가다인가?

제 1 부 생존에서 저자는 현재 IT 업계 종사자들이 어떤 처지에 놓여 있는지를 생생하다 못해 민망할 정도로 가감없이 설명해 준다. 현재로만 따지면 IT는 신종 노가다로 불리워도 할 말이 없을만큼 열악한 산업임에 틀림없어 보인다.

저자는 IT 핵심인력인 개발자들이 공사판의 막노동꾼처럼 다루어지고 있음에도 불구하고 그런 상황에 대해 분노하고 변화하려는 의지가 미약할뿐더러, 어떻게 변화해야 하는지조차 모르기에 더욱 절망적이라는 사실을 뼈저리게 실감했던 것 같다.

먼저 그 변화의 길을 치열하게 경험한 저자가 동료들에게 털어 놓는 진실은 기술이 모든 것을 좌우할 것만 같은 IT 업계에서 진정한 전문가로 성장하기 위해서는 메마른 IT 직무에 '사람'과 '소통'의 숨결을 강하게 불어넣자는 것이다.

저자는 개발자들을 지금의 고달프고 초라한 상황으로 몰아넣은 주범이 기술력 부족이나 무리한 고객의 요구때문이 아니라, 피플웨어를 하드웨어 방식으로 다루어 왔던 IT 업계의 고질적인 관행이 절대적인 '소통'의 부족과 품질문제를 야기시킨데 그 근본원인이 있다고 확신에 찬 어조로 말한다.

그는 자신의 생생하고 다양한 경험과 치열한 사색을 바탕으로 동종업계에 종사하는 이들은 물론이고 모든 직장인들의 고개를 끄덕이게 할만한 사례와 논거를 제시하며 웰빙 프로그래밍, 프로젝트 성공하기, 전문가로 성장하기 초식을 유감없이 펼친다.

이 모든 초식의 밑바탕에는 '사람 최우선'과 '소통의 질적.양적 강화'라는 IT 타짜 오병곤의 절대기술이 깔려있음은 당연하다. 경상도 짝귀가 고니에게 알려준 속임수 판별법이 기술에 있지 않았듯이, IT 타짜는 개발자들에게 함께 일하는 PM, 고객, 동료들과 진심으로 소통하는걸 습관으로 삼는 길만이 고수가 되는 비결이라고 속삭인다.

누가 읽으면 좋을까? 개발자만 읽는 책인가?

개인적으로 학교에서 IT관련 전공을 공부하고 있거나, 전공과 상관없이 IT업계에서 종사하고 싶은 사람에게 제일 먼저 일독을 권하고 싶다. 왜냐 하면 이 책을 통해 저자가 들려주는 살아있는 지식은 동문특강이라는 이름으로 실력있는 선배들을 초청해서 들어볼 수 있는 수준 이상의 가치를 가지고 있기 때문이다.

부연하자면, 1부 생존에서는 피상적으로만 느껴왔을 IT 업계의 정확한 현주소에 대한 정보를 제공하여 좀 더 정확한 진로에 대한 의사결정을 도울 수 있으며, 2부 생존에서는 어떻게 공부하고 준비해야 하는지를 가이드 해 줄 것이다. 3,4부 도약과 비전에서는 앞으로 IT 전문가로서 어떤 경력로드맵과 비전을 가지고 성장할 것인지에 대한 힌트가 들어 있다.

두번째 독자층은 당연히 대한민국 개발자의 몫이다. 이들은 1부 생존에서 무릎을 치고 분개하며 공감할 것이며, 또한 자신을 냉정하게 돌아볼 기회를 갖게 될 것이다.

특히 이들에게는 2부 정진보다는 3부 도약을 집중해서 읽어 보기를 강력히 바란다. 그 대목에 개발자들이 희망을 찾을 수 있는 중요한 힌트가 숨어 있기 때문이다.

세번째는 모든 직장인들에게 이 책을 권하고 싶다. 단 이 책을 대한민국 직장인을 위한 희망보고서로 읽어주길 바란다. 2부 정진의 개발 생산성 혁신과 관계지향 프로그래밍을 제외하고는 모든 내용에 개발자 대신 여러분을 대입해도 무리가 없을 것임을 보장한다.

역시 3부 도약 - 프로젝트 성공하기를 집중해서 읽어주시기를 바란다. 프로젝트형 조직이 일반화되는 추세에서 여러분에게도 매우 실용적인 지식이 될 것을 믿기 때문이다.

마지막으로 정체되어 있는 과거의 자신과 결별하고 어제보다 더 아름다워지기 위해 변화의 길을 떠나고자 하는 모든 분들에게 이 책을 권하고 싶다. 이 책은 IT 변화경영 전문가를 꿈꾸는 저자의 눈물나도록 처절하고 감동적인 변화체험실록이기 때문이다.

특히 프롤로그, 에필로그와 더불어 1부 생존의 불타는 갑판편, 2부 정진의 연금술편, 3부 도약의 숨겨진 힘 사람편, 4부 비전의 나의 기술사 도전기 등을 별도로 꼼꼼히 반복해서 읽어보기를 바란다. 이 대목들에 저자가 평범하고 피곤한 일상을 벗어날 수 있었던 중요한 힌트가 곳곳에 버무려져 있으니 말이다.

지지리도 바쁜 직장생활을 하면서 이 책을 쓸 수 있었던 것은 저자가 성실한 독종이었기 때문이고 그가 너무나도 사랑하는 알콩달콩 가족들이 있기 때문은 아니었을까? 그가 어려운 일을 해낸 것은 틀림없지만 이 멋진 성취끝에 10년만에 가족여행을 떠난 이 행복한 가족의 모습을 지켜보며 우리도 작은 용기를 내어 그가 안내해 주는 길을 나서 보면 어떨까?

1. 계속되는 야근, 주말근무로 인해 지쳐있는 탓인지 같이 고생하는 팀원들에게도

자꾸 목소리가 높아지는 경우가 생긴다. 안그럴 수 있는 일인데 말이다.

2. 최근 클라이언트가 말도 안되는 기능과 일정을 강요했다. 그 클라이언트의

모욕을 참지 못하고 결국 얼굴 벌개지고 회의 도중 벌떡 일어나 나와버리고 말았다.

3. 너무 힘들고 지친다는 생각에 회사를 그만두고 쉬고 싶다는 생각을 한다.

왠지 외롭고 허전하며 온통 주변 사람들이 날 괴롭히려는 적으로 보인다.

4. 본사... 이런 된장, 내가 앵벌이야? 도와주지는 못할 망정 방해는 하지 말아야

 할 것 아니야? 왜 참아보려고 하는 사람 염장을 지르고 난리지?

괴로움으로 나날을 보내고 있는 나는

세 권의 책을 샀다.

1. 신영복 선생님의 "더불어숲"

2. 문요한님의 "굿바이 게으름"

그리고 나머지 한권이 바로 이 책이다.

신영복 선생님의 글을 읽으면 잔잔한 자성과 감동이 느껴져서

정서적인 안정을 찾을 수 있다.

문요한님의 책은 우화형 자기계발서적이 난무하는 속에서

자기계발에 대한 날카롭고 분석적인 시각이 돋보인다.

(나 게으르다는 말에 먼 칭찬을 이리 하는건지... )

그리고 직업적인 문제점을 해결하기 위해 선택한 책이

오병곤님의 이 책이었다.

물론 외국책 좋은 것 넘 많다. 이 책에서도 언급되는 맥코널의 책은

나도 대학시절의 원서, 번역서 등 여러 권을 가지고 있다.

하지만 먼가 부족함이 있다고 생각했다. 바로 '공감'이다.

토종 개발자의 내공 수위가 팍팍 느껴지는 대목들이 많다.

내 스스로를 차근차근히 살펴볼 수 있어서 좋았다.

개발자로서 또는 PM으로서 되새겨야할 원칙과 가이드가 있다.

결국 내가 선택한 한 문장은

"사람을 최우선으로 대한다는 것은 오로지 성공만을 추구하는 것은 아니다.

삶의 의미와 보람에 초점을 맞추는 것이다. 사람에게 중점을 두게 되면

성공과 결실은 자연스럽게 따라올 것이다."

역시 사람이 꽃보다 아름답다.