일을 시작할 때 매뉴얼 좀 그만봐라. 세상은 급변하고 상황은 시시각각으로 달라지는 데
모른다는 이유로 매뉴얼을 처음부터 읽고 있으면 대체 언제 만들것인가? 목차가 있는
이유는 찾아보라는 뜻이고 매뉴얼이 있다는 것은 항상 찾아볼 수 있는 준비가 되어
있다는 이야기다. 꼭 공부 못하는 애들이 사전을 처음부터 읽으면서 외운다니까. 뭐하는
짓이람? 찾아보라고 만들어 진것을 공부하다니 말이지 - C 군

요새는 다른 의미로 자주 쓰여서 부정적인 이미지가 강하긴 하지만 사실 '실용'이라는
단어는 아주 좋은 말이지요.형식에 구애받지 않고 바로 결과를 얻어내는 비용을 최소화
하는 뭐 그런식의 느낌이지요.그래서 현학적으로 유명한 그래서 읽기가 난해했던
'실용주의 프로그래머' 라는 책이 프로그래머들 사이에 인기를 끌었던 적이
있었습니다. 저두 그 책을 보며 많은 감명을 받았습니다. 그 때는 그리 열심히 읽었던
책인데 지금은 하나도 기억이 안나는 군요. 이 것이 '장삼봉' 이 말하던 '태극검'의
요지겠군요. 잊으면 잊을 수록 강해지는.. ^^;

실용주의 프로그래머

이 책이지요. 선물도 많이 했던 기억이 ^^

중요한 것은 그리 열심히 '실용주의 프로그래머' 라는 책을 읽고 나서도 정작
'실용적'으로 행동을 못하는 데 문제가 존재합니다. 잘 보면 주변 개발자들 중에서
프로젝트를 진행할 때 잘 모른다는 이유로 그리고 기초를 탄탄히 해야 한다는 이유로
매뉴얼 또는 기초부터 다루는 책을 열심히 처음부터 읽어갑니다. 이러한 것은 시간이 매우
많이 필요한 일이지요 또한 열심히 해야 합니다. 저도 이런 식으로 처음부터 기초를
다지려고 하다가 바쁜 시간에 쫓기거나 무엇인가 해야 하는 당위성 같은 것이 희미해져
중간에 그만 둔 적이 매우 많습니다. 이렇게 열심히 기초부터 닦기에 적합한 곳이
있습니다. 바로 '학교' 이지요.

실용적으로 개발을 하려 함은, '다급함과 독함'으로 자신을 밀어 넣는 일이라고
생각합니다. 이런 방식을 통해서만 배우는 속도가 상향되고 그 과정을 통해서 나오는
산출물이 좋아집니다. 그렇다면 '다급함과 독함'으로 자신을 밀어 넣는 일이 무엇인가?
라는 의문이 들 것입니다. 쉽게 말씀드리자면 '일단 시작하라는 것'입니다. 새로운 기술을
배울때나 공부를 해야 할 필요가 있을 때 일단 그 기술을 쓸 것을 가정하고 그 것을
이용하는 일을 시작하라는 것입니다. 사람에 따라 스타일의 차이는 있지만 예를 들어 C#
으로 뭔가 해야 할 일이 있을때 일단 프로젝트 부터 만들고 시작을 하는 것이 실용적에
가깝다는 것이지, 처음부터 C# 문법책 꺼내놓구 공부를 시작하는 것은 실용적에 가깝지
않다는 것입니다.

실례로 제 주변에서 있었던 일입니다. 10년이 넘게 알고 지내던 친구가 있는데 그 친구가
두벌식 자판에서 세벌식 자판으로 바꾸고 싶어서 거의 5년전부터 세벌식 자판을 슬쩍 슬쩍
보더군요.그런데 결정적으로 못 바꾸는 이유가 일할때나 놀때 두벌식 자판이 손에 익어서
절대 세벌식이 안 익혀진다는 것이 그친구가 항상 하는 말이였습니다. 그러다 최근에
무슨 바람이 불었는지 과감히 IME 를 세벌식으로 바꿔버리더군요 그리고 일할 때나 놀 때
떠듬거리고 세벌식만 쓰는 것을 노력하더니 드디어 5년의 숙원사업을 쟁취하더군요!! 딱
일주일 걸릴 일이였습니다.세벌식으로 치다가 막힐때마다 키배열 보면서 익혔다고 하더군요.

비슷하게 어떤 프로젝트를 생각하시고 그 기반의 배경을 알 필요가 있는 경우가
많습니다. 뭐부터 해야 할까? 공부할 것도 많고 봐야 할 것도 많은데. 이럴 경우에도
'그냥 만드십시오' 그리고 막히면 그때 가서 찾아보세요. 진행하다 막혔을 때 찾아보는
'다급함'이 시작도 안하고 공부하면서 상상의 나래만 펼치는 것보다 훨씬 '생산적'
입니다.

그냥 시작하세요. 그게 실용입니다. 겉돌지 마시고 한방에 핵심을 찌르고 시작하시는
것입니다. 그리 하는 것이 여러분의 시간을 절약하고 빠른 결과의 보람을
알려드립니다. 제가 겪어왔었던 처음부터 공부하다 좌절하는 경우 의 밀어닥치는 후회감과
좌절감은 자신을 좀 먹습니다. 여러분의 시간은 무엇보다 소중하고 비싼 시간입니다. (또한
윗 상사의 시간이기도 합니다 ㅎㅎㅎ) 이 바쁜 세상에서 시간을 절약하는 것 만큼 강점이
없기 때문이지요.

사용자 삽입 이미지
지은이 : 데이비드 토마스, 앤드류 헌트
옮긴이 : 김정민 이용원

실용주의 프로그래머를 위한 Starter Kit 그 세번째 입니다. 책 순서상으로는 2번째지만 제가 읽은 것이 세번째 입니다.  CVS 와 자동화 빌드(허걱! 이건 서평을 안써군요 ㅜ.ㅜ ) 그리고 이것이 세번째 입니다.

애자일 관련은 철학과 경영에 맞 물려 있다고 제가 친구들과 후배들에게 말하고는 합니다. 그만큼 실천이 중요하고 또 살짝 난해하기도 합니다. 쉽게 실천을 하면서 기반 지식을 쌓아두면 더 나아가는 데 도움이 된다고 저자들이 생각해서 적어도 이 세가지 (레파지토리, 단위 테스트, 자동화 빌드) 는 지켜나가면서 실용주의 프로그래머가 되도록 독려하기 위한 책입니다.

이는 그중에서 단위 테스팅에 관련된 책입니다. 자신이 만든 코드에 대한 테스트를 꼭 동반해서 만들어, 항상 테스트를 자동화 해서 프로젝트가 진행해 나가며 도움을 많이 받을 수 있게 하면 프로젝트 수행중에 오픈일에 일이 집중되는 시간을 수정 할 수 있게 만들어 주는 고마운 방법입니다.

사실 이 계열에 관한 내용들은 충분히 나와 있지만 실천하기 어려운 것도 사실입니다. 그리고 이 책 자체도 다른 두권의 책보다는 이해하기가 그리 쉽지 않았습니다.
하지만!!! 그럼에도 불구하고 이책에 나온 기술은 꼭 익혀둘만 합니다. - 저도 실제로 개발하는 데 있어서 큰 도움이 됐습니다.

실용주의 노선에 동참하시길 기대합니다. +ㅂ+
편하고도 정교하면서도 쉬운길입니다.

사용자 삽입 이미지

제목: 성공적인 소프트웨어 개발 프로젝트를 위한 실용가이드
원제: ship it

지은이: 자레드 리차드슨,윌 그월트니 주니어
옮긴이: 최재훈

최근 (우리 회사를 비롯해서) 실패하는 소프트웨어 프로젝트의 비율이 매우
높습니다. 일반적인 프로젝트의 경우에는 실패율이 70% 에 육박하고, 대규모
프로젝트의 경우에는 94% 경우에 이릅니다. 즉 6% 밖에 성공 못한다는
겁니다. 왜 프로젝트가 실패하느냐.. 여러가지 말은 많습니다. 훌륭한
기술리더가 전세계적으로 부족한게 아닐까 싶습니다만 결국은, 프로젝트를
성공시키겠다고 하는 의지들이 개발자들에게 없나 싶습니다. 그냥 저냥
시키는 대로 일을 하고 그냥 퇴근이나 하자, 일이 많으면 왜 이렇게 일이
많은지 조금도 생각 안하고 , 바로 고객을 탓합니다. 그리고 어느덧
야근하는 자신을 원망하면서 '내가 왜 이길로 들어와서 이 고생을 하고
있나'. 라고 운명을 탓합니다.

이런 악순환의 고리를 적어도 우리 회사만이라도 탈피하기 위해서 최신
알려진 기법에 대해서 공부하고 그런 좋은 시스템들을 회사에 도입할려고
이것 저것 시도를 해보는 중이였습니다. 그러다가 이 책을 읽게
됐습니다. 제가 하려던 일에 대한 근거를 제시한다는 기쁨에 정말 빠르고
깊게 푹 빠졌습니다. 운전하다 빨간불에 잠깐 책을 잡고 읽는 경우가 그리
흔한 경우는 아니지요 ^^;

최근 개념 있는 프로그래머라고 하면 극찬하는 '실용주의 프로그래머' 라는
책이 있습니다. 워낙 유명하지만 그 책을 읽은 사람들이 가지는 의문이
있습니다. 심지어는 그 글을 썼던 작가들 마저 가졌던 의문이라고
하는데,대체 이걸 현실에 어떻게 적용하란 말인가.. 그래서 작가들은
'시작하는 실용주의 프로그래머들을 위한 3가지 도구'에 관한 책을 썼구, 이
자레드와 윌은 이 책을 썼습니다. 책에서는 많은 방법을 제공하고 현실에
어떻게 적용해야 할 것인지를 잘 설명하고 있습니다. 어느때의 실천사항이
요구되는 책처럼 실천하기 어려운 방식을 요구하는게 아니라 쉽게
지금이라도 당장 실행해서 재미를 볼 수 있는 방법들을 제공하고 있습니다.

개발자부터 관리자까지 그리고 여건이 된다면 회사에서 추진하는 IT
프로젝트를 성공으로 이끌고 싶은 고객까지 꼭 한번은 읽어보시라 추천하는
책 입니다.

저는 평소 생각과 이 책에 나와 있는 내용을 바탕으로 5가지 원칙은 꼭
지켜나가는 회사를 만들고 싶습니다.

1. 소스 저장 관리 시스템 : SVN 으로 회사는 지정해서 모든 개발자들이
사용하게 한다.

2. Continous Integration System : 개발 시작하자 마자 프로젝트를
만들어서 CI 머신에 올려놓는다.

3. Test Driven Development : 테스트 주도 개발로 테스트를 첨예하게
프로젝트에 적용 시킨다.

4. Issue Tracker  또는  Bug Tracker : 고객과 개발자의 접점을 시스템에
한정 시켜서 서로에게 방해되는 요소를 줄이고 목록에 대한 관리가
필요하게 한다.

5. 목록 또는 일정 관리의 체계화 : 자신이 해야 할 일을 머릿속에만
담아두면 관리의 대상이 되지 않습니다. 관리의 주체가 자신이 되던
관리자가 되던지 말입니다. 실제로 제 친구가 PM 업무를 할때
그 친구가 고안한 일정 시스템을 도입해서 프로젝트를 성공으로 이끈
경험을 말해 주더군요. 자기 자신이 할 일도 체계적으로 관리가 되니 일을
더 효율적으로 하게 되며 다른 사람들하고 협업할때도 편하다고 합니다.


적어도 이 다섯가지의 원칙을 지켜나가며 앞으로 개발을 성공적으로 디자인
하는 업체가 된다면, 지금까지의 IT 업계의 안좋은 악습을 우리 회사가 고쳐나가는
시발점이 되지 않을까 합니다.

+ Recent posts