"예스 24 리뷰어클럽 서평단 자격으로 도서를 제공받아 작성한 리뷰"

AI 시대가 본격적으로 적용되는 현 시점에서 소프트웨어 업계에서도 AI 발전에 따른 영향을 받을 수밖에 없다. 바이브 코딩이라는 AI를 이용한 페어 프로그래밍이 대세가 되어 가는 시점에서 개발자들은 어떻게 대처해야 하는가? 개인적으로 이런 문제에 대한 해답은 AI와 협업으로 최대의 효율을 얻을 수 있는 바이브 코딩 방법과 한층 더 고차원적인 지식을 습득하는 것이 올바른 대처라고 생각한다. 이를 습득하기 위한 구체적인 방법은 '패턴 언어'를 익히고 아키텍처와 같은 거시적인 관점에서 소프트웨어를 바라보는 것이라고 할 수 있다. '패턴 언어'는 개발자뿐만 아니라 AI 협업에서도 정확한 개발 언어로 토큰 사용을 줄이면서 좀 더 나은 결과를 얻을 수 있다. 아키텍처의 이해는 AI가 아직 명확하게 제시하지 못하는 거시적인 관점을 선점함으로써 개발자의 지위를 유지시켜 줄 수 있다.

이런 관점에서 '소프트웨어 아키텍처'를 익히는 것은 '선택'이 아니라 '필수'인 시대가 된 것이다. 개발자는 이제 '현자'가 될 필요가 있다. 실무 중심의 아키텍처 사고와 최신 트렌드를 반영한 『소프트웨어 아키텍처 The Basics 2nd Edition』은 이런 점에서 훌륭한 책이다. 이 책은 『헤드 퍼스트 소프트웨어 아키텍처』의 심화 과정에 해당되는 수준이며, 대부분 동일한 아키텍처 개념, 정의 및 예제를 대상으로 하고 있다. 따라서 여유가 된다면 『헤드 퍼스트 소프트웨어 아키텍처를 선수 과정으로 읽은 후에 『소프트웨어 아키텍처 The Basics 2nd Edition』을 읽는다면 아키텍처에 대해 좀 더 쉽게 이해할 수 있다. 번역은 IT 서적 번역에 뼈가 굵은 전문 번역가인 류광이 담당했기 때문에 믿고 읽을 수 있다.

책에서 다루는 내용이 전부 훌륭하지만, '이벤트 주도 아키텍처 스타일'과 '공간 기반 아키텍처 스타일'은 관심을 가지고 읽었다. '이벤트 주도 아키텍처 스타일'은 기존에 해오던 방식의 개발이지만, 개발 과정 중에 고민했던 부분에 대한 통찰을 제공했기 때문이고, '공간 기반 아키텍처 스타일'은 지금까지 자주 경험해 보지 못한 스타일의 아키텍처였기 때문이다. 특히 공간 기반 아키텍처 스타일에서 제시한 여러 소프트웨어를 저자가 제공한 아키텍처 스타일로 구성해 보는 재미도 있어서 좋았다.

대상 독자는 패턴 언어에 일정 수준의 지식을 가지고 있고 아키텍처에 관심이 있는 독자라면 추천이다. 『헤드 퍼스트 소프트웨어 아키텍처』를 읽은 독자라면 완전 추천한다. 책이 600페이지 이상이며, 글도 많은 편이라 가벼운 마음으로 볼 만한 책은 아니다. 어느 정도의 각오가 필요하다.

오랜만에 마음에 쏙 드는 책을 만나서 기쁘다.

아키텍처 결정 앞에서 망설이는 순간, 펼쳐보게 되는 책

시니어 개발자로서 팀을 이끌다 보면 어느 순간 코드를 넘어선 질문들과 마주하게 된다. "이 기능을 새로운 서비스로 분리해야 할까, 아니면 기존 모놀리스에 추가해야 할까?" "이벤트 기반으로 전환하면 정말 나아질까?" 같은 질문들 말이다. 이런 질문 앞에서 확신을 갖기란 쉽지 않다. 특히 그 결정이 향후 몇 년간 팀 전체의 생산성을 좌우할 수 있다는 걸 알기에 더 신중해진다.

"소프트웨어 아키텍처 The Basics 2판"은 바로 그런 순간을 위한 책이다. 이 책을 읽으면서 가장 먼저 든 생각은 "이런 책을 5년 전에 읽었더라면"이었다. 물론 그때 읽었어도 지금만큼 와닿지는 않았을 것 같다. 실제로 삽질을 해봐야, 잘못된 결정의 대가를 치러봐야 이 책의 가치를 제대로 느낄 수 있다.

트레이드오프라는 불편한 진실

책을 관통하는 핵심 메시지는 간단하지만 강력하다. "소프트웨어 아키텍처의 모든 것은 트레이드오프다." 처음엔 너무 당연한 얘기 아닌가 싶었는데, 책을 읽다 보니 우리가 얼마나 이 원칙을 무시하고 있었는지 깨닫게 됐다.

예를 들어 우리 팀은 작년에 마이크로서비스 전환을 검토했다. 당시 팀원들과 나눈 대화를 떠올려보면 "마이크로서비스로 가면 확장성도 좋아지고, 배포도 독립적으로 할 수 있고, 팀 자율성도 높아진다"는 장점만 나열했던 것 같다. 책에서는 이런 접근을 정확히 짚어낸다. 분산 아키텍처로 가면 네트워크 지연, 데이터 일관성 문제, 운영 복잡도 증가라는 대가를 치러야 한다고.

실제로 4장부터 7장까지 아키텍처 특성을 다루는 부분을 읽으면서, 우리가 얼마나 많은 것들을 간과했는지 새삼 느꼈다. 성능과 보안, 확장성과 단순성, 가용성과 비용... 이 모든 것을 동시에 만족시키는 아키텍처는 없다. 결국 비즈니스 우선순위에 따라 무엇을 취하고 무엇을 포기할지 결정해야 하는데, 이 책은 그 판단 기준을 제시한다.

현장에서 바로 써먹을 수 있는 실용성

이론서가 아니라는 점이 이 책의 가장 큰 강점이다.

 PART 02에서 다루는 각 아키텍처 스타일마다 동일한 구조로 설명하는데, 이게 정말 실무적이다.

⦁ 토폴로지: 실제 구조가 어떻게 생겼는지

⦁ 데이터 토폴로지: 데이터는 어떻게 흐르는지

⦁ 클라우드 고려 사항: 클라우드 환경에서 주의할 점

⦁ 일반적인 위험: 이 스타일의 함정은 무엇인지

⦁ 팀 토폴로지: 이 아키텍처에 맞는 팀 구성은?

특히 '일반적인 위험' 부분이 유용했다. 예를 들어 계층형 아키텍처(Chapter 10)에서 "싱크홀 안티패턴"을 설명하는데, 우리 레거시 시스템에서 정확히 이런 문제가 있었다. 요청이 각 레이어를 그냥 통과만 하면서 아무 의미 있는 처리도 안 하는... 이걸 읽으면서 "아, 이게 안티패턴이었구나" 하고 무릎을 쳤다.

11장의 모듈형 모놀리스는 개인적으로 가장 인상 깊었던 부분이다. 요즘 분위기가 "무조건 마이크로서비스"인 것 같은데, 이 책은 현실적인 대안을 제시한다. 모놀리스지만 내부를 모듈로 잘 나누면 대부분의 이점을 가져갈 수 있다는 것. 실제로 우리 팀도 서비스 분리 전에 먼저 모듈화를 시도해보기로 했는데, 이 챕터가 큰 도움이 됐다.

클라우드 시대를 제대로 반영한 2판

1판과 비교했을 때 2판의 가장 큰 변화는 클라우드 관련 내용이 대폭 강화됐다는 점이다. 각 아키텍처 스타일마다 '클라우드 고려 사항' 섹션이 추가됐고, 아키텍처 특성에도 클라우드 네이티브 특성들이 포함됐다.

⦁ 온디맨드 확장성

⦁ 온디맨드 탄력성

⦁ 존 기반 가용성

⦁ 지역 기반 개인정보보호

이런 특성들은 이제 선택이 아니라 필수다. 특히 AWS나 Azure 같은 클라우드 환경에서 작업하는 개발자라면 반드시 고려해야 하는 요소들이다. 우리 팀도 작년에 온프레미스에서 AWS로 마이그레이션했는데, 당시 이 책이 있었으면 훨씬 수월했을 것 같다.

예를 들어 16장 공간 기반 아키텍처에서 클라우드 환경의 자동 확장, 로드 밸런싱, 캐싱 전략을 다루는데, 실제 AWS 서비스들과 매핑해서 생각해보니 이해가 훨씬 잘 됐다. 책에서 제시하는 원칙들이 구체적인 클라우드 서비스 선택으로 이어지는 거다.

코드를 넘어선 영역: 사람과 조직

PART 03은 기술적인 내용보다 소프트 스킬에 집중한다. 처음엔 "이게 왜 아키텍처 책에 있지?" 싶었는데, 읽다 보니 이게 핵심이더라.

Chapter 24 '유능한 팀 만들기'는 실제로 겪은 상황들이 그대로 나온다. 아키텍트가 모든 결정을 독단적으로 내리면 팀이 무너진다는 것, 제약조건은 명확하게 주되 세부 구현은 팀에 맡겨야 한다는 것. 이런 내용들이 교과서적인 이야기가 아니라 실전 경험에서 우러나온 조언처럼 느껴졌다.

특히 '어느 정도까지 관여할 것인가?'라는 질문이 인상적이었다. 시니어 개발자로서 아키텍처 결정에 참여하다 보면, 어디까지 관여하고 어디서 멈춰야 할지 애매한 경우가 많다. 책에서는 이에 대한 실용적인 가이드라인을 제시한다. 전략적 결정은 함께하되, 전술적 구현은 신뢰하고 맡기라는 것.

Chapter 21의 아키텍처 결정 기록(ADR)도 당장 적용 가능한 실용적인 기법이다. 우리 팀도 중요한 기술 결정을 할 때 왜 그렇게 결정했는지 문서로 남기곤 했는데, 형식이 제각각이어서 나중에 찾아보기 어려웠다. ADR 템플릿을 적용하니 훨씬 체계적으로 관리할 수 있게 됐다.

"왜 이 결정을 내렸는가"를 명확히 문서화하면, 6개월 후 팀원이 바뀌어도, 컨텍스트를 잃어버려도 당시의 의사결정 맥락을 이해할 수 있다. 이게 레거시 시스템을 유지보수할 때 얼마나 중요한지는 다들 알 것이다.

실무에 적용하면서 느낀 점들

책을 읽고 나서 실제로 몇 가지를 적용해봤다.

1. 아키텍처 특성 우선순위 정하기

신규 프로젝트를 시작할 때 Chapter 5의 방법론을 그대로 따라해봤다. 도메인 요구사항에서 아키텍처 특성을 추출하고, 우선순위를 정하는 과정. 예전엔 "확장 가능하고, 안전하고, 빠르고..." 이렇게 모든 걸 다 만족시키려 했는데, 이제는 "우리 비즈니스에서 가장 중요한 3가지 특성은 뭔가?"를 먼저 묻는다.

결과적으로 불필요한 복잡도를 많이 줄일 수 있었다. 예를 들어 내부 관리 도구는 확장성보다 개발 속도와 유지보수성이 더 중요하다는 걸 명확히 하니, 계층형 아키텍처로 심플하게 가는 결정을 자신 있게 내릴 수 있었다.

2. 리스크스토밍 도입

Chapter 22의 리스크스토밍을 팀 회의에 도입했다. 새로운 아키텍처를 도입하기 전에 팀원들과 함께 포스트잇으로 리스크를 브레인스토밍하는 것. 처음엔 부정적인 얘기만 하는 것 같아 불편했는데, 실제로 해보니 사전에 많은 문제를 발견할 수 있었다.

특히 주니어 개발자들도 리스크를 제기할 수 있는 안전한 환경이 만들어졌다. "이거 괜찮을까요?"라고 조심스럽게 물었던 것들이 실제로 큰 문제가 될 수 있는 부분이었던 경우가 많았다.

3. 팀 토폴로지 재정비

각 아키텍처 스타일마다 '팀 토폴로지 고려 사항'이 있는데, 이게 생각보다 중요했다. 마이크로서비스를 제대로 운영하려면 팀 구조도 바뀌어야 한다는 것. 우리는 아키텍처만 바꾸고 팀 구조는 그대로 두려고 했는데, 책을 읽고 나니 그게 왜 문제인지 이해가 됐다.

결국 기능 중심 팀에서 서비스 중심 팀으로 재편했고, 각 팀이 자기 서비스에 대한 end-to-end 책임을 지도록 했다. 초반엔 혼란스러웠지만, 결과적으로 배포 속도도 빨라지고 팀 자율성도 높아졌다.

이 책이 아쉬운 점

완벽한 책은 없다. 몇 가지 아쉬운 점도 있었다.

첫째, 예제 코드가 거의 없다. 개념적인 설명은 훌륭하지만, 실제 구현 코드를 보고 싶을 때가 많았다. 특히 마이크로서비스 간 통신이나 이벤트 주도 아키텍처 같은 부분은 코드 예제가 있었으면 이해가 더 빨랐을 것 같다.

둘째, 특정 기술 스택에 대한 언급이 제한적이다. 이건 의도된 것이긴 한데(기술 중립적인 책이니까), 실무자 입장에서는 "그래서 이걸 Spring Boot로는 어떻게 구현하지?" 같은 질문이 남는다. 물론 이건 다른 책이나 문서를 참고하면 되긴 하다.

셋째, 분량이 꽤 된다. 630페이지를 다 읽으려면 시간 투자가 필요하다. 바쁜 실무자가 한 번에 쭉 읽기엔 부담스러울 수 있다. 다만 필요한 챕터만 골라서 읽어도 충분히 가치가 있으니, 레퍼런스처럼 활용하는 것도 방법이다.

누구에게 추천하는가

이 책은 다음과 같은 사람들에게 특히 유용할 것 같다:

시니어 개발자로서 아키텍처 결정에 참여하기 시작한 사람들

⦁ 코드 레벨을 넘어선 의사결정을 해야 하는데, 체계적인 방법론이 필요한 경우

⦁ "이게 정말 맞는 선택일까?" 하는 의구심이 들 때 판단 기준이 필요한 경우

레거시 시스템 개선을 고민하는 사람들

⦁ 모놀리스를 그대로 둘지, 모듈화할지, 서비스로 쪼갤지 결정해야 하는 경우

⦁ 현재 아키텍처의 문제점을 명확히 진단하고 싶은 경우

기술 리드나 테크 매니저

⦁ 팀의 기술 방향을 설정해야 하는 경우

⦁ 비즈니스 요구사항을 기술 결정으로 변환해야 하는 경우

반대로 프로그래밍 경험이 별로 없는 주니어 개발자에게는 너무 이른 감이 있다. 실제로 시스템을 설계하고 운영해본 경험이 있어야 책의 내용이 와닿는다. 최소 3~5년 정도 개발 경험이 있고, 시스템 전체를 바라볼 수 있는 시야가 생긴 다음에 읽는 게 좋을 것 같다.

결국 이 책이 주는 가장 큰 가치는 "정답"이 아니라 "사고의 틀"이다.

모든 결정에는 트레이드오프가 있고, 그 트레이드오프를 명확히 이해하고 설명할 수 있어야 한다. 기술은 수단이지 목적이 아니며, 아키텍처는 비즈니스를 위해 존재한다. 완벽한 아키텍처는 없으며, "지금 우리에게 가장 덜 나쁜" 선택을 하는 것이 현실이다.

이런 원칙들이 머릿속에 자리 잡으면, 새로운 기술이나 프레임워크가 나와도 흔들리지 않는다. "왜"를 물을 수 있기 때문이다. 그리고 그 "왜"를 팀원들에게, 경영진에게, 그리고 나 자신에게 설명할 수 있게 된다.

5년 전에 이 책을 읽었더라면 좋았을 거라고 했지만, 사실 지금 읽어서 다행이다. 이제야 이 책의 가치를 제대로 이해할 수 있으니까. 그리고 5년 후 다시 읽으면 또 다른 걸 얻을 것 같다. 경험이 쌓일수록 더 깊이 이해되는, 그런 책이다.

이 책은 시작부터 아키텍처 설계의 본질을 제대로 정의하고 들어간다.

구체적인 설계 기법을 설명하기 전에 아키텍처 설계를 하려면 어떤 사고방식으로 접근해야 하는지에 대해 이야기하며 생각의 뿌리부터 재정립해주는 느낌이었다.

그래서 읽고 나면 “어떻게 설계할 것인가”보다 “왜 그렇게 설계해야 하는가”에 대해 훨씬 더 깊이 고민하게 된다.

특히 인상 깊었던 부분은 서론부터 강조되는 소프트웨어 아키텍처의 법칙이었다.

그중에서도 책 전반에 걸쳐 반복적으로 다루는 핵심 개념은 단연 트레이드오프다.

아키텍처 설계를 정해진 방법에 대한 양자택일의 문제가 아닌, 양극단 사이의 스펙트럼에서 모든 트레이드 오프를 고려해 명확한 이유를 기반으로 최적의 지점을 선택하는 과정임을 끊임없이 강조한다.

이후 다양한 아키텍처 사례를 통해 각 구조의 장단점을 비교하고, 실무에서 어떤 기준과 고민을 통해 결정을 내려야 하는지를 차분하게 설명한다.

요즘 들어 AI가 점점 개발자의 역할을 대체할 수 있다는 이야기를 들을수록, 오히려 AI가 대체하기 어려운 영역은 무엇일지 고민하게 되었다. 그 과정에서 자연스럽게 아키텍처에 대한 관심도 깊어졌다.
책에서 말하듯, 아키텍처 설계란 단순히 구조를 그리는 일이 아니라 실무의 제약과 현실을 고려하며, 왜 이 선택이 최선인지 설득하는 작업이라는 점이 특히 공감되었다.

그동안 한빛미디어 리뷰어 활동을 통해 아키텍처 관련 서적을 읽어왔지만, 개인적으로는 이 책이 가장 ‘정석적인 아키텍처 설계서'라는 인상을 받았다.

책의 분량이 다소 두껍게 느껴질 수는 있지만, 그만큼 핵심 내용을 밀도 있게 담아냈다고 볼 수 있다.

아키텍처 설계를 체계적으로 공부하고 싶거나, 설계에 대한 사고의 기준을 세우고 싶은 개발자라면 꼭 한 번 읽어보기를 추천하고 싶은 책이다.

"한빛미디어 서평단 ＜나는 리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다."

소프트웨어 아키텍처 The Basics (2판)는 소프트웨어 아키텍처를 기초부터 폭넓게 정리한 실용서입니다. 이 책은 단순히 아키텍처의 개념을 나열하는 데 그치지 않고, 현대 소프트웨어 개발 환경에서 아키텍처를 정의하고 적용하는 데 필요한 사고의 틀과 실전적 기준을 제시합니다. 아키텍처 스타일, 품질 속성, 컴포넌트 설계, 도식화, 진화적 아키텍처 등 아키텍처의 핵심 주제를 망라하고 있어 개발자에서 아키텍트로 성장하고 싶은 엔지니어에게 실질적 방향성을 제시합니다. 책의 초반에는 아키텍트에 대한 정의와 필요한 내용들을 잘 정리하고 있어 팀에서 어떤 역할이 되어야 하는지 명확하게 이해할 수 있습니다.

이 책의 큰 특징은 아키텍처를 하나의 기술 스택에 종속된 설계 지식으로 다루지 않고, 폭넓은 원칙과 사고 체계로 풀어낸다는 점입니다. 예를 들어, 계층형 아키텍처, 모듈형 모놀리스, 마이크로서비스 등 다양한 스타일을 비교하면서 어떤 상황에서 각 스타일이 적합한지 설계 기준과 사례 중심으로 설명합니다. 이러한 접근 방식은 단지 문법적 요소를 설명하는 것이 아니라 독자가 아키텍처 결정을 스스로 분석하고 논리적으로 설명할 수 있도록 유도합니다. 

아키텍처 설계는 기술적 선택뿐 아니라 비즈니스 요구와 팀의 상호작용, 품질 속성 간의 트레이드오프를 고려하는 복합적 활동입니다. 이 책은 기술적 결정과 동시에 협업, 커뮤니케이션, 발표, 문서화 등의 소프트 스킬을 중요하게 다룹니다. 이는 아키텍트 역할이 단지 기술 결정자가 아니라 팀과 조직 전체의 방향성을 조율하는 리더 역할임을 이해하는 데 중요한 맥락을 제공합니다. 

또한 최신 클라우드 환경과 생성형 AI 중심의 현대적 엔지니어링 관행을 반영하여, 최근 기술 흐름과 아키텍처 사이의 상관관계를 이해하도록 구성되어 있습니다. 이러한 최신 사례 중심 설명은 전통적 아키텍처 지식에 머물지 않고 실무 중심의 적용과 판단 능력을 키우는 데 도움이 됩니다. 

정리하면, 『소프트웨어 아키텍처 The Basics (2판)』은 아키텍처의 본질적인 개념을 체계적으로 정리하고, 실전적인 설계 사고를 확장하도록 설계된 책입니다. 아키텍처를 처음 접하는 개발자부터 이미 설계 책임을 맡고 있지만 방향성을 고민하는 테크 리더까지 아키텍처를 이해하고 실전에 적용하는 데 필요한 큰 그림과 구체적 판단 기준을 제공합니다. 

한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

"한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

기존의 "소프트웨어 아키텍처 101" 책의 2판이 나왔다.

"헤드퍼스트 소프트웨어 아키텍처는" 는 가벼운 마음으로 아키텍처의 기초 대해 공부하는 책 느낌이었는데,

"소프트웨어 아키텍처 The Basics 2판" 은 교과서적인 느낌이다. 조금 더 실무적이다.

AI 가 엄청나게 발전하니,

이제는 AI 에게 먼저 질문한다.

하지만 답이 없는 문제를 물어보면 AI 는 편향된 답변을 하거나, 여러가지 여러가지의 해법에서 한두가지를 제시해준다.

그래서 이 책을 읽어야한다.

"아키텍처는 트레이드 오프이다".

그렇기 때문에 정답을 구하는 것이 아니라 토론해야한다.

AI 에게 어떻게 질문하느냐에 따라 대답의 퀄리티와 정보가 달라진다.

내가 토론을 하고 판단하고 철학을 논할 수 있을 때, AI 도 제대로 활용될 수 있는 분야라고 생각한다.

아키텍처가 결정하는 시스템 구조를 보여준다.

헤드퍼스트 책에서도 동일하게 나와있다.

아키텍처의 스타일을 출발점으로 아키텍처가 지원할 특성을 정하고,

시스템의 행동 방식을 구현하는 논리적 컴포넌트들이 결합되고,

아키텍처적 결정들이 결합된다.

각 단계는 정답이 정해져 있지 않다.

아키텍트가 트레이드오프를 항상 고려하여 결정해야한다.

우측그림을 보면 서비스간 통신을 어떻게 구현할지에 대한 예시가 2개 나와있다.

서비스간 토픽으로 구현하면 토픽을 통해 누구나 접근가능하다는 장점이자 단점이 생긴다.

확장성 측면으로 볼것이냐 보안적 측면으로 볼것이냐.

이 모든 것은 아키텍트가 결정해야한다.

아키텍처의 결정은 다른 결정보다 신중해질 수 밖에 없다.

한번 결정나면 다시 변경하는데 많은 비용이 들기 때문이다.

그래서 시스템을 이해하는 것을 넘어서 "시스템의 성공"에 필요한 비즈니스 동인도 이해하도록 노력해야한다.

이를 위해서는 비즈니스 이해관계자들과 원만하고 협력적인 관계를 맺어야하기 때문이다.

제품(시스템)은 컴퓨터 공학뿐 아니라 비즈니스를 이해해야 성공할 수 있다고 생각한다.

내가 가진 공학적 지식들은 제품의 품질을 높여 제품의 완성도를 높이고 적기에 납품할 수 있게 한다.

하지만 제품이 성공하기 위해서는 비즈니스를 이해하고 제품의 가치와 철학을 제대로 설정할 수 있어야한다.

적절한 가치를 녹이기 위해서는 적절한 기술을 선택할 수 있어야한다.

내가 시스템의 더 높은 곳을 볼 수록 코딩을 적게하게 되고 실질적인 기술과 멀어진다.

그래서 PoC(proofs of concept) 를 자주 진행하면서 구현 관점을 놓지 않도록 노력해야한다.

개인적으로 항상 이 특성 부분이 어렵다.

무수히 많은 특성이 있고, 숨겨진 특성을 찾아야하고 ...

숨겨진 특성은 도메인을 어느정도 이해하고 경험이 있어야하니 어려운 것 같다.

아키텍처엔 정답은 없다.

시스템의 성공에 필수이거나 가장 중요한 아키텍처 특성을 지원하도록 하자.

나머지는 중요하게 지원하지 않아도 된다.

너무 많은 아키텍처 특성은 오히려 시스템을 복잡하게 만든다.

어떻게 아키텍처 식별할 것인가에 대해서도 소개한다.

이해관계자들도 인정할 특성을 식별해야한다.

나만 이해한다면 그것은 중요한 특징이 아니다.

내가 중요하다고 생각한다면 그 이유를 손실없이 전달하여 동의를 받아야한다.

그렇게 식별한 특성이라도 명확하게 정의를 내리기엔 어렵다. 특성이라는 것이 "복합적" 이기 때문이다.

측정가능한 하위 특성들을 식별해서 객관적으로 볼 수 있게 하자.

이 책은 높은 관점(시스템 상위)에서 이야기를 한다.

단순 개발의 관점을 벗어나서 비즈니스 관점을 돌아보게 해주는 것 같다.

이런 책은 읽을 때마다 나의 관점이 리프레쉬해준다.

세상엔 답이 없다.

나의 답이 관점에 따라 맞을수도 아닐수도 있다.

항상 다양한 것들을 고려하도록 노력해야겠다.