거꾸로 배우는 소프트웨어 개발

거꾸로 배우는 소프트웨어 개발

이 호종 저
로드 북 출판사.
 

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

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


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

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

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

로 나눌 수 있겠다

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

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

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

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

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

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

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

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


마지막으로, 

  책은 저자가 블로그에 올렸던 글들을 모아서 삽화와 함께 책으로 다시 엮었다.  
  저자는 정말 많은 책을 계속 읽어가시는 분이라 그만큼 사변적이고 개성적인 시각을 가지고 있다.
하드웨어 개발자로 시작해서 소프트웨어 개발 그리고 조직 관리등을 거치면서 쌓인 경험과 생각을 한권의 책으로 엮었다.

  끝으로 책 중간에 나오는 개발자의 그레이드를 나누는 살벌한 피라미드가 있는데 , 댓글로 아웃사이더라고 달은 분이 계시다. 글을 쓴 분도 댓글을 다신 "분" 도 엘레강스 하고 그레이트하다  주제넘은 내 생각에는 개발자의 그레이드를 나누는 것은 아무런 의미가 없다고 생각한다. 나누어서 인증서를 줄 방법도 없고, 스스로 프로라고 하면 옆에 있던 사람들이 아냐 라고 할 수 있는 정량적인 방법은 존재하지 않는다. 개발자의 그레이드를 정량적으로 인정할 수 있는 유일한 방법은 허리 사이즈에 비례한다고 이야기 할 수 있다.  즉, 허리가 34 인치 이상만 일단 일정 수준에 오른 개발자라고 볼 수 있다.   

  물론 농담이고. 개발자는 아키텍트를 지향해야 한다고 생각한다. 전체를 조망하는 위치에 올라가야 나머지가 보인다. 그레이드에 속박당하지 말고 독수리 처럼 높은 시선으로 전체를 조망하도록 스스로 연마하고 노력한다면,  나머진 쉬워진다고 생각한다.