원본이 문제인지 번역이 문제인지 모르겠지만 쉽게 읽히지 않는 책이었다. 내용이 어려운 것은 아니었음에도 그런 걸 보면 역시나 번역이 좀 문제가 아니었나 싶다. 번역 문제가 아닌 내용으로 봐도 [한 번 읽은 것으로 만족]하는 책이다.
그래도, 꼼꼼히 읽은 결과 아래와 같은 내용은 두고두고 되새김질을 할 만하다.
단순히 시간상 비용을 기반으로 하면 우리는 구축하는 데 드는 시간과 소프트웨어의 가치(그리고 고객에게 제공하는 서비스의 가치)를 동일시하게 된다.
누가 소프트웨어의 가치를 단순히 투입 비용을 기반으로 생각하겠냐고 반문할지 모르겠으나, 당장 주위를 둘러보자. 무의식적으로 판단되는 많은 부분에서 대부분은 투입 시간이 마치 서비스의 가치인 것처럼 생각하고 계산하는 경우가 많지 않은가? 의식적으로 두 가지를 분리해서 비교하는 습관을 들이지 않는다면, 어느날 문득 괴짜 은둔자 같은 자신의 모습을 발견할지도 모를 일이다. 자신의 복잡하고 훌륭한 소프트웨어가 아무도 인정하지 않는다고 불만을 투덜거리면서 말이다.
마지막 수단으로 코드를 작성하라.
책에 정말 감동적인 예가 있었다. 엘리베이터가 느리고, 효율적으로 움직이지 않는다고 불평인 건물이 있었다고 한다. 뭐 사실 대부분 늘 그렇게 느끼고 있다. 이런 엘리베이터를 개선해 보고자 여러가지 방법을 조사한 결과 심리학자가 엘리베이터 앞에 거울을 설치하면서 불만이 사라졌다는 얘기다. 문제를 해결하는 방법이 소프트웨어 개발의 범위를 넘어서면 내 영역을 벗어나는 경우라 방법을 모르고 쩔쩔 매면서 계속 프로그램에 덕지덕지 기능만 추가해 가는 경우가 있다. 결론은 쓰레기 같은 시스템과 불만에 가득찬 고객, 그리고 피곤에 쩔어 쓰러지기 일보직전인 내가 남는다.
개발자라는 타이틀은 기본적으로 다른 사람의 문제를 해결해주는 사람이라고 생각한다. 물론 그 문제의 해결 방법이 프로그램을 작성해서 제공하는 것일 가능성이 높은 일을 하지만 그렇지 않은 경우도 종종 있다. 개발자라는 타이틀은 결국 복잡한 문제를 멋지게 해결하면서 그 도구로서 코딩을 하는 것이지 모든 문제를 코딩으로 해결하는 사람이 아니라는 점은 항상 잊지 말아야 할 것이다.
우리는 모든 작업에서 ‘코드작성’ 모드로 돌입하는 순간, 왜 우리가 이 코드를 작성하고 있는지 그 진짜 이유에 대하여 생각할 수 있는 기회를 잃게 된다.
난 이 문장을 생각 좀 하고 일하자는 말로 해석한다.
어떤 해결책에 대해서 뭐가 문제인지, 뭘 해야하고, 어떻게 해야할지 충분한 고민이 늘 중요하다고 생각한다. 개발에 비춰서 생각하면 분석, 설계와 같은 업무라고 할 수 있을텐데, 문서를 만드는데 급급하고 급하게 일단 코딩에 달려드는 경우가 많다. 코드를 작성하면서 생각해야 감이 온다는 말도 종종 듣고는 하는데, 생각하기 귀찮다는 말로 들릴 뿐이다.