[도서 리뷰] 적정 소프트웨어 아키텍처: 리스크 주도 접근법

> 진행에 앞서

개발자로 N년 이상(N은 개인별로 다양하겠지만, 개인적으로는 10년 이상)된다면 개발 뿐 아니라 소프트웨어 자체에 대해서 설계를 어떻게 하는 것이 좋을까 진지한 고민을 하기 시작한다고 생각한다. 코드를 만들고 무언가를 만드는 것이 즐거워서 시작한 개발이지만, 어떻게 하면 내가 하는 이 개발이 좀 더 견고한 프로그램을 만드는 데 사용될 수 있을까. 혹은 아름다운 구조를 가진 코드를 만들 수 있을까. 다양하게 접수되는 요구사항에 쉽게 대응할 수 있는 구조로 만들 수 있을까. 등 '설계'라는 영역을 찾아가게 만드는 생각에 다다르게 된다. 결국 좋은 구조의 프로그램(소프트웨어)은 좋은 설계로부터 시작되기 때문이다. 그 설계를 하는 일은 흔히 개발자가 하게 되지만, 개발자가 그 일을 좀 더 전문적으로 하다보면 그 사람을 아키텍트라고 부르기도 한다.

나 역시 이런 과정 속에서 살고 있기에 틈만 나면 좋은 아키텍처를 고민하고 있고, 그 아키텍처를 고민하는 과정에서 이 책의 부제인 '리스크 주도 접근법'이라는 문구가 들어오게 되었다.

 

> 책에 대한 간단한 정보

책의 앞 표지

온라인의 이미지로만 접했던 이 책을 처음 접했을 때, 하드커버라는 데에 놀랐다. 단지 하드커버만으로는 놀라지 않았겠지만, 하드커버와 이 책의 표지 이미지를 함께 보았을 때, 학술적인 느낌을 강하게 받았기 때문이다. 요즘 많은 책이 쉽게 표현하는 경향이 많고, 그 책을 통해 쏟아지는 많은 지식을 빠르게 습득하는 경우가 많은 편이라고 생각하는데, 이 책은 그 반대의 길을 갈 것이라는 느낌을 바로 책의 표지를 보면서 느껴졌다. '쉽지는 않지만, 제대로 익히고 싶다면 이 책을 접해보는게 어떻겠나' 라는 말을 나에게 하고 있는 것 같았다.

 

이 책의 챕터를 먼저 알면 흐름을 아는데 도움이 될 듯 하여, 여기에 남겨본다.

 

1 개요

 

<파트1> 리스크 주도 소프트웨어 아키텍처

2 소프트웨어 아키텍처, 3 리스크 주도 모델, 4 예제: 홈 미디어 플레이어, 5 모델링 관련 조언

 

<파트2> 아키텍처 모델링

6 엔지니어가 사용하는 모델, 7 소프트웨어 아키텍처의 개념 모델, 8 도메인 모델, 9 디자인 모델, 10 코드 모델, 11 캡슐화 및 파티셔닝, 12 모델 요소, 13 모델 관계, 14 아키텍처 스타일, 15 아키텍처 모델 사용하기, 16 결론

 

> 인상깊은 부분들

일단 당연하게도, 앞에서 언급했듯이 이론 중심이다. 마치 대학 수업이 생각날 정도이다. 내가 만약 소프트웨어 설계를 강의하는 교수의 입장이라면 이 책의 내용을 한번 진지하게 살펴보고 이 책을 교재로 사용할지도 모르겠다. 너무나도 딱 맞게 16챕터로 되어있으며(마지막 결론을 스킵하면 15챕터) 이정도 분량이 보통 한 학기를 구성하는 총 주차의 개수가 되기 때문이다.

내용도 학술적인 부분으로 느껴지기에 그런 생각을 하는 데 더 확고하게 만들었다.

 

리스크 완화를 위한 문장

중간에 리스크를 한창 언급하다가 '<리스크>가 있다면, 이를 줄이는 <기법>을 고려하자'는 이 문장이 전체를 관통하는 느낌이 들었다.

물론 그 방법이 어렵기에 배워야 하는 것이 많지만, 그것을 계산하는 수식도 존재하는 것을 보고 있노라면, 본인의 레벨에 따라서 습득할 수 있는 분량이 달라질 뿐이지, 전체를 꼭 알아야만 무언가를 할 수 있다는 생각이 들지는 않았다.

 

이 읽을 읽으며 몇 가지 적어둔 부분을 이 곳에 기록한다.

 

소프트웨어 아키텍처가 중요한 이유는 다음과 같다.

• 아키텍처는 시스템의 골격 역할을 한다
• 아키텍처는 품질 속성에 영향을 미친다
• 아키텍처는 (대부분) 기능과 직교한다
• 아키텍처는 시스템을 제한한다

 

엔지니어는 설계한 시스템이 의도대로 작동하는지 다음과 같은 제약조건을 사용하여 확인한다. 나 또한 이미 자연스레 이렇게 하고 있다는 사실을 알았다.

• 판단을 구체화한다
• 개념적 무결성을 장려한다
• 복잡성을 줄인다
• 런타임 동작을 이해한다

 

그리고 당연히 아키텍처가 중요하겠지만, 특별히 아키텍처가 중요한 상황은 다음과 같다. 이는 아키텍처 리스크가 높은 5가지 구체적인 사례에 해당한다)

• 선택할 수 있는 해결책이 적음
• 높은 실패 리스크
• 어려운 품질 속성
• 새로운 도메인
• 제품 라인

 

이 책에서는 소프트웨어 아키텍처에 대한 세 가지 접근방식이 있다고 이야기 한다.

• 아키텍처 무관 설계: 아키텍처에 거의 관심을 기울이지 않으므로 시스템은 큰 진흙 뭉치가 될 수도 있고, 의식적인 선택없이 뚜렷한 아키텍처가 나타날 수도 있다
• 아키텍처 집중 설계: 의도저으로 아키텍처를 선택하므로, 기능 및 품질속성을 포함하여 목표를 달성하는 데 적합한 아키텍처를 설계한다
• 아키텍처 상향 설계: 아키텍처 집중 설계의 일종으로, 개발자가 시스템의 목표나 속성을 보장할 목적으로 아키텍처를 설계하기 때문에 개발자는 이를 달성하는 추가 코드를 작성할 필요가 없다

 

그리고, 개발자는 얼마나 많은 설계와 아키텍처를 수행해야 하는가에 대한 내용이다. 나는 여기에서 보통 척도 사용 방법을 사용하는 편이 많았다. 어느정도는 문서 패키지를 구축하기도 하였으나, 그 문서가 완벽하게 작성되어야만 진행한 것이 아닌 개념적으로 작성되었다면 진행하는 편이기 때문에 척도 사용에 가깝다고 생각했다. 개인적으로 선행 설계 없음 단계는 지양해야 된다고 생각한다.

• 선행 설계 없음: 개발자는 코드를 바로 작성하면 된다. 설계가 있지만 이는 코드와 일치한다. 즉 설계가 사전에 이루어지지 않고 코드 작성시 나온다.
• 척도 사용: 예를 들어 개발자는 아키텍처 및 설계에 10%, 코딩에 40%, 통합에 20%, 테스트에 30%의 시간을 투자해야 한다.
• 문서 패키지 구축: 개발자는 설계 문서에 충분하고 포괄적인 설계를 포함시켜 완벽하게 문서화하여 제공해야 한다.
• 즉흥 접근 방식: 개발자는 프로젝트 요구사항에 반응하고 설계 작업의 양을 현장에서 결정해야 한다.

 

그리고 리스크에 대한 중요한 공식이 있다.

 

리스크 = 인지한 실패 확률 * 인지한 영향

 

실패의 확률이 높다면, 영향도가 낮아야 한다. 반대로 영향도가 놎다면 실패 확률을 더 낮추려고 노력해야 한다. 물론 둘 다 낮다면 금상첨화이긴 하다. 이것을 관리할 수 있는 설계가 되어야 한다.

 

프로세스에 따른 설계 분류

또 하나 인상적인 부분이었던 것은 기존에 알고 있던, 폭포수 및 이터레이션, XP 등에 대해서 설계를 언제 진행해야 하는가, 그 설계는 어떻게 진행해야 하는것이며 우선순위는 어떻게 되어야 하는지 가이드라인을 제시하고 있다. 내가 경험하고 싶은 XP에서는 의외로 설계에 대해서 유연하게 가져갈 수 있도록 하는 것을 권하고 있다. 모델이 계속 진화해야 한다는 것이다. 나름 유연하게 대응할 수 있도록 설계하는 방향으로 진행해야 한다는 것으로 이해했지만, 확실히 유연하게 한다는 것은 더 어렵게 느껴지기도 한다.

보통 사전 기술조사를 명목으로 프로토타입을 만들고 개발을 하는 경우가 근래에는 많았는데, 그러한 과정에서 요구사항을 수시로 수집하여 반영하게 된다. 그 사실에 빗대어 볼 때, 어느정도는 XP와 비슷한 부분도 있지 않았을까 하는 생각도 해 본다.

 

 

아키텍트에 대한 책이라는 사실을 강조하는 뒷표지

이 책은 확실히 그냥 개발자를 위한 책은 아니다. 아키텍트로 거듭나고 싶은 사람을 위한 책이다. 좀 더 체계적인 아키텍트가 되기 위해서는 관련 도서를 참고하면 된다.

 

 

> 괜찮은 부분

1. 체계적으로 아키텍처가 관심가져야 할 영역에 대해서 알려준다.

이 책을 처음 펼쳤을 때 머리말부터 개요를 거쳤을 때는 다소 얕은 지식으로도 어렵지 않게 볼 수 있는 편이었으나, 점점 다음 장으로 넘어가면서 내용이 깊어지는 것이 보인다. 독자의 시선을 점차 깊게 이동시켜주는 과정에서 필요한 용어나 개념을 잘 정리해준다는 느낌이 들었다. 이렇게 되어있지 않았다면 처음부터 겁먹어서 애초에 1장을 다 못 넘기고, 책을 덮는 이들이 속출했을지 모른다. 하지만, 이미 이 책에서 꽤나 어렵다고 느끼고 있을 시점에서 나의 위치를 체크해보면 5장을 넘어가고 있다는 것을 알 수 있었다. 그만큼 심지어 4장에서는 예제를 수록해서 알려줄 정도로 따라가다가 초반부터 낙오되지 않도록 여러 영역을 그 이유와 함께 알려준다.

 

2. 상당히 깊이 있고, 전문적인 분야에 대해서 다룬다.

리스크 주도로 시작하지만, 이 책은 아키텍처에 대해서 다루는 책이다. 따라서 리스크에 대한 정의 및 종류, 리스크 계산 방법, 현재 우리가 알고 있는 개발론에 대해서 어떤 설계가 적합하며 이것의 리스크를 줄이기 위해 어떤 노력이 필요한지 등에 대해 전문적인 용어와 함께 설명하고 있다. 작 자료들도 어떤 참고자료를 인용했는지 명시함으로써 근거를 어필하는데 힘을 실어주었다. 반대로 그렇게 인용한 자료들과 용어를 보면서 이 책에서 다루는 내용들이 전문적이라는 것을 알 수 있었다. 그리고 개념을 알려주는 부분에서는 여러 항목을 나열하는 방법을 사용함으로써 현재 자주 사용하지는 않더라도, 이것을 학술적으로는 어떻게 분류되고 있는지 알려주는 부분이 많다.

 

3. 강의 교재로 사용하기에 매우 좋은 구성을 갖췄다.

챕터 수와 분량으로 유추해볼 때 내가 강의를 해야하는 입장이라면 이 책이 너무 좋은 구성이라고 생각이 들었다. 심지어 중간에 예제 챕터도 있어서 그 중간에는 실습이나 과제에 활용하기도 좋아보인다. 그리고 용어들도 쉬운편이 아니라서 외우고 시험을 치를 수도 있다. 강의하기에 이만큼 필요한 구성요소를 다 갖춘 책을 찾기도 쉽지 않기에 좋은 교재로서 활용하기 좋다고 생각한다. 아울러 강의 교재 뿐 아니라 스터디 교재로 활용하기에도 괜찮을 수 있다. 다만 내용이 쉽지는 않기 때문에 시간은 많이 투자해야 할 것이다.

 

> 아쉬운 부분

1. 많은 사전지식이 필요하다.

이 책은 애초에 낮은 연차의 개발자가 접하기는 쉽지 않은 책이다. 그말인 즉슨 많은 경험을 토대로 이 책을 보아야만 보이는 부분이 많다는 뜻이다. 애초에 도메인이 무엇인지, 설계하는 다이어그램에 대한 해석이 안된다든지, 모델링이 무엇인지, 리스크를 경험해본 일이 별로 없다든지 한다면 공감이 되지 않는 부분이 많을 것이다. 사전 지식이 부족하다면 권하기 쉽지 않다. 물론 부족하다면 매 페이지를 넘기면서 다른 자료를 찾아보면서 보아도 무방하다. 하지만 그런 연유로 너무 많은 시간이 걸린다면 아마 완주하기가 쉽지는 않을 것 같다.

 

2. 문장이 다소 어려운 편이다.

쉽게 익히는 책 시리즈와는 다르게 이 책은 이미 어느정도 수준이 있는 사람을 대상으로 한 책으로 보인다. 그렇기 때문에 용어나 문장이 이해하기 쉬운 편은 아니다. 마치 내가 기존에 알고 있던 개념이라고 하더라도 여기에 있는 표현들로 인해 내가 알고 있던 그런 것들이 맞는지 다시 생각해보아야 하는 문장도 많다. 물론 역자주석이 많이 달려있으므로 도움을 받으면 쉬울 수 있고, 어떤 용어는 윗 첨자로 영문을 함께 실어놓았으므로 명확한 뜻을 찾기에도 좋으나, 그래도 표현이 어렵게 되어있는 부분은 이 책을 빠르게 읽을 수 없다고 말하고 있는 것만 같다.

 

> 추천 독자

• 개발을 충분히 경험하고 설계에 관심을 갖고 있는 개발자
• 아키텍트로 다양한 경험이 있으나, 이 경험을 체계화 및 이론화하여 정리하고 싶은 아키텍트
• 팀을 효율적이고 안전하게 관리해야 하는 관리자

 

> 개인적인 평점

- 가격: 9 / 10

- 내용: 8 / 10

- 디자인: 6 / 10

- 구성: 9 / 10

 

> 정보

저자: 조지 페어뱅크스

옮긴이: 이승범

출판사: 한빛미디어

가격: 32,000원

전체 페이지: 472페이지

 

** 한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.