소프트웨어 아키텍처에 대한 훌륭한 책들이 이미 많이 출간됐다. 이 책들은 무엇보다 소프트웨어 아키텍처를 정의하고, 분류하고, 서술한다. 아키텍처를 표현하는 표기법을 정의하고, 그 내용에 대해 의견을 교환한다. 그리고 오래도록 가치를 유지할 수 있는 좋은 아키텍처를 선택할 수 있도록 가이드를 제공한다. 불행히도 이런 책들은 성공적인 아키텍처를 만드는 데는 도움이 될지 모르지만, 성공하는 솔루션을 만드는 데는 도움이 되지 않는다. 성공하는 솔루션을 만들려면, 서브시스템이나 인터페이스를 뛰어넘어야 한다. 'Front Controller' 또는 'Pipe and Filters' 같은 아키텍처 패턴을 뛰어넘어야 하고, 관계형 데이터베이스를 3차 노말 폼(third-normal-form)으로 만드는 문제를 뛰어넘어야 한다. 또한 소프트웨어 아키텍처를 뛰어넘어서 비즈니스적인 문제를 이해하고 포용하는 방향으로 나아가야 한다. 성공하는 솔루션을 만들려면 반드시 비즈니스적인 문제를 해결해야 한다.

비즈니스적인 문제의 한 예로 기술지원 문제를 들 수 있다. 피치 못하게 고객 중에는 당신의 소프트웨어 때문에 문제를 겪는 고객이 생길 수밖에 없다. 로그 파일을 운영하는 방식, 다른 시스템과 통합하는 방식, 시스템을 설정하는 방식, 시스템을 업그레이드하는 방식 등에 관해 당신이 오래전에 내린 결정들이 고객의 문제를 얼마나 잘 지원할 수 있을지를 결정짓는다. 『소프트웨어 아키텍처 2.0』은 비즈니스적인 문제와 아키텍처적인 선택 간의 관계를 논의하면서, 소프트웨어 아키텍처를 넘어 성공하는 솔루션에 도달할 수 있도록 도와줄 것이다.

이 책은 내가 저가의 단일 사용자 프로그램, 학술 연구에 사용하는 소프트웨어 시스템, 사내용 시스템의 문제를 진단하고 해결하는 유틸리티, 수백만 달러짜리 기업용 분산 플랫폼 등을 개발하던 경험으로부터 배워온 고유한 관점을 제시한다. 지금까지 나는 개인적인 기여자, 현장 관리자, 기업의 고참 경영진 등 다양한 역할을 수행해왔다. 긴 시간 동안 엔지니어링팀, 제품 마케팅과 관리팀, QA팀, 기술문서 발행팀, 그리고 1선과 2선 지원조직 등의 내부에서 일하거나, 이런 조직을 이끌며 일했으며, 여러 도시와 대륙에서 팀과 프로젝트를 관리했다.

모든 소프트웨어를 함께 묶는 공통 분모는 그것이 어떤 사람에게 가치를 제공하기 위해 만들어졌다는 점이다. 예를 들어, 연구용 소프트웨어는 어떤 현상을 이해하고자 하는 연구원의 필요를 위해 봉사한다. 고객관리에서부터 공급체인 관리에 이르기까지 모든 것을 다루는 기업용 애플리케이션 소프트웨어는 잘 정의된 일군의 기업 사용자들의 필요를 위해 봉사한다. 기업용 애플리케이션 소프트웨어는 라이선스를 통해 지속적으로 이익을 내려는 사업적 목적으로도 사용된다. 게임에서부터 개인용 연락처 관리 프로그램, 재고관리 시스템, 그래픽 디자인 도구에 이르기까지 모든 종류의 소프트웨어에 대해서도 비슷한 설명을 적용할 수 있다.

이 책에서 밝히고 논의하는 문제들은 모든 종류의 시스템에 적용된다. 그중에서도 특히 기업용 애플리케이션 소프트웨어를 중심으로 논의한다. 기업용 애플리케이션은 내가 오랜 시간 경력을 쌓아온 분야다. 범용적으로 통용되는 정의가 존재하지는 않지만, 기업용 애플리케이션이란 일반적으로 다음 특성 중 한두 가지를 만족시키는 애플리케이션을 말한다.

● 비즈니스적 필요를 지원하기 위해 설계됐다. 그리고 소규모 부서나 거대 조직에서 사용된다.
● 구축과 라이선스 비용이 많이 든다($50,000~$5,000,000 또는 그 이상).
● 복잡한 배치와 운영을 필요로 한다.
● 독립적으로 운영된다. 하지만 다른 기업용 애플리케이션과 통합될 때 비즈니스 목표를 더 잘 달성할 수 있다.

당신이 만드는 애플리케이션이 기업용이 아니더라도, 이 책은 유용할 것이다. 지속적인 가치를 유지하는 소프트웨어 솔루션을 만들고, 오랜 시간 동안 여러 번의 출시를 통해 고객의 필요를 만족시키는 일은 도전적이고, 즐겁고, 보상받을 만한 노력이다. 이것은 분명 기업용 애플리케이션 영역에만 한정된 이야기가 아니다!

이 책에서 소프트웨어 아키텍처를 언급하고 기술적인 문제를 논의하긴 하지만, 다이어그램을 완성하는 방법, 아키텍처를 문서화하는 방법, 안정적이고 분산된 웹 기반 컴포넌트 시스템을 디자인하는 방법 등에 논의를 집중하지는 않을 것이다. 이전에 말한 바와 같이, 이런 주제를 다루는 책은 시중에 많이 나와 있다. 사실 너무 많다. 그래서 많은 사람이 기술적인 세부사항에 그토록 집중함으로써 원래 제공하려 했던 비즈니스적 가치에 대한 시선을 잃게 만든다. 이것은 불행한 부작용이다.

순전히 기술적인 선택에 집중하지 않는 대신, 광범위한 영역에서 개발팀이 반드시 내려야 하는 실용적이고, 실무적인 선택에 집중한다. 그래서 성공하는 솔루션을 만들고 유지하는 데 진정한 도움을 준다. 나는 어떻게 출시본을 도출해야 하는지, 또는 어떻게 솔루션에 브랜드 요소를 통합시켜야 하는지 같은 실용적인 문제에 집중함으로써, 인위적인 장벽을 제거할 수 있다는 사실을 발견했다. 인위적인 장벽이란 함께 일하는 개발 분야의 사람들, 그리고 비즈니스와 마케팅 분야의 사람들 사이에 존재하는 장벽을 말한다.

이런 장벽이 양쪽 그룹 사람들이 성공하는 솔루션을 만드는 것을 가로막는다. 나는 엔지니어들이 비즈니스 문제에 대한 당연한 고려 없이 학구적인 기술에만 집중할 때 긴장한다. 또한 마케팅 사람들이 기반 기술 부산물에 대한 당연한 고려 없이 "이 기능을 만들어줘"라고 요구할 때도 마찬가지다. 양쪽 사람들이 그 영향에 대한 당연한 고려 없이 자기 주장을 하면, 성공하는 솔루션을 만들고 유지할 수 있는 가능성이 극적으로 낮아진다.

특히 문제가 되는 것이 있다. 이런 논쟁이, 기술 문제는 어떻게든 비즈니스 문제로부터 분리될 수 있다는 생각에서, 또는 비즈니스 문제는 어떻게든 기술 문제로부터 분리될 수 있다는 생각에서 만들어지는 것처럼 보인다는 점이다. 좋게 생각해도 이것은 틀린 생각이다. 나쁘게 생각하면 이것은 재앙을 낳는 처방이다. 개발자는 일상적으로 극한의 설계를 강요 받는다. 예를 들어 전체 시스템 비용을 낮추기 위한, 작은 메모리 풋프린트(footprint) 같은 요구다. 모든 회사가 이미 존재하는 시장에서 경쟁을 시작한다. 투자자들은 기술 혁신이 성공을 위해 필요한 경쟁우위를 제공할 것이라고 확신하기 때문이다. 당연하게도 투자자들은 기술 혁신이 고객에게 제공하는 비즈니스 모델에서의 혁신을 동반할 때보다 적극적으로 투자한다.

기술과 비즈니스 사이의 상호관계를 관리하는 것이 이 책에서 반복하는 주제다. 기술만 다룰 경우 당신은 흥미로운 기술, 또는 그저 우아한 시스템을 보유하게 될 것이다. 하지만 곧 시들고 만다. 아무도 사용하지 않을 것이기 때문이다. 비즈니스만 다룰 경우 많은 사람이 환호하는 페이퍼 솔루션을 가질 수 있다. 아마 투자도 유치할 수 있을 것이다. 하지만 서류로만 존재하는 솔루션일 뿐 지속적인 가치를 전달할 수 없다. 두 가지를 모두 다뤄야 성공하는 솔루션을 가질 수 있다. 새로운 기술이나 우아한 솔루션을 만드는 일은 재미있다. 그리고 복잡한 새로운 소프트웨어 애플리케이션이나 비즈니스 모델을 설계하는 것은 흥분되는 일이다. 이 두 가지 감정과 비견할 수 있는 깊은 만족감이 성공하는 솔루션을 만들고 유지하는 데에서부터 비롯된다. --- '저자 서문' 중에서

내가 처음 컴퓨터를 접했을 당시에는 컴퓨터로 할 수 있는 가장 재미있는 놀이가 프로그래밍이었다. 당시에 컴퓨터를 접한 대부분의 사람처럼 나도 조그만 코드를 만들고 그것이 동작하는 것을 보며 즐거워했다. 컴퓨터에 관한 최신 소식과 기술은 언제나 흥미진진한 관심거리였다. 그리고 당시에는 새로운 프로그래밍 언어를 습득하는 것이 새로운 소프트웨어 개발 기술을 습득하는 지름길이었다. 베이직에서 파스칼로, 파스칼에서 C로, 또 C++를 비롯한 객체 지향 언어로, 수많은 언어가 명멸했다. 소프트웨어 개발을 직업으로 삼아 15년 가까이 일하면서 나름의 경험을 축적했다. 지금 와서 생각해보면 프로그래밍 언어는 소프트웨어를 만드는 도구일 뿐, 그 자체로는 큰 의미가 없다. 필요에 따라 그리고 상황에 따라 선택하는 도구는 본질이 아니기 때문이다. 경험이 많은 개발자는 누구나 유행을 타는 도구보다는 쉽게 변하지 않는 본질에 관심을 둔다. 그래서 소프트웨어 아키텍처에 관심을 갖는다. UML 다이어그램과 디자인 패턴을 응용한 설계를 고민한다. 그리고 그 다음에는 무엇을 고민해야 할까?

이 책 『소프트웨어 아키텍처 2.0』은 소프트웨어 개발자가 가져야 할 궁극적인 목표를 주제로 삼고 있다. 즉 '성공하는 솔루션'을 만드는 것이다. 성공하는 솔루션은 아키텍처적으로 아름다운 솔루션을 말하지 않는다. 성공하는 솔루션은 사용자가 원하는 기능을 충분히 제공하는 솔루션을 말한다. 성공하는 솔루션은 시장에서 수익을 내는 솔루션을 말한다. 이 책은 UML 다이어그램을 멋지게 그리는 방법이나, 디자인 패턴을 멋지게 적용하는 방법, 코드를 멋지게 작성하는 방법 등을 설명하지 않는다. 그 대신 시장의 흐름을 읽는 방법, 마케팅 부서와 개발 부서 사이의 작업을 조율하는 방법, 시장에 솔루션을 내놓을 때 필요한 비즈니스 모델과 라이선스 모델을 계획하는 방법 등을 설명한다. 이 책은 마케팅을 이해해야 하는 개발부서 사람들과 개발을 이해해야 하는 마케팅 부서 사람들이 읽어야 한다. 양쪽 진영 사람들 모두에게 실전에 임할 수 있는 충분한 교양을 전해줄 것이다.

이 책의 주제는 '성공하는 솔루션'이다. 영어 원서에는 'winning solution'이라고 표현되어 있다. 이 용어를 '대박 솔루션'이라고 번역하고 싶었다. 강렬한 어감이 끌리기는 했지만, 고차원적 종합예술인 소프트웨어 개발을 너무 생생한 시장경제적 차원으로 끌어내리는 것 같은 걱정이 들었다. 그래서 '성공하는 솔루션'이라는 서술적인 번역을 선택했다. 이 책은 마케팅 아키텍트(마키텍트)의 역할을 강조하고 있다. 마키텍트는 개발팀, 영업팀, 기획팀을 총괄하면서 제품을 성공시키고자 노력하는 사람이다. 마키텍트는 개발자 출신의 관리자일 수도 있고, 영업이나 기획 출신의 관리자일 수도 있다. 본질적으로 마키텍트는 시장과 기술을 모두 이해하는 종합예술인이다. 저자는 개발자이고, 그래서 개발자가 대접받는 환경을 강렬하게 원한다. 이 책은 시장에서 성공하지 못하는 솔루션은 제아무리 기술적인 도달 수준이 높다 하더라도, '성공하는 솔루션'이 아니라고 정의한다. 그래서 개발자에게 시장에 대한 관심을 촉구한다. 개발자가 대접받는 환경도 궁극적으로는 개발팀과 영업팀과 기획팀이 합심해서 성공하는 솔루션을 많이 만들어야 이룰 수 있다고 생각한다. 대한민국에 성공 솔루션과 서비스가 많이 나오기를 기원한다.

소프트웨어 조직의 생산성을 높이고 성공하는 제품 솔루션을 만들기 위해 아키텍처와 마케팅 정보를 어떻게 통합해야 하는지를 기술과 비즈니스 관점에서 날카롭게 지적하고 상세히 설명한다.<br/><br/>비즈니스와 테크놀로지 사이의 관계를 성공적으로 조율하는 일은 21세기의 모든 기업이 직면한 엄청난 임무다. 『소프트웨어 아키텍처 2.0』은 중요한 임무를 적절히 수행하는 데 도움을 주는 실용적인 안내서다. 현대의 경제 시스템에서 소프트웨어에 관한 결정이 사업에 미치는 영향은 막중하다. 거꾸로, 사업에 관한 대부분 결정 역시 소프트웨어 애플리케이션의 가능성에 영향을 미칠 것이다. 이 책은 현실세계에서 성공하는 솔루션을 만드는 것에 대해 날카로운 직관과 실용적인 가르침을 담고 있다.<br/><br/>소프트웨어는 기업에 어떤 가치를 제공할 수 있도록 만들어져야 하지만 가치보다는 혼란을 초래하는 경우가 다반사다. 강력한 애플리케이션이 시장에 존재하지만, 그것을 구매하거나 라이선스를 도입한다고 해서 성공이 보장되진 않는다. 성공하는 솔루션이 되려면 기업의 인프라에 적절히 통합돼야만 한다.<br/><br/>소프트웨어 전문가인 루크 호만은 소프트웨어 아키텍처에 관한 결정을 내릴 수 있도록 중요한 방향을 일러준다. 그리고 소프트웨어를 성공시키기 위해 반드시 해결해야 하는 비즈니스 이슈를 이해하고 터득하는 방법을 알려준다. 사업 담당자와 개발팀은 항상 중요한 결정 사안들로 뒤덮인 지뢰밭을 지나야 한다. 이 책을 지도로 사용하면 그런 지뢰밭을 안전하게 빠져나갈 수 있을 것이다. 비즈니스와 테크놀로지가 만들어내는 최종적인 시너지를 통해 성공하는 기술 솔루션을 만들 수 있으며 기업도 성공의 발판을 닦을 수 있게 되리라.

루크 호만은 소프트웨어 개발을 최종 사용자의 관점에서 바라보는 흔치 않은 소프트웨어 기술자다. 그는 최종 사용자와 보내는 한 시간이 소프트웨어 아키텍처 선택을 위해 보내는 몇 시간, 또는 사용자 요구사항을 문서화하는 데 보내는 며칠보다 가치 있다고 확신한다. 소프트웨어 개발을 다룬 대부분의 책이 안정적인 소프트웨어를 설계하고 개발하는 방법에 집중한다. 이 책 『소프트웨어 아키텍처 2.0』에서는 소프트웨어 제품의 전 라이프사이클을 통해 사용자를 지원하는 과정, 즉 진정한 비즈니스 솔루션을 만드는 과정을 좀 더 현실적인 측면에서 조명한다. 루크는 스스로 사업적 가치를 만드는 일에 종사하면서, 소프트웨어와 소프트웨어가 수행하는 비즈니스 기능 사이의 관계를 긴밀하게 고찰하고 있다.
브루스 버번(텔로스 벤처 파트너)

딜버트 만화를 보는 사람에는 두 부류가 있다. 한 부류는 자기 회사에서 일어나는 일을 얼마나 정확하게 묘사했는지에 경탄하면서 만화를 보지만, 반면 하이테크 회사의 현실이 딜버트의 세계보다 더 심할지도 모른다고 우울해하며 만화를 보는 부류도 있다. 이 책은 후자에 속하는 사람들을 위한 책이다.
토니 나바렛(다이아몬드헤드 벤처스 부사장)

루크는 소프트웨어 개발에 관련된 도전거리를 풀 수 있는 검증된 방법을 제시한다. 그는 이 책에서 모든 개발 경영진이 소프트웨어 조직의 생산성을 개선하기 위해 사용할 수 있는 실용적이고 검증된 기법을 소개한다.
G. 브래드퍼드 솔소(태비즈 테크놀러지 CEO)

내가 읽은 책 중에 이처럼 소프트웨어 아키텍처의 사업적인 측면과 기술적인 측면에 대한 내부자의 관점을 모두 다루는 책은 없었다. 소프트웨어 영업 관리자와 개발 관리자를 같은 장소로 불러모으는 훌륭한 책이다!
데이먼 셰스터(록 글로벌 CEO, 『Delivering the Goods』의 저자)

테크니컬 아키텍처와 제품 마케팅에 관한 책은 정말 많다. 하지만 세계적인 제품을 개발하기 위해 아키텍처와 마케팅 정보를 어떻게 통합해야 하는지를 소개하는 책은 없으며, 있더라도 매우 드물다. 『소프트웨어 아키텍처 2.0』은 기술과 마케팅 사이에 이런 귀중한 가교를 제공한다. 이 책은 어떻게 하면 시장에서 수익을 내는 고품질의 제품을 내놓을 수 있는지 설명한다.
짐 하이스미스(커터 컨소시엄 이사, 『Adaptive Software Development』의 저자)

제품개발 관리자, 마케팅 관리자, 아키텍트, 그리고 제품 기능을 책임지는 기술 리더가 반드시 읽어야 할 책이다. 프로젝트의 라이프사이클과 제품의 라이프사이클 동안 어떻게 제품의 아키텍처를 정의하고 이용하는지에 대한 실무적인 견해를 보게 될 것이다.
요하나 로스만(로스만 컨설팅 그룹)

루크 호만은 제품개발에 관한 정수를 이 책에 표현했다. 그는 제품개발에 있어 마케팅과 엔지니어링 모두의 역할이 필요하다는 사실을 조리 있게 설명할 뿐만 아니라, 그 둘을 함께 연결해 성공적인 제품을 개발하는 과정을 이해하고 실행할 수 있도록 만든다.
리 싱글러(360 마켓 뷰 사 회장)

종종 무시돼왔지만 중요한 업무인 라이선스, 배치, 설치, 설정, 지원 등을 다루는 책이 마침내 출간됐다. 이 책은 소프트웨어 제품을 개발하는 모든 사람 또는 그것을 구매하는 사람들에게 '하버드 비즈니스 스쿨에서 가르쳐주지 않는 것'을 가르쳐준다.
메리 포펜딕(애자일 얼라이언스 매니징 디렉터, 포펜딕 LLC 대표)

『소프트웨어 아키텍처 2.0』은 소프트웨어 엔지니어링 프로들만을 위한 책이 아니다! 경영진과 제품관리자도 이 책을 읽음으로써 회사가 만드는 소프트웨어에 관한 결정을 내릴 때 필요한 배경지식을 얻을 수 있다. 나는 이 책이 관리부서와 개발부서 간의 공감대를 만드는 데 유용한 도구임을 확인했다. 구현 세부사항을 깊이 언급하기보다는 비즈니스와 고객에 관련된 문제를 구체적으로 설명하기 때문이다.
데이비드 체이컨(시스템 아키텍처 부사장, 애자일TV)

『소프트웨어 아키텍처 2.0』은 그 제목이 암시하듯이 토탈 솔루션을 개발할 때 외면당하는 측면을 제대로 언급하고 있다. 호만은 광범위한 주제를 다루면서 열정과 깊이를 모두 드러낸다.
크레이그 프리스(레조넌트 소프트웨어 사 프로덕트 관리 이사)

QA 관리자로 루크 호만과 함께 일한 적이 있다. 그는 소프트웨어 개발에 관한 경쟁력을 보유한 인물이다. 기술적인 문제에 맞서 일했고, 어려운 비즈니스 결정을 다루며 땀을 흘렸다. 그는 소프트웨어 아키텍처에 관한 비즈니스와 기술 방면 모두에 대해 글을 쓸 수 있는 독특한 자질을 갖췄다. 두 세계를 성공적으로 연결한 이 책은 제품관리자와 소프트웨어 기획자를 위한 세미나용 핸드북이다.
제임스 바흐(새티스파이스(Satisfice) 설립자)

비즈니스적인 추진력과 소프트웨어 개발 사이의 상호작용으로부터 한 걸음 물러서서 평가함으로써, 성공하는 솔루션을 만드는 것을 바라보는 새로운 관점을 제공하는 책이다. 이 책은 효과적인 솔루션을 개발하는 과정에 존재하는 함정을 찾아내고, 문제에 대한 실무적인 대안을 제안함으로써 시장에 빠르게 접근할 수 있는 실용적인 가이드를 제공한다. 실제 사례를 통해 라이프사이클의 각 단계별 지침을 제공하며, 전체 프로젝트팀이 갖춰야 할 분명한 역할과 책임도 설명한다. 위험에 굴복할지도 모른다고 느껴진다면, 다른 사람의 도움을 청하거나, 검증된 모델을 채택하라. 위험을 피할 수 있는 대안을 제시하고, 중요한 결정 포인트를 설명하고 있는 이 책은, 성공적인 소프트웨어를 개발하는 데 필요한 모험과 역학, 그리고 성공하는 솔루션을 이해하는 방법을 찾는 소프트웨어 아키텍트와 제품개발자의 필독서다.
마크 벨케(휴렛 팩커드 마케팅 매니저)

성공적인 소프트웨어 제품의 테크니컬 아키텍처는 시장의 실체에 대응하는 것이어야 한다. 목표는 분명하다. 마케팅 담당자와 기술 담당자는 종종 자신이 타협할 수 없는 태도와 전망의 골로 갈라진 2개의 교전 중인 진영에 속해 있음을 발견한다. 이 책은 그 골을 메우고 제품의 성공에 집중하고 싶어하는 양쪽 진영의 모든 사람을 위한 필독서가 될 것이다.
데이브 퀵(마이크로소프트 사 통합 솔루션 개발그룹의 아키텍트)

소프트웨어 비즈니스 세계에서 아키텍처는 매우 모호한 용어가 됐다. 무엇을 의미하는지 명쾌하게 정의를 내리고 개념을 잡기가 어려운 용어다. 나는 '아키텍처'가 본질적으로 주관적인 용어라고 생각한다. 사람들은 자신의 소프트웨어 아키텍처를 설명할 때, 자기 시스템의 중요한 부분을 골라서, 선택한 부분들이 어떻게 조합되는지, 그리고 시스템을 설계할 때 중요한 결정을 어떻게 내렸는지에 대해 설명한다. 아키텍처는 기술적인 문제인 것처럼 보인다. 결정해야 할 중요한 문제들이 기술적인 문제이기 때문이다.

루크와 지난 몇 년간 많은 이야기를 나누며 그가 유감스럽게도 대부분의 아키텍처 관련 논의에서 등한시되던 사안들을 지적하는 말을 듣고 정말 기뻤다. 시스템을 보는 마케팅적인 관점, 라이선스 조약, 브랜딩, 배치, 과금 등 모든 조각이 어느 하나 빠짐없이 모두 중요하다. 이 모든 문제는 중요한 기술적인 함의와 사업적인 함의를 담고 있다. 고참 기술자는 이런 문제를 생각해야 한다. 그렇지 않으면 기술적 잠재력이 있는 시스템도 좋은 사업적 결정을 내리는 데 실패할 수 있다.

소프트웨어를 다른 사람들에게 판매하는 사람들 대부분이 이런 문제를 겪는다. 조직 내부의 IS 부서 아키텍트도 이런 문제에서 자유로울 수 없다. 외부 업체와의 라이선싱 계약 때문에 소프트웨어 비용에 큰 영향이 있을 것이다. 과금 방식 또한 사업적인 문제로 입금취소 기능을 도입하기로 결정할 경우 중요한 문제로 부각된다. 브랜딩은 사업적인 측면에서 회사를 노출시키는 데 도움이 된다.

루크는 기술적인 측면과 사업적인 측면을 모두 다뤄본 사람의 관점에서 글을 쓴다. 양쪽 측면 모두에 능숙하기 때문에 그는 종종 논의조차 되지 않는 문제도 숙고한다. 이것이 그의 장점이다. 루크는 생각조차 하지 않았던 문제로 인해 우리가 곤란에 처할 수도 있음을 지적한다. 그리고 그런 곤란함을 극복할 수 있는 절차에 대해 조언한다. 앞으로 이 책은 소프트웨어 설계의 기술적 측면에서 매우 훌륭한 업적으로 자리매김할 것이다.
마틴 파울러

소프트웨어 짜는 일은 과학이라기보다 예술에 가깝다고 생각한다는 점을 미리 밝힌다. 그렇다면, 어떻게 내가 창의적인 문제가 아닌 실천적인 문제를 깊게 다루는 책에 대해 추천사를 쓸 것인가?

예술과 소프트웨어 양쪽의 창의적인 프로세스는 너무 과대평가되어 있다. 편안한 의자에 앉아 마음의 눈을 깨끗이 하고 소프트웨어의 요정이 마음속에 들어와 아무런 노력 없이도 수천 줄의 우아한 코드를 두뇌에 흘려주는 장면을 상상해보라. 소프트웨어를 만들어본 적이 있는 사람이라면, 현실은 그렇지 않다는 사실을 잘 알 것이다.

예술은 어렵다. 디버깅 역시 어렵다. 이 책은 당신과 당신 팀이 더 나은 예술가가 되도록 도울 것이다. 이 책은 원칙, 팀워크, 땀, 그리고 영감에 관한 책이다. 나는 많은 이가 이 책을 읽기 바란다. 그래서 위대한 예술을(즉 소프트웨어를) 만들어 세상을 바꿨으면 좋겠다.
가이 가와사키(개러지 테크놀러지 벤처스의 CEO)