한빛미디어

프로그래밍

개발자에서 아키텍트로

38가지 팀 활동을 활용한 실전 소프트웨어 아키텍트 훈련법

한빛미디어

번역서

판매중

개발자에서 아키텍트로
좋아요: 34
  • 저자 : 마이클 킬링
  • 역자 : 김영재
  • 출간일 : 2021-06-07
  • 페이지 : 392쪽
  • ISBN : 9791162244326
  • 물류코드 :10432

합계 : 24,300

도서판매처

  • 개발자에서 아키텍트로 거듭나기! 초보 아키텍트를 위한 실전 입문서

     

    이 책은 개발자에서 아키텍트로, 변화의 첫걸음을 내딛는 이를 위한 실전 입문서다. 설계를 위한 필수 지식, 아키텍처 패턴, 모델, 설계 방법론, 커뮤니케이션 노하우를 상세히 소개한다. 문제 상황에서 팀원들과 해볼 수 있는 38가지 팀 활동을 소개하며 실무 적응 능력을 키워준다.

     

    아키텍처를 잘 모르는 개발자라면, 이 책을 읽으며 개발 업무의 구조를 이해하는 실력을 향상할 수 있다. 현업 아키텍트라면, 결정사항을 잘 설명하여 팀을 이끌고 이해관계자와 소통하는 능력을 키울 것이다. 이 책과 함께 프로젝트와 팀을 성공으로 이끄는 훌륭한 아키텍트로 거듭나길 바란다.

     

    상세이미지_개발자에서 아키텍트로.jpg

     

  • [저자] 마이클 킬링

    경험 많은 소프트웨어 아키텍트, 애자일 실천가이자 개발자. 전투 시스템 설계, 검색 애플리케이션, 웹 애플리케이션, IBM 왓슨을 포함해 다양한 소프트웨어 시스템과 일하며 경험을 쌓았다. 소프트웨어 관련 일을 하지 않을 때는 하이킹, 달리기, 요리, 캠핑을 즐긴다.

    [역자] 김영재

    평범한 IT 연구원으로 무난하게 지내다가 교육 분야에 관심을 가지며 모바일 애플리케이션 ‘바로풀기’를 개발한 에듀테크 스타트업 바풀의 CTO가 되었다. 바풀이 네이버/LINE에 인수된 후 기술 전문 임원인 ‘펠로우’로 재직 중이다. 여러 프로덕션 조직을 이끌면서 업무 프로세스, 팀워크, 자동화, 아키텍처에 관심을 가지고 있다.

     

  • [PART 1 소프트웨어 아키텍처]


    CHAPTER 1 소프트웨어 아키텍트가 되다

    1.1 소프트웨어 아키텍트가 하는 일

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

    1.3 팀에서 아키텍트가 되려면

    1.4 훌륭한 소프트웨어 만들기

    1.5 사례 연구: 라이언하트 프로젝트

    1.6 마치며

     

    CHAPTER 2 디자인 싱킹 기초

    2.1 디자인 싱킹의 네 가지 원칙

    2.2 디자인 마인드셋 장착하기

    2.3 생각-실행-확인하기

    2.4 마치며

     

     

    [PART 2 아키텍처 설계의 기초]


    CHAPTER 3 설계 전략 고안하기

    3.1 만족스럽게 설계하기

    3.2 설계를 얼마나 우선해야 하는가

    3.3 위험 요소를 가이드로 삼기

    3.4 설계 계획 세우기

    3.5 사례 연구: 라이언하트 프로젝트

    3.6 마치며

     

    CHAPTER 4 이해관계자와 공감하기

    4.1 알맞은 사람과 이야기하기

    4.2 이해관계자 맵 만들기

    4.3 비즈니스 목표 탐색하기

    4.4 사례 연구: 라이언하트 프로젝트

    4.5 마치며

     

    CHAPTER 5 아키텍처 핵심 요구사항 알아내기

    5.1 제약으로 설계 선택지 줄이기

    5.2 품질 속성 정의하기

    5.3 기능 요구사항 찾아내기

    5.4 아키텍처에 영향을 미치는 다른 요소 찾아내기

    5.5 콘웨이 법칙

    5.6 필요한 정보에 깊이 들어가기

    5.7 ASR 워크북 만들기

    5.8 사례 연구: 라이언하트 프로젝트

    5.9 마치며

     

    CHAPTER 6 아키텍처 선택하기

    6.1 대안을 위한 분기, 결정을 위한 융합

    6.2 제약 수용하기

    6.3 품질 속성 끌어올리기

    6.4 구성 요소에 기능별 역할 할당하기

    6.5 변화에 대응하는 디자인

    6.6 결정은 미룰 수 있을 때까지 미룬다

    6.7 사례 연구: 라이언하트 프로젝트

    6.8 마치며

     

    CHAPTER 7 패턴으로 기초 만들기

    7.1 아키텍처 패턴이란 무엇인가

    7.2 레이어 패턴

    7.3 포트와 어댑터 패턴

    7.4 파이프와 필터 패턴

    7.5 서비스 지향 아키텍처 패턴

    7.6 발행/구독 패턴

    7.7 공유 데이터 패턴

    7.8 멀티 계층 패턴

    7.9 숙련된 전문가 패턴

    7.10 오픈소스 공헌 패턴

    7.11 큰 진흙 공 패턴

    7.12 새로운 패턴 발굴하기

    7.13 사례 연구: 라이언하트 프로젝트

    7.14 마치며

     

    CHAPTER 8 의미 있는 모델로 복잡도 관리하기

    8.1 아키텍처 파악하기

    8.2 메타모델 설계하기

    8.3 코드로 모델 구현하기

    8.4 사례 연구: 라이언하트 프로젝트

    8.5 마치며

     

    CHAPTER 9 아키텍처 디자인 스튜디오 운영하기

    9.1 아키텍처 디자인 스튜디오 계획하기

    9.2 적절한 설계 활동 선택하기

    9.3 적절한 참가자 초대하기

    9.4 그룹 관리하기

    9.5 원격으로 협업하기

    9.6 사례연구: 라이언하트 프로젝트

    9.7 마치며

     

    CHAPTER 10 설계 시각화하기

    10.1 다양한 관점으로 아키텍처 표현하기

    10.2 멋진 다이어그램 그리기

    10.3 사례 연구: 라이언하트 프로젝트

    10.4 마치며

     

    CHAPTER 11 아키텍처 문서화하기

    11.1 문서화의 가치

    11.2 상황에 맞는 서술 방법

    11.3 명세서의 독자 고려하기

    11.4 이해도가 중요하다

    11.5 이해관계자의 관심사에 맞추어 뷰 구성하기

    11.6 결정에 대한 논리적 근거 설명하기

    11.7 사례 연구: 라이언하트 프로젝트

    11.8 마치며

     

    CHAPTER 12 아키텍처 평가하기

    12.1 평가를 통해 배우기

    12.2 설계 테스트하기

    12.3 평가 워크숍 꾸리기

    12.4 빠르게, 자주, 지속해서 평가하기

    12.5 사례 연구: 라이언하트 프로젝트

    12.6 마치며

     

    CHAPTER 13 아키텍트에게 힘 실어주기

    13.1 아키텍처 사고력 향상시키기

    13.2 팀의 의사결정력과 역량 높이기

    13.3 안전한 훈련으로 기회 만들기

    13.4 설계 권한 위임하기

    13.5 함께 아키텍처 설계하기

    13.6 사례 연구: 라이언하트 프로젝트, 성대한 결말

    13.7 마치며

     

     

    [PART 3 아키텍트의 은빛 도구상자]


    CHAPTER 14 문제를 이해하고 싶을 때

    활동 1 하나만 고르기

    활동 2 공감 지도

    활동 3 GQM 접근법

    활동 4 이해관계자 인터뷰

    활동 5 가정 나열하기

    활동 6 품질 속성 레이다 차트

    활동 7 미니 품질 속성 워크숍

    활동 8 관점 매드 립

    활동 9 허수아비 반응

    활동 10 이해관계자 맵

     

    CHAPTER 15 해결책을 찾고 싶을 때

    활동 11 아키텍처 의인화

    활동 12 아키텍처 플립북

    활동 13 컴포넌트-역할 카드

    활동 14 개념도

    활동 15 나눠서 정복하기

    활동 16 이벤트 스토밍

    활동 17 그룹 포스터

    활동 18 라운드 로빈 설계

    활동 19 화이트보드 토론

     

    CHAPTER 16 손에 잡히는 설계를 만들고 싶을 때

    활동 20 아키텍처 의사결정 기록(ADR)

    활동 21 아키텍처 하이쿠

    활동 22 컨텍스트 다이어그램

    활동 23 인기 독서 목록

    활동 24 인셉션 덱

    활동 25 모듈식 분해 다이어그램

    활동 26 가지 않은 길

    활동 27 프로토타입

    활동 28 시퀀스 다이어그램

    활동 29 시스템 메타포

     

    CHAPTER 17 설계 대안을 평가하고 싶을 때

    활동 30 아키텍처 브리핑

    활동 31 코드 리뷰

    활동 32 의사결정 매트릭스

    활동 33 관측하기

    활동 34 질문-코멘트-우려사항

    활동 35 리스크 스토밍

    활동 36 온전성 검사

    활동 37 시나리오 훑어보기

    활동 38 스케치하고 비교하기

     

    부록: 기여자들

  • 출판사 리뷰

    소프트웨어 아키텍처를 설계하는 일은 언제나 혼란스럽습니다. 비즈니스 목표를 이해하고 여러 이해관계자의 요구사항을 파악해야 할 뿐만 아니라, 제약을 극복하면서도 모두가 만족할 만한, ‘제대로’ 작동하는 프로그램을 만들어야 하기 때문입니다. 아키텍트에게는 소프트웨어를 비즈니스 관점에서 바라보는 안목뿐만 아니라, 시스템 전체를 조망하고 세부 기술을 이해하는 능력도 필요합니다.

     

    이 책은 개발자에서 아키텍트로, 변화의 첫걸음을 내딛는 이를 위한 실전 입문서입니다. 회사에서 갑자기 설계 일을 맡게 된 사람이나, 프로젝트를 직접 이끌어야 하는 스타트업 개발자와 CTO에게 최적의 책입니다. 물론 소프트웨어 아키텍처를 폭넓게 이해하고픈 개발자에게도 유용합니다.

     

    아키텍처와 설계에 대한 필수 지식, 경력 있는 아키텍트의 경험담, 실무와 현장의 사례를 이 책 한 권에서 모두 볼 수 있습니다. 하나의 장이 끝날 때마다 ‘라이언하트’라는 가상 도시의 프로젝트 사례로 배운 내용을 정리합니다. 난항을 겪으면서도 성공적으로 마무리된 프로젝트 사례를 따라가다 보면, 여러분도 할 수 있다는 자신감을 얻게 될 것입니다. 이 책을 읽는 모두가 프로젝트와 팀을 성공으로 이끄는 훌륭한 아키텍트로 거듭나길 바랍니다.

     

     

    주요 내용

    - 소프트웨어 아키텍처란 무엇이고 아키텍트는 무슨 일을 하는가

    - 디자인 싱킹과 디자인 마인드셋을 활용한 아키텍처 설계 전략

    - 이해관계자와 비즈니스 목표를 명확하게 파악하고 이해하기

    - 아키텍처 핵심 요구사항을 파악하고 품질 속성 정의하기

    - 자주 사용하는 아키텍처 패턴과 사용법

    - 아키텍처 모델을 활용해 시스템 복잡도 관리하기

    - 아키텍처 디자인 스튜디오 운영하기

    - 설계를 시각화하고 아키텍처 문서화하기

    - 아키텍처를 평가하고 피드백을 반영해 개선하기

    - 적절하게 설계 권한을 위임하며 팀의 역량 높이기

    - 현업에서 바로 활용 가능한 38가지 팀 활동

     

     

    대상 독자

    - 개발자에서 아키텍트로 커리어를 변경하고 싶은 사람

    - 소프트웨어 아키텍처를 제대로 이해하여 실무 개발 능력을 향상하고 싶은 사람

    - 소프트웨어의 전체 구조 및 개발 과정 전체를 이해하고 싶은 신입 개발자

    - 소프트웨어를 둘러싼 다양한 이해관계자들의 관점을 이해해보고 싶은 사람

     

     

    개발 경력별 이 책의 활용법

    - 신입 개발자: 단순히 코드를 짜는 일을 뛰어넘어, 소프트웨어 개발 및 프로젝트이라는 숲을 보며 시야를 넓혀보세요.

    - 5년 이하 경력의 개발자/아키텍트: 흔히 쓰는 패턴, 모델, 설계 방식을 이해하고, 아키텍처를 시각화하고 문서화하는 방법을 배우세요. 사람들과 협업할 때 어려움을 겪는다면, 사례 탐구와 경력 있는 아키텍트들의 기고문을 통해 지혜로운 방법을 찾아보세요.

    - 10년 이상 경력의 개발자/아키텍트: 아키텍트로서 프로젝트를 직접 이끌거나 개발 팀장의 역할을 수행해야 하나요? 팀원 및 이해관계자와 제대로 커뮤니케이션 하는 방법을 익혀보세요. 문제를 해결하기 위해 해볼 만한 활동을 찾아보고 책에서 소개하는 방법을 직접 따라해보세요. 금세 해결책을 찾을 수 있을 겁니다. 

     

     

    추천사

    소프트웨어 아키텍처를 다루는 책은 많지만 저는 늘 현실을 반영한 책에 갈증을 느끼고 있었습니다. 목차를 보면 바로 느낄 수 있을 겁니다. 이 책은 실제로 프로젝트를 진행하면서 맞닥뜨리는 상황에서 어떤 요소를 고려하고, 또 품질과의 트레이드오프는 어느 정도로 감수할 것인지 등 현실을 반영하며, 더 견고한 아키텍처를 만들어가는 이야기를 전달합니다. 사람들과의 협업까지 녹여낸 이 책은 성장하는 서비스와 기술 사이에서 고민하는 분들에게 도움이 될 것입니다.

    - 박미정, 전 우아한형제들 베트남 개발 팀장

     

    ‘뭐지 이 혼종은?’ 이 책의 첫인상이 그랬습니다. 쉰내나는 소프트웨어 아키텍트 고인물이자 개념 없는 애자일 파다완인 제게, 이 책은 마치 과거와 현재의 시공간을 넘나드는 <닥터 스트레인지>의 타임 스톤 같았습니다. ‘이게 가능해?’, ‘이렇게 접근한다고?’ 하며 그간 쌓은 고정관념이 파괴되어 당황하면서도, 갑갑했던 속내를 누가 대신 폭로하듯 통쾌하기도 했습니다. 아키텍처와 애자일이란 두 금기어가 합쳐지니 오랜 저주가 풀린 느낌이네요. 여러분 축하합니다. 이 책과 함께하면 제다이 원로회의 같은 아키텍처 회의를 더는 하지 않아도 될 거예요.

    - 신상재, 몰락 소프트웨어 아키텍트, 삼성SDS

     

    소프트웨어 아키텍처라는 복잡한 내용과 이것을 실제로 적용하는 방법을 소개하는 책입니다. 아키텍트의 관점에서 개발 조직에서 진행할 수 있는 워크샵 기법에 대해서도 자세히 다루었습니다. 아키텍트가 되고 싶은 개발자, 개발 팀 내 생산성을 높이는 활동을 하고 싶은 분들 모두에게 추천합니다.

    - 윤석준, 카카오엔터프라이즈

     

    오래 전 월스트리트에 있는 회사로 첫 출근을 했을 때, 누군가 자신을 아키텍트라 소개했다. 웅대한 계획을 즐겨 말하던 그는 오래지 않아 회사를 그만두었다. 코딩을 잘하는 회사의 실력자 친구들은 그의 말을 귀담아듣지 않았는데, 동료의 영향을 받은 나도 그랬다. 그의 코딩 실력을 아무도 신뢰하지 않았기 때문이다.

    아키텍트가 되고자 하는 사람에게 높은 수준의 코딩 실력은 필수다. 그게 출발점이다. 하지만 코딩 실력은 자체로 아키텍트의 길을 보장하지 않는다. 아키텍트가 지녀야 하는 덕목과, 지식과, 경험이 많기 때문이다. 이 책은 그 부분을 설명한다. 아키텍트로 성장하고 싶은 개발자라면, 이 책을 통해 아키텍트가 반드시 알아야 하는 기술과 현실을 효과적으로 배우게 될 것이다. 김영재 역자 자신이 훌륭한 개발자이자 아키텍트라서 번역도 매우 훌륭하다. 일독을 권한다.

    - 임백준, 삼성리서치


    • 



      이번에 리뷰하게 된 도서는 "개발자에서 아키텍트로" 이다.


       



      우선 이 책을 선택하게 된 이유는 아래와 같다.



      어느정도 현업에서 개발을 진행하다 보면 아키텍처를 고민하게 되는 상황을 필연적으로 마주치리라고 본다.


       



      처음에는 이미 만들어져있는 제품 코드를 유지보수하는 상황에서는 새로 설계할 일이 많지 않기 때문에 아키텍쳐에 대한 고민을 할 일이 별로 없는것 같다.



      하지만 점점 시간이 지남에 따라 새로운 프로젝트를 진행하게 되며 그 규모가 작을 수도 클 수도 있지만 새로 만들어야 하는 상황을 마주하게 된다.


       



      그럴때면 대학시절 배웠던 소프트웨어 공학 전공 과목이 떠오르게 된다.



      그때는 내용들도 딱딱했던 기억이며, 그 내용들을 내가 언제 어떻게 사용할 수 있을지 감이 오지 않았던 것이 사실이었다.



      하지만 현업에서 지내다보면 학부시절에 배웠던 사항들을 다시금 들춰보게 되는 타이밍들이 있는 것 같다.


       



      이렇게 신규 개발을 진행해 나가야 하는 과정이 필요한 시기에 이 책을 읽게 된다면



      큰 도움이 될 것 같다는 느낌이 들어 선택하게 되었다.


       



      과연 선택은 옳았을까?


       



      일단 도움이 되는 것 같다. 라는게 나의 의견이다.


       



      이 책은 대학 전공 서적과는 다르게 읽다보면 실전적인 느낌을 계속해서 받게 되었다. 물론 대학 시절의 나와 현업에 있는 지금의 내가 다르기 때문에 느낀것일 수 도 있지만 내용 자체가 딱딱하지 않고 잘 읽혀졌다.


       



      초반에는 소프트웨어 아키텍쳐에 대한 설명을하고 중반에는 아키텍쳐 설계에 대한 기초 설명으로 어떤식으로 접근해야 하는지 차근차근 설명해준다.



      그리고 마지막 후반에는 38가지 활동을 통하여 아키텍쳐 설계에 대한 실천적인 내용들을 설명하고 있다.


       



      사실 이 책을 읽는다고 해서 아키텍처 설계 능력이 올라가는 것은 아니라고 본다.



      간략하게 설명을 하고 있지만 내용은 방대하기 때문에 쉽게 볼 책은 아니라는 생각이다. 그리고 개발만 했었더라면 들어보지 못한 용어들도 많고 설계에 대한 생각의 깊이와 넓이를 많이 확장해야 겠다는 느낌을 받았다.


       



      확실히 아키텍트로 넘어가거나 아키텍처 설계를 해야 하는 상황이 되면 개발관점보다는 훨씬 넢은 시각에서 봐야 한다는 것을 이 책을 통하여 느낄 수 있었다.


       



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



      

    •  



      archi.jpg


       


       



      개발자에서 아키텍트로



      마이클 킬링 지음



       


       



      이 책을 읽어야 할 대상은 분명하다. 아키텍쳐를 진짜로 고민하는 사람.



      개발자나 그저 막연히 아키가 하고 싶어서 보려고 한다면 비추다.



      마치 대학 학부수업 느낌이 들 것이다. 코딩이라던가 실습예제 같은 것을 기대했다가는 영락없이 책꽂이로 직행이다. 대학교재 바로 옆자리로사진 찍은 골동품 교과서 소프트웨어 아키텍처 이론과 실제옆이라면 더 좋을 것이다.



       



      추천의 글을 보면 뭔가 있을 것 같은 기대감이 올라온다. 그러나 솔직히 지루하다. 우리나라에서 이렇게 프로젝트 하는 경우가 일년에 몇 개나 있을까? 다른 리뷰어들의 글을 보면서 진짜 저렇게 많은 사람이 높은 평점을 주는 이유가 뭘까 궁금했다. 내 내공은 아직 멀었나보다.



       



      또 하나 아키텍트의 역할과 To-do list를 제시했지만, PM이나 PL 역할과 너무 중첩된다. 국내 어떤 프로젝트에서 PM, PL 제쳐놓고 아키가 나서서 이해관계자나 ASR을 분석하고 있나? 20년 넘게 프리랜서로 경험했던 것들은 너무 뻔한 국한된 프로젝트들 뿐이었나?



       



      이 책을 비난하는 것은 아니다. 어쨌든 건질만한 것들은 있다.



      우리가 아키텍쳐를 너무 우습게 생각하고 있었다는 것, 점점 사라져가는 아키 포지션이 그래도 가치가 있다는 것, 골동품처럼 생각했던 아키텍처 패턴을 떠올릴 수 있었다는 교훈은 남는다. 책꽂이를 장식하던 소프트웨어 아키텍처 이론과 실제를 소환한 것도 단발성이지만 의미는 있었는데, 요 골동책보다는 훨씬 간결하고 이해가 쉽기 때문이다.



       



      제대로 된 소프트웨어 팀을 만든다면 이렇게 해보고 싶다는 생각이 들기는 하다. 초중급 수준의 개발자라면 이 책보다는 디자인 패턴 관련 책이 더 적당할 것 같다.



       



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


       





       



       


    • 



      PART1 소프트웨어 아키텍처



      CHAPTER 1. 소프트웨어 아키텍트란 무엇이며, 소프트웨어 아키텍트가 하는 일에 대해서 설명합니다. 



      소프트웨어 아키텍트는 팀에서 독특한 위치에 있습니다. 



      아키텍트는 소프트웨어가 언제 어떻게 전달되는지 결정하는 사람입니다. 



      또한 소프트웨어가 비즈니스 목표에 부합하도록 만드는 사람입니다. 코딩은 하지만 알고리즘이나 코드를 짜기보다는 더 크고 많은 것을 설계합니다.


       



      CHAPTER 2. 디자인싱킹은 소프트웨어를 개발하는 데서 기술과 사람을 잇는 방법을 알려줍니다. 


       



      PART2 아키텍처 설계의 기초


       



      CHAPTER 3. 설계 전략 고안하기에서는 아키텍처를 설계할 때 디자인 마인드셋을 적용하고 생각-실행-확인 사이클을 거치면서 어떤 부분에 초점을 맞춰야 할지 배웁니다. 


       



      CHAPTER 4. 이해관계자와 공감하기 - 이해관계자란 어떤 소프트웨어에 관심이 있거나 관여된 사람을 일컫습니다. 이해관계자가 누구인지 알아내고 그들의 요구를 이해하는 일이 아키텍트의 역할이기도 합니다. 


       



      CHAPTER 5. 아키텍처 핵심 요구사항 알아내기 - 챕터4에서는 이해관계자를 중심에 두고 누가 소프트웨어에 영향을 미치고 왜 우리가 그들을 중요하게 생각해야 하는지 알아봤습니다. 이번 장은 소프트웨어 아키텍처 관점에서 '무엇을'에 해당하는 요구사항을 알아봅니다. 


       



      CHAPTER 6. 아키텍처 선택하기 - 이번 장에서는 핵심 요구사항을 이용해 구조를 어떻게 선택하고 의사결정을 해나가는지에 대해 알아봅니다. 


       



      CHAPTER 7. 패턴으로 기초 만들기 - 어떤 소프트웨어 시스템이든 작은 주제의 패턴을 모아놓고, 그 위에서 전체 디자인을 결정합니다. 패턴을 사용하면 팀원들에게 소프트웨어 아키텍처를 설득하기 편해집니다. 패턴을 사용하면 수고스러운 노력을 직접 기울이지 않고도 다른 사람들의 지혜를 얻을 수 있습니다. 이 번 장에서는 가장 자주 사용하는 패턴 몇 가지를 알아보고, 이를 요구사항에 어떻게 적용하는지 소개합니다. 


       



      CHAPTER 8. 의미 있는 모델로 복잡도 관리하기 - 소프트웨어 복잡도가 점차 증가할때 쯤에는 몇가지 선택지가 있습니다. 요구사항을 수정하거나 코드의 일정 부분을 덜어내서 다시 소프트웨어를 좀 더 작게 만들 수 있습니다. 이번 장에서는 여러 요소를 쌓아올리면서 의미 있는 모델을 만드는 방법과 이를 통해 더 수월하게 아키텍처를 파악하는 방법에 대해 알아봅니다. 


       



      CHAPTER 9. 아키텍처 디자인 스튜디오 운영하기 - 이 장에서는 아키텍처 디자인 스튜디오를 계획하고 운영하는 방법에 대해 알아봅니다. 먼저 디자인 스튜디오의 개요부터 짚어본 후, 디자인 스튜디오를 쉽게 꾸리는 방법을 배울 것입니다. 


       



      CHAPTER 10. 설계 시각화 하기 - 챕터 10에서는 아키텍처 다이어그램을 그리는 방법을 배우고 개발들과 수월하게 대화하는 방법에 대해서 알아봅니다. 


       



      CHAPTER 11. 아키텍처 문서화 하기 - 훌륭한 문서는 업무 계획의 근간이 되며, 커뮤니케이션 보충 자료이자 협업 도구이기도 합니다. 설계 의사 결정을 할때 모두에게 공통의 인식을 심어주어서 더 나은 품질의 소프트웨어를 만들 수 있게 합니다. 


       



      CHAPTER 12. 아키텍처 평가하기 - 이 장에서는 아키텍처에 성적표를 부여하는 방법에 대해서 알아봅니다. 평가의 피드백은 팀을 교육하고, 설계 시 의사결정을 보강하고, 배포의 위험을 줄이고, 아키텍처를 개선하는 데 사용 할 수 있습니다. 


       



      CHAPTER 13. 아키텍트에게 힘 실어주기 - 이 번 장에서는 멋진 소프트웨어 아키텍처를 함께 설계하면서 팀을 성장시키고 역량을 강화하는 방법을 배웁니다. 


       



      PART 3. 아키텍트의 은색 도구상자 


       



      CHAPTER 14. 문제를 이해하고 싶을 때 - 문제 해결을 위한 공감대가 형성되면 이해관계자들에게 적극적으로 정보를 수집하고 문제를 정의해갑니다. 공감대를 형성한다는 건 요구사항을 정의하는 것보다 한 단계 더 높은 차원의 일입니다. 이해 관계자가 누군지 알



      아내고, 시스템의 비즈니스 목표를 확인하고, 아키텍처의 특성에 맞추어 요구사항을 파악합니다. 


       



      CHAPTER 15. 해결책을 찾고 싶을때 - 이 장에서 소개하는 활동은 아키텍처를 설계하며 여러 대안을 만들 때 유용합니다. 아키텍처로 발전할 수 있는 구조를 탐색하고, 실제로 구현해낼 엔지니어링 접근법을 찾아낼 수 있습니다.


       



      CHAPTER 16. 손에 잡히는 설계를 만들고 싶을때 - 이 장에서 다루는 활동들의 결과물은 아키텍처를 실물로 만드는데 큰 도움이 될 것입니다. 결과물은 혼자서 직접 만들 수 있지만, 때로는 다른 사람과 짝을 지어 하거나 큰 그룹으로 협업할때 더 재미있고 유익할 수 있습니다.


       



      CHAPTER 17. 설계 대안을 평가하고 싶을때 - 이 장에서 소개하는 활동은 팀원들과 아키텍처의 다양한 측면을 살펴보고 정보를 모아서 적절한 조치를 취하고자 할때 유용합니다. 아키텍처를 얼마나 잘 이해했는지 확인하거나, 설계의 대안을 선택하거나, 다음에 수행할 작업을 결정해야 할 때 활용하면 좋습니다. 


       



      끝으로



      소프트웨어 아키텍처는 멋진 소프트웨어를 만드는 단단한 기반입니다. 훌륭한 아키텍처가 소프트웨어 성공을 보장하지는 않지만 최소한 실패의 가능성을 적게 만들어줄 것입니다. 소프트웨어 개발자라면 소프트웨어 아키텍처에 대해 꼭 알아야 합니다. 이 책에서 훌륭한 소프트웨어 아키텍처를 어떻게 설계하는지 배우게 될 것입니다.



      이 책으로 설계자다운 사고방식과 인간중심적인 접근 방법을 배울수 있을 뿐만 아니라 팀원 간에 협업하면서 소포트웨어를 설계하는 방법도 배울 수 있습니다. 소프트웨어 아키텍처라면 이 책을 통하여 기술과 현실을 효과적으로 배우게 될것입니다.


       



      

    • 한빛미디어에서 낸 해외 번역서다.


      소프트웨어를 만드는 단단한 기반인 아키텍트를 설계하고 적용하는 방법을 소개한다.


       


      1부는 소프트웨어 아키텍트가 하는 일을 소개하고 정의한다.


      2부는 아키텍처를 설계하고 핵심적인 요구 사항을 알아내어 설계에 반영하는 방법을 알아본다.


      3부는 아키텍트를 설계하여 구체화하고 해결하기 위한 38가지 팀 활동을 소개한다.


       


      나는 소프트웨어 아키텍트에 대한 지식이 부족하기 때문에 1부 1장부터 차근차근 읽어나가면 된다.


      쉬운 설명과 내부 구성이 맘에 든다.


      학교에서 설계 부분을 듣긴 했지만, 기본부터의 체계적인 공부는 안 해보았다. 책을 보니까 학교에서 안 배운 내용들이 많아서 구멍 난 지식을 채우는 것 같다.


      감각적으로 알고 있었지만 이름을 몰랐던 개념을 확인하고, 알고 있던 지식과 실제 지식과의 차이를 발견할 수도 있었다. 개발자가 되기 위한 공부는 끝이 없다.


      인상깊은 부분


      공감은 곧 디자인을 이끄는 힘입니다. 이해관계자가 누구인지 명확하게 인식하고, 그들이 소프트웨어로 얻고자 하는 바를 정확히 알면 더 좋은 설계 결정을 할 수 있습니다. - 89p


      이 책은 다른 번역서와 비교하면 친숙한 느낌이다. 익숙한 종이 재질과 인디자인이 그렇게 느끼게 해준다.


      책의 특징으로 장마다 위에 제목과 함께 이해하기, 탐색하기, 평가하기, 실현하기로 분류가 되어있다.


       


      책의 일부 사진



      20210620_224620.jpg


       



      20210620_233204.jpg


       



      20210620_233915.jpg


       



      20210620_235120.jpg


       


       


    • 소프트웨어 아키텍처는 개발자라면 꼭 알아야 합니다. 더 뛰어난 개발자, 아키텍트, 기술 리더로 거듭나기 위해서는 다양한 아키텍처를 알아야하며 또한 잘 설계할 수 있어야 합니다.









      이 책은 초급 개발자에게는 자신의 프로그램을 더 나은 설계로 완성할 수 있게 도와주며, 시스템 관리자나 시니어 개발자에게도 인사이트를 부여해줍니다.









      책의 구성은 소프트웨어 아키텍트를 정의하는 것에서 시작하며, 디자인 싱킹에 대한 개념도 다루고 있습니다. 마음에 들었던 부분은 아키텍처를 설계하며 문제 상황을 마주했을 떄, 해결책을 찾아야 할 떄, 설계를 더 구체화하고 싶을 때 해볼 수 있는 활동을 소개해주고 있습니다.









      해당 과정을 통해서 빠른 피드백과 반복을 활용하고, 높은 품질을 달성할 수 있는 기대감을 맛보았습니다. 애자일 이전, 레거시 소프트웨어 개발에서의 성공적이지 않았던 사례가 해당 과정을 통해서 성공 할 수 있기를 기대합니다.















    • 업무에서 나름 아키텍처 관련 일을 하고 있지만 워낙 경험이 없는지라 고르게 된 책.



      아키텍처라고 하면 단순히 그림만 그리고 설계와 구성을 도와주면 끝인거 아닌가? 라고 생각했었는데 막상 일을 하다보면 여러가지 고려해야할 것들이 많은 것 같다.



      이 책은 개발자들에게 소프트웨어 아키텍처에 대해 어떻게 설계를 하는지 상세히 알려주는 책이다.


















      누가 읽으면 좋을까?












      소프트웨어 설계 및 아키텍처에 대한 기초 지식과 여러 팁들을 알려주는 내용이 많아 개발자 혹은 초보 아키텍처들에게 어울리는 책인 것 같다.


















      책의 구성은?












      책의 구성은 크게 3부로 나누어진다.



      1부는 소프트웨어 아키텍터가 하는일과 기초 디자인 싱킹에 대한 이야기들이다.



      2부는 아키텍처 설계를 할때 필요한 기초적인 설계전략들, 이해관계자에 대한 이야기들, 요구사항 알아내기, 아키텍처 선택하기 등 실제 아키텍처를 그리는 기초 지식들을 알려준다.



      3부는 실제 이해관계자 또는 동료들에게 의견을 받고 설계를 만들어나가는 방법들에 대해 이야기를 한다. 















      책의 내용들 중 좋았던 점들





















      이 책은 설계에 대한 기초적인 지식들도 잘 알려준다. 중간중간 이렇게 단어에 대한 설명과 차이, 방법론, 참고되는 말들을 자세히 적어주어서 도움이 되었다.




















      아키텍처 책이라그런지 중간중간 도식화된 그림들도 많았고, 아무래도 그림들이 많은듯했다. 이해하기는 더 좋았다.




















      그리고 단원이 끝날때마다 사례를 들어, 라이언하트 프로젝트에서는 어떻게 했는지 예를 들어줘서 좀 더 이해가 편리했다. 요약하는 글도 좋았고.












       












      이건 3부에서 나왔던 내용들인데, 3부는 생각보다 엄청 다양한 방법들이 소개된다. 약간 애자일 방법론같은? 그런 느낌도 들고 현실에서 한번쯤 도입해서 해보고 싶다는 생각이 들었다.









      책을 다 읽고서 든 생각은 아키텍처라는 업은 생각보다 소통이 참 중요하다는 생각을 했다. 시스템에 얽힌 이해관계자들의 중심에 있고, 이들의 요구사항을 귀기울이고 의견조율을 해서 최상의 소프트웨어 시스템을 만들어야 한다. 책의 절반은 이해관계자들과 어떻게 풀어나가는지, 어떻게 문제를 해결하는지의 내용인 것 같기도 하다. 기술만 잘 알아서 되는 것도 아니고 팀의 개발자들과의 소통도 매우 중요한 것 같다. 






      방향없던 아키텍처에 대한 지식들을 채울 수 있고 좀 정리할 수 있었던 책인 것 같다.






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






    •  입사해서 처음으로 아키텍트분들이 많은 프로젝트에서 일하게 되었다. 그러면서 자연스럽게 아키텍트라는 직군에 대한 관심이 많아졌다. 하지만 회사에서 아키텍트팀이 사라졌기도 하고, 원래부터 팀간의 이동은 어디서나 힘든 일이었다. 점차 연차가 늘어나면서 아키텍트와 비슷한 일을 하고 있지만 아키텍트라고 부르기에는 어딘가 어색한 부분이 많았다.



       이 책은 그런 개발자에서 아키텍트로의 전환할 수 있는 다양한 훈련법을 알려준다. 또한 프로젝트에서 시스템 구조를 설계하고, 공통기능을 구현하는 일이 아니라 아키텍트가 어떤 일을 하고 있으며, 많은 고민해야 할 것들에 대해서 알려준다. 마지막에서는 38가지의 훈련법을 통해서 아키텍트로서 한걸음 더 다가가게 해 준다.



       아키텍트를 꿈꾸는 개발자분들은 이 책을 통해서 연습하기를 바래본다. 


       



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


    • 두께는 여자 엄지 손가락 너비 정도. 팔랑 팔랑 얇은 종이라 무게는 생각보다 있습니다. 책을 펼쳐두어도 넘어가지 않습니다. (코딩 관련 책이 이럼 좋을텐데...)



      책은 아래와 같이 총 세개의 파트로 나뉘어 집니다.






      파트1. 소프트웨어 아키텍처



      파트2. 아키텍처 설계의 기초



      파트3. 아키텍트의 은색 도구상자






      파트1은 아키텍처란 무엇인지, 왜 해야 하는지, 어떻게 아키텍터가 될 수 있는지에 대한 짧은 내용으로 이루어 집니다.



      메뉴얼을 스킵하고 바로 도구를 사용하는 것을 즐기는 분들이라면 바로 파트 3로 넘어가서 바로 아키텍터로서 아키텍처를 만들어 가는 방법을 적용하는 방법을 학습할 수 있습니다. 설계 과정의 요약본으로 실습으로 빠르게 어떻게 하는 것인지 감을 잡을 수 있습니다. 이후 2장을 참고하여 하나하나 필요한 내용들을 알아보는 것도 성질 급한 사람들에겐 이책을 읽는 좋은 방법이리라 생각합니다.






      순서대로 읽을 경우 아키텍처는 무엇인지, 설계를 하나하나 어떻게 해나가야 하는지 하나하나 정성스럽게 배워갈 수 있습니다.



      개인적으로는 3장의 실습 부분 하나를 읽고 2장을 넘어 가는 것도 나쁘지 않은 순서라고 생각하지만, 그부분은 읽은 부분의 취향에 알맞게 읽으면 된다고 생각합니다.



      쉽게 읽히는 내용으로 예시와 하나 하나 읽어 나가보면 비교적 빠르게 읽어 나갈 수 있습니다. 그래서 번역체가 아닌 정성스러운 문구와 읽기 쉬운 문장 구성이 번역에 많은 신경을 썼다는 것을 느낄 수 있었습니다.


       






      "38가지 팀 활동을 활용한 실전 소프트웨어 아키텍트 훈련법"이라는 소제목 처럼 하나씩 읽어나가면 아키텍터라는 것이 무엇인지 체감하고 실전에서 사용할 수 있는 진짜를 얻을 수 있습니다.






      레벨 상관없이 프로그램을 하고 싶은 사람이라면 누구든, 프로젝트를 리더를 하는 누구든, 프로젝트를 팔로워 하는 누구든 개발자로서는 한번은 읽어 보고 옆에 두고서 언제나 필요할 때 마다 읽어보기를 권하고 싶은 좋은 책입니다.






      * 별점: 4/5 점





       

    •  



      KakaoTalk_20210620_211008734.jpg


       


       


       


        최근 팀장 직책을 맡게 되어서 기술서적보다는 설계나 관리에 관한 책을 좀 읽으려고 한다. 개발자로 사회생활에 첫 발을 내딛고 업무를 하다 보면 코더, 개발자, 프로그래머, 아키텍트 등 현재 자신의 모습과 자신이 되고자 하는 미래의 모습에 대해 고민하게 된다. 경험이 부족해서 시야가 좁을 수도 있지만, 내가 알기로는 한국에서는 개발 업무 자체가 속도가 굉장히 빠르고 설계보다는 결과물에 더 집중하는 것 같다. 지금도 오래되고 꽤 규모가 있는(규모가 큰 게 맞을까?) 솔루션을 개발하고 유지 보수하는데, 아무리 분석하고 설계해서 개발을 하더라도 초기에 만들어진 기능이나 코드 덕에 이계 한계에 다다랐다고 생각 중이다. 대화의 스킬이나 설득력이 부족해서 개발팀의 입장을 대변하는 건 참 어려운 것 같다. 하지만 이런 상황일수록 구조나 기능, 로직에 대한 설계가 중요한 게 아닌가 싶다. 하여튼 이런저런 이유로 아키텍트는 참 매력 있는 것이라고 생각을 했고 과연 책에서는 어떤 내용을 알려줄까 하는 궁금증이 생겼다.


        기대와는 다르게 책을 읽을수록 뭔가 잘 읽히지 않는다는 생각이 들었다. 용어나 개념, 접근법 등이 생소했을까? 이미 업무를 하며 녹아들어있는 부분인 것 같으면서도 이게 맞는지 아닌지 판단하기 어려운 부분도 있었다. 이렇게 판단하기 어려운 부분은 책을 제대로 이해했는지 의구심을 갖게 하고 더욱 읽기 힘들게 만들었다. 책 후반부에서는 분석이나 설계에 필요한 여러 가지 활동에 대해 설명해준다. 이 부분도 마찬가지로 이해가 쉽지 않다. 어떤 방법에 대해서 설명은 해주는데 목적과 수행하는 근거가 다소 부족한 것 같다. 다행히 챕터의 뒷부분에서 사례연구를 통해 이해가 좀 되긴 했지만 양이 턱없이 부족했다고 생각한다. 본인이 예시 등을 통한 설명에 익숙해서 그렇게 생각했을 수도 있다.


        어렵긴 했지만 공감되는 부분도 꽤 있었다. 분석을 오래 하면 좋지만, 쉬운 말로 가성비가 최적을 이루기 위해 고민해야 할 적당한 시점 - 균형 -에 대한 이야기가 대표적이다. 또 문제 해결을 위해 설계에 신경 써야 할 설계자의 태도에 대한 부분도 있다. 초기에는 적극적인 설계로 위험 요소를 줄이고 기준점 - 이것도 균형이 중요하겠다 - 이 지나면 수동적으로 모니터링해야 한다는 내용이다.


        업무를 하다 보면 개발팀 외부에서 여러 가지 요구 사항이 나오고 이걸 다 해야 할지 말아야 할지 고민이 많이 된다. 핵심 요구 사항을 알아내는 방법을 설명해주면서 제약으로 선택지를 줄이는 것에 대한 내용이 나온다. 할지 말지 고민하다 보면 결론 내기가 쉽지 않다. 하지만 이런 방법들에 대해 인식하고 있다면 훨씬 쉽게 결정을 할 수 있을 것 같다.


        아직 설계 방법 등에 대해 많이 경험해보질 않아서 전반적으로 어렵게 느껴졌을 수도 있지만 많은 방법을 알려주고 있는 만큼, 고민하는 것보다 여러 가지 방법을 하나씩 따라서 실행해보고 잘 맞는 방법을 찾는다면 좋은 아키텍트가 될 수 있지 않을까 하는 생각이 든다.


       


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

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


       


       



      SE-36FCAE8F-CFB8-4B12-B905-24D0A5EEE7C7.jpg


       


       


      아키텍트가 팀의 유일한 설계 권력자 역할을 맡는 게 아니라, 팀이 스스로 결정을


       


      내리는 데 필요한 지식의 기술을 주입해 주는 사람이 되어야 합니다.


       


       


       


      이 책을 신청한 이유 


       


      최근 들어 회사 내에서도 팀장을 하면서 아직 개발 업무를 지속적으로 하고 있고 또한 설계업무도 같이 하다 보니 좀 더 효율적으로 


       


      애플리케이션 및 인프라에 대해서도 효과적으로 설계를 할 수 있을지 또한 현재 돌아가는 시스템을 좀 더 효율적으로 개선해 나갈 수 있는


       


      노하우가 필요해서 신청을 하게 되었습니다.


       



       



       


      이 책의 구성


       


       



       


      1장은 소프트웨어 아키텍처에 대한 내용 


       



       


      2장은 디자인 싱킹 기초 


       



       


      3장은 설계 전략 고안하기 


       



       


      4장 이해관계자와 공감하기 


       



       


      5장 아키텍처 핵심 요구 사항 알아내기 


       



       


      6장 아키텍처 선택하기


       



       


      7장 패턴으로 기초 만들기 


       



       


      8장 의미 있는 모델로 복잡도 관리하기 


       



       


      9장 아키텍처 디자인 스튜디오 운영하기 


       



       


      10장 설계 시각화하기 


       



       


      11장 아키텍처 문서화하기 


       



       


      12장 아키텍처 평가하기 


       



       


      13장 아키텍처에게 힘 실어주기 


       



       


      14장 문제를 이해하고 싶을 때 


       



       


      15장 해결책을 찾고 싶을 때


       



       


      16장 손에 잡히는 설계를 만들고 싶을 때 


       



       


      17장 설계 대안을 평가하고 싶을 때


       



       


      개인적으로는 파트 2장의 7장 패턴으로 기초 만들기와 10장의 설계를 시각화하기, 11장의 아키텍처 문서화하기


       


      내용이 좀 더 저한테는 더 의미 있게 읽었습니다. 다양한 패턴에 대한 예시 또한 그림으로 잘 표현되어 있어서 더욱더 이해하시기에 좋습니다.


       


       


       


      마지막으로


       


       


      일단 이 책을 읽으면서 커뮤니케이션이 또한 중요하다고 생각하고 또한 책에서도 쉬운 말을 사용하고 전문용어를 피하라는 내용도 있었고 


       



       


      뭐든지 좋은 아키텍처는 설계한 내용을 어떻게든 잘 팀원들에게 전달을 하고 서포트를 잘해주는 것이 중요하다고 생각합니다.


       



       


      이 책에 나온 여러 패턴 및 기법과 노하우를 통해서 좀 더 효율적인 서비스를 운영할 수 있도록 노력할 것이고 또한 팀원들에게도 추천을 해주고 싶습니다.


       


       


       


    • “훌륭한 아키텍처가 소프트웨어의 성공을 보장하지는 않지만, 나쁜 아키텍처는 필연적으로 실패를 가져 온다.” 라는 말로 저자는 이 책을 시작 한다. 그리고 개발자라면 소프트웨어 아키텍처에 대해 꼭 알아야 한다고 한다.


       






      p.34 소프트웨어 아키텍트


       


       



      소프트웨어 아키텍트가 하는일



      소프트웨어 아키텍트는 모든 이해관계자와 협업 하면서 비즈니스 목표와 요구사항을 만들어 간다. 소프트웨어 시스템을 구현 가능한 작은 조각으로 나누는 동시에 전체 시스템이 일관성 있게 동작 하도록 큰 그림을 그린다. 또한 품질에 영향을 주는 다양한 품질 속성(Quality Attribute)  사이에서 균형을 잡아가며 어쩔 수 없이 늘어나는 기술 부채(Technical Debt) 도 관리 한다.







      위에서 이야기한 소프트웨어 아키텍트가 하는일 이라는 문장이 이해가 되지 않는 나 같은 사람에게 반드시 이 책을 추천 한다.







      단순히 소프트웨어 아키텍트가 하는일을 소개하는 문장에서 부터 알아들을 수 없는 단어들이 속출 한다. 특히 품질 속성이라는 굉장히 어색한 단어는 책을 읽는 내내 등장 하는데 (왜냐면 중요하니까!) 초반에는 무슨 말인지 이해하기가 어려웠다. 


       



      품질 속성 정의하기(5.2) 에 가서야 겨우 품질 속성이 무엇인지에 대해서 설명 하고 있고 실제 요소들이 나온다. 그리고 품질 속성 레이다 차트를 만드는 부분(활동 6) 에 가서야 좀더 상세하게 이해 할 수 있었다.


       






      p. 268 품질 속성 레이다 차트


       



      중요하게 생각하는 기준에 따라 시스템이 어떻게 다를 수 있는지 시각적으로 비교할 수 있다.


       


       



      책의 구성



      책은 아래의 순서로 구성 되어 있다. 1부의 소프트웨어 아키텍트가 하는 일(1.1) 에 대한 설명으로 시작해서 2부에서는 실제로 아키텍처 설계를 위한 전략(3), 핵심 요구사항 알아내기(5) , 주요 패턴 설명(7)  그리고 멋진 다이어그램 그리기 (10.2) 를 통해 다이어그램으로 아키텍처를 사실적으로 시각화 하여 보여주는 방법에 대해 이야기 한다.







      1부



      소프트웨어 아키텍트가 하는 일을 소개, 소프트웨어 아키텍처를 정의







      2부



      본격적으로 아키텍처를 설계, 이해관계자와 소통, 아키텍처 핵심 요구사항을 찾아내 설계에 반영







      3부



      아키텍처를 설계하며 문제 상황을 마주했을 때, 해결책을 찾아야 할 때, 설계를 더 구체화하고 싶을 때 해볼 수 있는 38가지 팀 활동을 소개







      개발자에서 소프트웨어 아키텍트로



      개발자에서 소프트웨어 아키텍트가 되고자 하는 이에 대한 조언은 1.3 팀에서 아키텍트가 되려면 이라는 부분에서 다루고 있다.







      저자는 개발자에서 아키텍트로 성장하고 있는지 측정해 보고 싶다면 프로젝트 포트폴리오를 만들어 보라고 말한다. 소프트웨어 시스템을 만들 때마다 어떤 역할을 했든지 간에, 참여했던 소프트웨어 시스템에 대해 간략히 정리하고 개발하면서 배운점을 정리 하는 활동은 소프트웨어 아키텍트에게 필수적이다.







      프로젝트 포트폴리오 정리를 위한 주요 질문사항



      1) 이해관계자들은 누구였고 주요 비즈니스 목표는 무었이었는가?
      2) 최종적으로 어떤 결과가 나왔는가?
      3) 어떤 기술을 사용했는가?
      4) 가장 큰 리스크는 무엇이고, 어떻게 극복했는가?
      5) 다시 시작할 수 있다면 어떤 점을 다르게 하겠는가?


       


       



      감상평



      두께도 얇은 편이고 편집도 깔끔하여 보기에는 쉬웠지만, 내용은 전체적으로 쉽지 않은 책이다. 







      하지만, 말로 이해하기 어려운 부분도 책의 그림 이나 다이어그램, 표의 적절한 사용으로 이해하는데 도움을 많이 주었다. 







      사례연구로 나오는 라이언하트 프로젝트는 뜬구름 잡기 같던 아키텍처 설계를 좀 더 구체화된 시선으로 볼 수 있도록 해주었다.







      3부의 아키텍트의 은색 도구상자는 충분히 확인 하여 실무에서 사용할 수 있는 방안을 생각해보는 중이다. 특히 고객과의 인터뷰 같은건 매번 하는 작업 이지만, “활동4 이해관계자 인터뷰” 에서 처럼 목표와 질문목록 그리고 실행단계를 구분하여 작업해본적은 없었기에 책의 내용을 실천하여 작업을 수행해 보고 싶다.







      소프트웨어 아키텍트가 뭐하는 포지션인지 모르는 사람에게 꼭 추천 하는 바이다. 



      팀에 아키텍트가 없다면... “네, 축하 합니다. 이제 당신이 하면 됩니다.!”


       



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


    • 개발자에서 아키텍트로 한빛미디어



       



      개발자의 이직의 시대에 맞추어 이직을 하게 되었다. 마침 새롭게 만나게 개발 팀원들간 시너지를 내면서 일을 있는 방법은 무엇이 있을까 하던 찰나에 책을 만나게 되었다. 단순히 개인 개발자가 코드를 작성하는 일을 넘어 넓은 시각으로 아키텍트에 대한 고민을 하고 팀원들과 함께 생산적으로 있는 방법에 대한 연구를 읽어봄직하다.



       



      KakaoTalk_Photo_2021-06-20-18-40-31.jpeg 



      책은 저자의 경험과 기술, 생각과 생각의 정리를 보여줄 있는 가장 강력한 무기이다. 책은 아키텍트가 가져야 덕목으로 코딩 실력과 더불어 지식과 경험을 이야기하며, 동시에 독자로 하여금 아키텍트의 일을 간접 경험하게 해준다.



       



      책이 출간 되자마자 주변에 흔히 말하는 늙은(?) 개발자들이 책을 구입하기 시작했다.



       



      책의 부분은 개발자 혹은 엔지니어가 아키텍트로서 일을 하게 되었을 어떤 일을 하게 되며 어떻게 소프트웨어를 개발해야 하는가에 대한 고민을 해결할 있는 방향을 보여준다. 문제가 발생했을 문제를 나누는 방법, 그리고 문제를 해결하는 과정에서 팀원들과의 협업을 이끌어 내는 방법을 보여준다. 서로 다르게 이해할 있는 부분에 대해서는 공동의 이해를 위한 용어의 정의, 사전의 역할을 한다고 설명하는 부분이 있다. 이는 DDD 부문에서 이야기하는 유비쿼터스언어 상통하는 부분이라는 생각마저 든다.



       



      개발자의 관점에서는 가장 급한 기능의 구현, Feature 단위로 생각하게 되고 Spec 구축하게 되는데 아키텍트로서 일정과 비용, 리스크, 역량에 대한 영역으로 생각의 폭을 넓혀야 한다 말한다. 아울러 품질까지 성공적으로 이끌어야 함으로 아키텍트로서의 역할이 결코 가볍지 않음을 보여준다.



       



      대부분 프로젝트에서 설계 일정은 필연적으로 선두에서 시작하게 되는데 이때 무한정 설계에 대한 시간을 할당할 없고 전체 프로젝트 일정은 제한 밖에 없는 , 어느 정도의 설계 시간을 할당해야 하는지에 대한 고민의 영역도 생각하게 해준다. 설계의 시간이 촉박하면 오히려 작업의 시간이 길어짐으로 전체 일정이 늘어나는 효과가 나타나므로 최적점을 찾아내는 고민도 역시 아키텍트가 맡은 짐이라 있겠다.



       



      프로젝트 하나를 예시로 들어 아키텍트로서 진행하는 내용을 보여줌으로써 이해를 높였다. 아울러 복잡한 시스템에 대한 관점, 문서화, 피드백을 통한 개선 등을 보여준다. 물론 책의 내용은 해답지는 아니지만 무엇을 미리 생각하고 무엇을 놓치지 않아야 하는지 자세히 드러내줌으로써 아키텍트로써 부족한 면이 생기지 않도록 가이드 해준다는 느낌이 강하다. 마치 사수 명이 차근 차근 일러주는 느낌이다. 그리고 마지막에는 많은 분량을 할당해 훌륭한 팀이 되도록 하는 여러 활동을 보여주는데 내용은 직접 책을 통해 확인해보자.



       



      최근 애자일에서 힌트를 얻어 플래닝 포커 도입해 실제 업무에 이용할 생각인데, 무엇을 하든 어떤 활동을 하든 팀원과 훌륭한 성과를 내는 방향으로 뜻이 통한다면 책에서 제시하는 여러 활동들도 함께 도입해보고자 한다. 책을 만나게 모든 엔지니어가 성장하고 아키텍트로서 부족함




  • 프로그래밍 면접을 볼 때 어느 정도 연차가 되면 시스템 디자인에 대한 시간이 들어간다. 매니저나 그 이상의 직급에서는 코딩 인터뷰보다 더 많은 시간이 할당되는 경우도 봤다. 코딩 인터뷰와 가장 큰 차이점은 딱 맞아 떨어지는 정답은 없다는 점이다. 그래서 대부분의 회사에서 시스템 디자인 인터뷰에 대해서 안내할 때 “정답이 있는 건 아니다"라는 이야기를 한다. 하지만 또 어느 정도는 납득할 수 있고 수긍할 수 있는 아키텍처라는 게 존재하고 그래서 아키텍처에도 패턴이 있다. 하지만 이 패턴을 외운다고 해도 바로 옳은 답을 할 수 있진 않다. 그래서 아키텍처는 어렵고 경험이 필요하다.


    이 책은 아키텍트가 되려면 어떻게 해야 하는지 여러가지 측면에서 다루는 데 다른 책들과는 특히 구분되는 면은 비기술적인 면도 중요하게 다룬다는 점이다. 예를 들어 4장은 “이해관계자와 공감하기”, 5장 “아키텍처 핵심 요구사항 알아내기”는 시스템의 관계자들과 협의를 하고 무엇을 최선으로 할지 결정하는 방법을 설명하는 데 다른 아키텍처 관련 서적에서는 쉽게 보기 힘든 부분이다. 실제로 업무를 하면 다른 부서의 매니저들이나 개발자들 뿐만 아니라 product owner와 같은 비즈니스 관련자들과 협의가 개발 방향에 큰 영향을 미친다. 이 때 어느 정도의 트레이드 오프를 통해 개발쪽에서 원하는 설계 방향을 유지하면서 비지니스 목표 달성에 협조하는 게 설계를 하는 사람의 몫이 된다.


    또 다른 특징은 문서화를 강조한다는 점이다. 10장 “설계 시각화하기”, 11장 “아키텍처 문서화하기”를 통해 체계적인 문서화로 아키텍처 설계의 결과뿐만 아니라 과정도 같이 보여줘야 한다고 설명한다. 맥락이 없이 결론만 보게 되면 과정에서 논의되었지만 어떤 이유로 배제되었던 다른 아키텍처를 다시 설명해야 할 수도 있고, 다른 목표와 상충되어 일단은 포기하고 가기로 했던 부분을 왜 빠뜨렸냐고 묻는 사람이 생길 수도 있는데, 이런 불필요한 낭비를 줄일 수 있다는 점에서 아키텍처 문서화 역시 중요하다.


    마지막으로 Part 3 “아키텍트의 은색 도구상자"에 있는 여러가지 활동이 독특한데, 모든 활동을 따라할 필요도 없고 가능하지도 않겠지만, 체계적인 회의를 하고 싶을 때 도움이 될 자료들이 많이 있다. 이런 개발과 무관해 보이는 업무 방식이 실제로는 잘 활용하면 업무 생산성을 높이는 데 도움이 된다는 점을 감안하면 여기 나오는 여러가지 활동을 잘 사용하면 아키텍처 설계뿐만 아니라 일반적인 개발 업무에서도 도움이 될 거 같다.


     


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


  • 설계를 해보신 적 있으신가요?



    회사에 취업하고 개발을 하다가 설계로 넘어가는 케이스가 많습니다.







    설계 경험이 부족하면 일을 맡았을 때 어려운 상황에 부딪히게 됩니다.







    개발자에서 설계 쪽 일을 하고자 하는 분들에게 추천하고 싶은 책이 있습니다.







    소개할 책은 ‘개발자에서 아키텍트로’입니다.







    이 책을 통해 설계자로 변화하는 첫걸음이 되시길 바랍니다.











    1.jpg


     







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



    소프트웨어 아키텍트는 소프트웨어가 언제 어떻게 전달되는지 결정하는 사람입니다.







    아키텍트는 코딩이나 알고리즘을 짜기보단 설계를 주로 합니다.







    소프트웨어 아키텍트는 비즈니스 목표와 요구사항을 만드는데요.



    프로덕트 매니저, 프로젝트 매니저, 모든 이해관계자와 협업을 합니다.







    아키텍트의 중요한 역할은 팀원들을 설계과정에 참여 시켜 팀의 설계역량을 끌어올려야 합니다.







    아키텍트가 되려면 팀에서 활동한 것을 설명을 잘해야 합니다.







    이해관계자의 니즈가 파악하며 설계를 이끌어 내야 합니다.







    또한 가장 큰 리스크는 무엇이었으며 극복한 방법도 말할 수 있어야 합니다.











    3.jpg


     







    2) 훌륭한 소프트웨어 만들기



    훌륭한 소프트웨어를 만들려면 어떻게 해야 할까요?



    큰 문제를 작게 나누고 관리하기 쉽게 만들 수 있어야 합니다.







    소프트웨어 개발은 사람 간의 커뮤니케이션이 중요합니다.







    시스템을 총체적으로 설명할 수 있어야 합니다.







    사람들이 협업하려면 프로젝트에 대한 이해가 필요합니다.







    설명을 이해하고 있어야 협업하여 일할 수 있습니다.







    소프트웨어 아키텍처는 기본적인 개념과 필수 단어를 통해 대화가 가능해야 합니다.











    1.jpg


     







    Ps



    이 책을 통해 소프트웨어 아키텍트가 어떤 일을 하는지 배울 수 있습니다.







    아키텍트에 대한 기본지식과 설계에 대해 자세히 알려줍니다.







    아키텍처 패턴 다이어그램으로 설명하므로 이해하는 데 도움 될 것입니다.







    프로젝트와 팀을 성공으로 이끌어줄 38가지 팀 활동도 소개해줍니다.







    아키텍트가 되고 싶은 분들에게 이 책을 추천합니다.


     



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


  • 개발을 진행할 때 아키텍칭은 정말로 중요하다.



    아키텍칭 없이 시작한 개발과 아키텍칭을 충분히 진행하고 개발에 착수한 개발물의 결과는 상당한 차이가 있기 때문이다.



    가령 10만 줄에 달하는 프로젝트를 진행할 때, 추후의 기능 확장성과 각 컴포넌트 간의 의존성 그리고 스케일 아웃 등의 관계를 고려하지 않고 코드를 짠다면, 이 프로젝트가 2, 3년 후에 휴지통에 처박히는 것은 어찌 보면 당연한 수순이기 때문이다.



    또한 어찌 보면 아키텍칭은 관련 소프트웨어의 수명과 연관되어 지속적이고 꾸준히 이뤄져야 할 요소이다. 즉 프로젝트가 처음 시작할 때 단 한 번만 수행하고 끝나는 행위가 아닌, 개발 중에도 서비스 중에도 수시로 아키텍처적인 고민과 개선이 이뤄져야만 한다.



    이러한 관점에서 봤을 때, 개발자와 아키텍칭 사이의 관계는 결국 때려야 땔 수가 없는 관계다. 개발이 이뤄진다면 곧 그와 관련된 간단한 명세가 적어도 하나쯤은 있어야 함을 의미하기 때문이다.



    이러한 관점에서 보았을 때, 개발자로써 아키텍트를 어떻게 이해야 할지, 혹은 아키텍트만 전문적으로 하는 직군의 업무를 꿈꿀 때 기본적으로 알아야 하는 지식과 이를 활용할 수 있는 가이드가 있다면 상당한 도움이 될 것이란 생각이 들었다.



    그렇기에 이번에 "개발자에서 아키텍트로"라는 책을 한빛미디어 리뷰 도서로 신청하였고, 관련 내용을 간략하게나마 정리해보았다.



     



    【책의 구성】 '개발에서 아키텍트로"의 책의 구성은 어떠한가?.



     



    이 책은 총 3개의 파트로 구성되어 있다. 1파트는 "소프트웨어 아키텍처"에 관한 내용을 다루고 있고 2파트는 "아키텍처 설계의 기초"에 대해서 다루고 있다. 3파트는 "아키텍트의 은색 도구상자(실버 블렛)"에 대해서 정리되어 있다.



    솔직히 파트 3은 간략하게 한번 읽어보고 필요할 때마다 참고하여 실무에 적용하면 좋을 것이란 생각이 들었다. ~ 이런 방법이 있구나. 정도로 이해하고 추후 필요할 때 도입하는 형태로 말이다. (왜냐하면 해당 사항들은 지식을 전달하기보단 책의 소주제에서 설명하는 것처럼 "문제를 이해하고 싶을 때", "해결책을 찾고 싶을 때"와 같이 특정 상황에 놓였을 때 이를 해결하기 위한 실천 방향 (액티비티)에 관한 가이드이기 때문이다.)



    파트 1은 말 그대로 "아키텍트"는 무엇을 하는 사람이고 무엇을 해야 하는지에 대해서 설명하고 있다. 거의 모든 책들의 시작과 유사하다. 다만 조금 다른 점이 있다면 "아키텍트"로써 문제를 해결해야 할 때, 어떤 접근법으로 접근하면 좋은지에 대해서 술 해져있다. 그런데 문제는 내용이 솔직히 좀 뻔한 것들이었다. 학부에서 소프트웨어 설계 혹은 소프트웨어 개발론에 관한 전공 과목을 한 번쯤 들어본 사람이라면 누구든 이해할 수 있는 내용들이다. 솔직히 약간 진부한 감이 없잖아 있는 파트이다.



    파트 2의 내용이야말로 이 책의 핵심이라 할 수 있다. 아키텍처에 관한 설계와 이에 대한 기초에 대해서 정리하고 있는데, 내용을 이해하기엔 크게 어려움이 없다. 솔직히 기획자나 디자이너도 읽어두면 좋을 것이란 생각이 든다.



    해당 파트의 각 챕터별 내용을 간략하게나마 몇 가지 요약하면 다음과 같다


     







     



    3 챕터 : 설계 전략 고안하기



     이 장에서 가장 인상적이었던 내용은 설계를 굉장히 디테일하게 한다고 해서 프로젝트 개발 기간이 짧아지진 않는다는 것이었다. 오히려 설계 기간이 너무 길면 길수록 이에 따라 프로젝트 개발 기간이 늘어난다는 그래프 자료가 상당히 인상적이었다.



    그렇다면 얼마만큼의 시간을 설계에 투자해야 가장 효율적인 일정 산정이 가능할까? 답은 없다였다. 왜냐하면 개발하려는 소프트웨어의 목적과 취지가 다양하며 또한 개발과정에서 사용되는 소프트웨어 개발론적 접근 방식 역시 상당히 다양하다.



    위의 조건으로만 보아도 이를 특정 시간만큼만 설계하면 최상의 효율적인 일정을 산출할 수 있다고 말하는 것은 사기에 가깝다고 할 수 있다.



    , 관련 프로젝트를 사전에 진행해본 유경험자가 있고 이에 대한 각 구성원들의 방향성이 어느 정도 뚜렷한 상태라면 이를 위해서 적정 수준의 설계를 진행한 후, (필자의 경우, 본 프레임이라고 한다(bone frame)) 개발을 진행하며 유연한 자세로 프로젝트의 아키텍칭에 대처하는 것도 하나의 좋은 방법이 될 수 있을 것이란 생각이 들었다.


     







     



    4 챕터 : 이해관계자와 공감하기



     "공감은 설계를 이끄는 힘이다" 이 챕터에서 가장 마음에 드는 문구였다. 맞는 말이다. 개발이건 뭐건 우리가 일하는 이유는 커스터머 즉 고객의 고충을 공감하고 이를 해결해 주는 것에 있는 것이다. 결국 이해관계자들 간의 요구 사항과 각각의 상충되는 필요사항을 적절히 융화하여 그들 모두를 최대한 만족시킬 수 있는 결과물을 도출하는 것이 분야를 막론하고 우리가 일하는 목적인 것이다.



    이 장에서는 이러한 이해관계자들 간의 요구를 적절히 파악하기 위해서 "이해관계자 맵"을 활용할 것을 권장하고 있다. 처음에는 무엇인가 했는데, 결국 관계도를 그리는 것이었다. 각 이해관계 그룹 간에 필요한 내용들을 그래프로 잘 표시하고 각 그룹의 요구 사항을 잘 도식화하여 이에 대한 궁극의 공감점을 형상하는 방법을 이해시키는 것의 해당 챕터의 목적이라 할 수 있을 것이다.



    하지만 이해관계자의 도표를 잘 그리고 그들의 요구 사항을 잘 도식화했다고 해서 이에 만족하고 끝내서는 안됨을 명심하도록 하자.



    앞서 언급한 것과 같아 고객은 그들의 고충이 해결되길 원하는 것이지, 이해당사자들 간에 각자의 요청 사항만을 탁상공론으로 끝내길 원하지 않는다는 사실을 말이다.


     







     



    10 챕터 : 설계 시각화하기



     "여러분이 만든 상상 속으로 끌여들이세요". 모든 아이디어는 결국 추상화를 통해 그림으로 보다 직관적으로 표현이 가능하다. 말로 설명하는 것은 직관성이 부족하므로 그림으로 그려서 그 의미를 보다 구체화하여 전달하면 훨씬 이해하기에 좋다.



    , 여기서 우리가 명심해야 할 사항이 있다면, 그림을 잘 그릴 필요는 없다는 점이다. 오직 의미를 잘 전달할 수 있는 수준의 그림이면 된다. 졸라맨 스타일이건 피카소가 울고 갈 정도의 걸작 수준의 그림이건 오직 구성원 간의 컨센서스를 맞추기 위한 의미만을 잘 전달할 수 있으면 되는 것이다. 따라서 그림을 잘 그리는 것보단, 의미를 잘 전달하는 데에 중점을 두는 스케치법을 익혀두도록 하자.


     







     



    【 "개발자에서 아키텍트로"를 읽고서…….】



     이번 도서를 리뷰를 읽으며 가장 와닿았던 점은 아키텍칭은 한 번하고 끝나는 것이 아니라는 점이었다. 시대가 변하면 새로운 기술도 나오고 그에 맞는 다양한 개발 방법론이 재기된다. 그렇기에 이에 맞게끔 서비스 구조는 수시로 그 구조의 형태를 바꿔가며 시대에 맞게끔 탈바꿈해야만 한다. 만약 이런 과정을 반복하지 않게 되면.. 결국 그 코드와 프로젝트는 레거시 괴수로 변해 엄청난 리소스를 잡아먹게 될 것이 자명하기 때문이다.



    어느 분야가 되었건 어느 산업이 되었건 지속적인 공부와 자기 개발은 필수가 된 시대인 것 같다. 평생직장이라는 말은 이제 거의 옛말이 되었고 직업과 일하는 형태도 지속적으로 변화하고 있는 것이 지금의 세계이다.



    그렇기에 서두에서 언급한 것과 같이, 자신의 미래와 패스를 너무 자세히 설계하기보단 가장 중요한 구심점을 세우고 그것을 중심으로 어느 정도 유연하게 현실을 파악하고 적응하는 것이 필요해 보인다.



    만약 본인의 직업이 프로그래머라면 위의 소양은 반드시 갖춰야 할 것이란 생각이 든다.



     


     



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



    ###### 감사합니다 ######



    



     

  •  


    아키텍트는 어떤 업무를 하나요?


     


    개발자에서 아키텍트를 고려하는 사람들도 많습니다. 그런데 정작 경력만으로는 만족할 수 없을 때가 많습니다. 그래서 다시 처음부터 공부하기는 버겁습니다. 그런데 그렇게 전반적인 내용을 알 수 있는 책이 이번에 나왔습니다.


     


    한 컷 한 컷 내용에 의미가 있습니다.


     



    2021-06-20-08-31-19-539.jpg


     


    이 책에 대하여



    미리보기1.png


    소프트웨어 아키텍트가 하는일



    미리보기2.png


    초보 아키텍트를 위한 실전 입문서



    미리보기3.png


    엔지니어링의 위험 요소



    2021-06-20-07-51-04-817.jpg


     이해관계자와 이해관계자의 요구



    2021-06-20-07-59-40-471.jpg


     스케치



    2021-06-20-08-17-59-716.jpg


     


    2부 아키텍처 설계의 기초



    2021-06-20-07-48-57-435.jpg


     



    설계 전략 고안하기2021-06-20-07-49-18-782.jpg


     위험분석 할당 시간



    2021-06-20-07-50-10-269.jpg


     디자인 마인드셋



    2021-06-20-07-50-54-143.jpg


     실현하기, 평가하기, 탐색하기, 실현하기



    2021-06-20-08-33-51-227.jpg


     실행하기, 확인하기, 생각하기



    2021-06-20-08-34-29-242.jpg


     



    2021-06-20-08-34-49-572.jpg


     이해관계자 맵



    2021-06-20-08-35-10-661.jpg


    이해관계자와 이해관계자 요구



    2021-06-20-08-35-20-022.jpg


     


    큰 그림 그리기 



    2021-06-20-08-32-51-873.jpg


     프로젝트 포트폴이오 정리 시 질문



    2021-06-20-08-33-12-900.jpg


     4가지 마인드셋



    2021-06-20-08-33-33-031.jpg


     콘웨이 법칙


    "설계 조직의 커뮤니케이션 구조는 곧 제품을 설계할 때의 한계를 정의한다"



    2021-06-20-08-35-58-692.jpg


     계산기 애플리케이션



    2021-06-20-08-35-35-969.jpg


     아키텍처 영향



    2021-06-20-08-35-49-974.jpg


     



    2021-06-20-08-40-41-060.jpg


     데이터 기반 웹 애플리케이션 아키텍처 패턴



    2021-06-20-08-36-24-621.jpg


     컴퍼넌트 구성



    2021-06-20-08-36-37-266.jpg


     의사결정



    2021-06-20-08-36-57-589.jpg


     포트와 어댑터



    2021-06-20-08-37-20-614.jpg


     발생/구독 패턴 예시



    2021-06-20-08-37-43-145.jpg


     웹 서비스 상호작용 뷰(동적 모델링)



    2021-06-20-08-39-43-775.jpg


     아키텍처 서술 방법



    2021-06-20-08-40-17-243.jpg


     


    해당 책은 매달 접하는 나는 리뷰어다 책을 통하여 접하게 됩니다.



    q4XlO0m2_c4DWRQmVrSa3uXSuyM_brunch.png


     아키텍처에 대한 정의와 실제 적용되는 내용입니다. 실제로 두고 두고 천천히 보면서 익혀도 되는 책이기도 합니다.


     


  • 개발자에서아키텍트로


    '개발자에서 아키텍트로' 이 책을 조금 더 일찍 출간되어서 읽었다면 어땠을까?



    아키텍트 역량을 향상시키고 아키텍트로 성장하기 위해 준비 중인 개발자로써 이 책을 읽은 건 기분 좋은 일이다.




    약 4년 전 사내에서 Architect 양성을 위한 교육 및 자격 이수 과정에 지원 및 선발되어 교육을 받은 적이 있었다.
    해당 교육은 Architect로써 필요로 하는 기본 역량과 함께 프로젝트를 진행하는 것이었다.










    이 교육 전에는 Architect라면 오로지 설계하는 사람으로만 알았지, 그 외에 많은 정보가 없었다.
    그랬기에 교육 내용은 더욱 충격적이였을지도 모른다. 사실 디자인 패턴이나 아키텍트 패턴 등은
    다양하게 접하면서 어느 정도 익숙해져있는 상태였다. 그랬기에 교육 이수 또한 자신있었다.







    하지만 교육은 내 생각과는 달랐다. Architect 로써 가져야 하는 역량은 소프트웨어 설계 능력만이 아니였다.
    처음 프로젝트를 시작하며, 이해관계자들간의 관계와 그들이 요구하는 사항에 대해 분석해야 한다.







    말은 쉽다. '분석하면 되잖아?' 하지만, 이해관계자들은 정확히 자신이 원하는게 무엇인지 알지 못하는 경우가 많다.
    버튼이 있었으면 좋겠고, 이뻤으면 좋겠고... 빨랐으면 좋겠고.. 이런 내역들을 모아서 설계하기란 쉽지 않다.
    그래서 Architect의 역할이 매우 중요하다. 이해관계자들이 원하는 걸 정확하게 이끌어 내는 방법이 필요하고,
    그렇게 모은 정보를 토대로, 제한사항부터, 요구사항 분석과, 기능적/비기능적 요구사항으로 분류하기 시작한다.
    그리고 요구사항을 만족할 수 있는 품질속성을 정의하고, 검증을 하기 위핸 방안을 생각한다.
    위의 과정들이 잘 끝나야지만, 시스템 / 소프트웨어적으로 설계를 시작할 수 있다.










    하지만 이런 내용을 쉽게 접하고 역량을 쌓기란 쉽지 않다. (나는 그랬다.)
    이런 내용을 알기 쉽게 정리하고 실습을 할 수 있는 책이 한국어 번역되었다는 것은 기쁜 일이다.
    만약 내가 교육에 입과하기 전에 이 책이 출간 되었으면 훨씬 더 많은 도움을 받았을 것 같다.







    물론 지금은 자격을 이수하고, 사내에서 Associate Architect 라는 자격으로 활동을 하고 있다.
    추후 S/W Architect 인증까지 받고자 하는 목표가 있기에 지금도 꾸준히 관련된 지식을 쌓으려고 노력 중이다.







    이 책이 좋은 점은 위에서 말한, 이해관계자들부터, 품질속성, 시스템 설계, 평가까지 다양한 내용을 모두 다루고 있기 때문이다.
    그렇기에 Architect 를 꿈꾸고 목표로 하는 현업개발자, 대학생들은 꼭 한번 읽어보길 추천한다.







    사실 처음에는 무슨 말인가 이해가 쉽지 않을 수 있다. Architect 책인데, 절반 이상이 UML, 설계 등의 내용보다
    다른 내용이 훨씬 많고, 처음보는 내용이라 이해가 어려울 순 있다.


    하지만 알면 충분히 큰 도움이 될 거라 생각한다.







    물론 아쉬운 건 깊이가 깊지는 않다는 것이지만, 그거야 뭐, 깊이까지 바란다는건 욕심이 과한거라 생각한다.
    욕심부리다 체할 수도 있으니까.. 첫 발은 뗀다는 정도까지만 생각하자.










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







  • 어떻게 하면 구현할 수 있을까?



    더 좋은 방법이 있지 않을까?


    개발을 업으로 하다보면 흔히 하는 생각이다.


     


    하지만 개발자로 일하다 보면 어느순간 구현하는 것보다 다른일이 더 많다(혹은 중요하다)고 생각하는 순간이 온다.


    그러면 이런 생각을 더 많이 하게 되는것 같다.



    왜 이런 코드들이 필요할까?



    꼭 이렇게 해야 할끼?



    어떻게 코드를 짜야 할까?


     


    기능을 구현보다 다른 부분에 신경이 쓰이기 시작했다면 이제 시니어가 되어가고 있다고 생각한다.


     


    대부분의 개발자들이 처음 일을 시작한 초짜시절에는 주어진 일을 처리하는데에 매달리다보니 주변을 둘러볼 여유가 없었을 것이다.


    나도 마찮가지였다. 단지 주어진 임무를 완수하면 최고라고 생각했었다.


    그러다 언젠가 현업사용자를 만족시켜야 한다는 생각을 갖게 됐다.


    원하는 기능을 만들어주는 것이 우선이겠지만, 그 좀더 편하게 혹은 맥락에 맞는 기능을 추가 해줄때 사용자들을 더욱 만족시켜줄 수 있었던것 같다.


    그렇게 개발하다보니 단순히 필요한 기능보다 더 많은 것을 생각하게 되었다.


     


    아래 그림을 일찍 깨닫는것이 좋은 개발자로 가는 지름길이라 생각한다.


    불행하게도 나는 이걸 좀 늦게 깨달았다.



     


     


    사실 내가 짜는 코드, 만들고 있는 S/W에는 많은 사람들이 얽혀 있다.


    이들의 원하는 바가 다 다른 경우가 대부분이다.


     


    저자는 이해관계자들 사이에서 최적의 길을 찾는 사람이 아키텍트라 말하고 있다.


    그리고 그 일을 도와줄 여러 사례와 기법을 소개하고 있다.


     


    주니어 개발자라면 한번쯤 읽어보시길 추천한다. 여러모로 앞날에 도움이 되리라 생각한다.


    시니어 개발자거나 PO라면, 여러 엑티비티를 소개한 3부만 읽어보아도 좋은 책이다.


     


    세상에는 많은 기술들이 소개되어있고, 빠르게 발전하고 있다.


    그런 많은 기술들 중에서 현재 상황에서 적절한 것을 제안하고, 팀을 끌고 갈수 있는 능력이야 말로 개발자로서 롱런하기 위한 핵심능력이 될 것이다.


     



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


  • 2021년 6월에 출간된 <개발자에서 아키텍트로>에 대해 알아보겠습니다. 이 책의 역자이신 '김영재'님의 페이스북에서 이 책이 출간된다는 소식을 듣고 개인적으로 기대하고 있던 책입니다. 



    이 책의 저자는 마이클 킬링이며, 역자는 김영재 님입니다. 번역은 김영재 님이 많은 고민을 하며 번역한 것을 알고 있었고, 제가 읽기에 매끄럽게 잘 읽혔으니 대부분 번역 품질에 대한 문제를 겪진 않을 것으로 생각합니다. 



    <개발자에서 아키텍트로>는 약 400여 페이지로 구성되어 있어 휴대하면서 읽을 수 있는 책입니다. 또한, 이 책은 전차잭으로도 만나볼 수 있음으로 전자책 뷰어가 있으신 분은 전자책으로 보셔도 좋을 것 같습니다. 
     



    이 책의 매력은?



    일반적으로 아키텍트가 지녀야 할 능력은 다양합니다. 자신의 분야에서 누구에게나 인정을 받을 수 있는 능력을 기본으로 갖춰야 합니다. 이 책의 주제인 소프트웨어 아키텍처로 보면 훌륭한 코딩 실력일 것입니다. 이뿐만 아니라, 아키텍처는 기본 소양과, 지식(기술), 경험 등이 필요합니다. 



    <개발자에서 아키텍트로>는 3개 파트와 17개의 챕터로 구성되어 있습니다. 두 번째 파트에서는 아키텍처가 지녀야 할 기본 소양과 지식 등을 소개하고, 세 번째 파트에서는 상황에 필요한 해법을 찾기 위한 다양한 방법론을 소개합니다. 이미 활용하고 있던 지식/도구도 있었고, 이 책으로 새로 배운 지식/도구도 있었습니다.



    이 책은 아키텍처로 나아가는 입문서라고 볼 수 있습니다. 하지만 이 책에서 다루는 내용은 개인적인 의견으로 가볍지 않다고 생각합니다. 모든 분야든지 기본이 제일 중요하듯이 이 책에서 다루는 내용을 자신의 것으로 만들기에는 많은 노력과 훈련이 필요합니다. 서두르지 말고 환경에 알맞게 조금씩 적용해 나간다면 아키텍처로 성장하는 자신의 모습을 볼 수 있을 것입니다.


     



    마치면서



    <개발자에서 아키텍트로>를 읽는 과정은 즐거웠습니다. 이 책을 읽으면서 평소 고민했었던 부분에 대한 해법을 얻기도 했고, 평소 깊게 생각하지 못했던 부분도 깨닫게 되었습니다. 저자의 의견과 방법에 공감을 느낀 부분도 있고, 도입을 해야 하는 부분도 있었으며, 다르게 생각한 부분도 있었습니다. 



    이 책에서 저자가 전달하고자 하는 내용을 기반으로 조직에 알맞게 개선하고, 적재적소에 적용하면 좋은 결과를 얻을 수 있을 것 같습니다. <개발자에서 아키텍트로>는 소프트웨어 아키텍처에 대해 배우고 싶은 분들에게 괜찮은 지침서가 될 것으로 생각합니다. 좋은 책을 출간해 주셔서 감사드립니다. 


     



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


  • 만들어진 소프트웨어는 결국 유지보수를 하거나, 소프트웨어를 확장할 판가름된다. 처음부터 마감일에 쫓겨 변화에 유연한 대응이 힘든 구조로 작업이 진행되기도 하고, 당시에는 최적의 설계라고 여겨졌으나, 시간이 지나서 보니 유연하지 못한 부분이 보이기도 하는 그만큼 좋은 설계를 하는 것은 어렵다. 하지만 어느 연차 이상이 되면 아키텍처를 설계하는 능력이 요구되기도 하고, 연차가 쌓이며 스스로의 작업물에 대해 필요성을 느끼게 되기도 한다. 



    책의 저자 또한 반강제로 아키텍트가 되었다고 말하고 있는데 그렇게 덜컥 소프트웨어 아키텍트가 사람의 입장에서 아키텍트가 어떤 일을 하는 , 소프트웨어 아키텍트를 알아야하는지에 대해 각각 개발자와 기술 리더 관점에서 집요하다 싶을만큼 차근차근 전달해간다.




    처음에 소프트웨어 아키텍트를 디자인 패턴과 같은 코드 설계 관점과 유사한 것으로 생각하고 책을 펼쳤기에, 예제 코드보다 이론에 가까운 내용으로 가득차있어 반전을 느꼈다. 또한 읽는 역시 소프트웨어 아키텍트에 대한 명확한 개념이 없다는 것을 반증하고 있다고 생각한다.




    저자가 말하는 아키텍트는 결국 이해관계자, 사용자와 닿아있다. 높은 품질을 달성하는 여러 설계 기법이 소개되지만 이는 결국 효율적인 협업의 방식을 말하는 것과도 유사하다고 여겨졌다. 어떻게 팀을 이끌어야 하는지, 어떻게 자신이 만든 소프트웨어를 설명해야 하는 각자의 현재 위치에서 효율적으로 일을 있도록 시야를 넓히는 관점에서 읽어보면 좋을 책이다.





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





  •  



    개발자에서아키텍트로.jpg


     


    < 개발자에서 아키텍트로 > | 마이클 킬링 지음 | 김영재 옮김 | 한빛미디어




    소프트웨어 아키텍트의 역할은 중요하지만 아키텍트에 대해 제대로 설명하는 책을 별로 보지 못한 것 같다. 이런 상황에서 이 책은 소프트웨어 아키텍트가 무엇인지와 어떤 역할을 해야 하는지를 잘 설명해 주고 있다.

    소프트웨어 아키텍트는 단순한 프로그램 매니저가 아니라 소프트웨어가 언제 어떻게 전달되는지를 결정하는 사람이다. 또한 소프트웨어가 비즈니스 목표에 부합하도록 만드는 사람이며, 코딩을 하지만 알고리즘이나 코드를 짜기 보다는 더 크고 많은 것을 설계하는 사람이다. 여러가지 역할에 대한 책임을 지며 동시에 모든 소프트웨어 개발 업무의 중심에 있는 사람으로 볼 수 있다.

    소프트웨어 아키텍트는 엔지니어링 관점에서 문제를 정의하고, 시스템은 분리하고 책임은 위임한다. 시스템에 대한 큰 그림을 그리고 품질과 속성의 트레이드오프를 고려하는 사람이다. 기술 부채를 관리하고 팀의 아키텍처 설계 역량을 키우는 사람이다.

    이 책은 크게 3부분으로 구성되어 있다. 1부는 소프트웨어 아키텍처에 대한 기본 개념을 설명한다. 소프트웨어 아키텍처의 핵심적인 원리와 설계의 기초를 다룬다. 2부에서는 아키텍처 설계의 기초에 대해 설명한다. 1부에서 설명한 디자인 싱킹의 원칙과 마인드셋을 기반으로 소프트웨어 아키텍처에 이러한 원칙을 적용하는 방법을 설명한다. 3부에서는 아키텍트의 핵심 역할 중의 하나인 이해 관계자의 의견을 받고 동료들의 생각을 정리하는 자신만의 도구상자를 만드는 방법을 설명한다.

    아키텍처 설계를 위해서는 다양하고 복잡한 과정을 거치게 된다. 실제 잘 드러나지 않은 무엇인가를 구체화시켜야 한다. 이 책은 아키텍처 설계를 위한 다양한 방법을 소개하고 실제 사례 연구를 샘플로 추가하고 있다. 아키텍처 설계를 위해 가장 먼저 해야하는 일은 설계 전략을 고안하는 것이다. 만족스러운 설계와 설계의 최적점을 찾는 방법에 대해 잘 설명하고 있다. 위험을 관리하기 위해 어떻게 위험을 처리해야 하는지, 그리고 이를 바탕으로 실제 설계 계획을 세우는 방법을 설명하고 있다.

    아키텍처 설계시 이해관계자와의 공감은 필수적이다. 이해관계자 맵을 만들고 비즈니스 목표를 공유하는 것이 중요하다. 그 이후에는 아키텍처의 요구사항을 파악하고 기능적인 요구사항과 아키텍처에 영향을 미치는 요소를 잘 선별해야 한다. 이 과정을 거쳐 아키텍처를 선택하고 아키텍처 디자인을 하게 된다. 아키텍처를 문서화하고 평가하는 과정도 필수적이다.

    실제 프로젝트에서 유용하게 활용할 수 있는 다양한 방법론과 내용이 잘 설명되어 있는 책으로 생각된다. 이론적인 내용과 실제 업무에 적용할 수 있는 내용이 적절히 조화가 되어 있어서 현업에 적용해 보는 것도 무리없이 가능하다고 생각된다. 소프트웨어 아키텍트를 꿈꾸는 개발자, 그리고 소프트웨어 아키텍처를 설계하는 개발자라면 곁에 두고 종종 참고할 만한 책이라고 생각된다.

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






  •  


     


    안녕하세요~ 오늘 살펴볼 책은 <개발자에서 아키텍트로 38가지 팀 활동을 활용한 실전 소프트웨어 아키텍트 훈련법> 입니다.


    먼저 이 책은 굉장히 어렵습니다.


    하지만 확실합니다.


    여러분들을 발전시켜준다는 것입니다. 더 중요한 것이 있습니다. 올바른 방법과 사례를 보여줄 것입니다.




    본격 책을 한번 살펴보도록 하죠.


     


     






     


     


    책에서 보시면 사실 챙겨야 될 문장과 무기들이 너무나도 많습니다.


    중요한 것은 어떤 문장을 챙겨갈 것인가입니다.


    저는 이 책에서 중요한 노트와 그림을 챙겨가기로 했습니다.


    아직 아키텍트가 되기위한 준비가 되지는 않았지만 그 준비과정으로 이 책은 큰 도움을 줄 것이라 확신합니다.


    우리는 개발을 하면서, 설계를 하면서 완성도와 정확도를 지켜야합니다.


    거기서 발생할 수 있는 원칙이 있습니다.


    이 책에서 소개되는 패턴과 원칙은 사례중심적이기 때문에 직접 실무에 적용해볼만 합니다.


     


     






     


     


    책에서 제시하는 방법들은 사실 개별적으로 적합하지 않을 수도 있습니다.


    문제는 뭐냐하면 책에서 제시되는 내용을 적용해볼 수 있냐입니다.


    일단 적용해보면서 자신의 팀에, 자신에게, 회사에 적합한지 끊임없이 테스트해보는 것입니다.


     


     






     


     


    책에서 다뤄지는 내용을 oop관련 내용, 기술관련 내용도 있으므로 어느정도 프로그래밍 언어에 대한 경험이 있으신 분들에게 추천드립니다.


    10독을 권하며 지속적으로 책을 보시면서 자신의 경험에 대조해보길 바랍니다.


     


     

  • [한빛미디어에서 제공 받은 '나는 리뷰어다' 2021년 6월 도서 리뷰입니다]




    '분석', '설계', '구현', '테스트', '유지보수'


    대학생때부터 배우게 되는 애자일 방법론의 단계이다.


    첫 프로젝트를 진행하면서 느낀건, '귀찮다' 였고,


    두번째 프로젝트를 진행하면서 느낀건, '이런 틀이 있으니 진행이 수월하군' 이었다.


     


    하지만 다양한 프로젝트를 진행하면서 실전에서 바로 적용 가능한


    '프로토타이핑'을 선호하게 되었다.


     


    이처럼 다양한 방법론과 진행방법이 존재한다.


    개인적으로 진행하는 프로젝트라면 어떠한 방법론을 이용하든


    본인에게 맞는것을 선택하면 되겠지만


    팀을 결성하고, 언젠가 팀의 중책을 맡게 될 경우가 생길텐데


    이 때 팀을 잘 꾸려가고 프로젝트를 잘 이끌어나가기 위한 직책,


    '아키텍트'에 관한 이야기를 다룬 책 '개발자에서 아키텍트로' 을 소개한다.


    아키텍트로~~!




    이 책에서는 일단 아키텍트가 무엇인지부터 설명한다.


    '프로그래밍 관리와 전체 시스템이 일관성 있게 동작하도록 하고 품질에 영향을 주는 품질 속성 균형을 잡아야 한다.'


    한마디로 말하면



    '두루두루 잘해야 한다.'


    라는 것이다.


     


    대학 컴퓨터(또는 정보)과에서는 아래와 같은 과목들을 배운다.


    '소프트웨어 공학'


    '시스템 분석 설계'


     


    프로그램을 어떻게 만들어야 좀 더 완성도 있게 만들 수 있는지에 대한 방법론과


    프로그램 개발 시 어떤식으로 진행해야 효율적인 개발이 될 수 있는지에 대한 내용을 배운다.


     


    코딩 실력과 더불어 이런 지식들을 합쳐 만들어진 직함이라고 생각하면 될 것 같다.


     





    - 아키텍트에게 필요한 기술을 차례로 진행


    목차를 보고 원하는 내용만 봐도 상관없지만


    처음으로 아키텍트를 접하는 개발자라면 차례대로


    아키텍트의 능력을 기르게끔 해준다.


     


    마치 스무고개 문답을 하듯 내용이 진행되는데,






    아키텍트란 무엇인가? -> 아키텍트를 좀 더 쉽게 접근하려면? -> 아키텍트에게 필요한 능력은?






    같이 초반부에는 '아키텍트'라는 것에 대해 익숙해지게끔 하고


    문서화, 문제 이해와 해결과 같은 실력이 요구되는 능력을 후반부에 배치해서


    실전에 필요한 능력을 알려준다.


     




    또한 새로운 장 시작면에는 제목과 함께 진행하는 주제가 어떤 단계에 해당하는지


    '이해', '탐색', '평가', '실현' 4단계로 디자인 마인드셋을 보여주어


    사람들이 저마다 어떻게 문제를 푸는지 엿볼 수 있다.


     


    책의 내용을 크게 아래와 같이 3PART로 나눈다.


    1PART :  아키텍트에 대해 정의


    2PART : 아키텍트가 하는 일


    3PART : 실전에서 아키텍트


     


    각 파트별로 어떤 단계에 해당하는지 간략하게 보여줌으로써


    진행도를 알게되고 발전하는 느낌을 받게 될 것 같다.


     





    - 꼭 알아야 하는 문장에 색상 표시


    새롭게 배울 때 불편한 것 중에 하나를 꼽자면 모르는 단어가 나왔을 때


    '이정도라면 독자는 당연히 알겠지' 라며 자연스레 사용될 때일 것이다.


     


    이 책에서는 처음 나오는 단어나 생소한 단어에 푸른색 표시를 주어 강조하고


    해당 단어에 대해 설명을 한 뒤 내용을 이어간다.


    번역서이기 때문에 한글로만 나타낼 수도 있는데 한글단어 옆에 영어 원문을 표시함으로써


    의미가 모호한 단어일 경우 직접 찾아볼 수도 있다(번역가님의 멋진 배려!).


     


    직접 해보자!



    - 실전에서 일어날만한 문제에 대해 접근


    1, 2파트에서 아키텍트에 대해 알게되었다면 마지막 파트에선 팀에서 해볼만한 활동을 보여준다.


    38가지로 나눠 문제집의 '실전문제' 같은 형식으로 직접 팀에서 해볼 수 있게끔 구성 되어있다.


     


    '현실'을 배운다...



    - 그래서...


    이 책을 한마디로 요약하자면 '어렵다'였다.


    처음보는 용어들도 많고, 신경써야 할 것도 많고...


    아직 리더의 역할을 맡을 시기가 아니라서 그런가보다 했는데,


    이 책에 이런말이 나온다.







    '만일 여러분의 팀에 아키텍트가 없다면... 네, 축하합니다. 이제 당신이 하면 됩니다!'


     


    우리가 학생으로써 보호받다가 갑자기 어른이라며 사회에 대한 책임을 요구받았을때 처럼


    아키텍트는 차근차근 준비를 하다가 맡게 되는 것 보단 어느순간 갑작스레 맡게 되는 경우가 많다는 것이다.


     


    개발자는 개발에 대한 능력이 중요하다고 믿고 있다.


    이 책을 읽은 다음에도 변함이 없다.


    하지만 많은 경험을 한 뒤 어떤 팀을 맡게 되는 리더가,


    어떤 프로젝트를 맡는 책임자가 되는 순간은 찾아온다.


     


    갑작스레 찾아올 미래에 당황하지 않고


    멋진 어른으로써 당당하게 아키텍트라는 명함을 달 때를 위해


    많은 개발자들이 이 책을 한번쯤은 읽어보면 좋을 것 같다.


  •  








    [주요 내용]



    - 소프트웨어 아키텍처란 무엇이고 아키텍트는 무슨 일을 하는가



    - 디자인 싱킹과 디자인 마인드셋을 활용한 아키텍처 설계 전략



    - 이해관계자와 비즈니스 목표를 명확하게 파악하고 이해하기



    - 아키텍처 핵심 요구사항을 파악하고 품질 속성 정의하기



    - 자주 사용하는 아키텍처 패턴과 사용법



    - 아키텍처 모델을 활용해 시스템 복잡도 관리하기



    - 아키텍처 디자인 스튜디오 운영하기



    - 설계를 시각화하고 아키텍처 문서화하기



    - 아키텍처를 평가하고 피드백을 반영해 개선하기



    - 적절하게 설계 권한을 위임하며 팀의 역량 높이기



    - 현업에서 바로 활용 가능한 38가지 팀 활동







    [대상 독자]



    - 개발자에서 아키텍트로 커리어를 변경하고 싶은 사람



    - 소프트웨어 아키텍처를 제대로 이해하여 실무 개발 능력을 향상하고 싶은 사람



    - 소프트웨어의 전체 구조 및 개발 과정 전체를 이해하고 싶은 신입 개발자



    - 소프트웨어를 둘러싼 다양한 이해관계자들의 관점을 이해해보고 싶은 사람







    [개발 경력별 이 책의 활용법]



    - 신입 개발자: 단순히 코드를 짜는 일을 뛰어넘어, 소프트웨어 개발 및 프로젝트이라는 숲을 보며 시야를 넓혀보세요.



    - 5년 이하 경력의 개발자/아키텍트: 흔히 쓰는 패턴, 모델, 설계 방식을 이해하고, 아키텍처를 시각화하고 문서화하는 방법을 배우세요. 사람들과 협업할 때 어려움을 겪는다면, 사례 탐구와 경력 있는 아키텍트들의 기고문을 통해 지혜로운 방법을 찾아보세요.



    - 10년 이상 경력의 개발자/아키텍트: 아키텍트로서 프로젝트를 직접 이끌거나 개발 팀장의 역할을 수행해야 하나요? 팀원 및 이해관계자와 제대로 커뮤니케이션 하는 방법을 익혀보세요. 문제를 해결하기 위해 해볼 만한 활동을 찾아보고 책에서 소개하는 방법을 직접 따라해보세요. 금세 해결책을 찾을 수 있을 겁니다.







    [서평]



    1부에서는 소프트웨어 아키텍트가 하는 일을 소개하며, 소프트웨어 아키텍처를 정의합니다. 2부에서는 본격적으로 아키텍처를 설계하고, 이해관계자와 소통하며, 아키텍처 핵심 요구사항을 알아내 설계에 반영하는 방법을 알아봅니다. 아키텍처 패턴은 물론 설계를 시각화하고 아키텍처를 문서화 하는 방법도 다룹니다. 3부에서는 아키텍처를 설계하며 문제 상황을 마주했을 때, 해결책을 찾아야 할 때, 설계를 더 구체화하고 싶을 때 해볼수 있는 38가지 침 활동을 소개합니다. 필요한 부분을 골라 읽어도 좋지만, 개발자에서 아키텍트로 첫걸음을 시작하는 분이라면 처음부터 순서대로 읽기는 것을 추천 합니다. 팀에서 해볼 만한 활동을 찾는다면 3부를 훑어보며 고라봐도 좋겠습니다. 







    이 책은 화이트보드 앞에 서서 복잡한 질문에 여러 가지 도형과 선을 그리면서 답변해야 하는 사람들에게 어울립니다. 또한 소프트웨어 설계를 처음 접하는 사람에게도 좋은 안내서가 될것입니다. 이책의 앞부분에서는 기본 지식을 정리하고, 그다음에는 훌륭한 소프트웨어 아키텍트라면 알아야 할 핵심 지실을 하나씩 설명하고 있습니다. 책을 읽다보면 느낌으로는 알고 있었지만 이름을 몰랐던 개념을 확인 할수 있고, 알고 있던 내용과 실제 지식 간의 차이를 발견할수 있습니다. 개발하는데 왜 필요한지 설명 할수 있게 되면서 다른 사람들을 설득하거나 팀을 더 잘 이끌 수도 있습니다. 아키텍트로 이런류의 책을 이미 읽어본 독자라면, 팀을 이끄는 새로운 관점을 배울수 있을 것입니다. 주니어 개발자라면 자신이 만들려는 소프트웨어를 더 잘 설명 할수 있을것이고, 또한 이책은 개발자이자 미래에 아키텍트가 될 사람을 가르치고 이끌어 설계 과정에 온전히 참여하도록 하는데 초점이 맞춰져 있습니다. 경험이 부족한 동료와 함께 시스템을 설계해도, 안전하고 생산적인 결과를 낼 수 있게 하는 여러 가지 협력적인 설계 방법도 배울수 있습니다.



    소프트웨어 아키텍처에 대해 배우고 싶은 개발자라면 좋은 지침서가 될 것이라 생각합니다. 


     



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







  • 오늘 리뷰할 책은 한빛 미디어의 따끈따끈한 신작 '개발자에서 아키텍트로'입니다.



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












    이 책은 소프트웨어 아키텍트가 무엇인지, 하는 일, 아키텍처를 설계하는 법과 핵심 요구사항을 설계에 반영하는 방법 등을 알려주는 책입니다.



    제목과 같이 소프트웨어 아키텍트가 되고자하는 개발자를 위한 책이라고 할 수 있겠네요^^




















    저는 아직 소프트웨어 아키텍트에 대해 많이 알지는 못하는데요. 기초를 배우기에 좋은 책이었습니다.








































    가볍지만 꽤 두꺼운 책입니다. 소프트웨어 아키텍트가 알아야할 기본적인 것부터 설계 방법, 패턴, 실천 등 실전 예시까지 제시해주는 친절한 책입니다.





























    화이트보드 토론 방법과 팁 :)




















    소프트웨어 아키텍트가 되기 위한 공부를 하시는 분께 추천드립니다.



    <개발자에서 소프트웨어 아키텍트로>









  • [ 선택 이유 ] 



    이제 자바스크립트 코드는 좀 눈에 들어온다. 그래서 요새는 구조, 아키텍쳐에 대해 고민을 하고 또 설계하고 있다.



    업무에서도 슬슬 설계관련된 것을 하다보니 부족한 점이 많이 보이는데, 대부분 물어보니 하면서 배우는 거라고 하시더라.



    하지만 나는 하면서 배우는 것도 좋지만, 일단 어느정도 기초지식과 배경을 가지고 시작하는 것을 선호한다. 그래서 책이 필요했고 읽게 되었다.



    [ 본문 ] 



    일단 내가 느끼기에 책이 난해하다. 프로그래밍 언어처럼 확실한 구조를 지닌 문법을 가지고 있는 것도 아니요.



    언어가 가진 특별한 특징도 없다. 그래서 나에게 난해하다



    그나마 다행인점은 난해할 거같은 나같은 독자를 위해 라이언하트 프로젝트를 통해 사례를 들고 어떤식으로 구체화해가는지 확장해간다.



    이 책을 읽고 난후 나는 어느정도 규모있는 기능을 구현하고자 할때 좀더 신중해졌다.



    설계<->구현<->유지보수의 시간분할은 필연적이다. 하지만 나는 설계는 그렇게 중요하지 않다고 생각했다. 전체적인 구조는 머리속으로 빠르게 그리고 그 시간에 구현을 하는게 올바른 개발자라고 생각했지만 요새 규모가 있는 개발을 하다보니 나는 똑똑하지 않는 개발자라는 확신??이 들었다.



    그래서 설계가 필요하고 정리가 필요하다. 그런만큼 이 책은 많은 도움이 되었다.



    내가 생각하는 개발자는 총 5단계가 있다. 1단계 낫휴먼부터 (초급,중급,고급) 5단계 개발자까지이다.



    그중에 2단계가 초급 개발자의 단계인데, 기능을 구현하라고 하면 어떻게든 구현해오는 단계이다.



    3단계는 기능을 구현하면서 유지보수, 리펙토링, 협업을 신경쓰는 단계이다.


    이 책은 2->3단계으로 가는 길을 넌지시 알려주는 책이다. 이번 책을 읽고 협업을 하고 싶은 개발자가 되길 스스로 기대한다.


     


  • 개발자에서아키텍트로_축소.jpg


     


     


       개발을 하다 보면 프로젝트에 참여한 아키텍트를 보면서 나도 언젠가는 될 수 있을까? 라는 생각을 가지거나 아키텍트의 높은 연봉을 부러워하기도 합니다. 혹은 별로 하는 것도 없는데 돈만 많이 받아간다고 생각될 수도 있습니다.


       그러나 어느정도 개발경력이 쌓이고 난 후에도 아키텍트가 되려면 어떤 것을 알아야 하고, 어떻게 공부해야 할 지 알려주는 사람도 없고 관련내용을 찾아보기가 쉽지 않습니다. 이 책은 설계를 위해서 필요한 내용이나 pattern, design, 방법론 등을 알려주는 입문서입니다.


       책을 절반 정도 읽게 되면 PART 3에서 38개의 활동을 소개합니다. 문제를 이해하고 싶고, 해결하고 싶고, 실제 아키텍처를 만들 때, 평가하고 싶을 때 등 4가지로 분류해서 각 10가지 정도의 내용을 알려줍니다. 쉽게 말씀드리면 이론 반 실무 반 정도로 구성되어 있다고 볼 수 있습니다.


       아키텍처에 대한 교육을 듣거나 아키텍트였거나 활동 중인 분들의 이야기를 들어보면 아키텍트를 하기 위해선 폭넓은 지식이 필수적이지만 그보다 더 중요한 것이 다양한 경험이라고 합니다. 실제로 설계할 때나 고객들과의 의사소통 시 일반적이지 않은 경우들을 마주하게 되고, 그것을 잘 해결하고 해결한 경험을 가지고 있는 것이 곧 그 사람의 실력이자 연봉이라고 합니다.


       이 책에서 모든 이론을 소개해주는 것은 아니지만 아키텍트를 수행하기 위해서 고려해야 할 요소들에 대해서 알려주어 길잡이 역할을 한다고 볼 수 있을 것 같습니다. 그리고 이론을 소개한 후에는 항상 “사례 연구”로 실제 사례처럼 비유하여 서술하고, “마무리”를 통해서 요약 정리해줍니다.


       또한 모든 경우를 소개하는 것은 아니지만 절반 정도의 분량을 할애하여 아키텍트를 수행하면서 고민하거나 수행해야 할 경우에 대해서 미리 알려주어 훈련해볼 수 있게 해 줍니다. 이 책의 특징이자 장점이라고 생각합니다. 아키텍트가 되고 싶다면 그냥 읽고 넘기지 말고 꼭 해보시기 바랍니다.


     


     


     


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

  •  





    저자: 마이클 킬링



    옮김: 김영재


     


     



    #책소개


     



    개발자에서 아키텍트로 거듭나기! 초보 아키텍트를 위한 실전 입문서



    이 책은 개발자에서 아키텍트로, 변화의 첫걸음을 내딛는 이를 위한 실전 입문서다. 설계를 위한 필수 지식, 아키텍처 패턴, 모델, 설계 방법론, 커뮤니케이션 노하우를 상세히 소개한다. 문제 상황에서 팀원들과 해볼 수 있는 38가지 팀 활동을 소개하며 실무 적응 능력을 키워준다.

    아키텍처를 잘 모르는 개발자라면, 이 책을 읽으며 개발 업무의 구조를 이해하는 실력을 향상할 수 있다. 현업 아키텍트라면, 결정사항을 잘 설명하여 팀을 이끌고 이해관계자와 소통하는 능력을 키울 것이다. 이 책과 함께 프로젝트와 팀을 성공으로 이끄는 훌륭한 아키텍트로 거듭나길 바란다.


     



    라고 교보문고가 소개하더이다.


     




     


     



    # 이 책의 특징


     



    1. 상세하면서도 일목요연하게 쓰여있다.



    사실 책을 읽는 순서는 딱히 정해져있지 않다.. 웬만해서는



    하지만 무엇인가 순차적으로 정보를 줄 때에는 정방향 구성을 하기 마련이고 



    그렇게 되면 앞을 읽지 않았을 때 뒷 내용이 전혀 이해가 되지 않는 경우도 발생하는데..?



    그리고 앞에 내용이 있다지만 그것도 어디에 있는지 몰라서 고생하는 경우가 있는데..



    이 책은 골라 읽어도, 순차적으로 읽어도 한 눈에 들어오는 구성을 가지고 있다.


     



    2. 적절한 예시



    구조적 관점에서 바라본다는 것이 새롭지 않으면서도 새로운 분야인데적절한 예시로 이해를 도왔고 중간 중간 용어 설명이나 보충 설명들이 실제 공부하다보면 생기는 의문점이라책만으로도 해결이 되는 것이 맘에 들었다.


     


     




     



    #후기


     



    사실 아키텍쳐 분야가 더 돈 많이 번다.



    어셈블리어가 공부하려는 사람은 적지만 정말 필요한 것처럼..



    밑바닥이 불편해보이지만 아주 필요한 부분이다.



    피라미드랄까..? 제일 낮은 곳에 위치하지만 윗부분을 전부 떠받치는 것은 밑부분이다.


     



    무엇인가 만들 때도 마찬가지이다.



    설계가 제일 중요하다.



    요구 사항을 모두 충족시키면서도 일어날 수 있는 모든 상황에 대해서 한 번 생각해보고실제 어떻게 구현하면 유지보수가 편해지고 호환성이 좋아 아무 곳에서 실행되는.. 그런 프로그램을 만들기 위해서는 설계이 전체의 7할 이상의 시간을 쏟아부어야 한다.


     



    솔직히 이 책을 읽는다고 갑자기 아키텍쳐에 관한 전문지식이 생기거나 그러는 것은 아니다.다만 이러한 관점도 있구나 하면서 새로운 관점을 머리에 입력되는 것은 사실이다.이는 실제 아키텍쳐를 설계하게 될 때에도 도움을 줄 것이며 내가 개발할 때 무엇을 염두하고 하느냐에 도움을 주기 때문에 코딩 스타일이 효율적으로 바뀔 수도 있다고 생각한다.


     



    물론 내 생각.


     



    아래 만화를 보면서 설계의 중요성을 알아보자.사실



    아래는 언어 별 특징을 알려주는 프로그래밍 만화지만... 안타까운건 자기가 아는 언어만 이해한다는 거..ㅎ


     




     


     




     



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





  • 오탈자 보기
  • 부록/예제소스
    내용이 없습니다.
  • 추천도서
    내용이 없습니다.
  • 장바구니
    위시리스트
    구매하기
    닫기

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