소프트웨어 아키텍처 101 내용 중 자율 평가 문제에 대한 제가 생각하는 답을 정리했습니다. 책에서 가르쳐준 내용을 토대로 최대한 정답이라고 생각하는 내용을 적었으나 잘못 정리 했거나 틀린 답을 적었을 수 있습니다. 정리한 내용 중 책의 저작권을 위배하는 사항이 있다면 내용이 수정될 수 있습니다.
소프트웨어 아키텍처를 정의하는 네 차원은 무엇인가요?
- 아키텍처 특성(architecture characteristic)
시스템의 기능과 직교하는 시스템의 성공 기준
시스템이 지원해야 하는 ‘~성’ 들 (ex: 가용성, 신뢰성, 시험성, 확장성, 보안, 민첩성 등) - 아키텍처 결정(architecture decision)
시스템 구축에 필요한 규칙들
시스템의 제약조건을 형성, 개발자가 해도 되는 것과 하지 말아야 할 것을 알려줌 - 설계 원칙(design principle)
소프트웨어의 조건과 구현 방안에 대한 가이드라인
(ex: 마이크로서비스 아키텍처의 성능 향상을 위한 서비스 간 통신은 비동기 메시징을 활용해야함) - 구조(structure)
시스템이 구현된 아키텍처 스타일(들)의 종류
(ex: 마이크로서비스, 레이어드, 마이크로커널 등)
아키텍처 결정과 설계 원칙은 어떤 차이점이 있나요?
아키텍처 결정이 반드시 지켜야 할 규칙이라면 설계 원칙은 가이드라인
소프트웨어의 모든 조건과 구현 방안을 아키텍처 결정(규칙)으로 다룰 수는 없기에 권장하는 방법에 관한 가이드를 설계 원칙으로 제공
소프트웨어 아키텍트의 8대 핵심 기대치를 나열하세요
- 아키텍처 결정을 내린다.
아키텍트는 기술 선택을 가이드 하는 사람이지 정해주는 사람이 아니다. - 아키텍처를 지속적으로 분석한다.
ex: 3년 이전에 정의한 아키텍처가 지금도 얼마나 현실성 있는지 평가 - 최신 트렌드를 계속 유지한다.
항상 최신 기술과 업계 트렌드를 따라가야 함 - 아키텍처 결정의 컴플라이언스를 보장한다.
아키텍트가 정의하고 문서화하여 전달한 아키텍처 결정과 설계 원칙들을 개발팀이 제대로 준수하고 있는지 지속적으로 확인 - 다양한 기술과 경험에 노출된다.
유능한 아키텍트는 여러가지 언어, 플랫폼, 기술을 경험할 기회를 적극적으로 모색하면서 기술의 깊이보다는 폭에 초점을 둔다. - 비즈니스 도메인 지식을 보유한다.
비즈니스 도메인 지식이 없으면 비즈니스의 문제점, 목표, 요구사항을 이해하기 어렵고, 따라서 비즈니스 요구사항을 수용할 만한 효율적인 아키텍처를 설계하기도 어려움. - 대인 관계 기술이 뛰어나다.
아키텍트는 개발팀을 기술적으로 이끌기만 하는 사람이 아니라, 개발팀을 리드해서 아키텍처를 구현하는 사람이므로 직책 또는 역할과 상관 없이, 리더십 스킬은 아키텍트로서 성공하기 위해 필수 요구사항의 절반 이상은 차지함. - 정치를 이해하고 처세를 잘한다.
아키텍트가 내린 거의 모든 결정은 사람들의 반발에 부딪히게 마련이다. 따라서 대부분의 결정을 사람들이 수용하도록 기본적인 협상 기술을 발휘해야 함.
소프트웨어 아키텍처 제1법칙은 무엇인가요?
소프트웨어 아키텍처의 모든 것은 다 트레이드오프다.
