추가 적립 안내

소프트웨어 아키텍처 평가에 대한 모든 것!

'에이콘 소프트웨어 아키텍처' 시리즈, 제4권 『소프트웨어 아키텍처 평가』. 아키텍처 설계 의사결정에 대해 회사와 고객의 합의를 이끌어내는 소프트웨어 아키텍처 평가를 수행하는 순서와 방법을 단계적으로 제공한다. 아키텍처 평가 실무자는 물론, 소프트웨어 엔지니어를 대상으로 저술된 것이다.

특히 성공적인 제품 개발과 발전을 위한 아키텍처 평가 방법 3가지를 실례를 들어 일목요연하게 설명한다. 아케텍처 평가 방법을 시스템에 적용했을 때의 가치를 확인할 수 있다. 아울러 아키텍처 평가에 제품 개발 일정이나 비용을 추가하는 것만으로도 위험을 줄일 수 있음을 보여준다. 저자의 아키텍처 평가에 대해 정리된 경험담도 담아 이해를 도모하고 있다. 문제점도 고백하여 실질적인 도움을 안겨준다.

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

아키텍처 평가를 수행하는 데 유용한 세 가지 최신 평가방법에 대한 실질적인 지침을 제공하는 책으로서, 실무자에게 유용할 뿐만 아니라 아키텍처 평가 발전의 기반으로도 그 가치를 인정받을 것이다.
(/ 리치 힐리어드, 콘센트캐시 주식회사 CTO)

성공적인 제품의 개발과 발전은 올바른 아키텍처를 선택하느냐에 달렸다. 아키텍처 선택이 이렇게 중요하다는 사실을 안다면 아키텍처를 제대로 파악하거나 평가해야겠다는 생각이 절로 들 것이다.
(/ 알렉산더 랜, 노키아의 소프트웨어 아키텍처 수석 과학자)

소프트웨어 엔지니어의 책장에 꼭 있어야 할 필독서
- 조 마란자노, 前 벨연구소 소프트웨어 기술 센터장

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

특히 다음 세 가지 주요 평가방법을 설명한다.
1. 아키텍처 트레이드오프 분석방법 (ATAM)
2. 소프트웨어 아키텍처 분석방법 (SAAM)
3. 중간설계에 대한 능동적 검토 (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장에 있는 사례연구는 팀에서 시범으로 평가를 수행하는 데 참조 자료로 사용할 수 있다.

〈 요약 〉

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


〈 소개 〉

아키텍처 평가를 수행하는 데 유용한 세 가지 최신 평가방법에 대한 실질적인 지침을 제공하는 책으로서, 실무자에게 유용할 뿐만 아니라 아키텍처 평가 발전의 기반으로도 그 가치를 인정받을 것이다.
- 리치 힐리어드, 콘센트캐시 주식회사 CTO

성공적인 제품의 개발과 발전은 올바른 아키텍처를 선택하느냐에 달렸다. 아키텍처 선택이 이렇게 중요하다는 사실을 안다면 아키텍처를 제대로 파악하거나 평가해야겠다는 생각이 절로 들 것이다.
- 알렉산더 랜, 노키아의 소프트웨어 아키텍처 수석 과학자

소프트웨어 엔지니어의 책장에 꼭 있어야 할 필독서
- 조 마란자노, 前 벨연구소 소프트웨어 기술 센터장

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

특히 다음 세 가지 주요 평가방법을 설명한다.

■ 아키텍처 트레이드오프 분석방법 (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장에 있는 사례연구는 팀에서 시범으로 평가를 수행하는 데 참조 자료로 사용할 수 있다.


★ 이 책에 쏟아진 찬사 ★

복잡한 소프트웨어나 시스템 아키텍처는 변경하는 데 고비용이 소요될 수 있는 어려운 의사결정의 총체다. 성공적인 제품의 개발과 발전은 올바른 아키텍처를 선택하느냐에 달렸다. 아키텍처 선택이 이렇게 중요하다는 사실을 안다면 아키텍처를 제대로 파악하거나 평가해야겠다는 생각이 절로 들 것이다. 저자들은 소프트웨어 아키텍처와 소프트웨어 아키텍처 평가에 대한 전문가들이다. 그들의 풍부한 아이디어와 경험을 잘 정리한 이 책을 통해 아키텍처 평가에 접근할 수 있다. 복잡한 시스템이나 소프트웨어 개발에 참여하는 사람이라면 누구나 실제 아키텍처 평가를 수립하고 향상하는 데 필요한 매우 귀중한 가이드를 이 책에서 찾을 수 있을 것이다.
- 알렉산더 랜, 노키아의 소프트웨어 아키텍처 수석 과학자

소프트웨어 엔지니어의 책장에 꼭 있어야 할 필독서다. 이 책은 소프트웨어 아키텍처를 평가하는 절차에 대해 잘 정리된 가이드다. 저자들은 소프트웨어 개발 생명주기의 표준에 아키텍처 평가와 검토를 포함해야 한다고 주장한다. 이 책은 확장용이성, 이식용이성, 신뢰성 같은 중요한 아키텍처 특성을 분석하는 새롭고 혁신적인 방법을 소개한다. 이와 같은 아키텍처 평가방법이 훌륭한 소프트웨어 시스템을 만드는 데 새로운 엔지니어링 초석이 되리라 믿는다.
- 조 마란자노, AT&T 벨연구소의 소프트웨어 아키텍처 펠로우(1990),
전 벨연구소 소프트웨어 기술 센터장

제품을 빠르고 저
렴하게 개발하면서도 고객을 만족시킬 수 있는 내가 아는 유일한 방법은 경험과 팀워크다. 저자들의 첫 번째 책인 『소프트웨어 아키텍처: 이론과 실제』에서 폴과 릭, 베스는 내가 쌓은 경험을 이론적으로 설명할 수 있도록 도와줬다. 저자들의 귀중한 경험과 사례연구를 통해 나는 시스템 설계와 소프트웨어 아키텍처를 진행하는 방법을 바꿀 수 있었다. 마크도 참여한 이 두 번째 책은 내가 아키텍처에 만족하기 전에 살펴보고자 하는 부분까지도 포함하고 있다. 즉 다른 사람의 경험에 기반한 피드백을 어떻게 이끌어내느냐다. 나는 고객을 만족시키기 위해 이 책에서 설명한 많은 개념을 사용했다. 이 책을 통해 아키텍트, 개발자, 관리자는 팀을 구성하는 데 필요한 공통된 언어와 실무경험을 쌓을 수 있으며, 좀 더 성공적인 제품을 고객에게 제공할 수 있게 될 것이다.
- 버트랜드 살레, 대규모 통신회사의 수석 아키텍트

아키텍처가 시스템 구축에 대한 기반이라면 아키텍처 평가는 훌륭한 아키텍처가 되기 위한 기반 중 한 부분이다. 저자들은 시스템 개발에서 가장 많은 압력을 받는 이슈에 대해 전문성을 발휘하고 있다. 즉 시스템을 구축하기 전에 해당 시스템의 실행가능성과 적합성을 확신하기 위해서 어떻게 아키텍처를 평가할 것인가이다. 이 책은 아키텍처 평가를 수행하는 데 사용할 수 있는 세 가지 최신 평가방법에 대한 실질적인 지침을 제공한다. 이 지침은 실무자에게 유용할 뿐만 아니라 공학적 실무로서 아키텍처 평가 발전의 기반으로도 그 가치를 인정받을 것이다.
- 리치 힐리어드, 콘센트캐시 주식회사의 CTO,
IEEE RPADSS(Recommended Practice for Architectural Description of Software-Intensive) Systems의 기술 편집자

많은 시스템이 부적합한 아키텍처로 인해 성능 등 여러 문제점을 안고 있다. 따라서 문제는 이미 앞에서 발생했지만 대체로 개발이 종료에 가까워서이거나 심하게는 신문에 보도되고 나서야 문제를 인식하는 것처럼 너무 늦게 발견될 수 있다. 이를 개선하는 방안은 일정 및 비용 초과, 출시시점 지연, 고객관계 악화 등의 많은 어려움을 초래한다. 이와 같은 문제는 아키텍처 선택에 대한 평가를 일찍 수행해서 적합한 아키텍처를 선택하는 것으로 쉽게 예방할 수 있다.
- 코니 스미스 박사, L&S 컴퓨터 기술 주식회사의 성능 공학 서비스 사업부의 수석 컨설턴트, 『Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software(성능 해결 방법: 반응적이고 규모가변적 소프트웨어를 만드는 실무적인 가이드)』의 공동 저자

이 책에서 설명하는 아키텍처 평가방법인 ATAM은 상세 설계 프로젝트가 시작되기 전에 상위 수준 설계가 통과해야 하는 자연스러운 품질 관문이다. 아키텍처를 평가하는 데 ATAM을 사용하는 이유는 무엇인가? 설계 위험을 완화하는 것이 주요한 이유지만 좀 더 중요한 것은 ATAM이 핵심 개발과 사용자 이해관계자의 아키텍처적인 가시성을 제공하는 상호작용 도구로서 가장 중요한 합의를 초기에 유도하기 때문이다.
- 리치 제브로스키, 모토로라의 소프트웨어 기술 관리자

캐터필러는 아키텍처 평가방법인 SAAM, ATAM, ARID, ADR(ADR을 제외한 나머지 평가방법은 이 책에 자세하게 소개됨)에 대한 경험이 있다. 이 평가방법은 사용자층의 요구가 달성되는 것을 보장하고 아키텍처를 노출시켜서 조직 내 다른 이해관계자들이 이해하고 조직 차원에서 수용가능하도록 도와준다. SAAM과 ATAM 기반 평가는 개발주기의 앞 단계에서 다양한 사람들에게 아키텍처를 드러내는 데 잘 작동한다. ARID와 ADR 기반 평가는 개발주기의 뒤 단계에서 아키텍처의 기술적인 상세한 내용을 잘 드러내도록 여러 방법을 제공한다. 개인적으로 ARID를 적용한 파일럿 프로젝트의 아키텍트로 참여했었는데 ARID는 아키텍처가 완전히 문서화되
기 전에 프로젝트의 아키텍처 교육으로도 사용할 수 있었다.
- 리 덴브라버, 캐터필러 주식회사의 수석 소프트웨어 아키텍트

팀의 혁신적인 창의성을 체계화하고 통합된 고객-개발자-제품팀을 구성해서 시스템이 최종사용자의 필요를 좀 더 잘 포착해야 한다고 관리자들이 과장되게 주장하는 이야기를 늘 들어왔다. 이 책에서 설명하는 ATAM 기법은, 기술 관리자, 시스템 아키텍트, 엔지니어들이 목표를 실현하는 데 있어서 능력을 방해하는 의사소통 장벽을 깨트릴 수 있는 검증된 도구다. 우리는 자체적인 개발 및 관리 생명주기에 ATAM 기법을 성공적으로 통합했고 EOSDIS 같은 대규모 시스템에서 요구되는 많은 어려운 절충점을 평가하는 데 필요한 강력한 기술적 기반을 제공해줬다.
- 마이크 무어, 나사 고더드 우주항공센터 과학 시스템 개발 부서장,
지구관측 시스템 데이터 정보 시스템(EOSDIS, Earth Observing System Data Information System) 프로젝트

아키텍처 검토가 얼마나 어려운지 아는 사람이라면 ATAM 평가의 효율성에 매우 놀랄 것이다. 예를 들면, 중요한 소프트웨어 프로덕트 라인에 대해 수행한 ATAM을 통해서 그동안 숨겨졌던 주요한 아키텍처 위험을 식별할 수 있었다. 이러한 이점을 지속적으로 얻기를 기대하고 있다. 추가로 ATAM 기법은 이와 같은 위험을 이해관계자들에게 다른 어떤 검토방법보다 훨씬 명확하게 설명할 수 있었다.
- 스테판 페버, 로버트 보슈 주식회사 연구소


★ 한국어판 특별 서문 ★

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

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

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


★ 저자 서문 ★

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

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

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

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

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

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

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

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

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

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

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

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

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

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

폴 클레멘츠, 릭 캐즈먼, 마크 클라인



★ 옮긴이의 말 ★

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

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

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

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

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 더 읽을거

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리
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 더 읽을거리

참고문헌
.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 더 읽을거리

참고문헌

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

폴 클레먼츠, 릭 케즈먼, 마크 클라인
(/ 저자 서문 중에서)

최근 소프트웨어 아키텍처에 대한 관심이 점차 높아지면서 다양한 서적과 교육과정들도 속속 생겨나고 있습니다. 또한 실제 현장에서도 아키텍처를 정의하는 절차에 따라 아키텍처 정의서를 작성하는 사례도 많아지고 있으며 이를 전담하는 아키텍트도 늘어나고 있습니다. 이 모두 소프트웨어 업계가 점차 성숙한다는 측면에서 반가운 일이지만 구축된 소프트웨어 아키텍처가 올바른지를 검증하는 일은 아직 부족한 상황이라고 할 수 있습니다.

저희 역자들이 몸담은 시스템 통합(SI) 프로젝트를 살펴보면 대부분 상용 또는 오픈소스 솔루션을 이용하는 환경에서 아키텍처를 수립하게 됩니다. 이처럼 각기 특정 기술이나 독자적인 아키텍처를 바탕해 만들어진 아키텍처 구성요소들을 기반으로 애플리케이션의 기능을 구현함에 있어 발생하는 위험요소와 절충점을 사전에 파악하는지의 여부는 성공을 가름하는 중요 요소가 됩니다. 따라서 아키텍트는 다양한 의사결정의 조합으로 발생하는 결과가 목표에 부합하는지를 확인하는 데 많은 시간을 할애해야 하지만 이런 시간은 잘 주어지지 않는 게 현실입니다. 따라서 많게는 수 백 명의 개발자가 준수해야 하는 아키텍처가 달성하고자 하는 목표에 얼마나 근접한지를 확인할 수 있는 절차나 검증 방법은 매우 단편적인 경우가 대부분이며 실제 오픈에 다다라서야 문제를 알 수 있는 경우가 많습니다.

한편 이와 같은 문제를 개선하기 위해 경험이 풍부하고 실력 있는 여러 엔지니어가 참여하더라도 고객의 요구사항과 개발자의 수준을 고려하지 않고 자신이 적용해본 특정 기술을 적용하는 일만 지향하거나 이들간의 이견을 효율적으로 조율할 수 있는 원칙이 없다면 이러한 접근방법도 심각한 문제를 일으킬 수 있습니다.

이 책에서 소개한 아키텍처 평가는 소프트웨어 공학이라는 관점에서 봤을 때 가장 최적의 비용으로 최대의 효과를 보장하는 안전장치라고 할 수 있습니다. 앞에 설명한 바와 같이 다양한 참여자들 간의 의견 공유를 통해 프로젝트의 중요한 의사결정을 내려야 할 때 편중된 의견을 효과적으로 조율하거나 침묵하는 다수 의견을 가시화하는 일은 매우 어렵습니다. 따라서 아키텍처 평가의 가장 중요한 효과는 이러한 프로젝트 참여자들 간의 역학관계를 매우 효과적으로 대응할 수 있는 방안을 제시한다는 점입니다. 이는 아키텍처 평가가 아키텍처 방향성을 수립하는 데 참여, 공유, 개방이라는 키워드에 매우 잘 들어맞는다고 할 수 있습니다. 이 책을 읽는 독자들도 저희 역자들이 느낀 아키텍처 평가의 효과를 공감하고 특히, 평가되는 데에 대해 두려움을 느끼기보다는 평가를 할 수 있음에 안도감을 느낄 수 있기를 바랍니다.

베타리더에 참여하셔서 이 책을 번역하는 데 조언을 주신 옥상훈님, 강용석님, 차병태님, 최정일님과, 물심양면의 도움은 물론 뜨거운 관심을 보여 주신 한국 소프트웨어 아키텍트 연합회 회원들과 회사 선배님, 동료들에게 감사드립니다.
(/ 옮긴이의 말 중에서)