서론

아키텍처 설계의 정의와 역할

• 소프트웨어 시스템의 전체 구조를 설계하는 과정.
• 주요 구성 요소와 그 구성 요소 간의 관계를 식별.

애자일 개발과 아키텍처 설계

• 초기 단계에서 전체 시스템 아키텍처 설계를 완료해야 함.
• 점진적인 아키텍처 개발은 실패 가능성이 높음.
• 아키텍처 리팩터링은 고비용이 발생.

시스템 아키텍처 예시: 패킹 로봇 시스템

• 로봇은 컨베이어에서 물체를 탐지하고, 종류를 식별하며, 적절히 포장 후 다른 컨베이어로 이동.
• 주요 구성 요소:
  • 비전 시스템: 물체 탐지 및 종류 식별.
  • 물체 이동 시스템: 물체를 컨베이어 간 이동.
  • 포장 시스템: 물체를 적절히 포장.

아키텍처 설계의 두 가지 추상화 수준

1. 작은 규모의 아키텍처: 프로그램을 구성 요소로 분해.
2. 큰 규모의 아키텍처: 여러 시스템, 프로그램, 프로그램 구성 요소를 포함. 엔터프라이즈 시스템은 분산될 수 있음.

소프트웨어 아키텍처의 중요성

• 시스템의 성능, 견고성, 분산 가능성, 유지보수성에 영향을 미침.
• 아키텍처는 비기능적 요구사항을 충족시키는 데 중요.

아키텍처 설계 및 문서화의 이점 (Bass, Clements, Kazman 2012)

1. 이해관계자 간 의사소통: 아키텍처는 시스템의 고수준 표현으로 다양한 이해관계자가 논의의 초점으로 삼을 수 있음.
2. 시스템 분석: 아키텍처 명시화는 성능, 신뢰성, 유지보수성 분석 가능.
3. 대규모 재사용: 아키텍처 모델은 시스템 구성과 컴포넌트 간 상호작용을 간결히 표현하고, 유사한 시스템 간 재사용 가능성 지원.

블록 다이어그램

• 블록 다이어그램: 아키텍처를 비공식적으로 모델링하는 도구.
  • 박스: 컴포넌트 표시.
  • 화살표: 데이터 및 제어 신호의 방향 표시.
    
• 장점: 직관적이고 이해하기 쉬움.
• 단점: 관계 유형이나 외부 속성을 표현하지 못함. 정밀한 아키텍처 문서화에는 ADP(Architectural Description Languages)가 필요.

아키텍처 모델 사용 목적

1. 시스템 설계를 위한 논의: 이해관계자와 시스템을 고수준으로 논의, 시스템 전체를 이해.
2. 설계된 아키텍처 문서화: 각 컴포넌트의 인터페이스와 연결 관계를 상세히 보여줌.

비공식 블록 다이어그램과 ADP 비교

• 비공식 블록 다이어그램: 직관적이지만 관계와 속성에 대한 오해 발생 가능.
• ADP: 관계 명확히 표현, 그러나 비용과 시간 소모가 크고 널리 사용되지 않음.

---

6.1 Architectural design decisions

아키텍처 설계

• 아키텍처 설계는 시스템의 기능적/비기능적 요구사항을 충족하는 시스템 구성을 창의적으로 설계하는 과정.
• 공식화된 절차는 없으며, 시스템 유형, 설계자의 경험, 요구사항에 따라 다름. 따라서, 설계를 결정의 연속으로 보는 것이 적절.

아키텍처 설계 시 주요 결정 사항

아키텍처 패턴 및 스타일

• 아키텍처 패턴: 시스템 구성에 대한 설명 (ex: 클라이언트-서버, 계층형 아키텍처).
  • 패턴은 다른 소프트웨어 시스템에서 사용된 아키텍처의 본질을 담음.
  • 선택 시, 강점과 약점을 이해하고 요구사항에 따라 적절히 사용.
• 구조 설계 요소:
  1. 적합한 구조적 스타일 선택 (ex: 클라이언트-서버, 계층형).
  2. 컴포넌트를 하위 컴포넌트로 분해할 전략 결정.
  3. 제어 모델링: 각 컴포넌트의 실행 제어 관계 정의.

비기능적 요구사항과 아키텍처 설계

1. 성능: 주요 작업을 소수의 컴포넌트로 집중화하고, 네트워크 대신 단일 컴퓨터에서 수행.
2. 보안: 중요한 자산을 내부 계층에 배치하고, 각 계층에 높은 수준의 보안 검증 적용.
3. 안전성: 안전 관련 작업을 소수의 컴포넌트에 집중화하여 실패 시 안전하게 종료 가능.
4. 가용성: 구성 요소 중복 설계로 시스템 중단 없이 교체와 업데이트 가능.
5. 유지보수성: 세분화된 독립 컴포넌트 설계로 변경 용이, 데이터 생산자와 소비자 분리

설계 평가

• 성능과 유지보수성 요구사항은 충돌할 수 있음. 해결책은 시스템의 부분별로 다른 아키텍처 패턴을 사용하는 것.
• 보안은 항상 중요한 요구사항이며, 다른 요구사항과 조화롭게 설계해야 함.
• 아키텍처 평가 방법: 참조 아키텍처 또는 일반적인 아키텍처 패턴과 비교.
  - Bosch (2000)의 비기능적 특성 설명을 통해 평가 가능.

---

6.2 Architectural views

아키텍처 모델의 사용 용도

1. 요구사항 및 설계 논의를 위한 초점 제공.
2. 디자인 문서화로 세부 설계 및 구현의 기초 제공.

4+1 View 모델 (Krutchen 1995)

• 단일 다이어그램으로 모든 시스템 정보를 표현할 수 없으므로, 다양한 관점(View)을 통해 아키텍처를 표현해야 함.

1. 논리적 관점: 시스템의 주요 추상화(객체 또는 클래스)와 요구사항 간의 관계.
2. 프로세스 관점: 런타임에서 상호작용하는 프로세스, 비기능적 특성 판단에 유용.
3. 개발 관점: 소프트웨어를 개발하기 위해 분해한 모습, 컴포넌트별 개발 책임 명확히.
4. 물리적 관점: 하드웨어 및 소프트웨어의 프로세서 배치, 시스템 배포 계획 시 유용.
5. 시나리오: 네 가지 관점을 연결하는 공통적인 사용 사례.

개념적 관점 (Hofmeister et al. 2000)

• 고수준 요구사항을 세부 사양으로 분해하기 위한 추상적인 관점.
• 재사용 가능한 컴포넌트 결정, 제품군 설계의 기반 제공.
• 이해관계자와 소통하거나 설계 결정을 지원하기 위해 주로 사용됨.

아키텍처 표현 방법

1. UML (Unified Modeling Language): 객체 지향 시스템 설계를 위한 언어. 아키텍처 설계에서 추상화 수준이 낮고, 상세 문서화나 모델 기반 개발에 적합.
2. ADL (Architectural Description Language): 컴포넌트와 연결 요소를 기반으로 한 전문 언어. 도메인 전문가가 이해하기 어려울 수 있음, 특정 도메인에 특화된 경우 유용.
3. 비공식적 모델: 빠르고 직관적인 표현. 이해관계자와 소통에 적합하며, 대부분의 소프트웨어 프로젝트에서 선호됨.

애자일 방식과 아키텍처 문서화

• 애자일 방법론에서는 상세 설계 문서가 시간과 비용 낭비로 간주됨.
• 완전한 문서화를 목표로 하기보다는 의사소통에 유용한 관점을 개발.
• 중요 시스템의 경우 예외적으로 상세 문서화가 필요할 수 있음.

---

6.3 Architectural patterns

아키텍처 패턴

• 패턴은 소프트웨어 시스템에 대한 지식을 표현, 공유, 재사용하는 방법으로 여러 소프트웨어 공학 분야에서 채택됨.
• 아키텍처 패턴은 이전 시스템에서 성공적으로 사용된 시스템 구성을 설명하며, 이 패턴이 언제 적합하고, 언제 부적합한지에 대한 정보도 포함함.

주요 아키텍처 패턴

1. 모델-뷰-컨트롤러 (MVC) 패턴

• 설명: 시스템의 상호작용 관리를 위한 아키텍처 패턴으로, 모델, 뷰, 컨트롤러를 분리하여 독립적으로 변경이 가능하게 함.
• 장점: UI와 데이터 처리 로직을 분리하여 유연성 제공.
• 적용 예시: 웹 시스템에서 사용자 인터페이스와 데이터 모델을 독립적으로 관리.

2. 계층화 아키텍처 (Layered Architecture)

• 설명: 시스템의 기능을 여러 계층으로 나누고, 각 계층은 바로 아래 계층의 서비스만 사용.
• 장점: 시스템의 변경과 확장이 용이하고, 다중 플랫폼을 지원하는데 유리함.
• 적용 예시: 데이터베이스, 애플리케이션, 사용자 인터페이스 등을 분리하여 각 계층에서 독립적으로 작업할 수 있음.

3. 저장소 아키텍처 (Repository Architecture)

• 설명: 데이터가 여러 컴포넌트 간에 공유되는 시스템 구조입니다. 공통 데이터 저장소를 사용하여 상호작용.
• 장점: 대규모 데이터를 관리하기에 효율적이며, 여러 컴포넌트 간 데이터 전송 없이 작업을 처리할 수 있음.
• 적용 예시: 데이터베이스와 같은 중앙 집중형 저장소를 활용하는 시스템.

4. 클라이언트-서버 아키텍처 (Client-Server Architecture)

• 설명: 서비스 제공자(서버)와 이를 이용하는 클라이언트로 구성된 분산 시스템 구조.
• 장점: 네트워크를 통해 분산된 시스템에서 서버와 클라이언트가 독립적으로 작업할 수 있음.
• 적용 예시: 웹 서버와 클라이언트 간의 상호작용 시스템, 예를 들어, 영화 및 사진 라이브러리 시스템.

5. 파이프와 필터 아키텍처 (Pipe and Filter Architecture)

• 설명: 데이터를 변환하는 여러 필터들이 파이프를 통해 연결되어 데이터를 처리하는 시스템.
• 장점: 데이터의 흐름이 명확하게 정의되어 있고, 배치 처리 시스템에 유용함.
• 적용 예시: 배치 처리 시스템 및 임베디드 시스템에서 주로 사용됨.

---

6.4 Application architectures

애플리케이션 아키텍처

• 애플리케이션 시스템은 비즈니스나 조직의 필요를 충족하기 위해 설계됨.
• 애플리케이션 아키텍처는 시스템 유형에 대한 공통된 구조를 제공함,
• 예로 실시간 시스템에서는 데이터 수집 시스템이나 모니터링 시스템과 같은 제네릭 아키텍처 모델이 존재.

애플리케이션 아키텍처 활용

1. 설계의 출발점: 익숙하지 않은 애플리케이션 유형을 설계할 때 제네릭 아키텍처를 기반으로 시작.
2. 설계 체크리스트: 기존 설계가 제네릭 아키텍처와 일치하는지 확인.
3. 팀 작업 조직: 구조적 특징을 식별해 병행 작업.
4. 구성 요소 재사용 평가: 재사용할 수 있는 구성 요소가 있는지 비교하여 확인.
5. 애플리케이션에 대한 어휘: 애플리케이션을 논의할 때 제네릭 아키텍처의 개념을 사용.

애플리케이션 시스템 유형

트랜잭션 처리 시스템

• 정의: 데이터베이스 중심의 시스템으로, 사용자 요청에 따라 정보를 처리하고 데이터베이스를 업데이트함.
• 특징: 사용자 행동이 서로 간섭하지 않도록 구성되어 데이터베이스의 무결성을 유지.
• 트랜잭션 아키텍처:
  1. 입력 컴포넌트
  2. 처리 컴포넌트
  3. 출력 컴포넌트
• 예시:
  

정보 시스템

• 정의: 웹 기반으로 데이터베이스 정보를 조회하고 수정하는 시스템.
• 예시:

• 다중 서버 시스템:
  - 높은 처리량을 가능하게 하여 분당 수천 개의 트랜잭션을 처리할 수 있음.
  - 수요가 증가함에 따라 각 레벨에서 서버를 추가하여 처리 능력을 확장할 수 있음.
  - 예시:
  1. 웹 서버: 모든 사용자 통신을 관리하며, 사용자 인터페이스는 웹 브라우저를 통해 구현.
  2. 애플리케이션 서버: 애플리케이션 특화 로직을 구현하고, 정보 저장 및 검색 요청을 처리합니다.
  3. 데이터베이스 서버: 데이터를 데이터베이스로 이동시키고 트랜잭션 관리를 담당합니다.

언어 처리 시스템

• 정의: 언어를 다른 형식으로 변환하는 시스템.
• 컴파일러 아키텍처:
  1. 어휘 분석기: 입력 언어 토큰 변환.
  2. 기호 테이블: 변수, 클래스 이름 저장.
  3. 구문 분석기: 문법 체크, 구문 트리 생성.
  4. 구문 트리: 프로그램 내부 구조.
  5. 의미 분석기: 의미적 정확성 체크.
  6. 코드 생성기: 기계어 코드 생성.
• 예시:

• 대체 아키텍처 패턴(repository and pipe and filter):
  - 컴파일러가 구조화된 편집기, 대화형 디버거 같은 도구와 통합되는 경우(예: Google Docs)에는 저장소(repository) 중심 모델이 더 적합.
  • 이 모델에서는 심볼 테이블과 구문 트리를 공유 저장소로 사용하며, 각 컴포넌트 간 변경 사항이 즉시 반영될 수 있도록 지원.

출처: Ian Sommerville - Software Engineering