소프트웨어 아키텍처 101 - CHAPTER 4 아키텍처 특성 정의
아키텍트는 개발팀과 함께 도메인 또는 비즈니스 요구사항을 정의할 수 있지만, 주로 소프트웨어로 처리할 일 중 도메인 기능과 직접적인 관련이 없는 모든 것들, 즉 아키텍처 특성(architectural characteristic)을 정의, 발견, 분석하는 일을 수행합니다.
아키텍처 특성은 다음 세가지 기준을 충족합니다.
- 비도메인(nondomain) 설계 고려 사항을 명시한다.
- 설계의 구조적 측면에 영향을 미친다.
- 애플리케이션 성공에 (절대적으로) 중요하다.
비도메인 설계 고려 사항을 명시한다.
아키텍처 특성은 요구사항을 구현하는 방법, 어떤 선택을 하게 된 이유와 관련된 운영/설계 기준을 명시합니다.
설계의 구조적 측면에 영향을 미친다.
프로젝트 담당 아키텍트가 아키텍처 특성을 서술하는 주된 이유는, ‘이 아키텍처 특성은 어떤 특별한 구조적 요소를 고려해야 하는가?’ 하는 설계 고려 사항 때문입니다.
애플리케이션 성공에 (절대적으로) 중요하다.
암묵적 아키텍처 특성은 요구사항 정의서에는 거의 안 나오지만 프로젝트 성공을 위해 꼭 필요한 특성들입니다. 아키텍트는 분석 단계에서 자신이 문제 영역에 대해 습득한 지식을 최대한 활용하여 아키텍처 특성을 밝혀내야 합니다.
4.1 아키텍처 특성 (일부) 목록
4.1.1 운영 아키텍처 특성
운영 아키텍처 특성(operational architecture characteristic)은 성능, 확정성, 탄력성, 가용성, 신뢰성 등의 능력을 말합니다(표 4-1).
표 4-1 운영 아키텍처 특성
| 용어 | 정의 |
|---|---|
| 가용성(availability) | 시스템이 얼마나 오랫동안 사용가능해야 하나? |
| 연속성(continuity) | 재해 복구 능력 |
| 성능(performance) | 스트레스 테스트(stress test), 피크 분석(peak analysis), 기능의 사용 빈도 분석, 필요 용량, 응답 시간. |
| 복구성(recoverability) | 비즈니스 연속성 요구사항(예를 들어, 장애 발생 시 얼마나 신속하게 시스템을 재가동시켜야 하나?). 백업 전략과 하드웨어 다중화 요건에 영향을 미친다. |
| 신뢰성(reliability)/안전(safety) | 시스템에 페일 세이프(fail-safe, 고장 났을 때 안전한 방향으로 흘러가도록 하는 설계 방식, 또는 그러한 기능을 담당하는 장치)가 필요한다? 즉, 페일 세이프가 시스템 가동에 필수인가? 시스템 실패 시 회사에 거액의 손실이 발생하는가? |
| 견고성(robustness) | 프로그램 실행 중 인터넷 접속 끊김, 정전, 하드웨어 실패 등 에러 및 경계 조건을 감당하는 능력 |
| 확장성(scalability) | 유저 수, 요청 수가 늘어나도 시스템이 그에 맞는 성능을 발휘하는 능력 |
운영 아키텍처 특성은 운영 및 데브옵스와 많은 부분에서 중첩되며, 많은 소프트웨어 프로젝트에서 이런 관심사는 교차점을 형성합니다.
4.1.2 구조 아키텍처 특성
아키텍트는 코드 구조에도 심혈을 기울여야 하며, 일반적으로 우수한 모듈성, 컴포넌트 간 커플링 제어, 가독성 높은 코드, 그 밖의 내부 품질 평가 등 코드 품질 문제를 전담(또는 공동으로 담당)합니다.
표 4-2 구조 아키텍처 특성
| 용어 | 정의 |
|---|---|
| 설정성(configurability) | 최종 유저(end user)가 (쓰기 편한 인터페이스를 통해) 소프트웨어 설정을 쉽게 바꿀 수 있는가? |
| 신장성(extensibility) | 새로운 기능을 삽입하는 일의 중요성 |
| 설치성(installability) | 필요한 모든 플랫폼에 시스템을 얼마나 손쉽게 설치할 수 있나? |
| 활용성(leverageability)/재사용(reuse) | 공통 컴포넌트를 여러 제품에서 활용할 수 있나? |
| 지역성(locality) | 데이터를 입력/조회하는 화면에서 다국어가 지원되는가? 리포트(report) 장표에서 멀티바이트 문자(multibyte character) 및 측정, 화폐 단위 등의 요구사항. |
| 유지보수성(maintainability) | 시스템을 얼마나 쉽게 변경/개선할 수 있나? |
| 이식성(portability) | 하나 이상의 플랫폼에서 시스템을 실행할 수 있나? (가령, 동일한 프런트엔드를 SAP DB와 오라클 데이터베이스에서 모두 실행할 수 있는가?) |
| 지원성(supportability) | 애플리케이션은 어느 정도의 기술 지원을 필요로 하나? 시스템에서 발생한 에러를 디버깅하려면 로깅 및 기타 기능이 어느 수준으로 뒷받침되어야 하나? |
| 업그레이드성(upgradeability) | 이 애플리케이션/솔루션의 구 버전을 새 버전으로 쉽고 빠르게 업그레이드할 수 있는가? |
4.1.3 아키텍처 공통 특성
따로 분류하기 어려운 아키텍처 특성
| 용어 | 정의 |
|---|---|
| 접근성(accessibility) | 색맹, 청각 장애인 등 모든 유저가 접근하는 데 불편함이 없나? |
| 보관성(archivability) | 데이터를 따로 아카이빙(archiving)해야 하나, 아니면 일정 시간 경과 후 삭제해야 하나? (예를 들어, 고객 계정은 3개월 후 삭제하거나 미사용 계정으로 표시하되 차후 해당 고객이 다시 접속할지 모르기 때문에 보조 데이터베이스에 아카이빙한다.) |
| 인증(authentication) | 유저가 본인이 맞다는 것을 증명하기 위해 필요한 보안 요구사항 |
| 인가(authorization) | (유즈 케이스, 서브시스템, 웹페이지, 비즈니스 규칙, 필드 레벨 등) 유저가 애플리케이션에서 정해진 기능만 사용할 수 있도록 강제하는 보안 요구 사항 |
| 합법성(legal) | 시스템 운영상 법적 제약조건이 있는가? (데이터 보호, 사베인스 옥슬리법(Sarbanes Oxley(미국의 회계 개혁에 관한 연방법률)), GDPR(유럽 연합 일반 데이터 보호 규칙) 등) 회사는 어떤 권리를 유보(reservation rights)해야 하나? 애플리케이션을 개발/배포하는 방법에도 따로 법적 규정이 있나? |
| 프라이버시(privacy) | 회사 내부 임직원의 트랜잭션을 외부에 드러내지 않는 기능(가령, 암호화 트랜젝션은 DBA나 네트워크 아키텍트도 해독 불가) |
| 보안(security) | 데이터를 암호화한 후 데이터베이스에 보관해야 하나? 내부 시스템 간 네트워크 통신도 암호화해야 하나? 원격 유저 액세스는 어떤 종류의 인증이 필요한가? |
| 사용성(usability)/성취성(achievability) | 유저가 애플리케이션/솔루션을 이용하여 원하는 목적을 달성하기 위해 필요한 교육/훈련 수준. 사용성 요구사항 역시 다른 아키텍처 이슈 못지않게 진지하게 다루어야 한다. |
4.2 트레이드오프 및 나쁜 것 중에서 제일 나은 아키텍처
시스템을 설계하며 모든 아키텍처 특성을 빠짐없이 최상으로 반영하기란 불가능에 가깝습니다. 아키텍트가 내린 결정은 상충되는 여러 문제들이 뒤얽힌 트레이드오프로 귀결되는 경우가 많습니다.
아키텍처 특성을 너무 욕심내면 모든 비즈니스 문제를 해결하려고 시도하는 일반적인 솔루션이 되어버립니다. 그러나 그런 아키텍처는 설계하기가 대단히 까다롭기 때문에 실현 가능성이 낮습니다.
아키텍트는 가능한 한 아키텍처 설계를 꾸준히 조금씩 반복해보는 게 좋습니다. 반복의 가치는 애자일 소프트웨어 개발에서도 가장 중요한 교훈 중 하나로, 아키텍처뿐만 아니라 모든 레벨의 소프트웨어 개발에도 적용됩니다.
요약
- 아키텍트의 역할
- 아키텍트는 개발팀과 함께 도메인 또는 비즈니스 요구사항을 정의할 수 있지만, 주로 도메인 기능과 직접적인 관련이 없는 아키텍처 특성을 정의, 발견, 분석하는 일을 수행한다.
- 아키텍처 특성은 다음 세 가지 기준을 충족한다:
- 비도메인 설계 고려 사항을 명시한다.
- 설계의 구조적 측면에 영향을 미친다.
- 애플리케이션 성공에 절대적으로 중요하다.
4.1 아키텍처 특성 (일부) 목록
4.1.1 운영 아키텍처 특성
- 가용성(availability): 시스템이 얼마나 오랫동안 사용 가능해야 하는가?
- 연속성(continuity): 재해 복구 능력.
- 성능(performance): 스트레스 테스트, 피크 분석, 기능 사용 빈도, 필요 용량, 응답 시간 등.
- 복구성(recoverability): 장애 발생 시 시스템을 얼마나 신속하게 재가동해야 하는가? 백업 전략과 하드웨어 다중화 요건에 영향을 미침.
- 신뢰성(reliability)/안전성(safety): 페일 세이프가 필요한가? 시스템 실패 시 회사에 거액의 손실이 발생하는가?
- 견고성(robustness): 인터넷 접속 끊김, 정전, 하드웨어 실패 등 에러 및 경계 조건을 감당하는 능력.
- 확장성(scalability): 사용자 수나 요청 수가 늘어나도 시스템이 성능을 유지하는 능력.
4.1.2 구조 아키텍처 특성
- 설정성(configurability): 최종 사용자가 소프트웨어 설정을 쉽게 변경할 수 있는가?
- 신장성(extensibility): 새로운 기능을 추가하는 일의 중요성.
- 설치성(installability): 필요한 모든 플랫폼에 시스템을 얼마나 쉽게 설치할 수 있는가?
- 활용성(leverageability)/재사용성(reuse): 공통 컴포넌트를 여러 제품에서 활용할 수 있는가?
- 지역화(localization): 데이터 입력/조회 화면에서 다국어가 지원되는가? 보고서에서 멀티바이트 문자, 측정 단위, 화폐 단위 등의 요구사항을 충족하는가?
- 유지보수성(maintainability): 시스템을 얼마나 쉽게 변경하거나 개선할 수 있는가?
- 이식성(portability): 하나 이상의 플랫폼에서 시스템을 실행할 수 있는가? (예: 동일한 프런트엔드를 SAP DB와 오라클 데이터베이스에서 모두 실행 가능한가?)
- 지원성(supportability): 애플리케이션은 어느 정도의 기술 지원을 필요로 하는가? 에러 디버깅을 위한 로깅 및 기타 기능은 어느 수준으로 제공되어야 하는가?
- 업그레이드성(upgradeability): 구 버전을 새 버전으로 쉽고 빠르게 업그레이드할 수 있는가?
4.1.3 아키텍처 공통 특성
- 접근성(accessibility): 색맹, 청각 장애인 등 모든 사용자가 접근하는 데 불편함이 없는가?
- 보관성(archivability): 데이터를 아카이빙해야 하나, 아니면 일정 시간 후 삭제해야 하나?
- 인증(authentication): 사용자가 본인임을 증명하기 위한 보안 요구사항.
- 인가(authorization): 사용자가 애플리케이션에서 허용된 기능만 사용할 수 있도록 하는 보안 요구사항.
- 합법성(legal compliance): 시스템 운영에 법적 제약 조건이 있는가? (예: 데이터 보호법, 사베인스 옥슬리법, GDPR 등)
- 프라이버시(privacy): 회사 내부 임직원의 트랜잭션을 외부에 드러내지 않는 기능. 예를 들어, 암호화된 트랜잭션은 DBA나 네트워크 아키텍트도 해독할 수 없음.
- 보안(security): 데이터를 암호화하여 데이터베이스에 보관해야 하는가? 내부 시스템 간 네트워크 통신도 암호화해야 하는가? 원격 사용자 액세스에 필요한 인증 방식은 무엇인가?
- 사용성(usability): 사용자가 애플리케이션을 이용하여 원하는 목적을 달성하기 위해 필요한 교육 및 훈련 수준은 어느 정도인가? 사용성 요구사항을 다른 아키텍처 이슈만큼 진지하게 다루어야 한다.
4.2 트레이드오프 및 나쁜 것 중에서 제일 나은 아키텍처
- 트레이드오프의 불가피성
- 모든 아키텍처 특성을 최상으로 반영하는 것은 불가능에 가깝다.
- 아키텍트의 결정은 상충되는 여러 문제들의 트레이드오프로 이어진다.
- 최고의 아키텍처보다는 최선의 선택
- 최고의 아키텍처를 고집하지 말고 나쁜 것 중에서 제일 나은 아키텍처를 선택해야 한다.
- 아키텍처 특성을 지나치게 욕심내면 실현 가능성이 낮은 일반적인 솔루션이 되어버린다.
- 반복적인 설계의 중요성
- 아키텍트는 아키텍처 설계를 꾸준히 조금씩 반복하며 개선해야 한다.
- 반복의 가치는 애자일 소프트웨어 개발에서 가장 중요한 교훈 중 하나이며, 아키텍처뿐만 아니라 모든 레벨의 소프트웨어 개발에 적용된다.