07a_아키텍처 설계와 패턴

1. 소프트웨어 아키텍처의 이해

1.1. 아키텍처의 개념

• 아키텍처 (Architecture)

  • 초기 의사결정의 핵심이며 시스템의 성패를 좌우한다.
  • 나중에 변경하기 어렵고, 시스템 개발에 필수적인 요소이다.

• 아키텍처 설계

  • 복잡한 소프트웨어를 서브시스템 수준의 덩어리(chunking)로 나누고, 구성 요소들의 역할·관계·인터페이스를 정의하는 작업이다.

• 아키텍처의 역할

  • 요구분석·설계·구현·통합·테스팅 전반을 관통하는 뼈대이다.
  • 기능 요구는 일반 설계로 구현되지만, 측정이 어려운 비기능적 품질 요구(유지보수성·확장성·성능)는 아키텍처가 결정한다.
  • UP(Unified Process)에서는 개발 초기부터 아키텍처를 확립하고 계속 발전시켜 나간다.

1.2. 아키텍처의 4가지 차원

1. 아키텍처 특성

   • 시스템이 지원해야 하는 측면
   • (확장성, 테스트 용이성, 가용성 등의 비기능 요구사항)

2. 아키텍처 결정

   • 장기적·중대한 영향을 주는 구조적 선택
   • (DB 종류, 통신 방법 등)

3. 논리적 컴포넌트

   • 시스템 기능의 구성 요소와 상호작용 방식
   • 잘 정의된 역할과 책임을 부여해야 한다.

4. 아키텍처 스타일

   • 시스템의 물리적 구조 형태
   • (마이크로서비스, 레이어드, 이벤트 기반 등)

1.3. 아키텍처 vs. 설계

두 패턴 모두 **소프트웨어 설계를 돕는 참조 모델(가이드라인)**이라는 공통점이 있지만, 적용되는 수준(Level)과 범위에서 큰 차이가 있다.

1. 아키텍처 패턴 (Architecture Pattern)

   • 상위 수준의 설계; 프로그램의 가장 큰 틀
   • 전체 시스템의 구조를 설계하기 위한 참조 모델

2. 디자인 패턴 (Design Pattern)

   • 하위 수준의 설계; 큰 틀 안에서 세부적인 기능들을 구현
   • 서브 시스템에 속하는 세부 컴포넌트들과 그들 간의 관계를 설계하기 위한 참조 모델

• 구분하는 스펙트럼 (3가지 기준)

  1. 전략적 vs. 전술적: 장기적 영향을 주는 전략적 결정일수록 아키텍처에 가까움
  2. 구축/변경 노력: 변경하기 어려울수록 아키텍처에 가까움
  3. 트레이드오프의 중대성: 중대할수록 아키텍처, 덜 중대할수록 설계에 가까움

• 두 패턴의 관계

  • 아키텍처 패턴이 전체적인 밑그림을 그리면, 그 밑그림 안의 세부적인 요소들을 디자인 패턴으로 채워 넣게 된다.
  • 따라서, 몇몇 디자인 패턴은 특정 아키텍처 패턴을 구현하는 데 매우 유용하게 사용되기도 한다.

2. 아키텍처의 표현과 모델링

2.1. 표현 방법과 다이어그램

• 아키텍처의 표현 방법

  • 좋은 아키텍처는 복잡한 시스템을 추상화해 간단히 요약한 것으로, 컴포넌트를 블랙박스로 두고 외부에 보이는 구조적 속성만 나타낸다.
  • 가장 강력한 방법은 계층적 분할로, 상세 수준에 따라 중요한 컴포넌트는 더 쪼개고, 덜 중요한 것은 분할하지 않는다.

• 아키텍처 다이어그램

  • 소프트웨어의 구조(사용자 인터페이스, 서비스, 데이터베이스, 통신 프로토콜 등)를 시각적으로 정의한다.

2.2. 패키지 다이어그램

• UML에서 서브시스템을 표현하는 수단으로, 관련 클래스를 의미 있는 그룹으로 묶는다. (Java의 package)
• 분할 기준은 기능적 관련성이며, 일관된 이름·하위 패키지 활용·순환 종속성 회피 등이 가이드이다.

3. 아키텍처 스타일 및 패턴

3.0. 시스템 타입

• 시스템의 타입이 아키텍처 스타일 선택에 영향을 준다.
  • 대화형 시스템
  • 이벤트 중심 시스템
  • 변환 시스템
  • 객체 영속 시스템

3.1. 아키텍처 스타일

• 아키텍처 스타일
  • 정의된 컨텍스트 안에 반복적으로 나타나는 설계 문제에 대한 개념적 솔루션

1. 클라이언트-서버

   • 요청/응답, 3-계층·thin/thick 파생
     • 서버가 자원 관리, 클라이언트가 요청
   • 데이터 집중화, 접근 검증
   • 서버 병목, 비용, 서버 장애 시 비강인성

2. 계층형

   • 인접 층(Layer)끼리만 통신
     • Presentation / Business / Persistence 계층 분리
   • 추상화, 캡슐화, 재사용성, 높은 응집
   • 계층 간 통신 제한적, 계층 구성이 까다로움

3. 이벤트 기반

   • 생산자-소비자 분리
     • Publisher → Event Channel → Subscriber
   • 확장성, 실시간 응답, 분산에 유리, 캡슐화
   • 복잡한 제어, 테스팅 어려움, 대규모 적용 곤란

4. MVC (Model-View-Controller)

   • Model-View-Controller 분리 (UI와 로직 분리)
   • 느슨한 결합, 다양한 뷰, 독립 개발, 확장성
   • 기술 복잡도 증가, 비효율(뷰만 데이터 접근)

5. 파이프-필터

   • 단계적 데이터 변환 (예: 컴파일러)
     • Pump → Filter → Pipe → Sink
   • 단순성, 재사용, 병렬성(병렬처리)
   • 시간/공간적 자원 낭비, 변환 오버헤드

6. 데이터 중심

   • 공유 저장소 + 접근자 (블랙보드/리포지토리)
   • 낮은 결합, 확장성
   • 단일 장애지점

7. Peer-to-Peer (P2P)

   • 각 노드가 클라이언트이자 서버 역할을 동시에 수행
   • 중앙집중 회피, 확장성, 신뢰성
   • 보안·성능·품질 보장 어려움, 중앙 제어 불가

8. 마이크로커널

   • 코어 + 플러그인 + 어댑터
   • 모듈성, 유연성, 유지관리 용이
   • 통신 오버헤드, 디버깅 어려움, 자원 소모

3.2. 아키텍처 패턴

• 클린 아키텍처
  • Robert C. Martin이 제안한, 유지보수·확장성·테스트 용이성을 높이는 아키텍처이다.
  • SOLID 원칙에 따라 프레임워크·UI·DB 등에 독립적으로 개발/배포할 수 있게 한다.
  • 안쪽부터 엔터프라이즈 비즈니스 규칙 → 유스케이스 → 인터페이스 어댑터 → 프레임워크/드라이버 4계층으로 구성되며, 핵심은 의존성 방향이다.
  • 자주 바뀌는(구체적인) 컴포넌트가 안정적인(추상적인) 컴포넌트에 의존하도록 해 시스템을 격리한다.

4. 디자인 패턴

4.1. 개념 및 적용 수준

• 디자인 패턴 (Design Pattern)

  • 아키텍처 스타일보다 낮은 수준, 즉 아키텍처 구성 요소 안의 상세 설계에서 반복적으로 발생하는 문제에 대한 검증된 모범 사례이자 재사용 가능한 솔루션이다.
  • (예: 객체 생성을 하나로 제한하면 싱글톤 패턴, 여러 객체의 직접 결합을 줄이면 중재자 패턴 사용)

• 적용 수준

  • 아키텍처 확정 후 컴포넌트를 구현하는 단계, 즉 클래스의 역할·동작을 정한 뒤 발생하는 설계 이슈에 대한 해법이다.
  • (예: 대화형 → MVC → 뷰 갱신 문제는 옵서버 패턴으로 해결)

4.2. 혜택 및 기술 형식

• 혜택

  • 재사용 용이,
  • 설계 작업 단순화,
  • 설계 지식 정리,
  • 공통 어휘를 통한 의사소통 향상,
  • 객체지향·SOLID 원칙 준수

• 기술 형식

  • 패턴 이름 / 소개 / 해결하는 문제 / 솔루션(클래스·상호작용 다이어그램 포함) / 예제 / 관련 패턴

4.3. GoF (Gang of Four) 디자인 패턴

• 생성 패턴 (Creational Pattern) 분류

  • 총 5가지 패턴으로 구성
  1. 싱글톤 (Singleton)
  2. 팩토리 메서드 (Factory Method)
  3. 추상 팩토리 (Abstract Factory)
  4. 빌더 (Builder)
  5. 프로토타입 (Prototype)

• 구조 패턴 (Structural Pattern) 분류

  • 총 7가지 패턴으로 구성
  1. 어댑터 (Adapter)
  2. 데코레이터 (Decorator)
  3. 브리지 (Bridge)
  4. 컴포지트 (Composite)
  5. 퍼싸드 (Facade)
  6. 플라이웨이트 (Flyweight)
  7. 프록시 (Proxy)

• 행위 패턴 (Behavioral Pattern) 분류

  • 총 11가지 패턴으로 구성
  1. 반복자 (Iterator)
  2. 상태 (State)
  3. 옵서버 (Observer)
  4. 책임 연쇄
  5. 커맨드
  6. 인터프리터
  7. 중재자
  8. 메멘토
  9. 전략(스트레티지)
  10. 템플릿 메서드
  11. 방문자

상세 설명은 08_디자인 패턴, 08a_디자인 패턴

5. 소프트웨어 아키텍처 평가 방법론

• 선택한 아키텍처가 기능적·비기능적 품질 요구를 충족하는지 보증하는 과정으로, 대표적으로 SAAM과 ATAM이 있다.

구분	SAAM	ATAM
목적	변경 용이성 평가	품질 속성 간 절충점 분석
참여자	주로 개발자·사용자	아키텍트·비즈니스 결정권자 포함
결과물	변경 비용·영향도	위험·절충점·민감도 목록

5.1. SAAM

소프트웨어 아키텍처 분석 방법 (Software Architecture Analysis Method)

• 최초로 체계화된 소프트웨어 아키텍처 평가 방법론이다.

• 시스템의 변경 용이성(Modifiability)과 기능성 평가에 집중한다.

• 특징

  • 시나리오 기반 평가: 사용자와 개발자가 참여하여 시스템이 직면할 상황 도출
  • 시나리오 분류: 직접 시나리오(아키텍처 변경 불필요) vs 간접 시나리오(아키텍처 변경 필요)
  • 변경 비용 예측: 간접 시나리오 실행 시 수정되어야 할 부분과 비용/난이도 예측

• 절차: 시나리오 추출 → 아키텍처 기술 → 시나리오 분류(직/간접) → 개별 평가 → 상호작용 검토 → 전체 평가

• 참고: 여러 간접 시나리오가 동일 모듈을 건드리면 해당 모듈의 응집도가 낮다는 신호 (리팩토링 필요)

5.2. ATAM

아키텍처 절충 분석 방법 (Architecture Tradeoff Analysis Method)

• SAAM의 한계를 보완하여 발전시킨 방법론이다.

• 여러 품질 속성(성능, 보안, 가용성 등)이 서로 충돌할 때, 상충 관계를 분석하여 아키텍처의 위험 요소(Risk)를 발견하고 최선의 절충안(Tradeoff)을 도출한다.

• 핵심 개념

  • 민감점(Sensitivity Point): 단일 품질 속성에 직접적 영향을 주는 지점 (예: 암호화 적용 → 보안성↑)
  • 절충점(Tradeoff Point): 여러 품질 속성에 동시 영향을 미쳐 상충 관계를 만드는 지점 (예: 암호화 적용 → 보안성↑, 성능↓)
  • 리스크(Risk) / 비리스크(Non-Risk): 향후 초래될 수 있는 위험 요소와 그렇지 않은 요소 분류

• 도구 및 산출물

  • 유틸리티 트리(Utility Tree): 품질 속성을 구체적 시나리오로 세분화하고 우선순위 부여
  • 산출물: 민감도·절충점·위험/비위험 목록 (예: “동기식 복제”가 가용성↑ 성능↓의 절충점)