소프트웨어 아키텍쳐 (4) 아키텍쳐 특성 정의

GJ·2023년 1월 17일
0
post-thumbnail

한빛미디어의 소프트웨어 아키텍쳐 101을 요약 정리했습니다.
이 포스팅은 개인 학습 목적으로 작성되었으며, 한빛미디어 도서 저작권 가이드라인을 준수하였습니다.
도서에 대한 자세한 정보는 아래 링크에서 확인 가능합니다.
https://www.hanbit.co.kr/store/books/look.php?p_code=B1494466807

  • 아키텍쳐 특성의 세가지 기준
  1. (명시적) 비도메인 설계 고려사항 명시
  2. (암묵적) 설계 구조적 측면의 영향
  3. (아키텍쳐 특성) 애플리케이션 성공에 중요할 것
  • 비도메인 설계 고려사항 명시
    애플리케이션으로 처리할 일은 구체적인 요구사항으로 정리해야 한다. 아키텍쳐 특성은 이 요구 사항을 구현하는 방법과 선택을 하게 된 이유, 운영/설계 기준을 명시한다. 애플리케이션 성능이 중요한 아키텍쳐 특성이지만 요구사항 정의서에는 적혀 있지 않은 경우가 많은데 명시해 주어야 한다.

  • 설계 구조적 측면의 영향
    서드파티 결제를 사용할 경우 아키텍트가 구조에 특별시 신경 쓰지는 않겠지만, 내부에서 직접 개발해서 처리하는 경우에는 아키텍트는 이를 위한 모듈이나 컴포넌트, 서비스를 설계해야 한다.

  • 애플리케이션 성공에 중요할 것
    모든 아키텍쳐 특성을 전부 지원하면 좋겠지만 그만큼 설계 복잡도는 증가된다. 가급적 아키텍쳐 특성은 적게 선정해야 하고, 암묵적, 명시적 특성으로 분류하여 꼭 명시해야 하는 아키텍쳐 특성들을 적용한다.

운영 아키텍쳐 특성

  • 가용성: 시스템이 얼마나 오랫동안 사용 가능해야 하는가
  • 연속성: 재해가 발생했을 경우 복구가 될 수 있는 능력이 있는가
  • 성능: 스트레스 테스트, 기능 사용 빈도 분석, 필요 용량 분석, 응답 시간 분석
  • 복구성: 백업 전략, 장애 발생시 얼마나 빠르게 복구가 될 수 있는가
  • 신뢰성/안전: 시스템에 fail/safe가 필요한가
  • 견고성: 프로그램 실행 중에 인터넷이나 전력이 끊겼을 경우 시스템이 감당 할 수 있는가
  • 확장성: 유저 수나 요청 수가 늘어났을때 시스템이 그에 맞는 성능을 발휘 할 수 있는가

구조 아키텍쳐 특성

  • 설정성: 유저가 소프트웨어 설정을 쉽게 바꿀 수 있는가
  • 신장성: 새로운 기능을 추가하는게 어렵지는 않는가
  • 설치성: 다양한 플랫폼에서 시스템을 쉽게 설치할 수 있는가
  • 활용성/재사용: 공통 컴포넌트 재사용이 편리한가
  • 지역성: 다국어나 화폐단위 등의 요구사항이 어떻게 되는가
  • 유지보수성: 시스템을 얼마나 쉽게 변경할 수 있는가
  • 이식성: 플랫폼이 다르더라도 시스템을 실행 할 수 있는가
  • 지원성: 디버깅하려면 로깅이나 기타 기능이 어느 수준으로 되어야 하는가
  • 업그레이드성: 어플리케이션을 새버전으로 쉽고 빠르게 업그레이드 할 수 있는가

아키텍쳐 공통 특성

  • 접근성: 색맹이나 청각 장애인 등을 포함한 모든 유저가 접근하는데 불편함이 없나?
  • 보관성: 데이터를 무한정 보관해야하는가 아니면 일정기간 후 영구 삭제 해야하는가?
  • 인증: 유저 본인이 맞다는 것을 증명하기 위한 보안 요구사항
  • 인가: 유저가 어플리케이션에서 정해진 기능만 사용하도록 하는 보안 요구사항
  • 합법성: 시스템이 법적 규정을 준수하는가(데이터 보호, 사베인스 옥슬리법, GDPR)
  • 프라이버시: 회사 내부 임직원의 트랜잭션을 외부로 드러내지 않음
  • 보안: 데이터를 암호화하여 보관하는가? 네트워크 사용시에 암호화하여 통신하는가?
  • 사용성/성취성: 유저가 원하는 목적을 달성하기 위해 필요한 교육과 훈련 수준

소프트웨어 아키텍쳐는 모호한 것들 투성이다

  • 소프트웨어 아키텍쳐의 대부분의 내용은 명확히 정의되어 있지 않다.
  • 스스로 용어를 정의해서 사용하는 회사도 있지만 그렇다 하더라도 혼란스러운것은 마찬가지이다.
  • 도메인 주도 설계 분야의 조언을 따르고 실천하는 방향으로 진행되어야 하며, 동료들끼리 보편적인 언어를 정해서 사용해야 한다.

트레이드 오프

  1. 지원되는 특성마다 설계 노력이 필요하고 구조적으로 지원되어야 한다.
  2. 각 아키텍쳐 특성이 다른 특성에 영향을 미치는 경우가 많다.
    모든 아키텍쳐를 빠짐없이 반영하기는 불가능하며 아키텍트가 내린 결정을 트레이드 오프가 되는 경우가 많다.
    아키텍쳐는 가능한 조금씩 설계를 반복하는게 좋다.
profile
Frontend Developer

0개의 댓글