Architecture

Architecture

Architecture(아키텍처) 는 소프트웨어 시스템의 전체 구조와 구성 요소, 이들 간의 관계, 상호작용 방식을 정의하는 고수준 설계로 구성 요소들 간의 관계와 설계를 지배하는 원칙들을 실체화한 것이다. 아키텍처는 시스템의 품질 속성 (성능, 확장성, 보안 등) 을 결정하며, 기술 선택, 설계 패턴, 개발 표준, 의사결정 과정을 포괄한다. 컴포넌트와 커넥터로 구성되는 구조적 요소를 통해 시스템의 청사진을 제공하며, 품질 속성과 비기능적 요구사항을 충족시키는 설계 기준을 정의한다. 효과적인 아키텍처 설계는 복잡한 시스템의 유지보수성과 확장성을 보장하고, 다양한 이해관계자와의 소통, 리스크 관리, 장기적 진화 및 변화 대응의 기반이 된다.

핵심 개념

소프트웨어 아키텍처는 시스템의 구조와 설계를 정의하며, 구성 요소의 조직 방식, 상호작용, 설계 원칙 등을 포함한다. 이는 시스템의 품질 속성에 직접적인 영향을 미치며, 다양한 아키텍처 스타일과 패턴이 존재한다.

기본 개념

• 시스템 구조 (System Structure): 시스템을 구성하는 요소와 그들 간의 관계
• 컴포넌트 (Component): 시스템을 이루는 독립적 모듈이나 서비스로, 각기 고유한 역할과 책임을 가진다.
• 커넥터 (Connector): 컴포넌트 간의 상호작용을 담당하는 인터페이스나 프로토콜이다.
• 아키텍처 스타일 (Architecture Style): 시스템의 구조적 특성을 정의하는 일반적인 설계 접근 방식.
• 아키텍처 패턴: 특정 문제를 해결하기 위한 재사용 가능한 설계 솔루션. 예: MVC(Model-View-Controller), 레이어드 아키텍처 등.

심화 개념

• 아키텍처 특성 (Architecture Characteristics): 시스템의 성공 기준
• 아키텍처 결정 (Architecture Decision): 시스템 구축에 필요한 규칙
• 설계 원칙 (Design Principle): 아키텍처 설계를 위한 지침
• 품질 속성 (Quality Attributes): 시스템의 성능, 확장성, 보안성, 유지보수성 등과 같은 비기능적 요구사항.

배경

소프트웨어 시스템이 복잡해짐에 따라, 체계적인 구조와 설계가 필요하게 되었으며, 이를 위해 아키텍처 개념이 도입되었다. 아키텍처는 시스템의 품질 속성을 만족시키기 위한 기반을 제공한다.

목적 및 필요성

• 시스템 분석/설계의 체계적 접근
• 품질 속성 간의 상충관계 해결
• 개발 및 유지보수 효율성 향상
• 변경 요구사항에 대한 유연한 대응

주요 기능 및 역할

• 시스템 청사진 제공: 전체 시스템 구조의 시각화
• 의사결정 지원: 아키텍처 수준의 설계 결정 가이드
• 품질 보장: 비기능적 요구사항 충족
• 커뮤니케이션 도구: 개발팀 간 공통 이해 기반 제공
• 변경 관리: 시스템 진화와 확장성 지원

특징

• 추상화: 복잡한 시스템의 핵심 구조 표현
• 모듈성: 구성 요소의 독립적 개발 및 관리 가능
• 계층성: 다양한 추상화 수준의 뷰 제공
• 표준화: 설계 표현 수단의 일관성 확보
• 재사용성: 아키텍처 패턴의 반복 활용

핵심 원칙

아키텍처는 시스템의 구성 요소와 이들 간의 상호작용을 정의하여, 전체 시스템이 일관되게 작동하도록 한다. 이를 통해 시스템의 품질 속성을 만족시키고, 효율적인 개발과 유지보수를 지원한다.

SOLID 원칙

1. 단일 책임 원칙 (SRP): 하나의 클래스는 하나의 책임만 가져야 함
2. 개방 폐쇄 원칙 (OCP): 확장에는 열려있고 변경에는 닫혀있어야 함
3. 리스코프 치환 원칙 (LSP): 상위 타입을 하위 타입으로 교체 가능해야 함
4. 인터페이스 분리 원칙 (ISP): 클라이언트가 사용하지 않는 인터페이스에 의존하지 않아야 함
5. 의존성 역전 원칙 (DIP): 추상화에 의존해야 하며 구체화에 의존하면 안됨

아키텍처 설계 원칙

• 관심사 분리 (Separation of Concerns)
• 모듈화 (Modularity)
• 추상화 (Abstraction)
• 캡슐화 (Encapsulation)

소프트웨어 아키텍처 설계 단계별 절차 및 흐름

1. 요구사항 수집 및 분석: 기능적/비기능적 요구사항 파악
2. 아키텍처 설계: 구조와 구성 요소 정의
3. 패턴 적용: 적절한 아키텍처 패턴 선택
4. 문서화: 아키텍처 뷰와 결정 기록
5. 평가 및 검증: 품질 속성 만족도 평가
6. 구현 지원: 개발 과정 가이드 제공

graph TD
    A[요구사항 분석] --> B[아키텍처 설계]
    B --> C[아키텍처 패턴 선택]
    C --> D[컴포넌트 정의]
    D --> E[커넥터 정의]
    E --> F[아키텍처 문서화]
    F --> G[아키텍처 평가]
    G --> H[구현 및 배포]
    H --> I[모니터링 및 피드백]
    I --> A

주요 원리 및 작동 원리

계층화 원리 (Layering Principle)

• 상위 계층은 하위 계층의 서비스를 사용
• 각 계층은 특정 추상화 수준을 제공
• 계층 간 인터페이스를 통한 통신

이벤트 기반 원리 (Event-Driven Principle)

• 비동기 메시지를 통한 컴포넌트 간 통신
• 이벤트 생산자와 소비자의 분리
• 실시간 반응성과 느슨한 결합 달성

서비스 지향 원리 (Service-Oriented Principle)

• 독립적인 서비스 단위로 기능 분해
• 표준화된 인터페이스를 통한 서비스 간 통신
• 재사용 가능한 서비스 컴포넌트

작동 원리 다이어그램

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

┌─────────────────────────────────────────────────────────────┐
│                    아키텍처 스타일과 패턴의 작동 원리                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. 문제 식별 → 2. 패턴/스타일 선택 → 3. 설계 적용 → 4. 구현  │
│       ↓                ↓                ↓            ↓      │
│  ┌──────────┐   ┌──────────┐    ┌──────────┐  ┌──────────┐  │
│  │반복적인   │   │적절한     │    │구조적     │  │실제 코드  │  │
│  │설계 문제  │   │솔루션     │    │가이드라인 │  │구현      │  │
│  │발생      │   │패턴 매칭  │    │제공      │  │         │  │
│  └──────────┘   └──────────┘    └──────────┘  └──────────┘  │
│                                                             │
│                        피드백 루프                            │
│              ←────────────────────────────────────           │
└─────────────────────────────────────────────────────────────┘

구조 및 아키텍처

아키텍처 구조

graph TB
    subgraph "아키텍처 뷰"
        LV[논리적 뷰<br/>Logical View]
        PV[프로세스 뷰<br/>Process View]
        DV[개발 뷰<br/>Development View]
        PH[물리적 뷰<br/>Physical View]
        UV[유스케이스 뷰<br/>Use Case View]
    end
    
    subgraph "구성요소"
        C1[컴포넌트 1]
        C2[컴포넌트 2]
        C3[컴포넌트 3]
        CN1[커넥터 1]
        CN2[커넥터 2]
    end
    
    UV --> LV
    UV --> PV
    UV --> DV
    UV --> PH
    
    LV --> C1
    LV --> C2
    LV --> C3
    
    C1 --> CN1
    CN1 --> C2
    C2 --> CN2
    CN2 --> C3

구현 기법

장점과 단점

단점 해결 방법

• 점진적 아키텍처: 초기에는 단순하게 시작하여 필요에 따라 발전
• 아키텍처 리뷰: 정기적인 아키텍처 평가와 개선
• 프로토타이핑: 개념 검증을 통한 위험 감소
• 자동화: 아키텍처 준수 검증 도구 활용

도전 과제

분류 기준에 따른 종류 및 유형

실무 적용 예시

활용 사례

사례 1: 전자상거래 마이크로서비스

시나리오: 대규모 온라인 쇼핑몰에서 마이크로서비스 아키텍처를 적용한 사례
시스템 구성:

graph TB
    subgraph "클라이언트 레이어"
        Web[웹 애플리케이션]
        Mobile[모바일 앱]
        API[써드파티 API]
    end
    
    subgraph "API 게이트웨이"
        Gateway[API Gateway]
    end
    
    subgraph "마이크로서비스"
        User[사용자 서비스]
        Product[상품 서비스]
        Order[주문 서비스]
        Payment[결제 서비스]
        Inventory[재고 서비스]
        Notification[알림 서비스]
    end
    
    subgraph "데이터 저장소"
        UserDB[(사용자 DB)]
        ProductDB[(상품 DB)]
        OrderDB[(주문 DB)]
        Cache[Redis Cache]
    end
    
    subgraph "외부 서비스"
        PaymentGW[결제 게이트웨이]
        SMS[SMS 서비스]
        Email[이메일 서비스]
    end
    
    Web --> Gateway
    Mobile --> Gateway
    API --> Gateway
    
    Gateway --> User
    Gateway --> Product
    Gateway --> Order
    Gateway --> Payment
    Gateway --> Inventory
    
    User --> UserDB
    Product --> ProductDB
    Product --> Cache
    Order --> OrderDB
    
    Order --> Inventory
    Order --> Payment
    Payment --> PaymentGW
    
    Order --> Notification
    Notification --> SMS
    Notification --> Email

Workflow:

1. 사용자 주문 프로세스
   • 사용자가 상품을 장바구니에 추가
   • 재고 서비스에서 재고 확인
   • 주문 서비스에서 주문 생성
   • 결제 서비스에서 결제 처리
   • 알림 서비스에서 주문 확인 알림 발송
2. 서비스 간 통신
   • 동기 통신: REST API (주문 생성, 결제 처리)
   • 비동기 통신: 메시지 큐 (알림 발송, 재고 업데이트)
3. 데이터 일관성
   • 사가 패턴을 통한 분산 트랜잭션 관리
   • 이벤트 소싱으로 상태 변경 추적

각 서비스의 역할:

• 사용자 서비스: 인증, 프로필 관리
• 상품 서비스: 상품 정보 관리, 검색
• 주문 서비스: 주문 생성, 상태 관리
• 결제 서비스: 결제 처리, 정산
• 재고 서비스: 재고 관리, 예약
• 알림 서비스: 이메일, SMS 발송

사례 2: 쿠팡의 마이크로서비스 아키텍처 전환 사례

목표: 트래픽 증가 대응, 독립적 기능 확장
구성도:

graph LR
  User --> Gateway
  Gateway --> OrderService
  Gateway --> PaymentService
  Gateway --> ProductService
  OrderService --> OrderDB
  PaymentService --> PaymentDB
  ProductService --> ProductDB

워크플로우:

1. 사용자 요청 → API Gateway
2. 요청 라우팅 → 개별 서비스
3. 서비스 처리 후 응답 반환

담당 역할:

• Gateway: 인증 및 라우팅
• 각 서비스: 독립 기능 수행 및 자체 DB 접근
• 통합 관측 및 모니터링 체계 구축 (Grafana, Prometheus)

사례 3: 대형 이커머스 플랫폼의 아키텍처 설계

시스템 구성: 사용자, 주문, 결제, 상품 관리 등 각 도메인별 마이크로서비스, API 게이트웨이, 메시지 브로커, 모니터링 시스템
아키텍처 다이어그램

graph TD
  User-->|API|Gateway[API Gateway]
  Gateway-->|REST|Order[Order Service]
  Gateway-->|REST|Product[Product Service]
  Gateway-->|REST|Payment[Payment Service]
  Order-->|DB|OrderDB[(Order DB)]
  Product-->|DB|ProductDB[(Product DB)]
  Payment-->|DB|PaymentDB[(Payment DB)]
  Order-->|메시지|MQ[Message Broker]
  Product-->|모니터링|Mon[Monitoring]
  Payment-->|모니터링|Mon

Workflow

1. 사용자가 API Gateway 를 통해 주문 요청
2. Gateway 가 각 서비스에 요청 라우팅
3. 서비스 간 메시지 브로커로 이벤트 비동기 처리
4. 각 서비스는 독립적으로 DB/로직 관리, 장애 발생 시 격리
5. 모니터링 시스템으로 상태·성능 실시간 감시

역할: 확장성, 장애 격리, 빠른 배포, 비즈니스 변화 대응

사례 4: 글로벌 여행 예약 플랫폼 (예: Booking.com 스타일)

배경: 사용자 수백만 명이 동시 접속
다양한 기능: 항공권, 호텔, 렌터카, 리뷰, 결제 등
요구사항: 확장성, 장애 격리, 빠른 피처 롤아웃

적용된 아키텍처 스타일 및 패턴:

• 마이크로서비스 아키텍처 (Microservices Architecture)
• 이벤트 기반 아키텍처 (Event-Driven Architecture)
• CQRS (Command Query Responsibility Segregation)
• API Gateway + BFF (Backend For Frontend)

시스템 구성:

핵심 Workflow: 호텔 예약 처리

1. 사용자 → 검색 → Search Service → 캐시/ES 기반 검색
2. 선택 → 예약 요청 → Booking Service → Kafka → Payment Service
3. 결제 성공 시 → Booking → Kafka 발행 → Notification Service 로 이메일 발송

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

최적화하기 위한 고려사항

문제점과 해결방안

주제와 관련하여 주목할 내용

추가로 알아야 하거나 학습해야할 내용

용어 정리

참고 및 출처

공식 문서 및 표준 가이드

• C4 Model for Visualising Software Architecture
• Microsoft Azure Architecture Center
• AWS Well-Architected Framework
• AWS - What is Architecture Diagramming?
• Google Cloud - 마이크로서비스 아키텍처란?
• 마이크로서비스 아키텍처 스타일 - Azure Architecture Center
• 마이크로서비스란 무엇입니까? - AWS

아키텍처 설계 및 원칙 해설

• Martin Fowler - Software Architecture Articles
• Clean Architecture - Uncle Bob
• SOLID 원칙 정리 - Velog
• SOLID (객체 지향 설계) - 위키백과
• 개발자를 위한 SOLID 원칙 적용 - F-Lab

국내 기술 블로그 및 해설

• 개발자를 위한 ‘소프트웨어 아키텍처’ 개념과 활용법 - 요즘IT
• 소프트웨어 아키텍처 101 - DevOwen 블로그
• 소프트웨어 설계와 아키텍처의 차이점과 중요성 - F-Lab Insight
• 사례 기반 소프트웨어 아키텍처 2편 - 오픈소스컨설팅 테크블로그
• 소프트웨어 아키텍처 : 네이버 블로그

패턴 및 사례 요약

• 10가지 소프트웨어 아키텍처 패턴 요약 - mingrammer
• 레이어드 아키텍처 설명 - 6mini 블로그
• 8 Software Architecture Diagrams (+ Templates) - MiroBlog

글로벌 기술 커뮤니티 및 참고서

• The A-Z of Software Architecture - Tecnovy
• What is Software Architecture? - IEEE Computer Society
• Key Principles of Software Architecture Design - Tutorialspoint
• Architecture Diagram Basics & Best Practices - vFunction
• Understanding Key Software Architecture Diagram Patterns - Cloudairy
• The Eleven Defining Characteristics of Modern Software Architecture - Hackernoon