오래된 SW 엔지니어의 평생 공부

크리스토퍼 알렉산더(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

스타워즈는 우리나라에서 크게 흥행하지는 않았지만, 프랜차이즈 영화로서는 인지도는 상당하다.  "May the Force be with you"는 스타워즈에서 제다이 기사들이 해어질 때 주로 쓰는 인사 말이다. "포스가 그대와 함께하길" 정도로 해석이 된다. 포스(Force)는 중국 무협 소설의 내공과 비슷한 것이라고 이해할 수 있다. 그렇다면, 소프트웨어 아키텍처에서의 포스(Force)는 무엇일까?

소프트웨어 아키텍처에 대해서 카네기 멜론 대학의 Software Engineering Institute를 이야기 하지 않을 수 없다. SEI 출신의 학자들 책인 'Software Architecture in Practice 소프트웨어 아키텍처 이론과 실제'[1]는 21년도에 4판까지 나와 있다. 이 책에서는 소프트웨어 아키텍처에서 "포스(force)"는 아키텍처 결정에 영향을 미치는 다양한 요소나 영향력을 의미한다. 이러한 포스는 기술적 요구사항, 비즈니스 전략, 사용자 요구 사항, 제약 조건 및 환경적 요인 등을 포함할 수 있다. 이 포스는 이 책의 특징인 품질 속성(Quality Attribute)로 정제되어 설계에 활용된다.

이외의 여러 문헌을 보았지만, 특히 패턴과 관련된 몇권의 책들에서 포스가 언급된다. 살펴 보았던 패턴 관련 문헌 중 가장 오래된 문헌은 브라이언 푸트와 조셉 요더의 "Big Ball of Mud"[2] 의 아래 내용이다.

By recognizing the forces and pressures that lead to architectural malaise, and how and when they might be confronted, we hope to set the stage for the emergence of truly durable artifacts that can put architects in dominant positions for years to come. The key is to ensure that the system, its programmers, and, indeed the entire organization, learn about the domain, and the architectural opportunities looming within it, as the system grows and matures.
아키텍처의 불쾌감을 유발하는 '포스과 압력'을 인식하고, 언제 어떻게 직면할 수 있는지 파악함으로써 향후 수년간 아키텍트를 지배적인 위치에 올려놓을 수 있는 아주 내구성 높은 산출물이 창발할 수 있는 발판을 마련할 수 있기를 바란다. 핵심은 시스템과 프로그래머, 나아가 전체 조직이 시스템이 성장하고 성숙함에 따라 해당 도메인과 그 안에서 다가오는 아키텍처 기회에 대해 학습하도록 하는 것이다.

이 글의 결론 부분에서 이야기하는 산출물은 패턴으로 볼 수 있다. 이 때, 포스는 패턴의 사용을 이끌어내는 여러 요소가 있다는 것을 이야기 한다고 볼 수 있다.

다른 책들의 경우는 객체 지향 리엔지니어링 패턴 "Object Oriented Reengineering Patterns"[3]에서는 각 장에서 패턴을 설명하기 전에 개요와 "포스: 주요한 요구사항(Forces)" 섹션이 있다. 즉, 관련된 패턴들이 공유하는 주요한 요구 사항들에 대해서 설명을 하고 패턴에 대해서 설명한다. 각 패턴이 집중하는 부분에 따라, 트레이드오프(Tradeoffs)가 존재하며 이에 따른 장점(Pros)와 단점(Cons)을 설명한다.

Patterns of API Design[4]의 경우도 여러 패턴을 다루는데, 여러 가지 포스/주요한 요구 사항 사이의 충돌(coflicting)이 있고, 이를 해소/해결(resolution)이 필요하다고 보고 있다. 또한 여기에는 트레이드오프(tradeoff)가 있다고 본다. 이러한 과정을 설계 결정(design decision) 혹은 아키텍처 결정(architecturla decision)이라고 한다. 책의 3장에서는 이러한 예제를 보여주는데, 다음과 같은 아키텍처 의사 결정 기록(architectural decision record, ADR) 형식을 제안한다.

[기능 또는 컴포넌트]에 해당하는 맥락에서,
[요구 사항 또는 목표로 하는 품질 속성(Quality Attribute)]을 충족할 필요가 있다,
우리는 [이익]을 우선적으로 달성하기 위해
[선택된 옵션]을 채택하기로 결정하고
그리고 [대안]은 선택하지 않아서
그 선택에 따르는 [부정적인 결과]는 받아들인다.


여러 아키텍처 책 혹은 디자인 패턴 책에서 언급하는 포스에 대해서 살펴 보았다. 앞에서 언급한데로 아키텍처에 영향을 미치는 드라이버(driver), 주요한 요구 사항, 혹은 품질 속성으로 보기도 한다. 이러한 부분은 아키텍처 결정에 어떤 영향을 미치는지 설명하는데 사용되기도 하고 패턴을 선택하는데도 사용되므로 이에 대해 이해하고 적절한 설계 결정, 즉 선택을 위해 고려되어야 한다.

참고문헌
[1] Len Bass, Paul Clements, Rick Kazman, "Software Architecture in Practice", SEI series in software engineering.
[2] Brian Foote and Joseph W. Yoder, "Big ball of mud", Pattern Languages of Program Design, volume 4, pages 654–692. Addison Wesley, 2000.
[3] Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz, "Object Oriented Reengineering Patterns"
[4] Olaf Zimmermann, Mirko Stocker, Daniel Lubke, Uwe Zdun, Cesare Pautasso, "Patterns for API Design: Simplifying Integration with Loosely Coupled Message Exchanges",  Addison-Wesley Signature Series

마틴 파울러는 [1]에서도 소개했지만, "Refactoring"으로 유명하고, 여러 저서의 저자이기도 하다. 그는 애자일리스트로 엔지니어링 실천법(engineering practices)에 집중하는 익스트림 프로그래밍(Extreme Programming, XP)의 추종자이다.
 
마틴 파울러의 웹사이트에서 여러가지 소개하고 있는데, 소프트웨어 아키텍처에 대해 설명하는 글[2]도 포함되어 있다. 여기서 그는 소프트웨어 아키텍처는 소프트웨어 "시스템의 중요한 내부 설계"를 의미한다고 정의 하며, 좋은 아키텍처는 시스템이 "진화"할 수 있도록 지원해야 한다고 강조한다. 이것이 마틴이 이야기하는 애자일 소프트웨어 아키텍처의 핵심이라고도 할 수 있겠다.마틴은 이 글에서 팀이 좋은 아키텍처를 만드는 방법과 아키텍처 사고를 어떻게 개발 조직에서 장려해야 하는지에 대해서도 이야기하는데 그내용도 살펴 보자.

아키텍처의 진화

마틴 파울러의 웹사이트에서 진화적 아키텍처는 요구사항의 변화를 수용하고 지속적인 피드백을 통해 시스템이 개선될 수 있도록 지원한다고이야기 한다. 그리고,  소프트웨어 아키텍처가 일회성 계획이 아닌 지속적인 과정으로 설명한다. 그리고, 이를 위해서 다음 사항에 대해서 강조한다.
 

• 반복적 개발과 피드백 루프: 소프트웨어 개발 과정에서 짧은 반복주기를 통해 지속적으로 통합하고 테스트하는 방식을 사용함으로써, 아키텍처를 점진적으로 발전시키는 방법을 강조한다. 이는 고도의 협업과 지속적인 개선을 가능하게 한다.
• 피트니스 펑션의 활용: 아키텍처의 상태를 모니터링하고 진화의 방향을 가이드하는 데 사용되는 '피트니스 펑션' 개념을 사용하여 아키텍처의 건강을 측정하고 관리한다.
• 데이터 관리의 중요성: 진화적 아키텍처에서는 오래 지속되는 데이터의 처리가 종종 간과되기 쉬운 문제로, 이에 대한 강조를 통해 데이터 관리와 관련된 전략을 체계적으로 다루어야 함을 강조한다.
• 마이크로서비스와 도메인 주도 설계: 큰 단일 시스템을 더 작고, 독립적으로 관리 가능한 마이크로서비스로 분해하는 과정에서, 중요한 비즈니스 기능을 식별하고 이를 기반으로 서비스를 분리하는 전략을 사용한다. 이는 시스템의 유연성을 높이고, 변경 관리를 용이하게 한다.

마틴이 늘 강조하듯이 이러한 점들은 소프트웨어 아키텍처가 단순히 기술적인 문제가 아니라, 지속적인 비즈니스 가치를 창출하고 유지하는 중요한 역할을 한다는 것을 강조한다. 진화적 아키텍처 접근 방식은 변화하는 비즈니스 요구와 기술 환경에 효과적으로 대응할 수 있도록 돕는다고 설명한다.
 

팀이 만드는 좋은 아키텍처

마틴은 아키텍처가 팀에서 나온다고 믿는데, 팀이 좋은 아키텍처를 만드는 방법에 대해 다음과 같이 설명한다.

• 지속적인 학습과 피드백: 팀은 반복적인 피드백 루프를 통해 아키텍처를 지속적으로 개선해야 한다.
• 협업과 소통: 개발자 그리고 여러 이해관계자 간의 긴밀한 협업이 필요하다.
• 작은 변경의 관리: 아키텍처를 점진적으로 변화시켜야 하며, 이는 작은 단위의 변경을 통해 이루어져야 한다.
• 자동화와 테스트: 지속적인 통합과 테스트 자동화를 통해 아키텍처의 품질을 유지해야 한다

개발조직이 아키텍처적 사고를 가지는 방법

팀이 아키텍처 사고를 가지기 위해서 마틴은 다음 사항들을 강조하고 있다:

• 교육과 훈련: 팀원들에게 아키텍처 원칙과 패턴을 교육한다.
• 협업 문화: 개발자 간의 적극적인 협업을 촉진하여 아키텍처 관련 논의를 장려한다.
• 피드백 루프: 정기적인 코드 리뷰와 피드백을 통해 아키텍처 품질을 유지하고 개선한다.
• 실험과 혁신: 새로운 아이디어와 접근 방식을 실험할 수 있는 환경을 조성한다.

참고 문서

[1] 로버트 마틴 vs. 마틴 파울러, https://technical-leader.tistory.com/94
[2] Martin Fowler, "Software Architecture Guide", https://martinfowler.com/architecture/

소프트웨어 아키텍처 공부를 시작하고 알게되어 한빛 출판에 번역을 제안하여 운 좋게 진행한 조지 페어뱅크스의 "Just Enough Software Architecture: A Risk-Driven Approach"[1]은 성공적으로 소프트웨어를 만드는 것이 "가능한 실패를 예상하고 실패할 수 있는 설계를 피하는 것을 의미"한다고 이야기 한다. 그렇기 때문에 실패 리스크를 찾고 이것에 매핑하는 소프트웨어 설계 테크닉을 적용하는 것이라고 한다.

책에서 말하는 리스크 주도 모델의 경우는 다음과 같은 단계를 거치면서 반복하는 과정이라고 말한다.

1. 리스크 식별/우선 순위 지정
2. 적용할 테크닉 선택/적용
3. 리스크 감소의 평가

소프트웨어 개발은 설계만으로 끝나는 것이 아니고 구현을 해야 한다. 그러므로 다음과 같은 예의 논리를 바탕으로 진행하는 것을 제안한다.

"A, B 그리고 C를 리스크로 식별하고, B는 매우 중요하다. 이를 위한 테크닉 X와 Y를 통해 B의 리스크를 줄일 수 있다고 판단했다. 결과물인 설계를 평가했을 때, B의 리스크가 충분히 완화되어 구현을 계속 했다."

리스크란 무엇인가?

책에서 이야기 하는 리스크의 정의는 "인지된 실패 확률*인지된 영향"이라고 정의 한다. 즉, 인지되지 않은 실패 혹률을 리스크로 판단할 수 없고, 실패로 인한 소프트웨어 프로젝트로의 영향도 파악할 수 없다면 리스크는 확인할 수 없는 것이다.

리스크의 구분은 크게 엔지니어링 및 프로젝트 관리 리스크로 나눈다. 일반적으로 엔지니어링 리스크는 제품의 분석, 설계 및 구현과 관련된 사항이고, 프로젝트 관리 리스크는 일정, 작업 순서, 팀 규모 등과 관련된 것들이다. 여기서 말하는 리스크는 엔지니어링 리스크와 관련되고 이를 해결하기 위한 엔지니러링 테크닉을 적용하는 것이 일반적이다.

리스크의 식별의 경우는 요구 사항에서 하는 것이 일반적이다. [2]에서 설명한 것과 같이 소프트웨어의 요구 사항에서 아키텍처적으로 중요한 요구 사항(Acrhitectural Significant Requirement, ASR)을 추출과 연결 시켜 보면, 추출된 요구 사항(기능적 그리고 비기능적 요구사항/품질 속성)에서 중요한 것을 찾는 것이 기존 방법과 다르게 리스크라는 관점에 중점에 두고 선정하는 것이 차이일 수 있다. 여기서 가장 달성하기 어려운 것을 찾는 것이 방법이라고 할 수있다.

개발하는 소프트웨어의 도메인에 따라 주로 발생하는 원형적 리스크(Prototypical Risk)도 있다. 예로는 아래와 같은 것들이 있다.

적용 테크닉

리스크를 인식하고 나면 리스크를 줄일 수 있을 것으로 예상 되는 테크닉(Techique)을 적용할 수 있다. 조지 페어뱅크스는 기존에 방식에서 지혜를 얻고 있다. 소프트웨어 아키텍처 설계에서 사용되는 전술(Tactics)[3] 혹은 패턴(Pattern)을 예로 들고 있다.

이와 같은 테크닉은 수 없이 많을 수 있다. 하지만, 시간과 돈을 낭비하지 않으려면 우선 순위가 지정된 리스크 목록을 가장 잘 줄이는 테크닉을 선택해야 한다. 즉, 최적화 문제로 생각하고 접근해야 한다. 이러하듯, 엔지니어링 리스크를 완전히 제거할 수 없는 이유는 주로 프로젝트 관리 리스크인 비엔지니러링 리스크와 균형르 이루어야 하기 때문이라고 책[1]에서는 이야기한다.

이와 같은 제약 뿐 아니라 적용할 테크닉의 선택을 위해서 문제의 종류(답을 찾는 문제/증명 문제), 모델의 종류(분석 모델 및 유추 모델)에 따라 다르다고 한다. 그리고, 설계를 바라 보는 관점이라고 할 수 있는 뷰타입(Viewtype)의 경우는 리스크와 테크닉의 쌍(Pair)에 효과를 다르게 하기 때문에 어떤 것이 적절한지 매칭(matching)을 고려해야 한다고 이야기 한다.

언제 멈추는가?

소프트웨어 아키텍처를 설계에는 중요한 두가지 질문은 "어떤 테크닉을 사용하는가?" 그리고 "얼마나 설계와 아키텍처를 수행하는가?"라고 할 수 있다. 리스크 주도 설계에서는 아주 단순히 답한다면 "충분히 리스크가 줄어 들 때까지 설계한다"가 답일 수 있다.

이를 위해서는 설계에 들이는 노력은 "리스크에 상응해야 한다"라고 한다. 저자는 아버지의 집앞에 우편함을 만드는 이야기를 하면서 단순하게 땅을 파고 우편함을 묻기만 하면 될 일을 위해서 측량을 한다거나와 같은 높은 건물 건축에서 사용되복잡한 설계나 리스크를 측정하는 테크닉을 적용할 필요가 없다는 것이다.

불완전해 보일 수 있지만, 리스크 모델에서는 리스크가 인식되는 영역만 설계한다는 부분과 리스크 평가가 주관적인 평가라는 부분 또한 언급한다. 이 부분은 단점일 수 있지만, 여전히 장점이기도 하다. 

계획된 설계와 진화적 설계

책[1]에서는 소프트웨어 개발에 사용되는 설계 접근 방식을 계획된 설계(Planned design)과 진화적 설계(Evolutionary design)으로 나눈다. 리스크 주도 설계는 이 두가지 설계 방식에 모두 적용 가능하다고 책에서는 주장한다.

진화적 설계의 경우, 주로 애자일 소프트웨어 개발 방식에서 사용하는 방식이다. 시스템이 구현됨에 따라 설계가 확장되기 때문에 지협적이고 파편화된 설계 결정이 여러 문제를 발생 시킨다. 이러한 단점을 해결하는 방법으로 리펙터링(Refactoring), 테스트 주도 설계(Test drivn design), 지속적인 통합(Continous integration)이 제안되어 채영되고 있다. 여전히 아키텍처적 입장에서는 좋은 지침에 제공되고 있지 않다고 지적하고 있다.

계획된 설계는 진화적 설계의 반대쪽 끝에 있다고 설명하며, 실재 구현 이전에 설계를 자세하게 작성하는 것이다. 하지만, 이는 지나친 선행 설계(Big Design Up Front BDUF)라고 비판을 받는다. 앞에서도 이야기 한 저자의 아버지 우편함에 대한 예가 주요 내용이라고 볼 수 있다.

위의 두 가지는 양쪽 극단이다. 마치 스펙트럼 같은 것일 수 있다. 이 중간에는 최소 계획된 설계(Minimal planned design) 또는 작은 선행 설계(Little Design Up Front LDUF)가 있다. 

이러한 접근 방법들은 서로 다른 지지자들이 있다. 또한 책에서는 만병통치약이 없듯이 다른 시스템에서는 다른 방법이 적절하다고 이야기 한다. 또한 둘은 다르고, 장점 또한 다르다. 이케텍처 설계를 한다는 것은 장기적인 관점을 가지고 시스템 전체의 속성을 보장하는 장점을 가진다. 진화적 설계는 앞에서 살펴 보았듯이 리펙터링, TDD 그리고 지속적 통합(CI)의 장점을 활용할 수 있다.

프로세스에 적용하기

리스크 주도 소프트웨어 설계를 여러 프로세스에 적용하기 위해서 몇가지 프로세스의 특징을 우선 아래와 같이 정리하고 있다.

우선 애자일 개발 프로세서인 eXtream Programming(XP)에서는 일반적으로 설계 작업이 없지만 반복 제로(Iteration zero)를 두고 설계 작업을 할 수 있다. 이렇게 반복적인 작업에서 리스크 주도 기반 접근법은 각 단계에서 필요한 만큼 설계 작업을 진행할 수 있다.

대표적인 애자일 프로세스인 스크럼은 기능 중심적 접근 방법으로 백로그에 구현할 기능을 관리한다. 여기에도 리스크 주도 접근법을 적용할 수 있다. 일반적인 기능 백로그는 제품 책임자(Product Owner)가 담당한다. 재품 책임자는 엔지니러링 리스크를 파악하기 어렵다. 대신 소프트웨어 팀이 리스크를 파악하고 이를 시스템의 테스트 가능한 기능으로 만들어 백로그에 넣을 수 있다. 이는 각 반복이 끝날 때 회고(Reflection/Retrospective)의 결과로 도출될 수 있다. 제품 책임자는 백로그 중에서 우선 순위에 따라 각 단계에 수행할 내용을 결정할 수 있다.

정리해보면...

리스크 주도 설계 접근 방식의 주요 내용은 설계에 많은 비용이 들기 때문에 리스크를 찾아 내고 이에 적절한 테크닉을 필요한 만큼 반복적으로 적용한다는 것이다. 이는 현재 소프트웨어 개발에서 적용되고 있는 양극단의 소프트웨어 개발 방법에서 모두 적용할 수 있다고 책에서는 주장하고 있다.

특히, 애자일 혹은 반복적 개발에서 알 수 있는 주요한 내용 중 하나가 설계가 항상 개발 프로세스의 앞부분에서만 진행되어야 하는 것은 아니라는 점이다. 후반부에 설계를 하게 되면설계를 변경하기 어려운 부분도 있을 수 있으나 구현하려고 하는 소프트웨어를 초기에는 잘 알지 못하는 문제점도 있다는 것을 책에서는 지적하고 있다. 소프트웨어 개발이 지식을 얻어 가는 과정이라면, 이를 이를 소프트웨어 설계 및 아키텍처링에 적용하는 방법으로서 리스크 주도 접근 방식의 장점과 적용하는 방법에 대해서도 흥미로운 재안을 하고있다.

참고 도서

[1] George Fairbanks, "Just Enough Software Architecture: A Risk-Driven Approach," 2010

[2] "Software Architecture: 어떻게 설계 할 것인가?," https://technical-leader.tistory.com/35

[3] 렌 베스 , 폴 클레멘츠 , 릭 캐즈먼, "소프트웨어 아키텍처 이론과 실제, 개정판 3판" 2015년, 에이콘출판

[4] Design Pattern 배우기, https://technical-leader.tistory.com/7?category=1015396 

소개

이 글[1]은 2015년도 글이기는 해도, 최근에 발견했다. 애자일 과정과 기존의 Software Architecture 접근법에 대한 고찰이 포함되어 있어 참고할만한 글이다.

Towards an Agile Software Architecture

소프트웨어 아키텍처는 시스템의 골격(Skeleton)이다. 다른 기능적 요구 사항(Functionall Requirements)과 비기능적 요구 사항(Non-functional requirements)으로 시스템이 작동하는 방식을 정의한다. 한편으로 전통적인 워터폴 방식은 프로젝트 개발의 모든 단계에 강한 제약을 가하기 때문에 엄격하다. 반면에 애자일 접근법은 개발 단계 후반에도 변경 사항을 환영한다. 우리는 견고한 개발에서보다 유연한 개발로 전환하고 있지만, 소프트웨어 아키텍처는 골격(Skeleton)이라는 태생상 기본 특성으로 인해 변화에 민감하다. 따라서 애자일 접근법을 따라갈 때 핵심 요소는 지속 가능한 소프트웨어 아키텍처의 개념을 수용하는 것이다. 이는 프로젝트의 복잡성 증가와 함께 시스템 확장이 점진적이고, 쉽고, 유지 보수 가능한 방식으로 이루어질 수 있도록한다.

이 글에서는 기존의 워터폴 소프트웨어 아키텍처와 애자일 아키텍처 모두에서 작업 할 때의 경험을 다룬다. 나는 세 가지 영역에 중점을 둔 이들의 유사점과 차이점을 묘사한다.

• 소프트웨어 아키텍트 역할의 세부 사항
• 소프트웨어 아키텍처의 타임스팬(Timespan)
• 소프트웨어 아키텍처의 결과물

소프트웨어 아키텍처란 무엇인가?

소프트웨어 아키텍처에 대한 정의는 수백 가지가 있다 (실제로 새로운 본인의 정의를 직접 추가 할 수도 있음). 그 이유는 모든 사람이 자신의 상황에 따라 정의하기 때문이다. 나는 특히 IEEE의 정의를 좋아하는데, 기본 개념을 설명하고 머리에서 쉽게 그려 볼 수 있기 때문이다. 또한 소프트웨어 아키텍처의 생성 방식이 아니라 소프트웨어 아키텍처의 본질을 묘사하기 때문에 워터폴 및 애자일 프로세스에 모두 적용된다. 이 글의 나머지 부분에서 나는 이 정의를 언급 할 것이다.

구성 요소(Components) 서로와 그리고 환경(Environment)과의 관계(Relationship), 설계 및 진화(Evolution)를 안내하는 원칙으로 구현되는 시스템(System)의 기본 구조(Fundamental Organization)

워터폴 소프트웨어 아키텍처

기존의 워터폴 개발은 시작 날짜와 종료 날짜가 명확한 일련의 단계로 구성되며, 각 단계에는 특정 활동 세트가 포함된다. 모든 단계는 서로 연결되어 있으며 각각의 단계는 이전 단계에서 생성된 결과물에 크게 의존한다. 그림 1은 폭포 개발과 관련된 일반적인 단계를 보여준다.

소프트웨어 아키텍처에 대한 작업은 일반적으로 소프트웨어 요구 사항이 정의 된 후에 시작된다. 이 시점에서 시스템은 수행해야 할 작업에 대해 잘 정의되어 있다고 가정한다. 다음 단계는 소프트웨어 아키텍처를 정의하는 담당자와 이 단계의 실제 결과를 조사하는 것이다.

전통적인 소프트웨어 아키텍트

소프트웨어 아키텍처는 실제로 소프트웨어 아키텍트가 수행한다. 기술 지식과 경험이 풍부한 사람이다. 일반적으로 회사의 특정 수준에 도달한 후 승진 한 개발자이다. 이 사람은 소프트웨어 요구 사항을 분석하고 이러한 요구 사항을 기반으로 미래 시스템에 대한 특정 기술 결정을 담당한다. 많은 회사에는 일반적으로 프로젝트 당 하나의 소프트웨어 아키텍트가 있지만 일부 대기업에는 소프트웨어 설계자 팀이 함께 작업 할 수 있다. 이는 일반적으로 프로젝트 도메인이 복잡하거나 프로젝트의 기간이 더 큰 경우 (예 : 2-3 년 이상)이다. 모든 회사에 지정된 소프트웨어 아키텍트 역할이있는 것은 아니다. 많은 회사에서 이러한 책임을 경험 많은 개발자(Senior Developer)에게 위임한다. 이 글의 나머지 부분에서는 명시적으로 언급하지 않는 한 소프트웨어 아키텍트는 다른 누군가가 하지 않고 소프트웨어 아키텍트가 수행하는 특정 활동을 언급한다.

전통적인 소프트웨어 아키텍트는 다음과 같은 네 가지 주요 기능을 담당한다.

• 큰 그림에 초점을 맞춘다. - 소프트웨어 아키텍트는 시스템이 향후 몇 달 (때로는 몇 년)처럼 어떻게 보일지 고려해야한다. 또한 관련된 다른 모든 시스템 (예 : 타사 시스템 및 데이터 저장소)과 시스템 간의 통신이 어떻게 진행 될지 고려해야 한다.
• 규정 준수 지향 - 소프트웨어 아키텍트는 가능한 규정 준수 문제를 고려해야 한다. 이것은 입법 규범, 라이센스, 표준 또는 기타를 포함하여 미래의 시스템이 이러한 중요한 기준을 충족하도록 해야한다.
• 청사진을 생성한다. - 중요한 산출물은 다양한 관점에서 아키텍처를 설명하는 문서 및 다이어그램 모음이다. 개발 팀은 이러한 결과물을 사용하여 시스템 구축을 시작한다.
• 실무 경험이 많지 않음 - 소프트웨어 아키텍트의 목표는 개발 팀을위한 최종 문서를 작성하는 것이다. 소프트웨어 아키텍트는 일반적으로 개발자로서의 경험이 있지만 개발 프로세스에는 거의 관여하지 않으며 개발자가 설계 시스템을 구축하도록 유도한다. 어느 시점에서 그는 개발자는 남겨 두고, 다른 프로젝트로 이동할 수 있다. 

실제 사례의 고통 

나는 세계에서 가장 큰 맥주 회사 중 하나를 위한 소프트웨어 프로젝트를 진행하고 있다. 이 프로젝트를 완료하는 데 2-3 년이 걸렸으며 일반적인 워터폴 방식으로 수행 되었기 때문에 소프트웨어 아키텍트, 개발자, 테스터 등 여러 단계를 담당하는 사람들이있었다. 나는 소규모 팀의 개발자였으며 ​​소프트웨어 아키텍트로부터 시스템 개발 수행 방법에 대한 지시와 가이드라인을 받았다. 처음에는 소프트웨어 아키텍트가 우리를 지원하기 위해 팀에 있었지만 나중에 그 프로젝트의 작업량이 줄어들면서 다른 프로젝트로 옮겼다. 제안 된 소프트웨어 아키텍처는 정의된 경계에 맞지 않는 새로운 종속성이 등장함에 따라 어느 시점에서 따르기가 어려워졌다. 수석 개발자가 아키텍처 비전을 인수하려고 했지만이 프로젝트는 소위 스파게티 코드로 성장했다.이 프로젝트는 다른 곳에서 문제를 일으킬 수 있으므로 모든 사람이 변경을 두려워 했다. 불행히도 프로젝트를 정상 괘도에 올릴 수 있는 과감한 변화를하기에는 너무 늦었었다. 우리는 프로젝트를 출시했지만 나중에 결국 종료되었다.

애자일 접근법

기존의 워터폴 구조는 시작 날짜와 종료 날짜가 명확한 일회성 활동이지만, 애자일 소프트웨어 아키텍처는 진행중인 프로세스이므로 결코 끝나지 않을 수 있다. 이를 통해 필요한 경우 아키텍처 변경 사항을 정기적으로 적용 할 수 있다. 프로젝트의 변화를 환영하는 메커니즘 중 하나는 반복적이고 점진적인 개발을 적용하는 것이다. 스크럼에서는 이러한 반복을 스프린트라고하며 하나의 스프린트는 일반적으로 그림 2에 표시된대로 2-4 주 사이에 지속된다. 이러한 작은 간격을 사용하면 발생하는 모든 변경 사항에 대해 바로 바로 논의 할 것이다. 또한, 팀 협업에 중점을 두고 있으며 오해와 의사 소통이 원활치 않은 것을 방지하며 팀원 간의 문제를 즉시 해결한다.

애자일 접근법을 통해 프로젝트의 변화를 환영할 수 있지만 얼마나 빠르게 대응해야하는지 알려주지는 않는다. 소프트웨어 아키텍처는 시스템의 백본이므로 변경에 따라 움직인다. 예를 들어, 프로젝트 중간에 사용하는 플랫폼이나 언어를 변경할 수 있다고 생각하는가? 드물기는하지만 이러한 변경에는 많은 추가적인 이터레이션을 필요로 한다. 심지어 프로젝트의 시작 부분으로 돌아갈 수도 있다. 소프트웨어 아키텍처와 관련하여 일부 유형의 변경은 고통스럽고 구현하는 데 시간이 걸린다.

애자일 소프트웨어 아키텍트

스크럼은 세 가지 유형의 역할을 정의한다.

• 제품 소유자(Product Owner) - 특정 비즈니스 도메인에 대한 정보를 제공한다.
• 스크럼 마스터 - 팀의 의사 소통 및 협업 촉진 한다.
• 개발팀 - 사용자 스토리을 구현하고 작동하는 소프트웨어를 제작한다.

전통적인 소프트웨어 아키텍트 역할을 애자일 개발에 맞는 역할로 변환하기 위해 가능한 변형을 살펴 봐야한다. 스크럼 팀을 구성하는 한 가지 방법은 개발자 팀과 별도의 소프트웨어 아키텍트 팀이 긴밀하게 협력하는 것이다. 그림 3은 이 시나리오를 여러 스크럼 팀에 적용한 것을 보여준다.

이것이 팀을 구성하는 올바른 방법이지만 두 가지 문제가 있다.

• 소프트웨어 아키텍트 팀은 수요자(Demander)가 될 수 있지만 개발자 팀은 일반적으로 워터폴 접근 방식의 경우 생산자(Producer)입니다. 소프트웨어 아키텍트는 비전을 정의하고 개발자는 비전을 구현해야한다. 이는 개발자를 관여시키지 않고 정중하게 다루지 않으면 개발자 간의 동기를 감소시킬 수 있다.
• 위의 결과로 일부 개발자는 다른 개발자가해야 할 일을 선택할 수 있도록 소프트웨어 설계자 팀의 일원이되기를 원할 수 있다. Trustpilot은 핵심 팀과 개발 팀을 보유한 사례를 제시했지만, 이는 작업장과 공동 작업에 대한 도덕을 감소 시켰기 때문에 핵심 팀의 각 구성원을 하나의 개발 팀으로 옮겼다. 이는 긍정적인 결과를 낳았다.

또 다른 방법은 소프트웨어 아키텍트를 그림 4와 같이 개발 팀에 직접 배치하는 것이다.

이 경우 애자일 소프트웨어 아키텍트는 약간 다른 책임을 갖는다.

• 큰 그림과 현재의 균형 – 민첩한 소프트웨어 아키텍트는 전체 시스템의 큰 그림에 맞춰 개발하는 동안 발생하는 상황을 고려해야 한다.
• 실무 경험 – 애자일 소프트웨어 아키텍트는 개발자이며 시스템 구현 작업을 한다. 이것은 선택된 구조적 결정(architectural decision)에 대한 직접적인 피드백을 제공한다.
• 결정 사항을 설명할 수 있도록 프로토 타입을 제작 - 중요한 기술적 결정을 내려야 할 경우, 빠른 프로토타입을 통해이 결정이 가능한지 여부와 기존 시스템에 어떤 영향을 미치는지 알 수 있다. 또한 전체 개발 팀과의 커뮤니케이션은 개인 개별 활동이 아닌 공동 노력해야 하는 것으로 필수적이다.
• 지속 가능성에 초점 – 구조적 결정(architectural decision)이 지속 가능한 소프트웨어 아키텍처를 이끌어내는 것이 매우 중요하다. 이는 장기적으로 프로젝트를 지원할 것이다. 이것의 필수 부분은 개인적인 책임과 공감이다. 애자일 소프트웨어 아키텍트는 개발 팀의 일원이므로 위에서 설명한 의사 결정을 통해 직접적인 피드백을 받는다. 이는 워터폴에서 접근하는 방식과 달리 개인의 책임 수준을 높이며, 결정은 개발 팀에 전달되어 구현된다.

다른 개발 팀 (및 프로젝트)간에 구조를 공유하려는 경우 별도의 소프트웨어 설계자 팀과 함께 구조를 선택할 수 있다. 또한 많은 관점을 고려해야하는 복잡한 도메인에서 작업하는 경우, 이 구조를 적용 할 수도 있다. 그러나 이 경우 소프트웨어 아키텍트가 개발자와 긴밀하게 협력하고 지원하도록 해야한다. 애자일 방법론은 협업에 중점을 두므로 소프트웨어 아키텍트를 개발자와 분리하면 협업이 어려워진다. 결과적으로 개발 프로세스는 워터폴 모델에 가까워진다. 나는 개인적으로 팀 구성원 간의 의사 소통이 향상되기 때문에 각 개발 팀에 한 명의 소프트웨어 설계자가 존재하는 두 번째 변형을 선호한다. 선임 아키텍트(High level architects)는 여전히 서로 협력 할 수 있다 (꼭 그렇게 해야 한다).

애자일 소프트웨어 아키텍처의 타임스팬

애자일 소프트웨어 아키텍처의 중요한 측면은 언제 시작하는가 이다. 우리가 잘 정의 된 단계를 가지고있는 워터폴 모델과는 달리, 애자일 세계에서는 사람들이 시작 단계라 정의 하는 특정 항목이 없다. 일반적인 접근 방식 중 하나는 스프린트 #0을 진행하는 것이다. 개발 환경을 구성하고 프로그래밍 언어, 플랫폼, 데이터베이스 등과 같은 몇 가지 기본 결정을 내리는 특수 스프린트이다.

그러나 이러한 접근 방식의 일반적인 함정은 사람들이 항상 “거의 준비되었다”고하면서 이 기간을 연장하는 경향이 있다는 것이다. "일주일 더 있으면 정규 스프린트를 시작할 수 있다"라는 말이 종종 들린다. 많은 경우에, "사전 도움말 기능을 미리 구현하는 것이 정말 멋지므로"라며서 유저 스토리없이 시스템에 이미 작업하고있는 것을 알 수 있다. 이러한 상황에서는 스프린트 #0의 종료 날짜에 미리 동의해야 한다. 이는 스프린트 지속 시간 또는 그와 유사한 기간이 될 수 있다.

정규 스프린트가 시작될 때 아키텍처가 준비되지 않은 경우 어떻게 될지 궁금 할 것이다. 글쎄, 그래도 괜찮다. 실제로 준비되지 않았을 수 있다. 그리고 그것 또한 괜찮다. 소프트웨어 아키텍처는 지속적으로 진행되는 프로세스이다. 이것은 시스템의 골격이므로 항상 되돌아와 수정해야한다. 당신의 아키텍처가 필요한 것을 충분히 지원하지 않는다면 시스템을 개발할 여유가 없다. 사이먼 브라운(Simon Brown)의 말을 인용해 보자 :

기민한 팀(Agile Team)이 반드시 기민한 소프트웨어 아키텍처(Agile Software Architecture)를 만들지는 않는다.
그러나 좋은 아키텍처는 기민성(Agility)을 가능하게한다.

관리 원칙

우리가 사는 세상은 복잡하며 모든 비즈니스 영역도 마찬가지이다. 소프트웨어 아키텍처를 구축 할 때는 처음부터 작업을 너무 복잡하게하면 결과적으로 오류가 발생하기 쉽다. 의사 결정시 두 가지 원칙이 사실상의 표준이되었다.

• 바보야, 단순하게 해 (Keep It Simple, Stupid. KISS)
• 넌 그것을 필요로하지 않을 거야 (Your Aren't Gonna Need It. YAGNI)

이 두 가지 원칙이 지키려고 하는 것이 바로 그 순간에 특정 기능이나 결정이 필요한지 생각하게 하는 것이다. 나중에 결정을 연기 할 수 있다면 아키텍처를 단순하게 유지하여 더 오랜 시간 동안 쉽게 관리 할 수 ​​있다. 소프트웨어 아키텍처가 복잡 해지는 일반적인 방법 중 하나는 추상화를 도입하는 것이다. 이 형식은 데이터를 한 형식으로 복사하여 다른 형식으로 변환하는 새로운 고급 레이어 일 수도 있고, 코드 100 % 테스트 가능하게 하기 위해 많은 클래스, 인터페이스, 팩토리 등을 생성하는 것일 수도 있다. .

그러나, 이 두 가지 원칙을 적용 할 때 한 가지 함정은 우리가 마지막 순간까지 모든 것을 지연시키는 경향이 있다는 것이다. 그때에는 필요한 변경을 구현하기가 이미 너무 어려워 졌을 수 있다. 대신 우리의 임무는 훨씬 더 어렵다. 왜냐하면:

우리는 마지막 순간이 아닌 가장 적정한 시간(Most Responsible Time)에 결정을 내려야 하기 때문이다 

구조적 결정을 내리려고 할 때, 결정의 확실성이 높은 경우, 일반적으로하는 일이 시간이 많이 걸리지 않는 작은 준비를하는 것이다. 나는 또한 동료들과 상의하고 함께 토론한다.

실제 상황의 고통

온라인 페리 티켓 판매에 관한 프로젝트를 진행하고 있었다. 다른 4 개의 타사 시스템과 통신해야했기 때문에 복잡한 시스템이었다. 처음에는 주로 사용자 스토리를 기반으로 기능을 구현하는 데 중점을 두었다. 우리는 정교한 캐싱 메커니즘이 필요하다는 것을 알고 있었지만 그 순간에 필요하지 않았기 때문에 이를 지연시켰다. 당시 사용자 스토리에 집중해야 했다. 그러나 나중에 다른 타사 시스템과의 광범위한 통신으로 인해 시스템 속도가 느려졌다. 우리는 다른 선택의 여지 없이 사용자 스토리에 대한 작업을 중단하고 캐싱 메커니즘에 초점을 맞추어야 했다. 그 때에는 이미 구현하기가 어려웠다.

문서를 작성하는 방법

워터폴 접근 방식은 단계 간에 정보를 전송하는 데 문서가 사용되므로 각 단계에 관련된 사람들이 광범위하게 문서를 작성해야한다. 이 작업은 시간이 많이 걸리는 프로세스 일뿐만 아니라 잘못 설명된 기능으로 인해 오해로 이어질 수 있다. 또한 개발 속도가 빨라지면, 문서가 더 이상 이를 반영하지 않기 때문에 문서를 최신 상태로 유지하기가 어렵다. 코드 작성하기 위해 반복(Iteration)을 하는 애자일 접근법을 사용하면, 문서 작성도 유사하게 수행할 수 있다. 우리는 시스템의 중요한 측면만을 설명하고 시작한 다음 필요할 때 지속적으로 더 많은 정보를 추가한다.

문서화 내용(What to Document)

동일한 형식을 여러 형식으로 여러 번 문서화하지 말자. 예를 들어 코드에서 다이어그램을 생성하는 데 도움이되는 도구가 있다. 이 도구는 사용되지 않는 경향이 있으므로 별도의 다이어그램을 만드는 대신 매우 편리 할 수 ​​있다. 또한 시스템의 특정 측면을 설명하기 위해 시각적 산출물을 작성한 경우 단어로 동일한 내용을 설명하는 광범위한 텍스트 문서를 작성할 필요가 없다 (세부 사항을 추가하지 않으면 시각적으로 표현할 수 없음). 여기서 중요한 점은 당신과 당신의  팀은 사용 된 도면 표기법에 대한 일반적인 이해가 필요하다는 것이다.

문서화하는 방법

소프트웨어 아키텍처를 문서화 할 때 UML이 최선의 방법이라고 생각할 수 있다. UML은 표준이며 모든 사람이 알고 있으며 대학에서 이를 가르치므로 조직의 모든 사람을 통합할 수있는 도구 중 하나다. 내 경험에 따르면 실제로 UML을 사용하는 사람은 거의 없다. 그 이유 중 하나는 다른 관점에서 시스템을 설명하는 많은 방법이 있기 때문에 정기적으로 사용하지 않으면 좌절 할 수 있습니다.

애자일 세계에서 소프트웨어 아키텍처를 문서화하기위한 특정 도구는 없다. 화이트 보드 그림, Post-It 메모, 텍스트 문서, 위키 등을 사용할 수 있다 (아래 그림 참조). 실제로 2-3 개의 다른 산출물 형식만 사용하는 것이 더 안전하다. 그렇지 않으면 해당 형식을 저장하고 정보를 검색하기가 어려워 질 수 있습니다. 예를 들어, 그림을 그린 후에 화이트 보드 사진을 찍어야 디지털 버전의 다이어그램을 만들 수 있다. 그러나 나중에 편집해야하는 경우 디지털 방식으로 편집 할 것인지 화이트 보드에 다시 그릴 것인지 새 사진을 찍을 것인지 선택해야한다.

결론

소프트웨어 아키텍처는 미래 시스템의 골격(Skeleton)을 정의한다. 이것은 선과 점이있는 다이어그램이 아니라 코드 자체를 포함하여 시스템 개발을 관리하는 완전한 결정 세트(Decision Set)이다. 모든 결정은 타협이므로 신중하게 고려해야 한다. 애자일 사고 방식은 요구 사항이 다소 안정적 일 것으로 예상되는 기존 워터폴 모델과 달리 프로젝트 후반에도 변화에 개방적이어야 한다. 그러나 시스템 골격의 변경이 항상 구현하기 쉽지는 않으며 개발 프로세스를 이전으로 되돌릴 수도 있다. 따라서, 마지막 순간까지 결정을 지연시키지 말고 그 시점에 필요하지 않은 것을 구현할 위험이 적더라도 가장 적정한 결정(Most Responsible Decision)을 내리는 것이 중요하다. 또한 애자일 소프트웨어 아키텍처는 모든 사람이 구축 할 수있는 지속 가능한 플랫폼을 만들기 위해 큰 그림과 "지금"을 복합적으로 혼합해야 한다.

번역의 결론

이 글을 읽으면서 가장 기억에 남은 문구는 가장 적정한 결정(Most Responsible Decision)이라 번역한 표현이다. 외국에 있을 때, 음주 관련 공익 광고 중에 "Drink Responsibly"라는 광고 카피가 기억에 남는다. 이는 자기가 감당할 정도로만 마셔서, 자신의 생활과 관계를 잘 유지할 수 있도록 하자는 뜻이라고 한다. 나는 이와 일맥 상통한다고 생각했다. 즉, 구조적 결정을 하는 시간과 범위를 가능한 미루는 것이 아니고 알맞고 발라야 한다는 것이다.

또한, 토론에 대한 언급도 좋았다. 나는 애자일 접근법이 소통으로 이루어 지는 부분이 매우 훌륭하다고 생각한다. 특히, 애자일 12원칙 중 "최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다."라는 구절을 매우 좋아 한다. 창발은 팀의 원할한 소통에서 나올 수 있다. 그러므로, 소통이 없는 팀에서는 좋은 아키텍쳐가 나오기 어렵다.

아쉬운 부분은 절차에 대한 이야기가 있지만, 어떻게 구조적 결정을 해야 하는지에 대한 기술적인 방법(Technical Method)에 대해서는 설명이 없다는 것이다. 이러한 부분은 아직 Design Pattern, Architectural Style, Aspect Driven Design(ADD) 혹은 AD를 활용해야 하는 것인지도 모르겠다. 이 부분은 숙제로 남겨두고 고민해도 좋겠다.

참고 문헌

[1] Boyan Mihaylov, "Towards an Agile Software Architecture," https://www.infoq.com/articles/towards-agile-software-architecture/?p13nId=6817&p13nType=followTopic#

개요

소프트웨어 아키텍처(Software Architecture)의 정의

Wikipedia[1]에서도 [2]의 정의를 가장 앞에 두고 채용하고 있다. 이 책은[2]는 Carnegie Mellon 대학의 Software Engineering Institute (SEI)의 Software Engineering Book Series[3] 중의 하나이기도 하다.

"The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, and properties of both"

"시스템의 소프트웨어 아키텍처는 시스템에 대해 추론하는 데 필요한 구조의 집합으로, 소프트웨어 구성 요소(Element)와 속성(Properties)로 구성된다."

여기서 구조(Structure)와 뷰(View)에 대해서 잘 이해애야 한다. [2]에서의 설명을 보면 다음과 같다.

• A view is a representation of a structure. It consists of a representation of a set of elements and the relations among them.
• A structure is the set of elements itself, as they exist in software or hardware.

즉, Structure가 Architecture를 구성하는 Element의 집합이라는 것이고 Architecture의 일부라는 것을 알 수 있다. 그렇다면, View를 이 Structure를 보여주는 (Represent) 것이다. Architecture를 설계하는 Architect는 결국 Structure를 설계하는 것이다. 그리고 설계한 Structure를 View를 통해서 보여주고(Represent)하고 문서화 한다(Document). 이 View에 대해서는 따로 상세히 이야기 하기로 한다.

Software Architecture에 대한 다른 정의를 Martin Fowler의 논문[4]에서 찾아 볼 수 있다. 

"Architecture is the set of design decisions that must be made early in a project." 

여기서 design decision을 Architectural Design Decision이라고 부른다. 이는 Software System의 요구 사항(Requirement)에 대해서 다른 결과를 제공하는 Architecture Design들의 차이점을 비교하여 내리는 결정들이라고 할 수 있다. 

이 내용을 요약하면, Software Architecture는 어떻게 Software System의 Structure를 보여주는 View들을 통해서 Stakeholder들에게 보여 주는가? 그리고, 이러한 Structure들을 선택하여 결정한 Architectural Design Decision을 Stakeholder들에게 설명하는가가 중요하다고 할 수 있다. 이는 최종 결과물에 대한 것이고 이러한 최종 결과물을 찾아 가는 과정은 또한 다른 이야기 이다. 이 최종 결과물은 여러가지 형태가 가능하겠지만, 여기서는 문서 (Architecture Document)로 보도록 한다.

뷰(Views)

CMU SEI Three Views

[5]에서는CMU의 SEI에 이야기 하는 Software Architecture의 3가지 View에 대해서 설명한다. 

첫 번째는 Module View이다. Module은 소프트웨어의 구현단위이다. 그렇기 때문에, Module View는 소스 코드 작성의 청사진(Blueprint)으로 사용될 수 있다. 그리고, Module은  소스코드나디렉터리같은 물리적구조와 대응된다.

 

 

 

 

세 번째 View는 Allocation View이다. 이는 Software Architecture와 환경을 매핑시키는 역할을 한다. 우선 Deployment Style와 Work Assignment Style을 살펴 보자

 

Deployment Style은 Software Element가 어떤 물리적 장치에 탑재되는지 보여 준다. 시스템 동작 시, Deployment 내용이 변경 될 수 있으므로 할당은 동적일 수 있다.

RUP Views: 4+1 Views

 

결국은 어떤 View를 선택해야 할까?

Architectural Decisions

마치며...

References

왜 여기까지 왔는가?

궁금증이 있었다. 우선 회사에서 가르치는 아키텍트(Architect) 관련 과정이 무엇을 가르치는 것일까? 그리고, 거기서 말하는 소프트웨어 아키텍트(Software Architecture)라는 것은 어떤 것일까? 그 과정을 들었떤 지인들에게 이야기 들었던 것들은 나에게 속시원한 답을 주지는 않았다. 그래서, 우선은 과정에 참여하였고, 일단락을 맺었다. 하지만, 이제 시작이라는 느낌이다. 그래서, 이글을 시작으로 또 공부하게되는 내용들을 정리하려고 한다.

교육 과정을 통해서 알게 된 소프트웨어 아키텍처 설계(Software Architecture Design)은 소프트웨어 공학(Software Engineering) 관점에서 최적 설계에 대한 것이었다. 단계별로 보면, 요구사항 분석(Requirement Analysis)에서 시작하여 시스템의 범위를 정하고, 기능적 요구 사항(Functional Requirement)를 도출한다. 그리고, 이를 분석하여 품질 시나리오(Quality Scenario)를 도출한다. 여기서, 비기능적 요구 사항(Non-Functional Requirement)와 품질 속성(Quality Attribute)를 선정한다. 이 때, 비지니스 동인(Business Driver)를 고려하여 우선순위 선정이 필요하다. 그리고, 이를 기반으로 시스템 범위 내에 중요한 내용을 기반으로 하는 후보 구조(Candidate Architecture)들을 도출하고 이를 비교 분석하며 아키텍처 디시젼(Architectural Decision)을 해가면서 최종적 아키텍처를 완성해 간다. 이 내용들은 시스템의 이해관계자(Stakeholder)과 공유 되어야 하면서 장점과 단점이 지속적으로 언급이 되면서, 의사결정이 되는 과정인 것이다.

아주 오래전에 소프트웨어 공학(Software Engineering) 교수님께서 설명하신 객체 지향 패러다임(Object Oriented Paradigm)관련한 강의에서 들은 내용이 있다. 소프트웨어 공학(Software Engineering)이 무엇인지에 대한 것인데, 이는 소프트웨어 개발자가 가져야 하는 상식(Common Knowledge)이다라는 것이 있다. 나도 소프트웨어를 개발하는 사람이 가져야 하는 기본적 소양이라는 관점에 지금까지도 동의 하는 부분이다. 하지만, 많은 소프트웨어 공학 책에서 강조하는 정식 프로세스(Formal Process) 관점에 대해서는 나는 수긍하지 못하고 있다. 많은 회사들이 이를 채용하고 있다고는 하지만, 직간접적으로 경헌한 나의 경우는 아직 보지 못했기 때문이다. 물론 많은 회사들이 제품을 만들기 때문에 프로세스가 있을 것이다. 

가장 큰 이유 중에 하나는 사람이다. 프로세스 중에 사람이 없다. 내 경험으로 여기에 가장 가까운 것은 애자일 소프트웨어 개발(Agile Software Development)이다. 나는 이것도 결국은 소프트웨어 공학의 한 분야로 이해하고 있다. 사람이 하는 일은 사람을 떠나서 생각하면 공허해 진다.

문서화에 대한 거부감

내가 SW 개발 실무를 처음 시작할 때에는 통신 프로토콜 스택의 설계 및 구현에 참여 하였다. 요구 사항(Requirement)이 사양서(Specification)이었다. 나의 상사는 소프트웨어 공학을 했던 분으로 내가 받았던 업무 지시는 요구 사항 분석을 통해서 상세 설계를 하는 것이었다. 코딩은 중요하지 않다(Trivial하다는 의미로 이해된다)고 이야기를 계속 들었다. 이러한 작업은 내가 구현해야 하는 분야의 도메인 지식(Domain Knowledge)을 높여 주는데는 성공했지만, 최종적으로 코딩을 하는데는 실패하게 되었다. 이유는 나의 기술적인 미숙, 하드웨어 제약에 대한 이해 부족, 목표한 테스트의 실패, 충분하지 못한 일정 그리고는 지속적은 목표 변경 등 여러 가지가 복합적이었다.

이후 내가 경험했던 여러 성공한 프로젝트들은 문서화보다는 실질적으로 동작하는 제품에 맞춰졌다. 내부 혹은 외부의 고객이 원하는 제품 혹은 우리가 만들 수 있는 제품을 고객에게 보여주면서 정제(Refine)해가는 절차를 통해서였다. 즉, 동작하는 솔루션을 만들어 놓고, 그를 바탕으로 확장해 나아가는 방식이다. 여기에서의 우리가 하는 문서화는 점점 줄어 들었다. 이는 읽지 않는 문서는 만들지 않는다는 중요한 원칙이 있었던 것이다.

성공적이라 할 수 있는 프로젝트는 많았지만, 늘 지적 받던 것은 소프트웨어의 품질이었다. 과제가 끝났지만, 여전히 소프트웨어에는 문제점(Defect)이 많고, 변경이 용이하지 않으며, 성능이 좋지 않은 경우가 많았다. 여러 가지 개선 방법들을 논의 하였지만, 우선적으로 소개되며 고민되었던 방법은 프러덕트 기반의 애자일 개발 접근 방법이었다. 여기서도 문서는 그렇게 중요한 것은 아니었다. 그 보다는 진행 사항을 가시화(Visualize)하고 제품을 점진적으로 개발하여 실재 제품에 적용가능한지를 평가하면서 진행하는 방식으로 프로젝트가 변경되었다.

이렇듯, 소프트웨어 공학에서 이야기 하는 설계서와 같은 문서화에 대해서는 여러 거부감이 있다. 하지만, 아이젠하워의 말대로 "계획대로 승리한 전투는 없지만, 계획없이 승리한 전투도 없다. No battle was ever won according to plan, but no battle was ever won without one" 인 것이다. 결국은 읽힐 문서, 다이어그램(Diagram)을 만들어야 하는 것이다.

소프트웨어 공학에 대한 비판

많은 아키텍처 책이나 글 그리고 프로세스는 소프트웨어 공학을 가정한 내용이다. 아래 글은 Wikipedia의 소프트웨어 공학(Software Engineering)[1]에 있는 내용이다. 여러가지 관점에서 살펴 보기 위해서 이러한 의견도 고려해 보려 한다.

소프트웨어 공학에서는 개발자를 전문가(Practitioner)로 본다. 즉, 문제 해결에 대해 잘 정의된 엔지니어링 방식을 따르는 개인, 즉 전문가로 본다. 이는 마치 의사, 변호사와 마찬가지로 보는 것이다. 이러한 접근법은 다양한 소프트웨어 공학 서적 및 연구 논문에 명시되어 있으며 항상 예측 가능성, 정확성, 리스크의 완화 및 전문성을 함축한다. 이러한 관점은 엔지니어링 지식을 전파하고 현장을 성숙시키는 메커니즘으로서 라이센스, 인증 및 체계화 된 지식 체계를 요구하게 되었다.

하지만, 소프트웨어 공학에 대한 핵심 쟁점 중 하나는 일반적으로 실제 접근 방식의 검증이 없거나 매우 제한적이어서 접근 방식이 충분히 경험적이지 않다는 것이다. 그래서, 소프트웨어 엔지니어링이 종종 "이론적 환경"에서만 가능한 것으로 오인된다.  

에츠허르 데이크스트라(Edsger Dijkstra)는 오늘날 소프트웨어 개발에서 사용 된 여러 개념을 만든 사람으로서 2002 년 사망 할 때까지 소프트웨어 엔지니어링에 대해 컴퓨터 과학의 "급진적 참신성(Radical Novelty)"라고 반박했다.[2]

"이러한 현상은 소프트웨어 공학이라는 이름으로 포장되었다. 경제학이 비참한 과학(The Miserable Science)으로 알려짐에 따라 소프트웨어 공학은 종말에 이른 체계(Doomed Discipline)으로 알려 져야한다. 목표가 자기 모순적이어서 목표에 다가 갈 수 없기 때문이다. 물론 소프트웨어 공학은 또 다른 가치있는 이유를 제시하지만, 눈속임이다. 글을 주의 깊게 읽고 그것이 실제로 무엇을 하려고 헌신하는지 분석하면 프로그래밍을 할줄 모르면 어떻게 하는가(How to program if you can not)가 소프트웨어 공학의 진정한 근본 원리(Charter)로 받아 들여 졌음을 알게 될 것이다."

그럼에도 불고하고, 소프트웨어 공학은 이러한 비판에 대해서 닫혀 있지 않았다. 여러 경험적이고 공통적으로 받아 지는 것들을 쌓아 왔다. 특히, 애자일 소프트웨어 개발(Agile Software Development)의 성공적인 부분을 받아 들였따. 특히, 반복적 접근 방법(Iteratvive Development)를 받아 들이고 있다.

정리해 보면...

받아 들이기 어려운 극단적인 비판적 입장일 필요도 없다. 간단하고 명료하게, 우리는 실용적(Practical)일 필요가 있다. 즉, 결과를 낼 수 있고, 논리적으로 명백하다면 받아 들이기는 더욱 쉬울 것이다. 단지, 늘 비판에 대해서 열려 있어야 한다. 하지만, 목표는 분명하고 단단해야 할 것이다. 즉, 소프트웨어는 완성되어야 한다. 그리고, 소프트웨어 개발이 어려 사람들과 함께 만들어 내야 하는 것일 것이다.

이러한 실용적이라는 관점에서는 목표를 이야기 하고 싶다. 우리는 최상의 결과물을 만들어 내야 한다. 그런 입장에서 결과물을 처음 부터 그려 가는 것이 필요하다. 처음에 그렸던 최종 결과물이 마지막에도 꼭 그런 모습을 가지지 않을 수 있다. 아이젠하워의 말처럼 "Plan is nothing, but planning is indispensable"이 생각난다. 결국, 전쟁에서는 승리가 최종 목표 이듯이, 설계서에 함몰하지 말고 최종 결과물을 목표로 하는 설계에 집중해야 한다고 생각한다.

그래서, 나는 소프트웨어 공학 관점에서의 아키텍처에 관해서 고민을 시작하여 여러 관점에서의 실용적인 소프트웨어 아키텍처의 설계에 대해서 살펴 보고자 한다.

참고 문서

[1] Software Engineering, https://en.wikipedia.org/wiki/Software_engineering 

[2] On the cruelty of really teaching computing science, https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html