Architecture and System Design

Architecture and System Design

소프트웨어 아키텍처와 시스템 아키텍처는 상호 보완적 관계에 있는 설계 개념이다. 시스템 아키텍처는 하드웨어, 네트워크, 소프트웨어 등 IT 시스템 전체의 구성요소와 상호작용을 통합적으로 설계하며, 소프트웨어 아키텍처는 소프트웨어 시스템의 구조, 컴포넌트, 인터페이스, 품질 속성에 집중한다. 설계 측면에서는 시스템 설계가 요구사항 분석 후 구체적인 시스템 사양을 결정하고, 소프트웨어 설계가 개별 모듈의 구현 세부사항을 다룬다. 이들은 상호 보완적으로 작용하여, 복잡한 IT 시스템의 품질, 확장성, 유지보수성, 효율성 확보에 필수적이다.

핵심 개념

graph TD
    %% 최상위 개념
    SystemArchitecture["시스템 아키텍처 (System Architecture)"]
    SoftwareArchitecture["소프트웨어 아키텍처 (Software Architecture)"]

    %% 시스템 아키텍처와 소프트웨어 아키텍처의 관계
    SystemArchitecture -->|포함| SoftwareArchitecture
    SystemArchitecture -->|구현 상세화| SystemDesign["시스템 설계 (System Design)"]
    SoftwareArchitecture -->|구현 상세화| SoftwareDesign["소프트웨어 설계 (Software Design)"]

    %% 아키텍처 스타일, 패턴, 설계 패턴
    SoftwareArchitecture -->|구성 원리| ArchitectureStyle["아키텍처 스타일 (Architecture Style)"]
    SoftwareArchitecture -->|구성 원리| ArchitecturePattern["아키텍처 패턴 (Architecture Pattern)"]
    SoftwareDesign -->|구현 기법| DesignPattern["설계 패턴 (Design Pattern)"]

    %% 아키텍처 스타일과 패턴의 관계
    ArchitectureStyle -->|구체화| ArchitecturePattern

    %% 설명 노드
    classDef concept fill:#f9f,stroke:#333,stroke-width:1px;
    classDef relation fill:#fff,stroke:#333,stroke-width:1px,font-style:italic;

    class SystemArchitecture,SoftwareArchitecture,SystemDesign,SoftwareDesign,ArchitectureStyle,ArchitecturePattern,DesignPattern concept;

• 시스템 아키텍처는 시스템 전체의 구조와 원리를 정의하며, 그 하위에 소프트웨어 아키텍처가 있다.
• 시스템 설계는 시스템 아키텍처를 바탕으로 전체 시스템의 상세 구현 방안을 설계한다.
• 소프트웨어 설계는 소프트웨어 아키텍처를 바탕으로 소프트웨어 내부의 상세한 구현을 설계한다.
• 아키텍처 스타일은 소프트웨어 아키텍처의 구조적 특성을 정의하는 상위 개념이며, 여러 아키텍처 패턴을 포괄한다.
• 아키텍처 패턴은 소프트웨어 아키텍처의 구체적인 구조와 규칙을 제공한다.
• 설계 패턴은 소프트웨어 설계 단계에서 코드 수준의 반복적 문제를 해결하는 구체적 방법이다.

개요

소프트웨어 아키텍처와 시스템 아키텍처는 모두 시스템의 구조를 정의하지만, 그 범위와 초점에서 차이가 있다. 소프트웨어 아키텍처는 소프트웨어 시스템의 내부 구조와 구성 요소 간의 관계를 중점적으로 다루며, 시스템 아키텍처는 하드웨어, 소프트웨어, 네트워크 등 전체 시스템의 구성 요소와 그 관계를 포괄적으로 다룬다.

주요 기능 및 역할

각 아키텍처는 서로 다른 수준에서 시스템의 구조와 동작을 정의한다.

특징

두 아키텍처는 공통적인 설계 원칙을 공유하지만 적용 범위와 구체성에서 차이를 보인다.

• 추상화 (Abstraction): 복잡한 내부 구현을 숨기고 핵심 개념이나 동작만을 노출하여 시스템을 단순하게 표현하는 설계 기법이다. 설계의 복잡도를 줄이고 이해도를 높이는 데 기여한다.
• 모듈성 (Modularity): 시스템을 독립적이고 재사용 가능한 여러 구성 요소 (모듈) 로 나누어 관리하는 설계 원칙이다. 변경 영향 최소화와 병렬 개발, 테스트 용이성 확보에 효과적이다.
• 계층성 (Layering): 기능과 책임을 계층 (Layer) 으로 구분하여 상위 계층은 하위 계층의 내부 구조에 의존하지 않고 추상화된 인터페이스만을 사용하는 구조이다. 유지보수성과 책임 분리에 유리하다.
• 확장성 (Scalability): 시스템이 사용량 증가나 기능 확장 요구에 따라 성능 저하 없이 수평 (노드 추가) 또는 수직 (리소스 증가) 으로 확장될 수 있는 능력을 의미한다. 특히 고가용성, 트래픽 대응에 중요하다.

핵심 원칙

SOLID 원칙과 DRY 원칙은 주로 소프트웨어 아키텍처에 적용되며, 시스템 아키텍처는 더 광범위한 시스템 설계 원칙을 따른다.

소프트웨어 아키텍처 설계 원칙

• SOLID 원칙
  • 단일 책임 원칙 (Single Responsibility Principle): 클래스나 모듈은 하나의 책임만 가져야 함
  • 개방 - 폐쇄 원칙 (Open-Closed Principle): 확장에는 열려있고 수정에는 닫혀있어야 함
  • 리스코프 치환 원칙 (Liskov Substitution Principle): 파생 클래스는 기본 클래스를 대체할 수 있어야 함
  • 인터페이스 분리 원칙 (Interface Segregation Principle): 클라이언트는 불필요한 의존성을 가지면 안됨
  • 의존성 역전 원칙 (Dependency Inversion Principle): 고수준 모듈은 저수준 모듈에 의존하면 안됨
• DRY 원칙 (Don’t Repeat Yourself): 코드나 로직의 중복을 제거하여 유지보수성을 높임
• KISS 원칙 (Keep It Simple, Stupid): 복잡성을 피하고 단순하고 이해하기 쉬운 설계를 추구

시스템 아키텍처 설계 원칙

• Separation of Concerns (관심사의 분리): 각 기능이나 도메인을 명확히 분리하여 독립적으로 관리할 수 있도록 함. 시스템 복잡도 감소와 변경 영향 최소화.
• Resilience Design (탄력성 설계): 장애나 예외 상황에서도 시스템이 자동 복구하거나 최소 기능을 유지할 수 있도록 설계. 예: Retry, Circuit Breaker.
• Failure Isolation (장애 격리): 한 컴포넌트의 장애가 전체 시스템에 영향을 주지 않도록 격리. 예: Bulkhead, 컨테이너 격리.
• Observability Design (관측 가능성 확보): 시스템 내부 상태를 외부에서 모니터링 가능하도록 설계. 예: 로그, 메트릭, 분산 트레이싱, 헬스 체크.
• Scalable Architecture (확장 가능한 구조): 부하 증가에 따라 수평 또는 수직 확장이 가능하도록 설계. 예: Stateless 설계, Auto-scaling.
• Security by Design (설계 단계의 보안 내재화): 인증, 인가, 데이터 암호화 등 보안 요소를 설계 초기부터 통합. 예: Zero Trust Model.
• Loose Coupling / High Cohesion (느슨한 결합 / 높은 응집도): 컴포넌트 간 의존성을 줄이고, 하나의 컴포넌트는 관련된 책임에 집중하여 높은 독립성과 재사용성을 확보.

시스템 아키텍처

작동 원리

sequenceDiagram
    participant U as 사용자
    participant C as 클라이언트
    participant N as 네트워크
    participant S as 서버
    participant D as 데이터베이스
    
    U->>C: 요청
    C->>N: 네트워크 전송
    N->>S: 서버 전달
    S->>D: 데이터 조회
    D->>S: 결과 반환
    S->>N: 응답 전송
    N->>C: 클라이언트 수신
    C->>U: 결과 표시

계층

graph TD

%% 최상위
    A[System Architecture] --> UI[사용자 인터페이스 계층]
    A --> NW[네트워크 계층]
    A --> SW[소프트웨어 계층]
    A --> HW[하드웨어 계층]

%% 사용자 인터페이스 계층
    UI --> WebApp[웹 애플리케이션]
    UI --> MobileApp[모바일 앱]
    UI --> GUI[데스크탑 GUI]
    UI --> Browser[브라우저]

%% 네트워크 계층
    NW --> Router[라우터]
    NW --> Switch[스위치]
    NW --> Firewall[방화벽]

%% 소프트웨어 계층
    SW --> OS[운영체제]
    SW --> Runtime[런타임 환경]
    SW --> Middleware[미들웨어]
    SW --> Services["서비스 (API 등)"]

%% 하드웨어 계층
    HW --> Server[서버]
    HW --> Storage[스토리지]
    HW --> IoT[IoT 디바이스]

구성요소

graph TD

%% 사용자 요청
    User[사용자] --> UI[웹/모바일 앱]

%% 네트워크 인프라
    UI --> FW["방화벽 (Firewall)"]
    FW --> LB["로드 밸런서 (Load Balancer)"]

%% 시스템 소프트웨어 계층
    subgraph 애플리케이션 서버
        LB --> App1[애플리케이션 서버 1]
        LB --> App2[애플리케이션 서버 2]
    end

    App1 --> OS1[운영체제]
    App2 --> OS2[운영체제]
    OS1 --> Middleware1[미들웨어]
    OS2 --> Middleware2[미들웨어]

%% 하드웨어 플랫폼 계층
    App1 --> HW1["서버 1 (CPU, 메모리)"]
    App2 --> HW2["서버 2 (CPU, 메모리)"]
    DB --> Storage[스토리지]

%% 데이터 및 외부 연계
    App1 --> DB[데이터베이스 서버]
    App2 --> Cache[캐시 서버]
    App1 --> API[외부 API]

%% 모니터링
    Monitor[모니터링 시스템] --> App1
    Monitor --> DB

실무 적용 예시

장단점

실무 적용 고려사항

최적화 고려사항

소프트웨어 아키텍처

작동 원리 (MVC 패턴)

sequenceDiagram
    participant V as View
    participant C as Controller
    participant M as Model
    
    V->>C: 사용자 입력
    C->>M: 비즈니스 로직 호출
    M->>M: 데이터 처리
    M->>C: 결과 반환
    C->>V: 뷰 업데이트 지시
    V->>V: 화면 갱신

계층

graph TD
    subgraph Presentation Layer [프레젠테이션 계층]
        UI[UI 컴포넌트] --> View[View]
        View --> Controller[Controller]
    end

    subgraph Application Layer [애플리케이션 계층]
        Controller --> Service[비즈니스 로직 서비스 객체]
        Service --> Domain[도메인 로직 수행]
        Domain --> Transaction[트랜잭션 관리]
    end

    subgraph Data Layer [데이터 계층]
        Service --> DAO[DAO]
        DAO --> ORM[ORM]
        ORM --> DB[(Database)]
    end

구성요소

graph TD
    subgraph 사용자 계층
        User[사용자]
    end

    subgraph 프레젠테이션 계층
        UI[UI 컴포넌트] --> Controller[컨트롤러 인터페이스]
    end

    subgraph 애플리케이션 계층
        Controller --> Service[비즈니스 서비스 컴포넌트]
    end

    subgraph 데이터 계층
        Service --> RepoInterface[저장소 인터페이스]
        RepoInterface --> Repository[Repository 구현체]
        Repository --> DB[(Database)]
    end

    subgraph 설정 관리
        Config[Configuration Manager]
        Config -- 설정 주입 --> Service
        Config -- 설정 주입 --> Repository
    end

    %% 연결자 표현
    User -->|HTTP Request| UI
    Service -->|Interface 호출| RepoInterface

실무 적용 예시

장단점

실무 적용 고려사항

최적화 고려사항

시스템 아키텍처 vs. 소프트웨어 아키텍처: 활용 관점 비교

아키텍처 스타일 (Architecture Style) vs. 아키텍처 패턴 (Architecture Pattern) vs. 디자인 패턴 (Design Pattern)

아키텍처 스타일 (Architecture Style), 아키텍처 패턴 (Architecture Pattern), 디자인 패턴 (Design Pattern) 은 모두 시스템/소프트웨어 설계에서 사용되지만, 적용 범위와 대상이 다르다.

• 아키텍처 스타일: 시스템/소프트웨어 공통 구조 방식 → 시스템 & 소프트웨어 모두 해당
• 아키텍처 패턴: 소프트웨어 아키텍처 구조 → 소프트웨어 중심, 시스템 설계 일부 연관
• 디자인 패턴: 코드 내부 설계 → 소프트웨어 전용

각 계층의 패턴들은 상호 보완적으로 동작하며, 스타일 → 패턴 → 코드 구현이라는 설계 흐름을 따라 적용된다.

아키텍처 스타일 (Architecture Style)

• 적용 대상: 시스템 아키텍처와 소프트웨어 아키텍처 모두
• 적용 범위: 고수준 설계 구조
• 예시:

아키텍처 패턴 (Architecture Pattern)

• 적용 대상: 주로 소프트웨어 아키텍처에 적용되지만, 분산 시스템 아키텍처 설계에도 활용됨
• 적용 범위: 애플리케이션 구조 설계
• 예시:

디자인 패턴 (Design Pattern)

• 적용 대상: 소프트웨어 설계 전용
• 적용 범위: 클래스, 객체, 함수 등 구현 세부 설계
• 예시:

아키텍처 패턴 (Architecture Pattern) vs. 디자인 패턴 (Design Pattern)

소프트웨어 아키텍처 패턴은 시스템 전체의 구조적 조직을 정의하는 더 높은 수준의 패턴이다. 이는 시스템의 주요 구성 요소, 그들 간의 관계, 환경과의 상호작용 방식을 설계한다. MVC, 마이크로서비스, 레이어드 아키텍처 등이 대표적인 예이다. 아키텍처 패턴은 시스템 전체의 품질 속성 (확장성, 성능, 보안 등) 에 영향을 미치며, 시스템의 전반적인 구조를 형성한다.

소프트웨어 디자인 패턴은 객체 지향 설계에서 자주 발생하는 문제에 대한 재사용 가능한 솔루션이다. 이는 주로 클래스와 객체의 구조 및 상호작용에 초점을 맞추며, GoF(Gang of Four) 의 23 가지 패턴이 널리 알려져 있다. 디자인 패턴은 코드 수준의 설계 문제를 해결하며, 일반적으로 작은 범위의 특정 문제에 적용된다.

두 패턴의 주요 차이점은 추상화 수준과 적용 범위에 있다. 디자인 패턴은 미시적이고 코드 중심적인 반면, 아키텍처 패턴은 거시적이고 구조 중심적이다. 그러나 두 패턴은 상호 보완적이며, 효과적인 소프트웨어 개발을 위해 함께 사용된다. 디자인 패턴이 코드의 품질을 향상시키는 동안, 아키텍처 패턴은 시스템 전체의 구조적 완전성을 보장한다.

목적 및 필요성 비교

주요 기능 및 역할 비교

특징 비교

핵심 원칙 비교

주요 원리 및 작동 원리

소프트웨어 아키텍처 패턴의 작동 원리:

• 소프트웨어 아키텍처 패턴은 시스템 전체 구조를 조직화하는 원칙에 기반한다.
• 핵심 원리는 다음과 같다:
  1. 관심사 분리 (Separation of Concerns): 시스템을 구별된 기능 영역으로 분할한다.
  2. 계층화 (Layering): 기능을 논리적 계층으로 구성하여 각 계층이 하위 계층에만 의존하도록 한다.
  3. 모듈화 (Modularity): 시스템을 독립적으로 개발, 테스트, 배포할 수 있는 모듈로 분할한다.
  4. 느슨한 결합 (Loose Coupling): 모듈 간 의존성을 최소화하여 변경 영향을 제한한다.
  5. 높은 응집도 (High Cohesion): 관련 기능을 함께 그룹화하여 모듈의 집중도를 높인다.

아키텍처 패턴 작동 원리 다이어그램:

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

+----------------+     +----------------+     +----------------+
|                |     |                |     |                |
| 프레젠테이션 계층|---->|   비즈니스 계층  |---->|   데이터 계층    |
|                |     |                |     |                |
+----------------+     +----------------+     +----------------+
       △                      △                     △
       |                      |                     |
       v                      v                     v
+----------------+     +----------------+     +----------------+
|                |     |                |     |                |
|   UI 컴포넌트    |     | 비즈니스 서비스  |     |  데이터 접근    |
|                |     |                |     |                |
+----------------+     +----------------+     +----------------+

소프트웨어 디자인 패턴의 작동 원리:

• 소프트웨어 디자인 패턴은 객체 지향 프로그래밍의 기본 원칙을 기반으로 작동한다.
• 핵심 원리는 다음과 같다:
  1. 캡슐화 (Encapsulation): 객체의 내부 상태와 구현 세부 사항을 숨기고 인터페이스를 통해서만 접근하도록 한다.
  2. 상속 (Inheritance): 기존 클래스의 속성과 동작을 새로운 클래스가 재사용할 수 있게 한다.
  3. 다형성 (Polymorphism): 같은 인터페이스를 통해 다양한 구현을 제공할 수 있게 한다.
  4. 합성 (Composition): “has-a” 관계를 통해 객체가 다른 객체를 포함할 수 있게 한다.
  5. 인터페이스 기반 설계: 구현보다는 인터페이스에 의존하여 결합도를 낮춘다.

디자인 패턴 작동 원리 다이어그램:

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

+---------------+      사용      +---------------+
|               |-------------->|               |
|    클라이언트  |               |    인터페이스   |
|               |<--------------|               |
+---------------+      제공      +---------------+
                                      △
                                      |
                                      | 구현
                                      |
                               +---------------+
                               |               |
                               |  구체 클래스    |
                               |               |
                               +---------------+

구조 및 아키텍처

소프트웨어 아키텍처 패턴의 구조:

• 아키텍처 패턴은 다음과 같은 구조적 요소로 구성된다:
  1. 컴포넌트 (Components): 시스템의 주요 구성 요소로, 특정 기능이나 서비스를 담당한다.
  2. 커넥터 (Connectors): 컴포넌트 간의 통신 방식을 정의한다.
  3. 제약 조건 (Constraints): 시스템 구성에 대한 규칙과 제한 사항을 정의한다.
  4. 뷰 (Views): 시스템의 다양한 측면 (구조, 행동, 배포 등) 을 보여준다.

아키텍처 패턴은 다양한 다이어그램 (컴포넌트 다이어그램, 배포 다이어그램, 시퀀스 다이어그램 등) 을 통해 표현된다.

예: 마이크로서비스 아키텍처 구조

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

+-------------+    +-------------+    +-------------+
|             |    |             |    |             |
| 사용자 서비스 |    |  주문 서비스  |    | 결제 서비스  |
|             |    |             |    |             |
+-------------+    +-------------+    +-------------+
       |                 |                  |
       |                 |                  |
       v                 v                  v
+---------------------------------------------+
|                                             |
|             메시지 브로커 (Kafka, RabbitMQ)   |
|                                             |
+---------------------------------------------+
       ^                 ^                  ^
       |                 |                  |
       |                 |                  |
+-------------+    +-------------+    +-------------+
|             |    |             |    |             |
| 알림 서비스  |    | 재고 서비스   |    | 배송 서비스   |
|             |    |             |    |             |
+-------------+    +-------------+    +-------------+

소프트웨어 디자인 패턴의 구조:

• 디자인 패턴은 일반적으로 다음과 같은 구조적 요소로 구성된다:
  1. 패턴 이름 (Pattern Name): 패턴을 식별하는 이름으로, 패턴에 대한 공통 어휘를 제공한다.
  2. 문제 (Problem): 패턴이 해결하려는 설계 문제를 설명한다.
  3. 해결책 (Solution): 문제 해결을 위한 디자인 요소와 그들의 관계, 책임, 협력 방식을 설명한다.
  4. 결과 (Consequences): 패턴 적용의 트레이드오프와 결과를 설명한다.

디자인 패턴은 주로 클래스 다이어그램을 통해 표현되며, 각 패턴마다 고유한 클래스 구조와 상호작용 방식이 있다.

예: 옵저버 패턴 구조

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

+---------------+      관찰      +---------------+
|               |<--------------|               |
|    Subject    |               |   Observer    |
|               |-------------->|               |
+---------------+      통지      +---------------+
       △                              △
       |                              |
       |                              |
+---------------+              +---------------+
|               |              |               |
|ConcreteSubject|              |ConcreteObserver|
|               |              |               |
+---------------+              +---------------+

구성 요소

소프트웨어 아키텍처 패턴의 구성 요소

아키텍처 패턴은 다음과 같은 주요 구성 요소로 이루어진다:

소프트웨어 디자인 패턴의 구성 요소

디자인 패턴은 주로 다음과 같은 구성 요소로 이루어진다:

활용 사례

시나리오: 대규모 전자상거래 플랫폼을 구축하는 과정에서 소프트웨어 디자인 패턴과 아키텍처 패턴을 어떻게 결합하여 사용하는지 살펴보자.

시스템 요구사항:

• 수백만 개의 제품 카탈로그 관리
• 수천 명의 동시 사용자 처리
• 결제, 재고, 배송 등 다양한 서비스 통합
• 피크 시즌 트래픽 급증 대응
• 새로운 기능의 빠른 출시와 안정적인 서비스 유지

아키텍처 패턴 적용: 마이크로서비스 아키텍처

• 전체 시스템은 마이크로서비스 아키텍처로 구성하여 독립적으로 개발, 배포, 확장 가능한 서비스로 분리한다.
• 주요 서비스:
  1. 제품 카탈로그 서비스
  2. 사용자 관리 서비스
  3. 장바구니 서비스
  4. 주문 서비스
  5. 결제 서비스
  6. 재고 관리 서비스
  7. 배송 서비스
  8. 검색 서비스
  9. 리뷰 서비스
• 각 서비스는 자체 데이터베이스를 가지며, API 게이트웨이를 통해 클라이언트와 통신한다. 서비스 간 통신은 비동기 메시지 큐를 사용한다.

디자인 패턴 적용

• 각 마이크로서비스 내부에서 다양한 디자인 패턴을 적용한다:
  1. 제품 카탈로그 서비스:
     • 전략 패턴: 다양한 제품 유형 (물리적 상품, 디지털 상품, 서비스) 에 따른 처리 전략
     • 데코레이터 패턴: 제품 정보에 프로모션, 할인 정보 동적 추가
  2. 사용자 관리 서비스:
     • 팩토리 패턴: 다양한 유형의 사용자 계정 생성
     • 옵저버 패턴: 사용자 활동 모니터링 및 알림
  3. 장바구니 서비스:
     • 메멘토 패턴: 장바구니 상태 저장 및 복원
     • 컴포지트 패턴: 번들 상품 관리
  4. 주문 서비스:
     • 상태 패턴: 주문 상태 관리 (생성, 결제 완료, 배송 중, 배송 완료 등)
     • 책임 연쇄 패턴: 주문 검증 및 처리 파이프라인
  5. 결제 서비스:
     • 전략 패턴: 다양한 결제 방법 지원
     • 어댑터 패턴: 다양한 결제 게이트웨이 통합

시스템 다이어그램

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

                                   클라이언트
                                       |
                                       v
                              +------------------+
                              |   API 게이트웨이   |
                              +------------------+
                                       |
                                       v
              +--------------------------------------------------+
              |                                                  |
 +------------+------------+                      +--------------+--------------+
 |                         |                      |                             |
 v                         v                      v                             v
+---------------+  +---------------+  +------------------+  +------------------+
| 사용자 서비스   |  | 제품 카탈로그  |  |   장바구니 서비스   |  |   주문 서비스     |
+---------------+  +---------------+  +------------------+  +------------------+
 |      |      |    |      |      |    |        |        |    |        |        |
 v      v      v    v      v      v    v        v        v    v        v        v
+---+ +---+ +---+ +---+ +---+ +---+ +------+ +------+ +---+ +---+ +--------+ +------+
|팩토리|옵저버|인증| |전략| |데코|검색| |메멘토| |컴포지트| |상태| |책임연쇄| |커맨드| |상태|
+---+ +---+ +---+ +---+ +---+ +---+ +------+ +------+ +---+ +---+ +--------+ +------+
                                       |
                +----------------------+----------------------+
                |                      |                      |
                v                      v                      v
         +---------------+    +---------------+    +------------------+
         |  결제 서비스   |    |  재고 서비스   |    |   배송 서비스    |
         +---------------+    +---------------+    +------------------+
          |      |      |      |      |      |      |        |        |
          v      v      v      v      v      v      v        v        v
        +---+ +---+ +---+    +---+ +---+ +---+    +---+   +---+    +---+
        |전략| |어댑터|프록시|    |옵저버|싱글톤|팩토리|    |전략|   |상태|    |옵저버|
        +---+ +---+ +---+    +---+ +---+ +---+    +---+   +---+    +---+

디자인 패턴과 아키텍처 패턴의 상호 보완성

이 시나리오에서 볼 수 있듯이, 아키텍처 패턴 (마이크로서비스) 은 시스템 전체의 구조를 정의하고, 디자인 패턴은 각 서비스 내부의 상세한 구현 문제를 해결한다.

활용 사례

사례 1: 대규모 전자상거래 시스템

시나리오: 월 1 억 건의 주문을 처리하는 글로벌 전자상거래 플랫폼 구축

시스템 구성:

graph TB
    subgraph "Frontend Layer"
        A[모바일 앱] --> D[API Gateway]
        B[웹 브라우저] --> D
        C[파트너 API] --> D
    end
    
    subgraph "Application Layer"
        D --> E[인증 서비스]
        D --> F[사용자 서비스]
        D --> G[상품 서비스]
        D --> H[주문 서비스]
        D --> I[결제 서비스]
        D --> J[배송 서비스]
    end
    
    subgraph "Data Layer"
        F --> K[(사용자 DB)]
        G --> L[(상품 DB)]
        H --> M[(주문 DB)]
        I --> N[(결제 DB)]
        J --> O[(배송 DB)]
    end
    
    subgraph "Infrastructure"
        P[로드 밸런서]
        Q[CDN]
        R[캐시 클러스터]
        S[메시지 큐]
    end
    
    P --> D
    Q --> A
    Q --> B
    E --> R
    G --> R
    H --> S
    I --> S
    J --> S

활용 사례 Workflow:

sequenceDiagram
    participant U as 사용자
    participant API as API Gateway
    participant AUTH as 인증서비스
    participant PROD as 상품서비스
    participant ORDER as 주문서비스
    participant PAY as 결제서비스
    participant SHIP as 배송서비스
    participant MQ as 메시지큐
    
    U->>API: 상품 주문 요청
    API->>AUTH: 사용자 인증 확인
    AUTH-->>API: 인증 성공
    API->>PROD: 상품 재고 확인
    PROD-->>API: 재고 확인 완료
    API->>ORDER: 주문 생성
    ORDER->>MQ: 주문 생성 이벤트 발행
    ORDER-->>API: 주문 ID 반환
    API-->>U: 주문 접수 확인
    
    MQ->>PAY: 결제 처리 요청
    PAY->>PAY: 결제 로직 실행
    PAY->>MQ: 결제 완료 이벤트 발행
    
    MQ->>SHIP: 배송 준비 요청
    SHIP->>SHIP: 배송 로직 실행
    SHIP->>MQ: 배송 시작 이벤트 발행
    
    MQ->>U: 주문 상태 알림

각 구성 요소의 역할:

• 시스템 아키텍처 역할:
  • API Gateway: 모든 외부 요청의 단일 진입점, 라우팅, 인증, 모니터링
  • 마이크로서비스: 각 비즈니스 도메인별 독립적인 서비스 운영
  • 메시지 큐: 서비스 간 비동기 통신으로 느슨한 결합 유지
  • 로드 밸런서: 트래픽 분산을 통한 고가용성 확보
• 소프트웨어 아키텍처 역할:
  • 헥사고날 아키텍처: 각 서비스 내부에서 비즈니스 로직과 외부 의존성 분리
  • CQRS 패턴: 주문 조회와 생성을 분리하여 성능 최적화
  • 이벤트 소싱: 주문 상태 변경 이력을 이벤트로 저장하여 추적성 확보

사례 2: 대규모 온라인 쇼핑몰 플랫폼 구축

시나리오: 글로벌 쇼핑몰 플랫폼을 구축하며, 높은 트래픽, 다양한 결제 수단, 실시간 재고 관리가 요구되는 상황

소프트웨어 아키텍처 관점의 시스템 구성:

graph TB
    subgraph "프론트엔드 (React/Vue)"
        A[상품 카탈로그]
        B[장바구니]
        C[결제 UI]
    end
    
    subgraph "백엔드 서비스 (마이크로서비스)"
        D[사용자 서비스]
        E[상품 서비스]
        F[주문 서비스]
        G[결제 서비스]
        H[재고 서비스]
    end
    
    subgraph "데이터 계층"
        I[사용자 DB]
        J[상품 DB]
        K[주문 DB]
        L[결제 DB]
    end
    
    A --> E
    B --> F
    C --> G
    
    D --> I
    E --> J
    F --> K
    G --> L
    H --> J

시스템 아키텍처 관점의 시스템 구성:

graph TB
    subgraph "CDN & 로드밸런서"
        A[Global CDN]
        B[Application Load Balancer]
    end
    
    subgraph "컴퓨팅 인스턴스 (AWS/Azure)"
        C[웹 서버 클러스터]
        D[앱 서버 클러스터]
        E[백그라운드 작업 서버]
    end
    
    subgraph "데이터 인프라"
        F[Primary Database]
        G[Read Replica]
        H[Redis Cache]
        I[Elasticsearch]
    end
    
    subgraph "외부 서비스 연동"
        J[결제 게이트웨이]
        K[배송 API]
        L[SMS/Email 서비스]
    end
    
    A --> B
    B --> C
    C --> D
    D --> E
    D --> F
    F --> G
    D --> H
    D --> I
    D --> J
    D --> K
    D --> L

활용 사례의 워크플로우:

• 소프트웨어 아키텍처 워크플로우:
  1. 사용자 요청 → API Gateway → 해당 마이크로서비스
  2. 비즈니스 로직 처리 → 도메인 모델 업데이트
  3. 데이터 계층 접근 → 응답 반환
• 시스템 아키텍처 워크플로우:
  1. 글로벌 CDN → 지역별 로드밸런서 → 웹 서버
  2. 앱 서버 클러스터에서 처리 → 데이터베이스 접근
  3. 캐시 활용 → 외부 서비스 연동 → 응답 반환

역할 분담 및 차이점:

• 소프트웨어 아키텍처의 역할:
  • 애플리케이션 내부 구조 설계
  • 컴포넌트 간 인터페이스 정의
  • 비즈니스 로직의 모듈화
  • 코드 품질과 유지보수성 확보
• 시스템 아키텍처의 역할:
  • 전체 인프라 설계와 배치
  • 성능과 가용성 보장
  • 확장성과 신뢰성 확보
  • 외부 시스템과의 통합

주요 차이점:

• 범위: 소프트웨어 아키텍처는 애플리케이션 내부, 시스템 아키텍처는 전체 시스템
• 관점: 개발자 vs 시스템 엔지니어 관점
• 의사결정: 프로그래밍 기술 vs 인프라 기술
• 영향도: 코드 변경 vs 시스템 전체 변경

사례 3: 대규모 전자상거래 플랫폼 구축

시스템 아키텍처: 클라우드 기반의 분산형 아키텍처를 채택하여 확장성과 가용성을 확보
소프트웨어 아키텍처: 마이크로서비스 아키텍처를 적용하여 주문, 결제, 배송 등의 기능을 독립적으로 관리

시스템 구성:

graph TD
    subgraph 사용자
        U[User Interface]
    end

    subgraph Frontend
        U --> GW[API Gateway]
    end

    subgraph Backend
        GW --> MS1[Order Service]
        GW --> MS2[Payment Service]
        GW --> MS3[Shipping Service]
        GW --> Auth[Authentication Service]
    end

    subgraph Infrastructure
        MS1 --> DB1[(Order DB)]
        MS2 --> DB2[(Payment DB)]
        MS3 --> DB3[(Shipping DB)]
        Auth --> DB4[(User DB)]

        GW --> MON[Monitoring]
        GW --> LOG[Logging Service]
        GW --> CACHE[Redis Cache]
    end

Workflow

1. 사용자가 제품 주문 요청
2. API Gateway → Order Service 로 요청 전달
3. 주문 생성 → Payment Service 호출 → 결제 완료
4. 결제 완료 → Shipping Service 호출 → 배송 시작
5. 각 단계에서 상태 이벤트는 로그 수집 및 모니터링 시스템으로 전달됨
6. 사용자는 주문 상태를 실시간으로 조회

각 아키텍처의 역할 및 적용 효과:

사례 4: 전자상거래 플랫폼

시나리오: 대규모 온라인 쇼핑몰 시스템 구축
시스템 구성:

• 사용자 서비스 (User Service): 회원 관리, 인증/인가
• 상품 서비스 (Product Service): 상품 정보 관리, 재고 관리
• 주문 서비스 (Order Service): 주문 처리, 주문 이력 관리
• 결제 서비스 (Payment Service): 결제 처리, 결제 이력 관리
• 알림 서비스 (Notification Service): 이메일, SMS, 푸시 알림

graph TB
    subgraph "클라이언트 계층"
        WEB["웹 애플리케이션"]
        MOBILE["모바일 앱"]
        ADMIN["관리자 콘솔"]
    end
    
    subgraph "API 게이트웨이"
        GATEWAY["API Gateway<br/>- 인증<br/>- 라우팅<br/>- 로드밸런싱"]
    end
    
    subgraph "마이크로서비스 계층"
        USER_SVC["사용자 서비스<br/>(User Service)<br/>- 회원 관리<br/>- 인증/인가"]
        PRODUCT_SVC["상품 서비스<br/>(Product Service)<br/>- 상품 정보<br/>- 재고 관리"]
        ORDER_SVC["주문 서비스<br/>(Order Service)<br/>- 주문 처리<br/>- 주문 이력"]
        PAYMENT_SVC["결제 서비스<br/>(Payment Service)<br/>- 결제 처리<br/>- 결제 이력"]
        NOTIFY_SVC["알림 서비스<br/>(Notification Service)<br/>- 이메일/SMS<br/>- 푸시 알림"]
    end
    
    subgraph "데이터 계층"
        USER_DB["사용자 DB<br/>(PostgreSQL)"]
        PRODUCT_DB["상품 DB<br/>(MongoDB)"]
        ORDER_DB["주문 DB<br/>(PostgreSQL)"]
        PAYMENT_DB["결제 DB<br/>(PostgreSQL)"]
        CACHE["캐시<br/>(Redis)"]
    end
    
    subgraph "메시징 시스템"
        MSG_BROKER["메시지 브로커<br/>(Apache Kafka)<br/>- 이벤트 스트리밍<br/>- 비동기 통신"]
    end
    
    subgraph "외부 서비스"
        PAYMENT_GATEWAY["결제 게이트웨이<br/>(PG사)"]
        EMAIL_SVC["이메일 서비스<br/>(SendGrid)"]
        SMS_SVC["SMS 서비스"]
    end
    
    WEB --> GATEWAY
    MOBILE --> GATEWAY
    ADMIN --> GATEWAY
    
    GATEWAY --> USER_SVC
    GATEWAY --> PRODUCT_SVC
    GATEWAY --> ORDER_SVC
    GATEWAY --> PAYMENT_SVC
    
    USER_SVC --> USER_DB
    PRODUCT_SVC --> PRODUCT_DB
    PRODUCT_SVC --> CACHE
    ORDER_SVC --> ORDER_DB
    PAYMENT_SVC --> PAYMENT_DB
    
    ORDER_SVC --> MSG_BROKER
    PAYMENT_SVC --> MSG_BROKER
    NOTIFY_SVC --> MSG_BROKER
    
    PAYMENT_SVC --> PAYMENT_GATEWAY
    NOTIFY_SVC --> EMAIL_SVC
    NOTIFY_SVC --> SMS_SVC

활용 사례 Workflow:

sequenceDiagram
    participant Client as 클라이언트
    participant Gateway as API 게이트웨이
    participant User as 사용자 서비스
    participant Product as 상품 서비스
    participant Order as 주문 서비스
    participant Payment as 결제 서비스
    participant Notify as 알림 서비스
    participant Kafka as 메시지 브로커
    
    Client->>Gateway: 주문 요청
    Gateway->>User: 사용자 인증 확인
    User-->>Gateway: 인증 성공
    
    Gateway->>Product: 상품 재고 확인
    Product-->>Gateway: 재고 확인 완료
    
    Gateway->>Order: 주문 생성
    Order->>Order: 주문 정보 저장
    Order->>Kafka: OrderCreated 이벤트 발행
    Order-->>Gateway: 주문 생성 완료
    
    Gateway->>Payment: 결제 처리 요청
    Payment->>Payment: 결제 정보 저장
    Payment->>Kafka: PaymentRequested 이벤트 발행
    Payment-->>Gateway: 결제 처리 완료
    
    Gateway-->>Client: 주문 완료 응답
    
    Kafka->>Notify: PaymentCompleted 이벤트 수신
    Notify->>Notify: 알림 메시지 생성
    Notify->>Client: 주문 완료 알림 전송
    
    Kafka->>Product: OrderCreated 이벤트 수신
    Product->>Product: 재고 차감 처리

각 서비스의 역할:

1. API 게이트웨이: 단일 진입점, 인증/인가, 라우팅, 로드밸런싱
2. 사용자 서비스: 회원 정보 관리, JWT 토큰 기반 인증
3. 상품 서비스: 상품 카탈로그, 재고 관리, 검색 기능
4. 주문 서비스: 주문 생성/조회, 주문 상태 관리
5. 결제 서비스: 결제 처리, 결제 이력 관리, 환불 처리
6. 알림 서비스: 이벤트 기반 알림 발송

사례 5: 실시간 음식 배달 플랫폼 구축

시나리오: 주문량 증가에 따라 서비스 지연과 시스템 간 충돌 발생
목표: 확장성, 장애 격리, 빠른 롤아웃을 지원하는 유연한 아키텍처 구현
적용된 아키텍처 원칙:

• 모듈화 (Modularity)
• SRP/DIP 기반 설계
• 이벤트 기반 아키텍처
• 마이크로서비스 분리 전략
• 서버리스 구성 일부 도입 (예: 알림 서비스)

시스템 구성 요소:

시스템 구성 다이어그램:

graph LR
    C[Client App] --> G[API Gateway]
    G --> O[Order Service]
    G --> S[Store Service]
    G --> D[Delivery Service]
    G --> P[Payment Service]
    G --> N["Notification Fn (Serverless)"]
    O -->|Event| K[Kafka]
    S -->|Event| K
    D -->|Event| K
    P -->|Event| K
    K --> N
    K --> MON[Prometheus + Grafana]

워크플로우:

1. 사용자가 앱에서 주문 생성
2. API Gateway → Order Service → Kafka 에 이벤트 전송
3. Store & Delivery 서비스가 Kafka 이벤트를 소비
4. 결제 완료 후 Notification 서비스 호출 → FCM 푸시 전송
5. 전체 흐름은 이벤트 기반으로 구성되어 비동기, 고가용 구조 유지

실무에서 효과적으로 적용하기 위한 고려사항

최적화하기 위한 고려사항

앞으로의 전망

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

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

하위 주제별 추가 학습 항목

용어 정리

참고 및 출처

• Difference between System Architecture and Software Architecture - GeeksforGeeks
• Systems vs Software Architecture - Mike Fisher
• Software Architecture vs Design - Lucidchart Blog
• Difference Between Architectural Style, Architectural Patterns and Design Patterns - GeeksforGeeks
• What’s the difference between design patterns and architectural patterns? - Stack Overflow
• The Future of Microservices: Software Trends in 2024 - Workast
• Microservices Architecture: Trends for 2025 - Analytics Insight
• Cloud-Native Application Development Trends 2025 - Aspire Systems
• InfoQ Software Architecture and Design Trends Report - 2025
• Software Architecture: Understanding Styles and Patterns - XCubeLabs
• GeeksforGeeks - System Architecture vs Software Architecture
• Mike Fisher - Systems vs Software Architecture
• Lucidchart - Software Architecture vs Design
• GeeksforGeeks - System Design vs System Architecture
• Stack Overflow - Design Patterns vs Architectural Patterns
• Turing - Software Architecture Patterns Types
• GeeksforGeeks - Architectural Style vs Patterns vs Design Patterns
• Simform - Software Architecture Patterns
• Red Hat - 14 Software Architecture Patterns
• Zero To Mastery - Software Architecture Design Patterns
• Wikipedia - List of Software Architecture Styles and Patterns
• Herbert Graca - Architectural Styles vs Patterns vs Design Patterns
• George Fairbanks - Architecture Patterns vs Architectural Styles
• Mohamed Sami - Architectural Styles and Patterns
• Software architecture - Wikipedia
• Is system design and software design same? - Design Gurus
• Software architecture vs System architecture vs Class diagrams - StackExchange
• System Design and Software Design in Distributed Systems - Multiplayer.app
• System Architecture: Tutorial & Best Practices - Multiplayer.app
• What is Software Architecture? A Comprehensive Guide - vFunction
• Software Architecture vs. Design: A Comprehensive Guide - Tecnovy
• Key Principles In Software Architecture - LinkedIn
• Future Trends Software Architecture - Swiftorial Lessons
• iSAQB Glossary of Software Architecture Terminology (PDF)
• 14 Software Architecture Patterns - Red Hat
• List of software architecture styles and patterns - Wikipedia
• Top 10 Software Architecture Patterns to Follow in 2024 - DZone
• InfoQ Software Architecture and Design Trends Report - 2024
• The Biggest Enterprise Architecture Trends in 2025 - Ardoq