클라우드 아키텍처 패턴 선정서 작성 완료

- 3개 핵심 패턴으로 간소화 (API Gateway, Async Request-Reply, Circuit Breaker)
- 기존 10개 패턴 문서 백업 (architecture-pattern-backup-20251021.md)
- 버전 2.0으로 업데이트
- Phase 1 MVP 중심 3개월 로드맵 작성
- 서비스별 패턴 적용 설계 및 시퀀스 다이어그램 작성
- 성과 지표 및 리스크 관리 방안 정리

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

design/pattern/architecture-pattern.md

@@ -2,7 +2,7 @@
 
 **작성일**: 2025-10-21
 **작성자**: System Architect (박영자)
-**버전**: 1.0
+**버전**: 2.0 (3개 핵심 패턴 적용)
 
 ---
 
@@ -128,7 +128,6 @@
 
 **기술적 도전과제**:
 - **다중 데이터 소스 통합 (KT API, POS, SNS API)**
-- CQRS 패턴으로 읽기/쓰기 분리
 - 5분 간격 스케줄러 기반 수집
 - 대시보드 실시간 업데이트
 
@@ -150,7 +149,6 @@
 - 성공/실패 패턴 자동 학습
 - 업종별/지역별 데이터 축적
 - 추천 정확도 향상 알고리즘
-- Event Sourcing으로 학습 데이터 추적
 
 ---
 
@@ -159,10 +157,10 @@
 #### 성능 목표 요약
 | 서비스 | 목표 응답시간 | 핵심 최적화 전략 |
 |--------|--------------|------------------|
-| Event Planning | **10초 이내** | AI API 병렬 호출, 응답 캐싱 |
+| Event Planning | **10초 이내** | AI API 병렬 호출 |
 | Content Generation | **5-8분 이내** | 이미지+영상 병렬 생성, 비동기 처리 |
 | Distribution | **1분 이내** | 6개 채널 병렬 배포 |
-| Analytics | **5분 주기** | CQRS 읽기/쓰기 분리, 스케줄러 수집 |
+| Analytics | **5분 주기** | 스케줄러 수집 |
 
 #### 확장성 요구사항
 - **동시 이벤트 처리**: 최소 100개
@@ -181,26 +179,19 @@
 
 ### 2.1 패턴 평가 매트릭스
 
-#### 핵심 패턴 Top 10 정량 평가
+#### 핵심 패턴 정량 평가
 
 | 패턴 | 기능 적합성<br/>(35%) | 성능 효과<br/>(25%) | 운영 복잡도<br/>(20%) | 확장성<br/>(15%) | 비용 효율성<br/>(5%) | **총점** | **우선순위** |
 |------|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
 | **API Gateway** | 10 × 0.35 = 3.5 | 9 × 0.25 = 2.25 | 9 × 0.20 = 1.8 | 9 × 0.15 = 1.35 | 8 × 0.05 = 0.4 | **9.30** | 🥇 1위 |
 | **Async Request-Reply** | 10 × 0.35 = 3.5 | 9 × 0.25 = 2.25 | 7 × 0.20 = 1.4 | 8 × 0.15 = 1.2 | 7 × 0.05 = 0.35 | **8.70** | 🥈 2위 |
 | **Circuit Breaker** | 9 × 0.35 = 3.15 | 7 × 0.25 = 1.75 | 8 × 0.20 = 1.6 | 8 × 0.15 = 1.2 | 8 × 0.05 = 0.4 | **8.10** | 🥉 3위 |
-| **CQRS** | 9 × 0.35 = 3.15 | 9 × 0.25 = 2.25 | 5 × 0.20 = 1.0 | 8 × 0.15 = 1.2 | 6 × 0.05 = 0.3 | **7.90** | 4위 |
-| **Cache-Aside** | 8 × 0.35 = 2.8 | 9 × 0.25 = 2.25 | 9 × 0.20 = 1.8 | 7 × 0.15 = 1.05 | 9 × 0.05 = 0.45 | **8.35** | 5위 |
-| **Event Sourcing** | 9 × 0.35 = 3.15 | 7 × 0.25 = 1.75 | 4 × 0.20 = 0.8 | 9 × 0.15 = 1.35 | 5 × 0.05 = 0.25 | **7.30** | 6위 |
-| **Queue-Based Load Leveling** | 8 × 0.35 = 2.8 | 8 × 0.25 = 2.0 | 7 × 0.20 = 1.4 | 9 × 0.15 = 1.35 | 7 × 0.05 = 0.35 | **7.90** | 7위 |
-| **Retry** | 7 × 0.35 = 2.45 | 6 × 0.25 = 1.5 | 9 × 0.20 = 1.8 | 6 × 0.15 = 0.9 | 9 × 0.05 = 0.45 | **7.10** | 8위 |
-| **Publisher-Subscriber** | 8 × 0.35 = 2.8 | 7 × 0.25 = 1.75 | 6 × 0.20 = 1.2 | 8 × 0.15 = 1.2 | 7 × 0.05 = 0.35 | **7.30** | 9위 |
-| **Choreography** | 7 × 0.35 = 2.45 | 6 × 0.25 = 1.5 | 5 × 0.20 = 1.0 | 8 × 0.15 = 1.2 | 6 × 0.05 = 0.3 | **6.45** | 10위 |
 
 ---
 
 ### 2.2 선정 패턴 및 적용 전략
 
-#### 🥇 **1. API Gateway** (총점: 9.30) - Phase 1 MVP
+#### 🥇 **1. API Gateway** (총점: 9.30)
 
 **선정 이유**:
 - 단일 진입점으로 7개 마이크로서비스 라우팅
@@ -215,23 +206,34 @@
 - 인증 처리 시간 50% 단축
 - 서비스 간 결합도 감소
 
+**구현 기술**:
+- **기술 스택**: Kong, AWS API Gateway, Spring Cloud Gateway
+- **Rate Limiting**: 사용자당 1분 100 요청
+- **JWT 토큰**: 만료 시간 1시간, Refresh Token 7일
+- **로깅**: 모든 요청/응답 로그 저장 (CloudWatch, ELK)
+
 ---
 
-#### 🥈 **2. Async Request-Reply** (총점: 8.70) - Phase 1 MVP
+#### 🥈 **2. Async Request-Reply** (총점: 8.70)
 
 **선정 이유**:
 - **Content Generation 서비스의 5-8분 처리 시간 대응**
 - 이미지/영상 생성 백그라운드 처리
-- 진행 상황 실시간 피드백 (WebSocket/폴링)
+- 진행 상황 실시간 피드백 (폴링)
 - 클라이언트 블로킹 방지
 
-**적용 서비스**: Content Generation, AI Learning
+**적용 서비스**: Content Generation
 
 **예상 효과**:
 - 사용자 대기 시간 체감 80% 감소
 - 시스템 응답성 향상
 - 동시 콘텐츠 생성 50개 처리 가능
 
+**구현 기술**:
+- **Job ID 관리**: UUID v4 사용
+- **상태 폴링**: 5초 간격, 최대 10분 타임아웃
+- **상태 관리**: Redis 또는 DB 기반 Job 상태 추적
+
 **구현 예시**:
 ```javascript
 // 클라이언트: 콘텐츠 생성 요청
@@ -253,7 +255,7 @@ const checkStatus = setInterval(async () => {
 
 ---
 
-#### 🥉 **3. Circuit Breaker** (총점: 8.10) - Phase 1 MVP
+#### 🥉 **3. Circuit Breaker** (총점: 8.10)
 
 **선정 이유**:
 - **6개 외부 API 장애 대응 (KT 채널, AI API, SNS)**
@@ -268,6 +270,12 @@ const checkStatus = setInterval(async () => {
 - 시스템 가용성 99.9% 보장
 - 배포 성공률 98% 이상 유지
 
+**구현 기술**:
+- **타임아웃 설정**: 외부 API별 차등 (15초 ~ 60초)
+- **실패 임계값**: 50% 실패 시 OPEN
+- **재시도 간격**: 30초 후 HALF-OPEN
+- **폴백 전략**: 기본값 제공 또는 실패 메시지
+
 **구현 예시** (Node.js with opossum):
 ```javascript
 const CircuitBreaker = require('opossum');
@@ -283,162 +291,36 @@ const breaker = new CircuitBreaker(callWooridongneTV, {
   resetTimeout: 30000 // 30초 후 재시도
 });
 
-breaker.fallback(() => ({ success: false, message: '우리동네TV 배포 실패' }));
+breaker.fallback(() => ({
+  success: false,
+  message: '우리동네TV 배포 실패'
+}));
 
 // 배포 요청
 const result = await breaker.fire(deployData);
 ```
 
----
+**Spring Boot 예시** (Resilience4j):
+```java
+@Service
+public class DistributionService {
 
-#### **4. Cache-Aside** (총점: 8.35) - Phase 1 MVP
-
-**선정 이유**:
-- Event Planning 서비스의 10초 응답 목표 달성
-- 트렌드 데이터베이스 조회 성능 향상
-- AI API 응답 캐싱 (동일 조건 재사용)
-- Redis 활용 고속 캐싱
-
-**적용 서비스**: Event Planning, Analytics
-
-**예상 효과**:
-- 트렌드 분석 응답 시간 70% 단축 (3초 → 0.9초)
-- AI API 호출 횟수 40% 감소
-- 비용 절감 (AI API 사용량 감소)
-
-**구현 예시**:
-```javascript
-// 트렌드 데이터 조회 (캐시 우선)
-const getTrendData = async (industry, region) => {
-  const cacheKey = `trend:${industry}:${region}`;
-
-  // 1. 캐시 조회
-  let data = await redis.get(cacheKey);
-
-  if (data) {
-    return JSON.parse(data); // 캐시 히트
+    @CircuitBreaker(name = "wooridongneTV", fallbackMethod = "fallbackDeploy")
+    public DeployResult deployToWooridongneTV(DeployData data) {
+        return wooridongneAPI.deploy(data);
     }
 
-  // 2. DB 조회
-  data = await db.query('SELECT * FROM trends WHERE industry = ? AND region = ?', [industry, region]);
-
-  // 3. 캐시 저장 (TTL: 1시간)
-  await redis.setex(cacheKey, 3600, JSON.stringify(data));
-
-  return data;
-};
+    private DeployResult fallbackDeploy(DeployData data, Exception e) {
+        return DeployResult.builder()
+            .success(false)
+            .message("우리동네TV 배포 실패: " + e.getMessage())
+            .build();
+    }
+}
 ```
 
 ---
 
-#### **5. CQRS** (총점: 7.90) - Phase 2 확장
-
-**선정 이유**:
-- **Analytics 서비스의 읽기/쓰기 분리**
-- 실시간 대시보드 조회 성능 최적화
-- 5분 간격 데이터 수집과 실시간 조회 분리
-- 읽기 전용 DB로 복잡한 집계 쿼리 처리
-
-**적용 서비스**: Analytics
-
-**예상 효과**:
-- 대시보드 조회 속도 80% 향상
-- 쓰기 작업 영향 없이 읽기 확장 가능
-- 복잡한 ROI 계산 성능 개선
-
-**아키텍처**:
-```mermaid
-graph LR
-    Client[클라이언트] --> ReadAPI[읽기 API]
-    Client --> WriteAPI[쓰기 API]
-
-    WriteAPI --> CommandDB[(Command DB<br/>쓰기 전용)]
-    CommandDB --> EventBus[이벤트 버스]
-    EventBus --> ReadDB[(Query DB<br/>읽기 전용)]
-    ReadAPI --> ReadDB
-```
-
----
-
-#### **6. Event Sourcing** (총점: 7.30) - Phase 3 고도화
-
-**선정 이유**:
-- AI Learning 서비스의 학습 데이터 추적
-- 이벤트 전체 이력 저장 및 재생
-- 감사 추적 (Audit Trail) 요구사항 충족
-- 성공/실패 패턴 분석 정확도 향상
-
-**적용 서비스**: AI Learning, Participation
-
-**예상 효과**:
-- AI 학습 정확도 30% 향상
-- 데이터 멱등성 100% 보장
-- 과거 데이터 재분석 가능
-
----
-
-#### **7. Queue-Based Load Leveling** (총점: 7.90) - Phase 2 확장
-
-**선정 이유**:
-- Distribution 서비스의 배포 요청 급증 대응
-- 100개 동시 배포 요청 큐잉 처리
-- 백엔드 서비스 부하 평준화
-- 배포 실패 재시도 관리
-
-**적용 서비스**: Distribution, Content Generation
-
-**예상 효과**:
-- 피크 타임 안정성 99.9% 유지
-- 배포 성공률 98% 이상
-- 시스템 과부하 방지
-
----
-
-#### **8. Retry** (총점: 7.10) - Phase 1 MVP
-
-**선정 이유**:
-- Distribution 서비스의 배포 실패 자동 재시도 (3회)
-- 외부 API 일시적 오류 복구
-- Circuit Breaker와 조합 사용
-
-**적용 서비스**: Distribution, Event Planning
-
-**예상 효과**:
-- 배포 성공률 15% 향상
-- 일시적 네트워크 오류 자동 복구
-
----
-
-#### **9. Publisher-Subscriber** (총점: 7.30) - Phase 2 확장
-
-**선정 이유**:
-- 이벤트 완료 시 다중 서비스 알림 (Analytics, AI Learning)
-- 서비스 간 결합도 감소
-- 비동기 이벤트 처리
-
-**적용 서비스**: 전체 서비스 (이벤트 기반 통신)
-
-**예상 효과**:
-- 서비스 간 결합도 70% 감소
-- 새로운 서비스 추가 용이성
-
----
-
-#### **10. Choreography** (총점: 6.45) - Phase 3 고도화
-
-**선정 이유**:
-- Saga 패턴 대안으로 중앙 조정자 없는 워크플로
-- Event Planning → Content Generation → Distribution 자율 조정
-- 확장성 및 유연성 향상
-
-**적용 서비스**: 이벤트 생성 워크플로
-
-**예상 효과**:
-- 워크플로 확장성 향상
-- 중앙 병목 현상 제거
-
----
-
 ## 3. 서비스별 패턴 적용 설계
 
 ### 3.1 전체 아키텍처 구조
@@ -456,12 +338,12 @@ graph TB
 
     subgraph "마이크로서비스"
         User[User 서비스<br/>회원/매장 관리]
-        Planning[Event Planning 서비스<br/>AI 이벤트 기획<br/>Cache-Aside]
+        Planning[Event Planning 서비스<br/>AI 이벤트 기획]
         Content[Content Generation 서비스<br/>AI 콘텐츠 생성<br/>Async Request-Reply]
-        Dist[Distribution 서비스<br/>다중 채널 배포<br/>Circuit Breaker + Retry]
+        Dist[Distribution 서비스<br/>다중 채널 배포<br/>Circuit Breaker]
         Participation[Participation 서비스<br/>참여/추첨 관리]
-        Analytics[Analytics 서비스<br/>효과 측정<br/>CQRS]
-        AILearn[AI Learning 서비스<br/>학습/개선<br/>Event Sourcing]
+        Analytics[Analytics 서비스<br/>효과 측정]
+        AILearn[AI Learning 서비스<br/>학습/개선]
     end
 
     subgraph "데이터 계층"
@@ -470,19 +352,9 @@ graph TB
         ContentDB[(Content DB<br/>MongoDB)]
         DistDB[(Distribution DB<br/>PostgreSQL)]
         PartDB[(Participation DB<br/>PostgreSQL)]
-
-        subgraph "CQRS - Analytics"
-            WriteDB[(Command DB<br/>쓰기)]
-            ReadDB[(Query DB<br/>읽기)]
-        end
-
-        EventStore[(Event Store<br/>AI Learning)]
-
-        Cache[(Redis Cache<br/>Cache-Aside)]
-    end
-
-    subgraph "메시지 큐"
-        Queue[RabbitMQ/Kafka<br/>Queue-Based Load Leveling<br/>Pub-Sub]
+        AnalyticsDB[(Analytics DB<br/>MongoDB)]
+        AILearnDB[(AI Learning DB<br/>MongoDB)]
+        JobStore[(Job Store<br/>Redis)]
     end
 
     subgraph "외부 시스템"
@@ -506,29 +378,21 @@ graph TB
 
     User --> UserDB
     Planning --> PlanningDB
-    Planning --> Cache
     Content --> ContentDB
-    Content --> Queue
+    Content --> JobStore
     Dist --> DistDB
-    Dist --> Queue
     Participation --> PartDB
-    Analytics --> WriteDB
-    Analytics --> ReadDB
-    WriteDB --> Queue
-    Queue --> ReadDB
-    AILearn --> EventStore
+    Analytics --> AnalyticsDB
+    AILearn --> AILearnDB
 
     Planning -->|Circuit Breaker| AIAPI
     Content -->|Circuit Breaker| AIAPI
-    Dist -->|Circuit Breaker + Retry| KTAPI
-    Dist -->|Circuit Breaker + Retry| SNS
+    Dist -->|Circuit Breaker| KTAPI
+    Dist -->|Circuit Breaker| SNS
     Dist -->|Circuit Breaker| Clova
     Analytics --> KTAPI
     Analytics --> SNS
     Analytics --> POS
-
-    Queue -->|Pub-Sub| Analytics
-    Queue -->|Pub-Sub| AILearn
 ```
 
 ---
@@ -536,7 +400,6 @@ graph TB
 ### 3.2 Event Planning 서비스 - 10초 응답 최적화
 
 **패턴 적용**:
-- **Cache-Aside**: 트렌드 데이터 캐싱
 - **Circuit Breaker**: Claude + GPT-4 API 장애 대응
 - **병렬 처리**: AI API 동시 호출
 
@@ -546,7 +409,6 @@ sequenceDiagram
     participant Client
     participant Gateway
     participant Planning as Event Planning
-    participant Cache as Redis Cache
     participant DB as Planning DB
     participant Claude as Claude API
     participant GPT4 as GPT-4 API
@@ -554,15 +416,9 @@ sequenceDiagram
     Client->>Gateway: 이벤트 기획 시작
     Gateway->>Planning: 기획 요청
 
-    Note over Planning,Cache: Phase 1: 트렌드 분석 (3초 목표)
-    Planning->>Cache: 트렌드 데이터 조회
-    alt 캐시 히트
-        Cache-->>Planning: 캐시 데이터 반환
-    else 캐시 미스
-        Planning->>DB: DB 조회
+    Note over Planning,DB: Phase 1: 트렌드 분석 (3초 목표)
+    Planning->>DB: 트렌드 데이터 조회
     DB-->>Planning: 트렌드 데이터
-        Planning->>Cache: 캐시 저장 (TTL: 1시간)
-    end
 
     Note over Planning,GPT4: Phase 2: AI 병렬 호출 (7초 목표)
     par Claude: 이벤트상품 + 참여방법
@@ -580,7 +436,6 @@ sequenceDiagram
 
 **예상 성과**:
 - **총 응답시간: 10초 이내** (목표 달성)
-- 트렌드 분석: 3초 → 0.9초 (캐시 히트 시)
 - AI API 병렬 호출: 9초 → 5초
 
 ---
@@ -589,7 +444,6 @@ sequenceDiagram
 
 **패턴 적용**:
 - **Async Request-Reply**: 5-8분 장시간 처리
-- **Queue-Based Load Leveling**: 동시 50개 콘텐츠 생성
 - **Circuit Breaker**: Stable Diffusion API 장애 대응
 
 **아키텍처**:
@@ -598,7 +452,7 @@ sequenceDiagram
     participant Client
     participant Gateway
     participant Content as Content Generation
-    participant Queue as RabbitMQ
+    participant JobStore as Job Store (Redis)
     participant Worker as Background Worker
     participant SD as Stable Diffusion
     participant VideoAI as AI Video Engine
@@ -606,14 +460,13 @@ sequenceDiagram
 
     Client->>Gateway: 콘텐츠 생성 요청
     Gateway->>Content: 생성 요청
-    Content->>DB: Job 생성 (상태: PENDING)
-    Content->>Queue: 작업 큐잉
+    Content->>JobStore: Job 생성 (상태: PENDING)
     Content-->>Gateway: Job ID 발급
     Gateway-->>Client: Job ID 반환
 
     Note over Client: 클라이언트는 다른 작업 가능
 
-    Queue->>Worker: 작업 할당
+    Content->>Worker: 비동기 작업 시작
 
     par 이미지 3종 생성 (2-3분)
         Worker->>SD: 이미지 생성 요청 (3건 병렬)
@@ -623,13 +476,14 @@ sequenceDiagram
         VideoAI-->>Worker: 15초 영상
     end
 
-    Worker->>DB: 콘텐츠 저장 + 상태 업데이트 (COMPLETED)
+    Worker->>DB: 콘텐츠 저장
+    Worker->>JobStore: 상태 업데이트 (COMPLETED)
 
     loop 상태 확인 (5초 간격)
         Client->>Gateway: Job 상태 조회
         Gateway->>Content: 상태 조회
-        Content->>DB: 상태 확인
-        DB-->>Content: 상태 + 진행률
+        Content->>JobStore: 상태 확인
+        JobStore-->>Content: 상태 + 진행률
         Content-->>Gateway: 진행 상황 (예: 60% 완료)
         Gateway-->>Client: 진행률 표시
     end
@@ -651,8 +505,7 @@ sequenceDiagram
 
 **패턴 적용**:
 - **Circuit Breaker**: 6개 외부 API 장애 대응
-- **Retry**: 배포 실패 자동 재시도 (3회)
-- **Queue-Based Load Leveling**: 100개 동시 배포
+- **병렬 배포**: 6개 채널 동시 배포
 
 **아키텍처**:
 ```mermaid
@@ -660,7 +513,6 @@ sequenceDiagram
     participant Client
     participant Gateway
     participant Dist as Distribution
-    participant Queue as RabbitMQ
     participant CB1 as Circuit Breaker<br/>(우리동네TV)
     participant CB2 as Circuit Breaker<br/>(지니TV)
     participant CB3 as Circuit Breaker<br/>(Instagram)
@@ -669,31 +521,24 @@ sequenceDiagram
 
     Client->>Gateway: 배포 요청 (6개 채널)
     Gateway->>Dist: 배포 시작
-    Dist->>Queue: 배포 작업 큐잉
 
     par 병렬 배포 (1분 목표)
-        Queue->>CB1: 우리동네TV 배포
+        Dist->>CB1: 우리동네TV 배포
         CB1->>KTAPI: API 호출
         alt API 성공
             KTAPI-->>CB1: 배포 완료
         else API 실패
             KTAPI--xCB1: 오류
-            CB1->>CB1: Retry (최대 3회)
-            alt Retry 성공
-                CB1->>KTAPI: 재시도
-                KTAPI-->>CB1: 배포 완료
-            else Retry 실패
-                CB1-->>Queue: 배포 실패 (OPEN 상태)
-            end
+            CB1-->>Dist: Fallback (배포 실패)
         end
         CB1-->>Dist: 결과 반환
     and
-        Queue->>CB2: 지니TV 배포
+        Dist->>CB2: 지니TV 배포
         CB2->>KTAPI: API 호출
         KTAPI-->>CB2: 배포 완료
         CB2-->>Dist: 결과 반환
     and
-        Queue->>CB3: Instagram 배포
+        Dist->>CB3: Instagram 배포
         CB3->>SNS: API 호출
         SNS-->>CB3: 포스팅 완료
         CB3-->>Dist: 결과 반환
@@ -705,63 +550,12 @@ sequenceDiagram
 
 **예상 성과**:
 - **총 배포시간: 1분 이내** (목표 달성)
-- 배포 성공률: 95% → 98% (Retry)
 - API 장애 시 응답: 30초 → 3초 (Circuit Breaker)
+- 배포 안정성: 95% → 98%
 
 ---
 
-### 3.5 Analytics 서비스 - CQRS 읽기/쓰기 분리
-
-**패턴 적용**:
-- **CQRS**: 읽기/쓰기 분리
-- **Publisher-Subscriber**: 5분 간격 데이터 수집
-
-**아키텍처**:
-```mermaid
-graph TB
-    subgraph "쓰기 모델"
-        Collector[데이터 수집기<br/>5분 스케줄러]
-        WriteAPI[쓰기 API]
-        CommandDB[(Command DB<br/>원본 데이터)]
-    end
-
-    subgraph "이벤트 버스"
-        EventBus[RabbitMQ<br/>Pub-Sub]
-    end
-
-    subgraph "읽기 모델"
-        ReadAPI[읽기 API<br/>대시보드]
-        QueryDB[(Query DB<br/>집계 데이터)]
-        Aggregator[집계 프로세서]
-    end
-
-    subgraph "외부 데이터 소스"
-        KTAPI[KT API]
-        SNS[SNS API]
-        POS[POS]
-    end
-
-    Collector -->|5분마다| KTAPI
-    Collector -->|5분마다| SNS
-    Collector -->|5분마다| POS
-    Collector --> WriteAPI
-    WriteAPI --> CommandDB
-    CommandDB --> EventBus
-    EventBus --> Aggregator
-    Aggregator -->|ROI 계산<br/>채널별 집계| QueryDB
-    ReadAPI --> QueryDB
-
-    Client[클라이언트<br/>대시보드] -->|실시간 조회| ReadAPI
-```
-
-**예상 성과**:
-- 대시보드 조회 속도: 5초 → 1초 (80% 향상)
-- ROI 계산 응답: 10초 → 2초
-- 동시 조회 처리: 100개 대시보드
-
----
-
-## 4. Phase별 구현 로드맵
+## 4. 구현 로드맵
 
 ### Phase 1: MVP (Minimum Viable Product) - 3개월
 
@@ -771,27 +565,27 @@ graph TB
 1. **API Gateway** - 단일 진입점 및 인증/인가
 2. **Async Request-Reply** - 콘텐츠 생성 비동기 처리
 3. **Circuit Breaker** - 외부 API 장애 대응
-4. **Cache-Aside** - 트렌드 데이터 캐싱
-5. **Retry** - 배포 실패 자동 재시도
 
 **구현 우선순위**:
 1. **Week 1-4**: User 서비스 + API Gateway
    - 회원가입/로그인 (JWT 인증)
    - 매장 정보 관리
    - 사업자번호 검증 연동
+   - API Gateway 구축 (Kong 또는 Spring Cloud Gateway)
 
 2. **Week 5-8**: Event Planning 서비스
    - AI API 연동 (Claude, GPT-4)
-   - Cache-Aside 패턴 적용 (Redis)
    - Circuit Breaker 적용
+   - AI API 병렬 호출 구현
 
 3. **Week 9-10**: Content Generation 서비스
    - Async Request-Reply 패턴 구현
    - Stable Diffusion 연동
    - 진행 상황 폴링 API
+   - Redis 기반 Job Store 구축
 
 4. **Week 11-12**: Distribution + Participation 서비스
-   - 6개 채널 병렬 배포 (Circuit Breaker + Retry)
+   - 6개 채널 병렬 배포 (Circuit Breaker)
    - 추첨/선착순 분기 로직
 
 **성공 지표**:
@@ -802,185 +596,68 @@ graph TB
 
 ---
 
-### Phase 2: 확장 (Scale-up) - 3개월
-
-**목표**: 성능 최적화 및 사용자 증가 대응
-
-**추가 패턴**:
-6. **CQRS** - Analytics 읽기/쓰기 분리
-7. **Queue-Based Load Leveling** - 피크 타임 부하 평준화
-8. **Publisher-Subscriber** - 서비스 간 이벤트 기반 통신
-
-**구현 계획**:
-1. **Week 1-4**: Analytics 서비스 CQRS 적용
-   - Command DB / Query DB 분리
-   - 5분 간격 데이터 수집 스케줄러
-   - 실시간 대시보드 최적화
-
-2. **Week 5-8**: 메시지 큐 도입 (RabbitMQ/Kafka)
-   - Queue-Based Load Leveling 적용
-   - Publisher-Subscriber 패턴 구현
-   - 서비스 간 결합도 감소
-
-3. **Week 9-12**: 성능 모니터링 및 최적화
-   - Auto Scaling 설정
-   - 로드 밸런싱 최적화
-   - 캐시 전략 개선
-
-**성공 지표**:
-- 동시 이벤트 처리: 100개 ✅
-- 대시보드 조회 속도: 1초 이내 ✅
-- 시스템 가용성: 99.9% ✅
-
----
-
-### Phase 3: 고도화 (Advanced) - 6개월
-
-**목표**: AI 학습 고도화 및 글로벌 확장
-
-**추가 패턴**:
-9. **Event Sourcing** - AI Learning 학습 데이터 추적
-10. **Choreography** - 워크플로 자율 조정
-
-**구현 계획**:
-1. **Week 1-8**: AI Learning 서비스 고도화
-   - Event Sourcing 패턴 적용
-   - 성공/실패 패턴 학습 고도화
-   - 추천 정확도 30% 향상
-
-2. **Week 9-16**: Choreography 패턴 적용
-   - Event Planning → Content → Distribution 자율 조정
-   - 중앙 조정자 제거
-   - 워크플로 확장성 향상
-
-3. **Week 17-24**: 글로벌 확장 대비
-   - Geodes 패턴 (다중 지역 배포)
-   - Federated Identity (글로벌 인증)
-
-**성공 지표**:
-- AI 추천 정확도: 30% 향상 ✅
-- 워크플로 확장성: 무제한 ✅
-- 글로벌 지연 시간: 100ms 이내 ✅
-
----
-
 ## 5. 예상 성과 지표
 
 ### 5.1 성능 개선
 
-| 지표 | 현재 (패턴 미적용) | Phase 1 MVP | Phase 2 확장 | Phase 3 고도화 |
-|------|-------------------|-------------|-------------|---------------|
-| **Event Planning 응답시간** | 25초 | **10초** ✅ | 8초 | 6초 |
-| **Content Generation 완료시간** | 12분 | **8분** ✅ | 6분 | 5분 |
-| **Distribution 배포시간** | 3분 | **1분** ✅ | 40초 | 30초 |
-| **Analytics 대시보드 조회** | 5초 | 3초 | **1초** ✅ | 0.5초 |
-| **동시 이벤트 처리** | 20개 | 50개 | **100개** ✅ | 300개 |
-| **시스템 가용성** | 95% | 99% | **99.9%** ✅ | 99.99% |
+| 지표 | 현재 (패턴 미적용) | Phase 1 MVP |
+|------|-------------------|-------------|
+| **Event Planning 응답시간** | 25초 | **10초** ✅ |
+| **Content Generation 완료시간** | 12분 | **8분** ✅ |
+| **Distribution 배포시간** | 3분 | **1분** ✅ |
+| **동시 이벤트 처리** | 20개 | 50개 |
+| **시스템 가용성** | 95% | 99% |
 
 ---
 
-### 5.2 비용 절감 효과
+### 5.2 패턴별 기대 효과
 
-| 항목 | 절감율 | 연간 절감액 (추정) |
-|------|--------|-------------------|
-| **AI API 호출 비용** (Cache-Aside) | 40% | ₩24,000,000 |
-| **외부 API 재시도 비용** (Circuit Breaker) | 30% | ₩9,000,000 |
-| **서버 리소스 비용** (CQRS, 캐싱) | 25% | ₩15,000,000 |
-| **운영 인력 비용** (자동화) | 20% | ₩12,000,000 |
-| **총 절감액** | - | **₩60,000,000** |
+| 패턴 | 적용 효과 | 개선율 |
+|------|----------|--------|
+| **API Gateway** | 클라이언트 통합 엔드포인트, 인증 중앙화 | 인증 처리 50% 단축 |
+| **Async Request-Reply** | 사용자 대기 시간 체감 감소 | 80% 체감 시간 감소 |
+| **Circuit Breaker** | API 장애 시 빠른 실패, 연쇄 장애 방지 | 응답 시간 95% 단축 |
 
 ---
 
-### 5.3 개발 생산성 향상
+## 6. 리스크 관리
 
-| 지표 | 개선율 |
-|------|--------|
-| **서비스 간 결합도 감소** (Pub-Sub) | 70% |
-| **장애 복구 시간** (Circuit Breaker) | 80% |
-| **새 기능 개발 속도** (패턴 재사용) | 50% |
-| **코드 재사용률** (Gateway, Sidecar) | 60% |
-
----
-
-## 6. 구현 시 고려사항
-
-### 6.1 API Gateway
-- **기술 스택**: Kong, AWS API Gateway, Azure API Management
-- **Rate Limiting**: 사용자당 1분 100 요청
-- **JWT 토큰**: 만료 시간 1시간, Refresh Token 7일
-- **로깅**: 모든 요청/응답 로그 저장 (CloudWatch, ELK)
-
-### 6.2 Async Request-Reply
-- **Job ID 관리**: UUID v4 사용
-- **상태 폴링**: 5초 간격, 최대 10분 타임아웃
-- **WebSocket 대안**: 실시간 진행 상황 푸시 (선택사항)
-
-### 6.3 Circuit Breaker
-- **타임아웃 설정**: 외부 API별 차등 (15초 ~ 60초)
-- **실패 임계값**: 50% 실패 시 OPEN
-- **재시도 간격**: 30초 후 HALF-OPEN
-- **폴백 전략**: 캐시 데이터 반환 또는 기본값 제공
-
-### 6.4 Cache-Aside
-- **캐시 TTL**: 트렌드 데이터 1시간, AI 응답 30분
-- **캐시 무효화**: 데이터 업데이트 시 자동 삭제
-- **Redis Cluster**: 고가용성 보장
-
-### 6.5 CQRS
-- **DB 선택**: Command (PostgreSQL), Query (MongoDB)
-- **동기화 지연**: 최대 5초
-- **이벤트 버스**: RabbitMQ 또는 Kafka
-
----
-
-## 7. 리스크 관리
-
-### 7.1 기술적 리스크
+### 6.1 기술적 리스크
 
 | 리스크 | 확률 | 영향도 | 완화 전략 |
 |--------|------|--------|-----------|
-| AI API 응답 지연 (>10초) | 중간 | 높음 | Cache-Aside, 프롬프트 최적화, 병렬 호출 |
-| 외부 API 장애 | 높음 | 높음 | Circuit Breaker, Retry, 폴백 전략 |
-| Redis 장애 | 낮음 | 중간 | Redis Cluster, DB 폴백 |
-| 메시지 큐 장애 | 낮음 | 높음 | Dead Letter Queue, 재처리 로직 |
+| AI API 응답 지연 (>10초) | 중간 | 높음 | 병렬 호출, 프롬프트 최적화 |
+| 외부 API 장애 | 높음 | 높음 | Circuit Breaker, 폴백 전략 |
+| Job Store (Redis) 장애 | 낮음 | 중간 | Redis Cluster, DB 폴백 |
 
-### 7.2 운영 리스크
+### 6.2 운영 리스크
 
 | 리스크 | 확률 | 영향도 | 완화 전략 |
 |--------|------|--------|-----------|
-| 피크 타임 트래픽 폭주 | 높음 | 높음 | Auto Scaling, Queue-Based Load Leveling |
-| 데이터 불일치 (CQRS) | 중간 | 중간 | 이벤트 재생, 수동 동기화 도구 |
-| 배포 실패율 증가 | 중간 | 중간 | Retry 3회, 수동 배포 옵션 |
+| 피크 타임 트래픽 폭주 | 높음 | 높음 | Auto Scaling, Rate Limiting |
+| 배포 실패율 증가 | 중간 | 중간 | Circuit Breaker 폴백 전략 |
 
 ---
 
-## 8. 결론
+## 7. 결론
 
-### 8.1 핵심 패턴 요약
+### 7.1 핵심 패턴 요약
 
-본 서비스는 **10개의 클라우드 아키텍처 패턴**을 3단계로 적용하여 성능, 확장성, 안정성을 보장합니다:
+본 서비스는 **3개의 클라우드 아키텍처 패턴**을 적용하여 성능, 확장성, 안정성을 보장합니다:
 
 1. **API Gateway**: 단일 진입점 및 횡단 관심사 분리
 2. **Async Request-Reply**: 장시간 처리 작업 비동기화
 3. **Circuit Breaker**: 외부 API 장애 대응
-4. **Cache-Aside**: 응답 시간 단축
-5. **CQRS**: 읽기/쓰기 분리로 조회 성능 최적화
-6. **Event Sourcing**: AI 학습 데이터 추적
-7. **Queue-Based Load Leveling**: 부하 평준화
-8. **Retry**: 일시적 오류 자동 복구
-9. **Publisher-Subscriber**: 서비스 간 결합도 감소
-10. **Choreography**: 워크플로 자율 조정
 
-### 8.2 예상 효과
+### 7.2 예상 효과
 
 - **Event Planning**: 25초 → **10초** (60% 단축) ✅
 - **Content Generation**: 12분 → **8분** (33% 단축) ✅
 - **Distribution**: 3분 → **1분** (67% 단축) ✅
-- **시스템 가용성**: 95% → **99.9%** ✅
-- **동시 이벤트 처리**: 20개 → **100개** (5배 향상) ✅
-- **연간 비용 절감**: **₩60,000,000** 💰
+- **시스템 가용성**: 95% → **99%** ✅
+- **동시 이벤트 처리**: 20개 → **50개** (2.5배 향상) ✅
 
-### 8.3 다음 단계
+### 7.3 다음 단계
 
 1. **Phase 1 MVP 착수** (3개월)
    - API Gateway + Async Request-Reply + Circuit Breaker 우선 구현
@@ -991,8 +668,8 @@ graph TB
    - 각 패턴별 성과 지표 측정
 
 3. **지속적 개선**
-   - Phase 2, 3 로드맵에 따라 점진적 고도화
-   - AI 학습 정확도 향상 및 글로벌 확장
+   - 추가 패턴 도입 검토 (Cache-Aside, CQRS 등)
+   - AI 학습 정확도 향상
 
 ---
 
@@ -1005,4 +682,4 @@ graph TB
 **참조 문서**:
 - design/userstory.md
 - claude/cloud-design-patterns.md
-- claude/architecture-patterns.md
+- design/pattern/architecture-pattern-backup-20251021.md (백업)