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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

이 책은 소프트웨어 아키텍트를 목표로 하거나 현재 직책이 CTO, 개발팀장, PM, 개발자 모두에게 추천하고 싶은 책이다. 이 책을 읽는 것만으로 소프트웨어 아키텍트가 될 수는 없지만, 향후 훌륭한 소프트웨어 아키텍트로 가는 방향을 훌륭히 제시하고 있다. 책 뒤로 가면 갈수록 더욱더 흥미있게 있을 수 있었던 몇 안 되는 책이었던 것 같다.

책의 구성은 기초, 아키텍처 스타일, 테크닉과 소프트 스킬로 나뉘며, 전체 챕터가 서론을 포함 총 24개나 되어서 읽는데 힘들겠다 싶었는데, 각 챕터가 길지 않고, 내용도 아주 어렵지 않다. 모두 이해하면 좋겠지만, 나중에 필요하면 다시 보면 되니까 이해가 되지 않으면 않는 데로 넘어가도록 하자. 언젠가는 다시 보게 될 것이므로, 그때 이해하면 될 것이다.

PART I 기초편 에서는 아키텍처와 아키텍트의 개념과 특성을 설명하고 있으며, 사례 연구를 통해 실제 현장에서 어떻게 아키텍처가 사용되고 있는지 설명하고 있다. PART II 아키텍처 스타일에서는 주로 사용되고 있는 8개의 아키텍처 스타일을 비교 분석하며 아키텍처 선정 방법과 고려 사항을 설명한다. 마지막 PART III에서는 아키텍처 선정 이후 리스크 관리와 도식화 및 프리젠테이션, 프로젝트에서 아키텍트의 역할과 향후 더 나은 아키텍트로 가야 할 방향을 제시하고 있다.

현재 많은 프로젝트가 클라우드 환경이 도입되면서 레이어드 아키텍처 스타일에서 마이크로서비스 아키텍처 스타일로 진화(?)하고 있지만, 이 또한 하나의 트렌드라고 생각하는데, 이 책을 통해서 무지성이 아닌 각각의 아키텍처 스타일을 비교 분석하여 설계하는 것이 바람직할 것이다. 이 책이 도움을 줄 것이다.

아키텍처 관련 책이다 보니, 이 책에서는 다양한 주제가 많이 소개되므로 개인적으로 기술의 폭이 넓어져 좋았으며, 특히 9장에서 설계 시 심심찮게 발생하는 오류 8가지 부분이 인상 깊었다. 22장 개발팀을 효율적으로, 23장 협상과 리더십 스킬에서는 아키텍처의 덕목과 다양한 주제에 대한 팁들을 설명하는데, 많이 반성도 하면서, 바로 적용할 내용이 있어서 특히 재미있게 읽은 챕터들이었다.

마지막으로 아키텍트는 항상 배우고, 항상 연습하는 자세로 끊임없이 아키텍처를 설계해야 하는 직업이라는데, 100% 공감하고 이 책에 신뢰를 느낄 수 있는 부분이라 좋았다.

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

2장 아키텍쳐 사고, p.55

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

최근 아키텍처에 대한 이야기가 더 자주나오는 시대입니다.
그것은 분명 기술의 변화의 속도 때문입니다.
다양한 요구사항에 따른 유연함입니다.
변화관리에 대한 대응을 위하여 아키텍처가 그 틈을 메꾸는 겁니다.

그래서 101가지 아키텍처를 통하여 여러가지를 생각하게 됩니다.

이 책은 특히 엔지니어링 접근 방식으로 배우는 소프트웨어 아키텍처 기초라는 겁니다.

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

아키텍처 패턴 : 수많은 아키텍처 결정을 내리는 기술적인 근간
컴포넌트 : 식별, 커플링, 응집, 분할, 세분도
소프트 스킬: 효과적인 팀 관리, 회의! 협상, 프레젠테이션 등
현대성 : 지난 수년 동안 근본적으로 변화한 엔지니어링 프랙티스외 운영 방식
엔지니어링으로서의 아키텍처: 소프트웨어 아키텍처를 더욱 탄탄하게 만들어주는 반복 가능한 결과, 매트릭, 구체적인 평가

책의 내용과 그림설명이아주 매칭이 잘되어 있어서 명ㅎ학하게 정리가 되는 책입니다.

현대적인 관점의 아키텍처 책입니다.

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

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

아키텍처

페츠닷컴의 사례

협력

그림을 통해 쉽게 이해하는

한빛미디어 나는 리뷰어다 활동을 통해서 책을 제공받아서, 읽고 서평을 쓰게됩니다.

간만에 볼만한 책을 접했다. 기존의 아키텍처 개론서들은 약간 뜬구름 이야기, 그리고 장황한 설명으로인하 졸음에 견디기 어려운 사투를 벌여야 했다. 소프트웨어 아키텍처를 배운다는 것 자체가 초급 개발자는 넘어서야 하는 단계이기는 하다. 단순히 로직을 어떻게 짜는게 좋다는 개념만 갖고 아키텍처를 만들지는 않는다. 경험, 노하우도 필요하다. 그런 차원에서 이 책은 최근에 지배적인 분산형 마이크로서비스 아키텍처 중심으로 다른 아키텍처를 비교해 가면서 설명을 해주었다.

전반적으로 간결하게 설명한 것도 좋았지만 더 나가서 상황극을 만들어서 디테일을 풀어준 점이 인상적이다. 대개 아키텍처는 이러이러한 점을 고려해야 한다! 하고 끝나는 경우들이 많다. 참 재미없다. 반면 상황극은 실무의 어떤 상황에서 이런 아키텍처를 적용할 수 있다는 점을 잘 설명해 준다. 물론 하나의 시나리오일 뿐 실전에서 쓰인 상황은 아니란 점이 아쉽기는 하지만 볼만한 책이었다.

『소프트웨어 아키텍처 101』의 심화과정이라 하는데 맞는 말 같다. 101 책은 보지 못하고 서점에서 훑어 봤는데 예전 학창시절 배웠던 교과서와 별반 차이 없는 것 같아서 보진 않았다. 시간 날 때 어떤 차이인지 확인해 보겠다.

TMI이지만 오늘날 대형 프로젝트에 참여해 보면 틀에 박힌 아키텍처에다가 무조건 쑤셔 넣으라고 강요받기 일색이다. 큰 장벽에 부딪힐 때 현장 개발자로서 합리적인 대안을 제시해 보기도 하지만 수용될 일은 어림 반푼어치도 없다. PM, PL, AA ... 누구의 책임일까? 아키라는 직책은 있는 것 같은데 예전처럼 실체(?)를 본 적이 근래에는 없다. 예전처럼 눈에 띄는 아키를 만날 수 있는 날을 고대해 본다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

아키텍트라는 직무에 대해 알아보고 싶었고, 신입 개발자로써 아키텍트가 왜 필요한지, 어떤 일을 하는지 알면 업무를 수행하는데 큰 도움이 될 것 같아 이 책을 읽게 되었다.

서론에는 소프트웨어 아키텍처가 무엇인지에 대한 설명이 있다

명확한 정의는 아직 없다고 한다. 기술 역량, 소프트 스킬, 운영 감강 등 많은 분야를 아우르기 때문이고, 끊임없이 변하기 때문인 것 같다.

이러한 구절이 있다

"소프트웨어 아키텍처의 범위는 끊임없이 변하는 개발 세상의 유일한 요소가 아니다. 변하는 생태계 안에서 뭔가 결정을 내리는 사람들" 이라고 한다.

아키텍처란 예술과 마친가지로 콘텍스트 로서만 이해할 수 있다

결정은 당시 환경에 기인한다.

아키텍처는 아키텍처 특성, 아키텍처 결정, 설계 원칙이 결합된 구조다.

신입 개발자가 읽기에 어려운 감이 있지만, 그만큼 멀리 넓게 볼 수 있는 시야를 배울 수 있었다.

"소프트웨어 아키텍처의 기초와 아키텍트가 개발자와 다른점"

"개발자, 다른 이해관계자들과 협력하는데 필요한 여러가지 기법과 소프트 스킬에 관한 내용"

이 도움이 되었다고 옮긴이가 말했다.

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