Dec 21 2007

뉴욕의 프로그래머 - 이상적인 개발자 환경에 대한 이야기

분류: Dev.BookReview 태그: ,, , , Heart @ 2:01 오후

Trackback : http://dev.heartsavior.net/archives/62/trackback/
뉴욕의 프로그래머뉴욕의 프로그래머 - 10점
임백준 지음/한빛미디어
http://dev.heartsavior.net2007-12-21T05:01:050.3810

언젠가부터 출퇴근 시간이 PSP 게임 시간으로 변한 것을 느꼈다. ‘남들은 도서관에서 영어공부 죽어라 할텐데…’ 라는 압박도 들었고, 그냥 내 자신이 좀 시간을 아깝게 쓰는구나 싶기도 해서 책을 한번 읽어볼까 생각했다.

회사일로 지쳐 있었기 때문에 전공서적 보기엔 좀 그랬고, 그렇다고 아예 문학쪽으로 읽고 싶은 마음도 없었다. 그런 의미에서 이 책은 나에게 두 가지 토끼를 전부 충족시켜주는 아이템이라고 할 수 있었다.
프로그래머라면 한번쯤 이런 생각을 해 보기 마련이다.
‘프로그래머가 주연으로 활동하는 드라마나 영화, 소설은 왜 없는걸까?’
그런 의미에서 ‘프로그래머의 이야기를 다루는 소설’이라는 것은 프로그래머의 구매욕구를 자극하기에 충분했다.

제목 앞의 ‘뉴욕의’ 도 사실 큰 몫을 했다.
개발자들 사이에서 우스갯소리, 혹은 정색하면서 하는 이야기가 해외 취업이고 최근 들어 해외 취업도 나름대로 트렌드가 되어 가고 있기에 해외 프로그래머의 생활을 간접적으로나 접할 수 있게 해 주는 메리트는 생각보다 크다.

게다가 임백준씨의 여러 에세이들은 호평을 많이 얻었고, 이 책 또한 유명한 편이기도 해서 구매의 가치는 충분하다고 생각하고 망설임 없이 주문했다.

여기까지는 구매 동기였고…

출퇴근길이 길지 않아서 아주 집중을 하면서 보긴 어려웠다.
일단 Java 프로그래머가 아니면 알아들을 수 없는 부분도 좀 있고, 타겟을 확실히 ‘프로그래머’ 로 잡고 이야기를 진행하고 있다. 이 부분은 다행히도 나에겐 별 문제는 아니었고…

전체적으로 한번 쭉 본 소감은, 프로그래머가 보면 재미있게 볼 만한 것 같다.

Java 프로그래머라면 IDE나 예외명, 프레임워크 혹은 라이브러리 등이 나올 때 익숙한 이름을 보고 반가워하게 된다. 사실 이 책 아니면 어디서 소설 책에 IDE명, 프레임워크명이 나올까?

그리고 책에서 많은 분량을 담당하고 있는 디버깅 또한 흥미 유발에 충분했다.
프로그래머가 직업상에서 가지는 긴장감과 희열은 보통 버그를 디버깅할 때 자주 느낄 수 있는데,(물론 일을 돈 때문에 하는 경우라면 그냥 짜증으로 받아들일 수도 있겠지만…) 책 전반에서 여러 가지 버그를 만들어내고 이를 슬기롭게 처리해 나가는 모습을 긴박감있게 표현하고 있어서 보면서 공감대 혹은 느끼는 바가 많았다.
참고로 난 실력이 별로 없어서 공감보다는 느끼는 바가 참 많았다.
(그나마 다 까먹었지만…-_-;; 눈에 띌 때 다시 쭉 읽어봐야겠다.)

사실 가장 인상적으로 다가온 것은 책의 전체에 걸쳐 묘사되는 개발 환경이다.
이 책에서 그려지는 개발 환경은 상당히 체계적이고 CI 기반, TDD 기반으로 진행되는 이상적인 환경이다. ‘Ship It’ 이라는 책에서 제시하는 테스트 기반, 일일 회의, CI 구축, 이슈 관리 등을 모두 갖춘 모습이다.
국내에서 이렇게 체계적인 시스템에서 개발하는 사례가 있던가?
얼마 전에 참석한 JCO 컨퍼런스에서 보니까 포탈 사이트들은 어느 정도는 이런 시스템을 갖추고 있는 것으로 보이던데… 일반 중소기업, SI에서 이런 시스템을 기대하기는 쉽지 않아보인다.
(현재 재직중인 회사도 버전관리/이슈관리 도입을 막내인 내가 주도했으니 더 말할 것도 없다.)
적용하기 어려운 환경도 있겠지만, 사실 몰라서 안하는 경우도 있을 것이다.
이 책을 보고 CI, TDD, 이슈 관리, 버전 관리 등의 필요성을 느끼고, 이를 행동으로 옮긴다면 책값의 가치보다 훨씬 많은 것을 얻을 것으로 본다.

이런저런 이유로, 이 책 보고 ‘해외취업’에 대한 긍정적인 생각이 무럭무럭 싹트는 중이다. -_-;;
(저자분의 경험을 근거로 하고 있다고 하기에, 책에서 묘사된 시스템은 저자분의 개발 환경과 같거나 근접할 것이다. 게다가 주인공인 영우가 일하는 직업은 실제로 저자분이 일하고 있는 직업이다.)
국내 회사들도 당장의 이윤 창출도 중요하지만 멀리 보고 개발자들이 편하게 개발할 수 있는 환경을 갖추는 데에도 투자를 했으면 하는 개인적인 바램도 책 리뷰에 살짝 끼워넣어 본다.

아무튼 프로그래머라면 한번쯤 볼 만하다고 생각하는 책이다.
빌려서 보던, 사서 보던, 꼭 한번 슬쩍이라도 보길 추천한다.

ps. Ship It 책 보다 말았는데 이 책 읽으면서 생각났다 -_-;; 빨리 시간내서 독파해야지.


May 31 2007

기간 추정…

분류: Dev.Think 태그: ,, Heart @ 1:42 오전

Trackback : http://dev.heartsavior.net/archives/99/trackback/

상사에게 일을 받으면 상사분은 ‘언제까지 할 수 있어?’ 부터 물어본다.

단순 작업이라면 기간이 얼마나 걸릴 지 어렵지 않게 이야기 할 수 있을 것이다.
그만큼 많이 해 왔을 작업일 것이니…

그 추정의 기준이 되는 것은 보통은 ‘이전에 걸린 시간’이다.
환경 차이, 스케쥴 차이, 기타 차이 등을 고려하면서 이전에 걸린 시간을 기준으로 더하거나 빼는 것이다.

근데, 프로그래머로 살다 보면 기간 추정이 상당히 어려울 때가 많다.
예를 들어, 기존에 한 번도 못해본 것이라던지, 설계단계부터 새로 시작하는 경우라던지, 해야 할 일이 방대해서 기간 추정을 길게 해야 할 때이다.

어렵다고 안할 수도 없는 노릇이고… 너무 짧게 잡으면 스스로 무덤을 파는 것이고, 너무 길게 잡으면 긴장이 풀려서 일하기가 어려울 뿐더러, 상사에게 좋게는 핀잔, 나쁘게는 잔소리를 들어야 한다.

Software Estimation 이라는 책이 있긴 한데, 얼마나 도움이 될까는 미지수이고…
(보신 분께서는 소중한 리뷰 부탁드립니다.)

필요한 것은 시간일까?(경험을 더 쌓는다는 의미로…)
아니면 문제를 분석하고 쪼개고 단순화시켜 단순 작업처럼 추정 가능한 정도로 만들 수 있는 능력일까?
아님, 후자를 가능하게 하는 것이 전자일까?

어떻게 하면 더 효율적이고, 더 정확하게 추정할 수 있을까?