[서평] 소프트웨어 아키텍처 101 (한빛미디어)

"성공의 공식에서 가장 중요한 한 가지 성분은 다른 사람들과 잘 지내는 방법을 아는 것이다."

-시어도어 루즈벨트

 

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

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

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

 

저자소개

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

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

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

사실 이런 지식들은 경험과 노하우가 쌓이고 수많은 시행착오를 겪은 뒤에야 얻을 수 있는 지식들인데 아키텍터를 꿈꾸고 있다면 이 책이 고민해야 하는 고민하고 있는 정말 많은 부분에 대해서 도움을 줄 수 있는 것 같다

 

서론에서는 

소프트웨어 아키텍처란? 아키텍트에 대한 기대치 ... 아키텍처의 교차점과 스포트 아키텍ㅊ터의 법칙에 대해 논한다. 

PART1에서는 기초에서는 아키텍처로 가는 기초에 대한 내용이다. 

아키텍처 사고, 모듈성, 아키텍처 특성 정의, 아키텍처 특성 식별, 아키텍처 특성의 측정과 서비스, 아키텍처 특성 범위,

컴포넌트 기반 사고 

PART2. 아키텍처 스타일에 대한 내용이다.

아키텍처 스타일의 기초, 레이어드 아키텍처 스타일, 파이프라인 아키텍처 스타일, 마이크로커널 아키텍터 스타일, 서비스 기반 아키텍처 스타일, 이벤트 기반 아키텍처 스타일, 공간 기반 아키텍처 스타일, 오케스트레이션 기반 서비스 지향 아키턱처 스타일, 마이크로서비스 아키텍처 스타일, 최적의 아키텍처 스타일 선정을 다룬다.

 

PART3에서는 테크닉과 소프트 스킬에 대한 내용이다.

아키텍처 결정, 아키텍처 리스크 분석, 아키텍처 도식화와 프리젠테이션, 개발팀을 효율적으로, 협상과 리더십 스킬, 커리어어패스 개발을 다룬다.    

 

책의 주요 키워드 도출

 

아키텍터가 코딩 실무능력을 유지하는 방법을 4가지 소개한다.(P65)

1.개념 증명(POC)를 자주 해 보는 것이다. POC는 아키텍트가 소스 코드를 직접 작성해보면서 구현 상세를 생각하게 되므로 아키텍터 결정을 검증하는데 유용하다. 아키텍트는 본인이 직접 구현한 결과 전체 솔루션을 개발하려면 어느 정도 공수가 필요할지 가늠할 수 있으며, 두 캐시 솔루션의 확장성, 성능, 종합적인 내고장성 등의 아키텍처 특성을 구체적으로 비교할 수 있다. POC 작업할때는 가능한 고품질 코드를 작성하는 게 좋다. 이유는 두가지...(중략) 

2.개발팀이 아주 중요한 유저 스토리 작업을 할 수 있도록 기술 부채 스토리나 아키텍처 스토리에 전념하는 것이다. 이터레이션을 하면서 버그를 잡는 일 역시 개발팀을 도우며 코딩 실무 능력을 유지하기에 좋은 방법이다. 

3.아키텍처 컴플라이언스 보장을 자동화하기 위해 피트니스 함수를 사용하는 것도 방법이다. 예를 들어, 커스텀 피트니스 함수를 만들어 실무 경험도 쌓으면서 아키턱처 컴플라이언스를 보장하는 식이다. 

4.자주 코드 리뷰를 하는 것이다. 아키텍트는 실제로 코딩하는 사람은 아니지만, 적어도 소스코드에 관여하는 사람들이다.코드리뷰를 수행하면 아키텍처 컴플라이언스를 보장할 수 있고 경험이 많지 않은 팀원을 멘토링하고 코치할 기회가 생기는 등 여러모로 장점이 많다.

 

소프트웨어 아키텍처 용어의 95%는 '모듈성'의 이로움을 찬양하는 데 사용되고 있지만, 정작 모듈성을 이떻게 달성할지에 대해서는 별다른 얘기가 없다. - 글렌포드 J.마이어스,1978년

 

모듈의 사전적 정의는 '복잡한 구조를 만드는 데 쓰이는 각각의 표준화된 부품이나 독립적인 단위'라고 나온다.

아키텍처를 논할때 클래스, 함수처럼 코드를 묶어 놓은 덩어리를 모듈성이라는 일반용어로 나타낸다.

 

업무를 진행하기 위해 기술의 깊이를 확보해야 하는 개발자와 달리, 소프트웨어 아키텍트는 아키텍트답게 사고하고 아키텍트 시각을 유지하기 위해 상당한 기술을 갖춰야 한다. 

책 55페이지에 나오는 그림 2-4 세상의 모든 지식을 표현하는 지식 피라미드에서는 세가지 지식의 종류가 있다.

내가 알고 있는 것 - 개발자가 계속 유지해야 할 부분, 기술의 깊이

내가 모르다는 사실을 아는 것 - 기술의 폭

내가 모르는 사실조차 모르는 것... 

내가 알고 있는 것에서 내가 모른다는 사실을 아는 것으로 특정분야 기술의 폭이 내려갈때 우리는 '전문 영역'이라고 말한다.

 

역효과 

1.아키텍트가 되어 다양한 분야에서 전문성을 유지하려고 하나, 어느 하나도 성공하지 못한 채 그러는 도중 지레 지쳐버린다.

2.김빠진 전문성(stale expertise)이 나타난다. 즉, 자신의 낡은 정보가 아직도 첨단을 달리는 것처럼 그릇된 인식에 사로잡히게 된다. 우리는 대기업에서 그런 현상을 자주 목격했는데, 회사의 창업 맴버 개발자들이 리더가 되어 아직도 옛날 기준으로 기술 결정을 내리는 것이다. ('꽁꽁 언 원시인 안티패터' 참조) - P58 

 

개발팀을 효율적으로...

소프트 아키텍트는 기술 아키텍처를 정립하고 아키텍처 결정을 내릴 뿐만 아니라, 개발팀이 아키텍처를 올바르게 구현하도록 안내할 책임이 있다. 이 일을 잘하는 아키텍트는 개발팀과 긴밀하게 협력하여 문제를 해결하고 성공적인 해법을 찾아낸다. 지금까지 우리는 아키텍트가 개발팀을 무시하고 폐쇄적인 환경에서 아키텍처 작업을 하는 모습을 참 많이 봤다. 그런 아키텍처가 개발팀에 전달되면 개발팀은 아키텍처를 올바르게 구현하느라 상당히 애를 먹죠. 팀을 생산적으로 만드는 능력은, 유능하고 성공적인 소프트웨어 아키텍트가 다른 아키텍트와 차별화되는 강점이다.

소프트웨어 아키텍트는 팀을 기술적으로 이끌 뿐만 아니라 아키텍처 구현을 통해 팀을 리드하기도 한다. 소프트 아키텍트는 개발팀과 긴밀한 협력관계를 유지하면서 팀 역학을 관찰하고 변경을 촉진하여 효과적으로 팀을 움직일 수 있다. 이것이 바로 기술만 가진 아키텍트와 유능한 소프트웨어 아키텍트를 구분하는 잣대이기도 하다.

 

협상과 리더십 스킬

협상(negotitation)과 리더십(leadership)은 습득하기 어려운 스킬이다. 유능한 소프트웨어 아키텍트가 되려면 오랜 기간에 걸쳐 학습, 실습, 그리고 '산 지식(lessons learned)을 체득해야 한다. 하룻밤 사이에 아키텍트는 협상과 리더십의 달인이 될 수 없기에 이책에서는 중요한 협상, 리더십 스킬을 얻기 위한 출발점을 제시한다. (P417 참조)

 

몇가지 Tip이 소개되는데 살펴보면 ...

1.상황을 더 잘 이해하기 위해 문법과 유행어를 사용하세요.

2.협상에 돌입하기 전, 가능한 많은 정보를 수집하세요.

3.다른 모든 것이 실패하면 비용과 시간으로 설명하세요.

4.'분할 및 정복(divide and conquer)'규칙을 활용해서 요구사항 또는 필우 조건을 검증하세요.

5.증명(demonstration)은 언제나 논쟁(discussion)을 이긴다는 사실을 명심하세요.

6.지나치게 논쟁을 벌이려고 하거나 협상과정에서 개인적인 감정을 드러내지 마세요. 간결 명료한 추론에 차분한 리더십을 더하면 반드시 협상에서 승리할 것입니다.

7.개발자가 아키텍처 결정을 수용해서 어떤 작업을 하도록 설득할 떄에는 '고압적으로 지시'하지 말고 왜 그일을 해야 하는지 정당성을 제공하세요.

8.개발자가 아키텍트의 결정에 동의하지 않을 경우 그들 스스로 해결책을 찾도록 유도하세요.  

 

개발자는 나방이 불빛에 끌리듯 복잡한 것에 이끌립니다. 결과는 대부분 똑같죠.

아키텍처는 모든 게 다 트레이드오프입니다. 

아키텍처 4C - 커뮤니케이션(Communication), 협동(Collaboration), 명료함(Clarity), 간결함(Consciseness)

실용적으로 행동하되 비전을 가져라.

 -비전은 상상력이나 지혜를 발휘하여 미래를 떠올리거나 계획한다.

 -이론적으로만 생각하지 않고 실제에 근거한 방식으로, 분별 있게, 현실적으로 일처리한다. 

    - 예산 제약 등의 비용요소

    - 시간 제약 등의 시간 요소

    - 개발팀의 스킬 세트 및 수준

    - 아키텍처 결정에 관한 트레이드오프와 의미

    - 제안된 아키텍처 설계 또는 솔루션의 기술적인 한계

 -모범을 보여 팀을 리드하라. 

    - 회의 전에 미리 의제를 요청해서 아키텍트가 그 회의에 정말 참석해야 하느지 여부를 판단하세요.

 

 

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