Top

소프트웨어 시스템 아키텍처 Software Systems Architecture Second Edition

  • 원서명Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives (2nd Edition) (ISBN 9780321718334)
  • 지은이닉 로잔스키(Nick Rozanski), 오언 우즈(Eóin Woods)
  • 옮긴이송재하, 금창섭, 박미율
  • ISBN : 9788960776555
  • 50,000원
  • 2015년 01월 30일 펴냄
  • 페이퍼백 | 784쪽 | 188*250mm
  • 시리즈 : 소프트웨어 아키텍처

책 소개

요약

이 책은 주로 신참 소프트웨어 아키텍트와 장차 아키텍트의 길을 가고자 하는 개발자들에게 소프트웨어 아키텍처의 본질은 무엇이며 소프트웨어를 디자인하는 종합예술가인 아키텍트가 어떻게 실무를 하는지에 대해 우리가 쉽게 접할 수 있는 정보 시스템을 기반으로 풍부한 예제와 깊이 있는 내용을 제공한다. 이전에 출간된 아키텍처 서적에서 언제나 갈구하던 ’실용성’을 갖추기 위한 저자들의 노력이 매우 돋보이는 책이다. 책을 읽다 보면 “아키텍트가 할 업무를 이렇게 명확하게 알려주는 책이 또 있을까?”라는 생각이 들 것이다.

이 책에서 다루는 내용

■ 이해관계자들의 다양한 요구를 반영해 균형 잡힌 아키텍처를 설계하고 설명하는 방법
■ 성능, 복원성, 지역성 등 간과하기 쉬운 영역을 비롯해 아키텍처적으로 중요한 설계적 측면에 초점을 맞추는 방법
■ 시나리오와 패턴을 활용해 아키텍처를 만들고 검증하는 방법
■ 연관된 뷰들을 묶어서 아키텍처를 문서화하는 방법
■ 시스템과 주위 환경 사이의 상호작용을 문서화하는 ‘시스템 맥락 시점’
■ 아키텍처 원칙에 대한 논의를 확장한, 아키텍처 의사결정에 대한 추적용이성과 근거를 제공하는 방법
■ 애자일 개발과 아키텍처를 융합할 수 있는 방안
■ 과제 맥락 내에서 요건과 아키텍처 활동의 위치 선정
■ 아키텍처 검증을 위한 가볍고 새로운 방법론

이 책의 대상 독자

이 책은 분명히 기성 소프트웨어 아키텍트와 소프트웨어 아키텍트 지망생이 관심을 보일 만한 책이다. 이 책에는 이미 친숙한 개념도 많지만 아직 낯선 개념도 다수 담겨 있다. 이 책을 통해 아키텍트의 역할을 명확히 설명하고 역할의 경계를 분명히 하며 독자들의 업무 방식이 개선되기를 기대해본다. 경력이 많은 아키텍트라면 일상적인 업무에서 3부와 4부에 담긴 정보를 참고용으로 활용하기에 유용하리라 본다.

또한 이 책에는 아키텍처 이해관계자들이 관심을 보일 만한 부분도 있다. 시스템 개발 과제에서 요구하는 쪽 입장으로 아키텍트와 협업하는 후원자와 고위 관리자라면 1부 전체, (각각 시점과 관점을 다루는) 3부와 4부의 도입장, 5부를 읽어보면 좋다.

소프트웨어 개발자(특히 설계자)와 지원 및 유지보수 인력도 이 책에서 유용한 자료를 많이 얻을 수 있을 텐데, 주로 3부와 4부를 집중해서 살펴보면 흥미를 끌 만한 아키텍처 정의 프로세스상의 여러 측면을 더 잘 이해할 수 있을 것이다.

이 책의 구성

1부에서는 책 전체에서 사용되는 기본적인 개념인 이해관계자, 아키텍처 문서, 시점, 뷰, 관점을 소개 및 검토하고 소프트웨어 아키텍트의 역할을 설명한다.

2부에서는 아키텍트로서 해야 하는 가장 중요한 활동인 과제 범위 합의, 이해관계자 식별 및 참여, 시나리오 및 패턴 활용, 모델 생성, 아키텍처 문서화 및 검증 같은 작업을 설명한다.

3부에서는 아키텍처 문서를 만들 때 쓰이는 가장 중요한 맥락, 기능, 정보, 동시성, 개발, 배치, 운영의 7가지 시점을 차례로 설명한다.

4부에서는 정보 시스템 관점 중에서 가장 중요한 보안, 성능 및 확장용이성, 가용성 및 복원성, 진화, 위치, 개발 자원, 국제화 관점을 차례로 설명한다.

5부에서는 이 모든 개념을 모아서 실무에 적용할 때 쓸 방안을 설명한다.

저자/역자 소개

저자 서문

이 책의 초판을 집필하던 10년 전과 비교하면 IT 업계의 지형이 엄청나게 달라졌습니다. 세상은 한결 더 연결된 공간이 됐고, 컴퓨터와 인터넷이 집에서나 일터에서나 많은 이들의 일상적인 삶에서 큰 부분을 차지하게 됐습니다. 이로 인해 사용자들과 이해관계자들 사이에서 시스템 기능이 풍부하고 완결되며, 사용하기 편하고 탄탄하며 확장하고 쉽고 안전하기를 기대하는 정도가 훨씬 더 커졌습니다. 우리는 아키텍트가 이런 목표를 이루는 데 중요한 역할을 담당하고 있다고 느낄 뿐 아니라 이런 시각이 소프트웨어 개발 전문가들과 고위 사업 책임자 및 기술 책임자들 사이에서 상당히 널리 수용되고 있다는 사실에 힘이 났습니다.

1판에 보내준 실무자들과 아키텍트 지망생들과 학계의 긍정적인 반응에 많이 고무됐습니다. 이 책의 독자들이 유용하고 빈틈없으며 정보가 가득하다고 여긴다고 생각했습니다. 하지만 아키텍처는 끊임없이 변하는 분야인 터라, 2판에는 1판을 출간한 뒤에 우리가 실무에서 갈고 닦은 성과를 반영해 넣었습니다. 더불어 독자들이 보내준 매우 유용한 의견과 제안도 많이 넣었는데, 이 부분이 특히나 만족스럽습니다.

하지만 원래 전하고자 했던 근본적인 메시지는 변함이 없습니다. 가장 초점을 뒀던 부분은 이해관계자를 위한 서비스로서의 아키텍처와 정보 시스템이 이해관계자의 요구를 충족시켰는지 확인할 방법이었습니다. 이해관계자가 이해할 수 있는 방식으로 아키텍처의 복잡성을 나타내기 위한 방편으로서 뷰의 본원적 중요성을 강조하는 것 역시 변함이 없습니다. 또한 시스템이 정적인 구조와 동적인 구조를 정의하는 작업은 물론이고 확장용이성, 복원성, 보안성 같은 요구된 품질 속성을 어떤 식으로 제공할지 정의하는 작업을 아키텍처를 통해 해야 한다는 믿음과, 관점이 이런 작업을 하는 데 있어서 매우 효과적이라는 신념에도 전혀 변함이 없습니다.
이 책은 아키텍트 수련생이나 지망생을 주된 독자층으로 잡았지만, 그 밖에도 아키텍트와 함께 작업하는 다른 정보기술 전문가나 언젠가 아키텍트 자리에 있는 자신을 발견할지도 모를 학생들도 읽어보면 쓸모가 있으리라 봅니다.

개정2판에서 주로 바뀐 내용은 다음과 같습니다.

■ 맥락 시점이라는 새로운 시점을 추가했습니다. 맥락 시점에서는 시스템과 주변 환경(시스템이 상호작용하는 사람, 시스템, 외부 개체 등) 사이의 관계, 의존성, 상호작용을 설명합니다. 1판의 8장에서 비교적 짧게 설명했던 범위와 맥락에 관한 설명을 확장하고 정규화 및 표준화해놓았습니다.
■ 2부에서 아키텍처 역할의 다른 측면에 대한 논의를 확장해놓았습니다.
■ 기존의 시점 및 관점 정의를 거의 대부분 재검토했고, 특히 기능 및 동시성 뷰와 성능 및 확장용이성 관점을 다시 정리했습니다.
■ 대부분의 장에서 참고문헌과 ‘더 읽을거리’ 절을 재검토하고 확장했습니다.
■ (IEEE 1471 표준을 승계한) 새로운 국제 아키텍처 표준인 ISO 42010에 나오는 개념과 용어에 맞춰 내용을 갱신했습니다.
■ UML 2.0에 들어간 변경 내용을 반영해 UML 모델링 조언과 예제를 갱신했습니다.

이 개정판이 1판을 좀 더 쓸모 있게 개선하고 확장한 결과임을 알아주길 바라며, 소프트웨어 아키텍처 관련 추가 자료를 살펴보거나 이 책에 대한 의견을 개진하기 위해 연락하고 싶은 분들은 우리 웹사이트 www.viewpoints-and-perspectives.info를 찾아주기 바랍니다.

저자 소개

닉 로잔스키 (Nick Rozanski)

영국 대형 은행의 정보기술 부서에 재직하면서 대고객 업무용 기능을 담당하는 아키텍트로 일하고 있다. 부서 차원에서 시스템의 전체적인 모습을 조망하고 핵심 시스템 및 과제에 아키텍처적인 지침을 내리고 지원하는 업무를 한다. 부서에서 만든 아키텍처 명세서 중에서 일부는 본인이 직접 작성했는데, 그 과정에서 이 책에 설명한 온갖 종류의 뷰를 만들고 거의 모든 관점의 관심사항을 처리하는 경험을 했다.

1980년부터 정보기술에 몸담으면서 로지카(Logica), 캡제미니(Capgemini), 사이베이스(Sybase) 같은 크고 작은 시스템 통합 회사와 막스앤스펜서(Marks and Spencer), 바클레이 글로벌 투자(Barclays Global Investors) 같은 최종 사용자 조직을 거쳤다. 또한 금융, 소비, 제조, 공공 등 광범위한 영역의 프로그램에서 고참 역할을 맡아왔다. 기술적으로는 전사적 애플리케이션 통합EAI, 패키지 구현, 관계형 데이터베이스, 데이터 복제, 객체지향 소프트웨어 개발을 배경으로 한다. 또한 숙련된 기술 강사이자 공인받은 내부 과제 감사이기도 하다.

영국의 캠브리지 대학교와 맨체스터 대학교를 나왔다. 영국 공인기술사이자 영국 컴퓨터 협회(British Computer Society) 공인 회원이기도 하다.

오언 우즈 (Eoin Woods)

유럽 대형 투자 회사의 자본 기술 그룹에서 선임 시스템 아키텍트로 있으면서 회사 내 여러 핵심 시스템의 아키텍처와 설계 책임을 맡고 있다. 1990년부터 소프트웨어 공학 분야에 종사하면서 여러 기술 기업, 컨설팅 회사, 금융 서비스 회사를 거쳤다.

시스템 제공 수명주기 전체에 걸쳐 업무를 경험했고 응용 연구, 서버 제품 개발, 대규모 정보 시스템 구현 과제를 이끌었다. 주로 관심을 두는 전문 영역은 소프트웨어 아키텍처, 분산 시스템, 컴퓨터 보안, 데이터 관리 분야다.

브루넬 대학교와 맨체스터 대학교에서 소프트웨어 공학으로 학사 학위와 석사 학위를 받았다. 영국 공학기술학회(Institution of Engineering and Technology)의 정식 회원이고 영국 공인기술사이자 영국 컴퓨터 학회 공인 회원이다.

역자 서문

소프트웨어 아키텍처라는 것에 매력을 느끼는 개발자라면, 유능한 소프트웨어 아키텍트가 돼서 훌륭한 소프트웨어 아키텍처를 갖춘 위대한 시스템을 만들고 싶다는 포부를 한 번씩은 품어봤으리라 생각합니다. 저희들도 그렇습니다. 그래서 일에서는 물론이고 일상에서도 대상의 본질적 가치를 꿰뚫어보고, 한 가지 측면만 바라보기보다는 여러 측면에서 살피며, 무언가 얻는 것이 있다면 잃는 것도 반드시 생기게 마련이니 균형점을 찾아서 올바른 절충을 해내기 위해 노력하는 자세를 견지하게 됩니다.

정보기술 시스템을 중심으로 한 소프트웨어 아키텍처를 수립하는 방법을 다룬 이 책을 번역해서 세상에 내놓는 일도 마찬가지였습니다. 소프트웨어 시스템의 아키텍처 설계에 관심이 있는 독자들에게 이 책이 제공할 수 있는 본질적인 가치가 무엇인지 파악하고, 그들이 좀 더 쉽고 편하고 깊이 있게 그 본질적 가치를 향유할 수 있도록 번역하는 일 또한 어찌 보면 아키텍트의 자질을 발휘하고 능력을 쌓는 일과 근본적인 차이는 없어 보입니다.

하지만 이 책을 내는 작업에 있어서 아키텍팅architecting은 그다지 성공적이지 못했습니다. “아키텍처 명세서를 만드는 목적은 그 문서를 사용하는 이들의 요구를 충족하는 데 있지, 시스템 이해관계자에게 전혀 실질적 혜택을 주지 못하면서도 엄청나게 많은 자원을 쏟아야 완성할 수 있는 완벽한 문서를 만들고자 노력하는 데 있지 않다.” 이 책 7장, ‘아키텍처 정의 프로세스’ 부분에 나오는 이야기입니다. 아키텍처 명세서를 만드는 일을 이 책을 펴내는 일과 비유해본다면, 저희 역자들이 지난 ‘몇 년’간 다들 엄청나게 많은 시간과 노력을 쏟으며 번역 작업에 매달렸음에도, 그만큼 출간이 지연되면서 이 책에 관심 있는 이해관계자들에게는 실질적 혜택을 전혀 주지 못했으니 말입니다.

기왕 시작했으니, 비유를 좀 더 끌고가 보겠습니다. 이 책의 출간 작업과 관련한 이해관계자를 살펴보면, 최종 사용자인 잠재적인 독자들과, 이 책을 낼 수 있도록 후원해주는 출판사, 이 책의 원 저자들이 있습니다. 저마다 다른 관심사항을 가지고 저희 역자들에게 요구와 기대와 압박을 전합니다. 더불어, 저희 역자들 스스로가 (매우 비중 있는) 이해관계자들입니다. 그리고 마치 같은 시스템을 개발하는 개발자들이 저마다의 처지와 입장에 따라 관심사와 욕구가 다르듯, 당연히 저희 역자들 역시 저마다 다양한 입장과 의견을 지닙니다. 또한 해당 전문 분야의 실무자들이 투박한 번역 솜씨로 옮겨 펴내는 전문서적들에 대해 신랄하게 비판하는 서평자들도 비중 있는 (또는 치명적인) 이해관계자로 존재합니다. 그리고 이 책이 출간된 후에 나올 여타 소프트웨어 아키텍처 번역서의 역자들과 독자들 또한 무시할 수 없는 간접적인 이해관계자입니다.

이런 이해관계자들을 꼽아보고, 저마다 다른 관심사와 요구를 조율해 원래 목표했던 가치를 끌어내는 작업은, 그 자체로 아키텍팅이라 할 수 있습니다. 하지만 그 일은 녹록지 않았으며, 그중에서도 가장 큰 어려움은 저희 아키텍트들의(그리고 곧 개발자들의) 부족한 역량과 일천한 경험이었습니다. 문장을 하나씩 옮기면서 기능적인, 아니 내용적인 부분을 만족시키는 것은 기본적인 가치로서, 노력과 성실성이 주로 필요한 부분입니다. 하지만 총 30개 장에 걸쳐 무려 원서 700페이지에 육박하는 분량으로 서술된, 소프트웨어 아키텍처 기본 개념, 이해관계자 파악, 아키텍처 정의, 아키텍처 평가 등의 프로세스 전체와, 각각의 뷰, 시점, 관점들을 하나하나 상세히 소개하는 방대한 한 권의 책을 용어와 내용, 문장과 문체가 일관되고 잘 읽히게 만드는 일은 여간 어려운 작업이 아니었습니다. 더욱이 셋이 함께 작업하는 일이라, 버전 관리와 산출물 통합 또한 신경 써야 했습니다.

특히나, 역자들이 평소에 고민했던, 영어 음독 표기로 점철된 소프트웨어 아키텍처와 소프트웨어 공학 분야의 각종 개념어와 전문용어를 되도록 친근한 우리말로 바꿔서 쓰는, 국어 순화라는 까다로운 품질 속성도 일을 더 어렵게 만드는 요인이었습니다. 가령, 업계에서는 ‘트레이드오프tradeoff’라는 개념을 매우 즐겨 사용합니다. 이 개념은 한 가지 이득을 얻고자 무언가를 선택하면 다른 뭔가에서 손해를 보는 상황 또는 그 상황에서의 선택 행위를 말하는 것으로, 서로 상충하는 품질 속성들 중에서 더 어렵고 더 중요한 것을 얻기 위해 덜 어렵고 덜 중요한 것을 포기, 타협, 교환하는 행위를 가리킬 때 주로 쓰입니다. 예전에 『소프트웨어 아키텍처: 이론과 실제』(2판)을 번역해서 낼 때는 별다른 대안을 생각해내지 못해 그냥 음차를 해서 ‘트레이드오프’라고 옮겨 적으며 아쉬움이 컸습니다. 이 책도 소프트웨어 아키텍처를 전방위적으로, 그리고 동시에 매우 깊이 있게 다루기 때문에 ‘트레이드오프’에 대한 언급이 매우 많이 등장하는 터라, 지난 번의 아쉬움을 극복하기 위해 ‘교환’, ‘등가교환’, ‘타협’, ‘절충’ 등을 두고 매우 오래 고심하다가결국 ‘절충’이라는 용어를 선택했지만 그 이후에도 고민은 끊이지 않았습니다.

이렇게 부족한 능력과 경험에도 불구하고, 매우 다양한 이해관계자가 개입해 있는 데다가 방대한 분량의 시스템에 매우 까다로운 품질 요구와 목표까지 있으니, 이 책의 번역 작업은 예사롭지 않은 험난한 과정의 연속이었습니다. 이미 벌인 일인지라 오기도 생기고 포기할 수도 없으니, 결국 납기가 마구 ‘희생’되는 것으로(절충이 아니라) 귀결됩니다. 이는 소프트웨어 시스템도 마찬가지여서, 제대로 절충을 하지 않으면, 원치 않는 무언가가 희생되고 맙니다. 그나마 다행인 것은 이 책이 단기적인 유행을 타는, 그래서 한두 해 지나면 의미가 퇴색되는 그런 책이 아니라 (적어도 다음 판이 나오기 전까지는) 쭉 가치를 빛낼 내용을 담고 있다는 점입니다. 역자들로서는, ‘실질적 혜택을 주지 못하면서 끝없는 노력과 시간을 쏟아야 완성할 수 있는 완벽한 문서를 추구하는’ 우매함을 깨우쳐 이 책을 드디어 펴낼 수 있게 된 것만으로도, 긴 시간 한결같은 가치를 발휘할 이 책의 편린을 맛본 셈이라 하겠습니다. 독자 여러분도 이 책을 통해 큰 가치를 찾아내기를 기원합니다.

이처럼 긴 시간이 걸려 번역돼 나온 이 책의 특장점이라면, 역시나 균형과 절충의 미덕이 담겨 있다는 점입니다. 소프트웨어 아키텍처 이론 위주의 서적을 읽을 때면 구체적인 사례가 부족해 소프트웨어 개발과 유지 보수에 적용하기에는 왠지 어려울 것 같은 공허함을 느끼기 쉽습니다. 반면에 특정 도메인 아키텍처 위주의 서적을 읽을 때는 뭔가 지식 체계로 기억할 만한 중요한 이론적 체계의 부재로 인한 아쉬움을 느끼곤 합니다. 이 책은 지금까지 발표된 아키텍처 이론 중 자연스럽게 실무에 잘 활용할 수 있는 내용만 모아 실제 사례와 함께 소개하고 있어, 학계와 업계 관계자 모두에게 도움이 줄 수 있으리라 기대합니다. 소프트웨어의 상세한 세부사항보다는 ‘큰 그림’을 그리며 각 구성요소들의 전체적인 조화, 단순함, 자연스러움이 깃든 생명력이 긴 명품 소프트웨어를 만들고자 하는 분들께 이 책을 추천해드리고 싶습니다.

역자 소개

송재하

성균관대학교 국어국문과를 다니면서 프로그래머가 되겠다고 마음먹은 후, 패키지 SW, SI 시스템, 분산 미들웨어 엔진,모바일 서비스 등을 두루 거치며 개발 경험을 쌓았다. 이후에는 소프트웨어 아키텍트의 길을 가기로 결심하고, 한국과학기술원 공학석사와 카네기멜론대학 소프트웨어공학 석사과정(MSE)을 졸업한 뒤, 엔씨소프트의 오픈마루 스튜디오에서 대용량 데이터처리팀을 맡아 웹 데이터 처리 인프라를 구축하고, 그를 바탕으로 MMORPG의 게임 로그를 처리해 확장된 게임 서비스 경험을 제공하는 시스템을 아키텍팅하고 구축했다. 현재 SK플래닛에서 다양한 생활 밀착형 서비스에서 풍부한 사용자 로그를 모아 확장된 생활 경험을 제공하기 위한 데이터 인프라스트럭처를 구축하면서 아키텍팅 역량을 다듬고 있다. 에이콘출판사에서 출간한 『소프트웨어 아키텍처: 이론과 실제』(2007)와 『소프트웨어 아키텍처 문서화』(2009)를 공역했다.

금창섭

카네기멜론대학에서 소프트웨어 공학 석사과정(MSE)을 졸업하고 한국과학기술원에서 소프트웨어 아키텍처 및 테스팅 분야를 연구해 박사학위를 받았다. 1994년 한국전자통신연구원에 입사하여 SDL 설계 자동화 도구, 객체지향 CHILL 컴파일러 등의 시스템 소프트웨어 개발했고, 소프트스위치, 개방형 서비스 게이트웨어, 융합서비스플랫폼을 아키텍팅했다. 현재는 연구실장으로 재직 하면서 5G 모바일 엣지 컴퓨팅 기술의 연구개발을 수행하고 있다. ‘인생은 속도가 아니라 방향’이라는 생각으로 소프트웨어 아키텍트의 의지를 이어가고 있다.

박미율

덕성여자대학교에서 전산학을 전공하고 한국과학기술원 공학석사와 카네기멜론대학 소프트웨어공학 석사과정(MSIT-SE)을 졸업했다. 주 관심분야는 소프트웨어 아키텍처, 빅데이터 인프라 구축 및 분석, 소프트웨어 개발방법론이다. 빅데이터 로그분석, 호 데이터처리, 디지털 사이니지, 임베디드 등의 분야에서 소프트웨어를 개발했으며, SQA, PMO, 아키텍트 등의 업무를 두루 거쳤다. 지식을 나누는 일에 보람을 느끼며, 소프트웨어 개발에 있어 아키텍처가 얼마나 훌륭한 의사소통 도구인지 공유하고자 번역에 참여했다. 현재 KT에서 빅데이터 인프라 설계 업무를 하고 있다. 에이콘출판사에서 출간한 『소프트웨어 아키텍처: 이론과 실제』(2007)와 『소프트웨어 아키텍처 문서화』(2009)를 공역했다.

목차

목차
  • __1장. 들어가며
  • ____이해관계자, 시점, 관점
  • ____이 책의 구성
  • ____이 책의 대상 독자
  • ____편집 관례

  • 1부. 아키텍처 기초
  • __2장. 소프트웨어 아키텍처 기본 개념
  • ____소프트웨어 아키텍처
  • ____아키텍처 요소
  • ____이해관계자
  • ____아키텍처 명세서
  • ____핵심 개념 사이의 관계
  • ____정리
  • ____더 읽을거리
  • __3장. 시점과 뷰
  • ____아키텍처 뷰
  • ____시점
  • ____핵심 개념 간의 관계
  • ____시점과 뷰를 사용하는 이점
  • ____시점의 함정
  • ____시점 목록
  • ____정리
  • ____더 읽을거리
  • __4장. 아키텍처 관점
  • ____품질 속성
  • ____아키텍처 관점
  • ____뷰에 관점 적용
  • ____관점 적용 결과
  • ____핵심 개념 사이의 관계
  • ____관점 활용에 따른 이점
  • ____관점의 함정
  • ____관점과 시점의 비교
  • ____관점 목록
  • ____정리
  • ____더 읽을거리
  • __5장. 소프트웨어 아키텍트의 역할
  • ____아키텍처 정의 프로세스
  • ____아키텍트의 역할
  • ____핵심 개념 사이의 상호관계
  • ____아키텍처 전문화
  • ____조직 맥락
  • ____아키텍트의 기량
  • ____아키텍트의 책임
  • ____정리
  • ____더 읽을거리

  • 2부. 소프트웨어 아키텍처 프로세스
  • __6장. 소프트웨어 아키텍처 정의 프로세스 소개
  • __7장. 아키텍처 정의 프로세스
  • ____핵심 원칙
  • ____프로세스 산출물
  • ____프로세스 맥락
  • ____보조 활동
  • ____아키텍처 정의 활동
  • ____프로세스 완료 조건
  • ____소프트웨어 개발 수명주기상의 아키텍처 정의
  • ____정리
  • ____더 읽을거리
  • __8장. 관심사항, 원칙, 결정
  • ____문제 중심 관심사항
  • ____해결책 중심 관심사항
  • ____기타 실무적인 제약사항
  • ____좋은 관심사항의 조건
  • ____아키텍처 원칙
  • ____아키텍처 결정사항
  • ____원칙을 활용한 관심사항과 결정사항 연결
  • ____점검 목록
  • ____정리
  • ____더 읽을거리
  • __9장. 이해관계자 파악과 유치
  • ____이해관계자 선정
  • ____이해관계자 유형
  • ____예제
  • ____대리 이해관계자
  • ____이해관계자 집단
  • ____이해관계자의 책임
  • ____점검 목록
  • ____정리
  • ____더 읽을거리
  • __10장. 시나리오 식별과 활용
  • ____시나리오의 종류
  • ____시나리오 활용
  • ____시나리오 식별 및 순위결정
  • ____시나리오 수집
  • ____좋은 시나리오의 조건
  • ____시나리오 적용
  • ____효과적인 시나리오 활용
  • ____점검 목록
  • ____정리
  • ____더 읽을거리
  • __11장. 스타일과 패턴 활용
  • ____설계 패턴
  • ____스타일, 패턴, 이디엄
  • ____패턴과 아키텍처 전술
  • ____아키텍처 스타일 예제
  • ____아키텍처 스타일 활용 시 이점
  • ____스타일과 아키텍처 설명
  • ____설계 패턴과 언어 이디엄 적용
  • ____점검 목록
  • ____정리
  • ____더 읽을거리
  • __12장. 아키텍처 모델 수립
  • ____모델의 중요성
  • ____모델의 유형
  • ____모델화 언어
  • ____효과적인 모델 도출 지침
  • ____애자일 팀에서의 모델화
  • ____점검 목록
  • ____정리
  • ____더 읽을거리
  • __13장. 아키텍처 명세서 작성
  • ____효과적인 아키텍처 명세서의 속성
  • ____용어집
  • ____ISO 표준
  • ____아키텍처 설명 내용
  • ____아키텍처 설명 제시
  • ____점검 목록
  • ____정리
  • ____더 읽을거리
  • __14장. 아키텍처 평가
  • ____아키텍처 평가 필요성
  • ____평가 기법
  • ____시나리오 기반 평가 기법
  • ____소프트웨어 수명주기 중의 평가
  • ____기존 시스템의 아키텍처 검증
  • ____평가 결과 기록
  • ____평가 접근법 선택
  • ____점검 목록
  • ____정리
  • ____더 읽을거리

  • 3부. 시점 목록
  • __15장. 시점 목록 소개
  • __16장. 맥락 시점
  • ____관심사항
  • ____모델
  • ____문제점 및 함정
  • ____점검 목록
  • ____더 읽을거리
  • __17장. 기능 시점
  • ____관심사항
  • ____모델
  • ____문제점 및 함정
  • ____점검 목록
  • ____더 읽을거리
  • __18장. 정보 시점
  • ____관심사항
  • ____모델
  • ____문제점 및 함정
  • ____점검 목록
  • ____더 읽을거리
  • __19장. 동시성 시점
  • ____관심사항
  • ____모델
  • ____문제점 및 함정
  • ____점검 목록
  • ____더 읽을거리
  • __20장. 개발 시점
  • ____관심사항
  • ____모델
  • ____문제점 및 함정
  • ____점검 목록
  • ____더 읽을거리
  • __21장. 배치 시점
  • ____관심사항
  • ____모델
  • ____문제점 및 함정
  • ____점검 목록
  • ____더 읽을거리
  • __22장. 운영 시점
  • ____관심사항
  • ____모델
  • ____문제점 및 함정
  • ____점검 목록
  • ____더 읽을거리
  • __23장. 여러 뷰 사이의 일관성 확보
  • ____뷰 사이의 관계성
  • ____맥락 뷰와 기능 뷰 일관성
  • ____맥락 뷰와 정보 뷰 일관성
  • ____맥락 뷰와 배치 뷰 일관성
  • ____기능 뷰와 정보 뷰 일관성
  • ____기능 뷰와 동시성 뷰 일관성
  • ____기능 뷰와 개발 뷰 일관성
  • ____기능 뷰와 배치 뷰 일관성
  • ____기능 뷰와 운영 뷰 일관성
  • ____정보 뷰와 동시성 뷰 일관성
  • ____정보 뷰와 개발 뷰 일관성
  • ____정보 뷰와 배치 뷰 일관성
  • ____정보 뷰와 운영 뷰 일관성
  • ____동시성 뷰와 개발 뷰 일관성
  • ____동시성 뷰와 개발 뷰 일관성
  • ____배치 뷰와 운영 뷰 일관성

  • 4부. 관점 목록
  • __24장. 관점 목록 소개
  • __25장. 보안성 관점
  • ____뷰 적용성
  • ____관심사항
  • ____활동: 보안성 관점 적용
  • ____아키텍처 전술
  • ____문제점 및 함정
  • ____점검 목록
  • ____더 읽을거리
  • __26장. 성능 및 확장용이성 관점
  • ____뷰 적용성
  • ____관심사항
  • ____활동: 성능 및 확장용이성 관점 작용
  • ____아키텍처 전술
  • ____문제점 및 함정
  • ____점검 목록
  • ____더 읽을거리
  • __27장. 가용성 및 복원성 관점
  • ____뷰 적용성
  • ____관심사항
  • ____활동: 가용성 및 복원성 관점 적용
  • ____아키텍처 전술
  • ____문제점 및 함정
  • ____점검 목록
  • ____더 읽을거리
  • __28장. 진화성 관점
  • ____뷰 적용성
  • ____관심사항
  • ____활동: 진화성 관점 적용
  • ____아키텍처 전술
  • ____문제점 및 함정
  • ____점검 목록
  • ____더 읽을거리
  • __29장. 그 밖의 관점
  • ____접근성 관점
  • ____활동: 접근성 관점 적용
  • ____개발 자원 관점
  • ____국제화 관점
  • ____위치 관점
  • ____규제 관점
  • ____사용편의성 관점

  • 5부. 총정리
  • __30장. 소프트웨어 아키텍트로 일하기
  • ____과제 수명주기상에서의 아키텍처
  • ____다른 유형의 과제 지원
  • __A. 그 밖의 시점들
  • ____크루첸 ‘4+1’
  • ____RM-ODP
  • ____지멘스(호프마이스터, 노드, 소니)
  • ____SEI ‘뷰와 그 이상’ 뷰
  • ____갈런드와 앤서니
  • ____IAF
  • ____전사적 아키텍처 프레임워크
  • ____그 밖의 전사적 아키텍처 프레임워크

도서 오류 신고

도서 오류 신고

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

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

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