당시에 읽을때는 다른 원서에 비해서도 영어의 문장이 매우 어려웠을뿐 아니라 초보 프로그래머의 아키텍쳐에 대한 인식부족으로 매우 꼼꼼히 느릿느릿 읽을수 밖에 없었고 결국 한문장 한문장을 곱씹으며 읽어야 했기에 내용 하나하나가 새로움으로 다가왔습니다.
아키텍쳐란 이런것인가 이 모든 전략적 판단과 분석, 품질고려와 평가, 무언가를 창조할때 필요한 이 꼼꼼함.. 내가 좀더 나은 프로그래머가 된다면 이렇게 될수 있을까?....
아마도 그래서 이책의 번역서가 나온다는 얘기를 들었을때 가장 기대하던 독자중 한명이었습니다.
하지만 5년이 지난후 나오자마자 다시 읽게 된 책은 그때의 감동이 없었습니다. 아이러니칼 하게도 5년동안 너무도 당연한 이 이야기들이 현실에서 그닥 별 도움이 되지 않는다는 사실을 경험했기 때문입니다.
NASA에서는 어쩌는지 모르겠지만-ㅅ- 현실에서의 프로그래밍은
먼지 알수는 없지만 멋지고 남과는 다른 신선한-_-.... 이라는 기획에 품질목표는 커녕 뚝 떨어진 상명 하달식 일정에 쫓기고 이길이 아닌갑다의 정치적으로 휘둘리는 전략 목표 형식적으로 작성된 UML 설계 - 가끔은 이마저도 안하고 몇가지 형용사와 대명사만으로 말해주면 -이를테면 유연하고 멋지고 새롭고.. 머 하여튼 좋은 OOO같지만 OOO는 아닌 무언가-_- 알아서 채워야 하는 요구사항 어떻게 진행되는지를 아무도 모르기 때문에 코딩시간보다 더 많은 일단 닥치고 회의 누구도 읽지 않지만 쪽수를 채우기 위해 대충 작성된 문서화 컨베이어의 기계적인 조립공으로 대우받는 프로그래머 코딩표준도 없고 이리저리 한가해 보이는 사람 모아서 팀 만들어서 짜집기로 작성되고 잦은 팀원과 관리자 교체로 이제는 이유를 알수 없어 봉인된 소스
위 경험을 고스란히 다시하면서 다시 읽은 이책은 지루했고 따분했으며 읽는 내내 그래서 어쩌라고-ㅅ- 라는 혼잣말을 하게 만들곤 했습니다.
그러나 이 책에 "사람 냄새"가 나지 않는다고 해서 평가절하되야할 이유는 물론 없습니다. 소프트웨어 아키텍쳐 바이블이라는 별칭에 걸맞게 소프트웨어 공학을 배우고자 하는 사람이라면 누구나 한번쯤은 읽어야 하며 이론적인 바탕이 없이 경험만으로 한걸음 내딪는데는 훨씬 더 힘들기 때문입니다.
다만 이책을 읽는동안 체게바라의 이말을 꼭 기억해 두어야 합니다. "리얼리스트가 되자. 그러나 마음속에는 언제나 불가능한 것을 꿈꾸자"
.jpg)
