한빛미디어의 소프트웨어 아키텍쳐 101을 요약 정리했습니다.
이 포스팅은 개인 학습 목적으로 작성되었으며, 한빛미디어 도서 저작권 가이드라인을 준수하였습니다.
도서에 대한 자세한 정보는 아래 링크에서 확인 가능합니다.
https://www.hanbit.co.kr/store/books/look.php?p_code=B1494466807
소프트웨어 아키텍트의 정확한 커리어 패스가 없는 이유
- 직업 자체에 대한 정확한 정의가 없음
- 너무 방대한 분야를 포괄하며 업무 범위도 넓어지고 있음
- 개발 생태계가 너무 빠르게 발전하고 아키텍트도 변화
- 많은 자료들이 역사적인 연관성을 강조
소프트웨어 아키텍쳐
- 소프트웨어 아키텍쳐를 바라보는 한가지 방법으로 아키텍쳐 특성, 아키텍쳐 결정, 설계원칙, 시스템 구조 측면에서 보는 방법이 있음
- 시스템 구조란 시스템이 구현된 아키텍쳐 스타일들의 종류(마이크로서비스, 레어어드, 마이크로커널)를 말함
- 아키텍쳐 특성이란 소프트웨어 아키텍쳐를 다른 관점에서 바라본 것
- 아키텍쳐 결정이란 시스템 구축에 필요한 규칙들을 정한 것(시스템의 제약조건, 개발자가 해도 되는 것)
- 설계 원칙이란 가이드라인(비동기를 사용해야 한다고 명시하면 개발자는 적합한 통신 프로토콜 선택 사용)
아키텍트에게 바라는 핵심적인 요구사항
- 아키텍쳐 결정: 기술 결정이 아니라 기술 범주를 결정, 필요시엔 기술 결정도 가능
- 아키텍쳐 지속적 분석: 현재 환경 분석 및 해결 방안 제시, 아키텍쳐 건전성 추구
- 최신 트렌드 유지: 최신 기술과 업계 트렌드를 따라감
- 컴플라이언스 보장: 구성원이 결정과 원칙을 제대로 준수하는지 지속적인 확인
- 기술과 경험에 노출: 통달은 아니어도 다양한 시스템과 서비스를 사용하고 연동하는 방법은 알아야 함
- 비즈니스 도메인 지식 보유: 성공한 아키텍트는 기술 지식뿐만 아니라 도메인에 깊이있는 지식
- 뛰어난 대인관계 기술: 결국에 개발은 사람이 하므로 사람 관리 기술 필요
- 처세술: 아키텍트의 결정은 반발심이 생기므로 사람들이 수용하도록 협상 기술 필요
아키텍트와 다른 부서와의 교차점
- 엔지니어링 프랙티스: 소프트웨어 개발 프로세스는 팀을 어떻게 구성하고 관리를 어떻게 할지 사람을 조직하고 상호작용하는 기법이고, 소프트웨어 엔지니어링 프랙티스는 프로세스와는 무관하게 가시적이고 반복가능한 혜택을 주는 실천론임. 예를 들어 지속적 통합은 특정 프로세스의 종속되지 않는다.
- 운영, 데브옵스: 아키텍쳐와 운영간에 연결 고리를 맺어 설계를 단순화 하고 운영자가 가장 잘 처리할 수 있는 부분은 운영에 맡김
- 프로세스: 애자일 프로젝트의 아키텍트는 반복적인 개발을 통해 의사결정에 필요한 피드백을 빠르게 받을 수 있음
- 데이터: 코드와 데이터는 공생관계며 데이터베이스 관리자는 아키텍트와 협업하여 복잡한 시스템의 데이터 아키텍쳐를 구축
소프트웨어 아키텍쳐 법칙
- 소프트웨어 아키텍쳐의 모든 것은 트레이드 오프다.
- 어떻게보다 왜가 더 중요하다.
Frontend Developer