메뉴 바로가기 검색 및 카테고리 바로가기 본문 바로가기

한빛출판네트워크

적정 소프트웨어 아키텍처

리스크 주도 접근법

한빛미디어

번역서

판매중

  • 저자 : 조지 페어뱅크스
  • 번역 : 이승범
  • 출간 : 2022-05-30
  • 페이지 : 472 쪽
  • ISBN : 9791162245538
  • 물류코드 :10553
  • 초급 초중급 중급 중고급 고급
4.6점 (42명)
좋아요 : 32

소프트웨어 개발자를 위한 실용 가이드

 

이 책은 소프트웨어 개발을 시작할 때 필요한 실용 가이드북이다. 소프트웨어 아키텍처의 리스크는 무엇인지, 아키텍처 설계 원칙은 어떻게 적용하고 해결하는지, 유관 부서의 실무자를 어떻게 도울 수 있는지 등의 주제를 개발자가 흔히 겪는 경험을 기반으로 풀어냈다. 개발하면서 너무 많은 문서를 작성했거나, 코딩을 시작하기 전에 너무 적게 고민한 적도 있을 것이다. 어느 쪽이든 소프트웨어 개발이 왜 잘못되는지 알 수 있고, 이 책에서 제공하는 해결책이 많은 도움이 될 것이다.

 

 

최종_700px(상세이미지)적정 소프트웨어 아키텍처.jpg

조지 페어뱅크스 저자

조지 페어뱅크스

소프트웨어 시스템을 구축하는 방법을 배우려고 노력한 결과, 학계와 산업 소프트웨어 개발을 접목할 수 있었다. 저자는 컴퓨터 과학 학위 세트(학사, 석사, 박사)가 있으며 박사는 카네기 멜런 대학교의 소프트웨어 엔지니어링 분야에서 취득했다. 연구한 논문의 주제는 많은 개발자가 직면하는 문제인 ‘소프트웨어 프레임워크’였다. 프레임워크 사용 방법을 설명하려고 ‘design fragments’라는 새로운 사양을 개발했고, 올바르게 사용하는 중인지 확인할 수 있는 이클립스 기반 도구를 구축했다. 데이비드 갈란과 빌 셜리스의 지도를 받았고, 논문심사위원회에는 영광스럽게도 조너선 올드리치와 랄프 존슨이 참여했다. 학업 중에는 이론적인 내용을 배웠으며, 현업에서 실질적인 부분을 더 익힐 수 있었다. 노텔 DMS-100 중앙 사무실 전화 스위치(central office telephone switch), 운전 시뮬레이터(driving simulator)용 통계 분석, TW Telecom의 IT 애플리케이션, 이클립스 IDE용 플러그인, 그리고 웹 스타트업의 모든 코드를 포함한 프로젝트에 소프트웨어 개발자로 참여했다. 아마추어 시스템 관리자로서 리눅스 박스를 만지고, 컴퓨터 LED를 벽장의 미등처럼 사용했으며, 전원 공급 장치를 난방기처럼 사용했다. 그리고 초창기부터 애자일 기법을 지지해왔다. 1996년 몸담았던 부서의 6개월 개발 주기를 2주로 단축했고, 1998년 테스트 주도 개발을 시작했다. 현재 구글의 소프트웨어 엔지니어다. 구글 애드 익스체인지(AdX)를 포함한 다수의 프로젝트에서 테크니컬 리더로 활동 중이다.

이승범 역자

이승범

아일랜드에 있는 더블린시티 대학교에서 박사 학위를 받고, 2010년부터 안드로이드 기반 휴대폰 소프트웨어의 멀티미디어 기능 및 서비스 개발 업무를 리드해왔다. 소프트웨어 아키텍처, 애자일 방법론(특히 애자일 매니지먼트)에 관심이 많다. 최근에는 복잡계 및 센스메이킹에 관심을 가지고 애자일 코치, 소프트웨어 개발자들과 교류하며 스터디와 콘텐츠 제작도 한다.

CHAPTER 1 개요

_1.1 분할, 지식, 추상화

_1.2 소프트웨어 아키텍처 세 가지 예시

_1.3 되돌아보기

_1.4 관점 이동

_1.5 아키텍처를 아키텍처링하는 아키텍트

_1.6 리스크 주도 소프트웨어 아키텍처

_1.7 애자일 개발자를 위한 아키텍처

_1.8 이 책에 대하여

 

 

PART I 리스크 주도 소프트웨어 아키텍처


CHAPTER 2 소프트웨어 아키텍처

_2.1 소프트웨어 아키텍처 개요

_2.2 소프트웨어 아키텍처가 중요한 이유

_2.3 아키텍처가 중요한 상황은?

_2.4 추정 아키텍처

_2.5 소프트웨어 아키텍처 사용법

_2.6 아키텍처 무관 설계

_2.7 아키텍처 집중 설계

_2.8 아키텍처 상향 설계

_2.9 대규모 조직에서의 아키텍처

_2.10 마치며

_2.11 참고 자료

 

CHAPTER 3 리스크 주도 모델

_3.1 리스크 주도 모델 개요

_3.2 리스크 주도성 자가 진단

_3.3 리스크

_3.4 기법

_3.5 기법 선택 가이드

_3.6 적정한 투자

_3.7 계획 설계와 진화적 설계

_3.8 소프트웨어 개발 프로세스

_3.9 프로세스 변동의 이해

_3.10 리스크 주도 모델과 소프트웨어 프로세스

_3.11 애자일 프로세스에 적용

_3.12 리스크와 아키텍처 리팩터링

_3.13 리스크 주도 모델의 대안

_3.14 마치며

_3.15 참고 자료

 

CHAPTER 4 예제: 홈 미디어 플레이어

_4.1 팀 커뮤니케이션

_4.2 상용 기성품 컴포넌트 통합

_4.3 메타데이터 일관성

_4.4 마치며

 

CHAPTER 5 모델링 관련 조언

_5.1 리스크에 집중하기

_5.2 아키텍처 이해

_5.3 아키텍처 기술 배포

_5.4 합리적인 아키텍처 선택

_5.5 지나친 선행 설계 미리 피하기

_5.6 하향식 설계 방지

_5.7 남은 과제

_5.8 기능과 리스크: 예시

 

 

PART II 아키텍처 모델링


CHAPTER 6 엔지니어가 사용하는 모델

_6.1 규모와 복잡성에 필요한 추상화

_6.2 통찰력과 지렛대 효과를 제공하는 추상화

_6.3 시스템 품질 추론

_6.4 세부 사항을 제거하는 모델

_6.5 추론을 증폭하는 모델

_6.6 질문이 먼저, 모델은 그다음

_6.7 마치며

_6.8 참고 자료

 

CHAPTER 7 소프트웨어 아키텍처의 개념 모델

_7.1 정준 모델 구조

_7.2 도메인 모델, 디자인 모델, 코드 모델

_7.3 지정 및 구체화 관계

_7.4 마스터 모델의 여러 가지 뷰

_7.5 모델을 구성하는 다른 방법

_7.6 비즈니스 모델링

_7.7 UML 사용

_7.8 마치며

_7.9 참고 자료

 

CHAPTER 8 도메인 모델

_8.1 도메인과 아키텍처의 관계

_8.2 정보 모델

_8.3 탐색 및 불변 사항

_8.4 스냅샷

_8.5 기능 시나리오

_8.6 마치며

_8.7 참고 자료

 

CHAPTER 9 디자인 모델

_9.1 디자인 모델

_9.2 경계 모델

_9.3 내부 모델

_9.4 품질 속성

_9.5 인저 시스템 설계 살펴보기

_9.6 뷰타입

_9.7 동적 아키텍처 모델

_9.8 아키텍처 기술 언어

_9.9 마치며

_9.10 참고 자료

 

CHAPTER 10 코드 모델

_10.1 모델 코드 격차

_10.2 일관성 관리

_10.3 구조적으로 명확한 코딩 스타일

_10.4 코드에서 설계 의도 표현

_10.5 코드 내 모델 원칙

_10.6 표현할 내용

_10.7 코드에서 설계 의도를 표현하는 패턴

_10.8 이메일 처리 시스템 둘러보기

_10.9 마치며

 

CHAPTER 11 캡슐화 및 파티셔닝

_11.1 여러 수준의 스토리

_11.2 계층 구조 및 분할

_11.3 분해 전략

_11.4 효과적인 캡슐화

_11.5 캡슐화된 인터페이스 구축

_11.6 마치며

_11.7 참고 자료

 

CHAPTER 12 모델 요소

_12.1 할당 요소

_12.2 컴포넌트

_12.3 컴포넌트 조립도

_12.4 커넥터

_12.5 설계 결정

_12.6 기능 시나리오

_12.7 불변 사항(제약 조건)

_12.8 모듈

_12.9 포트

_12.10 품질 속성

_12.11 품질 속성 시나리오

_12.12 책임

_12.13 트레이드오프

_12.14 마치며

 

CHAPTER 13 모델 관계

_13.1 투영(뷰) 관계

_13.2 분할 관계

_13.3 구성 관계

_13.4 분류 관계

_13.5 일반화 관계

_13.6 지정 관계

_13.7 구체화 관계

_13.8 바인딩 관계

_13.9 종속성 관계

_13.10 관계의 사용

_13.11 마치며

_13.12 참고 자료

 

CHAPTER 14 아키텍처 스타일

_14.1 장점

_14.2 개념 스타일 대 구현 스타일

_14.3 제약 조건 및 아키텍처 집중 설계

_14.4 패턴 대 스타일

_14.5 스타일 카탈로그

_14.6 계층 스타일

_14.7 큰 진흙 뭉치 스타일

_14.8 파이프와 필터 스타일

_14.9 일괄-순차 스타일

_14.10 모델 중심 스타일

_14.11 발행-구독 스타일

_14.12 클라이언트-서버 스타일 및 다중 계층

_14.13 P2P 스타일

_14.14 맵리듀스 스타일

_14.15 미러링, 랙, 팜 스타일

_14.16 마치며

_14.17 참고 자료

 

CHAPTER 15 아키텍처 모델 사용하기

_15.1 바람직한 모델 특성

_15.2 뷰를 이용한 작업

_15.3 뷰 품질 향상

_15.4 다이어그램 품질 개선

_15.5 테스트 및 증명

_15.6 아키텍처 모델 분석

_15.7 아키텍처 불일치

_15.8 추상화 수준 선택

_15.9 사용자 인터페이스 계획

_15.10 규범 모델 대 설명 모델

_15.11 기존 시스템 모델링

_15.12 마치며

_15.13 참고 자료

 

CHAPTER 16 결론

_16.1 당면 과제

_16.2 품질 속성에 집중

_16.3 모델링이 아니라 문제 해결

_16.4 제약 조건을 가이드 레일로 사용

_16.5 표준 아키텍처 추상화 사용

리스크 관리 중심의 적정한 설계를 위한 소프트웨어 아키텍처 가이드

 

처음부터 완벽한 소프트웨어 개발 설계 방법이 있을까? 이 책은 설계의 적정한 수준은 무엇이며, 리스크 관리 중심으로 아키텍처를 설계하는 방법은 무엇인지, 어떻게 전략적으로 자신의 프로젝트에 적용할 수 있는지 자세히 설명한다. 다루는 내용과 수준은 실무 소프트웨어 개발자뿐 아니라 미숙한 개발자나 고학년 학부생까지 총망라한다. 

소프트웨어 아키텍처의 필수 개념, 아키텍처 설계를 수행하는 추천 시기와 현실적인 조언, 다양한 모델과 스타일, 리스크 관리 중심의 설계 적용 방법을 배우고 여러분의 아키텍처 설계에 필요한 실용적이고 적절한 해결책을 찾길 바란다. 

 

 

주요 내용

  • 리스크 주도 아키텍처링: 직면한 리스크에 따라 적정한 아키텍처 설계를 수행하는 방법
  • 참여하는 아키텍처: 아키텍트뿐 아니라 모든 소프트웨어 개발자를 위한 아키텍처
  • 선언적 지식: 기법을 적재적소에 사용하기 위한 개념과 용어
  • 엔지니어링 강조: 소프트웨어 개발의 기술적인 부분과 시스템 작동을 위한 엔지니어링
  • 실용적인 활용 방법: 상위 아키텍처부터 하위 자료 구조 설계까지 다양한 수준의 모델을 활용하는 접근 방법

 

추천사

 

명쾌한 설명과 흥미로운 사례가 넘친다. 일찍부터 이 책이 있었다면 상당히 많은 실수를 피할 수 있었을 것이다. 더 나은 소프트웨어 아키텍처가 되고 싶다면 이 책을 항상 곁에 두길 바란다.

_티머시 핼러런 박사, SureLogic 엔지니어링 디렉터

 

이 책은 소프트웨어 아키텍처를 쉽게 적용하고 실용적으로 만드는 독특한 관점을 제시한다. 적정 아키텍처와 리스크 주도 설계의 개념은 획기적인 아이디어다. 이 책은 아키텍처 원칙을 실제 사례에 효과적으로 적용할 수 있는 방법을 보여준다. 소프트웨어 개발 분야에서 일하는 모든 사람이 반드시 읽어야 할 매우 유용한 책이다.

_마커스 폰토라 박사, Yahoo! 리서치 수석 연구원 및 아키텍트

적정, 소프트웨어, 아키텍처 그 어느 것 하나 흥미롭지 않을 수가 없다. 프로젝트의 설계를 고민하면서 끊임없이 머릿 속에 드는 생각은, ‘너무 적게/많이 조합/분리 했나?’ 였다. 소프트웨어 설계는 절대적 정답이 없다. 어제의 정답이 오늘의 오답이 될 수 있다. 더 나은 방향을 찾기 위해 고찰하고 있는 와중에 **적정 소프트웨어 아키텍처**를 읽게 되었다.

> 프레더릭 브룩스가 말했듯이 소프트웨어 개발의 어려움을 제거할 은제 탄환을 기대해서는 안 된다. 대신 시스템을 더 잘 분할하고, 지식을 제공하고, 추상화로 문제의 본질을 드러내는 무기를 찾아야 한다.

이 문장이 이 책의, 소프트웨어 설계를 관통하는 핵심이라고 생각했다.

책에서는 세 가지 접근 방식으로 설계 방식을 나눈다.

아키텍처 무관 설계
아키텍처 집중 설계
아키텍처 상향 설계

요약하면, 무관 설계는 목표까지 아키텍처를 고려하지 않는다. 집중 설계는 의도적으로 소프트웨어 아키텍처를 설계한다. 상향 설계는 시스템의 목표나 속성을 보장할 목적으로 설계하는 일종의 집중 설계다.

나는 대부분 집중 설계 방식으로 접근하고 있다. 지금까지 품질(목표)을 위한 설계는 고려해보지 않았는데, 이번 기회에 어떤 목표를 설계로 달성할 수 있을지 고민해봐야겠다는 생각이 들었다.

> 아키텍처 이해의 핵심은 '왜'로 시작하는 질문에서 얻을 수 있다. 이해한다고 해서 특정 프로세스를 따르거나 특정 언어로 프로그램하거나 종이에 다이어그램을 작성해야 하는 것은 아니다. 소프트웨어 아키텍처를 이해한다는 말은 (불완전하고 불완벽하지만) 지식과 추상화를 머리에 자리 잡게 해서 새로운 시스템을 구축하거나 기존 시스템을 분석할 때 이해한 내용을 활용할 수 있다는 의미다.

(저자의 의도가 어떻든 간에) 위안이 되었던 것은, 이해하지 못한다고 해서 두려울 필요가 없다는 말이었다. 아는 만큼 보인다던데, 보이는 게 많이 없어서 아직도 갈 길이 멀구나 싶었다.

아는 게 없어서 이론적인 부분은 솔직히 지루했다. 와중에 홈 미디어 플레이어라는 예제를 넣었는데 그 부분은 흥미롭게 읽었다. 있을 법한 프로젝트로 내용을 녹여낸 것이 좋았다. 더불어 전반적으로 이해를 돕기 위한 다이어그램이 삽입되어 있어서 글과 함께 읽기에 좋았다. 또, 모호할 수 있는 표현은 영어와 같이 병기한 것도 좋았다.

책에서는 독자로 미숙한 개발자, 숙련된 개발자, 소프트웨어 아키텍트, 학계 관련 인사를 꼽는다. 소프트웨어 공학 공부를 막 끝마치고 따끈따끈한 두뇌일 때 이 책을 읽으면 좋지 않을까? 어디까지나 개인적인 견해다.

---

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

 

이번에 한빛 미디어에서 "적정 소프트웨어 아키텍쳐"라는 책을 제공 받아 서평을 쓰게 되었다.

책의 서문에도 적혀있듯, 리스키한 환경의 소프트웨어 엔지니어들의 소프트웨어 아키텍쳐 설계에 대한 내용인데.. 결론부터 이야기해보자면 책이 꽤 어렵다. 어쩌면 내가 잘 몰라서 & 관심이 상대적으로 적은 분야여서 그럴 수도 있다. 

 

그렇지만 책의 구성과 짜임새는 잘 짜여져 있어서 읽어나가는 데에는 큰 어려움이 없었다. 

책의 내용은 어렵다고 적었지만, 현업과는 밀접한 관계가 있는 내용들이다. 현재 회사에서 스크래치부터 소프트웨어를 개발하고 있는데, 그 회의에서 나오던 내용들의 흐름을 이해하는 데에 책의 내용이 큰 도움이 되었다. 아래 첨부된 사진대로 소프트웨어 아키텍쳐에 관심있는 학부 고학년이나 실제 소프트웨어 아키텍쳐를 다루는 시니어급 개발자들이 보면 좋을 것 같다. 쥬니어들의 경우는 업무의 흐름을 이해하는데에 큰 도움이 될 것 같다. 

 

 

개발자에서 아키텍트로 진화해 나아가길 바라는 나에게는 새로운 아키텍처 관련 도서가 출판된다는 소식은 매우 반가운 소식이다. 아키텍처와 관련된 도서는 대부분 구매하여 읽었고, 학습하였다. 이번 도서도 구매 준비 중이였는데, 마침 한빛리더스의 리뷰 활동 지원 도서로 리스트에 있어서 아무런 고민 없이 선택하였다.

 

양장본의 힘

처음 택배를 뜯었을 때 양장본의 그 딱딱한 촉감이 내 손바닥에 느껴졌을 때의 기분이 잊혀지질 않는다. 출판사에서 정말 준비를 많이 했구나. 보통 개발 서적은 양장본으로 출간하지 않는다. 소설과 같은 베스트셀러 도서들도 재출간, 이벤트 기념으로 양장본을 일부만 출간한다. 그 만큼 제작에 비용이 많이 들고 많은 사람들이 찾을 거라는 자신감이 없다면 하기 힘든 결정이다.

그런데 처음 출간되는 도서의 표지를 양장본으로 했다는 것 자체가, 출판사와 번역가, 출판 담당자 모두가 자신있다는 신념이 있다는 것이 아닐까 생각된다. 아무튼 나는 이 딱딱한 질감과 책이 주는 느낌이 너무나도 좋다. 일반 표지에서는 너무나 합격! (사실 표지 이미지도 너무 마음에 든다.)

 

리스크 주도??

 

 

개발을 하다보면 도메인 주도 개발(Domain Driven Development), 테스트 주도 개발(Test Driven Development) 등 다양한 주도 개발 방법론을 접할 수 있다. 하지만 리스크 주도 접근법이란 것 을 처음 들어본 나는 어떤 방식의 설계 기법일 지 너무나 궁금하였다.

처음 책을 읽기 전에 생각한 내용은 프로젝트의 리스크가 발생했을 때 마다 설계를 변경하는 것인가? 이러한 방법은 옳지 않다는 것을 많은 이 들이 알텐데, 리스크란 개발자들의 손안에서 관리할 수 있는 장난감과 같은 것이 아닌데 이러한 위험성을 어떻게 관리하려는 것인가? 등 많은 생각들이 스쳐지나갔다. 

솔직히 말해서 조금 의외였다. 내가 알고있는 아키텍처 설계 기법과는 다르게 직면한 리스크에 따라 적정한 아키텍처 설계를 수행하는 방법을 가이드 한다는 게 이해가 쉽지 않았다. 책을 읽다보니 내가 생각한 리스크 관리와는 조금 달랐다. 처음 관리할 수 있고 예방 가능한 리스크에 대해서는 설계에 녹여 대비하도록 하고, 후에 애자일과 결합하여 발생하는 리스크에 대해서는 설계 안에 조금씩 적용시켜 나아가는 것이다.

솔직히 예상치 못한 리스크 발생을 대처할 수 있는 커다란 팁이 있을 것 같은 제목이라 궁금했는데, 그러한 내용을 이야기 하고자하는 것은 아니였다. 우리 팀에서 진행하는 설계, 개발방법과 유사한 방법이였다.

 

다이어그램, 이미지 등을 통한 상세한 설명

 

 

 

처음 아키텍쳐 공부를 하는 개발자들은 일단 다이어그램부터 익숙하지 않고, 세상에 이렇게 많은 다이어그램이 있었나 싶을 정도로 혼란스러워 한다. 각 다이어그램은 어떤 용도로 어떤 경우에 사용할 수 있는 것이고 어떤 정보를 포함할 수 있는가 등 매우 어려워 했다. (내 주변 지인들의 경험이다.)

이런 다이어그램을 표와 그림을 통해 상세하게 설명하고 넘어간다. 솔직히 한번 이해한다고 머리속에 영원히 기억되는 것은 아니라는 것을 모두가 안다. 하지만 처음 이해를 제대로 해둔다면 추후에 다시 찾아보았을 떄 이해도와 적용의 시간이 매우 빨라지는 것 또한 모두가 알 것 이다.

추천하는 것은 각 다이어그램의 특성과 사용 용도, 작성법 등은 꼭 한번은 제대로 정리하고 넘어갔으면 한다.

 

빠질 수 없는 아키텍처 설명

당연히 빠질 수 없는 내용이 아키텍처 설명이다. 매우 단순한 파이프 앤 필터 아키텍처부터 맵 리듀스 등 다양한 아키텍처를 설명한다.

이 도서의 아키텍처만으로 모든 아키텍처를 다 공부했다고 할 순 없다. 물론 이 책의 포함된 아키텍처도 다양하지만 매우 소수에 불과하다. 지금도 새로운 기술과 그 기술들이 접목되어 더욱 효율적이고 각 환경에 알맞은 아키텍처가 나타나고 있다. 특히 이 도서에 포함된 아키텍처로는 클라우드 환경의 복잡한 아키텍처를 이해하고 접목하는 것은 쉽지 않을 것이다.

하지만 그럼에도 기초적인 이러한 아키텍처들은 꼭 익혀둬야 한다. 하나의 아키텍처안에 다양한 아키텍처가 녹아들어 있다. 그런 큰 구조의 그림을 파악하고 이해하기 위해서는 단일 아키텍처로는 지금 사용하지 않지만 이 책에서 설명하고 있는 아키텍처에 대한 이해를 소홀히 하지 않았으면 좋겠다.

 

가장 추천하는 내용

흥미로우면서도 친근한 리스크 주도 모델을 이용하여 애자일 방법론에 접목하여 어떻게 리스크를 관리하고 설계를 발전시켜 나가는지 설명하는 내용들은 잘 정리해 놓고 실제로 팀에 적용해 보면 어떨까 하는 생각을 많이 하게 되었다. 실제로 유사한 부분도 많지만 일부 차이나는 갭을 메우고 조금 더 좋은 방향으로 프로젝트 진행 방향을 유도할 수 있지 않을까 하는 생각도 하게 되게 만드는 책이였다.

이 책이 너무 어려운 사람들은 한빛미디어에서 출간한 '개발자에서 아키텍트로' 라는 도서를 먼저 읽어보는 것도 추천한다. 처음 개발자에서 아키텍트를 꿈꾸는 사람들에게 어떤게 아키텍트인지 하나의 프로젝트를 진행해 나가면서 이해를 시켜 줄 것이다.

 

조금.. 아쉬운 점?

이 책에서 조금 아쉬운 점이라면 아키텍처 패턴에 관한 내용이다. 물론 아키텍트는 요구사항 분석 부터 도출, 설계, 최적 설계 등 다양한 단계를 고려해야 한다. 아키텍트는 아키텍처 패턴을 이용해 설계만 하는 사람이 아니라는 것은 안다. 하지만 그럼에도 불구하고 너무 최신 트렌드를 조금 반영하지 못한 고전적인 패턴들의 향연은 아쉬움이 남는다. 물론 고전적인 패턴이 지금까지 사용되는 이유는 있다. 하지만 앞에서도 말했듯이, 요즘 앱, 웹, 클라우드 등의 시스템에서 적용되는 아키텍트 패턴들과는 조금 거리가 있는 것도 사실이긴 하다. 다양한 패턴에 대해 조금 더 다뤘으면 좋지 않았을까 하는 아쉬움이 조금은 남는다.

 

 

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

 책이 양장본으로 나왔다. 매우 고급스럽게 나와서 보관용으로도 훌륭할 뜻 하다.

 많은 아키텍처 책들이 있고 아키텍처에 관련된 책들은 모두 좋은 듯하다. 이 책또한 아키텍처에 관련된 책이기 때문에 좋은 듯 하다.

예전부터 아키텍처에 관심이 많았지만 프로젝트에서 아키텍트 직함을 가져 본 적은 없다. 그래서 아키텍트에 관련해서는 되고 싶다는 생각을 많이 가지고는 했다. 그런 아쉬움을 어느정도 해소해 줄 수 있는 책이라고 생각된다. 여러가지의 예시(다이어그램, 소스 코드, 쉘 스크립트 등)를 통해 적정한 내용을 찾아서 활용하기 좋을 뜻 하다.

 아키텍트가 되기 위해서 이 책에 나온 내용을 프로젝트에서 조금씩이라도 적용해 보는 것이 중요할 뜻 하다. 기존에 있는 프로젝에서 책에 나온 대로 모델을 만들어서 분석을 하고, 그 개선점을 찾는다면 스스로가 좀 더 발전하는 모습을 찾을 수 있을 것이다.

 아키텍트를 꿈꾸는 사람들은 이 책을 통해서 프로젝트에 적용하다 보면 어느세 아키텍트에 한 걸음 좀 더 다가갈 수 있을 것이다.

 

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

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

 

 보통 처음 개발을 할때는 개발문화가 정말 좋은 조직이 아니고선 구현에 초점을 두지 전체적 구조를 생각해볼 기회는 적은 것 같다. 특히 경력을 시작하게 된 조직이 아직 큰 데이터가 없으면서 MVP처럼 빠른 개발을 목적으로 하는 상황이라면 말이다.

 그러나 연차가 어느정도 차게 되면 전체적 아키텍처의 중요성이 서서히 와닿기 시작하는데 이런 시기에 접하기 좋은 책중 하나같다.

 

스크린샷 2022-11-27 오후 9.31.31.png

 

 이 책은 그중에서도 리스크 주도 소프트웨어 아키텍처를 다루고 있으며, 1부와 2부로 나뉘어져있다. 1부에서는 소프트웨어 아키텍처와 리스크 주도 접근 방식에 대해 소개하고 2부에서는 소프트웨어 아키텍처의 개념 모델을 설명한다.

 

본문발췌

 

....리스크 주요모델을 소개한다. 핵심 아이디어는 소프트웨어 아키텍처를 설계하는데 드는 노력이 프로젝트의 리스크에 비례해야한다는 것이다.

 

 리스크 주도 모델은 다음 세 단계로 요약할 수 있다. 1. 리스크 식별 및 우선 순위 지정 2. 일련의 기법 선택 및 적용 3. 리스크 감소 평가

 

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

 

도메인 모델에서 표현할 수 있는 가장 순수한 지식은 사람이 만들어낸 인공적인 진실보다는 자연에서 나온 진실이다.

 

디자인 모델은 설계에 관한 모든 세부사항을 포함하는 마스터 모델이다.

 리스크를 메인으로 아키텍처 짜는 것에 대해서 총 망라해서 다루고 있다. 각 모델에 관해서 소게하고 UML등으로 좀 더 자세한 설명을 곁들인다. 물론 그럼에도 불구하고 다소 어려운 부분은 있다. 자세한 설명을 곁들이긴 했지만 경험이 부족한 입장에서 실제 상황에서 어떻게 적용되는지는 직접 부딪쳐보기 전까지는 확실하게 알 수 없는 부분들이 있었기 때문이다.

 하지만 그거랑 별개로 여러번 읽어볼 가치가 있는 책이라는 생각이 들었다. 1회독이라 내용을 쫓아가는 부분만으로도 벅찼는데 이후에는 아예 스터디를 구성해서 각 모델별로 적용 사례등을 찾아보는등으로 읽어보면 각 모델이나 사례들이 더 와닿을 것 같다.

 

 

 

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

예전에 소프트웨어 아키텍처 관련 책을 본 적이 있었다. 책 두께에 놀라고 읽다보면 어느것 하나 불필요한것이 없어보이고, 중요하지 않아 보이는게 
없어보여 모든것을 다 만들어야 할 거 같았었다.  그래서인지 이 책을 볼 때도 두려움과 부담감이 크게 느껴졌었다.

'아키텍처' 라는 용어는 건축에서 차용됐다. 아키텍처를 만드는 사람을 아키텍트라고 한다.
SW를 만들때는 바로 코딩에 들어가는게 아니라 충분한 분석과 설계를 하여 UML이나 문서등을 이용한  수많은 산출물들을 작성한다. 견고한 SW, 목적에 맞는 SW를 만들기 위해서다. 충분한 시간을 분석설계에 사용한다면 좋은 SW가 나올 수 있다. 

이 책은 크게 2파트로 구성되어있다.
파트1은 저자의 의도가 담긴 리스크 주도 소프트웨어 아키텍처 설계에 대한 내용이 그리고 
파트 2에는 일반적인 아키텍처 설명이 1:2정도의 비중으로 들어가있다.

리스크가 적은 프로젝트는 아키텍쳐계획을 적게하거나 아니면 아예 하지 않을 수 있다. 하지만 리스크가 큰 프로젝트는 반드시 아키텍쳐 작업이 필요하다
닭 잡는데 소잡는 칼을 쓸 필요없이 리스크를 해결할 정도의 적절한(Just Enough) 아키텍처를 선택할 수 있으면 된다. 
아키텍처 무관설계, 아키텍처 집중 설계, 아키텍처 상향설계등으로 나뉜다.
 
리스크 주도 모델은
- 내 리스크가 무엇인가? 의 리스크식별
- 이를 줄이는 가장 좋은 기법은 무엇인가? 의 일련의 기법적용
- 리스트가 완화되었고 코딩을 시작할 수 있는가? 의 리스크 감소평가
로 이루어진다.

이런 리스크 주도 모델은 모든 SW개발 프로세스에서 사용할 수 있습니다.(ex: 애자일에서 리스크를 기능 및 리스크 백로그처럼 백로그로 관리하여 반복적으로 처리)
리스크를 줄일 기법을 선택할 때는 노력(시간,비용등 )이 필요한 법인데 이는 실패 리스크에 비례해야 한다. 감수해야할 리스크가 적다면 설계에도 굳이 시간을 할애할 필요는 없다.


저자가 교재로 쓰이길 원했을 정도이니 용어 설명이나 다이어그램 설명, 참고문헌 정리등이 꽤 잘 정리되어 있었음
단지 이론적인 내용 뿐 아니라 경험에서 우러나온 장점 및 단점 고려해야할 점등을 옆에서 이야기해주는 느낌이었음
전자책으로 읽었는데 어디서나 읽을 수 있다는 점은 장점이었고, 모바일에서 페이지이동이나 검색이 안되는 점은 불편했음


구상한 모든 것을 단번에 구현하던 수준이었던 소프트웨어 개발은 다중 스레드/프로세스, RPC, 프레임워크나 컴포넌트를 이용하는 것이 일상이 되었고, 갈수록 덩치가 커지고 복잡해지는 소프트웨어를 개발을 성공하기 위해 다양한 설계, 개발 방법 이론이 주목받게 되었습니다. 이론 제안, 정립과 병행하여 이를 실천할 수 있는 다양한 구현체, 도구의 개발 필요성도 생겼습니다. 좋은 소프트웨어 개발이라는 목적 달성을 위해 만들어진 소프트웨어 설계 원칙, 아키텍처/디자인 패턴, 언어별 각종 이디엄, UML, 그밖에 여러 소프트웨어 설계 도구들이 이러한 이론과 구현체입니다. 하지만, 소프트웨어 설계 이론은 실제 개발 방법으로 부드럽게 이어지는데 크고 작은 저항이 있습니다. 소프트웨어 개발에 있어서 설계가 필수불가결하다는 건 알겠는데, 설계하는 자는 기능/성능을 모두 명세하여 펼치고 훗날 확장성과 유지 보수까지 고려한 모든 것을 문서화 하고 싶고, 구현하는 자는 애자일, 동적 언어, 기능 위임 등 기술적 대안을 활용하여 충분히 예측 가능하고 상식적인 부분의 설계는 생략하고 싶어 합니다. 빠른 변화와 유연한 대응을 요구하는 현대 IT 환경은 이에 대한 대립을 더욱 첨예하게 만듭니다.

 

이 책의 주제는 리스크를 고려한 설계로 실용적인 결과물을 도출하라는 것입니다. 적정 수준의 설계 필요성과 가치에 대해 설명하고 고려할 것과 생략할 것을 결정하는 방법과 통찰력을 제공합니다. 평가된 리스크가 작다면 꼼꼼한 디자인으로 엄격한 설계를 하여 실패 확률을 줄이고, 그렇지 않다면 느슨함을 통해 효율성을 높이는 겁니다. 리스크를 고려하여 소프트웨어 개발의 설계를 추진하고(A Risk-Driven Approach) 이를 통해 모두가 공감하고 성공적이며 실용적인 소프트웨어 설계(Just Enough Software Architecture)를 얻을 수 있다는 게 이 책의 제목입니다. 다분히 이론적이고 선악식 접근으로, 단순 맹목적이 아닌 리스크의 크고 작음에 따라 적정한 수준의 설계 분량을 설정하고 시간을 투자한다는, 철저히 필요에 의한 실용적인 방법으로 소프트웨어 설계를 설명합니다.

 

이 책의 장점을 꼽자면 아래와 같습니다.

 

1.

컴퓨터를 전공하지 않거나 이론적인 바탕 없이 실무 경험을 만들어 가고 있는 이들을 위한 소프트웨어 아키텍처 관련 기본 소양서로 훌륭합니다. 다른 아키텍처 도서와의 접근방법 차이점은 차치하더라도 실제 소프트웨어 설계 및 정립 개념을 연구 사례와 예제를 곁들여 알아갈 수 있습니다.

 

2.

전문가의 관점으로 소프트웨어 개발 과정을 조망하며 모델링을 전체적으로 살펴볼 수 있는 좋은 기회를 제공합니다. 챕터 구성이 잘 되어 있고, 용어 정의 집, 참고 문헌의 정보와 단어에 해당하는 책 내용을 바로 찾아볼 수 있는 색인이 있어 활용도가 높습니다.

 

3.

관련 개념과 정의, 용어를 쉽게 설명합니다. 이 책의 대상은 책 주제와 내용 특성상 충분한 이론적 바탕이나 기본적인 개발 경험을 갖춘 중급 이상의 개발자나 동등한 경험을 갖춘 초급 아키텍트입니다. 예를들어 [캡슐화 및 파티셔닝(11장)]의 경우 모든 개발자가 언젠가는 알아야 되는 내용을 읽기 쉽고 뚜렷하게 구성하여 서술하고 있습니다. 다만, 독자의 사전 지식에 따라, 예를들어 추상 자료형(ADT)의 경우 70년대 초반 개념으로 내용이 진부할 수도 있고, 책 중반의 상단 분량의 모델링과 관련된 내용은 지루할 수도 있습니다.

 

4.

관련 분야 전문가가 검증하고 실제 업계에서 두루 사용되는 표준 이론 및 어휘를 배우고 확인할 수 있습니다. 이런 의미에서 훌륭한 레퍼런스 도서이며, 모니터 옆 책장 한켠을 차지할 만하고 이러한 관점에서 본 도서의 두꺼운 표지와 양장본은 좋은 선택이라 생각됩니다.

 

5.

책 내용을 서점에서 요약하여 간단히 읽고 싶다면 3장을 읽어 볼 것을 추천합니다. 리스크를 정의하고 진단법을 개괄한 뒤 리스크 주도 모델에 대한 설명과 적용 방법을 안내하고 있습니다.

 

소프트웨어 아키텍처를 설명하기에 분량이 얇아 기대보다 많은 것을 다루지는 않을 수 있습니다. 개발 도서처럼 결과가 가시적이거나 실습을 통해 확인하기는 어려운 부분이 있는 만큼 자칫 이론 중심적이고 서술이 장황하게 느껴질 수도 있습니다. 또한 오늘날 위협으로부터의 보안이 기본적으로 반영된 설계를 해야 할 때는 전혀 맞지 않는 방법일 수도 있습니다. 하지만 리스크에 집중하고 모델링 관련 통찰력을 느끼는 데는 전혀 문제되지 않습니다. 이 도서에서 습득한 내용을 의식적으로 개발과정에서 실천하고 있다면 한 단계 높은 수준으로 올라선 개발자가 되었다고 자부심을 가져도 될 것 같습니다.

 

 

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

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

요즘은 아키텍처 책을 계속 보게 되네요.

이 책을 보고 처음 받은 인상은 딱딱하다 였습니다.

요즘 못 보던 Hardcover 였기 때문이기도 하지만,

최근 보던 책들이 좀 더 가볍게 쓰여져 있었다면, 이 책을 좀 더 진중하게 다루고 있습니다.

아마도 '아키텍처 무용론'에 대한 저자의 대답으로써 이 책을 쓴게 아닌가 생각합니다.

제가 생각한 것을 간단히 정리 하자면,

어떤 소프트웨어도 아키텍처가 없는 것은 없고, 별로 도움이 안되는 부분까지 아키텍처를 만들어서 비판을 받고 있으니,

리스크가 높은 부분은 좀 더 아키텍처를 잡는데 시간과 노력을 들이고,

그렇지 않은 부분은 좀 더 간편하게 하는게 좋겠다는 것이고,

아키텍처의 적절성의 평가는 리스크 감소에 얼마나 효과가 있었는지 하는 것이었습니다.

좋은 내용이기는 한데, 이런 적절, 적정 또는 중용 같은 단어는 객관적으로 판단하기 어렵다는 점이 있고,

결국 경험과 환경에 따라 달라질 수 있는 것이라 절대적으로 따라야 하는 가이드 제시가 아니고

아키텍처를 결정하는 방법론에 대한 이야기 입니다.

책의 전반부에서는 저자가 말하는 방법론인 '리스크 주도 모델'에 대한 전반적인 설명을 하는 부분으로 3장이 이 책의 핵심이라고 생각합니다.

후반부는 구체적인(?) 모델들을 설명합니다.

특별히 번역이 이상하다고 생각하지는 않지만,

그동안 제가 사용하던 용어와 좀 다른 범주로 쓰인 것 같은 느낌이 들어서 (또는 잘 못 사용하던?)

읽고 이해하는게 쉽지는 않은 책이었습니다.

소프트웨어 개발을 시작할 때 볼만한 가이드북리스크는 무엇인고,

아키텍처의 설계 원칙은 어떻게 적용하고 해결하는지에 대해서 알려줍니다.

 

책 앞 부분에 추천사나 지은이, 옮긴이의 말을 보면

소프트웨어 개발을 "시작할 때" 보면 좋은 책인 걸 알 수 있습니다.

즉 실제 개발을 하기 전에 설계를 할 때 보면 좋은 책입니다.

 

 

그림보다는 글 위주로 채워져 있습니다.

 

 

그림은 별로 없지만 글 자체가 굉장히 자세히 써져 있습니다.

 

 

아무래도 글 위주이다 보니

책 중간중간에 예제를 넣어서 이해를 하기 쉽게 만들어줬습니다.

예제를 보면서 흐름에 따라가면서

 

읽으면 책이 전달하고자 하는 내용을 잘 알 수 있습니다.

 

 

글로만 이해하기 어려운 부분은 그림도 넣어서 이해를 하기 쉽게 만들었습니다.

개발을 처음 시작할 만한 사람들이 볼 만한 책은 아닙니다.

저도 읽으면서 많이 어려웠네요

개발을 어느 정도 하고 경험이 쌓였을 때

어떻게 설계를 하는지에 대한 고민이 생기기 시작했을 때

 

보기 좋은 책이라고 생각합니다.

 

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

  개발자 커리어 트랙에 올라선 지 몇 년 되지 않았다. 이곳 세계도 알면 알수록 넓은 세상이라는 것을 배워가고 있다. 한빛 미디어 리뷰어 활동도 그 여정 중에 우연히 참여하게 된 것이고, 이곳에서 IT분야의 신간 서적들을 조금이나마 빠르게 접해볼 수 있다는 것은 또 하나의 행운이고, 감사한 일이라 여기고 있다.

  'SW 개발'이라는 분야에서 '아키텍처'라는 것을 알게된것도 얼마 되지 않았다. 다만 일을 하며 직관적으로 내 머릿속에서는 어느 정도의 구조 설계와 흐름 등이 나름 정립되어 일을 하고 있었고, 그것이 '아키텍처'의 일부라는 것을 알게 되었다.

  이번에 책을 받고 나서는 조금 부담이 되었다. 표지가 멋지기도하고, 내용도 배워가고 있는 것이어서 선택지 중에 하나로 올리긴 했었지만, 막상 받고 나니 내가 잘 리뷰할 수준이 아니라고 여겨졌기 때문이다. 이번 책도 지난번 [전문가를 위한 C] 책처럼 공부하며 꺼내볼 수 있는 사전과 같은 역할을 하게 될 것 같다.

 

  당연히 서론과 앞부분을 먼저 읽었고, 이곳에서 조금은 헷갈려하던 개념들을 어느정도 정리할 수 있었다는 게 이번 리뷰의 성과라고 할 수 있다. 관련 내용은 뒤에서 정리해보겠다.

 

  옮긴이가 설명하는 이 책의 대상 독자는 '실무 소프트웨어 개발자'라고 하였다. " '객체 지향 소프트웨어 개발, UML, 유스 케이스, 디자인 패턴과 같은 기본적인 소프트웨어 개발 아이디어를 이미 알고 있는 사람"이 적합한 주요 독자라고 설명하였다. 또, 학부 고학년이나 대학원 수준의 교과서로도 적합할 것이라고 설명하며 문을 열었다.

 

  리뷰를 하며 느낀점은... 옮긴이 "이승범"님이 번역을 하며 '참 많은 고민을 하셨겠구나'라는 것이 느껴졌다. 단순히 원어를 한글로 번역할 때 전문용어가 오역되는 것을 막기 위해 영어 병기는 물론, 이해를 돕기 위한 초월 번역을 한 부분(제목에서 Just Enough'를 '적정'이라 번역한 점!!)과 책 뒷부분에 친절한 용어 설명 부분까지... 출판사와 옮긴이분이 독자를 위해 세심하고 노력한 것에 대해 감사함을 표하고 싶다. 다른 번역책들도 훌륭한 번역들이 많았지만, 올해 내가 리뷰한 책들 중에서 번역에 관한 것은 이 책이 제일이라 생각한다. 

 

  아키텍트로 향하는 여정 초입에 있는 나로서는 이 책을 통해 애매했던 정의와 역할에 대해 조금은 정리가 되었고, 앞으로 갈 길이 멀다는 것을 다시 한번 점검했으며, 그럼에도 이런 책들의 도움을 받아 한 걸음씩 내딛어야겠다는 다짐을 하게 된 시간이었다.

 

 

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

 스타트업에서의 개발은 초기의 시스템의 설계를 완벽하게 하여 개발을 시작하기 보다는, 당장에 결과물을 보여줘야 하는 경우가 많다. 시간이 지나면서 이러한 시스템을 만든 개발자는 이 시스템에 대해 점점 더 잘 이해하게 된다. 처음에는 시스템에 관한 지식이나 이해가 부족할 수 밖에 없다가 코드가 최상의 설계를 기반으로 하지 않는다는 사실을 인식했을 때 코드를 리팩토링하여 유지 관리할 수 있어야 한다. 

 

 여기서 말하는 바는 두 가지이다. 

  1. 설계는 프로세스의 앞부분에서만 진행하는 작업이 아니다. 
    • 최선의 선택을 하려면 프로젝트 앞부분에 미리 시간을 투자하는 편이 합리적이지만, 프로젝트 시작 후에도 시간을 할애해야 한다.
  2. 실패 리스크 때문에 아키텍처 리팩토링을 해야할 수 있다. 
    • 구현을 완료할 때 쯤이면 거의 모든 시스템이 개발자가 최선이라고 생각하는 수준보다 구식이 된다. 

 

 현재 애자일 소프트웨어 개발은 당연시되고 있다. 우리가 목표하는 소프트웨어 시스템이 최종적으로 어떤 모습이어야 하는지 시작할 때부터 완벽하게 만들 수도 있지만, 대부분은 초기에 설계를 완벽하게 하여 최종 제품을 개발할 수 없다. 개발을 진행하면서 소프트웨어의 모습은 변하기 마련이다. 애자일 개발의 아키텍처에는 리팩토링을 통한 진화적 설계에 특징이 있다.

 

 하지만 중요한 것은 프로젝트 초기에 '과연 우리가 프로젝트에 관한 정보를 충분히 아는가' 이다. 

 

 이 책은 이런 어려움을 완화해주는 대안을 제시한다. 리스크 주도로 아키텍처 설계를 반복하는 방법이다. 다시 말해 자신이 속한 팀에서 수행하는 소프트웨어 개발 프로세스에 맞춰 리스크가 해소될 정도로 충분한 설계량과 시간을 투자하자고 제안한다. 

 

다음은 아키텍처 리스크가 높은 5가지 구체적인 사례다. 

  1. 선택할 수 있는 해결책이 적음 : 채용할 수 있는 해결책의 범위가 작거나 적용 가능한 해결책을 설계하기 어려울 때
  2. 높은 실패 리스크
  3. 어려운 품질 속성 : 수백만 명의 사용자가 사용하는 빠른 성능의 시스템을 만들어야 할 때
  4. 새로운 도메인 : 구현해야 하는 도메인이 새롭거나 경험이 없는 분야일 때
  5. 제품 라인 : 공통 아키텍처는 어떤 종류의 제품 변경은 쉽지만, 다른 종류의 변형은 어렵게 만든다. 

 

 가장 중요한 것은 아키텍처를 잘못 만들면 얼마나 나쁜 영향이 미칠지 살펴보는 것이다. 위처럼 아키텍처를 올바르게 설정하면 전체 시스템 리스크를 크게 줄일 수 있다. 

 


 

 이 책은 크게 두 부분으로 나뉘는데, 1부에서는 소프트웨어 아키텍처와 리스크 주도 접근 방식을 소개한다. 2부에서는 소프트웨어 아키텍처의 개념 모델을 설명한다. 또한 컴포넌트 및 커넥터와 같은 추상화 개념을 자세히 다룬다. 

 

 이 책은 상세하고 완전한 아키텍처 셜계를 중요시 하는 사상과 아키텍처 설계를 최소화하고 경시하는 두 가지 사상 사이에서 '적정 아키텍처(just enough architecture)'를 제안한다. 저자는 아키텍처 설계가 얼마나 충분한지 결정하는 핵심 기준이 리스크 감소라고 주장한다. 설계 리스크가 거의 없는 곳에서는 아키텍처 설계가 필요하지 않다. 그러나 어려운 시스템을 설계해야 할 때 아키텍처는 엄청난 잠재력이 있는 도구가 된다. 

 

 이 책의 저자는 소프트웨어 엔지니어링 분야에서 박사 학위 까지 보유하신 분으로 이 책은 어려울 수밖에 없다. 이 책은 개발자들이 흔히 겪는 경험들이나 고민들을 기반으로 하기 때문에 실제 소프트웨어 개발 경험이 있고, 내가 짠 코드에 대해서도 나쁜 냄새를 잘 맡을 수 있는 사람들이 읽으면 좋을 것 같다. 

 

 숙련된 개발자 및 소프트웨어 아키텍트, 그리고 이 분야를 전공하는 학부 3, 4학년 혹은 석사 과정생을 대상으로 이 책을 추천한다. 

 

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

 

 

 

 

최근 많은 아키텍처 관련 서적들이 출판되고 있는데,

이 책은 특히 개발자들에게 추천을 하고 싶습니다.

많은 자료와 지식, 경험을 바탕으로 만들어진 책.

> 진행에 앞서

개발자로 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페이지

 

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

두껍다. 하지만, 이 책이 말하고자 하는 바는 사실 서문에 나와 있다.

 

'리스크 주도로 아키텍처 설계를 반복하라. 자신이 속한 팀에서 수행하는 소프트웨어 개발 프로세스에 맞춰 리스크가 해소될 정도로 충분한 설계량과 시간을 투자하자고 제안한다.'

 

초반에는 아키텍처와 리스크 주도 모델에 대한 개념적인 설명을 진행하고, 이를 기반으로 4장부터 예제들과 아키텍처 모델에 대해 설명한다. 내용이 방대하여 읽는데 상당한 시간이 걸릴 것 같아서... 중요하다고 생각되는 약간의 내용들을 아래에 열거해본다.

 

개발자에게는 분할, 지식, 추상화의 세 가지 범주의 무기가 필요하다.

 

개발자는 얼마나 많은 설계와 아키텍처를 수행해야 하는가? 핵심 아이디어는 소프트웨어 아키텍처를 설계하는데 드는 노력이 프로젝트의 리스크에 비례해야 한다는 것이다.

 

리스크 주도 모델은 다음 3단계로 요약할 수 있다.

1. 리스크 식별 및 우선순위 지정

2. 일련의 기법 선택 및 적용

3. 리스크 감소 평가

 

모든 개발자는 '지금 어떤 기능을 구현하고 있는가'라는 질문에는 답할 수 있지만, '가장 중요한 실패 리스크와 이에 대응할 수 있는 엔지니어링 기법은 무엇인가'라는 질문에는 곤란할 수 있다.

 

리스크가 완화되었는지 테스트할 수 있도록 리스크를 설명하는 편이 좋다. 리스크는 크게 엔지니어링 리스크(제품의 분석, 설계, 구현)와 프로젝트 관리 리스크(일정, 작업 순서, 전달, 팀 규모, 지역 등)로 분류할 수 있다.

 

어떠한 설계 및 아키텍처링 기법을 사용해야 하는가? 해답은 리스크를 식별하고 이에 대처할 수 있는 기법을 선택하는 것이다. 아키텍처 설계에 들이는 노력은 실패 리스크에 상응해야 한다. 가장 달성하기 어려운 요구사항을 찾아야 한다.

 

리스크 주도 접근 방식을 따르는 개발자는 머릿 속에 계속 반복되는 질문이 있다고 느낄 수 있다. 다루어야 하는 리스크는 무엇인가? 이를 줄이는 가장 좋은 기법은 무엇인가? 리스크가 완화되어 구현을 시작(또는 재개)할 수 있는가?

 

진화적 설계와 계획 설계 중간에 최소 계획 설계 or 작은 선행 설계가 있다.

 

리스크를 줄여 실패를 피하는 것이 개발자 행동의 주요 동력이다.

 

이 도서에서는 따라야 할 하나의 프로세스를 규정하지 않는다. 여러가지 기법을 알려주고 상황에 맞춰 알아서 그들을 잘 버무려 사용하라고 한다. 'ㅅ'); 

말 그대로 읽는 것도 적용하는 것도 꾸준한 수련이 필요하다. 

'소프트웨어 아키텍처 101' 이라는 도서와 함께 꾸준히 읽어봐야겠다.

 

.

 

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

적정 소프트웨어 아키텍처라는 책을 읽게되었다. 리스크 주도 접근법이라는 부제를 가진 책이었다.

 

이 책에서는 리스크를 활용하여 소프트웨어 아키텍처의 작업량을 결정하는 방법을 살펴본다고 한다. 그러기 위해선 소프트웨어 아키텍처가 무엇인지부터 이해해야 한다고 한다.

 

소프트웨어 아키텍처는 시스템의 골격 역활을 하고 품질 속성에 영햘을 미치며 대부분의 기능과 직교하면서 시스템을 제한한다고 한다. 이것이 소프트웨어 아키텍처가 중요한 이유라고 한다.

 

코드 내 모델 원칙이라는 것이 있는데, 사용하는 모델의 종류를 코드를 읽는 사람에게 전달하려는 설계 의도라고 한다. 힌트를 제공하고 모델의 일부를 소스 코드에 포함시키면 설계 의도가 더 쉽게 복구되며 전혀 손실되지 않을 수도 있다고 한다.

 

전체 시스템과 구성 부분은 관련되어 있으며 때대로 계층적 중첩, 계층적 분해라고도 한다고 한다. 부분과 전체의 관계를 분할 관계라고 한다고 한다.

 

아키텍처 스타일에는 여러가지 스타일이 있을 수 있는데 그 스타일들을 나열해 보았다.

 

일괄-순차 스타일, 모델 중심 스타일, 발행-구독 스타일, 클라이언트-서버 스타일 및 다중 계층 스타일, 파이프와 필터 스타일 등이 있는 것으로 보인다.

 

​이 중 나는 모델 중심 스타일을 기본으로 해서 프로그램을 작성하는 타입이라는 생각이 들었다. 왜냐하면 내가 주로 코딩하는 부분은 서버 프로그램이고 서버 프로그램의 기본은 데이터 모델링에 있다는 생각에서 였다.

 

이것으로 이 책의 리뷰를 마칠까 한다. 소프트웨어 아키텍처 중에서도 리스크 주도 접근법에 관심이 있으신 분들이 이 책을 읽으시면 도움을 얻을 수 있으시리라고 생각한다. 일반 소프트웨어 아키텍처에 관심이 있으신 분들 역시 구독자로서 해당이 되는 책이라고 할 수 있다.

저자 조지 페어뱅크스의 "Just Enough Software Architecture: A Risk-Driven Approach"은 성공적으로 소프트웨어를 만드는 것이 "가능한 실패를 예상하고 실패할 수 있는 설계를 피하는 것을 의미"한다고 이야기 한다. 그렇기 때문에 실패 리스크를 찾고 이것에 매핑하는 소프트웨어 설계 테크닉을 적용하는 것이라고 한다.

 

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

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

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

 

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

 

아키텍처 도서와 방법론 관련된 도서가 요즘들어 굉장히 많이 나오고 있는데, 

해당도서도 마찬가지다.

 

평소 오랠리의 도서시리즈를 좋아해서 '아키텍처 101'을 먼저 읽었고 해당 '리스크 주도학습법'을 읽어보면서 '실무 적용'에 대해 여러가지 생각을 읽어보고 고민을 했었는데,

해당 도서를 읽으면서 좋았던 부분은 '리스크 주도 접근(A Risk Driven Approach)'과 관련해 

실무관련된 내용을 실습 위주로 다루고 있다는 부분이였다.

 

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

 

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

 

개인적으로는 아키텍처 101일 먼저 읽고 해당도서를 읽어서 더욱 와닿았던 부분이 많았다.

두가지 모두 읽어보기를 추천드립니다!

 

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

KakaoTalk_20220701_000259005.jpg

 

KakaoTalk_20220701_000259005_01.jpg

 

KakaoTalk_20220701_000259005_08.jpg

 

KakaoTalk_20220701_000259005_07.jpg

 

KakaoTalk_20220701_000259005_09.jpg

 

 


1. 시작


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


2022년 6월달에 소개할 책은 적정 소프트웨어 아키텍처 입니다



<표지>


개발자가 힘들어하는 것 중에 하나가 아키텍처 입니다

누구한테서 배우기가 쉽지 않은 것이 아키텍처 설계입니다


누구한테 배울 수 없으니 얼마나 세부적으로 설계해야하는지 알 수가 없는데, 바로 이책은 그 ‘적정' 수준에 도움을 줄 수 있는 책입니다.


개발자로서 경력이 3년이상이 된 분이 이 책을 읽는 것을 권장드립니다.

내용이 다소 어려울 수 있습니다.


작은 규모의 소프트웨어 개발을 한다면 굳이 아키텍처 설계를 안해도 되겠지만

유지보수 가능한 소프트웨어

지속가능한 소프트웨어

품질(성능, 보안, 이식성, 유지보수성)을 만족시키는 소프트웨어

를 개발한다면 아키텍처 설계를 추천합니다.


프로젝트 관리에도 리스크 기반 프로젝트 관리를 합니다.

소프트웨어 개발할때도 리스크 기반 sprial 모델을 통해서 개발을 합니다.


아키텍처 설계를 할때도 리스크 주도 접근법을 제시하고 있습니다.


아키텍처 설계는 소프트웨어의 뼈대를 만드는 과정입니다.

리스크가 크면 클수록 설계를 더 세세히 해야 하고

그렇지 않으면 간단한 설계로 할 수 있습니다.


이 책의 저자는 설계의 수준이 적절한지에 대해서 이책에서 제시를 하고

있습니다.





2.목적 (책을 쓴 이유)

저자가 책을 쓴 목적을 보도록 하겠습니다.


‘주어진 시스템의 아키텍처 설계를 얼마나 수행하고 결과물을 만들어야 하는가? 에서 출발합니다.


이 책은 위의 질문에 대한 답을 리스크 주도 모델, 아키텍처 무관, 집중, 상향 설계와 같은 접근 방식을 알려줌으로써 답을 알려주는 책입니다.


대상독자는 

미숙한 개발자 또는 학생에게는 효과적이고 숙련된 개발자가 되는 빠른 방법을 배울수 있고,

숙련된 개발자는 멘토링 능력 향상, 표준 모델, 표기법, 명칭을 배울수 있으며,

소프트웨어 아키텍트는 시스템 구축 기법, 수행 방법을 알려줍니다.

마지막으로 학계 관련자들에게는 리스크 주도 모델, 아키텍처 무관, 집중, 상향 설계를 알려줍니다.


지금부터 책의 내용을 요약하고 살펴보도록 하겠습니다.



3.책의 내용

그럼 이 책의 내용은 어떠한지 구조부터 알아보겠습니다.

구조는 총 2부로 구성되어 있습니다.


1부에서는 소프트웨어 아키텍처가 뭔지?

왜 중요한지?



<페이지 51>


어떤 종류의 제품군에서 아키텍처를 설계해야하는지?

어떻게 사용하는지?


설계방법으로 아키텍처 무관 설계, 집중 설계, 상향 설계제시를 하고, 주요 핵심인 리스크 주도 모델에 대한 설명, 가이드를 제시하고 있습니다.

실제 개발 프로세스에서 적용하는 방법을 설명하고 있습니다.



<페이지 61>



2부에서는 아키텍처 모델을 설명하고 있습니다.

도메인에 포함되는 지속적인 진실을 표현하는 도메인 모델, 



<페이지 183>


시스템 설계를 모델링하는 디자인 모델,



<페이지 199>


아키텍처를 소스코드로 현실화하는 코드 모델을 다룹니다.



<페이지 243>


그리고 아키텍처 모델링에 필요한 핵심 요소인 모델, 컴포넌트, 커넥터, 포트, 역할, 품질 속성, 설계 근거, 환경 요소, 시나리오, 불변 사항, 트레이드 오프, 스타일과 같은 모델 요소를 세밀히 다루고 있습니다.



<페이지 310>


마지막으로 투영(뷰), 분할, 구성, 분류, 일반화, 지정, 구체화, 바인딩, 종속성과 같은 모델 관계를 다루며, 아키텍처 스타일을 다루게됩니다.



<페이지 334>


그리고 아키텍처 모델 사용하기에서는 바람직한 모델 특성, 뷰를 효과적으로 사용하는 방법, 아키텍처 불일치의 리스크, 사용자 인터페이스 계획방법, 기존 시스템을 설명하는 모델에 대비하여 미래 시스템을 규정하는 모델 설명방법, 기존 시스템 모델링하는 방법에 대한 힌트를 다룹니다.


<페이지 376>



4. 책의 좋은 점과 아쉬운 점


4.1 좋은점(장점)

  • 아키텍처 설계의 중요성, 리스크 주도 접근법 등에 대한 깊은 지식을 제공합니다.

  • 적절한 소프트웨어 설계의 수준을 알수 있습니다.



4.2 아쉬운점(단점)

  • 아키텍처 설계는 여전히 어렵습니다.



여기서 책의 서평을 마무리 짓고자 합니다.


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

 

감사합니다

좋은 개발이란 무엇일까?
코딩가이드부터 인프라 구축까지 다양한 범위의 다양한 대답들이 나올 수 있다.
개발의 궁극적인 목적은 ‘원하는 것을 제대로 구현하는 것’이라고 할 수 있다.
여기서 말한 ‘제대로'에 대한 많은 방법들이 있다.
이 책 ‘적정 소프트웨어 아키텍처'는 그 방법들 중 ‘리스크 주도 접근법'에 대해 설명하고 있다.

 

software.jpg

 

소프트웨어 아키텍처에 대한 책들은 많다.
다양한 이론과 깊이를 보여주고 있지만 막상 실무에 접목하려면 막막해질 때가 있다.
이 책이 가장 큰 특징은 철저히 실무 위주라는 것이다.
사용되지 않는 아키텍처는 의미가 없다.
이제 개발을 시작하는 분들에게는 체계적으로 아키텍처를 배울 수 있고, 오랜 경험을 바탕으로 감각적으로 사용하던 분들은 깊은 이론을 배울 수 있다.

 

architecture.jpg

 

처음 개발을 시작할 때 아키텍처부터 고민하고 공부하는 사람은 별로 없다.
바로 키보드를 두드리면서 코딩을 시작한다.
함수 하나, 문법 하나를 알아갈 때마다 실력을 늘어난 듯 하다.
하지만 어느 정도의 시간이 흐르면 복사, 붙여넣기를 하고 있는 자신에 놀라고, 뭔가 부족한 느낌을 받을 것이다.
아키텍처의 필요성을 느끼는 순간이다.

이 책은 소프트웨어 아키텍쳐 중 ‘리스크 주도 모델'을 설명하고 있다.
 

risk.jpg

 

간단히 요약하면 애자일처럼 ‘리스크' 위주로 아키텍처의 적용 범위와 방법을 접목시키기를 반복한다.
처음부터 제대로 설계를 하고 진행하면 최선이겠지만, 비즈니스 환경의 변화로 인해 그러지 못하는 것이 현실이다.
그렇기에 ‘현재 상황'에 맞는 ‘적절한 아키텍쳐'를 만들고, 적용하는 것이 바람직하다.

이 책을 통해 ‘리스크 주도 모델'에 필요한 아키텍처의 전반적인 기술 스택을 모두 배울 수 있다.
모델(도메인, 디자인, 코드)은 물론이고, 캡술화와 파티셔닝까지 알려주고 있다.

개발을 시작한 분들에게는 어렵게 느껴질 수도 있는 내용이지만, 개발자라면 ‘꼭' 알아야 할 내용이다.
코딩만 할지라도 아키텍쳐에 대한 이해 여부에 따라 결과가 달라질 수 있다.
아키텍처를 이해한 이후와 이전의 차이를 직접 느껴보자.

[한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.]
 
#한빛미디어, #적정소프트웨어아키텍처, #아키텍처, #리스크주도접근법

 

 

적정 소프트웨어 아키텍처

JUST ENOUGH SOFTWARE ARCHITECTURE

리스크 주도 접근법

A Risk Driven Approach

조지 페어뱅크스 지음 / 이승범 옮김 / 한빛미디어

 

 

이 책은 다른 소프트웨어 아키텍처 책과 다르다. 차이점은?

1.   리스크 주도 아키텍처링을 가르친다.

리스크가 적을 때는 세심한 설계가 필요하지 않지만, 리스크가 많아 성공이 불확실할 때는 엉성한 설계가 용납되지 않는다. 유명 애자일 소프트웨어 지지자들은 일부 선행 설계가 도움이 될 수 있다고 제안한다. 이 책은 적정하게 아키텍처 설계를 수행하는 방법론을 말한다. 직면한 리스크에 따라 아키텍처와 설계에 들이는 노력을 조정하는 방법에 관해 조언하여 프리사이즈() 프로세스 구렁텅이로 가능 상황을 방지한다. 복잡한 기법을 간략화하여 빠르게 처리하는 방법부터 상세하게 적용하는 방법까지 상황에 따라 조절하여 적용할 수 있다.

2.   참여하는 아키텍처를 지향한다.

여러분이 소프트웨어 아키텍트이거나 조직에 소프트웨어 아키텍트가 있을 수 있다. 저자가 만난 아키텍트들은 모든 개발자가 아키텍처를 이해하기를 바란다 아키텍트는 개발자가 아키텍처와 관련된 제약 조건이 존재하는 이유 작아 보이는 변경이 시스템 속성에 큰 영향을 미칠 수 있다는 점을 이해하지 못한다고 불평한다. 이 책은 아키텍트뿐 아니라 모든 소프트웨어 개발자와 관련된 아키텍처를 만드는 데 노력한다.

 

3.   선언적 지식(declarative knowledge)을 키운다

테니스 공을 칠 수 있다 테니스 공을 칠 수 있는 이유를 설명할 수 있다는 다르다. 심리학자가 말하는 절차적 지식()과 선언적 지식() 사이에도 이와 같은 차이가 있다. 여러분이 시스템 설계 및 구축 전문가라면 이 책의 많은 기법을 이미 사용해봤을. 것이다. 하지만 여기서는 여러분이 무엇을 사용했는지 더 잘 알 수 있도록 용어와 개념을 사용해 설명한다. 이러한 선언적 지식은 다른 개발자를 가르치는 데 도움이 된다.

 

4.   엔지니어링을 강조한다

소프트웨어 시스템을 설계하고 구축하는 사람들은 일정, 자원 할당(), 이해관계자 요구를 처리하는 등 많은 일을 해야 한다. 소프트웨어 아키텍처에 관한 많은 책에서 이미 소프트웨어 개발 프로세스와 조직 구조를 다뤘다. 하지만 이 책은 소프트웨어 개발의 기술적 부분에 초점을 맞추고, 개발자가 시스템을 작동하게 하려고 수행하는 작업인 엔지니어링을 다룬다. 원칙을 기반으로 설계의 절충안을 만들 수 있도록 모델을 구축하고 아키텍처를 분석하는 방법을 보여준다. 소프트웨어 설계자가 중대형 문제를 해결하는 데 사용하는 기법을 설명하고, 전문 기법을 어디서 더 자세히 배울 수 있는지 알려준다. 결과적으로 이 책 전체에서 소프트웨어 엔지니어를 프로그래머와 아키텍트로 구별하지 않고 모두 개발자라고 부른다.

 

5.   실용적 조언을 제공한다.

이 책은 아키텍처의 실용적인 활용 방법을 제공한다. 소프트에어 아키텍처는 일종의 소프트웨어 설계다. 하지만 설계 설정은 아키텍처에 영향을 미치며 그 반대도 마찬가지다. 최고의 개발자는 장애물을 자세히 살펴보고 이해한 후 이 내용을 바탕으로 해당 장애물의 특성을 아키텍처에 연결한다. 이 책은 상위 아키텍처에서 하위 자료 구조 설계에 이르기까지 추상화를 위한 다양한 수준의 모델을 활용하는 접근 방법을 알려준다.

 

대상독자

이 책의 주요 독자는 실무 소프트웨어 개발자다.

 

객체지향 소프트웨어 개발, UML, 유스 케이스, 디자인 패턴과 같은 기본적인 소프트웨어 개발 아이디어를 이미 알고 있어야 한다.

실제 소프트웨어 개발 경험이 있다면 더 도움이 될 것이다. 이 책에서 이야기하는 기본적인 내용은 대부분 개발자가 흔히 겪는 경험을 기반으로 하기 때문이다. 개발하면서 너무 많은 문서를 작성했거나, 코딩을 시작하기 전에 너무 적게 고민한 적이 있을 것이다. 어느 쪽이든 소프트웨어 개발이 왜 잘못되는지 알 수 있고, 이 책에서 제공하는 해결책이 많은 도움이 될 것이다.

이 책은 학부 고학년이나 대학원 수준의 교과서로도 적합하다.

 

이 책은 소프트웨어 아키텍처 분야에 몇 가지 공헌을 한다.

프로젝트에서 수행할 아키텍처와 설계 작업의 양을 결정하는 방법인 소프트웨어 아키텍처의 리스크 주도 모델을 소개한다.

또한 아키텍처에 대한 세 가지 접근 방식을 설명한다. 바로 아키텍처 무관 설계, 아키텍처 집중 설계, 아키텍처 상향 설계다.

추가로 소프트웨어 아키텍처에 대한 두 가지 관점인 기능적 관점과 속성 관점을 통합하여 하나의 개념 모델을 생성한다. 그리고 소스 코드를 읽음으로써 아키텍처를 분명하게 만드는, 구조적으로 명확한 코딩 스타일에 관한 아이디어를 소개한다.

 

소프트웨어 개발 PM은 읽고 프로젝트 진행에 적용할 적정한 방법을 찾을 수 있고, 소프트웨어 개발자들은 자신이 개발하는 소프트웨어가 잘 작동될 수 있도록 기능적 관점과 속성 관점을 통합하여 하나의 관점으로 바라보는 훈련이 필요하다.

 

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

2022년 5월에 출간된 따끈따끈한 책 <적정 소프트웨어 아키텍처>를 소개합니다. 이 책의 부제는 '리스트 주도 접근법'입니다. 이 책의 저자는 구글 소프트웨어 엔지니어인 조지 페어뱅크스(George H. Fairbanks)님이며, 역자는 이승범 님입니다. 이승범 님의 번역은 처음 본 것 같은데, 용어마다 원문의 내용을 첨부하고, 낯선 용어들에 대한 역자 주가 충분히 남겨져 있어 읽는 데 불편함을 느끼지 못했습니다. 전반적인 번역 품질도 좋았습니다. 저자님과 역자님께 감사하다는 메시지를 전하고 싶습니다.   

이 책의 원서는 아마존 리뷰에서 우수한 점수(4.4점, 5점 만점)를 받았습니다. 원서는 약 10년 전(2010년 출간됨)에 출간되었지만, 필자에게 이 책은 매력적인 책이었습니다. 이 책은 소프트웨어를 설계하고 개발할 때 지니고 있어야 할 기본적인 내용들을 잘 정리하고 있으며, 소프트웨어 아키텍처를 설계할 때 리스크를 분석하여 적정한 수준으로 설계하는 방법을 안내하고 있습니다. 

<적정 소프트웨어 아키텍처>는 약 470페이지로 구성되어 있어 휴대하면서 읽기에 크게 부담스럽지 않습니다. 전자책으로도 출간되어 있으므로, 전자책 뷰어가 있으시다면 전자책으로 만나보는 것도 좋을 것 같습니다. 하지만 이 책은 일반 책으로 읽는 것이 좋을 것 같습니다. 양장본으로 구성된 책을 보니 소장하고 싶은 욕구가 생겼습니다. 
 

한빛미디어 평가단에 참가하여 작성한 글이며, 한빛미디어에서 제공해준 책을 읽고 작성했음을 밝힙니다. 

 

이 책의 매력은?

<적정 소프트웨어 아키텍처>는 2부 16장으로 구성되어 있습니다. 1부는 리스크 주도 소프트웨어 아키텍처를 주제의 내용을 다루고 있으며, 3장에서 이 책에서 가장 중요한 요소인 리스크 주도 모델을 소개하고 있습니다. 3장에서 이론적인 부분을 이야기하고 있다면, 4장에서는 실 예제를 들어 독자들에게 리스크 주도 개발의 이해도를 높여줍니다.

필자는 이 책을 통해 리스크 주도 모델에 대해 이해할 수 있었고, 공감할 수 있는 부분이 많았습니다. 실제로 리스크 주도 모델을 활용하려면 많은 연습과 훈련이 필요하겠지만, 내재화한다면 더 커다란 실수를 예방할 수 있을 것 같습니다. 또한, 다양한 종류의 컴퓨터 사이언스 지식도 부가적으로 정리하고 학습할 수 있었던 매력 만점인 책이었습니다. 

이승범 님께서 이 책의 제목을 잘 정한 것 같습니다. 역자분께서 번역을 할 때 고민을 많이한 후, <적정 소프트웨 아키텍처>로 정했다고 했는데, 필자는 이 책의 주요 내용을 잘 함의하고 있다고 생각합니다. 

 

마치면서

<적정 소프트웨어 아키텍처>는 최고, 최선의 아키텍처가 아닌, 프로젝트 상황에 알맞은 '적정한' 아키텍처를 제시하는 방법을 소개하고, 이를 위해 리스크를 줄이기 위한 '리스크 주도 모델'을 소개하고, 이를 적용하는 다양한 아키텍처 스타일을 소개하고 있습니다.

 

저자가 이 책의 대상 독자 절에서 '이 책은 학부 고학년이나 대학원 수준의 교과서로도 적합하다.'라고 이야기를 한 부분이 있었습니다. 필자도 이 책을 읽으며, 저자의 의견에 동의하여 조만간 세미나를 진행해보려고 합니다.  
 

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

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.
 
적정 소프트웨어 아키텍처

책 요약

프로젝트에서 소프트웨어를 설계에 적정(Just Enough)하게 할애하는 비중을 정하는 방법을 제시한다. 그리고 그 기준을 실패할 때 발생할 리스크를 기준으로 소개한다.


리뷰

소프트웨어 아키텍처에 생소하거나 처음 접하는 사람이라도 일단 기준(리스크)을 잡고 소개한다는 점이 접근하기 수월하다는 생각이 들었다. 물론 다른 많은 서적들이 소프트웨어 아키텍처에 소개하고 명서들이 존재한다. 하지만 이러한 명서나 저서들을 이해하기에는 초보자들을 다소 어려운 점들이 있다. 하지만 적정 소프트웨어 아키텍처는 리스크 주도 접근법이라는 기준을 제시하여 소프트웨어 설계 방법을 활용할 수 있도록 제시한다. 이 점이 처음 소프트웨어 설계를 접하는 사람들에게 매우 유용한 점이라고 생각된다.(다만 특정한 컨셉을 통해 접근한다는 것은 다른 접근법을 학습할 때 비교해서 장단점을 익혀야한다는 부담은 존재한다.)

특히 소프트웨어 아키텍처가 무엇인지 그리고 발생하는 배경에 대해 설명하는 초반부는 리스크 주도 접근법과는 무관하여 소프트웨어 아키텍처의 기초를 학습하기에 매우 유용한 내용들로 가득하다.


아래의 내용은 기초적 배경 지식으로 유용하다고 생각되는 부분들이다.


소프트웨어 아키텍처란 무엇인지지금의 아키텍처링까지 오기까지의 히스토리소프트웨어 아키텍처의 범위를 설명하며 이는 기능과 직교하지만 품질 속성을 달성하기 위해서는 매우 중요하다. 소프트웨어 아키텍처의 차이에 따라 경험하게 될 개발 방법 등이 달라지게 된다.

소프트웨어 설계에 집중하는 비중에 따라 나뉘는 구분 방법과 장단점

  • 아키텍처 무관 설계
  • 아키텍처 집중 설계
  • 아키텍처 상향 설계

이후 리스크를 통한 소프트웨어 설계 기준을 정한다.

소프트웨어의 품질 속성에 따른 리스크를 산정하여 중요도를 결정한다. 이에 따라 소프트웨어 아키텍처를 결정하는 기준을 정한다. 특히 Chapter4 예제: 홈 미디어 플레이어 를 통해 설계 적용방법을 상세히 제시한다.

 

아무래도 소프트웨어 아키텍처라는 분야는 심오하면서도 생각을 많이 해야하는 분야이기에 새로운 접근법을 알아가고 이러한 접근법을 통해 설계를 고려할 수 있는 선택지로 삼을 수 있다는 점에서 매우 좋은 도서라고 생각한다.

적정 소프트웨어 아키텍처 ※ 한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다. 이번달 한빛리뷰단에서 선정된 서적은 적정 소프트웨어 아키텍처_리스크 주도 접근법 입니다 ​ 부제인 리스크 주도 접근법이란 우선순위, 만기일, 리스크 정도를 점수로 매겨 리스크가 심한 부분을 도려내는 방식을 설명한다 ​ 책이 전체적으로 실제 개발에 사용할 기법 등이 아닌 이론에 대한 설명이라고 해야할까 논점에 대한 설명으로만 이루어져있다 ​ 그런게 재밌을 때도 있지만 아무래도 어떻게 짜면 좋다 보다는 어떻게 짜는 방법이 있다 라는 설명이고 그 설명 들이 그렇게 눈에 들어오는 편은 아닌거 같다 ​ 아무래도 오가며 흔들리는 곳에서 주로 읽다보니 더 집중이 안되기도 했지만 책의 내용도 대부분이 이론 설명에 집중되어 있다보니 자주 집중이 흩어져버렸다 ​ 그래도 공감가는 부분도 많이 있었는데 왜 아키텍처가 있어야하며 개발하는 방법에 제한을 두는 것이 개발자를 무조건 적으로 방해하고 안되게하는 게 아니라는 점이다 골격을 세우고 공통된 살을 붙여 하나된 탑을 쌓을 수 있게한다는 점인데… 아무래도 이걸 싫어하는 사람을 가끔 봐왔던 게 생각이 났다 이게 옳다 틀리다 보다는 좀 더 적절하고 새로운 안정화된 기술로 되도록 동일한 방법을 써서 올려가면 좋겠다는 생각이 드는 서적이었다

되돌아보면 10년마다 새로운 어려움에 맞서는 새로운 추상화가 도입되었음을 알 수 있다. 오래된 도구를 연마해두는 일도 도움이 되지만 새로운 도구 없이는 향후 10년 동안의 어려움을 극복하기 힘들다.

본문 407 페이지

저자는 "필요한 새로운 도구"에 대해서 이 책에 이야기하고 있습니다. 저자가 제시하고자 하는 건, "적정 소프트웨어 아키텍처"인데요. 이는 1.6절에 언급하고 있는 "리스크 주도 소프트웨어 아키텍처"라고 볼 수 있습니다.

그럼 리스크 주도 소프트웨어 아키텍처는 무엇일까요?

아키텍처링에 투입할 노력은 소프트웨어 개발의 실패 리스크에 따라 달라져야 한다.

본문 40 페이지

소프트웨어 프로젝트가 실패할 경우 발생하는 문제가 심각할 수록 아키텍처에 많은 신경을 써야겠죠. 만약, 프로그램이 "Hello world"를 찍지 못하고 죽어버리는 정도라면, 아키텍처에 신경쓸 필요 없겠지만, 달착륙선이 달착륙에 실패할 리스크가 있는 정도라면 아키텍트에 엄청난 노력을 기울일 겁니다.

아키텍처를 설계하는 데 드는 노력이 프로젝트의 리스크에 비례해야 한다.

본문 73 페이지

저자는 책 곳곳에서 "리스크 주도 아키텍처" 또는 "적정 소프트웨어 아키텍처"에 대해 설명하려고 노력하고 있습니다. 아키텍트를 설명해야 하므로 일반적인 아키텍트에 대해서도 꽤 자세히 설명하고 있는데요. 아키텍트에 대해서 전반적으로 이야기하고 있어서, 아키텍트에 대해 이해하고 싶다면 꽤 도움이 될 것 같습니다.

히, big ball of mud (큰 진흙 뭉치)라고 부르는 아키텍트에 대한 설명은 많은 것을 생각하게 했습니다. 큰 진흙뭉치 아키텍트는 사실상 아키텍트가 없는 상태에서 소프트웨어를 개발하는 상황을 말합니다. ( 사실 우리가 진행하는 프로젝트 대부분이 여기에 해당할지도 모릅니다. )

물론, 아키텍트가 필요없는 프로젝트가 있을 수 있습니다. 저자가 언급한건, 마당 앞 작은 우체통을 만들거나 뒤뜰에 아무렇게나 쓸 헛간을 만드는 경우에는 특별한 아키텍트가 필요없을 거라고 말합니다. 그정도로 간단한 프로젝트에서는 아키텍트를 쓰지 않는게 오히려 낫다는 의미인데요.

저는 다른 방향으로 생각해봤습니다. ' 그런 프로젝트를 해서 나온 소프트웨어를 팔수 있다는 말인가? '

사실 팔지 않는게 당연할지도 모르겠습니다. 그렇게 나온 소프트웨어는 나혼자 아무렇게나 쓸 헛간이나, 집앞에 대충 서있는 작은 우체통이어야 하기 때문이죠.

개발자가 자기 맘데로 코딩을 해나가는걸 방해하는게 아키텍트입니다. 하지만 그렇게 함으로써 개발자에게 지혜를 전달하고 불필요한 창의성 소모를 감소시켜, 결국 더 나은 코드를 만들어 내는 결과를 만드는 게 아키텍트라 할 수 있습니다.

따라서 아키텍트가 있어야 소프트웨어 조직에 지혜가 축적되고, 프로젝트 진행에 대한 회고가 가능하며, 개발자의 역량도 빠르게 성장할 수 있을 겁니다.

문제는 우리는 아키텍트를 그리 중요하게 여기지 않는다는 것입니다. 그래서, 우리의 다양한 활동이 결국 우리와 회사와 우리의 기술역량이 성장해 나가는데 까지 연결되지 않는 것 아닐까 싶었습니다.

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

소프트웨어를 개발하거나 IT시스템을 구축하는 것은 건설/건축과 종종 비견되기도 한다. 그리고 소프트웨어나 IT시스템을 개발하는 과정에 프로젝트 관리 방법을 적용한다던지 소프트웨어 구조와 이를 설계하는 사람을 아키텍처/아키텍트라 부르는 것 역시 차용해서 통용되고 있다.


시대에 따라서 소프트웨어나 IT시스템을 구축하는데 있어 설계를 중요시하는 것에도 조금씩 차이가 있고, 클라우드 컴퓨팅 환경이 대세를 이루고 아키텍처적으로도 MSA 등 서비스 지향적인 요소가 강조되고 조직의 구성과 문화, 방법론, 언어 등등 IT전반적인 요소가 빨리, 필요한 만큼, 반복적으로 확장해 나가는 시대적 흐름에 접어든 만큼 아키텍처를 대하는 우리의 생각과 자세도 많이 달라졌다. 인프라도 이제 소프트웨어적으로 쉽게 구성하고 변경하고 확장할 수 있는 시대다 보니 온프레미스 환경만큼 공을들이지는 않는게 전반적인 흐름이고 시각인 것 같다.


이러한 시대적 흐름에도 불구하고 불확실성과 다양한 니즈와 변화에 민접하게 대응해야하는 요즘의 서비스 운영환경에서 소프트웨어나 IT시스템은 유연하고 변화에 민감하고 기민하게 대응하여야 하며 이를 효과적으로 변경할 수 있도록 설계되어야 한다. 전통적인 아키텍팅과는 또 다르게...


그런면에서 "적정 소프트웨어 아키텍처"는 꽤나 흥미롭다.


이 책의 특징이나 가치를 어디에 둘 수 있을까? 부제에 나와 있듯 리스크 주도 접근법이 아닐까?

소프트웨어 아키텍처에 리스트를 분석하여 적정한 수준으로 설계하는 방법이 이 책의 핵심가치이다. 리스크를 관리하는 차원에서 소프트웨어를 설계 한다는 점은 요즘의 시대적 흐름과 환경에 유용한 접근법중 하나이지 않을까 싶다. 그런면에서 특히나 3장의 내용인 리스크 주도 모델 부분은 이 책의 핵심 가치를 가장 잘 담고 있는 챕터라 생각된다.


백문이 불여일견... 이 책에 대한 좀더 상세한 내용은 요기 참조...


이 책은 학계, 현업 아키텍트, 시니어 개발자 그리고 초급 개발자나 학생 등 다양한 독자층을 겨냥하여 썼다고 책에 언급하고 있으나 아무래도 아키텍처 관련 또는 다양한 방법론 등에 나오는 용어들이 생소할 수 있기에 책의 끝부분에 용어들만 따로 추려 30페이지 분량으로 정리해주는 친절함까지...


프로젝트 관리, 개발 방법론 그리고 아키텍처 관련 궁금한 부분이 많다보니 종종 이런 부류의 책들을 읽게 되는데 간만에 색다른 시각의 아키텍처 관련 책을 보게되서 흥미로운 시간을 보냈다.


※ 본 리뷰는 IT 현업개발자가, 한빛미디어 책을 제공받아 작성한 서평입니다.

 

20220626_01.jpeg

 

 

이 책은 유독 추상적이며 비유가 많고 동시에 비슷한 SW 설계 개념과 용어들이 즐비하다. 어떻게 보면 불친절하다는 뜻이지만 나름 실제 설계 예제를 이용하여 독자를 설득하고자 노력하고 있는 것을 보면 애초에 SW 설계 자체가 추상적이고 어려운 개념이라서 어쩔 수 없겠다는 생각도 든다. 어떤 이유가 됐든 주니어 개발자에게는 추천하기 어려운 책이라는 사실은 변함이 없다. 저자의 비유를 빌려보자면 저자는 아키텍처 선생님보다는 아키텍처 코치에 가깝다. 새로운 개념을 차근차근 새로 가르치는 친절한 선생님을 원했다면 이 책은 적절한 선택이 아닐 것이다. 선생님과 코치의 차이는 여기서 나온다. 선생님은 모르는 것을 가르쳐주지만, 코치는 이미 알지만 고쳐지지 않는 문제 또는 미쳐 생각지 못한 부분을 짚어주고 고쳐준다. 그러나 코치라고 표현한 이유는 이 책이 당신이 아키텍처를 실패한 이유를 정확하게 짚어 주기 때문이다.

SW는 복잡했고 복잡해져왔으며 앞으로 더더욱 복잡해 질 것이다. 수학적 귀납법으로 추론된 이 절망스런 사실 앞에 우리 개발자들은 어떤 자세를 가져야 할까?
이 책에서는 분할, 지식, 추상화라는 무기를 통해 맞서 싸울 것을 각오하고 있다. 저자는 분할, 지식, 추상화 각각을 실제 아키텍처 설계 관점에서 어떻게 적용하여 다룰 지 설명한다. 나에게는 코드 수준을 넘어 시스템 수준에서의 SOLID 패턴의 개방-폐쇄 원칙(Open-Closed Priciple)을 적용하는 느낌이었다. 다르게 말하면 객체 수준이 아닌 시스템 수준에서 확장은 개방적으로, 수정은 폐쇄적으로 대해야 한다는 것이다. 여기서 중요한 점은 '딱 필요한 만큼 만 개방-폐쇄적이어야 하고 이것을 이 '적정 아키텍처 기법'을 리스크 주도 모델을 통해 설명한다.

리스크 주도 모델을 설명하기에 앞서 저자의 리스크 정의를 먼저 살펴본다.

 

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

쉽게 말해 실패의 기댓값이다. 리스크에는 선임 개발자의 교통사고나 고객의 낮은 이해도로 인한 사용자 오류와 같은 프로젝트 관리 리스크부터 응답 메세지 파싱코드 오류 다발, 1000명 동시 접속 할 서버 증설 불가와 같은 소프트웨어 엔지니어링 리스크가 있다. 저자는 이 리스크의 종류와 리스크를 식별하고 우선순위를 지정하는 다양한 기법과 원칙들을 설명한다. SW의 기능이 요구사항을 해결하는 것이라면 아키텍처는 이 SW 리스크를 예방 또는 최소화 해야 한다는 것이다. 저자는 같은 말을 다음 한줄로 요약하여 리스크 주도 모델이 무엇인지 정의한다.

<리스크>가 있다면, 이를 줄이는 <기법>을 고려하자.

 

그러나 모든 것에는 Trade-Off가 존재한다. 개발자에게는 주로 발생하는 개발 리소스와 비용을 의미할 것이다. 따라서 모든 리스크를 예방하는 것은 물리적으로 불가능하며 애초에 리스크를 기댓값으로 계산한 이유도 여기에 있다. 결론적으로 SW 설계에 드는 노력이 프로젝트 리스크에 비례해야 한다는 것이다. 즉 지나친 선행 설계(Big Design Up Front)를 지양하며 딱 적당한 수준의 아키텍처, 다시 말해 적정 소프트웨어 아키텍처를 통해 딱 적정 수준의 아키텍처 설계로 적정수준의 리스크에 대응하라는 것이 이 책의 핵심이다.

이 책을 저와 같이 아키텍처를 설계해 보고 또 실패해본 경험이 있는 개발자에게 추천한다. 저자는 코치가 되어 당신의 아키텍처가 실패한 이유를 정확하게 짚어 줄 것이다. 추상적인 아키텍처가 실패한 구체적인 이유를 통해 다음번엔 더 나은 아키텍처가 될 수 있기를 기원한다.

 

	

소프트웨어 엔지니어링을 통해 소프트웨어를 개발하는 과정은 지난하고 복잡하다. 요구 사항을 분석하고 도출된 결과를 통해 설계를 해 나갈 때, 다양한 어려움이 도사리고 있으며, 예기치 못한 숱한 난관이 도처에 드리우고 있다. 때로는 요구 사항을 통해 분석된 결과를 전면 재수정해야 할 필요가 있을 수 있고, 요구 사항 자체가 전복되어 처음부터 다시 그것을 위한 노력이 투여되는 상황도 존재한다. 전형적인 워터폴 방식의 개발 프로세스가 지배적인 구조라면, 이런 과정이 고역 그 자체일 수 있겠지만 애자일로 무장된 개발 조직에서는 고객의 요구 사항을 그때그때마다 피드백 받고 그것을 개발 과정에 반영하며 점진적인 개선을 꾀한다. 

 

그런데 애자일 방식을 활용하더라도 소프트웨어를 개발하는 과정에는 리스크가 항상 존재한다. 워터폴 방식이든, 애자일 방식이든 소프트웨어 개발 과정 자체가 예측불허한 리스크를 태생적으로 수반하고 있음을 부정할 수 없는 현실에 직면하게 된다. 어떻게 하면 리스크를 최소화하고 적정하게 관리하면서 소프트웨어를 개발할 수 있을지에 대한 가이드를 제공하는 바로 오늘의 주인공, ' 적정 소프트웨어 아키텍처'라는 책에 대해 이야기를 풀어 나갈 생각이다. 

 

 

이 책은 오랜 세월 동안 소프트웨어를 개발하며 지내 온 베테랑 저자의 생생한 경험과 지식이 녹아 들어간 서적이다. 그런 저자의 커리어가 증명하듯, 책 전체를 관통하며 주장하는 리스크 주도 접근법을 통한 소프트웨어 아키텍처 설계라는 발상이 무척 생경하게 다가왔지만 책을 완독하고 덮는 순간 이루 표현할 수 없는 뿌듯함을 느낄 수 있는 시간을 가질 수 있었다. 

 

소프트웨어 아키텍처가 무엇인지에 대한 물음으로 시작해서 소프트웨어 아키텍처의 중요성을 갈파하며, 아키텍처 특성 별로 아키텍처 무관 설계, 아키텍처 집중 설계, 아키텍처 상향 설계라는 새로운 방향을 제시한다. 이윽고 리스크 주도 모델에 대한 세세한 특성을 풀어 나가며, 리스크 모델이 왜 필요한지에 대한 저자의 고찰과 진지한 논의가 계속 이어진다. Part 1의 모델링과 관련된 조언을 통해 아키텍처를 어떻게 설계할지에 대한 실질적인 조언과 가이드를 여실히 제공 받을 수 있었다. 

 

Part 2에서는 아키텍처 모델링에 대한 여럿 주제를 놓고 이야기가 계속 진행된다. 도메인 모델, 디자인 모델, 코드 모델에 대한 개별적 특성과 구조에 대해 상세한 설명이 풀이되고 캡슐화 및 파티셔닝을 통해 어떻게 아키텍처가 자리잡게되는지에 대해 인사이트를 얻을 수 있게 된다. 계속해서 모델 요소와, 모델 관계에 대한 세부 논의를 통해 아키텍처 내부가 어떻게 서로 연관되고 상호작용하게 되는지 학습하게 되며, 아키텍처 스타일에 대한 이야기를 통해 현실 세계 적용 가능한 아키텍처의 종류를 배우게 된다. 

 

이 책은 참고로 하드 커버로 제작되었다. 하드 커버로 구성된 책을 참 오랜만에 접하게 되었는데, 하드 커버가 제공하는 나름 독특한 분위기와 책의 겉표지가 절묘하게 어우러져 책을 받은 즉시 기분이 좋았다. 이 책 전체를 횡단하는 리스크 주도의 접근을 통해 소프트웨어 아키텍처를 설계하는데에 있어, 어떻게 리스크를 최소화하고 적정 수준으로 리스크를 관리할 수 있을지 궁금한 사람이라면 응당 이 책을 반드시 일독해야 한다. 소프트웨어 아키텍처를 제대로 설계하고 리스크에 휘둘리지 않는 아키텍트가 되고 싶은 사람, 그런 아키텍트를 지향하는 개발자라면 꼭 이 책을 접해 보길 바란다. 

 

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

◎ 추천 포인트
1. 프로젝트의 성공을 위한 설계의 중요성
2. 소프트웨어 아키텍처에 대한 전반적인 소개
3. 잘 읽히는 편집과 번역


개인적으로 정보보호에 대해 관심이 많다.
그렇다 보니 “리스크 주도 접근법”이라는 부제에 끌려서 보게 되었다.

간단히 말하면 소프트웨어 아키텍처에 대한 일반적인 이론서… 딱 그만큼이다.
기대에 비해 다소 김 빠지는 내용이었다.
부제에서 말한 리스크는 정보보호 관점이 아닌 소프트웨어 개발 프로젝트에서 발생하는 리스크에 초점이 맞춰저 있다.
물론 보안에 관한 고려를 이야기 하고 있지만, 핵심적인 부분은 아니다.

그리고 보다보면 여러 다른 책에서 인용한 부분이 많이 나온다.
그런데 그 인용된 책들 대분이 90년대 혹은 2000년대 초반으로 되어 있다.
아직도 중요 바이블인 GOF 디자인패턴도 90년대 책인데다가, 이 분야가 자주 바뀌지 않기 때문인가 싶다가…
이 책이 2010년도에 발행된 책인걸 알게 되었다…


이정도 방법론이 사용되던 시절의 내용이다보니 데브옵스 등 최신 트랜드와는 조금 거리가 있어보인다.
심지어 그때 1판 이후 판올림도 없다.
좀 실망스러운 부분이다.

 

아키텍처 입문용이라면 소프트웨어 아키텍처 101 쪽을 더 추천 하겠다.
내용자체는 나쁘지 않은것 같지만 개인적으로 기대한 내용이 아니다 보니 흥미와 집중도가 떨어셔서 이 책에 대한 올바른 평가가 아닐수 있겠다. 

처음 "소프트웨어공학"을 접하게 된 것은 대학교 3학년때였다.

전공선택으로 소프트웨어 공학을 골랐었는데, 당시에는 쉽게 학점을 받을 수 있는 과목이라는 선배들의 팁 때문이었다.

그리고, 수업을 들었을 때는 "이게 뭐야? 이게 무슨 도움이 된다는 거지? 이거 순 말장난 아닌가?" 하는 생각으로 한 학기를 보냈다.

그럴수 밖에 없었던 것은, 당시만 해도, 만들어본 코드는 1000라인을 넘지 않았었고, 프로그래밍 수업의 과제를 할 때도, 요구사항 분석-설계 같은 것을 할 필요가 없이 그냥 무조건 #include <studio>를 치고 시작하는 그런 시기였었기 때문이었다.

혼자 짜는 프로그램, 1천라인 내외의 코드 분량의 경우, 문서화 작업은 오히려 귀찮은 일이었고, 짜면서 수정하는 그런 행동 (당시 교수님들은 "그러지 마라" 라고 하는 행동이었지만, 우리들은 "이렇게 하면 더 빠르고 편한데 왜 정석을 따르면서 불필요한 짓을 해야 하지?" 라고 생각하던 시기였다)이 당연하던 시기에 소프트웨어 공학이 말하는 것들은 공감하기 힘들었다.

그러다가, 취업을 하고, 만 단위 라인이 넘어가는 프로그램을 팀 단위로 작업하는 경험을 하고, 고객의 요구사항이 매 순간 바뀌면서, 바뀔때마다 프로그램의 구조가 변하게 되고, "그걸 하려면 차라리 새로 만드는 것이 낫다!" 라고 하면, "그럼 바꿔. 불평할 시간에 코딩하라고!" 라는 식의 스퀴즈 일정을 몇번 보내다보면, 소프트웨어 공학의 필요성을 느끼게 된다.

그제서야, 소프트웨어 공학의 필요성과 그 선구자적 비전에 공감하게 된다.

하지만, 이제와서 설계부터 다시하고 하기에는 납품 시간이 촉박하니까, "다음부터는 꼭 해야지.." 라는 다짐만 남기고 또 똑같은 과정을 반복해서 수행하곤 하는데, 그런 경험이 반복되면, 몸으로 겪고 이해하게 되는 소프트웨어 개발 방법론이 생기게 된다.

야근 후, 동료들과 담배 피면서 "이건 이렇게 했었어야 했다", "나중에 이렇게 바뀔 수도 있는데, 그럼 여기에서는 이런 식으로 하는 것이 더 낫지 않은가?" "지금 좀 더 고생하더라도 나중에 쉽게 갈 수 있게 해야 하나? 아니면, 지금 빨리 돌아가게 만들어야 하나?" 이런 고민들이 이 책에는 다 설명되어 있었다.

소프트웨어 아키텍처라는 이름으로 말이다.

학교에서 배웠던 소프트웨어 공학 뿐만 아니라, 그 이후에 나왔던 에자일 방법들까지 모두가 설명된 책이었다.

1부에서는 소프트웨어 아키텍처는 무엇이고 왜 만들어야 하고, 이것을 만들기 위해 어떤 흐름들이 있었는가에 대한 이야기를 하고 2부에서는 아키텍처 모델을 만들기 위한 개념들에 대한 설명을 하고 있다.

"그래 그래 이거야. 이게 내가 하고 싶었던 말이야!" 라는 것이 알고 보니, 이미 배웠던 것이고, 이런 것에 대한 체계적인 연구가 진행되어 왔고, 또 진행되고 있었다는 것을 다시금 확인할 수 있는 책이었다.

이 책의 진가를 알기 위해서, 본인이 겪었던 것 처럼 수년간의 뻘짓의 경험이 꼭 필요하지는 않을 것이다. 좋은 선생님/교사가 있다면, 그 경험이 없더라도, 이 내용이 왜 중요한지 실무의 사례를 통해서 설득시키고 납득시키고, 또 책에서는 "참고자료"로만 설명하고 넘어간 수 많은 추가 자료들에 대해 알려줄 수 있을 것이다.

만약, 내가 대학교때 이 책을 봤었더라면, 지금 이 책을 보면서 느낀 감동을 그때 느꼈을 수 있었을까? 냉정하게 생각해보면, 그때 혼자 이 책을 봤더라면 역시 "뭐야 이건" 이라면서 무시했을 것 같다.

아직 삽질의 경험이 없는 초심자가 소프트웨어공학의 진가를 스스로 알아차리고 학습 동기를 얻기란 어려운 일이니까 말이다.

이 책은 경험 많은 교수가 본인의 강의를 할 때, 교재로 사용될 때 그 진가를 다할 수 있을 것 같았다. 이 책의 저자 역시, 본인의 강의 경험을 바탕으로 만든 책이라고 하니, 대학 전공 교재로 탁월할 것으로 생각된다.

배움에는 왕도가 없다고 하지만, 최소한 소프트웨어 공학을 공부할 때는 이 책을 선택하는 것이 왕도가 될 수 있을 것 같았다.

-------------

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

---------------

1220626.jpg

 

소프트웨어 개발자는 지속적으로 성장하면서 개발하려고 합니다.

 

개발할 때 경험에 따라서 능력치가 다르게 나타납니다.

 

그런 이유로 많이들 큰 회사에 취업하려고 하는데요.

서비스 이용 트래픽이 회사마다 차이가 많습니다.

 

리스크를 최소화해야 손해를 막을 수 있습니다.

 

소프트웨어 아키텍처를 통해 리스크를 최소화하게 도와줄 책을 살펴보려 합니다.

 

살펴볼 책은 ‘적정 소프트웨어 아키텍처‘입니다.

 

완벽한 코딩은 할 수 없지만 실패할 수 있는 설계는 피할 수 있습니다.

 

리스크에도 위험도가 중요도를 잘 따져야 합니다.

 

리스크 주도 접근 방법을 통해 설계하는 것이 어떤 것인지 같이 알아보겠습니다.

 

 

2220626.jpg

 

 

◆ 아키텍처 스타일

개발하다 보면 디자인 패턴을 배우게 됩니다.

 

패턴은 반복되는 문제를 재사용할 수 있는 해결책입니다.

 

아키텍처 스타일은 아키텍처 수준에서 발생하는 컴포넌트와 모듈 같은 아키텍처에 적용이 됩니다.

 

스타일은 사전 제작된 제약 조건을 그대로 사용할 경우 쉽게 적용할 수 있습니다.

 

그대로 사용해도 되는 경우 설계와 디버깅 작업 시간 절약이 가능합니다.

 

또한 한번 쓰였던 스타일은 깔끔하게 만들어졌다면 일관되게 구현할 수 있는 장점도 있습니다.

 

 

3220626.jpg

 

 

◆ 리스크 주도 모델

소프트웨어 개발자들은 만들고자 하는 서비스를 만들 때 리스크를 비교합니다.

 

여러 기능 중 꼭 필요한 기능을 중심으로 만드는데요.

실패 리스크가 적은 옵션을 선택합니다.

 

성공적인 설계는 한 번에 만들어지지 않습니다.

 

실패를 예상하고 제거했을 때 성공적인 설계가 만들어집니다.

 

리스크 주도모델의 핵심은 3가지로 볼 수 있습니다.

리스크 식별 및 우선순위 지정

일련의 기법 선택 및 적용

리스크 감소 평가

 

개발을 하다 보면 여러 리스크를 고려하며 간과하는 경우도 생깁니다.

 

간과한 것은 추후에 발견되면 조치하게 됩니다.

 

 

4220626.jpg

 

 

끝으로 이 책은 미숙한 개발자나 숙련된 개발자를 위한 책입니다.

 

리스크 주도모델의 개념부터 적용 방법까지 잘 정리되어 있습니다.

 

만날 수 있는 리스크에 맞게 적정한 아키텍처를 설계하는 방법을 알려 줍니다.

 

다양한 종류의 아키텍처 스타일도 정리되어 있어 개념을 쌓을 수 있습니다.

 

리스크 관리에 관심 있는 분들에게 이 책을 추천합니다.

 

 

요즘 신규 프로젝트를 한참 진행 중이어서 이것저것 다양한 개발론과 아키텍처 설계에 관한 책들을 공부하고 있는중이다.

그렇게 꽤나 많은 분량의 책들을 공부해가던 중, 한빛미디어에서 신간으로출간된 "적정 소프트웨어 아키텍처"라는도서가 눈에 끌려 이번 달 리뷰 도서로 지정하여 리뷰하게 되었다.

이 책의 핵심 내용을 정말 단순히 요약하자면 책의 부제로 나와있는 것과 동일하게 "리스크 주도 접근법에 근거한 리스크 우선순위의 아키텍처 이론이라 할 수 있을 듯하다."

뭔 말인고 하니, 우리가 아키텍처를 설계하고 계획할 때, 모든 것들을 두루 살펴 상당한 시간을 투자하는 것보단, 우선순위가높고 시급도와 리스크가 높은 테스크를 점수화한 후, 이를 우선적으로 아키텍처에 반영하는 형태의 개발론을선보인 것이다.

마치 예전에 스티브 코비 박사가 저술하였던 성공하는 7가지 습관에있는 것처럼 중요한 것을 우선시 수행하라 와 동일하게 말이다.

이 책의 구성은 대부분이 위에서 언급한 리스크들을 어떤 순위로 정렬할 것이며 어떻게 해야 효과적으로 아키텍처에반영할 수 있는지를 다양한 예시와 적절한 유희적 언어를 표현해가며 술하고 있다.

【책의 구성】 '적정 소프트웨어 아키텍처 - 리스크 주도 접근법' 책은 어떤 책일까?

 이 책은 대학교 도서로 쓰기에 안성맞춤인 책이다. 솔직히 컴퓨터 분야에 대해서 전무한 사람이 읽기엔 허들이 있는 책이고 읽는다 해도 많은 것을 얻긴 힘들 것이라보인다. 왜냐하면 생소한 언어뿐만 아니라 실무 입장에서 경험을 해보고 책을 읽어야 훨씬 많은 것이 와닿을법한 내용들로 구성되어 있기 때문이다.

이 책은 각각의 "모델"들을예로 들어가며 책을 술하고 있다.

여기서 말하는 요즘 핫했던 딥러닝의 모델들을 의미하는 것이 아니다. 여기서의미하는 모델은 각 도메인에 속하는 지식들과 대표하는 하나의 특징 등을 의미하는 것이다. 따라서 딥러닝의모델과는 사뭇 다르므로 혼동해서는 안 된다.

이 책의 구성은 다양한 모델들을 언급하고 이에 맞는 리스크 기반의 접근법에 대해서 설명하고 있다.

도메인 모델, 디자인 모델, 코드모델 그리고 각 모델들의 구성과 서로의 상관관계들도 잘 서술하고 있다.

솔직히 이 책은 제법 시간을 들여서 읽어봐야 많은 것을 얻을 수 있는 책이며,간략하게 책의 구성과 흐름 그리고 전반적인 설명에 관한 내용을 알고자 한다면 챕터 3과챕터 4를 충분히 읽어보길 권한다.

 


 

3 챕터 : 리스크 주도모델

 이 장에서는 리스크 주도 모델이 과연 무엇인지, 그리고 어떤 것이 리스크 모델의 특징인지를 술하고 있다. 거의 이책의 가장 핵심이라 할 수 있다. 이외의 자세한 내용은 아키텍처 모델링이라는 섹션 이후부터 자세히 설명하고있으므로 이 챕터를 읽어보며 궁금한 부분은 해당 섹션의 챕터를 읽어보면 된다.

리스크 모델은 그렇다면 무엇일까?

단순히 요약하면 가장 시급도가 높고 빠져서는 안되는즉 반드시 고려되어야 하는 요소들을 리스크 모델이라고 한다.

가령, 나는 차를 디자인하려 한다.차를 디자인할 때 가장 핵심 모델은 무엇인가? 바로 차는 인간을 대신하여 효과적으로 움직일수 있어야 한다는 것이다.

그렇다면 어떻게 해야 효율적으로 움직일 수 있을까? 이때 효율적으로움직이기 위한 필수 요소들은 무엇이고 반드시 빠져서는 안되는 요소들은 무엇일까?

아마도 타이어, 엔진, 그리고골격, 그리고 차 외피 정도를 들 수 있을 것이다. (필자는자동차를 전공하지 않아, 대략적으로 생각나는 대로 적어본 것이므로 너그러이 봐주시길 바란다.)

이것들이 리스크 주도 모델을 구성하는 핵심 리스크 요소가 된다.

 


 

4 챕터 : 홈 미디어플레이어

 3장의 설명만으로는 부족할 것이다. 왜냐하면 3장의 대부분의 내용은 글로써 설명하고 있고, 글이라고 해봐야 핵심 개념 정도만 예제를 들어 설명하는 정도의 내용이기 때문이다.

이런 내용들만으로는 독자는 쉽게 피로해질 것이고 금세 책에 흥미를 잃어버릴 가능성이 있다. 그래서 저자는 다음 장에서 바로 적절한 소프트웨어를 예로 들어가며 리스크 모델이 무엇인지에 대해서 예시를 설명하고있다.

필자는 이 책에서 이 부분이 가장 흥미로우면서도 가장 핵심적인 내용들을 많이 담아내고 있지 않나 싶었다. 물론 세부적인 내용들은 뒤에 있는 챕터들에서 설명하고 있으나 책의 전반에 걸친 내용들을 이 챕터에서 잘 나타내고있었기 때문이다.

이 챕터에서는 소프트웨어 프로그램을 기획하며 리스크 모델을 뽑고, 그리스크 모델 기반으로 어떤 식으로 코드들을 구성할지에 대해서 잘 술하고 있다

 


 

【 "적정 소프트웨어 아키텍처 - 리스크 주도 접근법"을 읽고 나서…….】

프로그래머 세계에이런 말이 있다.

"백문이 불여 일타"

즉 백번 물어보는 것보다, 직접 한번 타이핑하고 구동시켜보는 것이의미 있다는 말이다.

컴퓨터 공학은 실용학이기에 이제껏 필자는 위의 글을 불문율이라 생각하고 지향하며 지키고 살고자 하였다. 하지만 한번 타이핑해 보는 것만큼 중요한 것은 기본기에 대한 지식과 역량을 쌓는 것이라는 것을 요즘 들어 깨닫게된다.

책을 읽고 학습하고 이해하는 것으로는 충분하지 않을 수도 있다. 또한책의 내용은 시간이 흐르면 자연스레 잊히게 되고 책의 성문적인 내용을 현실에 그대로 적용한다는 것은 어찌 보면 어리석고 고된 일이라 할 수도 있다.

하지만 책을 읽으며 한걸음 한걸음 쌓아올린 지식들과 심도 있는 고민들은 자신도 모르게 손으로 그리고 몸으로 그리고행동에 옮겨붙게 되어 있다.

따라서 코딩도 중요하지만 훌륭한 프로그래머, 나 자신을 이겨낸 진정한개발자가 되고자 한다면 기초 학문과 다양한 이론적 접근에 대해서도 항상 게을리하지 않고 공부해야 할 것이라 생각된다.

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

 

 

이 책은 무엇보다 추천사의 여러 추천글이 인상적인것 같다. 추천사의 글을 읽고 공감가는 글이 있다면 이 책은 독자에게 훌륭한 가이드가 될 수 있음을 믿어 의심치 않는다.

 

아마존 별점 최상위를 수년간 유지하고 있는 서적(22년 6월 현재 - 4.4)을 원서가 아닌 한글로 쉽게(?) 볼 수 있게 해준 역자에게 먼저 고마움을 표하고 싶다. 소프트웨어 업체에 수년간 몸을 담구며 바쁜 현업을 하고 있지만 여전히 배움에 대한 열정으로 목마르다. 소프트웨어 아키텍처는 단순히 소프트웨어 아키텍처를 주업으로 하고 있는 아키텍트만의 일이 아닌 협업하고 있는 모든 관계자들(개발자(저자는 개발자를 주 독자로 여기긴 했지만...), 테스터, 아키텍트, DBA 등)이 어느정도는 알고 있어야 하는 청사진이자 뼈대를 이루는 근간이기 때문이다.

박사 학위를 가지고 있고 다년간의 소프트웨어 엔지니어링 분야의 경험을 가진 저자로 부터 소프트웨어 아키텍처에 대한 깊고 풍부한 경험을 책으로 전해 들을 수 있는 소중한 기회였다. 물론 번역에 있어서 최대한 원저자의 의도를 잘 전달하려고 노력해준 역자의 노력도 큰 도움을 준다.

 

이 책의 원제는 'Just Enough Software Architecture'이다. 일반적으로 'Just Enough'이라는 말은 적당한 정도로 해석하는데, 역자는 '충분한'으로 제목을 정하려다 고심끝에 '적정'으로 정했다고 한다. 이 책의 제목에서 알 수 있듯이 이 책은 모든 소프트웨어에 최적의(?), 최고의(?) 아키텍처를 제시하고자하는 것이 아닌 프로젝트 상황에 맞는 '적당한', '적정한' 아키텍처를 제시하는 것이 목적이다. 이를 위해 '리스크를 줄이기 위한 주도 모델'개념과 이를 적용하는 상황별 다양한 아키텍처 스타일을 제시하고 이를 통해 많은 것을 알려 주고 있다.

 

이번 책은 소프트웨어 아키텍처에 관한 책이다. 요즘 개인적으로 어떤 소프트웨어를 개발하고 만드는 단계에 있어서 아키텍처에 대한 고민들을 주로 하게된다. 

 

물론 정답은 없고, 상황에 따라 다르긴하지만 다양하게 접근하는 방법에 대해 알려주고 있으며, 책 뒷면에서는 "실용 가이드북"이라고 칭하고 있다. 

대상 독자

대상 독자는 개발자라는 대상에서 전체적으로 해당되고 있다고 생각하고 그중에서 나는 미숙한 개발자라서 도움이 될것 같다.

 

 

책은 크게 2파트로

1. 리스크 주도 소프트웨어 아키텍처

2. 아키텍처 모델링

으로 나누어져 있어 해당 파트 아래에 다양한 챕터들로 설명해주고 있다.

 

파트0 챕터1 개요를 지나, 파트1에서는 좀  더 이론적인 소프트웨어 아키텍처에 관해 설명해주고 있다.

 

챕터2부터 2.소프트웨어 아키텍처/ 3. 리스크 주도 모델/ 4. 예제: 홈 미디어 플레이어 / 5.모델링 관련 조언 으로 파트1이 끝난다.

 

 

단순히 이론만 설명해주면 헷갈렸을 부분을 미디어 플레이어라는 예제로 챕터로 넣은게 좋다고 생각했다.

 

이후에 파트2 부터는 다양한 모델에 대해 설명해주고 있다.

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

 

해당 구성을 보면 파트2의 부분이 더 많이 차지하고 있다.  파트1에서는 소프트웨어 아키텍처와 리스크에 관해 살펴보면서 리스크를 완화하려는 아키텍처를 구축하는 부분에 대해 설명한다면 파트2부터는 필요한 소프트웨어 아키텍처 개념과 표기법에 대해 설명해주고 있다.

 

이런 여러한 모델을 보다보면, 이 책은 미숙한 개발자 입장에서 보기에는 다양한 아키텍처들의 모델의 경우와 상황에 이해를 도와주는데에 있고, 실제로 개발하는데에 있어서 다양한 경우가 있기에 당장 써먹을 수 있다라는 책이라기보단, 옆에 두고 있다보면 언젠간 도움이 된다고 생각 하는부분이 많이 있다.

 

 

 

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

 

 

 

http://www.yes24.com/Product/Goods/109748333

 

 


완벽한 소프트웨어 개발 설계 방법은 하늘에 뚝- 떨어지진 않는다. 특히 트레이드 오프에 놓이거나, 오버엔지니어링이 될 수 있는 설계의 적정한 수준을 알아가보는 책이 나왔다. 

 

 

스크린샷 2022-06-26 오후 4.50.55.png

 

 

 

이 책은 리스크 관리 중심으로 아키텍처를 설계하는 방법은 무엇인지, 어떻게 전략적으로 자신의 프로젝트에 적용할 수 있는지 자세히 설명한다. 소프트웨어 아키텍처의 필수 개념, 아키텍처 설계를 수행하는 추천 시기와 현실적인 조언, 다양한 모델과 스타일, 리스크 관리 중심의 설계 적용 방법을 배우고 여러분의 아키텍처 설계에 필요한 실용적이고 적절한 해결책을 찾을 수 있게 도와줄 책이다. 

 

적정 소프트웨어 아키텍처는 소프트웨어 개발을 시작할 때 필요한 실용 가이드북으로, 소프트웨어 아키텍처의 리스크는 무엇인지, 아키텍처 설계 원칙은 어떻게 적용하고 해결하는지, 유관 부서의 실무자를 어떻게 도울 수 있는지 등의 주제를 개발자가 흔히 겪는 경험을 기반으로 풀어내고 있다. 개발하면서 너무 많은 문서를 작성했거나, 코딩을 시작하기 전에 너무 적게 고민한 적도 있을 것이다. 어느 쪽이든 소프트웨어 개발이 왜 잘못되는지 알 수 있고, 이 책에서 제공하는 해결책이 많은 도움이 될 것이다.

 

대상 독자는 다음과 같다.

1. 미숙한 개발자 또는 학생

- 개념 모델, 품질 속성, 아키텍처 스타일 등의 통해 숙련된 개발자가 되는 빠른 방법을 배운다. 

2. 숙련된 개발자

- 멘토링 능력을 향상하고, 다른 개발자가 겪는 문제와 해결을 익힌다. 

3. 소프트웨어 아키텍트

- 조직에서 아키텍트의 역할, 시스템 구축 기법, 수행 방법을 배운다.

4.학계 관련 인사

- 리스크 주도 모델 아키텍처 접근법으로 소프트웨어 아키텍처 분야 지식을 습득한다. 

 

적정 소프트웨어 아키텍처 책이 다른 책과 차별화를 두는 점은 상황에 따른 소프트웨어 아키텍처 사용법을 정리하고, 아키텍처 무관 설계, 집중 설계, 상향 설계의 접근 방식을 소개하고 있다. 소개하면서 다이어그램과 표를 통한 개념 모델 이해를 돕기 때문에 이런 점은 막연하기만 내용을 도식화하니 훨씬 도움이 된다. 

 

크게 5가지 주요 내용으로 요약할 수 있다. 

1. 리스크 주도 아키텍처링

- 직면한 리스크에 따라 적정한 아키텍처 설계를 수행하는 방법

2. 참여하는 아키텍처

- 아키텍트뿐 아니라 모든 소프웨어 개발자를 위한 아키텍처

3. 선언전 지식

- 기법을 적재적소에 사용하기 위한 개념과 용어

4. 엔지니어링 강조

- 소프트웨어 개발의 기술적인 부분과 시스템 작동을 위한 엔지니어링

5. 실용적인 활용 방법

상위 아키텍처부터 하위 자료 구조 설계까지 다양한 수준의 모델을 활용하는 접근 방법

 

추천평: 마커스 폰토라 박사 (Yahoo! 리서치 수석 연구원 및 아키텍트)

이 책은 소프트웨어 아키텍처를 쉽게 적용하고 실용적으로 만드는 독특한 관점을 제시한다. 적정 아키텍처와 리스크 주도 설계의 개념은 획기적인 아이디어다. 이 책은 아키텍처 원칙을 실제 사례에 효과적으로 적용할 수 있는 방법을 보여준다. 소프트웨어 개발 분야에서 일하는 모든 사람이 반드시 읽어야 할 매우 유용한 책이다.

 

 

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

이 책은 소프트웨어 개발을 위한 적정한 아키텍처를 다루는 일종의 가이드북이다. 나는 책 말머리를 많이 보는 편이다. 저자가 어떤 목적으로 이 책을 쓰게되었는지 알 수 있기 때문이다.

 

이 책 역시 서두의 말머리부터 꼼꼼히 보았다. 그 말 중 조금 독특한 부분이 있어 기억이 나는 부분이 있다. 저자가 대학교 교재로 사용하기를 바라는 마음으로 작성했다는 말이 쓰여 있었다.

 

읽으면서 아 '이 책 컴퓨터공학과 교재로 사용해도 무방하겠구나' 싶었다. 대신 좀 더 실용적인 부분에 대한 교재이므로 대학교 1-2학년은 아니고 3-4학년에게 더욱 어울려 보인다.

 

본론으로 들어가 책에 대한 내용을 살펴보면 리스크 주도 아키텍처링을 비롯해 모든 소프트웨어 개발자들을 위한 아키텍처 지식, 개념, 품질 등에 대해 쓰여있고 이에 해당하는 기법과 알맞은 방법으로 활용할 수 있는 방법들을 가르쳐 준다.

 

주니어 단계의 레벨을 가진 개발자가 다음 레벨로 나아가기 위해서는 꼭 아키텍처링이라는 지식이 필요하다고 생각하는 편인데, 이 책을 읽으면 어느정도 아키텍처링에 대한 갈망을 해소할 수 있어 보인다.

 

아키텍처에 대한 개념에 대해 나름 전공(?)책과 같은 이야기를 풀어쓰는데, 여기서 리스크 주도 모델 개념이라는 아키텍처 기법을 처음 들었다. (표지나 책 재질도 전공책 같다는 데 한 몫했다. 책갈피가 없어 아쉬울 뿐이다.)

 

리스크 주도란,

 

첫째, 리스크를 식별하고 우선 순위를 지정하는 것. 

둘째, 일련의 기법을 선택하고 적용하는 것

셋째, 리스크 감소 평가

 

위 3가지 원칙을 반복적으로 체킹하며 리스크에 따른 기준으로 아키텍처 기법을 선택해 설계하는 의미이다.

 

나와 같은 주니어 개발자는 사수에게서 배우지 않는 이상 아키텍처, 쉽게 말해 유지보수와 시스템 설계 방식에 대해 알기 쉽지 않고 배울 기회가 없을 수 밖에 없다. 사수가 아예 없는 주니어도 더러 있거니와 사수 역시 아키텍처 품질에 대한 고민이 많지 않을 수 있기 때문이다.

 

이를 빗대어 보면 '적정 소프트웨어 아키텍처'는 이국 너머의 대선배 개발자에게 많은 것을 배워볼 수 있는 기회가 가득했던 좋은 책이었다.

 

참고로.. UML이나 OOP에 대한 기본적인 개념, 그리고 디자인 패턴에 대한 지식이 어느정도 있어야 이해가 가능하다. 

 

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

KakaoTalk_20220626_142721522.jpg

 

대부분의 아키텍처 책이 그렇듯이 이 책도 해당 분야를 전공한 학부생 3,4학년 혹은 석사과정을 대상으로 한다. 언어의 뉘앙스 차이로 책 제목은 'just'가 '적정'으로 번역되었다. 옮긴이의 말에서도 적혀있지만, just enough 느낌이 제대로 살지 않는 느낌이다. 완벽히 들어맞다고 할 수는 없지만 이보다 좋은 단어는 없다고 생각된다.

 이 책은 특정 아키텍처 모델을 설명하는 책이 아니다. 이 책은 다른 저자가 발명한 아키텍처 모델링 접근법을 어떻게 해야 효율적으로 선택할 수 있는지 기준을 제시한다. 그 기준이 바로 리스크(Risk)다. 핵심 아이디어는 소프트웨어 아키텍처를 설계하는 데 드는 노력이 프로젝트의 리스크에 비례해야 한다는 것이다. 이것을 간단하게 저자는 우편함 설치를 예시로 들었다. 기계공학 전문 지식이 있는 사람이 새 우편함을 설치할 때 모든 기계공학 분석 및 설계 기술을 적용하지 않고, 그냥 단순히 구멍을 파고 우편함을 세우고 구멍을 콘크리트로 채운다는 것이다. 이런 식으로 리스크 주도 모델은 아키텍처링 기법을 언제 적용하지와 언제 건너뛸지를 결정하는 데 도움이 된다는 것이 이 책의 핵심 내용이다.

 즉, 이 책은 애자일 소프트웨어 아키텍처에 특화한 책은 아니지만, 리스크 주도 접근 방식이 애자일 프로젝트에 적합하다는 점을 알려준다. 소프트웨어 개발 프로세스가 요구사항에서 소프트웨어 배포까지 모든 활동을 조정할 떄는 리스크 주도 모델이 아키텍처 설계만 가이드한다. 그러므로 리스크 주도 모델은 모든 소프트웨어 개발 프로세스에서 사용할 수 있다는 것이다. 저자는 그 과정을 3단계로 나누어서 설명하였다.

1. 리스크 식별 및 우선 순위 지정 (내 리스크는 무엇인가?)

2. 일련의 기법 선택 및 적용 (이를 줄이는 가장 좋은 기법은 무엇인가?)

3. 리스크 감소 평가 (리스크가 완화되었고 코딩을 시작(또는 재개)할 수 있는가?)

 위 질문 과정을 반복적으로 행하여 리스크에 따라 아키텍처 기법을 선택하라는 조언이다.

 저자는 소프트웨어 개발의 어려움을 해결할 만병통치약 같은 기법을 기대하면 안된다고 말한다. 대신 시스템을 잘 분할하고, 지식을 제공하고, 추상화로 문제의 본질을 드러내는 무기를 찾아야 하는데 소프트웨어 아키텍처는 그러한 무기이며 소프트웨어 시스템의 복잡성과 규모를 다루는 데 도움을 준다고 한다. 아키텍처는 소프트웨어를 분할하는 데 도움을 주고, 더 나은 소프트웨어를 설계하는 데 도움을 주는 지식을 제공하며, 소프트웨어를 추론하는 데 도움을 주는 추상화를 제공한다. 이것들은 모두 숙련된 개발자가 이미 보유하고 있는 도구라고 말하고 있다.

 따라서 저자는 개발자들이 서로 다른 다양한 프로세스를 사용하여 성공적으로 소프트웨어를 개발할텐데, 개발해야 하는 소프트웨어의 리스크로 아키텍처 작업량을 결정하는 방법을 제안한다. 물론 소프트웨어 아키텍처는 비교적 새로운 기술이며 시스템 모델링과 분석에 유용한 많은 기법이 있다. 그러나 이러한 개별 기법을 실제로 시스템 개발할 떄 사용하면 개발 시간을 그만큼 소비하게 된다. 이런 이유로 저자는 소프트웨어 아키텍처에 대한 리스크 주도 모델(Risk-driven Model)을 제안한 것이다. 이 모델은 적절한 아키텍처링 기법을 선택하여 적용하고, 얼마나 많은 시간을 투자할지 파악하도록 해주어 적정 아키텍처(Just enough architecture) 작업을 수행하도록 안내한다.

 사실 아키텍처를 잘 모르는 내 입장에서는 당연한 말인 것처럼 느껴진다. 아주 간단한 프로그램을 만드는데 이것저것 아키텍처 기법과 디자인 패턴 등등을 고려하여 프로그래밍할 필요는 없다고 본다. 그러나 만들어야 하는 프로그램 규모가 크고 복잡하다면 리스크에 따라 적절한 아키텍처 모델링을 선택해야 한다는 것은 매우 동의한다. 한국에서 코딩을 배울 때 이런 아키텍처 기법을 절대로 설명해주지 않는다. 보통 프로그래밍 언어의 기본적인 내용을 가르쳐주고, 자료 구조와 알고리듬 정도만 알려준다. 그 이외에 기법들은 알아서 배우라는 식이다. 또는 코딩을 하다보면 프로그램 구조에 대해 생각할 수 밖에 없기 때문에 그 때가서 따로 공부하라는 식이다.

 나 역시 그런식으로 공부했기 때문에 책에 나오는 아키텍처 기법들 대부분은 처음 듣거나 모르는 내용이 많았다. 그러나 책에서 말하고자 하는 핵심 내용은 쉽게 파악할 수 있었다. 결국 아키텍처를 생각하는데 시간을 투자하면 실패 리스크를 완하는 설계를 선택하는 데 도움이 된다는 것이다. 또한 아키텍처 모델에서 모든 모델링 기법을 사용하려고 노력해서는 안 된다는 것.

 책에 마지막에 저자가 재밌는 말을 해두었다.앞으로 10년 안에, 개발자가 아키텍처를 무시하는 것은 오늘날 개발자가 자료 구조를 무시하는 것과 같이 어리석게 보일 것이라고 한다. 자료 구조를 배운 직후, 컴파일러나 운영체제를 배우기 전인 학부생에게 소프트웨어 아키텍처를 가르치자는 좋은 아이디어가 있는데, 이렇게 한다면 해당 시스템에서 볼 수 있는 아키텍처 패턴을 이해하고 각기 다른 설계 결정과 품질 속성을 절충하는 이유를 이해할 수 있기 때문이라고 한다. 또한 학부생이 컴파일러나 운영체제를 개발하는 일은 거의 없지만, 거의 모든 학부생이 소프트웨어 아키텍처를 사용하여 시스템을 구축하기 때문이라고 한다.

이 내용에 대해 나 역시 틀린 말은 아니라고 생각한다. 10년 후에도 아직 이 일을 하고 있을지는 모르겠지만, 아키텍처 기법이 자료구조와 동일시하여 필수로 배우는 과목이 되는 날을 보고 싶긴한다.

 이 책은 아키텍처를 기법을 공부하기 위해 보기 보다는, 여러 아키텍처 기법을 공부한 다음에 이제 어떤걸 선택하는 게 더 효율적인지 고민하는 단계에서 보기를 추천한다.

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

 

적정 소프트웨어 아키텍처 책입니다 .이책은 소프트웨어의 개발에 있어서 조금더 좋은 소프트웨어 개발을 위한 실용적인 가이드북이라고 할수가 있습니다. 소프트웨어의 아키텍처의 리스크가 무엇인지 알고 어떻게 리스크를 관리하면서 도움을 줄수 있는지에 곽한 책입니다. 책의 주요내용을은 리스크 주도 아키텍처링을 비롯하여, 모든 소프트웨어 개발자를 위한 아키텍처, 선언적 지식을 통한 기법과 적재적소의 사용하기 위한 개념과 용어, 엔지니어링 강조, 실용적인 활용방법을 들 수가 있습니다.
이 책은 누구를 위한 책일까? 라는 의문에서 보면 이책은 개발자를 준비하는 과정에 있는 모든 사람들에게 필요하고 개발을 하고 있는 숙련된 개발자에게 상당히 도움이 되는 책이라고 볼 수가 있습니다. 개념,품질,아키텍처 스타일들을 통해 숙련된 개발자가 되는 빠른 방법을 배우며, 숙련된 개발자는 멘토링 능력과 문제해결력을 기르게 되고 아키텍트, 학계관련인사 모두 배울수 있는 좋은 책입니다.
책의 인사말에는 IT업계의 유명한 분들의 추천사가 적혀져 있습니다. 적정 소프트웨어 아키텍처는 조지페어뱅크스의 의해 써졌습니다. 그는 컴퓨터과학학위에 박사과정이 있으며 소프트웨어의 프레임워크의 올바른 사용에대해서 늘 생각하고 이클립스의 기반도구를 구축하기도 하였습니다.
적정 소프트웨어 아키텍처 다양한 CONTENTS를 가지며 자세한 설명과 예제로 구성되어 있습니다.  소프트웨어 아키텍처의 사용법정리는 물론 리스크 주도 모델 개념과 적용방법 다이어그램 표를 통한 개념모델의 대한 이해 다양한 아키텍처 스타일을 통하여 한번에 많은것을 배울 수 있도록 되어 있습니다. 즉 더 나은 소프트웨어 설계를 위한 리스크(실수)에 대하여 많은것을 배울 수가 있습니다.
아키텍처는 시스템을 제한한다
아키텍처는 시스템을 제한한다. 모든 시스템에는 제약이 있다고 책에서는 말합니다. 이전 시스템과 상호작용을 해여 하고 공급업체의 서브컴포넌트를 사용해야 한다. 정해진 메모리의 사용이나, 시간이러한 많은 제약들은 개발자의 제약으로도 볼 수 있지만 제약을 다른시각으로도 볼 수 있다고 말합니다. 시스템을 한방향으로 제한하면 다른방향으로 가지못하게 된다고 합니다. 그래서 제약이라는것을 어떻게 설정하냐가 중요합니다. 제약을 잘 설정하면 가이드 레일역할을 하며 올바른 프로그램 개발을 통하여 유지보수성이 좋은 시스템을 설계 할 수가 있습니다.
컴포넌트 타입의 사용
적정 소프트웨어 아키텍처는 컴포넌트 타입 사용에서 우리는 시퀀스 다이어그램과 구체화 사항을 볼수가 있다. 이러한 과제에서 그림의 이미지를 제공하여 컴포넌트타입과 포트타입 Livrary-PeopleDB커넥터 타입을 알 수가 있다. HTTP 웹 커넥터 타입이 어떻게 구성되어 있는지 알 수가 있다.ADD설계에서는 일반적이 소형 시스템은 기능을 집중하고 대형시스템은 품질에 더 많이 기울여야 한다고 말합니다. 그 이유는 이렇게 이야기 하고 있습니다. 시스템이 클 수록 서브컴포넌트의 대하여 엄격한 확률이 크고, 소프트웨어의 동학 연구소의 속성 주도 설계 ADD 프로세스는 품질 속성을 사용하여 모듈의 재귀적 설계를 추진하는 방법을 서택합니다. 품질 속성 드라이버를 다루는 전술을 안내하는 소프트웨어 엔지니어링 연구소에서는 그림 11-2와 같이 표로 자세함을 설명하고 있습니다.소프트웨어 개발자를 위한 실용적인 가이드는 아키텍처 설계 원칙을 어떻게 적용하고 실무자, 개발자에게 일어날수 있는 일들이 적혀져 있습니다. 그로인하여 관리 및 유지보수의 올바른 시스템을 만드는것을 지향하는 책이라고 볼 수가 있습니다. 프로그램의 리스크의 관리의 중점으로 생각한다면 이책을 꼭 읽어보기를 추천합니다.

1. 책 선정 계기

 

2022년 6월 한빛미디어의 '나는 리뷰어다' 대상 도서로 신청한 책이다.

리뷰어 신청 전에, 번역서인 경우 아마존 원서 리뷰를 먼저 본다.

평균 평점을 보니깐 4.4점이더라.

 

01.png

 

https://www.amazon.com/Just-Enough-Software-Architecture-Risk-Driven/dp/0984618104

이 정도면 괜찮겠다 싶어서 이번 달 리뷰 도서는 이 책으로 골랐다.

2. 도서 내용 리뷰

 

퇴근길에 버스에서 틈날 때마다 읽으려고 했는데.. 

읽다 읽다가 도저히 안 되겠어서 총 30분~한 시간 정도 읽고 포기했다.

나한테는 안 맞는 책인 것 같다.  왠지 교과서를 보는 것 같더라.

하드커버인 것부터 시작해서.. ㅎㅎ

작가님이 UML로 설명을 하려고 했는데 그렇게 실무적인 예제가 아니라 이해하기 어렵다.

 

02.jpg

 

그림 있는 페이지보다 줄글로 도배된 부분이 훨씬 더 많다 보니 정말 더 어렵다.

 

03.jpg

 

다시 아마존 리뷰로 돌아가서, 평이 안 좋은 것부터 봤다.

리뷰 일자가 2012년이네?

확인을 해 보니 2010년에 출간된 책이었더라.

12년 전 책인데 지금 보는 건 아무래도 아닌 것 같다.

'리스크 주도 접근법'이라길래 위험 감지하고 그런 것부터 시작하는 것이 좋다.. 

그런 내용일 줄 알았는데(그런 게 있긴 있다) 쓸데 없는 설명이 너무 많다.

중간에 예제도 있고 다이어그램도 있는데 잘 안 와닿더라.

1점 평을 준 글을 보니깐 딱 내마음이더라. ㅎㅎ

Nothing related to enterprise architecture, I have finished several chapters but no useful skills or valuable knowledge in my basket. Repeated explanation. no hand-on experience, or tangible example, just theory.

엔터프라이즈 아키텍처와 관련이 없으며 여러 장을 완료했지만 바구니에 유용한 기술이나 귀중한 지식이 없습니다. 반복된 설명. 실제 경험이나 유형의 예는 없고 이론만 있습니다.

https://www.amazon.com/product-reviews/0984618104/ref=acr_dpx_hist_1?ie=UTF8&filterByStar=one_star&reviewerType=all_reviews#reviews-filter-bar

 

3. 결론

 

그렇게 사람들이 좋다던 '클린 아키텍처' 책을 봤을 때 난 전혀 재미 없었는데 딱 그 느낌이었다.

'라즈베리 파이로 배우는 컴퓨터 아키텍처'처럼 실제 구현한 예제를 가지고 아키텍처 설명한 책이 더 잘 와닿았다(그 책도 지루하긴 했지만 이 책 정도는 아니었다).

나의 추상화 수준은 아키텍트로서 요구되는 그것과는 안 맞는 것 같다.

내가 문제인가 싶기도 했는데, 책 내용도 공감을 일으키기엔 부족한 부분이 있어 보인다.

제목(리스크 주도 접근법)은 마음에 들었지만, 서사 방법에 문제가 있지 않나 한다.

게다가 12년 전 아키텍처 책이라 지금 읽기에는 적합하지 않은 것 같다.

 


[도서 소개]

소프트웨어 개발자를 위한 실용 가이드


이 책은 소프트웨어 개발을 시작할 때 필요한 실용 가이드북이다. 소프트웨어 아키텍처의 리스크는 무엇인지, 아키텍처 설계 원칙은 어떻게 적용하고 해결하는지, 유관 부서의 실무자를 어떻게 도울 수 있는지 등의 주제를 개발자가 흔히 겪는 경험을 기반으로 풀어냈다. 개발하면서 너무 많은 문서를 작성했거나, 코딩을 시작하기 전에 너무 적게 고민한 적도 있을 것이다. 어느 쪽이든 소프트웨어 개발이 왜 잘못되는지 알 수 있고, 이 책에서 제공하는 해결책이 많은 도움이 될 것이다.



[대상 독자]

- 숙련된 개발자

- 학계 관련 인사

- 미숙한 개발자 또는 학생

- 소프트웨어 아키텍트



[주요 내용]

-  리스크 주도 아키텍처링: 직면한 리스크에 따라 적정한 아키텍처 설계를 수행하는 방법

- 참여하는 아키텍처: 아키텍트뿐 아니라 모든 소프트웨어 개발자를 위한 아키텍처

- 선언적 지식: 기법을 적재적소에 사용하기 위한 개념과 용어

- 엔지니어링 강조: 소프트웨어 개발의 기술적인 부분과 시스템 작동을 위한 엔지니어링

- 실용적인 활용 방법: 상위 아키텍처부터 하위 자료 구조 설계까지 다양한 수준의 모델을 활용하는 접근 방법



[서평]

이 책을 좀더 빨리 알았더라면 소프트웨어 설계에 좀더 도움이 되지 않았을까 생각한다. 예전에는 언어와 객체지향 프로그래밍 책은 많이 있었지만 아키텍처 설계에 관련된 책은 많지 않았다. 단순히 프로그래밍 언어나 UML을 알고 있다고 좋은 시스템 아키텍처를 설계할 수 없다. 


이 책은 다른 소프트웨어 아키텍처 책과 차별점은 다음과 같다.


1.리스크 주도 아키텍처링을 가르친다. 리스크가 작을때는 세심한 설계가 필요하지 않지만, 리스크가 많아 성공이 불확실할 때는 엉성한 설계가 용납되지 않는다. 유명 애자일 소프트웨어 지지자들은 일부 선행 설계가 도움이 될 수 있다고 제안한다. 이 책은 적정하게 아키텍처 설계를 수행하는 방법을 설명한다.


2.참여하는 아키텍처를 지향한다. 소프트웨어 아키텍트이거나 조직에 소프트웨어 아키텍트가 있을 수 있다. 아키텍트는 개발자가 ‘아키텍처와 관련된 제약 조건이 존재하는 이유ㅜ’ㅏ와 ‘작아 보이는 변경이 시스템 속성에 큰 영향을 미칠 수 있다는 점’을 이해하지 못한다고 불평한다.


3.선언적 지식을 키운다. 심리학자가 말하는 절차적 지식과 선언적 지식 사이에도 이와 같은 차이가 있다. 시스템 설계 및 구축 전문가라면 이 책의 많은 기법을 이미 사용해봤을 것이다. 하지만 여기서는 무엇을 사용했는지 더 잘 알 수 있도록 용어와 개념을 사용해 설명하고 있다. 선언적 지식은 다른 개발자를 가르치는데 도움이 된다.


4.엔지니어링을 강조한다. 소프트웨어 시스템을 설계하고 구축하는 사람들은 일정, 자원 할당, 이해관계자 요구를 처리하는 등 많은 일을 해야 한다. 소프트웨어 아키텍처에 관한 많은 책에서 이미 소프트웨어 개발 프로세스와 조직 구조를 다뤘다.


5.실용적인 조언을 제공한다. 이책은 아키텍처의 실용적인 활용 방법을 제공한다. 소프트웨어 아키텍처는 일종의 소프트웨어 설계다. 하지만 설계 결정은 아키텍처에 영향을 미치며 그 반대도 마찬가지다. 이책은 상위 아키텍처에서 하위 자료 구조 설계에 이르기까지 추상화를 위한 다양한 수준의 모델을 활용하는 접근 방법을 알려준다.


이 책에서 이야기하는 기본적인 내용은 대부분 개발자가 흔히 실무에서 겪는 경험을 기반으로 하기 때문에 개발을 하기전에 설계 문서를 너무 많이 작성 했거나 반대로 너무 적게 해서 고민 한적이 있을것이다. 어느 쪽이든 소프트웨어 개발이 왜 잘못되는지 않 수 있고, 이책에서 제공하는 해결책이 많은 도움이 될것이라 생각합니다.

 

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

	

 

 

#. 들어가기 전에

최근 우리 회사는 많은 변화를 겪고 있다.
기존의 조직 구성에서 벗어나 새로운 홀로 서기를 하고 있는데, IT조직도 예외는 아니다.
외부에서 새로운 조직장 들이 합류하면서 조직에 활기를 불어 넣고 있다.
(‘활기’라고 적고 ‘갈아 넣는다’는 표현이 적합하겠지만…)

우리 IT 조직에 한정지어 얘기를 풀어보자면, 
기술력이 뒷받침되어야 디지털 시대에 뒤쳐지지 않는다며 역량 강화를 강조하고 있다.
나 또한 최근 그러한 연유로 많은 기술서적을 읽고 인터넷 강의를 들으면서 다시금 공부를 하고 있다.

#. 구성

서론이 길었는데 이번에 읽게 된 ‘적정 소프트웨어 아키텍처’ 도 아키텍처링에 대한 혜안을 얻고자 선택한 도서 중 하나이다.
‘적정 소프트웨어 아키텍처’는 ‘리스크 주도 모델’이라는 기법을 중심으로 아키텍처 방법에 대해 설명하고 있다.

책의 서두에서 밝히고 있지만 이 도서의 주요 독자는 ‘실무 소프트웨어 개발자’ 이다.
사실 이 책은 하드커버지에 종이 질은 얇은 재질의 ‘대학교재’ 같은 느낌의 도서이다. 아무래도 아키텍처링 방법에 대해 논하는 책이므로 딱딱한 내용이 주를 이룬다.
그리고 기본적으로 OOP, UML, 디자인패턴에 대한 이해가 필요하다고 한다.

책은 크게 1부와 2부로 구성되어 있다.
1부 : 리스크 주도 소프트웨어 아키텍처
2부 : 아키텍처 모델링

 

 


책을 읽다보면 설계5원칙 SOLID의 내용이 간간히 나온다. 
사실 내 수준에서는 책의 내용이 딱딱하다보니 저런 아는 단어가 나오면 상당히 반갑더라.

전체적으로 책의 내용이 쉽게 읽히지는 않는다.
번역이 안좋다기보다는 지식 위주의 책이다보니 한 번에 이해되지 않는 것이 더 큰 것 같다.
그렇지만 모든 기술 서적이 그렇듯 여러 번 읽어야 그제서야 개념이 잡히고 예제 코드를 작성해봐야 어느 정도 이해가 되지 않나 싶다.

 

< 총평 >

1. 대학원서 읽는 것을 좋아한다!

2. 새로운 방법론에 대해 알기를 좋아한다!

그렇다면 이 책을 읽어 보자!

 

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

 

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

 

 

 

이번 도서 후기는 아키텍처를 설계하는 데에 있어서 리스크를 줄이는 방법을 배울 수 있는 책이다.

개발자로 일을 하면서 프로젝트를 처음부터 시작하는 단계에서 부터 참여하든 그렇지 않든 어떻게 하면 예상치 못한 장애 상황을 줄일 수 있을지, 이전의 경험이 설계 단계에서 많은 영향을 준다.

소프트웨어 아키텍처는 시스템의 뼈대 역할을 하고, 품질과 기능, 여러 상황을 통해 시스템의 영향을 준다.

이러한 소프트웨어 아키텍처는 어떠한 상황에서의 해결책이 적거나 리스크가 높은 경우, 여러 조건을 충족해야할 때가 중요한데, 이 책은 아키텍처 무관 설계, 아키텍처 집중 설계, 아키텍처 상향 설계 방법을 소개한다.

설계 방법과 아키텍처의 범위를 결정할 때 리스크를 기반으로 수행하는데, 리스크를 줄이는 과정을 3단계의 과정을 반복한다.

 

첫번째는 리스크를 식별하고 우선순위를 지정한다.

두번째는 적용할 기법을 선택하고 적용한다.

세번째는 리스크가 감소되었는 지에 대한 평가를 한다.

 

이러한 과정을 통해 아키텍처를 설계하여 문제를 해결하고, 제약 사항을 추가하며, 리스크에 집중할 수 있게 도와준다.

 

​이후 아키텍처의 개념 모델에 대해 다룬다.

아키텍처의 개념 모델은 도메인 모델, 디자인 모델, 코드 모델이 있다.

 

도메인 모델은 현실의 실제 상황에 해당하는 모델을 의미한다.

디자인 모델은 만들고 있는 소프트웨어의 설계를 의미한다.

코드 모델은 구현한 소스 코드에 해당한다.

 

이러한 모델은 컴포넌트와 모듈을 사용하여 작동방식을 숨겨서 여러 난제를 해결할 수 있도록 해준다.

이 과정에서 캡슐화된 컴포넌트와 모델은 자유롭게 변경할 수 있도록 도와준다.

 

이러한 아키텍처의 설계하는 과정의 기법을 통해서 우리가 겪을 수 있는 여러 문제를 해결하는 방법과 문제를 줄이는 방법을 배울 수 있다.

이번 도서를 통해 어떻게하면 유연하고 리스크를 줄일 수 있는 아키텍처를 설계할 수 있는지 배울 수 있었다.

경험 뿐만 아니라 이러한 지식을 기반으로 좀 더 나은 시스템을 구축할 수 있는데 도움이 되었다.

나와 같이 아키텍처를 설계하고 어떻게 해결하는 지, 여러 관점을 통해 접근하는 방법을 배우고 싶은 분들에게 추천한다.

적정

원서의 제목은 Just enough software architecture 이다. Just enough가 한글로 “적정”인데 제목만 보고 여기서 말하는 적정의 수준은 어느 정도가 되야하는지 궁금했다.  왜냐면 과유불급이라고 넘침은 모자람만 못하고, 또 모자라면 그것도 문제이기 때문이다.

결론적으로 적정의 수준은 공학적 이익과 비용의 균형을 맞추는 것을 말한다.

 

소프트웨어 아키텍처

소프트웨어 아키텍처는 왜 필요할까?

  • 시스템의 복잡성이 점점 더 증가되어 
  • 인간이 이해하고 기억하기 쉽게 문제를 작게 만드는 것(분할, 지식, 추상화)이 필요하기 때문이다.

 

리스크 주도 접근법

이 책은 소프트웨어 아키텍처의 접근을 리스크 관리 측면에서 즉 리스크를 줄이는 기법을 사용해서 접근을 한다.

리스크 주도 모델은 개발자가 최소한의 아키텍처 기술을 적용하여 가장 시급한 리스크를 줄이도록 한다.

그리고 다음과 같은 3단계를 거치면서 반복하는 과정이라고 한다.

  1. 리스크 식별 및 우선 순위를 지정하고
  2. 적용할 기법을  선택  및 적용하고
  3. 리스크가 감소 되었는지 평가 한다.

 

리스크

책에서 이야기 하는 리스크의 정의는 "인지한 실패 확률 x 인지된 영향"이라고 정의 한다. 

즉, 인지되지 않은 실패 확률은 리스크로 판단할 수 없고, 실패로 인한 영향도 파악할 수 없다면 리스크는 확인할 수 없다는 것이다.

여기서 리스크는 “소프트웨어 엔지니어링 리스크” 와 “프로젝트 관리 리스크”로 나눈다. 이 말을 기술적인 리스크와 관리적인 리스크로 볼 수 있는데, 일반적으로 엔지니어링 리스크는 제품의 분석, 설계 및 구현과 관련된 사항이고, 프로젝트 관리 리스크는 일정, 작업 순서, 팀 규모 등과 관련된 것들이다. 

 

 

리스크의 식별

요구사항을 가지고 시작할 있고, 개발하는 소프트웨어의 도메인에 따라 주로 발생하는 원형적 리스크(prototypical risk) 있다

기법

아키텍처 설계에 들이는 노력은 실패 리스크에 상응해야 한다.

이는 기법을 지나치게 적용하거나 너무 적게 적용하지 않는다는 뜻이다. 즉 효율성에 주목을 해야 한다.

 

 

애자일 프로세스에 적용

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


홈페이지든 프로그램이든 무언가를 개발하기 전에는 무엇을 어떻게 만들지를 고민하고

그에따라 정책정의, 기획설계부터 시작하는것이 일반적이다.

건축물을지을때 기초공사가 튼튼해야 건축물이 튼튼하게 지어지듯이, 무언가를 잘 만들기 위해서는 기초공사가 중요하다.

이 책은 소프트웨어 개발을 시작할 때 필요한 실용 가이드북으로써, 아키텍처를 설계할 때 도움이 될만한 내용들이 기술되어있다.

부제목이 리스크 주도 접근법인것 처럼 설계를 이렇게 해야한다라는것 보다는

'오답노트'처럼 실무자들이 개발하는 과정에서 일아난일들을 바탕으로 아키텍처 설계단계에서부터 이러한 상황을 고려한다면

수월한 개발을 할 수 있는 해결책을 제공해주고있다.

즉 리스크 관리 중심으로 아키텍처를 설계할 수 있도록 안내되어있다.

*주요내용

리스크 주도 아키텍처링 - 직면한 리스크에 따라 적정한 아키텍처 설계를 수행하는 방법

참여하는 아키텍처 - 아키텍트뿐 아니라 모든 소프트웨어 개발자를 위한 아키텍처

선언적 지식 - 기법을 적재적소에 사용하기 위한 개념과 용어

엔지니어링 강조 - 소프트웨어 개발의 기술적인 부분과 시스템 작동을 위한 엔지니어링

실용적인 활용 방법 - 상위 아키텍처부터 하위 자료 구조 설계까지 다양한 수준의 모델을 활용하는 접근 방법

* 대상독자

책 제목만 봐서는 개발에 경험이 많은 PL급인 사람이 읽어야할 것 같아보이지만

실제로 읽어보면 개발에 관심이있어 탄탄한 설계를 하고싶어하거나 프로젝트를 이끄는 PL뿐만아니라 PM이 읽어도

충분히 유익해보이는 책이라 생각된다.

책 내용중 개발언어들이 나오기는 하지만 하나의 소설책 읽듯이 읽을 수 있는 수준이라 생각되어 개발관련 학과를 졸업한 사람이라면

편하게 읽을 수 있는정도의 수준이라 생각된다.

이 책에서의 특징은

  1. 상황에 따른 소프트웨어 아키텍처 사용법이 정리되어있으며

  2. 자연스러운 흐름으로 이해하는 리스크 주도 도멜 개념과 적용 방법

  3. 다이어그램과 표를 통한 개념 모델 이해

  4. 다양한 아키텍처 스타일을 보여준다.

독자에게 전하는 말 중에 이런말이 있다.

소프트웨어 시스템 대부분은 초기에 설계를 완벽하게 해서 최종 제품으로 개발할 수 없습니다.

개발을 진행하면서 소프트웨어의 모습은 변하기 마련입니다.

저자의 다양한 경험을 바탕으로 고안한 리스크 주도 접근 방법은 우리가 지닌 큰 숙제에 도움이 되며

좋은 실무 교본으로 옆에 두고 찾아볼 만합니다.

적정 소프트웨어 아키텍어 옮긴이의 말 발췌

이중에서 "개발을 진행하면서 소프트웨어의 모습은 변하기 마련입니다." 이 말이 참 와닿았다.

분명 설계단계에서는 나름 잘 설계했다고 생각하며 개발을 진행했지만 완성단계에 다다르면서 미쳐 생각하지못했던 이슈사항이 생겨

이를 고치기엔 많은부분을 뜯어고쳐야하는 일이 종종 있었다.

이럴 때 마다 설계단계에서 왜 생각하지 못했을까.. 이 부분을 다르게 개발했으면 나중에 유지보수하기 쉬웠을텐데 하는 아쉬웠던적이

한두번이 아니었다.

이 책을 통해 탄탄한 아키텍처 설계를 할 수 있는 능력이 향상됐으면 한다.

결제하기
• 문화비 소득공제 가능
• 배송료 : 2,000원배송료란?

배송료 안내

  • 20,000원 이상 구매시 도서 배송 무료
  • 브론즈, 실버, 골드회원이 주문하신 경우 무료배송

무료배송 상품을 포함하여 주문하신 경우에는 구매금액에 관계없이 무료로 배송해 드립니다.

닫기

리뷰쓰기

닫기
* 도서명 :
적정 소프트웨어 아키텍처
* 제목 :
* 별점평가
* 내용 :

* 리뷰 작성시 유의사항

글이나 이미지/사진 저작권 등 다른 사람의 권리를 침해하거나 명예를 훼손하는 게시물은 이용약관 및 관련법률에 의해 제재를 받을 수 있습니다.

1. 특히 뉴스/언론사 기사를 전문 또는 부분적으로 '허락없이' 갖고 와서는 안됩니다 (출처를 밝히는 경우에도 안됨).
2. 저작권자의 허락을 받지 않은 콘텐츠의 무단 사용은 저작권자의 권리를 침해하는 행위로, 이에 대한 법적 책임을 지게 될 수 있습니다.

오탈자 등록

닫기
* 도서명 :
적정 소프트웨어 아키텍처
* 구분 :
* 상품 버전
종이책 PDF ePub
* 페이지 :
* 위치정보 :
* 내용 :

도서 인증

닫기
도서명*
적정 소프트웨어 아키텍처
구입처*
구입일*
부가기호*
부가기호 안내

* 온라인 또는 오프라인 서점에서 구입한 도서를 인증하면 마일리지 500점을 드립니다.

* 도서인증은 일 3권, 월 10권, 년 50권으로 제한되며 절판도서, eBook 등 일부 도서는 인증이 제한됩니다.

* 구입하지 않고, 허위로 도서 인증을 한 것으로 판단되면 웹사이트 이용이 제한될 수 있습니다.

닫기

해당 상품을 장바구니에 담았습니다.이미 장바구니에 추가된 상품입니다.
장바구니로 이동하시겠습니까?

자료실