6장 - 아키텍처 스타일과 4+1 관점 완벽 가이드 (44)

아키텍처 스타일과 4+1 관점 완벽 가이드

들어가며

지난 포스팅에서 소프트웨어 아키텍처의 기본 개념과 품질 속성에 대해 알아보았습니다. 이번에는 실제로 시스템을 설계할 때 사용할 수 있는 구체적인 아키텍처 스타일들과 시스템을 바라보는 다양한 관점에 대해 깊이 있게 다뤄보겠습니다.

아키텍처 스타일이란?

아키텍처 스타일은 소프트웨어 시스템의 구조를 조직화하는 검증된 방법들입니다. 마치 건축에서 고딕 양식, 모던 양식 등이 있듯이, 소프트웨어에도 각각의 특징과 장단점을 가진 다양한 아키텍처 스타일이 존재합니다.

아키텍처 스타일을 사용하는 이유

• 개발 기간 단축: 검증된 패턴을 재사용하여 시행착오 최소화
• 품질 보장: 이미 검증된 구조로 안정성 확보
• 의사소통 개선: 팀원들이 공통된 이해를 바탕으로 협업 가능
• 유지보수 용이: 표준화된 구조로 인한 이해도 향상

주요 아키텍처 스타일

1. 데이터 중심형 스타일 (Repository Style)

특징

데이터 중심형 스타일의 핵심은 중앙 집중식 데이터 관리입니다. 모든 중요한 데이터가 리포지토리(저장소)에서 관리되고, 여러 서브시스템이 이 리포지토리에 접근하여 데이터를 읽고 쓰는 구조입니다.

구성 요소

• 리포지토리: 공유 데이터를 저장하고 관리하는 중앙 저장소
• 서브시스템: 리포지토리에 접근하여 업무를 처리하는 독립적인 모듈들

실무 적용 예시

은행 업무 시스템:

고객 정보 관리 시스템 ← → 중앙 데이터베이스 ← → 대출 관리 시스템
                                ↑
                              ↓
                         계좌 관리 시스템

• 고객의 계좌 정보, 거래 내역, 신용 정보 등이 중앙 데이터베이스에 저장
• 각 업무 시스템(대출, 예금, 카드 등)이 필요에 따라 데이터에 접근

장점과 단점

장점:

• 데이터 일관성 보장
• 대량의 데이터 효율적 관리
• 데이터 공유 용이

단점:

• 리포지토리와 서브시스템 간 높은 결합도
• 리포지토리 변경 시 전체 시스템 영향
• 성능 병목 지점 발생 가능

2. 클라이언트-서버 스타일

기본 개념

네트워크를 통해 서비스를 요청하는 클라이언트와 서비스를 제공하는 서버로 구성된 분산 시스템 아키텍처입니다.

서버의 특성

• 대기 상태: 클라이언트 요청을 기다리는 수동적 역할
• 서비스 제공: 요청을 처리하고 결과를 반환
• 동시 처리: 여러 클라이언트의 요청을 동시에 처리

실무 예시:

• 웹 서버: HTTP 요청을 받아 웹 페이지 제공
• 데이터베이스 서버: SQL 쿼리를 받아 데이터 반환
• 파일 서버: 파일 업로드/다운로드 서비스 제공

클라이언트의 특성

• 능동적 요청: 필요한 서비스를 서버에 요청
• 사용자 인터페이스: 사용자와 직접 상호작용
• 결과 처리: 서버로부터 받은 결과를 사용자에게 표시

비중에 따른 클라이언트-서버 분류

씬 클라이언트 (Thin Client) 스타일

클라이언트가 주로 화면 표시만 담당하고, 대부분의 처리가 서버에서 이루어지는 구조입니다.

특징:

• 클라이언트: 프레젠테이션 계층만 구현
• 서버: 비즈니스 로직 + 데이터 관리

적용 사례:

• 웹 애플리케이션 (브라우저가 씬 클라이언트)
• 클라우드 기반 오피스 도구 (Google Docs, Office 365)

장점: 클라이언트 관리 용이, 업데이트 간편
단점: 네트워크 의존성 높음, 서버 부하 집중

팻 클라이언트 (Fat Client) 스타일

클라이언트가 상당한 비즈니스 로직을 처리하고, 서버는 주로 데이터 저장소 역할을 하는 구조입니다.

특징:

• 클라이언트: 프레젠테이션 + 비즈니스 로직
• 서버: 데이터 관리

적용 사례:

• 데스크톱 애플리케이션 (Photoshop, AutoCAD)
• 모바일 앱의 오프라인 기능

장점: 응답성 좋음, 서버 부하 분산
단점: 클라이언트 관리 복잡, 배포 어려움

3. 계층 스타일 (Layered Style)

기본 개념

기능을 여러 계층으로 나누어 구성하는 아키텍처로, 각 계층은 특정 책임을 가지고 있으며 인접한 계층과만 통신합니다.

3-계층 아키텍처

데이터베이스를 활용하는 대부분의 시스템에서 사용되는 표준 구조입니다.

프레젠테이션 계층 (Presentation Layer)

역할: 사용자 인터페이스 담당
기술 예시:

• 웹: HTML, CSS, JavaScript, React, Vue.js
• 모바일: Swift, Kotlin, Flutter
• 데스크톱: WPF, JavaFX

비즈니스 로직 계층 (Business Logic Layer)

역할: 핵심 업무 규칙과 처리 로직 구현
기술 예시:

• Java Spring, .NET Core, Node.js Express
• 마이크로서비스 아키텍처에서는 각 서비스가 이 역할

데이터 계층 (Data Layer)

역할: 데이터 저장, 조회, 관리
기술 예시:

• RDBMS: MySQL, PostgreSQL, Oracle
• NoSQL: MongoDB, Redis, Elasticsearch

실무 적용 예시: 온라인 쇼핑몰

[프레젠테이션 계층]
↓ 상품 조회 요청
[비즈니스 로직 계층] - 재고 확인, 가격 계산, 할인 적용
↓ 데이터 조회
[데이터 계층] - 상품 정보, 재고 정보 조회

계층 스타일의 장점

• 높은 응집도: 각 계층이 명확한 책임을 가짐
• 낮은 결합도: 계층 간 독립성 보장
• 재사용성: 각 계층을 독립적으로 재사용 가능
• 유지보수성: 특정 계층만 수정하여 변경 영향 최소화

4. MVC 스타일 (Model-View-Controller)

기본 개념

사용자 인터페이스를 가진 애플리케이션을 세 개의 상호 연관된 구성 요소로 분리하는 아키텍처 패턴입니다.

구성 요소

Model (모델)

역할: 데이터와 비즈니스 로직 관리

• 데이터베이스와의 상호작용
• 비즈니스 규칙 구현
• 데이터 유효성 검증

View (뷰)

역할: 사용자 인터페이스 담당

• 모델의 데이터를 사용자에게 표시
• 사용자 입력 받기
• 다양한 형태의 출력 지원 (웹, 모바일, 출력 등)

Controller (컨트롤러)

역할: 사용자 입력 처리 및 모델-뷰 조정

• 사용자 요청 해석
• 적절한 모델 호출
• 결과를 적절한 뷰로 전달

MVC 동작 과정

1. 사용자 → 컨트롤러: 요청 전송
2. 컨트롤러 → 모델: 데이터 처리 요청
3. 모델 → 데이터베이스: 데이터 조회/수정
4. 데이터베이스 → 모델: 결과 반환
5. 모델 → 컨트롤러: 처리 결과 반환
6. 컨트롤러 → 뷰: 결과 데이터 전달
7. 뷰 → 사용자: 최종 결과 표시

실무 적용 예시: 블로그 시스템

사용자가 게시글을 조회하는 경우:

• Controller: 게시글 ID를 받아 조회 요청 처리
• Model: 데이터베이스에서 해당 게시글 정보 조회, 조회수 증가
• View: 게시글 내용을 HTML로 렌더링하여 사용자에게 표시

MVC의 장점

• 관심사 분리: 각 구성 요소가 독립적인 책임
• 병렬 개발: 프론트엔드와 백엔드 개발자가 동시 작업 가능
• 재사용성: 하나의 모델을 여러 뷰에서 사용 가능
• 테스트 용이성: 각 구성 요소를 독립적으로 테스트 가능

5. 데이터 흐름 스타일 (Pipe and Filter)

기본 개념

데이터가 일련의 처리 단계(필터)를 거치면서 변환되는 아키텍처입니다. 각 단계는 독립적이며, 파이프를 통해 연결됩니다.

구성 요소

• 필터: 데이터를 입력받아 처리한 후 출력하는 독립적인 모듈
• 파이프: 필터들을 연결하는 데이터 전달 통로

실무 적용 예시: 이미지 처리 시스템

원본 이미지 → [크기 조정 필터] → [밝기 조정 필터] → [압축 필터] → 최종 이미지

실무 활용 사례

• ETL 시스템: Extract → Transform → Load
• 컴파일러: 소스 코드 → 렉서 → 파서 → 최적화 → 코드 생성
• Unix 명령어: cat file.txt | grep "keyword" | sort | uniq

아키텍처의 4+1 관점

4+1 관점이란?

필립 크루첸(Philippe Kruchten)이 1995년에 제안한 아키텍처 문서화 방법으로, 복잡한 소프트웨어 시스템을 5개의 서로 다른 관점에서 바라보는 방법입니다.

1. 시나리오(유스케이스) 관점

특징

• 사용자 중심: 최종 사용자가 인식하는 시스템 기능에 초점
• 기능 명세: 시스템이 제공해야 하는 서비스 정의
• 다른 관점의 검증: 나머지 4개 관점이 올바르게 설계되었는지 검증

사용 다이어그램

• 정적 표현: 유스케이스 다이어그램
• 동적 표현: 순차 다이어그램, 활동 다이어그램

실무 예시: 온라인 뱅킹 시스템

주요 유스케이스:

• 로그인/로그아웃
• 잔액 조회
• 계좌 이체
• 거래 내역 조회
• 비밀번호 변경

2. 논리적(디자인) 관점

특징

• 내부 구조 중심: 시스템 기능을 제공하기 위한 내부 설계에 초점
• 클래스와 컴포넌트: 주요 구성 요소들과 그들 간의 관계 정의
• 설계 패턴: 재사용 가능한 설계 솔루션 적용

사용 다이어그램

• 정적 표현: 클래스 다이어그램, 객체 다이어그램
• 동적 표현: 상태 다이어그램, 순차 다이어그램

실무 예시: 전자상거래 시스템 클래스 설계

User 클래스 ←→ Order 클래스 ←→ Product 클래스
    ↓               ↓              ↓
ShoppingCart   OrderItem      Category

3. 개발(구현) 관점

특징

• 개발자 중심: 실제 구현을 담당하는 개발자의 관점
• 모듈 구성: 소스 코드, 라이브러리, 실행 파일 등의 구성
• 빌드 시스템: 컴파일, 패키징, 배포 과정 정의

사용 다이어그램

• 정적 표현: 컴포넌트 다이어그램
• 동적 표현: 순차 다이어그램, 활동 다이어그램

실무 예시: 마이크로서비스 컴포넌트 구성

User Service (user-service.jar)
↓
Order Service (order-service.jar)
↓
Payment Service (payment-service.jar)
↓
Notification Service (notification-service.jar)

4. 물리적(배치) 관점

특징

• 인프라 중심: 하드웨어와 네트워크 환경에 초점
• 배포 구성: 소프트웨어 구성 요소들이 어떤 하드웨어에 배치되는지 정의
• 성능과 확장성: 물리적 제약사항 고려

사용 다이어그램

• 정적 표현: 배치 다이어그램
• 동적 표현: 네트워크 통신 다이어그램

실무 예시: 클라우드 배치 구성

[로드 밸런서] 
    ↓
[웹 서버 클러스터] (Auto Scaling Group)
    ↓
[애플리케이션 서버] (Kubernetes Pods)
    ↓
[데이터베이스] (RDS Multi-AZ)

5. 프로세스 관점

특징

• 런타임 동작: 시스템이 실행될 때의 동적 행동에 초점
• 동시성과 동기화: 프로세스, 스레드 간의 상호작용
• 성능과 가용성: 시스템의 실행 시 특성

중요 고려사항

• 동시성 제어: 멀티스레드 환경에서의 안전성
• 통신 메커니즘: 프로세스 간 통신 방법
• 오류 처리: 실행 시 발생할 수 있는 예외 상황 처리

아키텍처 스타일 선택 가이드

프로젝트 특성에 따른 선택

데이터 중심적 시스템

적합한 스타일: 데이터 중심형, 계층형
예시: 은행 시스템, ERP, 데이터 웨어하우스

사용자 인터랙션이 중요한 시스템

적합한 스타일: MVC, 클라이언트-서버
예시: 웹 애플리케이션, 모바일 앱

배치 처리 시스템

적합한 스타일: 데이터 흐름 스타일
예시: ETL 도구, 로그 분석 시스템

분산 시스템

적합한 스타일: 클라이언트-서버, 마이크로서비스
예시: 클라우드 서비스, IoT 플랫폼

마무리

아키텍처 스타일과 4+1 관점은 복잡한 소프트웨어 시스템을 체계적으로 설계하고 문서화하는 강력한 도구입니다. 각 스타일의 특성을 이해하고 프로젝트의 요구사항에 맞는 적절한 스타일을 선택하는 것이 성공적인 시스템 구축의 핵심입니다.

다음 포스팅에서는 클래스 간의 관계와 UML 다이어그램을 통한 설계 표현 방법에 대해 알아보겠습니다. 연관, 일반화, 집합, 합성, 의존, 실체화 관계의 구체적인 사용법과 실무 적용 사례를 다룰 예정입니다.