추가 적립 안내

성공하는 솔루션을 위한 비즈니스와 아키텍쳐의 만남

『소프트웨어 아키텍처 2.0』는 현실에서 성공할 수 있는 아키텍처와 마케팅 정보를 어떻게 통합해야 하는지, 기술과 비즈니스 관점에서 날카롭게 지적하고 상세히 설명한다. 소프트웨어 전문가인 저자는 아키텍처에 관한 결정을 내릴 수 있도록 중요한 방향을 일러준다. 이 책은 실제로 도움이 되는 가이드라인을 제공한다.

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

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

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

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

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

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

추천의 글 Ⅰ

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

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

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

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

마틴 파울러

추천의 글 Ⅱ

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

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

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

이 책에 쏟아진 찬사

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

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

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

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

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

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

루크 호만은 제품개발에 관한 정수를 이 책에 표현했다. 그는 제품개발에 있어 마케팅과 엔지니어링 모두의 역할이 필요하

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

◈ 책 소개

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

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

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

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

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

◈ 이 책에 쏟아진 찬사

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

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

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

내가 읽은 책 중에 이처럼 소프트웨어 아키텍처의 사업적인 측면과 기술적인 측면에 대한 내부자의 관점을 모두 다루는 책은 없었다. 다는 사실을 조리 있게 설명할 뿐만 아니라, 그 둘을 함께 연결해 성공적인 제품을 개발하는 과정을 이해하고 실행할 수 있도록 만든다.
- 리 싱글러 / 360 마켓 뷰 사 회장

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

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

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

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

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

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

이 책을 강력하게 추천한다. 예전에 소프트웨어 회사의 CEO와 설립자로서 많은 소프트웨어 엔지니어와 함께 일했으며, 엔지니어링 분야를 책임지는 여러 VP와 함께했었다. 루크는 예전에도 최고였고 지금도 최고다. 그는 위대한 엔지니어일 뿐 아니라 좋은 코드와 아키텍처에 관한 결정을 내릴 때 반드시 관여해야 하는 전략적인 비즈니스 문제에 대해 날카로운 통찰력을 지녔다. 이 책은 소프트웨어 시스템을 구축하는 모든 사람의 필독서다.
- 케빈 리베트 / BCG 컨설팅 수석 고문, [Rembrandts In The Attic]의 저
소프트웨어 영업 관리자와 개발 관리자를 같은 장소로 불러모으는 훌륭한 책이다!
- 데이먼 셰스터 / 록 글로벌 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』의 저자

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

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

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

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

루크 호만의 뛰어난 책 [소프트웨어 아키텍처 2.0]은 아키텍트이자 비즈니스 리더로서 힘들게 획득한 귀중한 직관을 나눠준다. 그는 아키텍처가 단지 계층에 대해 논의하는 것만이 아님을 보여준다. 아키텍처는 시장, 비즈니스, 그리고 기술적 요인에 대한 이해를 바탕으로 성공하는 솔루션을 만드는 일이기 때문이다.
- 크레이그 라만
[Applying UML and Patterns: An Introduction to OOA&D and the Rational Unified Process]의 저자

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

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

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

이 책은 내가 기술자에서 제품팀의 리더로 변신해서, 공부와 행동과 오류를 통해 배웠던 많은 교훈을 전해준다. 여전히 소프트웨어 개발과 경영 관리 사이에 존재하는 간극을 중재하려고 시도하는 사람에게 이 책은 훌륭한 안식처가 될 것이다. 이 책은 수없이 "오 예!"라고 외칠 만한 직관들로 가득하다. 내가 팀과 함께 새로운 제품을 만들고 개발하는 일을 계속하는 한 이 책을 지침서로, 그리고 교육 교재로 계속 사용할 것이다. 이 책은 '큰 그림'을 보여준다. 그리고 비용이 많이 드는 함정을 피하게 해준다. 제품개발자, 마케팅 관리자, 이 분야에 뜻을 둔 사람, 현재의 관리방식에 불만이 있는 사람이라면 호만의 책을 꼭 읽어야 한다.
- 토드 거빈 / 옵티뷰 사 대표
모험과 역학, 그리고 성공하는 솔루션을 이해하는 방법을 찾는 소프트웨어 아키텍트와 제품개발자의 필독서다.
- 마크 벨케 / 휴렛 팩커드 마케팅 매니저

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

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

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

◈ 추천의 글 Ⅰ

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

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

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

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

마틴 파울러

◈ 추천의 글 Ⅱ

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

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

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

가이 가와사키 / 개러지 테크놀러지 벤처스의 CEO

◈ 저자 서문

소프트웨어 아키텍처에 대한 훌륭한 책들이 이미 많이 출간됐다. 이 책들은 무엇보다 소프트웨어 아키텍처를 정의하고, 분류하고, 서술한다. 아키텍처를 표현하는 표기법을 정의하고, 그 내용에 대해 의견을 교환한다. 그리고 오래도록 가치를 유지할 수 있는 좋은 아키텍처를 선택할 수 있도록 가이드를 제공한다. 불행히도 이런 책들은 성공적인 아키텍처를 만드는 데는 도움이 될지 모르지만, 성공하는 솔루션을 만드는 데는 도움이 되지 않는다. 성공하는 솔루션을 만들려면, 서브시스템이나 인터페이스를 뛰어넘어야 한다. ‘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’이라고 표현되어 있다. 이 용어를 ‘대박 솔루션’이라고 번역하고 싶었다. 강렬한 어감이 끌리기는 했지만, 고차원적 종합예술인 소프트웨어 개발을 너무 생생한 시장경제적 차원으로 끌어내리는 것 같은 걱정이 들었다. 그래서 ‘성공하는 솔루션’이라는 서술적인 번역을 선택했다. 이 책은 마케팅 아키텍트(마키텍트)의 역할을 강조하고 있다. 마키텍트는 개발팀, 영업팀, 기획팀을 총괄하면서 제품을 성공시키고자 노력하는 사람이다. 마키텍트는 개발자 출신의 관리자일 수도 있고, 영업이나 기획 출신의 관리자일 수도 있다. 본질적으로 마키텍트는 시장과 기술을 모두 이해하는 종합예술인이다. 저자는 개발자이고, 그래서 개발자가 대접받는 환경을 강렬하게 원한다. 이 책은 시장에서 성공하지 못하는 솔루션은 제아무리 기술적인 도달 수준이 높다 하더
라도, ‘성공하는 솔루션’이 아니라고 정의한다. 그래서 개발자에게 시장에 대한 관심을 촉구한다. 개발자가 대접받는 환경도 궁극적으로는 개발팀과 영업팀과 기획팀이 합심해서 성공하는 솔루션을 많이 만들어야 이룰 수 있다고 생각한다. 대한민국에 성공 솔루션과 서비스가 많이 나오기를 기원한다.

1장 소프트웨어 아키텍처
소프트웨어 아키텍처의 정의
소프트웨어 아키텍처를 보는 또 다른 관점
서브시스템은 의존성을 관리할 수 있도록 디자인한다
서브시스템은 인간적인 동기와 욕구를 충족시킬 수 있도록 디자인한다
훌륭한 아키텍처에 승복하라
아름다움은 그것을 추구하는 사람의 눈 안에 있다!
소프트웨어 아키텍처가 중요한 이유
수명
안정성
수정 작업의 난이도와 성격
수익성
사회적 구조
영역 결정
지속 가능한, 우월한 경쟁력
아키텍처 만들기
패턴과 아키텍처
아키텍처의 발전과 성숙: 기능과 수용력
아키텍처에 대한 관심과 육성
기술적 자산
기술적 부채
알고 있는 버그
라이선스 협약 준수
제1, 제2, 제3의 원칙
캡슐화
인터페이스
느슨한 연결
적절한 규모
높은 응집력
매개변수
지연
아키텍처의 이해
팀

2장 제품개발 첫걸음
제품관리의 정의
제품관리의 중요성
제품개발 프로세스: 릴리즈 1.0 만들기
개념제안서
제품제안서/사업계획서
개발계획서
개발
최종 품질보증QA
출시준비
출시
오해하지 말자
폭포수 프로세스를 닮았다. 그런데 폭포수 프로세스는 효과적이지 않다
모든 단계가 동등하게 중요한 것처럼 소개하고 있다
시간을 상술하지 않고 있다
어떻게 반복하나?
개발 프로세스를 정하지 않고 있다
진행 단계별로 관련된 그룹 사이의 협업 수준을 명시하지 않고 있다
사업계획서
제품개발 프로세스: 릴리즈 버전 n.n.n 만들기
제품개발 프로세스의 확장
지속적인 마감
변화관리 프로토콜
재활용 상자
주요 제품관리 개념
마케팅의 4P
총 유효 시장, 총 접근가능 시장, 시장 세그먼트
S자 제품 채택 곡선
완전제품
기술 우월성과 시장 우월성
포지션과 포지셔닝
브랜드
메인 메시지

3장 마키텍처와 타키텍처의 차이점
누가 무엇을 책임지는가?
솔루션 개발 초기에 영향을 주는 요인
미래를 보는 안목으로 현실에서 성과 만들기
미래 계획하기
피드백 이용하기
분명하게 만들기
협력하며 일하기
합의에 이르기
데이터 공유하기
컨텍스트 다이어그램과 타깃 제품

4장 비즈니스 모델과 라이선스 모델의 공생
일반적인 소프트웨어 비즈니스 모델
접근이나 이용기간 제한
트랜잭션
미터링
하드웨어
서비스
매출증가/비용절감
비즈니스 모델과 연관된 권리
비즈니스 모델을 위한 타키텍처의 지원
일반적인 문제
접근이나 이용기간 제한
트랜잭션
미터링
하드웨어
라이선스 모델 강제하기
명예 시스템
직접 만든 라이선스 관리자
서드파티 또는 전문 라이선스 관리자
클라이언트
시장의 성숙도가 비즈니스 모델에 미치는 영향
비즈니스 모델 선택

5장 기술 도입
라이선스 도입의 위험/보상
계약서―액션(행동지침)이 있는 곳
계약서의 기초
라이선스 약정
비즈니스 모델이 충돌하면, 협상을 해야 한다
라이선스 협정서 존중
라이선스 도입한 기술 관리
오픈 소스 라이선스 도입
라이선스 비용
라이선스 도입의 경제학

6장 이식성
알려진 이식성의 장점
이식성에 관한 제안
이식 가능한 애플리케이션 만들기
인터프리터 언어를 사용하라
표준에 기반한 영구 스토리지를 사용하라
비즈니스 로직을 이식 가능하게 만들라
사용자에게 가까울수록 이식성이 떨어진다
표준화되고 공동 사용 가능한 서브시스템 간의 통신에는 XML을 사용하라
이식성이란 명목으로 특정 플랫폼에 한정적인 우수한 기능을 감추지 마라
난이도 도표
1단계: 실행환경 지우기
2단계: 실행환경 정렬하기
3단계: 최종본 만들기
조심해서 약속하라

7장 배치 아키텍처
배치 방식
고객 사이트 방식
ASP 방식
MSP 방식
트랜잭션 방식(웹 서비스)
고객이 배치 아키텍처에 미치는 영향
통제와 통합
데이터 보안/프라이버시와 최고 부하
비용과 업체에 대한 신뢰
고객의 역량과 경험 그리고 지리적 분포
회사가 배치 아키텍처에 미치는 영향
세일즈 사이클
인프라에 대한 투자
현금 흐름
유연성
지리적 분포
가격이 아닌, 서비스
소프트웨어 배치 아키텍처의 선택
배치 아키텍처와 작업 배분
정보기기
배포 방식이 소프트웨어 아키텍처에 미치는 영향
유연한, 파라미터에 의한 통합 옵션, 또는 통합 옵션이 없는 경우
업그레이드 정책
데이터 보호와 접근
이전 옵션
소비자 소프트웨어의 미래

8장 통합과 확장
사용자의 지배력―주도하는 힘
통합/확장의 이유
계층적인 비즈니스 아키텍처: 논리적인 구조
사용자 인터페이스 계층
서비스 계층
도메인 모델 계층
퍼시스턴트 데이터 계층
주제에 의한 변주
계층적인 비즈니스 아키텍처 만들기
비즈니스 로직 계층에서의 통합과 확장
기술, 그리고 제어권의 소재
API를 통한 통합
등록을 통한 확장
퍼시스턴트 데이터의 통합과 확장
뷰
사용자 필드
후크 테이블
스프레드시트 피벗 테이블
추출, 변환, 로드 스크립트
고객에게 현실을 공개하라
비즈니스 파생물
전문가 서비스
교육 프로그램
자격증
사용자 커뮤니티
라이선스 협약
여러 출시에 걸쳐 API를 관리하기
API 관리 테크닉

9장 브랜드와 브랜드 요소
브랜드 요소
브랜드 네임
그래픽, 슬로건, 기타 브랜드 요소
언제 트레이드마크(™) 심볼을 사용하나
라이선스 도입한 브랜드의 관리
브랜드 요소 수정 및 맞춤
브랜드 요소 바꾸기
변경해야 할 제품 영역
QA와 변경

10장 사용성
사용성은 돈에 관한 문제다
멘탈 모델, 메타포 그리고 사용성
타키텍처가 사용자 인터페이스 디자인에 미치는 영향
영향을 미치는 범위
속도에 대한 욕구
우리가 이야기할 것을 분명하게 정하자
마키텍트가 진정으로 원하는 것
사용자에게 응답하기
성능 그리고 타키텍처의 효과

11장 설치
OOBE
아야! 그건 아프다고
고객의 공포
설치와 아키텍처
원인과 선택
설치 방법
설치 관련 데이터 수집과 전제 조건 검사하기
설치하기
설치 이후 확인하기
마지막 손길
사용자는 매뉴얼을 읽지 않는다
설치와 삭제를 테스트하라

12장 업그레이드
설치와 비슷하다. 단지 더 나쁠 뿐이다
업그레이드에 대한 공포
업그레이드의 고통을 줄이는 방법
고통 없는 업그레이드를 위한 선택
시장 성숙도와 업그레이드

13장 설정
설정용이성(사용성의 한 요소)
시스템 컨텍스트
컨텍스트 정보
초기화와 실행
값 설정하기
올바른 값 설정하기
설정 매개변수 결정법

14장 로그
무슨 일이 일어나는지 알고 싶다
충분한 데이터가 필요하다
로그 포맷과 관리
로그 포맷
로그 관리
로그 관련 표준과 라이브러리
로그 데이터에 대한 후처리
서비스에 대한 로그 남기기

15장 출시관리
그렇다, 당신이 정말 필요로 하는 것은 이것이다
기초 다지기
출시본 관리
당신이 출시하려는 것
당신이 타깃으로 삼는 사람
그들이 그것을 원하는 이유
출시본 식별
전체 또는 완전 출시본
부분 출시본
패치본
변형본
SKU(제품번호)와 시리얼넘버(일련번호)
SKU 관리
시리얼넘버, 등록 그리고 활성화
출시관리가 타키텍처에 미치는 영향

16장 보안
바이러스, 해커, 무단사용자
위험 관리
나쁜 것은 보지도, 말하지도 마라
디

1장 소프트웨어 아키텍처
소프트웨어 아키텍처의 정의
소프트웨어 아키텍처를 보는 또 다른 관점
서브시스템은 의존성을 관리할 수 있도록 디자인한다
서브시스템은 인간적인 동기와 욕구를 충족시킬 수 있도록 디자인한다
훌륭한 아키텍처에 승복하라
아름다움은 그것을 추구하는 사람의 눈 안에 있다!
소프트웨어 아키텍처가 중요한 이유
수명
안정성
수정 작업의 난이도와 성격
수익성
사회적 구조
영역 결정
지속 가능한, 우월한 경쟁력
아키텍처 만들기
패턴과 아키텍처
아키텍처의 발전과 성숙: 기능과 수용력
아키텍처에 대한 관심과 육성
기술적 자산
기술적 부채
알고 있는 버그
라이선스 협약 준수
제1, 제2, 제3의 원칙
캡슐화
인터페이스
느슨한 연결
적절한 규모
높은 응집력
매개변수
지연
아키텍처의 이해
팀

2장 제품개발 첫걸음
제품관리의 정의
제품관리의 중요성
제품개발 프로세스: 릴리즈 1.0 만들기
개념제안서
제품제안서/사업계획서
개발계획서
개발
최종 품질보증QA
출시준비
출시
오해하지 말자
폭포수 프로세스를 닮았다. 그런데 폭포수 프로세스는 효과적이지 않다
모든 단계가 동등하게 중요한 것처럼 소개하고 있다
시간을 상술하지 않고 있다
어떻게 반복하나?
개발 프로세스를 정하지 않고 있다
진행 단계별로 관련된 그룹 사이의 협업 수준을 명시하지 않고 있다
사업계획서
제품개발 프로세스: 릴리즈 버전 n.n.n 만들기
제품개발 프로세스의 확장
지속적인 마감
변화관리 프로토콜
재활용 상자
주요 제품관리 개념
마케팅의 4P
총 유효 시장, 총 접근가능 시장, 시장 세그먼트
S자 제품 채택 곡선
완전제품
기술 우월성과 시장 우월성
포지션과 포지셔닝
브랜드
메인 메시지

3장 마키텍처와 타키텍처의 차이점
누가 무엇을 책임지는가?
솔루션 개발 초기에 영향을 주는 요인
미래를 보는 안목으로 현실에서 성과 만들기
미래 계획하기
피드백 이용하기
분명하게 만들기
협력하며 일하기
합의에 이르기
데이터 공유하기
컨텍스트 다이어그램과 타깃 제품

4장 비즈니스 모델과 라이선스 모델의 공생
일반적인 소프트웨어 비즈니스 모델
접근이나 이용기간 제한
트랜잭션
미터링
하드웨어
서비스
매출증가/비용절감
비즈니스 모델과 연관된 권리
비즈니스 모델을 위한 타키텍처의 지원
일반적인 문제
접근이나 이용기간 제한
트랜잭션
미터링
하드웨어
라이선스 모델 강제하기
명예 시스템
직접 만든 라이선스 관리자
서드파티 또는 전문 라이선스 관리자
클라이언트
시장의 성숙도가 비즈니스 모델에 미치는 영향
비즈니스 모델 선택

5장 기술 도입
라이선스 도입의 위험/보상
계약서―액션(행동지침)이 있는 곳
계약서의 기초
라이선스 약정
비즈니스 모델이 충돌하면, 협상을 해야 한다
라이선스 협정서 존중
라이선스 도입한 기술 관리
오픈 소스 라이선스 도입
라이선스 비용
라이선스 도입의 경제학

6장 이식성
알려진 이식성의 장점
이식성에 관한 제안
이식 가능한 애플리케이션 만들기
인터프리터 언어를 사용하라
표준에 기반한 영구 스토리지를 사용하라
비즈니스 로직을 이식 가능하게 만들라
사용자에게 가까울수록 이식성이 떨어진다
표준화되고 공동 사용 가능한 서브시스템 간의 통신에는 XML을 사용하라
이식성이란 명목으로 특정 플랫폼에 한정적인 우수한 기능을 감추지 마라
난이도 도표지털 신원 관리
권한부여(누가 무엇을 할 수 있는지 정의하기)
신원확인(누구인지 확인하기)
트랜잭션 보안
감사가능성(행위에 대한 증명)
무결성(데이터에 대한 위조와 변조 막기)
기밀성(권한 없는 사람들로부터 데이터를 보호하기)
책임성(사람들이 자신의 행동에 책임을 지게 만들기)
소프트웨어 보안
소프트웨어 보안 기술
소프트웨어 보안 비용/혜택
정보 보안
알고리즘을 비밀로 할까, 아니면 키를 비밀로 할까?
백도어
보안과 마키텍처
상호작용의 영역

부록 A 출시 체크리스트
정보 추적
엔지니어링/개발
품질 보증
기술문서
핵심 제품관리
지식 이전: 전문가 서비스
지식 이전: 세일즈와 채널
지식 이전: 기술지원
출시 활동

부록 B 전략적인 제품관리를 위한 패턴 랭귀지
패턴 적용
결과 표시와 공유
시장 지도
내용
문제
요인
해법
결과
관계된 패턴
시장 이벤트/시장 리듬
내용
문제
요인
해법
결과
관계된 패턴
기능/혜택 지도
내용
문제
요인
해법
결과
관계된 패턴
타키텍처 로드맵
내용
문제
요인
해법
결과
관계된 패턴


1단계: 실행환경 지우기
2단계: 실행환경 정렬하기
3단계: 최종본 만들기
조심해서 약속하라

7장 배치 아키텍처
배치 방식
고객 사이트 방식
ASP 방식
MSP 방식
트랜잭션 방식(웹 서비스)
고객이 배치 아키텍처에 미치는 영향
통제와 통합
데이터 보안/프라이버시와 최고 부하
비용과 업체에 대한 신뢰
고객의 역량과 경험 그리고 지리적 분포
회사가 배치 아키텍처에 미치는 영향
세일즈 사이클
인프라에 대한 투자
현금 흐름
유연성
지리적 분포
가격이 아닌, 서비스
소프트웨어 배치 아키텍처의 선택
배치 아키텍처와 작업 배분
정보기기
배포 방식이 소프트웨어 아키텍처에 미치는 영향
유연한, 파라미터에 의한 통합 옵션, 또는 통합 옵션이 없는 경우
업그레이드 정책
데이터 보호와 접근
이전 옵션
소비자 소프트웨어의 미래

8장 통합과 확장
사용자의 지배력―주도하는 힘
통합/확장의 이유
계층적인 비즈니스 아키텍처: 논리적인 구조
사용자 인터페이스 계층
서비스 계층
도메인 모델 계층
퍼시스턴트 데이터 계층
주제에 의한 변주
계층적인 비즈니스 아키텍처 만들기
비즈니스 로직 계층에서의 통합과 확장
기술, 그리고 제어권의 소재
API를 통한 통합
등록을 통한 확장
퍼시스턴트 데이터의 통합과 확장
뷰
사용자 필드
후크 테이블
스프레드시트 피벗 테이블
추출, 변환, 로드 스크립트
고객에게 현실을 공개하라
비즈니스 파생물
전문가 서비스
교육 프로그램
자격증
사용자 커뮤니티
라이선스 협약
여러 출시에 걸쳐 API를 관리하기
API 관리 테크닉

9장 브랜드와 브랜드 요소
브랜드 요소
브랜드 네임
그래픽, 슬로건, 기타 브랜드 요소
언제 트레이드마크(™) 심볼을 사용하나
라이선스 도입한 브랜드의 관리
브랜드 요소 수정 및 맞춤
브랜드 요소 바꾸기
변경해야 할 제품 영역
QA와 변경

10장 사용성
사용성은 돈에 관한 문제다
멘탈 모델, 메타포 그리고 사용성
타키텍처가 사용자 인터페이스 디자인에 미치는 영향
영향을 미치는 범위
속도에 대한 욕구
우리가 이야기할 것을 분명하게 정하자
마키텍트가 진정으로 원하는 것
사용자에게 응답하기
성능 그리고 타키텍처의 효과

11장 설치
OOBE
아야! 그건 아프다고
고객의 공포
설치와 아키텍처
원인과 선택
설치 방법
설치 관련 데이터 수집과 전제 조건 검사하기
설치하기
설치 이후 확인하기
마지막 손길
사용자는 매뉴얼을 읽지 않는다
설치와 삭제를 테스트하라

12장 업그레이드
설치와 비슷하다. 단지 더 나쁠 뿐이다
업그레이드에 대한 공포
업그레이드의 고통을 줄이는 방법
고통 없는 업그레이드를 위한 선택
시장 성숙도와 업그레이드

13장 설정
설정용이성(사용성의 한 요소)
시스템 컨텍스트
컨텍스트 정보
초기화와 실행
값 설정하기
올바른 값 설정하기
설정 매개변수 결정법

14장 로그
무슨 일이 일어나는지 알고 싶다
충분한 데이터가 필요하다
로그 포맷과 관리
로그 포맷
로그 관리
로그 관련 표준과 라이브러리
로그 데이터에 대한 후처리
서비스에 대한 로그 남기기

15장 출시관리
그렇다, 당신이 정말 필요로 하는 것은 이것이다
기초 다지기
출시본 관리
당신이 출시하려는 것
당신이 타깃으로 삼는 사람
그들이 그것을 원하는 이유

출시본 식별
전체 또는 완전 출시본
부분 출시본
패치본
변형본
SKU(제품번호)와 시리얼넘버(일련번호)
SKU 관리
시리얼넘버, 등록 그리고 활성화
출시관리가 타키텍처에 미치는 영향

16장 보안
바이러스, 해커, 무단사용자
위험 관리
나쁜 것은 보지도, 말하지도 마라
디지털 신원 관리
권한부여(누가 무엇을 할 수 있는지 정의하기)
신원확인(누구인지 확인하기)
트랜잭션 보안
감사가능성(행위에 대한 증명)
무결성(데이터에 대한 위조와 변조 막기)
기밀성(권한 없는 사람들로부터 데이터를 보호하기)
책임성(사람들이 자신의 행동에 책임을 지게 만들기)
소프트웨어 보안
소프트웨어 보안 기술
소프트웨어 보안 비용/혜택
정보 보안
알고리즘을 비밀로 할까, 아니면 키를 비밀로 할까?
백도어
보안과 마키텍처
상호작용의 영역

부록 A 출시 체크리스트
정보 추적
엔지니어링/개발
품질 보증
기술문서
핵심 제품관리
지식 이전: 전문가 서비스
지식 이전: 세일즈와 채널
지식 이전: 기술지원
출시 활동

부록 B 전략적인 제품관리를 위한 패턴 랭귀지
패턴 적용
결과 표시와 공유
시장 지도
내용
문제
요인
해법
결과
관계된 패턴
시장 이벤트/시장 리듬
내용
문제
요인
해법
결과
관계된 패턴
기능/혜택 지도
내용
문제
요인
해법
결과
관계된 패턴
타키텍처 로드맵
내용
문제
요인
해법
결과
관계된 패턴

소프트웨어 아키텍처에 대한 훌륭한 책들이 이미 많이 출간됐다. 이 책들은 무엇보다 소프트웨어 아키텍처를 정의하고, 분류하고, 서술한다. 아키텍처를 표현하는 표기법을 정의하고, 그 내용에 대해 의견을 교환한다. 그리고 오래도록 가치를 유지할 수 있는 좋은 아키텍처를 선택할 수 있도록 가이드를 제공한다. 불행히도 이런 책들은 성공적인 아키텍처를 만드는 데는 도움이 될지 모르지만, 성공하는 솔루션을 만드는 데는 도움이 되지 않는다. 성공하는 솔루션을 만들려면, 서브시스템이나 인터페이스를 뛰어넘어야 한다. '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'이라고 표현되어 있다. 이 용어를 '대박 솔루션'이라고 번역하고 싶었다. 강렬한 어감이 끌리기는 했지만, 고차원적 종합예술인 소프트웨어 개발을 너무 생생한 시장경제적 차원으로 끌어내리는 것 같은 걱정이 들었다. 그래서 '성공하는 솔루션'이라는 서술적인 번역을 선택했다. 이 책은 마케팅 아키텍트(마키텍트)의 역할을 강조하고 있다. 마키텍트는 개발팀, 영업팀, 기획팀을 총괄하면서 제품을 성공시키고자 노력하는 사람이다. 마키텍트는 개발자 출신의 관리자일 수도 있고, 영업이나 기획 출신의 관리자일 수도 있다. 본질적으로 마키텍트는 시장과 기술을 모두 이해하는 종합예술인이다. 저자는 개발자이고, 그래서 개발자가 대접받는 환경을 강렬하게 원한다. 이 책은 시장에서 성공하지 못하는 솔루션은 제아무리 기술적인 도달 수준이 높다 하더라도, '성공하는 솔루션'이 아니라고 정의한다. 그래서 개발자에게 시장에 대한 관심을 촉구한다. 개발자가 대접받는 환경도 궁극적으로는 개발팀과 영업팀과 기획팀이 합심해서 성공하는 솔루션을 많이 만들어야 이룰 수 있다고 생각한다. 대한민국에 성공 솔루션과 서비스가 많이 나오기를 기원한다.
(/ 옮긴이의 말 중에서)