# 논리 아키텍처 설계서

## 1. 개요

### 1.1 목적
회의록 작성 및 공유 개선 서비스의 논리 아키텍처를 정의하고, 마이크로서비스 간 통신 전략과 클라우드 디자인 패턴 적용 방안을 제시합니다.

### 1.2 설계 원칙

#### 1.2.1 마이크로서비스 설계 원칙
- **서비스 독립성**: 각 서비스는 독립적으로 배포 가능하며, 서비스 간 직접 의존성 최소화
- **단일 책임**: 각 서비스는 명확한 비즈니스 책임을 가지며, 하나의 도메인 영역에 집중
- **느슨한 결합**: 이벤트 기반 통신을 통한 서비스 간 결합도 최소화
- **캐시 우선**: Redis를 통한 성능 최적화 및 서비스 간 데이터 공유 최소화

#### 1.2.2 통신 전략
- **동기 통신**: 즉시 응답이 필요한 단순 조회 (REST API)
- **비동기 통신**: 장시간 작업 및 이벤트 기반 통신 (RabbitMQ)
- **캐시 우선**: 자주 사용되는 데이터는 Redis 캐시에서 직접 읽기
- **API Gateway**: 모든 클라이언트 요청의 단일 진입점

#### 1.2.3 클라우드 디자인 패턴 적용
- **API Gateway**: 라우팅, 인증, Rate Limiting
- **Queue-Based Load Leveling**: 부하 분산 및 비동기 처리
- **Cache-Aside**: 성능 최적화 및 DB 부하 감소
- **Publisher-Subscriber**: 이벤트 기반 통신
- **Asynchronous Request-Reply**: 장시간 작업 비동기 처리
- **Health Endpoint Monitoring**: 서비스 상태 모니터링

### 1.3 핵심 컴포넌트

#### 1.3.1 클라이언트 레이어
- **Web Application**: 브라우저 기반 SPA (Single Page Application)
- **Mobile Application**: iOS/Android 네이티브 앱 (향후 확장)

#### 1.3.2 API Gateway
- **Kong Gateway** 또는 **Spring Cloud Gateway**
- 역할: 라우팅, 인증/인가, Rate Limiting, 로깅

#### 1.3.3 백엔드 서비스 (8개)
1. **User Service**: 사용자 인증 및 권한 관리
2. **Meeting Service**: 회의 관리, 회의록 생성 및 관리, 회의록 공유
3. **STT Service**: 음성 녹음 관리, 음성-텍스트 변환, 화자 식별
4. **AI Service**: LLM 기반 회의록 자동 작성, Todo 자동 추출, 프롬프팅 기반 회의록 개선
5. **RAG Service**: 맥락 기반 용어 설명, 관련 문서 검색 및 연결, 업무 이력 통합
6. **Collaboration Service**: 실시간 동기화, 버전 관리, 충돌 해결
7. **Todo Service**: Todo 할당 및 관리, 진행 상황 추적, 회의록 실시간 연동
8. **Notification Service**: 알림 발송 및 리마인더 관리

#### 1.3.4 인프라 컴포넌트
- **PostgreSQL**: 각 서비스별 독립 데이터베이스
- **Redis**: 분산 캐시 및 세션 관리
- **RabbitMQ**: 메시지 큐 및 이벤트 버스
- **Azure Storage**: 음성 파일 저장
- **Azure Speech API**: STT(Speech-to-Text) 엔진
- **LLM API**: AI 회의록 자동 작성 엔진

---

## 2. 서비스 아키텍처

### 2.1 서비스별 책임

#### 2.1.1 User Service
**책임**: 사용자 인증 및 권한 관리
- LDAP 연동 인증
- JWT 토큰 발급 및 검증
- 사용자 프로필 관리
- 권한 관리

**데이터**:
- 사용자 정보 (user_db)
- 세션 정보 (Redis 캐시)

**외부 의존성**:
- LDAP 서버

---

#### 2.1.2 Meeting Service
**책임**: 회의 관리, 회의록 생성 및 관리, 회의록 공유
- 회의 예약 및 참석자 초대
- 회의 템플릿 관리
- 회의 시작/종료 관리
- 회의록 조회 및 수정
- 회의록 공유 설정
- 회의 통계 생성

**데이터**:
- 회의 정보 (meeting_db)
- 회의 템플릿 정보
- 회의록 메타데이터
- 회의 참석자 정보

**주요 이벤트**:
- **발행**: MeetingCreated, MeetingStarted, MeetingEnded, MeetingCancelled
- **구독**: TranscriptCreated, TodoCompleted

**통신 전략**:
- **동기**: User Service (사용자 정보 조회 - Redis 캐시 우선)
- **비동기**: STT Service (회의록 생성 요청 - Queue), Notification Service (알림 발송 - Event)

---

#### 2.1.3 STT Service
**책임**: 음성 녹음 관리, 음성-텍스트 변환, 화자 식별
- 음성 녹음 시작/중지
- 음성 파일 Azure Storage 저장
- Azure Speech API 연동 STT 처리
- 화자 자동 식별
- 텍스트 변환 결과 저장

**데이터**:
- 음성 파일 메타데이터 (transcript_db)
- 텍스트 변환 결과

**외부 의존성**:
- Azure Speech API (STT 엔진)
- Azure Storage (음성 파일 저장)

**주요 이벤트**:
- **구독**: MeetingEnded
- **통신**: AI Service (회의록 자동 작성 요청 - Queue)

---

#### 2.1.4 AI Service
**책임**: LLM 기반 회의록 자동 작성, Todo 자동 추출, 프롬프팅 기반 회의록 개선
- 회의록 자동 작성 (구조화, 문장 다듬기, 요약)
- Todo 자동 추출 및 담당자 식별
- 프롬프팅 기반 회의록 개선 (1Page 요약, 핵심 요약 등)
- 관련 회의록 자동 연결 (벡터 유사도 검색)

**데이터**:
- AI 처리 이력 (ai_db)
- 비동기 작업 상태 (Redis)

**외부 의존성**:
- LLM API (OpenAI, Azure OpenAI 등)

**주요 이벤트**:
- **구독**: TranscriptCreated
- **통신**: Todo Service (Todo 할당 요청 - Queue), RAG Service (관련 문서 검색 - 동기)

**비동기 작업**:
- AI 일정 생성 (Asynchronous Request-Reply 패턴 적용)
- AI 회의록 요약 생성

---

#### 2.1.5 RAG Service
**책임**: 맥락 기반 용어 설명, 관련 문서 검색 및 연결, 업무 이력 통합
- 전문용어 자동 감지
- 벡터 유사도 검색을 통한 관련 문서 검색
- 과거 회의록 및 사내 문서에서 맥락 기반 설명 생성
- 용어 사전 관리

**데이터**:
- 벡터 DB (관련 문서 임베딩)
- 용어 사전 (rag_db)

**외부 의존성**:
- 사내 문서 저장소 (위키, 매뉴얼 등)

**통신 전략**:
- **동기**: AI Service (관련 문서 검색 요청 시)

---

#### 2.1.6 Collaboration Service
**책임**: 실시간 동기화, 버전 관리, 충돌 해결
- 회의록 실시간 수정 동기화 (WebSocket)
- 회의록 버전 관리
- 동시 수정 충돌 감지 및 해결
- 회의록 섹션 검증 완료 처리

**데이터**:
- 회의록 버전 정보 (collaboration_db)
- 수정 이력

**주요 이벤트**:
- **발행**: TranscriptUpdated, SectionVerified

**통신 전략**:
- **WebSocket**: 실시간 동기화 (클라이언트 ↔ Collaboration Service)
- **비동기**: Notification Service (검증 완료 알림 - Event)

---

#### 2.1.7 Todo Service
**책임**: Todo 할당 및 관리, 진행 상황 추적, 회의록 실시간 연동
- Todo 생성 및 할당
- Todo 진행 상황 추적
- Todo 완료 처리
- 회의록과 Todo 실시간 양방향 연동
- 캘린더 연동

**데이터**:
- Todo 정보 (todo_db)
- Todo 진행 상황

**주요 이벤트**:
- **발행**: TodoCreated, TodoStatusChanged, TodoCompleted
- **구독**: MeetingEnded (AI Service를 통한 Todo 자동 추출)

**통신 전략**:
- **동기**: Meeting Service (회의록 Todo 섹션 업데이트 - REST API)
- **비동기**: Notification Service (Todo 알림 - Event)

---

#### 2.1.8 Notification Service
**책임**: 알림 발송 및 리마인더 관리
- 이메일 알림 발송
- SMS 알림 발송 (선택)
- 리마인더 관리 (회의 시작 30분 전, Todo 마감일 3일 전 등)
- 알림 발송 큐 처리

**데이터**:
- 알림 발송 이력 (notification_db)

**외부 의존성**:
- SMTP 서버 (이메일)
- SMS 서비스 (선택)

**주요 이벤트**:
- **구독**: MeetingCreated, MeetingEnded, TranscriptCreated, TodoCreated, TodoCompleted, SectionVerified

---

### 2.2 서비스 간 통신 전략

#### 2.2.1 동기 통신 (REST API)
**사용 시나리오**: 즉시 응답이 필요한 조회 작업

| 요청 서비스 | 대상 서비스 | 목적 | 캐시 전략 |
|-----------|-----------|------|---------|
| Meeting Service | User Service | 사용자 정보 조회 | Redis 캐시 우선 (TTL: 30분) |
| Todo Service | Meeting Service | 회의록 Todo 섹션 업데이트 | 즉시 반영 |
| AI Service | RAG Service | 관련 문서 검색 | 캐시 없음 (검색 결과는 매번 변경 가능) |

**특징**:
- Cache-Aside 패턴 적용 (User 정보, Meeting 정보 등)
- API Gateway를 통한 라우팅 및 인증

---

#### 2.2.2 비동기 통신 (Message Queue)
**사용 시나리오**: 장시간 작업 또는 즉시 응답 불필요

| 발행 서비스 | 큐 이름 | 구독 서비스 | 목적 |
|-----------|---------|-----------|------|
| Meeting Service | transcript.creation.queue | STT Service | 회의록 생성 요청 |
| STT Service | ai.processing.queue | AI Service | 회의록 자동 작성 요청 |
| AI Service | todo.extraction.queue | Todo Service | Todo 추출 및 할당 |
| 모든 서비스 | notification.queue | Notification Service | 알림 발송 요청 |

**특징**:
- Queue-Based Load Leveling 패턴 적용
- Consumer Concurrency 조정으로 부하 분산
- Dead Letter Queue를 통한 실패 메시지 관리

---

#### 2.2.3 이벤트 기반 통신 (Pub-Sub)
**사용 시나리오**: 하나의 이벤트를 여러 서비스가 구독

| 이벤트 | 발행 서비스 | 구독 서비스 | 목적 |
|-------|-----------|-----------|------|
| MeetingCreated | Meeting Service | Notification Service, AI Service | 회의 생성 알림, AI 분석 준비 |
| MeetingEnded | Meeting Service | STT Service, Notification Service, Todo Service | 회의록 생성, 종료 알림, Todo 추출 |
| TranscriptCreated | STT Service | Notification Service, Meeting Service, AI Service | 회의록 생성 완료 알림, 상태 업데이트, AI 분석 |
| TodoCreated | Todo Service | Notification Service | Todo 할당 알림 |
| TodoCompleted | Todo Service | Notification Service, Meeting Service | Todo 완료 알림, 회의록 업데이트 |
| SectionVerified | Collaboration Service | Notification Service | 검증 완료 알림 |

**특징**:
- Publisher-Subscriber 패턴 적용
- RabbitMQ Topic Exchange 사용
- 서비스 간 느슨한 결합

---

#### 2.2.4 비동기 작업 처리 (Asynchronous Request-Reply)
**사용 시나리오**: 장시간 실행되는 작업 (1분 이상)

| 서비스 | 작업 | 예상 시간 | 상태 저장 |
|-------|------|----------|---------|
| AI Service | AI 일정 생성 | 30초 ~ 2분 | Redis (taskId 기반) |
| AI Service | AI 회의록 요약 생성 | 1분 ~ 5분 | Redis (taskId 기반) |
| STT Service | 음성 파일 STT 변환 | 1분 ~ 10분 | Redis (taskId 기반) |

**처리 플로우**:
1. 클라이언트 → API Gateway → 서비스: 작업 요청
2. 서비스: taskId 생성 → Redis 상태 저장 (PENDING) → Queue 발행
3. 서비스 → 클라이언트: 202 Accepted + taskId 즉시 반환
4. Worker: Queue 소비 → 상태 업데이트 (PROCESSING) → 작업 처리 → 상태 업데이트 (COMPLETED)
5. 클라이언트: GET /tasks/{taskId}로 상태 폴링 또는 WebSocket Push

**특징**:
- Asynchronous Request-Reply 패턴 적용
- Redis를 통한 작업 상태 관리 (TTL: 24시간)
- 폴링 또는 WebSocket을 통한 결과 조회

---

#### 2.2.5 실시간 통신 (WebSocket)
**사용 시나리오**: 실시간 협업 및 즉시 알림

| 사용 케이스 | 서비스 | 클라이언트 |
|----------|-------|----------|
| 회의록 실시간 동기화 | Collaboration Service | Frontend |
| AI 작업 완료 Push (옵션) | AI Service | Frontend |

**특징**:
- WebSocket 기반 양방향 통신
- 수정 델타만 전송하여 네트워크 효율 최적화
- 충돌 감지 및 해결 (Last Write Wins 또는 수동 병합)

---

## 3. 주요 사용자 플로우

### 3.1 회의 생성 및 예약 플로우

```
1. 사용자 → Frontend: 회의 예약 정보 입력
2. Frontend → API Gateway → Meeting Service: POST /api/meetings
3. Meeting Service:
   - 회의 정보 저장 (meeting_db)
   - MeetingCreated 이벤트 발행
4. Notification Service (구독):
   - 참석자에게 초대 이메일 발송
   - 캘린더 일정 등록
5. AI Service (구독):
   - 회의 일정 분석 준비 (비동기)
6. Frontend ← Meeting Service: 회의 정보 반환
```

**적용 패턴**:
- API Gateway: 라우팅 및 인증
- Publisher-Subscriber: MeetingCreated 이벤트
- Queue-Based Load Leveling: 알림 발송 큐

---

### 3.2 회의 진행 및 회의록 생성 플로우

```
1. 사용자 → Frontend: 회의 시작 버튼 클릭
2. Frontend → API Gateway → Meeting Service: POST /api/meetings/{id}/start
3. Meeting Service:
   - 회의 상태 '진행중'으로 업데이트
   - 회의 세션 생성
   - MeetingStarted 이벤트 발행
4. STT Service:
   - 음성 녹음 시작
   - 실시간 STT 처리 (Azure Speech API)
   - 텍스트 변환 결과 저장
5. AI Service:
   - 텍스트 변환 결과 수신
   - 실시간 회의록 자동 작성 (구조화, 문장 다듬기)
6. Collaboration Service:
   - 회의록 실시간 동기화 (WebSocket)
   - 참석자 화면에 실시간 반영
7. 사용자 → Frontend: 회의 종료 버튼 클릭
8. Frontend → API Gateway → Meeting Service: POST /api/meetings/{id}/end
9. Meeting Service:
   - 회의 상태 '종료'로 업데이트
   - 회의 통계 생성
   - MeetingEnded 이벤트 발행
10. STT Service (구독):
    - 음성 녹음 중지
    - 음성 파일 Azure Storage 저장
11. Notification Service (구독):
    - 참석자에게 회의 종료 알림
12. Todo Service (구독):
    - AI Service를 통한 Todo 자동 추출 요청 (비동기)
```

**적용 패턴**:
- API Gateway: 라우팅 및 인증
- Publisher-Subscriber: MeetingStarted, MeetingEnded 이벤트
- Queue-Based Load Leveling: Todo 추출 큐
- WebSocket: 실시간 회의록 동기화

---

### 3.3 AI 기반 Todo 자동 추출 및 할당 플로우

```
1. Todo Service (MeetingEnded 이벤트 구독):
   - AI Service에 Todo 추출 요청 (Queue)
2. AI Service Worker:
   - 회의록 텍스트 분석
   - Todo 항목 추출 (LLM API)
   - 담당자 자동 식별
   - Todo 정보 생성
3. AI Service → Todo Service:
   - Todo 정보 전달 (Queue)
4. Todo Service:
   - Todo 생성 및 저장 (todo_db)
   - TodoCreated 이벤트 발행
   - 회의록 Todo 섹션 업데이트 (Meeting Service REST API 호출)
5. Notification Service (구독):
   - 담당자에게 Todo 할당 알림 (이메일)
   - 마감일 3일 전 리마인더 일정 생성
6. Meeting Service:
   - 회의록 Todo 섹션 업데이트
   - Redis 캐시 무효화
```

**적용 패턴**:
- Publisher-Subscriber: MeetingEnded, TodoCreated 이벤트
- Queue-Based Load Leveling: AI 처리 큐, Todo 할당 큐
- Cache-Aside: 회의록 캐시 무효화

---

### 3.4 맥락 기반 용어 설명 플로우

```
1. Frontend: 회의록 작성 중 전문용어 감지 (클라이언트 측)
2. Frontend → API Gateway → RAG Service: POST /api/rag/terms/explain
3. RAG Service:
   - 용어 사전 확인
   - 벡터 유사도 검색 (과거 회의록, 사내 문서)
   - 관련 문서 추출 (최대 5개)
   - LLM을 통한 맥락 기반 설명 생성
4. RAG Service → Frontend:
   - 용어 정의
   - 맥락 기반 상세 설명
   - 실제 사용 사례
   - 관련 프로젝트/이슈
   - 과거 회의록 링크 (최대 3개)
5. Frontend:
   - 툴팁 또는 사이드 패널로 설명 표시
```

**적용 패턴**:
- API Gateway: 라우팅 및 인증
- Cache-Aside: 용어 사전 캐싱

---

### 3.5 AI 일정 생성 (비동기 작업) 플로우

```
1. Frontend → API Gateway → AI Service: POST /api/ai/schedules
2. AI Service:
   - taskId 생성 (UUID)
   - Redis 상태 저장 (PENDING)
   - Queue에 작업 메시지 발행
   - 202 Accepted + taskId 즉시 반환
3. AI Worker (비동기):
   - Queue 소비
   - Redis 상태 업데이트 (PROCESSING)
   - LLM API 호출하여 일정 생성 (1분 소요)
   - Redis 상태 업데이트 (COMPLETED) + 결과 저장
4. Frontend (폴링):
   - GET /api/ai/tasks/{taskId}를 5초마다 호출
   - status가 COMPLETED일 때 결과 획득
```

**적용 패턴**:
- Asynchronous Request-Reply: 비동기 작업 처리
- Queue-Based Load Leveling: AI 처리 큐
- Redis: 작업 상태 관리

---

### 3.6 회의록 실시간 협업 플로우

```
1. 참석자 A → Frontend: 회의록 수정
2. Frontend → Collaboration Service (WebSocket): 수정 델타 전송
3. Collaboration Service:
   - 수정 권한 확인
   - 수정 이력 저장 (collaboration_db)
   - 버전 관리
   - 충돌 감지 (동일 위치 동시 수정 시)
4. Collaboration Service → 모든 참석자 (WebSocket):
   - 수정 델타 실시간 브로드캐스트
   - 수정 영역 하이라이트 (3초간)
5. 참석자 B, C Frontend:
   - 실시간으로 수정 내용 반영
6. 충돌 발생 시:
   - Last Write Wins (기본) 또는 수동 병합 UI 제공
```

**적용 패턴**:
- WebSocket: 실시간 양방향 통신
- Queue-Based Load Leveling: 알림 발송 큐 (수정 알림)

---

### 3.7 회의록 검증 완료 플로우

```
1. 참석자 → Frontend: 섹션 검증 완료 버튼 클릭
2. Frontend → API Gateway → Collaboration Service: POST /api/collaboration/sections/{id}/verify
3. Collaboration Service:
   - 검증자 정보 기록
   - 검증 상태 업데이트 (검증 완료)
   - 회의 생성자만 섹션 잠금 가능 (선택)
   - SectionVerified 이벤트 발행
4. Notification Service (구독):
   - 전체 참석자에게 검증 완료 알림 (이메일)
5. Collaboration Service → Frontend (WebSocket):
   - 검증 완료 상태 실시간 동기화
   - 검증 배지 표시 (체크 아이콘)
```

**적용 패턴**:
- Publisher-Subscriber: SectionVerified 이벤트
- WebSocket: 실시간 상태 동기화
- Queue-Based Load Leveling: 알림 발송 큐

---

## 4. 데이터 흐름 및 캐싱 전략

### 4.1 데이터베이스 구성
- **서비스별 독립 데이터베이스**: 각 서비스마다 독립적인 PostgreSQL 데이터베이스
- **서비스 간 데이터 공유 최소화**: 캐시 또는 이벤트를 통한 데이터 공유

| 서비스 | 데이터베이스 | 주요 테이블 |
|-------|-----------|----------|
| User Service | user_db | users, roles, permissions |
| Meeting Service | meeting_db | meetings, templates, participants, transcripts_metadata |
| STT Service | transcript_db | audio_files, stt_results, speakers |
| AI Service | ai_db | ai_tasks, ai_results, related_transcripts |
| RAG Service | rag_db | terms_dictionary, document_embeddings |
| Collaboration Service | collaboration_db | transcript_versions, edit_history, conflicts |
| Todo Service | todo_db | todos, todo_status_history |
| Notification Service | notification_db | notifications, notification_templates |

---

### 4.2 캐싱 전략 (Cache-Aside 패턴)

#### 4.2.1 캐싱 대상 데이터

| 서비스 | 캐시 데이터 | TTL | 무효화 트리거 |
|-------|----------|-----|-------------|
| User Service | 사용자 프로필 정보 | 30분 | 사용자 정보 업데이트 |
| User Service | 사용자 권한 정보 | 1시간 | 권한 변경 |
| Meeting Service | 회의 기본 정보 | 10분 | 회의 정보 수정 |
| Meeting Service | 회의 참여자 목록 | 10분 | 참여자 변경 |
| Meeting Service | 회의 템플릿 목록 | 1시간 | 템플릿 생성/수정 |
| STT Service | 회의록 조회 | 30분 | 회의록 수정 |
| Todo Service | 사용자별 Todo 목록 | 5분 | Todo 상태 변경 |
| Todo Service | Todo 진행 상태 통계 | 5분 | Todo 완료 |

#### 4.2.2 캐시 정책

**읽기 집중 데이터** (Cache-Aside):
- 패턴: Lazy Loading
- 전략: 캐시 미스 시 DB 조회 → 캐시 저장
- 예: 사용자 프로필, 회의 정보 조회

**쓰기 빈도 높은 데이터** (Write-Through + Cache-Aside):
- 패턴: 업데이트 시 캐시 무효화
- 전략: DB 업데이트 → 캐시 삭제 → 다음 조회 시 재생성
- 예: Todo 상태 변경, 회의 정보 수정

**캐시 무효화**:
- 데이터 변경 시 즉시 무효화 (Cache Eviction)
- TTL 기반 자동 만료
- 명시적 삭제 API 제공 (관리자용)

---

### 4.3 비동기 작업 상태 관리 (Redis)

**작업 상태 저장**:
- Key: `task:{taskId}`
- Value: `{ taskId, status, createdAt, startedAt, completedAt, result, errorMessage }`
- TTL: 24시간

**상태 흐름**:
1. PENDING: 요청 접수 직후
2. PROCESSING: Worker가 작업 시작
3. COMPLETED: 작업 성공 완료
4. FAILED: 작업 실패

---

## 5. 확장성 및 성능 고려사항

### 5.1 수평 확장 전략

#### 5.1.1 Stateless 서비스 설계
- **모든 백엔드 서비스는 Stateless**: 세션 정보는 Redis에 저장
- **수평 확장 가능**: Kubernetes 기반 Pod Auto Scaling
- **Load Balancer**: Kubernetes Service (ClusterIP)를 통한 부하 분산

#### 5.1.2 서비스별 확장 전략

| 서비스 | 확장 전략 | Auto Scaling 기준 |
|-------|---------|-----------------|
| API Gateway | 수평 확장 (최소 2개) | CPU > 70% 또는 RPS > 1000 |
| User Service | 수평 확장 | CPU > 70% |
| Meeting Service | 수평 확장 | CPU > 70% 또는 메모리 > 80% |
| STT Service | 수평 확장 + Worker 증설 | Queue 길이 > 100 |
| AI Service | 수평 확장 + Worker 증설 | Queue 길이 > 50 |
| Notification Service | 수평 확장 + Worker 증설 | Queue 길이 > 200 |
| Todo Service | 수평 확장 | CPU > 70% |
| Collaboration Service | 수평 확장 (WebSocket) | 동시 연결 > 500 |

---

### 5.2 성능 최적화

#### 5.2.1 캐싱 최적화
- **Cache Hit Rate 목표**: 70% 이상
- **Hot Key 문제 대응**: 자주 조회되는 데이터는 로컬 캐시 + 분산 캐시 병행
- **Cache Stampede 방지**: Singleflight 패턴 적용 (동시 다발적 Cache Miss 방지)

#### 5.2.2 데이터베이스 최적화
- **Connection Pool**: HikariCP 설정 최적화 (maxPoolSize: 10-20)
- **인덱스 최적화**: 자주 조회되는 필드에 인덱스 생성
- **Read Replica**: 읽기 부하 분산 (필요 시)

#### 5.2.3 메시지 큐 최적화
- **Consumer Concurrency**: 서비스별 동시 처리 워커 수 조정 (3-10)
- **Prefetch Count**: RabbitMQ Prefetch 설정 최적화
- **Dead Letter Queue**: 실패 메시지 별도 처리

---

### 5.3 성능 목표

| 지표 | 목표 |
|------|------|
| API 응답 시간 (P95) | < 500ms |
| 회의록 생성 시간 | < 2분 |
| AI 일정 생성 시간 | < 1분 |
| Cache Hit Rate | > 70% |
| 시스템 가용성 | > 99.5% |
| 동시 사용자 수 | 10,000명 |
| 동시 진행 회의 수 | 1,000개 |
| 일일 처리 회의 수 | 100,000개 |

---

## 6. 보안 고려사항

### 6.1 인증 및 인가

#### 6.1.1 인증 전략
- **LDAP 연동**: 사내 LDAP 서버와 연동한 사용자 인증
- **JWT 토큰**: 인증 후 JWT 토큰 발급 (만료 시간: 1시간)
- **Refresh Token**: 장기 세션 유지 (만료 시간: 7일)
- **Token 검증**: API Gateway에서 JWT 토큰 검증 (모든 요청)

#### 6.1.2 인가 전략
- **역할 기반 접근 제어 (RBAC)**: 사용자 역할에 따른 권한 관리
- **회의 참여자 검증**: 회의 참여자만 회의록 접근 가능
- **회의록 작성자 권한**: 수정, 삭제 권한은 작성자에게만 부여

---

### 6.2 데이터 보안

#### 6.2.1 암호화
- **전송 중 암호화**: HTTPS/TLS (API Gateway)
- **저장 시 암호화**: PostgreSQL Transparent Data Encryption (TDE)
- **민감 정보 암호화**: 사용자 비밀번호는 bcrypt 해싱

#### 6.2.2 데이터 접근 제어
- **데이터베이스 접근**: 서비스별 독립 계정, 최소 권한 원칙
- **Redis 접근**: Password 인증 + ACL 설정
- **RabbitMQ 접근**: 서비스별 독립 계정, 큐별 권한 관리

---

### 6.3 보안 모니터링

#### 6.3.1 로깅
- **API Gateway**: 모든 요청/응답 로깅 (사용자 ID, 엔드포인트, 응답 시간)
- **인증 실패 로깅**: 반복적인 인증 실패 시 경고
- **민감 정보 마스킹**: 로그에서 비밀번호, 토큰 등 마스킹

#### 6.3.2 보안 이벤트 모니터링
- **이상 접근 탐지**: 짧은 시간 내 과도한 요청 (Rate Limiting)
- **권한 없는 접근 시도**: 403 Forbidden 응답 모니터링
- **보안 패치**: 정기적인 보안 업데이트 및 취약점 점검

---

## 7. 논리 아키텍처 다이어그램

논리 아키텍처 다이어그램은 별도 파일로 작성되었습니다.

**파일**: [logical-architecture.mmd](logical-architecture.mmd)

**온라인 확인**: https://mermaid.live/edit

---

## 8. 문서 이력

| 버전 | 작성일 | 작성자 | 변경 내용 |
|------|--------|--------|----------|
| 1.0 | 2025-01-20 | 준호 | 초안 작성 |