프로그래머, 열정을 말하다

본 책은 더 나은 코드를 작성하기 위한, 더 나은 소프트웨어를 설계하기 위한 지침을 제시하진 않습니다. 그러나 더 나은 소프트웨어 엔지니어가 되는 지침을 제시합니다. 그러면 여러분은 더 나은 엔지니어가 되기 위해서는 어떤 모습을 가져야 한다고 생각하시나요? 컴퓨터 과학이나 본인이 사용하는 기술에 대한 깊숙한 이해를 가진 모습이라는 데는 다 동의를 할 것입니다. 그러면 이외에는 어떤 것이 있을까요? 본 책은 이에 해당하는 궁금증을 풀어 줄 것입니다.

신입 때 그런 적이 있었습니다. 그 당시 회사는 기획자 1명에 개발자 10명 정도로 구성되어 있었고, 이런저런 이유로 기획서는 개발자가 만족할 만한 수준은 아니었습니다. 한 대리님 제게 말씀해주시기를 "대기업의 기획은 작은 조건까지 다 달아서 기획이 나온다. 지금 이것은 기획서가 아니다."라고 말씀하시며 불평을 하셨고, 저 또한 그에 동의하며 불평을 했던 기억이 있습니다. 

이 책을 읽은 지금 다시 생각을 해보면 '저러한 행동은 단순한 코더를 자청하는 행동이었구나.'라는 생각을 듭니다. 기획서에 나오는 데로 코딩만 하는 자원은 충분히 대체될 수 있습니다. 그러나 단순한 기획 속에서 세심한 구현을 하는 엔지니어는 어떨까요? 또 탄탄한 도메인 지식을 토대로 한 엔지니어의 경우에는 어떨까요?

책에서 재미난 내용이 나옵니다. 회사가 엔지니어에게 연봉 5000만 원을 준다면 회사는 해당 엔지니어에게 1년에 최소 1억 원을 기대하게 됩니다. 이유는 엔지니어에게 투자한 만큼의 비용이 돌아오길 바라기 때문이죠. '연봉 * 2'만큼의 실적을 내고 있는지, 그것을 위해 뭘 해야 할지 고민하게 되었습니다.

다음 주부터 새로운 직장에서 새로운 경험을 쌓기 전 이 책을 읽은 것은 참 행운인 것 같습니다. 저를 위해 그리고 회사를 위해 뭘 해야 할지 방향이 잡혔기 때문이죠. 평소 '기술적 지식 >>>>> 도메인 지식' 이라고 생각했던 저에게 새로운 안목을 심어주었습니다.