제9회 JOLT상 수상작

소프트웨어 아키텍트는 물론, 아키텍트를 꿈꾸는 개발자, 대학생도 꼭 읽어야 할 아키텍처 바이블!
소프트웨어 엔지니어링의 패러다임을 바꾸고 있는 소프트웨어 아키텍처의 이론과 개념, 풍부한 베스트 프랙티스가 담겨 있다.

카네기멜론大와 소프트웨어 공학 연구소 SEI가 채택한 교육 교재
정보통신부와 한국소프트웨어진흥원이 선정한 아키텍트 교육과정 주교재

다년간의 연구 내용과 현장 경험이 면밀히 녹아있는 소프트웨어 아키텍처의 필독서

[ 책 소개 ]

『소프트웨어 아키텍처: 이론과 실제』는 소프트웨어 아키텍처의 개념을 명확하게 소개하고 있을 뿐만 아니라, 현장의 다양한 실무 사례를 소개한다. 소프트웨어 개발과 관련한 여러 상을 수상한 이 책은 현장의 실무자들에게 매우 유용한 소프트웨어 아키텍처의 지침서로 정평이 높다. 개정판인 이 책은 개발 프로젝트에서의 최근 소프트웨어 아키텍처의 트렌드와 실무사례를 반영하고 있다. 특히 소프트웨어 시스템을 좋은 구조로 설계하는 방법과 시스템의 구성요소들이 상호 작용할 때 어떤 역할을 해야 하는지 상세히 소개한다.

시스템 품질을 달성하기 위해서는 상세 구현이나 알고리즘, 데이터 모델링 등이 필수적이다. 그러나 이들과 소프트웨어 아키텍처는 명백히 별개의 것으로 구분된다. 특히 소프트웨어 아키텍처는 시스템 품질을 달성하는 핵심 역할을 한다. 또한 소프트웨어 아키텍처는 다른 시스템에 적용 가능한 재사용 자산으로 활용될 수 있으며 비즈니스 조직이 전략을 수립하고 실행하는 데 중요한 역할을 한다.

이 책의 저자들은 자신들의 다양하고 깊이 있는 실무 경험을 활용해 소프트웨어 시스템의 설계, 명세, 확인 작업 등 핵심 기술을 다룬다. 특히 대형 시스템을 설계할 때 비즈니스 상황의 중요성 또한 놓치지 않는다. 회사가 당면할 수 있는 비즈니스 기회와 기술적, 경영적 제약사항 모두를 고려해 실제 환경에서 구현할 수 있는 최적의 소프트웨어 아키텍처를 제시한다. 각 부의 마지막 장에서는 실무에서의 아키텍처 사례 연구를 설명하고 있으며, 각 장의 마지막에는 기술뿐만 아니라 조직적인 측면까지 고려한 다양한 토론 문제를 제시한다.


[ 이 책에서 다루는 내용 ]

♦ 아키텍처 설계 및 ATAM 기법을 활용한 아키텍처 평가 분석 방법
♦ 품질 요구사항 수집, 품질 시나리오 설계, 아키텍처 설계 전술을 활용한 품질 요구사항의 달성 방법
♦ 문서화되지 않은 시스템 아키텍처를 복구하기 위한 아키텍처 재건 방법
♦ 웹 기반 시스템에서의 아키텍처 설계 사례와 착용식 컴퓨터(Wearable Computer)를 지원하기 위해 설계된 무선 기반 엔터프라이즈 자바빈즈(EJB) 시스템 사례 등 새로운 아키텍처 적용 사례 연구
♦ 경영진의 의사결정을 지원하는 아키텍처의 재무적 분석 방법(CBAM) 활용 사례

대형 소프트웨어 시스템의 설계, 개발, 관리, 기획 업무를 담당하고 있거나, 대형 소프트웨어 시스템을 획득/구매하려 한다면, 최신 소프트웨어 아키텍처 기술을 담고 있는 『소프트웨어 아키텍처: 이론과 실제』는 유용한 길잡이가 되어 줄 것이다.


[ 이 책의 독자층 ]

소프트웨어 공학에 지식과 경험이 있는 소프트웨어 전문가나 학생을 대상으로 한다.

♦ 아키텍처에 대한 기술적인 배경과 함께 거기에 작용하는 업무적, 조직적 상황과 요구사항, 영향력에 대해 이해하고자 하는 소프트웨어 공학 교육생
♦ 소프트웨어 아키텍처를 통해 시스템 구축 업무를 좀더 효과적으로 감독하고 조직을 개선시킬 수 있는 방법을 배우고자 하는 기술 관리자들
♦ 학부나 대학원의 소프트웨어 공학 과정에서 이 책을 학습 자료로 활용하고자 하는 전산과나 소프트웨어 공학과 학생


[ 이 책의 구성 ]

아키텍처 비즈니스 사이클(ABC, Architecture Business Cycle)이라고 부르는 아키텍처 생명주기 관점에 따라 총 4부로 구성돼 있다.

♦ 아키텍처 개요 (1장~3장)
♦ 아키텍처 수립 (4장~10장)
♦ 아키텍처 분석 (11장~13장)
♦ 아키텍처 확산 (14장~19장)

사례 연구의 구성 방식

♦ 사례 연구에 대한 개요, 당면 과제, 해당 소프트웨어 아키텍처의 요점
♦ 아키텍처 비즈니스 사이클 적용
♦ 시스템의 요구사항과 품질 목표
♦ 아키텍처 해결방안
♦ 각 장의 핵심 내용 요약


[ 추천의 글 ]

이 책은 소프트웨어 아키텍처의 개념을 설명하고 소프트웨어 아키텍처 수립 방법을 소개합니다. 또한 소프트웨어 아키텍처의 가치를 보여주는 실무 사례를 포함하여 실무자들에게 보다 확실한 소프트웨어 아키텍처의 가치를 심어줍니다. 이 책은 소프트웨어 아키텍트가 되려는 분들에게 소프트웨어 아키텍처의 개념과 수립 방법의 훌륭한 지침서가 될 것입니다. SKC&C는 소프트웨어 아키텍처 아키텍트 양성 과정에 이 책을 기본 교과서로 교육을 진행하고 있으며, 교육생 상당수가 이 책을 통해 새로운 소프트웨어 아키텍처의 개념을 습득하고 소프트웨어 아키텍트로 실무에서 활동하고 있습니다.

이 책의 우수성에 비해 국내 번역서가 없어 실무자들이 원서를 봐야 하는 어려움이 있었습니다. 국내에 소개된 지 얼마 안되었고 소프트웨어 아키텍처 개념도 생소했으며 결코 내용이 쉽지 않은 책이었던지라 정확한 번역본을 만들 수 없었기 때문입니다. 하지만 이 책의 대표 역자인 SKC&C 김정호 아키텍트를 비롯해 번역자 대부분이 미국 현지에서 이 책으로 소프트웨어 아키텍처 교육을 받은 분들이고, 또한 실무에서 아키텍트로 직접 활동을 하는 분들이어서 누구보다 열심히 그리고 정확한 번역해냈을 것이라 믿습니다. 이 책이 소프트웨어 아키텍처에 관심이 있고 아키텍트의 길을 가고자 하는 분들의 훌륭한 길잡이가 될 것입니다. 이 책을 읽는 모든 독자들의 건승을 기원합니다.



이 책은 소프트웨어 아키텍트의 역량 강화를 위해 교육 및 실무에서 활용할 수 있는 체계적인 지침을 제공합니다. 미국 카네기멜론 대학 내 소프트웨어공학연구소(SEI)의 전문 연구위원들이 수년간 연구하고 현장에서 검증한 내용을 기반으로 집필하였으며, 전세계적으로 소프트웨어 아키텍처의 필독서로 손꼽히고 있습니다. 이번에 다양한 현장에서 소프트웨어 아키텍트 역할을 전문적으로 수행하고 있는 실무 베테랑들이 원서의 깊은 이해와 현장 적용 경험을 바탕으로 정확한 번역서를 출간하게 되었으니, 국내 전문 소프트웨어 아키텍트 양성에 큰 기여를 할 것으로 기대합니다.



이 책은 미국 소프트웨어 공학 연구소(SEI) 전문 연구위원들의 다양한 현장 경험과 연구를 바탕으로 정리되었고, 산업계 프로젝트에 적용된 다수의 사례를 제시하고 있어서, 소프트웨어 아키텍처의 실체를 파악하는 데 많은 도움이 될 것입니다. 미국의 IT 업계에서 소프트웨어 엔지니어 필독서로 추천되고 있는 것은 이러한 효용성을 뒷받침하고 있다 하겠습니다. 특히 소프트웨어 아키텍트라는 아직은 생소한 전문 분야로 첫 걸음을 내딛는 실무자들에게 체계적인 개념을 정립하고 업무에 적용할 수 있도록 가이드를 제공해주는 유용한 지도서라고 여겨집니다.

이 책의 번역을 맡은 역자들은 소프트웨어 아키텍트로서 우리나라 개발 실무 현장에서 다년간 실무 프로젝트에 참여한 경험이 있으며, 한국정보통신대학교(ICU)-카네기멜론대학교(CMU)의 MSE과정에서 저자들의 강의를 미국에서 직접 수강하면서 스튜디오 프로젝트를 통하여 이 책의 이론을 실증적으로 검증한 바 있습니다. 따라서 저자들의 의도를 충분히 이해하고, 이를 바탕으로 번역서가 나왔다는 것은 언어 장벽이나 원문의 난해함 때문에 손쉽게 책을 읽지 못했던 소프트웨어 엔지니어들에게 매우 반가운 소식입니다.

아무쪼록 이 책을 읽은 독자들이 소프트웨어 아키텍처를 손쉽게 이해하고 이를 바탕으로 각자의 현장 업무를 적용해서 시스템을 성공적으로 구축해나가기를 바랍니다.

[ 저자 서문 ]

애플리케이션이나 시스템의 규모가 커지고 복잡해지면서 아키텍처의 중요성이 점점 더 커지고 있고, 관련 논의도 매우 활발히 진행되고 있다. 이에 따라 소프트웨어 아키텍처는 매우 중요한 연구분야로 자리잡은 상태이다. 그럼에도 실제 소프트웨어 개발 조직에서 소프트웨어 아키텍처를 다루는 데 필요한 실무 안내서는 기술적인 관점에서든, 관리적인 관점에서든 아직까지 한 권도 없었다. 이 책을 집필한 동기도 소프트웨어 아키텍처가 사업 현황이나 조직 상황과 어떤 관계에 있는지 충분한 연구가 이뤄지지 않고 있다는 문제인식에서 비롯됐다.

복잡한 대규모 소프트웨어 집약 시스템을 분석하고 설계했던 오랜 경험을 통해, 사업 목표와 조직 구조가 시스템 설계는 물론 궁극적으로 시스템 성패에도 매우 중요한 영향을 미친다는 사실을 알 수 있었다. 시스템은 기본적으로 특정 조직의 요구사항(내부에서 개발하는 제품일 경우 기획을 통해 도출된 가상의 요구사항)을 충족시키기 위해 만들어진다. 요구사항에 따라 해당 시스템의 성능, 가용성, 보안, 타 시스템과의 호환성, 시스템이 운영되는 동안의 변경수용 능력과 같은 품질 목표가 결정된다. 소프트웨어를 통해 이와 같은 품질 목표를 달성하려면 그에 따른 선결요건들을 만족시켜야 하고, 이런 선결요건들이 결국 소프트웨어 아키텍트가 수행하는 설계상의 의사결정에 영향을 미치게 된다. 이 책에서는 다음과 같은 실제 프로젝트 사례를 들어 소프트웨어 아키텍처와 기업조직간의 연관관계에 대해 설명한다.

♦ 월드와이드웹의 소프트웨어 아키텍처: 최소한의 중앙집중식 통제로 문서를 쉽고 빠르게 공유하기 위해 월드와이드웹의 소프트웨어 아키텍처가 탄생했다.
♦ 항공관제 시스템의 소프트웨어 아키텍처: 항공관제 시스템에 요구되는 극도의 안전성 요구사항에 따라 초고도의 가용성(availability)을 확보할 수 있는 아키텍처를 만들었다.
♦ 비행 모의실험기의 소프트웨어 아키텍처: 지리적으로 먼 곳에 위치한 개발자들이 비행 모의실험기의 하위시스템을 나눠 맡아 개발한 후 쉽게 통합할 수 있는 아키텍처가 탄생했다.
♦ 프로덕트 라인에서의 소프트웨어 아키텍처: 여러 제품을 동시에 출시해야 했던 회사는 복잡하게 관련된 연관 소프트웨어 시스템들을 프로덕트 라인으로 구성할 수 있게 해주는 아키텍처를 수용하게 됐다(수용할 수밖에 없었다는 말이 더 맞다).
♦ J2EE 기반에서의 소프트웨어 아키텍처: 기업 조직이나 커뮤니티 차원에서 의사소통을 원활히 하기 위해 표준화된 아키텍처가 필요했고, 이런 요구사항에 따라 J2EE나 EJB와 같은 기반구조가 나오게 됐다.

이런 예들을 보면 소프트웨어 아키텍처는 당시에 주류를 이루던 설계 환경뿐 아니라 조직의 요구사항과 사업 모델, 아키텍트의 경험 등에서도 우러나온다는 사실을 알 수 있다. 이에 더해 아키텍처가 어떻게 해서 아키텍처에 영향을 준 것들에 다시 영향을 끼치는 강력한 매체가 될 수 있는지도 알아본다. 성공적인 제품이나 제품군은 향후 다른 제품이 만들어지는 방식에 많은 영향을 미친다. 월드와이드웹의 근간을 이루고 있는 소프트웨어에 대한 사례 연구가 좋은 예다. 이런 종류의 시스템이 각광받기 전에는 네트워크에 대한 인식 수준이 매우 낮았고, 데이터 접근성에 대해서도 별로 고려하지 않았으며, 보안 같은 것에 대해서는 금융 업체나 정부 조직 등 몇 군데 말고는 그다지 심각하게 고려하지 않았었다. 이 책은 대규모 소프트웨어 집약 시스템의 설계자와 구현자, 소프트웨어 전문 관리자는 물론이고 소프트웨어 전문가의 꿈을 품은 학생 등 다양한 소프트웨어 전문가들을 대상으로 한다.

필자들은 소프트웨어 아키텍처가 품질, 일정, 비용상 투자 대비 효과가 매우 높은 발명품이라 믿고 있다. 아키텍처는 제품 수명이 시작되는 시점에 등장하기 때문에 아키텍처를 제대로 설계해 놓으면 시스템 개발, 통합, 검수, 변경 등 앞으로 수행하거나 발생할 모든 작업의 토대가 마련되는 셈이다. 아키텍처를 잘못 설계했다는 말은 시스템의 구조를 잘못 짰다는 말이 된다. 따라서 구축된 시스템의 일부를 새로운 부분으로 대체하거나 이미 만든 몇 부분을 제거한다고 해서 고쳐질 수 있는 것이 아니라 전체적인 구조를 다시 짜야 하는 것이다. 또한 아키텍처는 다른 개발 활동과 비교했을 때, 분석에 소요되는 비용은 매우 저렴하다. 즉 아키텍처로 인해 내려지는 의사 결정에 따르는 파급 효과에 비해 아키텍처를 검토하고 수정하는 비용은 상대적으로 저렴하기 때문에 투자 대비 효과가 매우 높다.

소프트웨어를 효과적으로 재사용하기 위해서는 아키텍처 관점에서 접근하는 것이 가장 바람직하다고 필자들은 믿는다. 재사용 가능한 산출물로 컴포넌트만 나오는 것은 아니다. 아키텍처 자체를 재사용할 경우에는 시스템 군이 형성되는 방향으로 가게 되고 결국 새로운 조직 구조와 새로운 사업기회를 창출하게 된다.

이 책은 업무현장에서 실제 문제를 해결하는 데 사용된 아키텍처 사례를 제시하는 데 많은 분량을 할애했다. 이 사례들을 통해 당면한 품질 목표를 달성하기 위해 내려야 하는 아키텍처적 의사결정에는 어떤 것들이 있는지, 조직의 목표가 최종 시스템에 어떻게 반영되는지 살펴볼 것이다.

사례 연구와 더불어 소프트웨어 아키텍처 설계, 구축, 평가에 쓸 수 있는 여러 가지 기법도 제시하고 있다. 아키텍처 관점에서 품질 요구사항을 파악하고 그에 맞는 아키텍처를 수립할 수 있게 해 주는 기술을 제시한다. 소프트웨어 아키텍처를 기술하고 검증할 때 쓸 수 있는 아키텍처 표현 기법과 재건(reconstruction) 기법도 소개한다. 또한 설계된 아키텍처가 시스템 구축 목적에 부합되는지 분석하고 평가하는 데 활용할 수 있는 기법도 살펴본다. 이런 기법들은 모두 저자들이 SEI(Software Engineering Institute)에서 동료들과 함께 다양한 소프트웨어 시스템을 구축하면서 얻은 경험을 바탕으로 만들어졌다. 대부분 코드 크기가 수백만 줄에 이르는, 다년간 대규모 팀이 투입된 시스템들을 실 사례로 다루고 있다. 책 전반에 걸쳐 사업 현안(예를 들어 아키텍처가 조직의 시장 경쟁력에 끼치는 영향이나 제품군이 시장적시성에 끼치는 영향 등)에 대해 논의하고 있기는 하지만, 필자들은 소프트웨어 공학자이기 때문에 사업 현안이나 관련 전문용어 자체를 깊이 다루지는 않는다. 대신 기술적인 부분을 더 깊이 있게 다룬다. 이 책은 이론과 실무가 접점을 이루는 지점에 서서 소프트웨어 아키텍처 분야의 현재 성과를 소개한다. 사례 연구에서는 이런 기술적 토대를 조명하고 그것이 실무에서 어떻게 현실화되는지 보여준다. 사례 연구를 통해 알게 된 교훈을 제대로 활용하려면 컴퓨터 과학이나 소프트웨어 공학, 기타 관련 이론에 대해 어느 정도 배경지식이 있어야 한다. 그러나 각 사례의 업무영역에 대한 전문지식을 갖춰야만 이해할 수 있는 내용은 되도록 피했다. 조종사가 아니더라도 항공관제 시스템이나 비행 모의실험 사례 연구를 이해하는 데는 별 문제가 없을 것이다.

개정판에서 추가된 내용
개정판의 저술 목적이 초판과 달라진 부분은 없지만, 초판 집필 이후 시간이 흐르면서 소프트웨어 아키텍처 분야도 나날이 발전하고 있었고 주요 기반이론에 대해 새롭게 이해한 부분도 생겼다. 따라서 이번 개정판에서는 새로운 사례 연구를 추가하고 기존 내용을 강화하는 방식으로 새로운 발전경향과 이해를 반영하고자 했다. 이에 더해 초판 발행 후 『Documenting Software Architectures: Views and Beyond』(2007년 출간 예정, 에이콘출판)나 『Evaluating Software Architectures: Methods and Case Studies』, 『Software Product Lines: Principles and Practice』 등 필자들이 저술에 참여한 다른 책들이 나오면서 개정판 집필에 많은 영향을 끼쳤다. 따라서 이번 개정판에는 아키텍처 분석, 설계, 재구성, 문서화에 있어 초판 발간 시점 이후 크게 발전한 내용들이 반영됐다. 아키텍처 분석은 이제 업계에서 실무에 적용할 수 있는 기법을 갖춘 성숙한 분야로 발전했다. 개정판에서는 3부에 별도로 새로운 장을 할애해 아키텍처 분석 기법 중 하나인 아키텍처 트레이드오프 분석 방법(ATAMSM)을 소개한다. 많은 기업에서 소프트웨어 아키텍처 평가 기법으로 ATAM을 채택하고 있다.

아키텍처 설계 또한 초판 발간 이후 크게 발전했다. 품질 요구사항을 도출하는 방법, 소규모의 아키텍처 접근법인 아키텍처 설계전술이나 대규모의 아키텍처 접근법인 아키텍처 설계 패턴을 통해 품질 목표를 달성하는 방법, 이를 달성하는 데 필요한 지식을 담고 있는 설계 방법 등을 여러 장에 걸쳐 심도 있게 논의한다. 새롭게 추가된 장들에서 품질 요구사항의 이해와 품질 목표 달성, 속성위주 설계(ADD, Attribute Driven Design) 방법을 다룬다.

아키텍처 재건(아키텍처 역공학)은 문서화되지 않은 아키텍처를 찾아낼 때 반드시 하게 되는 작업이다. 아키텍처 재건은 설계 프로젝트나 분석 프로젝트의 일부분으로 활용되거나 시스템 재건 시 무엇을 기반으로 할 것인지 결정할 때 입력값으로 활용될 수 있다. 초판에서 재건 도구(Dali)를 짤막하게 소개하고, 재공학(reengineering) 시 활용법에 대해서도 간략히 언급했었는데, 개정판에서는 별도의 장을 할애해 이 주제를 다룬다.

소프트웨어 아키텍처 문서화는 최근 들어 많이 성숙해진 주제다. 초판이 출간될 즈음 UML(Unified Modeling Language)이 막 등장했었다. 현재 UML이 업계에서 다양하게 활용되고 있으므로, 이번 개정판에서는 이런 현실을 반영해 많은 부분을 UML로 표현했다. 어떤 표기법을 사용하는지보다 더 중요한 것은 시스템의 아키텍처를 파악하는 데 필요한 정보의 종류가 명확해졌다는 것이다. 이에 따라 아키텍처 문서화를 다루는 장을 추가했다. 기업조직은 단일한 소프트웨어 아키텍처를 활용해 다양한 시스템을 효율적으로 만들 수 있게 된다. 이 내용은 개정판에서 추가된 14장 ‘소프트웨어 프로덕트 라인’에서 다루고 있다. 이에 따라 14장에서는 소프트웨어 아키텍처를 기반으로 프로덕트 라인을 구축하면 비용, 품질, 시장적시성에 있어 수십 배의 향상을 이룰 수 있다는 사실에 근거해 아키텍처와 조직의 업무 목표 사이의 관계를 좀더 명확하게 설명한다.

최근 비즈니스 환경이 변하면서 소프트웨어 아키텍처의 발전과 더불어 분산이나 웹 기반 시스템 구축에 쓰이는 기술이 각광받게 됐다. 이런 추세를 반영하고자 월드와이드웹에 대한 내용(13장)을 갱신했고, ATAM 관련 장(11장)과 컴포넌트 조립을 통한 시스템 구축을 다루는 장(18장)에서 예제를 웹 기반으로 바꾸고, CORBA(Common Object Request Broker Architecture)에 대한 기존 사례 연구를 EJB(Enterprise JavaBeans)에 대한 사례 연구(16장)로 교체했다. 그리고 현장에서의 유지보수 근로자들이 사용하는 착용식 컴퓨터(wearable computer)를 지원하도록 설계된 무선 EJB 시스템에 대한 사례 연구 (17장)도 추가했다.

끝으로 아키텍처에 대한 비용적인 관점을 좀 더 면밀히 관찰하는 내용을 추가했다. 12장에서는 아키텍처적인 결정을 내릴 때 앞에서 논의한 기술적인 기준에 더해 경제적인 기준도 적용할 수 있도록 비용 이익 분석 기법(CBAM, Cost Benefit Analysis Method)을 소개한다. 초판과 마찬가지로 아키텍처 비즈니스 사이클(ABC, Architecture Business Cycle)이 책 전체 내용을 묶어주는 구심점 역할을 한다. 모든 사례 연구는 시스템 설계에 동기를 부여해 준 품질 목표가 무엇이고, 시스템의 아키텍처가 그 목표를 어떻게 달성하는지의 관점에서 설명된다. 개정판을 집필할 때도

초판과 마찬가지로 주 독자는 실무자들이라는 사실을 명심하고 있었기에, 가까운 미래에 실현할 수 있거나 이미 현장에서 유용하게 쓸 수 있다고 검증된 기술에만 초점을 맞췄다. 저자들이 이 책을 집필하면서 가졌던 보람과 즐거움을 독자들도 함께 누릴 수 있기를 바란다.


[ 저자 소개 ]

렌 베스
현재 미 SEI 연구소의 기술 분야 수석 연구원이다. 소프트웨어 공학과 관련된 책을 포함하여 6권의 책을 저술했고 수많은 논문을 발표했다. 또한 실제 프로젝트에서 아키텍처 설계를 담당하는 등 풍부한 실무 경험을 보유하고 있다.

폴 클레멘츠
현재 미 SEI 연구소에서 기술 분야의 수석 연구원으로서 소프트웨어 아키텍처와 프로덕트 라인 공학에 대해 연구하고 있다. 소프트웨어 아키텍처 분야에 대해 5권의 책을 저술했고 36편 이상의 논문을 발표했다.

릭 캐즈먼
미 SEI 연구소 기술 분야의 수석 연구원 겸 하와이 대학의 부교수이다. 편집자이기도 한 그는 3권의 저서가 있으며 소프트웨어 공학과 관련한 논문을 70편 이상 발표 해왔다.


[ 역자 서문 ]

이 책을 처음 만난 것은 아키텍트에 막연한 동경을 품고 열심히 스터디 그룹에서 공부하던 초급 개발자일 때였습니다. 당시에는 책 내용이 난해해 이해하기 어려운데다 소프트웨어 아키텍처 분야 자체가 학문적으로 많이 성숙되기도 전이라 실무에 어떻게 적용할 수 있을지 참 난감했습니다. 몇 년이 지난 후 카네기멜론대학교(CMU)에서 소프트웨어 아키텍처 과목을 수강하게 되었고, 그 때 이 책의 개정판을 다시 접하게 됐습니다. 참고로 이 책은 CMU뿐만 아니라 SEI(Software Engineering Institute)의 아키텍처 교육과정을 비롯해 전세계의 권위 있는 교육기관에서 아키텍처를 가르칠 때 기본교재로 사용하고 있습니다. 개정판에서는 초판의 일부 모호하던 개념을 다듬고, 그 사이 연구가 진전된 내용을 추가해 좀더 현실감 있게 아키텍처의 이론과 실제를 소개하고 있습니다.

CMU와 SEI에서 소프트웨어 아키텍처를 다룰 때는 경험적 요소와 기술적 세부사항에 앞서 공학적 관점으로 바라보도록 요구합니다. 이것을 정확히 꿰뚫고 있는 것이 바로 이 책입니다. 아키텍처란 무엇을 말하는 것인지, 그것이 실무에 어떤 가치와 의미가 있는지, 소프트웨어 관련 조직은 그것을 어떻게 인식하고 받아들여야 하는지, 소프트웨어 아키텍처를 기반으로 시스템을 만들 때는 어떤 방법을 사용해야 하는지, 결과물의 문서화는 어떻게 해야 하는지, 아키텍처를 어떻게 분석하고 평가해야 하는지, 이런 것들을 실무 사례연구를 들어가며 자세히 설명해 주고 있습니다. 처음에는 흥미진진해 하면서도 이것을 실무에서 어떻게 활용할 수 있을까 의심스럽기도 했지만, 학기를 마치고 실전에서 소프트웨어 아키텍트의 역할을 수행해 보니 이 책의 가치를 온몸으로 느낄 수 있었습니다.

우리나라에서도 이 책은 여러 대학의 참고서로 활용되고 있으며 SKC&C, SDS와 같은 대기업의 아키텍트를 위한 실무 교본으로 활용되고 있습니다. 또한 한국소프트웨어진흥원과 정통부에서 진행하는 실무 중심의 ‘소프트웨어 아키텍트 양성 교육과정’에서 교재로 채택돼 활용되고 있습니다. 한마디로 소프트웨어 아키텍처의 경전이라고 부를 수 있는 책이 바로 이 『소프트웨어 아키텍처: 이론과 실제』입니다.

안타까운 사실은 이 책이 원서로 출판된 지 벌써 몇 년이 지났지만, 첫 장부터 마지막 장까지 온전히 읽은 사람이 많지 않다는 사실입니다. 대학교나 업무현장에서도 과제물을 내거나 당장에 필요한 부분만 살펴보고 덮어버리는 경우가 많더군요. 많은 소프트웨어 엔지니어들이 아키텍트를 꿈꾸고 있고, 이 책이 바로 그 길로 안내해 주는 몇 안 되는 正典인데도 불구하고 현실이 이렇다는 것은 안타까운 일이 아닐 수 없습니다. 여러 가지 이유가 있겠지만 분량이 많고 내용이 딱딱한데다, 영어로 돼 있다는 사실이 적지 않게 작용했다고 봅니다. 이 책 『소프트웨어 아키텍처: 이론과 실제』를 통해 많은 엔지니어, 개발자들이 좀 더 쉽게 아키텍처에 접근할 수 있다면 역자들이 그간 쏟아 부은 노력은 충분히 보상받을 수 있으리라 생각합니다. 모쪼록 독자분께 많은 도움이 되기를 바랍니다.


[ 역자 소개 ]

김정호
한양대학교 대학원에서 응용 수학을 전공하였고 카네기멜론대에서 소프트웨어공학 석사과정을 마쳤다. 현재 SKC&C의 대규모 프로젝트의 소프트웨어 아키텍트로 활동하고 있으며 소프트웨어 아키텍트 양성 교육강사를 겸임하고 있다. 이 시대 최고의 소프트웨어 아키텍트를 목표로 오늘도 열심히 달리고 있다.

송재하
92년 대학교 동아리에서 터보 파스칼을 배우면서 프로그래밍을 시작했다. 소프트웨어 설계와 분석에 많은 관심을 가지고 공부하던 중, 뜻한 바 있어 한국정보통신대학교 공학석사와 카네기멜론대 소프트웨어공학 석사과정(MSE)을 졸업했다. 훌륭한 소프트웨어 아키텍트가 되고 싶어하고, 되어가고 있다고 생각한다. 일이든 삶이든 “從心所欲不踰矩”의 경지에 다다르기를 소망하는 엔지니어다.

이석준
웨스턴 시드니 대에서 정보공학 및 컴퓨터학과를 졸업하고 대학원은 뉴 사우스웨일즈 대에서 정보공학과를 전공했다. 현재는 삼성 SDS 소프트웨어 아키텍처 팀에서 소프트웨어 아키텍트로 활동하고 있다. 다수의 프로젝트에서 OO/CBD 방법론 컨설팅 및 아키텍트로 참여하고 있으며 관련된 다양한 활동을 수행하고 있다. 삼성 SDS 멀티캠퍼스에서 다양한 과정의 집필과 강의를 맡고 있다.

박미율
덕성여대 전산학과를 졸업한 후, 한국정보통신대학교 공학석사, 카네기멜론대 소프트웨어공학 석사 과정(MSIT-SE)을 졸업했다. 현재는 LG전자 DM연구소에서 연구원으로 재직 중이다.

방정욱
숭실대학교 컴퓨터학부를 졸업한 후, 한국정보통신대학교 공학석사, 카네기멜론대학교 소프트웨어공학 석사과정(MSIT-SE)을 졸업했다. 현재 안철수연구소에서 모바일 백신 개발을 하고 있다. 더 넓고 더 큰 세상으로 나아가기를 항상 간절히 소망하고 있다.

노구율
서강대학교 정보통신통신대학원, 카네기멜론대 소프트웨어공학 석사과정(MSE)을 졸업했다. 현재 삼성 SDS에서 IT 컨설팅을 수행하고 있다. PLM(Product Lifecycle Management)과 IT 프로젝트 관리에 관심이 많다.

송창선
한국항공대학교 항공기계공학과를 졸업한 후, 한국정보통신대학교 공학석사, 카네기멜론대 소프트웨어공학 석사과정을 졸업했다. 현재는 한국정보통신기술협회(TTA) SW시험인증센터에서 연구원으로 재직 중이다.

목차

• 1부 아키텍처 개요 1
  
  • 1장 아키텍처 비즈니스 사이클 3
    • 1.1 아키텍처에 영향을 주는 요인 6
    • 1.2 소프트웨어 프로세스와 아키텍처 비즈니스 사이클 12
    • 1.3 좋은 아키텍처의 요건 15
    • 1.4 요약 17
    • 1.5 생각해볼 문제 17
      
  • 2장 소프트웨어 아키텍처 정의 19
    • 2.1 소프트웨어 아키텍처의 요건 19
    • 2.2 소프트웨어 아키텍처에 대한 기타 관점 23
    • 2.3 아키텍처 패턴, 참조 모델, 참조 아키텍처 24
    • 2.4 소프트웨어 아키텍처의 중요성 26
    • 2.5 아키텍처 구조와 뷰 35
    • 2.6 요약 42
    • 2.7 더 읽을거리 42
    • 2.8 생각해볼 문제 45
      
  • 3장 A-7E 항공 전자 시스템 47
    • 3.1 아키텍처 비즈니스 사이클과의 관계 48
    • 3.2 요구사항과 품질 48
    • 3.3 A-7E 항공 전자 시스템의 소프트웨어 아키텍처 53
    • 3.4 요약 66
    • 3.5 더 읽을거리 68
    • 3.6 생각해볼 문제 68
      
      
• 2부 아키텍처 수립 69
  
  • 4장 품질속성 이해 71
    • 4.1 기능성과 아키텍처 72
    • 4.2 품질속성과 아키텍처 72
    • 4.3 시스템 품질속성 74
    • 4.4 실전에서의 품질속성 시나리오 78
    • 4.5 기타 시스템 품질속성 94
    • 4.6 업무 품질 95
    • 4.7 아키텍처 자체의 품질 96
    • 4.8 요약 97
    • 4.9 더 읽을거리 97
    • 4.10 생각해볼 문제 98
      
  • 5장 품질 목표 달성 99
    • 5.1 설계전술 100
    • 5.2 가용성 설계전술 101
    • 5.3 변경용이성 설계전술 106
    • 5.4 성능 설계전술 112
    • 5.5 보안 설계전술 117
    • 5.6 시험용이성 설계전술 119
    • 5.7 사용편의성 설계전술 122
    • 5.8 설계전술과 아키텍처 패턴 관계 124
    • 5.9 아키텍처 패턴과 스타일 125
    • 5.10 요약 127
    • 5.11 생각해볼 문제 127
    • 5.12 더 읽을거리 127
  • 6장 항공관제 시스템 129
    • 6.1 아키텍처 비즈니스 사이클과의 관계 132
    • 6.2 요구사항과 품질 132
    • 6.3 아키텍처 관점에서의 해결방안 135
    • 6.4 요약 151
    • 6.5 더 읽을거리 152
    • 6.6 생각해볼 문제 152
      
  • 7장 아키텍처 설계 153
    • 7.1 생명주기상에서의 아키텍처 153
    • 7.2 아키텍처 설계 155
    • 7.3 팀 구조 형성과 아키텍처의 관계 167
    • 7.4 골격 시스템 구축 170
    • 7.5 요약 171
    • 7.6 더 읽을거리 173
    • 7.7 생각해볼 문제 173
      
  • 8장 비행 모의실험 175
    • 8.1 아키텍처 비즈니스 사이클과의 관계 176
    • 8.2 요구사항과 품질 177
    • 8.3 아키텍처 관점에서의 해결방안 182
    • 8.4 요약 197
    • 8.5 더 읽을거리 199
    • 8.6 생각해볼 문제 199
      
  • 9장 아키텍처 문서화 201
    • 9.1 아키텍처 문서의 용도 201
    • 9.2 뷰 204
    • 9.3 관련 뷰 선택 205
    • 9.4 뷰 문서화 207
    • 9.5 여러 뷰를 고려한 문서화 215
    • 9.6 UML 218
    • 9.7 요약 229
    • 9.8 더 읽을거리 230
    • 9.9 생각해볼 문제 230
  • 10장 아키텍처 재건 231
    • 10.1 개요 231
    • 10.2 정보 추출 234
    • 10.3 데이터베이스 구축 237
    • 10.4 뷰 융합 239
    • 10.5 재건 241
    • 10.6 사례 연구 248
    • 10.7 요약 257
    • 10.8 더 읽을거리 258
    • 10.9 생각해볼 문제 259
      
      
• 3부 아키텍처 분석 261
  
  • 11장 ATAM 271
    • 11.1 ATAM 참여자 272
    • 11.2 ATAM의 결과물 274
    • 11.3 ATAM의 과정 275
    • 11.4 나이팅게일 시스템: ATAM을 적용한 사례 연구 288
    • 11.5 요약 303
    • 11.6 더 읽을거리 304
    • 11.7 생각해볼 문제 305
      
  • 12장 CBAM 307
    • 12.1 의사결정의 배경 308
    • 12.2 CBAM의 기초 310
    • 12.3 CBAM의 구현 314
    • 12.4 사례 연구: 미국항공우주국 ECS 프로젝트 317
    • 12.5 CBAM 작업 결과 324
    • 12.6 요약 324
    • 12.7 더 읽을거리 325
    • 12.8 생각해볼 문제 325
  • 13장 월드와이드웹 327
    • 13.1 아키텍처 비즈니스 사이클과의 관계 328
    • 13.2 요구사항과 품질 329
    • 13.3 아키텍처 관점에서의 해결방안 334
    • 13.4 제2차 ABC 사이클: 웹 기반 전자상거래 아키텍처로의 진화 340
    • 13.5 품질 목표 달성 346
    • 13.6 오늘날의 웹 아키텍처 비즈니스 사이클 346
    • 13.7 요약 348
    • 13.8 더 읽을거리 349
    • 13.9 생각해볼 문제 349
      
      
• 4부 아키텍처 확산 351
  
  • 14장 소프트웨어 프로덕트 라인 353
    • 14.1 개요 353
    • 14.2 소프트웨어 프로덕트 라인의 작동원리 355
    • 14.3 범위 설정 357
    • 14.4 프로덕트 라인 아키텍처 360
    • 14.5 프로덕트 라인의 방해 요소 364
    • 14.6 요약 367
    • 14.7 더 읽을거리 368
    • 14.8 생각해볼 문제 368
      
  • 15장 셀시우스테크 369
    • 15.1 아키텍처 비즈니스 사이클과의 관계 370
    • 15.2 요구사항과 품질 388
    • 15.3 아키텍처 관점에서의 해결방안 390
    • 15.4 요약 399
    • 15.5 더 읽을거리 400
    • 15.6 생각해볼 문제 400
      
  • 16장 J2EE/EJB 401
    • 16.1 아키텍처 비즈니스 사이클과의 관계 402
    • 16.2 요구사항과 품질 403
    • 16.3 아키텍처 관점에서의 해결방안 406
    • 16.4 시스템 배치 의사결정 420
    • 16.5 요약 425
    • 16.6 더 읽을거리 426
    • 16.7 생각해볼 문제 426
      
  • 17장 루더 아키텍처 427
    • 17.1 아키텍처 비즈니스 사이클과의 관계 428
    • 17.2 요구사항과 품질 431
    • 17.3 아키텍처 관점에서의 해결방안 434
    • 17.4 품질 목표 달성 451
    • 17.5 요약 452
    • 17.6 더 읽을거리 452
    • 17.7 생각해볼 문제 452
      
  • 18장 기성 컴포넌트를 활용한 시스템 구축 453
    • 18.1 컴포넌트가 아키텍처에 미치는 영향 455
    • 18.2 아키텍처 불일치 456
    • 18.3 검색을 통한 컴포넌트 기반 설계 462
    • 18.4 ASEILM 사례 466
    • 18.5 요약 476
    • 18.6 더 읽을거리 476
      
  • 19장 소프트웨어 아키텍처의 미래 477
    • 19.1 다시 살펴보는 아키텍처 비즈니스 사이클 479
    • 19.2 아키텍처 수립 479
    • 19.3 생명주기 내에서의 아키텍처 481
    • 19.4 상용 컴포넌트의 영향 482

 1쇄 오류/오탈자 

[ 앞표지 면지 부분 마지막 그림 ]
시험용이성 시나리오 예제
→ 사용편의성 시나리오 예제

[ p17 첫 번째 문장 ]
각 시스템의 ~ 때문이다.
→ 모든 태스크나 프로세스는 문서화되어야 한다. 이를 통해 특정 프로세서에 할당된 태스크가 실행시점이라도 태스크가 쉽게 변경할 수 있다.

[ p22 아래에서 6행 ]
표시 있다면,
→ 표시되어 있다면,

[ p39 2행 ]
어떻게 대응되는지 나타내고 "~에 전이되는"의 의미는 소프트웨어 배치가 동적일 경우에 사용된다.
→ 어떻게 대응되는지에 대한 것이고, "~에 전이되는"은 소프트웨어 배치가 동적일 경우에 사용된다.

[ p47 표 3.1 ]
'구조' 열: 모듈 분해 → 모듈 분할
'미치는 영향' 열, '프로세스' 행: 일정조정용이성(scedulability) → 일정조정용이성(schedulability)

[ p59 그림 3.4 ]


[ p62 ■ 항목 아래 1-2행 ]
계층으로 구분된 시스템 사진을 ~ 최하단의 계층이고,
→ 계층으로 구분된 사진은 표 3.4와 그림 3.4로 유추해볼 수 있다. 계층 구조를 유추해보면 확장 컴퓨터 모듈은 최하단의 계층이고,

[ p77 그림 4.3 ]


[ p83 표 4.2 ]
'입력 가능한 값' 열, '자극 유발원' 행: 시스템 → 시스템 관리자

[ p88 표 4.4 ]
'입력 가능한 값' 열, '응답' 행에서 4행: 록, 데이터나 → 록 / 데이터나

[ p102 세 번째 문단 1행 ]
예외를 통해 결합을 → 예외를 통해 결함을

[ p108 아래에서 8행 ]
서비스 순서 → 제어 순서

[ p130 1행, 8행, 9행 ]
댈러스 → 덜레스

[ p132 그림 6.3 ]


[ p171 두 번째 문단 5행 ]
보면 작동하는 → 보면 제대로 작동하는

[ p172 아래에서 8행 ]
결국 미국의 기차 궤도가 결국 → 결국 미국의 기차 궤도는

[ p177 아래에서 4행 ]
감각이 정확하게 → 감각이 실제와 정확하게

[ p180 세 번째 문단 2행 ]
위험한 훈련을 하려는 → 위험한 훈련을 대체하려는

[ p183 아래에서 7행 ]
모의실험 시간을 분량만큼 증가시킨다. → 모의실험 시간을 정해진 분량만큼 증가시킨다.

[ p185 두 번째 문단 ]
구조적 모델 아키텍처 패턴은 크게 관리부와 관리부로 구성돼 있다.
→ 구조적 모델 아키텍처 패턴은 크게 실행부와 응용부로 구성돼 있다.

[ p185 항목 부분 ]
■ 관리부는 하위시스템의~
■ 관리부는 비행 모의실험의~
→ ■ 실행부는 하위시스템의~
■ 응용부는 비행 모의실험의~

[ p185 두 번째 중제목 ]
기체모델 관리부 모듈
→ 기체모델 실행부 모듈

[ p185 '기체모델 관리부 모듈' 절 1행 ]
관리부에는 모의
→ 실행부에는 모의

[ p185 아래에서 8행 ]
관리부의 다른 세 요소인 주기 배열기,
→ 실행부의 다른 세 요소인 주기 배열기,

[ p186 그림 8.4 설명 부분 ]
관리부에 초점을 맞춘
→ 실행부에 초점을 맞춘

[ p187 중제목 ]
기체 모델 관리부 모듈
→ 기체모델 응용부 모듈

[ p187 '기체 모델 관리부 모듈' 절 1행 ]
그림 8.5에 구조적 모델의 관리부에 존재하는
→ 그림 8.5에 구조적 모델의 응용부에 존재하는

[ p188 그림 8.5 설명 부분 ]
그림 8.5 관리부 모듈 타입
→ 그림 8.5 응용부 모듈 타입

[ p189 2행 ]
관리부를 거치면서 개별 관리부 상태로 변환된다. 이후 관리부가
→ 실행부를 거치면서 개별 실행부 상태로 변환된다. 이후 실행부가

[ p189 항목 부분 ]
■ 관리부의~
■ 관리부 인스턴스의~
→ ■ 실행부의~
■ 실행부 인스턴스의~

[ p189 마지막 문단 ]
'stabilize' Bold 해제, 제목이 아니라 위의 문단에 이어지는 글입니다.

[ p198 1행 ]
이것은 기본적으로 관리부를
→ 이것은 기본적으로 실행부를

[ p198 2행 ]
관리부에 의해
→ 실행부에 의해

[ p198 8행 ]
(관리부 모듈 구성)
→ (실행부 모듈 구성)

[ p211 마지막 행 역자주 ]
로 in, out, inout 있다. → 로 in, out, inout이 있다.

[ p214 아래에서 5행 ]
9 활용 지침: 2번(제공되는 자원) → 9 활용 지침: 2번(요소 제공 자원)

[ p322 표 12.6 ]
'번호' 열: 11~10 → 1~10

[ p342 마지막 문장 변경 ]
대표적으로 ~ 제공한다.
→ 대표적으로 XML, 플래시, 액티브X, 자바 애플릿이 이에 해당한다. 이와 같은 웹 상호작용기(그래픽과 핫 스팟)에 대한 표준 기술들은 브라우저를 통해 프로그램 가능한 상호작용 인터페이스를 제공하기 위해 확장되었다.

[ p372 2행 ]
레이더 장치를 통해 감시한다. → 레이더 장치를 통해 외부 환경을 감시한다.

[ p373 1행 ]
라인의 이같은 → 라인이 이같은

[ p397 두 번째 문단 4행 ]
즉 암호화에 대해 스웨덴의 제품, 덴마크의 제품 등이 될 수 있다.
→ 예를 들어 암호화를 지원하기 위한 스웨덴 제품이나 덴마크 제품 등을 들 수 있다.

[ p418 아래에서 2행 ]
표 6.2에는 → 표 16.2에는

[ p420 두 번째 문단 ]
EJB 모델은 ~ 고민해야 한다.
→ 상이한 아키텍처 패턴이 사용된 애플리케이션의 컴포넌트를 EJB 모델로 결합할 수 있다. 각 애플리케이션 환경에서 최적의 결합은 무엇이고, '최적'이란 의미가 무엇인지 고민해야 한다.

[ p425 '요약' 절 첫 번째 문단 변경 ]
썬 마이크로시스템은 ~ 영향을 받았다.
→ 썬 마이크로시스템즈는 사업적으로 필요했기 때문에 J2EE 다중 단 아키텍처를 구축했다. 이는 CORBA에서 얻은 경험과 독점되고 있는 분산 프로그램 모델(마이크로소프트 COM+)의 영향이 컸다.

[ p428 '착용식 컴퓨터의 역사' 절 세 번째 문단 3행 ]
이 실험이 성공함으로써 → 이 실험이 성공하자

[ p428 '착용식 컴퓨터의 역사' 절 다섯 번째 문단 2행 ]
다양한 회사들이 컴퓨터와 → 다양한 회사들이 착용식 컴퓨터와

[ p428 '착용식 컴퓨터의 역사' 절 다섯 번째 문단 4행 ]
소프트웨어의 정교함이 증가해 → 소프트웨어의 정교함이 증가함에 따라

[ p429 '개발 조직' 절 ]
'연통형(stovepipe) 시스템'에 역자주 추가
: 난로를 사용하다 보면 연통에 연기가 새는 곳을 알루미늄 테이프로 덕지덕지 땜질을 해 놓게 된다. 소프트웨어 시스템도 이런 식으로 필요에 따라 별도로 개발된 것들을 덕지덕지 붙여서 사용하는 모습을 난로의 연통에 비유한 것이다.

[ p431 2행 ]
따라서 ~ 생기게 됐다.
→ 그리고 솔루션 그룹이 개별 고격에 맞춰 솔루션을 만들 때 제품 그룹에서 개발한 컴포넌트를 사용하게 했다.

[ p437 마지막 행 ]
제시되었던 뷰의 정제된 모습과 각각의 구조를
→ 제시했던 뷰를 정제한 모습을 각 요소의 내부구조와 함께

[ p448 두 번째 문단 2행 ]
그 행위에 정당한 → 그 행위에 적당한

[ p448 네 번째 문단 6행 ]
을 따르므로 많은 부하를 발생하게 된다.
→ 을 따르므로 많은 부하를 유발하게 된다.

[ p448 아래에서 3행 ]
EJB의 연동 → EJB와 연동

[ p451 '품질 목표 달성' 절 3행 ]
그러나 인메디어스로에서 → 그러나 인메디어스 내부에서

[ p451 표 17.1 ]
'설계 전술' 열, '신속한 애플리케이션 개발' 행에서 3행
●된 모듈을 표현함) → 된 모듈을 표현함)

[ p463 첫 번째 문단 3행 ]
시스템의 목적과 가장 맞는 → 시스템의 목적과 가장 잘 맞는

[ p463 두 번째 문단 3행 ]
교정 완료 후에 남아 있는 위험도 → 교정 완료 후에 어떤 위험이 남아 있을지도

[ p463 네 번째 문단 1행 ]
"주로 컴포넌트로 구성된 → "기성 컴포넌트 위주로 구성된

[ p483 '교육 현장에서의 소프트웨어 아키텍처' 절 네 번째 문단 2행 ]
하나 이상 것으로 예상된다. → 하나 이상 진행할 것으로 예상된다.

[ p484 두 번째 문단 3행 ]
소프트웨어 공학도도 마찬가지다. → 소프트웨어 공학도 마찬가지다.

 2쇄 오류/오탈자 

[ p40 표 2.1 '할당' 행, '소프트웨어 구조' 열 ]
할당 → 배치