한빛미디어의 소프트웨어 아키텍쳐 101을 요약 정리했습니다.
이 포스팅은 개인 학습 목적으로 작성되었으며, 한빛미디어 도서 저작권 가이드라인을 준수하였습니다.
도서에 대한 자세한 정보는 아래 링크에서 확인 가능합니다.
https://www.hanbit.co.kr/store/books/look.php?p_code=B1494466807
- (명시적) 비도메인 설계 고려사항 명시
- (암묵적) 설계 구조적 측면의 영향
- (아키텍쳐 특성) 애플리케이션 성공에 중요할 것
-
비도메인 설계 고려사항 명시
애플리케이션으로 처리할 일은 구체적인 요구사항으로 정리해야 한다. 아키텍쳐 특성은 이 요구 사항을 구현하는 방법과 선택을 하게 된 이유, 운영/설계 기준을 명시한다. 애플리케이션 성능이 중요한 아키텍쳐 특성이지만 요구사항 정의서에는 적혀 있지 않은 경우가 많은데 명시해 주어야 한다.
-
설계 구조적 측면의 영향
서드파티 결제를 사용할 경우 아키텍트가 구조에 특별시 신경 쓰지는 않겠지만, 내부에서 직접 개발해서 처리하는 경우에는 아키텍트는 이를 위한 모듈이나 컴포넌트, 서비스를 설계해야 한다.
-
애플리케이션 성공에 중요할 것
모든 아키텍쳐 특성을 전부 지원하면 좋겠지만 그만큼 설계 복잡도는 증가된다. 가급적 아키텍쳐 특성은 적게 선정해야 하고, 암묵적, 명시적 특성으로 분류하여 꼭 명시해야 하는 아키텍쳐 특성들을 적용한다.
운영 아키텍쳐 특성
- 가용성: 시스템이 얼마나 오랫동안 사용 가능해야 하는가
- 연속성: 재해가 발생했을 경우 복구가 될 수 있는 능력이 있는가
- 성능: 스트레스 테스트, 기능 사용 빈도 분석, 필요 용량 분석, 응답 시간 분석
- 복구성: 백업 전략, 장애 발생시 얼마나 빠르게 복구가 될 수 있는가
- 신뢰성/안전: 시스템에 fail/safe가 필요한가
- 견고성: 프로그램 실행 중에 인터넷이나 전력이 끊겼을 경우 시스템이 감당 할 수 있는가
- 확장성: 유저 수나 요청 수가 늘어났을때 시스템이 그에 맞는 성능을 발휘 할 수 있는가
구조 아키텍쳐 특성
- 설정성: 유저가 소프트웨어 설정을 쉽게 바꿀 수 있는가
- 신장성: 새로운 기능을 추가하는게 어렵지는 않는가
- 설치성: 다양한 플랫폼에서 시스템을 쉽게 설치할 수 있는가
- 활용성/재사용: 공통 컴포넌트 재사용이 편리한가
- 지역성: 다국어나 화폐단위 등의 요구사항이 어떻게 되는가
- 유지보수성: 시스템을 얼마나 쉽게 변경할 수 있는가
- 이식성: 플랫폼이 다르더라도 시스템을 실행 할 수 있는가
- 지원성: 디버깅하려면 로깅이나 기타 기능이 어느 수준으로 되어야 하는가
- 업그레이드성: 어플리케이션을 새버전으로 쉽고 빠르게 업그레이드 할 수 있는가
아키텍쳐 공통 특성
- 접근성: 색맹이나 청각 장애인 등을 포함한 모든 유저가 접근하는데 불편함이 없나?
- 보관성: 데이터를 무한정 보관해야하는가 아니면 일정기간 후 영구 삭제 해야하는가?
- 인증: 유저 본인이 맞다는 것을 증명하기 위한 보안 요구사항
- 인가: 유저가 어플리케이션에서 정해진 기능만 사용하도록 하는 보안 요구사항
- 합법성: 시스템이 법적 규정을 준수하는가(데이터 보호, 사베인스 옥슬리법, GDPR)
- 프라이버시: 회사 내부 임직원의 트랜잭션을 외부로 드러내지 않음
- 보안: 데이터를 암호화하여 보관하는가? 네트워크 사용시에 암호화하여 통신하는가?
- 사용성/성취성: 유저가 원하는 목적을 달성하기 위해 필요한 교육과 훈련 수준
소프트웨어 아키텍쳐는 모호한 것들 투성이다
- 소프트웨어 아키텍쳐의 대부분의 내용은 명확히 정의되어 있지 않다.
- 스스로 용어를 정의해서 사용하는 회사도 있지만 그렇다 하더라도 혼란스러운것은 마찬가지이다.
- 도메인 주도 설계 분야의 조언을 따르고 실천하는 방향으로 진행되어야 하며, 동료들끼리 보편적인 언어를 정해서 사용해야 한다.
트레이드 오프
- 지원되는 특성마다 설계 노력이 필요하고 구조적으로 지원되어야 한다.
- 각 아키텍쳐 특성이 다른 특성에 영향을 미치는 경우가 많다.
모든 아키텍쳐를 빠짐없이 반영하기는 불가능하며 아키텍트가 내린 결정을 트레이드 오프가 되는 경우가 많다.
아키텍쳐는 가능한 조금씩 설계를 반복하는게 좋다.