개발자에서 아키텍트로 -마이클 킬링- 김영재 옮김 [책리뷰][실용주의프로그래머][실용주의] [7/7]

Design it! : From Programmer to Software Architect

 

원제는 From Programmer to Software Architect이다. 한국말로 번역하면 역서의 제목처럼 프로그래머에서 아키텍트로!

가 될 수 있겠다. 미국에서는 2017년에 나온 책으로 "실용주의 책 선반"의 아키텍트 분야에 올라온 책이다.

실용주의 프로그래머 책 선반에 올라와 있다.

 

Pragmatic Bookshelf: By Developers, For Developers

위의 사이트에 들어가면 다양한 카테고리의 실용주의 책들이 존재한다.

 

대부분의 책들이 실용주의에 초점을 두는 편이며 난이도가 상당히 다양한 편이다. (어려운 책은 상당히 어렵다.)  

[ 나는 대부분의 책들을 추천하는 편이다. 진짜 실용주의적이기 때문!! ]

 

고전이기도 한 "실용주의 프로그래머"의 저자인 앤드류 헌트가 운영하는 웹사이트로 알고 있다. 

 

번역되지 않은 책들도 많아서 필요하다면 원서로 구매하고 보는 것도 나쁘지 않아 보인다. 

 

---

데브옵스의 시대. 인프라와 개발자의 영역이 혼합되었다.

추천도 : 7/7

★★★★★★★

 

읽은 기간 📅 : 2021년 7월 7일부터 9월 15일. 

 

이 책을 추천하는 이들 👨‍👧

• 소프트웨어 아키텍트를 희망하는 사람들
• 데브옵스를 지향하는 프로그래머

 

난이도 🦈

중.

아키텍트와 관련된 경험이나 지식이 없다면 꽤나 까다롭게 읽힐지도 모르겠다. 

 

책은 최대한 친절하게 설명해주고 있으니 크게 걱정하지는 않아도 될 듯하다. [개인적인 생각]

 

관련된 책들 📚

1. 인프라(클라우드) 관련 책
2. 프로젝트 관리 관련 책
3. 자기계발 서적들

 

한 줄 평 ✍️

건강한 소프트웨어 아키텍처가 되는 법.

---

프로그래머에서 아키텍트로 성장해야 하는 시대.

 

조직 문화는 애자일하게 변하고 있다.

 

인프라는 클라우드로 관리하는 것이 대세! (하이브리드)

 

서비스는 작게 분할되고 있다.

 

배포 주기는 상당히 빨라지고 있다.

 

해당 프로젝트의 초당 배포수가 해당 프로젝트의 비즈니스 기민성을 보여주는 지표이다.

 

마이크로 서비스, 클라우드, 애자일 문화, 성장 마인드셋 등등..

 

이전보다 프로그래머가 갖춰야 할 역량이 복합적인 시대가 되었다.

 

그리고 이 책은 프로그래머에서 훌륭한 소프트웨어 아키텍트로 성장할 수 있는 가이드라인을 끝내주게 제시해준다.

 

학부 때 배운 설계

 

학부 시절 설계와 관련된 과목은 과거의 소프트웨어의 설계 방법론부터 접근했다.

 

그 유명한 폭포수 모델.

 

모든 것을 결정론적인 상태로 결정해 가면서 프로젝트를 진행한느 것.

 

뒤는 돌아볼 수 없는 구조. 거슬러 오를 수 없는 폭포처럼 한 방향으로만 진행된다.

 

그리고 수십 년이 지나 폭포수 모델은 "죽음의 행진"이라는 꼬리표를 달게 된다.

 

폭포수처럼 물이 떨어지는 방향으로 프로젝트가 진행된다. 폭포수는 거스러 오를 수 없다는 것이 주요한 메타포이다.

 

변화에 매우 둔한 구조를 갖추게 되는 폭포수 모델은 이해관계자가 원했던 요구사항이 아니더라도 초기의 요구사항을 고집하면서 진행한다. 이미 멈출 수 없고, 돌이킬 수 없다는 것이 주된 이유였다. [ 다시 돌아간다고 하면 다시 폭포수 모델이 시작되는 것이다. ]

 

폭포수 모델의 단점을 보완하겠다고 나온 설계 방법이 바로 점진적 반복 개발론 "Iterative process"이다.

 

빠른 사이클을 가지는게 주 특징

폭포수 방식을 압축하여 빠른 프로세스에 넣어버리고

 

빠른 피드백을 받는 것이 주 목표인 방식이다.

 

빠르게 프로토타입을 출시하고, 사용자에게서 올바른 요구사항을 캐치했는지 피드백을 받고

 

그 피드백의 내용을 다시 반영하면서 개선해나가는 방식이다.

 

IP(Iterative Process)의 주요 특징은 "기민함"이 필요하다는 것이다.

 

거대한 폭포수 방법론의 물줄기를 작게 작게 진행시키는 방식이다. 

 

그렇게 애자일 문화가 태동하고, 객체지향 개발론이 고개를 들면서 모듈식 구조 혹은 컴포넌트 방식으로 프로젝트를

 

진행할 수 있게 되면서 설계 방법론의 대세의 자리에 있던 폭포수 모델 방식은 자리를 내주게 된다.

 

"폭포수 모델이 옳지 않다. 정말 별로인 설계 방법이다."라고 확정 지을 수는 없다.

 

그저 폭포수 모델과 실제 해결해야 하는 비즈니스 문제의 성격이 매칭되지 않았던 것뿐이다.

 

실험이 불가능하고, 사람의 생명이 오가는 치명적인 영역에서는 한 단계 한 단계 매우 조심스럽고 꼼꼼하게 시뮬레이션해야 하며 요구사항이 명확한 프로젝트에서는 폭포수 모델이 적격이기도 한다.

 

그리고 지금. 마이크로 서비스의 시대가 오고 있다.

 

마이크로 서비스 아키텍처 설계 전문가들은 프로젝트 진행을 마이크로서비스 아키텍처 설계로 시작하는 것을 경계하고 있지만 클라우드의 장점을 고려하고, 모놀리식 아키텍처에서 마이크로서비스 아키텍처로의 이전(migration) 비용을 고려한다면 MSA로 바로 시작하는 것은 나름의 메리트가 있다.

[ 클라우드 환경은 마이크로 서비스에 적합하기도 하지만, 모놀리식 아키텍처에도 적합하다. ]

 

다만 도메인 주도 설계에서 강조하듯이 설계를 갈아엎는 과정을 여러 번 거쳐야 뚜렷한 도메인을 담을 수 있게 된다.

 

그리고 명확하게 분리된 경계된 맥락(Bounded Context)으로 구분할 수 있게 되고 이 맥락 하나하나가 작은 마이크로 서비스의 후보가 되어준다. [ MSA를 한번에 성공해서 정착시키려고 한다면 크게 위험할 수 있다!! ]

 

마이크로서비스 아키텍처가 변화시킨 조직 문화

 

이제는 설계 팀, 개발 팀, 테스트 팀, 품질 관리 팀,  DB 팀, 인프라팀, UX/UI 팀 이런 식의 팀 별로 소통하면서 프로젝트를 진행하는 구조보다는

 

한 팀에 테스트, 품질, 인프라, UX/UI, 설계, 개발 역량을 두루두루 갖추어 프로젝트 진행에 있어서 소통의 벽이 허물어진 팀원들로 구성된 것을 선호하고 있다. 

 

서비스를 직접 빌드하고 직접 운영하면서 서비스의 개발부터 운영까지 담당하며 서비스에 대한 책임감도 형성되고

 

팀원들은 필요한 기술들을 동료들과 함께 페어 프로그래밍을 하거나 서로 교육하면서 익혀나갈 수 있다.

 

마이크로 서비스 아키텍처는 아키텍처의 변화만을 이야기하는 게 아니라 조직 문화, 개발 문화까지 완전히 뒤바꾸고 있다.

 

모놀리식에 맞는 조직 구성도가 있었다면, 마이크로 서비스 아키텍처도 그에 맞는 도구와 조직 구성도, 조직 문화가 있는 법이다.

 

그리고 이 책은 애자 일한 조직 문화 속에서 프로그래머가 아키텍트로 성장할 수 있도록 많은 가르침을 선사한다.

 

아키텍트의 전문성은 무엇인지

아키텍트란 무엇인지

아키텍처란 무엇인지

아키텍처가 가져야 할 특징들은 무엇인지

아키텍처의 핵심은 무엇인지

아키텍트가 활용할 수 있는 도구들은 무엇인지

소프트웨어 아키텍처들의 트레이드오프들은 무엇인지

등등

 

아키텍트가 다뤄야 하는 대부분의 영역들을 이 책은 꼼꼼하게 설명해주고 있다.

 

그간 모호하게 정의되었던 아키텍트에 대해서도 많은 프로그래머들이 공감할 수 있는 방향으로 정의해주고 있다.

 

이 책에 기여한 사람들의 목록을 보더라도 이 책은 심상치 않음을 알 수 있다. 

 

깔끔한 책의 구성

 

1부에서는 소프트웨어 아키텍트가 하는 일들을 전반적으로 들여다보고 소프트웨어 아키텍처에 대해 정의한다.

 

2부에서는 본격적으로 아키텍처를 설계해본다.

- 가장 먼저 이해관계자와 소통하며 소프트웨어가 이뤄야 할 요구사항들을 분석해본다.

- 아키텍처 핵심 요구사항을 뽑아낸다. (비기능적, 기능적) 그리고 설계에 반영한다.

- 아키텍처 패턴의 설계를 "시각화"해본다.

- 아키텍처를 "문서화"한다.

 

3부에서는 아키텍처가 필요한 상황에 맞게 활용할 수 있는 38가지의 팀 활동들을 들여다본다. 

- 문제 이해

- 해결책을 찾고자 할 때

- 설계를 공유하거나 시각화하는데 도움이 되는 활동들

- 설계 대안이 존재하는 경우 이를 "평가"하는 활동

 

이 책에서도 보게 되는 전문가의 필요한 역량 "공감"

 

스티브 존슨의 "미래를 어떻게 결정할 것인가"에서 앞으로 인류에게 필요한 역량으로 "공감"을 뽑았다.

 

공감력이 높은 사람은 다양한 상황에서 이해관계자의 관점으로 들여다볼 수 있고 복잡하게 얽힌 가치 관계에서

 

미래지향적이면서 옳은 정답이 될 수 있는 방법을 찾을 수 있기 때문이다.

 

이 책에서도 소프트웨어 아키텍처의 주된 역량으로 "공감"을 꼽는다.

 

팀원들을 공감해야 하고

 

해당 프로젝트에 연관된 이해관계자들을 공감해야 하고

 

나아가 내가 만들고 있는 소프트웨어 아키텍처를 "사람"으로 메타포하여 공감하라고 한다.

 

이 공감을 통해서 소프트웨어 아키텍처가 이행한 소프트웨어가 전달하는 가치를 절대적으로 높일 수 있다고 주장한다.

 

3부에 나오는 38가지의 활동 대부분이 누군가와 같이 활동하는 것이다.

 

서로의 의견을 나누고,

 

서로의 지식 격차를 좁혀나가고,

 

적극적으로 설계와 활동에 참여해서 모두에게 책임감을 느끼고 생동감을 느끼게 해주는 활동들이다.

 

이 책을 읽으면서 소프트웨어 아키텍처의 책임감을 경험해볼 수 있었다.

 

훌륭한 소프트웨어 아키텍트는 팀원들을 아키텍트로 성장시키는 아키텍트라고 했다.

 

나는 이 말을 다른 의미로 표현해보고 싶다.

 

훌륭한 소프트웨어 아키텍트는 팀원들의 공감성을 높여줄 수 있는 아키텍트이다.

 

이해관계자를 공감하고

 

설계 결정의 배경을 공감하고

 

선택된 기술들의 필요성에 대해서 공감하고

 

팀원들과의 활동들에 공감하는

 

서로를 공감하고 존중해주는 문화를 배양하며 팀원들의 시야를 넓혀주는 그런 사람이 훌륭한 아키텍트가 아닐까 한다.

 

오랜만에 읽은 정말 훌륭한 책이다.

 

소프트웨어 아키텍트라면 늘 옆에 두고 활용할 수 있는 책이 되지 않을까 한다.

 

깔끔하게 번역해주신 김영재 옮김이에게 감사를 표하고 싶다.