한빛출판네트워크

IT/모바일

소프트웨어 아키텍처 101

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

한빛미디어

번역서

판매중

소프트웨어 아키텍처 101
좋아요: 2
  • 저자 : 마크 리처즈 , 닐 포드
  • 역자 : 이일웅
  • 출간일 : 2021-11-01
  • 페이지 : 472쪽
  • ISBN : 9791162244869
  • 물류코드 :10486

합계 : 28,800

도서판매처

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

     

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

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

     

     

    주요 내용

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

     

    추천사

    • 당신이 경험 많은 아키텍트든, 이제 새로 시작한 아키텍트든, 이 책은 여러분을 더 나은 아키텍트로 만들어줄 겁니다. 제가 커리어를 시작할 즈음에 이런 책이 나왔다면 얼마나 좋았을까요! _너새니얼 슈타, VMWare 아키텍트
    • 이 책은 소프트웨어 아키텍처를 섭렵할 수 있도록 충실하게 안내하는 가이드북이 될 것입니다. _레베카 J. 파슨스, 쏘우트웍스 최고 기술 책임자(CTO)

     

    소프트웨어 아키텍처 101_940px.jpg

     

  • [저자] 닐 포드

    종단간 소프트웨어 개발과 인도를 전문으로 하는 글로벌 IT 컨설팅 회사, 쏘우트웍스(ThoughtWorks) 의 이사이자 소프트웨어 아키텍트, 밈 랭글러(meme wrangler). 이 회사에 입사하기 전에는 미국에서 유명한 교육/훈련 개발 회사인 DSW Group에서 최고 기술 책임자(CTO)를 역임했다.

     

     

    [저자] 마크 리처즈

    마이크로서비스 등의 분산 아키텍처의 설계와 구현에 참여한 소프트웨어 아키텍트 경력자. 개발자를 소프트웨어 아키텍트 세계로 안내하는 ‘DeveloperToArchitect.com’을 처음 만든 사람이다.

    [역자] 이일웅

    20년 가까이 국내외 엔터프라이즈 현장에서 자바 전문 풀스택 개발자, 소프트웨어/애플리케이션 아키텍트로 프로젝트를 수행했다. 어느덧 50대를 바라보는 중년 아재가 되었지만 아직도 궁금한 기술이 많은 엔지니어고, 20여 권의 IT 전문서를 번역하며 동료, 후배 개발자들과 지식과 경험을 나누는 일에도 힘쓰고 있다. 집에서는 세 여인의 분에 넘치는 사랑을 받고 사는, 세상에서 제일 행복한 딸바보 아빠다.
     
  • CHAPTER 1 서론

    _1.1 소프트웨어 아키텍처란?

    _1.2 아키텍트에 대한 기대치

    _1.3 아키텍처의 교차점 그리고...

    _1.4 소프트웨어 아키텍처 법칙

     

     

    [PART I 기초]


    CHAPTER 2 아키텍처 사고

    _2.1 아키텍처 대 설계

    _2.2 기술 폭

    _2.3 트레이드오프 분석

    _2.4 비즈니스 동인의 이해

    _2.5 아키텍처와 코딩 실무 간 균형 맞추기

     

    CHAPTER 3 모듈성

    _3.1 정의

    _3.2 모듈성 측정

    _3.3 모듈에서 컴포넌트로


    CHAPTER 4 아키텍처 특성 정의

    _4.1 아키텍처 특성 (일부) 목록

    _4.2 트레이드오프 및 나쁜 것 중에서 제일 나은 아키텍처

     

    CHAPTER 5 아키텍처 특성 식별

    _5.1 도메인 관심사에서 아키텍처 특성 도출

    _5.2 요구사항에서 아키텍처 특성 도출

    _5.3 사례 연구: 실리콘 샌드위치

     

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

    _6.1 아키텍처 특성 측정

    _6.2 거버넌스와 피트니스 함수

     

    CHAPTER 7 아키텍처 특성 범위

    _7.1 커플링과 커네이선스

    _7.2 아키텍처 퀀텀과 세분도

     

    CHAPTER 8 컴포넌트 기반 사고

    _8.1 컴포넌트 범위

    _8.2 아키텍트 역할

    _8.3 개발자 역할

    _8.4 컴포넌트 식별 흐름

    _8.5 컴포넌트 세분도

    _8.6 컴포넌트 설계

    _8.7 컴포넌트 발굴 사례 연구: GGG

    _8.8 아키텍처 퀀텀 딜레마: 모놀리식이냐, 분산 아키텍처냐

     

     

    [PART II 아키텍처 스타일]


    CHAPTER 9 기초

    _9.1 기초 패턴

    _9.2 모놀리식 대 분산 아키텍처

     

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

    _10.1 토폴로지

    _10.2 레이어 격리

    _10.3 레이어 추가

    _10.4 기타 고려 사항

    _10.5 왜 이 아키텍처 스타일을 사용하는가

    _10.6 아키텍처 특성 등급

     

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

    _11.1 토폴로지

    _11.2 예제

    _11.3 아키텍처 특성 등급

     

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

    _12.1 토폴로지

    _12.2 레지스트리

    _12.3 계약

    _12.4 실제 용례

    _12.5 아키텍처 특성 등급

     

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

    _13.1 토폴로지

    _13.2 토폴로지 변형

    _13.3 서비스 설계 및 세분도

    _13.4 데이터베이스 분할

    _13.5 아키텍처 예시

    _13.6 아키텍처 특성 등급

    _13.7 언제 이 아키텍처 스타일을 사용하는가

     

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

    _14.1 토폴로지

    _14.2 브로커 토폴로지

    _14.3 중재자 토폴로지

    _14.4 비동기 통신

    _14.5 에러 처리

    _14.6 데이터 소실 방지

    _14.7 브로드캐스팅

    _14.8 요청-응답

    _14.9 요청 기반이냐, 이벤트 기반이냐

    _14.10 하이브리드 이벤트 기반 아키텍처

    _14.11 아키텍처 특성 등급

     

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

    _15.1 토폴로지

    _15.2 데이터 충돌

    _15.3 클라우드 대 온프레미스 구현

    _15.4 복제 캐시 대 분산 캐시

    _15.5 니어 캐시

    _15.6 구현 예시

    _15.7 아키텍처 특성 등급


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

    _16.1 역사와 철학

    _16.2 토폴로지

    _16.3 택소노미

    _16.4 재사용… 그리고 커플링

    _16.5 아키텍처 특성 등급

     

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

    _17.1 역사

    _17.2 토폴로지

    _17.3 분산

    _17.4 경계 콘텍스트

    _17.5 API 레이어

    _17.6 운영 재사용

    _17.7 프런트엔드

    _17.8 통신

    _17.9 아키텍처 특성 등급

    _17.10 더 읽을거리

     

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

    _18.1 아키텍처 ‘유행’은 계속 변한다

    _18.2 결정 기준

    _18.3 모놀리스 사례 연구: 실리콘 샌드위치

    _18.4 분산 아키텍처 사례 연구: GGG

     

     

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


    CHAPTER 19 아키텍처 결정

    _19.1 아키텍처 결정 안티패턴

    _19.2 아키텍처적으로 중요한

    _19.3 아키텍처 결정 레코드

     

    CHAPTER 20 아키텍처 리스크 분석

    _20.1 리스크 매트릭스

    _20.2 리스크 평가

    _20.3 리스크 스토밍

    _20.4 애자일 스토리 리스크 분석

    _20.5 리스크 스토밍 예시


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

    _21.1 도식화

    _21.2 프레젠테이션

     

    CHAPTER 22 개발팀을 효율적으로

    _22.1 팀 경계

    _22.2 아키텍트 성향

    _22.3 얼마나 제어해야 하나?

    _22.4 팀의 이상 징후

    _22.5 체크리스트 활용

    _22.6 지침 제시

    _22.7 마치며

     

    CHAPTER 23 협상과 리더십 스킬

    _23.1 협상과 조정

    _23.2 소프트웨어 아키텍트는 리더다

    _23.3 개발팀과의 융합

    _23.4 마치며

     

    CHAPTER 24 커리어패스 개발

    _24.1 20분 규칙

    _24.2 개인 레이더 개발

    _24.3 소셜 미디어 활용

    _24.4 종언

     

    Appendix A 자율 평가 문제

  • 새 시대 새 아키텍처에 대한 인사이트를 주는 ‘소프트웨어 아키텍처’ 가이드북

     

    빠르게 변하는 기술 혁신으로 업계를 바라보는 아키텍트의 시선도 변화가 필요하다. 이 책은 지난 10년간의 변화를 오늘날의 구조에 부합하는 새로운 지표를 바탕으로 소프트웨어 아키텍처를 현대적인 관점에서 살펴본다.

    아키텍처 기초(패턴, 사고, 특성)와 아키텍처 스타일(레이어드, 파이프라인, 마이크로커널, 이벤트, 서비스, 오케스트레이션), 그리고 테크닉과 소프트 스킬(결정, 리스크, 도식화, 협상, 리더십, 커리어패스 등)을 최근 생태계와 설계 아키텍처의 관점에서 깔끔하게 정리해 담았다.

    대학교 전공과목에서도 잘 알려주지 않는 소프트웨어 아키텍처에 대한 놀라운 인사이트와 주옥같은 명언을 이 책을 통해 배우길 바란다.


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


       



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



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



      출판년도 : 2021.11.01





      책을 읽기 전에...


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


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


      항목이라고 생각한다.


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


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




       



      책의 내용...


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


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


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


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


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


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


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


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


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




       


      파트 1 기초


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


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




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


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




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


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




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




       


      파트 2 아키텍처 스타일


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


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


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




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


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


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


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


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




       


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


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


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




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


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


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






       



      책을 읽고나서


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


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


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


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


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




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


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



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



      작성된 서평입니다."


       



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



       


      소프트웨어 아키텍처 101


      \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'개발자가 아키텍트\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'로 전향하는 데 실질적인 도움을 주는 실무 지침서다. 아키텍처 기초(패턴, 사


      www.hanbit.co.kr







    • 서론


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


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


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


      책 소개



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



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


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


      결론


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

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


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



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


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


       


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


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



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



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


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


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


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


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




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


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


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




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



      - 이벤트 기반 아키텍처



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






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


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



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


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


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



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




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


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



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


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



       



      11월의 서평단 후기



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


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


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


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


       



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







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











      20211122-소프트웨어 아키텍처 101-표지(앞).jpeg


       



      20211122-소프트웨어 아키텍처 101-표지(뒤).jpeg


       


       


       


       


       





       


       



      이 책은 소프트웨어 아키텍트(Software Architect)란 누구이며 어떤 덕목을 갖추어야 하는지 그리고 어떻게 성장할 수 있는지를 소개한다. 또한 가장 유명한 3-tire 구조의 Layered 아키텍처부터 MSA 라고 부르는 마이크로서비스 아키텍처까지 다양한 아키텍처를 소개한다.


       

      다른 기술서적과의 차별점이라면 이 책은 도메인에 대한 전문지식을 의미하는 하드 스킬(Hard Skills)과 함께 의사소통 및 대인관계 능력을 의미하는 소프트 스킬(Soft Skills)를 함께 소개한다. 이는 어떤 문제를 해결하려면 하드 스킬과 소프트 스킬 두 개가 모두 필요하기 때문이다. (하드 스킬과 소프트 스킬에 대한 상세한 설명은 아래 영상 참고)


















      책의 저자는 '아키텍처는 좋고 나쁜 게 없다, 오직 트레이드 오프만 있다'는 철학을 주장한다. 이론적인 내용 뿐만 아니라 코드 커버리지 및 품질을 점검하는 Crap4J, 패키지 간 의존성을 체크하는 JDepend, 아키텍처 피트니스를 체크하는 ArchUnit 와 같은 실무에 도움이 되는 도구도 함께 소개한다.






      특별히 책의 약 50%를 차지하는 <2부 아키텍처 스타일>은 그동안 어렴풋이 알고 있었던 각종 아키텍처 스타일을 일목요연하게 설명하고 정리하는데, 이 부분이 개인적으로는 큰 도움이 되었다. 그리고 <3부 테크닉과 소프트 스킬>에서 소개한 아래 사이트는 굉장히 유용했는데, 앞으로 소프트웨어 아키텍트로서 계속 배우고 성장하는 데 큰 도움이 될 것 같다.






      - (사이트) InfoQ, Technology Rader, DZone Refcardz






      올해 읽었던 기술서적 중 TOP 5 안에 든다고 말할 수 있을 정도로 책의 전반적인 내용이 좋았다. 만약 소프트웨어 아키텍트라는 역할이 무엇인지 궁금하다면, 더 좋은 개발자가 되기를 소망한다면 이 책을 읽어볼 것을 추천한다.






      #한빛미디어 #리뷰 #소프트웨어아키텍트 #아키텍트 #아키텍처 #설계 #O'REILLY #마이크로서비스 #레이어드아키텍처 #SOA #파이프라인아키텍처 #ACID #BASE #Crap4J #fitnessfunction #JDepend #ArchUnit #마이크로커널아키텍처















       




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


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


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



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



      책 소개




      소프트웨어 아키텍처 101 (출처: 한빛미디어)


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


      소프트웨어 아키텍처 101 책의 일부




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



      예상 독자




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


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


       



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


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



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



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



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




      이 책의 매력은?



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



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


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



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



      마치면서



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



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



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



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


    • 



      SE-b4e67268-792d-47fc-935b-9bb18af87b17.jpeg


       


       








      아키텍처.



      아키텍처가 뭘까?



      실무에서 숱하게 들어는 봤다.



      최근 유독 내 주변을 얼쩡거리는 '마이크로 서비스 아키텍처'는 하도 들어서 귀에 딱지가 앉을 지경이다.


       


       



      아키텍처.



      그래서 그게 정확하게 뭐냐고 물어보면 설명할 수 없다.



      설명할 수 없는 것은 이해하고 있다고 볼 수 없다.



      그러니 아키텍트가 정확히 무슨 일들을 하는 사람인지도 잘 모르겠다.



      소프트웨어 설계를 하는 사람? 넓게 보고 큰 그림을 그리는 사람?



      어쩐지 그걸로는 충분하지 않다.


       


       



      그래서, 아키텍처가 뭘까?



      아키텍처를 논하는 사람들은 아키텍처에 대해 잘 이해를 하고 있는가?



      그들과 나의 '멘탈 모델'은 같을까?



      아키텍트는 구체적으로 뭘 하는 사람들일까?



      이 상태에서 '아키텍처'를 논하는 말에 한 마디라도 의견을 얹을 수 있을까?


       


       



      이런 궁금증으로 보기 시작한 책.


       



       



      솔직히 소프트웨어 아키텍트는 유일하게 규정지을 수 있는 사람들이 아닙니다. 마틴 파울러 역시 그의 유명한 백서 'Who Needs an Architect?'에서 명언 한 구절을 인용했을 뿐 정의하려는 시도조차 거부했습니다.



       







      아키텍처는 중요한 것들에 관한 것이다. 그게 무엇이든 말이다. - 랄프 존슨


       







      CHAPTER 1 서론 / p25















      아키텍처를 공부하는 사람들이 명심해야 할 점은, 아키텍처란 예술과 마찬가지로 콘텍스트(문맥, 맥락)로서만 이해할 수 있다는 점입니다. 즉, 아키텍트가 내린 결정은 대부분 그들이 그렇게 결정한 당시 환경에 기인한 것입니다.


       



      CHAPTER 1 서론 / p27




       



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







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


       







      CHAPTER 1 서론 / p47



       



      1장 서론을 굉장히 흥미롭게 읽었다.



      '그래서, 아키텍처가 뭘까?', '아키텍트는 무엇을 하는 사람일까?'라는 질문에 대해 훌륭한 인사이트를 얻을 수 있었다. 소프트웨어 아키텍처 법칙 두 가지는 특히나 강렬해서 뇌리에 콕 박혀버렸다.



      '왜'를 고민하는 사람들.



      최악을 피해서 차악을 선택하는 사람들.



      "최고는 없다. 오직 나쁜 것 중에서 제일 나은 트레이드오프들만 있을 뿐!"


       


       



      책은 총 세 챕터로 이루어져 있는데,



      챕터 1에서는 아키텍처와 아키텍트 전반에 대해 설명하고 개발자와 어떤 차이점이 있는지, 개발자와는 달리 어떻게 소프트웨어를 바라봐야 하는지에 대해 이야기한다.


       


       



      챕터 2에서는 다양한 아키텍처 스타일에 대해 설명한다.



      좋았던 것은 1부에서 설명한 아키텍처 특성을 가지고 각 아키텍처별 특성 등급을 매기는 부분이었다.


       



      SE-1feb5f4a-c7b0-4bf1-a913-aadb7bfbab74.jpeg












       



      별점과 함께 장단점을 정리해 주니 내용을 받아들이기가 훨씬 좋았다.


       


       



      챕터 3의 제목은 '테크닉과 소프트 스킬'이다.



      아키텍트로서 다른 사람들과 함께 협업하기 위한 방법들을 꽤나 재미있게 풀어놓았다.


       



      스크린샷 2021-11-22 오전 3.35.51.png


       


       












       



      책이 450 페이지 정도로 두껍고 얼핏 내용이 어려워 보이기도 하지만



      실습을 하거나 달달 외워야 하는 내용들이 아니라서 생각보다 훨씬 술술 읽힌다.


       


       



      사실 실무에서 아키텍트와 함께 일할 기회가 없었고, 내 커리어 방향으로 봤을 때 앞으로도 없을 듯하다.



      그래서 그냥 '그런 사람들이 있다'고 알고 있던 부분에 대해 구체적으로 알 수 있는 기회였다.



      대개 시니어 개발자들이 커버하고 있는 그 업무들을 전문적으로 맡아 하는 사람들이 어떤 사람들인지에 대해 이해하고 역으로 그들의 입으로 이야기하는 '개발자'를 함께 타인의 눈으로 바라보면서 많은 생각을 했다.


       


       



      '왜'를 고민해야 하고



      좁고 깊은 지식보다는 넓고 얕은 지식을 가져야 하는 일.



      매력적이다.


       


       


       



      **













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



      **


       


       








      


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



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



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



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



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


       



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

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


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






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






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










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






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






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







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



       


      기업 통합 패턴 Enterprise Integration Patterns - YES24


      기업 내 복잡한 분산 애플리케이션들을 통합하려면 어떻게 해야 할까? IT 역사만큼이나 오래됐지만 여전히 가장 어려운 이 질문에 기업 통합 패턴은 시대를 초월한 해결책을 제시한다. 이 책의


      www.yes24.com








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






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






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










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








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






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


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




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




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



       



      arch.jpg


       



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



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




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




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


       



      trade.jpg


       



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




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




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



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


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

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

      • 최신 트랜드를 계속 유지한다.

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

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

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

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

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




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


       



      period.jpg


       



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




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




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




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




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


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


       



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


       



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


       



      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 [요가하는프로그래머]


    • KakaoTalk_Photo_2021-11-21-22-24-40.jpeg


       


       


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

       

      어느 회사에서나 개발하기 전에 아키텍팅 작업을 진행하게 된다. 대부분의 개발자들이 별 생각없이 진행하는 layered "Arhitecture" 또한 아키텍처 패턴중 하나이다. 이 책에서는 이러한 아키텍처 스타일들을 설명하고 더 나아가 아키텍트가 해야하는 업무 등에 대해 쓰여져 있는 책이다.

       

      아키텍처 관련된 책이라 실습을 위주로 진행하는 책이 아니라서 조금은 부담없이 읽을 수 있다. 하지만 아키텍팅 작업이 여러 기술과 패턴이 조합되어 있기 때문에 특정 디자인 패턴이나, 특정 기술(queue, topic)들에 대한 용어가 나오게 되는데 따로 설명이 들어가거나 하지는 않아서 이러한 부분들에 대한 이해가 없다면 조금 어려울 수도 있지 않을까 싶다. 그래도 대부분의 개발자라면 알고 있을만한 내용들이라 이러한 부분때문에 읽을 수 없을 것 같지는 않다.

       

      책은 짧은 호흡으로 읽을 수 있도록 여러 챕터로 구성되어 있다. 초반에는 소프트웨어 아키텍처가 무엇인지, 그리고 아키텍트는 어떤 작업을 수행해야 하는지에 대해서 알려준다. 특히나 최신 트랜드에 맞게 아키텍트와 개발자간 일방향성이 아니라 상호 보완적인 관계를 중요하게 생각하는 점이 특징이다. 그러면서 아키텍트는 개발자와는 다르게 어떤 생각을 가져야 하는지에 대해서도 알려준다. 그 후에는 아키텍처 특성들을 설명해주면서 아키텍팅을 하기 위해서 알아야할 개념들에 대해서 설명해준다. "아키텍처 카타" 라는 개념과 이를 활용한 예시를 드는 것도 흥미로웠다.

       

      두번째 챕터부터는 우리가 흔히 아키텍처라고 불리는 layered 아키텍처, 파이프라인 아키텍처, 마이크로 커널 아키텍처, 이벤트 기반 아키텍처 등에 대해서 설명해준다. 하지만 이 책의 특이한 점은 1장에서 설명한 개념을 가지고 각챕터의 마지막에 아키텍처 특성 등급을 설명해준다는 것이다. 퀀텀수, 배포성, 탄력성 등에 대해 별점을 매기고 장단점에 대해서 정리해준다. 예를 들어 이벤트 기반 아키텍처는 내고장성이나 확장성에는 뛰어나지만 테스트가 어렵고 단순하지 않고 복잡하다는 단점이 존재한다.

       

      세번째 챕터에서는 이러한 두번째 챕터의 아키텍처 스타일을 바탕으로 아키텍처를 결정하고 리스크를 분석하고 팀을 운영하는 방안에 대해서 설명한다. 재밌는 점은 프레젠테이션이 들어가 있다는 점인데 다이어그램을 그리고 도식화하고 애니메이션을 삽입해서 이해하기 쉽게 만들어야 한다는 점을 꼽고 있다. 마지막에는 개발을 주로 하지 않게되는 아키텍트 특성상 커리어가 고민이 들게 될텐데 이러한 부분들에 대해서 어떻게 커리어패스를 유지하고 개발해야하는지 알려준다.

       

      개인적으로는 회사에 개발자가 부족해 스스로 아키텍팅을 하고 개발을 해야 해서 관심이 많이 있던 분야 중 하나였다. 사실 대부분의 개발자들이 아키텍처를 공부한다기 보단 경험으로 이렇게 하면 괜찮은 것 같다, 혹은 컨퍼런스에서 그렇게 하더라 이정도로 넘어가게 될텐데 이렇게 한번쯤은 직접적으로 책을 읽고 공부해보는 것도 괜찮은 것 같다.

       

      책 내용이 어렵고 기술적으로 복잡한 내용이 아니기 때문에 대부분의 개발자들이 읽을만한 책이여서 다들 한번쯤 읽어보면 좋을 것 같다.


    • 



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



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



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



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


       



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


       



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


       



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


       



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


       



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


       


       




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



      

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


       


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


       


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


       


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


       


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


       


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


       


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


       


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


       



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

    •  



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







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



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







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







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







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







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



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











      df.jpg


       







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



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







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







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







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







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







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











      df2.jpg


       







      2) 아키텍처 사고



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







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



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







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







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







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











      p.png


       







      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은 보다 현대적이라고 볼 수 있습니다.


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


       


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


       



      1.jpg


       



      9.jpg


       


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



      10.jpg


      주요내용입니다.



      11.jpg


       


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


       



      12.jpg


       



      13.jpg


       


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


       



      2.jpg


      아키텍처는??



      3.jpg


       


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



      4.jpg


       


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



      5.jpg


      아키텍처의 역할



      6.jpg


       



      7.jpg


       



      8.jpg


       


      광범위한 범위하고 할 수 도 있지만, 현대성 현재의 아키텍처들을 다룬 것이 차별점이기도 합니다. 보통 다른 아키텍처 문서는 이론과 내용 이전 사례들이지만 이벤트기반, 쿠버네티스, 마이크로서비스(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)을 자주 해보는 것이다. 아키텍트가 결정 장애를 극복하는 가장 좋은 방법은, 실제로 각 제품을 응용한 예제 코드를 짜보고 실행 결과를 비교해보는 것이다.


       


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


       


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


       


      .


       


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

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


       


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


       


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


       


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


       


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

  • 내용이 없습니다.
  • 내용이 없습니다.
닫기

해당 상품을 장바구니에 담았습니다.
장바구니로 이동하시겠습니까?