포토/동영상 (1)
|
대한민국 개발자 희망보고서, 제목이 참 좋습니다.
뭔가 딱히 짚어 내기는 어렵지만 무언가 부족한 책일 듯 하다는 느낌을 받았습니다.
그럼에도 불구하고 찜찜함은 가시지 않았습니다. 어떻게 북 머지를 해놓고 희망보고서라는 거창한 제목을 붙였는지 의문입니다. 한가지 덧붙이자면 다른 사람의 저서를 무수히 인용하고 무단으로 같다 붙였음에도 불구하고 책에는 어떤 저자의 어떤 도서 / 논문 등을 참고 했는지 참고 문헌 소개가 전혀 없습니다. 기본이 안되 있다고 봐야 하는 거지요.
참으로 개탄스럽습니다.
ps. 초보 개발자들은 전체의 내용을 담고 있는 원전을 읽어야지 이런 요약본을 읽는 것은 바다에서 표류중의 갈증을 잊기 위해서 바닷물을 마시는 것과 같은 행동이라 생각이 듭니다. |
|
이런 책이 왜 이제야 나왔나 하는 생각이 듭니다. 많은 개발자들이 흔히 자신이 하는 일에 대해 노가다 라고 표현합니다. 저자는 자신을 전문가라고 생각합니다. 대한민국 개발자라면 이 책을 꼭 읽어봐야 한다고, |
|
리뷰나 평 그리고 판매지수에 비해 상당히 실망한 책.
이책 저책에서의 인용. 인용에 대한 설명. 누구나 다 알고 있는 SI 현실의 문제점 나열 그리고 이에 대한 아주 교과서적인 해결 방안 제시.
이 기술 저기술 방법론에 대한 표현. 과연 저자 스스로 거기에서 말하는 것을 그대로 실천하였는지. 아니면 이러면 좋겠다고 그냥 책에 나온 얘기를 그대로 옮겼는지 그것 자체도 궁금.
그리고 왜 책제목이 희망보고서인지 전혀 알수 없음.
솔직히 많이 실망한 책. |
|
이 책은 요상한 책이다. 명색이 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년만에 가족여행을 떠난 이 행복한 가족의 모습을 지켜보며 우리도 작은 용기를 내어 그가 안내해 주는 길을 나서 보면 어떨까?
|
|
이책은 한 직장인의 치열한 삶의 흔적이 가득하다. 그래서 더욱 아름다운 책이다. 비록 IT개발자를 위한 책이라고 하나 비전문가인 내가 읽어도 시원한 책이다
이세상의 진리는 결국 하나로 합쳐진다. 시내가 강이 되어 바다로 흐르듯이 말이다. 이책을 통해 대한민국 개발자들의 희망을 엿볼 수 있다. 그래서 이책은 희망보고서일 것이다.
|
|
내가 웹과 인연을 맺은 것은 1998년도 즈음 당시 회사의 홈페이지를 한글, 영문판 두개를 직접 만들었는데 호기심 반, 재미 반 만들어 본 홈페이지가 너무 좋아서 결국 이쪽 분야로 발을 담그게 되었고 지금도 치열한 SI 프로젝트 현장에서 일한다. 그래서 이 책에서 저자가 건네는 수많은 이야기에 고개를 끄덕이며 공감하지 않을래야 않을수가 없었다. 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전문가로 되기 위해서 내가 해온 것들이 무엇인가에 대한 질책을 하기 시작했다. 일단 짜보고 고치고, 나역시 월화수목금금금의 이런 근무 상황을 어쩔수 없지 라는 말 한마디로 일축하곤 했다. 품질에 대한 잘못된 오해가 있었음을 인정한다. 내가 전문가로서의 혼을 가지고 일에 임하지 못했음을 시인한다.
다만, 이 책을 읽는 독자들은 이런 착각을 할 수 있다. "소프트웨어 개발자로서 이런 마음을 가지지 않으면 안되는 것 같네?" "난 이런 마음을 가지지 못하니 오래 못하겠다. 이제 그만 다른길을 준비해야지" "나는 이런 자질이 없으니 희망이 없군." 이런 질문은 저자의 의도에 대한 오해라고 말하고 싶다.
이책의 주제는 변화다. 당신이 가진 마인드에 대한 질문이다. 그리고 현실 문화의 어긋남에 대한 질책및 책임감에 대한 고찰이다.
저자의 경험이 그리고 저자가 제시한 방향이 정답이라고는 생각하지 않는다. 다만, 우리에게 이런 글을 보여줄 수 있는 분들이 있기에 우리에겐 아직 드러나지 않은 풍부한 Role 모델이 등장 하리라 본다.
저자의 소중한 경험, 소중한 생각, 그리고 신랄한 현실 비판과 방향제시 에 대해 감사드린다. |
|
이 책의 제일가는 미덕이라고 꼽으라면... 공감이 가는 부분이 참 많다는겁니다. 표지에 써있는 월화수목금금금은 물론이고 공사중인 건물 속에 있는 개발실이라든가, M/M을 두배로 늘려서 기간을 반으로 줄이라고하는 어이없는 갑돌이라든가, 공공프로젝트의 '정신적인 공황'을 견뎌야 한다라던가하는...... '토종 개발자'의 내공과 포스가 느껴지는 부분입니다. ^^
맨땅에 헤딩과 삽질을 반복하는 노가다같고 몸파는 앵벌이 매춘 같기도 하지만 목구멍이 포도청이라 자위하며 많은 분들이 아둥바둥 매달리고 있는 부분이 이 넘의 SI지요. 저는 개인적으로는 이런 난감함에 대한 답을 찾고 있는 중입니다. 누가 해답지를 파는 것은 아니겠지요.이 책에서도 해답을 얘기하고 있진 않습니다. 단지, '발자국'같은 책이라 생각합니다. 이 땅에서, SI 종사자로서 누군가가 그 험난한 길을 어떻게 무사히 걸어갔는지 써있습니다. 그리곤 그 발자국에 '희망'을 써놓았더군요. 아~ 희망이라... |
|
◎ 소감 책을 완독한 후 자연스레 그런 생각이 들었다. 정말 하고 싶은 얘기가 많으셨구나. 오랜 IT 경력과 다양한 프로젝트 경험 그리고 그것을 통해 쌓였던 노하우, 사색 등을 한꺼번에 토해낸 책이 아닌가 싶다. 책의 분량도 만만한 편이 아니지만 저자가 책에서 다루고 있는 내용의 범위도 읽기가 만만치 않다. 아직 역사가 짧은 탓에 적지 않은 시행착오를 겪고 있는 IT 업계의 문제점, 소프트웨어 개발이론 및 현황과 사례, 프로젝트 수행 이론, 그리고 IT 전문가의 경력개발론에 이르기까지 하나의 책에서 여러가지 주제를 다루고 있다. 아무래도 같은 직종에서 일하다 보니 중간중간 공감되는 내용이 많다. 예를 들면 개발자 간, 혹은 개발자와 고객간의 커뮤니케이션을 강조하는 부분은 현장에서 근무하는 사람들이라면 충분히 경험해 봤음직한 내용들이다. 다만 이렇게 책으로 그것을 정리함으로써 무엇이 문제가 명확해지고 그러다보면 자연히 해결책도 명확해진다. 책 한권이 얼마나 의미 있는 역할을 해내는가를 설명해주는 부분이다. 한편으로 읽는 중간중간 다양한 인용을 접하다 보면 저자의 방대한 독서량을 어렵지 않게 짐작할 수 있다. 듣도 보도 못한 소프트웨어 공학 관련 외서부터 철학, 경제서에 이르기까지 두루 인용되어 있는 것을 보면서, 이 책 한권을 위해 저자가 들인 노력이 느껴졌고 감탄하지 않을 수 없었다. 아울러 '개발자'라는 이름을 붙이고 일하는 데에 부끄러움을 느끼지 않을 수 없다. 이렇게 열심히 일하면서 열심히 공부하는 전문가가 있는 반면, 현재 지니고 있는 기술에 안주하여 주어진 상황만 처리하는 '코더'가 모두 개발자로 불리고 있으니 그러한 상황에 감사해야 할지도 모르겠다. 내용이 방대해서 그렇지 개발자외에 일반 직장인들이 보아도 좋은 내용들이 곳곳에 숨어 있다. 예를 하나 들자면 초과 근무에 대한 인식 전환인데 저자는 '열심히 일하기' 에서 '현명하게 일하기'로 인식이 전환되어야 한다고 주장하며 나 역시 공감한다. 그 외에 기술결정론의 허구, 개발자들간 혹은 개발자와 고객간 커뮤니케이션의 중요성, 리더십과 전문가에 대한 개념 정립 등은 일반 직장인들이 읽어 보아도 귀감이 될만한 부분들이다. 농담반, 진담반 섞어 한 가지 아쉬운 점을 얘기한다면, 개인적으로 이 책을 읽고 나서 '희망'이 생기기 보다는 '고민'이 많이 늘었다. 물론 이 책을 유용하게 쓸 수 있는 전문가 그룹은 따로 존재한다. 나는 엄밀히 말해 그 그룹에 들어가지 않는다. 그러다보니 이 책에서 제시하는 '희망사항'들은 희망으로 다가오지 않고 나는 여전히 스스로 희망을 새로 만들어야 하는 과제를 새삼 확인하게 됐다. ◎ 마음에 들어온 글귀 초과근무에 몰두하는 또 다른 이유는 다소 끔찍한 생각이지만 일이 잘못 되었을 경우를 대비한 보호수단으로 활용될 수 있다고 믿기 때문이다. 일종의 면죄부인 셈이다. 현명하지 못한 관리자는 직원들이 사생활을 희생해서라도 더 오래 더 열심히 일하도록 해야 일을 잘한다고 생각한다. 왜냐하면 그는 성과 위주로 직원을 평가할 능력이 없기 때문이다. 그렇다면 초과근무를 가능한 줄이면서 생산성을 높일 수 잇는 방법은 무엇이 있을까? 이 물음에 대한 대답은 일에 대한 인식의 전환을 수반한다. 첫째, 이제는 열심히 일하기(Work Hard)에서 현명하게 일하기(Work Smart)로 변화하고 있다. 피터 드러커는 지식 근로자의 경웅 ‘현명하게 일하는 것’이야말로 일의 생산성을 높이는 유일한 방법이라고 강조한 바 있다. 소프트웨어 개발과 같은 지적 노동의 경우에는 일의 질과 시간이 비례하지 않는다. 일 잘하는 사람은 먼저 일에 대해 생각하고, 스마트하게 일할 수 있는 방법을 찾아내고, 비효율적이고 불필요한 관행을 타파하는데 주력한다. 둘째, 직원들이 일을 통해 성취감을 느끼고 일 자체를 즐길 수 있도록 다양한 방법들이 모색되어야 한다. 일에 대한 생산성을 획기적으로 닢일 수 있는 유일한 방법은 동기부여라는 것을 명심해야 한다. 바쁘다는 것은 일의 목적이 아니다. 오히려 바쁨 속에서 우리는 일의 진정한 가치를 잃어버리고 있는지도 모른다. 커뮤니케이션 이론에 따르면 사람수에 따라 커뮤니케이션은 더 복잡해지고 비용은 기하급수적으로 증가한다고 한다. 문제는 기술적인 것이 아니라 사람에 관련된 일이다. 다들 사람이 중요하다고 말을 한다. 그러면서도 행동이 따르지 않는 이유는 사람이 도구, 기술, 프르세스보다 다루기 어려운 문제이기 때문이다. 그리고 그 일은 보통 팀, 프로젝트를 통해 진행하기 때문에 사실은 커뮤니케이션을 다루는 일에 종사한다고 볼 수 있다. 건축과 IT 서비스의 차이는 건축의 경우에는 눈으로 분명하게 진행상황을 확인할 수 있지만 IT 서비스의 경우에는 쉽지 않다는 점이다. IT 서비스 업체들의 사업 대상은 국내 모든 산업 분야에 걸쳐 있기 때문에 산업별로 고유한 업무의 특성을 이해하지 못하면 성공적인 프로젝트를 수행할 수 없다. 정보기술 전체를 조망할 수 있는 아키텍트와 함께 각 산업의 특징을 이해하고 시스템에 적용할 수 있는 업무 전문가의 육성이 시급하다. 또한 대형 프로젝트를 수주하고도 프로젝트를 제대로 수행할 수 있는 프로젝트 관리자가 드물다. 프로젝트 관리자는 소프트웨어 개발 경험을 바탕으로 인문학적 감수성, 리더십, 경영마인드 역량이 요구되는 전문가다. 프로젝트 관리자의 직무는 소프트웨어에 대한 지식과 경험만으로는 잘 수행되기 어렵다. IT 전문인력의 양성에 있어서 편식은 금물이다. 분야별 전문인력이 골고루 양성되어야 한다. 그리고 이제는 인력의 질적 수준의 문제를 심각하게 고려해야 한다. 이 땅에서 을로 살아간다는 것은 참으로 고되고 어려운 일이다. 품삯을 위해 분을 삭히거나 갑과 전투를 벌여서 승리해야 한다. 기술이 바뀌면 시대와 사회가 변한다고 생각한다. 그러나 그것은 '기술 결정론'의 허구다. 새로운 기술이나 발명품이 나와도 그것을 옛 개념으로 사용하는 한 진정한 변화는 일어나지 않는다. (이어령의 디지로그 中) 소프트웨어 개발은 기술의 문제로만 인식되어 사람은 부차적인 존재로, 하나의 모듈로 간주되고 있다. 개발인력을 아웃소싱의 대상으로만 보려는 관행이 널리 퍼져 있다. 이제 소프트웨어 개발은 사람을 일의 중심으로 보는 휴머니즘을 회복해야 한다. 소프트웨어 산업은 그 자체가 인간활동(human activity)이며 따라서 지적 자산이라고 할수 있는 '사람'이 가장 중요하기 때문이다. 행운은 지속적으로 반복되지 않는다. 그리고 행운은 우연보다 성실함과 더 친하다. 인터뷰를 통해 요구사항을 수렴할 때 고객이 합리적으로 행동하고 있을 것이란 가정을 하지만 실은 고객은 질문한 사항에 대해서만 대답할 뿐 그 이상은 잘 말하지 않는다. '알아서 잘해주세요.'라고 방관자적인 미소만 지을 뿐이다. 열 길 물 속은 알아도 한 길 사람 속은 알기가 어려운 법이다. 생떽쥐베리는 '완벽한 설계는 더 추가할 게 없을 때가 아니라 더 이상 뺄 것이 없을 때 완성된다'라고 했는데 이 친구의 그림을 보고 있으면 왜 그런지 이해가 된다. 단순한 것이 아름답고 진실에 가깝다. 프로그램을 짠다는 것 고객의 비즈니스를 지원할 일을 짜는 일이요(개념), 그 과정에서 부딪히는 온갖 문제를 해결하기 위한 창조의 쥐어짜기요(과정), 자신을 녹여 음식의 부패를 막아주는 소금의 짠 맛을 만들어 내는 것(결과)이다. 나는 비로소 프로그램을 왜 짠다고 부르는 지를 이해할 수 있게 되었다. 디지털 시대에 역설적으로 아날로그 방식은 글쓰기가 중요해진 이유는 무엇일까? 서울대 최재천 교수는 한 언론과의 인터뷰에서 "디지털이 아무리 새로워진다고 해도 우리는 그 내용을 아날로그로 구상하고 채워야 한다."고 그 이유를 설명한다. 일하는 방식을 '열심히(work hard)'에서 '스마트하게(work smart)'로 변화시켜야 한다. 무조건 열심히 일하는 것이 미덕인 시대는 한참 지났다. 문제가 더욱 복잡해진 시대가 되어 이제 문제해결은 논리적인 접근보다 창의적인 방법에 의해 시도될 때 잘 풀린다. 프로젝트는 희마사항이 아니라 냉엄한 현실이다. 진실이 담긴 현실적 낙관주의가 절실하다. 이제 착취와 관료주의 조직을 넘어서 유연한 팀워크를 기반으로 하는 프로젝트 팀의 모습으로 거듭나야 한다. 그것은 오케스트라 조직과 닮아 있으며 영화제작 팀과도 비슷하다. 영화제작 팀은 코끼리(대기업)와 벼룩(프리랜서) 조직의 장점을 취한 미래 조직의 모습이다. 영화제작 팀은 수십, 수백 명의 인력을 계속적으로 유지할 이유가 없다. 무릇 프로젝트를 하고 나면 배우는 게 있어야 한다. 리더십의 핵심능력은 인품이다. 리더십은 테크닉이 아니라 마음이며 배려이다. 전문가는 한 분야의 고수다. 전문가로 성장하기 위해서는 먼저 인생에 대한 좋은 철학이 있어야 한다. 그리고 자신의 기질과 재능, 굼을 바탕으로 자신만의 차별화된 브랜드를 만들어내야 한다. 전문가는 어제의 나와 경쟁할 수 있는 사람으로 평생학습을 지향한다. 전문가는 늘 새로움을 추구하는 초보자다. 일은 회사에서만 하는 게 아니다. 일을 더 잘하기 위해서는 여가, 운동, 취미, 학습, 자원봉사, 가족, 친구가 필요하다. 일을 인생의 관점에서 조명해 보고 일의 포트폴리오를 다채롭게 구성해야 한다. |
|
초년생 시절에는 책을 지금만큼 안읽진 않았지만 요즘들어 참으로 오랜만에 기억에 오래 남을 책을 읽은것 같습니다. 앞으로도 이런류의 도서를 많이 접할 수 있었으면 좋겠습니다. |