아키텍처 스타일

[ 아키텍처 스타일이란 ]

건축에서 반복되는 유사한 패턴을 건축 양식이라 부르듯,

소프트웨어 설계에도 유사한 구조와 상호작용 패턴을

공유하는 시스템이 있다.

 

이때 아키텍처 스타일은

시스템을 구성하는 방식의 유형이며,

단순한 구조 모양이 아니라 다음을 함께 규정한다.

• 구성 요소 유형에 대한 설명
• 런타임 제어 방식
• 데이터 전송 패턴
• 컴포넌트 상호작용 방식과 그에 대한 제약

예를 들어 웹, ftp, 이메일 등은

클라이언트-서버 스타일로 설명할 수 있고

클라이언트-서버는 아키텍처 스타일의 한 종류다.

---

시스템 타입

개발할 시스템의 타입은

분석, 모델링, 설계, 구현, 테스팅 등

거의 모든 개발 작업에 영향을 준다.

 

따라서 아키텍처 스타일을 선택할 때도

시스템 타입을 먼저 고려하는 것이 효과적이다.

 

일반적으로 다음 네 가지로 나눈다.

시스템 타입	특징	설계 출발점
대화형 (interactive)	화면 흐름, 로그인/탐색/입력 반응이 중심	유스케이스 식별과 명세, 상태 흐름 모델링
이벤트 중심 (event-driven)	상태에 따라 이벤트 반응이 달라짐	상태 다이어그램, 상태 단위 설계
변환 (transformational)	입력을 여러 단계를 거쳐 변환해 출력 생성	처리 단계 분해, 데이터 흐름 설계
객체 영속 (object-persistence)	저장/검색/갱신이 핵심 능력	저장소 캡슐화, 데이터 구조와 접근 설계

 

스타일 선택 흐름도

[요구 파악]
   |
   v
[주요 성격이 무엇인가]
   |
   +--> 대화형 중심인가? ---------> MVC, 클라이언트-서버, 계층형
   |
   +--> 이벤트/상태 반응인가? ----> 이벤트 기반
   |
   +--> 단계적 변환/처리인가? ----> 파이프-필터
   |
   +--> 저장/검색/갱신이 핵심인가? -> 데이터 중심, 클라이언트-서버
   |
   +--> 중앙 없이 노드가 동등한가? -> Peer-to-Peer
   |
   +--> 기능 확장이 플러그인 중심인가? -> 마이크로커널

---

클라이언트-서버 스타일

네트워크로 연결된 개체는

클라이언트 또는 서버 역할을 가진다.

 

서버는 자원을 관리하고

클라이언트 요청에 따라 기능이나 자원을 제공한다.

 

클라이언트는 서버를 통해 간접적으로만 통신하며,

원격 접근을 통해 서비스를 이용한다.

[Client A] \
[Client B] ---> [Server] ---> (Data/Resources)
[Client C] /

파생 형태

• N-계층
  : 프레젠테이션, 처리, 데이터 관리 기능 분리
• 무거운 클라이언트
  : 클라이언트가 처리를 많이 담당
• 가벼운 클라이언트
  : 서버가 처리를 대부분 담당, 클라이언트는 UI 중심

장점

• 데이터 집중화로 관리와 백업/변경이 쉬움
• 요청 모니터링과 접근 제어로 보안 통제가 쉬움

단점

• 서버 병목 가능
• 비용 부담 가능
• 서버 장애에 취약

---

계층형 스타일

소프트웨어 기능을 수직으로

상호작용하는 여러 층으로 분할한다.

 

각 층은 바로 위나 아래층과만 메시지를 교환하며,

층의 역할이 명확할수록 구조가 안정된다.

 

예시 관점)

- 애플리케이션 서버 아키텍처
클라이언트 층, 웹 층,
비즈니스 컴포넌트 층, 엔터프라이즈 정보 층

 

- 통신 시스템
하위층이 신호 송수신을 제공하고,
상위층이 메시지 분할·재구성,
커넥션 처리, 응용 프로토콜 제공

[Presentation]
     |
[Application]
     |
[Business]
     |
[Data]

장점

• 추상화가 좋아 이해가 쉬움
• 캡슐화로 변경 영향이 줄어듦
• 재사용성과 교체 용이

단점

• 계층 구성 자체가 까다로울 수 있음

---

이벤트 기반 아키텍처

이벤트가 감지되고 처리되어야 하는

사건 중심 시스템에 사용한다.

 

이벤트 스트림을 만드는 이벤트 생산자와,

이벤트 수신을 위해 대기하는 이벤트 소비자로 구성된다.

 

이벤트는 발생 즉시 전달되어

소비자가 빠르게 응답할 수 있어야 한다.

 

특징

• 생산자와 소비자는 분리되어 서로를 직접 알지 못함
• 소비자는 서로 분리되며
  이벤트가 각 소비자에게 전달될 수 있음
• 상태 기반 처리가 많아 이벤트 종류와
  시스템 상태에 따라 처리 방식이 달라짐
• 특정 조건 만족 시 호출되는 콜백이 핵심 메커니즘이 됨

[Event Source] --> [Event Stream/Bus] --> [Consumer 1]
                                     \--> [Consumer 2]
                                     \--> [Consumer 3]

장점

• 생산자/소비자 분리로 캡슐화가 좋아짐
• 확장성이 좋음
• 즉시 반응 가능

단점

• 상태별 제어가 복잡
• 테스트 부담이 큼

---

MVC

사용자 인터페이스로부터 비즈니스 로직을 분리해,

시각적 요소와 비즈니스 로직이 서로 영향을 덜 주고

수정이 쉬워지도록 하는 스타일이다.

 

응용 프로그램을 모델, 뷰, 컨트롤러 3요소로 나눈다.

 

구성 요소 역할

• 컨트롤러
  모델 상태를 변경하는 명령을 보내고,
  뷰의 표시 방법도 바꾸게 할 수 있음
• 모델
  데이터 상태 변화 시 컨트롤러와 뷰에 통보
  또는 구현 방식에 따라 뷰/컨트롤러가 직접 읽기도 함
• 뷰
  사용자에게 보여줄 결과물을 생성하기 위해
  모델로부터 정보 획득

[User] -> [Controller] -> [Model]
               ^            |
               |            v
             [View] <--- (변화 통보)

장점

• 느슨한 결합
• 다양한 뷰 제공 가능
• 독립 개발이 쉬움

단점

• 전체 구조 이해가 어려울 수 있음
• 접근 방식에 따라 비효율 가능
• 구현 기술 요구가 늘어날 수 있음

---

파이프-필터

필터 사이에 데이터를 이동시키며

단계적으로 처리하는 구조다.

 

입력·출력과 데이터 변환을 수행하는 필터로 구성되며,

데이터는 파이프를 통해 한 방향으로 흐른다.

 

대표 사례

• 컴파일러
  문자 스트림을 토큰으로 변환, 구문 트리 작성,
  의미 분석, 코드 생성 등 단계 필터로 구성 가능
• 변형 형태로 일괄 처리도 있으며
  일괄 순차 처리와 달리 파이프-필터는
  데이터가 준비되는 즉시
  처리 시작과 병렬 필터링이 가능하다

[Input] -> (Filter 1) -> (Filter 2) -> (Filter 3) -> [Output]

장점

• 흐름이 명확
• 재사용/교체 쉬움
• 병렬 처리에 유리

단점

• 변환 오버헤드
• 오류 처리 어려움

---

데이터 중심 아키텍처

공유된 자료가 중요한 시스템에서 채택하는 스타일이다.

공유 데이터 저장소와 공유 데이터 접근자로 구성된다.

 

접근자는 저장소를 추가·삭제·수정하며,

접근자끼리는 직접 알지 못하고

공유 데이터 업데이트를 통해 간접적으로 통신한다.

 

범주에 포함되는 유형

• 블랙보드
  공유 데이터 변경 시 클라이언트에게 알림,
  옵서버 패턴과 결합
• 리파지토리
  클라이언트가 공유 데이터를 질의해
  변경 사항을 발견

[Accessor A] \
[Accessor B] ---> [Shared Repository] <--- [Accessor C]
[Accessor D] /

장점

• 낮은 결합
• 확장 용이

단점

• 단일 장애 지점 가능성

---

Peer-to-Peer 스타일

각 컴포넌트가 동등하며, 서비스를 요청하는

클라이언트가 될 수도 있고 제공하는 서버가 될 수도 있다.

 

어느 쪽이든 커뮤니케이션을 시작할 수 있고,

하드웨어 리소스 일부를 공유해 서비스나 콘텐츠를 제공한다.

블록체인 기술은 Peer-to-Peer 기반으로 설명할 수 있다.

[Node1]---[Node2]
   |\       /|
   | \     / |
[Node3]---[Node4]
   |         |
[Node5]---[Node6]

장점

• 전담 서버 없음
• 확장성과 신뢰성이 좋음

단점

• 보안/제어가 어려울 수 있음
• 성능 변동 가능

---

마이크로커널 스타일

확장성과 적응성이 뛰어나야 하는

소프트웨어 시스템에서 사용되는 스타일이며,

플러그인 아키텍처라고도 한다.

 

핵심 아이디어는

최소한의 핵심 서비스 세트인 마이크로커널과,

확장 기능을 제공하는 플러그인을 분리하는 것이다.

 

핵심 시스템에 영향을 주지 않고

새로운 기능을 추가할 수 있는 유연하고

확장 가능한 구성이 가능해진다.

 

구성 요소

• 마이크로커널
  필수 서비스를 제공하는 최소 핵심 기능
• 플러그인
  핵심 기능을 확장하는 추가 모듈
  독립적으로 추가·제거·교체 가능
• 어댑터
  코어와 플러그인 간 통신을
  용이하게 하는 인터페이스 층

(Plugin A) --\
(Plugin B) --- [Adapter] --- [Core System] --- [Adapter] --- (Plugin C)
(Plugin D) --/

장점

• 모듈성과 확장성이 좋음
• 유연성이 좋음
• 유지관리와 업데이트가 쉬움

단점

• 성능 오버헤드 가능
• 디버깅/테스트가 어려울 수 있음
• 자원 소모와 대기 시간 증가 가능

---

클린 아키텍처

클린 아키텍처는 유지보수, 확장성, 테스트 용이성을

높이기 위한 아키텍처 원리로, 시스템 컴포넌트가

프레임워크·유틸리티·UI 라이브러리·테스트 방법 등에 대해

독립적으로 개발·수정·배포될 수 있도록

구성하는 것을 목표로 한다.

 

제안하는 4계층

• 엔터프라이즈 비즈니스 규칙
  가장 핵심적인 비즈니스 규칙,
  상태와 규칙을 캡슐화
• 유스케이스
  제공 기능을 비즈니스 관점에서 기술,
  비즈니스 로직과 애플리케이션 로직이 구현됨
• 인터페이스 어댑터
  유스케이스와 외부 시스템 간
  데이터 변환 및 전달, 웹·DB·UI 포함
• 프레임워크와 드라이버
  DB, 웹 프레임워크,
  외부 API 같은 세부 구현 계층

[Frameworks/Drivers] -> [Interface Adapters] -> [Use Cases] -> [Entities]
(자주 바뀜)                                                     (덜 바뀜)

핵심 원칙

• 의존성 방향이 중요하다
• 덜 안정적인 요소가 안정적인 요소에 의존해야 한다
• 의존성은 항상 안쪽을 향해야 하며,
  안쪽 계층은 바깥쪽 계층에 대해 알지 못한다

---

[ 마무리 ]

아키텍처 스타일은 구성 요소의 형태, 런타임 제어,

데이터 전송 방식, 상호작용 제약을 포함하는 설계 유형이다.

 

시스템 타입을 먼저 분류한 뒤,

요구되는 상호작용 방식과

데이터 흐름에 맞는 스타일을 선택하면

설계의 일관성과 품질을 높일 수 있다.

 

최종 정리 표

스타일	강점 키워드	주의 키워드
클라이언트-서버	데이터 집중화, 보안, 모델링 용이	병목, 비용, 서버 장애 영향
계층형	추상화, 캡슐화, 재사용	계층 구성 난이도, 제한된 통신
이벤트 기반	확장성, 즉시 응답, 분리	상태 기반 복잡성, 테스트 부담
MVC	느슨한 결합, 다양한 뷰	구조 이해 난이도, 비효율 가능
파이프-필터	단순 흐름, 재사용, 병렬성	변환 오버헤드, 오류 처리 어려움
데이터 중심	낮은 결합, 확장 용이	단일 장애 지점
Peer-to-Peer	서버 없음, 신뢰성·확장성	보안, 중앙 제어 불가, 성능 변동
마이크로커널	모듈성, 유연성, 유지보수	성능 오버헤드, 복잡, 자원 소모