미국 대기업에서 인력 개발 팀장과 부사장 등을 역임했던 신시아 샤피로의 "회사가 당신에게 알려주지 않는 50가지 비밀" 이란 책을 읽다보면 회사  생활에 대해 많은 생각을 하게 된다. 결론은 회사 생활이란게 그렇치! 라는 생각과 더불어..

내용 중 반복적으로 나오는 주요 대상 중 하나가 직원과 인사부의 관계와 매니저와 직원간의 관계에서 발생하는 이야기가 많다. 그 중, 직원과 인사부의 관계에서 저자는 인사부는 직원을 위해 존재하는 것이 아니라 회사를 위해 존재하며 ,  그 활동 목표도 회사에 피해가 안가도록 지원을 관리하는 데 있다고 규정한다. 맞는 이야기 일까?

매니저와 직원간의 관계에 있어서는 나의 생각과 동일한 것 같다. 매니저의 기본 역할은 담당자들이 본인의 업무를 잘 수행할 수 있도록 지원해서 전체의 목표를 달성하도록 만드는 것을 말한다라고 말한다. 여기에 전적으로 동의한다. What을 중심으로 담당자에게 How를 찾아가면서 목표를 달성하도록 하고 여기에 발생하는 위기 관리는 하는 것..

반복해서 읽을 때 마다 많은 생각을 하게 해준다....
아마 일생에 있어 회사 생활을 그만두는 순간까지 힘들때마다 한번씩 읽어 보게 될 것 같다...느끼는 사람에게만 좋은 책!

로버트 L.글래스의 우리가 미처 알지 못한 S/W공학의 사실과 오해(Facts and fallacies of software engineering)에서 ...

구매한지 몇 달이 지난 책인데 이제서야 정독을 하고 있습니다. 개발에 있어 참고할 만한 재미난 통계 정보들이 있어 정리해 봅니다. 이 책은 소프트웨어 개발에 있어 관리, 개발 생명 주기, 품질 그리고 각 과정상에 발생하는 오류에 대해 정리하고 있습니다 .특히, 가장 개발자들이 싫어하는 유지보수에 대해 참고할 의견들이 많은 것 같습니다.

1. 관리에 대해

- Al Davis , "뛰어난 관리가 뛰어난 기술보다 중요하다."

- 소프트웨어 개발에 있어 가장 중요한 요소는 프로그래머의 자질이다"
무척 중요한 사실입니다. 사람중심의 개발에 반대되는 것이 아마 프로세스 중심의 개발이라고 할 수 있습니다. 어떤 것이 중요할까요? 물론 사람중심이 정답일 것입니다. 그러나 만약 사람 중심의 시각에서 해당 개발자가 충분한 자질을 갖지 않는다면 어떻데 될까요? 결국 이러한 문제 상황에 봉착했을 때 할 수 있는 방법은 프로세스를 만들고 이를 규정화하는 것 입니다. 물론 프로세스 기반의 개발의 경우 이를 이해시키고 강제시키는 것이 가장 어려운 일이지만요.. 자질있는 프로그래머... 참 요즘은 찾아 보기 어렵죠..!

- 최상의 프로그래머는 최악의 프로그래머보다 28배 더 뛰어나다.
- 지체된 프로젝트에 사람을 추가 투입하면 프로젝트가 더 지체된다."
역설적으로 우리나라 SI의 경우 이러한 사실에 정반대로 프로젝트를 관리하죠. 납기일에 맞추기 위해 막판 개발자 추가 투입.... ^-^

2. 개발 생명 주기에 대해

- 개발 생명 주기의 비율은?
요구분석 20% , 설계 20% , 코딩 20% , 오류 제거 40%

- 위기의 프로젝트의 가장 흔한 원인 2가지 중 하나는 불안정한 요구사항이다.

3. 유지보수에 대해

전체 소프트웨어 공정 비용 중 60%가 유지보수 비용이고 그중 60%가 기능 강화(enhancement)에 드는 비용이랍니다.  나머지는 17% 오류 수정 , 18%는 다른 플랫폼 지원들을 위해 드는 적응성 유지(adaptive maintenance) 비용 , 그리고 마지막 5%는 리팩토링 비용이라고 합니다.

이러한 유지보수를 위해서는 기존 시스템을 이해하는 게 정말 중요합니다.  실제 기존 시스템을 이해하는 게 유지보수에서 가장 어려운 작업입니다. 다른 사람이 설계하고 개발된 시스템을 코드를 통해 역으로 이해해야 하기 때문입니다. 평균적으로 기존 시스템을 이해하는 데 걸리는 시간은 전체 유지보수 시간중 대략 30% 정도라고 합니다. 아마 이 경우 , 기존 시스템을 잘 이해할 수 있도록 문서나 코드 들이 잘 정리돼어 있어야 겠죠.  이렇치 않을 경우 제 경험한 전체 유지보수 시간이 기하급수적으로 늘고 결국 다시 짜야 합니다 라는 담당자의 보고를 받게 됩니다 ^-^.  참고로 Fjelstedz 와 Hamlen가 정의한 유지보수의 생명주기는 다음과 같습니다.
 
-수정 사항의 정의와 이해(15%) - 시스템 문서 검토(5%)-로직 추적(25%)-수정사항 구현(20%)-테스트와 디버깅(30%)-문서 업데이트(5%)

4. 품질에 대해

소프트웨어 품질의 7개 속성 - 이식성, 신뢰성, 효율,사용편의성, 테스트 용이성, 이해 용이성, 수정 용이성

여기서 효율이란 S/W가 실행 시간과 사용 공간에 있어 얼마나 효율적인지를 의미하는 것이며 이해 용이성과 수정 용의성은 유지보수 담당자가 얼마나 쉽게 이해하고 수정을 할 수 있는지를 말하는 것입니다.  어차피 정답은 없지만 개발자로서 내가 개발하고 있는 소프트웨어가 얼마나 높은 품질을 갖고 있는 가는 의미있는 일 입니다. 물론, 생각해 보면 좌절할 수도 있겠지만요^-^.

오류의 발견 위치
- 오류의 반이 모듈의 15%에서 발견된다.
- 오류의 80%가 단지 모듈의 2% 이내에서 발견된다.
- 대락 80%의 결함이 모듈의 20%에서 나오고 모듈의 절반정도는 오류가 없다.

결국 소프트웨어는 여러 개발자가 모듈을 나눠서 개발하기 때문에 특정 모듈을 맡은 개발자에 의해서 대다수의 오류가 만들어진다고 생각할 수 있습니다. 결국 오류를 완벽하게 제거할 수 없기 때문에 모듈 개발시 난위도를 조절하여 개발 역할을 나누고 , 오류 수정은 심각한 것을 수정하는 전략이 필요하겠죠...

5, 후기
소프트웨어 분야에 있어 관리자가 아니라 개발자로 오래 남는 다는 것은 결국 자신이 그 일에 매우 능숙하게 된다는 것과 동시에 다른 부분의 사람들이 갖지 못하는 권력(?)을 갖는 것이기도 합니다. 이를 악용하는 사례들도 많이 있지만 대다수의 개발자들은 오래 동안 개발자로 남길 원할 것 입니다. 정말 코드로 승부하려는 개발자들 에게 다시 한번 격려를 보냅니다.  요즘은 그런 생각이 드네요 CTO라는 직업으로 뭘 해야 하나? ^-^. 관리자인가 개발자인가..직원인가 임원인가..

먼저 새해 복많이 받으세요!!

지난 번 블러그를 통해 씽크프리에서 새 식구를 찾는 다는 소식을 듣고 많은 분들이 연락을 주셨읍니다. 연락주신 분들과 몇 주간에 걸쳐 면접아니 면접을 진행했고 그 결과 몇 분은 씽크프리란 배에 함께 탑승하여 웹 오피스란 오션을 탐험하게 되었습니다(언제고 제게 연락주세요).

주로 2년에서 3년 정도의 경력을 갖거나 신입 개발자 경력을 갖는 분들이 대부분이었습니다. 열정과 가능성 그리고 개발자로서의 자질, 좀 더 나가면 수행한 프로젝트의 경험과 개발파워를 주로 보았습니다.

그런데 공통적으로 느낀 부분은 컴퓨터 관련 전공을 한 많은 개발자 분들이 수학이나 물리처럼 문제를 논리적으로 풀어내는 과목을 좋아하지 않고는 다는 점과 학부에서 공부한 과목 특히, 개발에 대한 부분이 문제의 의미를 찾고 이를 해결하는 방법을 배우는 Semantic 적 프로그래밍이  아니라 해당 언어의 문법을 위주로 배우는 Syntatic 적 교육을 받았다는 사실입니다.  오히려 전산 관련된 전공은 아니지만 문제를 논리적으로 풀어나가는 사고를 제대로 배운 분들이 더 개발에 대해 열정과 가능성이 보였다는 사실입니다.

안타까운 마음에 여러 분들에게 제가 컴퓨터 프로그램의 구조와 해석이라는 책을 소개하고 시간이 되는 데로 꼭 읽어보라고 권했습니다. 아울러 다른 분들에게도 이 책을 좀 소개하고자 합니다. 이 책은 말 그대로 캄퓨터 프로그램의 구조와 해석을 다루는 책으로서  MIT에서  모든 학생에게  가르치는 필수 교제 입니다. 사람의 생각을 컴퓨터 프로그램으로 표현해서 이를 컴퓨터를 통해 표현하는 방법을 가르치는 멋진 책입니다. 내부의 예제도 자바나 C++같은  일반 개발 언어가 아니라 Lisp의 한 형제격인 Scheme을 사용하여 생각하는 방법과 생각을 표현하는 방법, 이 표현을 컴퓨터 내부에서 어떻게 해석하고 실행하는 가에 대한 좋은 지침을 주는 책 입니다.

저도 이 책을 마이크로소프트의 김명호 박사님으로 부터 선물을 받고 연휴 기간에 한장 한장을 넘기면서 너무나도 재미있게 보았습니다 . 아직  전부 보지는 못했지만 짬짬히 머리 아플때 마다 보고 있습니다. 과거 저도 처음 컴퓨터 프로그램을 배울 때 이런 방법으로 학습하지는 못했지만 컴파일러나 다른 유사한 과목들을 학습하면서 이러한 접근 방법의 필요성을 이 느꼈습니다.

개발을 사랑하는 여러분 너무 새로운 것에만 관심갖지 말고 항상 기본을 튼튼히 하는 것도 멋진 투자입니다. 

아래 링크에 가시면 관련된 자료와 전문을 웹으로 이용할 수 있습니다. - http://mitpress.mit.edu/sicp/

마지막으로 다시한번 좋은 책 선물해 주신 마이크로소프트의 김명호 박사님께 감사드립니다. 꾸벅

2008년 힘네세요!

개인적으로 검색엔진과 더불어 가장  많이 사용하는 서비스는 위키입니다. 구글은 로봇을 통해 인터넷상의 문서를 수집하고 이를 색인한 후 가장 랭킹이 높은 정보를 사용자에게 제공하는 반면에 위키는 사용자들의 자발적인 참여로 정리된 용어 사전이기 때문에 정보의 질이 다릅니다. 검색을 통해 얻는 정보라는 것이 본질적으로 공개되어 있는 엄청난 양의 정보중에서 가장 가치있는 정보를 순위별로 정리하여 제공받는 것이기 때문입니다. 실제 첫페이지에 원하는 것이 나오지 못하면 좌절하게 됩니다. 실제 어떤 용어(Term)를 검색하면 대부분 첫페이지 결과에 위키가 포함되어 있습니다.

위키는 초보적인 수준의 Semantic Web입니다. 이해할 수 있는 위키 태그로 정보를 보다 구체적으로 명시할 수 있기 때문입니다. 그러나 그 의미가 상호 연동되지 하기 때문에 진정한 Semantic Web은 아닙니다. 이에 반해 블러그 정보의 교환을 위해 RSS로 정리된 정보는 Semantic Web입니다. RSS 명세를 통해 서로 그 의미를 이해할 수 있기 때문입니다. 이처럼 현재 보이지 않는 여러 곳에서 이미 기존의 Syntatic Web이 Semantic Web 으로 진화되어 가고 있습니다. FreeBase처럼 Semantic Wiki 기반의  검색엔진이 차세대 검색 서비스로 주목을 받고 있으며 구글 Base , 야후의 Answer 서비스 등 여러 방면에서 Semantic 기반의 서비스와 커뮤니티가 출현하고 있습니다.

초기 팀 버너스 리에 의해 제안된 Semantic Web의 스펙을 보면서 무척 복잡하고 정제되지 않은 상태라 이해도 떨어지고 무척 어려웠던 기억이 납니다. 특히, 상호운영성을 위한 온토로지에 대한 이해와 온토로지의 작성 및 활용에 대한 명확한 개념 정리가 어려웠습니다. 짬짬히 단편적으로 이해하던 Semantic Web 을 체계적으로 정리할 좋은 기회가 있었습니다.
"인터넷 진화의 열쇠 : 온톨로지"라는 책은 바로 이렇게 모호했던 Semantic Web을 체계적으로 이해하는 데 많은 도움을 줄 것 입니다. 이 책은 경영정보 분야입장에서 Semantic Web에 대해 연구를 하고 있는 서울대 노상규 교수와 박진수 교수께서 집필한 책으로서 엔지니어 입장에서 보다 넓은 시각에서 Semantic Web 을 바라보게 해주는 좋은 안내서라 소개해 드립니다. 저도 올해 가을에 구매해서 보고 연휴때 다시 한번 책을 보게 되었는데 두고두고 많은 도움이 되네요^-^.

간혹 좋은 책들을 선물하기도 하고 선물받기도 합니다. 이번 연말에는 귀한 분들에게 멋진 책들을 선물받았습니다. 그 중 하나가 초난감 기업의 조건이란 책입니다. 올 해 읽은 책중에서는 죠엘 스폴스키의 조엘 온 소프트웨어와 더불어 가장 재미나게 읽은 책중 하나로 기억될 것 같습니다. 특히, 이 두권 모두 얼굴을 모르지만 제 둘째 동생과 동명인 박재호씨가 번역한 책인데 아주 맛깔스럽게 번역해서 재미있었습니다. 약력을 보니 동문이네요.ㅎㅎ.

이 책에 대한 재미난 소개 중에 블로터 닷넷의  황치규님이 쓴 "IT업계 '초절정 뒷담화'의 매력: 초난감 기업의 조건 이란 블러그도 눈에 띠네요.

릭 채프먼이란 저자는 1978년부터 IT업계에서 일한 종사자로서 영업부터 개발에 이르기까지 다양한 경험을 했으며 , 이 과정에서 얻은 경험을 주요한 IT 업체들의 과감하게 벌인 초난감 실수를 중심으로 자세히 소개하고 있습니다.

개인적으로도 성공하는 사람은 두번의 실수를 반복하지 않는 다고 생각합니다. 이 책에서 사례로 소개한 초난감 기업들은 공통적으로 같은 실수를 두 번이상 반복한 것 같습니다. 또한 실수를 하더라도 그 실수를 극복하는 방법에서 차이가 있다는 것을 확인해 볼 수 있었습니다.

몇가지 책을 읽으면서 다르게 느꼈던 점에 바탕하여 좀 더 뒷담화를 곁들여 보면...

- 과거 TI사가  ㅆI99/4A 라는 모델로 가정용 컴퓨터 시장에서 5억불에 다르는 큰 손해를 입고 철수를 했는데 , 당시  TI 는 20년 장기 근속으로 은퇴 연금을 받을 자격이 되기 직전에 직원을 해고 하는 파렴치한 정책까지 행한 탓에 직업 교육 전문학교라고 불렸다고 합니다. 예나 지금이나 직원을 부품으로 아는 회사치고 성공하는 회사는 없다 라는 것을 확인할 수 있을 것 같네요.
- 100페이지 밑에서 4번째 줄에 오타가 있습니다. : "너어무우도 처언처언히" , 갑자기 그 부분에서 너무도 천천히 읽게 되었습니다^-^. 에어컨 출판사 책이 무지 꼼꼼한 책인데 이런 오타가..ㅎㅎ 농담입니다.
- 언젠가 빌게이츠가 새 제품발표회에서 자리를 박차고 나가면서 발표자에게 차가운 눈길을 준후 이렇게 물었다고 합니다. "이 빌어먹을 자식, 우리 회사에는 도대체 어떻게 들어왔어?"  MS가 채용 과정이 까다롭고 길다고 하는 게 그 때 이후에 바뀐게 아닐까요!

개인적으로 초난감 회사의 끝에는 역시 초난감 CEO 가 있는 것 같습니다. 워드스타의 마이크로프로,  IBM , 에시톤 데이트, 시벨 시스템즈.... 반대로 성공하는 회사에는  유능한  CEO와 임원진 그리고 멋진 문화가 있는  것을 다시한번 확인할 수 있는  또 한번의 좋은 계기였던 것 같습니다.