Top

소프트웨어 아키텍처 이론과 실제 4/e

  • 원서명Software Architecture in Practice, 4th Edition(ISBN 9780136886099)
  • 지은이렌 베스(Len Bass), 폴 클레멘츠(Dr. Paul Clements), 릭 캐즈먼(Rick Kazman)
  • 옮긴이김무항
  • ISBN : 9791161756707
  • 40,000원
  • 2022년 08월 31일 펴냄
  • 페이퍼백 | 556쪽 | 188*250mm
  • 시리즈 : 소프트웨어 아키텍처

책 소개

요약

소프트웨어 아키텍트뿐만 아니라 소프트웨어 아키텍처 관련 이해관계자 모두 읽어야 할 책이다. 90년대 후반 초판이 나온 이후 25년이 지난 현재 4판이 나올 정도로 소프트웨어 아키텍처 분야의 교과서와 같은 책이다. 4판에서는 클라우드, 모빌리티, 에너지 효율성 등 최신 소프트웨어 기술에 관한 내용이 추가됐다.

이 책에서 다루는 내용

◆ 아키텍처가 기술적 환경, 프로젝트 생애주기, 비즈니스 프로필, 자신만의 실천법에 어떤 식으로 영향을 미치고, 이들로부터 어떤 식으로 영향을 받는지 알아본다.
◆ 아키텍처를 통해 품질을 최적화하기 위해 검증된 패턴, 인터페이스, 실천법을 활용한다.
◆ 모빌리티, 클라우드, 머신러닝, 양자 컴퓨팅을 위한 아키텍처를 설계한다.
◆ 점점 더 중요해지는 에너지 효율성과 안전 같은 품질 속성을 위한 설계 방법을 알아본다.
◆ 아키텍처 관점에서 중요한 영향들을 파악하고 데브옵스와 배포 파이프라인을 활용하고 아키텍처 부채를 관리함으로써 시스템을 확장한다.
◆ 더 많은 가치를 전달하기 위해 조직에서의 아키텍처 역할을 이해한다.

저자/역자 소개

지은이의 말

이 책을 쓰기 시작할 때 스스로 든 첫 번째 질문은 ‘아키텍처가 여전히 중요한가?’였다. 거의 모든 도메인과 품질 속성(quality attribute)에 있어 클라우드 인프라와 마이크로서비스, 프레임워크와 참조 아키텍처가 부상하고 있는 가운데, 과연 아키텍처에 관한 지식이 아직도 필요한지에 대한 의문이 들 수 있다. 오늘날 아키텍트는 다양한 종류의 툴과 인프라 옵션 중에서 필요한 부분을 선택한 다음, 이를 인스턴스화하고 설정하기만 하면 만들어진다.
과거에도 그랬고 현재도 우리는 이게 사실이 아니라고 생각한다. 이것이 어느 정도 편견이 라는 점은 인정한다. 따라서 우리는 헬스케어와 자동차, 소셜 미디어, 항공, 국방, 금융, 전자 상거래 분야에서 일하는 중인 아키텍트 동료와 이야기를 나눴다. 결과적으로 우리는 아키텍처가 1판을 썼던 20년 전만큼 여전히 중요하다는 믿음에 확신을 얻을 수 있었다.
3판이 나온 이후로 IT 환경은 많이 변했다. 예전에 고려하지 않았던 일부 품질 속성은 많은 아키텍트에게 중요해졌다. 또한 소프트웨어가 우리 사회의 모든 측면에 계속해서 스며들고 있어 안전(safety) 고려 사항이 많은 시스템에서 매우 중요해졌다. 이는 소프트웨어가 오늘날 우리가 모는 자동차를 어떤 방식으로 제어하는지 생각해보면 쉽게 알 수 있다. 마찬가지로 에너지 효율성(energy efficiency)은 10년 전에는 아키텍트들이 별로 생각지 못했던 속성이었지만 지금은 반드시 관심을 가져야 하는 속성이다. 엄청난 양의 에너지를 필요로 하는 대규모 데이터 센터부터 우리를 둘러싼 배터리로 동작하는 작은 크기의 모바일 장치와 IoT 장치까지 에너지 효율성을 생각해야 한다. 지금은 그 어느 때보다도 기존에 이미 만들어져 있는 컴포넌트들을 활용해 시스템을 만들고 있다는 점을 생각할 때 통합성(integrability)이라는 품질 속성은 점점 더 많은 관심을 받고 있다.
이번 4판이 여러분의 서재 한 켠에 유용한 책으로 자리 잡기를 기대한다.

지은이 소개

렌 베스(Len Bass)

세계 여러 곳에서 강의를 해왔고 수상 경력이 있다. 소프트웨어 아키텍처에 관한 그의 책은 업계 표준으로 여겨지며, 소프트웨어 아키텍처에 관한 책 외에 사용자 인터페이스 소프트웨어와 데브옵스(DevOps)에 관한 책도 썼다. 50년 넘게 소프트웨어 개발을 해왔고, 그중 25년은 카네기 멜론(Carnegie Mellon)의 SEI(Software Engineering Institute)에서 일했다. 호주의 NICTA에서 3년간 근무했으며, 현재는 카네기 멜론 대학교(Carnegie Mellon University)에서 겸임 교수로 데브옵스를 가르친다.

폴 클레멘츠(Dr. Paul Clements)

빅레버 소프트웨어(BigLever Software Inc.)의 고객 성공 부서 부사장이다. 이전에는 워싱턴 DC의 미해군 연구소(The U.S. Naval Research Laboratory)에서 컴퓨터 과학자로 일하면서 고급 소프트웨어 엔지니어링 원칙들을 실시간 임베디드 시스템에 적용하는 업무를 수행했다. 그 후에 카네기 멜론 대학교 SEI의 기술 부서 수석 구성원으로서 소프트웨어 제품 라인 엔지니어링과 소프트웨어 아키텍처 설계, 문서화, 분석에 관한 프로젝트를 이끌었다.
이 책 외에도 『소프트웨어 아키텍처 문서화』(에이콘, 2016)와, 『소프트웨어 아키텍처 평가』(에이콘, 2009)을 공저했다. 까다로운 소프트웨어 시스템의 설계와 명세화에 대한 오랜 관심을 두고 있으며, 소프트웨어 엔지니어링에 관한 100여 개의 논문을 썼다.

릭 캐즈먼(Rick Kazman)

하와이 대학교(University of Hawaii)의 교수이자 카네기 멜론 대학교 SEI의 방문 연구원이다. 주요 연구 관심 분야는 소프트웨어 아키텍처와 설계 및 분석 툴, 소프트웨어 가시화, 소프트웨어 엔지니어링 경제다. 영향력이 매우 높은 여러 아키텍처 분석 방법과 툴을 만드는 데 참여했으며 ATAM(Architecture Tradeoff Analysis Method, 아키텍처 절충점 분석 방법)과 CBAM(Cost-Benefit Analysis Method, 비용-이익 분석 방법), Dali, Titan 등이 대표적이다. 이 책 외에도 200개가 넘는 출간물을 작성했고, 세 개의 특허와 여덟 권의 책을 공저했다. 저서로는 『Technical Debt』(MIT Press, 2021)과 『Designing Software Architectures』(Addison-Wesley Professional, 2016), 『소프트웨어 아키텍처 평가』(에이콘, 2009), 『Ultra-Large-Scale Systems』(Carnegie Mellon University, 2006) 가 있다. 구글 스칼라(Google Scholar)에 따르면, 그의 연구는 25,000번 넘게 인용됐다. 현재 IEE TAC(Technical Activities Committee, 기술 활동 위원회)의 의장이자, IEEE Transactions on Software Engineering의 부편집자이며, ICSE Steering Committee의 회원이다.

옮긴이의 말

이 책은 소프트웨어 아키텍처 분야에서 최고로 꼽히는 명저 중 하나로, 1판이 1990년대 후반에 출간된 이래로 약 25년에 걸쳐 4판까지 출간됐다. 1990년대 후반의 소프트웨어는 지금과 완전히 다른 모습이었지만, 좋은 소프트웨어가 갖춰야 할 본질적인 속성은 그때나 지금이나 크게 다르지 않다고 생각한다. 이 책은 과거 1판이 출간될 당시에도 큰 반향을 불러일으켰으며, 시간이 흐름에 따라 저자들의 축적된 경험이 반영됐고 클라우드 컴퓨팅이나 모빌리티와 같은 현대 컴퓨팅에 관한 내용도 추가됐다.
이 책은 소프트웨어 아키텍트뿐만 아니라 소프트웨어 개발에 관련된 모든 이해관계자가 알아야 할 내용을 체계적으로 다룬다. 좋은 소프트웨어가 갖춰야 할 품질 속성들을 중심으로 아키텍트, 고객, 개발자 등 각 역할을 맡은 사람들이 품질 속성을 달성하기 위해 무엇을 해야 할지 깨닫게 해준다. 아키텍트 입장에서는 좋은 소프트웨어 아키텍처를 구성하기 위한 길잡이가 될 것이고, 다른 역할을 맡은 사람들 역시 좋은 소프트웨어 아키텍처를 위한 요소들은 무엇이고 그 요소들이 어떤 식으로 절충점을 만들어야 할지 잘 이해할 수 있으므로 좋은 소프트웨어 아키텍처를 만드는 데 기여할 수 있다.
역자로서 느끼는 이 책의 가장 큰 교훈은 우리는 모든 것을 가질 수 없고 언제나 선택을 해야 한다는 점이다. 그러한 선택은 A 아니면 B와 같은 이분법적 선택이 아니라, 언제나 절충점(tradeoff)을 고려해야 하는 것이다. 좋은 소프트웨어를 위한 많은 품질 속성 모두를 만족시킬 수는 없다. 어떤 품질 속성을 강조하기 위해서는 다른 품질 속성이 어느 정도 희생될 수밖에 없기 때문이다. 이 책을 길라잡이 삼아 여러분 소프트웨어의 특성에 맞춰 품질 속성 간의 절충점을 잘 찾아내고, 이로써 좋은 소프트웨어 아키텍처를 구성할 수 있길 바란다.

옮긴이 소개

김무항

위치 기반 서비스, 증강현실, 보안 등 다양한 분야에서 연구하고 개발했으며 기술 번역에 관심이 많다. 에이콘출판사에서 펴낸 『프로그래머처럼 생각하기』(2014), 『PHP와 MariaDB를 활용한 웹 애플리케이션 개발』(2016), 『파이썬으로 처음 시작하는 코딩』(2018), 『자바스크립 트로 하는 자료 구조와 알고리즘』(2019) 등을 번역했다.

목차

목차
  • 1부. 소개

  • 1장. 소프트웨어 아키텍처 정의
  • 1.1 소프트웨어 아키텍처의 올바른 정의와 오해
  • 1.2 아키텍처 구조와 뷰
  • 1.3 무엇이 좋은 아키텍처를 만드는가?
  • 1.4 요약
  • 1.5 참고 문헌
  • 1.6 토론 질문
  • 2장. 소프트웨어 아키텍처가 중요한 이유
  • 2.1 시스템의 품질 속성 억제 또는 보장
  • 2.2 변경 사항 추론 및 관리
  • 2.3 시스템 품질 예측
  • 2.4 이해관계자 간의 의사소통
  • 2.5 초기 설계 결정
  • 2.6 구현에 대한 제약
  • 2.7 조직 구조에 대한 영향
  • 2.8 점증적 개발 가능
  • 2.9 비용 및 일정 추정
  • 2.10 이전 가능한 재사용 모델
  • 2.11 독립적으로 개발된 요소들의 통합
  • 2.12 설계 선택 사항 제한
  • 2.13 훈련 기반
  • 2.14 요약
  • 2.15 참고 문헌
  • 2.16 토론 질문

  • 2부. 품질 속성

  • 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 토론 질문
  • 5장. 배포 용이성
  • 5.1 지속적인 배포
  • 5.2 배포 용이성
  • 5.3 배포 용이성 일반 시나리오
  • 5.4 배포 용이성 전술
  • 5.5 배포 용이성 전술 기반 질문지
  • 5.6 배포 용이성 패턴
  • 5.7 참고 문헌
  • 5.8 토론 질문
  • 6장. 에너지 효율성
  • 6.1 에너지 효율성 일반 시나리오
  • 6.2 에너지 효율성 전술
  • 6.3 에너지 효율성 전술 기반 질문지
  • 6.4 패턴
  • 6.5 참고 문헌
  • 6.6 토론 질문
  • 7장. 통합 용이성
  • 7.1 아키텍처의 통합 용이성 평가
  • 7.2 통합 용이성 일반 시나리오
  • 7.3 통합 용이성 전술
  • 7.4 통합 용이성 전술 기반 질문지
  • 7.5 패턴
  • 7.6 참고 문헌
  • 7.7 토론 질문
  • 8장. 변경 용이성
  • 8.1 변경 용이성 일반 시나리오
  • 8.2 변경 용이성 전술
  • 8.3 변경 용이성 전술 기반 질문지
  • 8.4 패턴
  • 8.5 참고 문헌
  • 8.6 토론 질문
  • 9장. 성능
  • 9.1 성능 일반 시나리오
  • 9.2 성능 전술
  • 9.3 성능 전술 기반 질문지
  • 9.4 성능 패턴
  • 9.5 참고 문헌
  • 9.6 토론 질문
  • 10장. 안전성
  • 10.1 안전성 일반 시나리오
  • 10.2 안전성 전술
  • 10.3 안전성 전술 기반 질문지
  • 10.4 안전성 패턴
  • 10.5 참고 문헌
  • 10.6 토론 질문
  • 11장. 보안
  • 11.1 보안 일반 시나리오
  • 11.2 보안 전술
  • 11.3 보안 전술 기반 질문지
  • 11.4 보안 패턴
  • 11.5 참고 문헌
  • 11.6 토론 질문
  • 12장. 테스트 용이성
  • 12.1 테스트 용이성 일반 시나리오
  • 12.2 테스트 용이성 전술
  • 12.3 테스트 용이성 전술 기반 질문지
  • 12.4 테스트 용이성 패턴
  • 12.5 참고 문헌
  • 12.6 토론 질문
  • 13장. 사용성
  • 13.1 사용성 일반 시나리오
  • 13.2 사용성 전술
  • 13.3 사용성 전술 기반 질문지
  • 13.4 사용성 패턴
  • 13.5 참고 문헌
  • 13.6 토론 질문
  • 14장. 기타 품질 속성
  • 14.1 기타 품질 속성 종류
  • 14.2 품질 속성 표준 리스트 사용 여부
  • 14.3 새로운 품질 속성을 다루는 방법
  • 14.4 참고 문헌
  • 14.5 토론 질문

  • 3부. 아키텍처 해결책

  • 15장. 소프트웨어 인터페이스
  • 15.1 인터페이스 개념
  • 15.2 인터페이스 설계
  • 15.3 인터페이스 문서화
  • 15.4 요약
  • 15.5 참고 문헌
  • 15.6 토론 질문
  • 16장. 가상화
  • 16.1 공유 리소스
  • 16.2 가상 머신
  • 16.3 가상 머신 이미지
  • 16.4 컨테이너
  • 16.5 컨테이너와 가상 머신
  • 16.6 컨테이너 이식성
  • 16.7 팟
  • 16.8 서버리스 아키텍처
  • 16.9 요약
  • 16.10 참고 문헌
  • 16.11 토론 질문
  • 17장. 클라우드 및 분산 컴퓨팅
  • 17.1 클라우드 기본 지식
  • 17.2 클라우드에서의 고장
  • 17.3 성능과 가용성을 향상시키기 위한 다중 인스턴스 사용
  • 17.4 요약
  • 17.5 참고 문헌
  • 17.6 토론 질문
  • 18장. 모바일 시스템
  • 18.1 에너지
  • 18.2 네트워크 연결성
  • 18.3 센서와 액추에이터
  • 18.4 리소스
  • 18.5 생애주기
  • 18.6 요약
  • 18.7 참고 문헌
  • 18.8 토론 질문

  • 4부. 확장 가능한 아키텍처 실천법

  • 19장. 아키텍처 관점에서 중요한 요구 사항들
  • 19.1 요구 사항 문서로부터 ASR 수집
  • 19.2 이해관계자 인터뷰를 통한 ASR 수집
  • 19.3 비즈니스 목표 이해를 통한 ASR 수집
  • 19.4 유틸리티 트리와 ASR
  • 19.5 언제나 발생하는 변경
  • 19.6 요약
  • 19.7 참고 문헌
  • 19.8 토론 질문
  • 20장. 아키텍처 설계
  • 20.1 속성 중심 설계
  • 20.2 속성 중심 설계의 구성 단계
  • 20.3 단계 4: 설계 개념 선택에 관한 추가 내용
  • 20.4 단계 5: 구조 생성에 관한 추가 내용
  • 20.5 단계 6: 설계 중에 예비 문서 생성에 관한 추가 내용
  • 20.6 단계 7: 현재 설계에 대한 분석 수행과 반복 목표 및 설계 목적 달성 리뷰에 대한 추가 내용
  • 20.7 요약
  • 20.8 참고 문헌
  • 20.9 토론 질문
  • 21장. 아키텍처 평가
  • 21.1 위험 감소를 위한 평가
  • 21.2 무엇이 핵심 평가 활동인가?
  • 21.3 평가 주체
  • 21.4 상황적 요인들
  • 21.5 아키텍처 절충점 분석 방법
  • 21.6 경량 아키텍처 평가
  • 21.7 요약
  • 21.8 참고 문헌
  • 21.9 토론 질문
  • 22장. 아키텍처 문서
  • 22.1 아키텍처 문서의 사용 용도와 청중
  • 22.2 표기법
  • 22.3 뷰
  • 22.4 뷰 결합
  • 22.5 행동 문서화
  • 22.6 뷰 외의 항목들
  • 22.7 근거 문서화
  • 22.8 아키텍처 이해관계자들
  • 22.9 실질적인 고려 사항
  • 22.10 요약
  • 22.11 참고 문헌
  • 22.12 토론 질문
  • 23장. 아키텍처 부채 관리
  • 23.1 아키텍처 부채 문제가 있는지 여부 결정
  • 23.2 핫스팟 발견
  • 23.3 아키텍처 부채 사례
  • 23.4 자동화
  • 23.5 요약
  • 23.6 참고 문헌
  • 23.7 토론 질문

  • 5장. 아키텍처와 조직

  • 24장. 프로젝트에서 아키텍트의 역할
  • 24.1 아키텍트와 프로젝트 관리자
  • 24.2 점증적인 아키텍처와 이해관계자들
  • 24.3 아키텍처와 애자일 개발
  • 24.4 아키텍처와 분산 개발
  • 24.5 요약
  • 24.6 참고 문헌
  • 24.7 토론 질문
  • 25장. 아키텍처 역량
  • 25.1 개인 역량: 아키텍트의 업무와 기술, 지식
  • 25.2 소프트웨어 아키텍처 조직의 역량
  • 25.3 더 나은 아키텍트 되기
  • 25.4 요약
  • 25.5 참고 문헌
  • 25.6 토론 질문

  • 6부. 결론

  • 26장. 미래 예측: 양자 컴퓨팅
  • 26.1 큐비트
  • 26.2 양자 순간 이동
  • 26.3 양자 컴퓨팅과 암호화
  • 26.4 기타 알고리즘
  • 26.5 잠재적인 적용 분야
  • 26.6 결론

도서 오류 신고

도서 오류 신고

에이콘출판사에 관심을 가져 주셔서 고맙습니다. 도서의 오탈자 정보를 알려주시면 다음 개정판 인쇄 시 반영하겠습니다.

오탈자 정보는 다음과 같이 입력해 주시면 됩니다.

(예시) p.100 아래에서 3행 : '몇일'동안 -> 며칠동안

정오표

정오표

[ p.81 : 1행 ]
산출물이
->
대상물이

[ p.81 : 3행 ]
정산 운영
->
정상 운영

[ p.115 : 7행 ]
변경 용이성
->
배포 용이성

[ p.194 : 2행 ]
도작하는
->
도착하는

[ p.200 : 8행 ]
캐싱(aching)
->
캐싱(caching)