개발자에서 아키텍트로

2022-07-19

도서명	개발자에서 아키텍트로:38가지 팀 활동을 활용한 실전 소프트웨어 아키텍트 훈련법
지은이	마이클 킬링
옮김	김영재
출판사	한빛미디어
ISBN	9791162244326
금액	27,000원
출판일	2021년 06월 07일 발행
페이지수	392쪽
참고	yundream소프트웨어 아키텍처 이론과 실제 : 1장 소개

책소개

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

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

출판사 리뷰

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

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

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

주요 내용

소프트웨어 아키텍처란 무엇이고 아키텍트는 무슨 일을 하는가
디자인 싱킹과 디자인 마인드셋을 활용한 아키텍처 설계 전략
이해관계자와 비즈니스 목표를 명확하게 파악하고 이해하기
아키텍처 핵심 요구사항을 파악하고 품질 속성 정의하기
자주 사용하는 아키텍처 패턴과 사용법
아키텍처 모델을 활용해 시스템 복잡도 관리하기
아키텍처 디자인 스튜디오 운영하기
설계를 시각화하고 아키텍처 문서화하기
아키텍처를 평가하고 피드백을 반영해 개선하기
적절하게 설계 권한을 위임하며 팀의 역량 높이기
현업에서 바로 활용 가능한 38가지 팀 활동

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

엔지니어링 관점에서 문제 정의하기
시스템은 분리하고 책임은 위임하기
큰 그림 그리기
품질/속성의 트레이드오프 고려하기
기술 부채 관리하기
팀의 아키텍처 설계 역량 키우기

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

아키텍처의 개요
- 아키텍처는 건축물에서 유래가 되었다.
- 16세기 르네상스 시대를 거치면서, 건축물에 대한 미적/수학적/산업적 가치에 대한 눈을 뜨면서 부터다.
- 그전에 건축관련 설계등을 하던 사람들은 길드에 소속되어서 일당을 받고 일을 처리하는 기능공으로써의 대우를 받았을 뿐이다.
- 16세기에 이르러서야 이들을 architecture라고 부르게 된다.
- architecture의 어원은 arkhitekon 이다.
소프트웨어 아키텍처
- 아키텍처는 기술,비지니스,문화,산업 환경을 아우르는 것으로 서로가 서로에게 영향을 끼친다.
- 아키텍처에는 넓은 범위를 포괄하므로 다양하며 충돌되는 이해관계자의 요구에서 최선의 해를 찾는 능력이 요구된다.
- 이해관계자에는 개발조직, 마케팅, 사용자, 유지보수, 고객등이 포진해 있으며, 몇몇 관계자는 전혀다른 요구사항을 내놓는다.
- 혹은 아키텍처 자신의 요구와 충돌 될 수도 있다.
개발조직과의 관계
- 여기 한명의 아키텍트가 있다.
- 이 아키텍트는 서버/클라이언트 환경보다는 RPC응용과 같은 묵시적인 호출을 이용한 아키텍처를 이용해서 프로젝트를 성공한 경험이 있다면, 다음 프로젝트에도 비슷한 아키텍처를 수립하려고 할 것이다.
- 만약 아키텍처가 유닉스(:12)환경을 선호한다면, 유닉스(:12)환경과 분산객체처리와 관련된 경험이 있는 개발원으로 개발조직을 꾸려나가길 원할 것이다.
- 만약 만들어져 있는 개발조직이 서버/클라이언트 환경을 선호한다면, 충돌이 불가피할 것이다.
- 분명히 아키텍트는 경험이 없는 서버/클라이언트 환경하에서의 수립을 달가워하지 않을 것이다.
- 위험부담이 있기 때문이다.
- 결국 아키텍처는 개발조직을 설득해야 할것이다.
- 최악의 경우에는 설득당해서 서버/클라이언트 환경으로 아키텍처를 수립해야 한다.
다른 이해관계자와 개발조직과의 관계
- 마케터는 빠른시간에 완벽한 기능을 가진 제품이 나오길 원한다.
- 개발시간이 단축되면 제품의 품질이 떨어진다.
- 고객의 다양한 요구에 모두 대응할 수 있는 유연한 제품을 만들길 원한다.
- 그럴 경우 개발기간이 길어지기 때문에, 개발조직은 고객의 요구를 한정시키길 원한다.
- 마케터는 인공지능을 가진 제품을 원한다. 대게가 이론적으로는 가능하다.
- 그러나 개발조직은 시스템과 기술적인 한계와 시간의 부족함을 느낀다.
좋은 아키텍처
- 아키텍트는 소수의 그룹으로 유지되어야 한다.
- 이해관계자의 요구사항을 수집 분석해야 하고, 이들 요구사항에 대한 우선순위를 정해야 한다.
- 아키텍처의 모든 내용은 이해관계자가 쉽게 이해할 수 있도록 문서화 되어야 한다.
- 현재 만들고 있는 QOS 시스템은 이러한 문서화가 부실한 것으로 생각된다. 내일부터 제대로된 문서를 만들어야 할거 같다.
- 아키텍처와 관련된 내용은 협업차원에서 이해관계자에게 배포되어야 한다.
- 성능, 확장성, 운용성등과 같은 것들은 수치로 정량화 될 수 있어야 한다.
- 일반적으로 좋은 아키텍처는 최소한의 기능을 포함하도록 하고, 후에 유연하게 다른 기능들을 포함시킬 수 있는 방향으로 설계될 필요가 있다.
- 소프트웨어개발은 한정된 시간과 자원을 가지고 이루어진다. 그러므로 이들 사이에 균형을 맞출 필요가 있다. 얼마만큼의 네트워크 자원을 소비하는지, 얼마만큼의 CPU 혹은 메모리 자원을 소모할지를 예상할 수 있어야 한다.
  CHAPTER 2 디자인 싱킹 기초