이펙티브 소프트웨어 아키텍처(Effective Software Architecture)
이펙티브 소프트웨어 아키텍처
더 나은, 더 빠른 소프트웨어를 구축하기 위한 소프트웨어 아키텍처 필수 가이드
www.gilbut.co.kr
책 정보
소프트웨어는 점점 더 복잡해지고 있으며, 이러한 시스템을 개발하고 운영하는 일은 매우 어렵습니다. 이 과정에서 소프트웨어 아키텍처는 시스템을 구상하고 구현하며 운영하는 데 중요하고 핵심적인 역할을 합니다. 이 책은 소프트웨어 아키텍처가 무엇인지 정의하고, 이를 실제 개발 과정에서 어떻게 활용할 수 있는지 설명합니다.
특정 아키텍처 방식만 다루는 것이 아니라, 아키텍처가 제품 개발 과정에서 어떤 역할을 하며, 팀 내 다른 팀과 어떻게 협력해야 하는지도 알려줍니다. 특히, 시스템이 변화할 때 이를 효과적으로 설계하고 관리하는 방법을 소개하며, 빠르고 좋은 결정을 내리는 것이 프로젝트 성공에 얼마나 중요한지 강조합니다.
또한, 개발 과정에서 의사소통과 협업이 왜 중요한지, 그리고 아키텍처 팀을 어떻게 구성하고 운영해야 하는지도 다룹니다. 마지막으로, 저자의 경험과 실무적인 조언을 풍부하게 담고 있어 실제 아키텍처 설계와 운영에 매우 유용한 가이드를 제공합니다.
- 출간: 2025년 3월 28일
- 페이지: 296쪽
목차
1장 소프트웨어 아키텍처
1.1 기본 구조
1.2 시스템
1.3 구성 요소
1.4 구성 요소 간 관계
1.5 환경과의 관계
1.6 설계를 통제하는 원칙
1.7 시스템 진화
1.8 요약
2장 맥락
2.1 콘셉트
2.2 신뢰도
2.3 아키텍처적으로 중요한 요구 사항
2.4 제품 계열
__2.4.1 하나의 제품, 여러 플랫폼
__2.4.2 제품 라인
__2.4.3 제품군
__2.4.4 크로스 플랫폼
2.5 플랫폼 구축
2.6 표준
2.7 요약
3장 변화
3.1 변화의 단계
3.2 변화의 유형
3.3 제품 중심 변화
3.4 기술 중심 변화
3.5 단순화
3.6 투자 마인드
3.7 점진적 배포
3.8 아키텍처 진화
3.9 요약
4장 프로세스
4.1 시스템 문서화
4.2 비전을 향한 작업
4.3 변경 제안서 작성
4.4 백로그 관리
4.5 대안 고려
4.6 아무것도 하지 않기
4.7 긴급성과 중요성
4.8 시스템 재문서화
4.9 요약
5장 설계
5.1 아키텍처가 설계 효율을 높이는 방법
5.2 설계가 아키텍처 변화에 미치는 영향
5.3 분해
5.4 조합
5.5 조합과 플랫폼
5.6 점진적 접근
5.7 병렬 처리
5.8 조직 구조
5.9 개방적인 작업
5.10 포기하기
5.11 완료
5.12 요약
6장 의사 결정
6.1 추가 정보는 도움이 되는가?
6.2 그동안 어떤 일이 일어났는가?
6.3 얼마나 많은 의사 결정을 하고 있는가?
6.4 아무것도 하지 않을 경우 비용은 얼마인가?
6.5 변경을 수용할 수 있는가?
6.6 결정을 잘못 내렸을 때 비용은 얼마인가?
6.7 얼마나 더 확신할 수 있는가?
6.8 이 결정은 내 책임인가?
6.9 일관성이 있는가?
6.10 문서화할 수 있는가?
6.11 요약
7장 실무 방식
7.1 백로그
7.2 카탈로그
7.3 템플릿
7.4 검토
7.5 진행 상태
7.6 진행 속도
7.7 집중 시간
7.8 요약
8장 커뮤니케이션
8.1 정신 모델
8.2 문서 작성
8.3 대화
8.4 정보 아키텍처
8.5 네이밍
8.6 용어집
8.7 경청
8.8 요약
9장 아키텍처 팀
9.1 전문화
9.2 팀 구조
9.3 리더십
9.4 책임
9.5 인재
9.6 다양성
9.7 조직 문화
9.8 모임
9.9 세미나와 서밋
9.10 요약
10장 제품 개발 조직
10.1 개발 방법론에 따른 작업
10.2 제품 관리 팀과 협업
__10.2.1 도와주기
__10.2.2 다양한 결말
__10.2.3 작업 범위의 한계 설정
10.3 UX 팀과 협업
10.4 프로그램 관리 팀과 협업
10.5 엔지니어링 팀과 협업
__10.5.1 끝까지 참여하기
10.6 테스팅 팀과 협업
10.7 운영 팀과 협업
10.8 요약
부록 결론
A.1 비전
A.2 아키텍처 복구
A.3 조직 변화
A.4 변경 프로세스
A.5 맺음말
독서
책을 펼치고 작가의 말, 추천사를 지나서 독자가 맨 처음 만나는 부분은 어딜까요? 바로 맨 앞장입니다.
그리고 이 책은 1장부터 소프트웨어 설계란 무엇인가, IEEE 표준, 아키텍처의 정의를 소개하며 시작합니다.
(개인적으로) 책도 하나의 구조물, 즉 아키텍처에 속한다고 생각합니다. 헤드라인, 소제목, 적절한 단락 나누기 등등..
1장을 읽으며 이 책은 도구나 방법들에 대해서 아주 구체적인 해결책을 제시하는 것보다는 조금은 추상화된 개념들을 사용하여 올바른 방향의 길을 제시한다는 느낌을 받았습니다. 또한 용어설명, 헷갈리는 용어들의 vs. 정보, 한 챕터 끝의 요약 등 딱! 제가 원하는 형식이고, 이러한 설명 방식은 이펙티브(Effective)라는 책 제목의 의미를 잘 담은 포맷이라고 생각했습니다.
1장을 지나서 다음 여정은 맥락에 대해서 설명합니다. 한국어로는 어감이 잘 와닿지 않을 수 있지만.. 문맥, 맥락 등으로 사용되며 영어로는 Context라고 부릅니다. 실제 개발을 할 때에도 이 Context는 상당히 많은 부분에서 사용되는 용어이고, 맥락을 일치시키지 않고 대화하거나 일을 하게 된다면 서로 다른 방향으로 도달할 지도 모릅니다.
소프트웨어는 어떻게 될까요? 하드웨어는? 모든 것은 변화합니다. 마인드나 배포, 아키텍처 또한 말이죠! 그 과정을 3장에서 다루고 있습니다.
변화란 어떤 것인지에 대해 이해했다면, 그 다음은 일을 진행(Process)해야겠죠?
운영체제에서의 프로세스/스레드 그런 개념이 아니라 일 처리를 할때의 프로세스를 의미합니다.
제가 경험했던 문서화, 변경 제안서, 백로그에 대해서 조금 더 깊게 알게 되었고 직전 회사에서 경험했던 긴급한 일&중요한 일을 사람마다 각기 중요하게 생각하는 차이 그리고 재문서화에 대해서도 배웠습니다.
5장 설계가 가장 소제목이 많았습니다. 그도 그럴것이 아키텍처==설계에 근사하기 때문입니다.
설계에서 대표적으로 나오는 용어인 분해와 추상화! 어떤 백엔드시스템은 종종 너무 과도한 추상화때문에 알아보기 힘들고 오히려 더 어렵다고들 합니다. 그렇지만 적절한 추상화는 소프트웨어를 유연하고, 추가해야되는 코드나 변경해야되는 코드를 효과적으로 줄일 수 있습니다. 모든 것은 '적절한'이 중요한 포인트인데, 이것은 매력적이게 느껴지기도 하지만 경험이 필요한 영역이기도 합니다.
이후에 점진적 접근, 병렬처리, 조직 구조, 개방적인 작업, 포기, 완료 등에 대한 설계과정에 대해 간적접인 텍스트로 저자의 경험을 들어볼 수 있었습니다.
빠르게 6장 의사 결정에서 주요한 체크리스트 항목들, 7장의 실무 방식을 읽으며 많은 정보들에서 중요한 포인트를 빼낸 생각 정리를 하며 나는? 우리 팀은? 우리 회사는? 어떤 방식으로 의사 결정과 실무를 하고 있는지 되돌아봤습니다.
8장에서는 커뮤니케이션을, 9장에서는 아키텍처 팀을, 10장에서는 제품 개발 조직에 대해 다룹니다.
여기 9, 10장에서 공통점을 찾으셨을까요?
"'팀', '조직'은 '커뮤니케이션'이 필요하다." 입니다.
결국 혼자 일하고, 소프트웨어를 만드는 것이 아닌 이상 팀(조직)으로 일을 하고 우리는 커뮤니케이션을 통해 협업을 할 수 밖에 없습니다.
물론 조직의 성격과 종류에 따라 커뮤니케이션해야 하는 방법은 달라져야 합니다.
총평
마지막 문구에서도 볼 수 있듯, 아키텍처에서 가장 중요한 것은 대화와 협업. 그리고 변화에 대응할 수 있는 경험과 숙련도라고 생각합니다.
이 책의 1장부터 10장까지 읽으면서 아키텍처 개발의 전 과정을 함께 진행한 듯한 느낌이 들었고, 나중에 시니어나 아키텍처가 돼서도 두고두고 반복해서 읽을 좋은 책이라는 것을 느꼈습니다.
효과적인 소프트웨어 아키텍처를 만들고 싶으시다면 Effective Software Architecture를 한번 읽어보시는 건 어떨까요?