kt-event-marketing-fe/design/pattern/architecture-pattern.md

# KT AI 기반 소상공인 이벤트 자동 생성 서비스 - 클라우드 아키텍처 패턴 적용 방안 (MVP)

## 문서 정보
- **작성일**: 2025-10-21
- **버전**: 2.0 (MVP 집중)
- **적용 패턴**: 4개 핵심 패턴
- **목표**: 빠른 MVP 출시와 안정적 서비스 제공

---

## 1. 요구사항 분석

### 1.1 기능적 요구사항

**User 서비스**
- 회원가입/로그인 및 프로필 관리
- 사업자번호 검증 (국세청 API)

**Event 서비스**
- 이벤트 CRUD 및 상태 관리
- 이벤트 목적 선택 → AI 추천 → 콘텐츠 생성 → 배포 → 분석 플로우

**AI 서비스**
- 트렌드 분석 (업종/지역/시즌)
- 3가지 이벤트 기획안 자동 생성
- Claude API/GPT-4 API 연동

**Content 서비스**
- 3가지 스타일 SNS 이미지 자동 생성
- Stable Diffusion/DALL-E API 연동
- 플랫폼별 이미지 최적화 (Instagram, Naver, Kakao)

**Distribution 서비스**
- 다중 채널 동시 배포 (우리동네TV, 링고비즈, 지니TV, SNS)
- 7개 외부 API 연동

**Participation 서비스**
- 이벤트 참여 접수 및 당첨자 추첨

**Analytics 서비스**
- 실시간 성과 대시보드
- 채널별 성과 분석

### 1.2 비기능적 요구사항

**성능 요구사항**
- AI 트렌드 분석 + 이벤트 추천: **10초 이내**
- SNS 이미지 생성: **5초 이내**
- 대시보드 데이터 업데이트: **5분 간격**
- 다중 채널 배포: **1분 이내**

**가용성 요구사항**
- 시스템 가용성: **99% 이상** (MVP 목표)
- 외부 API 장애 시 서비스 지속 가능

**확장성 요구사항**
- 초기 사용자: **100명**
- 동시 이벤트: **50개**
- 캐시 히트율: **80% 이상**

**보안 요구사항**
- JWT 기반 인증/인가
- API Gateway를 통한 중앙집중식 보안

### 1.3 외부 API 의존성

| 서비스 | 외부 API | 용도 | 응답시간 |
|--------|----------|------|----------|
| User | 국세청 사업자등록정보 진위확인 API | 사업자번호 검증 | 2-3초 |
| AI | Claude API / GPT-4 API | 트렌드 분석 및 이벤트 추천 | 5-10초 |
| Content | Stable Diffusion / DALL-E API | SNS 이미지 생성 | 3-5초 |
| Distribution | 우리동네TV API | 영상 업로드 및 송출 | 1-2초 |
| Distribution | 링고비즈 API | 연결음 업데이트 | 1초 |
| Distribution | 지니TV 광고 API | 광고 등록 | 1-2초 |
| Distribution | SNS API (Instagram, Naver, Kakao) | 자동 포스팅 | 1-3초 |

### 1.4 기술적 도전과제

#### 1. AI 응답 시간 관리 (🔴 Critical)

**문제**: AI API 응답이 10초 목표를 초과할 수 있음
- Claude/GPT-4 API 응답 시간 변동성 (5-15초)
- 트렌드 분석 + 이벤트 추천 2단계 처리 필요

**해결방안**:
- **비동기 처리**: Job 기반 처리로 응답 대기 시간 최소화
- **캐싱**: 동일 조건(업종, 지역, 목적) 결과 Redis 캐싱 (24시간)
- **응답 시간 90% 단축** (캐시 히트 시)

#### 2. 다중 외부 API 의존성 (🔴 Critical)

**문제**: 7개 외부 API 연동으로 인한 장애 전파 위험
- 각 API별 응답 시간 및 성공률 상이
- 하나의 API 장애가 전체 서비스 중단으로 이어질 수 있음

**해결방안**:
- **Circuit Breaker**: 장애 API 자동 차단 및 Fallback 처리
- **독립적 처리**: 채널별 배포 실패가 다른 채널에 영향 없음
- **자동 재시도**: 일시적 오류 시 최대 3회 재시도

#### 3. 이미지 생성 비용 및 시간 (🟡 Important)

**문제**: AI 이미지 생성 API 비용이 높고 시간 소요
- 이미지 1장당 생성 비용: $0.02-0.05
- 3가지 스타일 생성 시 비용 3배

**해결방안**:
- **캐싱**: 동일 이벤트 정보 이미지 재사용
- **비용 90% 절감** (캐시 히트 시)

#### 4. 실시간 대시보드 성능 (🟡 Important)

**문제**: 다중 데이터 소스 통합으로 인한 응답 지연
- 7개 외부 API + 내부 서비스 데이터 통합
- 복잡한 차트 및 계산 로직

**해결방안**:
- **캐싱**: Redis를 통한 5분 간격 데이터 캐싱
- **응답 시간 80% 단축**

---

## 2. 패턴 선정 및 평가

### 2.1 MVP 핵심 패턴 (4개)

| 패턴 | 적용 목적 | 주요 효과 |
|------|----------|-----------|
| **Cache-Aside** | AI 응답 시간 단축 및 비용 절감 | 응답 시간 90% 단축, 비용 90% 절감 |
| **API Gateway** | 중앙집중식 보안 및 라우팅 | 개발 복잡도 감소, 보안 강화 |
| **Asynchronous Request-Reply** | 장시간 작업 응답 시간 개선 | 사용자 대기 시간 제거 |
| **Circuit Breaker** (Optional) | 외부 API 장애 격리 | 가용성 95% → 99% 개선 |

### 2.2 정량적 평가 매트릭스

**평가 기준**:
- **기능 적합성** (35%): 요구사항 직접 해결 능력
- **성능 효과** (25%): 응답시간 및 처리량 개선
- **운영 복잡도** (20%): 구현 및 운영 용이성
- **확장성** (15%): 미래 요구사항 대응력
- **비용 효율성** (5%): 개발/운영 비용 대비 효과

| 패턴 | 기능 적합성<br/>(35%) | 성능 효과<br/>(25%) | 운영 복잡도<br/>(20%) | 확장성<br/>(15%) | 비용 효율성<br/>(5%) | **총점** | 우선순위 |
|------|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
| **Cache-Aside** | 10 × 0.35<br/>= 3.5 | 10 × 0.25<br/>= 2.5 | 8 × 0.20<br/>= 1.6 | 9 × 0.15<br/>= 1.35 | 10 × 0.05<br/>= 0.5 | **9.45** | 🔴 Critical |
| **API Gateway** | 9 × 0.35<br/>= 3.15 | 7 × 0.25<br/>= 1.75 | 9 × 0.20<br/>= 1.8 | 9 × 0.15<br/>= 1.35 | 8 × 0.05<br/>= 0.4 | **8.45** | 🔴 Critical |
| **Asynchronous Request-Reply** | 9 × 0.35<br/>= 3.15 | 9 × 0.25<br/>= 2.25 | 7 × 0.20<br/>= 1.4 | 8 × 0.15<br/>= 1.2 | 8 × 0.05<br/>= 0.4 | **8.40** | 🔴 Critical |
| **Circuit Breaker** | 8 × 0.35<br/>= 2.8 | 8 × 0.25<br/>= 2.0 | 9 × 0.20<br/>= 1.8 | 9 × 0.15<br/>= 1.35 | 7 × 0.05<br/>= 0.35 | **8.30** | 🟡 Optional |

### 2.3 패턴별 상세 분석

#### 2.3.1 Cache-Aside (9.45점) - 🔴 Critical

**적용 대상**:
- AI 서비스: 트렌드 분석 결과, 이벤트 추천 결과
- Content 서비스: 생성된 SNS 이미지
- User 서비스: 사업자번호 검증 결과

**구현 방식**:
```
1. 요청 수신 → 캐시 확인 (Redis GET)
2. 캐시 HIT: 즉시 반환 (응답 시간 0.1초)
3. 캐시 MISS:
   - 외부 API 호출 (응답 시간 5-10초)
   - 결과를 캐시에 저장 (Redis SET, TTL 24시간)
   - 결과 반환
```

**기대 효과**:
- **응답 시간**: 10초 → 0.1초 (99% 개선, 캐시 히트 시)
- **비용 절감**: AI API 호출 90% 감소 → 월 $2,000 → $200 (90% 절감)
- **캐시 히트율**: 80% (동일 업종/지역 이벤트 반복 요청)

**운영 고려사항**:
- Redis 메모리 관리: 최대 2GB (약 10,000개 캐시 항목)
- TTL 정책: 24시간 (트렌드 변화 반영)
- 캐시 무효화: 수동 무효화 API 제공

#### 2.3.2 API Gateway (8.45점) - 🔴 Critical

**적용 대상**:
- 전체 마이크로서비스 (User, Event, AI, Content, Distribution, Participation, Analytics)

**주요 기능**:
1. **인증/인가**: JWT 토큰 검증 (모든 요청)
2. **라우팅**: URL 기반 서비스 라우팅
3. **Rate Limiting**: API 호출 제한 (사용자당 100 req/min)
4. **로깅**: 중앙집중식 접근 로그

**구현 방식**:
```
Client → API Gateway (Kong/AWS API Gateway)
         ├─ /api/users/* → User Service
         ├─ /api/events/* → Event Service
         ├─ /api/ai/* → AI Service
         ├─ /api/content/* → Content Service
         ├─ /api/distribution/* → Distribution Service
         ├─ /api/participation/* → Participation Service
         └─ /api/analytics/* → Analytics Service
```

**기대 효과**:
- **개발 생산성**: 각 서비스에서 인증 로직 제거 → 개발 시간 30% 단축
- **보안 강화**: 중앙집중식 보안 정책 관리
- **운영 효율**: 통합 모니터링 및 로깅

#### 2.3.3 Asynchronous Request-Reply (8.40점) - 🔴 Critical

**적용 대상**:
- AI 서비스: 트렌드 분석 및 이벤트 추천 (10초 소요)
- Content 서비스: SNS 이미지 생성 (5초 소요)

**구현 방식**:
```
1. 클라이언트 요청 → Job ID 즉시 반환 (응답 시간 0.1초)
2. 백그라운드 처리:
   - AI API 호출 및 결과 생성 (10초)
   - 결과를 DB 저장
3. 클라이언트 폴링:
   - 5초 간격으로 Job 상태 확인 (GET /jobs/{id})
   - 완료 시 결과 수신
```

**기대 효과**:
- **사용자 경험**: 대기 화면에서 진행 상황 표시 → 이탈률 감소
- **서버 부하**: 동기 대기 제거 → 동시 처리 가능 요청 5배 증가

**운영 고려사항**:
- Job 상태 저장: Redis (TTL 1시간)
- 폴링 간격: 5초 (UX 고려)
- Job 만료: 1시간 후 자동 삭제

#### 2.3.4 Circuit Breaker (8.30점) - 🟡 Optional

**적용 대상**:
- 모든 외부 API 연동 지점 (7개 API)

**동작 방식**:
```
1. Closed (정상):
   - 외부 API 정상 호출
   - 실패율 5% 미만

2. Open (차단):
   - 실패율 5% 초과 시 Circuit Open
   - 모든 요청 즉시 실패 (Fallback 처리)
   - 30초 대기

3. Half-Open (테스트):
   - 30초 후 1개 요청 시도
   - 성공 시 Closed로 전환
   - 실패 시 Open 유지
```

**Fallback 전략**:
- **AI 서비스**: 캐시된 이전 추천 결과 제공 + 안내 메시지
- **Distribution 서비스**: 해당 채널 배포 스킵 + 알림
- **User 서비스**: 사업자번호 검증 스킵 (수동 확인으로 대체)

**기대 효과**:
- **가용성**: 95% → 99% (외부 API 장애 격리)
- **장애 복구**: 자동 복구 시간 5분 → 30초

---

## 3. 서비스별 패턴 적용 설계

### 3.1 전체 아키텍처 (MVP)

```mermaid
graph TB
    subgraph "클라이언트"
        Client[Web/Mobile App]
    end

    subgraph "API Gateway Layer"
        Gateway[API Gateway<br/>인증, 라우팅, Rate Limiting]
    end

    subgraph "마이크로서비스"
        UserSvc[User Service<br/>회원관리]
        EventSvc[Event Service<br/>이벤트 관리]
        AISvc[AI Service<br/>트렌드 분석, 추천]
        ContentSvc[Content Service<br/>이미지 생성]
        DistSvc[Distribution Service<br/>다중 채널 배포]
        PartSvc[Participation Service<br/>참여자 관리]
        AnalSvc[Analytics Service<br/>성과 분석]
    end

    subgraph "Cache Layer"
        Redis[(Redis Cache<br/>Cache-Aside)]
    end

    subgraph "외부 API (Circuit Breaker 적용)"
        TaxAPI[국세청 API]
        ClaudeAPI[Claude API]
        SDAPI[Stable Diffusion]
        UriAPI[우리동네TV API]
        RingoAPI[링고비즈 API]
        GenieAPI[지니TV API]
        SNSAPI[SNS API]
    end

    Client -->|HTTPS| Gateway
    Gateway --> UserSvc
    Gateway --> EventSvc
    Gateway --> AISvc
    Gateway --> ContentSvc
    Gateway --> DistSvc
    Gateway --> PartSvc
    Gateway --> AnalSvc

    UserSvc -.->|Cache-Aside| Redis
    AISvc -.->|Cache-Aside| Redis
    ContentSvc -.->|Cache-Aside| Redis

    UserSvc -->|Circuit Breaker| TaxAPI
    AISvc -->|Circuit Breaker| ClaudeAPI
    ContentSvc -->|Circuit Breaker| SDAPI
    DistSvc -->|Circuit Breaker| UriAPI
    DistSvc -->|Circuit Breaker| RingoAPI
    DistSvc -->|Circuit Breaker| GenieAPI
    DistSvc -->|Circuit Breaker| SNSAPI

    style Gateway fill:#e1f5ff
    style Redis fill:#ffe1e1
    style AISvc fill:#fff4e1
    style ContentSvc fill:#fff4e1
```

### 3.2 AI Service - Asynchronous Request-Reply 패턴

```mermaid
sequenceDiagram
    participant Client as 클라이언트
    participant API as API Gateway
    participant Event as Event Service
    participant AI as AI Service
    participant Cache as Redis Cache
    participant Claude as Claude API

    Client->>API: POST /api/ai/recommendations<br/>(업종, 지역, 목적)
    API->>Event: 이벤트 추천 요청
    Event->>AI: 추천 요청

    AI->>Cache: GET cached_result
    alt Cache HIT
        Cache-->>AI: 캐시된 결과
        AI-->>Event: 즉시 반환 (0.1초)
        Event-->>API: 결과
        API-->>Client: 결과 (Total: 0.2초)
    else Cache MISS
        Cache-->>AI: null
        AI-->>Event: Job ID 즉시 반환
        Event-->>API: Job ID
        API-->>Client: Job ID + 처리중 상태 (0.1초)

        AI->>Claude: 비동기 AI 호출
        Note over AI,Claude: 백그라운드 처리 (10초)
        Claude-->>AI: 추천 결과
        AI->>Cache: SET result (TTL 24h)
        AI->>AI: Job 상태 = 완료

        loop 폴링 (5초 간격)
            Client->>API: GET /api/jobs/{id}
            API->>Event: Job 상태 확인
            Event->>AI: Job 상태
            alt 완료
                AI-->>Event: 결과
                Event-->>API: 결과
                API-->>Client: 최종 결과
            else 진행중
                AI-->>Event: 진행중
                Event-->>API: 진행중
                API-->>Client: 진행 상황 (예: 70%)
            end
        end
    end
```

### 3.3 Distribution Service - Circuit Breaker 패턴

```mermaid
graph TB
    subgraph "Distribution Service"
        DistCtrl[Distribution Controller]
        CB_Uri[Circuit Breaker<br/>우리동네TV]
        CB_Ringo[Circuit Breaker<br/>링고비즈]
        CB_Genie[Circuit Breaker<br/>지니TV]
        CB_SNS[Circuit Breaker<br/>SNS]
    end

    subgraph "외부 API"
        UriAPI[우리동네TV API]
        RingoAPI[링고비즈 API]
        GenieAPI[지니TV API]
        SNSAPI[SNS API]
    end

    DistCtrl --> CB_Uri
    DistCtrl --> CB_Ringo
    DistCtrl --> CB_Genie
    DistCtrl --> CB_SNS

    CB_Uri -->|실패율 < 5%<br/>Closed| UriAPI
    CB_Uri -.->|실패율 >= 5%<br/>Open, Fallback| Fallback_Uri[배포 스킵<br/>+ 알림]

    CB_Ringo -->|실패율 < 5%<br/>Closed| RingoAPI
    CB_Ringo -.->|실패율 >= 5%<br/>Open, Fallback| Fallback_Ringo[배포 스킵<br/>+ 알림]

    CB_Genie -->|실패율 < 5%<br/>Closed| GenieAPI
    CB_Genie -.->|실패율 >= 5%<br/>Open, Fallback| Fallback_Genie[배포 스킵<br/>+ 알림]

    CB_SNS -->|실패율 < 5%<br/>Closed| SNSAPI
    CB_SNS -.->|실패율 >= 5%<br/>Open, Fallback| Fallback_SNS[배포 스킵<br/>+ 알림]

    style CB_Uri fill:#ffe1e1
    style CB_Ringo fill:#ffe1e1
    style CB_Genie fill:#ffe1e1
    style CB_SNS fill:#ffe1e1
```

---

## 4. MVP 구현 로드맵

### 4.1 단일 Phase MVP 전략

**목표**: 빠른 출시와 안정적 서비스 제공

**기간**: 12주

**목표 지표**:
- 사용자: 100명
- 동시 이벤트: 50개
- 시스템 가용성: 99%
- AI 응답 시간: 10초 이내 (캐시 미스), 0.1초 (캐시 히트)

### 4.2 구현 순서 및 일정

| 주차 | 작업 내용 | 패턴 적용 | 완료 기준 |
|------|----------|-----------|-----------|
| **1-2주** | 인프라 구축 | API Gateway | - Kong/AWS API Gateway 설정<br/>- Redis 클러스터 구축<br/>- JWT 인증 구현 |
| **3-4주** | User/Event 서비스 | Cache-Aside | - 회원가입/로그인 완료<br/>- 사업자번호 검증 캐싱<br/>- 이벤트 CRUD 완료 |
| **5-6주** | AI 서비스 | Asynchronous Request-Reply<br/>Cache-Aside | - Claude API 연동<br/>- Job 기반 비동기 처리<br/>- AI 결과 캐싱 (24시간 TTL) |
| **7-8주** | Content 서비스 | Asynchronous Request-Reply<br/>Cache-Aside | - Stable Diffusion 연동<br/>- 이미지 생성 Job 처리<br/>- 이미지 캐싱 및 CDN |
| **9-10주** | Distribution 서비스 | Circuit Breaker | - 7개 외부 API 연동<br/>- 각 API별 Circuit Breaker<br/>- Fallback 전략 구현 |
| **11주** | Participation/Analytics | Cache-Aside | - 참여자 관리 및 추첨<br/>- 대시보드 데이터 캐싱 |
| **12주** | 테스트 및 출시 | 전체 패턴 검증 | - 부하 테스트 (100명)<br/>- 장애 시나리오 테스트<br/>- MVP 출시 |

### 4.3 기술 스택

**백엔드**:
- Spring Boot 3.2 (Java 17) / Node.js 20
- Redis 7.2 (Cache)
- PostgreSQL 15 (주 DB)
- RabbitMQ / Kafka (비동기 처리, Optional)

**프론트엔드**:
- React 18 + TypeScript 5
- Next.js 14 (SSR)
- Zustand (상태관리)
- React Query (서버 상태 관리)

**인프라**:
- Docker + Kubernetes
- Kong API Gateway / AWS API Gateway
- Resilience4j (Circuit Breaker)
- Prometheus + Grafana (모니터링)

**외부 API**:
- Claude API / GPT-4 API
- Stable Diffusion API
- 국세청 사업자등록정보 진위확인 API
- 우리동네TV, 링고비즈, 지니TV, SNS API

---

## 5. 예상 성과

### 5.1 성능 개선

| 항목 | Before | After | 개선율 |
|------|--------|-------|--------|
| AI 응답 시간 (캐시 히트) | 10초 | 0.1초 | **99% 개선** |
| AI 응답 시간 (캐시 미스) | 10초 | 10초 | - |
| 이미지 생성 시간 (캐시 히트) | 5초 | 0.1초 | **98% 개선** |
| 대시보드 로딩 시간 | 3초 | 0.5초 | **83% 개선** |

### 5.2 비용 절감

**AI API 비용 절감** (캐시 히트율 80% 가정):
- Before: 1,000 요청/일 × $0.02 = **$20/일** = **$600/월**
- After: 200 요청/일 × $0.02 = **$4/일** = **$120/월**
- **절감액**: $480/월 (**80% 절감**)

**이미지 생성 비용 절감** (캐시 히트율 80% 가정):
- Before: 500 이미지/일 × $0.04 = **$20/일** = **$600/월**
- After: 100 이미지/일 × $0.04 = **$4/일** = **$120/월**
- **절감액**: $480/월 (**80% 절감**)

**총 비용 절감**:
- Before: $1,200/월
- After: $240/월
- **총 절감액**: **$960/월** (**80% 절감**)

### 5.3 가용성 개선

| 지표 | Before | After | 개선 |
|------|--------|-------|------|
| 시스템 가용성 | 95% | 99% | **+4%p** |
| 외부 API 장애 시 서비스 지속 | ❌ 불가 | ✅ 가능 (Fallback) | - |
| 장애 자동 복구 시간 | 5분 (수동) | 30초 (자동) | **90% 단축** |

### 5.4 개발 생산성

| 항목 | 효과 |
|------|------|
| API Gateway | 각 서비스 인증 로직 제거 → 개발 시간 **30% 단축** |
| Cache-Aside | 반복 API 호출 제거 → 테스트 시간 **50% 단축** |
| Circuit Breaker | 장애 처리 로직 자동화 → 예외 처리 코드 **40% 감소** |
| Async Request-Reply | 동시 처리 능력 **5배 증가** |

---

## 6. 운영 고려사항

### 6.1 모니터링 지표

**Cache-Aside**:
- 캐시 히트율 (목표: 80% 이상)
- Redis 메모리 사용률 (목표: 70% 이하)
- 캐시 응답 시간 (목표: 100ms 이하)

**API Gateway**:
- 요청 처리량 (TPS)
- 평균 응답 시간
- 인증 실패율

**Circuit Breaker**:
- API별 실패율
- Circuit 상태 (Closed/Open/Half-Open)
- Fallback 호출 횟수

**Asynchronous Request-Reply**:
- Job 처리 시간
- 동시 Job 수
- Job 완료율

### 6.2 알람 임계값

| 지표 | Warning | Critical |
|------|---------|----------|
| 캐시 히트율 | < 70% | < 50% |
| Redis 메모리 | > 80% | > 90% |
| API 응답 시간 | > 500ms | > 1000ms |
| Circuit Breaker Open | 1개 | 3개 이상 |
| 시스템 가용성 | < 99% | < 95% |

### 6.3 장애 대응 절차

**Circuit Breaker Open 발생 시**:
1. 알람 수신 (Slack/Email)
2. 해당 외부 API 상태 확인
3. Fallback 전략 동작 확인
4. 30초 후 자동 복구 확인
5. 복구 실패 시 수동 개입

**캐시 장애 시**:
1. Redis 클러스터 상태 확인
2. Failover 자동 수행 (Sentinel)
3. 캐시 미스로 전환 (성능 저하 허용)
4. 긴급 Redis 복구

---

## 7. 체크리스트

### 7.1 패턴 적용 완료 확인

- [x] **Cache-Aside**: AI 결과, 이미지, 사업자번호 검증 캐싱 완료
- [x] **API Gateway**: 인증, 라우팅, Rate Limiting 구현 완료
- [x] **Asynchronous Request-Reply**: AI 및 이미지 생성 Job 처리 완료
- [x] **Circuit Breaker**: 7개 외부 API에 Circuit Breaker 및 Fallback 적용 완료

### 7.2 성능 목표 달성 확인

- [ ] AI 응답 시간: 10초 이내 (캐시 미스), 0.1초 (캐시 히트)
- [ ] 캐시 히트율: 80% 이상
- [ ] 시스템 가용성: 99% 이상
- [ ] 비용 절감: 월 $960 (80%)

### 7.3 운영 준비 완료 확인

- [ ] 모니터링 대시보드 구축 (Prometheus + Grafana)
- [ ] 알람 설정 완료 (Slack/Email)
- [ ] 장애 대응 매뉴얼 작성
- [ ] 부하 테스트 완료 (100명)

---

## 8. 다음 단계 (Phase 2 이후)

**MVP 이후 확장 계획** (선택 사항):

- **Retry 패턴**: 일시적 오류 자동 재시도 (현재는 Circuit Breaker로 커버)
- **Queue-Based Load Leveling**: 트래픽 폭증 시 부하 분산
- **Saga 패턴**: 복잡한 분산 트랜잭션 관리 (이벤트 생성 플로우)
- **CQRS**: 읽기/쓰기 분리로 대시보드 성능 최적화
- **Event Sourcing**: 이벤트 변경 이력 추적 및 감사

---

## 참고 문서

- [유저스토리](../userstory.md)
- [UI/UX 설계서](../uiux/uiux.md)
- [클라우드 디자인 패턴 개요](../../claude/cloud-design-patterns.md)
- [백업 파일](./architecture-pattern-backup.md) - 이전 버전 (9개 패턴)