상세정보

현실세계에서 성공하는 솔루션을 만드는 것에 대해 날카로운 직관과 실용적인 가르침을 담고 있는 책이다. 소프트웨어 조직의 생산성을 높이고 성공하는 제품 솔루션을 만들기 위해 아키텍처와 마케팅 정보를 어떻게 통합해야 하는지를 기술과 비즈니스 관점에서 날카롭게 지적하고 상세히 설명한다.

소프트웨어 조직의 생산성을 높이고 성공하는 제품 솔루션을 만들기 위해 아키텍처와 마케팅 정보를 어떻게 통합해야 하는지를 기술과 비즈니스 관점에서 날카롭게 지적하고 상세히 설명한다.

지난 수년간 새롭고 혁신적인 제품을 만드는 많은 프로젝트에서 생산한 제품들은 끝내 성공하는 솔루션이 되는 데 실패했거나 힘든 과정을 겪어야만 했다. 실제로 도움이 되는 가이드라인을 엄청나게 제공하는 매우 유용하고 유익한 책이다.

댄 레윈 / 마이크로소프트 .NET 개발 담당 부사장

비즈니스 마인드와 기술이 만나면 정말 마법 같은 일이 일어난다. 두 분야의 아이디어를 융합시키는 데 큰 도움이 되는 책이다.

데이빗 랭커샤이어 / Geniant 사 CEO

비즈니스와 테크놀로지 사이의 관계를 성공적으로 조율하는 일은 21세기의 모든 기업이 직면한 엄청난 임무다. 『소프트웨어 아키텍처 2.0』은 중요한 임무를 적절히 수행하는 데 도움을 주는 실용적인 안내서다. 현대의 경제 시스템에서 소프트웨어에 관한 결정이 사업에 미치는 영향은 막중하다. 거꾸로, 사업에 관한 대부분 결정 역시 소프트웨어 애플리케이션의 가능성에 영향을 미칠 것이다. 이 책은 현실세계에서 성공하는 솔루션을 만드는 것에 대해 날카로운 직관과 실용적인 가르침을 담고 있다.

소프트웨어는 기업에 어떤 가치를 제공할 수 있도록 만들어져야 하지만 가치보다는 혼란을 초래하는 경우가 다반사다. 강력한 애플리케이션이 시장에 존재하지만, 그것을 구매하거나 라이선스를 도입한다고 해서 성공이 보장되진 않는다. 성공하는 솔루션이 되려면 기업의 인프라에 적절히 통합돼야만 한다.

소프트웨어 전문가인 루크 호만은 소프트웨어 아키텍처에 관한 결정을 내릴 수 있도록 중요한 방향을 일러준다. 그리고 소프트웨어를 성공시키기 위해 반드시 해결해야 하는 비즈니스 이슈를 이해하고 터득하는 방법을 알려준다. 사업 담당자와 개발팀은 항상 중요한 결정 사안들로 뒤덮인 지뢰밭을 지나야 한다. 이 책을 지도로 사용하면 그런 지뢰밭을 안전하게 빠져나갈 수 있을 것이다. 비즈니스와 테크놀로지가 만들어내는 최종적인 시너지를 통해 성공하는 기술 솔루션을 만들 수 있으며 기업도 성공의 발판을 닦을 수 있게 되리라.

★ 이 책에 쏟아진 찬사 ★

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

- 브루스 버번 / 텔로스 벤처 파트너

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

- 토니 나바렛 / 다이아몬드헤드 벤처스 부사장

루크는 소프트웨어 개발에 관련된 도전거리를 풀 수 있는 검증된 방법을 제시한다. 그는 이 책에서 모든 개발 경영진이 소프트웨어 조직의 생산성을 개선하기 위해 사용할 수 있는 실용적이고 검증된 기법을 소개한다.

- G. 브래드퍼드 솔소 / 태비즈 테크놀러지 CEO

내가 읽은 책 중에 이처럼 소프트웨어 아키텍처의 사업적인 측면과 기술적인 측면에 대한 내부자의 관점을 모두 다루는 책은 없었다. 소프트웨어 영업 관리자와 개발 관리자를 같은 장소로 불러모으는 훌륭한 책이다!

- 데이먼 셰스터 / 록 글로벌 CEO, 『Delivering the Goods』의 저자

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

- 짐 하이스미스 / 커터 컨소시엄 이사, 『Adaptive Software Development』의 저자

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

- 요하나 로스만 / 로스만 컨설팅 그룹

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

- 리 싱글러 / 360 마켓 뷰 사 회장

종종 무시돼왔지만 중요한 업무인 라이선스, 배치, 설치, 설정, 지원 등을 다루는 책이 마침내 출간됐다. 이 책은 소프트웨어 제품을 개발하는 모든 사람 또는 그것을 구매하는 사람들에게 ‘하버드 비즈니스 스쿨에서 가르쳐주지 않는 것’을 가르쳐준다.

- 메리 포펜딕 / 애자일 얼라이언스 매니징 디렉터, 포펜딕 LLC 대표

루크 호만은 열정적이고 명료한 이야기로 소프트웨어 아키텍처에 관한 주의를 환기시킨다. 기술적인 측면만이 아니다! 기술적인 아키텍처는 의미 깊은 사업적인 부산물을 수반한다. 이식성, 사용성, 설정, 업그레이드와 출시 관리, 보안, 그리고 기타 아키텍처적인 선택을 무시한다면 프로젝트가 실패할 뿐만 아니라, 실망한 고객들로부터 번거로운 법정소송을 당할 수도 있다. 『소프트웨어 아키텍처 2.0』은 성공하는 제품관리자의 필독서다!

- 에드워드 요든 / 소프트웨어 개발서 저자

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

- 데이비드 체이컨 / 시스템 아키텍처 부사장, 애자일TV

제품 마케팅은 제품 아키텍처에 큰 영향을 끼친다. 이는 그다지 놀랍거나 새로운 일이 아니다. 하지만 소프트웨어 아키텍처를 다룬 대부분 책에서는 이 사실에 대해 침묵한다. 우리에게 아키텍처의 기술적 측면과 마케팅적 측면을 구별하는 어휘가 부족하기 때문일 것이다. 이 책에서는 적절한 어휘들로 이런 중요한 차이점을 표현하고 아키텍처의 성공을 위한 전반적인 전략을 제공한다.

- 데이브 W. 스미스

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

- 크레이그 프리스 / 레조넌트 소프트웨어 사 프로덕트 관리 이사

내가 모은 기술 서적 목록을 보다 보면, 많은 책이 이미 기술적 혁신과 변화에 뒤처졌음을 확실히 알 수 있다. 하지만 그 의미가 퇴색되지 않는 책도 있다. 루크 호만의 새 책 『소프트웨어 아키텍처 2.0』이 바로 그런 책이다. 이 책은 내가 기억하기로, 소프트웨어 개발을 전체적인 관점에서 조망한 최초의 책으로서 틈새를 확실히 메워준다. 기술적인 측면을 넘어서, 중요한 비즈니스 문제와 마케팅 개발 문제를 엮고 결합하며, 기술 프로세스와 마케팅 프로세스를 결합해야만 성공하는 솔루션을 만들 수 있음을 보여준다. 다루는 주제나 내용 또한 프로그래머, 설계자 등 기술직의 한계를 넘는다. 마케팅 전문가에게는 그들의 결정과 전략이 어떻게 기술적 결정에 영향을 주는지 보여주며, 고객에게는 소프트웨어 제작사와 일하는 최선의 방식에 대한 직관을 일깨워준다. 소프트웨어 회사에게는 성공적인 벤처를 만드는 계획을 제공한다. 책은 적당한 정도의 난이도와 쉽게 이해할 수 있는 언어로 내용을 전달하므로 정보를 기억하고 적용하기 쉽다. 이 책이 다루는 주제는 시간에 구애 받지 않으므로, 오랫동안 그 가치를 이어갈 것이다.

- 클레이 밀러

이 책을 강력하게 추천한다. 예전에 소프트웨어 회사의 CEO와 설립자로서 많은 소프트웨어 엔지니어와 함께 일했으며, 엔지니어링 분야를 책임지는 여러 VP와 함께했었다. 루크는 예전에도 최고였고 지금도 최고다. 그는 위대한 엔지니어일 뿐 아니라 좋은 코드와 아키텍처에 관한 결정을 내릴 때 반드시 관여해야 하는 전략적인 비즈니스 문제에 대해 날카로운 통찰력을 지녔다. 이 책은 소프트웨어 시스템을 구축하는 모든 사람의 필독서다.

- 케빈 리베트 / BCG 컨설팅 수석 고문, 『Rembrandts In The Attic』의 저자

매우 다양하면서도 사소한 기술적 결정들이 어떻게 경제적, 전략적 지형 형성에 관여하는지를 독특한 관점으로 설명하는 책이다. 업계에 종사하는 많은 회사의 전략 담당자들이 이런 직관에서 놀랄 만한 가치를 발견할 것이다.

- 마르타 암람 / 『Value Sweep』 저자이자, 『Real Options』의 공저자

루크는 그의 엄청난 경험을 좋은 곳에 쏟아부어 마케팅 부서와 엔지니어링 부서 사이의 반목과 대결을 잠재웠다. 이 책은 모든 숙련된 엔지니어, 소프트웨어 아키텍트, 제품관리자의 필독서다. 이 책에 있는 실용적인 조언을 이용하면 경쟁자를 물리치는 데 도움이 될 것이다.

- 하인리히 간텐바인

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

- 제임스 바흐 / 새티스파이스(Satisfice) 설립자

루크 호만의 뛰어난 책 『소프트웨어 아키텍처 2.0』은 아키텍트이자 비즈니스 리더로서 힘들게 획득한 귀중한 직관을 나눠준다. 그는 아키텍처가 단지 계층에 대해 논의하는 것만이 아님을 보여준다. 아키텍처는 시장, 비즈니스, 그리고 기술적 요인에 대한 이해를 바탕으로 성공하는 솔루션을 만드는 일이기 때문이다.

- 크레이그 라만

『Applying UML and Patterns: An Introduction to OOA&D and the Rational Unified Process』의 저자

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

- 마크 벨케 / 휴렛 팩커드 마케팅 매니저

위대한 애플리케이션을 만들 때 당신은 ‘모든 것’을 생각해야 한다. 위대한 애플리케이션은 위대한 아이디어, 위대한 아키텍처, 또는 고객의 필요에 대한 위대한 대응, 이 중 한 가지로부터 얻어지는 것이 아니다. 마케팅, 기술, 심리학, 지원, 경제, 법적 요소 등 여러 가지 요소를 아우르는 특별한 통합을 통해 만들어진다. 많은 책이 소프트웨어 애플리케이션 개발에 관한 개별적인 요소들을 다루는 데 반해, 루크 호만의 책은 매우 광범위한 주제를 다룬다. 특히나 애플리케이션 개발에 필요하면서도 자주 다뤄지지 않던 주제들이다. 소프트웨어 애플리케이션 개발에 관여하는 모든 사람에게 이 책을 추천한다. 이 책은 소프트웨어 개발 과정에서 고려해야 하는 모든 것을 위한 가이드가 돼줄 것이다. ‘모든 것’을 다루는 책은 없었다. 바로 그 점이 이 책을 높이 사는 이유다.

- 짐 게이 / 원 점프 컨설팅

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

- 데이브 퀵 / 마이크로소프트 사 통합 솔루션 개발그룹의 아키텍트

이 책은 내가 기술자에서 제품팀의 리더로 변신해서, 공부와 행동과 오류를 통해 배웠던 많은 교훈을 전해준다. 여전히 소프트웨어 개발과 경영 관리 사이에 존재하는 간극을 중재하려고 시도하는 사람에게 이 책은 훌륭한 안식처가 될 것이다. 이 책은 수없이 “오 예!”라고 외칠 만한 직관들로 가득하다. 내가 팀과 함께 새로운 제품을 만들고 개발하는 일을 계속하는 한 이 책을 지침서로, 그리고 교육 교재로 계속 사용할 것이다. 이 책은 ‘큰 그림’을 보여준다. 그리고 비용이 많이 드는 함정을 피하게 해준다. 제품개발자, 마케팅 관리자, 이 분야에 뜻을 둔 사람, 현재의 관리방식에 불만이 있는 사람이라면 호만의 책을 꼭 읽어야 한다.

- 토드 거빈 / 옵티뷰 사 대표

★ 저자 서문 ★

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

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

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

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

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

● 비즈니스적 필요를 지원하기 위해 설계됐다. 그리고 소규모 부서나 거대 조직에서 사용된다.

● 구축과 라이선스 비용이 많이 든다($50,000~$5,000,000 또는 그 이상).

● 복잡한 배치와 운영을 필요로 한다.

● 독립적으로 운영된다. 하지만 다른 기업용 애플리케이션과 통합될 때 비즈니스 목표를 더 잘 달성할 수 있다.

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

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

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

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

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

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

정보제공 :

목차
이 책에 쏟아진 찬사 = 4
추천의 글 Ⅰ 마틴 파울러 = 10
추천의 글 Ⅱ 가이 가와사키 = 11
감사의 글 = 12
저자 소개 = 13
옮긴이의 말 = 14
들어가며 = 27
1장 소프트웨어 아키텍처
 소프트웨어 아키텍처의 정의 = 31
 소프트웨어 아키텍처를 보는 또 다른 관점 = 32
  서브시스템은 의존성을 관리할 수 있도록 디자인한다 = 32
  서브시스템은 인간적인 동기와 욕구를 충족시킬 수 있도록 디자인한다 = 32
  훌륭한 아키텍처에 승복하라 = 34
  아름다움은 그것을 추구하는 사람의 눈 안에 있다! = 34
 소프트웨어 아키텍처가 중요한 이유 = 35
  수명 = 35
  안정성 = 35
  수정 작업의 난이도와 성격 = 35
  수익성 = 36
  사회적 구조 = 36
  영역 결정 = 38
  지속 가능한, 우월한 경쟁력 = 38
 아키텍처 만들기 = 38
 패턴과 아키텍처 = 41
 아키텍처의 발전과 성숙: 기능과 수용력 = 42
 아키텍처에 대한 관심과 육성 = 50
  기술적 자산 = 50
  기술적 부채 = 50
  알고 있는 버그 = 51
  라이선스 협약 준수 = 51
 제1, 제2, 제3의 원칙 = 52
  캡슐화 = 52
  인터페이스 = 52
  느슨한 연결 = 53
  적절한 규모 = 53
  높은 응집력 = 54
  매개변수 = 54
  지연 = 54
 아키텍처의 이해 = 54
 팀 = 56
2장 제품개발 첫걸음
 제품관리의 정의 = 61
 제품관리의 중요성 = 62
 제품개발 프로세스: 릴리즈 1.0 만들기 = 63
  개념제안서 = 65
  제품제안서／사업계획서 = 65
  개발계획서 = 65
  개발 = 67
  최종 품질보증(QA) = 67
  출시준비 = 70
  출시 = 70
 오해하지 말자 = 71
  폭포수 프로세스를 닮았다. 그런데 폭포수 프로세스는 효과적이지 않다 = 71
  모든 단계가 동등하게 중요한 것처럼 소개하고 있다 = 72
  시간을 상술하지 않고 있다 = 72
  어떻게 반복하나? = 72
  개발 프로세스를 정하지 않고 있다 = 73
  진행 단계별로 관련된 그룹 사이의 협업 수준을 명시하지 않고 있다 = 73
 사업계획서 = 74
 제품개발 프로세스: 릴리즈 버전 n.n.n 만들기 = 75
 제품개발 프로세스의 확장 = 76
  지속적인 마감 = 76
  변화관리 프로토콜 = 77
  재활용 상자 = 78
 주요 제품관리 개념 = 79
  마케팅의 4P = 79
  총 유효 시장, 총 접근가능 시장, 시장 세그먼트 = 81
  S자 제품 채택 곡선 = 82
  완전제품 = 85
  기술 우월성과 시장 우월성 = 86
  포지션과 포지셔닝 = 86
  브랜드 = 88
  메인 메시지 = 89
3장 마키텍처와 타키텍처의 차이점
 누가 무엇을 책임지는가? = 93
 솔루션 개발 초기에 영향을 주는 요인 = 95
 미래를 보는 안목으로 현실에서 성과 만들기 = 101
 미래 계획하기 = 102
 피드백 이용하기 = 103
 분명하게 만들기 = 105
 협력하며 일하기 = 107
  합의에 이르기 = 108
  데이터 공유하기 = 109
 컨텍스트 다이어그램과 타깃 제품 = 109
4장 비즈니스 모델과 라이선스 모델의 공생
 일반적인 소프트웨어 비즈니스 모델 = 115
  접근이나 이용기간 제한 = 118
  트랜잭션 = 122
  미터링 = 125
  하드웨어 = 128
  서비스 = 129
  매출증가／비용절감 = 130
 비즈니스 모델과 연관된 권리 = 131
 비즈니스 모델을 위한 타키텍처의 지원 = 134
  일반적인 문제 = 134
  접근이나 이용기간 제한 = 136
  트랜잭션 = 136
  미터링 = 138
  하드웨어 = 140
 라이선스 모델 강제하기 = 140
  명예 시스템 = 141
  직접 만든 라이선스 관리자 = 141
  서드파티 또는 전문 라이선스 관리자 = 142
  클라이언트 = 143
 시장의 성숙도가 비즈니스 모델에 미치는 영향 = 147
  비즈니스 모델 선택 = 148
5장 기술 도입
 라이선스 도입의 위험/보상 = 154
 계약서―액션(행동지침)이 있는 곳 = 158
  계약서의 기초 = 158
  라이선스 약정 = 158
 비즈니스 모델이 충돌하면, 협상을 해야 한다 = 164
 라이선스 협정서 존중 = 166
 라이선스 도입한 기술 관리 = 166
 오픈 소스 라이선스 도입 = 167
 라이선스 비용 = 168
 라이선스 도입의 경제학 = 171
6장 이식성
 알려진 이식성의 장점 = 175
 이식성에 관한 제안 = 176
 이식 가능한 애플리케이션 만들기 = 180
  인터프리터 언어를 사용하라 = 180
  표준에 기반한 영구 스토리지를 사용하라 = 181
  비즈니스 로직을 이식 가능하게 만들라 = 181
  사용자에게 가까울수록 이식성이 떨어진다 = 181
  표준화되고 공동 사용 가능한 서브시스템 간의 통신에는 XML을 사용하라 = 182
  이식성이란 명목으로 특정 플랫폼에 한정적인 우수한 기능을 감추지 마라 = 182
 난이도 도표 = 182
  1단계: 실행환경 지우기 = 184
  2단계: 실행환경 정렬하기 = 185
  3단계: 최종본 만들기 = 186
 조심해서 약속하라 = 189
7장 배치 아키텍처
 배치 방식 = 192
  고객 사이트 방식 = 192
  ASP 방식 = 192
  MSP 방식 = 193
  트랜잭션 방식(웹 서비스) = 193
 고객이 배치 아키텍처에 미치는 영향 = 195
  통제와 통합 = 195
  데이터 보안／프라이버시와 최고 부하 = 196
  비용과 업체에 대한 신뢰 = 196
  고객의 역량과 경험 그리고 지리적 분포 = 197
 회사가 배치 아키텍처에 미치는 영향 = 199
  세일즈 사이클 = 199
  인프라에 대한 투자 = 200
  현금 흐름 = 201
  유연성 = 201
  지리적 분포 = 202
  가격이 아닌, 서비스 = 202
 소프트웨어 배치 아키텍처의 선택 = 202
 배치 아키텍처와 작업 배분 = 203
 정보기기 = 204
 배포 방식이 소프트웨어 아키텍처에 미치는 영향 = 205
  유연한, 파라미터에 의한 통합 옵션, 또는 통합 옵션이 없는 경우 = 205
  업그레이드 정책 = 205
  데이터 보호와 접근 = 206
  이전 옵션 = 206
 소비자 소프트웨어의 미래 = 206
8장 통합과 확장
 사용자의 지배력 - 주도하는 힘 = 211
  통합／확장의 이유 = 211
 계층적인 비즈니스 아키텍처: 논리적인 구조 = 214
  사용자 인터페이스 계층 = 215
  서비스 계층 = 216
  도메인 모델 계층 = 216
  퍼시스턴트 데이터 계층 = 217
  주제에 의한 변주 = 218
 계층적인 비즈니스 아키텍처 만들기 = 219
 비즈니스 로직 계층에서의 통합과 확장 = 223
  기술, 그리고 제어권의 소재 = 223
  API를 통한 통합 = 224
  등록을 통한 확장 = 228
 퍼시스턴트 데이터의 통합과 확장 = 229
  뷰 = 230
  사용자 필드 = 231
  후크 테이블 = 232
  스프레드시트 피벗 테이블 = 234
  추출, 변환, 로드 스크립트 = 234
  고객에게 현실을 공개하라 = 235
 비즈니스 파생물 = 236
  전문가 서비스 = 236
  교육 프로그램 = 237
  자격증 = 239
  사용자 커뮤니티 = 241
  라이선스 협약 = 242
 여러 출시에 걸쳐 API를 관리하기 = 243
  API 관리 테크닉 = 244
9장 브랜드와 브랜드 요소
 브랜드 요소 = 247
  브랜드 네임 = 247
  그래픽, 슬로건, 기타 브랜드 요소 = 252
  언제 트레이드마크(TM) 심볼을 사용하나 = 253
 라이선스 도입한 브랜드의 관리 = 254
 브랜드 요소 수정 및 맞춤 = 254
 브랜드 요소 바꾸기 = 255
  변경해야 할 제품 영역 = 256
  QA와 변경 = 257
10장 사용성
 사용성은 돈에 관한 문제다 = 260
 멘탈 모델, 메타포 그리고 사용성 = 262
 타키텍처가 사용자 인터페이스 디자인에 미치는 영향 = 264
  영향을 미치는 범위 = 265
 속도에 대한 욕구 = 273
  우리가 이야기할 것을 분명하게 정하자 = 273
  마키텍트가 진정으로 원하는 것 = 276
  사용자에게 응답하기 = 278
  성능 그리고 타키텍처의 효과 = 279
11장 설치
 OOBE = 287
 아야! 그건 아프다고 = 289
  고객의 공포 = 289
 설치와 아키텍처 = 291
  원인과 선택 = 291
 설치 방법 = 294
  설치 관련 데이터 수집과 전제 조건 검사하기 = 294
  설치하기 = 296
  설치 이후 확인하기 = 298
 마지막 손길 = 299
  사용자는 매뉴얼을 읽지 않는다 = 299
  설치와 삭제를 테스트하라 = 299
12장 업그레이드
 설치와 비슷하다. 단지 더 나쁠 뿐이다 = 303
  업그레이드에 대한 공포 = 303
 업그레이드의 고통을 줄이는 방법 = 308
  고통 없는 업그레이드를 위한 선택 = 308
 시장 성숙도와 업그레이드 = 312
13장 설정
 설정용이성(사용성의 한 요소) = 315
 시스템 컨텍스트 = 316
  컨텍스트 정보 = 316
 초기화와 실행 = 318
 값 설정하기 = 319
 올바른 값 설정하기 = 320
 설정 매개변수 결정법 = 322
14장 로그
 무슨 일이 일어나는지 알고 싶다 = 326
 충분한 데이터가 필요하다 = 328
 로그 포맷과 관리 = 330
  로그 포맷 = 330
  로그 관리 = 332
  로그 관련 표준과 라이브러리 = 334
 로그 데이터에 대한 후처리 = 334
 서비스에 대한 로그 남기기 = 335
15장 출시관리
 그렇다, 당신이 정말 필요로 하는 것은 이것이다 = 339
 기초 다지기 = 340
 출시본 관리 = 341
  당신이 출시하려는 것 = 341
  당신이 타깃으로 삼는 사람 = 342
  그들이 그것을 원하는 이유 = 343
 출시본 식별 = 343
  전체 또는 완전 출시본 = 344
  부분 출시본 = 346
  패치본 = 346
  변형본 = 349
 SKU(제품번호)와 시리얼넘버(일련번호) = 350
  SKU 관리 = 351
  시리얼넘버, 등록 그리고 활성화 = 353
 출시관리가 타키텍처에 미치는 영향 = 355
16장 보안
 바이러스, 해커, 무단사용자 = 360
  위험 관리 = 361
  나쁜 것은 보지도, 말하지도 마라 = 362
 디지털 신원 관리 = 363
  권한부여(누가 무엇을 할 수 있는지 정의하기) = 363
  신원확인(누구인지 확인하기) = 364
 트랜잭션 보안 = 367
  감사가능성(행위에 대한 증명) = 367
  무결성(데이터에 대한 위조와 변조 막기) = 368
  기밀성(권한 없는 사람들로부터 데이터를 보호하기) = 369
  책임성(사람들이 자신의 행동에 책임을 지게 만들기) = 370
 소프트웨어 보안 = 370
  소프트웨어 보안 기술 = 370
  소프트웨어 보안 비용/혜택 = 373
 정보 보안 = 374
 알고리즘을 비밀로 할까, 아니면 키를 비밀로 할까? = 375
 백도어 = 376
 보안과 마키텍처 = 378
  상호작용의 영역 = 378
부록 A 출시 체크리스트 
 정보 추적 = 385
 엔지니어링／개발 = 385
 품질 보증 = 385
 기술문서 = 386
 핵심 제품관리 = 386
 지식 이전: 전문가 서비스 = 386
 지식 이전: 세일즈와 채널 = 386
 지식 이전: 기술지원 = 387
 출시 활동 = 287
부록 B 전략적인 제품관리를 위한 패턴 랭귀지 
 패턴 적용 = 389
 결과 표시와 공유 = 391
 시장 지도 = 392
  내용 = 392
  문제 = 392
  요인 = 392
  해법 = 392
  결과 = 393
  관계된 패턴 = 393
 시장 이벤트/시장 리듬 = 394
  내용 = 394
  문제 = 394
  요인 = 394
  해법 = 394
  결과 = 395
  관계된 패턴 = 395
 기능／혜택 지도 = 396
  내용 = 396
  문제 = 396
  요인 = 396
  해법 = 396
  결과 = 397
  관계된 패턴 = 397
 타키텍처 로드맵 = 397
  내용 = 397
  문제 = 397
  요인 = 397
  해법 = 398
  결과 = 399
  관계된 패턴= 399
참고문헌 = 401
추천도서 = 403
찾아보기 = 406