hgzero/design/pattern/architecture-pattern.md

# 클라우드 아키텍처 패턴 적용 방안

## 문서 정보
- **작성일**: 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 패턴 평가 매트릭스

| 패턴 | 기능 적합성<br/>(35%) | 성능 효과<br/>(25%) | 운영 복잡도<br/>(20%) | 확장성<br/>(15%) | 비용 효율성<br/>(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<br/>+ Gateway Offloading<br/>+ Rate Limiting]
    end

    subgraph "Authentication"
        LDAP[LDAP Server<br/>Federated Identity]
    end

    subgraph "Microservices"
        User[User Service<br/>Cache-Aside]
        Meeting[Meeting Service<br/>CQRS + Event Sourcing]
        STT[STT Service<br/>Queue + Async]
        AI[AI Service<br/>Queue + Circuit Breaker]
        RAG[RAG Service<br/>Cache-Aside]
        Collab[Collaboration Service<br/>Pub-Sub + WebSocket]
        Todo[Todo Service<br/>Saga + Pub-Sub]
        Notif[Notification Service<br/>Queue + Competing Consumers]
    end

    subgraph "Data Layer"
        Cache[(Redis Cache<br/>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<br/>RabbitMQ/Kafka<br/>Queue-Based Load Leveling]
        EventBus[Event Bus<br/>Publisher-Subscriber]
    end

    subgraph "External Services"
        AzureSpeech[Azure Speech API<br/>Circuit Breaker]
        OpenAI[OpenAI API<br/>Circuit Breaker]
        AzureBlob[Azure Blob Storage<br/>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<br/>(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: 수정 이벤트 발행<br/>(Publisher)

    Note over EventBus,Client2: 실시간 동기화
    EventBus->>Collab: 수정 이벤트 전달<br/>(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<br/>(Queue-Based)
    participant STT as STT Service<br/>(Circuit Breaker)
    participant AzureSpeech as Azure Speech API
    participant AIQueue as AI Queue<br/>(Queue-Based)
    participant AI as AI Service<br/>(Circuit Breaker)
    participant OpenAI as OpenAI API
    participant RAG as RAG Service<br/>(Cache-Aside)
    participant Cache as Redis Cache

    Note over Client,Meeting: 음성 녹음 시작
    Client->>Gateway: 음성 녹음 업로드
    Gateway->>Meeting: 녹음 데이터 전달
    Meeting->>STTQueue: 변환 요청 적재<br/>(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<br/>(Saga Orchestrator)
    participant EventBus as Event Bus<br/>(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 분석<br/>(액션 아이템 추출)
    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 이벤트<br/>(Publisher)

    Note over Todo,Calendar: Saga Step 2: 알림 발송
    EventBus->>Notif: TodoCreated 수신<br/>(Subscriber)
    Notif->>Notif: 이메일 발송

    alt 알림 성공
        Notif->>EventBus: NotificationSent 이벤트
    else 알림 실패
        Notif->>EventBus: NotificationFailed 이벤트
        EventBus->>Todo: 보상 트랜잭션<br/>(Todo 상태 변경: 알림 실패)
    end

    Note over Todo,Calendar: Saga Step 3: 캘린더 등록
    EventBus->>Todo: NotificationSent 수신
    Todo->>Calendar: 일정 등록 요청 (비동기)

    alt 캘린더 등록 성공
        Calendar-->>Todo: 성공
        Todo->>EventBus: TodoCompleted 이벤트<br/>(Saga 완료)
    else 캘린더 등록 실패
        Calendar--xTodo: 실패
        Todo->>Todo: 보상 트랜잭션<br/>(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% 절감<br/>Async: AI API 30% 절감<br/>Auto-scaling: 유휴 자원 80% 절감 | **총 50% 절감** |
| Phase 3 | $10,000/월 | 글로벌 확장으로 사용자 10배 증가<br/>비용은 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<MeetingListDTO> 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<MeetingEvent> 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
**작성자**: 아키텍트 팀 (길동)