이 책을 이제야 읽었다는 사실이 좀 부끄럽긴 하지만, 어쨌든 이제라도 읽어서 다행인 거겠죠. 이렇게 오래도록 읽힐 수 있는 책을 쓴다는 것. 그리고 급변하는 컴퓨팅 환경에서 아직도 유효한 내용을 많이 담고 있다는 사실에 놀랐습니다.
저자는 숙련된 프로그래머들이 프로그램 작성을 시작하기 전에 판에 박힌 듯이 상세한 흐름도를 만드는 것을 본 적이 없다. 조직에서 요구하는 표준에 흐름도가 포함되어 있더라도 대부분은 프로그램이 실체화된 이후에 만들어진다.
폴 그레이엄 아저씨가 쓴 “해커와 화가”라는 책에도 이와 유사한 이야기가 들어 있습니다. 뛰어난 개발자들은 그림을 그리듯이 프로그램을 작성한다는 이야기였는데요, 제가 현업에서 만나본 대부분의 뛰어난 개발자들도 비슷한 방식으로 일을 하더군요. 모든 설계가 끝난 다음에 코딩을 시작해야 한다라는 이야기를 대학교 수업에 들으면서 참 씁쓸했습니다. 탁상공론의 끝은 어디일까, 라는 생각이 들었기 때문이죠.
순서도만 보여주고 테이블을 보여주지 않으면 오리무중 상태에서 빠져나올 수 없다. 테이블을 보면 대개 순서도는 볼 필요도 없이 모든 것이 명백해진다.
개인적으로 코드 보다는 데이터 구조에 다는 주석을 더 좋게 여기는 이유이기도 합니다. 브룩스 아저씨의 말대로 대부분의 프로그램이 데이터 구조만 이해한다면 코드가 어떻게 돌아가는지는 저절로 이해할 수 있기 때문입니다.
저자는 오랫동안 프로그래머 후보들에게 “다음 11월은 어디 있는가?”라는 질문을 즐겨 해왔다. 질문이 너무 애매해서 이해하기 힘들다고 대꾸하면 “달력에 대한 당신의 정신적 모델에 대해서 말해보라”고 되묻는다. 정말 훌륭한 프로그래머는 뛰어난 공간 감각을 갖고 있으며, 대개 시간에 대한 자기 나름의 기하학적 모델을 갖고 있고, 설명하지 않아도 저자의 위 첫 질문을 잘 이해한다. 그들은 아주 개인적인 모델을 갖고 있다.
책 읽으면서 아! 하는 탄성을 지르게 된 부분입니다. 너무 공감하는 내용이었거든요. 프로그래밍을 가르쳐보면 대부분의 학생들이 어려워 하는 포인터, 재귀호출과 같은 것 들 내지는 리스트, 스택, 그래프, 트라이와 같은 자료 구조를 설명할 때, 뛰어난 프로그래머의 자질을 가진 학생들은 마치 그것들이 처음부터 자신들의 머릿속에 들어 있었던 것처럼 이해를 합니다. 그것에 대한 자신 나름의 기하학적 모델을 가지고 있다는 점이죠. 반면에 그런 모델이 없는 학생들은 구구절절한 비유를 들어서 설명을 해도 제대로 이해하지 못하는 경우가 많습니다. 이런 점은 디버깅을 할 때 더욱 극명하게 나타납니다. 기하학적 모델을 가지고 있는 학생들의 경우는 숫자만 보고도 그것들의 형태를 머릿속으로 재현하는 능력이 뛰어납니다. 반면 그렇지 않은 경우는 DDD 같은 툴을 사용해서 모델을 직접 보여주더라도 왜 그렇게 되는지에 대한 충분한 이해를 하지 못하는 경우가 많습니다.
빈약한 개념 설계와 좋은 개념 설계의 차이는 설계 방법의 견실함에 달려 있을 테지만, 좋은 설계와 훌륭한 설계의 차이는 전혀 그렇지 않다. 위대한 설계는 위대한 설계자만 할 수 있다. 소프트웨어 구축은 창조적인 과정이다. 견실한 방법론은 창조적인 정신에 힘을 주고 해방시킬 수 있지만, 판에 박힌 듯 일하는 사람들에게 불을 지피고 영감을 줄 수 없다.
사람이 전부다 (어쩌면, 거의 전부다)
결국은 모두 사람입니다. 사람, 사람, 사람. 사람이 하는 일이니 사람이 제일 중요할 수 밖에 없는 것 같습니다. 그런데 사람이 제일 어렵죠. 다른 모든 문제는 그 문제가 해결된 다음에나 생각해볼 가치가 있는 것들이 아닐까라는 생각을 저도 요즘 많이 했습니다. 결국 사람이 안되면 죽도 밥도 안되는거 아니겠습니까. 그런데 너무 많은 사람들이 지금 이 순간도 마법 같은 시스템 내지는 방법론을 찾고 있는 것이 현실인 것 같아 조금 안타까운 생각이 들기도 합니다. 어쩌면 사람은 너무 해결하기 힘든 문제라 그런지도 모르겠네요. 시스템과 기계는 그것보다는 다루기가 쉬우니깐염.
0 0