diff --git a/.claude/settings.local.json b/.claude/settings.local.json index 28d74d5..a0f0877 100644 --- a/.claude/settings.local.json +++ b/.claude/settings.local.json @@ -24,7 +24,8 @@ "Bash(git commit -m \"UI/UX 프로토타입 디렉토리 정리\n\n- 기존 프로토타입 파일 삭제\n- 백업 디렉토리(uiux_bk) 추가\n- 프로젝트 구조 정리\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\nCo-Authored-By: Claude \")", "Bash(curl -s https://raw.githubusercontent.com/cna-bootcamp/clauding-guide/refs/heads/main/guides/design/architecture-patterns.md -o claude/architecture-patterns.md)", "Bash(cp:*)", - "Bash(git commit -m \"$(cat <<''EOF''\n아키텍처 패턴 설계서 업데이트 및 백업\n\n- 클라우드 아키텍처 패턴 적용 방안 재작성\n- 기존 버전을 architecture-pattern_bk.md로 백업\n- .claude/settings.local.json 설정 업데이트\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\nCo-Authored-By: Claude \nEOF\n)\")" + "Bash(git commit -m \"$(cat <<''EOF''\n아키텍처 패턴 설계서 업데이트 및 백업\n\n- 클라우드 아키텍처 패턴 적용 방안 재작성\n- 기존 버전을 architecture-pattern_bk.md로 백업\n- .claude/settings.local.json 설정 업데이트\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\nCo-Authored-By: Claude \nEOF\n)\")", + "Bash(git commit:*)" ], "deny": [], "ask": [] diff --git a/design/pattern/architecture-pattern_bk.md b/design/pattern/architecture-pattern_bk.md deleted file mode 100644 index c34c2ca..0000000 --- a/design/pattern/architecture-pattern_bk.md +++ /dev/null @@ -1,1274 +0,0 @@ -# 클라우드 아키텍처 패턴 적용 방안 - -## 문서 정보 -- **작성일**: 2025-10-21 -- **작성자**: 아키텍트 팀 -- **버전**: 1.0 -- **프로젝트**: 회의록 작성 및 공유 개선 서비스 - ---- - -## 1. 요구사항 분석 결과 - -### 1.1 기능적 요구사항 - -#### 핵심 기능 -1. **실시간 회의록 작성 및 협업** - - 여러 참석자의 동시 수정 및 실시간 동기화 - - 충돌 감지 및 해결 (Last Write Wins) - - 버전 관리 및 변경 이력 추적 - - WebSocket 기반 3-5초 간격 업데이트 - -2. **AI 기반 회의록 자동 생성** - - STT 음성-텍스트 변환 (1초 이내 지연) - - LLM 기반 구조화된 회의록 작성 - - Todo 자동 추출 및 담당자 식별 - - 프롬프팅 기반 다양한 형식 변환 - -3. **맥락 기반 용어 설명 (RAG)** - - 전문용어 자동 감지 및 하이라이트 - - 과거 회의록/사내 문서 기반 실용적 설명 - - 벡터 유사도 검색 및 관련 문서 연결 - -4. **Todo 실시간 연동** - - AI 추출 Todo 자동 할당 - - 회의록과 양방향 실시간 연결 - - Todo 완료 시 회의록 자동 반영 - - 캘린더 자동 등록 및 리마인더 - -#### 서비스 간 연계 -- **Meeting ↔ STT**: 음성 녹음 → 텍스트 변환 -- **STT ↔ AI**: 텍스트 → 회의록 자동 생성 -- **AI ↔ RAG**: 용어 감지 → 맥락 기반 설명 -- **Meeting ↔ Todo**: 회의록 확정 → Todo 추출/할당 -- **Collaboration**: 모든 변경사항 실시간 동기화 - -### 1.2 비기능적 요구사항 - -#### 성능 요구사항 -| 지표 | 목표 | 근거 | -|------|------|------| -| STT 발언 인식 지연 | 1초 이내 | 유저스토리 UFR-STT-010 | -| STT 변환 정확도 | 60% 이상 | 유저스토리 UFR-STT-020 | -| 화자 식별 정확도 | 90% 이상 | 유저스토리 UFR-STT-010 | -| 실시간 동기화 간격 | 3-5초 | 유저스토리 UFR-AI-010 | -| AI 회의록 생성 | 실시간 업데이트 | 유저스토리 UFR-AI-010 | -| RAG 검색 응답시간 | 2초 이내 | 사용자 경험 | -| Todo 할당 알림 | 즉시 발송 | 유저스토리 UFR-TODO-010 | - -#### 가용성 및 신뢰성 -- **회의 중 서비스 중단 불가**: 99.9% uptime 목표 -- **장애 격리**: 한 서비스 장애가 전체 시스템에 영향 최소화 -- **데이터 손실 방지**: 모든 회의록 변경사항 영구 저장 - -#### 확장성 -- **동시 회의 처리**: MVP 100명 → Phase 2: 1,000명 → Phase 3: 10,000명 -- **대용량 데이터**: 장시간 회의 (3시간+) 안정적 처리 -- **글로벌 확장**: 다중 리전 배포 준비 (Phase 3) - -#### 보안 -- **사용자 인증**: LDAP 연동 SSO -- **권한 관리**: 회의록 접근 권한 제어 -- **데이터 보호**: 민감한 회의 내용 암호화 저장 - -#### 데이터 일관성 -- **Todo ↔ 회의록 동기화**: 실시간 양방향 연결 -- **버전 관리**: 모든 수정사항 이력 추적 -- **충돌 해결**: 동시 수정 시 일관성 보장 - -### 1.3 기술적 도전과제 - -#### 1. 실시간 협업 처리 -**문제**: -- 여러 참석자의 동시 수정으로 인한 충돌 -- WebSocket 연결 관리 및 메시지 전송 부하 -- 3-5초 간격 실시간 업데이트 요구 - -**영향**: -- 사용자 경험 저하 (수정 내용 손실, 충돌) -- 서버 부하 증가 (다수 WebSocket 연결) - -#### 2. 대용량 데이터 처리 -**문제**: -- 음성 녹음 파일 (장시간 회의 시 GB 단위) -- STT 변환 처리 시간 증가 -- 장시간 회의록 (수만 자 텍스트) - -**영향**: -- 응답 시간 지연 -- 저장소 비용 증가 - -#### 3. AI/LLM 통합 복잡성 -**문제**: -- LLM API 호출 시간 (수 초 ~ 수십 초) -- API 비용 (토큰 기반 과금) -- API 장애 시 서비스 중단 - -**영향**: -- 사용자 대기 시간 증가 -- 운영 비용 상승 -- 가용성 저하 - -#### 4. RAG 시스템 성능 -**문제**: -- 벡터 DB 검색 성능 (대량 회의록 축적 시) -- 관련 문서 추출 정확도 -- 맥락 기반 설명 생성 시간 - -**영향**: -- 용어 설명 응답 지연 -- 검색 정확도 저하 - -#### 5. 서비스 간 의존성 관리 -**문제**: -- Meeting → STT → AI 순차 의존성 -- Todo ↔ Meeting 양방향 의존성 -- 한 서비스 장애 시 전체 기능 마비 - -**영향**: -- 장애 전파 -- 가용성 저하 - -#### 6. 데이터 일관성 보장 -**문제**: -- Todo 완료 → 회의록 반영 시 동기화 -- 실시간 수정 충돌 해결 -- 분산 트랜잭션 관리 - -**영향**: -- 데이터 불일치 -- 사용자 혼란 - ---- - -## 2. 패턴 선정 및 평가 - -### 2.1 평가 기준 - -| 기준 | 가중치 | 평가 내용 | -|------|--------|-----------| -| **기능 적합성** | 35% | 요구사항을 직접 해결하는 능력 | -| **성능 효과** | 25% | 응답시간 및 처리량 개선 효과 | -| **운영 복잡도** | 20% | 구현 및 운영의 용이성 (낮을수록 좋음) | -| **확장성** | 15% | 미래 요구사항에 대한 대응력 | -| **비용 효율성** | 5% | 개발/운영 비용 대비 효과 (ROI) | - -**평가 척도**: 1-10점 (10점이 가장 우수) - -### 2.2 패턴 평가 매트릭스 - -| 패턴 | 기능 적합성
(35%) | 성능 효과
(25%) | 운영 복잡도
(20%) | 확장성
(15%) | 비용 효율성
(5%) | **총점** | Phase | -|------|:---:|:---:|:---:|:---:|:---:|:---:|:---:| -| **API Gateway** | 9 × 0.35 = 3.15 | 8 × 0.25 = 2.0 | 8 × 0.20 = 1.6 | 9 × 0.15 = 1.35 | 8 × 0.05 = 0.4 | **8.50** | MVP | -| **Queue-Based Load Leveling** | 9 × 0.35 = 3.15 | 9 × 0.25 = 2.25 | 7 × 0.20 = 1.4 | 8 × 0.15 = 1.2 | 7 × 0.05 = 0.35 | **8.35** | MVP | -| **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** | MVP | -| **Publisher-Subscriber** | 9 × 0.35 = 3.15 | 7 × 0.25 = 1.75 | 8 × 0.20 = 1.6 | 9 × 0.15 = 1.35 | 8 × 0.05 = 0.4 | **8.25** | MVP | -| **Asynchronous Request-Reply** | 9 × 0.35 = 3.15 | 8 × 0.25 = 2.0 | 7 × 0.20 = 1.4 | 8 × 0.15 = 1.2 | 7 × 0.05 = 0.35 | **8.10** | MVP | -| **Gateway Offloading** | 8 × 0.35 = 2.8 | 6 × 0.25 = 1.5 | 9 × 0.20 = 1.8 | 7 × 0.15 = 1.05 | 8 × 0.05 = 0.4 | **7.55** | MVP | -| **Federated Identity** | 8 × 0.35 = 2.8 | 5 × 0.25 = 1.25 | 9 × 0.20 = 1.8 | 6 × 0.15 = 0.9 | 8 × 0.05 = 0.4 | **7.15** | MVP | -| **Circuit Breaker** | 8 × 0.35 = 2.8 | 6 × 0.25 = 1.5 | 8 × 0.20 = 1.6 | 7 × 0.15 = 1.05 | 8 × 0.05 = 0.4 | **7.35** | Phase 2 | -| **CQRS** | 7 × 0.35 = 2.45 | 8 × 0.25 = 2.0 | 5 × 0.20 = 1.0 | 8 × 0.15 = 1.2 | 6 × 0.05 = 0.3 | **6.95** | Phase 2 | -| **Retry** | 7 × 0.35 = 2.45 | 6 × 0.25 = 1.5 | 8 × 0.20 = 1.6 | 6 × 0.15 = 0.9 | 8 × 0.05 = 0.4 | **6.85** | Phase 2 | -| **Materialized View** | 6 × 0.35 = 2.1 | 8 × 0.25 = 2.0 | 6 × 0.20 = 1.2 | 7 × 0.15 = 1.05 | 7 × 0.05 = 0.35 | **6.70** | Phase 2 | -| **Event Sourcing** | 7 × 0.35 = 2.45 | 7 × 0.25 = 1.75 | 4 × 0.20 = 0.8 | 9 × 0.15 = 1.35 | 5 × 0.05 = 0.25 | **6.60** | Phase 3 | -| **Saga** | 7 × 0.35 = 2.45 | 6 × 0.25 = 1.5 | 4 × 0.20 = 0.8 | 8 × 0.15 = 1.2 | 5 × 0.05 = 0.25 | **6.20** | Phase 3 | -| **Bulkhead** | 6 × 0.35 = 2.1 | 6 × 0.25 = 1.5 | 7 × 0.20 = 1.4 | 6 × 0.15 = 0.9 | 7 × 0.05 = 0.35 | **6.25** | Phase 2 | -| **Valet Key** | 5 × 0.35 = 1.75 | 7 × 0.25 = 1.75 | 8 × 0.20 = 1.6 | 5 × 0.15 = 0.75 | 8 × 0.05 = 0.4 | **6.25** | Phase 2 | -| **Priority Queue** | 5 × 0.35 = 1.75 | 6 × 0.25 = 1.5 | 7 × 0.20 = 1.4 | 6 × 0.15 = 0.9 | 6 × 0.05 = 0.3 | **5.85** | Phase 3 | -| **Health Endpoint Monitoring** | 7 × 0.35 = 2.45 | 4 × 0.25 = 1.0 | 9 × 0.20 = 1.8 | 5 × 0.15 = 0.75 | 8 × 0.05 = 0.4 | **6.40** | MVP | -| **External Configuration Store** | 6 × 0.35 = 2.1 | 4 × 0.25 = 1.0 | 8 × 0.20 = 1.6 | 6 × 0.15 = 0.9 | 8 × 0.05 = 0.4 | **6.00** | Phase 3 | - -### 2.3 선정 패턴 및 근거 - -#### MVP Phase (총 8개 패턴) -1. **API Gateway (8.50점)** ⭐ 최고점 - - 단일 진입점으로 모든 클라이언트 요청 처리 - - 서비스 라우팅 중앙화 - - 높은 기능 적합성과 확장성 - -2. **Queue-Based Load Leveling (8.35점)** - - STT/AI 비동기 처리 필수 - - 부하 분산으로 성능 안정화 - - AI API 호출 최적화 - -3. **Cache-Aside (8.35점)** - - RAG 검색 결과 캐싱으로 성능 향상 - - 구현 용이, 높은 비용 효율성 - - 60% 검색 비용 절감 예상 - -4. **Publisher-Subscriber (8.25점)** - - Todo 상태 변경 이벤트 - - 회의록 공유 알림 - - 실시간 알림 발송 - -5. **Asynchronous Request-Reply (8.10점)** - - AI 회의록 생성 비동기 처리 - - 사용자 대기 시간 단축 - - 장시간 작업 효율적 처리 - -6. **Gateway Offloading (7.55점)** - - 인증(LDAP), 로깅, SSL 처리 - - 서비스 복잡도 감소 - - 핵심 비즈니스 로직에 집중 - -7. **Federated Identity (7.15점)** - - LDAP SSO 연동 - - 사용자 관리 효율화 - - 보안 강화 - -8. **Health Endpoint Monitoring (6.40점)** - - 서비스 상태 점검 - - 장애 조기 발견 - - 운영 안정성 - -#### Phase 2 - 확장 (총 6개 패턴 추가) -9. **Circuit Breaker (7.35점)** - - AI/STT API 장애 격리 - - 장애 복구 시간 90% 단축 - - 가용성 99.9% 달성 - -10. **CQRS (6.95점)** - - 회의록 읽기/쓰기 분리 - - 읽기 성능 70% 향상 - - 확장성 개선 - -11. **Retry (6.85점)** - - 일시적 오류 자동 복구 - - Circuit Breaker와 통합 - - 안정성 향상 - -12. **Materialized View (6.70점)** - - 회의록 목록, 요약 뷰 - - 조회 성능 80% 향상 - - 사용자 경험 개선 - -13. **Bulkhead (6.25점)** - - 서비스 격리로 장애 전파 방지 - - 리소스 풀 분리 - - 안정성 강화 - -14. **Valet Key (6.25점)** - - 음성 파일 직접 다운로드 - - 네트워크 대역폭 절감 - - Azure Storage SAS 토큰 활용 - -#### Phase 3 - 고도화 (총 4개 패턴 추가) -15. **Event Sourcing (6.60점)** - - 완벽한 변경 이력 추적 - - 감사 추적 (Audit Trail) - - 데이터 복원 가능 - -16. **Saga (6.20점)** - - Todo 할당 분산 트랜잭션 - - 데이터 일관성 보장 - - 보상 트랜잭션 - -17. **Priority Queue (5.85점)** - - VIP 회의 우선 처리 - - 중요 회의 응답시간 50% 단축 - - 비즈니스 가치 향상 - -18. **External Configuration Store (6.00점)** - - 동적 설정 관리 - - 재배포 없이 설정 변경 - - 운영 효율성 - ---- - -## 3. 서비스별 패턴 적용 설계 - -### 3.1 서비스별 패턴 매핑 - -#### API Gateway Layer -- **API Gateway**: 모든 요청 진입점, 라우팅 -- **Gateway Offloading**: LDAP 인증, 로깅, SSL 종료 -- **Rate Limiting**: 사용자당 100 req/min - -#### User Service -- **Federated Identity**: LDAP SSO 연동 -- **Cache-Aside**: 사용자 정보 캐싱 (TTL 30분) -- **Health Endpoint**: /actuator/health - -#### Meeting Service -- **CQRS**: 읽기(조회)/쓰기(작성) 모델 분리 -- **Materialized View**: 회의록 목록, 대시보드 요약 -- **Event Sourcing**: 회의록 변경 이력 (Phase 3) -- **Publisher-Subscriber**: 회의록 공유 이벤트 -- **Cache-Aside**: 회의록 목록 (TTL 5분) - -#### STT Service -- **Queue-Based Load Leveling**: 음성 변환 큐 처리 -- **Asynchronous Request-Reply**: 변환 결과 비동기 반환 -- **Valet Key**: Azure Blob Storage 음성 파일 직접 업로드 -- **Circuit Breaker**: Azure Speech API 장애 격리 -- **Retry**: STT API 일시적 오류 (최대 3회) -- **Priority Queue**: 중요 회의 우선 처리 (Phase 3) - -#### AI Service -- **Queue-Based Load Leveling**: LLM 요청 큐 (배치 처리) -- **Asynchronous Request-Reply**: AI 생성 비동기 응답 -- **Circuit Breaker**: OpenAI/Azure OpenAI API 장애 격리 -- **Retry**: LLM API 오류 재시도 (Exponential Backoff) -- **Priority Queue**: VIP 회의 우선 처리 (Phase 3) -- **Cache-Aside**: 프롬프트 템플릿 캐싱 - -#### RAG Service -- **Cache-Aside**: 벡터 검색 결과 캐싱 (TTL 1시간) -- **Materialized View**: 용어 사전 인덱스 -- **Circuit Breaker**: 벡터 DB 장애 격리 -- **Retry**: 검색 실패 재시도 - -#### Collaboration Service -- **Publisher-Subscriber**: 실시간 동기화 이벤트 (WebSocket) -- **Event Sourcing**: 수정 이력 관리 (Phase 3) -- **Bulkhead**: WebSocket 연결 풀 격리 - -#### Todo Service -- **Saga**: Todo 할당 → 알림 → 캘린더 등록 (Phase 3) -- **Publisher-Subscriber**: Todo 상태 변경 이벤트 -- **Cache-Aside**: Todo 목록 캐싱 (TTL 5분) -- **Asynchronous Request-Reply**: 캘린더 등록 비동기 - -#### Notification Service -- **Queue-Based Load Leveling**: 알림 발송 큐 -- **Competing Consumers**: 병렬 알림 처리 (이메일/푸시) -- **Retry**: 알림 발송 실패 재시도 - -#### 공통 적용 -- **Health Endpoint Monitoring**: 모든 서비스 -- **External Configuration Store**: 환경 설정 중앙 관리 (Phase 3) -- **Bulkhead**: 서비스별 리소스 풀 격리 - -### 3.2 전체 시스템 아키텍처 - -```mermaid -graph TB - subgraph "Client Layer" - Web[Web Client] - Mobile[Mobile App] - end - - subgraph "API Gateway Layer" - Gateway[API Gateway
+ Gateway Offloading
+ Rate Limiting] - end - - subgraph "Authentication" - LDAP[LDAP Server
Federated Identity] - end - - subgraph "Microservices" - User[User Service
Cache-Aside] - Meeting[Meeting Service
CQRS + Event Sourcing] - STT[STT Service
Queue + Async] - AI[AI Service
Queue + Circuit Breaker] - RAG[RAG Service
Cache-Aside] - Collab[Collaboration Service
Pub-Sub + WebSocket] - Todo[Todo Service
Saga + Pub-Sub] - Notif[Notification Service
Queue + Competing Consumers] - end - - subgraph "Data Layer" - Cache[(Redis Cache
Cache-Aside)] - UserDB[(User DB)] - MeetingDB[(Meeting DB)] - STTDB[(STT DB)] - AIDB[(AI DB)] - RAGDB[(Vector DB)] - TodoDB[(Todo DB)] - end - - subgraph "Messaging Layer" - Queue[Message Queue
RabbitMQ/Kafka
Queue-Based Load Leveling] - EventBus[Event Bus
Publisher-Subscriber] - end - - subgraph "External Services" - AzureSpeech[Azure Speech API
Circuit Breaker] - OpenAI[OpenAI API
Circuit Breaker] - AzureBlob[Azure Blob Storage
Valet Key] - Email[Email Service] - end - - Web --> Gateway - Mobile --> Gateway - - Gateway --> LDAP - Gateway --> User - Gateway --> Meeting - Gateway --> STT - Gateway --> AI - Gateway --> RAG - Gateway --> Collab - Gateway --> Todo - - User --> Cache - User --> UserDB - - Meeting --> Cache - Meeting --> MeetingDB - Meeting --> EventBus - - STT --> Queue - STT --> AzureSpeech - STT --> AzureBlob - STT --> STTDB - - AI --> Queue - AI --> OpenAI - AI --> Cache - AI --> AIDB - - RAG --> Cache - RAG --> RAGDB - - Collab --> EventBus - - Todo --> EventBus - Todo --> TodoDB - - Notif --> Queue - Notif --> Email - - Queue --> STT - Queue --> AI - Queue --> Notif - - EventBus --> Meeting - EventBus --> Collab - EventBus --> Todo - EventBus --> Notif -``` - -### 3.3 실시간 협업 플로우 - -```mermaid -sequenceDiagram - participant Client1 as 참석자1 - participant Client2 as 참석자2 - participant Gateway as API Gateway - participant Collab as Collaboration Service - participant EventBus as Event Bus
(Pub-Sub) - participant Meeting as Meeting Service - participant Cache as Redis Cache - - Note over Client1,Client2: WebSocket 연결 - Client1->>Gateway: WebSocket Connect - Gateway->>Collab: Establish Connection - Client2->>Gateway: WebSocket Connect - Gateway->>Collab: Establish Connection - - Note over Client1,EventBus: 회의록 수정 - Client1->>Collab: 회의록 수정 (Delta) - Collab->>Meeting: 수정 내용 저장 - Meeting->>Cache: 캐시 무효화 - Meeting->>EventBus: 수정 이벤트 발행
(Publisher) - - Note over EventBus,Client2: 실시간 동기화 - EventBus->>Collab: 수정 이벤트 전달
(Subscriber) - Collab->>Client2: WebSocket Push (Delta) - Client2->>Client2: 화면 실시간 업데이트 - - Note over Client1,Meeting: 충돌 처리 (Last Write Wins) - Client1->>Collab: 동시 수정 시도 - Client2->>Collab: 동시 수정 시도 - Collab->>Meeting: 충돌 감지 - Meeting->>Meeting: Last Write Wins 적용 - Meeting->>EventBus: 최종 수정 이벤트 - EventBus->>Collab: 동기화 - Collab->>Client1: 최종 버전 전송 - Collab->>Client2: 최종 버전 전송 -``` - -### 3.4 AI/STT 비동기 처리 플로우 - -```mermaid -sequenceDiagram - participant Client as Web Client - participant Gateway as API Gateway - participant Meeting as Meeting Service - participant STTQueue as STT Queue
(Queue-Based) - participant STT as STT Service
(Circuit Breaker) - participant AzureSpeech as Azure Speech API - participant AIQueue as AI Queue
(Queue-Based) - participant AI as AI Service
(Circuit Breaker) - participant OpenAI as OpenAI API - participant RAG as RAG Service
(Cache-Aside) - participant Cache as Redis Cache - - Note over Client,Meeting: 음성 녹음 시작 - Client->>Gateway: 음성 녹음 업로드 - Gateway->>Meeting: 녹음 데이터 전달 - Meeting->>STTQueue: 변환 요청 적재
(Async Request-Reply) - Meeting-->>Client: 202 Accepted (즉시 응답) - - Note over STTQueue,AzureSpeech: STT 비동기 처리 - STTQueue->>STT: 큐에서 메시지 가져오기 - STT->>AzureSpeech: 음성-텍스트 변환 요청 - - alt API 정상 - AzureSpeech-->>STT: 변환 결과 - STT->>AIQueue: AI 회의록 작성 요청 - else API 장애 - AzureSpeech--xSTT: 오류 - STT->>STT: Circuit Breaker OPEN - STT->>STT: Retry (최대 3회) - alt Retry 성공 - STT->>AIQueue: AI 요청 - else Retry 실패 - STT->>Meeting: 실패 알림 - Meeting->>Client: WebSocket Push (오류) - end - end - - Note over AIQueue,OpenAI: AI 비동기 처리 - AIQueue->>AI: 큐에서 메시지 가져오기 - AI->>Cache: 프롬프트 템플릿 조회 - Cache-->>AI: 캐시된 템플릿 - AI->>OpenAI: 회의록 생성 요청 - - alt API 정상 - OpenAI-->>AI: 회의록 초안 - AI->>RAG: 용어 설명 요청 - RAG->>Cache: 검색 결과 조회 - - alt 캐시 적중 - Cache-->>RAG: 캐시된 설명 - else 캐시 미스 - RAG->>RAG: 벡터 검색 수행 - RAG->>Cache: 결과 캐싱 (TTL 1시간) - end - - RAG-->>AI: 용어 설명 - AI->>Meeting: 최종 회의록 전달 - Meeting->>Client: WebSocket Push (결과) - else API 장애 - OpenAI--xAI: 오류 - AI->>AI: Circuit Breaker OPEN - AI->>AI: Retry (Exponential Backoff) - end -``` - -### 3.5 Todo 실시간 연동 플로우 (Saga 패턴) - -```mermaid -sequenceDiagram - participant Client as Web Client - participant Gateway as API Gateway - participant Meeting as Meeting Service - participant AI as AI Service - participant Todo as Todo Service
(Saga Orchestrator) - participant EventBus as Event Bus
(Pub-Sub) - participant Notif as Notification Service - participant Calendar as Calendar API - - Note over Client,AI: 회의록 확정 및 Todo 추출 - Client->>Gateway: 회의록 최종 확정 - Gateway->>Meeting: 확정 요청 - Meeting->>AI: Todo 자동 추출 요청 - AI->>AI: LLM 분석
(액션 아이템 추출) - AI-->>Meeting: 추출된 Todo 목록 - - Note over Meeting,Todo: Saga 시작 (Phase 3) - Meeting->>Todo: Todo 할당 요청 (Saga Start) - - Note over Todo,Calendar: Saga Step 1: Todo 등록 - Todo->>Todo: Todo 데이터 저장 - Todo->>EventBus: TodoCreated 이벤트
(Publisher) - - Note over Todo,Calendar: Saga Step 2: 알림 발송 - EventBus->>Notif: TodoCreated 수신
(Subscriber) - Notif->>Notif: 이메일 발송 - - alt 알림 성공 - Notif->>EventBus: NotificationSent 이벤트 - else 알림 실패 - Notif->>EventBus: NotificationFailed 이벤트 - EventBus->>Todo: 보상 트랜잭션
(Todo 상태 변경: 알림 실패) - end - - Note over Todo,Calendar: Saga Step 3: 캘린더 등록 - EventBus->>Todo: NotificationSent 수신 - Todo->>Calendar: 일정 등록 요청 (비동기) - - alt 캘린더 등록 성공 - Calendar-->>Todo: 성공 - Todo->>EventBus: TodoCompleted 이벤트
(Saga 완료) - else 캘린더 등록 실패 - Calendar--xTodo: 실패 - Todo->>Todo: 보상 트랜잭션
(Todo 상태: 캘린더 미등록) - Todo->>EventBus: SagaCompensated 이벤트 - end - - Note over EventBus,Meeting: 회의록 실시간 반영 - EventBus->>Meeting: Todo 이벤트 수신 - Meeting->>Meeting: 회의록에 Todo 링크 추가 - Meeting->>EventBus: MeetingUpdated 이벤트 - EventBus->>Client: WebSocket Push (Todo 상태) - Client->>Client: 화면 업데이트 - - Note over Client,Meeting: Todo 완료 처리 - Client->>Todo: Todo 완료 요청 - Todo->>Todo: 완료 시간 기록 - Todo->>EventBus: TodoCompleted 이벤트 - EventBus->>Meeting: Todo 완료 수신 - Meeting->>Meeting: 회의록에 완료 표시 - Meeting->>EventBus: MeetingUpdated 이벤트 - EventBus->>Client: WebSocket Push (완료 상태) -``` - ---- - -## 4. Phase별 구현 로드맵 - -### 4.1 Phase 1: MVP (3개월) - -#### 목표 -- 핵심 기능 구현 (회의록 작성, STT, AI, Todo) -- 안정적 서비스 출시 -- 100명 동시 사용자 지원 - -#### 적용 패턴 (8개) -1. API Gateway -2. Gateway Offloading -3. Queue-Based Load Leveling -4. Cache-Aside -5. Publisher-Subscriber -6. Asynchronous Request-Reply -7. Federated Identity -8. Health Endpoint Monitoring - -#### 마일스톤 -| 주차 | 작업 내용 | 산출물 | -|------|-----------|--------| -| 1-2주 | 인프라 구축 | API Gateway, Redis, RabbitMQ 설정 | -| 3-4주 | User/Meeting 서비스 개발 | 인증, 회의 관리 API | -| 5-6주 | STT 서비스 개발 | 음성 녹음, 변환 API | -| 7-8주 | AI 서비스 개발 | 회의록 자동 생성, Todo 추출 | -| 9-10주 | RAG/Collaboration 서비스 | 용어 설명, 실시간 동기화 | -| 11-12주 | 통합 테스트 및 배포 | 프로덕션 배포, 모니터링 | - -#### 예상 성과 -- **성능**: - - STT 변환: 1초 이내 ✓ - - AI 회의록 생성: 10초 이내 - - RAG 검색: 2초 (캐시 적중 0.1초) - - 실시간 동기화: 3-5초 간격 -- **가용성**: 99% uptime -- **동시 사용자**: 100명 -- **비용**: 월 $500 (Azure 인프라) - -### 4.2 Phase 2: 확장 (6개월, MVP 이후) - -#### 목표 -- 성능 최적화 (CQRS, Materialized View) -- 안정성 강화 (Circuit Breaker, Retry, Bulkhead) -- 1,000명 동시 사용자 지원 - -#### 추가 패턴 (6개) -9. CQRS -10. Circuit Breaker -11. Retry -12. Materialized View -13. Bulkhead -14. Valet Key - -#### 마일스톤 -| 월 | 작업 내용 | 성과 지표 | -|----|-----------|-----------| -| 1-2개월 | CQRS 적용 (Meeting 서비스) | 읽기 성능 70% 향상 | -| 3-4개월 | Circuit Breaker/Retry 적용 | 장애 복구 시간 90% 단축 | -| 5개월 | Materialized View 구현 | 목록 조회 80% 빠름 | -| 6개월 | 부하 테스트 및 최적화 | 1,000명 동시 사용자 | - -#### 예상 성과 -- **성능 개선**: - - 읽기 응답시간: 70% 단축 (CQRS) - - 목록 조회: 80% 빠름 (Materialized View) - - RAG 캐시 적중률: 80% -- **가용성**: 99.9% uptime (Circuit Breaker) -- **동시 사용자**: 1,000명 (10배 증가) -- **비용**: 월 $2,000 (Auto-scaling) - -### 4.3 Phase 3: 고도화 (12개월, Phase 2 이후) - -#### 목표 -- 대규모 확장 (10,000명 동시 사용자) -- 완벽한 감사 추적 (Event Sourcing) -- 글로벌 배포 (다중 리전) - -#### 추가 패턴 (4개) -15. Event Sourcing -16. Saga -17. Priority Queue -18. External Configuration Store - -#### 마일스톤 -| 분기 | 작업 내용 | 성과 지표 | -|------|-----------|-----------| -| Q1 | Event Sourcing 구현 | 완벽한 변경 이력 | -| Q2 | Saga 패턴 적용 (Todo) | 분산 트랜잭션 일관성 | -| Q3 | Priority Queue 도입 | VIP 회의 50% 빠름 | -| Q4 | 다중 리전 배포 | 글로벌 확장 | - -#### 예상 성과 -- **성능**: - - Priority Queue: VIP 회의 응답시간 50% 단축 - - Event Sourcing: 완벽한 감사 추적 -- **가용성**: 99.99% uptime (다중 리전) -- **동시 사용자**: 10,000명 -- **글로벌**: 3개 리전 (한국, 미국, 유럽) -- **비용**: 월 $10,000 (글로벌 인프라) - -### 4.4 비용 효율성 분석 - -| Phase | 인프라 비용 | 예상 절감 | ROI | -|-------|------------|----------|-----| -| MVP | $500/월 | - | - | -| Phase 2 | $2,000/월 | Cache-Aside: RAG 비용 60% 절감
Async: AI API 30% 절감
Auto-scaling: 유휴 자원 80% 절감 | **총 50% 절감** | -| Phase 3 | $10,000/월 | 글로벌 확장으로 사용자 10배 증가
비용은 5배만 증가 (효율성 2배) | **비용 대비 2배 효율** | - ---- - -## 5. 구현 시 고려사항 - -### 5.1 API Gateway 구현 - -**기술 스택**: Spring Cloud Gateway - -**설정**: -```yaml -spring: - cloud: - gateway: - routes: - - id: user-service - uri: lb://user-service - predicates: - - Path=/api/users/** - filters: - - name: RequestRateLimiter - args: - redis-rate-limiter.replenishRate: 100 - redis-rate-limiter.burstCapacity: 200 - - id: meeting-service - uri: lb://meeting-service - predicates: - - Path=/api/meetings/** -``` - -**Gateway Offloading**: -- LDAP 인증: Spring Security LDAP -- 로깅: Spring Cloud Sleuth + Zipkin -- SSL 종료: Let's Encrypt 인증서 - -**Rate Limiting**: -- 사용자당: 100 req/min -- 익명 사용자: 10 req/min -- VIP: 500 req/min - -### 5.2 Queue 설정 - -**기술 스택**: RabbitMQ (MVP), Kafka (Phase 2) - -**Queue 구성**: -```yaml -queues: - stt: - name: stt-conversion-queue - type: priority # Priority Queue (Phase 3) - durable: true - ttl: 1800000 # 30분 - dead-letter-exchange: stt-dlx - - ai: - name: ai-generation-queue - type: priority - durable: true - ttl: 1800000 - dead-letter-exchange: ai-dlx - - notification: - name: notification-queue - durable: true - ttl: 300000 # 5분 -``` - -**Dead Letter Queue**: -- 실패한 메시지 3회 재시도 후 DLQ로 이동 -- DLQ 메시지 수동 확인 및 재처리 - -**메시지 우선순위** (Phase 3): -- VIP 회의: Priority 9 -- 일반 회의: Priority 5 -- 배치 작업: Priority 1 - -### 5.3 Cache 전략 - -**기술 스택**: Redis Cluster (고가용성) - -**TTL 설정**: -```yaml -cache: - rag-search: - ttl: 3600 # 1시간 - max-size: 10000 - - user-info: - ttl: 1800 # 30분 - max-size: 5000 - - meeting-list: - ttl: 300 # 5분 - max-size: 1000 - - todo-list: - ttl: 300 # 5분 - max-size: 2000 -``` - -**캐시 무효화**: -- 쓰기 작업 시 즉시 무효화 -- 회의록 수정 → 해당 회의 캐시 삭제 -- Todo 상태 변경 → Todo 목록 캐시 삭제 - -**캐시 워밍**: -- 애플리케이션 시작 시 인기 회의록 사전 로드 -- 스케줄러: 매일 오전 6시 캐시 갱신 - -### 5.4 WebSocket 최적화 - -**기술 스택**: SockJS + STOMP - -**설정**: -```yaml -websocket: - heartbeat: - client: 30000 # 30초 - server: 30000 - - message-size-limit: 1048576 # 1MB - - connection: - max-per-user: 5 - timeout: 300000 # 5분 -``` - -**재연결 정책**: -- Exponential Backoff: 1초, 2초, 4초, 8초, 16초 -- 최대 재시도: 5회 - -**메시지 전송 최적화**: -- Delta 전송: 전체 내용이 아닌 변경 부분만 -- 압축: gzip 압축 (1KB 이상 메시지) -- 배치: 100ms 내 변경사항 묶어서 전송 - -### 5.5 AI/LLM 최적화 - -**기술 스택**: Azure OpenAI Service - -**배치 처리**: -```python -# 여러 요청 묶어서 처리 -batch_requests = [] -for i in range(batch_size): - request = queue.pop() - batch_requests.append(request) - -# 한 번에 처리 -responses = openai.ChatCompletion.create_batch(batch_requests) -``` - -**스트리밍 응답**: -- 긴 회의록 생성 시 스트리밍 -- 클라이언트에 실시간 전달 (WebSocket) - -**프롬프트 캐싱**: -- 동일 템플릿 재사용 -- Redis에 프롬프트 템플릿 저장 - -**비용 최적화**: -- 토큰 제한: 요약 시 최대 500 토큰 -- 모델 선택: GPT-3.5 (일반), GPT-4 (중요 회의) - -### 5.6 Circuit Breaker 설정 - -**기술 스택**: Resilience4j - -**설정**: -```yaml -resilience4j: - circuitbreaker: - instances: - azure-speech: - failure-rate-threshold: 50 # 50% 실패 시 OPEN - wait-duration-in-open-state: 30s - sliding-window-size: 10 - minimum-number-of-calls: 5 - - openai: - failure-rate-threshold: 50 - wait-duration-in-open-state: 60s # 1분 - sliding-window-size: 20 - - retry: - instances: - azure-speech: - max-attempts: 3 - wait-duration: 1s - retry-exceptions: - - java.net.SocketTimeoutException - - org.springframework.web.client.HttpServerErrorException -``` - -**Fallback 전략**: -- STT 실패 → 수동 입력 안내 -- AI 실패 → 기본 템플릿 제공 -- RAG 실패 → 일반 용어 설명 - -### 5.7 CQRS 구현 (Phase 2) - -**Read Model** (조회): -```java -@Service -public class MeetingQueryService { - @Cacheable("meeting-list") - public List getMeetingList(Long userId) { - // Materialized View 조회 - return materializedViewRepository.findByUserId(userId); - } -} -``` - -**Write Model** (쓰기): -```java -@Service -public class MeetingCommandService { - @CacheEvict(value = "meeting-list", key = "#userId") - public void updateMeeting(Long meetingId, MeetingUpdateRequest request) { - // DB 갱신 - meetingRepository.update(meetingId, request); - - // 이벤트 발행 - eventBus.publish(new MeetingUpdatedEvent(meetingId)); - } -} -``` - -**Materialized View 갱신**: -- 이벤트 기반 비동기 갱신 -- 배치 작업: 매 10분마다 동기화 - -### 5.8 Event Sourcing 구현 (Phase 3) - -**Event Store**: -```java -@Entity -public class MeetingEvent { - @Id - private UUID eventId; - private Long aggregateId; // Meeting ID - private String eventType; // CREATED, UPDATED, SHARED - private String eventData; // JSON - private LocalDateTime timestamp; - private Long userId; -} -``` - -**이벤트 재생**: -```java -public Meeting rebuildFromEvents(Long meetingId) { - List events = eventStore.findByAggregateId(meetingId); - Meeting meeting = new Meeting(); - for (MeetingEvent event : events) { - meeting.apply(event); - } - return meeting; -} -``` - -**스냅샷** (성능 최적화): -- 100개 이벤트마다 스냅샷 생성 -- 재생 시 최신 스냅샷부터 시작 - -### 5.9 모니터링 및 운영 - -**Health Endpoint**: -```yaml -management: - endpoints: - web: - exposure: - include: health, metrics, prometheus - health: - circuitbreakers: - enabled: true - redis: - enabled: true - db: - enabled: true -``` - -**Metrics** (Prometheus + Grafana): -- 서비스 응답시간 (p50, p95, p99) -- 요청 처리량 (req/s) -- 에러율 (%) -- Circuit Breaker 상태 -- 캐시 적중률 - -**분산 추적** (Zipkin): -- 요청 전체 흐름 추적 -- 병목 구간 식별 - -**로그 중앙화** (ELK Stack): -- Elasticsearch: 로그 저장 -- Logstash: 로그 수집 및 파싱 -- Kibana: 로그 검색 및 시각화 - -**알림** (Phase 2): -- 에러율 5% 초과 → Slack 알림 -- Circuit Breaker OPEN → 즉시 알림 -- 디스크 사용량 80% → 경고 - -### 5.10 보안 - -**HTTPS 강제**: -- Let's Encrypt 무료 인증서 -- HTTP → HTTPS 자동 리다이렉트 - -**CORS 설정**: -```yaml -spring: - web: - cors: - allowed-origins: - - https://meeting.example.com - allowed-methods: GET, POST, PUT, DELETE - allowed-headers: "*" - allow-credentials: true -``` - -**SQL Injection 방지**: -- JPA/Hibernate PreparedStatement 사용 -- 동적 쿼리 금지 - -**XSS 방지**: -- Input Sanitization (OWASP Java Encoder) -- Output Encoding - -**민감 정보 암호화**: -- DB 암호화: AES-256 -- 전송 암호화: TLS 1.3 - ---- - -## 6. 예상 성과 지표 - -### 6.1 Phase별 성과 비교 - -| 지표 | MVP (Phase 1) | Phase 2 (확장) | Phase 3 (고도화) | -|------|---------------|----------------|------------------| -| **성능** | | | | -| STT 변환 | 1초 이내 | 0.8초 | 0.5초 | -| AI 회의록 생성 | 10초 | 7초 (배치 처리) | 5초 (스트리밍) | -| RAG 검색 (캐시 미스) | 2초 | 1.5초 | 1초 | -| RAG 검색 (캐시 적중) | 0.1초 | 0.1초 | 0.1초 | -| 실시간 동기화 | 3-5초 | 2-3초 | 1-2초 | -| 회의록 목록 조회 | 500ms | 100ms (Materialized View) | 50ms | -| **가용성** | | | | -| Uptime | 99% | 99.9% | 99.99% | -| MTTR (평균 복구 시간) | 30분 | 3분 (Circuit Breaker) | 1분 | -| **확장성** | | | | -| 동시 사용자 | 100명 | 1,000명 | 10,000명 | -| 회의당 최대 참석자 | 10명 | 50명 | 100명 | -| 일일 회의 처리 | 500건 | 5,000건 | 50,000건 | -| **비용** | | | | -| 인프라 비용 | $500/월 | $2,000/월 | $10,000/월 | -| 사용자당 비용 | $5/월 | $2/월 (2.5배 절감) | $1/월 (5배 절감) | - -### 6.2 패턴별 기대 효과 - -#### Cache-Aside -- **RAG 검색 비용**: 60% 절감 - - 캐시 미스: 2초 → 캐시 적중: 0.1초 - - 캐시 적중률: 80% (Phase 2) -- **API 호출 감소**: 외부 API 호출 80% 감소 -- **비용 절감**: 월 $500 → $200 (RAG API 비용) - -#### Queue-Based Load Leveling -- **처리량 향상**: 동시 요청 100 → 1,000 (10배) -- **응답 안정성**: 피크 시간대 응답시간 편차 50% 감소 -- **자원 효율**: CPU 사용률 평준화 (80% → 50%) - -#### Asynchronous Request-Reply -- **사용자 대기 시간**: 10초 → 즉시 응답 (202 Accepted) -- **사용자 경험**: 응답 대기 중 다른 작업 가능 -- **AI API 최적화**: 배치 처리로 30% 비용 절감 - -#### CQRS (Phase 2) -- **읽기 성능**: 응답시간 70% 단축 (500ms → 150ms) -- **쓰기 성능**: 독립적 최적화 가능 -- **확장성**: 읽기/쓰기 DB 독립 스케일링 - -#### Circuit Breaker (Phase 2) -- **장애 복구**: MTTR 30분 → 3분 (90% 단축) -- **장애 격리**: 한 서비스 장애가 전체 영향 없음 -- **가용성**: 99% → 99.9% uptime - -#### Event Sourcing (Phase 3) -- **감사 추적**: 100% 변경 이력 보존 -- **데이터 복원**: 임의 시점 상태 복원 가능 -- **규제 준수**: 완벽한 감사 로그 - -#### Priority Queue (Phase 3) -- **VIP 회의**: 응답시간 50% 단축 (10초 → 5초) -- **비즈니스 가치**: 중요 회의 우선 처리 -- **자원 활용**: 일반 회의는 유휴 시간 활용 - -### 6.3 비용 효율성 분석 - -#### Phase 1 (MVP) -- **인프라**: $500/월 - - API Gateway: $100 - - Redis: $50 - - RabbitMQ: $50 - - DB (PostgreSQL): $100 - - 컴퓨팅 (VM): $200 -- **외부 API**: $300/월 - - Azure Speech: $100 - - OpenAI: $200 -- **총 비용**: $800/월 -- **사용자**: 100명 -- **사용자당 비용**: $8/월 - -#### Phase 2 (확장) -- **인프라**: $2,000/월 (4배 증가) -- **외부 API**: $600/월 (2배 증가) - - Cache-Aside로 60% 절감 → $240 절감 - - Async 배치 처리로 30% 절감 → $60 절감 - - 실제 비용: $600 - $300 = $300 -- **총 비용**: $2,300/월 -- **사용자**: 1,000명 (10배 증가) -- **사용자당 비용**: $2.3/월 (71% 절감) - -#### Phase 3 (고도화) -- **인프라**: $10,000/월 (글로벌 배포) -- **외부 API**: $1,000/월 -- **총 비용**: $11,000/월 -- **사용자**: 10,000명 -- **사용자당 비용**: $1.1/월 (86% 절감 대비 MVP) - -**ROI 분석**: -- Phase 2: 투자 대비 2.5배 효율 (사용자 10배, 비용 4배) -- Phase 3: 투자 대비 7배 효율 (사용자 100배, 비용 14배) - ---- - -## 7. 결론 - -### 7.1 핵심 성과 - -본 아키텍처 패턴 적용 방안은 회의록 작성 및 공유 개선 서비스의 기술적 도전과제를 체계적으로 해결합니다: - -1. **실시간 협업 처리**: Publisher-Subscriber + WebSocket으로 3-5초 실시간 동기화 달성 -2. **대용량 데이터 처리**: Queue-Based Load Leveling으로 안정적 비동기 처리 -3. **AI/LLM 통합**: Asynchronous Request-Reply + Circuit Breaker로 안정성과 사용자 경험 보장 -4. **RAG 성능**: Cache-Aside로 80% 캐시 적중률, 60% 비용 절감 -5. **서비스 격리**: Circuit Breaker + Bulkhead로 99.9% 가용성 달성 -6. **데이터 일관성**: Saga + Event Sourcing으로 완벽한 일관성 보장 - -### 7.2 차별화 포인트 실현 - -아키텍처 패턴 적용으로 서비스 차별화 포인트를 강화합니다: - -- **맥락 기반 용어 설명**: RAG + Cache-Aside로 2초 이내 실용적 정보 제공 -- **강화된 Todo 연결**: Saga 패턴으로 Todo ↔ 회의록 실시간 양방향 연동 -- **프롬프팅 기반 회의록 개선**: Async Request-Reply로 즉시 응답, 백그라운드 생성 - -### 7.3 단계별 추진 전략 - -**Phase 1 (MVP)**: 핵심 패턴 8개로 안정적 출시 -- API Gateway, Queue, Cache, Pub-Sub 중심 -- 100명 사용자, 99% 가용성 목표 - -**Phase 2 (확장)**: 성능 최적화 및 안정성 강화 -- CQRS, Circuit Breaker, Materialized View 추가 -- 1,000명 사용자, 99.9% 가용성 목표 -- 70% 성능 향상, 90% 장애 복구 시간 단축 - -**Phase 3 (고도화)**: 대규모 확장 및 글로벌 배포 -- Event Sourcing, Saga, Priority Queue 적용 -- 10,000명 사용자, 99.99% 가용성 목표 -- 완벽한 감사 추적, 글로벌 3개 리전 - -### 7.4 비용 효율성 - -- **Phase 1**: 사용자당 $8/월 -- **Phase 2**: 사용자당 $2.3/월 (71% 절감) -- **Phase 3**: 사용자당 $1.1/월 (86% 절감) - -**투자 대비 수익**: -- Phase 2: 2.5배 효율 (사용자 10배 증가, 비용 4배 증가) -- Phase 3: 7배 효율 (사용자 100배 증가, 비용 14배 증가) - -### 7.5 리스크 및 대응 - -| 리스크 | 영향 | 대응 패턴 | -|--------|------|-----------| -| AI/STT API 장애 | 서비스 중단 | Circuit Breaker + Retry | -| 동시 수정 충돌 | 데이터 손실 | Last Write Wins + Event Sourcing | -| 대용량 트래픽 | 응답 지연 | Queue-Based Load Leveling + Auto-scaling | -| 캐시 불일치 | 데이터 정합성 | Write-through + TTL 관리 | -| 분산 트랜잭션 실패 | 데이터 불일치 | Saga + 보상 트랜잭션 | - -### 7.6 다음 단계 - -1. **MVP 개발 착수** (즉시) - - API Gateway, Queue, Cache 인프라 구축 - - User/Meeting 서비스 개발 시작 - -2. **프로토타입 검증** (1개월 내) - - 핵심 패턴 PoC 구현 - - 성능 및 안정성 테스트 - -3. **단계별 출시** (3-12개월) - - Phase 1: 3개월 MVP 출시 - - Phase 2: 6개월 성능 최적화 - - Phase 3: 12개월 글로벌 확장 - ---- - -## 부록 - -### A. 참고 문서 -- [유저스토리](../userstory.md) -- [클라우드 디자인 패턴 개요](../../claude/cloud-design-patterns.md) -- [아키텍처 패턴 선정 가이드](../../claude/architecture-patterns.md) - -### B. 기술 스택 -- **API Gateway**: Spring Cloud Gateway -- **Message Queue**: RabbitMQ (MVP), Kafka (Phase 2) -- **Cache**: Redis Cluster -- **Database**: PostgreSQL (주 DB), MongoDB (Event Store) -- **WebSocket**: SockJS + STOMP -- **Circuit Breaker**: Resilience4j -- **모니터링**: Prometheus + Grafana, Zipkin, ELK Stack -- **외부 API**: Azure Speech, Azure OpenAI, Azure Blob Storage - -### C. 용어 정의 -- **STT**: Speech-to-Text (음성-텍스트 변환) -- **LLM**: Large Language Model (대규모 언어 모델) -- **RAG**: Retrieval-Augmented Generation (검색 증강 생성) -- **CQRS**: Command Query Responsibility Segregation (명령 쿼리 책임 분리) -- **Saga**: 분산 트랜잭션 관리 패턴 -- **Event Sourcing**: 이벤트 기반 데이터 저장 패턴 -- **Circuit Breaker**: 장애 격리 패턴 -- **Pub-Sub**: Publisher-Subscriber (발행-구독) 패턴 - -### D. Mermaid 다이어그램 검증 -모든 Mermaid 다이어그램은 https://mermaid.live/edit 에서 검증 완료되었습니다. - ---- - -**문서 버전**: 1.0 -**최종 수정**: 2025-10-21 -**작성자**: 아키텍트 팀 (길동)