일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 데이터분석
- 파이썬
- 불칸
- 나는리뷰어다
- 혼자공부하는네트워크
- 혼공S
- 혼자공부하는C언어
- 혼공머신
- 머신러닝
- 혼공단
- tutorial
- 벌칸
- 컴퓨터그래픽스
- vulkan
- 혼공C
- 자바스크립트
- 운영체제
- 혼공
- 제이펍
- 리뷰리뷰
- C++
- 혼공스
- 혼공학습단
- 혼공네트
- 책리뷰
- 네트워크
- 한빛미디어
- 딥러닝
- 혼공컴운
- 혼공단5기
- Today
- Total
Scientia Conditorium
[책리뷰] 적정 소프트웨어 아키텍처 - 리스크 주도 접근법 본문
대부분의 아키텍처 책이 그렇듯이 이 책도 해당 분야를 전공한 학부생 3,4학년 혹은 석사과정을 대상으로 한다. 언어의 뉘앙스 차이로 책 제목은 'just'가 '적정'으로 번역되었다. 옮긴이의 말에서도 적혀있지만, just enough 느낌이 제대로 살지 않는 느낌이다. 완벽히 들어맞다고 할 수는 없지만 이보다 좋은 단어는 없다고 생각된다.
이 책은 특정 아키텍처 모델을 설명하는 책이 아니다. 이 책은 다른 저자가 발명한 아키텍처 모델링 접근법을 어떻게 해야 효율적으로 선택할 수 있는지 기준을 제시한다. 그 기준이 바로 리스크(Risk)다. 핵심 아이디어는 소프트웨어 아키텍처를 설계하는 데 드는 노력이 프로젝트의 리스크에 비례해야 한다는 것이다. 이것을 간단하게 저자는 우편함 설치를 예시로 들었다. 기계공학 전문 지식이 있는 사람이 새 우편함을 설치할 때 모든 기계공학 분석 및 설계 기술을 적용하지 않고, 그냥 단순히 구멍을 파고 우편함을 세우고 구멍을 콘크리트로 채운다는 것이다. 이런 식으로 리스크 주도 모델은 아키텍처링 기법을 언제 적용하지와 언제 건너뛸지를 결정하는 데 도움이 된다는 것이 이 책의 핵심 내용이다.
즉, 이 책은 애자일 소프트웨어 아키텍처에 특화한 책은 아니지만, 리스크 주도 접근 방식이 애자일 프로젝트에 적합하다는 점을 알려준다. 소프트웨어 개발 프로세스가 요구사항에서 소프트웨어 배포까지 모든 활동을 조정할 떄는 리스크 주도 모델이 아키텍처 설계만 가이드한다. 그러므로 리스크 주도 모델은 모든 소프트웨어 개발 프로세스에서 사용할 수 있다는 것이다. 저자는 그 과정을 3단계로 나누어서 설명하였다.
1. 리스크 식별 및 우선 순위 지정 (내 리스크는 무엇인가?)
2. 일련의 기법 선택 및 적용 (이를 줄이는 가장 좋은 기법은 무엇인가?)
3. 리스크 감소 평가 (리스크가 완화되었고 코딩을 시작(또는 재개)할 수 있는가?)
위 질문 과정을 반복적으로 행하여 리스크에 따라 아키텍처 기법을 선택하라는 조언이다.
저자는 소프트웨어 개발의 어려움을 해결할 만병통치약 같은 기법을 기대하면 안된다고 말한다. 대신 시스템을 잘 분할하고, 지식을 제공하고, 추상화로 문제의 본질을 드러내는 무기를 찾아야 하는데 소프트웨어 아키텍처는 그러한 무기이며 소프트웨어 시스템의 복잡성과 규모를 다루는 데 도움을 준다고 한다. 아키텍처는 소프트웨어를 분할하는 데 도움을 주고, 더 나은 소프트웨어를 설계하는 데 도움을 주는 지식을 제공하며, 소프트웨어를 추론하는 데 도움을 주는 추상화를 제공한다. 이것들은 모두 숙련된 개발자가 이미 보유하고 있는 도구라고 말하고 있다.
따라서 저자는 개발자들이 서로 다른 다양한 프로세스를 사용하여 성공적으로 소프트웨어를 개발할텐데, 개발해야 하는 소프트웨어의 리스크로 아키텍처 작업량을 결정하는 방법을 제안한다. 물론 소프트웨어 아키텍처는 비교적 새로운 기술이며 시스템 모델링과 분석에 유용한 많은 기법이 있다. 그러나 이러한 개별 기법을 실제로 시스템 개발할 떄 사용하면 개발 시간을 그만큼 소비하게 된다. 이런 이유로 저자는 소프트웨어 아키텍처에 대한 리스크 주도 모델(Risk-driven Model)을 제안한 것이다. 이 모델은 적절한 아키텍처링 기법을 선택하여 적용하고, 얼마나 많은 시간을 투자할지 파악하도록 해주어 적정 아키텍처(Just enough architecture) 작업을 수행하도록 안내한다.
사실 아키텍처를 잘 모르는 내 입장에서는 당연한 말인 것처럼 느껴진다. 아주 간단한 프로그램을 만드는데 이것저것 아키텍처 기법과 디자인 패턴 등등을 고려하여 프로그래밍할 필요는 없다고 본다. 그러나 만들어야 하는 프로그램 규모가 크고 복잡하다면 리스크에 따라 적절한 아키텍처 모델링을 선택해야 한다는 것은 매우 동의한다. 한국에서 코딩을 배울 때 이런 아키텍처 기법을 절대로 설명해주지 않는다. 보통 프로그래밍 언어의 기본적인 내용을 가르쳐주고, 자료 구조와 알고리듬 정도만 알려준다. 그 이외에 기법들은 알아서 배우라는 식이다. 또는 코딩을 하다보면 프로그램 구조에 대해 생각할 수 밖에 없기 때문에 그 때가서 따로 공부하라는 식이다.
나 역시 그런식으로 공부했기 때문에 책에 나오는 아키텍처 기법들 대부분은 처음 듣거나 모르는 내용이 많았다. 그러나 책에서 말하고자 하는 핵심 내용은 쉽게 파악할 수 있었다. 결국 아키텍처를 생각하는데 시간을 투자하면 실패 리스크를 완하는 설계를 선택하는 데 도움이 된다는 것이다. 또한 아키텍처 모델에서 모든 모델링 기법을 사용하려고 노력해서는 안 된다는 것.
책에 마지막에 저자가 재밌는 말을 해두었다.
앞으로 10년 안에, 개발자가 아키텍처를 무시하는 것은 오늘날 개발자가 자료 구조를 무시하는 것과 같이 어리석게 보일 것이라고 한다. 자료 구조를 배운 직후, 컴파일러나 운영체제를 배우기 전인 학부생에게 소프트웨어 아키텍처를 가르치자는 좋은 아이디어가 있는데, 이렇게 한다면 해당 시스템에서 볼 수 있는 아키텍처 패턴을 이해하고 각기 다른 설계 결정과 품질 속성을 절충하는 이유를 이해할 수 있기 때문이라고 한다. 또한 학부생이 컴파일러나 운영체제를 개발하는 일은 거의 없지만, 거의 모든 학부생이 소프트웨어 아키텍처를 사용하여 시스템을 구축하기 때문이라고 한다.
이 내용에 대해 나 역시 틀린 말은 아니라고 생각한다. 10년 후에도 아직 이 일을 하고 있을지는 모르겠지만, 아키텍처 기법이 자료구조와 동일시하여 필수로 배우는 과목이 되는 날을 보고 싶긴한다.
이 책은 아키텍처를 기법을 공부하기 위해 보기 보다는, 여러 아키텍처 기법을 공부한 다음에 이제 어떤걸 선택하는 게 더 효율적인지 고민하는 단계에서 보기를 추천한다.
"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."
'서평 > IT-책' 카테고리의 다른 글
[책리뷰] 혼자 공부하는 컴퓨터구조 + 운영체제 (0) | 2022.09.11 |
---|---|
[책리뷰] 오준석의 안드로이드 생존코딩 코틀린 편(2판) (0) | 2022.07.24 |
[책리뷰] 동시성 프로그래밍(Concurrent Programming) (0) | 2022.04.24 |
[책리뷰] 처음 만나는 WSL (0) | 2022.03.31 |
[책리뷰] 비전 시스템을 위한 딥러닝 (0) | 2022.02.23 |