크리스토퍼 알렉산더(Christopher Alexander, CA)는 오스트리아 출신의 건축가(Architect)이다. 사용자 중심의 설계 방식과 패턴 언어(Pattern Language)를 통한 건축 설계 방식으로 유명하다. 특히, 다른 건축가들과 다른 부분은 건축과 도시 설계를 보다 인간 중심적이고 살아 있는 방식으로 접근해야 하는 것을 강조했다. 이러한 접근법은 그는 여러 저서를 남겼는데,  유명한 초기 저서인 "영원의 건축"[1]이나 "패턴 랭귀지"[2] 뿐만 아니라 그의 마지막 4권의 저서인 "Nature of Order"[3] 등에서 상세히 설명한다. 이 책들에서 자연의 형태와 어울리는 건축적 원리를 제시하며, 디자인 프로세스에서 "살아 있는 구조"를 창조하는 방법에 대해 설명한다.

"영원의 건축"의 "건물군 설계하기"에서는 캘리포니아에 세워질 정신과 병원 설계에 대한 사례를 소개 한다. 이 장의 초기에 언급되어 있듯이 실재 병원의 주요 이해관계자인 병원장, 의료진, 관련 연구원들이 설계에 참여한다. 시작은 이해관계자들이 생각하는 "기능"이나 "활동"을 기반으로 적용해야 하는 패턴들을 포함시키거나 제외하는 작업들을 상당히 긴 시간의 토론을 통해 찾아간다. 이러한 패턴에 합의하게 되면 설계 준비가 되었다고 보고 설계를 시작한다. 이 때, 사무실에 설계를 하는 것이 아니라 건물이 세워질 대지에 나가서 이해 관계자들과 함께 이야기를 나누며 진행된다. 이러한 과정을 거칠 때, CA는 "눈을 감고 생각해보라"라는 요청을 많이 했다.

"Nature of Order"의 Book 2의 13.9 "The process of Finding a Good Centers"에도 비슷한 사례가 나온다. 앙드레와 애나 부분의 집 설계에 관한 부분이다. 일반적으로 부억, 거실, 식당과 같은 구조를 만들면서도 가족들은 아이들과 보낼 장소에 대한 필요가 있었던 것 같다. 가족방(family room)이 일반적인 해법이겠지만, CA는 적절한 해결책이 아니라 생각한 것 같다. 역시, 이해 관계자들과 3일간의 토론이 있었다. 눈을 감고 미소 띄운 앙드레가 떠올린 것은 프랑스 남부에 있는 그의 할아버지 집이었고 벽난로, 테이블 그리고 밖에서 들어오는 남향의 햇볕이었다. 이를 기반으로 이 집의 여러 중요 부분 중 하나인 농가의 부엌(farmerhouse kitchen)이 만들어졌다.

일본의 학교법인인 Eishin School(盈進学園, 영진학원)도 CA가 참여했고 이 과정이 "The Battle for the Life and Beauty of the Earth: A Struggle Between Two World-Systems"[4]에 담겨져 있다. 여기서도 위에서 이야기한 병원 설계와 유사하게 이해관계자들과 진행한 내용들이 담겨져 있다. 특히 8장을 보면 안드레의 사례와 비슷하게 이해 관계자들이 눈을 감고 상상하게 한다. 그런데, 이게 자신이 중요하다고 생각하는 구체적인 경험과 연결된다. 인터뷰이는 부끄러워 하기도 하고, 주저하기도 하지만 꿈같은 이야기를 꺼내게 된다. 이러한 과정을 통해 정리된 패턴 랭귀지는 수 개월에 걸처 이해관계자들에게 채택되게 된다. 이후 9개월에 걸처 부지에 직접 나아가서 병원에서의 사례와 같이 설계를 진행하는 과정을 거친다.

CA가 소프트웨어 공학에 많은 영향을 끼치기도 했고, 이러한 것들이 소프트웨어 설계에도 영향을 많이 미치고 있다고 생각된다. 위에서 CA가 사용한 방법을 보면, 이해관계자를 참여 시키는 것을 넘어 그 들에게 중요한 기능이나 활동 그리고 거기에 숨어 있는 요구 사항을 함께 찾는 것이 핵심인 것을 살펴 볼 수 있다. 이 부분을 소프트웨어 아키텍처 설계 측면에서 살펴 보면, 아키텍처 드라이버, 포스(force) 혹은 품질 속성(Quality Attribute)라는 것으로 볼 수 있다. 이런 것들을 발견하여 건축물의 "살아있는 구조"를 만들 수 있는 것처럼 소프트웨어의 "살아있는 구조"도 만들어 낼 수 있을 것으로 기대해 본다. 이러한 과정을 도와 줄 수 있는 것들이 도메인 주도 설계(DDD), Quality Attribute Workshop(QAW) 혹은 ATAM이 있다. 이러한 프로세스를 통해서 건축물을 설계할 때, 이해 관계자들과 소통하는 부분과 연결하여 이해할 수 있다.

참고문헌
[1] 크리스토퍼 알렉산더 "영원의 건축", 한진영 역, 안그라픽스 
[2] 크리스토퍼 알렉산더, 사라 이시가와, 머레이 실버스타인, "패턴 랭귀지" 이용근, 양시관, 이수빈 공역, 인사이트
[3] Christopher Alexander, "The Process of Creating Life: Nature of Order, Book 2: An Essay on the Art of Building and the Nature of the Universe", The Center for Envionmental Structure
[4] Christopher Alexander (Author), HansJoachim Neis Maggie Moore Alexander. 
"The Battle for the Life and Beauty of the Earth: A Struggle Between Two World-Systems", Center for Environmental Structure, 16 1st Edition

여기서는 Software Architect가 이해 관계자들과 아키텍처 평가를 진행하는 실 사례를 ATAM을 기준으로  살펴 보자.

 

Software Architecture 평가 방법에 대해서 [1]에서 CBAM 및 ATAM을 포함하여 설명하고 있다. 특히, ATAM 관련해서는 [2][3]에서 잘 설명하고 있다. ATAM의 예로서는 [4]에서 살펴 볼 수 있다. 특히, [2]에서 살펴 볼 수 있는 9가지 단계는 잘 살펴 보면 아키텍처를 설계하는 것과 같은 절차이다. 즉, 설계한 아키텍처를 이해관계자들에게 전달하는 것을 포함하여 설계의 평가에 대한 내용도 전달하는 것이다. 그렇다면, 어떻게 전달해야 하는 것일까?

 

ATAM 프로세스[2]

 

핵심은 위의 그림에 있다. 특히 분석(Analysis)가 가장 중심이 된다. 이 것의 입력으로 볼 수 있는 것이 품질 속성 시나리오(Quality Attribute Scenario)와 아키텍처 결정(Architectural Decision)이라고 볼 수 있다.

 

아키텍처 설계에서 중요한 것이 품질 속성이라고 볼 수 있다. 비지니스 드라이버(Business Driver)에서 품질 속성(Quality Attribute)를 도출하고 시나리오에 적용하여 분석한다. 이와 더불어 아키텍처에서 여러 접근법을 활용하여 아키텍처 결정(Architectural Decision)을 결정한다.

 

이를 기반으로 아키텍처 설계가 잘 되었는지 분석을 할 때, 트레이드오프(Tradeoff), 센세티비티 포인트(Sensitivity Point), 논리스크(Non-risk) 그리고 리스크를 도출하고 이것들이 영향을 미치는 설계를 반복하여 최종적인 설계가 완료될 때까지 검토를 하면 된다.

 

이해관계자들에게 이 부분을 어떻게 보여 주면 좋을까? 아래는 iPhone의 SharePlay와 유사하게 다른 사람들과 컨텐츠를 함께 보는 서비스의 설계 관련한 품질 속성으로 도출한 서버 비용(Server Cost)의 품질 시나리오(Quality Scenario) 측면에서의 ATAM 보고의 일부이다.

Scenario 공동 시청에 사용되는 서버 비용은 작아야 한다.
Environment 시스템 정상 동작
Stimulus 서비스 시작
Artifact 시스템
Response 서비스는 서버를 사용하여 서비스를 제공
Measure [Cloud 포함 서비스 운영 비용 < 월 $5000]
Architectural Decision Sensitivity Tradeoff Non-Risk Risk
Video/Control 분리 S1 T1 N1  
RTT 기반 성능 관리 S2 T2   R1
Sensitivity S1: 컨텐츠 공유 방안에 따라 서버 비용에 영향을 받는다.
S2: 사용자 간 재생 위치 최적화 방안에 따라 서버 비용에 영향을 미친다.
Tradeoff T1: Server Cost vs Modifiability
OTT 추가에 따른 수정용이성을 좋게 하기 위해서 실재 비디오 데이터를 다뤄야 하므로 서버 비용이 증가하고, 서버 비용을 줄이기 위해 비디오와 컨트롤을 분리하면 수정용이성이 나빠진다.

T2: Server Cost vs Performance
사용자간 재생 위치 최적화에 대한 서버 비용을 최소화 하려면 추가적인 통신을 하지 않도록 해야 한다. 하지만, 추가적인 성능 확보를 위한 추가적인 정보교환이 필요한 경우 서버 비용이 증가한다.
Non-risk N1: 비디오와 컨트롤을 분리하여 컨트롤만 서버가 담당하게 하여 서버 비용을 줄였다.
Risk R1: 사용자가 재생 위치 차이 최적화를 위하여 참가자들의 네트워크 상황을 파악하고 수집하여 기준 사용자 선정하는데 추가적인 통신을 수행하였다. 이를 위한 서버 비용 증가가 발생하였다.
Reasoning 사용자간 재생 위치 차이 최적화를 위하여 초가적인 통신이 발생하는데, 이를 위한 서버 비용 증가를 피하기 어렵다. 하지만, 이 부분 또한 기존 통신 필요 기능에 관련 기능 통합을 고려하여 추가 최적화를 진행하여 비용을 최소화하였다.
Architectural Diagram ** 편의상 구조도는 생략한다.

 

위의 내용에서 품질 시나리오는 설계시 도출된 것을 그대로 가져온다. 그리고, 이 품질 속성과 관련된 아키텍처 결정(Architectural Decision)을 가져오고, 분석(Analysis)를 통해 도출한 트레이드오프(Tradeoff), 센세티비티(Sensitivity), 논리스크(Non-risk) 그리고 리스크(Risk)를 설명한다. 특히, 트레이드오프는 아키텍처 결정에 따른 트레이드오프 관계의 품질 속성에 대해 상세한 설명이  필요하다. 또한 선택된 구조로 인한 리스크에 대해서 상세히 기술할 필요가 있다. 이를 위해서 리스크에 대해서 어떻게 관리해야 하는지에 대한 설명(Reasoning)도 반드시 있어야 한다.

참고 문헌

[1] 소프트웨어 구조 평가 모델 비교, http://blog.skby.net/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%ED%8F%89%EA%B0%80-%EB%AA%A8%EB%8D%B8-atam-cbam/

[2] 아키텍처 트레이드오프 분석 방법(ATAM), https://www.geeksforgeeks.org/architecture-tradeoff-analysis-method-atam/

[3] 소프트웨어 아키텍처 평가, https://www.slideshare.net/ssuserff7918/atam-19297511

[4] Rick Kazman, et al, "ATAM: Method for Architecture Evaluation," https://www.win.tue.nl/~wstomv/edu/2ii45/year-0910/00tr004.pdf

[5] iPhone SharePlay, https://support.apple.com/ko-kr/guide/iphone/iph861568c10/ios

+ Recent posts