[SA강좌2회] 소프트웨어 아키텍처 설계를 위한 방법…

[소프트웨어 아키텍처 그 두번째]

아키텍처와 이노베이터

소프트웨어 아키텍처 설계를 위한 방법

 

많은 개발자들이 소프트웨어 개발에 실패하는 대표적인 이유는 어떤 것일까. 먼저 첫째, 비전문가 집단에서 의사결정이 이뤄진다는 점과 둘째, 단기적인 수익만 바라본다는 점, 셋째, 실패 예상시나리오가 부족했다는 점 등 3가지 경우로 볼 수 있겠다. 전문가집단들의 상호의사소통은 프로젝트 성공을 위한 기본이고, 프로젝트 그 이후를 예측하는 것 또한 중요하다. 또한 모든 프로젝트는 실패할 수 있다. 이처럼 실패를 대비한 위험관리와 요구사항 관리는 소프트웨어 아키텍처에 가장 중요한 요소라 하겠다.

 

----------------------------------

신현묵 zetlos.tistory.com | 현재 명지병원 정보통신팀 팀장과 헬스로그 이사로 재직하고 있다. 제약, 의료기기 생산업체의 정보시스템 개발 경험과 온라인 게임개발, 대형 SI에 이르기까지 경험이 풍부한 자칭 '삽질의 대가'. 현재 기존의 소프트웨어 삽질을 아키텍트로 승화시키려 노력하고 있다. 또한 현재 한국전자정보통신산업진흥회(KEA) 디지털병원수출기획단의 디지털병원 IT 관련 실무위원으로도 활동 중이며, 새롭게 출범하는 IT의료융합센터의 자문위원으로도 활동할 예정이다. 독자들과 트위터(@zetlos)를 통한 소통을 즐기고 있다.

----------------------------------------------

 

지난 필자의 글(2010년 10월호 커버스토리 참고)에서는 소프트웨어 아키텍처의 전반적인 내용과 개념에 대해서 서술을 해봤다면 이번 컬럼에서는 소프트웨어 아키텍처 설계를 하기 위한 절차와 기법에 대해서 알아보는 것을 주요 목적으로 두고 이야기하고자 한다.

먼저 소프트웨어 아키텍처 설계에 대한 내용에 대해서 정리한다면, 다음과 같이 언급할 수 있다.

 

1. SA설계 개요

2. 요구사항 정의 절차

3. SA설계

4. SA평가

5. SA상세화

6. SA설계 산출물 관계

7. 아키텍트의 의사결정항목

 

 

 

 

 

<그림 1>은 소프트웨어 아키텍처의 전체적인 설계 절차에 대해 쉽게 알아볼 수 있도록 기술한 것이다. <그림 1>에 대해 보다 상세하게 설명하면 다음과 같다.

가장 먼저 소프트웨어 아키텍처 중 논리적 아키텍처를 구성하기 위해 업무도메인을 분할하고, 업무도메인의 서브도메인을 파악하여 이들의 관련성(interface)을 정의하는 데서 시작한다. 이어 정의된 애플리케이션 아키텍처에 맞게 전 도메인 또는 서브도메인에 대한 아키텍처 구조에 맞게 상세설계 및 구현을 실시한다.

소프트웨어 아키텍처 설계는 고객의 요구사항에서부터 출발한다. 고객의 요구사항은 요구사항 정의 단계에서 인터뷰를 통한 회의록, 인터뷰시트로 파악할 수 있으며, 분석설계단계에서는 유즈케이스 설계서를 통해 구체적으로 파악할 수 있게 된다.

개발자는 앞서 언급된 단서들을 통해 고객의 요구사항을 파악하고, 소프트웨어 아키텍처에 고려해야 할 요소를 보다 쉽게 적용할 줄 아는 기술을 습득하는 것이 필요하다.

이때 요구사항의 우선수위 결정을 위해서는 애플리케이션 시스템의 중요한 품질요소를 결정하는것이 좋다. 이를 통해 우선순위를 가지는 품질요소에 대한 요구사항을 기반으로 작업우선순위를 결정할 수 있게 되며, 전체 애플리케이션 아키텍처에 대한 해당 요구사항이 어떻게 변경되고, 얼만큼의 영향이 미치는지도 결정할 수 있게 된다.

따라서 기본적인 소프트웨어 아키텍처 설계 방법은 기능기반 아키텍처 설계, 아키텍처 평가, 아키텍처 전이 라는 3가지 단계로 구성된다.

품질요소기반 소프트웨어 아키텍처 설계방법은 다시 내부 반복 프로세스와 외부 반복 프로세스라는 두 개의 반복적인 설계 프로세스로 구성된다.

내부 반복 프로세스는 소프트웨어 아키텍처의 품질 요구사항의 설계, 평가, 전이로 크게 나눠볼 수 있으며, 외부 반복 프로세스는 고객의 요구사항을 품질요소에 따른 선택하는 방법에 대한 활동으로 이루어진다.

반복적 소프트웨어 아키텍처 개발 사이클의 외부 소프트웨어 설계는 요구사항 중 가중 높은 고려대상이 되는 제품에 대한 품질요구사항으로 시작되는데, 이는 요구사항들의 내부 반복 프로세스를 진행하게 된다.

또한 외부 반복 프로세스는 모든 요구사항이 애플리케이션 아키텍처에 고려될 때까지 나머지 요구사항을 반복하게 된다.

선택된 요구사항은 <그림 4>와 같이 소프트웨어 아키텍처 분석·설계 및 개발을 위한 핵심 소프트웨어 아키텍처 개발을 통해 수행되며, 이 과정을 통해 소프트웨어 아키텍처의 반복적인 수정의 기본 단위 작업들이 수행된다.

이때 발생되는 여러 가지의 요구사항은 반복적 소프트웨어 아키텍처 개발 사이클을 통해 품질요소의 우선순위 또는 작업의 우선순위에 따라 핵심 소프트웨어 아키텍처 개발수행을 이끌어낸다.

내부 반복 프로세스는 소프트웨어 아키텍처가 구현되는 기본이 되는 요구사항들로 이뤄진다. 내부 반복 프로세스에서 맞춰야 할 초점은 품질요소의 평가와 전이다.

애플리케이션 아키텍처 설계 방법은 목표, 관계상 설계 과정, 균형과 최적화를 지원하도록 제공된다. 반복적인 방법은 모든 품질요구사항이 만족될 때까지 각각의 품질요구사항을 지원하고, 전이로 사용되는 아키텍처로 반영된다.

완성된 애플리케이션 아키텍처는 업무 서브 도메인별 유즈케이스로 상세설계 또는 구현이 되며, 각 요구사항에 대한 단위 테스팅 수행 전체 시스템의 제품을 완성시키기 위한 반복적인 분석/설계 과정으로 대량생산체계를 수립한다.

이때 수정되는 비 기능적인 요구사항은 품질요소에 따라서 평가되어 애플리케이션 아키텍처의 재수정 과정을 거쳐 변경된 애플리케이션 아키텍처에 대한 제품적용이 이뤄진다.

따라서 소프트웨어 아키텍처 설계 방법은 소프트웨어 아키텍처 설계와 관련한 프로세스 정의뿐만 아니라, 아키텍처 설계를 위한 소프트웨어 아키텍처 문서(SAD : Software Architecture Document)와 설계적 의사결정물 들로 구성된다.

<그림 1>을 살펴보면, 기본적으로 요구사항 정의를 분류한 기능적 요구사항을 기반으로 해서 출발하고 있음을 알 수 있다.

비록 소프트웨어 엔지니어가 품질요구사항을 명확하게 정의하지 않으면 시스템은 안정적 또는 재사용될 수 없도록 설계되는 게 일반적이다. 이러한 소프트웨어 아키텍처 설계는 품질 요구사항 측면에서 많이 평가된다. 각각의 품질요소는 소프트웨어 아키텍처가 지녀야 할 정량적 또는 정성적 예상 값으로 평가된다.

아키텍처 전이단계 동안에는, 아키텍처는 적절한 품질요소를 최적화하는 전이 방법을 선택함으로써 더욱 명확해지며, 새로운 버전의 아키텍처 설계 버전을 탄생케 한다. 이러한 요구사항 수집, 평가, 전이하는 반복적인 단계는 아키텍처 설계 또는 제품 릴리스 동안 지속적으로 발생하게 된다.

<그림 > 반복을 통한 소프트웨어 아키텍처 설계 절차

 

<그림 2>는 소프트웨어 아키텍처가 프로젝트의 각 단계에서 어떻게 작성되는지를 보여준다. Inception 단계에서는 아키텍처 팀을 구성하고 아키텍처에 대한 개략적인 안을 작성하며, Elaboration 초기 단계에서는 핵심 아키텍처를 설계한다. Elaboration 후반부에서는 추가 요구사항을 받아서 아키텍처를 계속 수정하고. Construction 단계에서는 개발 도중 이슈가 발생하면 아키텍처를 보완한다. 이러한 Inception → Elaboration → Construction 단계를 반복하면서, 충분한 아키텍처의 견고함을 가지게 된다.

 

기존의 CBD방법론을 소프트웨어아키텍처 관점으로 살펴보기

 

<그림 3> CBD 방법론

 

<그림 3>은 기본적인 CBD방법론의 전형적인 예시를 보여주고 있다. 비즈니스 요구사항단계에서 요구사항을 파악하고 비즈니스모델을 설계한 다음, 실질적인 아키텍처 단계인 솔루션 아키텍처와 솔루션개발을 통해서 구체적인 소프트웨어를 개발한다. 이어 해당 소프트웨어에 대한 지원정책을 준비하고, 개발된 소프트웨어를 도입하는 절차로 진행된다.

솔루션아키텍처에서는 요구사항의 정의와 분석을 통해서 컴포넌트 식별 및 명세화를 취하고, 아키텍처를 정의하는 단계를 진행하면서 필요한 컴포넌트를 조달하거나 기존의 컴포넌트를 수정하는 정책들을 수립한다.

이렇게 만들어진 요구사항 명세와 컴포넌트 명세, 아키텍처의 정의를 통해 솔루션개발을 진행할 수 있다. 컴포넌트를 설계하면서 테스트설계를 병행하는 것이 CBD의 핵심중의 하나다. 이처럼 솔루션 아키텍처와 솔루션개발을 반복적으로 점진적으로 개발을 진행하는 것이 CBD방법론이다.

다만 CBD방법론은 현실에서 사용하기 매우 어렵다. 그 이유는 대다수의 아키텍트와 개발자들이 인식하고 있듯이, 모든 요구사항을 컴포넌트의 형태로 식별하거나 조달하는 방법자체가 거의 불가능하기 때문이다.

소프트웨어는 완전한 블록화나 캡슐화는 불가능한 형태다. 때문에 이상적인 CBD방법론을 적용한 실제 개발환경에서의 사용은 매우 어렵다. 때문에 CBD방법론 보다는 좀 더 유연하면서도 소프트웨어 자체를 아키텍처라는 관점으로 바라보고 개발에 나서는 것이 좀 더 바람직하다고 볼 수 있다.

그렇다면 이번에는 이상적인 CBD방법론을 SA관점에서 변환하고, 어떤 부분이 변경되는지 알아보도록 하자.

 

기존의 CBD방법론에서 아키텍처 정의 단계를 세분화하면 아키텍처 설계, 아키텍처 평가, 아키텍처 상세화로 나눠진다. 이는 CBD방법론에서 '솔루션 아키텍처'를 좀 더 세분화했다는 것이 그 차이일 수 있겠으나, 실제로 작업을 진행했을 때는 엄청난 차이를 보이게 된다.

이론과 실제가 큰 차이를 보이는 이유는 무엇일까. 요구사항을 통해 정의하고, 분석하는 과정에서 아키텍처 설계시 발생하는 컴포넌트 영역과 비컴포넌트 영역의 구분을 명화히 한다는 점과, 기존의 컴포넌트 설계시 요구사항 정의와 분석을 통해 바로 컴포넌트를 식별하거나 명세화 하는 것 뿐만 아니라, 좀 더 구체적인 아키텍처의 평가와 상세화 작업을 통해서, 컴포넌트를 식별하고 명세화하는 단계로 진행되기 때문이다.

이러한 이유로 실질적인 아키텍처 설계, 평가, 상세화 단계의 심도있는 작업과 논의를 진행해야 하는 아키텍처 팀의 구성과 형태가 매우중요하게 부각된다.

더불어 아키텍처 상세화 작업시, '기능/비기능'부분과 '고품질/저품질', '반복패턴과/집중개발'영역 등의 구분들을 세부적으로 정의하게 된다.

업무의 기능적인 사항이나 제약사항, 필요시 정의된 기능들에 대한 내용들과 실제, 시스템에서 요구되는 성능이나 UX에 대한 정의, 실제 외부시스템과의 연계 및 정의된 사항들에 대해서 정의한다. 또한 모든 소프트웨어의 기능부분들을 모두 고품질로 정의하는 미련한 행위를 하지 않는 정의가 일어난다.

소프트웨어의 고품질요소와 중요 기능요소를 도출하여 고품질영역을 구분한다. 아주 단순한 기능부터 아주 복잡하고 주요하게 요구되는 부분과 향후 유지보수와 가장 민감한 영역들에 대한 것은 물론이고, 고품질 개발이 가능한 팀원이나 팀이 필요한 요소들도 구분한다.

또한 반복패턴의 단순한 작업으로 구성되는 영역들과 별도로 개발될 영역들을 구분해야 한다. 이러한 방법들은 기존의 CBD의 작업순서와는 많은 차이를 보이며, 결과물의 형태 또한 다르게 나타난다.

 

 

 

 

기존의 CBD방법론을 소프트웨어아키텍처 관점으로 개선하기

이처럼 아키텍처 설계, 아키텍처 평가, 아키텍처 상세화의 단계에 대해 알아봤다면, 이번에는 프로토타입 기법과 같은 방법으로 제작된 중요한 샘플 프로세스나, 중요한 테스트케이스를 통해서 필요한 부분에 대해서 구성하는 방법도 가능하다. 원한다면, 고객이 원하는 대부분의 주요기능들에 대한 테스트케이스에 대한 진행도 가능한 부분으로 진행할 수 있다.

이번에는 좀 더 상세하게 전반적인 프로세스의 흐름에 대해서 살펴보자.

 

비즈니스 요구사항 분석 및 모델개발

<그림 > 요구사항 파악활동

 

<그림 5>를 통해 솔루션 아키텍처와 솔루션 개발에 대해서 상세하게 알아봤다. 그렇다면 요구사항 파악단계에 대해 알아보자. 요구사항 파악단계는 요구사항 수집 및 기술 → 현행 조직 및 시스템 정보 수집 → 시스템 비전 개발 3단계로 진행된다.

시스템을 주기적으로 유지보수하는 조직의 경우에는 평소의 요구사항과 명세서 등을 취합해 정기적으로 발생하는 영역과 주변의 상황에 따라 변경되는 다양한 요구사항들을 중요도를 따져 취합하며, 시스템에 반영될 요구사항을 수집하고 기술하고 평가하는 단계를 먼저 수행한다.

이어 현재의 조직체계와 프로세스와 현재의 시스템에 대한 정보들을 수집한 뒤, 이 요구사항들을 기반으로 현재의 시스템인 As-Is에 대한 명쾌한 기술을 통해 to-be 시스템의 비전에 대해 설계한다.

여기에서 가장 중요한 점은 기능적 요구사항과 비 기능적 요구사항을 명확하게 파악해야 한다는 점이다. 비 기능적 요구사항은 품질에 대한 요구사항이나 시스템 제약사항 등이 이에 해당된다.

그러나 아키텍트는 '기능'과 '비기능'을 전혀 다른 것으로 봐서는 안된다. 마치 '기능/비기능'은 동전의 양면과 같은 존재이기 때문이며, 서로 tradeoff의 중요한 관점으로 보아야하기 때문이다.

기능을 위해 비 기능을 축소하거나, 비 기능적인 요소인 성능을 위해 원하는 기능을 빼야하는 동전의 양면과 같은 요소라는 것이다. 모든 기능요소를 구현하는 것도, 모든 비 기능적인 요소를 구현하는 것도 SA를 디자인하는 아키텍트의 중요한 선택의 폭이라는 것이다.

일반적으로 기능을 '사용자와 직접적인 연관이 있는 업무'라고 한다면, 비 기능이란, 전체적인 시스템이거나 일부 기능들이 가져야할 일종의 속성에 해당한다. 특히 성능, 사용성, 편의성 등과 같은 비 기능적인 요소를 만족하지 못한다면, 전반적인 시스템이 개발된 이후 실패를 맛보는 가장 큰 요소가 되기도 하며, 심지어 모든 기능을 만족시켰지만 사용자의 편의성을 무시하고 개발되거나 엄청 느린 반응속도를 가진 프로그램이라면 해당 프로젝트는 실패하게 된다.

보통 우리들은 기존의 C/S프로젝트들을 웹(Web)화 하면서 이러한 비기능적인 사용자 편의성부분에서 차이를 보인다.

기존 C/S에서는 하나의 화면에서 모든 것을 처리했는데, 웹에서는 클릭수가 늘어나거나 반응속도가 느려지는 현상이 발생되는 것이 바로 그것이다. 이러한 현상은 초기에 비기능적인 부분에 대한 정의를 제대로 정의하지 못했기 때문에 발생하는 것으로, 전체적인 시스템 디자인에 대한 문제가 발견되는 것을 초기부터 알 수 있게 한다. 하지만 이를 무시하게 된다면 실패로 직결된다.

여기에서 문제는 이와같은 비 기능적인 요구사항에 대해서도 명확한 도출이 필요하다는 것이다. 이것이 아키텍트의 임무이며, 이를 고객에게 이해시키는 것이 가장 중요한 미션 중 하나다. 때문에 아키텍트에게 가장 필요한 기술은 커뮤니케이션 능력이라고 할 수 있다. 개발자들 간의 의사소통 뿐만 아니라 고객과의 효과적인 의사소통을 이끌어내는 능력을 가지는 것이 바로 아키텍트가 가져야 할 능력이기 때문이다.

더군다나 국내의 개발환경에서는 PM이 아키텍트의 말을 들으려 하지 않는다면, PM과의 의사소통 또한 틀어지기 때문에 가장 많은 신경을 써야 할 포인트가 되기도 한다.

 

<그림 > 비즈니스 모델 개발 활동

 

비즈니스 모델 개발활동에서는 사용자의 '비즈니스 적인' 기능적 요구사항과 업무규칙 등이 추가된다. 사용자의 전반적인 업무와 대응하는 프로세스를 모두 이곳에서 검증하거나, 필요한 유스케이스 모델들을 도출하고 필요한 비즈니스 객체 모델들을 도출하여 개발하는 과정을 보여주는 것이다.

 

솔루션아키텍처와 솔루션개발과정을 통한 '반복적인 개발 프로세스'

 

<그림 > 요구사항 정의 활동

 

요구사항 정의활동은 '유스케이스 모델 개발', '클래스 모델 개발', 'UI 모델 개발(프로토타입 수행)' 이라는 3단계가 진행된다. 이때, 기존의 CBD에서는 초기 아키텍처 정의가 있었지만 SA가 도입된 프로세스에서는 유스케이스 모델과 클래스 모델, UI 모델을 정의하는 단계라고 볼 수 있는데, 특히 중요한 유스케이스들의 모델들의 형태와 클래스 모델, 그리고 UX와 비 기능적인 성능과 관련된 부분들에 대해서 밀접하게 분석하고 정의하는 단계라고도 볼 수 있다. 요구사항에 대한 정의를 받아들일 유스케이스 모델들과 클래스 모델들, UI 모델들은 향후 시스템에 지대한 영향을 주게 된다.

이러한 내용들은 실제 아키텍처 정의와 평가, 상세화 단계를 거치면서 더욱더 견고한 단계로 변화할 수 있다.

 

<그림 > 아키텍처 설계 활동

 

유스케이스 모델, 클래스 모델, UI 모델을 통한 요구사항을 정의한 다음, 실질적인 아키텍쳐 설계과정에서 중요한 '아키텍처 관련 요구사항 분석'을 통해 시스템 컨텍스트를 정의할 수 있게 되는데, 이 단계에서는 Component&Connector View, Module View, Allocation View, Code View 라는 4가지 View를 구성하게 된다.

여기에서 4가지 View는 모두가 필요한 것은 아니며, 각각의 시스템 상황과 형태에 맞춰 필요한 View까지만 작성하면 된다.

SA에서의 주요 컨셉은 개발자들간의 의사소통에 필요한 단계에 대해서 정의를 내리고, 필요한 부분까지만 작성하면 된다는 점이다. 구체적으로 필요한 요구사항이 없는 형태까지 모두 기술 할 필요는 없다. 오히려 필요없는 상황들에 대해서 기술함으써 더욱 복잡한 형태가 만들어지기도 한다. 이와같은 단계에서의 활동을 '아키텍처를 모델링'이라고 할 수 있다.

 

 

 

<그림 > 아키텍처 평가 활동

 

<그림 9>는 설계된 아키텍처를 평가하는 과정을 보여주고 있다. 보통 이와같은 경우에는 기본적으로 작성된 아키텍처 문서를 평가하는데, 필요한 요구사항이나 품질, 기능/비기능적인 요소들을 만족하는지 검토한다. 다만, 이 부분에 있어서 '비기능적인' 품질 부분의 중요도가 높다면 프로토타입 기법이나 중요 테스트 단계를 거쳐 중요한 아키텍처의 키포인트를 테스트하는 단계를 거칠 수도 있다.

<그림 > 아키텍처 상세화 활동

 

아키텍처 상세화 활동은 '아키텍처 패턴'이라 불리는 아키텍처 스타일을 적용하거나, 필요한 요소들을 상세화 하는 것을 말하며, 유사한 프로젝트에서 필요한 아키텍처를 가져오거나 완성된 프레임워크를 도입하고, 해당 단계에서 실제로 필요한 패턴들을 도출하거나 설계 가이드라인을 구성하는 것 또한 포함된다.

이 단계에서는 평가된 결과를 바탕으로 아키텍처를 상세화하고, 상세 결과가 필요한 부분과 상세 설계를 구현하는 단계까지 진행되며, 설계와 구현을 진행하기 위한 가이드라인과 지침 작성 또한 이뤄져야 한다.

이때, 실제 설계와 구현을 진행하기 위한 팀원들의 수준 및 개발자들의 상황에 맞는 팀구성과 설계검증 및 개발 품질에 대한 체크사항들을 나열해야 한다. 그 이유는 저 수준의 개발자들이 많을 경우, 좀 더 패턴화한 개발방법으로 진행하는 것이 개발품질을 유지할 수 있도록 하거나 중요도가 높고, 고품질을 요구하는 부분을 최소화하는 방향으로 진행할 수 있기 때문이다.

이때 만들어지는 꽤 많은 가이드라인들은 가능한 최소화 하는 것이 중요하며, 개발툴의 자동화 혹은 템플릿의 활용이 최대한 이뤄지게 된다. 이외에도 빌드 방법이나 형상관리방안, 프로파일링을 통한 소스검증 방법에 이르기까지 다양한 설계 및 개발과 관련된 부분에 대해서 많은 부분을 아키텍트와 아키텍트 팀에서 준비하게 되는데, 이는 최선의 결과물을 도출할 수 있는 방법을 찾게 되는 것이다.

<그림 > 컴포넌트 식별 및 명세 활동( 컴포넌트 식별 및 명세의 작업내용 4가지.

- 컴포넌트 식별 및 구조화, 인터페이스 식별, 컴포넌트 명세서 작업, 컴포넌트 상호작용분석 )

 

 

<그림 > 컴포넌트 조달 활동

( 컴포넌트 평가기준 선정, 컴포넌트 선정 및 구매 )

 

<그림 11>과 <그림 12>는 컴포넌트와 관련된 활동들로써 CBD에서 기술하고 있는 내용과 크게 다르지 않다. 다만 컴포넌트를 식별하고 컴포넌트의 인터페이스에 대한 명세서를 작성하고, 필요한 컴포넌트의 평가 기준을 선정하고 구매나 형태를 정의하는 부분에서 과도한 컴포넌트형태로의 정의를 강요하기 보다는 정말 컴포넌트로써의 의미가 있는지에 대해서 아키텍트와 아키텍트 팀이 고민해야 한다는 점이 다를 뿐이다.

보통 업무단계에서 컴포넌트라고 불리는 부분들은 말 그대로 캡슐화와 향후 유지보수 단계에서 중요한 영역으로 구분되는 것으로, 실제 변동이 별로 없거나 정말 많은 부분에서 표준적으로 활용되는 부분이라고 하겠다.

또한 컴포넌트라고 불리는 부분들은 예외를 인정해서는 안된다. 실제 개발에 들어가서 예외를 인정하거나 일부분의 변경이 발생하는 부분이 있다면, 이러한 부분들은 비즈니스 컴포넌트로 구성되어서는 안되며, 개발자의 수준이 이러한 구분과 형태를 이해하지 못하거나 향후 유지보수 계획과 비용 부분을 모두 고려하여서 컴포넌트의 형태와 그 단계를 조절해야 한다.

정밀한 컴포넌트의 구현과 설계가 꼭, 프로젝트의 성공을 말하지 않는 다는 것은, 어느정도의 실무를 경험한 아키텍트들은 모두 알고 있는 내용이다.

다만 사용자의 UX와 접목되어서 향후 유지보수시 수시로 발생되는 부분에 대한 대응책을 이 부분에서 서술해두는 것이 최선이다.

보통의 유지보수는 거의 대부분이 UX관련된 부분에서 발생되므로, 이 부분에 대해서 얼마나 유연한 UI컴포넌트들의 배치와 형태, 유지보수 체계를 가지느냐에 따라서 시스템의 구성형태가 정말 판이하게 다른 구조로 만들어지기 때문이다.

 

--- 이후의 단계는 다음회로 넘겨도 괜찮습니다.

 

 

SA설계란 과연 무엇인가

 

이번에는 SA설계에 대해서 정리해보도록 7하겠다. SA설계는 크게 '인터페이스 정의, 요구사항의 우선순위 파악, 고객의 요구사항 파악이라는 3가지 중요 요소로 축약할 수 있다. 시스템적으로서의 중요한 부분은 시스템과 사용자간의 UX도 인터페이스요, 컴포넌트와 컴포넌트 사이의 인터페이스, 모듈과 모듈의 인터페이스에 있다.

더욱더 중요한 사실은 고객의 요구사항에 대한 반응이다. 고객의 요구사항을 어떻게 명확하게 파악할 것이며, 그 요구사항의 우선순위를 정확하게 파악하는 것이 바로 SA설계의 중요3가지 요소이다.

 

 

<화면 1> SA설계의 기초단계

 

SA설계의 기초단계는 <화면 1>과 같이, 사용자의 요구사항들을 수집하고 리스트를 관리하며, 해당 요구사항 리스트에서 작업의 우선순위와 품질요소를 결정하는 것이다. 또한 이러한 요구사항들을 통해 요구사항의 변경지표 및 시기, 변화의 내용들에 대해서 대응해야 한다.

사용자의 요구사항들은 중요한 UX와 컴포넌트들간의 연관관계에 영향을 끼치기 때문에, 사용자 요구사항을 명확히 관리하는 것이 최선의 프로젝트 품질요소 지표다.

해당되는 요구사항들에도 각각의 우선순위가 있다. 개발의 우선순위, 기능적인 우선순위, UX의 우선순위, 개발비용의 우선순위, 위험요소의 우선순위가 바로 그것인데, 이를 통한 다양한 프로파일링이 가능하다. SA설계의 3단계 과정을 표현하면 <화면 2>와 같다.

 

<화면 2> SA설계의 3단계

 

<화면 2>는 SA설계의 3단계를 중요한 지표로서 서술한 것으로, 가장 중요한 내부적인 SAD(Software Architecture Document)와 설계적 의사결정문을 구성하기 위해서 중요한 3가지의 단계를 거치는 것을 의미한다.

첫 번째는 작업 우선순위이며, 두 번째는 내·외부 반복 프로세스 수립, 세 번째는 업무 서브 도메인별 반복적인 분석 및 설계과정의 대량생산체계 수립이다.

이는 기능/비 기능과 이에 따라 파생되는 유지보수 단계 및 개발과 테스트, 아키텍처의 구성형태에 영향을 주는 작업의 우선순위에 대한 파악이 그 첫 번째이며, 중요한 요구사항들이 반영될때에 해당 프로세스에 대한 영향을 개발조직 내부와 업무조직 내부의 요구조건, 외부의 법이나 기타 연관관계에 따른 요구사항의 변경들에 대한 영향의 변화에 대한 프로세스들을 수립하는 것이 두 번째요. 실제, 분석/설계시에 대량생산과 수집, 패턴화가 가능한 요소들을 도출하는 것이 그 세 번째가 되겠다.

 

이번 컬럼에서는 SA설계의 기초적인 프로세스의 흐름과, SA설계를 하기 위한 기본적인 생각의 흐름과 주요한 요구사항에 대한 대응하는 방법에 대해서 알아보았다. SA에서 가장 중요한 것은 이 요구사항을 어떻게 아키텍처에 반영하고 이를 어떤 기능/비 기능으로 구분하여 관리할 것이며, 그 단계와 분석/설계에 대응하는 실제 개발팀에 대한 통제방법들에 대해서 고민하고, 실제 개발/유지·보수할 조직에 대한 예측을 해야한다는 것이다.

다만 아키텍트는 이러한 계획을 수립하고 필요 가이드라인을 구성할 때에, '불필요한 절차와 행위'에 대해서 독자적으로 구성하지 말고, 실제 수행할 개발조직과 팀원들과의 대화와 타협에 의해서 이를 구성하는 것이 가장 최선임을 잊어서는 안된다는 것을 강조하고 싶다.