이 책을 신청했을 때는, 흔히 `소프트웨어 공학` 과목에 등장하는 소프트웨어 아키텍처 패턴에 대한 내용이 나올 것이라 기대했다.

하지만, 이 책은 비단 software 뿐만 아니라 조금 더 상위 시스템을 구측하고 설계하는데 필요한 지식들이 담겨있었다.

흔히들 개발자의 명서라고 말하는 `클린 코드`, `클린 아키텍처`와 결을 나란히 한다고 생각한다. 개발자가 흔히 겪을 수 없는 소프트웨어 시스템 아키텍처 설계에 대한 무수한 팁들과 모호한 개념에 대한 새로운 정의, 그리고 이해하기 쉬운 그림과 설명이 담겨 있기 때문이다.

크게 4가지 파트로 구성이 된다. 

솔직히 말하면, 책 내용이 어려웠다. 

왜냐.. 나는 아직 초보 개발자와 시니어 개발자의 사이에 있기 때문이다. 아직 큰 그림을 보고 설계하기엔 멀었다는 생각이 든다. 

훗날 시니어 개발자가 되어 나의 모듈을 이끄는 업무 리더가 된다면 이 책을 꼭 다시 펼쳐보겠다.

> `Part 1 기초`

업무를 하다보면, 트레이트오프 상황에 대한 많은 고민이 있을 것이다.

`아키텍처는 모든 게 다 트레이드오프 입니다.` 라는 구절이 있다. "

"A를 포기하고 B를 선택해야하는 것인가..."

"A를 선택했다면 그 이유는?"

우리는 항상 상황을 분석하고 최적의 선택을 해야한다. 소프트웨어 아키텍처가 그것이다. 그 시스템의 트레이드오프를 분석하고 주어진 상황에서 가장 좋은 선택을 해야한다.

이런 좋은 선택을 하기위한 마인드와 구체적인 상황에 대한 설명이 주어진다. 

또한 아키텍처의 특성(~~성 으로 끝나는 성질)을 구분짓고 정의하고 예시를 들며 다양한 방면을 고려할 수 있게 도와준다.

> `Part 2  아키텍처 스타일`

아키텍처 패턴에 대한 내용이다. 패턴을 카테고라이징하여 장/단점을 구분하고 각각의 토폴로지가 뭔지, 서비스 설계도는 어떤건지를 설명한다.

레이어드 아키텍처 스타일, 파이프라인 아키텍처 스타일, 마이크로커널 아키텍처 스타일, 서비스/이벤트/공간/오케스트레이션 기반 아키텍처 스타일에 대해서 배울 수 있다. 

> `Part 3  테크닉과 소프트스킬`

해당 장은 아키텍트답게 사고하는 방법과 팀원들을 이끄는 소프트한 스킬에대한 내용이 담겨있다. 

뭔가 외국 기업에서 진행되는 아키텍처 결정 레코드(ADR)이 어떻게 진행되는지 엿볼 수 있었다. 

아무래도 대기업에서는 소프트웨어 시스템이 다양하고 복잡하고 규모가 크기때문에 이런 레코드를 통해 관리를 하는구나... 생각해봤다. 

해당 장은 IT 도서를 읽는 것보단 자기계발 서적을 읽는 듯 했다.

선배 개발자가 남긴 조언이 많기 때문에 재밌게 읽을 수 있었다.

> 총평

 경력 10년 이상의 실무자가 읽으면, 도움이 가장 많이 될 것 같다.

 풋내기 개발자인 나는 이해할 수 없었지만, 업무를 오래 해본 분들이라면 충분히 공감할 것이라고 생각한다. 훌륭한 아키텍트가 되기 위한 필수 도서라고 생각하며 책을 읽으면서 더 열심히 해야겠다는 다짐을 하게 된다.  

<이 리뷰는 한빛미디어 '나는 리뷰어다'로 부터 책을 지원 받아 작성되었습니다>

이 책을 읽기 전에는 소프트웨어 설계(Design)하는 일과 아키텍트가 하는 일이 비슷하다고 생각했다. 그런데 아키텍트는 디테일한 소프트웨어 설계는 하지 않을 뿐만 아니라 더 다양한 역할을 수행하고 있었다.

• 아키텍처 결정을 내린다.
• 아키텍처를 지속적으로 분석한다.
• 최신 트렌드를 계속 따라간다
• 아키텍처 결정의 컴플라이언스를 보장한다
• 다양한 기술과 경험에 노출된다
• 비즈니스 도메인 지식을 보유한다
• 대인 관계 기술이 뛰어나다
• 정치를 이해하고 처세를 잘한다

챕터 1에서는 소프트웨어 아키텍처를 구성하는 기본 요소와 아키텍처를 분석하는 기법에 대해서 설명한다. 부제에서 말했듯이 ‘엔지니어링 접근 방식으로’ 소프트웨어의 특성을 수치화하는 시도들에 대해서 알려준다.

챕터 2에서는 여러가지 아키텍처 스타일을 소개하고 각 스타일 별 아키텍처 특성을 별점으로 제시하고 있다. 트레이드 오프를 고려하고 아키텍처 결정에 도움을 줄 유익한 내용들로 가득하다.

챕터 3에서는 아키텍트에 필요한 소프트 스킬에 대해 설명한다.

책을 읽으면서 아키텍처 결정에 있어 어떤 정답이 있을 거라는 기대를 좀 했었다. 하지만 아키텍처 결정은 정답이 있는 문제가 아니라, 컨텍스트를 고려하여 각 아키텍처 스타일이 가진 트레이드오프를 고려하여 가장 좋은 스타일을 선택하는 것임을 알게 됐다. 또 그 결정을 개발자들에게 정당화시켜야 한다. 역자의 말처럼 소프트웨어 아키텍처의 세계를 컴팩트한 분량으로 담아낸 책이기에 개발자, 아키텍트 지망자들에게 추천한다.

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

이 책은 소프트웨어 아키텍트를 목표로 하거나 현재 직책이 CTO, 개발팀장, PM, 개발자 모두에게 추천하고 싶은 책이다. 

이 책을 읽는 것만으로 소프트웨어 아키텍트가 될 수는 없지만, 향후 훌륭한 소프트웨어 아키텍트로 가는 방향을 훌륭히 제시하고 있다. 

책 뒤로 가면 갈수록 더욱더 흥미있게 있을 수 있었던 몇 안 되는 책이었던 것 같다.

책의 구성은 기초, 아키텍처 스타일, 테크닉과 소프트 스킬로 나뉘며, 전체 챕터가 서론을 포함 총 24개나 되어서 읽는데 힘들겠다 싶었는데, 각 챕터가 길지 않고, 내용도 아주 어렵지 않다. 모두 이해하면 좋겠지만, 

나중에 필요하면 다시 보면 되니까 이해가 되지 않으면 않는 데로 넘어가도록 하자. 

언젠가는 다시 보게 될 것이므로, 그때 이해하면 될 것이다.

PART I 기초편 에서는 아키텍처와 아키텍트의 개념과 특성을 설명하고 있으며, 사례 연구를 통해 

실제 현장에서 어떻게 아키텍처가 사용되고 있는지 설명하고 있다.  

PART II 아키텍처 스타일에서는 주로 사용되고 있는 8개의 아키텍처 스타일을 

비교 분석하며 아키텍처 선정 방법과 고려 사항 설명한다. 마지막 PART III에서는 아키텍처 선정 이후 리스크 관리와 

도식화 및 프리젠테이션, 프로젝트에서 아키텍트의 역할과 향후 더 나은 아키텍트로 가야 할 방향을 제시하고 있다.

현재 많은 프로젝트가 클라우드 환경이 도입되면서 레이어드 아키텍처 스타일에서 마이크로서비스 아키텍처 스타일로 진화(?)하고 있지만, 이 또한 하나의 트렌드라고 생각하는데, 

이 책을 통해서 무지성이 아닌 각각의 아키텍처 스타일을 비교 분석하여 설계하는 것이 바람직할 것이다. 

이 책이 도움을 줄 것이다.

아키텍처 관련 책이다 보니, 이 책에서는 다양한 주체가 많이 소개되므로 개인적으로 기술의 폭이 넓어져 좋았으며, 

특히 9장에서 설계시 심심찮게 발생하는 오류 8가지 부분이 인상 깊었다. 22장 개발팀을 효율적으로, 23장 협상과 리더십 스킬에서는 아키텍처의 덕목과 다양한 주제에 대한 팁들을 설명하는데, 많이 반성도 하면서, 

바로 적용할 내용이 있어서 특히 재미있게 읽은 챕터들이었다.

마지막으로 아키텍트는 항상 배우고, 항상 연습하는 자세로 끊임없이 아키텍처를 설계해야 하는 직업이라는데, 

100% 공감하고 이 책에 신뢰를 느낄 수 있는 부분이라 좋았다.

어떤 사람이 갖고 있는 지식은 '내가 알고 있는 것', '내가 모른다는 사실을 아는 것', '내가 모른다는 사실조차 모르는 것' 으로 분류할 수 있는데, 그 중 가장 큰 비중은 그 존재조차 모르는 '내가 모른다는 사실조차 모르는 것' 이다.

 

2장 아키텍쳐 사고, 55 page

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

이번에 한빛미디어의 체험단 활동으로 소프트웨어 아키텍처 101을 받게 되었다.

잠시 미국에 있는 대학교의 대학원에서 공부할 때에 계절학기 프로젝트로 아키텍처 설계 수업을 들었을 때에는 이걸 왜 듣지 하는 생각이 들었었다. 한국에 귀국해서 대학원 학기가 붕 뜨는 바람에 인턴 활동을 시작하게 되었고, 인턴 활동 중에 협업을 접하게 되며 아키텍처 설계의 중요성에 대해 생각하게 되었다.

기본적으로 개발 프로세스의 규모가 거대해져가면서 팀으로 개발하게 되는 것이 필수가 되었고, 아키텍처 설계는 그 개발의 결과물에 대한 사전 설계와 같다고 생각하게 되었다. 비유하자면 건물을 짓는데에 건물의 설계를 하고 짓는지 아니면, 이 건물을 이렇게 생겼고, 이런 기능을 해야하니 대강 이렇게 지으면 되겠지? 1층부터 지어보자 의 차이에서 아키텍처 설계는 그 전자에 해당할 것이다. 

그런면에서 이 책은 상당히 재미있었다. 일반적으로 101이라함은 A to Z, 모든 것을 담고 있다. 라는 뜻으로 쓰이곤 한다. 소프트웨어 아키텍처 101이란 제목 답게 상당히 풍부한 내용들을 짧고 굵게 담고 있다. 이 글을 쓰고 있는 중에도 아키텍트는 사실 잘은 모른다. 더더욱이 연구 분야에 몸담고 있기 때문에 잠깐 배워본 경험이 전부이다. 하지만, 소프트웨어 아키텍처 수업을 들었을 즈음에 이 책을 알았다면 많은 도움이 되었겠다는 생각이 들 정도로 다양한 내용과 그 정수를 잘 담고 있는 책이라고 생각한다. 

책에서 말하는 SA의 핵심적 요구사항 8가지는 아래와 같다.

그리고 책에서는 이 8가지에 대해서 각 챕터별로 설명하고 있다.

- 아키텍처 결정을 내린다.

어떤 기술을 선택할지 가이드를 내려준다. 결정하는 사람이 아니다.

- 아키텍처를 지속적으로 분석한다.

아키텍처와 현재 기술 환경을 분석하고 개선하기 위해 해결 방안을 제시한다. 대부분의 아키텍처 구조는 쇠락하기 때문에 설계를 변경하게 된다. 

- 최신 트렌드를 계속 유지한다.

최신 기술과 업계 트렌드를 따라가야 된다. 이것과 관련해서 24장을 주의깊게 읽어봤는데(왜냐면 이쪽은 특히 중요한 분야라고 해서 뭐가 다른가 궁금해서) '20분 규칙'이 있다고 한다. 

20분 정도 모르는 전문용어를 배우고 '모른다는 사실을 알고있는 것들'로 표시한다. 그런데 시간이 중요하다. 저녁이 아니라 아침 출근 후 커피 마신 뒤(여기까지 용납) 이메일 확인 전 20분에 하라고 한다. SA 대가가 알려주는 비법이니 비교적 확실한 트렌드 습득 방법이겠다. 생각해보니 아침에 정보성 메일을 읽을 때나 들을 때가 가장 기억력이 높았다. 10분도 아닌 20분이면 출근시간에 한번 해볼만하지 않나 생각한다.

- 아키텍처 결정의 컴플라이언스를 보장한다.

- 다양한 기술과 경험에 노출된다.

기술의 깊이보다는 폭에 초점을 두라. 테크 제너럴리스트의 관점을 갖는 것도 좋겠다. 

- 비즈니스 도메인 지식을 보유한다.

'IT회사에 간 문과 여자' 라는 책에서도 비슷한 얘기를 마지막 부분에서 본 적이 있다. 회계나 감사에 대한 지식이 있다면 IT쪽이라도 도움이 많이 된다라는 얘기였다. 일정 부분 동의하는 바다. 결국 이 부분이 말하는 건 IT서비스업계가 만드는 건 product이기 때문이 아닐까. 어떤 것을 '만드는' 게 코딩한다라는 동사와 유사하게 엮을 수 있다고 본다. 

- 대인 관계 기술이 뛰어나다.

이런 소프트웨어 스킬은 앞으로 점점 더 중요해질 것이다.

- 정치를 이해하고 처세를 잘한다.

어느 정도는 협상하는 것이 필요하다고 생각한다. 가끔은 SA는 결과적으로 이득이 될 결정을 반발에도 '무릅쓰고' 해야 할 필요도 있다. 이때 이 반발의 강도를 조금씩 줄일 수 있는 방법이 협상이다. 

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

		
		

			SW공부를 하고 있는 요즈음, 이런저런 알고리즘들 뿐만 아니라 SW 설계를 담당하는 아키텍트에 대한 내용이 궁금해서 리뷰하게 되었다. 
		
		

			막상 책을 받으니... 대학 전공서적으로 해도 될만큼 두껍고 내용도 상세하였다. 챕터가 무려 24개나...
		
		

			이 책은 한달봐서는 제대로 리뷰를 할 수 없을 것 같았다. 그리고 실제로 약 3주간 살펴보았지만 진도가 많이 나가지도 못했다. 
		
		

			하지만 전체적으로 훑어보면서 내가 아는 것과 모르는 것들의 키워드들을 정리해볼 수 있었다. 
		
		

			이 책은 사전처럼 곁에 두고 아키텍트 학습을 준비하는 동안 꺼내보면서 학습할때 유용할 것 같다. 
		
		
 
		
 
		

			- "아키텍처는 중요한 것들에 관한 것이다. 그게 무엇이든 말이다. (Ralph Johnson)"
		
		
 
		
 
		
			

				(도널드 럼즈펠드, 전 미국 국방부 장관의 말 중)
			
			

				'알려진 기지의 것들(known knowns)' , 즉 우리가 알고 있다는 사실을 알고 있는 것들입니다. 
			
			

				그리고 '알려진 미지의 것들(known unknowns)', 즉 우리가 모르는 뭔가가 있다는 사실을 알고 있는 것들입니다. 
			
			

				하지만 여기서 하나 더, '알려지지 않은 미지의 것들(unknown unknowns)' 도 있습니다. 
			
			

				우리가 모른다는 사실조차 알지 못하는 것들이죠.
			
			
 
			

				  : 이 말이 참 인상깊었다. 내가 아는 것, 모르는 것만 생각해보았는데, 모른다는 것 조차도 모르는 것들이 있다는 것에 대해서는 깊이 생각해보지 못했던 것 같다.
			
			

				이 책에서는 '내가 알고 있는 것'을 [기술 깊이]로 '내가 모른다는 사실을 아는 것' 까지를 [기술 폭]으로 설명하였다. 아키텍트에게는 깊이보다 폭이 더 중요하다는 설명과 함께.
			
			
 
			

				(pg 47) "소프트웨어 아키텍처의 모든 것은 다 트레이드오프다." (소프트웨어 아키텍처 제1법칙)
			
			

				(pg 48) " '어떻게'보다 '왜'가 더 중요하다. " (소프트웨어 아키텍처 제 2법칙)
			
			
 
			
				

					(20분 규칙) (pg 438~439)
				
				

					- 아키텍트로서 커리어를 유지하기 위해 새로운 것을 배우거나 특정 주제를 깊이 파고드는 시간을 매일 최소 20분은 할애하라는 규칙
				
				

					- 20분 규칙은 하루가 시작될 때 가장 먼저 실천하는 게 좋다
				
				

					 
				
				

					이번 리뷰를 하며 모르는게 여전히 너무 많다라는 것을 다시금 깨닫게 되었다. 
				
				

					가야할 길이 멀고 많이 남은 것 같긴 하지만 가늠하기 어려울만큼 많이 남은 것 같아서 아마도 평생을 배우다 죽을 것 같다는 생각이 들기도 했다. 
				
				

					다만 그 과정에서 크고 작은 성취와 성장을 누리는 개발자가 되어보아야겠다라는 생각을 할 수 있는 귀중한 시간이었다.
				
				

					 
				
				

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

		

	

엔지니어링 접근 방식을 배우는 소프트웨어 아키텍처 기초

Fundamentals of Software Architecture - 소프트웨어 아키텍처 101

소프트웨어 아키텍트는 전문가로 간주되는 소프트웨어 개발자로서, 고수준의 설계를 결정하고 소프트웨어 코딩 표준, 도구, 플랫폼 등의 기슬 표준을 지시한다.(출처: 위키백과)

현직 개발자로 일하면서 항상 최종 목표는 리드 소프트웨어 아키텍트 였습니다. 그러기 위해선 소프트웨어 아키텍트가 먼저 되어야 했지만

소프트웨어 아키텍트라는게 명확히 정의된 일이 아니다 보니 준비하는게 생각보다 쉽지 않았습니다.

그러던 차에, 이번 기회를 통해 "소프트웨어 아키텍쳐 101" 이라는 책을 접하게 되었고, 이전보다 조금 더 명확하게

소프트웨어 아키텍처에 대해 알게 되었습니다.

이 책은 이름에서 볼 수 있듯, 소프트웨어 아키텍처에 대한 입문서라고 할 수 있습니다.

소프트웨어 아키텍처에 대한 정의부터 시작하여, 여러가지 다양한 소프트웨어 아키텍처 스타일,

소프트웨어 아키텍트가 가져야 할 사고 방식, 소프트웨어 아키텍트의 커리어 패스 까지 

소프트웨어 아키텍트의 전반적인 분야에 대한 설명을 잘 해주고 있습니다.

이 책에서 가장 인상깊게 읽었던 부분은 바로 소프트 스킬 관련된 파트였습니다.

물론 소프트웨어 아키텍처 관련 테크니컬한 부분 또한 여러가지를 배울 수 있어서 좋았지만,

기술적인 부분 이외에 개발자와 소프트웨어 아키텍트간의 사이에 관한 내용, 개발팀을 이끄는 내용, 소프트웨어 설계할 때 고려해야할 사항등 다양한 소프트 스킬 관련내용도 흥미롭게 읽었습니다.

개발자분들 중 소프트웨어 아키텍트를 꿈꾸시는 분께 꼭 추천드리고 싶은 책입니다.

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

[나는리뷰어다] 엔지니어링 접근 방식으로 배우는 소프트웨어 아키텍처 기초, 소프트웨어 아키텍처 101

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

글 / 사진 : 서원준 (news@toktoknews.com) 

상반기를 마무리 짓고 하반기로 접어들 시점이 다가온다. 본격적으로 장마가 시작되는 시점이기도 하다. 코로나 19는 여름철을 맞이하여 어느 정도 잠잠해졌다고는 하지만 올 가을에 다시 한번 팬데믹이 찾아올 가능성이 있다. 이럴 때일수록 개인 방역수칙을 철저하게 지켜서 만약의 사태에 대비하는 자세가 필요하다고 하겠다. 

상반기를 돌이켜보면 5월 말부터 6월 사이에 가족 중 한 명이 눈수술을 받은 탓에 서울국제도서전에 가지 못하게 되었다. 그 트라우마에서 벗어나기 위해서 필자로서는 체험단과 서평단을 잇따라 신청해야 했다. 서평(체험기)을 등록하는 시점이 많이 늦어진 이유는, 6월에 집중적으로 신청한 체험단, 서평단 결과 및 배송을 끝까지 확인하느라 늦어진 것이다. 

필자가 원래 정해진 책만 그 틀 안에서 달마다 서평을 진행해 왔다. 이번에 진행되었던 소프트웨어 아키텍처 101 역시 마찬가지. 그런데 필자가 도서 전시회에 불참을 하게 된 것이었다. 필자로서는 대책을 마련하지 않으면 입지를 잃을 수 있겠다 싶어서 다른 서평단을 노리게 되었고 거기 참가를 마구잡이로 했다가 책만 잔뜩 오게 된 것이다. 이번 “나는리뷰어다” 는 몇 페이지 읽지 않은 채로 인터넷에 등록하게 된 것이다. 

사실 소프트웨어의 제작원리를 알기 위해서 반드시 읽어봐야 하는 책이 “소프트웨어 아키텍처 101” 이다. 이 책은 PC나 스마트폰의 어플이 어떻게, 어떤 방법으로 제작되는지를 알 수 있는데 특히 수많은 아키텍처의 결정을 내리는 데 있어서 기술적인 근간이 되는 아키텍처 패턴부터 설명하고 있다. 이것만 보더라도 이 책이 지닌 가치를 알 수 있다.

특히 이 책은 소프트웨어 아키텍처의 기초를 튼튼하게 한 상태에서 컴포넌트, 소프트스킬 등을 배울 수 있다는 점이 돋보인다. 이 책을 보면 어려운 용어들이 등장하지만 인내심을 가지면 술술 읽힌다는 점이 특징이기도 하다. 

소프트웨어 아키텍처 101 서평을 마치면서 

소프트웨어 아키텍처는 스마트폰 앱과 PC 앱을 설계하고 만드는 것에 있어서는 꼭 필요하다 하겠다. 이번에 다룬 소프트웨어 아키텍처 101 책은 그런 의미에서 정말 중요하다고 하겠다. 필자로서는 다른 서평단에 신경쓰다보니 기본적인 것을 놓쳤다는 생각이 든다. 향후에는 널리 사용되면서도 기본적인 내용을 다룬 도서를 택하여 “나는 리뷰어다” 를 진행할 것을 다짐한다.

소프트웨어 아키텍처는 이제 갓 4년차를 향해 가는 저로써는 난해한 분야입니다.

실제로 마땅히 공부하거나 경험해보기 어려운 분야이기도 합니다. 

책에서도 말하길 숙련된 아키텍터는 일평생 6번 정도 큰 프로젝트를 경험해본다고 합니다.

숙련된 아텍터도 6명 경험하는데, 프론트엔트 개발자인 저에게 역시나 난해한 분야이입니다.

하지만 어느순간 단순한 개발뿐만 아니라 아키텍쳐, 즉 구조에 대해 고민을 해야만 하고, 또 해야할 위치와 시기가 오게 됩니다.

그때를 대비하여 미리미리 준비한다는 마음가짐으로 책을 읽었습니다.

일단 책은 어렵습니다. 고오급 개발자는 되야 가볍게 지하철에서 읽을만한 수준이지 않을까 감히 판단해봅니다.

저같은 주니어는 카페에서 각잡고 읽어야합니다. 그런대도 이해가 한번에 되지 않습니다만,

읽다보면 과거의 추억(추억이라 말하고 삽질 내지 트롤짓)이 떠오르면서 아 이떄는 이런 구조와 설계 그리고 스타일을 가지고 했으면 어떨까 라는 자기 반성을 하게됩니다.

특히나 프론트엔드의 경우 이렇다할 디자인패턴이 없습니다.

상대적으로 빠르게 바뀌고 이제서야 관심을 가지게된 분야인지라 많은 개발자 형누님들이 드높은 지식과 폭넓은 경험을 바탕으로 좋은 디자인패턴을 만들어가는 과도기가 아닐까 생각하고 있습니다.

그런만큼 다양한 글을 접하게 되면 디자인패턴, 설계원칙들이 쏟아져오는 과도기 상황에 근본으로 돌아가 아키텍처에 대한 기본지식을 가지고 있으면 좋지 않을까 생각합니다.

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



# 요약

'소프트웨어 아키텍트'에 필요한 능력을 파악하는데 도움을 주는 책

# 장점

소프트웨어 아키텍트로써 경력을 쌓아온 저자들이 전하는 이야기

소프트웨어 아키텍트가 어떤 일을 한다고 명확히 표현하기는 어렵지만, 우리가 잘못 생각했던 것들에 대해서 바로잡게 해줌

아키텍처 패턴, 컴포넌트, 소프트 스킬 등 현대에도 실제로 필요하고 적용할 수 있는 것들을 배울 수 있음

실무적인 예시들로 설명을 하고 있어서, 비록 추상적인 개념들이긴 하지만 쉽게 이해할 수 있었음

---

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



최근 몇년간 서비스 구현을 많이 했었습니다. 서비스 유형이 새로운 경우는 새로 설계해야 했었기에 뭐가 더 나은 선택인가에 대해서 고민하는 시간이 다소 소요됬었습니다. 이런 경우에 이 책을 먼저 봤었다면 상당히 도움이 됬을텐데한 책이 이번에 읽은 소프트웨어 아키텍처 101입니다. 이 책은 아키텍처라는 것은 어떤 것인가부터 시작하여 설계할 때 필요한 사고력과 여러가지 아키텍처 스타일을 설명합니다. 특히 어떤 아키텍처가 더욱 합리적인가를 굉장히 많이 다루는데 내가 이 책을 읽고 일을 했으면 시간을 덜 들였을 것 같다는 생각이 듭니다. 책의 서문에는 '이 책을 읽는다고 하룻밤 사이에 소프트웨어 아키텍트가 되는 것은 아닙니다.'라는 문구가 있습니다. 소프트웨어 아키텍처에 대해서 고민을 해본 사람에게는 당연한 말이겠지만 한편으로는 시스템 설계자가 되기 위한 지식과 경험을 쌓기 위해서는 꾸준한 노력과 시간 투자가 필요하다는 내용이기에 앞으로도 더 정진해야 한다는 생각을 다시 하게된 책입니다. 설계에 관심있다면 꼭 읽어보는 것을 추천합니다.

이 책을 선택하고 책장을 펼치기 전까지도 사실 "아키텍트"에 대해서는 관심이 없었다. "소프트웨어 아키텍처"라는 주제에 관심을 두면서도, 아키텍처를 결정하는 사람이라고 할 수 있는 "아키텍트"에 대해서는 관심이 없었다는게 지금와서 생각해보면 좀 이상한 것도 같다. 그러고 나서 또 가만히 생각해보면 내 주위에 자신을 아키텍트라고 말하는 사람도 없었던 것은 사실이다.

내가 기대했던 책의 내용은 소프트웨어 아키텍처에 대한 소개와 구현에 대한 내용이라고 짐작하고 있었다. 그런데 이 책은 아키텍처를 결정해야하는 "중요한" 역할의 아키텍트에 대해 먼저 이야기를 풀어나간다. 단순히 아키텍처의 특징은 무엇이고 장단점은 무엇이다를 설명하는게 아니라, 아키텍트의 입장에서 아키텍처를 결정하기 위해 어떤 것들에 집중해야하는지를 시작으로 이야기를 풀어나간다. 

앞서 얘기했지만, 적지않은 개발경력에도 (물론 큰물에서 아직 놀아보지 못해봐서 그럴 수도 있지만) 아직 명함에 "아키텍트" 라고 써있거나, 스스로를 아키텍트라고 소개하는 사람을 만나보지 못했다. 그렇다면 내가 지금까지 진행했던 프로젝트들의 아키텍처는 "누가" 결정한 것일까? 대부분이 아시겠지만, 보통은 경험이 많은 시니어 개발자가 보통은 결정할 것이다. 그리고 더 아이러니는 프로젝트를 여럿 진행하면서도 우리 프로젝트의 아키텍처는 "이것"으로 결정했다 거나 하는 얘기도 들어보진 못했다. 그만큼 주먹구구식의 프로젝트 였을 수도 있고, 암묵적인 표준이라고 할만한 아키텍처를 컨벤션처럼 받아들이고 있었는지도 모른다. 아마 이것이 이책에서도 소개하는 모놀리식한 레이어드 아키텍처 스타일 이었는지도 모르겠다. 이런만큼 이 책은 내게 특별하게 다가왔다. 

이 책은 크게 세 파트로 나눠져있다. 첫 파트인 '기초'에서는 아키텍처의 특성에 대해 상세하게 다룬다. 사실 이 부분에서 그리 쉽게 읽히지만은 않았다. 오히리 두번째 파트의 아키텍처 스타일에 대한 내용은 조금 더 구체적이고 기술적인 내용이라 더 쉽게 읽혔던 것 같다. 그 이유는 아마도 생소한 단어들 때문이 아닌가 싶다. 생소하지 않더라도 명확한 의미보다는 뭔가 조금 추상적이고 개념적인 뜻으로 다가오는 단어들이 중간 중간 끼어있다보니 한번에 술술 읽히기 보다는 컴퓨터가 옆에 있으면 검색을 한번 해본다거나 하는 인터럽트가 발생하는 경우가 좀 있었다. 그렇다고 너무 어렵다거나 이해를 전혀 못할만한 내용은 아니니 겁을 먹을 필요까진 없을 것 같다.

두번째 파트에서는 개인적으로 가장 궁금했던 각 아키텍처 스타일들에 대해 설명하고 있다. 물론 다른 책들을 통해서 이해하고 있던 내용도 있었지만, 처음 들어보거나 이걸 이렇게 따로 분류를 하기도 하는구나 싶은 내용도 있었다. 그리고 결국 요즘 핫한 '마이크로서비스' 역시도 아무것도 없는 상황에서 마법처럼 등장한게 아니라는 것이었다. 그리고 이 모든것의 핵심은 "트레이드 오프" 라는 것. 절대적인 해결책이 있는 것이 아닌 각 프로젝트의 요구사항에 따라 결정을 해야한다는 것이다. 그래서 각 스타일별로 특징과 장단점 등을 설명하고 "아키텍처 특성 등급표" 라는 것을 보여준다. 단순히 어떤 아키텍처 스타일이 더 좋고 나쁜게 아니라 앞에서 설명한 아키텍처 특성들 별로 별점을 통해 평가를 하고 있다. 예를 들어 "확장성"은 별5개 만점이지만 "단순성"은 별1개라거나... 또한 각 스타일별로 그림을 통해서 아키텍처의 구성도를 상세하게 보여주고 있어서 이해도를 높이는데 도움이 되었다.

그리고 마지막 파트인 "테크닉과 소프트 스킬"에서는 아키텍처와 관련있는 다양한 주제들을 다루고 있다. "도식화 및 프레젠테이션" 에서는 아키텍트로서 필요한 소프트 스킬이라고 할수 있는 아키텍처를 어떻게 도식화하고 프리젠테이션을 준비하면 좋은지를 설명하고, "협상과 리더십 스킬" 챕터를 통해 바람직한 리더가 될 수 있는 팁들을 담고있다. 마지막은 "커리어패스 개발" 이라는 주제로 아키텍트가 되기 위해 어떤 노력을 하면 좋은지에 대한 노하우를 제시한다. 책 전반적으로 이런 깨알같은 팁들이 등장하는데, 개인적으로 이런 내용들에 포스트잇을 더 많이 붙이게 되는 것 같았다.

아키텍트, 아키텍처라는 단어에 거부감을 가지거나 어려움을 가지는 사람들이 많다고 본다. 관련해서 등장하는 용어들도 딱딱한 것 같고. 그래서 이런 얘기를 주제로 토론을 하기가 쉽지 않은 것 같다. 이럴 때 구성원들이 이런 책을 통해 이해도를 높인다면, 현재 진행중이거나 앞으로의 프로젝트 개발에 많은 도움이 되리라 생각한다.

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





아직 다 읽진 못했다.

아키텍트가 어떤 생각과 어떤 마음을 가지고 설계를 해야 하는지 잘 얘기한다.
아직 책 초중반이라서 그런가 개발적인 내용보다는 위에서 말했던 내용이 좀 더 나오는 것 같다.
그래도 백엔드 개발자라면 서비스를 혼자 설계하고 개발하고 운영할 수 있는 정도는 되야한다고 생각하기 때문에 필요없는 내용은 아니기에 읽기 좋았다. 

기대하고 있는 부분은  여러 아키텍처 스타일에 대해서 얘기를 하고 있는 부분이 기대가 되나 아직 그 부분까지 나가지 못해서 추후 책 완독 후 해당 글에 남은 부분을 작성하려고 한다.

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

이 책은 크게 기초, 아키텍처 스타일, 테크닉과 소프트스킬의 세부분으로 나뉜다. 

1. 기초 

시스템 아키텍처는 '아키텍처 특성', '아키텍처 결정', '설계 원칙', '구조' 로 구성된다. 

구조 : 시스템이 구현된 아키텍처 스타일의 종류 (마이크로서비스, 레이어드, 마이크로 커널 등)

아키텍처 특성 : 시스템의 성공 조건 (시스템이 올바르게 동작하기 위해서 반드시 필요한 것들)

아키텍처 결정 : 시스템의 제약조건 (시스템 구축에 필요한 규칙들)

설계 원칙 : 가이드라인 (권장하는 방법에 관한 가이드)

신입 아키텍트 또는 개발자에서 아키텍트로 커리어를 전환하려고 하는 사람들을 위해   

위와 같이 소프트웨어 아키텍처가 무엇인지, 아키텍처 사고 등 기본과 용어, 개발자와 아키텍트의 차이를 설명하고 있다. 

아키텍처를 구성하고 있는 항목들을 하나하나 쉽게 설명해서 아키텍처 지식이 별로 없는 상태에서도 이해할 수 있었다.

2. 아키텍처 스타일

레이어드, 파이프라인, 마이크로 커널, 서비스 기반, 이벤트 기반, 공간 기반, 오케스트레이션 기반, 마이크로 서비스의 8가지 아키텍처 스타일들을 각각 왜, 언제 이 아키텍처를 사용해야 하는지, 아키텍처 스타일의 토폴로지를 그림을 통해서 설명한다.

또한 마지막 챕터에서는 적합한 아키텍처 스타일을 선택하긱 위한 몇가지 기준들과 사례를 보여준다.

3. 테크닉과 소프트스킬

아키텍트 결정 문서화, 아키텍트 리스크 분석, 리스크 스토밍, 도식화와 같이

아키텍처 결정 후 소통을 효율적으로 할 수 있도록 기록과 분석을 단계별 중요한 포인트들을 중심으로 설명하고 있다. 

효율적으로 개발팀을 이끌어 가기 위한 테크닉, 협상과 리더십 스킬, 커리어패스 개발등 실제 업무를 하면서 필요한 소프트 스킬을 담고 있다.

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

개인적인 난이도

전공을 하지 않았거나, 정처기를 공부하지 않은 사람이라면 조금 모르는 용어가 많이 있어 어려워 보일 수 있는 책.

하지만 전반적인 내용만 훑는다면 내용의 난이도가 그렇게 높지는 않은 것같다.

초보자는 전반적인 맥락을 훑는 느낌으로 보고 책이 맘에 들었다면 회독을 하는 것으로 책의 내용을 공부하는 것이 좋을 것 같다.

감상

막연하게 아키텍처에 대한 이야기는 많이 들어봤지만, 구글링을 해도 정확한 명칭을 이해하기는 어려웠었다.

그랬다보니 직무에 대한 이해도 뜬구름잡기처럼 잘 와닿지가 않았었는데 이 책을 통해서 배울 수 있게 되었다.

비단 아키텍트 뿐만 아니라, 개발자로써도 앞으로 변화하는 시대에 맞춰서 시야를 넓히기에는 좋은 책이라고 생각한다.

물론 깊게 내가 가지고 있는 기술을 파는 것도 중요하지만, 점차 연차가 쌓이면서부터는 전반적인 숲을 볼 줄알아야되고, 기능이나 컴포넌트 구성을 할 때 확장성 등을 많이 고려해야하는 것 같기 때문이다.

때문에, 세부적인 지식들은 다 잘 모르더라도, 앞으로 내가 개발자로서 나아갈 방향은 제시해줘서 좋았던 것 같다.

추후 회차를 돌면서 책에서 제시하는 아키텍처에 대해 깊게 이해를 해보려고 한다

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

소프트웨어 아키텍처 101

잘 만들어진 상당히 큰 규모의 서비스를 접하게 되면 예전에는 어떤 언어로 어떻게 만들었을까 궁금했는데

이제는 각각의 서비스가 어떻게 상호 동작하는지, 어떤 패턴을 어떻게 응용했는지가 궁금하다.

사용자가 많은 시스템을 보면 대규모 트래픽을 어떻게 분산 처리 했는지, 시스템간 연동을 위해 데이터 연계는 어떤 방식을 썼는지 등이 궁금하다. 

소프트웨어적인 스킬을 넘어 데이터베이스와 네트워크에 대해서도 상당한 지식을 보유하고 있어야 할 것이다.

그래서인지 책 서문에는 아래와 같은 내용이 있다.

"소프트웨어 아키텍트는 전문가로 간주되는 소프트웨어 개발자로서, 고수준의 설계를 결정하고 소프트웨어 코딩표준, 도구, 플랫폼 등의 기술 표준을 지시한다"

책의 머리말에 옮긴이가 위키백과에서 인용한 "소프트웨어 아키텍트"에 대한 설명이다.

하지만 어디서 부터 어디까지가 이키텍의 영역이고, 어떤 것이 아키텍트의 역활인지에 대해서는 아직도 명확하지는 않다.

그렇다면 개발을 오래 한 사람, 많이 개발해본 사람은 아키텍트가 될 수 있을까? 

많은 경험은 분명 도움이 될 것이다.

하지만 이 책을 읽고 나면 어느 정도 아키텍트의 역활에 대해서는 감을 잡을 수 있을 거라고 생각된다.

이책은 크게 세개의 파트로 나뉘어 있다.

 - Part1. 기초

 - Part2. 아키텍처 스타일

 - Part3. 테크닉과 소프트 스킬

"Part1. 기초" 앞에 소프트웨어 아키텍처에 대해 정의를 해보고 어떤 역활을 하는지에 대해 간략하게 짚고 넘어간다.

"Part1. 기초" 에서는 아키텍처와 설계를 구분하고, 최선의 아키텍처란 어떤 것인가에 대해 이야기 하고 있다.

"Part2. 아키텍처 스타일"에서는 여러가지 아키텍처 스타일에 대해서 다룬다.

"Part3. 테크닉과 소프트 스킬" 에서는 유능한 소프트웨어 아키텍트가 갖추어야 할 핵심 기술과 소프트스킬을 이야기 한다.

아키텍처에는 정답이 없다. 경험에 의한 최선의 방법을 찾을 뿐이다.

하지만 경험이 모자란다면 타인의 경험을 바탕으로 부족한 부분을 조금이나마 매울 수 있다.

이 책이 그러한 책이 되지 않을까 싶다.

저자 마크 리처즈와 닐 포드는 경험 많은 아키텍트 경력자 이다.

아키텍트를 목표로 하는 개발자라면 가볍게 한 번 읽어 보면 좋을거 같다.

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

한빛출판네트워크의 도서 서평단인 "나는 리뷰어다 2022"에 선정되어 제공받은 책 두 번째인 ‘소프트웨어 아키텍처 101’.
 

나는 리뷰어다 서평단에서는 여러 신간 옵션을 주시고 리뷰어에게 선택권을 주시는데, 아직 주니어지만 직무가 데브옵스 엔지니어인 만큼 마이크로서비스니 이벤트 주도 아키텍처니 하는 소프트웨어 아키텍처에 관한 용어들을 자주 접하게 되다 보니 자연스레 ‘소프트웨어 아키텍처 101’을 선택하게 되었다.

‘소프트웨어 아키텍처 101’은 컴퓨터 공학을 접해본 사람들이라면 누구나 알 법한 오라일리 미디어 ’O’Reilly Media’ 에서 출간한 책으로 마크 리처즈(Mark Richards)와 닐 포드(Neal Ford) 두 명이서 집필했다.

‘소프트웨어 아키텍쳐 101’은 총 3개의 파트로 구성되어있다.

1. 기초
2. 아키텍처 스타일
3. 테크닉과 소프트 스킬

1. 기초

기초 파트에서는 소프트웨어 아키텍트가 가져야 할 아키텍처 사고와 아키텍처의 특성과 컴포넌트 기반 사고 등 파트의 제목 그대로 아키텍트로서 필요한 소양을 간단하게 짚고 넘어가는 느낌이었다.
 

2. 아키텍처 스타일

개인적으로는 두번쨰 파트의 내용이 비교적 익숙해서 그런지 가장 흥미로웠는데, 애플리케이션/시스템 개발에 사용되는 아키텍처들을 챕터별로 나눠 설명하고 있다.

내가 자주 들어왔던 마이크로서비스 아키텍처뿐만 아니라 레이어드 아키텍처, 파이프라인 아키텍처, 마이크로커널 아키텍처, 서비스 기반 아키텍처, 이벤트 기반 아키텍처, 공간 기반 아키텍처, 오케스트레이션 기반 서비스 지향 아키텍처까지 다양한 아키텍처 스타일을 토폴로지로 시각화할 뿐만 아니라, 해당 아키텍처가 등장하게 된 배경, 철학, 특성까지 포함하고 있다. 그래서 이 책의 도입부에 저자가 언급한 트렌드와 기술적 배경에 따라 소프트웨어 아키텍처를 적절하게 적용해 나갈 수 있도록 구성했다는 인상을 받았다.
(비록 나는 초심자라 정확한 내용을 100% 이해하지는 못했지만…)
 

3. 테크닉과 소프트 스킬

테크닉과 소프트 스킬 파트는 아키텍트로서 개발팀을 효율적으로 이끌 수 있게 하기 위한 도식화, 커뮤니케이션 스킬 등을 다루고 있는데, 이 부분에 대해서는 아직 주니어인 내가 당장 업무에 직접적으로 활용하지는 않겠지만, 향후 시니어가 되어 애플리케이션 디자인에 대한 의사결정을 하게 될 수 있게 되고 나면 소프트웨어 아키텍트로써의 커리어를 밟지 않더라도 충분히 활용할만한 부분이 많아 향후에도 계속 들춰보게 될 만한 책이라고 느꼈다.

‘소프트웨어 아키텍트 101’은 유행에 따라 단편적으로 습득하게 되는 아키텍처들을 구조적으로 분석해, 소프트웨어 아키텍트로서의 진로를 고민하는 사람들 뿐만 아니라, 단순히 주어진 요건에 따라 코딩을 해 나가는 것에서 한 발짝 나아가 시스템 특성에 걸맞게 애플리케이션을 개발하는 것을 고민하는 시니어 개발자(혹은 미리 공부하고 싶은)에게도 도움이 되지 않을까 싶은 책이었다.

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

Software Architecture

이 책의 목차는 크게 3개의 Part로 나뉘어져 있습니다.

• Part 1. 기초
• Part 2. 아키텍처 스타일
• Part 3. 테크닉과 소프트스킬

각 Part에는 몇 개의 장으로 구성되어 있습니다. 모든 내용이 알차게 구성되어 있습니다.

많은 쥬니어 개발자들, 아키텍트를 목표로 하는 사람들을 만나보았고, 대화를 하면 설계에 다양한 패턴들을 외우고, 공부하고, 적용해보기에 바쁩니다. 아키텍트는 아키텍처를 많이 알고 적용할 줄 아는 사람이라고 생각하는 듯한 분들이 많았습니다. 물론 저도 소프트웨어 아키텍트에 대해 그렇게 단순하게만 생각했던 적이 있었던 것 같습니다. 지금 생각하면 부끄러운 생각이였던 것 같습니다.

물론 아키텍처 스타일, 패턴들을 공부하고, 장단점을 파악하고 다양하게 적용할 수 있는 능력. 트레이드 오프를 파악하고 여러 후보 중 최적의 스타일을 찾아내는 능력이 중요하지 않다는 것은 아닙니다.

하지만 아키텍처 스타일은 시대가 변할수록 패턴도 변화하고, 낡은 아키텍처 패턴은 도태되고 새로운 스타일들이 제시하고 그 시대의 표준 스타일처럼 자리잡을 수도 있습니다. 그렇기에 아키텍처 스타일을 많이 아는 아키텍트가 최고다. 라는 말은 동의하기 어렵습니다.

제가 이 책을 추천드리고 싶은 부분은 아키텍처 스타일의 설명이 아니라, Part 1. 과 Part 3. 입니다. 아카텍트로서의 기초, 소양, 가져야할 자세와 프로젝트를 바라보는 시야부터 시작해서 트레이드 오프에 대해 분석, 최고의 구조를 파악하는 방법과 테크닉에 대한 설명들이 아주 상세하고 읽기 쉽게 잘 작성되어 있습니다.

특히 추천드리고 싶은 부분은 2장. 아키텍처 사고 입니다. 아키텍트는 개발자와 다른 시야와 다른 지식 도메인을 가져야 하고 그러한 다름을 이해하는데서 부터 출발한다고 해도 괜찮다고 저는 생각합니다. 먼저 사고방식을 개발자와 다름을 이해, 인정하고 아키텍트로서 준비를 하는게 우선이지 않을까 싶습니다.

아키텍쳐 평가를 위한 내용과 수식들은 조금 이해가 되지 않고 어려울 수 있습니다. 구조를 선택하는데 수식과 데이터는 왜 필요한지 의문일 수 있습니다. 처음 아키텍트로써 성장하기 위해 이 책을 읽으시는 분들은 그런 내용들은 과감하게 skip!! 하시는 것을 추천드립니다. 그 내용에 집중하다 흥미를 잃을수도 있을 것 같습니다.

Part 2 아키텍처 스타일 은 8개의 아키텍처를 설명하고 있습니다. 많이 사용되어왔던, 현재도 많이 사용되는 아키텍처도 있고 지금은 사용되지 않고 사라져가는 아키텍처도 있습니다. 왜 이런 아키텍처를 공부해야 하는가라고 생각하지 않고 다 공부해 보시는 것을 추천드립니다. 아키텍처의 역사 즉, 발전된 방향을 아는 것도 추후 더 나은 아키텍처를 설계하고 결정하고 분석하는데 큰 도움이 될거라고 믿습니다!

이 책을 보기 전 또는 함께 볼 만한 책으로 한빛미디어에서 출간한 개발자에서 아키텍트로 도서를 추천합니다. 추천하는 이유는 아키텍트는 결국 실무에서 실제로 경험을 쌓는게 가장 좋은 것인데, 그러기 쉽지 않습니다.

아키텍트는 설계만을 하는것이 아니라 비지니스 모델부터 시작해서, 이해관계자 간의 이해와 요구사항 도출, 정리, 품질속성 정리 등 해야할 일들이 너무나도 많습니다. 그리고 개발자들이 싫어하는 문서화 작업 또한 필수!로 해야합니다. 개발자에서 아키텍트로는 그러한 과정을 실습과 함께 잘 정리되어 있기에 추천합니다.

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

이 책은 소프트웨어 아키텍트의 소양으로 필요한 두 가지의 스킬, 학습을 통해 배우게 되는 하드스킬(개발기술, 지식, 도구 사용법, 기성 개발 방법론 및 숙련도 등)과 시간을 통해 습득하게 되는 소프트스킬(도메인에 특화된 개발 방법론을 파악하는 방법, 효과적인 커뮤니케이션, 신뢰받는 태도 및 관용 등)을 모두 다루고 있습니다. 일반적으로 다른 도서의 경우 한 가지에 집중하여 깊게 다루는 반면 이 책은 저자의 경험을 토대로 한 관점으로 파전같이 얇고 넓지만 중간 풍미 있게 씹히는 오징어 조각처럼 필요한 부분은 구체적 예를 들어가며 설명합니다.

아키텍트 직무에 필요한 기술과 집중해야 되는 지식의 종류, 아키텍처 방향을 결정하는 방법, 의사결정/토론/문서화/개발프로세스, 각 아키텍처의 장단점 및 트레이드오프 절충 방법, 개발팀과 상호소통하는 방법, 비즈니스 관점 및 갈등을 해소하는 방법 등 쉽지 않은 주제라 두껍게 다루어도 쉽게 끝내기 어려운 내용을 솔직 담백하게 경험에 기반하여 풀어냅니다. 또한, 넓고 핵심적인 내용만을 다루어 무겁고 정답 없는 내용을 쉽고 부담 없이 읽을 수 있도록 구성하였습니다. 역자분께서는 이를 "아키텍처의 세계를 콤팩트한 분량의 책에 깔끔하게 담아냈다는 사실이 무척 존경스럽습니다."라고 표현했는데, 무척 공감합니다.

책 내용 초반 '아키텍트에게 바라는 기대치' 대해 설명하면서 아키텍트가 수행해야 하는 핵심 역할 및 요구사항을 아래와 같이 안내하고 있습니다. 이는 이 책의 목표이자 직간접적으로 책 주제를 리스트업한 것과 같고 배울 수 있는 내용과 일치합니다.

  * 아키텍처 결정을 내림

  * 아키텍처를 지속적으로 분석

  * 최신 트렌드 유지

  * 아키텍처 결정에 대한 법적 준수/감시/내부통제 보장

  * 다양한 기술과 경험 도입

  * 비즈니스 도메인 지식 보유

  * 대인 관계 기술

  * 정치 이해 및 처세 잘하기

소프트웨어 아키텍처란 무엇인지, 아키텍처 혹은 의사결정 부분에서 일반적으로 어떤 오해가 있는지에 대한 논의, 개발과 아키텍처가 어떻게 다른지, 아키텍트가 하는 일, 올바르게 고민하는 방법 등을 안내하며 아키텍트가 고려하고 다루어야 하는 기술에 대해 친절히 설명해 줍니다. 적절한 예시, 흥미로운 박스 내용, POC, 부분적인 코드의 예를 통해 구체적으로 설명하여 개발 경험이 풍부한 호기심 많은 독자가 지루해 하지 않게 구성되어 있습니다. 또한, 아키텍트 임무 특유의 트레이드오프 관계 요소들로 인해 답이 없는 문제를 생각할 경우가 생기는데, 과장하거나 치우침 없이 저자의 경험에 기반하여 솔직하고 올바른 방향이라고 생각하는 부분을 강조하여 말해주고 있습니다.

또한 마인드맵으로 만든 것 같은 경험 있는 사람의 생각을 직관적 도표로 표현한듯한 삽화는 안개같이 실체 없는 구름 속에서 목표 지향적으로 근두운을 잡길 원하는 마음의 아키텍트 입문자들이 방향을 정하는데 큰 도움이 됩니다.

도서는 크게 아래 3개의 파트로 나누어져 있습니다.

1부 기초 : 소프트웨어 아키텍처 구성하는 기본 요소와 아키텍처를 다루는 기본 소양에 대한 내용과 아키텍트와 개발자의 차이점을 설명합니다.

2부 아키텍처 스타일의 세계 : 레이어드, 파이프라인, 마이크로커널, 서비스 기반, 이벤트 기반, 공간 기반, 오케스트레이션 기반 등 서비스 전체의 구조를 결정하는 아키텍처 디자인 패턴에 대해 설명하고, 이를 선택하는 방법을 설명합니다. 각 아키텍처 특성에 대해 배포, 탄력, 진화, 모듈, 성능, 신뢰, 확장, 단순 등 각 고려 항목을 나열하고 별점으로 평가한 부분은 단연 도서 내용 중 백미라고 볼 수 있습니다.

3부 테크닉과 소프트 스킬 : 아키텍처를 결정하기 위한 회의 방법, 리스크 분석/평가, 프레젠테이션 등 개발자, 다른 이해관계자들과 협력하는데 필요한 여러 기법과 소프트스킬에 대해 설명합니다.

실제 두 저자는 소프트웨어 아키텍트로 활동하고 있고, 특히 닐 포드는 마틴 파울러로 유명한 쏘우트웍스의 컨설턴트입니다. 역자 또한 개발자로 시작한 현직 아키텍트로, 저자와 역자 모두 실제 아키텍트의 경험을 기반으로 책이 탄생했습니다.

"아키텍트가 내린 거의 모든 결정은 사람들의 반발에 부딪히게 마련입니다. ... 아키텍트는 회사에서 정치를 잘하면서 대부분의 결정을 사람들이 수용하도록 기본적인 협상 기술을 발휘해야 합니다. ... 거의 모든 결정을 정당화하고 반대 세력에 맞서 싸울 준비를 갖추어야 합니다. ... 협상 기술은 ... 하나의 장으로 담았습니다."

이렇게 글을 쓸 수 있다는 것은 아마도 경험이 있는 저자와 역자이기에 가능했을 것입니다.

책에서도 언급되었지만 개발의 발전 속도보다 아키텍처의 발전 속도가 더 빠른 경향이 있습니다. 개발은 여전히 C/C++, Java가 필요하지만, 레거시 및 최신 기술을 모두 포용하기 위해 대두되었던 SOA(Service Oriented Architecture)는 특유의 복잡함으로 인해 이제 구시대 방식이 되었고 DevOps 등 개발과 운영을 한번에 고려하는 방식이 주목받으며 심플한 아키텍처가 대세가 되는 것이 아마도 기술과 아키텍처의 속도 차이를 단편적으로 알 수 있는 좋은 예라 생각됩니다. 따라서, 예를 들어 '이벤트 기반 아키텍처 스타일' 중 일부 내용이나 구성요소들 연결을 위해 항상 네트워크 프로토콜만을 고려하는 등 이론에 치우치거나 조금은 지난 경험인 내용이 포함되어 있기도 합니다.

이런 지엽적 부분을 제외하면, 본 도서는 방대하고 추상적이며 정답 없는 아키텍트 세계를 실제 아키텍트 선배가 진심어린 눈으로 설명해 주듯 설득력 있는 조언의 내용이 가득합니다. 이를 바탕으로, 제가 편집자였다면 "소프트웨어 아키텍트 101"보다는 "소프트웨어 아키텍트를 준비하는 히치하이커를 위한 안내서"로 정했을 것 같습니다.

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

아키텍트 지망생을 위한 기본서가 한빛미디어에서 발간되었다. 바로 Fundamentals of Software Architecture, 소프트웨어 아키텍처 101 되시겠다.

총 세 개의 파트로 구성되어 있고 대략적인 흐름은 다음과 같다. 소프트웨어 아키텍처란 무엇인지 살펴보고 역사적인 트렌드를 알아본다. 아키텍처적인 사고와 모듈성에 대해 언급하며 응집 / 커플링 / 커네이선스처럼 아키텍처를 설계할 때 고려해야 하는 것을 설명한다. 요즘 아키텍처 관련된 책이나 글을 찾아보면 한 번씩은 모두 언급되는 용어들인데 이 책에 가득 정리되어 있다고 보면 된다.

아키텍처 스타일 파트에선 다양한 아키텍처 스타일을 다룬다. 레이어드 아키텍처 스타일(2 티어, 3 티어 아키텍처를 생각하면 된다), 파이프라인 아키텍처 스타일, 마이크로커널 아키텍처 스타일, 서비스 기반 아키텍처 스타일, 이벤트 기반 아키텍처 스타일, 공간 기반 아키텍처 스타일, 오케스트레이션 기반 서비스 지향 아키텍처 스타일, 마이크로서비스 아키텍처 스타일이 있다. 이름만 들어서는 생소한 것도 있을 수 있는데 현업에서 조금 굴러본 사람이라면 글을 읽는 순간 대충 머릿속에 그려질 것 같다. 한편, 아직 공부하는 학생이라면 조금 뜬구름 잡는 이야기처럼 들리거나 난해한 부분도 분명히 존재할 것 같다. 하지만 제목에 붙어있는 101을 생각하면 여러 개념을 쉽게 설명하기 위해 펼쳐놓은 느낌이기 때문에 잘 이해가 안 되는 부분이 있다면 각 잡고 여러 번 읽어보시길 권장한다. 마지막 파트인 테크닉과 소프트 스킬에서는 아키텍처를 결정하고 리스크를 분석하는 등 개발팀과 긴밀하게 일할 수 있는 소프트 스킬에 대해서도 함께 다룬다. 

시중에 아키텍처를 다루는 책은 이미 여러 권 있다. 더 쉬운 책도 있을지도 모른다. 하지만 이 책만큼 폭넓게 여러 개념을 다루는 책은 흔하지 않다. 더욱이 시대적인 흐름에 따라 변화해온 아키텍처 스타일과 아키텍트로써 어떻게 성장할 수 있는지가 아주 잘 정리되어 있기 때문에 "아키텍처"를 공부하려고 마음먹었다면 이 책을 먼저 읽어보시길. 일독을 권한다.

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

#들어가기 전에

지금 재직 중인 회사는 지금까지는 현업 주도의 프로젝트가 많아서 정해진 일정에 맞춰 개발하다 보니, 

동일한 기능인데도 표준이 없어 영향도 확인하는 것이 업무의 절반이었습니다.

그러한 탓에 새롭게 셋팅된 조직에서도 기준을 세워서 일하자. 라는 니즈가 생겼는데,

과연 '아키텍처'란 무엇인지에 대한 부분에 많은 고민을 하였습니다.

이 책은 그러한 고민에 대해 분명 참고가 될 도서입니다.

물론 한 번 읽는 것으로는 안되고 여러 번 읽어 봐야 할 것 같아요.

#구성

이 책은 크게 3개 파트로 구성되어 있습니다.

파트1 : 아키텍처 특성은 무엇인지 등 개념에 대해 설명합니다.

파트2 : 실제 8가지 아키텍처 스타일에 대해 설명하고 고찰해 봅니다.

파트3 : 관리적인 측면에서 설명합니다.

그런데 왜 제목은 101일까요? ^^;;

#내용

전체 472페이지로 구성되어 있고, 종이가 얇은 두께라서 손가락 한 마디 정도의 두께 입니다.

그리고 상당히 가벼워서 출퇴근 길 들고 다니며 재미있게 읽었습니다.

아무래도 메모하며 책을 읽는 습관이 있어서 읽는 내내 노트에 내용을 적으며 보았는데, 저 같은 경우에는 책을 읽고나서도 복기하는데 도움이 되었습니다.

그리고 다양한 사례와 풍부한 도식으로 개념을 이해하는데 많은 도움을 주었습니다.

개발서적이 아니다보니 코드는 수도코드로 작성된 경우도 있지만 많지 않습니다.

< 총평 >

1. 아키텍처 업무를 하게 되었다! 그런데 뭘 해야하지? 할 때 시작하기에 좋습니다.

2. 아키텍처 패턴을 단편적으로 아는데 정리가 안된다! 그럴때 읽으면서 정리하기 좋습니다.

저는 머리가 좋은 편이 아니라

항상 책은 여러 번 보는 것을 좋아합니다. 

이 도서도 여러 번 읽으면서 보다 나은 아키텍처를 구성할 수 있도록 노력해야겠습니다.

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

◎ 추천 포인트

1. 매끄러운 번역

2. 과거부터 현재까지의 다양한 아키택쳐의 진화를 설명

3. 다이어그램을 활용한 깔끔 아키택쳐의 소개

이 책은 여러 아키택처들의 장단점, 다른 아키택처와의 차이 등 소프트웨어 아키택처에대한 이해를 위한 좋은 참고서로서, 코딩만으로 배우기 힘든 부분을 채워주는데 큰 도움이 될것이다.

소프트웨어 아키텍처가 무엇인지, 아키택트는 어떤일을 하는지에 대해 소개로 시작한다.

그리고 과거 모놀리식 형태부터 최근의 MSA형태까지 다양한 아키택처의 장단점을 설명한다.

마지막으로 개발기술이 아닌 소프트스킬에 대한 부분을 소개한다.

리더십, 토론방법, 협법 방식 등 시니어가 되기 위한 여러 지식에 대해 설명한다.

개발자로서 시니어로 성장하거나, 코더 수준에서 벗어나려면 코딩능력 말고도 여러가지 필요한 것들이 있다.

팀장이 되기위한 소프트스킬이나, 요구사항을 도출하는 능력이라던지, 문제해결력 같은 단순한 개발기술이 아닌부분도 제법 필요하고 생각한다.

소프트웨어 아키텍처 역시 그런 소양의 하나라고 생각한다.

정해진 프레임워크에서 개발을 하다보면 아키텍처에 대한 고민을 하지 않게 된다.

그러다보면 누군가 정해준 방식으로 프로그램을 만들어 갈 수 밖에 없다.

더 좋은 개발자가 되기 위해서는 이러한 단계를 뛰어 넘어야 할것이고 이 책은 그런 사람들에게 도움이 될 것이다.

그리고 시니어로 성장할 수록 설계(design)에 참여해야 하는 일이 많아 진다.

이때 자신의 생각한 구조를 명확하게 표현하는 능력도 중요하다.

책에 소개된 여러 아키택쳐의 다이어그램의 양식을 살펴보는 것도 많은 도움이 될것 같다.

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

이번 달에는 소프트웨어 아키텍처 101을 골라서 읽게 되었습니다. 이 책을 고른 이유는 개발을 배우기 시작할 때 가장 먼저 배우는 모놀리식 아키텍처부터 요즘 제일 핫한 MSA 아키텍처까지 아키텍처에 대한 전반적인 개념을 접해보고자 읽게 되었습니다.

이 책은 크게 3가지 파트로 나누어집니다.

첫 번째 파트 '기초'는 다소 지루할 수 있습니다. 아키텍처적인 사고, 특성 등등 컴포넌트는 어떻고 모듈은 어떻고 다소 추상적인 내용으로 글이 이어지기 때문에 집중하기 쉽지 않았습니다. 중간 중간 아키텍처에 대한 개념이 정립되지 않았던 옛날 옛적에는 어떻게 개발을 해왔는지, 그래서 어떤 문제가 있었는지 옛날 이야기도 들려줍니다. 구체적인 예시가 부족한 추상적인 이야기나 옛날 이야기가 다소 지루한건 어쩔 수가 없었습니다. 하지만, 첫 번째 파트에서 소개하는 기초 개념을 읽고 넘어가야 후반부에 나오는 내용들을 이해하는 데 도움이 됩니다.

두 번째 파트는 아키텍처 설계 방식의 종류들을 한 장에 하나씩 구석구석 뜯어가며 설명해줍니다. 이 파트가 대부분의 독자가 가장 집중해서 보는 파트일 것이라 생각합니다. 소개하는 아키텍처는 다음과 같습니다.

• 레이어드 아키텍처 스타일
• 파이프라인 아키텍처 스타일
• 마이크로커널 아키텍처 스타일
• 서비스 기반 아키텍처 스타일
• 이벤트 기반 아키텍처 스타일
• 공간 기반 아키텍처 스타일
• 오케스트레이션 기반 서비스 지향 아키텍처 스타일
• 마이크로서비스 아키텍처 스타일

위 아키텍처들을 설명하는 글의 구조는 다음과 같이 거의 비슷합니다. 

• 토폴로지
• 각 아키텍처 스타일의 특성 여러가지 ( 장단점 등등 )
• 아키텍처 특성 등급

모든 아키텍처들도 비슷한 형식으로 설명되어 있으니 요즘 가장 핫한 MSA 구조에 대한 설명만 간단히 알아보겠습니다.

토폴로지

마이크로서비스의 토폴로지는 위의 그림과 같습니다. 마이크로서비스는 단일 목적만 가지기 때문에 오케스트레이션 기반의 서비스 지향 아키텍처와 같은 다른 분산 아키텍처보다 서비스 규모가 훨씬 작습니다. 실제로 각 서비스에는 데이터베이스 및 기타 종속적인 컴포넌트 등 서비스가 독립적으로 작동되는 데 필요한 모든 것들이 준비되어 있습니다.

특징

마이크로서비스 아키텍처의 특징으로는 다음의 특성들에 대한 설명이 있습니다. 여기서는 한 줄로만 적겠습니다.

• 분산 : 뭔가를 공유함으로써 불거지는 문제들과 분산 속성 탓에 발생하는 부정적인 요소에 대하 설명
• 경계 콘텍스트 : 마이크로서비스의 근본 철학은 경계 콘텍스트 개념과 일치한다는 설명
• 세분도 : 서비스의 적절한 경계를 찾는데 도움이 되는 몇 가지 가이드라인 (목적, 트랜잭션, 코레오그래피)
• 데이터 격리 : 마이크로서비스는 경계 콘텍스트 개념에 따라 데이터를 격리해야 한다는 설명
• API 레이어 : 마이크로서비스에서 여러 시스템 컨슈머 사이에 있는 API 레이어에 관한 설명
• 운영 재사용 : 모니터링, 로깅, 회로 차단기 등의 운영 관심사는 사이드카 패턴을 활용하라는 설명
• 프론트엔트 : 프론트엔드를 모놀리식으로 할지 마이크로 프론트엔드로 할지에 관한 설명
• 통신 : 동기로 할지, 비동기로 할지 등 근본적인 통신 방식에 대한 설명
• 코레오그래피와 오케스트레이션 : 코레오그래피와 오케스트레이션 아키텍트에 관한 설명
• 트랜잭션과 사가 : 여러 서비스에 걸친 트랜잭션을 어떻게 처리할지에 대한 설명

두번째 파트를 통해 여러 아키텍처 스타일에 대해 구체적인 학습을 할 수 있고, 각각의 아키텍처가 어떤 요구사항에 적합한지 어떤 장단점이 있는지 여러 특징들을 살펴볼 수 있었습니다. 

세 번째 파트는 앞에서 익힌 아키텍처에서 더 나아가 테크닉과 소프트 스킬에 대한 내용으로 이루어져 있습니다. 아키텍처의 기술적인 부문을 이해하는 것과 함께 아키텍트답게 사고하면서 다양한 이해관계자들과 효과적으로 소통할 수 있는 소프트 스킬들에 대해 이야기합니다.

아키텍처와 관련된 내용은 아키텍처를 결정하는 안티패턴은 어떤 것들이 있는지, 아키텍처의 리스크를 분석하는 방법, 아키텍처를 도식화 하는 방법 등에 대해 설명이 이어지고, 소프트 스킬과 관련된 내용으로는 개발팀과 효율적으로 상호작용하는 방법, 협상과 조정, 커리어패스를 개발하는 내용 등이 이어집니다. 

코드 레벨에서의 구현을 고민하는 것도 즐겁지만 가끔은 더 큰 아키텍처의 관점에서 학습하고 고민하는 것도 즐거운 것 같습니다. 아키텍처의 전반적인 개념에 대한 이해와 여러 구체적인 아키텍처 스타일의 특징들을 학습하시고 싶은 분들께 추천드립니다.

   회사 상사분과 대화를 나누며 책 이야기가 나왔을 때 개발자로서의 가이드라인을 제시해주신 적이 있다. 지금은 입사 초반이므로 객체지향 언어에 대한 대한 서적을 먼저 필독이라고 알려주셨고, 그다음으로는 알고리즘 혹은 디자인 패턴에 대해 공부하라고 알려주셨다. 그 뒤에 5년 정도의 경력이 쌓인 후 아키텍처에 대해서 공부해보면 좋을 거라고 하셨다.

  개발 관련 문서나 블로그 등을 읽다 보면 아키텍처, 아키텍트라는 단어가 자주 보이곤 하지만 그 뜻을 정확하게 이해하고 있진 않았다. 

  그러다가 만나게 된 소프트웨어 아키텍처 101이라는 책.

  아직 개발 실무 경험도 많지 않고 여러모로 공부하는 단계여서 아직 읽기는 이를 수도 있다고 생각했지만 모르는 분야이지만 언젠가 공부해야 한다면 미리 읽고 용어들에 익숙해져 두는 것도 나쁘지 않다고 생각해서 읽게 됐다.

  그리고 내가 아키텍처에 대해 정확하게 이해하지 못했던 이유도 책에 나와 있었다. 다음은 책의 내용을 일부이다.

소프트웨어 아키텍트라는 직업의 명확한 정의가 아직 없다. 방대한 분야를 포괄하고 있고 업무 범위도 계속 넓어지고 있기 때문이다. 10년 전만 해도 소프트웨어 아키텍트는 주로 모듈성, 컴포넌트, 패턴 등 순수 기술적인 부분을 다뤘지만 이제는 마이크로 서비스와 같은 폭넓은 능력을 활용하는 새로운 아키텍처 스타일의 등장으로 인해 그 역할과 범위가 한층 더 확대되었다.

  아키텍처란, 한 문장으로 표현하기 어렵고 트렌드에 맞추어 변화해 가야만 하고, 개발뿐만 아니라 프로젝트에 대한 이해도 또한 높아야 한다. 그뿐만이랴? 대인 관계나 정치를 잘해야 한다고까지 나온다. 이런 내용들이 주니어 개발자인 나에게는 당연히(?)도 익숙하지 않고 어떤 것인지 이해조차 못하고 있던 게 어쩌면 당연하다.

  책의 서론에서는 소프트웨어 아키텍처란 무엇인지 소프트웨어 아키텍트가 돈을 그렇게 잘 번다는데 하는 일이 무엇인지에 대한 설명을 해준다.

  파트 1 기초에서는 아키텍처로 사고하는 내용과 모듈의 응집도에 대한 내용을 다루고 있다.

  이번 3월에 정보처리기사 필기시험을 준비하며 달달 외웠던 내용이 있다. 높은 응집도와 낮은 결합도가 중요하다. 이 내용은 이전에도 자주 나왔던 문제로 필수 내용이었다. 정보처리기사가 개발자의 필수 자격증이라고 그렇게 인정해주는 데에는 이유가 있구나.. 하고 생각했다. (지금 읽고 있는 '실용주의 프로그래머'에서도 나오고,  소프트웨어 아키텍처 101에서도 크게 다루고 있으니!!!) 단순히 알고만 있던 단어들을 이해한다면 좀 더 좋은 개발자가 될 수 있을 것 같다. 

  7가지 챕터로 나눠 아키텍처의 특성에 대해 알려준다.

 운영 아키텍처와 구조 아키텍처의 각각 특성이 어떤 것인지. 용어와 정의를...

  책을 읽다 보면 어려운 개념들도 있지만 일부는 ' 음음 개발자라면 당연히 그래야지! '라고 생각을 하는 부분이 많기도 했다. 하지만... 내가 지금 진행하는 팀 프로젝트의 설계를 다시 돌아보면... ㅎㅎ.. 데이터베이스를 직접 호출하는 레이어조차 정하지 못해서 어디서는 repository에서 호출하고, 또 다른데선 service에서 호출하는 우리 팀의 코드가 생각이 났다... ( 이 부분도 책에서 여러 차례 언급된다! 프로젝트에 실질적 도움이 되고 있다. )

  눈으로 스치듯 보고 있기 때문에 당연하고 쉬워 보이는 거란 생각이 들었다. 하지만 한편으로는, 전부는 아니더라도 이 중 몇 퍼센트만이라도 머릿속에 남겨둔다면 개발자로서 성장하는 과정에서 시야는 확실히 넓어질 것이라 확신했다.

  파트 2에서는 아키텍처 스타일에 대해 10개 챕터로 나눠 알려준다. 

  파트 3에서는 테크닉과 소프트 스킬에 대해 7가지 챕터로 나눠 알려준다.

 파트 3은 아키텍처를 결정함에 있어서 적용 방식에 대한 내용을 다루고 있다. 아키텍처에 대한 직접적인 내용이 아니라 조금 간접적인 내용들이라서 이해하기는 더 쉬웠다. 이해관계자들과도 충분한 소통이 필요하고, 정당화, 문서화하는 등 아키텍처의 결정은 단순하지 않기 때문에, 아키텍처 안티 패턴에 빠지곤 한다.

  예를 들어 직접적인 이러한 아키텍처로 결정했다 라는 식의 직접적인 표현이 아니라 '서비스 간 통신에 관한 중요한 결정을 내렸으니 확인 부탁드립니다'와 같이 결정 그 자체보다 필요한 내용을 제공하는 식으로..

  전반적으로 책을 읽으며 어려운 개념이 많아서 온전히 내 것으로 만들었다는 생각은 들지 않는다. 이런 게 있구나 하는 정도로 가볍게 읽었다. 하지만 적어도 주니어 개발자로서의 공부 방향성에 큰 힌트를 주고 있음은 분명하다. 1년 정도 지나서 다시 읽어보면 와닿는 것도 다르겠지.

  직장에 근무하며 중요한 설계 등에 대해서는 주니어 개발자인 나에게 결정권이 있을 리가 없었고, 내용이라도 알면 다행인 정도였다. 하지만 이번에 팀 프로젝트를 진행하며 제로부터 모든 결정을 팀원과 직접 상의하며 정해야 하는 현재로서는 효율적인 팀 운영에 대한 내용도 있고 모르는 개념들도 많이 습득하게 되어 알찬 책이었다.

책 자세히 보기

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

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

매달 말 다음 달에 리뷰할 도서를 고르라고 한빛 미디어에서 메일이 온다. 난 이 책을 골랐던 것을 잊었다. 머신러닝 엔지니어인 나에겐 아직은 어색한 책이다. 게다가 나는 3학년 2학기가 끝나자마자 취업을 했고 거의 학교를 1년 대충 다녔는데  하하 심지어 한 학기는 월-목 일하고 금요일에 강의를 몰어넣어서 금요일마다 학교에 갔다 4학년에 배우는 소프트웨어 공학 등의 수업을 못들었기 때문에 소프트웨어 아키텍쳐란 딥러닝 모델 아키텍쳐만 보던 나에겐 더욱이 낯설었다.

나도 컴퓨터를 사용하는 일종의 소프트웨어를 다루는 엔지니어니까 도움이 될 것 같았다. 하지만 역시 처음보고 듣는 이야기는 어려웠다. 물론 마이크로 서비스 정도는 대충 알고 있다. 일하면서 약간 주워들은 게 있어서 그렇다.

이 책의 시작은 일단 소프트웨어 아키택쳐가 무엇인지부터 시작한다. 그리고 점점 더 어려워졌다.. ㅎ 아키텍처 특성, 아키텍처 패턴, 컴포넌트 결정, 아키텍처 도식화 및 프레젠테이션, 진화적 아키텍처 등 다양한 주제가 나온다.

예전에 인터넷 어디선가 "마이크로서비스가 다 좋은건 아니다!" 라는 것을 들었다. 책에서 이야기하는 마이크로서비스 아키텍쳐는 요즘 유행하는 스타일이라고는 얘기하였지만 역시 제일 좋다 아니다를 얘기하진 않았다. 이처럼 다양한 아키텍쳐 스타일에는 유행은 있으나 더 좋은 것은 없고 역시 서비스에 알맞는 사이즈가 최고가 아닌가 싶었다. 물론 아키텍처 이야기는 아니지만 다 현재 상황에 맞는게 있으니 예전엔 어느 회사는 뭐 쓴대~ 이러면 부러웠는데 이제는 꼭 부럽지만은 아닌 것 같기도하고  아닌가 부럽다 

책을 읽으면서 뭣도 모르는 나도 그림으로 '오호 이런거구나' 싶게 아키텍처 토폴로지를 그림으로 잘 표현해놓았다.

그리고 또 다른 재미있었던 점은 실제로 어떤 서비스를 위해 사용되는 아키텍처인지 구현 예시가 있다. 난 백엔드 개발자나 소프트웨어 아키텍트가 아니지만 뼛속깊이 개발자인지 어쩐지 이거 만드려면 어떻게 해야되나? 뭐 쓰면되나? 혼자 생각할 때가 있는데 이 책을 읽으면 이런 궁금증이 풀리지 않을까 싶다. 그 중 관심이 갔던게 콘서트 티켓 판매 시스템인데 동시 요청수가 많은 콘서트 티켓 판매 시스템을 위해 공간기반 아키텍처를 사용하는 것이 좋다는 것이었다. 읽다보니 이선좌(이미 선택된 좌석), 이결좌(이미 결제된 좌석)로 나를 괴롭히는 시스템들이 어떻게 생긴 아키텍처를 사용하고 있을지 상상해보았다.

이 책을 머신러닝 엔지니어들에게 추천할 만큼.. 이해하지는 못했지만 내가 만든 딥러닝 모델을 서비스하게 만들어주는 더 큰 뒷면의 톱니바퀴들이 하는 일이 어떤 것인지 알고싶다면 추천한다!

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

​

이 전에는 보안 관련 책이었는데, 이번에는 아키텍트의 책

제가 실제로 가지고 있는 역할과는 조금 거리가 있는 책이어서 그렇게 기대하지 않고 봤다.

101이니 여러 아키텍처를 조금씩 나열식으로 소개하는 책이 아닐까 하는 선입관도 있었다.

​

전반적인 책의 내용은 아키텍트라는 직업에 대한 소개, 가이드에 가까웠던 것 같다.

물론 여러 아키텍처를 소개하고, 각 아키텍처의 장단점을 정리해주기도 하지만

아키텍트 선배로써 이제 입문한 또는 방향을 못 잡고 있는 아키텍트에게 실질적인 접근 방식을 알려주는 책이었다.

​

실제 아키텍트라는 직업도다는 선임 개발자가 아키텍처를 잡는 현실에서는

어느 정도 연차가 있는 개발자가 읽어 본다면, 아키텍처를 선택하는데 도움이 될 것 같다.

​

특히 3부의 테크닉과 소프트 스킬이 내일부터다로 써먹을 수 있는 수단이 되지 않을까 기대가 된다.

책에 단점이라면 소소한 오타가 많다는 점과 전체적으로는 괜찮지만, 특정 단락이 해석이 잘 안되는 번역톤 정도인데, 크지는 않다.

​

책의 외관은 앵무새의 등장으로 시작합니다.

기본적으로 비전공자이다보니 소프트웨어 및 모든 내용에서 웹개발자에 합당한 기본 지식이 부족하다.

뭐든지간에 읽고 씹고 맛보고 해봐야 조금이나마 개발자 고수님들을 따라잡을 수 있다고 생각하기에 현재의 프론트개발자라는 직종에서 100% 일치하지는 않지만 그래도 많은 부분을 함유하고 있다고 생각하여 아키텍처 구조를 살펴보려고 신청하였다.

해당 책은 소프트웨어의 전반적인 아키텍처에 대한 소개가 핵심이다.

여러 가지 아키텍처를 소개해주고, 이에 따른 내용을 설명해준다.

내 개발 지식이 부족하기에 어쩔 수 없긴하지만
나름 아는 내용(컴포넌트, 데이터베이스, 비동기통신 등등..)이 등장하기도 하였다.

이 책은 개발자 중급에서 읽기 좋고
고급에서도 가끔 아~뭐가있었더라~ 심심한데 읽어볼까? 하면 도움이 될 것 같다.

이 책은 아키텍처 구조에 대한 설명이 주 이기 때문에, Part 2를 집중해서 봐야한다.

이 책에서 소개하는 여러 아키텍처들을 한 번 찬찬히 살펴보아야한다.

원서의 제목은 Fundamentals of Software Architecture이다. 즉 소프트웨어 아키텍처의 기본적인, 근본적인 내용을 담고 있다.

그래서 책의 Part I 에서는 소프트웨어 아키텍처에서 나오는 개념들에 대한 설명으로 시작을 하고 아키텍트는 어떤 사람인지 얘기를 한다.

아키텍트에게는 기술의 깊이보다 폭이 더 중요하다.

아키텍트는 결정을 내리고, 지속적으로 분석을 하고 최신 트렌드를 계속 따라가며, 비즈니스 도메인 지식이 필요하며 대인관계 기술도 뛰어나야 한다.

그리고 Part II (이 책의 가장 핵심적인 챕터이다)에서는 다음과 같은 아키텍처 스타일에 대한 설명을 한다.

• 레이어드 아키텍처 스타일
• 파이프라인 아키텍처 스타일
• 마이크로커널 아키텍처 스타일
• 서비스 기반 아키텍처 스타일
• 이벤트 기반 아키텍처 스타일
• 공간 기반 아키텍처 스타일
• 오케스트레이션 기반 서비스 지향 아키텍처 스타일
• 마이크로서비스 아키텍처 스타일

이런 아키텍처 스타일을 설명을 할 때 각 아키텍처 스타일 별로 다이어그램으로 설명이 되어 있어서 이해하기 쉽고 유용한 것 같다.

그리고 마지막 챕터는 기술적인 내용이 아닌 어떻게 아키텍처를 결정해야 하는지, 개발팀의 효율을 높이기 위한 방법, 협상과 리터십 스킬등 소프트 스킬에 대한 설명이 있어서 인상이 깊었다. 사실 이런 내용들은 경험자에게 전해 들을 수 밖에 없는 내용 들인데 이런 내용이 설명되어 있는 것도 좋았다.

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

이 책은 아키텍트가 되기 위해 소프트웨어 아키텍처를 바라봐야 하는 방향을 제시하고 있다.

물론 개발자라면 시스템설계 및 아키텍처에 대한 이해를 하고 있어야하는 것이 맞지만 

이 책에서는 개발자의 역할과  아키텍트의 역할을 설명하며 두 직업 사이의 차이를 설명하고 있다.

두 직업의 차이를 설명하고 있는 것은 다음 그림과 같다.

두 그림이 의미하는 바는 개발자는 자신의 전문분야를 가지고 있어야 한다.

예를들어 자바 개발자 라면 자바에 대한 깊이 있는 전문성을 가져야지 C++, Python, node 등 모든 언어에 대한 전문성을 가질 필요는 없다.

하지만 아키텍트는 하나의 언어에 대한 깊이는 낮더라도 대부분의 언어에 대한 전반적인 특징 및 지식을 알고 있어야 한다는 것을 나타내고 있다.

또한 아키텍트로서의 자세 및 가치를 다음과 같이 정의하고 있다.

• 아키텍처 결정을 내린다.
  

  아키텍처와 설계 원칙을 결정하고 팀, 부서뿐만 아니라 회서 전체의 기술 결정을 가이드 하는 사람
  

• 아키텍처를 지속적으로 분석한다.
  

  끊임없이 아키텍처와 현재 기술 환경을 분석하고 이를 개선하기 위한 해결 방안을 제시
  

•  

  최신 트렌드를 계속 따라간다.
  

  항상 최신 기술과 업계 트렌드를 따라가야 함
  

•  

  아키텍처 결정의 컴플라이언스를 보장한다.
  

  아키텍처 결정과 설계 원칙의 컴플라이언스를 보장해야함
  

•  

  다양한 기술과 경험에 노출된다.
  

  다양한 기술, 프레임 워크, 플랫폼, 환경에 노출 되어야함.
  

•  

  비즈니스 도메인 지식을 보유한다.
  

  어느 수준 이상의 비즈니스 도메인 전문가여야 함.
  

•  

  대인 관계 기술이 뛰어나다.
  

  팀워크, 조정, 리더쉽을 포함한 대인 관계 기술이 뛰어나야함
  

•  

  정치를 이해하고 처세를 잘한다.
  

  기업 내부의 정치적 분위기를 이해하고 적절하게 잘 처신할 줄 알아야 함.

개인적으로는 다양한 기술과 경험에 노출되어야 하는 것과 대인 관계 기술이 뛰어나야 한다는 것이 매우 중요하다고 생각된다.

위에서 언급한 것과 같이 아키텍트는 기술의 깊이보다는 폭이 넓어야 한다. 

그리고 개발자에게 어떤 기술을 사용하도록 유도하기 위해서는 대인 관계가 원만하게 유지하며 정치도 해야한다.

책에서는 ‘소프트웨어 아키텍처의 모든 것은 다 트레이드오프이다.’라고 설명하고 있다.

아키텍트는 요구사항, 시스템 구조, 설계 등의 상황에 따라 적절한 선택을 해야한다.

이 책의 대상 독자를 초중급 으로 정하고 있는데 개인적으로는 중급이상이 봤으면 하는 생각을 갖고 있다. 

내용은 소프트웨어 아키텍처에 대한 설명을 잘 하고 있지만 초급이 이해하기에는 약간 어려운 면이 있으며 잘못 접근 했다가는 

소프트웨어 아키텍처는 어렵다는 생각을 가질수 도 있다는 생각이 든다.

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

책제목 : 소프트웨어 아키텍처 101

저자 : 마크 리처즈, 닐 포드 지음 / 이일웅 옮김

출판년도 : 2021.11.01

책을 읽기 전에...

프로그래머라는 직업을 가지고 나서 아키텍처에 관련해서는 꽤 많은 책을 읽은 기억이 있다.

아키텍처는 프로그래머가 배워야 할 기본 소양이며 프로그래밍을 시작할 때 늘 생각해야 할

항목이라고 생각한다.

아키텍처가 튼튼하게 설계된 소프트 웨어는 유지보수 및 기능 추가가 쉽고 

작업자들간의 협업에서 시간을 단축시켜준다.

책의 내용...

책의 서론은 소프트웨어 아키텍처에 대한 설명으로 시작한다.

소프트웨어 아키텍트라는 직업을 보면 전 세계 직업순위에서 수위에 있는데

이 직업을 위한 커리어패스는 분명하지 않다.

이유는 소프트웨어 아키텍트라는 직업자체에 대한 명확한 정의가 아직 없기 때문이다.

저자는 이 책의 서론에서 소프트웨어 아키텍트의 업무가

얼마나 많은 기술 역량, 소프트 스킬, 운영 감각등 많은 분야를 아우르는지 마인드 맵을 제공하였다.

그리고 소프트웨어 아키텍트에게 바라는 핵심적인 요구사항 8가지를 정리하고

유능한 소프트웨어 아키텍트가 되기 위해 사람들이 자신에게 바라는 요구사항을 충분히 이해하고 실천하려는

마음가짐을 가져야 한다고 서술한다.

파트 1 기초

이 파트에서는 아키텍처 사고와 모듈성, 아키텍처 특성, 컴포넌트 기반 사고에 대해 이야기 한다.

아키텍처가 사고하는 방법, 아키텍처 관점에서 사물을 바라보는것에 대해 설명해 준다.

이를 이해하고 나면 다음으로는 모듈성에 대해 이야기 한다.

코드의 재사용, 연관된 코드를 묶어 모듈로 제공하는 것에 대한 여러가지 이론 및 방법론, 정의 등에 대해 설명한다.

그리고 아키텍처 특성들에 대해 정의하고 여러가지 상황에서 아키텍처 특성을 도출해내는 법, 

그리고 아키텍츠 특성을 측정하는법에 대해 설명해 준다.

기초 파트의 마지막으로 컴포넌트에 대해 설명하고 아키텍트 역활, 개발자 역활, 컴포넌트 등에 대해 설명한다.

파트 2 아키텍처 스타일

파트 1 에서는 아키텍처가 무었인지, 어떤것인지에 대한 설명과

예시들을 보여주었다면 파트 2에서는 사용되고 있는 아키텍처 스타일을 보여주며

설명 및 정의와 예시를 보여준다.

이키텍처 스타일 레이어드, 파이프라인, 마이크로커널, 서비스 기반, 이벤트 기반,

공간 기반, 오케스트레이션 기반 서비스 지향, 마이크로서비스 아키텍처 스타일을 예로 설명해 준다.

이 파트의 마지막에는 최적의 아키텍처 스타일 선정에 대해 이야기 하는데,

아키텍처 유행은 계속 변하고 늘 가장 최적인 아키텍처는 없으며 상황에 맞게

여러가지 조건들을 고려해서 아키텍처를 선정해야 한다고 설명한다.

파트 3 테크닉과 소프트 스킬

파트 3 에서는 유능한 소프트웨어 아키텍트가 갖추어야 할 핵심 기술과 소프트 스킬을 이야기 한다.

간단하게 하나씩 살펴보면 아키텍처 결정이다.

아키텍트로서 애플리케이션이나 시스템의 구조, 기술 결정등 중요한 결정을 올바르게 내려

개발팀이 올바른 기술을 선택할 수 있도록 도움을 줘야 한다.

리스크를 분석하고 아키텍처르 도식화 및 프리젠테이션 하며 개발팀을 좀 더 효율적으로 진행할 수 있도록 해야 한다.

책을 읽고나서

책 내용은 프로그래머를 희망하는 이나 프로그래머로서 오래동안 종사해 온 이 모두에게 좋은 책 이라고 생각한다.

다만 국내에서는 소프트웨어 아키텍트라는 직군이 그다지 널리 알려지지 않고 있고

일반적으로 경력이 많은 이가 아키텍처를 담당하고 있는걸로 알 고 있다.

이 책을 읽고 나니 소프트웨어 아키텍처라는 직업이 좀 더 전문화 되어 개발에 있어

서로 시너지가 날 수 있으면 좋겠다 라는 생각을 하게 되었다.

책 자체는 이해를 돕기 위한 그림이 많고 설명이 잘 되어 있으며 여러가지 아키텍처에 대해

예시등을 많이 들어줘서 읽기가 편했다.

 "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아

작성된 서평입니다."

책 소개 링크 : https://www.hanbit.co.kr/store/books/look.php?p_code=B1494466807 

서론

소프트웨어 아키텍쳐, 평소 시스템 전체에 대한 아키텍쳐에 관심이 꽤나 있었다.

그래서 각종 컨퍼런스들에서 MSA, 이벤트 버스 등 여러 구조들을 접하려고 노력했다. 구조 자체는 이해하는데 크게 어렵지 않지만, 내부적인 요소들이 왜 필요한지, 어떤 케이스에서 효율적일지 등 완전한 이해를 하기가 어려웠습니다.

이런 부분들을 긁어주려고 하는 책인데, 제가 가려운 부분을 잘 파악하지 몰라 시원하지 못하다는 생각이 듭니다 ㅎ

책 소개

책은 소프트웨어 아키텍처가 무엇인가? 부터 시작해 아키텍처의 특성, 스타일 그리고 그 외에 아키텍처가 갖춰야할 소양들(협상과 리더십, 커리어 패스 등)에 대해 다루고있습니다.

제 목표는 아키텍처 관련 키워드들을 몸으로 익히는 것이었습니다. 추후 이런 키워드가 나오면 언제든지 찾아볼수 있게끔.. 이 모든 것을 이해하기에는 역시나 약간의 무리가 있었습니다 ㅎ

하지만 책 자체에서 소개해주는 백엔드 내부의 스타일부터 전체적인 스스템의 스타일까지 어떻게 생겼는지 정도를 이해하는데에 설명이 굉장히 상세하게 되어있었습니다. 설명에서 아키텍처영역을 벗어난 부분도 주석으로 잘 풀어주는 부분이 이해하는데에 도움을 많이 받았습니다.

결론

추천! 소프트웨어 아키텍처라는 직업에 대해서도, 아키텍처 그 자체에 대해서도 많은 도움을 받을 수 있습니다!

저는 현재 3년차 개발자인데, 회사에서 시니어 분들 끼리 대화하실 때 특정 아키텍처의 이름이 나오며 장단점이 거론되거나,

어떤 아키텍처를 사용할 것인지 논의하는 걸 많이 들어왔습니다.

실무 기간이 짧다보니 이와 관련해서는 지식이 많이 모자라서 아쉬웠는데, 

때마침 아키텍처와 관련된 책이 리뷰 대상으로 나와 바로 신청하게 되었습니다.

신청할 당시에는, 제목만 보고 여러 아키텍처들이 나열되어 있고, 각 아키텍처별로 정의와 특징들이 정리되어 있을 거라고 예상했는데요.

막상 책을 받아보니 그 외의 내용들이 많았습니다.

먼저 책을 여는 1장, 기초 파트에서는 소프트웨어 아키텍처의 정의와 아키텍트라는 역할에 대해서 이야기하고 있습니다.

아키텍트라는 팀 내 역할에 대해서는 조금 생소했는데요. 

이 장을 읽으면서 이미 팀 내에, 아키텍트라고 직접적으로 부르고 있지는 않지만, 아키텍트의 역할을 하고 계시는 분이 있다는 생각이 들었습니다.

아키텍트로서 일 하기 위해서는 어떤 소양을 길러야 하는지, 어떤 방향으로 노력해야 하는지에 대한 내용들을 담고 있습니다.

아직은 주니어 개발자로서 머나먼 이야기들처럼 느껴졌지만, 당장 아키텍트로 일하는 게 아니더라도,

개발자로서 특정 아키텍처나 기술 스택 중 하나를 선택해야 할 때 가져야할 마음가짐도 배울 수 있었습니다.

​

다음 2장은, 제가 예상헀던 책의 내용인 아키텍처 스타일 파트입니다.

여러 아키텍처들에 대해서 다루고 있었는데, 종류가 워낙 많다보니 일단 익숙한 이름의 아키텍처부터 하나씩 읽어보는 중입니다.

제가 관심을 가지고 있던 아키텍처들은 다음과 같았습니다.

​

- 모놀리틱 vs 분산 아키텍처

- 이벤트 기반 아키텍처

- 마이크로서비스 아키텍처

​

각 아키텍처별로 초반에는 토폴로지를 소개하고, 중반에 특징과 장단점을 정리하고 있으며, 

마지막에 아키텍처 특성 등급을 통해 다른 아키텍처와 어떤 차이가 있는지 정리해주는 구성입니다.

​

마지막 3장은, 테크닉과 소프트 스킬 파트입니다.

여기서는 아키텍트로서 가져야 할 스킬들에 대해서 이야기해 주고 있었는데요.

저는 아직 주니어 개발자로서 아키텍처들에 대해서 공부하는 게 목적이었던 관계로, 이 부분을 모두 읽지는 않았으나,

23장 협상과 리더십 스킬과 24장 커리어패스 개발 부분은 연차를 불문하고 알아야 하는 내용 같아서 관심을 가지고 읽어보았습니다.

​

23장의 경우에는 실제 상황별 시나리오와, 대화 예시들이 나와있어 재미있게 읽었고, 

(대화 예시들의 경우 팀 분들 사이의 대화에서 본 적이 있나 싶은 기시감이 들어서 흥미로웠던 것 같습니다.)

24장의 경우 어떻게 커리어를 이어나갈 것인지에 대한 이야기보다는, 

이 부분은 아키텍트에 초점이 많이 맞춰서 있던 느낌이라 원하던 내용은 아니어서 좀 아쉬운 느낌이 들었습니다.

​

11월의 서평단 후기

책을 선택할 당시에 제가 생각했던 구성의 책은 아니었지만, 

소프트웨어 아키텍처 자체 뿐 아니라 소프트웨어 아키텍트의 역할과 소양에 대해서 폭 넓게 익힐 수 있는 책이었습니다.

최근에 유행하고 있는 소프트웨어 아키텍처에 대해 궁금한 분들이나,

아키텍트라는 직업 또는 역할에 관심이 있는 분들 모두 한 번 읽어보면 좋을 것 같습니다.

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

이 글은 2021년 11월 한빛미디어에서 진행하는 <나는 리뷰어다> 프로그램에 참여하게 되어 책을 제공받아 글을 작성하였습니다.

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

만약 이 글을 읽는 사람이 개발자라면, 소프트웨어 구조 혹은 소프트웨어 구성 조직이라고 말 할 수 있을 것이다.

그렇다면 소프트웨어 구조는 왜 필요하며 왜 중요할까?
흔히 아키텍처를 잘못 설계 하면, 속도 저하 및 무리한 리소스 사용등 다양한 이유가 될 수 있다.
오늘은 우리가 흔히 말하는 소프트웨어 즉, 프로그램 구조를 설계하는 방식에 대해 작성 되어 있는 책에 대해 서평을 작성학고자 한다.

책 소개

이 책은 아키텍처의 모듈성, 특성, 컴포넌트등 기초부터 여러가지 스타일에 대해 글과 그림으로 쉽게 설명하고 있다.

그 만큼 글만 있는 책에 비해 그림이 함께 나와 있어 초보자도 쉽게 이해 할 수 있다. 또한 다양한 아키텍처 스타일에 대해 작성되어 있어 그에 맞는 특징들을 쉽게 이해하고 실무에 적용 할 수 있을 것 같다는 생각을 하였다.

예상 독자

이 책은 컴퓨터 전공자 혹은 개발자로 일 하는 사람에게는 필수로 읽어야 하는 도서 중 하나라고 말 할  수 있다.

그만큼 내용이 쉽게 이해가 되었다. 특히 그림으로 설명이 되어 있어 누구나 쉽게 이해 할 수 있었다.

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

2021년 11월에 출간된 따끈따끈한 신작 <소프트웨어 아키텍처 101>에 대해 소개합니다. 이 책의 부제는 '엔지니어링 접근 방식으로 배우는 소프트웨어 아키텍처 기초'입니다. 이 책의 저자는 Mark Richards와 Neal Ford로 CS 세계에 발을 들여놓았다면 많이 들어본 이름일 것입니다. 이 세계에서 매우 유명한 분들입니다. 

이 책의 원서는 아마존 리뷰에서 높은 점수(4.6점, 5점 만점)를 받았습니다. 역자는 이일웅 님으로 그동안 이분의 책을 많이 읽어봐서인지 어색한 부분은 거의 없었습니다.

<소프트웨어 아키텍처 101>은 470페이지로 구성되어 있어 휴대하면서 읽기에 부담스럽지 않습니다. 다만 최근 출시된 한빛미디어 책은 전차책으로도 출간되므로 전자책을 읽을 수 있는 장치를 보유하신 분이라면 전자책으로 만나보는 것도 좋을 것 같습니다. 구매 가격도 더 저렴합니다. 

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

이 책의 매력은?

<소프트웨어 아키텍처 101>은 3부 24개의 챕터로 구성되어 있습니다. 중요하지는 않지만, 첫 번째 챕터(Introduction)가 큰 부(장)에 속하지 않은 부분에서 재미있는 편집이라고 생각했습니다.

1부에서는 아키텍처적 사고, 모듈성, 아키텍처 특성에 대해 안내합니다. 즉, 아키텍처가 무엇인지에 대해 이야기하고 있으며 어떤 관점에서 바라봐야 하는지에 대해 소개합니다. 2부에서는 다양한 아키텍처 스타일을 보여줍니다. 모놀리식과 분산 아키텍처에 대해 논하는 것을 시작으로, 레이어드 아키텍처 스타일에서 마이크로서비스 아키텍처 스타일까지 다양한 아키텍처 스타일을 소개합니다. 이 장을 읽을 때, 그동안 직/간접적으로 경험했던 아키텍처 스타일을 정리할 수 있으며, 다양한 관점에서 공감하며 읽을 수 있을 것 같습니다. 3부는 테크닉과 소프트 스킬이라는 주제로 아키텍트로 성장할 때 필요한 기술들을 소개합니다. 꼭 아키텍트가 아니더라도, 한 번쯤 읽고, 정리하고 자기 또는 팀에 알맞게 교정한다면 큰 도움을 받을 수 있습니다. 

이 책은 앞에서도 이야기했지만, 이 책은 한 번 꼭 읽어봤으면 합니다. 아키텍트가 아니더라도, 내가 만들어야 하는 시스템이 어떤 모양을 가졌는지 큰 그림을 그린 다음 설계를 하고 코드를 작성한다면, 더 좋은 결과물을 도출해 낼 것으로 믿기 때문입니다. 또한, 어떤 요구사항에 직면했을 때, 문제를 해결하기 위한 더 나은 해결 방안을 제시할 가능성이 더 높을 것으로 생각합니다. 

사견으로, 가능하다면 이 책에서 제시하는 아키텍처 스타일을 적용한 애플리케이션을 작성해 보면 좋을 것 같습니다. 스터디 그룹 같은 것을 만들어 하나하나 만들다 보면 그 과정에서 꽤(?) 다양한 경험과 지식을 쌓을 수 있을 듯 합니다. 
 

마치면서

평소에 이 책의 주제에 대한 관심이 높아서인지 많이 익숙했던 주제여서 더 재미있게 읽었던 것 같습니다. 필자는 책을 읽고, 내재된 지식을 정리하는 데 많은 도움을 받았습니다. 이 책을 2주만에 읽고 리뷰를 하는 것은 쉽지 않았습니다. 매력적인 책이기에 다시 한 번 정독을 하며 개인적으로 정리하는 시간을 가지려 합니다. 

이 도메인에 익숙하지 않은 분들은 <소프트웨어 아키텍처 101>을 활용하여 시작하면 많은 도움이 될 것 같습니다. 실제로 이 도메인을 처음 학습하면, 갈지자로 횡보하는 사람들을 많이 보게 됩니다. 이 책을 먼저 읽는다면, 이런 비효율을 조금이라도 줄여줄 수 있지 않을까? 란 생각이 들었습니다. 

<소프트웨어 아키텍처 101>은 매력적인 도서입니다. 이 책에는 다양한 아키텍처 스타일이 나오는데, 각각의 아키텍처가 어떤 과정을 거쳐 발전했는지 등을 살펴보면 조금 더 흥미를 느끼면서 재미있게 학습할 수 있을 것 같습니다.  

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





 엔지니어링 접근 방식으로 배우는 소프트웨어 아키텍처 기초라는 표지 문구와 함께 시작한다.

 대부분의 나의 경험에 의하면 우리는 IT개발 중에 SW웨어 개발을 담당하면서 아키텍처라는 것과는 대부분의 연관성이 거의 없다고 생각할 수 있다. 나의 IT개발의 역사는 SI이었기 때문에 더욱 그럴 것이다. SI의 특성상 아키텍처를 담당하는 사람들은 몇사람 안되고 대부분의 업무개발자 일 것이다. 아키텍처라는 말은 대부분이 알고 있겠지만 본인의 업무와는 상관이 없다고 느껴질 것이다.

 하지만 개발을 하는 것에 있어서 아키텍처는 알면 알수록 많은 도움이 되고 있는 것이 사실이다. 개발을 하면서 아키텍처를 모른다는 것은 숲을 보지 않고 나무만 보는 것이라고 할 수 있을 것이다. 그런 점에서 이책을 통해서 아키텍처에 대한 전체적인 내용을 알 수 있어서 좋았다.

 특히 아키텍처 스타일에서 여러 아키텍처 스타일을 보여주면서 그 각각의 특성을 알 수 있어서 좋았다. 또한 요즘 각광받고 있는 MSA나 이벤트 기반 스타일을 알 수 있어서 좋았다.

 아키텍트를 꿈꾸는 사람이라면 꼭 봐야할 책이라고 할 수 있다.

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

컴퓨터공학을 전공하고 20년 현업 개발자로 일하면서 한번 커리어 패스를 밟아 보고 싶었던 것이 아키텍트이다.

뭐 그간 쌓아온 커리어나 전문영역에서의 제한적인 아키텍쳐를 설계하는 것은 전문적인 아키텍트 만큼은 아닐지라도 제법 자부심을 가질만큼의 역량은 된다 생각하지만 좀더 큰틀에서의 아키텍트를 해보고 싶다는 생각은 맘 한켠에 여전히 남아 있다.

일반적인 IT 개발자가 아키텍트로 전향하거나 성장하는 것은 현실세계에서 그리 많지는 않는 것 같다. 따로 교육체계 내에서 배우기도 쉽지 않고 참고할 만한 관련된 서적 같은것도 그다지 없고 회사에서 그런 부서에서 애초에 시작해서 맨땅에 헤딩하며 차근차근 밟아나가지 않는 이상 그런 기회는 사실상 거의 없다시피한게 맞다고 해야할 것이다.

재미난 책이 있다, ' 소프트웨어 아키텍처 101'   

소프트웨어 아키텍트를 꿈꾼다면 반드시 그리고 제일 첫번째로 읽어야하는 필독서라 생각한다. 아키텍트와 아키텍처에 대한 기본적인 역량을 익힐 수 있는 가장 좋은 입문서이지 않을까? 이 책은 이러한 극찬을 받아도 마땅하다.

필자는 한 10여년 정도 엔터프라이즈 환경에서 통합 인터페이스 허브를 구축하는 일을 했었다, 인프라성 미들웨어를 기반으로 하는 업무다 보니 개발에 대한 역량과 IT 전반에 걸친 지식도 중요하지만 소위말하는 아키텍팅에 필요한 역량이 더욱 중요한 업무이나, 선배들 어깨너머로 배우고 무수히 많은 시행착오를 거치면서 그래도 어디가서 차세대 프로젝트의 인터페이스 통합 업무를 맡아서 진행하거나 프리세일즈 정도는 할 역량과 경험을 가지고 있다고 생각한다.

하지만 여기까지 올때까지 너무나 많이 돌아왔다, 너무 주먹구구식으로... 이 업무를 처음 맡았을 당시 체계적인 교육 같은건 없다보니 별도로 어떻게든 공부를 해야했고 그때 봤던 책이 '기업 통합 패턴'이라는 책이었는데 딱 내게 필요했던 책이나 번역이 좀 그래서 그런지 몰라도 너무 원론적이고 딱딱해서 그다지 재밌게 읽었다는 느낌이 없다, 그냥 필요에 의해서 읽어 내려갔을뿐... 

http://yes24.com/Product/Goods/14631181 

근데 '소프트웨어 아키텍처 101' 이 책은 좀 다르다, 달라도 한참 다르다.

이 책은 단순히 여러 패턴의 아키텍처를 소개하는 정도에서 그치는게 아니다. 총 3부로 구성되어 있는 이 책 특징은 1부에서 소프트웨어 아키텍처 그리고 아키텍트에 대한 내용과 일반적인 개발자와 차이점에 대한 내용을 다루고 3부에서 아키텍트에 필요한 소프트 스킬에 대한 부분까지 언급하고 있다. 이 부분이 관련 분야의 다른 책들과는 차별화 되는 요소라 생각한다.

아키텍처와 관련된 책이다 보니 풍부한 그림을 포함하여 설명하는 것은 당연하다.

그리고 거의 매 챕터 말미에 관련된 사례를 살펴볼 수 있는 내용을 포함한다, 해당 챕터 내용을 현장에서 어떻게 적용해볼 수 있을지 가늠해볼 수 있는 좋은 내용이라 생각한다.

이런 책이 나오길 학수고대 했었다.

아키텍트를 꿈꾸는자, 시스템이나 서비스를 구상하고 설계하는 자, 이 책은 그들에게 새로운 인사이트를 선물해 줄 것이다.

아키텍처.
'건축양식'이란 의미지만, 소프트웨어 업계에서는 흔히 설계자란 의미로 쓰이고 있다.
초창기 소프트웨어 산업이 만들어지면서 '만든다'는 의미에서 건축업계 용어를 많이 사용하고 있다.
IT 산업이 발전되면서 점점 그 색채가 옅어지기는 하지만 아직 큰 구조적 맥락에서는 이미 굳어져버린 용어라 계속해서 쓰이고 있다.

'아키텍처'라고 하면 개발자들의 마지막 커리어라고 할 수 있다.
프로덕트 매니저, 프로덕트 오너는 기획, 디자인 파트에서도 가능하지만 아키텍처는 대부분 기술 기반의 개발자 출신들이 많다.
기술에 대한 이해가 풍부해야만 가능한 영역이기도 하다.

아키텍처란 직책에 기술적 정의도 모호하고 업무 범위 또한 그러하다.
예전에는 백앤드, 프론트앤드, 그리고 시스템에 대한 지식과 경험이 있는 개발자가 가능한 영역이였지만, 요즘은 별도의 영역으로 전문 인력들이 나오고 있다.

아키텍처에 대한 책이 그리 많지는 않다.

더구나 지금까지의 책들은 최근의 변화를 제대로 담고 있지 못하고 있다.
기술의 변화는 1년에도 몇 번씩 바뀌는데 그 기술을 담아야 할 아키텍처 분야라고 바뀌지 않을까?
위에서 말한바와 같이 아키텍처는 업무와 기술범위가 조직마다 조금씩 다르기에 표준화된 문서나 책을 만나보기 어려웠다.
그래서, 이 책 '소프트웨어 아키텍처 101'이 너무 반가웠다.

저자들의 풍부한 경험과 최근의 트랜드를 이 책 한 권에 잘 담았다.
책은 크게 3부로 나누어져 있다.
1부에서는 아키텍처란 무엇인지를 설명하고 있다.
어떤 기술과 사고방식을 갖추고 있어야 하는지에 대해 말해주고 있다.
2부에서는 다양한 아키텍처 스타일을 보여준다.
왠만큼 다양한 도메인 경험이 있지 않고서는 이런 다양한 아키텍처를 모두 만나 볼 기회가 없을 것이다.
그리고 자신이 편안하게(?) 느끼는 분야에서만 일하기에 이 모두를 접하기 어렵다.
(나만 그런가?)
3부에서는 아키텍처가 갖추어야 할 자질과 기술에 대해 말하고 있다.
최근의 기술들도 소개하고 있기에 바로 실무에 접목할 수 있는 방법들을 만나볼 수 있다.

워낙 관심이 많은 분야였기에 모두가 흥미로웠지만, 가장 좋았던 부분은 1부였다.
2부의 아키텍쳐 스타일은 계속 추가될 것이고, 3부의 기술들은 변형되거나 새로운 것들로 대체될 수 있다.
하지만 '아키텍처'에 대한 본질적 정의와 의의는 변하지 않고 계속될 것이다.
특히 '트레이트오프'에 대한 정의가 너무 좋았다.

소프트웨어 아키텍처 제 1법칙으로 소개하고 있다.
무언가를 얻기 위해서는 다른 것을 희생할 수 있어야 한다.
제한된 자원-시간, 돈 등-으로 모든 것을 충족시킬 수 없다.
한정된 자원으로 가장 효율적인 방법을 찾는 것이 아키텍처이다.

우리는 트레이드오프 분석이라는 중대한 이슈도 다루었습니다.
소프트웨어 개발자는 어떤 기술이나 접근 방식에 마음을 빼앗기기 쉽지만, 아키텍트는 언제나 모든 선택의 좋고 나쁨을 냉졍하게 평가해야 합니다.
실로 이 세상에는 모 아니면 도 식으로 간편하게 결정할 수 있는 건 하나도 없습니다.
만사가 다 트레이드오프죠.

어느 직종이나 일종의 직업병이 있겠지만 소프트웨어 개발자들에게는 '기술'이 그러하다.
자신이 만들어 온 기술과 방법, 프로그래밍 언어에 대한 맹목적인 믿음이 대표적인 예라고 할 수 있다.
제대로 만들었고 정상적으로 작동하기에 문제가 없다.
다만 시간이 지나면서 더 나은 기술, 더 좋은 방법이 있음에도 기존의 것을 고집한다면 문제가 되는 것이다.
금융기관의 예를 들자면 예전의 코볼이 그랬고, 현재의 자바가 그러하다.
IT 강국이라고 하는 우리나라지만 다양성의 면에서 보면 결코 그렇지 않다.
그렇기에 '트레이드오프'가 주는 의미가 무척 깊게 다가온다.

역할, 직책, 직무에 상관없이 소프트웨어 아키텍트에게 바라는 핵심적인 요구사항은 다음 여덟가지로 정리할 수 있습니다.

• 아케텍처 결정을 내린다.
• 아키텍처를 지속적으로 분석한다.
• 최신 트랜드를 계속 유지한다.
• 아키텍쳐 결정의 컴플라이언스를 보장한다.
• 다양한 기술과 경험에 노출된다.
• 비즈니스 도메인 지식을 보유한다.
• 대인 관계 기술이 뛰어나다.
• 정치를 이해하고 처세를 잘한다.

저자들은 불투명한 아키텍트의 업무를 위와 같이 정의했다.
마지막 '정치를 이해하고 처세를 잘한다'가 좀 이질적으로 느껴지지만 아키텍처의 업무를 생각한다면 어쩌면 가장 필요한 자질일지로 모른다.
실제로 아키텍처의 업무 중 가장 많은 시간을 차지하는 것인 회의다.
다양한 부서와의 협업이나 조율이 필수적이기에 정치와 처세, 대인 관계 기술은 필수라고 할 수 있다.

아키텍처라는 업무가 생기기 전에는 시니어 개발자가 그 업무를 맡아왔다.
다양한 경험과 깊은 지식을 바탕으로 기술적 조언을 한 것이다.
하지만 아키텍처는 '좁고 깊은 지식'이 아니라 '넓고 얕은 지식'이 있어야 한다.
'어떻게'가 아니라 '무엇을' 결정하는 자리이기 때문이다.
망치만 들고 있는 사람은 벽에 옷을 걸기 위해 못을 박으려고 하지만, 간단하게 접착식 옷걸이로 해결할 수도 있다.
아키텍처는 문제를 해결할 수 있는 다양한 방법을 알고 있어야 하고, 그것을 제시할 수 있어야 한다.

아카텍트는 아키텍처와 설계 원칙을 결정하고 팀, 부서뿐만 아니라 회사 전체의 기술 결정을 가이드하는 사람입니다.
아키텍트는 기술 선택을 가이드하는 사람이지, 정해주는 사람이 아닙니다.

가장 오해가 많은 부분이 아닐까 싶다.
아키텍트는 '가이드'를 하는 사람이지 '정하는' 사람이 아니다.
현장에서 많이 오해하고, 잘못 실행되고 있는 부분이다.
아키텍쳐가 경험이 많기에 정해주길 원하거나, 정한대로 개발해 주길 원한다.

책을 보면서 그동안 잘못 알고 있었던, 그리고 몰랐던 아키첵처의 세계에 대해 많이 배울 수 있었다.
아키텍처가 되기 위해서는 깊은 경험보다는 다양한 경험과 폭넓은 지식이 있어야 한다.
그리고 언제든지 '트레이드오프'를 할 수 있는 용기도 필요하다.

최근의 기술과 트렌드를 보여주는 아주 오랫만에 흥미진진하게 볼 수 있는 아키텍처 책이다.
이 책으로 아키텍처 분야도 기술 분야처럼 최신화 되었으면 하는 바램이다.

마크 리처즈, 닐 포드 지음 / 이일웅 옮김

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

11월

나는 리뷰어다 활동의 10번째 리뷰.

(벌써 10번째 리뷰라니!!! 한빛미디어 항상 감사합니다. 내년에도 잘 부탁드려요!!)

2021년 한빛미디어의 리뷰어로 활동하면서 책 제목으로만 봤을 때 가장 어려워 보이는 책이다.

아키텍처라는 단어만 들어도 흐음... 하게 되니 말이다.

하지만 우리 개발자분들 너무 겁먹지 말자. 우리 주니어를 위한 소프트웨어 아키텍처 기초다. 기초!

소프트웨어 아키텍트는 전문가로 간주되는 소프트웨어 개발자로서, 고수준의 설계를 결정하고 소프트웨어 코딩 표준, 도구, 플랫폼 등의 기술 표준을 지시한다. - 위키백과

당장 옮긴이의 말부터 어렵다. 고수준이라니. 하지만 한번 더 힘을 내보자.

'아키텍트에게는 기술의 깊이보다 폭이 더 중요하다'

'아키텍트는 기업의 정치 기류를 이해하고 처세를 잘해야 한다'

이 두 문장에서 무언가가 느껴진다면, 꼭 완독하겠다는 마음으로 책을 구매하자.

(한빛미디어 감사합니다. 저는 작은 희망을 보았습니다.)

공리 axiom

- 이미 정립되고 받아들여졌거나 그 자체로 자명한 명제 또는 정리

소프트웨어 아키텍트는 공리를 토대로 이론을 만들지만 수학보다 더 소프트하기 때문에 이론의 기반이 되는 기초 자체가 계속 빠른 속도로 변한다. 소프트웨어 개발 생태계는 일정한 동적 평형 상태로 존재한다. 즉, 어느 시점에서는 균형이 잡힌 상태이지만 장기적으로는 동적인 움직임을 나타낸다. 요즘 대세인 컨테이너화와 그로 인한 변화를 그 예로 들 수 있는데, 10년 전에는 없던 도구가 글로벌 소프트웨어 콘퍼런스도 열릴 정도로 성장했다.

하나의 작은 변화가 또 다른 작은 변화를 일으키고, 그런 일이 수백 회 반복되면 또 다른 생태계가 새로 탄생한다.

그래서...(아직 저자가 무슨 이야기를 하고 싶은지 모르겠다)

아키텍트는 이전 시대에서 물려받은 가정과 공리에 의문을 제기할 중요한 책임이 있다.

새로운 시대에는 그에 걸맞는 새로운 프랙티스, 도구, 측정, 패턴 등 많은 변화가 필요하다.

그리하여, 이 책은 지난 10년 동안 일어난 모든 혁신과 더불어 오늘날의 새로운 구조와 관점에 부합하는 새로운 지표를 바탕으로 소프트웨어 아키텍처를 현대적인 관점에서 살펴보려고 한다.

이 책은 이미 잘 알려진 패턴을 다루지만 산지식, 도구, 엔지니어링 프랙티스, 그 밖의 다른 입력에 기반한 새로운 접근 방식으로 바라본다.

그래서 기존 소프트웨어 아키텍처에서 당연시됐던 많은 공리들을 최근 생태계와 설계 아키텍처의 관점에서, 그리고 요즘의 전반적인 추세와 비교하여 다시 한번 돌아보는 책이다.

챕터를 보자

CHAPTER 1 서론

[PART I 기초]
CHAPTER 2 아키텍처 사고
CHAPTER 3 모듈성
CHAPTER 4 아키텍처 특성 정의
CHAPTER 5 아키텍처 특성 식별
CHAPTER 6 아키텍처 특성의 측정 및 거버넌스
CHAPTER 7 아키텍처 특성 범위
CHAPTER 8 컴포넌트 기반 사고

[PART II 아키텍처 스타일]
CHAPTER 9 기초
CHAPTER 10 레이어드 아키텍처 스타일
CHAPTER 11 파이프라인 아키텍처 스타일
CHAPTER 12 마이크로커널 아키텍처 스타일
CHAPTER 13 서비스 기반 아키텍처 스타일
CHAPTER 14 이벤트 기반 아키텍처 스타일
CHAPTER 15 공간 기반 아키텍처 스타일
CHAPTER 16 오케스트레이션 기반 서비스 지향 아키텍처 스타일
CHAPTER 17 마이크로서비스 아키텍처 스타일
CHAPTER 18 최적의 아키텍처 스타일 선정

[PART III 테크닉과 소프트 스킬]
CHAPTER 19 아키텍처 결정
CHAPTER 20 아키텍처 리스크 분석
CHAPTER 21 아키텍처 도식화 및 프레젠테이션
CHAPTER 22 개발팀을 효율적으로
CHAPTER 23 협상과 리더십 스킬
CHAPTER 24 커리어패스 개발
Appendix A 자율 평가 문제

굉장하다. 챕터만 봐도 숨이 막힌다. 아무래도 아키텍처는 내 길이 아닌가 싶기도 하지만,

깊은 지식 없이 얄팍하게 두루두루 알고 있는 본인을 보자면 또 이 쪽은 어떨까 싶은 생각이 든다.

아직 책을 다 보진 않았지만, 책 자체는 정말 굉장히 좋은 책이라고 생각한다. 전혀 생소한 분야 같지만 생각보다 접근성이 좋았고,

기초적인 내용들로 시작하면서 어렵지 않게 느끼게 해 주었다.

또한 기초를 보고 있는 나 자신이 많이 부족하다고 느낀다면 그건 당연한 것이라 생각한다.

어찌 보면 제너럴 한 개발자의 길보다는 험난함이 예상되지만 그만큼 돌아오는 베너핏이 다르리라.

가는 길이 힘들 땐 선배들의 명언이 힘을 줄 것이다.

막연하게나마 아키텍처에 대한 관심이 있는 자들이여. 꼭 이 책으로 시작해보라.

본인도 꼭 완독 할 테니!!

훌륭한 건축물을 만들기 위해서는 훌륭한 설계도가 필요하다. 마찬가지로 훌륭한 소프트웨어를 만들기 위해서는 훌륭한 아키텍처가 필요하다. 너무나 단순하고 명료한 진리임에도 불구하고 아키텍처의 중요성을 간과하는 케이스는 도처에서 쉽게 목도되곤 한다. 그저 동작하기만 하는 소프트웨어를 만들고 그것을 서비스로 고객에 전달하며, 그 이후에 발생 되는 자잘한 결함과 오류, 그것들을 처리하기 위해 다시 수 많은 인력이 시간과 비용을 투입하며 고군분투하는 경우를 우리는너무 흔하게 접해 왔고 지금도 그런 사례들이 우리 주위에 회자되곤 한다. 그렇다면 이렇게 하지 않기 위해서 우리는 무엇을 할 수 있을까? 어떻게 하면 훌륭한 소프트웨어를 만들 수 있을까 하는 질문에 대한 답을 오늘 소개하는 서적이 제공하고 있다. 

소프트웨어의 뼈대를 지탱하는 설계도는 바로 이키텍처다. 이 아키텍처를 만들기 위해서는 아키텍트가 소프트웨어 개발 현장의 중심에 서있고, 그는 수 많은 이해관계자들과 다양한 요구사항을 청취하고 트레이드 오프를 따져 보며 종국적으로 소프트웨어의 근간인 아키텍처를 설계한다. 그 이후 채택 된 아키텍처는 다양한 이해관계자들에게 전달되어 소프트웨어 개발이 진행 되고 비로소 완성된다. 결국 소프트웨어 아키텍처는 소프트웨어를 지탱하는 주춧돌이자 핵심이라 할 수 있겠다. 

이 책은 소프트웨어 아키텍처 설계 과정에 있어, 다양한 아키텍처 패턴과 아키텍트에게 필요한 소프트 스킬과 여럿 유용한 팁을 제공하는 훌륭한 아키텍처 설계 지침서라 요약할 수 있다. 모놀리스로 부터 시작하여 마이크로 서비스 아키텍처(MSA)로 끝나는 소프트에어 아키텍처 패턴을 통해 다양다종한 아키텍처의 변종과 진화한 유형을 거쳐, 작금의 클라우드 네이티브 환경에 걸맞는 아키텍처가 MSA임을 은연중에 깨닫게 된다. 

각설하고 본 서적은 다양한 아키텍처 패턴의 본질과 케이스를 통해 해당 아키텍처의 장단점을 각각 비교하며 결국 저자가 설파하는 아키텍처를 설계하는 궁극의 요소는 바로 '트레이드 오프'와 '최악의 아키텍처를 피하고 차악의 아키텍처를 선택한다'라는 것으로 귀결된다. 책의 첫 장을 넘기며 완독한 이후에 머릿 속에 맴도는 가장 주요한 2가지 원칙, 이것은 아직까지도 마음 속 깊은 곳을 강렬하게 자리잡고 있음을 고백하지 않을 수가 없다. 

아키텍처 패턴은 정형화 되어 있지만 한 시대를 풍미하는 IT 패러다임과 트렌드에 의해 진화되고 발전 되고 있다. 그 수 많은 패턴 중 어떤 것을 선택할지는 아키텍트의 수 많은 고민이 투사되며, 다양한 이해관계자들과의 끊임 없는 소통을 통해 다듬어지고 결국엔 하나의 선택지가 채택 된다. 하지만 그 선택지가 정답은 아니며 언제라도 그것은 변경 될 수 있고 갈아 치워질 수도 있음을 우리는 인지해야 할 것이다. 계속해서 변화하는 환경 속에서 강건한 아키텍처로 자리 잡는 최고의 아키텍처는 존재하지 않는다. 다만 우리가 선택한 아키텍처는 트레이드 오프에 대한 철저한 계산과 차악을 채용한 결과임을 잊지 말아야 할 것이다. 

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

[도서리뷰] 소프트웨어 아키텍쳐 101 Fundamentals of Software Architecture

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

제목에서 보여진는것 처럼 소프트웨어 아키텍처에 대한 기본부터 알려줍니다. 
아키텍트란 무엇인지, 아키텍트가 아키텍처를 디자인 할 때 고려할 사항들은 무엇인지에 대해 자세히 다루고있고, 중반부로가면 상황에 맞게 필요한 유명한 아키텍처 스타일에 대한 설명이 있습니다.

 이미 아키텍트이신 분 보다는 주니어 혹은 미들급 개발자가 읽으면 좋은 내용입니다. 개발자라면 아키텍트가 어떤 일을 하는지는 막연하게나마 알고 있겠지만 책을 읽어보면 아키텍트 라는 흐릿한 바운더리에 확실한 경계가 생기는 느낌이 듭니다. 그만큼 구체화가 된다는 의미이지요.

모든 개발자는 아키텍트의 역할을 동시에 수행하고 있습니다. 작은 함수 하나를 작성하거나, 리펙토링을 할때도 아키텍처에 대한 고려를 하게 되고, 아키텍트적인 사고를 필요로 합니다. 이책을 통해서 이미 유명한 아키텍처들이 어떤 이유로 디자인 되었고, 어떤 상황에서 사용되고, 어떤 트레이드 오프가 있는지에대해 알 수 있고, 여기서 얻은 지식은 개발을 할때 바로바로 적용 될 것이라는 생각이 듭니다.

아직 학생이신 분들 보다는 이미 현업에서 1~2년정도의 경험을 가지고 계신 개발자 분들에게 추천드립니다. 

출처: https://devms.tistory.com/574 [요가하는프로그래머]



한빛미디어 "나는 리뷰어다" 도서 리뷰를 하면서, 이번엔 정말 마음에 드는 아키텍처 책을 만났습니다.

첫째, 아키텍처에 대한 책이기 때문입니다. (무슨 뚱단지 같은 소리냐고요 ^^) 소프트웨어 구조에 대해 항상 관심을 가져왔기 때문에, 아키텍처에 대한 책을 읽어보고는 싶은데, 손을 뻗치기는... 용기가 나지 않는 책이 아키텍처에 대한 책이거든요. 그런데 반강제적으로 읽게 되었으니 좋았습니다.

둘째, "닐 포드"가 저자라서 좋았습니다. 닐 포드의 책은 지금까지 두 권 읽었었는데요. 읽을 때마다 만족스럽게 읽을 수 있었습니다. 먼저 2010년에 읽었던 <능률적인 프로그래머>라는 책은 다양한 "통찰"을 제공한 책이었습니다. 특히 <능률적인 프로그래머>에서 나오는 "성난 원숭이 떼"이야기는 제가 상당히 자주 인용하게 되는 이야기 거든요.

두번째, 2016년에 읽은 <함수형사고>도 정말 재미있었습니다. 특히 "나무꾼과 전기톱"에 대한 비유는 정말 많은 것을 생각하게 해주는 비유였고요.

이 책 역시 아키텍처에 대한 책 답지 않게 술술 읽히는 책이었습니다. 특히 소프트웨어 기술이 발전하면서 요즘의 소프트웨어 아키텍처는 예전과 많은 차이가 나게 되었는데요. 그 부분까지도 반영하려고 노력한 점이 상당히 돋보이는 책이었습니다.

이제 애자일을 하는 조직이 많아지고 있고, 익스트림 프로그래밍에서 파생된 CI/CD와 이를 체계화한 DevOps가 소프트웨어 조직 전반에 퍼져가고 있는 상황에서 이런 기술들이 역으로 소프트웨어 아키텍처에 영향을 미치는 그런 상황이 되었는데요. 그러다보니 마이크로 서비스 아키텍처 같은 개념들이 나오면서, 예전에는 전혀 상상도 하지 못했던 복잡한 구조가 가능해지고, 어쩌면 소프트웨어 아키텍트가 따로 손을 댈 필요가 없이 다들 가는대로 가면 되는 상황이 되고 있는 것이죠.

하지만 소프트웨어 아키텍트는 "뭔가 결정 내리는 사람"입니다. 좀더 넓은 안목을 가지고 기술적인 것을 뛰어넘어서, 비즈니스 적인 지식도 섭렵하면서 다시 다양한 기술의 특징을 감안해서 트레이드 오프를 해내는 사람들입니다.

저는 아키텍트 부서가 따로 있는 회사를 다닌적이 없고, 대부분 시니어 개발자로서 소프트웨어 구조를 잡을 때 영향을 미치는 정도로 소프트웨어 구조에 의견을 냈던 경험을 가지고 있습니다. 10년도 전에 운 좋게 프로젝트 리더로 일할 기회가 있었었는데요. 당시 신규 프로젝트의 구조를 고민하면서, 함께 일할 개발자들과 이야기해서 이벤트 기반으로 프로세스를 관리하는 구조를 사용하기로 했었습니다. 당시에 아키텍처에 대한 지식이 전무하기는 했지만, 이벤트 기반으로 프로세스들을 관리하다보니, 꽤 튼튼한 구조를 가질 수 있었고, 경쟁사에 비해 좋은 결과를 만들 수 있었습니다. 그리고 사내에서 사용할 자바스크립트 프레임워크를 개발한 경우도 있습니다. 이때는 아직 이것이 정답이다라고 얘기할 만한 프레임워크가 없었던 시기이기 때문에, 자바스크립트 코드 구조를 규정하는 쪽에 주안점을 둔 프레임워크를 만들었었습니다. 계층구조를 가지고 프리젠테이션 레이어와 어플리케이션, 도메인 레이어를 강제로 분리하게 하여 복잡도를 낮추게 했습니다. 그 결과 여러 프로젝트에서 함께 사용할 수 있는 프레임워크가 되었고, 꽤 오랜 기간 회사에서 사용했었습니다.

"무엇을", "어떻게"에 대해 개발자들이 힘을 쏟을 때 누군가는 "왜"에 대해서도 고민해야 할 필요가 있습니다. 좀 외로울 수도 있지만, 소프트웨어 아키텍트는 "왜"를 고민하는 사람이 아닐까 싶습니다. 그리고 없어도 될것 같지만 상당히 중요한 일을 읽기 편하게 잘 설명해 준책이 바로 <소프트웨어 아키텍처 101>이 아닌가 싶습니다.

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



해당 책을 신청한 목적은 프로그램을 만들 때 어떤 것을 어떻게 구조를 짜면서 만들어 가야 하는 지 참조하고 싶어서 였다..

연구소에 있다 보니, 팀에서 무엇을 하면, 어쩌다 보니 하는 일이 혼자서 코드를 짜고, 혼자서 평가하고, 다 혼자서 하는 것이라서, 너무 주먹구구 같다는 느낌이 컸다.  게다가 문과에 데이터 분석으로 시작한 것이라, 소프트웨어 개발론에 대해서는 거의 아는 것이 없어서 이 책을 읽으면 도움이 될 것이라는 생각에서 읽었다.

챕터 1을 넘어가면서, 아쉽게도, 나에게는 별로 도움이 되지 않는 다는 것을 깨달았다. 대규모나 상업적으로 만드는 책임있는 소프트웨어를 만드는 것이 아니라서, 요구 사항들이 매우 적은 부류이고 아직 나의 경험이 적었기 때문에 이해할 수 있는 부분 자체가 적었다.

즉, 해당 책은 오랜 기간 동안 개발 분야에 종사하면서 소프트웨어의 구조를 설계할 수 있을 정도의 지식을 가지고, 실제 개발자가 아닌 아키텍트로서 일을 시작하려는 사람들을 위한 책이라는 것이다. 

그렇기 때문에 이 책의 많은 부분을 이해하지는 못하고, ~같은 느낌이다로 넘어갔다. 

이 책에서 아키텍트는 도메인 지식을 가져, 그대로 구현하는 것이 아닌 현장에서 어떤 식으로 될지 대비하면서 요구 사항을 정의해야 하며, 이와 더불어 요구자가 인지 하지 못한 것까지도 미리 예상하고 방지시키는 구조를 설계해야 되는 것 같다. 

이렇게 쓰니, 무언가 아키텍트란 완벽 초인인 것 같은 느낌으로 썼는 데, 내용 상으로는 아키텍트는 자기가 하고 있는 역할을 단순하게 소프트웨어의 구조를 짜는 것이 아닌, 실제 소프트웨어가 상업화되었을 때, 안전하고 확장성있는 구조가 될 수 있는 지를 생각하면서 유연하게 생각하라는 것이다. 그리고, 이 책은 일종의 지침서이자 동시에 여러 아키텍처가 이런 양상으로 흘러간다는 것을 보여 주면서 참조하게 해준다.

본인에게는 너무 이른 책이었지만 도움이 안 되는 책은 아니었다. 본인이 만든 코드가 어떻게 들어 가서 어떤 파장을 일으킬 것인지를 예측이 되고, 그렇기 때문에 좀 더 견고하고 안전한 방법을 생각해 보게 하는 책으로, 웹개발을 처음하는 사람들이 읽으면 자신의 코드에 대해 생각할 여지가 많지 않을까 생각했다.

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

소프트웨어 개발 생태계는 빠르게 발전하고 있습니다.

소프트웨어 아키텍트의 역할도 많아지고 있는데요.

10년 전에는 주로 모듈성, 컴포넌트, 패턴 등 순수 기술적인 부분을 다뤘습니다.

마이크로서비스로 바뀌면서 훨씬 폭넓은 능력을 요구하게 됐습니다.

소프트웨어 아키텍처에 대해 잘 설명해주는 책을 소개해 드리겠습니다.

소개해 드릴 책은 ‘소프트웨어 아키텍처 101’입니다.

소프트웨어 아키텍쳐는 끊임없이 변화하는 생태계에서 결정을 내리는 사람들인데요.

이 책을 보면 변화하는 생태계에서 결정을 내리는 데 도움이 될 것입니다.

1) 소프트웨어 아키텍처란

아키텍처의 특성, 결정, 설계 원칙, 시스템구조가 결합된 구조입니다.

시스템 구조는 시스템이 구현된 아키텍처 스타일을 말합니다.

아키텍처 스타일에는 마이크로서비스, 레이어드, 마이크로커널이 있습니다.

아키텍처의 특성은 시스템의 기능을 보며 성공기준을 결정합니다.

아키텍쳐 결정은 시스템 구축에 필요한 규칙을 정한 것입니다.

규칙을 통해 시스템의 제약조건을 형성하고 해야 될 것과 하지 말아야 할 것을 정할 수 있습니다.

2) 아키텍처 사고

아키텍처 사고는 아키텍처의 관점으로 사물을 바라봐야 합니다.

크게 네 가지로 볼 수 있는데요.

첫 번째는 아키텍처 설계의 차이를 이해하고 개발팀과 어떻게 협력해야 할지 알아야 합니다.

두 번째는 일정 수준의 기술 깊이를 유지하며 폭넓게 기술 지식을 확보해두면 문제를 만났을 때 해결책을 떠올릴 수 있습니다.

세 번째는 솔루션과 기술을 이해하고 분석하고 조율할 줄 알아야 합니다.

마지막으로 비즈니스 목표를 이해하고 아키텍처 관심사로 해석할 줄 알아야 합니다.

Ps

아키텍트로 성장하고 싶다면 공부해야 할게 많습니다.

소프트웨어 아키텍쳐로 성장하기 위해 필요한 가이드북입니다.

그와 더불어 주요 개념은 다이어그램으로 한눈에 보기 쉽게 정리되어 있습니다.

또한 아키텍처의 흐름과 개발자의 생생한 조언도 실려있습니다.

아키텍트를 고민하는 분들에게 이 책을 추천합니다.

글만 있으면 따분하겠지만 그림을 통해 현대의 아키텍쳐를 쉽게 이해할 수 있습니다.

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

소프트웨어 아키텍처와 시스템 아키텍처는 무엇이 다른 것일까? 거의 20년? 훨씬 전부터 논해져오던 주제일 것이다. 하지만 모놀로식 시스템 구성에서 보다 복잡한 event driven이나 queue나 구독과 같은 다양한 요소들이 결합되어 시스템이나 서비스가 만들어지는 지금 이 경계는 보다 확실하게 선이 그어졌다고 봐도 과언이 아닐 것이다.

첫째로 시스템 아키텍처는 특정 시스템 혹은 컴포넌트의 성질에 한하여 구성된 아키텍처를 의미한다. 즉, 하나의 특정 성질을 기반으로 한 기능이 있다면 그 기능에 한한 아키텍처를 말하는 것이다.

둘째로 소프트웨어 아키텍처는 이러한 시스템 아키텍처로 이뤄진 다양한 요소들의 결합으로 이뤄진 전체 아키텍처를 의미한다. 어찌 보면 시스템 아키텍처의 상위 버전이라고 봐도 무방할 것이다.

그렇다면 소프트웨어 아키텍처는 시스템 아키텍처와 달리 어떤 해안을 가져야 할까?

그들은 무엇을 바라볼 줄 알아야 하고 어떤 능력을 갖춰야 할까? 확실한 것은 특정 도메인 한정적으로 지식을 보유하고 있어선 안된다는 점일 것이다.

소프트웨어 아키텍처는 나무보단 숲을 바라봐야 하는 사람이다. 그렇다고 시스템 아키텍처가 나무만 바라본다는 것은 아니다. 좀 더 포괄적인 범위에서 문제를 해결하기 위한 안목을 가져야 함을 의미한다.

이번에 출간된 "소프트웨어 아키텍처 101"이 바로 그런 소프트웨어 아키텍처가 가져야 하는 안목과 함양해야 할 능력이 무엇인지 잘 정리해둔 책이라 생각되며 소프트웨어 개발을 지향하는 사람들이라면 한 번쯤 꼭 읽어보길 권장하는 도서이다.

【책의 구성】 '소프트웨어 아키텍처 101'의 책의 구성은 어떠한가.

 이 책은 총 세 개의 파트로 구성되어 있으며 총 24개의 챕터로 이뤄져 있다. 책의 두께는 제법 있는 편이다. 450pg 정도 되는 양인데, 책의 구성과 내용이 좋아 쉽게 읽히는 편이므로, 두꺼운 책을 읽는데 어려움을 느끼는 독자라면 책을 여러 부분으로 나눠 조금씩 꾸준히 읽어가시길 권장한다.

이 책은 다양한 사례들이 소개되어 있고, 또한 그 사례 스터디를 통해 소프트웨어 아키텍처가 함양해야 할 능력과 자질에 대해서 잘 설명하고 있다.

첫째로 소프트웨어 아키텍처는 전달받은 명세를 기반으로 설계를 시작할 때, 쓰여있는 명세 내용 외에도 훨씬 멀리 내다볼 수 있는 해안을 가져야 한다.

가령 대학 수강 신청 시스템을 독자들이 구현하다고 생각해 보자. 이때 이 시스템이 가져야 할 가장 중요한 사항은 무엇이겠는가? 바로 탄력성이다.

탄력성을 갖춰야 하는 이유는 간단하다. 대학교에서 수강신청을 해본 사람은 알겠지만, 접속 5분 이내로 주요 신청 과목 (특히나 좋은 시간대의 수강 항목)은 수강 신청 시작과 동시에 엄청난 트래픽이 몰리게 되어있다. 그렇기에 이러한 탄력적인 트래픽을 감당할 수 있는 아키텍처가 사전에 준비되어 있어야 한다.

즉, 소프트웨어 아키텍처는 큰 배를 이끄는 선장이라 할 수 있다. 선장은 조타수와 갑판장 등의 모든 일을 디테일하게 알 순 없다. 그리고 알 필요도 없다. 단지, 큰 그림을 그리기 위한 지식으로써 넓은 지식에 대한 해안을 가지며 된다.

다음의 내용들은 이번 도서를 리뷰하면서 인상 깊었던 챕터 위주로 정리해 보았다. (어쩌다 보니, 앞장 위주가 되었다.)

1챕터 : 서론

 보통은 서론 내용은 책의 핵심으로 뽑지 않는 편이다. 왜냐하면 전체 내용을 포괄하여 설명하는 데에 그치는 것이 바로 서문이기 때문이다. (어찌 보면 가장 중요한 부분이라고도 할 수 있다.)

하지만 이번에 서문을 리뷰에 포함한 이유는 다음과 같다.

- 소프트웨어 아키텍처로써 함양해야 할 덕목과 능력에 대해서 논하고 있다

- 소프트웨어 아키텍처가 무엇인지에 대해서 설명하고 있다.

- 엔지니어링과 소프트웨어 아키텍처 링 위 차이가 무엇인지 논하고 있다.

- 이러한 사항들을 실제 한국의 개발 환경에 적용할 수 있을지 생각해게 한다. 정도를 꼽을 수 있다.

소프트웨어 업계에서 일한다는 것은 한시도 빠지지 않고 계속 공부를 해야 함을 의미한다. 솔직히 어느 분야가 되었건 산업 환경은 계속 변화한다. 변화는 환경 속에서 도태되지 않고 나아가는 방법은 더디더라도 꾸준히 학습하여 부족한 부분을 채워가는 것일 것이다.

세상은 변하지 않는다고 하는데. 세상에 변하지 않는 것은 없다. 엔트로피는 끊임없이 증가하는 방향으로 나아가고 있고 같은 뉘앙스의 문제를 대면할지라도 그 디테일한 내용은 어느 하나 같은 것이 존재할 수 없는 것이 세상의 이치이기 때문이다.

그렇기에 당면한 숙명을 받아들이고 꾸준히 학습하고 변해가는 세상에 적응하기 위해 분투할 줄 아는 덕목 역시 소프트웨어 아키텍처라면 당연히 지니고 있어야 할 덕목 중 하나이다.

또한 소프트웨어 아키텍처는 선장의 역할을 하는 포지션이다. 물론 한국 IT 업계에서 소프트웨어 아키텍처라는 직군은 따로 정해져 있지 않다. 보통 TL이나 leader 급 혹은 시니어 개발자들이 이러한 역할을 대신하거나 겸직하고 있다.

그렇기에 관련 포지션이 되면 보통 한 기술을 깊이 알기보단, 두루 넓게 아는 형태로 학습 형태와 기술 파악 형태를 바꾸게 된다. 이유는 간단하다. 보다 넓은 범위에서 기술의 접목점을 생각하기 위함이다. 소프트웨어 아키텍처는 기술을 두루 알아야만 한다. A라는 서비스를 만들 때 기술 도메인이 굉장히 한정적이라면 다양한 상황에서 탄력성과 내구성 그리고 확장성을 갖춘 소프트웨어를 설계하는 것이란 불가능에 가깝기 때문이다.

그 밖에도 기술의 최신 트렌드 파악, 비즈니스 도메인 지식 획득, 대인 관계 기술의 이해도의 전문화, 사내 정치와 형국에 대한 적절한 대응 능력 등을 책에서 손꼽고 있다.

이 중에 필자도 강조하고 싶은 부분이 있다면 "사내 정치와 형국에 대한 적절한 대응"을 손꼽고 싶다. 소프트웨어 아키텍처가 된다면 단연 사내의 흐름을 잘 이해해야 한다.

좋은 제품은 회사의 결정에 의해서 출시되게 되어있다. 아무리 제품이 좋아도 회사가 출시하지 않으면 말짱 꽝임을 명심하도록 하자.

8챕터 : 컴포넌트 기반 사고

 이 파트에서는 컴포넌트 기반의 사고의 중요성에 대해서 설명하고 있다. 컴포넌트를 어떤 식으로 구성하는 것이 옳은 일일지, 그리고 아키텍처라면 어떤 입장에 의거하여 명세의 흐름을 이해해야 하는지에 대해서 말이다.

가령 여러분은 실리콘밸리의 작은 IT 벤처를 운영하고 있다고 하자. 어느 날 실리콘 샌드위치라는 회사에서 연락이 왔다. 명세는 간단하다. 샌드위치를 실리콘밸리에 팔려고 한다. 주문과 제고를 컨트롤할 수 있는 시스템을 설계해 달라.

이제 여러분은 실리콘밸리에 있는 수많은 불쌍한 개발자에게 저렴한 샌드위치를 판매하기 위한 시스템을 개발하는 사명을 지게 되었다.

명세만 보아선 간단하다. 주문 및 제고 파악 시스템을 만들면 된다.

하지만 생각해야 할 지점은 수도 없이 많다.

주 고객은 누구일까? 어느 시간대에 트래픽이 몰릴까? 사용자들은 주로 어떤 플랫폼 상에서 주문을 진행할까? 이 시스템은 추후 전 세계로 확장할 것인가? 최대 동접은 어느 정도로 하는 것이 좋을까? 등등이 이에 속한다.

명세는 정말 간단했다. 한 줄이었다.

그런데 생각해야 할 포인트는 상당히 많았다. 위에 열거한 것만 들여다보아도 최소 5가지는 넘는다. 그렇다 소프트웨어 아키텍처는 명세를 받아들고 명세에 맞는 기술들과 상황을 해안을 가지고 분석한 후, 본인의 팀원들에게 제각각 맡는 역할에 따라서 일을 분배해야 하는 선장의 역할을 해야 한다.

이때 기술적 해안을 가지고 어떤 기술로 관련 상항 혹은 명세에 대해서 접근하면 좋겠다고 구성원들에게 전달할 수도 있다. 하지만 한 가지 명심할 점은 본인의 의견이 항상 정답은 아니라는 점이다.

소프트웨어 아키텍쳐링은 최악들 중에서 가장 차악을 꼽는 것임을 책에서 강조하고 있다. 맞는 말이다. 세상에 옵티멀한 설루션은 없고, 설령 그런 것이 있다 한들 우리 인간은 다루지 못할 것이다. (생각해 보라, 이 세상에 존재하는 문제는 모두 제각각이다. 이것을 동시에 모두 해결할 설루션은 신 외엔 아무도 이해하지 못할 것이다.)

즉, 이것저것 모두의 니즈를 만족하기보단. 최소한의 그리고 반드시 만족해야 하는 우선순위의 컴포넌트를 정하고 이를 최우선으로 아키텍쳐링하는데에 집중해야 한다. 그 외의 일은 그다음에 생각해 봐도 늦지 않는다.

2파트 : 아키텍처 스타일

 파트 2에서는 아키텍처링 스타일에 대해서 정리하고 있으며 그 목록은 하기와 같다.

모놀리식

- 레이어드 아키텍처

- 파이프라인 아키텍처

- 마이크로커널 아키텍처

분산형

- 서비스 기반 아키텍처

- 이벤트 기반 아키텍처

- 공간 기반 아키텍처

- 서비스 지향 아키텍처

- 마이크로 서비스 아키텍처

위의 것들이 대표적인 아키텍처들이다. 정말 이 업계에 몸담고 있다 보면 한 번쯤은 다들 들어봤을 법한 아키텍처들이다. 특히 레이어드 아키텍처와 이벤트 기반 아키텍처는 정말 많이 들어본 아키텍처이다.

이중 요즘 가장 인기 있는 아키텍쳐링을 꼽으라면 "마이크로 서비스 아키텍처"가 그것일 것이다.

각각의 아키텍처와 관련된 자세한 내용은 책을 참고하시길 바란다.

다만, 책에서 정말 친절하게도 각 아키텍처별 장단점을 별점으로 정리하고 있으니, 신규 서비스의 적용이나 혹은 본인이 요즘 관심 있어 하는 기술은 어떤 특성을 갖추고 있는지 등을 파악하는 데에 좋은 팁과 방향성을 얻을 수 있을 것으로 보인다.

하지만 반드시 이점은 알아두도록 하자. 모든 아키텍쳐링은 장단점이 있다는 사실을 말이다.

아키텍처의 역할은 장단점 사이에서 가장 트레이드오프가 적은 아키텍처를 선택하는 역할임을 말이다.

【 "소프트웨어 아키텍처 101"를 읽고서…….】

 한때 소프트웨어 구성에 있어서 모놀리식만큼 뛰어난 구성은 없다고 생각한 적이 있었다. 한 파일에 모든 코드들을 집어넣고 같은 코드라 할지라도 가독성은 둘째치고 조금의 리소스라도 더 절약하면 최고의 코드라고 각광받던 시절에 말이다.

하지만 시대가 많이 변했다. 이제는 위와 같은 구성과 코드를 짠다면 코드에서 스멜이 지독하게 나는 악취 코더로 전략하게 된다.

많은 것들이 복잡해지고 많은 것들이 세분화된 지금. 한 명이 모든 것을 해낸다는 것은 어찌 보면 지독한 욕심이고 말도 안 되는 일을 도모하는 것일지 모른다.

그렇기에 소프트웨어 아키텍처라는 새로운 직군도 생겨나고 전에 없던 데이터 아날 리스트, FE 개발자, BE 개발자와 같이 세분화되어 나누어 가는 것일지 모르겠다는 생각이 든다.

혼자서 뛰어나면 1M를 뛰어가는 데에 참으로 쉬울지 모른다. 하지만 100명이 협업하여 한 가지 일을 도모한다면 인당 50CM만 걸어가도 5000CM 즉 50M를 갈 수 있게 된다.

따라서 개인의 역량만큼 중요한 것이 협업에 대한 태도이고 작은 나무를 보는 것 대신 큰 안목을 가지고 자신을 끊임없이 쇄신하여 큰 숲을 그릴 줄 아는 개발자 나아가 아키텍처가 더 주목받고 높게 평가되는 시대가 바로 지금의 시대이지 않나 싶다

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

[도서 소개]

막막했던 아키텍처가 쉬워지는 실무 지침서

소프트웨어 아키텍트는 전 세계 연봉 10위 안에 드는 직업이지만, 지금까지 ‘개발자가 아키텍트’로 전향하는 데 실질적으로 도움이 될 만한 지침이 없었다. 이 책은 소프트웨어 아키텍처의 다양한 부분을 포괄적으로 개괄한다. 장차 아키텍트가 될 사람과 현직 아키텍트 모두 이 책을 통해 아키텍처 특성, 아키텍처 패턴, 컴포넌트 결정, 아키텍처 도식화 및 프레젠테이션, 진화적 아키텍처 등 다양한 주제를 살펴볼 수 있다.

마크 리처즈와 닐 포드는 수년간 전문적으로 소프트웨어 아키텍처를 강의한 잔뼈가 굵은 실무자로서 이 책에 모든 기술 스택에 고루 적용되는 아키텍처 원칙을 담았다. 이 책으로 지난 10년 동안 이룩한 모든 혁신과 현대적인 관점에서 바라본 소프트웨어 아키텍처를 배우길 바란다.

[목차]

CHAPTER 1 서론

[PART I 기초]

CHAPTER 2 아키텍처 사고

CHAPTER 3 모듈성

CHAPTER 4 아키텍처 특성 정의

CHAPTER 5 아키텍처 특성 식별

CHAPTER 6 아키텍처 특성의 측정 및 거버넌스

CHAPTER 7 아키텍처 특성 범위

CHAPTER 8 컴포넌트 기반 사고

[PART II 아키텍처 스타일]

CHAPTER 9 기초

CHAPTER 10 레이어드 아키텍처 스타일

CHAPTER 11 파이프라인 아키텍처 스타일

CHAPTER 12 마이크로커널 아키텍처 스타일

CHAPTER 13 서비스 기반 아키텍처 스타일

CHAPTER 14 이벤트 기반 아키텍처 스타일

CHAPTER 15 공간 기반 아키텍처 스타일

CHAPTER 16 오케스트레이션 기반 서비스 지향 아키텍처 스타일

CHAPTER 17 마이크로서비스 아키텍처 스타일

CHAPTER 18 최적의 아키텍처 스타일 선정

[PART III 테크닉과 소프트 스킬]

CHAPTER 19 아키텍처 결정

CHAPTER 20 아키텍처 리스크 분석

CHAPTER 21 아키텍처 도식화 및 프레젠테이션

CHAPTER 22 개발팀을 효율적으로

CHAPTER 23 협상과 리더십 스킬

CHAPTER 24 커리어패스 개발

[주요 내용]

- 아키텍처 패턴: 수많은 아키텍처 결정을 내리는 기술적인 근간

- 컴포넌트: 식별, 커플링, 응집, 분할, 세분도

- 소프트 스킬: 효과적인 팀 관리, 회의, 협상, 프레젠테이션 등

- 현대성: 지난 수년 동안 근본적으로 변화한 엔지니어링 프랙티스와 운영 방식

- 엔지니어링으로서의 아키텍처: 소프트웨어 아키텍처를 더욱 탄탄하게 만들어주는 반복 가능한 결과, 메트릭, 구체적인 평가

[서평]

이 책은 시니어 개발자 혹은 아키텍처에 첫 발을 들이는 독자에게 유용한 책입니다. 이책에서 다루는 내용은 1부에서는 소프트웨어 아키텍처의 기초와 아키텍트가 개발자와 어떻게 다른지에 대해서 자세히 설명을 하고 2부에서는 다양한 아키텍처 스타일에 대해서 알아보고 3부에서는 개발자와 다른 이해관계자들과 협업 하는데 필요한 여러가지 기법과 소프트 스킬에 관한 내용을 다루고 있습니다. 

소프트웨어 아키텍처는 시간이 지남에 따라 능력이 진화합니다. 익스트림 프로그래밍의 엔지니어링 프랙티스부터 지속적 전갈, 데브옵스 혁신, 마이크로서비스, 컨테이너화, 그리고 이제는 클라우드에 기반한 리소스에 이르기까지 모든 지속적인 혁신은 새로운 기능과 트레이드오프를 낳았습니다. 능력이 변화하면서 업계를 바라보는 아키텍트의 시선도 달라졌습니다. 소프트웨어 아키텍처는 오랫동안 ‘나중에 변경하기 어려운 부분’이라고 약간 비꼬는 듯 정의됐지만, 이후 등장한 마이크로서비스 아키텍처 스타일에서 변경은 일급 설계 고려 사항입니다.

새로운 시대에는 그에 걸맞는 새로운 프랙티스, 도구, 측정, 패턴 등 많은 변화가 필요합니다. 이책은 지만 10년 동안 일어난 모든 혁신과 더불어 오늘날의 새로운 구조와 관점에 부합하는 새로운 지표를 바탕으로 소프트웨어 아키텍처를 현대적인 관점에서 살펴보고 있습니다.

이 책을 읽는다고 바로 아키텍트가 되는건 아니지만 소프트웨어 아키텍처의 다양한 측면에 대해서 인사이트를 받을수 있을 겁니다.

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

아키텍처에 대하여 아키텍터에 대하여 다르게 보는 시대입니다.

마이크로서비스와 클라우드에 대한 활용도가 높아짐에 따라 더이상 효율적인 리소스 관리보다는 유연한 요구사항을 대응할 수 있는 아키텍처로 변모하고 있습니다. 그렇다고 기준이 없다는 것이 아닙니다. 더욱 견고하고 확장성있는 구성으로 나아가기에 고전적인 소프트웨어 아키텍처에만 머물러서는 안된다는 겁니다.

그런면에서 소프트웨어 아키텍처 101은 보다 현대적이라고 볼 수 있습니다.

기초적인 아키턱처에 대한 고찰에서 시작하여 서비스 기반, 이벤트 기반 아키텍처 스타일까지 그리고 오케스트레이션 기반으로 해서 마이크로서비스까지 언급하고 있습니다. 최근 클라우드향에 관심이 많은 분들에게는 아키텍처 스타일 후반부를 집중해서 접해도 될 것 같습니다.

시작은 기본입니다. 기준과 변화관리입니다.

출판사 소개 자료도 새 시대 새 아키텍처에 대한 인사이트라는 표현이 이 책을 대변하기도 합니다.

주요내용입니다.

많은 기술서를 접해보았지만, 설명글과 그림이 잘 어울려져 있습니다. 그림이 내용을 잘 대변하고 있어서 내용이 딱딱함에도 이해하기가 용이하기도 합니다. 실제가 가려운 곳을 잘 설명으로 긁어주는 듯 함이 있습니다.

엔지니어링 접근 방식으로 배우는 소프트웨어 아키텍처 기초라는 소제목이 있습니다.

아키텍처는??

사례설명 틴력적 확장이 부족했던 페츠닷컴이었습니다.

협력, 협업의 중요성, 아키텍처와 설계의 구분짓지 말자는 내용이기도 합니다.

아키텍처의 역할

광범위한 범위하고 할 수 도 있지만, 현대성 현재의 아키텍처들을 다룬 것이 차별점이기도 합니다. 보통 다른 아키텍처 문서는 이론과 내용 이전 사례들이지만 이벤트기반, 쿠버네티스, 마이크로서비스(MSA)까지 다루고 있는 점에서 최신 경향까지의 내용이라고 볼 수 있는 책이기도 합니다. 

한빛미디어 나는 리뷰어다 활동으로 책을 제공받아서 책을 읽고, 서평을 씁니다.

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

"아키텍처는 정답도, 오답도 없다. 오직 트레이드오프만 있을 뿐."

학습 과정이나 실무에서도 늘 정답만을 찾으려고 노력했던 내 머리를 '띵'하게 만들었던 책 속의 한마디.

실제로 우리 서비스에 REST와 메시징 중 어느 게 더 나은지, 마이크로서비스가 딱 맞는 아키텍처 스타일인지는 구글을 아무리 뒤져봐도 알 수 없다. 배포 환경이나 회사의 문화, 예산, 기간, 개발자 스킬 등 여러 가지 팩터들이 영향을 미치기 때문이다. 이것이 아키텍처가 어렵다는 말이 나오는 이유가 아닐까 싶다.

전반부에는 이런 모호함 속에서 아키텍처를 구축하거나 기존 아키텍처의 타당성을 검증하기 위해 아키텍처의 특성을 식별하고 구체적으로 정의할 수 있는 기초 지식과 아키텍트가 특정 비즈니스 문제에서 올바른 선택을 할 수 있도록 다양한 아키텍처 스타일의 트레이드 오프를 중점적으로 학습할 수 있다.

반면 위와 같은 기술적인 부분뿐만 아니라 개발자나 다른 이해관계자들과 협력하는데 필요한 여러 가지 기법과 소프트 스킬에 대한 내용이 비교적 자세하게 서술된 대목 또한 인상 깊다.

아키텍트가 아무리 훌륭한 아이디어를 갖고 있다 한들 결국 그들에게 자금을 댈 고객사 관리자와 그 아이디어를 실제로 구현할 개발자들이 납득하지 못한다면 결국 빛을 볼 수 없기 때문이다.

실제로 책 후반부에는 아키텍처를 보기 좋게 도식화하는 방법부터 파워포인트나 키노트 같은 도구로 효과적인 프레젠테이션을 하는 법, 프로젝트의 리더로서 개발팀을 효과적으로 이끌어가기 위해 알아둬야 할 기본 테크닉, 고객사 임원 같은 핵심 비즈니스 이해관계자들과의 협상 스킬까지 유능한 소프트웨어 아키텍트가 되기위한 지침들이 쓰여있다.

끝으로 아키텍트가 되고 난 후의 커리어 패스 관리를 위한 팁까지 알차게 담겨 있기에 연차와 관계없이 아키텍트 희망하는 사람이라면 이 책을 통해 다양한 인사이트를 얻을 수 있으리라 생각한다.

이 책은 소프트웨어 아키텍처 설계에 대한 다양한 방법에 대해서 써놓은 책이다. 설계 뿐만 아니라 아키텍트가 알아야 하는 것들 또는 고려해야 하는 상황들도 다양한 관점에서 설명을 해준다. 책을 읽으면서 몇가지 내가 기억해두면 좋을것 같다는 부분들을 아래와 같이 작성해봤다.

아키텍처 대 설계

- 아키텍트와 개발자를 나누는 가상의 물리장벽을 통과하는 단방향 화살표는 많은 문제를 야기한다. 따라서 아키텍처, 설계 모두 소프트웨어 프로젝트 생명 주기의 일부로서 항상 서로 동기화되어야 성공할 수 있다.

아키텍처와 코딩 실무간 균형 맞추는 방법
1. POC를 자주 해본다. 가능한 한 프로덕션 수준의 고품질 코드로 작성하는 것이 좋다.
2. 기술 부채나 아키텍처 스토리에 전념한다. 또는 버그를 수정한다.
3. 코드리뷰를 자주한다.

아키텍처 특성 식별
1. 도메인 관심사에서 아키텍처 특성도출
  - 도메인의 핵심 목표와 현재상황 고려하여 아키텍처 결정
  - 모든 아키텍처 특성을 지원하는 제네릭 아키텍처 설게 --> 가장 흔한 안티패턴
  - 가급적 설계를 단순화 하는게 좋다
2. 요구사항에서 아키텍처 특성 도출

컴포넌트 식별흐름

1. 초기 컴포넌트 식별
2. 요구사항을 컴포넌트에 할당
3. 역할 및 책임 분석
4. 아키텍처 특성 분석
5. 컴포넌트 재구성
위 그림처럼 컴포넌트 식별은 한번에 끝나는게 아니라 컨포넌트의 특성을 분석해 나가면서 계속해서 수정될 수 있다.

컴포넌트 설계
- 엔티티 함정
   각각의 엔티티를 바탕으로 컴포넌트를 만드는것. 이건 프레임워크를 데이터베이스에 컴포넌트 관계형으로 매핑한 것에 불과한것이다. (내가 항상 이렇게 설계를 하고 있지 않나 싶다... )
- 액터/액션 접근법
   애플리케이션에서 뭔가 일을 하는 액터와 그들을 수행하는 액션으로 식별
- 이벤트 스토밍
   다양한 컴포넌트가 메시지나 이벤트를 이용해 서로 통신한다고 가정.
   어떤 이벤트가 일어나는지 파악하고 컴포넌트를 이벤트와 핸들러 중심으로 구축.
- 워크플로 접근법
   이벤트 스토밍의 대안으로 DDD나 메시징을 사용하지 않고 더 일반화 한 방법.
   핵심 역할을 식별하고 이 역할이 관여하는 워크플로 유형을 결정하여 식별된 활동에 따라 컴포넌트 구축.

아키텍처 스타일 : 크게 모놀리식과 분산형으로 나누면 다음과 같은 아키텍처들이 존재한다.
- 모놀리식
   레이어드 아키텍처, 파이프라인 아키텍처, 마이크로커널 아키텍처
- 분산형
   서비스 기반 아키텍처, 이벤트 기반 아키텍처, 공간기반 아키텍처, 서비스 지향 아키텍처, 마이크로서비스 아키텍처 

아키텍처 결정의 안티패턴
- 네 패를 먼저 보여주지마
  아키텍트가 잘못된 선택을 하는 것을 두려워해서 아키텍처 결정을 회피하거나 미루는 현상
  개발팀과 지속적으로 협력하면서 결정한 내용을 의도한 대로 추진 가능함. --> 모든 이슈를 아키텍트가 혼자 다 알수 없기 때문에 개발팀과 협력은 절대적임.
- 무한반복 회의
  어떤 결정을 왜 했는지 모르고 주구장창 회의만 계속 하는것.
  무한반복 회의가 발생하는 이유는 아키텍트가 자신이 내린 결정을 정당화 하는데 실패했기 때문
  아키텍처 결정을 할때 비즈니스 가치를 제시하는 것이 중요함.
- 이메일 기반 아키텍처
  아키텍처 결정을 놓치거나 잊어버리고 심지어는 그렇게 결정됐다는 사실조차 알지 못해 아키텍처 결정을 구현하지 못하는 상태.
  즉, 아키텍처 결정을 효과적으로 전달하지 못해서 발생하는 문제.
  이메일 본문에 아키텍처 결정을 포함하지 않는다. 중요한 세부사항은 단일 기록시스템(위키페이지등)에 보관해서 링크만 제공한다.
  아키텍처 결정에 정말 관심이 있는 사람들에게만 통지한다.
 

협상과 조정 tips
- 상황을 더 잘 이해하기 위해 문법과 유행어를 사용한다.
- 협상에 돌입하기 전 가능한 한 많은 정보를 수집한다.
- 다른 모든것이 실패하면 비용과 시간으로 설명한다.
- '분할 및 정복' 규칙을 활용해서 요구사항 또는 필우 조건을 검증한다.
- 증명은 언제나 논쟁을 이긴다는 사실을 명심한다.
- 지나치게 논쟁을 벌이려고 하거나 협상 과정에서 개인정인 감정을 드러내지 않는다. 간결 명료한 추론에 차분한 리더십을 더하면 반드시 협상에 승리한다.
- 개발자가 아키텍처 결정을 수용해서 어떤 작업을 하도록 설득할 때에는 '고압적으로 지시' 하지 말고 왜 그 일을 해야 하는지 정당성을 제공한다.
- 개발자가 아키텍트의 결정에 동의하지 않을 경우 그들 스스로 해결책을 찾도록 유도한다.

위 내용들 중에서도 특히 엔티티 함정 과 아키텍처 결정 안티패턴은 읽으면서 나 자신이 반성을 많이 하게 되었다. 아마도 내가 그런 안티패턴에 빠져서 설계를 하지 않았나라는 느낌이 많이 들었기 때문이다. 아키텍처에 대한 기초 지식을 얻고자 하는 분들에게 큰 도움이 될수 있는 책이라고 생각한다. 

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

아키텍처는 구글링해도 안되는 것이다. 

아키텍처는 정답도, 오답도 없다. 오직 트레이드오프만 있을 뿐.

프로그래머는 장점은 잘 알지만 트레이드오프는 하나도 모른다. 아키텍트는 둘 다 잘 알아야 한다.

저자소개

저자1 마크 리처즈는 마이크로소프트 등의 분산 아키텍처의 설계와 구현에 참여한 소프트웨어 아키텍터 경력자로서, 개발자들을 소프트웨어 아키텍트세계로 안내한 'DeveloperToArchitect.com'을 만들었다. 

저자2 닐 포드는 개발과 인도를 하는 글로벌 IT컨설팅회사, 쏘우트웍스의 이사이자 소프트웨어 아키텍처, 밈 랭글러 이다. 이전에는 미국의 유명한 교육/훈련 개발사인 DSW Group의 CTO를 역임했다. 

이책의 번역을 맡은 이일웅 옮긴이는 20년 경력 자바전문 풀스택 개발자. 소프트웨어/애플리케이션 아키텍트로 프로젝트 수행경험이 있다. 

서평

이책은 개발자와 소프트웨어 아키텍트의 경계 및 아키텍트의 필요성 , 아키텍트로서의 직업을 갖기 위해 필요한 것이 무엇인가를 현직 개발자가 상세하게 기술한 책이다.

특히 소프트 아키텍처가 뭐하는 것인지 그리고 개발자와 어떻게 다른지, 달라야 하는지, 하는 일이 상세히 나와 있다. 

따라서, 개발자로서 커리어를 아키텍트로 가려는 사람... 그리고 개발입문자 중에 향후 직업을 고려하는 분들, 

그리고 프로젝트 PM으로 아키텍처 역할을 부여할때 주의해야 할 사항들을 캐치업하는데 아주 좋은 책이다. 

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

최근에 회사에서 개발중인 서비스 이슈로 '아키텍트'와 직접 대화를 나누면서 팀 내 본인의 역할, 서비스의 방향성, 앞으로의 개선 방향 등 크고 작은 주제들에 대해 논의할 기회가 있었다. 본인이 개발자로서 일을 한지 15년 가량 되었지만 실제로 아키텍트 포지션의 인력이 하는 일을 가까이서 보게 된 것은 처음이었고, 그 분이 조직을 변화시켜 나가는 과정 속에서 아키텍트라는 업이 내 생각보다 다양한 일을 해야 한다는 것을 알게 되었다.

때마침 한빛미디어에서 이 도서가 출간되었고 리뷰할 수 있는 기회를 얻게 되었다. 현재는 자세한 아키텍처 스타일에 관련된 챕터 외에는 가볍게 읽은 상태이다.

도서를 읽으며 본인이 메모해둔 부분 중 몇몇 부분을 공유해본다. 이 단편적인 정보 조각들만 살펴보아도 아키텍트 업이 궁금한 사람들에게 이 도서가 어떠한 도움을 줄 수 있는지 설명이 되리라 믿는다. 파트 2에서는 다양한 아키텍처 스타일을 소개하고 있는데, 서비스를 만들기 위한 전체 시스템의 설계 방법에 대한 참고가 될 것이다.

.

소프트웨어 아키텍트는 어떤 일을 하는 사람들인가? 끊임없이 변화하는 생태계 안에서 뭔가 결정을 내리는 사람들이다.

아키텍처란 예술과 마찬가지로 context 로서만 이해할 수 있다. 아키텍트가 내린 결정은 대부분 그들이 그렇게 결정한 당시 환경에 기인한 것이다. 모든 아키텍처는 그 context의 결과물이다.

아키텍트는 알려지지 않은 미지의 것들을 설계할 수 없기 때문에 'Big Design Up Front (일단 설계부터 확실하게)' 방식으로 진행하기 어렵다. 모든 아키텍처는 알려지지 않은 미지의 것들(Unknown unknowns) 때문에 자꾸 되풀이된다. 우리가 필요한 것은 진화하는 아키텍처(Evolutionary architecture)이다.

소프트웨어 아키텍처 설계시, '어떻게'보다 '왜'가 중요하다. 왜 다른 것보다 그런 선택을 하게 되었는지 설명하는 것은 어렵다.

아키텍처는 모든 것이 다 트레이드오프이다. 배포 환경, 비즈니스 동인, 회사 문화, 예산, 기간, 개발자 스킬 세트 등 여러 팩터들이 영향을 미친다. 아키텍처는 정답도, 오답도 없다. 오직 트레이드오프만 있을 뿐. 프로그래머는 장점은 잘 알지만 트레이드오프는 하나도 모른다. 아키텍트는 둘 다 잘 알아야 한다.

아키텍트는 어떻게 해야 코딩 실무 능력을 잃지 않으면서도 일정 수준의 기술 깊이를 유지할 수 있을까? 개념 증명(POC. proof of concept)을 자주 해보는 것이다. 아키텍트가 결정 장애를 극복하는 가장 좋은 방법은, 실제로 각 제품을 응용한 예제 코드를 짜보고 실행 결과를 비교해보는 것이다.

개발자가 아키텍처를 구현할 수 있게 제약조건이나 틀을 만들어 개발팀과 소통하라. 제약 조건을 너무 많이 설정하거나 너무 느슨하게 적용해서는 안 된다.

아키텍처는 물론 삶의 모든 것에서 더 나은 사람으로 거듭날 수 있는 가장 검증된 방법은 바로 연습입니다. 여러분이 신입 아키텍트이건 경력 아키텍트이건 각자의 기술 폭은 물론, 아키텍처를 설계하는 기술을 끊임없이 갈고 닦기 바랍니다. 불행히도 정답은 없습니다.

.

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

최근까지 출간된 책중 최고의 책이라고 생각된다 아키텍처의 기초부터 다양한 아키텍트 스타일에 대해 알아볼 수 있고 아키텍트가 되기 위한 협업과 처세술, 프레젠테이션 기술등 아키텍트가 갖추어야될 모든 것에 대한 내용을 다루고 있다

물론 훌륭한 아키텍트가 되기 위해선 이 책에 나온 내용들 이외에도 수없이 많은 것들을 알고 경험해야 되겠지만

아키텍트가 되고 싶어 하는사람 자신이 올바르게 아키텍트의 길을 걷고 있는 것인지 알고 싶은 사람들에게 정말 많은 도움을 줄 수 있는 책임에는 틀림없다고 생각한다

본인도 아키텍트로써의 역량이 매우 부족하다고 생각되는 시점에서 이 책을 접하게 된 것에 대해 매우 기쁘게 생각하고 있다

얇은 책이지만 정말 컴팩트하게 주옥같은 명언과 해법들이 가득 담겨 있는 이 책은 훌륭한 아키택트가 될 수 있도록 안내하는 이정표 역할을 톡톡히 해낼 것이다