한 줄 정의
아키텍처 특성은 도메인 기능성과는 독립적이면서도 시스템의 성공에 필수적이거나 중요한, 설계의 구조적 측면을 정의하는 역량(capability)입니다.
쉽게 말하면
소프트웨어를 만들 때 “무엇을 할 것인가”(기능 요구사항)만으로는 부족합니다. “어떻게 해야 하는가”도 결정해야 합니다.
설계 요구사항은 애플리케이션이 무엇을 해야 하는지, 어떻게 구현할지를 명시합니다. 반면에 아키텍처 특성은 요구사항을 왜 그렇게 결정하고 선택했는지를 명시합니다. 프로젝트가 성공하기 위한 운영 및 설계의 기준(criteria)입니다.
예를 들어, “주문 시스템을 만들어라”는 기능 요구사항이고, “초당 10,000건의 거래를 처리해야 한다”는 아키텍처 특성(성능)입니다.
왜 중요한가?
- 해결하는 문제: 아키텍트가 도메인 기능성 외에 시스템의 성공을 좌우하는 구조적 고려 사항들을 정의, 식별, 분석하는 체계적인 기준을 제공합니다.
- 이게 없다면: 요구사항만 충족하는 시스템을 만들더라도, 성능·확장성·보안 등의 운영 측면에서 실패하거나 유지보수가 불가능한 시스템이 됩니다.
핵심 내용
아키텍처 특성과 시스템 설계
어떤 요구사항이 아키텍처 특성으로 간주되려면 세 가지 기준을 모두 충족해야 합니다.
아키텍처 특성은 도메인과 무관한 설계 고려 사항을 명시합니다
소프트웨어 아키텍처의 구조적 설계는 아키텍트가 수행하는 두 가지 활동으로 구성됩니다.
하나는 문제 도메인을 이해하는 것이고, 다른 하나는 역량의 종류를 파악하는 것입니다.
이 두 활동의 조합에 의해 구조적 설계가 정의됩니다.
설계 요구사항 은 애플리케이션이 무엇을 해야 하는지 명시합니다.
반면에 아키텍처 특성 은 요구사항을 어떻게 구현할지, 그리고 어떤 사항을 왜 그렇게 결정하고 선택했는지를 명시합니다. 간단히 말해 아키텍처 특성은 프로젝트가 성공하기 위한 운영 및 설계의 기준(criteria)입니다.
예를 들어, 성능이 특정 수준 이상이어야 한다는 것은 하나의 아키텍처 특성이지만, 요구사항 문서에는 수록되지 않는 경우가 많습니다. “기술 부채를 방지해야 한다”라고 요구하는 것은 일반적인 설계 고려 사항이지만, 요구사항 문서에 이것이 명시된 경우는 보지 못했습니다.
아키텍처 특성은 설계의 구조적 측면에 영향을 미칩니다
아키텍트가 아키텍처 특성에 대한 관심사를 서술하려는 주된 이유는 그로부터 중요한 설계 고려 사항을 끌어내기 위해서입니다. 아키텍트가 아키텍처 특성을 설계만으로 구현할 수 있는가, 아니면 그 아키텍처 특성이 성공하기 위해 어떤 특별한 구조적 고려 사항이 필요한가를 따져야 합니다.
예를 들어, 보안 은 거의 모든 프로젝트에서 관심사이지만, 암호화·해싱·솔팅 같은 코딩 관행을 적용하는 것만으로 충분하다면 아키텍처 특성 수준이 아닌 설계 수준에서 해결됩니다. 반면 마이크로서비스 같은 분산 아키텍처라면 보안을 위한 특별한 구조적 지원 이 필요하므로 아키텍처 특성으로 승격됩니다.
아키텍처 특성은 애플리케이션 성공에 필수이거나 중요해야 합니다
하나의 애플리케이션이 아주 많은 수의 아키텍처 특성을 지원하는 것은 가능 하지만, 실제로 그렇게 해서는 안 됩니다. 시스템이 지원하는 아키텍처 특성이 늘어날수록 설계가 더 복잡해지기 때문입니다. 아키텍트가 아키텍처 특성을 가능한 한 적게(많이가 아니라) 선택하려고 노력해야 하는 이유입니다.
암묵적 특성 vs 명시적 특성
이 책은 아키텍처 특성들을 암묵적 특성(implicit attribute) 과 명시적 특성(explicit attribute) 으로 구분합니다.
| 구분 | 설명 |
|---|---|
| 암묵적 특성 | 요구사항 문서에 거의 등장하지 않지만, 프로젝트가 성공하는 데 꼭 필요한 특성입니다 |
| 명시적 특성 | 요구사항 문서나 기타 가이드라인 문서 등에 명시되어 있는 특성입니다 |
아키텍트는 분석 단계에서 문제 도메인에 대한 지식을 활용해서 암묵적 성격의 아키텍처 특성들을 찾아내야 합니다.
예를 들어, 고빈도 거래(high-frequency trading)에 주력하는 증권사라면 모든 시스템에서 저지연시간이 핵심이라는 것을 굳이 명시할 필요가 없을 수 있습니다. 해당 문제 도메인의 아키텍트들이 이미 그것이 얼마나 중요한지 알고 있기 때문입니다.
중요한 아키텍처 특성들
아키텍처 특성들은 낮은 수준의 코드 특성(모듈성 등)부터 정교한 운영상 관심사(확장성, 탄력성 등)까지, 복잡성의 광범위한 스펙트럼에 걸쳐 존재합니다.
아키텍처 특성은 엄청나게 많고 다양하므로 정량화하기는 어렵지만, 몇 가지 범주로 나누어 살펴볼 수 있습니다.
운영 아키텍처 특성
운영 아키텍처 특성(operational architecture characteristics) 에는 성능, 확장성, 탄력성, 가용성, 신뢰성 같은 역량들이 포함됩니다. 운영 및 데브옵스 관심사들과 크게 겹칩니다.
| 용어 | 정의 |
|---|---|
| 가용성 (availability) | 시스템이 얼마나 오랫동안 사용 가능한 상태를 유지해야 하는가 (예: 24/7) |
| 연속성 (continuity) | 시스템의 재해 복구 역량 |
| 성능 (performance) | 시스템이 얼마나 잘 수행되는지 (스트레스 테스트, 피크 분석, 응답 시간 등) |
| 복구성 (recoverability) | 비즈니스 연속성 요구사항. 재해 발생 시 얼마나 빨리 온라인 상태로 복구되는가 |
| 신뢰성/안전성 (reliability/safety) | 시스템이 실패했을 때 그 영향이 얼마나 치명적인가. 인명에 영향을 미치거나 큰 금전적 손실을 초래할 수 있는지의 여부 |
| 견고성 (robustness) | 실행 중 오류와 경계 조건을 처리하는 시스템의 역량 (예: 인터넷 연결 끊김) |
| 확장성 (scalability) | 사용자나 요청 수가 증가할 때 시스템의 수행 및 작동 능력 |
구조적 아키텍처 특성
| 용어 | 정의 |
|---|---|
| 설정성 (configurability) | 최종 사용자가 인터페이스를 통해 구성의 측면을 얼마나 쉽게 변경할 수 있는가 |
| 확장 능력 (extensibility) | 아키텍처가 기존 기능성을 확장하는 변경 사항을 얼마나 잘 수용하는가 |
| 설치성 (installability) | 모든 필수 플랫폼에 시스템을 설치하는 것이 얼마나 쉬운가 |
| 활용성/재사용 (leverageability/reuse) | 시스템의 공통 컴포넌트를 여러 제품에서 어느 정도나 활용할 수 있는가 |
| 현지화 (localization) | 데이터 필드의 입력/조회 화면에서 여러 언어를 지원하는 문제 |
| 유지보수성 (maintainability) | 변경 사항을 적용하고 시스템을 개선하는 것이 얼마나 쉬운가 |
| 이식성 (portability) | 시스템을 둘 이상의 플랫폼(오라클, SAP DB 등)에서 실행할 수 있는 능력 |
| 업그레이드성 (upgradeability) | 서버와 클라이언트에서 새 버전으로 업그레이드하는 것이 얼마나 쉽고 빠른가 |
클라우드 아키텍처 특성
클라우드 기반 컴퓨팅의 등장으로 대부분의 시스템이 최소한 어떤 형태로든 클라우드 기반 시스템과 상호작용합니다.
| 용어 | 정의 |
|---|---|
| 온디맨드 확장성 (on-demand scalability) | 수요에 따라 자원을 동적으로 확장하는 클라우드 제공업체의 능력 |
| 온디맨드 탄력성 | 리소스 수요가 급증할 때 클라우드 제공업체의 유연성. 확장성과 유사함 |
| 존 기반 가용성 | 컴퓨팅 존(zone)으로 자원을 분리해서 좀 더 복원력이 강한 시스템을 만드는 능력 |
| 지역 기반 개인정보보호 및 보안 | 다양한 국가와 지역(region)에 데이터를 합법적으로 저장하는 것과 관련한 능력 |
횡단적 아키텍처 특성
| 용어 | 정의 |
|---|---|
| 접근성 (accessibility) | 색맹이나 장애를 가진 사용자를 비롯해 모든 사용자가 시스템에 얼마나 쉽게 접근할 수 있는가 |
| 보관성 (archivability) | 지정된 기간 후 데이터를 보관하거나 삭제하는 것과 관련된 시스템의 제약조건 |
| 인증 (authentication) | 사용자가 본인이 주장하는 사람이 맞는지 확인하기 위한 보안 요구사항 |
| 권한 부여 (authorization) | 사용자가 애플리케이션 내에서 특정 기능에만 접근할 수 있도록 하는 보안 요구사항 |
| 법적 요건 | EU의 GDPR, 미국의 사베인스-옥슬리법 같은 법적 제약조건 |
| 개인정보보호 (privacy) | 내부 직원으로부터(심지어 DBA나 네트워크 아키텍트까지도) 트랜잭션을 암호화하고 숨기는 능력 |
| 보안 | 데이터베이스나 내부 시스템 간 네트워크 통신에서의 암호화, 원격 사용자 접근을 위한 인증/권한 부여 |
| 지원성 (supportability) | 애플리케이션이 필요로 하는 기술 지원 수준. 시스템의 오류를 디버깅하기 위해 로깅 및 기타 기능이 어느 정도까지 필요한지를 의미합니다 |
| 사용성/성취성 (usability/achievability) | 사용자가 애플리케이션/솔루션으로 목표를 성취하기 위해 필요한 교육 수준 |
아키텍처 특성의 목록은 필연적으로 불완전할 수밖에 없습니다. 어떤 소프트웨어 프로젝트든 유관 요인에 따라 아키텍처 특성을 새로 만들어낼 수 있기 때문입니다.
예를 들어 상호운용성(interoperability) 과 호환성(compatibility) 은 비슷해 보이지만, 상호운용성은 다른 시스템과의 통합이 얼마나 쉬운지에 관한 것이고 호환성은 업계 및 도메인 표준과 더 관련이 있어서 둘은 다릅니다. 또한 회사마다 같은 용어를 다른 의미로 사용하거나, 다른 용어로 같은 개념을 지칭하기도 합니다.
이런 범주들과 특성들을 완전하게 정의하는 표준 목록은 없지만, ISO가 주요 특성들을 역량별로 정리한 목록을 발표했습니다.
ISO의 아키텍처 특성 분류
ISO(International Organization for Standardization; 국제 표준화 기구)가 주요 특성들을 역량별로 정리한 목록을 발표했습니다. 몇 가지 주요 항목을 살펴보면 다음과 같습니다.
성능 효율성(performance efficiency)
알려진 조건에서 사용된 자원의 양을 기준으로 성능을 측정합니다.
- 시간 행동방식 — 응답/처리 시간
- 자원 활용 — 사용된 자원의 양과 유형
- 용량 — 설정된 최대 한계를 초과하는 정도
호환성
어떤 제품이나 시스템, 컴포넌트가 다른 제품, 시스템, 컴포넌트와 정보를 어느 정도나 교환할 수 있는가입니다.
- 공존성 — 다른 제품과 공통 환경 및 자원을 공유하면서 필요한 기능을 효율적으로 수행할 수 있는지
- 상호운용성 — 둘 이상의 시스템이 정보를 교환하고 활용할 수 있는 정도
사용성
사용자가 의도된 목적을 위해 시스템을 어느 정도나 효과적이고 효율적이며 만족스럽게 사용할 수 있는가를 나타냅니다.
- 적정성 인지 능력 — 사용자가 자신의 필요에 적합한지를 인식할 수 있음
- 학습성 — 사용자가 소프트웨어 사용법을 얼마나 쉽게 배울 수 있는가
- 사용자 오류 보호 — 사용자의 실수로부터 보호
- 접근성 — 아주 다양한 특성을 가진 사람들이 모두 소프트웨어를 사용할 수 있게 하는 것
신뢰성
시스템이 지정된 조건에서 지정된 기간 동안 어느 정도나 잘 작동하는지를 나타냅니다.
- 성숙도 — 정상 운영 중 요구사항 충족
- 가용성 — 운영 가능하고 접근 가능한지
- 내결함성 — 장애 상황에서도 의도한 대로 작동
- 복구성 — 영향받은 데이터를 복구하고 시스템의 원하는 상태를 재설정할 수 있는지
보안
사람이나 다른 제품 또는 시스템이 자신의 유형과 권한 수준에 적합한 정도로만 데이터에 접근할 수 있게 하는 것입니다.
- 기밀성 — 접근 권한이 있는 사람만 접근
- 무결성 — 무단 접근이나 수정 방지
- 부인 방지 — 행동이나 사건의 발생을 증명하는 능력
- 설명책임성 — 사용자의 행동을 추적하는 것
- 진정성 — 사용자의 신원을 증명하는 것
유지보수성
개발자가 소프트웨어를 개선하거나 바로잡거나 환경/요구사항의 변화에 적응시키기 위해 어느 정도나 효과적/효율적으로 소프트웨어를 수정할 수 있는지를 나타냅니다.
- 모듈성 — 개별 컴포넌트로 구성된 정도
- 재사용성 — 개발자가 하나 이상의 시스템에서 또는 다른 자산을 구축할 때 자산을 사용할 수 있는 정도
- 분석성 — 개발자가 소프트웨어에 대한 구체적인 지표를 얼마나 쉽게 수집할 수 있는 정도
- 수정성 — 개발자가 경함을 도입하거나 기존 제품 품질을 저하시키지 않고 소프트웨어를 수정할 수 있는 정도
- 테스트성 — 개발자와 다른 사람들이 소프트웨어를 얼마나 쉽게 테스트할 수 있는 정도
이식성
개발자가 시스템, 제품 또는 컴포넌트를 한 하드웨어, 소프트웨어 또는 기타 운영이나 사용 환경에서 다른 환경으로 어느 정도나 옮길 수 있는지를 나타냅니다.
- 적응성 — 개발자가 다른 또는 계속 바뀌는 하드웨어, 소프트웨어, 기타 운영 환경 및 사용 환경에 맞춰 소프트웨어를 효과적이고 효율적으로 적응시킬 수 있는 정도
- 설치성 — 지정된 환경에서 소프트웨어를 설치 또는 제거할 수 있는 정도
- 대체성 — 개발자가 다른 소프트웨어로 얼마나 쉽게 대체할 수 있는 정도
기능적 적합성(functional suitability)
이 특성은 제품이나 시스템이 지정된 조건에서 사용될 때 시스템의 기능들이 명시적/암묵적 요구사항들을 어느 정도나 잘 충족하는지를 나타냅니다.
- 기능적 완전성 — 기능들의 집합이 지정된 작업들과 사용자 목표들을 어느 정도나 많이 충족하는지
- 기능적 정확성 — 제품이나 시스템이 어느 정도나 정확한(요구된 정밀도를 기준으로) 결과를 제공하는지
- 기능적 적절성 — 기능들이 지정된 작업 및 목표의 달성을 어느 정도나 촉진하는지
기능적 적합성이 아키텍처 특성 목록에 속한다고 생각하기 쉽지만, 기능적 적합성은 아키텍처 특성을 설명하는 것이 아니라 소프트웨어 구축의 동기(motive) 와 관련한 요구사항을 설명한다고 봐야 합니다.
소프트웨어 아키텍처의 수많은 모호성
소프트웨어 아키텍처 활동 자체를 포함해서, 소프트웨어 아키텍처에 대한 많은 것은 그 정의가 명확하지 않습니다. 표준이 없다 보니 공통적인 개념이나 기법을 회사마다 다른 용어로 지칭하기도 하고, 더 나쁘게는 같은 용어를 완전히 다른 의미로 사용하다 보니 업계 전체가 혼란해지는 지경에 이릅니다.
아무리 원한다고 해도 소프트웨어 개발 세계에 어떤 하나의 표준 명명법을 강요할 수는 없지만, 용어와 관련한 오해를 피하는 노력은 필요합니다. 이를 위해 DDD에서는 조직 하나의 보편 언어(ubiquitous language) 를 장려해서 직원들이 사용하게 하려고 조언합니다.
정리와 ‘가장 덜 나쁜’ 아키텍처
아키텍트는 시스템의 성공에 필수이거나 중요한 아키텍처 특성만 지원해야 합니다.
모든 아키텍처 특성을 동시에 지원할 수 없는 이유는 다음과 같습니다.
- 아키텍처 특성에 대한 지원이 ‘공짜’인 경우는 거의 없습니다.
- 어떤 특성이든 아키텍트의 설계 노력과 개발자의 구현 및 유지보수 노력이 필요하며, 구조적 지원이 필요할 수도 있습니다.
- 아키텍처 특성들은 서로 상승작용(시너지)을 일으키며, 문제 도메인과도 상승작용을 일으킵니다.
- 우리의 바람과는 달리 설계의 각 요소는 다른 모든 요소와 상호작용합니다.
- 예를 들어 보안 을 개선하기 위해 뭔가를 수정하면 성능 에는 거의 확실히 부정적인 영향이 미칩니다.
- 아키텍처 특성에 대한 표준 정의가 없으므로 조직이 모호성과 싸워야 합니다.
- 업계 전체가 변치 않는 아키텍처 특성 목록을 만드는 것은 애초에 불가능합니다.
- 하지만 각 조직이 객관적인 정의를 가진 목록(즉, 보편 언어 )을 자체적으로 만드는 것은 가능한 일입니다.
- 지난 십 년간 아키텍처 특성의 수가 지속해서 증가할 뿐만 아니라 범주 자체도 많아졌습니다.
- 마이크로서비스 같은 아키텍처의 인기가 높아지면서, 아키텍트와 운영 팀이 더 집중적으로 협업해야 하는 경우가 많아졌습니다.
최고의 아키텍처를 추구하지 말고, 가장 덜 나쁜(least worst) 아키텍처를 목표로 하라. 나쁜 것 중에서 제일 나은 아키텍처를 목표로 하라.
너무 많은 아키텍처 특성을 지원하려고 하면 모든 비즈니스 문제를 해결하려는 범용 솔루션이 만들어집니다. 그러면 설계가 금세 다루기 어려워지므로, 그런 아키텍처는 제대로 작동하는 경우가 거의 없습니다.
아키텍트는 가능한 한 반복(iteration) 이 용이한 아키텍처를 설계하도록 노력해야 합니다. 아키텍처를 변경하기가 쉬우면, 첫 시도에서 정답을 찾아야 한다는 부담이 줄어듭니다. 애자일 소프트웨어 개발의 가장 중요한 교훈 중 하나는 반복의 중요성이며, 이 점은 아키텍처를 비롯해 소프트웨어 개발의 모든 수준에서 적용됩니다.
정리
암묵적 특성 vs 명시적 특성
| 기준 | 암묵적 특성 (Implicit) | 명시적 특성 (Explicit) |
|---|---|---|
| 출처 | 아키텍트의 도메인 지식과 경험 | 요구사항 문서, 설계 문서 |
| 요구사항 문서에 등장 여부 | 거의 등장하지 않음 | 명시되어 있음 |
| 발견 방법 | 경험 기반 분석 | 문서 분석 |
아키텍처 특성 범주 비교
| 범주 | 관심 대상 | 주요 이해관계자 |
|---|---|---|
| 운영 특성 | 성능, 확장성, 가용성, 복구성 | 운영 팀, 데브옵스 |
| 구조적 특성 | 모듈성, 유지보수성, 확장 능력 | 아키텍트, 개발자 |
| 클라우드 특성 | 온디맨드 확장성, 존 기반 가용성 | 클라우드 엔지니어, 운영 팀 |
| 횡단적 특성 | 보안, 접근성, 법적 요건 | 모든 이해관계자 |
내 생각
-
아키텍처 특성을 판별할 때 삼각형의 세 기준이 유용한 체크리스트 가 됩니다. 특히 “이것이 특별한 구조적 지원을 필요로 하는가?” 라는 질문이 핵심입니다. 같은 관심사(예: 보안)라도 아키텍처 스타일에 따라 설계 수준에서 해결될 수도 있고 아키텍처 특성으로 승격될 수도 있기 때문입니다.
-
아키텍처 특성의 용어가 조직마다 다르다는 점 은 실무에서 자주 겪는 문제입니다. 같은 팀 안에서도 “확장성”이 수평 확장을 의미하는지, 기능 확장을 의미하는지 다르게 해석할 수 있습니다. DDD의 보편 언어 처럼 팀 내에서 아키텍처 특성의 정의를 명확히 합의해두는 것이 중요합니다.
-
“가장 덜 나쁜 아키텍처” 라는 관점과 반복(iteration) 의 중요성은 서로 연결됩니다. 처음부터 완벽한 아키텍처를 만들 수 없다는 것을 인정하고, 변경하기 쉬운 아키텍처 를 설계하는 것이 더 현실적인 전략입니다.
관련 개념
출처
- 소프트웨어 아키텍처 The Basics, Ch04 아키텍처 특성의 정의