내가 책의 저자(이호종 연구소장)를 처음 만난 것은 11년전, 그 때는 한 회사의 대표이사였다.

대표이사였지만, 직접 C 언어와 PHP 언어로 코딩도 하고 개발자와 동등한 관계에서 협업을 했다.

그때 나는 신입사원이라 그런 상황에 대해 특별함을 느끼지 못했지만 직장 생활을 십수년해보니까,

사장님이 말단 사원과 협업을 하는 일이 특별하다는 것을 알게 되었다.

회사의 대표이사가 여러 일에 깊숙하게 개입하다보니, 논쟁도 많고 항상 시끌벅적했다.

이런 논쟁 과정에서 대표이사님이 삐지는 일이 종종 발생했다.

그래서 직원들이 붙여준 별명이 '툭삐'였다. '툭하면 삐진다'는 의미이다. ^^

(절대로, 나쁜 뜻으로 붙여준 별명이 아니다.)

아무튼 책의 저자(이호종 연구소장)은 특별한 성격과 독특한 이데올로기를 가진 분이었다.

회사를 창업하고 처음 1년 정도는 소프트웨어 엔지니어(SE)에 관심을 두지 않았다.

개발업무량이 많지 않았고, 복잡도는 낮았다. 5명 정도가 충분히 할 수 있을 정도였다.

게다가 개발자 수가 많지 않았기 때문에 개발조직 자체를 관리하기 위한 도구와 지식이 필요하지 않았다.

(솔직히 그때는 대충 만들어도, 주변 사람들이 감동과 감탄을 하며, 단순한 SW가 돈을 벌어다 주었다. 최고의 시기였다)

그러나 회사의 역사가 길어지면서, 회사가 만들어낸 코드의 양은 기하급수로 늘어나고

비슷하지만 조금씩 다른 코드가 시스템의 여기저기 기생하게 되었다. (이것은 아마도 소비자가 똑똑해져서 그런 것 같다)

대부분의 SW 개발회사들이 처한 상황이 그렇겠지만, 예전의 Requirement와 비슷한 Requirement이지만

프로그래밍 언어로 구현하려고 보면, Requirement의 미묘한 차이만큼 작은 코드 수정량이 있는 것이 아니다.

연구소장님도 머리를 쥐어뜯는 날이 많아졌고, 개발자도 매사 조심스러웠다.

우리는 CVS, WiKi 같은 관리툴을 도입해서 1차적인 관리를 하고 있었지만, 

개발자와 코드들이 유기적으로 관리되고 있다는 느낌은 안 들었다.

그렇게 많은 문제들을 해결하기 위해 고민하며, 10년이 흐른 것 같다.

이 책을 읽으면서, 저자(이호종 님)가 SE를 교과서적인 정리가 아닌, Field에서 직접 부딛히며

진정 무엇이 SW 개발자와 관리자를 괴롭히는지 핵심을 찾으려 한 것 같다.

우리 같은 경험이 많은 개발자에게 개발방법론 자체를 정리하는 것은 그다지 중요하지 않을 것이다.

내 또래의 개발자들은 SE의 개념적인 것은 학교에서 학습하고 나오기까지 했으니까.

(물론 학생이라면 개념 정리를 먼저하고 Field에 나오는 것이 좋다.)

이 책의 중간에도 종종 언급되었던 것처럼, 천재들만 모아서 개발을 하면 SE를 운운할 필요조차 없다.

그리고 프로젝트의 규모가 작다면 더욱 SE의 필요성을 느끼기 어렵다.

그러나 SW개발회사에서 관리자가 되어보면, "천재"를 찾기는 하늘의 별따기 만큼 어렵다는 것을 알게된다.

중소기업이라면, 이런 천재 개발자 찾기를 꿈꾸지 말아야 한다. 

S전자, G사, F사, A사 등 에게 수천명의 천재를 양보하면, 중소규모의 SW 개발사들은 평범한 사람들로

덩치큰 프로젝트를 꾸려 나가야 한다.

평범한 사람을 모아놓고 프로젝트를 진행하다보면, 이 책에 묘사된 것처럼 별일이 다 일어난다.

개성이 제각각이고, 사람마다 제 고집도 있고, 감정도 있는지라 프로젝트 관리자는 머리가 복잡하다.

신참 개발자들은 SE를 모른다. SE의 필요성을 입에 거품물고 알려주어도 반응은 시큰둥하다.

왜냐하면, 그들은 프로젝트 관리시 나타나는 문제를 경험하지 못 했고, 1~2번 경험한다고 하다라도

본인이 책임지어야 할 부분이 아니므로 관심이 없다. 

그들은 본인에게 주여진 코딩만 잘하면 된다고 생각한다. 실제로는 그것조차도 잘 못한다. ㅡㅡ

반대의 경우, 15~20년 SW를 개발하고 프로젝트를 관리해본 선배들은 SE의 필요성을 느끼고 있지만

무엇을 어떻게 접근하고 해결해야 하는지 모른다. 왜냐하면, 이런 것을 어느 누구도 가르쳐주지 않기 때문이다.

아마 20년 전에 대학교를 졸업한 개발자는 SE라는 과목조차 접할 기회가 없었을 것이다.

우선 신참 개발자들은 프로젝트 관리자의 머리속을 이해하고 더 나아가 감정상태까지 이해하기 위해

이 책을 한번 읽어보면 좋을 것 같다. 세상을 보는 눈이 한층 넓어질 것이다.

(이런 혜안을 가진 신참 개발자에게는 연봉 협상시 Special Grade를 주어야 한다. 

 왜냐하면 훌륭한 개발자에게 걸맞는 대우를 해주어야 S사, G사로 인재를 빼앗기지 않기 때문이다.

 평범한 개발자라도 노력해서 천재수준에 오르게 되면, S사, G사로 이동을 한다. 중소기업에게는 위기이다.)

15~20년 경력의 프로젝트 관리자는 더욱 이 책이 필요할 것 같다. 내가 모르는 답을 책이 주기 때문이다.

철저하게 학문적으로 SE를 접근하고 싶다면, 이호종 소장님이 쓴 책이 아닌 다른 SE 관련 서적을 볼 것을 추천하지만

나처럼 현업에서 개발을 하고 프로젝트를 관리하는 사람이라면 "거꾸로 배우는 소프트웨어 개발" 서적을 읽으면 좋겠다.

책속에서 나와 너무 비슷한 문제 상황을 묘사해주니, 감동스럽기까지 하다.

갑자기 생각나는 키워드가 있다.

"회의 !!"

이 책에서도 언급하고 있고, 저자와 직접 만나서 맥주 한잔을 할 때도 듣는 것이 있다.

"회의, 회의, 회의... 이거 안 하거나 줄이면 안 될까?"

프로젝트 관리자가 SW개발자의 집중도를 떨어뜨리기 때문에 회의에 대한 회의적인 생각이 지배적이다.

10분만 주의가 흐트려져도, 개발자는 다시 집중하기 위해 2~3시간을 허비해야 한단다.

나도 동감한다. 그래서 나도 업무시간에는 SW 개발을 안한다. (즉, 코딩을 안 한다)

남들 퇴근하고 적막한 시간이 되면 집중적으로 코딩한다.

낮 시간에 8시간 동안 할 것을 저녁에 2시간만에 끝낸다.

또는 일주일 내내 쌓아 놓았다가 주말에 반나절 정도 출근해서 하면 대부분 끝난다.

즉, 1주일짜리 개발분량은 주말에 5시간 정도만 하면 끝날 분량이다. (이것은 책 내용이 아니고, 내 생각이다. ^^)

개발자가 몰입해 있는 것 같으면, 어느 누구도 절대 간섭하면 안 된다.

표면적으로 1시간 짜리 회의(Meeting)라도 실제로 개발자는 3~4시간을 날려버리는 것이다.

반대로 개발자는 가능하면 인터넷 서핑/전화질을 하지 않는 것이 좋다.

나의 경우, 코딩/문서화 작업 중이라면 전화를 받지 않는다. 

(우리 가족들의 전화도 절대 안 받는다. 반대로 내가 10~20분에 일을 마무리하고 전화를 한다.)

아무튼 학교에서 SE를 배울 때는 다루지 않았거나, 또는 별거 아니었던 것을 이 책은 대단한 것으로 여기고 있다.

근데, 내가 십수년을 일해보니까 정말 그런 사소한 것들이 대단하다는 것을 뼈속깊이 느낀다.

여담이지만, 책을 읽다보면 왠지 모르게... 육군 중대장 또는 미식축구 감독의 어투를 느끼게 된다.

저자(이호종 님)는 오프라인에서 만나도 전략, 전술, 스크럼 등 군대에서 쓰는 개념을 종종 언급한다.

책에도 그런 부분이 간혹있다. 그래서 더 흥미롭고 재미있다. (딱딱한 개념서가 아니라는 것을 강조하고 싶다 ^^)

워낙 다독을 좋아하는 저자라서, 다른 기술서들과 다르게 문장이 부드럽고 흥미를 이끈다.

교과서라 생각하지 말고, 인생 선배가 나랑 치킨을 먹으며 들려주는 조언이라고 생각하면서 읽어도 될 것 같다.

한 때 XP가 등장했을 때 열광했던 기억이 난다. 정말 내가 꿈꾸고 바라는 방식으로 일할 수 있겠다는 생각 때문에 XP 관련 책을 읽고 관련 내용을 공부했었다. 하지만 내가 XP 초창기에 관심을 가졌던 것은 XP에서 주장하는 다양한 개발 프랙티스에 집중되어 있었다. 많은 개발자가 XP에 관심을 가진다. 팀장, PM과 같은 관리자가 XP에 관심을 가져야할 듯 한데 애자일에 관심을 가지는 사람들을 살펴보면 개발자인 경우가 대부분이다. 왜 개발자들이 애자일에 더 많은 관심을 가질까라는 생각을 해봤는데 어쪄면 애자일 진영에서 주장하는 개발 프랙티스에서 더 많은 관심을 가지고 있기 때문이지 않을까라는 생각을 해본다.

애자일에 관심을 가지고 한 참의 시간이 지난 후에야 알았다. 애자일을 성공하려면 애자일에서 주장하는 프랙티스를 도입하는 것이 우선이 아니라 그 속에서 일하는 사람들의 생각이 먼저 바뀌어야 한다는 것을.. 물론 사람들의 생각을 모두 바꾼 후에 시작할 수도 없을 뿐만 아니라, 사람들의 생각이 쉽게 바뀌지도 않는다. 하지만 기술적으로 먼저 접근하는 것이 아니라 사람에 대한 이해가 선행되고, 사람들 간의 신뢰가 일정 수준으로 쌓인 후에 변화를 만들고 기술적인 접근을 시도할 때 성공할 수 있다는 것을 경험이 쌓이면서 조금씩 느껴가고 있다.

이 책은 그런 측면에서 기술적인 프랙티스보다는 사람에게 초점을 맞추고 있다. 기술적인 세세한 내용보다는 왜 이 같은 도구를 사용하고, 기술을 사용해야 하는지에 대하여 조목 조목 이야기하고 있다. 기술적인 적용을 하기에 앞서 사람들을 설득하는데 대부분의 공간을 할애하고 있다. 이미 온라인 상이나 다양한 책을 통해서 접했던 이야기일 수 있다. 하지만 하나의 주제를 다양한 시각으로 바라보는 측면이 있기 때문에 충분한 가치가 있다고 생각한다. 이 책은 프로그래머보다는 팀장, PM, 사장 위치에 있는 사람들이 봤으면 좋겠다. 지금까지 무엇인가 새로운 변화를 만들고, 재미있는 개발 환경을 만들고 싶은 관리자라면 이 책을 통해 아이디어를 얻을 수 있을 것이다. 이미 생각은 하고 있지만 실천이 잘 되지 않는다면 이 책을 통해서 마음을 다지고 다시 한번 실천할 수 있는 계기가 되면 좋겠다.

이 책에서도 이야기하고 있지만 이 책이 이야기하고 있는 내용은 우리 모두가 이미 알고 있을 수도 있다. 하지만 아는 것과 실천하는 것은 다르다. 아는 것에만 머무르고 실천하지 않는다면 모르는 것만 못할 것이다. 정말 알고 있다면 실천을 통해 결과를 만들어 내는 것이 진정 알고 있는 것이라 자부할 수 있을 것이다. 변화를 만들어 갈 때 아이디어가 필요하거나 도움이 필요하다면 이 책이나, 이 책에서 제시하는 참고 자료를 통해 한 걸음씩 걸어갈 수 있기를 기대한다.

"기술과 인문학의 교차점에 있다."

이것은 애플의 잡스옹께서 하신 말씀이고 이 말씀 이후로 많은 사람들이 듣도 보도 못한 용어가 무었인지 알기도 전에 잡스옹이 던진 마력에 빠져서 이 말을 자유로이 구사하고 다니고 있다

"철학이 필요한 시간" (강신주, 사계절)을 보면 인문학은 솔직함에서 기반한다고 한다 시인의 마음처럼 솔직함, 임금님이 벌거 벗었다고 외칠수 있는 아이의 솔직함 그런 마음으로 사물과 현상을 바라 볼 수 있어야 하고 그것이 인문학의 시작이라 하고 있다

  이 책은 "솔직한 시선으로  소프트웨어의 개발에 대한 내용을 본다면 어떻게 보일까?"  라는 관점을 가지고 시작한다  그래서 책 제목에서 말하는 것 처럼 거꾸로 본다는 개념은 결국 솔직한 시선으로 있는 그대로의 개발에 대한 내용을 보여준다는 의미이다.  한편으로는 솔직하다는 의미는 작가의 (아주) 주관적인 생각에서 정리했다는 의미이다. 상당히 주관적으로 정리했기 떄문에 반론하는 사람들도 있겠지만, 전체적으로는  작가가 생각하는 잡식성 성향 그대로의 개발에 대한 생각을 정리한 책이다

책은 7개의 테마로 나누어져 구성되어 있지만 다시 분류를 내 마음대로 한다면
 
-  개발 전반에 걸친 잡다한 생각
-  개발 방식
-  개발 도구
-  TDD

로 나눌 수 있겠다

   우선 개발 전반에 잡다한 생각은 내 생각이고 실제 읽어 보면 저자는 개발이란 주제에 대해서 정말 많은 생각과 고민을 하면서 생각을 발전 시켜 왔다는 것을 알 수 있다. 학생때 프로그램으로 시작해서 SoC/ASIC 개발로 다시 인터넷으로 옮겨가며 만들어낸 저자의 개발에 대한 생각은 즐겁고 행복한 개발자를 지향한다고 볼 수 있다. 
이를 위한 3종 세트 즉 소스 코드 관리, 개발 프레임 워크, 단위 테스트를 하면 개발이 즐겁다고 이야기한다.  만약 이렇게 해도 즐겁지 않다면 그것은 개발외의 요소 즉 외부 요소에 의해서 압박받고 통제받는 개발자의 삶을 살고 있다고 볼 수 있다.  

  두번째 테마는, 개발 방식이라고 간단하게 이름을 붙였지만 이 내부는 개발 조직과 방법론을 함께 엮어서 설명하고 있다. 

  얼마전부터 많이 사용하는 스크럼의 본질도 잘 집어서 설명해주고 있다. 내가 생각하는 스크럼의 본질은 윗 사람과 아래 사람 모두에게 마음의 안식을 줄 수 있는 방식이다. 윗사람들은  (싸장님 포함) 언제쯤 제품이 나올지 어느정도 기대감을 가지고 지낼 수 있다는 장점이 있다.  아래 분들 즉 개발자들은 정해진 스프린트 기간에는 윗분들의 어택이 존재하지 않을 것이라는 믿음으로 평안을 얻을 수 있다는 점이다.  저자는 책에서 후자 즉 개발자의 안식을 이야기 하고 있다.  

  개발 방식에서 빠질 수 없는 또하나의 주제가 협업이다. 
 
  협업을 성공 시키는 가장 확실한 방법은 협업을 최소화 하는 것이라는 패러독스가 존재 할 만큼 쉽지 않은 문제이다.  책에서는 조직내에서 협업의 전제 조건으로 존중과 신뢰 도움을 이야기 한다.  이를 하나로 이야기한다면 기업 문화라고 이야기할 수 있겠다. 기업 문화는 유리 같아서 강력한 칼날이 되지만 한편으로는 깨지기도 쉬운 물건이다. 이것을 어떻게 유지할 수 있고 발전 시킬 수 있는 것인지가 항상 고민되는 문제이다.  
협업의 적은 많다 못해 화려하기 까지 하다.  하지만 그것을 모두 모으면 사람의 마음이다 정확하게는 과한 욕심과 욕망이라는 것으로 귀착된다. 그것을 다루는 것 역시 사람이 해야 할 일이다.  

  아쉬운 부분은 저자도 아직 명확한 해결책 혹은 실버 블렛을 찾지 못한것 같다.  가장 그런 부분에 근접한 사람이 저자라고 생각하고 있기 때문에 나는 못찾았지만, 저자는 (언젠가는) 찾을 것이란 기대가 있다.  책에서는 한센 교수가 제시하는 체계적인 협업이라는 협업에 대한 실천적인 가이드를 제시하여 설명하고 있다. 

개발 도구에서는 
   코드 형상 관리 시스템과 이슈 트레킹 시스템을 이야기한다
   두 시스템 모두 입이 닯도록 이야기 하지만 잘 정착이 안되는 부분도 많다
   코드 형상관리는 좀 쉬운데 이슈 트래킹은 정착이 조금 어렵다.  
   -  이 부분은 회사마다 처해진 상황이 다르지만 
      우리는, 하드웨어 특히 개발 기간이 긴 ASIC이라는, 개발이라는 업종의 특성도 존재한다. 
      아직도 제대로 풀지 못한 숙제이다.
   - 이슈를 등록시키고 해결시키는 것이 ASIC 개발 업체라는 속성상 길어지게 되고 그렇게 되면, 
      계속 이슈로 남게되는데 은근히 개발자들을 압박하게되는것 같다. 
      (일종의 심리적 매카니즘이 나쁜 쪽으로 작용하는 예라고 볼 수 있다.) 

TDD
   처음에 TDD에 대한 내용을 볼 때에, 오죽 제대로 검사도 안하고 출하 했으면 이런 개발 방식이 나올까 생각하였만 
배우고 난뒤에는 개발과 동시에 안정정을. 확보할 수 있는 방법이라 생각되었다. 관련하여 책에서도 테스팅이 유일한 해법이라고 강조하고 있다.   저자는 TDD의 중요성을 강조하기 위해서 아래와 같은 예언을 하였다

  앞으로 10년이내에 단위 테스트와 TDD를 적용하지 않는 개발 회사들은 모두 사라질 것이다
  그리고, 단위 태스트와 TDD를 실행하지 못하는 개발자들 역시 그 회사들과 사라질 것이다   

강력한 개발자가 되길 바란다는 문구와 함께 선물 받은 이 책은 개발자만을 향한 책은 아니었다. 기획자, 개발자, 개발관리자까지...IT업계에 종사하고 있는 사람들에게 조곤 조곤 얘기하는 책이었다.

저자의 문체는 군더더기가 별로 없이 간결한 편이어서 술술 따라가기가 참 좋다.
방대한 자료를 바탕으로 하셨는지 중간 중간 주석의 링크를 따라가서 그것들을 모두 참고하려면 엄청난 양의 후폭풍을 몰고 오는데, 초독때는 참고 링크들은 그냥 그런게 있구나~ 하고 넘어가면서 술술 읽는것을 추천한다.

내가 했던 고민들, 생각들과 너무 비슷해서 놀라기도 하고...
나만 겪는것 같았던 상황들을 이런 사람들도 겪는구나...싶어서 무언가 기분좋은 유대감이 살짝 생기기도 한다.
이 사람이랑 함께 일하면 좋겠다...하는 희망도 살짝 생겼다가, 조금 일하기 빡빡할라나? 싶은 고민도 살짝 고개를 든다.
(나를 너무 잘 아는 적은 조금 꺼려지는 법이다. ㅋㅋㅋㅋ)

2003,4년 무렵 개발을 시작한이 이제 2년차가 되었을때 개발 서비스마인드에 대한 고민을 한참 했었다. 그런 고민은 우연한 기회와 맞물려 완전한 서비스 직종에서 일하는 경험을 쌓겠다는 결정까지 낳게 했다. 그 경험을 가지고 다시 IT업계로 돌아왔을때 놀랐던것은 2년이라는 시간이 흘렀음에도 그런 생각을 가진 사람이 매우 적다는 사실이었다. 여전히 사용자 편의 보다는 개발자 편의 또는 사업주 편의의 개발들이 진행되고 있었다. 이런 저런 개발환경은 분명 이전보다 나아지고 발전해왔는데도 어째서 초보적인 개발 마인드에서 벗어나지 못한걸까 매우 의아했던 기억이 난다.
이 책은 그런 나의 의문들을 일 부분 해소해 주었다.
'아...이런 이유였군...'
그리고 그런 이유들을 제거해나가기 위한 노력에 대한 이야기를 시작하고 있었다.

사실 이 책을 보고 나면...
공부해야 겠구나, 아직도 배울것이 너무도 많구나, 나라는 사람은 아직도 멀었구나...하는 자괴감도 살짝 든다.
거짓말을 쪼꼼 보태서 꽤 많은 개발자들이 그럴거니까 너무 상심하지 말라고 해주고 싶다. 그리고, 이런 자극을 주는 책이 있다는것이 얼마나 다행이냐고 해주고 싶다.
아마도 저자가 생각하는 환경이 자리를 잡기에는 꽤 많은 시간이 흘러야 겠지만, 그 필요성을 느끼고 바꾸기 시작하는 사람들이 하나, 둘 모여서 IT업계의 고질적인 문제점을이 조금이나마 개선되 나갈것이라고 믿어본다.

IT업계에서 계속 일하고 싶다면... 꼭 한번 읽어보라고 추천한다

http://aquamir.userstorybook.net/

책을 읽자면, 책을 처음 들었을 때의 느낌과 마지막 장을 다 읽고 난 후의 느낌이 다른 책이 간혹 있다. 괜찮다고 생각했던 책이 후반부로 가면서 공감할 수 없어 실망감을 느끼게 하는 경우도 많았다.  이 책은 반대의 경우다. 처음 도입부에서는 거부감이 느껴졌으나 읽어 가면서 공감 가는 부분들이 많아 형광팬으로 줄을 쳐 가면서 읽었다.

처음 내용이 거슬렸던 부분은 폭포수 모델에 대한 부분이였다. 폭포수 모델- 소프트웨어 공학 개발 방법론-을 옹호 또는 변호하는 부분이였다. 저자가 인용한 책은 개인적으로 별로 좋았던 기억이 없었던 책이라 그랬던 것 같다. 제대로 실행해 본 적도 없고 시도도 해 본적이 없는 그 모델... 과연 우리 나라만 그런 것일까? 폭포수 모델은 아주 이상적인 유토피아이기 때문에 인간이 존재하는 한 완벽하게 그것을 실행한 프로젝트는 나오지 않을 것이다. 계획적인 프로젝트 실행은 필요하다. 하지만, 틀에 정해놓은 개발 방법론은 아닌 듯 하다.

이렇듯 거부감이 차 오르는 것을 참으면 계속 읽어 가고 있자니, 하나 둘씩 마음에 와 닫는 이야기들이 나온다. 프로젝트에서 지켜져야 할 최소한의 규약과 규칙들의 가이드라인이 제공된다. 대규모 개발이 아닌 경우, 대부분 개발자들은 자신만의 스타일을 고집하려고 한다. 평자 또한 그러한 편인데, 같은 개발 업무에 있는 다른 개발자들과 규칙을 합의하고 맞추는 데도 상당한 시간과 설득이 필요했다.

그런 다음, 애자일 방법론 중 하나인 스크럼과 테스트 주도 개발 방법을 다루는 내용도 나온다. 이 내용들은 관련 서적을 읽어본 독자라면, 쉽게 알 수 있는 내용이다. 하지만, 개발자들은 참으로 책을 읽지 않는다. 이 정도의 축약된 내용들은 책 읽기  싫어하는 개발자들도 읽을 수 있을 정도의 내용인 듯 하다.

＜슬랙＞에서 톰 드마르코가 깨달았듯이, 이 책은 CEO나 프로젝트 관리자 보다는 말단 개발자들이 알아야 할 지식과 깨달아야 할 금언들의 내용이다. 밑에서 부터 바뀌면, 언젠가는 위에 부분도 바뀔 것이다. 평자는 이 책을 개발자들에게 권하고 싶다. 다른 사람들에게도 꼭 읽어 보라고 선물해 주고 싶지만... 가격이 만만치 않은 것이 조금 흠이다.

평상시 기술 서적 이외의 책을 잘 읽지 않는 분이나 책을 잘 읽지 않는 개발자들이 꼭 읽었으면 좋겠다.  교양이나 인문학은 꼭 몰라도 세상을 살아가는 데는 문제가 없다. 하지만 그것들을 알면, 세상을 보는 눈이 바뀌고 많은 생각과 다양한 시각을 가질 수 있다.

 다 아는 내용이다 또는 그냥 지하철에서 후다닥 읽을 수 있는 내용이다 식의 그런 것 말고 지식으로 받아들이고 가슴으로 느낄 수 있었으면 하는 바램이다.

요즘들어 폭포수개발 방법론, 애자일 방법론, TDD 등과 같은 개발 방법론에 대한 책들이
많이 출판되고 있는거 같다. 이와 더들어 좋은 소프트웨어를 개발하기 위해서 개발자들이
가져야 하는 습관 등에 대한 책도 함께 나온다.

내가 생각할때 좋은 소프트웨어는 똑똑한 사람이 만들어내는 것이 아니다. 얼마나 체계적인
소프트웨어 프레임워크를 가지고 작업하느냐 라는 것과 그것을 얼마나 효율적으로 사용하고
지키느냐가 좋은 소프트웨어랑 그렇지 못한 것과의 구분이 되는거 같다.

이 책에서는 똑똑한 소프트웨어를 만들기 위해서 필요한 요소들을 하나씩 집어주고 있다.
현재 우리가 가지고 있는 개발 방법 및 개발자의 현실로 부터 시작해서 개발 방법론, 조직론,
개발표준, 소스관리, 프레임워크, TDD  에 대해서 빠짐없이 이야기 하고 있다.

책을 접하면서 느낀점은 이 책은 소프트웨어 개발을 위한 실용서적이 아니라 가이드 서적이라고
보면 딱 맞을꺼 같아.. 우리가 다 알고 있지만 시간이 없다는 이유로 혹은 어떤 환경이 갖춰지지
않았다는 이유로 지켜지지 못했던 내용들을 정리해 주었다. 그래서 이 책은 개발자 및 관리자를
포함해서 프로젝트를 시작하는 사람들에게 1-2 일 시간을 주어 읽으라고 권하고 싶은책이다.

새로운 개발을 시작하기 전에 이러한 내용을 상기하고 개발 프로세스를 만들어 나간다면,
기존 보다는 좋은 소프트웨어를 만들어낼수 있을것이라 생각한다.

(이 서평은 출판사로부터 무료로 제공 받아서 작성한 서평입니다.) 

이 책을 읽고 나서 바로 팀원들에게 추천해줬다.
개발자 뿐만 아니라 기획자, PM, PL에게 까지 꼭 읽어보라고 추천했다.

지금까지 개발해오면서 개발방법론에 대해서 그렇게 생각해보지는 않았고,
그냥 PM의 스케줄에 맞춰 개발을 해왔다.
그러다가 프로젝트를 진행하던 중에 이 책을 접하게 되었다.
개발 방법론이 왜 필요한지, 어떻게 해야 하는지 정말 쉽게 정리를 해놓은 책이다.
평범한 내가 조금더 나은 코드를 작성하기 위해서 어떻게 해야 하는지,
팀 협업을 위해 어떻게 해야 하는지...
읽으면서 정말 많은 도움이 되었다.

급박하게 책의 내용을 프로젝트에 적용해 진행하는 것은 무리겠지만,
내가 맡은 부분부터 시작해 나와 협업하는 사람들에게 차근차근 전파할 생각이다.
위태위태하게 진행되는 현 프로젝트에 많은 도움이 될것 같다. 

경력이 어느정도 있으신 분들께서는 다년간의 경험이 지금의 쏟아져 나오는 개발 프로세스나 기술의 홍수속에서 살아갈수 있는 방법으로 체득하여 살아가고 계실 것 같습니다.

하지만 경험이 부족한 저에게는 이러한 것들이 너무 버겁게 느껴집니다.

학교에서 배우는 다양한 개발 방법론... 인터넷 서점에서 컴퓨터 분야를 클릭했을때 매번 생소한
정보에 대한 책들... SVN? TDD? Agile? 의미도 잘 모른채 입에서 툭툭 나오는 이러한
용어들이며 어디서부터 어떻게 배워 나가야 할지 막막하다는 생각마져 듭니다.

그러다가 "프로그래머 그 다음 이야기"책에 이어서 좋은 기회로 이 책을 읽게 되었는데
먼저읽은 책이 개발자로써의 앞날을 헤쳐나갈수 있는 멘토가 된 책이었다면
이 책은 기술이나 프로세스와 같은 다양한 정보들을 어떻게 활용하며 어떠한 상황속에서
왜 사용해야 하는지 사용했을때의 장/단점에 대한 설명해주는 지침서같은 느낌이었다.
기술적인 딱딱한 내용보다는 선배개발자의 조언같은 느낌이다.

그래서 이책에 "소프트웨어 개발에 관한 인문학적 접근"이라고 써놓은 것 같다.

이책을 통해서 복잡하고 정리안되었던 내용들이
구색에 맞춰 틀에 맞아 떨어지며 정리된 것 같다.

책 중간에는 '개발조직론'에 대한 이야기도 있는데 아직 협업이나 어느 단체에 속하여 개발하지 않았기 때문에 조금이나마 현업에 대한 문제와 이해를 도울 수 있어서 좋았다.

로드북 출판사에서 '사람과 프로그래머'라는 주제로 나오는 책들이 나에게 큰 도움이 되는것 같아 상당히 만족스럽다 ^^