# KT AI 기반 소상공인 이벤트 자동 생성 서비스 - 클라우드 아키텍처 패턴 선정서 **작성일**: 2025-10-21 **작성자**: System Architect (박영자) **버전**: 1.0 --- ## 1. 요구사항 분석 ### 1.1 마이크로서비스별 기능 및 비기능 요구사항 #### 1.1.1 User 서비스 **기능 요구사항**: - 회원가입/로그인 (JWT 인증) - 매장 정보 관리 및 사업자번호 검증 - KT 인증 시스템 연동 **비기능 요구사항**: - 응답시간: 1초 이내 - 가용성: 99.9% - 보안: 개인정보 암호화 (AES-256), HTTPS/TLS - 확장성: 1,000 동시 사용자 **기술적 도전과제**: - 외부 사업자번호 검증 API 의존성 - 인증 토큰 관리 및 세션 유지 - 개인정보 보호 규정 준수 --- #### 1.1.2 Event Planning 서비스 **기능 요구사항**: - AI 기반 업종/지역 트렌드 분석 - AI 이벤트상품 추천 (Claude API) - AI 참여 방법 설계 - AI 홍보 문구 생성 (GPT-4 API) **비기능 요구사항**: - **응답시간: 10초 이내 (전체 기획 과정)** ⚡ - AI API 병렬 호출 필수 - 추첨형/선착순형 이벤트 자동 프로세스 분기 - 확장성: 100개 동시 이벤트 기획 **기술적 도전과제**: - **Claude + GPT-4 API 병렬 호출 및 응답 시간 관리** - AI 프롬프트 최적화로 10초 목표 달성 - 트렌드 데이터베이스 실시간 조회 성능 - 응답 캐싱 전략 --- #### 1.1.3 Content Generation 서비스 **기능 요구사항**: - AI 이미지 생성 (Stable Diffusion, 3종) - AI 영상 제작 (15초) - SNS 콘텐츠 자동 생성 (플랫폼별 최적화) - QR 포스터 생성 **비기능 요구사항**: - **응답시간: 5-8분 이내 (병렬 처리 시)** ⚡ - 이미지 생성: 2-3분 (Stable Diffusion 특성) - 영상 제작: 3-5분 (AI 영상 엔진 특성) - GPU 가속 활용 - 확장성: 50개 동시 콘텐츠 생성 **기술적 도전과제**: - **이미지 3종 + 영상 1개 병렬 생성** - 진행 상황 실시간 피드백 - 백그라운드 비동기 처리 필수 - 품질과 속도 균형 유지 --- #### 1.1.4 Distribution 서비스 **기능 요구사항**: - 다중 채널 배포 (우리동네TV, 링고비즈, 지니TV, Instagram, Naver Blog, Kakao Channel) - 네이버 클로바 TTS 연동 (연결음 생성) - 배포 실패 시 자동 재시도 (3회) **비기능 요구사항**: - **응답시간: 1분 이내 (전체 배포 과정)** ⚡ - 채널별 병렬 배포 필수 - 배포 상태 실시간 업데이트 - 확장성: 100개 동시 배포 **기술적 도전과제**: - **6개 외부 API 병렬 호출 및 통합** - API 장애 대응 (Circuit Breaker, Retry) - 네이버 클로바 TTS 품질 보장 - 배포 실패 복구 전략 --- #### 1.1.5 Participation 서비스 **기능 요구사항**: - 이벤트 참여 신청 및 중복 방지 - 추첨형 자동 추첨 (매장 방문 고객 가산점) - 선착순형 쿠폰 소진 시 자동 종료 - 당첨 알림 발송 (SMS/카카오 알림톡) **비기능 요구사항**: - 응답시간: 1초 이내 - 1인 1회 참여 보장 (멱등성) - 공정한 추첨 알고리즘 - 확장성: 10,000 동시 참여 **기술적 도전과제**: - 중복 참여 방지 (전화번호 기준) - 추첨형/선착순형 프로세스 분기 - 대량 SMS/알림톡 발송 - 매장 방문 고객 가산점 처리 --- #### 1.1.6 Analytics 서비스 **기능 요구사항**: - 실시간 대시보드 (참여자 수, 노출 수, 매출 증가율) - 5분 간격 데이터 수집 및 업데이트 - 채널별 성과 분석 (Instagram, Naver Blog, Kakao Channel API) - ROI 자동 계산 - 분석 리포트 PDF 생성 **비기능 요구사항**: - **데이터 수집 주기: 5분 간격** ⏱ - 실시간 데이터 시각화 - 확장성: 100개 이벤트 동시 분석 **기술적 도전과제**: - **다중 데이터 소스 통합 (KT API, POS, SNS API)** - CQRS 패턴으로 읽기/쓰기 분리 - 5분 간격 스케줄러 기반 수집 - 대시보드 실시간 업데이트 --- #### 1.1.7 AI Learning 서비스 **기능 요구사항**: - 이벤트 결과 분석 및 개선안 생성 - 성공 패턴 학습 및 재활용 - 다음 이벤트 아이디어 제안 (시즌별) **비기능 요구사항**: - 빅데이터 분석 시스템 연동 - AI 머신러닝 엔진 API 호출 - 학습 데이터 누적 및 모델 개선 - 확장성: 누적 데이터 기반 지속적 학습 **기술적 도전과제**: - 성공/실패 패턴 자동 학습 - 업종별/지역별 데이터 축적 - 추천 정확도 향상 알고리즘 - Event Sourcing으로 학습 데이터 추적 --- ### 1.2 통합 분석 및 핵심 도전과제 #### 성능 목표 요약 | 서비스 | 목표 응답시간 | 핵심 최적화 전략 | |--------|--------------|------------------| | Event Planning | **10초 이내** | AI API 병렬 호출, 응답 캐싱 | | Content Generation | **5-8분 이내** | 이미지+영상 병렬 생성, 비동기 처리 | | Distribution | **1분 이내** | 6개 채널 병렬 배포 | | Analytics | **5분 주기** | CQRS 읽기/쓰기 분리, 스케줄러 수집 | #### 확장성 요구사항 - **동시 이벤트 처리**: 최소 100개 - **AI API 동시 호출**: 최소 50개 - **배포 API 동시 호출**: 최소 100개 #### 외부 시스템 의존성 - **KT 채널**: 우리동네TV, 링고비즈, 지니TV - **AI API**: Claude, GPT-4, Stable Diffusion - **SNS**: Instagram, Naver Blog, Kakao Channel - **기타**: 네이버 클로바 TTS, 사업자번호 검증, POS 시스템 --- ## 2. 클라우드 아키텍처 패턴 선정 ### 2.1 패턴 평가 매트릭스 #### 핵심 패턴 Top 10 정량 평가 | 패턴 | 기능 적합성
(35%) | 성능 효과
(25%) | 운영 복잡도
(20%) | 확장성
(15%) | 비용 효율성
(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 **선정 이유**: - 단일 진입점으로 7개 마이크로서비스 라우팅 - 인증/인가 중앙 처리 (JWT 토큰 검증) - Rate Limiting으로 100개 동시 이벤트 관리 - 횡단 관심사 분리 (로깅, 모니터링) **적용 서비스**: 전체 서비스 **예상 효과**: - 클라이언트 요청 단순화 (1개 엔드포인트) - 인증 처리 시간 50% 단축 - 서비스 간 결합도 감소 --- #### 🥈 **2. Async Request-Reply** (총점: 8.70) - Phase 1 MVP **선정 이유**: - **Content Generation 서비스의 5-8분 처리 시간 대응** - 이미지/영상 생성 백그라운드 처리 - 진행 상황 실시간 피드백 (WebSocket/폴링) - 클라이언트 블로킹 방지 **적용 서비스**: Content Generation, AI Learning **예상 효과**: - 사용자 대기 시간 체감 80% 감소 - 시스템 응답성 향상 - 동시 콘텐츠 생성 50개 처리 가능 **구현 예시**: ```javascript // 클라이언트: 콘텐츠 생성 요청 const response = await axios.post('/api/content/generate', { eventId: 'evt-001', imageCount: 3 }); const jobId = response.data.jobId; // Job ID 발급 // 상태 폴링 (5초 간격) const checkStatus = setInterval(async () => { const status = await axios.get(`/api/content/status/${jobId}`); if (status.data.completed) { clearInterval(checkStatus); // 콘텐츠 다운로드 } }, 5000); ``` --- #### 🥉 **3. Circuit Breaker** (총점: 8.10) - Phase 1 MVP **선정 이유**: - **6개 외부 API 장애 대응 (KT 채널, AI API, SNS)** - Distribution 서비스의 배포 실패 방지 - API 장애 시 빠른 실패 및 폴백 - 연쇄 장애 전파 차단 **적용 서비스**: Distribution, Event Planning, Content Generation **예상 효과**: - API 장애 시 응답 시간 95% 단축 - 시스템 가용성 99.9% 보장 - 배포 성공률 98% 이상 유지 **구현 예시** (Node.js with opossum): ```javascript const CircuitBreaker = require('opossum'); // 우리동네TV API 호출 const callWooridongneTV = async (data) => { return axios.post('https://api.wooridongne.kt.com/deploy', data); }; const breaker = new CircuitBreaker(callWooridongneTV, { timeout: 15000, // 15초 타임아웃 errorThresholdPercentage: 50, // 50% 실패 시 OPEN resetTimeout: 30000 // 30초 후 재시도 }); breaker.fallback(() => ({ success: false, message: '우리동네TV 배포 실패' })); // 배포 요청 const result = await breaker.fire(deployData); ``` --- #### **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); // 캐시 히트 } // 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; }; ``` --- #### **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
쓰기 전용)] CommandDB --> EventBus[이벤트 버스] EventBus --> ReadDB[(Query DB
읽기 전용)] 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 전체 아키텍처 구조 ```mermaid graph TB subgraph "클라이언트" Web[웹 애플리케이션] Mobile[모바일 앱] end subgraph "API Gateway Layer" Gateway[API Gateway
인증/인가/라우팅/Rate Limiting] end subgraph "마이크로서비스" User[User 서비스
회원/매장 관리] Planning[Event Planning 서비스
AI 이벤트 기획
Cache-Aside] Content[Content Generation 서비스
AI 콘텐츠 생성
Async Request-Reply] Dist[Distribution 서비스
다중 채널 배포
Circuit Breaker + Retry] Participation[Participation 서비스
참여/추첨 관리] Analytics[Analytics 서비스
효과 측정
CQRS] AILearn[AI Learning 서비스
학습/개선
Event Sourcing] end subgraph "데이터 계층" UserDB[(User DB
PostgreSQL)] PlanningDB[(Planning DB
MongoDB)] ContentDB[(Content DB
MongoDB)] DistDB[(Distribution DB
PostgreSQL)] PartDB[(Participation DB
PostgreSQL)] subgraph "CQRS - Analytics" WriteDB[(Command DB
쓰기)] ReadDB[(Query DB
읽기)] end EventStore[(Event Store
AI Learning)] Cache[(Redis Cache
Cache-Aside)] end subgraph "메시지 큐" Queue[RabbitMQ/Kafka
Queue-Based Load Leveling
Pub-Sub] end subgraph "외부 시스템" KTAPI[KT 채널 API
우리동네TV/링고비즈/지니TV] AIAPI[AI API
Claude/GPT-4/Stable Diffusion] SNS[SNS API
Instagram/Naver/Kakao] Clova[네이버 클로바 TTS] POS[POS 시스템] end Web --> Gateway Mobile --> Gateway Gateway --> User Gateway --> Planning Gateway --> Content Gateway --> Dist Gateway --> Participation Gateway --> Analytics Gateway --> AILearn User --> UserDB Planning --> PlanningDB Planning --> Cache Content --> ContentDB Content --> Queue Dist --> DistDB Dist --> Queue Participation --> PartDB Analytics --> WriteDB Analytics --> ReadDB WriteDB --> Queue Queue --> ReadDB AILearn --> EventStore Planning -->|Circuit Breaker| AIAPI Content -->|Circuit Breaker| AIAPI Dist -->|Circuit Breaker + Retry| KTAPI Dist -->|Circuit Breaker + Retry| SNS Dist -->|Circuit Breaker| Clova Analytics --> KTAPI Analytics --> SNS Analytics --> POS Queue -->|Pub-Sub| Analytics Queue -->|Pub-Sub| AILearn ``` --- ### 3.2 Event Planning 서비스 - 10초 응답 최적화 **패턴 적용**: - **Cache-Aside**: 트렌드 데이터 캐싱 - **Circuit Breaker**: Claude + GPT-4 API 장애 대응 - **병렬 처리**: AI API 동시 호출 **아키텍처**: ```mermaid 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 Client->>Gateway: 이벤트 기획 시작 Gateway->>Planning: 기획 요청 Note over Planning,Cache: Phase 1: 트렌드 분석 (3초 목표) Planning->>Cache: 트렌드 데이터 조회 alt 캐시 히트 Cache-->>Planning: 캐시 데이터 반환 else 캐시 미스 Planning->>DB: DB 조회 DB-->>Planning: 트렌드 데이터 Planning->>Cache: 캐시 저장 (TTL: 1시간) end Note over Planning,GPT4: Phase 2: AI 병렬 호출 (7초 목표) par Claude: 이벤트상품 + 참여방법 Planning->>Claude: 이벤트상품 추천 요청
+ 참여방법 설계 요청 Claude-->>Planning: 추천 결과 (5초) and GPT-4: 홍보문구 Planning->>GPT4: 홍보문구 생성 요청 GPT4-->>Planning: 홍보문구 (4초) end Planning->>DB: 기획안 저장 Planning-->>Gateway: 완성된 기획안 (총 10초 이내) Gateway-->>Client: 기획안 제공 ``` **예상 성과**: - **총 응답시간: 10초 이내** (목표 달성) - 트렌드 분석: 3초 → 0.9초 (캐시 히트 시) - AI API 병렬 호출: 9초 → 5초 --- ### 3.3 Content Generation 서비스 - 비동기 처리 **패턴 적용**: - **Async Request-Reply**: 5-8분 장시간 처리 - **Queue-Based Load Leveling**: 동시 50개 콘텐츠 생성 - **Circuit Breaker**: Stable Diffusion API 장애 대응 **아키텍처**: ```mermaid sequenceDiagram participant Client participant Gateway participant Content as Content Generation participant Queue as RabbitMQ participant Worker as Background Worker participant SD as Stable Diffusion participant VideoAI as AI Video Engine participant DB as Content DB Client->>Gateway: 콘텐츠 생성 요청 Gateway->>Content: 생성 요청 Content->>DB: Job 생성 (상태: PENDING) Content->>Queue: 작업 큐잉 Content-->>Gateway: Job ID 발급 Gateway-->>Client: Job ID 반환 Note over Client: 클라이언트는 다른 작업 가능 Queue->>Worker: 작업 할당 par 이미지 3종 생성 (2-3분) Worker->>SD: 이미지 생성 요청 (3건 병렬) SD-->>Worker: 이미지 3종 and 영상 1개 생성 (3-5분) Worker->>VideoAI: 영상 제작 요청 VideoAI-->>Worker: 15초 영상 end Worker->>DB: 콘텐츠 저장 + 상태 업데이트 (COMPLETED) loop 상태 확인 (5초 간격) Client->>Gateway: Job 상태 조회 Gateway->>Content: 상태 조회 Content->>DB: 상태 확인 DB-->>Content: 상태 + 진행률 Content-->>Gateway: 진행 상황 (예: 60% 완료) Gateway-->>Client: 진행률 표시 end Client->>Gateway: 최종 상태 조회 Gateway->>Content: 상태 조회 Content-->>Gateway: COMPLETED + 콘텐츠 URL Gateway-->>Client: 콘텐츠 다운로드 ``` **예상 성과**: - **총 처리시간: 5-8분** (목표 달성) - 사용자 대기 체감 시간: 8분 → 0초 (비동기) - 동시 처리 능력: 50개 콘텐츠 --- ### 3.4 Distribution 서비스 - 안정적 배포 **패턴 적용**: - **Circuit Breaker**: 6개 외부 API 장애 대응 - **Retry**: 배포 실패 자동 재시도 (3회) - **Queue-Based Load Leveling**: 100개 동시 배포 **아키텍처**: ```mermaid sequenceDiagram participant Client participant Gateway participant Dist as Distribution participant Queue as RabbitMQ participant CB1 as Circuit Breaker
(우리동네TV) participant CB2 as Circuit Breaker
(지니TV) participant CB3 as Circuit Breaker
(Instagram) participant KTAPI as KT API participant SNS as SNS API Client->>Gateway: 배포 요청 (6개 채널) Gateway->>Dist: 배포 시작 Dist->>Queue: 배포 작업 큐잉 par 병렬 배포 (1분 목표) Queue->>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 end CB1-->>Dist: 결과 반환 and Queue->>CB2: 지니TV 배포 CB2->>KTAPI: API 호출 KTAPI-->>CB2: 배포 완료 CB2-->>Dist: 결과 반환 and Queue->>CB3: Instagram 배포 CB3->>SNS: API 호출 SNS-->>CB3: 포스팅 완료 CB3-->>Dist: 결과 반환 end Dist-->>Gateway: 배포 결과 (성공 5/6) Gateway-->>Client: 배포 완료 + 실패 채널 안내 ``` **예상 성과**: - **총 배포시간: 1분 이내** (목표 달성) - 배포 성공률: 95% → 98% (Retry) - API 장애 시 응답: 30초 → 3초 (Circuit Breaker) --- ### 3.5 Analytics 서비스 - CQRS 읽기/쓰기 분리 **패턴 적용**: - **CQRS**: 읽기/쓰기 분리 - **Publisher-Subscriber**: 5분 간격 데이터 수집 **아키텍처**: ```mermaid graph TB subgraph "쓰기 모델" Collector[데이터 수집기
5분 스케줄러] WriteAPI[쓰기 API] CommandDB[(Command DB
원본 데이터)] end subgraph "이벤트 버스" EventBus[RabbitMQ
Pub-Sub] end subgraph "읽기 모델" ReadAPI[읽기 API
대시보드] QueryDB[(Query DB
집계 데이터)] 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 계산
채널별 집계| QueryDB ReadAPI --> QueryDB Client[클라이언트
대시보드] -->|실시간 조회| ReadAPI ``` **예상 성과**: - 대시보드 조회 속도: 5초 → 1초 (80% 향상) - ROI 계산 응답: 10초 → 2초 - 동시 조회 처리: 100개 대시보드 --- ## 4. Phase별 구현 로드맵 ### Phase 1: MVP (Minimum Viable Product) - 3개월 **목표**: 핵심 비즈니스 기능 제공 및 빠른 출시 **적용 패턴**: 1. **API Gateway** - 단일 진입점 및 인증/인가 2. **Async Request-Reply** - 콘텐츠 생성 비동기 처리 3. **Circuit Breaker** - 외부 API 장애 대응 4. **Cache-Aside** - 트렌드 데이터 캐싱 5. **Retry** - 배포 실패 자동 재시도 **구현 우선순위**: 1. **Week 1-4**: User 서비스 + API Gateway - 회원가입/로그인 (JWT 인증) - 매장 정보 관리 - 사업자번호 검증 연동 2. **Week 5-8**: Event Planning 서비스 - AI API 연동 (Claude, GPT-4) - Cache-Aside 패턴 적용 (Redis) - Circuit Breaker 적용 3. **Week 9-10**: Content Generation 서비스 - Async Request-Reply 패턴 구현 - Stable Diffusion 연동 - 진행 상황 폴링 API 4. **Week 11-12**: Distribution + Participation 서비스 - 6개 채널 병렬 배포 (Circuit Breaker + Retry) - 추첨/선착순 분기 로직 **성공 지표**: - Event Planning: 10초 이내 응답 ✅ - Content Generation: 8분 이내 완료 ✅ - Distribution: 1분 이내 배포 ✅ - 동시 이벤트 처리: 50개 --- ### 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% | --- ### 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** | --- ### 5.3 개발 생산성 향상 | 지표 | 개선율 | |------|--------| | **서비스 간 결합도 감소** (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 기술적 리스크 | 리스크 | 확률 | 영향도 | 완화 전략 | |--------|------|--------|-----------| | AI API 응답 지연 (>10초) | 중간 | 높음 | Cache-Aside, 프롬프트 최적화, 병렬 호출 | | 외부 API 장애 | 높음 | 높음 | Circuit Breaker, Retry, 폴백 전략 | | Redis 장애 | 낮음 | 중간 | Redis Cluster, DB 폴백 | | 메시지 큐 장애 | 낮음 | 높음 | Dead Letter Queue, 재처리 로직 | ### 7.2 운영 리스크 | 리스크 | 확률 | 영향도 | 완화 전략 | |--------|------|--------|-----------| | 피크 타임 트래픽 폭주 | 높음 | 높음 | Auto Scaling, Queue-Based Load Leveling | | 데이터 불일치 (CQRS) | 중간 | 중간 | 이벤트 재생, 수동 동기화 도구 | | 배포 실패율 증가 | 중간 | 중간 | Retry 3회, 수동 배포 옵션 | --- ## 8. 결론 ### 8.1 핵심 패턴 요약 본 서비스는 **10개의 클라우드 아키텍처 패턴**을 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 예상 효과 - **Event Planning**: 25초 → **10초** (60% 단축) ✅ - **Content Generation**: 12분 → **8분** (33% 단축) ✅ - **Distribution**: 3분 → **1분** (67% 단축) ✅ - **시스템 가용성**: 95% → **99.9%** ✅ - **동시 이벤트 처리**: 20개 → **100개** (5배 향상) ✅ - **연간 비용 절감**: **₩60,000,000** 💰 ### 8.3 다음 단계 1. **Phase 1 MVP 착수** (3개월) - API Gateway + Async Request-Reply + Circuit Breaker 우선 구현 - 핵심 비즈니스 기능 검증 2. **성능 모니터링** - Prometheus + Grafana 대시보드 구축 - 각 패턴별 성과 지표 측정 3. **지속적 개선** - Phase 2, 3 로드맵에 따라 점진적 고도화 - AI 학습 정확도 향상 및 글로벌 확장 --- **문서 승인**: - [ ] System Architect (박영자) - [ ] Backend Developer (최수연) - [ ] DevOps Engineer (송근정) - [ ] PO (갑빠) **참조 문서**: - design/userstory.md - claude/cloud-design-patterns.md - claude/architecture-patterns.md