[아키텍처] 5. 아키텍처 특성 식별

[Seulwoo]

아키텍처 특성 식별

• 아키텍처를 구축하거나 기존 아키텍처의 타당성을 검증할 때 제일 먼저 할 일은 아키텍처 특성을 식별하는 것
• 도메인 관심사, 요구사항, 암묵적 도메인 지식에서 아키텍처 특성을 밝혀냄

5.1 도메인 관심사에서 아키텍처 특성 도출

• 아키텍트는 도메인 관심사를 올바르게 해석하여 정확한 아키텍처 특성을 식별해야 함
• 확장성, 내고장성, 보안, 성능 중 어느 것이 가장 중요한 관심사일까? -> 도메인의 핵심 목표와 현재 상황을 고려하여 도메인 관심사를 "~성" 으로 해석한 후, 그에 따라 정확하고 합리적인 아키텍처 결정을 내려야 함
• 도메인 이해관계자와 협력하여 주요 아키텍처 특성을 정의하는 팁 : 최종 목록을 가능한 짧게 하는 것
  • 너무 많은 아키텍처 특성을 수용하면 아키텍처가 너무 복잡해져 버림
  • 아키텍처 특성의 개수에 연연하지 말고 설계를 단순화하는 것이 좋음
• 사례 연구 : 바사
  • 과도한 아키텍처 특성의 안좋은 사례
  • 수송선과 전함 역할을 둘 다 하는 큰 군함을 만들다가 무거워서 뒤집혀버림
• 최종 특성 목록을 주고 각자 중요한 특성을 3개 뽑는 방법 -> 자연스럽게 합의를 이끌어내기 쉽고 중요한 것이 무엇일까 논의하게 되며, 아키텍트가 중요한 아키텍처 결정을 내리기 전에 트레이드오프를 분석하는 데에 도움이 됨
• 아키텍트와 도메인 이해관계자들은 서로 다른 언어로 말을 함
  • 아키텍트 : 확장성, 상호운용성, 내고장성, 학습성, 가용성
  • 도메인 이해관계자 : 인수 병합, 고객 만족, 출시 시점, 경쟁 우위
  • 도메인 관심사를 아키텍처 특성으로 옮겨야 하는 이유
• 일반적인 도메인 관심사와 뒷받침하는 아키텍처 특성 정리
  • 인수 합병 : 상호운용성, 확장성, 적응성, 신장성
  • 출시 시기 : 민첩성, 시험성, 배포성
  • 유저 만족 : 성능, 가용성, 내고장성, 시험성, 배포성, 민첩성, 보안
  • 경쟁 우위 : 민첩성, 시험성, 배포성, 확장성, 가용성, 내고장성
  • 시간 및 예산 : 단순성, 실행성

5.2 요구사항에서 아키텍처 특성 도출

• 요구사항 정의서에 명시된 문장에서 도출한 아키텍처 특성
  • 예상 유저 수와 그에 따른 확장 문제
• 아키텍트가 알고 있는 도메인 지식에서 도출되는 특성들이 있기 때문에 아케틱트가 도메인 지식을 갖고 있는 것이 중요함
  • 대학교 수강 등록 애플리케이션 사례

• 아키텍처 카타의 유래

  • 초보 아키텍트가 도메인에 관한 설명을 보고 아키텍처 특성을 도출하는 연습을 할 수 있도록 고안한 훈련
  • 카타에 정의된 섹션들
    • 설명 : 시스템으로 해결하려는 전체 도메인 문제
    • 유저 : 시스템을 사용할 것으로 예상되는 유저의 유형과 인원 수
    • 요구사항 : 아키텍트가 도메인 유저 및 도메인 전문가의 말을 듣고 예상하는 도메인/도메인 수준의 요구사항
    • 부가 콘텍스트 : 요구사항에는 명확하게 기술되어 있지 않지만 아키텍트가 암묵적인 문제 영역에 관한 지식을 이용해 반드시 고려해야 할 여러 항목들

  5.3 사례 연구 : 실리콘 샌드위치

• 실리콘 샌드위치 카타를 예시로 "요구사항"을 바탕으로 아키텍처 특성을 도출하는 방법
• 설명
  • 실리콘 샌드위치 : 전국 가맹점을 보유한 샌드위치 브랜드. 온라인 주문 시스템을 구축하려고 함
• 유저
  • 앞으로 수천 명 / 수백만 명
• 요구사항
  • 여러가지
• 부가 콘텍스트
  • 샌드위치 지점은 소유자가 다 다름
  • 모회사는 해외 시장 진출 계획
  • 값싼 인력 고용해 이윤 최대화하는 것이 목표
• 아키텍처 특성을 어떻게 도출해야 할가?
  • 도메인 요구사항을 충족하는 전체 시스템을 코드 레벨로 설계하는 것이 아니라, 설계/구조에 영향을 미치는 것들을 찾아냄
  • 아키텍처 특성이 될 만한 것들은 명시적인 것과 암묵적인 것으로 분류

5.3.1 명시적 특성

• 명시적 아키텍처 틀성은 필요한 설계의 일부로서 요구사항 정의서에 기술됨
• 요구사항의 각 항목이 어떤 아키텍처 특성과 관련있는지 검토해야 함 -> 그 전에 도메인 레벨에서의 기대치를 먼저 고려해야 함
• 유저 수 -> 확장성, 유의미한 성능 저하 없이 다수의 동시 유저를 처리하는 능력이 중요 아키텍처 특성
• 이처럼 도메인 언어를 엔지니어링 언어로 해독해야 함
• 순간적으로 폭증한 유저 요청을 처리하려면 탄력성도 필요함
  • 확장성은 동시 유저 성능을 나타내고 탄력성은 트래픽의 폭주 정도를 나타냄
  • 확장성은 좋지만 탄력적이지 않은 시스템 : 호텔 예약 시스템
  • 탄력성이 좋아야 하는 시스템 : 콘서트 티켓 예약 시스템
• 비즈니스 요구사항을 하나씩 검토하면서 다음과 같은 아키텍처 특성이 존재하는지 확인해야 함
  • 1 ) 유저가 주문을 하면 샌드위치를 픽업하러 갈 시간 및 상점까지 가는 경로를 안내받음
    • 외부 지도 서비스는 연계 지점에 해당하므로 신뢰성과 같은 특성에 영향을 미침
    • 서드파티 시스템은 호출이 실패할 경우 전체 시스템 안전성에 타격을 입음
    • 불필요한 불안정성 또는 취약점이 설계에 반영되지 않도록 조심해야 함
  • 2 ) 배달 서비스가 가능한 지점은 기사를 보내 샌드위치 유저에게 배달함
    • 별다른 아키텍처 특성은 필요하지 않음
  • 3 ) 모바일 기기에서 이용 가능함
    • 웹 애플리케이션 / 네이티브 웹 애플리케이션 방향성
  • 4 ) 전국 어느 지점이나 이용 가능한 프로모션/스페셜 행사를 제공함
  • 5 ) 특정 지점에서만 이용 가능한 로컬 프로모션/스페셜 행사를 제공함
    • 커스터마이징 여부
    • 템플릿 메서드 같은 기존 설계 패턴을 이용할 수 있음
  • 6 ) 온라인 결제, 대면 결제, 배송 시 다양한 옵션을 제공함
    • 보안
  • 7 ) 샌드위치 지점은 가맹점이므로 소유자가 다 다름
    • 아키텍처 비용에 제약 (왜???)
    • 단순하거나 기능이 조금 빠진 아키텍처로도 충분한지 타당성을 미리 확인
  • 8 ) 모회사는 해외 시장에 진출할 계획
    • 국제화 -> i18n
    • 설계 결정에 영향
  • 9 ) 값싼 인력을 고용해 이윤을 최대화하는 것이 목표
    • 사용성이 중요하지만 아키텍처 특성보다는 설계와 연관이 있음

5.3.2 암묵적 특성

• 요구사항 정의서에 따로 없지만 중요한 설계 요소
• 가용성 : 시스템에서 마땅히 지원되어야 할 암묵적인 특성. 유저는 샌드위치 사이트에 접속할 수 있어야 함
• 신뢰성 : 유저가 사이트에 방문해서 시스템을 문제없이 사용해야 함
• 보안 : 안전한 소프트웨어. 보안이 설계의 구조적인 측면에 영향을 미치거나 애플리케이션에 매우 중대한 요소라고 판단할 경우 아키텍처 특성으로 간주함
  • 샌드위치는 서드파티 업체가 결제 처리를 전담하므로 개발자가 상식적인 보안 지침을 위반하지 않는 한, 아키텍트가 특별한 구조적 설계를 고민할 필요는 없음
  • 어느 한 아키텍처 특성을 지나치게 적용하지 않아야 함
• 맞춤성 : 레시피, 로컬 한매, 약도 등 문제 영역의 여러 부분을 유저의 의도에 맞게 다시 정리해야 하므로 커스터마이징이 원활하게 지원되는 아키텍처가 필요함
• 설계 대 아키텍처, 그리고 트레이드오프
  • 아키텍처는 구조적 컨포넌트를 나타내지만, 설계는 아키텍처 내부에 속함
  • 실리콘 샌드위치의 맞춤성 : 마이크로커널 같은 아키텍처 스타일을 선택해 구조적으로 지원 / 템플릿 메서드 같은 설계 패턴으로 커스텀 로직을 직접 구현해서 자식 클래스에서 오버라이드 가능한 워크플로를 부모 클래스에 정의하는 식으로 개발
  • 마이크로커널 아키텍처로 구현하지 않을 타당한 사유가 있는가?
  • 이렇게 설계하면 다르게 설계할 때보다 특별히 더 구현하기 어려운 아키텍처 특성이 있는가?
  • 각 '설계 대 패턴' 에서 모든 아키텍처 특성을 지원하려면 비용이 얼마나 들어가는가?
  • 아키텍트는 개발자, 프로젝트 관리자, 운영팀, 기타 소프트웨어 시스템 구축에 참여한 사람들의 협조를 구해야 함
• 아키텍처 특성에 우선순위를 매겨 가장 단순한 필수 세트로 정리해야 함
  • 덜 중요한 것 ? 맞춤성과 성능? 확장성이나 가용성 같은 다른 특성들보다 성능을 우선시하지 않는다는 의미이지 성능이 떨어지는 애플리케이션을 개발해도 된다는 것은 아님