올바른 아키텍처를 선택하거나 수립했는지를 평가하는 데 활용할 수 있는 ATAM 등 평가 기법을 소개하고 이를 기반으로 아키텍처 평가를 수행하는 데 실질적인 절차와 지침을 제공하는 소프트웨어 아키텍트의 필독서.


[ 소개 ]

아키텍처 평가를 수행하는 데 유용한 세 가지 최신 평가방법에 대한 실질적인 지침을 제공하는 책으로서, 실무자에게 유용할 뿐만 아니라 아키텍처 평가 발전의 기반으로도 그 가치를 인정받을 것이다.


성공적인 제품의 개발과 발전은 올바른 아키텍처를 선택하느냐에 달렸다. 아키텍처 선택이 이렇게 중요하다는 사실을 안다면 아키텍처를 제대로 파악하거나 평가해야겠다는 생각이 절로 들 것이다.


소프트웨어 엔지니어의 책장에 꼭 있어야 할 필독서

이 책에서는 아키텍처 설계 의사결정과 그 결과인 소프트웨어 자산 간에 명확하게 파악된 연결관계를 그려내기 위해 소프트웨어 아키텍처 평가방법과 이를 실제 적용한 사례를 설명한다. 이 방법은 아키텍처 평가에 개발 일정(대개 며칠 이내)을 좀 더 늘리거나 비용을 추가하는 것만으로도 실제로 위험을 감소시킬 수 있다는 사실을 보여준다. 또한 아키텍처 평가에 대한 개념적인 배경 소개와 많은 정부기관과 업계에서 실제 수행됐던 내용을 기반으로 한 단계적 가이드도 제공한다.

특히 다음 세 가지 주요 평가방법을 설명한다.
■ 아키텍처 트레이드오프 분석방법 (ATAM)
■ 소프트웨어 아키텍처 분석방법 (SAAM)
■ 중간설계에 대한 능동적 검토 (ARID)

이 책에서 다룬 상세한 사례연구를 통해 평가방법을 실제 시스템에 적용했을 때의 가치를 보여주며, 보충설명을 통해 이 책의 전반에 걸쳐 어려운 상황에서 도출된 실제 팁과 흥미로운 뒷이야기를 제공한다.

소프트웨어 엔지니어라면 어떻게 소프트웨어 아키텍처 평가를 수행하는지를 반드시 알아야 한다. 이 책을 읽으면 아키텍처 평가에 대해 정리된 경험담을 통해 좀 더 쉽게 익힐 수 있을 것이다.


[ 이 책의 구성 ]

이 책을 읽는 독자는 아키텍처 이슈에는 능통하지만 아키텍처 평가는 실무 경험이 없다고 가정한다. 이 책은 다음과 같은 주제를 다룬다.

● 1장은 이 책에서 사용되는 공통적인 개념의 시작점을 잡고 용어를 정립하기 위해 소프트웨어 아키텍처의 주제를 간단히 소개한다.

● 2장은 소프트웨어 아키텍처 평가를 설명할 수 있는 기반을 마련한다. 아키텍처 평가를 하는 이유와 시점, 참여자, 비용과 이점 및 평가에서 어떤 실질적인 결과를 기대할 수 있을지를 논의한다.

● 3장은 이 책에서 설명할 방법 중 첫 번째며 가장 자세하게 다룬 아키텍처 트레이드오프 분석방법(ATAM)을 소개한다. 또한 ATAM의 주요단계와 세부단계를 설명한다.

● 4장은 ATAM을 실제 시스템에 적용한 짧은 사례연구로서, 이를 통해 앞 장에서 배운 세부단계가 적용된 모습을 간략히 볼 수 있다.

● 5장은 ATAM에 깔린 기본 개념과 관련된 소프트웨어 아키텍처 평가방법을 소개한다. 여기에는 품질속성 특징화와 분석 질문과의 관계, 그리고 속성 기반의 아키텍처 스타일(ABAS) 등이 있다.

● 6장은 미 항공 우주국(NASA)에서 운영되는 시스템에 적용된 ATAM을 자세하고 심층적으로 소개한다. 이 사례연구는 4장에서 설명한 방법의 세부단계와 유사하지만, 실무적이고 상세한 내용에 집중하고 있으며 경험 기반의 지침(즉 계획대로 진행되지 않을 때 무엇을 할지 등)을 제공한다.

● 7장은 변경용이성(그리고 이에 관련된 이식용이성, 확장용이성, 유지보수성 등)과 기능성 면에서 아키텍처를 평가하는 데 특화된 방법인 소프트웨어 아키텍처 분석방법(SAAM)을 소개한다. SAAM을 적용한 검증된 사례연구도 살펴본다.

● 8장은 아키텍처의 한 부분으로 제공되는 실행가능성과 적합성을 시험하는 방법인 중간설계에 대한 능동적 검토(ARID)를 제공한다. ARID는 부분적인 설계를 평가하는 데 유용하다. 여기에도 ARID를 적용한 사례연구를 담았다.

● 9장은 ATAM, SAAM, ARID와 그 밖의 여러 아키텍처 평가방법을 광범위하게 비교해본다.

● 10장은 조직 차원에서 제도화된 아키텍처 기반 소프트웨어 개발로 변화해가는 데 중요한 단계인 지속적인 아키텍처 평가 역량의 증대에 대해 이야기한다.

● 11장은 결론과 마무리 부분으로서 내용을 정리한다.


[ 이 책의 대상 독자 ]

이 책은 아키텍처 평가자에게 직접 이야기하는 형식으로 썼지만 고객과 프로젝트 대표자(특히 아키텍트)도 이 책을 읽음으로써 아키텍처 평가 프로세스가 무엇인지를 배울 수 있다. 특히 이 책은 다음과 같은 네 종류의 독자를 염두에 뒀다.

● 평가자: 아키텍처 평가팀을 이끌거나 팀에 지원할 예정인 사람. 신입 평가자는 모든 장을 주의 깊게 읽어야 한다. 경력을 쌓은 평가자는 평가방법(3장, 7장, 8장)을 설명한 장과 품질속성에 깔린 개념(5장)에 집중해야 한다.

● 고객: 아키텍처 평가를 의뢰할 예정이어서 아키텍처 평가에 어떤 내용이 포함되는지를 배우고자 하는 사람. 고객은 1장과 2장을 중점적으로 읽는다. 고객 입장에서 어떤 방법이 프로젝트에 가장 적합한지에 대한 확신이 없다면 평가방법을 소개하는 3장, 7장, 8장은 대략 훑으면 된다. 평가방법을 선택하는 데 도움이 되는 9장을 먼저 읽고 적합한 방법을 다루는 이전 장을 주의 깊게 다시 읽는 것도 한 방법이다.

● 프로젝트 구성원: 아키텍처 평가를 받아야 하는 프로젝트 대표자(아키텍트, 관리자, 기타 프로젝트 구성원)는 평가를 통해 무엇을 기대할지를 배우기 바랄 것이다. 프로젝트 구성원은 1장과 2장을 가볍게라도 읽어야 한다. 다음에는 프로젝트에 사용될 방법을 정의하는 장(3장, 7장, 8장)을 읽어야 한다. 그 다음에는 해당 방법을 적용한 사례연구를 담은 장을 읽는다. 4장, 6장에 ATAM에 대한 사례연구가 포함돼 있다. 아키텍트는 자신이 만든 창작물이 평가를 받게 되는 특별한 프로젝트 구성원이다. ATAM을 사용한다면 아키텍트는 앞에 언급한 장에 덧붙여 5장도 읽어야 한다.

● 평가부서 관리자: 조직 내에 아키텍처 평가 역량을 키우고 싶은 사람은 전체 장의 내용을 잘 알아야 하지만 특히 10장을 잘 알아야 한다. 4장, 6장, 7장, 8장에 있는 사례연구는 팀에서 시범으로 평가를 수행하는 데 참조 자료로 사용할 수 있다.

[ 한국어판 특별 서문 ]

지난 15여년 간 소프트웨어 아키텍처에 대한 연구가 성장하고 성숙됨에 따라 소프트웨어 아키텍트들은 단순히 아키텍처만 수립하는 일을 넘어서 수많은 일에 기여한다는 사실이 매우 명확해졌다. 아키텍트는 설계자를 선도해주고, 새로운 기술을 도입하기 위한 계획을 수립하는 역할도 담당한다. 또한 조직의 경영목표를 구체화하는 데 참여하는 일에서부터 개발자와 테스터의 가이드 역할까지도 수행한다. 요약하면 아키텍트는 아키텍처를 올바로 이해하고 사용하는 데 필요한 모든 일이 제대로 돌아가게 하는 역할을 해야 한다.

아키텍트는 수많은 과업 중에서 무엇보다도, 설계한 아키텍처가 문제를 해결하는 데 올바른 것인지 최선을 다해야 한다. 즉 아키텍트는 아키텍처가 제대로 기능을 수행해내는가와 마찬가지로 성능과 보안, 가용성 등의 품질속성도 올바르게 달성됐는지를 파악하는 일이 중요하다.

이 책 『소프트웨어 아키텍처 평가』는 아키텍트가 이와 같은 업무 수행을 하는 데 도움을 주기 위해 집필한 책이다. 한국어판이 출간된다고 하니 기쁜 마음을 형언할 길 없다. 아무쪼록 이 책이 역동적으로 발전하고 있는 한국의 소프트웨어 산업에 큰 보탬이 되기를 기원한다. 아울러 우리가 이 책을 쓸 때의 환희와 즐거움을 한국의 독자들도 느끼게 되길 바란다.


[ 저자 서문 ]

소프트웨어 시스템의 토대는 아키텍처에 있다. 이는 소프트웨어 시스템이 개별적으로 개발된 구성요소들로 구축되며 이 구성요소 간에 상호작용하는 방식에 기반을 둔다는 사실을 의미한다. 어떤 시스템을 구축하더라도 한 명 이상이 참여하는 규모라면 아키텍처를 기반으로 한 구성원 간의 의사소통과 작업 할당에 대한 조율이 필요하다. 요구사항 중에 성능, 보안, 신뢰성, 유지보수성에 대한 목표가 있다면 아키텍처는 시스템이 어떻게 이 목표를 달성할 수 있을지를 최초로 표현하는 설계 산출물이 된다. 아키텍처는 개발 프로젝트의 구조를 결정하며 이는 프로젝트 문서화의 기반이 된다. 또한 아키텍처는 프로젝트에 참여한 신규인력이 가장 먼저 접하는 문서며, 유지보수 조직이 가장 먼저 파악해야 하는 첫 업무다. 일정, 예산과 작업계획 모두가 아키텍처를 중심으로 움직이게 된다. 따라서 고참이면서 가장 능력 있는 설계자가 아키텍처를 만들도록 요구된다.

시스템에 대한 변화의 압력 속에서 시스템의 수명을 어떻게 유지하는가는 전적으로 아키텍처에 달렸다. 3티어 아키텍처, 계층 아키텍처, 파이프 필터 아키텍처 같은 아키텍처 스타일은 일반화돼서 개발 커뮤니티에 널리 활용되고 있다. 이제는 점차 전사적인 목표를 달성하는 데 있어서 아키텍처의 가치와 중요성을 인식하고 있다. 아키텍처는 회사에 경쟁력을 제공하며 마치 금융자산과 같이 자산으로 축적될 수도 있다.

적합한 아키텍처는 성공의 첫걸음인 반면에 잘못된 아키텍처는 재난을 야기한다. 다음과 같은 중요한 질문을 고려해보자. 시스템의 아키텍처가 회사의 미래를 좌우한다고 할 때, 지금 적합한 아키텍처를 기반으로 개발하고 있다는 것을 어떻게 보장할 것인가?

아키텍처를 만드는 일이 점차 성숙돼가면서 아키텍처로 인해 만들어진 설계 의사결정과 이를 기반으로 구축된 시스템에서 도출된 품질과 특성 간에 의도하지 않았던 관련성을 식별할 수 있게 됐다. 이는 구축할 시스템에 부여된 목표와 요구사항 측면에서 아키텍처 의사결정을 분석하기 위해 아키텍처를 평가하는 게 가능하다는 의미다.

최근에는 시스템 개발에서 아키텍처가 필수적인 부분으로 여겨지고 있지만 아키텍처 평가는 거의 어떤 개발 프로세스에서도 표준으로 포함된 적이 없었다. 우리는 아키텍처 평가가 개발 프로세스에 포함돼야 한다고 믿으며 이 책을 통해 이러한 현실과의 차이점을 극복하는 데 도움을 주고자 한다.

아키텍처 평가가 실무적인 소프트웨어 공학 활동으로 인정돼야 하는 시점이 된 데는 다음 두 가지 이유가 있다. 첫째, 아키텍처는 개발 프로젝트에 있는 엄청나게 많은 위험을 가시화한다. 앞에서도 말했듯이 잘못된 아키텍처는 프로젝트에 재앙을 야기한다. 일반적으로 불확실성이 있는 경우에 위험완화 전략을 세우듯이 핵심적인 산출물을 평가하는 것은 좋은 판단이라고 할 수 있다. 둘째, 생각보다 훨씬 적은 비용으로도 아키텍처 평가를 수행할 수 있다. 이 책에서 설명하는 평가방법은 프로젝트 일정에 일주일 이내의 시간만 필요하며 간략화된 방식은 하루나 이틀 정도의 시간만 추가하면 된다. 따라서 아키텍처 평가는 매우 저렴한 보험 증서라고 할 수 있다. 미흡한 아키텍처로 인해 발생하는 비용에 비하면 적절한 소프트웨어 아키텍처 평가에 대한 비용은 충분히 정당화된다. 이 책은 지금까지 부족했던 아키텍처 평가를 수행하는 실무적인 방법을 개선하려는 목적으로 등장했다.

이 책은 아키텍처 평가 실무자(또는 실무자가 되기를 원하는 사람)를 위한 지침서다. 이 책에서는 평가에 필요한 개념적인 배경을 제공하고 있지만 그보다는 아키텍처 평가와 분석의 실무에 대한 단계적인 지침을 제공하는 것을 목적으로 한다. 아키텍처 평가방법을 실무에서 적용하기 위해 다음과 같은 실제 사용할 수 있는 샘플 산출물을 추가했다. 예를 들면, 프리젠테이션 템플릿, 시나리오, 수행 후 설문, 최종보고서 템플릿 등이다. 이는 이 책을 읽은 후에 자신이 속한 조직의 아키텍처에 평가방법을 적용할 수 있을 정도의 자신감을 느끼게 하는 것이 목적이다. 평가 중에 “다음에는 무엇을 하지?” 같은 질문에 답을 할 수 있도록 노력했다.

이 책은 평가자 관점에서 쓰였으나 평가에 참여하는 그 밖의 사람들(프로젝트 관리자, 아키텍트, 기타 이해관계자)도 이 책을 읽으면 아키텍처 평가에 대한 가치 있는 통찰을 얻을 수 있을 것이다. 이들도 자신의 제품이 어떻게 평가되는지와 평가 분류를 준수하면서 해당 제품을 좀 더 잘 만들지에 대해서 이해할 수 있게 된다. 마치 미리 시험 문제를 보고 점수를 잘 받는 것과 같지만, 이는 속임수가 아니라 뛰어난 관리와 공학적인 실무기법이라고 할 수 있다. 하지만 이 책에서 ‘당신’ 또는 ‘여러분’이라는 말을 사용할 때, 평가자만을 대상으로 이야기하고 있다는 사실을 주지하기 바란다.

이 책은 정부기관과 업계에서 실제 적용된 기법을 기반으로 한다. 대부분 방법은 SEI에 있는 저자들과 다른 전문가들이 개발했으며 고객과 협력사 시스템에 적용했다. 그 밖의 내용은 아키텍처 분석과 평가의 전문가들이 참여하는 워크숍을 개최해 얻었다. 다시 말해, 직접 수행하면서 배웠고 다른 사람들의 수행 경험을 통해서도 배웠다.

이 책은 훌륭한 아키텍트가 되는 방법을 알려주지 않으며 아키텍처의 이슈를 잘 이해할 수 있게 도와주지도 않는다. 여러분이 이미 실무 경험을 통해서 아키텍처를 확실히 이해하고 있다고 전제한다. 또한 개인적인 아키텍트의 업무 성과 평가나 프로젝트의 아키텍처 프로세스(또는 개발 프로세스)를 제시하는 것도 아니다. 이 책이 도와줄 수 있는 것은 다양하고 중요한 품질속성을 준수하는 아키텍처와 이를 기반으로 만들어질 미래 시스템을 어떻게 평가하는지를 보여주는 것이다.

마지막으로 소프트웨어 집약적 시스템에서 소프트웨어 아키텍처와 시스템 아키텍처에 대해 이야기할 필요가 있다. 이 책은 소프트웨어 아키텍처에 대한 평가를 다루지만 다음과 같은 질문을 자주 받게 된다. “단순히 소프트웨어에 대한 평가만이 아니라 시스템에 대한 아키텍처는 어떻게 평가해야 하나요? 시스템도 소프트웨어만큼이나 중요하잖아요.” 물론 맞는 말이다. 시스템 아키텍처도 소프트웨어 아키텍처와 유사한 종류의 구조와 분할에 대한 의사결정을 담고 있다. 게다가 시스템 아키텍처에는 하드웨어/소프트웨어 간의 절충과 컴퓨팅 및 네트워크 장비를 포함하고 있어서 소프트웨어 아키텍처의 범위를 벗어난다. 소프트웨어 아키텍처가 소프트웨어의 성패에 영향을 미치는 것처럼, 시스템 아키텍처는 시스템의 성패에 중요한 역할을 한다. 따라서 시스템 아키텍처도 소프트웨어 아키텍처와 마찬가지로 평가돼야 당연하다.

이 책에 소개된 방법들은 소프트웨어 아키텍처뿐만 아니라 시스템 아키텍처에도 동일하게 적용할 수 있다고 믿는다. 시스템의 변경용이성을 고려한다면 시스템의 생명주기 동안 변경하는 데 드는 비용을 측정하는 방법을 사용할 수 있다. 예를 들어 성능을 고려한다면 시스템과 소프트웨어에서 병목구간과 문제 영역을 찾아내는 방법을 사용할 수 있다.

시스템 아키텍처에도 적용될 수 있다면 왜 이 책을 ‘소프트웨어’ 아키텍처 평가라고 부르는가? 이는 이 평가방법이 소프트웨어 범위에서 생성되고, 만들어지고, 테스트되고, 성숙했기 때문이다. 따라서 이 책에서 아키텍처라고 말할 때는 소프트웨어를 접두어로 붙여서 이해해도 무방하다. 시스템을 접두어로 붙일 수도 있지만 이는 여러분이 얼마나 해당 방법이 시스템 아키텍처에 적용가능한지와 우리의 의도를 얼마나 확실하게 이해하는지에 달렸다.

마지막으로 여러분의 경험을 공유해주기를 바란다. 여러분이 어떤 부분을 잘 수행하고 있고 어떤 부분이 잘 안 되는지를 알고 싶다. 책을 쓴다는 것은 교훈을 공유할 기회이기도 하지만, 새로운 교훈을 모으는 중요한 기회이기도 하다.



[ 저자 소개 ]

폴 클레멘츠
현재 미 SEI 연구소에서 기술 분야의 수석 연구원이다. 『Software Product Lines: Practices and Patterns(소프트웨어 프로덕트 라인: 실무와 패턴)』(애디슨 웨슬리, 2002)과 『소프트웨어 아키텍처: 이론과 실제』(에이콘출판사, 2007)의 공동저자다.

릭 캐즈먼
미 SEI 연구소 기술 분야의 수석 연구원이자 하와이 대학의 교수이며 카네기 멜론 대학의 소프트웨어 연구원이다. 『소프트웨어 아키텍처: 이론과 실제』(에이콘출판사, 2007)의 공동저자다.

마크 클라인
미 SEI 연구소 기술 분야의 수석 연구원이다. 마크는 카네기 멜론 대학의 소프트웨어 공학 석사과정의 교수이며 『A Practitioner’s Handbook for Real-Time Analysis(실무자를 위한 실시간 분석 가이드)』(슈프링거, 1993)의 공동저자다.


[ 옮긴이의 말 ]

벌써 에이콘의 아키텍처 시리즈도 4번째에 접어들었습니다. 그동안 현장에서 아키텍처에 관한 관심도 매우 높아지고, 실제로 업종이나 규모에 따라서 다양한 형태의 아키텍처 부서를 두는 회사들도 늘어났습니다. 이런 주변여건의 개선에도 불구하고 현장에서 아쉬웠던 점은 아키텍처의 이해관계자인 고객, PM, 개발자들에게 소프트웨어 아키텍처가 구축 목표에 어떻게 부합하는지를 사전에 파악하고 공유하는 방법이 부족하다는 점이었습니다. 결국 아키텍처를 수립하는 데 들어간 노력과 시간에 대한 이점을 구체적으로 설명하기가 어렵다 보니 실질적인 아키텍처 활동에 대한 이해와 투자를 구하는 데는 아직 어려움이 많은 상황이라고 할 수 있습니다.

저희 역자들이 몸담은 시스템 통합SI 프로젝트를 살펴보면 대부분 특정 기술이나 독자적인 아키텍처를 기반으로 만들어진 상용 또는 오픈소스 솔루션을 이용하는 환경에서 아키텍처를 수립하게 됩니다. 이와 같은 다양한 구성요소를 활용해서 시스템을 구축하는 데 발생하는 위험요소와 해결방안을 조기에 파악하고 조치하는 일은 모두가 아는 프로젝트의 성공 요소입니다. 하지만 많은 경우 프로젝트의 일정이나 비용상의 문제로 이런 활동은 사전에 확보되기가 어렵고 프로젝트 종료 직전까지 개발자들의 엄청난 노력으로 문제가 발생할 때마다 해소하곤 합니다. 간신히 시스템을 오픈하고 나면 당연히 이렇게 작업한 대가는 두고두고 치르게 됩니다. 하지만 이런 상황을 다시 반복하게 되는 걸 보면 정말 어려운 문제임을 확신합니다.

이 책에서 소개한 아키텍처 평가는 소프트웨어 공학 관점에서 봤을 때 이러한 문제에 대해서 최적의 비용으로 최대의 효과를 보장하는 안전장치라고 할 수 있습니다. 일반적으로 아키텍처 평가라고 하면 아키텍처 설계 메커니즘을 복잡한 수학공식을 통해서 증명하는 것을 떠올리게 됩니다. 하지만 프로젝트 초기에 다양한 참여자들 간의 상충되는 요구사항을 토대로 프로젝트의 중요한 의사결정을 내려야 할 때 이를 효과적으로 조율하거나 침묵하는 다수 의견을 가시화해서 핵심 아키텍처 요구사항을 구체화하는 일이 좀 더 효과적인 아키텍처 평가 결과라는 게 역자들의 의견입니다.

이 책에서 제시하는 아키텍처 평가방법의 가장 중요한 효과는 핵심 요구사항을 도출하는 방안을 제시하고 아키텍처 설계 의사결정에 대해 고객과 프로젝트의 합의를 이끌어낸다는 점입니다. 따라서 아키텍처 평가가 일반적으로 아키텍처를 수립하는 데 부족한 참여, 공유, 개방이라는 요소를 효과적으로 보완한다고 할 수 있습니다. 하지만 이 책에서 설명한 평가방법들을 바로 적용하기는 쉽지 않으며 특히 평가에서 가장 중심이 되는 시나리오 작성은 상당한 경험과 노력이 필요합니다. 하지만 이 책에서는 저자들이 실제 현장에서 적용하면서 발생했던 다양한 문제점도 상세하게 설명해주고 있어서 많은 도움이 됩니다. 이 책을 읽는 독자들도 저희 역자들이 느낀 아키텍처 평가의 효과를 공감하고 특히, 평가되는 데에 대한 두려움을 느끼기보다는 아키텍트 혼자 고민하던 부분을 평가를 통해 공유할 수 있음에 안도감을 느낄 수 있기를 바랍니다.


[ 옮긴이 소개 ]

이석준
뉴사우스웨일스 대학원에서 정보공학을 전공했으며 삼성 SDS 아키텍처팀에서 소프트웨어 아키텍트로 활동하고 있다. SEI에서 소프트웨어 아키텍처 전문가 자격과 ATAM 평가자 자격을 수료했다. 참여한 다수 프로젝트에서 소프트웨어 아키텍처 수립 및 절차를 반영하는 데 많은 노력을 하고 있으며 이와 관련한 사내 과정의 집필과 강의를 맡고 있다. 『소프트웨어 아키텍처: 이론과 실제』(에이콘출판사, 2007)를 번역했다.

백창현
KAIST 전산학 석사출신으로 일찍이 전투기 파일럿을 꿈꾸다 항공 시뮬레이션에 빠져 소프트웨어 분야에 입문했다. 핸디소프트의 BPM/그룹웨어 개발과 벤처기업 이모션의 개발 경력을 거쳐 삼성 SDS IT 플랫폼 팀에서 차세대 시스템을 위한 엔터프라이즈 프레임워크 개발을 선도하고 있다. 제품/시스템 개발을 위한 최적화된 소프트웨어 설계가 주 관심 분야며, 소프트웨어 시스템 개발의 근간은 아키텍처라고 확신한다. 공저서로는 『1st 워크플로우』(시사컴퓨터, 2000), 역서로는 『소프트웨어로 승리하자』(학현사, 2004)가 있다.

박인수
숭실대에서 전산을 전공했으며 현재 삼성 SDS에서 소프트웨어 아키텍트로 활동하고 있다. 누구보다도 소프트웨어 아키텍처에 대한 애착이 있다고 자부하며, 실제 프로젝트에서 이상적인 소프트웨어 아키텍처를 적용하기 위해 노력한다. 훌륭한 아키텍처는 성공적인 시스템의 밑거름이 된다는 철학을 바탕으로, 설계에서 의도한 대로 시스템이 구현될 수 있을까에 대한 해답을 찾기 위한 연구에 매진 중이다. 개발자들이 희생을 강요당하지 않고 품질, 납기, 원가 모두를 만족하는 성공적인 소프트웨어 시스템을 구축할 수 있는 세상을 위해 늘 고민한다.

목차

• 1장 소프트웨어 아키텍처
  • 1.1 이해관계자 간 의사소통 수단으로서의 아키텍처
    • 1.1.1 | 아키텍처와 이해관계자에게 미치는 영향
    • 1.1.2 | 아키텍처 뷰
    • 1.1.3 | 아키텍처 설명 언어
  • 1.2 초기 설계 의사결정에 대한 방향선언으로서의 아키텍처
    • 1.2.1 | 아키텍처 스타일
  • 1.3 재사용가능하고 이전할 수 있는, 시스템 추상화로서의 아키텍처
  • 1.4 정리
  • 1.5 더 읽을거리
  • 1.6 생각해볼 문제
    
• 2장 소프트웨어 아키텍처 평가
  • 2.1 아키텍처 평가 이유
  • 2.2 아키텍처 평가 시점
  • 2.3 아키텍처 평가 참여자
  • 2.4 아키텍처 평가의 예상 결과
  • 2.5 아키텍처 평가대상 품질속성
  • 2.6 품질속성 분석의 모호성
  • 2.7 아키텍처 평가의 결과물
    • 2.7.1 | ATAM, SAAM, ARID의 결과물
    • 2.7.2 | ATAM만의 결과물
  • 2.8 아키텍처 평가 수행의 이점과 비용
  • 2.9 더 읽을거리
  • 2.10 생각해볼 문제
    
• 3장 ATAM - 아키텍처 평가방법
  • 3.1 ATAM 스텝의 요약
  • 3.2 ATAM 스텝 상세 설명
    • 3.2.1 | 스텝 1: ATAM 프리젠테이션
    • 3.2.2 | 스텝 2: 비즈니스 동인 프리젠테이션
    • 3.2.3 | 스텝 3: 아키텍처 프리젠테이션
    • 3.2.4 | 스텝 4: 아키텍처 접근방법 식별
    • 3.2.5 | 스텝 5: 품질속성 유틸리티 트리 작성
    • 3.2.6 | 스텝 6: 아키텍처 접근방법 분석
    • 3.2.7 | 스텝 7: 시나리오 브레인스토밍과 우선순위 결정
    • 3.2.8 | 스텝 8: 아키텍처 접근방법 분석
    • 3.2.9 | 스텝 9: 결과 프리젠테이션
  • 3.3 ATAM의 단계
    • 3.3.1 | 0단계 활동
    • 3.3.2 | 1단계 활동
    • 3.3.3 | 2단계 활동
    • 3.3.4 | 3단계 활동
  • 3.4 더 읽을거리
  • 3.5 생각해볼 문제
    
• 4장 전장통제 시스템 - ATAM을 적용한 첫 사례연구
  • 4.1 준비
  • 4.2 1단계
    • 4.2.1 | 스텝 1: ATAM 프리젠테이션
    • 4.2.2 | 스텝 2: 비즈니스 동인 프리젠테이션
    • 4.2.3 | 스텝 3: 아키텍처 프리젠테이션
    • 4.2.4 | 스텝 4: 아키텍처 접근방법 식별
    • 4.2.5 | 스텝 5: 품질속성 유틸리티 트리 작성
    • 4.2.6 | 스텝 6: 아키텍처 접근방법 분석
  • 4.3 2단계
    • 4.3.1 | 스텝 7: 시나리오 브레인스토밍과 우선순위 결정
    • 4.3.2 | 스텝 8: 아키텍처 접근방법 분석
    • 4.3.3 | 스텝 9: 결과 프리젠테이션
  • 4.4 BCS 평가의 결과
    • 4.4.1 | 문서화
    • 4.4.2 | 요구사항
    • 4.4.3 | 민감점과 절충점
    • 4.4.4 | 아키텍처 위험요소
  • 4.5 정리
  • 4.6 생각해볼 문제
    
• 5장 품질속성 이해
  • 5.1 품질속성 특징화
    • 5.1.1 | 성능
    • 5.1.2 | 가용성
    • 5.1.3 | 변경용이성
    • 5.1.4 | 품질속성 특징화 질문
  • 5.2 ATAM에서의 품질속성 특징화 사용
  • 5.3 속성 기반 아키텍처 스타일
  • 5.4 정리
  • 5.5 더 읽을거리
  • 5.6 생각해볼 문제
    
• 6장 ATAM 적용 사례연구
  • 6.1 배경 6.2 0단계: 제휴와 준비
    • 6.2.1 | 0단계, 스텝 1: ATAM 프리젠테이션
    • 6.2.2 | 0단계, 스텝 2: 후보 시스템 설명
    • 6.2.3 | 0단계, 스텝 3: ATAM의 진행 여부 결정
    • 6.2.4 | 0단계, 스텝 4: 업무내용 협의
    • 6.2.5 | 0단계, 스텝 5: 핵심 평가팀 구성
    • 6.2.6 | 0단계, 스텝 6: 평가팀 착수회의 개최
    • 6.2.7 | 0단계, 스텝 7: 1단계 준비
    • 6.2.8 | 0단계, 스텝 8: 아키텍처 검토
  • 6.3 1단계: 초기평가
    • 6.3.1 | 1단계, 스텝 1: ATAM 프리젠테이션
    • 6.3.2 | 1단계, 스텝 2: 비즈니스 동인 프리젠테이션
    • 6.3.3 | 1단계, 스텝 3: 아키텍처 프리젠테이션
    • 6.3.4 | 1단계, 스텝 4: 아키텍처 접근방법 식별
    • 6.3.5 | 1단계, 스텝 5: 품질속성 유틸리티 트리 작성
    • 6.3.6 | 1단계, 스텝 6: 아키텍처 접근방법 분석
  • 6.4 1단계와 2단계 사이의 공백기간
  • 6.5 2단계: 평가 완성
    • 6.5.1 | 2단계, 스텝 0: 2단계 준비
    • 6.5.2 | 2단계, 스텝 1~6
    • 6.5.3 | 2단계, 스텝 7: 시나리오 브레인스토밍과 우선순위 결정
    • 6.5.4 | 2단계, 스텝 8: 아키텍처 접근방법 분석
    • 6.5.5 | 2단계, 스텝 9: 결과 프리젠테이션
  • 6.6 3단계: 후속조치
    • 6.6.1 | 3단계, 스텝 1: 최종보고서 작성
    • 6.6.2 | 3단계, 스텝 2: 사후 개선회의 개최
    • 6.6.3 | 3단계, 스텝 3: 포트폴리오 구축과 산출물 저장소 갱신
  • 6.7 더 읽을거리
  • 6.8 생각해볼 문제
    
• 7장 SAAM을 이용한 예제 아키텍처 평가
  • 7.1 SAAM 개요
    • 7.1.1 | SAAM 평가를 위한 입력물
    • 7.1.2 | SAAM 평가의 결과물
  • 7.2 SAAM 평가의 스텝
    • 7.2.1 | 스텝 1: 시나리오 개발
    • 7.2.2 | 스텝 2: 아키텍처 설명
    • 7.2.3 | 스텝 3: 시나리오 분류와 우선순위 결정
    • 7.2.4 | 스텝 4: 간접 시나리오의 개별적인 평가
    • 7.2.5 | 스텝 5: 시나리오 상호작용 평가
    • 7.2.6 | 스텝 6: 평가 총괄 정리
  • 7.3 SAAM 의제 예시
  • 7.4 SAAM 사례연구
    • 7.4.1 | ATAT 시스템 개요
    • 7.4.2 | 스텝 1: 시나리오 개발, 첫 번째 반복
    • 7.4.3 | 스텝 2: 아키텍처 설명, 첫 번째 반복
    • 7.4.4 | 스텝 1: 시나리오 개발, 두 번째 반복
    • 7.4.5 | 스텝 2: 아키텍처 설명, 두 번째 반복
    • 7.4.6 | 스텝 3: 시나리오 분류와 우선순위 결정
    • 7.4.7 | 스텝 4: 간접 시나리오의 개별적인 평가
    • 7.4.8 | 스텝 5: 시나리오 상호작용 확인
    • 7.4.9 | 스텝 6: 평가 총괄 정리 - 결과와 권고사항
  • 7.5 정리
  • 7.6 더 읽을거리
  • 7.7 생각해볼 문제
    
• 8장 ARID - 부분적 아키텍처 평가방법
  • 8.1 능동적 설계검토
  • 8.2 ARID: ARD/ATAM 하이브리드
  • 8.3 ARID의 스텝
    • 8.3.1 | 1단계: 예행연습
    • 8.3.2 | 2단계: 검토
  • 8.4 ARID를 적용한 사례연구
    • 8.4.1 | 스텝의 수행
    • 8.4.2 | 활동 결과
  • 8.5 정리
  • 8.6 더 읽을거리
  • 8.7 생각해볼 문제
    
• 9장 소프트웨어 아키텍처 평가방법 비교
  • 9.1 질의기법
    • 9.1.1 | 설문지와 체크리스트
    • 9.1.2 | 시나리오와 시나리오 기반 방법
  • 9.2 측정기법
    • 9.2.1 | 측정지표
    • 9.2.2 | 시뮬레이션, 프로토타입, 실험
    • 9.2.3 | 비율단조 분석
    • 9.2.4 | 자동화 도구와 아키텍처 설명 언어
  • 9.3 하이브리드 기법
    • 9.3.1 | 소프트웨어 성능 엔지니어링
    • 9.3.2 | ATAM
  • 9.4 정리
  • 9.5 더 읽을거리
  • 9.6 생각해볼 문제
    
• 10장 조직 차원에서 아키텍처 평가역량의 증대
  • 10.1 조직적인 합의 구축
  • 10.2 평가자 후보군의 확대
  • 10.3 조직 차원 기억 수립
    • 10.3.1 | 비용과 이득 데이터
    • 10.3.2 | 평가방법 지침
    • 10.3.3 | 재사용 산출물
  • 10.4 정리
  • 10.5 생각해볼 문제
    
• 11장 결론
  • 11.1 이제 준비완료!
  • 11.2 앞서 살펴본 방법
  • 11.3 아키텍처를 평가해야 하는 이유
  • 11.4 ATAM의 효과
  • 11.5 마치면서
    
• 부록 A 속성 기반 아키텍처 스타일의 사례
  • A.1 문제 서술
  • A.2 자극/응답
  • A.3 아키텍처 스타일
  • A.4 분석
    • A.4.1 | 추론
    • A.4.2 | 우선순위 지정
    • A.4.3 | 우선순위 반전
    • A.4.4 | 중단시간
  • A.5 더 읽을거리
    

[ p16 마지막 행 ]
구체화하는 하는 → 구체화하는