"... 그럼에도 불구하고, 사람들은 직무 재조정을 전혀 거치지 않은 상태에서 상급 코딩 기술자를 관리자로 밀어붙이는 작업이 가능하다고 받아들입니다."-조엘 온 소프트웨어

현재 근무하는 회사에서 이러한 현실을 바꿀 수 없는 경우, 관리자로 밀어붙여진 개발자가 선택할 수 있는 길은 무엇일까?

임베디드 시스템 펌웨어 분석, Ed Sutter, 에이콘 ***

http://www.acornpub.co.kr/book/firmware

임베디드 시스템의 펌웨어 개발자가 알아야 하는 내용을 깔끔하게 설명한 책. (너무 깔끔해서 가끔은 좀 불친절해 보임) 이책은 간단한 기능의 디버그 모니터의 소스 코드 전부를 CD로 제공하고 이 디버그 모니터의 구현을 설명하였다.

최초에 H/W팀으로 부터 받은 H/W를 어떻게 동작시키는지부터 시작하여 target보드에 기본적인 개발 환경을 어떻게 만드는지를 설명한다.

디버그 모니터 소스 코드를 통째로 지원하므로 자신의 h/w에 책에서 제공하는 디버그 모니터를 올려서 테스트 해 볼 수 도 있다. (단 당신의 target board가 책에서 지원하지 않는 CPU를 사용하여 구성되었다면 해당 CPU의 assembler를 사용하여 초기화 루틴을 직접 작성해야 한다.)

앞서 잠깐 언급했지만 이 책을 읽다보면 종종 내용이 너무 깔끔해 설명이 충분치 못하다고 느껴지는 부분이 많다. 사실 이런 부분을 모두 제대로 설명하려면 책 분량이 엄청나게 커질 것이기 때문에 저자를 비난하기는 힘들것 같다. 하지만 CD에 첨부된 PDF 문서들을 열심히 읽으면 대부분의 궁금증을 해결할 수 있을 것이다. 물론 이해하려면 약간의 내공이 필요한 문서들이지만 모두 읽고나면 뿌듯히 충만한 공력이 단전에서 느껴질 것이다.

게임 개발자를 위한 C++, 서진택, 민커뮤니케이션 ***

도대체 왜 이 책의 제목에 굳이 "게임 개발자를 위한" 이라는 말이 들어갔는지 이해하기 힘들다. 차라리 이 책은 C++에 처음 입문하여 아직 C++에 완전히 적응하지 못한 개발자들에게 저자가 자신이 맨땅에 헤딩하며 얻은 C++관련 지식을 친절하게 알려주는 그런 책이다.

이 책의 저자는 자신이 C++에 대해서 모든 것을 아는것처럼 이 책을 기술하지 않았다. 오히려 저자는 자신도 모르고 있던 C++의 기능/정의 등이 왜? 그렇게 되었는지 끊임없이 탐구하면서 자신이 찾아낸 결과를 독자들에게 전달하여 주고 있다.

만일 C++ 문법책 한두권을 읽고 C++ 문법을 안다고 생각하는 C++ 초보 프로그래머라면 (설령 C언어의 고수라고 할지라도...) 일반적인 C++ 설명서가 놓친 부분들을 이 책의 저자와 함께 고민해보기를 권하고 싶다.

아직도 나는 헷갈리는 C++문법이 나오면(계속 C만 사용하다 보니, 때론 C++ 문법이 가물가물해진다.) 베게같은 C++ 문법책 대신에 이 책을 먼저 찾는다. 나보다 먼저 고민하고 나름대로의 모범답안을 적어놓은 선배의 족보같은 느낌... (마치 족보처럼 편집이나 구성은 별로 뛰어나지 않다. 하지만 내용은 쪽집게라는거~~ )

C만 사용하다 갑자기 10년전 대학시절에 배우고 쓰지않던 C++로 프로젝트를 수행해야 한다면 강추. 자신이 C++ 고수라고 생각한다면 통과.

P.S. 사실 C++ 문법은 평균적인 IQ의 인간이 익히기에는 너무 복잡하다. 자신이 C++의 고수라고 생각한다면 Effective C++ 과 More Effective C++을 읽어보기 바란다. 내용이 이해가 잘되신다면 당신을 고수로 인정합니다. 나는 아직도 이 두 책의 많은 부분이 이해되질 않는다. ㅠㅠ

Inside Windows 2000, Solomon/Russinovich, Microsoft ****

수 많은 리눅스 커널 분석 책들이 있지만 의외로 Windows의 커널 동작에 대해서 설명한 서적은 찾기 힘들다. Windows가 소스 코드가 공개되지 않은 OS라는 점을 생각하면 별로 의외도 아니지만...

Windows 환경에서의 개발자 뿐만 아니라 다른 환경에서 개발을 해야 하는 개발자이더라도 OS의 동작 원리를 아는 것은 일반적으로 개발자의 내공을 높이는데 결정적인 계기를 만들어 준다. OS 마다 최종적으로 제공하는 기능은 비슷 비슷 하지만 이를 구현하기 위한 디자인은 서로 조금씩 다르기 마련이며, 이러한 디자인의 차이점을 공부하는 것은 그야말로 엄청난 내공을 쑥쑥 키우는 영양제가 될 듯하다.

기존에 OS나 전신이론에 대한 기초 지식이 없이 바로 읽기에는 약간 부담되는 내용이므로 내용이 절반 이상 이해되지 않는다면 다른 공부를 좀 더 하고 다시 도전하기 바란다.

내가 읽을 것은 Windows2000용이었으나 Windows XP나 Vista용이 나왔을지도 모르겠다. 하지만 기본 내용이 많이 바뀌었을 것 같지는 않다.

번역서도 있으나, 절.대. 추천하지 않는다. (최소한 내가 본 초판 번역서는 정말 엉망이었다.) 중급이상 개발자라고 생각한다면 강추.

What not to do list as a manager

항상 객관적으로 자기 자신을 평가하기는 어려운 일이다. 지금 개발자로써 내가 관리자에게 느끼는 점을 모아 적어 놓는다면, 나중에 반면교사의 교재로 사용할 수 있을 것이다.
이 게시물은 생각이 날때마다 update할 계획이며, 혹시 누군가 댓글에 좋은 내용을 추가하여 준다면 이 또한 게시자의 id와 함께 추가하도록 하겠다.

1. 책임을 개발자에게 떠넘기기
한두가지 문제에 대한 책임을 개발자에게 떠넘긴다고 프로젝트 실패의 책임이 개발자에게 넘어가는 것은 아니다. 이런 행동은 최악의 경우 개발자의 사보타지를 부추길지도 모른다. 당신의 프로젝트는 실패하고 당신은 신망을 잃고 앞으로 누구도 당신 밑에서 일하려 하지 않을 것이다.

2. 개발자에게 자신의 방법을 강요하기
개발자가 어려운 디버깅 문제에 봉착하였을 때 이에 대해 적절한 코멘트를 통하여 디버깅을 도와줄 수 있다면 정말 훌륭한 관리자가 아닐 수 없다.(물론 이것은 개발에 대한 경험이 있는 관리자의 경우에만 해당된다) 하지만 개발자가 아주 초짜라 별도의 코칭이 필요한 경우가 아니라면 디버깅을 위한 의견 제시나 방향만 제시하여 주는 것이 좋다. 사사건건 간섭하여 이거 해 봐라 저거 해 봐라 하는것은 별로 좋은 방법이 아닌것 같다. 당신은 (한국사람이라면 특히나 더 ) 개발자로써 화려하게 성공하여 관리자로 진급하였는지도 모른다. 이 경우 당신은 자신만의 화려한 개발 실력을 무기로 삼아 문제를 빨리 해결할 수 있는 수만가지 방법을 알고 있겠지만, 문제 해결을 위하여 이러한 무기를 사용하고자 한다면 자신의 손으로 직접 행하기 바란다. 이것은 당신의 손에서 사용된다면 문제 해결을 위한 훌륭한 무기이지만, 당신의 입에서 사용된다면 개발자의 마음을 찟는 무기로 돌변 할 것이다. 괜시리 개발자의 마음들 다치게 하여서는 문제 해결에 도움이 되지 못한다. 사람에게는 자신만의 무기가 있는 법이다. 다른 사람에게 자신의 무기를 강요할 필요는 없다. 특히나 이것 저것 시켜보고 안되면 은근슬쩍 발을 빼려 한다면 당신은 좋은 매니져가 아니다. 해당 문제를 자신의 책임하에 끝까지 해결할 마음의 자세가 되지 않았다면 개발자에게 자신의 방법을 강요하지 않는 것이 좋다.

악몽의 순간에 발생하는 일들

프로젝트가 막바지에 이르면 개발자와 관리자 모두 패닉상태가 되기 쉽다. 이미 code freeze일정이 지나 validation team에게 이미지가 전달되었지만, 잇달아 발생하는 개발자의 sanity test failure report는 별다른 위기조차 되지 않는다. 왜냐면 곧이어 validation team에서 "진짜" 문제들을 쏟아낼 것이기 때문이다. 이쯤되면 이미 validation team으로 부터 몇번의 양해를 구해서 이미지를 다시 build하였기 쉽상이지만 아직 절망에 이를 단계는 아니다.

- (사실 validation team이 그나마 "진짜"문제를 쏟아내주면 그것만으로도 고마운 일이다. 최근에 투입된 "초짜" tester가 등록하는 수많은 "가짜"문제들의 홍수에 질식해 본 적이 있다면 "진짜"문제들은 차라리 고맙기까지 하다)

만일 최종 이미지가 빌드 후 제품 양산을 위해서 공장에서 라인이 기다리고 있는 상황이면 관리자들은 똥 마려운 강아지처럼 안절 부절 하면서 눈을 희번득거린다. 이들은 곧잘 개발자들의 경제 관념을 운운 하며 새로운 이미지를 제때에 만들지 못할 경우 생산 라인당 몇명의 작업자가 몇시간 동안 작업한 것이 날아가며, 이때 발생하는 손실 및 고객신뢰 실추등을 읊어대기 시작할 것이다. (이 단계에 이르면 관리자는 이미 패닉 상태에 있다고 보면 정확하다.)

이쯤 되면 개발 경력이 짧거나 소심한 개발자들은 서서히 관리자들과 함께 미쳐가기 시작하며 이때 누군가 중심을 잡아주지 않을 경우 개발팀 전체의 패닉으로 프로젝트가 산으로 가기 시작한다. ( 정말 최악의 시나리오군..)

어느정도 경력이 있는 개발자들은 이럴 때 빛을 발한다. 그들은 평정심을 유지하며 설령 마지막 순간에 발생한 문제의 모든 증상이 자신을 지목한다고 하더라도 최대한 객관적으로 문제를 살펴 정확한 원인을 찾아낸다. 일단 문제의 원인이 밝혀지면 (설명 문제의 원인이 자신이 짠 코드라고 하더라도) 현 상황에서 최대한 빨리 문제를 수습 가능한 대안을 찾고 제시한다. (나는 이런걸 알고 있으면서 왜 이렇게 못할까? 왜 나는 늘 전전긍긍하며 내 문제가 아니기만을 기도할까? 신앙심도 전혀 없으면서... ㅋ)

사실 이시점에서 개발자들이 할 수 있는 일은 별로 많지 않다. 다만 문제가 자신의 문제가 아니라 밝혀졌을 때 가슴을 쓸어내리며 문제를 만든 다른 개발자를 욕하는 대신에(이건 정말 최악이다 이런 개발자라면 짐싸라), 함께 다른 대안을 찾을 수 있도록 도와줄수 있을 따름이다.

그럼 이 시점에서 관리자는? 관리자는 이미 이 시점에서 문제를 만든 개발자보다 더 큰 원죄를 가지고 있다. 이를 인식하고 반성한다면 앞으로 훌륭한 관리자가 될 자질이 있는 사람이라고 생각한다. 만일 당신이 관리자인데, 문제 발생의 이유를 개발자에게서 찾고 있는 당신을 발견한다면 제발 프로젝트를 위해서 관리자 자리를 포기하여 주기 바란다. 어짜피 최종 프로젝트가 성공하고 못하고에 대한 평가는 팀원 모두가 나누어서 짊어지게 된다. 당신 혼자 욕 먹지도 당신 혼자 칭찬 받을 수도 없다는걸 항상 기억하라.

또한 만일 당신이 누구 한명에게 죄를 뒤집어씌워 당장의 비난을 피한다면 다음에 누가 당신이 돌격 앞으로를 외칠때 앞서서 뛰쳐나가려 할지 생각해 보기 바란다. 어짜피 당신의 관리자로서의 생명은 절단났다고 봐도 될 것 이다.

구글? 그게 뭔데?

세계 소프트웨어 시장의 패권을 차지한 마이크로소프트사가 가장 두려워하는 회사는 구글이 아닐까? 이미 구글은 마이크로소프트로부터 자유를 획득하였는지도 모른다. 이들은 자신뿐만이 아니라 일반 대중까지 마이크로소프트로부터 독립시키기 위한 매우 치밀하고 주도면밀한 쿠테타를 준비하는것럼 보여진다.

사실 구글이 아직 알려지기 이전에는 리눅스 정도가 마이크로소프트가 두려워하는 대상이었을지도 모른다. 비록 리눅스가 시장에서 자신만의 장점으로 깊은 뿌리를 내리는데 성공하였다고 말할 수 있겠지만, 윈도우를 이겼다고 말할 수는 없다. (꼭 윈도우를 이기는 것 자체가 가치있는 일이라고 말하고자 하는 것은 아니다. 여기서 말하고 싶은 것은 대중을 독점의 피해로부터 구해냈는가 그렇지 못했는가이다.)

많은 사람들이 지적하였듯이, 대부분의 사람들은 업무상 사용하는 주요 s/w(개발자라면 편집기나 개발툴등)이외의 어플리케이션이 제공하 대부분의 기능을 사용하지 아니한다. 이러한 사람들이 불필요하게 비용을 지불하며 값비싼 어플리케이션을 구매하는 이유는 다른 사람들과 함께 일할때 발생하는 데이터 호환성 문제를 피하고 싶기 때문일 것이다.

이러한 데이터 호환성 문제는 마이크로소프트의 독점으로 인하여 발생하였고 마이크로소프트는 이를 지능적으로 이용하여 지난 20여년이 넘는 기간동안 엄청난 이익을 거두었다. 구글은 이러한 호환성 문제를 극복한 웹 어플리케이션을 사용하여 대중을 열광케 만들 준비를 진행하고 있는 듯 하다. (유료화 안하면 좋을 텐데...)


웹 어플리케이션이 일반 어플리케이션보다 뛰어난 기능을 제공하지는 못하지만 설치가 필요없고 데이터의 이동의 측면에서 더 유리하기 때문에 (USB 메모리를 가지고 다닐 필요도 없다!) 데이터 호환 문제만 해결된다면 일반 사용자를 흡수하는데 아무런 문제가 없다. 구글 이전에 오픈 오피스등이 완벽한? 데이터 호환성을 주장하며 기존 사용자 층을 흡수하려 하였지만, 오픈 오피스는 아무리 뛰어나도 마이크로소프트 오피스를 뛰어넘을 수 없는 흉내작일 수 밖에 없었다. 하지만 구글이 제공하는 서비스는 태생부터 이런 문제를 극복할 수 있는 핏줄을 타고 난것이라 생각한다.

넷스케이프가 인터넷 익스플로어에 패배당한 후 몇년간 마이크로소프트는 인터넷 익스플로어를 거의 개선시키지 않았다. 그러다 최근 FireFox가 인기를 얻자 부랴부랴 인터넷 익스플로어 7을 발표하였는데 이것은 경쟁이 있어야 발전이 가능하다는 진리를 일깨워 준다.

구글이 마이크로소프트를 긴장시킬수록 우리는 즐거워 질 것이다. 마이크로소프트도 필사적으로 뭔가를 준비할테니까...

(마이크로소프트는 OS쪽에서 늘 OS X를 모방해 왔다. OS X가 마이크로소프트를 긴장시키지는 못했지만, 윈도우가 늘 OS X의 따라장이 였다는것을 부인할수는 없을 것 이다. 하지만 제발.. 기능뿐아니라 디자인도 좀 따라하길 바란다. 최근에 나온 Vista의 디자인은 정말 최악이다.)

문을 열며

최근에 읽은 "조엘 온 소프트웨어"는 바쁘다는 핑계로 자기개발에 게을리 했던 나에게 큰 자극이 되었다. 나는 한순간 닫혀있었던 눈으로 밝은 빛이 새어 들어옴을 느낄 수 있었고, 나의 주변에서 열심히 살아가는 사람들로부터도 기존에 느끼지 못했던 배울점을 찾을 수 있게 되었다.

하지만 또다른 문제는 한순간 아주 짧게 떠올랐던 배움의 쪼가리들이 멋들어지게 다듬어져 체계적으로 정리되지 못하고 공중으로 흩어져 간다는 것이다.

나는 아직도 이렇게 불현듯이 떠올라다가 부질없이 사라져가는 생각들을 멋들어지게 정리 할 수 있는 방법을 찾지 못했다. 최근에 선물받은 값비싼 플랭크린 다이어리를 업무 용도에 한정해서 비교적 잘 활용하고 있지만, 왠지 이곳에 업무상의 사실관계 이외의 배움의 생각을 적지 못하고 있다. (그래도 플랭클린 플래너가 비싼 값 이상을 해내고 있음은 분명하다. 태생부터 컴퓨터와 친숙한 N세대는 아니지만, 아직 PDA나 노트북을 통한 업무 관리보다는 구식의 아날로그 방식이 좀 더 사용하기 쉽다고 느끼는 이유는 아직 이들이 쓸만한 h/w, s/w환경을 제공하지 못하기 때문이라고 생각한다.)

아직 아무것도 결정된 것도 확실한 것도 없지만, 나는 이 블로그를 통하여 나의 생각들의 쪼가리를 모으고, 언젠가 이것들을 짜깁기하여 멋들어진 나만의 세계를 가지고 싶다.