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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

아키텍처

페츠닷컴의 사례

협력

그림을 통해 쉽게 이해하는

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

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

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

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

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

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