3.2 아키텍처 드라이버의 핵심 사항 #1477
Description
3.2 아키텍처 드라이버의 핵심 사항
3.2.1 아키텍처 드라이버
시스템의 구조를 검토할 때 중요한 고려 사항이 되는 요구 사항을 아키텍처 드라이버architectural driver 라고 합니다.
이러한 드라이버는 다음 네 가지로 분류할 수 있습니다.
- 제약constraint
- 품질 속성quality attribute
- 영향력 있는 기능 요구사항functional requirements
- 그리고 기타 영향을 미치는 요소
3.2.2 제약
제약은 시스템의 개발부터 운영 환경에 배포되기까지의 전 과정에 부과되는 특정 조건을 의미하며, 비즈니스적 제약과 기술적 제약으로 구분됩니다.
비즈니스적 제약에는 프로젝트의 예산, 일정 등이 있습니다.
또한 운영 단계에서는 유지보수 및 관리에 대한 비용을 고려해야 합니다.
기술적 제약이란 사용해야 하는 프로그래밍 언어, 라이브러리, 프레임워크, 개발 환경 등에 대한 조건을 뜻합니다.
3.2.3 품질 속성
소프트웨어 품질에는 성능이나 사용 편의성처럼 사용자가 직접 이용하고 인식할 수 있는 외부 품질과
유지보수의 용이성과 같이 사용자에게 드러나지 않는 내부 품질이 있습니다.
품질 모델
품질 속성을 정리하고 분류한 품질 모델로 KS X 25010 (ISO/IEC 25010:2011)이라는 표준 규격이 있습니다.
- 기능 적합성
- 수행 효율성
- 호환성
- 유용성
- 신뢰도
- 보안성
- 유지가능성
- 이식성
품질 속성 선정
기능 적합성functional suitability 은 주로 애플리케이션 기능으로 구현되며,
유용성 usability 은 주로 UX나 UI를 통해 구현됩니다.
따라서 아키텍처 관점에서는 나머지 6개 품질 속성을 중심으로 검토해 나가면 됩니다.
수행 효율성
수행 효율성performance effeciency은 시스템의 성능을 나타내는 품질 속성으로, 처리 응답 시간과 처리량(시간 반응성 time behavior), 시스템 리소스 크기(기억 용량 capacity) 등의 품질 부속성을 포함합니다.
이러한 품질 속성은 외주 개발 프로젝트의 경우, RFP request for proposal에 비기능 요구사항으로 명시되어 있는 경우가 많습니다.
호환성
호환성compatibility은 여러 시스템이 다른 시스템에 영향을 주지 않으면서 환경과 자원을 공유할 수 있는지(공존 co-existence), 그리고 여러 시스템 간 연계가 원활하게 이루어질 수 있는지(상호 운용성 Interoperability)을 평가하는 두 가지 품질 부속성으로 구성됩니다.
트랜잭션이 여러 시스템에 걸쳐 이루어지는 분산 트랜잭션이 필요한 경우 앞서 설명한 공존과 상호 운용성을 만족하도록 구현 방법을 검토하고 검증해야 합니다.
신뢰도
신뢰도reliability는 시스템을 안정적으로 이용할 수 있는 정도를 나타내는 품질 속성 입니다.
시스템이 필요할 때 상시 이용 가능한지(가용성 availability),
설령 일부에서 장애가 발생해도 시스템의 운용이 계속 가능한지(결점 완화 fault tolerance),
만일 시스템이 다운되었을 때 적절한 시간 내에 정상적인 상태로 복구할 수 있는지(회복 가능성 recoverbility)와 같은 품질 부속성을 가집니다.
B2B나 B2C 서비스의 경우 SLAService Level Agreement에 따라 요구되는 품질 수준이 사전에 명시되며, 이를 충족하지 못하면 이용 금액 감액이나 환불 등의 보상이 필요할 수 있습니다.
보안성
보안성security은 시스템이 취급하는 정보와 데이터를 안전하게 보호할 수 있는 정도를 나타내는 품질 속성입니다.
사용자가 허가된 정보와 데이터에만 접근할 수 있는지(기밀성confidentiality),
정보와 데이터를 부정 접근으로부터 보호하고 완전한 상태로 유지할 수 있는지(무결성integrity)와 같은 품질 부속성을 가집니다.
유지 가능성
유지 가능성maintainability은 시스템의 수정, 보수, 확장이 얼마나 효율적이고 용이한 지를 나타내는 품질 속성입니다.
적절한 구성 요소로 분해되어 있는지(모듈성modularity),
성능 저하 등의 문제 없이 효율적으로 소스 코드를 수정할 수 있는지(수정 가능성modifiability),
유효성이 높은 테스트를 효율적으로 수행할 수 있는지(시험 가능성 testability)와 같은 품질 부속성을 가집니다.
소프트웨어의 총소유비용total cost of ownership(TCO)관점에서 유지 가능성은 매우 중요한 요소입니다.
아키텍트는 전문성과 직업적 책임감을 바탕으로 유지 가능성과 관련된 적절한 목표를 설정해야 합니다.
이식성
이식성portability은 시스템을 다른 환경이나 플랫폼으로 쉽게 이전할 수 있는 정도를 나타내는 품질 속성입니다.
설치 및 배포가 효율적으로 이루어지는지(설치성installability),
같은 목적의 다른 제품 또는 제품의 새로운 버전으로 쉽게 대체할 수
있는지(대체성replaceability)등의 품질 부속성을 가집니다.
패키지 제품이나 서비스 개발 분야에서는 이러한 품질 속성이 중요합니다.
여러 마이크로서비스로 구성되어 하루에도 여러 번 배포가 이루어지는 시스템에서는 설치성이 높아야 합니다.
3.2.4 품질 속성 적용 사례
표 3.3 품질 속성의 적용 예시
| 품질 속성 | 품질 부속성 | 적용 예시 |
|---|---|---|
| 수행 효율성 | 시간 반응성 | 월말이나 월초에 신청이 집중되는 시간대에도 단위 시간당 일정량을 처리할 수 있어야 함. 특히 경리 담당자는 많은 회계 내역을 처리해야 하기 때문에 응답 속도가 저하되지 않아야 함 |
| 호환성 | 상호 운용성 | 회계 ERP나 경로 탐색 서비스와의 연동이 필요함. 워크플로 workflow 엔진을 공통 서비스로 구현하여 제공하고, 이를 각시스템과 연동해야 함 |
| 보안성 | 기밀성 | 역할 기반 액세스 제어 기능과 데이터 접근 권한 관리가 필요함 |
| 보안성 | 무결성 | 전자문서 및 전자거래기본법을 준수하여 증빙의 위·변조를 방지 해야 함 |
| 유지 가능성 | 분석성 | 시스템 장애나 애플리케이션 장애가 발생했을 때, 로그를 추적하여 원인을 명확히 파악할 수 있어야 함 |
| 유지 가능성 | 수정 가능성 | 변경 요구에 유연하게 대응할 수 있으며, 커스터마이징이 쉽고 변경이 용이해야 함 |
3.2.5 품질 속성 시나리오
시스템이 특정 환경이나 상황에서 구체적으로 어떻게 동작해야 하는지를 시나 리오 형식으로 기술하는 방법이 있으며, 이를 품질 속성 시나리오라고 합니다.
품질 속성 시나리오에서는 외부 입력(이벤트), 요청 주체, 적용 대상, 처리 결과, 결과 측정, 환경의 여섯 가지 요소를 사용하여 시나리오를 기술합니다.
표 3.4 무결성 품질 속성 시나리오 예시
| 시나리오 요소 | 요소 설명 | 사례 시나리오 |
|---|---|---|
| 외부 입력 | 시스템에 응답을 요구하는 이벤트 (예, 사용자 조작, API 호출) | 경비 정산 신청서에 증빙(영수증, 청구서) 으로 이미지 또는 PDF 파일 첨부 |
| 요청 주체 | 시스템에 외부 입력 주체(엔티티) | (예, 사용자, 시스템) |
| 적용 대상 | 외부 입력(증빙 첨부 요청)을 처리하는 시스템 또는 시스템의 일부 | 경비 정산 서비스 |
| 처리 결과 | 외부 입력의 결과로 시스템에 나타나는 관찰 가능한 동작 | 디지털 서명으로서 타임스탬프가 부여된 증빙 파일이 생성되고, 증빙 관리 서비스에 저장됨 |
| 결과 측정 | 산출물이 목표를 달성했는지 여부를 판단하기 위한 기준 | 신청 후 1시간 이내에 모든 첨부 증빙 파일에 타임스탬프가 부여됨 |
| 환경 | 시스템을 둘러싼 환경 조건 | 월말, 월초의 피크 타임 |
3.2.6 영향력 있는 기능 요구사항
[REQ-12] 그룹사별 사내 규정에 따라 신청서 항목과 입력 검증 방식을 커스터마이징할수 있다.
이 요구사항을 심층 분석한 결과, 그룹사 IT 담당자가 자사의 사내 규정에 맞춰 신청 화면의 항목을 직접 구성할 수 있는 기능이 필요했습니다.
구체적으로는 드래그 앤 드롭을 통해 항목의 정렬 순서를 변경하거나, 항목을 추가 및 삭제할 수있어야 하며, 경우에 따라 스크립트를 삽입하여 입력값의 유효성을 검증하는 기능도 요구되었습니다.
아키텍트는 비기능 요구사항뿐만 아니라 기능 요구사항도 면밀히 검토해야 합니다.
궁금한 점이 있으면 업무팀 담당자와 논의를 거쳐 요구사항을 심층적으로 파악해야 합니다.
3.2.7 그 외 영향을 미치는 요소
그중 하나가 아키텍트와 개발팀의 지식과 기술 수준 그리고 과거 경험입니다.
신기술을 도입할 때는 최소한의 검증을 거쳤는지 혹은 사내 다른 팀에서 사용한 사례가 있는지 사전에 리스크를 대비할 방안이 있는지 검토해야 합니다.
또한 아키텍트가 함수형 언어에 대한 깊은 지식을 가지고 있고 해당 기술이 도메인에 적합하더라도 팀원들이 객체 지향 언어만을 다룰 수 있어 개발팀을 구성할 수 없다면 이 역시 리스크가 될 수 있습니다.
기술 트렌드를 지속적으로 파악하는 것 역시 중요합니다.
특정 기술, 언어, 프레임 워크, 라이브러리가 인기를 얻는 데에는 그만한 이유가 있으며 이를 적절히 채택 하면 개발 프로세스를 개선하고 소프트웨어의 경쟁력과 품질을 높이는 효과를 기대할 수 있습니다.
갑자기 오픈소스 제품이 유지보수 지원이 중단되거나 라이선스가 유료로 전환될 가능성도 있는데 이 점도 고려해야 합니다.
뿐만 아니라 해당 기술에 대한 문서 정보가 충분하지 않거나 자료가 부족하여 예상보다 많은 개발 비용과 시간이 소요되는 경우도 있습니다.