- 예비12기_이경종
- 조회 수 10808
- 댓글 수 0
- 추천 수 0
대한민국 개발자 희망보고서 - 오병곤
저자 소개
"가도 가도 끝없이 펼쳐진 몽골의 초원은 원시적인 느낌이었다. 하늘은 물감을 뿌려놓은 듯 푸르고 푸르렀다. 고요히 불어오는 바람은 자유의 숨소리였다. 말을 타고 바람을 가르며 초원을 내달렸다. 구름이 걸쳐 있는 듯한 언덕까지 올라가 사방이 트인 전경을 보며 감탄하고 감탄했다. 밤에는 은하수와 별똥을 보면서 소원을 빌었고 새벽녘까지 모닥불을 피워놓고 노래를 부르고 춤을 췄다. 모처럼 마음먹고 감행한 몽골여행은 내 인생 최고의 여행이었으며 이후 내 인생의 좌표가 되었다. 내가 원하는 삶이 어떤 것인지 생생하게 그릴 수 있었다." - 오병곤 저 <회사를 떠나기 3년전> p75
오병곤은 터닝포인트 경영 연구소 대표이자 정보관리 기술사이다. 불안에서 희망으로, 의무에서 자유로 도약하는 자기혁명 프로젝트 전문가이다. 지난 25년동안 IT와 인문학의 중간에서 일해 왔다. CT등의 회사에서 오랜 기간 IT업무를 하였고, 구본형 변화경영연구소 1기 연구원으로 첫 책 <대한민국 개발자 희망 보고서> 를 출간하였다. '3050 터닝포인트 스쿨', '내 인생의 첫 책 쓰기'와 같은 프로그램을 운영하며 일반인들의 삶의 전환을 돕는 멘토의 삶을 살고 있다. 저서는 다음과 같다.
대한민국 개발자 희망보고서(2007)
내 인생의 첫 책 쓰기(2008)
회사가 나를 미치게 할 때 알아야 할 31가지(2010, 공저)
프로그래머 그 다음 이야기(2011, 공저)
회사를 떠나기 3년전(2014)
실용주의 소프트웨어 개발(2017)
IT와 인문학의 경계에서
오병곤은 대학에서 인문학을 배웠지만 전공과는 관련없는 IT분야에서 오랜 경험을 쌓았다. 지금은 시대가 많이 바뀌었지만 그때는 인문학은 IT분야에 전혀 도움이 되지를 못 했다. 그는 IT 기술은 익히기까지 산전수전, 공중전을 겪었고, 오랜 노력 끝에 본 궤도에 올라 기술력을 인정받고 IT분야의 최고 자격증인 기술사까지 취득하게 된다. 그러난 그의 마음 한구석에는 '내게 엔지니어가 어울리는가?'라는 질문이 항상 멤돌았고, 고민 끝에 그가 내린 결론은 '아니다'였다. 결국 그는 인문학과 엔지니어링을 연결시키는 지점에서 그의 길을 찾기 시작했다. 구본형 경영연구소 1기 연구원 활동을 통해 그의 삶의 전환은 더욱 가속화된다.
"기술보다는 기술로 밥을 먹고 사는 사람과 조직의 성장에 관심을 갖자. 엔지니어에게 꼭 필요한 휴먼 스킬을 양성하는 전도사가 되자."
스스로에 대한 굳은 다짐 후 그는 그만이 할 수 있는 차별화된 콘텐츠 개발을 시작했다. 그리고 그걸로 먹고 살수 있게 되었다. 인생의 후반기, 진정한 자기로의 여행을 즐기는 오병곤은 자기혁명 프로젝트 전문가로서 1인 기업가의 입지를 더욱 다지고 있는 중이다.
"인생의 전반기에 우리는 사회에 봉사한다. 이것은 종속이다.
인생의 후반기에 우리는 내면으로 돌아선다. 이것은 해방이다."
- 조셉 캠벨
저자 인터뷰
링크 - http://www.bhgoo.com/2011/index.php?mid=life&document_srl=839987
내 마음을 무찔러드는 글귀
프롤로그
오히려 세상은 하루가 다르게 변화하는데 과거의 무용담을 자랑스럽게 늘어 놓으며 예전의 경험을 오늘의 진리로 일반화시키는 관리지들이 적지 않다.
> 어리석고 치졸한 짓이다. 신입사원 때 그런 상사들을 보며 한심해 한 적도 있었는데, 시간이 흘러 내가 그 상사의 위치가 되고 보니, 문득문득 나도 예전의 경험에만 집착해서 사리분별을 못 하는 스스로를 보기도 한다. 사실 나이든 관리자들은 빠르게 변해가는 시대에 부식되어 가는 스스로를 차마 볼 수 없어 과거의 경험에 집착하고 있는 것인지도 모른다.
변화가 문제가 아니라 변화에 적절히 대처하지 못하는 우리의 무능력이 문제다.
p21
초과근무에 몰두하는 또 다른 이유는 다소 끔찍한 생각이지만 일이 잘못되었을 경우를 대비한 보호수단으로 활용될 수 있다고 믿기 때문이다. 일종의 면죄부인 셈이다.
> 현업에서 실제 그렇다. 성실이라는 이름으로 포장된 초과근무는 면죄부가 되기도 한다. 이를 악용하는 사람들도 있고, 정말 무능력해서 초과근무를 일삼는 사람들도 있다. 어떤 경우든 그들은 업과 직무에 대해 스스로를 돌아보는 시간을 가져야 한다.
p23
일에 대한 생산성을 획기적으로 높일 수 있는 유일한 방법은 동기부여라는 것을 명심해야 한다
> 조직의 정체기가 길어지고, 그것이 일상으로 굳어버리면 동기 부여가 어려워진다. 책에 있는 얘기대로 성취감을 주고 일 자체를 즐길수 있도록 하는 다양한 방법들이 모색되어야 한다. 장기적으로 조직의 문화를 개선시켜 나가는 것이 중요하다. 개발조직의 문화를 위해서 무엇보다도 개발자들의 특성을 파악하는 것이 중요하고, 기저에 깔린 그들의 속내를 파악하는 것이 급선무이다.
p28
프랭클린 베커와 프리츠 스틸은 '일터와 디자인'에서 회사의 사무실 공간은 조직에 대한 일종의 신체 언어라고 작업 환경의 중요성을 강조한다.
> 작업환경의 중요성은 두말할 나위가 없다. 톰 디마르코가 저술한 '피플웨어'에도 작업환경의 중요성을 크게 강조하며, 오픈 플랜식 배치 - 다시 말해 관리자가 한눈에 관리가 용이하도록 만들어진 사무실의 비효율성을 꼬집고 있다. 마치 감옥과 같은 큰 공간에 개발자들을 몰아 넣고 도때기 시장으로 만들어 놓는 것은 일견 관리자의 눈에는 모든 것이 잘 돌아가고 있는 것처럼 보이겠지만, 실상 개발자들은 모니터안의 일감뿐만이 아닌 주위환경이라는 예상치 못 한 적들과도 싸워야 한다. 개발자들은 자연광에서 일을 더 잘 한다. 몰입하는 것과 그렇지 않은 것의 업무효율은 엄청난 차이가 있으며, 불필요한 전화 한통은 업무효율에 심대한 타격을 준다.
p36
n명의 프로그래머로 구성된 개발팀의 내부 의사 소통 경로는 n(n-1)/2개가 된다. 따라서 프로젝트가 지연되고 있는 상황에서 추가 인력을 투입하면 프로젝트는 더 늦어지게 된다.
CBD(Component Based Development) 방법론도 소프트웨어를 잘게 부품으로 나누고 잘 조립해서 재사용을 높이자는 개념이다. 프로그래밍 경험이 많은 엔지니어들은 몸속 깊이 이 개념이 녹아 있다. 문제는 이 개념에 길들어진 사람이 관리자가 되었을 때 나타난다. 마치 소프트웨어 부품처럼 직원들을 대하게 된다는 점이다.
> 사람들을 레고처럼 생각하는 것 자체가 잘못된 것이다. 이는 개발경험이 없는 관리자들에게서도 많이 보이는 현상이다. 또한 개발경험이나 직무의 문제가 아닌 관리자의 자질이 문제인 경우가 많다. 많은 사려깊은 고참개발자들은 자신들의 경험에 비추어 개발자들을 레고로 대하는 것의 폐해를 잘 알고 있다. 개발업무의 성격상 레고 다루듯이 업무분배를 하기도 하지만, 중요한 것은 사람을 먼저 보느냐, 일을 먼저 보느냐에 달려 있다.
p39
모든 프로젝트는 커뮤니케이션으로 통한다
다들 사람이 중요하다고 말을 한다. 그러면서도 행동이 따르지 않는 이유는 사람이 도구, 기술, 프로세스보다 다루기 어려운 운제이기 때문이다.
> 어려운 것을 외면하고 쉬운 것들을 먼저 하려는 인간의 속성 때문이겠지만, 사실 대부분의 관리자나 경영진들은 사람이 중요하다는 사실을 말로만 떠들뿐이지 실제로 깨닫고 있지 못하다. 문제의 본질이 사람에 있음을 진정으로 깨닫고 있다면, 프로세스나 도구가 모든 것을 해결해줄 것이라는 생각을 할 수 있을까?
p41
톰셋(R. Thomsett) - '프로젝트는 90% 달성될 때까지는 빨리 진행된다. 그런데 나머지 10%가 영원히 계속된다.'
> 이는 99%의 저주라고도 알려진 개발 프로젝트의 속성이다. 영원히 계속되는 10% 내지 1%는 대부분 프로젝트의 시작이 잘못 되었기 때문에 발생하는 문제다. 흐리멍텅한 요구사항 수집, 경영진의 과도한 압력이 만들어낸 잘못된 일정 추산, 설계의 빈곤 내지는 아키텍처의 부재는 이미 프로젝트의 성패를 시작부터 가늠한다. 영원히 계속될 것만 같았던 1%의 저주를 땜빵으로 해결하고, 안도의 한숨을 돌리지만 이제 프로젝트는 실력이 아닌 운에 모든 것을 맡기게 된 망망대해속의 돛 없는 돗단배와도 같다. 관리자나 개발자들이 유일하게 할 수 있는 일은 목적지에 도착하기까지 폭풍우나 큰 파도가 없기만을 기도하는 것밖에 없다.
p59
나는 소프트웨어 위기의 근본적인 원인을 다음 두 가지로 지적하고 싶다.
- '개발 관행'. 다시 말하면 '일하는 방식'의 전 근대성
- 사람을 일의 중심으로 인식하는 피플웨어의 부족
> 두가지 모두 개발문화의 관점에서 접근해야 한다. 프로세스와 도구, 기술은 그 다음이다.
p61
전통적으로 문제 해결은 분할과 정복(divide & conquer) 같은 분석 기번에 의존했으나 오늘날에는 고객과 시장을 선도하고 가치를 제공하는 방향으로 비지니스가 전개됨에 따라 창의성이 더 요구되고 있다. IT업무가 주는 기쁨 중 하나는 일 자체가 근본적으로 창조적이라는 점을 기억해야 한다.
소프트웨어 개발이 다양한 영역과의 결합을 통해 새로워져야 한다. 경영에 대한 학습을 통해 비지니스에 대한 이해를 넓혀 나가야 하며 프로세스 개선, 품질 경영, 커뮤니케이션, 리더쉽, 조직개발, 문제 해결등의 영역을 소프트웨어 개발과 프로젝트 관리 영역으로 끌어와야 한다.
p62
관리자가 진정 해야 하는 일은 사람들에게 일을 시키는 것이 아니라 그들이 일에 전념할 수 있는 환경을 만들어 주는 것이다. - 톰 디마르코
p63
회사측에서 직원들을 존중해주면, 직원들 역시 회사를 위하여 최선을 다하기 마련이다
> 여기 식어버린 난로가 있다. 그 앞에서 서서 아무리 "날 따뜻하게 해봐, 그럼 땔감을 넣어줄께"라고 얘기해도 난로는 따뜻해지지 않는다. 본인이 따뜻하고 싶으면, 우선 땔감을 넣어야 한다. 여기서 먼저 땔감을 넣는 쪽은 회사가 될 수도 있고 직원이 될 수 도 있다. 어느쪽이든 먼저 시작하는 것이 중요한데, 좋은 관계는 시작이 반이다.
p69
개인적으로 '일단 짜보고 고치기'가 탐탁하지 않은 이유는 우연에 맡기는 프로그래밍 방식이기 때문이다. 운에 맡기는 프로그래밍이다.
> 인간이 창조한 것 중 지구상에서 가장 복잡한 것이 바로 소프트웨어다. 이 복잡한 것을 Try & Error로 접근을 하니 수준이 떨어질 수 밖에 없다.
p70
로마의 희극작가 플라우투스는 '인간의 삶은 주사위 놀이와 같다. 주사위가 비록 바라는 대로 떨어지지 않더라도, 우연의 결과를 개선시키는 기술이 있어야 한다.' 고 말했다.
우연은 불안과 동의어에 다름 아니다. 비록 예측할 수 없는 것이 인생일지라도, 실패가 우리 주위 곳곳에 매복되어 있는 것이 또한 인생일지라도, 우리는 꿈꾸고 계획하고 실행해야 한다.
> '우연의 결과를 개선시키는 기술'로 개인의 삶 뿐만 아니라 인류의 삶이 진일보한 듯 하다. 살다보면 마주치는 온갖 문제들도 어찌 보면 전부 우연의 결과가 아니겠는가. 필연적이라고 생각되는 것들이라도 우연적인 요소가 개입되어 있다. 삶은 끊임없이 계속되는 일련의 문제처리과정인 셈이다.
p72
'일단 짜보고 고치기'는 그저 바쁘게 지내는 방식이다. 마음은 바빠서 조급증이 오고 몸도 바빠서 초과근무에 시달린다. 당연히 성과가 좋을 리 없다
> 일단은 마음이 바쁘기 때문에 가시적인 성과를 볼 수 있는 '일단 짜보고 고치기'에 뛰어드는 것이다. 부끄럽지만 나 역시 그럴 때가 많다.
'일단 짜보고 고치기'를 택하는 또 하나의 이유는 이 방법이 제일 쉬운 개발 방법이기 때문이다.
> 맞는 말이다. 통제받지 않는 상태에서 마음이 급하면 가장 쉽게 저지를수(?) 있는 개발방식이다. 이성은 잘못된 방법이라고 경고를 보내지만, 다시 한번 자신의 운을 알 수 없는 힘에 맡기게 되는 어리석음을 범하게 된다. 운이 좋으면 더 빨리 개발할 수 있고, 천운이 도와준다면 문제가 없을 수 도 있다. 하지만 대부분 결과적으로 더 오랜 시간이 걸리기 마련이고, 우여곡절끝에 만들어진 소프트웨어의 품질도 형편없는 경우가 태반이다. 그럼에도 불구하고 다시 '일단 짜보고 고치기'를 하는 것은 사실 도박과 별 다를 바가 없다.
p74
그 동안 우리는 주어진 일을 해치우는 데에 너무 많은 시간을 할애했고, 정말 핵심적인 질문인 "이 일을 대체 할 필요는 있긴 한 것인가?"라는 것에 대해서는 시간을 내지 못 했다. 주위를 둘러보라. 정작 일 잘하는 사람은 일 자체에 대해 생각하는 사람이라는 것을.
> 지극히 동감하는 부분이다. 진정한 개발자란 무엇인가에 대해 다시 한번 생각해 보게 된다. 이 시대가 요구하는 개발자들은 뛰어난 문제 해결능력을 가지고 있다. 이 문제해결능력은 소프트웨어 개발자라고 해서 소프트웨어 버그를 잡아내는 디버깅 능력만을 의미하지는 않는다. 이들은 문제를 바라봄에 있어 궁극적인 최종 목적이 무엇인지를 항상 염두에 둔다. 문제나 일을 명확히 정의하고 일의 필요성에 대해 정리한다. 어떤 형태로 해결되어야 하는지 궁극적인 최종 목적을 정의하고, 이를 위한 최선책과 차선책, 그리고 현실적인 절충안을 마련한다. 실제 일에 착수하는 것은 그 다음이다. 많은 엔지니어들이 문제 자체에만 깊숙히 파고드는 우를 범한다. 버그 하나에 매달려 밤을 세워 해결하고 새벽과 함께 맞는 성취감에 뿌듯해하지만, 허망하게도 정작 그냥 놔둬도 상관없는 문제인 경우도 있고, 이미 다른 개발자에 의해 해결된 유사 문제인 경우도 있다. 일이나 문제 자체에 대해 먼저 생각하고 정리하는 시간을 가져야 한다.
p76
프로젝트는 정해진 기한이 있고, 유일하고, 점진적으로 상세화된다는 속성을 가지고 있다.
p89
'나 홀로 프로그래밍'을 벗어나 팀 단위의 '관계지향 프로그래밍'을 추구해야 한다.
> 관계지향 프로그래밍, 상당히 멋진 말이다. 이 개념은 우리가 현업에서 안고 있는 많은 소프트웨어와 프로젝트의 문제들을 개선시킬 수 있는 가능성을 내포하고 있다. 한편으로는 소프트웨어 개발, 프로그래밍은 지극히 개인적이며 창조성이 개입되는 분야이기도 하다. 모든 프로젝트 팀원이 관계지향 프로그래밍을 지향하고, 각자 팀원이 이에 기반하여 개발에 몰입한다면 막대한 시너지가 창출될 것으로 보인다.
p99
고객이 실제로 구입하는 것은 제품과 서비스가 제공하는 효율(utility)과 가치(value)다.
p100
고객들은 때때로 요구사항을 수집하고 그 품질을 확인하기 위해 노력하는 것이 얼마나 중요한지를 이해하지 못 한다.
고객참여가 불충분한 프로젝트는 뒤늦은 요구사항 추가로 프로젝트 완료를 지연시킨다.
> 아... 바로 요즘 내가 경험하고 있는 일이다. 많은 프로젝트와 개발자들이 경험하는 흔하디 흔한 일이다. 초기에 제대로 파악되지 않은 요구사항은 항상 후반부에 프로젝트를 지연시키는 원인이 된다. 회사 입장에서는 뒤늦은 요구사항 추가라고 고객과 실랑이를 벌이지만, 이는 요구사항 수집이라는 전처리 과정이 실패했음을 의미한다.
p101
우선순위를 정하는 것은 쉽지만 우선순위대로 일하기는 어렵다. 우선순위는 실천의 문제이다. 우선순위를 결정하는 것에는 중요한 일에 집중하고 하찮은 일은 과감히 버릴 수 있는 용기가 필요하다.
p103
세계 최고의 디자인 회사인 IDEO는 프로토타입을 적극적으로 활용하는 기업이다. IDEO는 일하는 방법을 이해한다 - 관찰한다 - 시각화 한다 - 평가하고 다듬는다 - 실천한다의 5단계로 구분한다. 이 중에서 3단계인 '시각화한다'는 프로토타입을 만드는 과정이다.
p107
자신의 생각을 구체적인 일상에 적용하기 위해 실패를 두려워하지 않고 실험하는 혁신가가 바로 프로토타이핑 매니아다. 프로토타입은 이 실험의 결과다. 어찌 보면 자기 변화도 이와 크게 다르지 않다. 처음부터 '나는 이것 저것 다 해서 나의 꿈을 달성하겠다'는 거창하기는 해도 욕심을 부리면 오히려 이루기 어렵다. 일단은 긴요하게 필요한 것부터 바꿔보는 것이다.
p119
모델링이 무시되는 가장 큰 원인은 분석, 설계보다 개발을 더 중요시 여기는 소프트웨어 개발 관행 때문이다. 분석, 설계 기간은 상대적으로 개발기간에 비해 짧게 계획되어 충분하게 설계되지 못 하고 문서 작업하기에만 급급하다.
p128
자본주의 경제방식이 기존의 상품중심에서 고객중심으로 변화하면서 모든 제품의 목적은 사용자에게 봉사하는 것이며, 사용자와 관련이 있는 한 사용자 인터페이스가 바로 제품이 되는 현실을 맞게 된다.
> 나이 많고 과거에 절어 있는 개발자들이 간과하는 부분이기도 하다.
p130
UI는 개발 과정에 또 하나 주어진 귀찮은 과업이 아닌 U(You)와 I를 잇는 가교이며 커뮤니케이션이다.
p132
명세화는 주요한 모호함들을 제거하는 등의 방법으로 세계를 설명하고 명확하게 만드는 의사소통의 한 행위다.
> SRS(Software Requirements Specification, 소프트웨어 요구 사양서)가 중요한 이유이다.
p133
프로그램은 원래 의도한대로 완성되지 못하고 의도와 현실의 중간지점에서 애매하게 타협되기 쉽다
> 비단 프로그램만 그렇겠는가. 철저한 사전과정이 없는 실행은 어중간한 형태로 마무리되기 십상이다. 실행력도 중요하지만, 사전계획이 더 중요할 수도 있는 대목이다.
p137
소프트웨어를 디자인할 때 저는 건축가입니다. 유저 인터페이스를 디자인할 때는 예술가이며, 구현할 때는 장인이 됩니다. 하지만 테스트를 할 때는 아마 쳐죽일 놈이 될 것입니다. - 스티브 맥코넬
> 소프트웨어 종사자를 이렇게 멋지게 표현하다니, 감동이다. 특히 쳐죽일 놈의 테스터!
p138
문제해결의 관점에서 소프트웨어 개발을 바라보면 요구사항 분석은 문제가 무엇인지 정의하는 것이고, 설계는 문제릉 어떻게 해결할 것인지 정하는 것이고, 개발은 문제 해결방법을 컴퓨터 언어로 정의하는 것이고, 테스트는 문제가 제대로 해결되는 지를 검증하고 또 다른 문제를 발견하는 것이다.
p142
테스트는 피도 눈물도 없이, 인정사정 없어야 한다
> 테스트가 인정사정없이 가혹해야 한다는 것은 맞다. 그와 함께 중요한 것은 그 테스트 결과에 대한 분석과 판단, 그리고 의사결정이다. 테스트 결과가 정치적으로 악용되거나, 또는 실제 내포하고 있는 위험성이나 중요성이 간과되어서는 안 된다. 정치적으로 악용된 실제 사례를 보면, 정말 사소한 문제로 개발을 지연시키는 행위, 또는 개인의 업적만을 위해서 테스트 결과에서 나온 문제를 과장하는 사례들이 있을 수 있다. 큰 대기업이나 융통성 없는 프로세스가 정착된 회사들에서 많이 보일 수 있는 현상이다. 반대로 그 테스트 결과가 너무 가볍게 다뤄지는 경우도 있는데, 이는 작은 회사나 프로세스가 없이 주먹구구로 일을 하는 회사들에서 많이 나타나는 현상이다.
p146
소프트웨어 업계에서 재사용에 집착하는 것은 다빈치 코드를 해석하여 성배를 찾아 헤매는 것과 유사하다.
p150
요구사항을 재사용해야 한다. 요구사항부터 재사용이 된다면 이후의 모든 공정을 재사용할 수 있다. 비지니스 도메인별로 요구사항 DB를 축적하고 요구사항 추적표를 관리한다
> 소프트웨어는 재사용성, 모듈화가 중요하다. 하지만, 그것들에 너무 집착해서 나무만 보고 숲을 보지 못 하는 우를 범해서는 안 된다. 요구사항을 재사용한다는 개념은 매우 참신한 것 같다.
p155
프로그램을 짠다는 것 고객의 비지니스를 지원할 일을 짜는 일이요(개념), 그 과정에서 부딪히는 온갖 문제를 해결하기 위한 창조의 쥐어짜기요(과정), 자신을 녹여 음식의 부패를 막아주는 소금의 짠맛을 만들어 내는 것(결과)이다. 나는 비로소 프로그램을 왜 짠다고 부르는지 이해할 수 있게 되었다.
p156
프로그램(program)이라는 단어의 어원은 17세기로 거슬러 올라가는데 '어떤 일을 시작하기 이전에'라는 의미의 'pro'와 '글을 쓴다'라는 의미의 'gram'이 합쳐져서 생겼다. 즉, 프로그램은 '미리 글을 쓴다'는 의미였다.
> 글은 손으로 쓰라는 말이 있지만, 프로그램은 절대 손에서 나오는 대로 타이핑을 해서는 안 된다. 비단 요구사항 수집이나 설계와 같은 사전 단계 뿐만이 아니라, 실제 코딩 전 로직을 머릿 속으로 정리해서 '미리 글을 써 놓는 과정'이 선행되어야 한다.
p157
프로그램의 효율성보다 더 중요한 것은 과연 그 프로그램이 고객에게 적합한 것이냐는 효과성에 대한 물음이다.
> 사실 모두가 알고 있는 단순한 사실인데, 프로젝트에 몰두하다보면 숲이나 먼 하늘을 보지 못 하고 땅만 보고 개발하는 경우가 왕왕 생긴다. 개발자 개인의 문제이기도 하겠지만, PM이나 개발팀 전체의 문제일 수도 있다. 사실 개발자들은 소심할 수 밖에 없는 직업병이라면 직업병을 가지고 있는데, 이는 분(minute), 초(second) 단위로 진행되는 일반적인 일상과 달리, 프로그램이라는 것 자체가 micro second 이상의 정밀함을 요구하기 때문이다. 개발자들은 거시적인 시각을 가지기가 어렵고, 자꾸 미시적인 시각으로만 일을 하다보면 시야가 좁아질 수 있다. 쇼펜하우어는 이렇게 얘기한다.
"같은 물건을 오래도록 바라보면 눈이 흐려져서 결국 아무것도 보이지 않게 된다.
그와 마찬가지로 한 가지일만 계속해서 생각하면 오히려 이해하기 어려운 경우가 있다 "
개발자들에게는 특히 편협한 시각에서 벗어나려는 의식적인 노력이 필요하다.
p162
그렇지만 프로그래밍을 예술로 바라볼 때는 한 가지 주의해야 한다. 아르키메데스가 느꼈던 '유레카(알겠다!)'의 감정은 어느 분야에서도 느낄 수 있는 것이다. 프로그래밍이 단순히 기술이나 공학의 수준에 머무르지 않는다는 사실은 프로그래밍이 예술의 속성을 갖고 있다기 보나는 프로그래머가 그 수준에 올라왔음을 말하는 것이다.
p164
나는 앞으로는 소프트웨어 개발이 팀을 매개로 하여 진행되어야 한다고 생각한다. 나는 이것을 '관계지향 프로그래밍(Relationship Oriented Programming)이라 부른다
> 책의 제목을 관계지향 프로그래밍'이라고 지었어도 괜찮았을 것 같다.
p169
훌륭한 프로그래머의 딜레마
> 실제 개발자가 회사에서 겪을 수 있는 공감 100%의 글이다. 경영진이나 관리자들도 피상적으로는 쉽게 일을 하고 문제 자체를 만들지 않는 개발자가 더 훌륭하다고 생각한다. 하지만 자주 보지 않으면 잊혀지듯이, 엄청나게 어려운 문제를 해결한 냥 떠들고 다니는 요란한 빈 수레같은 부류들에게 시선은 쏠리기 마련이다. 장기적으로 볼 때 그런 부류들은 언젠가 밑천이 드러나고 본질이 파악되기 마련이다. 단기적으로 본인의 능력이 폄하되는 것에 기분 나빠할 것이 아니라, 적극적으로 표현하고 본인의 성과를 주장하는 것도 필요하다. 진정한 개발자를 알아보는 안목을 가진 좋은 조직과 좋은 상사가 중요한 이유다.
p171
소프트웨어 공학 최초의 베스트셀러인 <The Psychology of Computer Programming>의 저자인 와인버그(Weinberg)는 프로그래밍은 비자아적이어야 한다는 주장을 한다. 개발자는 그들이 만드는 제품에 자신의 자아(ego)를 투영해서는 안 된다는 것이다
그들은 오류 보고서를 인신공격으로, 동료검토, 코드 리뷰는 위협으로 받아들이고, 그들의 작업에 대한 질문은 비생산적이라고 생각한다는 것이다. 엔지니어들이 한 고집하는 이유가 여기에 있다.
비자아적 프로그래밍은 객관적인 시각에서 자신이 만든 설계나 코드를 보도록 노력하고, 비판을 냉정하게 평가해 옳은 것은 수용해야 한다는 사상이다.
> 실제로는 그렇게 하기가 쉽지 않다. 잘못된 부분에 대한 지적은 받아들이고, 개선을 목적으로 본인의 코드를 객관적으로 바라보는 것은 마땅하나, 개발자에게 있어 코드와 프로그램은 때론 혼신의 노력이 깃든 예술 작품과 다를 바 없다. 때론 자신의 분신처럼 여기는 개발자들도 있다. 자존심 센 개발자들은 본인의 코드에 있는 오류를 남이 지적하고 비판하는 것에 자존심을 다친다. 자신의 작품의 문제를 지적하는 평론가들이 좋게만 보인다면 그는 이미 인격수양이 완성된 군자일 것이다. 피땀흘려 만들어 놓은 자식과도 같은 코드에 발생하는 문제는 본인이 미리미리 개발단계에서 발견하고 개선해나가는 것이 최선이다. 개발이후의 단계에서 발견되는 문제에 대해 자존심이 상할수 있고, 자책감도 느낄 수 있다. 그런 것은 자연스럽고 문제가 되지 않는다. 자존심 상한 나머지 대의를 그르치는 우를 범하지만 않으면 된다. 자신이 만든 코드의 품질을 책임지고, 문제가 생기면 이를 받아들여서 더 좋은 품질의 소프트웨어로 개선시켜나가려는 의지가 필요하다.
p176
XP는 극단적이기리보다는 고객, 개발자, 관리자의 의사소통을 중시하는 관계지향적 프로그래밍에 가깝다.
p180
아기발걸음 - 작은 변화가 큰 변화를 시도하여 실패하는 것보다 훨씬 낫다
> 천개의 작은 변화와 성취가 모여 하나의 큰 성공을 만드는 것이다.
p182
소프트웨어 개발 생산성의 향상을 위한 방법으로 베리 보엠은 우수인력의 확보, 개발 작업의 효율화, 불필요한 개발작업의 제거, 재작업 제거, 단순화한 제품 제작, 컴포넌트 재사용을 제시하였다.
p184
XP 적용의 현실적 문제들
> XP를 프로젝트에 적용하기 위해서는 SW공학적인 경험과 지식이 필요하다. 중요한 것은 구성원 모두가 이해하고 숙지해야 한다는 것이다. 모두가 왜 프로세스가 필요한지 정확히 이해하고 있지 않은 상태에서는 프로세스는 그냥 오버헤드일 뿐이다. 또한 알고 있는 것과 실천은 다를 수 있다. 프로세스의 적용은 팀이나 개인의 의지의 문제라기보다는 개발조직의 문화라는 측면에서 접근해야 할 소프트웨어 개발 지상 과제 중의 하나다.
p197
무엇을 쓰든 짧게 써라 그러면 읽힐 것이다. 명료하게 써라 그러면 이해될 것이다. 그림같이 써라. 그러면 기억속에 머물 것이다. - 조지프 플리처
서울대 최재천 교수는 한 언론과의 인터뷰에서 "디지털이 아무리 새로워진다고 해도 우리는 그 내용을 아날로그로 구상하고 채워야 한다."고
> 어차피 우리가 사는 세상은 아날로그라는 얘기다. 사람은 이성으로 결정하는 것이 아니라 감성으로 결정하는 것이고, 가상세계가 아무리 아름다워도, 맞잡은 두손과 정감어린 눈맞춤에서 오는 기쁨을 당해낼 수는 없는 법이다.
p202
작가는 모든 소문과 지나가는 이야기를 귀담아 들을 책임이 있다 - 그레이스 팔레이
p203
초고는 가슴으로 쓰고, 재고는 머리로 써야 한다. 글쓰기의 첫번째 열쇠는 쓰는 거지, 생각하는 것이 아니다 - 영화 '파인딩 포레스터'에서
> 너무 좋은 영화다. 결말이 너무 뻔하긴 해도, 책에 인용될 만한 좋은 구절들이 많다. 책도 보고, 영화도 보고 일타 쌍피 작렬이다.
p204
개발자들이 문제점을 이야기하면 고객은 질책을 한다
고객이 중요한 사항을 이야기하면 개발자는 무시한다
> 질책은 오타인 것 같고, 질색을 하는 것이라고 생각된다. 고객은 문제에는 관심이 없으니까 질색할 수 밖에 없다. 서로 다른 커뮤니케이션 언어를 가지고 얘기를 하니, 의사소통과 협업에 문제가 없을 수 없다.
p207
소프트웨어 개발자의 가장 많은 성격유형은 신중하고, 조용하며, 현실적이고, 계획적이며, 논리적이고, 집중력이 강하고, 철저하다
> 고등학교 때 한문선생님이 싫어서 이과를 택한 이후로 나는 공돌이의 삶을 살아왔다. 항상 스스로를 공돌이 기질이 전혀 없는 문과적 인간으로 생각해 왔지만, 악화가 양화를 구축한다고 했던가 - 어느 새 나의 성격은 신중하고, 조용하고, 현실적이고, 계획적이며, 논리적이고, 집중력이 강하고, 철저해졌다. 항상 무엇인가를 얘기할 때 첫째, 둘째, 셋째 와 같이 넘버링을 하는 천상 공돌이가 되고 말았다. 태어나서 공돌이로 살아온 시간이 그렇지 않은 시간보다 많기에 어쩔 수 없겠지만, 요즘은 내가 원래 그런 기질이 있었던 것 같기도 하다. 1만 시간도 뛰어넘는 10만시간의 법칙이 작용된 결과이니 공돌이로 재탄생되었다고 해도 사실 이상할 것은 없다.
p211
고객과의 갈등을 대립적으로 풀지 말고 통합으로 이끌어내는 노력이 필요하다. 모든 것은 협상가능하다. 상대방의 감정에 감정적으로 대응해서는 안 된다
p225
계속적인 개선이 지연되는 완벽함보다 낫다. 시장 선도자는 혁신을 일상적인 것으로 만드는 법을 배워야 한다 - 마크 트웨인 & 필립 커틀러
> 이는 애자일 방법론의 핵심이다. 꼭 소프트웨어나 개발방법론에만 적용되는 것이 아닌 우리의 일상에 적용되어야 하는 삶의 기술이다.
p229
대부분 ISO같은 인증 획득에만 골몰한다. CMMI Lv5의 최상위 조직이라 하더라도 프로세스가 조직문화로 제대로 정착된 사례를 목격하기 어렵다.
> 프로세스가 조직문화로 정착되기는 정말 힘들다. 우선 좋은 조직문화가 있어야, 프로세스도 정착이 가능하다. 소프트웨어 강국인 인도는 CMMI Lv5를 획득한 회사들이 적지 않다. 과거 대기업에서 일할 때 그런 회사와 일한적이 있었는데, 그들조차도 프로세스가 형식에 불과한 경우가 적지 않았다. 그당시 내가 근무하던 회사에서는 이전에 GE에서 도입해던 식스시그마라는 품질개선활동을 했었는데, 이 활동의 99%는 시간만 잡아먹는 쓰레기나 다름 없었다. 프로세스는 양날의 검이다. 그리고 대부분 제대로 사용하고 있지 못 하다.
p231
변화와 혼돈은 동의어이다. 성공하기 위해서는 두 가지를 모두 겪어야 한다.
p234
코딩과 테스트는 소프트웨어 개발에서 단지 우유적 속성일 뿐이고, 소프트웨어 개발의 본질은 서로 맞물려 돌아가는 여러 컨셉들을 명세화하고 설계하며 검증하는 것이라고 주장한다.
p237
이 세상에는 계획 하나도 제대로 세우지 못하기 때문에 실수조차 못하는 사람들이 있다 - 괴테
조지 도란은 "계획을 세울 때는 구체적이고(Specific), 성과를 측정할 수 있어야 하며(Measurable), 자원이 할당되어야 하며(Assignable), 현실적이며(Realistic), 시한이 정해져야 한다(Time related)"고 말했는데, 이것의 앞글자를 따서 SMART 방법론이라고 한다
p245
추정은 완벽할 수 없다. 똑같은 프로젝트가 없기 때문이다. 정확하다는 것은 오차한계가 좁아진다는 의미일 뿐이다. 추정은 주어진 정보를 가지고 해당시점에서 최선을 다하는 것이다.
> 추정은 추정일 뿐이다. 그리고 그 사실을 경영진과 관리자가 명백하게 인식하고 있어야 한다. 추정에 실제 개발자들를 참여시켜서 가능한 정확도를 높임과 동시에 그들에게 책임감과 자율성을 부여해주는 것이 필요하다.
p249
Backward로 일정계획을 수립하지 말고 Forward한 방식으로 하라
> 쉽게 간과되는 부분이다. 대부분, D-Day를 기준으로 역산하여 일정을 수립한다. 특히 제조업에서는 더욱 그러하다. 하드웨어와 같은 자재의 수급일정과 고객에게의 출하시점을 기준으로 소프트웨어 일정을 억지로 끼워넣는 경우가 허다하다.
p270
크로스비 박사는 여기에 한술 더 떠서 "품질은 무료다 Quality is free"라고 말한다 최초에 올바르게 일을 하면 돈이 들 이유가 없다는 것이다
품질에 대한 경영진의 투자를 이끌어 내려면 품질비용을 토대로 과거에 수행한 프로젝트의 비용 내역을 제시하는 것이 효과적이다
> 경영진들은 망각의 동물인듯 하다. 제품의 품질문제로 인한 비용을 지불했던 과거는 금방 잊어버린다. 그들의 기본적인 마인드는 품질은 협상가능하다는 것이다. 개발자나 프로젝트 관리자가 대화의 기술을 키워야 하는 이유는 그런 경영진을 설득시켜야 하기 때문이다.
p275
위험관리를 가장 적절하게 표현한 비유가 바로 새도우 복싱이다. 장차 발생한 가상의 위험을 상대로 지금 한판 승부를 겨뤄 자신의 약점을 보완하고 실제 위험이 현실화 되었을 때를 대비해 근력을 키우는 것이다.
p277
위험관리가 프로젝트 현장에서만 관리되는 현실을 들 수 있다. 조직의 중심이 아닌 변두리에서 위험이 관리된다. 위험관리의 몫은 프로젝트 관리자에게만 있을 수 없다. 요즘처럼 프로젝트가 복잡하고 대형화되는 추세에서는 오롯이 프로젝트 현장에서만 위험을 감당하기는 어렵다.
p279
문제의 징후는 반드시 먼저 찾아온다는 사실을 주지 또 주지하라. 방귀 잦은 놈이 똥 싼다
> 신입사원 딱지를 뗀지 얼마 되지 않았던 시절, 업무에 시달리고 매너리즘에 빠져있던 어느날의 일이다. 프로젝트의 초기개발 단계였는데, 갑자기 소프트웨어의 이상동작을 발견했다. 문제는 두번 다시 재현되지 않았다. 그냥 내가 잘못 본 것인가, 뭔가 우연히 발생한 것이겠지 하며 그냥 넘어갔다. 소프트웨어라는 것은 우연이라는 것을 허락하지 않는다. 시간이 흘러 제품출시가 임박해졌을 때 난데없이 큰 문제가 터졌고, 며칠을 밤새워가며 문제의 원인을 분석한 결과 오래전 내가 보았던 바로 그 문제임을 알게 되었다. 그때의 혹독한 경험덕분에 이제는 작은 이상동작이라도 절대 간과하지 않는다. 한번 생겼던 문제는 언젠가, 그것도 정말 중요하고 더욱 해결이 힘든 시점에 터진다는 것을 알고 있다. 난감한 곳에서 똥싸지 않으려면 미리미리 속을 챙겨야 한다.
p280
무책임은 무능으로 직결된다. 문제해결능력이 있을 리가 없다. 무능한 조직이 오래 갈 수 있을까?
p298
고객과의 첫 공식적인 활동인 착수(Kick off) 보고에서 중요한 것은 고객의 니즈와 이슈를 정확히 이해하는 것이다.
> 요구사항 수집의 중요성은 두말할 나위 없이 중요하다. 단추를 제대로 끼지 않으면 프로젝트는 시작부터 실패라고 봐야 한다. 책을 보면서 행간을 읽어내듯이, 고객이 직접 요구하지 않더라도 고객의 니즈와 이슈를 가능한 정확히 파악해서 요구사항에 포함시켜야 한다.
p301
일단 의심하라. 말 뒤에 숨겨진 진의를 파악하라. 그럴듯해 보이는 제안은 정말 유익한 지 따져보고 협의해야 한다.
기록하라 회의록을 작성하여 반드시 근거를 남겨라
p305
그런즉 기술, 프로세스, 사람, 이 세가지는 항상 있을 것인데 그 중의 제일은 사람이라
p310
짐 콜린스는 <Good to Great>에서 "누가 적합한 사람인지의 여부는 전문 지식이나 배경, 기술 보다는 성격상의 특질이나 타고난 소양과 더 관련이 있다."고 주장한다
p312
개인의 역량과 책임 중심의 팀이 흔히 보여주는 병폐는 개인의 노동력을 착취하는 모습을 보여준다는 점이다.
프로세스 기반의 팀에서 나타나는 부작용은 관료주의다. 프로젝트 관리자는 자주 이렇게 말한다. "시키면 시키는대로 할 것이지 무슨 말이 많아?" 문서와 회의가 많아지고 일방적인 지시에 의해 일이 진행된다. NATO(No Action Talk Only)가 일상화된다.
p315
우리가 산다는 것은 장작불 같은거야
먼저 불탄 토막은 불씨가 되고
빨리 불붙은 장작은 밑불이 되고
늦게 붙은 놈은 마른 놈곁에
젖은 놈은 나중에 던저져 마침내
활활타는 장작불같은거야
우리가 산다는건 장작불 같은거야
장작 몇개로는 불꽃을 만들지 못해
여러 놈이 엉켜붙지 않으면
절대 불꽃을 피우지 못해
몸을 맞대어야 세게 타오르지
마침내 활활 타 올라 쉿덩이를 녹이지
- 백무산의 시 <장작불>
p320
훌륭한 관리를 위한 4가지 필수 요건,
적절한 사람을 구한다.
그들에게 알맞은 일을 할당한다. 항상 동기 부여를 한다.
팀이 결속하도록 하고, 그 상태를 유지하도록 돕는다
(이외의 나머지 일은 전부 허드레 관리업무다)
- 톰 디마르코의 <데드라인> 중에서
p323
진정한 리더는 뛰어난 위기관리, 문제해결능력을 갖추고 있다. 폭풍을 만나야 누가 뛰어난 항해사인지 알게 되는 것과 같다.
p326
경영 컨설턴트 나딤 마타는 "프로젝트 리더는 장기적인 목적과 단기적인 실적 사이에서 균형을 유지해야 하며, 추진 과정뿐만 아니라 실제 성공을 이루어 내도록 리드해야 한다."고 말했다.
p327
프로젝트 관리자의 룰 - 식은 열정, 미그적거림, 나약한 PM은 부적격하다
p344
문제는 각 단계로의 진입장벽이 거의 없다는 것이다. 분명 담당 직무에 필요한 역량이 상이함에도 불구하고 연수가 차면 자동으로 무임승차가 된다. 그래서 오로지 개발자 마인드로만 프로젝트를 수행하는 PM을 심심찮게 보게 된다
> 개발자들은 나이가 들고 연차가 차면 자연스럽게 프로젝트의 개발리더로서 활동하게 된다. 여기서 능력의 차이가 극명하게 갈린다. 프로젝트 개발 리더(Project SW Development Leader)는 프로젝트 관리자(Project Manager)의 역할도 부분적으로 수행하게 되면서 미시적인 시야에서 거시적인 시야로 업무의 스펙트럼을 확장하게 된다. 여기서 기술적으로 뛰어난 이들이 소프트웨어 내지는 시스템 아키텍트(Architect)의 직무를 맡게 된다. 아키텍트는 미시적인 시야와 거시적인 시야 모두를 가지고 있어야 한다. 관리적인 역량이 뛰어난 이들은 프로젝트 관리자의 직무를 맡는 것이 좋다. 어느 쪽이든 개발 프로젝트를 책임지는 이들은 기술과 비지니스 두 부분의 조화를 추구해야 한다. 아키텍트중 기술적인 부분만을 고집하는 테크니컬 아키텍트보다는 비지니스에 대한 이해에 기반하여 시스템을 설계하는 마케팅 아키텍트으로 전환이 필요하다. 마찬가지로 개발자 출신이 아닌 프로젝트 관리자들은 기술에 대해 깊은 이해를 갖춰야 하는 것은 당연한 애기다.
p359
무엇을 모르는지를 아는 것이 지식의 가장 중요한 부분이다 - 노자
> 후배 사원들에게 일을 시킬때 가장 중요하게 생각하는 부분중의 하나다. 일을 하는데 있어 어떤 기반지식이나 기술이 필요한지 알아야 하는 것처럼, 내가 무엇을 모르고 있는지를 알아야 한다. 당연한 애기처럼 들리는데, 실제 현업에서 일을 하다보면 자기가 무엇을 모르고 있는지를 모르는 사람들이 적지 않다.
p376
피터의 법칙에 따르면 "위계질서 안에서 일하는 사람들은 자신이 무능력한 수준에 도달할 때까지 승진하려는 경향이 있다."고 한다.
404
'왜' 살아야 하는지를 아는 사람은 '어떤' 상황도 견뎌낼 수 있다. - 니체
> '죽음의 수용소에서'의 저자 빅터 프랭클이 생각나는 대목이다. 왜 살아야 하는지를 안다는 것은 자기 내면의 영웅이 이미 부활했음을 의미한다. 내 삶을 살아가는 것이다. 왜 살아야 하는가 - 내 삶이기 때문이다.
내가 저자라면
책은 4부 10장의 구성을 취한다. 1부 생존, 2부 정진, 3부 도약, 4부 비전이라는 각 부의 제목에서 알 수 있듯이 책의 흐름은 과거에서 미래, 현실에서 이상으로 흐르는 구조를 가진다. 자기 개발서에서 가장 보편적인 구조이며 독자가 자연스럽게 책의 내용에 빠질수 있는 흐름이다. 그럼 이 책이 독자에게 말하고자 하는 바는 무엇인가? 다시 말해 저자의 의도는 무엇인가? 소프트웨어 개발을 잘 하기 위해서 읽어야 하는 책일까, 아니면 프로젝트를 성공적으로 수행하기 위해서 읽어야 하는 책인가, 궁극적으로 IT 전문가가 되기 위해 무엇을 해야 하고 어떻게 해야 하는지 얘기하고 싶은 것인가? 책을 읽는 독자는 자신의 상황, 즉 독자의 컨텍스트를 책에 투영시키게 된다. 책은 IT와 소프트웨어 개발의 진짜 현실을 가감없이 드러낸다. 그럼으로써 이 책의 주요 독자라고 할 수 있는 개발자들에게 알고는 있지만 애써 외면하고 덮어 두었던 어두운 현실을 적극적으로 상기시킨다. 스스로를 아는 것에서부터 삶의 여행이 출발할 수 있듯이, 소프트웨어 개발의 현실을 냉정히 짚어보는 것에서부터 책의 내용은 시작된다.
목차
[프롤로그]변화를 통한 새 길 트기
1부 [생존] IT 업계에서 살아가기
1장 불타는 갑판
월화수목금금금
사무실이 기가 막혀
5개월 만에 출산하기
뫼비우스의 띠
레드오션(Red Ocean)
2장 동굴의 우상(偶像)
소프트웨어 진짜 위기
일단 짜보고 고치기
실패하는 프로젝트의 7가지 습관
생존을 위해서는 직면한 문제들을 정확하게 파악해야 한다. 소프트웨어 개발의 현실적 문제들은 간단히 말해 초과근무, 열악한 근무 및 개발 환경, 무리한 일정, 잘못된 관행, 개발의식과 개발문화의 미성숙으로 정리될 수 있다. 저자는 소프트웨어 위기의 근본적인 원인으로 잘못된 개발 관행, 다시 말해 일하는 방식의 전근대성과 사람을 일의 중심으로 인식하지 못하는 것을 들고 있다. 2장의 마지막 내용인 '실패하는 프로젝트의 7가지 습관'은 1부의 최종 정리인 동시에 앞으로 책의 후반부에서 저자가 이것들을 '성공하는 프로젝트의 7가지 습관'으로 전환하고자 함을 나타낸다. '실패하는 프로젝트의 7가지 습관'은 다음과 같다.
[사람] - 사람이 무시된다
[추정] - 추정이 모호하고 비현실적이다
[요구사항] - 요구사항이 불안정하다
[계획] - 계획수립이 엉성하다
[통제] - 프로젝트 진행 상황을 파악하지 못 한다
[위험] - 위험을 관리하는 할동이 없다
[품질] - 품질보증 활동이 미흡하다
2부에서부터 어떻게 문제점들을 극복하고 개선할 수 있을지에 대한 내용이 전개된다. 내가 저자라면 1부 이후의 책의 목차나 구성이 명확히 이를 드러내도록 7개의 장으로 구성해서 각 꼭지들을 알맞은 곳에 배치하는 게 어떨까 싶다. 그렇게 하면, 좀 더 일관적인 흐름을 가질 수 있지 않을까 싶다.
2부 [정진] 소프트웨어 개발 잘하기
3장 개발 생산성 혁신
요구사항을 개발하라
프로토타이핑 퍼포먼스
아키텍처를 아시나요?
아키텍처 뷰 등과 같은 지극히 이론적인 내용은 책의 전체적인 흐름에 그다지 어울리지 않는 것 같다. 내가 저자라면 기술적인 내용은 부록으로 따로 빼서 다룰 것 같다. 부록에서 그 내용을 다루면서 더욱 상세한 내용은 웹사이트와 같은 관련 링크나 관련 서적을 소개하도록 하겠다, 실제 본문에서는 아키텍처의 중요성과 실제 활용예, 그리고 간과되는 경우 발생하는 문제를 위주로 더 내용을 전개해 나가는 것이 좋을 것 같다.
모델링, 씨줄과 날줄
지금은 스타일 시대
명세 없이 코드 없다
인정사정 볼 것 없다
재사용은 양치기 소년
4장 관계지향 프로그래밍
프로그래밍을 바라보는 4가지 시선
팀 플레이 프로그래밍
eXtreme Programming
XP를 프로젝트에 적용하기
5장 연금술
프로그래머와 글쓰기
커뮤니케이션 능력 향상
혼이 있는 소프트웨어 개발
2부는 1부에서 짚어 냈던 문제들에 대한 상세한 분석을 제공함과 동시에 해결방안으로서 소프트웨어 공학적인 원리들과 방법론들을 제시한다. 간단히 핵심을 정리하면 요구사항, 설계, 모델링, UI, 테스팅, 재사용, 관계지향 프로그래밍, XP, 기술적 글쓰기(Technical Writing)와 같은 주제로 소프트웨어 개발의 다소 미시적인 문제를 다루고 있다.
3부 [도약] 프로젝트 성공하기
6장 프로세스 혁신
기업의 뼈대, 프로세스
프로젝트 전반부에 집중하라
계획 무용론 VS 계획 결정론
프로젝트의 원죄, 추정
일정 단축하기
소프트웨어는 소프트 하지 않다
동료 성토? 동료 검토!
품질은 여유 있는 자들의 행복한 비명
프로젝트 중심에서 위험을 외치다
실패를 통해 배운다
7장 고객 중심 프로젝트
고객에 대한 깊은 이해
고객 참여와 협상
8장 숨겨진 힘, 사람
사람을 최우선으로 대하라
드림 팀을 꿈꾸며
PM은 리더다
개발자 채용하기
2부에서 소프트웨어 개발 자체를 다루면서 다소 미시적인 부분에 초점을 맞추었다면 3부에서는 프로젝트라는 보다 거시적인 관점으로 내용이 전개된다. 개인적으로는 '8장 숨겨진 힘, 사람'의 내용이 좋았다. 소프트웨어 개발 회사에서 발생하는 모든 문제들의 근본적인 원인은 기술이 아니라 사람에게 있다는 것이 이 책을 관통하는 핵심 철학이라면 8장의 내용을 4부에 이어서 확장 전개하는 구조를 취했으면 어떨까 싶다.
4부 [비전] IT 전문가로 성장하기
9장 IT 전문가의 조건
전문가로 가는 길
IT 전문가 프로필의 변화
스티브 잡스와 안철수
10장 IT 전문가 경력개발
IT 지식체계
p361에서 p370까지의 내용은 이론적인 부분으로 개념이나 용어의 설명이 주를 이룬다. 책이 소프트웨어 실무 기술서적이 아닌 이상 책의 내용과 조화되지 않는 감이 없지 않다. 해당 내용에 대해 잘 모르고 있는 초심 개발자들에게는 자신들의 커리어를 어떻게 전개해 나갈 것인지 지도를 보여준다는 측면에서는 나쁘지 않다. 내가 저자라면, 용어나 개념에 대한 원론적인 설명은 부록으로 빼겠다. 책의 구성에 있어 필수적인 내용이라면 부록에서 오히려 더 많은 설명을 명료하게 제공하는 것이 좋을 수 있다.
개발자 경력 로드맵
나의 기술사 도전기
IT 전문가 육성하기
[에필로그]질문을 품고 살아가기
저자가 하고 싶은 얘기는 대부분 3부의 마지막 챕터인 '8장 숨겨진 힘, 사람'을 맺으며 마무리 된 것은 아닐까 생각이 들었다. 4부는 그렇게 본다면 보너스와 같은 내용이 아닐까? 전문용어들이 나열된 챕터나 개발자 경력 로드맵, 그리고 저자의 기술사 도전기 등은 부록으로 다뤘으면 더 좋지 않았을까 생각 된다. 내가 저자라면 3부 마지막 장인 사람에 대한 내용을 좀 더 확장해서 4부에 다루고, 4부의 대부분 장들은 부록으로 다루겠다. 책을 읽으면서 개인적으로 아쉬웠던 부분은 순수하게 기술적이며 원론적인 내용들이 책의 정체성에 다소 혼란을 줄 수도 있겠다는 생각이 들었다. 내가 저자라면 그런 내용들은 부록에서 체계적으로 다루는 것으로 구성할 듯 하다. 저자가 책에서 강조하고 있는 것은 결국 사람이다. 그런 측면에서 책의 제목을 내용중에 나오는 단어인 관계지향 프로그래밍이라고 지었더라도 나쁘지 않았을 것 같다.
프랑스 시인인 폴 발레리는 "생각하는대로 살지 않으면, 사는대로 생각하게 된다"고 말했다. 주어진 현실을 개선하려는 노력을 하지 않으면, 현실의 노예가 되어서 살 수 밖에 없다. 누구나 끊임없이 본인의 일과 삶에 질문을 던지고 어제보다 더 나아진 내가 되려는 노력이 필요하다. 그런 면에서 이 책은 대한민국의 소프트웨어 개발자들에게 특화된 한권의 지침서이다. 대한민국의 소프트웨어개발자들이 주체적인 일과 삶을 찾는데 도움을 줄 수 있는 <대한민국 개발자 희망보고서>와 같은 좋은 책들이 많이 나오기를 바래본다.
VR Left
