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

p. 89
소프트웨어 솔루션은 도메인 요구사항과 아키텍처 특성으로 구성된다.

 

💬정처기에서 공부했던 것을 연결해보면 '도메인 요구사항 = 기능 요구사항 / 아키텍처 특성 = 비기능 요구사항'인걸까?

 

아키텍처 특성의 기준

• 비도메인 설계 고려 사항을 명시한다.
• 설계의 구조적 측면에 영향을 미친다.
• 애플리케이션 성공에 (절대적으로) 중요하다.

 

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

운영 아키텍처 특성

가용성(availability)	시스템이 얼마나 오랫동안 사용 가능해야 하나?
연속성(continuity)	재해 복구 능력
성능(performance)	스트레스 테스트, 피크 분석, 기능의 사용 빈도 분석, 필요 용량, 응답 시간
복구성(recoverability)	비즈니스 연속성 요구사항(e.g. 장애 발생 시 얼마나 신속하게 시스템을 재가동시켜야 하나?)
신뢰성(reliability)/안전(safety)	시스템에 페일 세이프(fail-safe, 고장 났을 때 안전한 방향으로 흘러가도록 하는 설계 방식)가 필요한가?
견고성(robustness)	프로그램 실행 중 인터넷 접속 끊김, 정전, 하드웨어 실패 등 에러 및 경계 조건을 감당하는 능력
확장성(scalability)	유저 수, 요청 수가 늘어나도 시스템이 그에 맞는 성능을 발휘하는 능력

 

 

구조 아키텍처 특성

설정성(configurability)	최종 유저가 (쓰기 편한 인터페이스를 통해) 소프트웨어 설정을 쉽게 바꿀 수 있는가?
신장성(extensibility)	새로운 기능을 삽입하는 일의 중요성
설치성(installability)	필요한 모든 플랫폼에 시스템을 얼마나 손쉽게 설치할 수 있나?
활용성(leverageability)/재사용(reuse)	공통 컴포넌트를 여러 제품에서 활용할 수 있나?
지역성(locality)	데이터를 입력/조회하는 화면에서 다국어가 지원되는가? 등
유지보수성(maintainability)	시스템을 얼마나 쉽게 변경/개선 할 수 있나?
이식성(portability)	하나 이상의 플랫폼에서 시스템을 실행할 수 있나?
지원성(supportability)	어플리케이션은 어느 정도의 기술 지원을 필요로 하나? 시스템에서 발생한 에러를 디버깅하려면 로깅 및 기타 기능이 어느 수준으로 뒷받침 되어야 하나?
업그레이드성(upgradeability)	이 어플리케이션/솔루션의 구 버전을 새 버전으로 쉽고 빠르게 업그레이드를 할 수 있는가?

 

 

아키텍처 공통 특성

접근성(accessability)	색맹, 청각 장애인 등 모든 유저가 접근하는데 불편함이 없나?
보관성(archivability)	데이터를 따로 아카이빙 해야 하나, 아니면 일정 시간 경과 후 삭제해야 하나?
인증(authentication)	유저가 본인이 맞다는 것을 증명하기 위해 필요한 보안 요구사항
인가(authorization)	(유스 케이스, 서브 시스템, 웹 페이지, 비즈니스 규칙, 필드 레벨 등) 유저가 어플리케이션에서 정해진 기능만 사용할 수 있도록 강제하는 보안 요구사항
합법성(legal)	시스템 운영상 법적 제약조건이 있는가? (데이터 보호, 사베인스 옥슬리법, GDPR 등) 회사는 어떤 권리를 유보 해야 하나?
프라이버시(privacy)	회사 내부 임직원의 트랜잭션을 외부에 드러내지 않는 기능(e.g. 암호화 트랜잭션은 DBA나 네트워크 아키텍트도 해독이 불가)
보안(security)	데이터를 암호화 한 후 DB에 보관해야 하나? 내부 시스템 간 네트워크 통신도 암호화 해야 하나? 원격 유저 액세스는 어떤 종류의 인증이 필요한가?
사용성(usability)/성취성(achievability)	유저가 어플리케이션/솔루션을 이용하여 원하는 목적을 달성하기 위해 필요한 교육, 훈련 수준

 

 

국제 표준기구(ISO)가 발표한 기능별 목록

성능 효율(performance efficiency)	알려진 조건에서 리소스 양에 비례하는 성능 측정값, 시간 측정, 리소스 사용, 능력 등이 포함된다.
호환성(compatibility)	제품, 시스템, 컴포넌트가 다른 제품, 시스템, 컴포넌트와 정보를 교환하고(하거나) 동일한 HW/SW 환경을 공유하면서 필요한 기능을 수행할 수 있는 정도. 공존(환경과 리소스를 다른 제품과 공유하면서 효율적으로 필요한 기능을 수행할 수 있음) 상호운용성(둘 이상의 시스템에 정보를 교환, 활용 가능한 정도)이 포함된다.
사용성(usability)	유저가 시스템을 원하는 목적에 맞게 효과적으로, 효율적으로, 만족스럽게 사용할 수 있는 정도 적합성 인지도(유저가 자신의 사용 목적에 소프트웨어가 부합하는지 인식할 수 있음) 학습성(유저가 얼마나 쉽게 소프트웨어 사용법을 익히는가) 유저 에러 방지(유저가 실수하는 것을 방지) 접근성(사람들이 소프트웨어의 가장 다양한 능력과 기능을 접할 수 있게 함)이 포함된다.
신뢰성(reliability)	주어진 기간 동안 특정 조건에서 시스템이 기능하는 정도 성숙도(정상 동작 시 소프트웨어가 원하는 신뢰성을 보장하는가) 가용성(소프트웨어가 가동 중이고 엑세스 가능한가) 내고장성(HW/SW가 고장나도 SW가 의도한 대로 작동되나) 복구성(소프트웨어가 고장나도 영향 받은 데이터를 되살리고 원하는 시스템 상태로 돌아갈 수 있는가)이 포함된다.
보안(security)	사람들, 다른 제품, 시스템이 자신의 인증 레벨에 맞게 데이터를 액세스 할 수 있게끔 소프트웨어가 정보를 보호하는 정도. 기밀성(데이터는 인증된 사람만 액세스 할 수 있음) 무결성(데이터를 함부로 변조하지 못하게 소프트웨어가 허가되지 않은 액세스를 차단함) 부인 방지(어떤 액션이나 이벤트가 발생하였음을 증명함) 책임 소재(유저가 수행한 액션을 추적) 진위(유저 신원을 증명)가 포함된다.
유지보수성(maintainability)	개발자가 얼마나 효율적으로 소프트웨어를 고쳐 개선/발전시키고 계속 변화하는 환경이나 요구사항에 맞게 적용할 수 있는가 모듈성(소프트웨어를 독립된 컴포넌트로 구성할 수 있는 정도) 재사용성(개발자가 어떤 자산을 여러 시스템에서, 다른 자산을 구축하는데 다시 사용할 수 있는 정도) 분석성(개발자가 얼마나 쉽게 소프트웨어 메트릭을 취합할 수 있나) 수정성(개발자가 기존 제품 품질을 떨어뜨리지 않고도 어렵지 않게 소프트웨어를 수정할 수 있나) 시험성(개발자나 다른 사람들이 얼마나 쉽게 소프트웨어를 테스트 할 수 있나)이 포함된다.
이식성(portability)	개발자가 HW/SW 또는 다른 운용 환경에 있는 시스템, 제품, 컴포넌트를 다른 곳에 옮길 수 있는 정도. 적응성(개발자가 소프트웨어를 다른 HW, SW, 기타 운용 환경에 맞게 적용시킬 수 있나) 설치성(소프트웨어를 주어진 환경에 설치/삭제 할 수 있나) 교체성(개발자가 얼마나 쉽게 다른 소프트웨어로 기능을 교체할 수 있는가)이 포함된다.

 

 

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

p.99
시스템을 설계하며 모든 아키텍처 특성을 빠짐없이 최상으로 반영하기란 불가능에 가깝습니다.
......
최고의 아키텍처를 고집하지 말고 나쁜 것 중에서 제일 나은 아키텍처를 선택하세요.