아키텍처 개념 (Concept of Architecture)
아키텍처는 구성 요소와 구성 요소 간의 통신에 관한 것으로, 클래스 수준 이상의 그루핑, 역할, 인터페이스를 정의하는 작업이다. 아키텍처는 다양한 수준에서 구성 요소의 역할과 구성 요소 간의 관계에 집중한다. 소프트웨어 적용 분야에 따라 아키텍처 유형이 결정되고 스타일을 기초로 아키텍처의 뼈대를 구성하고 필요한 구성 요소들을 추가하며 배치한다.
소프트웨어 아키텍처는 소프트웨어 시스템에서의 높은 추상 수준의 구성 요소를 의미한다. 소프트웨어 시스템과 비기능적 품질 요구 사항을 충족시키기 위해 좋은 아키텍처를 구성하는 것이 중요하다.
아키텍처 역할
아키텍처는 시스템의 구조를 확립하는 소프트웨어 개발에서 중심축으로, 소프트웨어 개발의 모든 단계에 영향을 주는 초기 의사 결정의 핵심이다. 아키텍처의 역할은 다음과 같다.
- `요구사항 분석`: 아키텍처에 제약사항을 반영한다.
- `아키텍처 설계`: 컴포넌트와 인터페이스를 정의하고 시각화한다.
- `상세 설계`: 아키텍처를 구성하는 컴포넌트의 내부를 설계한다.
- `구현`: 컴포넌트를 구현한다.
- `통합 및 시험`: 인터페이스를 시험한다.
아키텍처 표현
아키텍처 내의 불필요한 것들을 생략하고 중요한 문제에 관심을 집중시키려면, 아키텍처에서 컴포넌트를 블랙박스로 명시하고 외부에 보일 수 있는 구조적인 속성만 나타내야 한다.
이때, 아키텍처를 표현하는 가장 강력한 방법은 “계층적 분할”이다. 이는 표현된 컴포넌트를 상세 수준에 따라 더 자세히 나타내기 위해 분할하는 방법이다. 계층적으로 분할된 아키텍처는 수준에 따라 서로 다른 개발자들이 관심을 가지게 되고, 분석하고 설계하여 더 좋은 품질 목표를 설정할 수 있게 한다.
아키텍처 스타일 (Style of Architecture)
아키텍처 스타일이란 구성 요소 유형에 대한 설명, 런타임 제어, 데이터 전송에 대한 패턴을 나타낸 것으로, 아키텍처 유형을 정의하는 것이다.
클라이언트 서버형 아키텍처
클라이언트 서버 아키텍처는 컴퓨터 네트워크에서 역할을 “클라이언트”와 “서버”로 분리하여 구성하는 시스템 구조이다. 서버는 자원을 관리하며 클라이언트가 요청하는 기능이나 자원을 제공하고, 클라이언트는 사용자 시스템으로 자원의 사용을 위하여 서버를 접속하는 애플리케이션이다. 클라이언트와 서버는 물리적으로 다른 장소에 존재하여 원격 접근하여 통신한다.
클라이언트 서버형 아키텍처의 장단점은 다음과 같다.
- (장점) `데이터 집중화`: 모든 데이터는 서버에 모아 데이터의 구성과 관리를 단순화할 수 있다.
- (장점) `보안`: 클라이언트의 요청을 모니터링하고 기록할 수 있어서, 인증된 클라이언트만이 특정 서비스에 접근할 수 있도록 할 수 있다.
- (단점) `병목`: 서버와 통신하려는 클라이언트가 증가하면 서버의 부하도 증가하여 네트워크 속도가 저하된다.
- (단점) `비용`: 설치 및 관리 비용이 높다.
- (단점) `비강인성`: 서버가 고장 나면 복구될 때까지 클라이언트는 작동할 수 없다.
계층형 아키텍처
계층형 아키텍처는 소프트웨어의 기능을 역할 별로 분리된 여러 층으로 분할하고, 기능이 명확하게 정해진 각 층 사이에서 메시지를 교환한다. 이때, 각 층은 인접한 층과만 메시지를 송수신한다. 대부분의 통신 시스템은 계층형 시스템을 따르며, 대표적으로 OSI 7 계층 모델이나, TCP/IP 모델이 계층형 시스템이다.
계층형 아키텍처의 장단점은 다음과 같다.
- (장점) `추상화`: 시스템에 대해 좋은 추상적인 뷰를 제공하여, 각 층의 역할과 책임, 관계를 잘 이해할 수 있다.
- (장점) `캡슐화`: 자세한 데이터들이 각 층 안에 캡슐화되어 층 사이에 가정하거나 이해해야 할 사항이 적다. 즉, 각 층의 응집이 높고 층 사이의 결합은 적다.
- (장점) `재사용성`: 각 층의 의존도가 적어 쉽게 다른 모듈로 교환이 가능하며 다른 시스템에서 사용 가능하다.
- (단점) `구성의 어려움`: 이웃 층과의 커뮤니케이션이 제한적이며 결합력이 낮기에 시스템을 계층으로 구성하는 것이 쉽지 않다.
이벤트 기반 아키텍처
이벤트 기반 아키텍처는 비동기 메시지인 이벤트 스트림을 생성하는 “이벤트 생산자”와 이벤트를 수신 대기하는 “이벤트 소비자”로 구성된다. 이벤트는 실시간으로 전달되고 발생 즉시 소비자는 이벤트에 응답할 수 있어야 한다. 이벤트 기반 아키텍처는 발생된 이벤트의 종류와 현재 시스템의 상태에 따라 다른 처리를 하는 상태 기반 처리로 주로 이루어진다.
이벤트 기반 아키텍처의 장단점은 다음과 같다.
- (장점) 이벤트가 도착하는 즉시 소비자가 이벤트에 응답 가능하다.
- (장점) `캡슐화`: 이벤트의 생산자와 소비자가 분리되어 캡슐화된다.
- (장점) `확장성`: 시스템에 새로운 소비자를 쉽게 추가할 수 있다.
- (단점) `복잡성`: 상태에 따라 복잡하고 정교한 제어가 필요하다.
- (단점) `테스팅`: 각 상태에 허용된 이벤트가 제한적인 것을 정확히 테스트해야 한다. 허용되지 않은 이벤트에 대해서도 적절한 제어가 필요하다.
MVC (Model-View-Controller)
MVC는 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 스타일의 아키텍처이다. MVC는 응용 프로그램을 세 가지 구성요소로 나누며, 각각의 구성요소 사이에는 다음의 관계가 있다.
- `컨트롤러(Controller)`: 모델에 명령을 내림으로 모델의 상태를 변경할 수 있다. 사용자의 요청을 받아 처리의 흐름을 제어한다.
- `모델(Model)`:애플리케이션의 데이터와 비즈니스 로직을 담당한다. 데이터의 상태에 변화가 있을 때, 컨트롤러와 뷰에 통보한다.
- `뷰(View)`: 사용자에게 보여지는 UI를 담당하며, 모델로부터 정보를 얻어온다.
MVC 아키텍처의 장단점은 다음과 같다.
- (장점) `확장성`: 각 컴포넌트의 결합이 약하기에 다른 부분에 영향을 주지 않고 수정 가능하다.
- (장점) `다수의 뷰`: 하나의 모델을 위해 다수의 다른 뷰를 제공할 수 있고, 데이터와 비즈니스 로직이 분리되기에 코드 중복이 적다.
- (장점) `비동기`: 비동기 기술을 이용하여 애플리케이션을 빠르게 로딩 가능하다.
- (단점) `복잡도`: 컴포넌트의 분리로 인해 메커니즘 이해를 위한 복잡도가 올라간다.
- (단점) `비효율성`: 뷰에서 데이터를 접근해야 한다는 비효율적인 요소가 있다.
- (단점) 각 컴포넌트 구현을 위한 여러 가지 기술에 대한 이해도가 필요하다.
파이프 필터
파이프 필터 아키텍처는 필터 사이에 데이터를 이동시키며 단계적으로 처리하는 구조이다. 데이터는 파이프를 통해 단방향으로 흐른다. 파이프 필터 아키텍처의 장단점은 다음과 같다.
- (장점) `단순성`: 시스템을 일련의 입력, 출력, 변환으로 쉽게 볼 수 있다.
- (장점) `재사용`: 다른 응용 프로그램에서 필터를 쉽게 재사용하고 교체할 수 있다.
- (장점) `병렬성`: 병렬 처리로 구현하기 쉬운 아키텍처를 제공한다.
- (단점) `복잡도`: 컴포넌트의 분리로 인해 메커니즘 이해를 위한 복잡도가 올라간다.
데이터 중심 아키텍처
데이터 중심 아키텍처는 시스템이 데이터를 중심으로 구성되며, 모든 컴포넌트가 데이터를 공유하거나 처리하기 위해 상호작용하는 아키텍처이다. 데이터 중심 아키텍처에서는 공유 데이터 저장소와 공유 데이터 접근자, 두 가지 유형의 구성 요소로 분류된다.
- `공유 데이터 저장소`: 모든 데이터의 중심, 컴포넌트들이 여기로 접근한다.
- `공유 데이터 접근자`: 공유 데이터를 추가/삭제/수정한다.
데이터 중심 아키텍처의 대표적인 유형은 다음과 같다.
- `블랙보드 아키텍처`: 여러 컴포넌트가 공유 공간(블랙보드)에 데이터를 놓고, 서로의 결과를 기반으로 추론하거나 문제 해결한다. (Ex: 음성 인식)
- `레파지토리 아키텍처`: 중앙에 데이터 저장소가 있고, 여러 컴포넌트들이 여기에 읽고/쓰기를 통해 협력한다. (Ex: Github)
데이터 중심 아키텍처의 장단점은 다음과 같다.
- (장점) `낮은 결합`: 접근자 간 통신은 공유 데이터 저장소를 통해 이루어지기에 느슨한 결합을 유지한다.
- (장점) `확장성`: 각 접근자를 수정하고 확장하기 쉽다.
- (단점) `단일 장애지점`: 공유 데이터의 장애 시, 전체 장애 가능성이 존재한다.
Peer-to-Peer 스타일
P2P 아키텍처는 모든 참여자가 동등한 지위(Peer)를 가지며, 서버와 클라이언트의 구분 없이 서로 직접 데이터를 주고받는 분산형 구조이다. 각 컴포넌트는 하드웨어 리소스의 일부를 공유하고 서비스나 컨텐츨르 제공한다. 즉, 각 컴포넌트 자원 제공자이자 자원이다.
대표적으로 블록체인 기술은 Peer-to-Peer 아키텍처를 기반으로 한다. 보안을 해결하기 위해 각 노드가 상대방의 노드를 비교하고 감시하여 일관성을 유지한다.
Peer-to-Peer 아키텍처의 장단점은 다음과 같다.
- (장점) 전담하는 애플리케이션이나 서버가 없다.
- (장점) 컴포넌트에 고장이 있어도 전체 시스템은 가동된다.
- (단점) 중앙에서 제어할 수 없고 보안이 취약할 수 있다.
- (단점) 공유된 자원으로 성능이 떨어질 수 있다.
아키텍처 평가 (Architecture Evaluation)
아키텍처 평가는 소프트웨어 아키텍처나 디자인 패턴의 속성, 강점 및 약점을 결정하는 방법으로, 기능적 및 비기능적 품질 요구 사항을 모두 충족시키는지 보증하는 과정이다. 이를 통해 시스템에 대한 이해도가 증가하고 문서화하여 기존의 문제를 감지할 수 있다.
소프트웨어 아키텍처 평가를 위해 제안된 방법과 기술들은 다음과 같다.
SAAM (시나리오 기반 평가 방법)
관심 있는 일련의 시나리오에 대해 아키텍처를 조사할 수 있는 체계적인 수단을 제공한다. 시나리오를 기반으로 소프트웨어 아키텍처를 탐색하고 매핑하여 원하는 아키텍처 구성 요소와 해당 상호 작용을 찾아 시나리오를 통해 표현된 작업을 수행한다.
시나리오 기반 방법은 시나리오를 도출할 때, 여러 이해 당사자들을 통합하여 최종 사용자가 성능 문제를 나타낼 수 있도록 한다. 이때, 시나리오는 다음의 두 가지로 구분된다.
- `직접 시나리오`: 시스템 변경이 요구되지 않는 시나리오, 일반적인 유스케이스에 대한 아키텍처 지원의 평가 인터페이스에 의해 지원되는 보통 기능들에 대해 아키텍처를 평가한다.
- `간접 시나리오`: 시스템의 변경이 요구되는 시나리오, 새로운 장치 환경에 적응하는지, 아키텍처를 재구조화하거나 새로운 기능을 추가하거나 기능을 삭제할 때 아키텍처를 지원하는지 평가한다.
ATAM (속성 모델 기반 방법)
ATAM도 시나리오를 기반으로 아키텍처를 분석하지만 여러 가지 품질 속성에 더 초점을 맞추어 평가한다. 이를 통해 아키텍처의 설계 타협점(Trade-Off)을 찾아내고, 아키텍처 내부의 리스크를 발견한다.
ATAM의 진행 순서는 다음과 같다.
- 시스템 개발팀이 업무 배경과 요구 사항들을 설명하고 아키텍처에 대해 소개한다.
- 품질 특성 목표를 파악하고 이에 대한 우선순위와 시나리오를 작성한다. (유틸리티 트리)
- 아키텍처에서 품질 목표와 민감한 부분을 찾아낸다.
