BLOG main image
분류 전체보기 (344)
NWC Consulting (1)
서비스 (173)
출판 (169)
일반 (0)
195,318 Visitors up to today!
Today 34 hit, Yesterday 86 hit
daisy rss
2013.04.26 13:08

이 장에서는 기술적 관점에서 소프트웨어 아키텍처의 중요성에 대해서 이야기한다. 3장은 비즈니스 관점에서 이야기 한다.

이 장의 내용은 누군가에게 소프트웨어 아키텍처링을 왜 해야 하는지를 설득하는데 사용할 수 있는 부분이다. 저자도 우리를 설득하고 있는 것이다. 물론 우리는 이미 아키텍처가 중요하다고 생각하고 이 책을 읽고 있으니 고개를 끄덕여 가면서 저자들의 설득을 받아들여 가면서 읽으면 된다.

 

중요한 이유에 대한 세부 내용은 필자가 본문의 내용을 참조하여 조금 각색하였다.

소프트웨어 아키텍처는 왜 중요한가?

1. An architecture will inhibit or enable a system’s driving quality attributes.

소프트웨어 아키텍처가 어떠하냐에 따라 시스템에 요구되는 품질속성이 가능하기도 하고 그렇지 못하기도 한다.

품질속성은 시스템 수준에서 중요하게 다루어져야 하는 비기능요구이다. 요구사항이라는 것이다. 요구사항을 만족하지 못하는 시스템은 실패한 시스템이다. 품질속성은 시스템 개발의 성공 기준이 되는 것이니 매우 중요하게 다루어져야 한다.

소프트웨어 아키텍처가 등장하기 이전의 시대는 기능이 중심인 시대이다. 물론 지금도 기능이 중요하다. 기본이다. 하지만 모두가 기본을 갖추고 있는 시대가 되면 기본 말고 또 다른 것이 있어야 한다. 그것이 비기능이고, 비기능 중에 대부분을 차지하는 것이 품질속성이다.

2. The decisions made in an architecture allow you to reason about and manage change as the system evolves.

지금은 변화의 시대이다. 시스템 개발을 마치고 릴리즈해서 운영되는 시점부터 곧바로 예상치 못한 변화에 직면하게 된다. 시스템은 변화에 대응하여 쉽게 바꿀 수 있어야 살아남는다.

대상을 바꾸려면 먼저 그 대상을 이해해야 한다. 대상에 대한 이해가 쉬우면 쉬울 수록 변경도 그 만큼 쉬워진다. 변경이 얼마나 쉬운가를 나타내는 품질속성이 수정용이성(modifiability)이다. 품질속성은 아키텍처로 다루어진다. 변화의 시대에 아키텍처가 더 중요해지는 이유이다.

3. The analysis of an architecture enables early prediction of a system’s qualities.

계획은 검증될 수 있어야 한다. 특히 잘못되었을 때 위험이 큰 것일 수록 그렇다. 아키텍처는 시스템 수준에서의 중요한 의사결정임으로 이것이 잘못되었을 때 파급효과는 대단히 클 것이다. 따라서 시스템 개발 초기에 검증이 가능해야 한다. 다행인 것은 아키텍처 평가 방법이 있고, 그 수준도 상당히 높은 수준이라는 것이다.

평가를 하려면 평가대상이 있어야 한다. 시스템은 아직 만들어지지 않았으니 평가대상이 될 수 없다. 평가 시점까지의 시스템에 대한 이해가 평가대상이 될 수 밖에 없다. 시스템의 다양한 이해관계자들이 이해해야 하니 그 수준에서 추상화되어야 한다. 추상화된 결과는 모델로 작성된다. 모델을 가지고 평가한다. 아키텍처 모델이 만들어지고 그것을 기준으로 평가되어야 한다. 검증된 모델은 설계로 반영되어 구현된다.

4. A documented architecture enhances communication among stakeholders.

서로 다른 이해관계자들이 시스템에 대한 공통의 이해 없이, 자신들의 이해관계만을 시스템에 반영하려고 한다면 시스템 개발은 산으로 갈 것이다. 문서화된 아키텍처가 있다면 그들은 아키텍처 문서를 통해 시스템에 대한 공통적 이해를 갖고, 공통의 언어를 사용해서 커뮤니케이션할 수 있게 된다.

5. The architecture is a carrier of the earliest and hence most fundamental, hardest-to-change design decisions.

소프트웨어 아키텍처는 시스템 개발 초기에 내려지는 설계결정이다. 초기에 내려지는 설계결정은 그 뒤에 내려지는 설계결정들을 제약한다. 따라서 초기 설계결정에 변경이 생기면 그 파급효과는 대단히 크다.

소프트웨어 아키텍처는 시스템 개발 초기에 내려져야 하는 중요한 설계결정들을 주의 깊고 체계적으로 다루도록 한다.

6. An architecture defines a set of constraints on subsequent implementation.

상위 수준의 결정이 하위 수준의 결정을 제약한다.

7. The architecture dictates the structure of an organization, or vice versa.

아키텍처는 시스템을 가장 넓은 수준에서의 분할로, 조직구조를 만들때 사용하는 작업분할구조를 반영한다. 따라서 프로젝트 관리자는 개발조직을 구성할 때 아키텍트와 긴밀히 협력해야 한다.

8. An architecture can provide the basis for evolutionary prototyping.

아키텍처가 정의되면, 아키텍처는 뼈대가 되는 시스템으로 분석되고 프로토타입될 수 있다.

9. An architecture is the key artifact that allows the architect and project manager to reason about cost and schedule.

10. An architecture can be created as a transferable, reusable model that forms the heart of a product line.

아키텍처 재사용은 개발주기 초기에 재사용을 적용하자는 것이다. 다양히 컴포넌트나 코드 재사용보다 큰 규모의 재사용이 될 것이다. 제품 군이 있는 경우 아키텍처는 다수의 시스템에서 재사용될 수 있다. 

11. Architecture-based development focuses attention on the assembly of components, rather than simply on their creation.

아키텍처 기반 개발은 컴포넌트를 조립하는데 중점을 둔다. 조립하려면 조립도가 필요하다. 조립도에 해당하는 것이 컴포넌트 아키텍처이다.

12. By restricting design alternatives, architecture channels the creativity of developers, reducing design and system complexity.

설계 대안이 많다는 것이 꼭 좋은 것은 아니다. 대안이 많다는 것은 그 만큼 복잡하다는 것이다. 대안들이 모두 좋은 것이 아니기 때문에 나쁜 대안을 선택할 수도 있다. 가능하면 복잡하지 않은 수준에서 좋은 대안을 선택할 수 있도록 제약하는 것이 좋다. 아키텍처 패턴들은 이를 위해서 등장한다.

13. An architecture can be the foundation for training a new team member.

새로운 팀 멤버를 훈련하는 기초로 사용될 수 있다. 필자는 개인적으로 이 부분을 가장 중요한 아키텍처의 유용성의 하나로 든다.

 

변경은 세 가지 범주로 구분된다.

단일 요소를 수정하면 되는 변경을 지역적 변경(local change)이라 하고, 다수의 요소를 수정해야 하는 변경을 비지역적 변경(nonlocal change)이라고 한다. 지역적 비지역적 변경은 시스템 수준에서의 의사결정을 바꾸지는 않는다. 시스템 수준에서의 의사결정을 바꾸는 변경을 아키텍처적 변경이라고 한다.

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret

티스토리 툴바