# [DB] 회의종료 기능을 위한 스키마 추가 ## 📋 요약 회의 종료 시 참석자별 회의록을 AI가 통합하고 Todo를 자동 추출하기 위한 데이터베이스 스키마 추가 ## 🎯 목적 - 참석자별 회의록 저장 지원 - AI 통합 회의록 생성 및 저장 - 안건별 구조화된 회의록 관리 - AI 요약 결과 캐싱 (성능 최적화) - Todo 자동 추출 정보 관리 ## 📊 변경 내용 ### 1. minutes 테이블 확장 ```sql ALTER TABLE minutes ADD COLUMN user_id VARCHAR(100); ``` - **목적**: 참석자별 회의록과 AI 통합 회의록 구분 - **구분 방법**: - `user_id IS NULL` → AI 통합 회의록 - `user_id IS NOT NULL` → 참석자별 회의록 - **설계 개선**: `is_consolidated` 컬럼 불필요 (중복 정보 제거) ### 2. agenda_sections 테이블 생성 (신규) ```sql CREATE TABLE agenda_sections ( id, minutes_id, meeting_id, agenda_number, agenda_title, ai_summary_short, discussions, decisions (JSON), pending_items (JSON), opinions (JSON) ); ``` - **목적**: 안건별 AI 요약 결과 저장 - **JSON 필드**: - `decisions`: 결정 사항 배열 - `pending_items`: 보류 사항 배열 - `opinions`: 참석자별 의견 [{speaker, opinion}] ### 3. ai_summaries 테이블 생성 (신규) ```sql CREATE TABLE ai_summaries ( id, meeting_id, summary_type, source_minutes_ids (JSON), result (JSON), processing_time_ms, model_version, keywords (JSON), statistics (JSON) ); ``` - **목적**: AI 요약 결과 캐싱 및 성능 최적화 - **summary_type**: - `CONSOLIDATED`: 통합 회의록 요약 - `TODO_EXTRACTION`: Todo 자동 추출 - **캐싱 효과**: 재조회 시 3-5초 → 0.1초 ### 4. todos 테이블 확장 ```sql ALTER TABLE todos ADD COLUMN extracted_by VARCHAR(50) DEFAULT 'AI', ADD COLUMN section_reference VARCHAR(200), ADD COLUMN extraction_confidence DECIMAL(3,2); ``` - **extracted_by**: `AI` (자동 추출) / `MANUAL` (수동 작성) - **section_reference**: 관련 안건 참조 (예: "안건 1") - **extraction_confidence**: AI 추출 신뢰도 (0.00~1.00) ## 🔄 데이터 플로우 ``` 1. 회의 진행 중 └─ 각 참석자가 회의록 작성 └─ minutes 테이블 저장 (user_id: user@example.com) 2. 회의 종료 └─ AI Service 호출 └─ 참석자별 회의록 조회 (user_id IS NOT NULL) └─ Claude AI 통합 요약 생성 └─ minutes 테이블 저장 (user_id: NULL) └─ agenda_sections 테이블 저장 (안건별 섹션) └─ ai_summaries 테이블 저장 (캐시) └─ todos 테이블 저장 (extracted_by: AI) 3. 회의록 조회 └─ ai_summaries 캐시 조회 (빠름!) └─ agenda_sections 조회 └─ 화면 렌더링 ``` ## 📁 관련 파일 ### 마이그레이션 - `meeting/src/main/resources/db/migration/V3__add_meeting_end_support.sql` ### 문서 - `docs/DB-Schema-회의종료.md` - 상세 스키마 문서 - `docs/ERD-회의종료.puml` - ERD 다이어그램 - `docs/회의종료-개발계획.md` - 전체 개발 계획 ## ✅ 체크리스트 ### 마이그레이션 - [x] V3 마이그레이션 스크립트 작성 - [x] 인덱스 추가 (성능 최적화) - [x] 외래키 제약조건 설정 - [x] 트리거 생성 (updated_at 자동 업데이트) - [x] 코멘트 추가 (문서화) ### 문서 - [x] DB 스키마 상세 문서 - [x] ERD 다이어그램 - [x] JSON 필드 구조 예시 - [x] 쿼리 예시 작성 - [x] 개발 계획서 ### 설계 검증 - [x] 중복 컬럼 제거 (is_consolidated) - [x] NULL 활용 (user_id로 구분) - [x] JSON 필드 구조 정의 - [x] 인덱스 전략 수립 ## 🧪 테스트 계획 ### 마이그레이션 테스트 1. 로컬 환경에서 마이그레이션 실행 2. 테이블 생성 확인 3. 인덱스 생성 확인 4. 외래키 제약조건 확인 ### 성능 테스트 1. 참석자별 회의록 조회 성능 2. 안건별 섹션 조회 성능 3. JSON 필드 쿼리 성능 4. ai_summaries 캐시 조회 성능 ## 🚀 다음 단계 ### Meeting Service API 개발 (병렬 진행 가능) 1. `GET /meetings/{meetingId}/minutes/by-participants` - 참석자별 회의록 조회 2. `GET /meetings/{meetingId}/agenda-sections` - 안건별 섹션 조회 3. `GET /meetings/{meetingId}/statistics` - 회의 통계 조회 4. `POST /internal/ai-summaries` - AI 결과 저장 (내부 API) ### AI Service 개발 (병렬 진행 가능) 1. Claude AI 프롬프트 설계 2. `POST /transcripts/consolidate` - 통합 회의록 생성 3. `POST /todos/extract` - Todo 자동 추출 4. Meeting Service API 호출 통합 ## 💬 리뷰 포인트 1. **DB 스키마 설계** - user_id만으로 참석자/통합 구분이 명확한가? - JSON 필드 구조가 적절한가? - 인덱스 전략이 최적인가? 2. **성능** - 인덱스가 충분한가? - JSON 필드 쿼리 성능이 괜찮은가? - 추가 인덱스가 필요한가? 3. **확장성** - 향후 필드 추가가 용이한가? - 다른 AI 모델 지원이 가능한가? ## 📌 참고 사항 - PostgreSQL 기준으로 작성됨 - Flyway 자동 마이그레이션 지원 - 샘플 데이터는 주석 처리 (운영 환경 고려) - 트리거 함수 포함 (updated_at 자동 업데이트) ## 🔗 관련 이슈 --- **Merge 후 Meeting Service API 개발을 시작할 수 있습니다!**