[소프트웨어 아키텍처 101] 4. 아키텍처 특성 정의

요약

아키텍처 특성 정의

• 아키텍트는 주로 소프트웨어로 처리할 일 중 도메인 기능과 직접적인 관련이 없는 모든 것들, 즉 아키텍처 특성(architectural characteristic)을 정의, 발견, 분석하는 일을 수행함
• 아키텍처 특성은 아래 세 가지 기준을 충족함
  • 비도메인 설계 고려 사항을 명시 : 요구사항을 구현하는 방법, 어떤 선택을 하게 된 이유와 관련된 운영/설계 기준을 명시함
  • 설계의 구조적 측면에 영향 : 예를 들어, 어떤 시스템이든 기본 보안을 준수해야 하지만, 뭔가 특별한 것을 설계해야 한다면 보안은 아키텍처 특성 수준으로 격상됨
  • 어플리케이션 성공에 절대적으로 중요
    • 아키텍처 특성을 적게 선정하는 것도 중요한 책무
    • 암묵적 아키텍처 특성은 요구사항 정의서에는 없지만 프로젝트 성공에 꼭 필요한 특성 (ex: 가용성, 신뢰성, 보안 등)
    • 명시적 아키텍처 특성은 요구사항 정의서나 다른 지침에 기재됨
    • 분석 단계에서 문제 영역에 대해 습득한 지식을 최대한 활용하여 아키텍처 특성을 밝혀내야함

      4.1 아키텍처 특성 (일부) 목록

• 과거에도 아키텍처 특성을 체계화하려는 시도는 있었지만 아직도 보편적인 표준은 따로 없음
• 어떻게 나열해도 불완전한 목록이 될 수밖에 없고, 정의가 중복되는 것들도 많음
• 용어의 대부분이 의미가 미묘하거나, 객관적으로 정의하기 어렵거나, 다소 부정확하고 모호한 부분도 있음
• 운영 아키텍처 특성
  • ==[[가용성(availability)]]== : 시스템이 얼마나 오랫동안 사용 가능해야 하나? (24/7이면 장애 발생 시 시스템을 신속하게 재가동시키는 절차가 준비되어야 함)
  • 연속성(continuity) : 재해 복구 능력
  • 성능(performance) : 스트레스 테스트, 피크 분석, 기능의 사용 빈도 분석, 필요 용량, 응답 시간. 이 정도 성능이면 됐다 싶으려면 직접 돌려봐야 하는데 그 기간만 대략 수 개월 소요된다.
  • 복구성(recoverability) : 비즈니스 연속성 요구사항(ex: 장애 상황 시 얼마나 신속하게 재가동시켜야하나?), 백업 전략과 핟웨어 다중화 요건에 영향을 미친다.
  • 신뢰성/안정(reliability/safety) : 시스템에 페일 세이프(fail-safe)가 필요한가? 즉, 페일 세이프가 시스템 가동에 필수인가? 시스템 실패 시 회사에 거액의 손실이 발생하는가?
  • 견고성(robustness) : 프로그램 실행 중 인터넷 접속 끊김, 정전, 하드웨어 실패 등 에러 및 경계 조건을 감당하는 능력
  • ==[[확장성(scalability)]]== : 유저 수, 요청 수가 늘어나도 시스템이 그에 맞는 성능을 발휘하는 능력
• 구조 아키텍처 특성
  • 설정성 : 최종 유저가 쓰기 편한 인터페이스를 통해 소프트웨어 설정을 쉽게 바꿀 수 있는가?
  • ==[[신장성(extensibility)]]== : 새로운 기능을 삽입하는 일의 중요성
  • 설치성 : 필요한 모든 플랫폼에 시스템을 얼마나 손쉽게 설치할 수 있나?
  • 활용성/재사용 : 공통 컴포넌트를 여러 제품에서 활용할 수 있나?
  • 지역성 : 다국어 지원, 화폐 단위 등의 요구사항
  • 유지보수성 : 시스템을 얼마나 쉽게 변경/개선할 수 있나?
  • 이식성 : 하나 이상의 플랫폼에서 시스템을 실행할 수 있나?
  • 지원성 : 어플리케이션은 어느 정도의 기술 지원을 필요로 하나? 시스템에서 발생한 에러를 디버깅하려면 로깅 및 기타 기능이 어느 수준으로 뒷받침되어야 하나?
  • 업그레이드성 : 이 어플리케이션/솔루션의 구 버전을 새 버전으로 쉽고 빠르게 업그레이드할 수 있는가?
• 아키텍처 공통 특성
  • 접근성(accessibility) : 색맹, 청각 장애인 등 모든 유저가 접근하는 데 불편함이 없나?
  • 보관성 : 데이터를 따로 아카이빙해야 하나, 아니면 일정 시간 경과 후 삭제해야 하나?
  • 인증(authentication) : 유저가 본인이 맞다는 것을 증명하기 위해 필요한 보안 요구사항
  • 인가(authorization) : 유저가 어플리케이션에서 정해진 기능만 사용할 수 있도록 강제하는 보안 요구사항
  • 합법성 : 시스템 운영상 법적 제약조건이 있는가?
  • 프라이버시 : 회사 내부 님직원의 트랜잭션을 외부에 드러내지 않는 기능
  • 보안 : 데이터를 암호화한 후 데이터베이스에 보관해야하나? 내부 시스템 간 네트워크 통신도 암호화해야 하나? 원격 유저 액세스는 어떤 종류의 인증이 필요한가?
  • 사용성/성취성 : 유저가 어플리케이션/솔루션을 이용하여 원하는 목적을 달성하기 위해 필요한 교육/훈련 수준. 사용성 요구사항 역시 다른 아키텍처 이슈 못지않게 진지하게 다루어야 한다.

    4.2 트레이드오프 및 나쁜 것 중에서 제일 나은 아키텍처

• 최고의 아키텍처를 고집하지 말고 나쁜 것 중에서 제일 나은 아키텍처를 선택하세요
  • 아키텍트가 설계하기로 결정한 아키텍처 특성 하나하나가 전체 설계를 복잡하게 만들 가능성을 품고 있다. 아키텍처 특성은 시스템 구조적으로 지원되야하는 경우가 많다
  • 아키텍처 특성끼리는 서로 영향을 미치는 경우가 많음
  • 모든 아키텍처 특성을 반영한 설계는 불가능에 가깝다. 아키텍트가 내린 결정은 상충되는 여러 문제들이 뒤얽힌 트레이드오프로 귀결되는 경우가 많다.
• 가능한 한 아키텍처 설계를 꾸준히 조금씩 반복해보는 게 좋다. 반복의 가치는 애자일 소프트웨어 개발에서도 가장 중요한 교훈 중 하나로, 아키텍처뿐만 아니라 모든 레벨의 소프트웨어 개발에도 적용된다.