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

[1]의 4장 초기 이해에서는 소스 코드의 초기 분석을 위한 세 가지 주요 패턴을 제시한다. 퍼시스턴트 데이터 분석하기, 디자인 추측하기, 예외적인 엔터티 연구하기가 그것이다. 각 패턴은 리엔지니어링 프로젝트의 성공적인 진행을 위한 필수적인 단계이다.

퍼시스턴트 데이터 분석하기

• 의도: 데이터베이스 시스템 내부에 보관해야 할 중요한 개체를 식별하고 이해한다.
• 문제: 귀중한 데이터는 외부 저장 장치에 보관되어야 하지만, 정리되지 않은 데이터와 혼재될 수 있다.
• 해결:
  1. 모든 테이블 이름을 열거하여 초기 모델을 준비.
  2. 각 테이블에 대해 열 이름을 수집하고 속성으로 추가.
  3. 후보 키 및 외래 키 관계를 분석.
  4. 상속 관계를 유추하여 클래스 다이어그램을 도출.
  5. 데이터 샘플과 SQL 문을 통해 검증.
• 장점: 팀 커뮤니케이션 개선, 가치 있는 데이터 추출.
• 단점: 범위 제한, 정크 데이터 포함, 전문 지식 필요.

디자인 추측하기

• 의도: 소스코드에서 디자인 개념을 복구하여 가설을 검증하고 구체화한다.
• 문제: 많은 디자인 개념이 있으며 프로그래밍 언어에서 이를 표현하는 방법이 다양하다.
• 해결:
  1. 초기 가설 역할을 하는 클래스 다이어그램 작성.
  2. 클래스, 연산, 속성 이름을 소스 코드에서 찾아 가설 검증.
  3. 불일치를 기반으로 클래스 다이어그램을 조정.
  4. 만족스러운 다이어그램을 얻을 때까지 반복.
• 장점: 대규모 객체 지향 프로그램에 유리, 저렴한 리소스 투자.
• 단점: 전문 지식 필요, 시간이 많이 소요됨.

예외적인 엔터티 연구하기

• 의도: 시스템에서 예외적인 엔터티를 식별하고 분석하여 전체 구조를 이해한다.
• 문제: 예외적인 엔터티는 일반적인 패턴을 따르지 않으며, 특별한 처리가 필요하다.
• 해결:
  1. 예외적인 엔터티를 식별.
  2. 해당 엔터티의 특성과 동작을 분석.
  3. 다른 엔터티와의 관계를 이해하여 시스템 전체의 구조를 파악.
• 장점: 시스템의 비정상적인 부분을 이해하고 해결하는 데 도움.
• 단점: 예외적인 상황을 처리하기 위한 추가 분석이 필요.

이 세 가지 패턴은 소프트웨어 리엔지니어링 프로젝트의 초기 분석 단계에서 시스템을 이해하고 문서화하는 데 필수적인 방법들이다. 이를 통해 프로젝트의 안정적인 기반을 구축하고, 성공적인 진행을 보장할 수 있다. [2]에서 번역된 내용을 찾을 수 있다.

참고 문헌

[1] Serge Demeyer et al., "Object-oriented Reengineering Patterns"

[2] https://github.com/blcktgr73/OORP 

[1] 의  3장 초기 접근 방법에 다음과 같은 리엔지니어링 프로젝트 예제를 이용해서 실제 예시로 패턴에 대해 설명한다.

• 시나리오: 사용자 팀은 의료 소프트웨어 시스템인 proDoc을 개발하고 있으며, 경쟁사인 XDoctor의 인터넷 기능을 proDoc에 통합하려고 합니다.
• 주요 과제: 시스템을 통합하고 리엔지니어링하기 위해 첫 번째 평가와 계획을 수립하는 것입니다.

주요 요구사항

1. 규모 문제: 레거시 시스템이 크고 복잡하므로 이를 관리 가능한 부분으로 나누어야 한다.
2. 시간 부족: 프로젝트 초기에는 시간을 낭비하지 않도록 주의해야 한다.
3. 불완전한 지식: 초기에 중요한 결정을 내릴 때 불완전한 지식으로 인해 잘못된 결정을 내릴 수 있다.
4. 다양한 이해관계: 여러 이해관계자들이 서로 다른 의제를 가지고 있을 수 있다.

패턴 적용:

• 유지보수자와의 담소나누기: 시스템의 역사적, 정치적 맥락을 이해하기 위해 유지보수자와 논의한다.
• 한 시간 안에 모든 코드 읽기: 소프트웨어 시스템의 상태를 빠르게 평가하기 위해 집중적으로 코드를 검토한다.
• 모의 설치 수행하기: 리엔지니어링 적합성을 평가하기 위해 시스템을 실제로 설치하고 실행해 본다.
• 문서 스키밍하기: 관련 문서를 빠르게 검토하여 중요한 정보를 파악한다.
• 데모 중 인터뷰하기: 시스템을 사용하는 사람들과 인터뷰를 통해 추가 정보를 수집한다.

예시

예시에서는 앞에서 설명한 것의 사례에서 일어 났던 경험을 해당 패턴에 연계하여 이야기 한다.

• XDoctor 인수: XDoctor의 개발팀에서 유일하게 남은 데이브와의 대화를 통해 중요한 기술적 정보를 얻고, 두 시스템을 통합하는 계획을 세훈다.
• 코드 검토: Java와 C로 작성된 코드를 검토하여 시스템의 구조와 품질을 평가한다.

결론

리엔지니어링 프로젝트를 성공적으로 수행하기 위해서는 초기 단계에서 정확한 평가와 계획이 중요하며, 이를 위해 다양한 패턴을 적용하여 시스템의 상태와 문제를 파악해야 한다고 이야기한다. 이 패턴들을 읽어 보면, 실재로 경험한 듯한 것들이 많다. 특히, 유지보수자와 담소나누기, 모의 설치하기 등은 마치 내 경험을 몰래 들여다 본 것 같은 느낌도 들 정도였다. 다른 것들의 경우도, 일부는 경험한 듯 하고 시간 제약을 두고 하는 것도 눈에 띄는 이야기였다. 무엇보다도 사회적 맥락에서 접근하는 패턴은 이 부분이 매우 실용적인 것이라는 생각도 많이 들었다. [2]에 번역 내용이 올라가 있다.

참고 문헌

[1] Serge Demeyer et al., "Object-oriented Reengineering Patterns"

[2] https://github.com/blcktgr73/OORP 

[1]의 2장 방향 설정하기는 리엔지니어링 프로젝트의 방향 설정에 관한 내용을 다루고 있다. 팀 내에서 공통된 목적의식을 확립하는 방법과 함께 리엔지니어링 프로젝트를 효과적으로 진행하는 데 필요한 다양한 전략과 맥심(지침 원칙)을 소개하고 있다.

주요 내용은 다음과 같습다.

• 맥심에 동의하기 - 프로젝트의 핵심 우선순위를 설정하고 팀이 올바른 방향으로 나아갈 수 있도록 돕는 지침과 원칙을 개발하는 과정다.
• 내비게이터 지정 - 아키텍처 비전을 유지할 수 있도록 특정 인물을 '내비게이터'로 지정하는 전략이다.
• 원탁 회의에 말하기 - 정기적인 원탁 회의를 통해 프로젝트 상태에 대한 팀 인식을 유지하고 정보를 공유하는 방법이다.
• 가장 가치 있는 것 먼저 하기 - 문제 해결에 있어 가장 중요하고 가치 있는 부분부터 시작하는 전략이다.
• 증상이 아닌 문제 수정하기 - 문제의 증상이 아닌 근본 원인을 해결함으로써 더 효과적인 리엔지니어링을 도모하는 접근법이다.
• 고장이 나지 않으면 수정하지 않기 - 실제로 문제를 일으키고 있는 부분만을 수정하는 실용적 접근 방식이다.
• 간단하게 유지하기 - 과도한 복잡성을 피하고, 간단하고 효과적인 솔루션을 구현하는 전략이다.

각 절에서는 이러한 원칙들을 실제로 적용하는 방법과 예상되는 도전, 그리고 팀 내부의 동기 부여 및 관리 방법에 대해 논의한다. 이를 통해 리엔지니어링 프로젝트가 보다 성공적으로 수행될 수 있도록 설계된 지침서로 사용할 수 있다.

[2]에 번역 내용이 올라가 있다.

참고 문헌

[1] Serge Demeyer et al., "Object-oriented Reengineering Patterns"

[2] https://github.com/blcktgr73/OORP 

이 책은 에디슨 위슬리 반 버논 시리즈의 여러 책 중의 한 권이다. 특히, 아키텍처 설계와 관련해서 관심을 가지다가 알게 되었고 번역 제안을 받아 진행하게 되었다. 쉽지 않은 과정이었지만, 몇 가지 알게 된 것, 느낀 것 그리고 번역에 대한 나의 짧은 생각을 적어 보려 한다. 

반 버논은 도메인 주도 설계(Domain Driven Design, DDD)가 도입되는데 큰 기여를 하고 있다. 특히, 도메인 주도 설계 구현(Implementing DDD)으로 유명하다. 나는 DDD가 요구사항과 구현 사이의 간극을 드라마틱하게 줄여주는 실천법이라고 생각한다. 이를 통해 확보한 요구 사항의 명확한 이해를 기반으로 효과적인 소프트웨어 설계를 수행할 수 있다. 흥미롭게도 비지니스 전문가와 개발자들이 함께 일하는 애자일 원칙과도 맞닿아 있다. 또한 이 책은 반 버논 시리즈의 두 번째 역서이다. 하나는 “웹 API 설계 원칙”이다. 반 버논의 추천사를 보아도 두 책의 저자들이 상호 보완적으로 글을 썼다고 한다. 이 책에서는 웹 API 설계 원칙의 정렬-정의-설계-구체(Align-Define-Design-Refine) 단계 개념을 패턴에 적용하기도 했다.

반버논의 추천사에서 보면 유기적 구체(organic refinement)는 소프트웨어와 관련된 모든 개념이 무생물이 생물체의 측면을 '특성화'한다는 아이디어를 언급한다. 소프트웨어는 구체적인 시나리오를 통해 모델을 논의하거나 아키텍처를 설계하고 도메인 모델을 작성함으로써 살아 움직이기 시작한다. 마찬가지로, 건축가이자 패턴 개념을 만든 크리스토퍼 알렉산더는 "Nature of Order"에서 인간 배아(Embryo)의 예를 들며, 분화(Differentiation)에 대해 이야기한다. 이는 유기적 구체와 매우 유사하며 유기적이며 발전하고 성장하는 프로세스를 강조한다. 이러한 관점에서 소프트웨어의 진화는 생물의 발전에 대한 이해와 유사한 맥락에서 이해할 수 있다. 생명체가 환경과 상호작용하면서 성장하고 변화하는 것처럼, 소프트웨어도 사용자와 시스템 사이의 상호작용 속에서 점진적으로 발전하는 것이라 이해할 수 있다.

이 책에서 언급하는 패턴의 경우도, 이러한 유기적 구체 혹은 분화 과정에서 발견되는 반복적인 내용들을 잡아 내어 패턴의 커뮤니티에서 키워내고 리뷰하여 만들어 내는 과정을 거친다. 그러므로, 패턴, 유기적 구체, 분화와 같은 것을 이해하고 소프트웨어 구조를 설계할 때 분화의 관점 그리고 소프트웨어가 발전 성장하는 과정에서 패턴을 적용해가는 것이 필요하다는 관점에서 이 책에 접근하는 것을 권한다.

개별 언어는 독특한 여러 특징을 가진다. 이로 인해, 각 언어에 내재한 작은 뉘앙스 차이를 다른 언어로 옮기는 일은 매우 어렵다고 생각한다. 이 책에서는 "force"라는 어찌 보면 "힘"이라고 단순하게 번역할 수 있는 단어의 번역에 고민을 오래 하였다. 소프트웨어 설계에서 "force"는 설계 결정에 영향을 미치는 다양한 요인을 의미한다. 특히 이 책에서는 패턴의 문제-해결 짝과 이후에 상세 설명에서 패턴과 관련된 여러 "중요한 요구 사항"을 가리키는 용어로 등장한다. 이는 서로 상충되는 경우가 많다. 다른 아키텍처 책에서도 이 "force"를 언급하지만 이 책에서 더 자주 언급되어 시간을 들여 고민을 하였다.

이 책에서는 한글과 원어를 여러 번 병기하였다. 그 이유는 소프트웨어 개발이나 소프트웨어 개발과 관련된 도메인의 중심이 여전히 미국에 있기 때문이다. 따라서 영어로 쓴 원서나 관련 논문, 인터넷 글을 읽을 기회가 많으므로 원어 용어에 익숙해져야 한다. 따라서 이 책에서도 병기를 충분히 했다. 여러분도 책을 보면서 소프트웨어 아키텍처와 소프트웨어 개발에 관련된 원어 용어에 익숙해졌으면 한다.

번역 중 저자들과의 몇 번의 소통이 있었다. 올라프 짐머만과의 몇차례 이메일을 통해서 사소한 오탈자 뿐 아니라 그들이 생각하는 용어 정의와 같은 부분에 대해서도 의견을 나눌 수 있었다. 이러한 과정은 나에게 새로운 경험이었고, 책에 담긴 내용을 조금 더 깊게 이해하는데 도움이 되었다.

책의 번역을 마무리하면서 소프트웨어 개발, 설계에 대해 다시금 돌아보며 좋은 학습의 기회였고, 저자와 연락하며 짧지만 전문가들과 이야기 나눌 수 있어서 좋았다. 번역이라는 작업에 대해서도 내 생각을 정리하는 것은 나름 의미가 있었다. 

이 부분은 소프트웨어 아키텍처 101 (Fundamentals of Software Architecture)[1]의 2장에 나온 내용을 정리한 것이다.

아키텍처와 설계

저자는 아키텍처와 설계를 비교 설명한다. 이를 수행하는 아키텍트와 개발자의 역할이 다음과 같다고 이야기 한다.

아키텍트는 아래 사항을 수행한다

1. "비즈니스 요구사항"을 분석하여 "아키텍처 특성(Architecture Characteristics, ~bilities ~성)"을 도출/정의하고
2. 어떤 "아키텍처 패턴"과 "아키텍처 스타일"이 해당 문제 영역에 적절한지 선택하여
3. 각종 "컴포넌트(시스템 구성 요소)"를 만든다.

개발자는 다음 역살을 수행한다.

1. 아키텍트의 수행 결과인 "아티팩트(artifact 산출물)"이 전달되면, 컴포넌트의 "클래스 다이어그램(상세 설계)"를 그린 뒤
2. "UI 화면"을 만들고
3. 소스 코드를 개발/테스트 한다.

이 부분에 대해서는 이견이 있을 수 있다. 상세 설계에 해당한다고 보이는 부분도 아키텍처에서 중요하다고 할 수 있는 품질 속성(Quality Attribute, 이 책에서는 아키텍처 특성이라고 하고 있다.)과 관련될 수 있고 이 부분이 아키텍처와 관련된 산출물에 포함되어 설명될 수 있기 때문이다. 이 책에서는 이러한 내용은 명시되어 있지는 않지만, 아키텍트와 개발자의 소통의 중요성을 이야기 하면서 언급되고 있다.

기술 폭(Technical Breadth)

아키텍트이든 개발자 이든 자신이 알고 있는 기술 세부의 범위는 한정적일 수 밖에 없다. 그렇다면, 아키텍트의 이 범위가 어떻게 될까? 책의 저자는 "내가 알고 있는 것", 내가 모른다는 사실을 아는 것" 그리고 "내가 모른다는 사실조차 모르는 것"으로 지식을 설명한다.

저자는 여기에서 지식의 깊이(Depth)와 폭(Breadth)를 구분하면서 개발자는 이 기술의 폭을 넓혀야 한다고 주장한다. 이 지식의 폭을 넓혀야 하는 이유 중에 하나가 다양한 분야에 전문성을 유지하려고 하면, 어느 하나에도 전문성을 충분히 확보하지 못할 수 있기 때문이다. 두 번째는 김빠진 전문성(stale expertise)이 나타나 자신은 첨단이라고 이야기 하지만, 실상은 낡은 정보만 가지고 있는 경우가 생긴다는 것이다.

정도의 차이는 있을 수 있으나 자신의 전문성을 가지고 다른 분야에도 얕지만 넓은 지식을 가지는 T자형 인재 혹은 제너럴라이징 스페셜리스트(Generalizing Specialist)[2]가 좋은 인재상으로 이야기 된다. 여기서도 깊이와 폭으로 이해될 수 있다. 마치 스펙트럼으로 살펴 보면, 한 분야의 깊이만 아주 깊은 학교의 교수, 전문가를 한쪽 끝으로 생각할 수도 있고 넓이만 아주 넓은 강연자, 이야기꾼을 반대쪽 한쪽 끝으로 생각할 수 있다. 경력이 높은 개발자와 경험이 많은 아키텍트는 모두 이 사이에 있을 것이고 개발자는 스페셜리스트에 이키텍트는 제너럴리스트에 가까울 수 있다. 하지만, 이키텍트들도 획일적으로 한 포인트에 머무르는 것이 아니고, 이 깊이와 폭이 가지각색인 것을 쉽게 예상할 수 있다.  

트레이드오프 분석

저자들은 아키텍처 사고(Architectural Thinking)의 요체를 다양한 솔루션과 기술 간의 트레이드오프를 이해하고, 분석하고, 조율하는 것이라고 한다. 책에서는 간단하지만 좋은 비교를 통해서 이 부분이 담고 있는 내용이 어떤 것인지 설명한다. 대표적인 소프트웨어 아키텍처 설계 방법인 속성 주도 설계(ADD, Attribute Driven Design)[3]에서는 품질 속성을 요구사항으로 도출해 내고 여기에 맞는 설계 전략 혹은 아키텍처 패턴/스타일을 적용[4]하는데, 여기에서 다루게 되는 것이 결국은 트레이드오프가 된다고 볼 수 있다.

책[1]에서는 경매 시스템을 구현할 때 컴포넌트 간의 연결을 Queue 혹은 Topic을 사용하였을 때, 트레이드오프에 대해서 논의 한다. 실재 설계할 때에는 접근 방법이 다르지만, 여기서는 우선 두 기술의 장점/단점을 비교하여 트레이드오프가 두드러지게 하였다.

Queue/Topic의 장단점 비교

실재로는 어떻게 될까? 여러 요인이 있겠지만 시스템의 품질 속성과 같은 여러 요소들에 따라 더 적절한 기술을 선택해 가는 것이 아키텍처 설계가 된다.

아키텍처와 코딩 실무 간의 균형 맞추기

이 책의 저자 뿐 아니라 다른 책의 저자들도 이야기 하지만, 아키텍트도 개발자로서 코딩 실무를 놓지 말아야 한다는 이야기를 많이 한다. 저자는 특히 이러한 균형을 맞추는 여러가지 방법을 제안하고 있고, 아주 실용적인 예들이기도 하다.

1. 개념 증명(Proof of Concept, PoC)를 주주 해보자
2. 개발팀이 아주 중요한 유저 스토리 작업을 할 수 있도록 기술 부채(Technical Debt) 스토리나 이키텍처 스토리에 전념한다.
3. 개발 이터레이션을 하는 도중에 버그를 잡는다.
4. 개발팀 일상 업무를 간소화 하거나 자동화 하는 간단한 커맨드라인 도구나 분석기를 만든다. 아키텍처 컴플라이언스 보장을 자동화 하는 피트니스 함수 측정기로 쓸 수 있는 아치유닛(ArchUnit)을 이용할 수 있다.
5. 자주 코드 리뷰를 한다.

4번 자주 하고 있는 것 중에 하나이다. 또한, 5번은 코드의 흐름을 놓치지 않을 수 있는 좋은 접근 방법이기도 하다.

참고 문서

[1] 마크 리처즈, 닐 포드, "소프트웨어 아키텍처 101 (Fundamentals of Software Architecture)", 한빛 미디어, 이일웅 옮김, 2021

[2] 위르헌 아펄로, "매니지먼트 3.0" 에이콘, 조승빈 옮김. 2019

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

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

소프트웨어 아키텍처 공부를 시작하고 알게되어 한빛 출판에 번역을 제안하여 운 좋게 진행한 조지 페어뱅크스의 "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