Brain핵심 인사이트
- 본질(Essence): 소프트웨어 아키텍처(Software Architecture)는 소프트웨어 시스템을 구성하는 요소들 간의 관계, 속성, 그리고 시스템의 설계 및 진화를 통제하는 기본 구조를 정의하는 분야이다. 이는 단순한 설계도를超越하여 시스템의 품질 속성(Performance, Security, Availability 등)을 결정하는 핵심 설계 결정의 모음이다.
- **가치(Value):**良好的 아키텍처는 시스템의 품질과 생명 주기에 결정적인 영향을 미친다. 아키텍처가 우수하면 요구사항 변경에 유연하게 대응할 수 있고, 시스템의 유지보수성이 향상되며, 투자 대비 효과를最大化할 수 있다.
- 융합(Convergence): 컴퓨터 과학(Computer Science), 시스템 공학(System Engineering), 관리 과학(Management Science)의 교차점에서 기술적 우수성과 경영적 효율성을 동시에 달성하기 위한 설계 철학이다.
Ⅰ. 소프트웨어 아키텍처의 정의와 중요성
소프트웨어 아키텍처에 대한 정의는 여러 학자와 기관에서 다양하게 제시하고 있다. IEEE(Institute of Electrical and Electronics Engineers, 전기전자기술자협회)는 IEEE 1471에서 소프트웨어 아키텍처를 '시스템을 구성하는 요소들 간의 관계와 외부에 드러나는 속성, 그리고 시스템의 설계와 진화를 통제하는 원칙'으로 정의하였다. 메리 쇼(Mary Shaw)와 데이비드 가란(David Garlan)은 '소프트웨어 아키텍처는 시스템의 구조적 요소와 그들 간의 관계로 구성되며, 이러한 구조가 시스템의 동작(Behavior)에 영향을 미친다'라고 설명한다.
1. 아키텍처가 시스템 품질에 미치는 영향
- 유지보수성(Maintainability): 잘 설계된 아키텍처는 요구사항 변경 시 영향을局部화하여 수정 비용을 줄인다.
- 확장성(Scalability): 아키텍처决定了 시스템이 어떻게 성장하고 확장될 수 있는지를 결정한다.
- 성능(Performance): 컴포넌트 간 통신 방식과 데이터 흐름 구조가 시스템의 응답 시간과 처리량에 영향을 미친다.
- 보안(Security): 아키텍처는 시스템의 공격 표면(Attack Surface)을 결정하고 보안 메커니즘의 배치에 영향을 미친다.
2. 아키텍처 결정의 영향 아키텍처 결정(Architecture Decision)은 시스템의 설계 방향을 결정하는 중요한 선택이며, 일단 결정되면 تغيير 비용이 매우 크다. 따라서 초기 단계에서 충분한 분석과 논의를 통해 합리적인 결정을 내리는 것이至关重要하다.
📢 섹션 요약 비유: 소프트웨어 아키텍처는 '도시의 기본 설계도'와 같습니다. 처음에 잘 설계되면 나중에 길을 넓히거나 새 건물을 지어도整体計画에 맞게 확장할 수 있지만, 엉터리로 설계하면 길을 파헤칠 때마다 전체 교통이 마비됩니다.
Ⅱ. 아키텍처의 구성 요소와 이해관계자
소프트웨어 아키텍처는 여러 핵심 요소로 구성되며, 다양한 이해관계자(Stakeholder)의 필요를 충족시키려 노력한다. 각 이해관계자는 서로 다른 관심사(Concern)를 가지고 있으며, 아키텍처는 이러한 다양한 관심사를 조율하는 균형점이다.
1. 핵심 구성 요소
- 구조(Structure): 시스템의 요소들과 그들 간의 관계를 정의한다. 계층 구조, 모듈화, 컴포넌트 배치 등이 포함된다.
- 속성(Attribute): 시스템이 가져야 할 품질 속성(Performance, Security, Reliability 등)을 명시한다.
- 결정(Decision): 아키텍처를 형성하는 주요 설계 결정과 그 근거를 기록한다.
- 관점(Viewpoint): 특정 이해관계자의 관심사에 따라 시스템을 바라보는 방식이다.
2. 이해관계자 유형
- 비즈니스 이해관계자: 경영진, 프로젝트 스폰서 - 비용, 일정, ROI에 관심
- 기술 이해관계자: 개발자, 아키텍트 - 기술적 실현 가능성, 확장성에 관심
- 운영 이해관계자: 시스템 관리자, DBA - 가용성, 관리 용이성에 관심
- 사용자: конечные 사용자 - 기능성, 사용 편의성에 관심
[ASCII 다이어그램: 소프트웨어 아키텍처 구성 요소와 이해관계자]
┌─────────────────────────────────────────────────────────────────────────────┐
│ 소프트웨어 아키텍처 구성 요소 │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ 시스템 (System) │ │
│ │ │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ 구조 │ │ 속성 │ │ 결정 │ │ │
│ │ │ (Structure) │ │ (Attribute) │ │ (Decision) │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ • 모듈화 │ │ • 성능 │ │ • 기술 선택 │ │ │
│ │ │ • 계층화 │ │ • 보안 │ │ • 패턴 적용 │ │ │
│ │ │ • 컴포넌트 │ │ • 가용성 │ │ • 표준 준수 │ │ │
│ │ │ 배치 │ │ • 유지보수성 │ │ • 제약 조건 │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ [이해관계자와 관심사] │
│ │
│ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ │
│ │ 비즈니스 │ │ 기술 │ │ 운영 │ │
│ │ 이해관계자 │ │ 이해관계자 │ │ 이해관계자 │ │
│ │ │ │ │ │ │ │
│ │ • 비용 절감 │ │ • 기술적 우수성│ │ • 시스템 안정성│ │
│ │ • ROI 달성 │ │ • 개발 생산성 │ │ • 관리 용이성 │ │
│ │ • 시장 대응 │ │ •创新能力 │ │ • 모니터링 │ │
│ │ 속도 │ │ │ │ • 장애 복구 │ │
│ └────────────────┘ └────────────────┘ └────────────────┘ │
│ │
│ ┌────────────────┐ │
│ │ 사용자 │ │
│ │ │ │
│ │ • 기능성 │ │
│ │ • 사용 편의성 │ │
│ │ • 반응 속도 │ │
│ └────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘
[설명]
1. 구조는 시스템의 뼈대를 형성하며, 모듈화와 계층화를 통해 시스템을 논리적으로 분할한다.
2. 속성은 시스템이 만족해야 할 품질 요건이며, 아키텍처 설계의 목표가 된다.
3. 결정은 구체적인 기술 선택과 설계 방향을 기록하며, 향후 유지보수 시 의사결정 근거가 된다.
4. 다양한 이해관계자의 상반된 관심사를 조율하는 것이 아키텍트의 핵심 역할이다.
📢 섹션 요약 비유: 소프트웨어 아키텍처의 구성 요소는 '오케스트라의 편성'과 같습니다. 관악기(구조), 현악기(속성), 지휘자의 결정(결정)이 조화를 이루어야美しい 음악(시스템 품질)이 나오며, 지휘자는 청중(이해관계자)이 음악을 즐길 수 있도록 모든 것을 조율합니다.
Ⅲ. 아키텍처 뷰(View)와 뷰포인트(Viewpoint)
아키텍처 뷰(View)는 특정 이해관계자의 관심사에 따라 시스템을 일정한 방향에서 바라본 것을 의미한다. 하나의 뷰만으로 시스템의 모든 측면을 표현하기는 불가능하므로, 다양한 뷰를 통해 시스템을全方位적으로描述한다. 뷰포인트(Viewpoint)는 특정 뷰를 작성하기 위한 기준과 규칙의 모음이다.
1. 뷰의 종류와 목적
- 논리 뷰(Logical View): 시스템의 기능적 요구사항을 충족하는 요소와 그들 간의 관계를 보여준다. 주로 최종 사용자와 비즈니스 분석가가 관심을 가진다.
- 프로세스 뷰(Process View): 시스템의 런타임 동작, 특히 병행성과 동기화 측면을 다룬다. 시스템 통합자와 성능 엔지니어가 관심을 가진다.
- 배포 뷰(Deployment View): 물리적 노드への 소프트웨어 배치를 보여준다. 시스템 관리자와 인프라エンジニアが関心を持つ。
- 구현 뷰(Implementation View): 모듈의 구조와 패키징, 빌드 관점을 다룬다. 개발자가 관심을 가진다.
2. 4+1 뷰 모델 필립 크루첸(Philippe Kruchten)이 제안한 4+1 뷰 모델은 4개의 핵심 뷰와 이를 검증하는 유스케이스 뷰를 결합한 모델이다.
- **논리 뷰(Logical):**最終ユーザー 관점의 기능적 설계
- 프로세스 뷰(Process): 시스템 통합자 관점의 동작 설계
- 구현 뷰(Implementation): 프로그래머 관점의 모듈 설계
- 배포 뷰(Deployment): 시스템 엔지니어 관점의 물리적 배치
- 유스케이스 뷰(Use Case): 모든 뷰를 연결하고 검증하는 중심
[ASCII 다이어그램: 4+1 뷰 모델 구조]
┌─────────────────────────────────────────────────────────────────────────────┐
│ 4+1 뷰 모델 (Kruchten's 4+1 View Model) │
│ │
│ ┌───────────────────────────────┐ │
│ │ 유스케이스 뷰 (+1) │ │
│ │ (Use Case / Scenarios) │ │
│ │ 모든 뷰의 검증 기준 │ │
│ └───────────────┬───────────────┘ │
│ │ │
│ ┌─────────────────────────────┼─────────────────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐ │
│ │ 논리 뷰 │ │ 프로세스 뷰 │ │ 배포 뷰 │ │
│ │ (Logical View) │ │ (Process View) │ │ (Deployment View) │ │
│ │ │ │ │ │ │ │
│ │ • 클래스 다이어그램│ │ • 액티비티 다이어그램│ │ • 배포 다이어그램│ │
│ │ • 객체 다이어그램 │ │ • 시퀀스 다이어그램 │ │ • 노드 다이어그램 │ │
│ │ │ │ • 상태 다이어그램 │ │ │ │
│ │ [최종 사용자] │ │ [시스템 통합자] │ │ [시스템 엔지니어] │ │
│ │ [비즈니스 분석가] │ │ [성능 엔지니어] │ │ [인프라 관리자] │ │
│ └───────────────────┘ └───────────────────┘ └───────────────────┘ │
│ │
│ ┌───────────────────┐ │
│ │ 구현 뷰 │ │
│ │(Implementation) │ │
│ │ │ │
│ │ • 컴포넌트 다이어그램│ │
│ │ • 패키지 다이어그램│ │
│ │ │ │
│ │ [프로그래머] │ │
│ │ [빌드 관리자] │ │
│ └───────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘
[설명]
1. 유스케이스 뷰는 중심 역할로서 시나리오를 통해 각 뷰의 무결성을 검증한다.
2. 논리 뷰는 '무엇을 제공하는가'에 초점을 맞추어 기능 구조를 설계한다.
3. 프로세스 뷰는 '어떻게 동작하는가'에 초점을 맞추어 런타임 동작을 설계한다.
4. 구현 뷰는 '어떻게 모듈화하고 패키징하는가'에 초점을 맞추어 코드 구조를 설계한다.
5. 배포 뷰는 '어디에 배치하는가'에 초점을 맞추어 물리적 구성을 설계한다.
📢 섹션 요약 비유: 4+1 뷰 모델은 '같은 건물에 대한 다른 관점의 사진'과 같습니다. 외부에서 찍은 전경 사진(배포 뷰), 내부 구조 사진(논리 뷰), 배선도(프로세스 뷰), 도면(구현 뷰)이 모두 필요하며, 이 모든 것이 실제 입주자 시나리오(유스케이스 뷰)로 검증되어야 합니다.
Ⅳ. 아키텍처 품질 속성 및 설계 원칙
소프트웨어 아키텍처의优劣은 시스템이 요구되는 품질 속성을 얼마나 잘 충족하느냐에 따라 결정된다. 품질 속성은 기능적 요구사항之外의 시스템 특성을描述하며, 아키텍처 설계의 주요 목표가 된다.
1. 주요 품질 속성
- 성능(Performance): 시스템의 응답 시간, 처리량, 리소스 활용도를 의미한다.
- 가용성(Availability): 시스템이 작동하고 있을 시간의 비율을 나타낸다.
- 보안(Security): 시스템이 무단 접근과 공격으로부터 보호되는 능력과다.
- 확장성(Scalability): 시스템이 workload 증가에 따라 처리 능력을 늘릴 수 있는 능력이다.
- 유지보수성(Maintainability): 시스템 변경이 얼마나 용이하게 이루어질 수 있는지를 나타낸다.
- 이식성(Portability): 시스템이 다른 환경으로 이동할 때의 용이성이다.
2. 아키텍처 설계 원칙
- 모듈화(Modularity): 시스템을 독립적인 모듈로 분할하여 응집도를 높이고 결합도를 낮춘다.
- 응집도(Cohesion): 각 모듈 내부의 요소들이 하나의 책임에 집중하는 정도이다.
- 결합도(Coupling): 모듈 간의 상호 의존성 정도이며, 낮을수록 좋다.
- 추상화(Abstraction): 복잡성을 관리하기 위해 불필요한 세부 사항을 숨기고 필수적 요소만 노출한다.
📢 섹션 요약 비유: 아키텍처 품질 속성은 '자동차의 성능 지표'와 같습니다. 최고 속도(성능), 고장 없이 달리는 시간(가용성), 도난 방지 장치(보안), 좌석 수 늘리기(확장성), 엔진 쉽게 수리(유지보수성) 등 모든 것이 설계(아키텍처)에서 결정됩니다.
Ⅴ. 아키텍처 문서화와 아키텍처 의사결정 기록
아키텍처는 명시적으로 문서화되어야만 효과적으로 공유되고 평가받을 수 있다. 아키텍처 문서화의 핵심은 아키텍처 의사결정(Architecture Decision)을 체계적으로 기록하는 것이며, 이는 ADR(Architecture Decision Record)로 수행된다.
1. 아키텍처 문서화의 원칙
- 적절한抽象화 수준: 모든 세부 사항을 나열하기보다 중요한 설계 결정과 그 근거에 집중한다.
- 이해관계자 대상: 문서의 수준과 표현 방식은 대상 독자를 고려해야 한다.
- 최신 상태 유지: 아키텍처가 변경되면 문서도 함께 업데이트되어야 한다.
2. ADR (Architecture Decision Record) 구조
- 제목(Title): 결정의 이름을 명확히 기술
- 상태(Status): 제안됨, 수락됨, 폐기됨 등
- 맥락(Context): 이 결정이 이루어진 배경과 제약 조건
- 결정(Decision): 실제로 선택된 방향
- 결과(Consequences): 결정의 긍정적/부정적 결과
3. 아키텍처 검토(Architecture Review) 아키텍처는 독립적인 검토를 통해其 타당성을 검증받아야 한다. ATAM(Architecture Trade-off Analysis Method)은 대표적인 아키텍처 평가 방법론이다.
📢 섹션 요약 비유: 아키텍처 문서화는 '게임의 룰북 작성'과 같습니다. 게임을 만드는 사람(설계자)만이 아니라 플레이하는 사람(개발자), 심판(감리인)도ルールを正確に理解する必要があります. ADR은 각 게임 규칙을 정할 때 왜 그렇게 정했는지 이유를 적어둔 메모와 같습니다.
📌 Knowledge Graph
-
핵심 개념 (Core Concepts)
- 소프트웨어 아키텍처: 시스템 구성 요소 간의 관계와 구조를 정의하는 설계
- 뷰(View): 특정 관점에서 본 시스템의 표현
- 뷰포인트(Viewpoint): 뷰를 작성하기 위한 규칙의 모음
- 품질 속성(Quality Attribute): 성능, 보안, 가용성 등 비기능적 요건
-
관련 표준 및 프레임워크 (Standards & Frameworks)
- IEEE 1471 / ISO/IEC 42010: 소프트웨어 아키텍처 명세 국제 표준
- ISO/IEC 25010: 시스템 및 소프트웨어 품질 모델
- TOGAF (The Open Group Architecture Framework): 기업 아키텍처 프레임워크
-
아키텍처 평가 방법론 (Architecture Evaluation)
- ATAM (Architecture Trade-off Analysis Method): 아키텍처 품질 속성 평가
- CBAM (Cost Benefit Analysis Method): 비용 대비 효익 분석
- SAAM (Software Architecture Analysis Method): 수정 용이성 평가
👶 어린이를 위한 3줄 비유
- 아키텍처는 레고 조립 설명서: 레고를 살 때 어떤 블록을 어디에 연결해야 하는지 그림으로 보여주는 설명서(뷰)와 같으며, 처음에 잘못 연결하면 나중에 다시 분리하기가 매우 힘듭니다.
- 품질 속성은、自転車の 성능: 자전거의 바퀴 수(확장성), 페달 접는 정도(유지보수성), 고장 빈도(가용성) 등이 설계(아키텍처)에서 결정되며,乘坐者的舒适度가 달라집니다.
- ADR은 맛집 후기: 맛집을 찾았을 때 '왜 이 식당을 선택했는지(결정)', '어떤 점이 좋았는지/아쉬웠는지(결과)'를 기록해두면, 다음에 다시 찾거나 다른 사람에게 추천할 때参考가 됩니다.