mirror of
https://github.com/hwanny1128/HGZero.git
synced 2025-12-06 20:46:23 +00:00
ca78f9bc5a
프로토타입 기반 유저스토리 전면 재정비 - 10개 프로토타입 화면 분석 반영 - 신규 유저스토리 추가: UFR-MEET-015 (참석자 실시간 초대), UFR-NOTI-010 (알림 발송) - 알림 아키텍처 폴링 방식으로 통일 - 기존 24개 유저스토리 ID 승계 및 정리 - 총 28개 유저스토리 완성 분석 문서 추가 - 유저스토리 비교 분석 (v2.2.0 → v2.3.0) - MSC 아키텍처 분석 - 유저스토리 리뷰 및 작성 가이드 - UI/UX v1.4.20 업데이트 요약 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
221 lines
8.6 KiB
Markdown
221 lines
8.6 KiB
Markdown
# 유저스토리 M/S/C 및 기능점수 검토 결과
|
|
|
|
## 검토자: 민준(PO), 서연(AI), 준호(Backend), 유진(Frontend), 도현(QA), 지수(Designer)
|
|
|
|
---
|
|
|
|
## 1. M/S/C 우선순위 검토
|
|
|
|
### ✅ 적절한 Must (M) 항목들
|
|
1. **AFR-USER-010** (사용자 인증, M/8) - 핵심 보안 기능
|
|
2. **UFR-MEET-010** (회의예약, M/13) - 서비스 핵심 플로우
|
|
3. **UFR-MEET-030** (회의시작, M/8) - 서비스 핵심 플로우
|
|
4. **UFR-MEET-040** (회의종료, M/8) - 서비스 핵심 플로우
|
|
5. **UFR-MEET-050** (최종확정, M/13) - 회의록 완성 필수
|
|
6. **UFR-STT-010** (음성녹음인식, M/21) - 기본 기능이지만 필수
|
|
7. **UFR-AI-010** (회의록자동작성, M/34) - 핵심 차별화
|
|
8. **UFR-COLLAB-010** (실시간협업, M/34) - 핵심 차별화
|
|
|
|
### ⚠️ M → S로 변경 제안
|
|
**UFR-MEET-046** (회의록목록조회, M/8 → **S/8**)
|
|
- **이유**: 대시보드에서 최근 회의록을 볼 수 있으므로 1차 출시에서는 목록 조회가 없어도 서비스 가능
|
|
- **민준(PO)**: 사용자들이 과거 회의록을 찾기 위해서는 필요하지만, MVP에서는 대시보드만으로도 가능
|
|
- **유진(Frontend)**: 1차에서는 대시보드의 "최근 회의" 섹션으로 충분, 필터/검색은 2차 출시 추가 가능
|
|
|
|
**UFR-MEET-047** (회의록상세조회, M/8 → **S/8**)
|
|
- **이유**: 대시보드에서 회의록을 바로 열 수 있으므로, 별도 상세조회 화면은 2차 출시 가능
|
|
- **민준(PO)**: 상세조회는 있으면 좋지만, 대시보드 → 수정 화면으로 바로 진입 가능하면 MVP 가능
|
|
|
|
**AFR-USER-020** (대시보드, M/8 → **유지 M/8**)
|
|
- **검토**: 대시보드는 사용자 경험의 시작점이므로 Must 유지 필요
|
|
- **지수(Designer)**: 대시보드는 사용자 첫 인상과 전체 서비스 파악에 핵심적
|
|
|
|
### ⚠️ S → M으로 변경 제안
|
|
**UFR-AI-050** (용어설명, S/13 → **M/13**)
|
|
- **이유**: 차별화 전략 문서에서 "맥락 기반 용어 설명"을 핵심 차별화 포인트로 명시
|
|
- **서연(AI)**: 이 기능이 경쟁사와의 핵심 차별점이므로 1차 출시에 포함해야 함
|
|
- **민준(PO)**: 차별화 전략과 일관성을 위해 Must로 승격 필요
|
|
|
|
**UFR-AI-060** (회의록검색, S/13 → **유지 S/13**)
|
|
- **검토**: RAG 기반 검색은 고도화 기능으로 2차 출시 적절
|
|
- **서연(AI)**: 벡터 DB 구축 시간 고려 시 2차 출시가 현실적
|
|
|
|
### ⚠️ Should(S) 추가 제안
|
|
**UFR-TODO-020** (Todo연결, M/13 → **S/13**)
|
|
- **이유**: Todo 기본 관리(UFR-TODO-010)만 있어도 서비스 가능, 양방향 연결은 고도화 기능
|
|
- **준호(Backend)**: Todo-회의록 양방향 연결 복잡도가 높아 2차 출시 권장
|
|
- **민준(PO)**: 차별화 전략에 "강화된 Todo 연결"이 있지만, 기본 Todo 관리로도 차별화 가능
|
|
|
|
---
|
|
|
|
## 2. 기능점수 검토
|
|
|
|
### ⚠️ 점수 조정 제안
|
|
|
|
#### **UFR-AI-035** (섹션AI요약, M/21 → **M/13**)
|
|
**현재 점수**: 21
|
|
**조정 점수**: 13
|
|
**이유**:
|
|
- 복잡도: 단일 섹션 요약은 비교적 단순 (LLM 단일 호출)
|
|
- UFR-AI-010(회의록자동작성)의 부분 기능으로 기술 재사용 가능
|
|
- 처리 시간: 2-5초로 명시되어 있어 기술적 난이도 낮음
|
|
**서연(AI)**: 프롬프트 엔지니어링 재사용으로 8-13점 정도가 적절
|
|
|
|
#### **UFR-AI-040** (관련회의록연결, M/21 → **M/13**)
|
|
**현재 점수**: 21
|
|
**조정 점수**: 13
|
|
**이유**:
|
|
- 복잡도: 벡터 유사도 검색 표준 기술 사용
|
|
- UFR-AI-060(회의록검색)과 기술 스택 공유
|
|
- RAG 인프라 구축 시 함께 개발 가능
|
|
**서연(AI)**: 벡터 DB 구축되면 단순 유사도 검색이므로 13점 적절
|
|
|
|
#### **UFR-STT-010** (음성녹음인식, M/21 → **M/13**)
|
|
**현재 점수**: 21
|
|
**조정 점수**: 13
|
|
**이유**:
|
|
- 기본 기능으로 Azure Speech 등 외부 API 사용
|
|
- 화자 식별 없이 단순 텍스트 변환만
|
|
- 기술 리스크 낮음 (검증된 외부 서비스)
|
|
**준호(Backend)**: Azure Speech SDK 연동은 복잡도 낮아 13점 적절
|
|
|
|
#### **UFR-MEET-010** (회의예약, M/13 → **M/8**)
|
|
**현재 점수**: 13
|
|
**조정 점수**: 8
|
|
**이유**:
|
|
- 복잡도: 기본 CRUD + 이메일 발송
|
|
- 알림 서비스(UFR-NOTI-010, M/8)에 의존하지만 단순 호출
|
|
- 캘린더 연동은 나중 고도화 가능
|
|
**준호(Backend)**: 기본 예약 기능은 8점, 캘린더 자동 등록 제외 시 더 낮아질 수 있음
|
|
|
|
#### **UFR-TODO-020** (Todo연결, M/13 → **S/13 유지**)
|
|
**현재 점수**: 13
|
|
**조정 후**: S/13
|
|
**이유**:
|
|
- 복잡도: Todo-회의록 양방향 동기화는 고도화 기능
|
|
- UFR-TODO-010 (기본 Todo 관리)로도 서비스 가능
|
|
**준호(Backend)**: 양방향 연결은 복잡도 13점 적절, Should로 분류 권장
|
|
|
|
#### **UFR-COLLAB-010** (실시간협업, M/34) - **점수 유지**
|
|
**검토 결과**: 34점 적절
|
|
**이유**:
|
|
- WebSocket 인프라 + 버전 관리 + 충돌 해결
|
|
- 기술 복잡도 매우 높음
|
|
- 다수 동시 접속 처리 필요
|
|
**준호(Backend)**: WebSocket 서버 + Redis 캐시 + 버전 관리 로직으로 34점 타당
|
|
|
|
#### **UFR-AI-010** (회의록자동작성, M/34) - **점수 유지**
|
|
**검토 결과**: 34점 적절
|
|
**이유**:
|
|
- 실시간 처리 + 회의 종료 시 전체 요약 (2단계)
|
|
- 템플릿 반영 + 주요 메모 통합
|
|
- LLM 프롬프트 엔지니어링 복잡도 높음
|
|
**서연(AI)**: 실시간/배치 2단계 처리로 34점 타당
|
|
|
|
---
|
|
|
|
## 3. 종합 개선 제안
|
|
|
|
### M/S/C 변경 요약
|
|
| 요구사항 ID | 현재 | 제안 | 변경 이유 |
|
|
|-----------|------|------|----------|
|
|
| UFR-MEET-046 | M/8 | S/8 | 대시보드로 대체 가능 |
|
|
| UFR-MEET-047 | M/8 | S/8 | 대시보드 → 수정 바로 진입 가능 |
|
|
| UFR-AI-050 | S/13 | M/13 | 차별화 전략 핵심 |
|
|
| UFR-TODO-020 | M/13 | S/13 | 기본 Todo로 충분 |
|
|
|
|
### 기능점수 변경 요약
|
|
| 요구사항 ID | 현재 | 제안 | 변경 이유 |
|
|
|-----------|------|------|----------|
|
|
| UFR-AI-035 | M/21 | M/13 | 기술 재사용으로 복잡도 낮음 |
|
|
| UFR-AI-040 | M/21 | M/13 | 표준 벡터 검색 기술 |
|
|
| UFR-STT-010 | M/21 | M/13 | 외부 API 사용으로 리스크 낮음 |
|
|
| UFR-MEET-010 | M/13 | M/8 | 기본 CRUD 수준 |
|
|
|
|
### 변경 후 통계
|
|
**M/S/C 분포**:
|
|
- Must (M): 18개 (72%) ← 기존 20개
|
|
- Should (S): 7개 (28%) ← 기존 5개
|
|
- Could (C): 0개 (0%)
|
|
|
|
**평균 기능점수**:
|
|
- 변경 전: 15.48점
|
|
- 변경 후: 14.00점 (약 10% 감소)
|
|
|
|
**총 기능점수**:
|
|
- 변경 전: 387점
|
|
- 변경 후: 350점
|
|
|
|
---
|
|
|
|
## 4. MVP 출시 범위 권장사항
|
|
|
|
### 1차 출시 (Must만)
|
|
- 사용자 인증 및 대시보드
|
|
- 회의 예약/시작/종료/확정
|
|
- 음성 인식 및 회의록 자동 작성
|
|
- Todo 자동 추출 및 기본 관리
|
|
- 섹션 AI 요약 재생성
|
|
- **용어 설명 (차별화)**
|
|
- 관련 회의록 자동 연결
|
|
- 실시간 협업 및 충돌 방지
|
|
- 알림 발송
|
|
|
|
총 기능점수: **292점** (변경 후)
|
|
|
|
### 2차 출시 (Should 추가)
|
|
- 회의록 목록 조회 및 필터링
|
|
- 회의록 상세 조회 전용 화면
|
|
- 템플릿 선택 및 커스터마이징
|
|
- 회의록 RAG 검색
|
|
- 회의 패턴 분석 및 추천
|
|
- Todo 양방향 연결 강화
|
|
|
|
총 추가 기능점수: **58점**
|
|
|
|
---
|
|
|
|
## 5. 리스크 및 제약사항
|
|
|
|
### 기술 리스크
|
|
1. **UFR-COLLAB-010** (실시간협업, 34점)
|
|
- WebSocket 동시 접속 부하 테스트 필수
|
|
- Redis 캐시 장애 시 대응 방안 필요
|
|
|
|
2. **UFR-AI-010** (회의록자동작성, 34점)
|
|
- LLM 응답 시간 변동성 관리
|
|
- 프롬프트 품질 검증 시간 필요
|
|
|
|
3. **UFR-AI-050** (용어설명, M/13)
|
|
- RAG 인프라 구축 리드타임 (벡터 DB, 임베딩)
|
|
- 사내 문서 수집 및 전처리 시간
|
|
|
|
### 일정 제약
|
|
- 변경 후 총 기능점수: 350점
|
|
- 1인당 월 평균 생산성: 30-40점 (경험치)
|
|
- 4명 개발팀 기준: **약 2.5개월** 소요 예상
|
|
|
|
---
|
|
|
|
## 6. 최종 권고사항
|
|
|
|
### 지수(Designer)
|
|
- UFR-MEET-046, UFR-MEET-047을 Should로 변경하되, 사용자 경험 테스트 후 재검토 권장
|
|
- 대시보드만으로 충분한지 프로토타입 단계에서 검증 필요
|
|
|
|
### 서연(AI)
|
|
- UFR-AI-050(용어설명)은 차별화 전략 핵심이므로 Must로 승격 강력 권장
|
|
- UFR-AI-035, UFR-AI-040의 점수 하향은 기술 재사용 관점에서 타당
|
|
|
|
### 준호(Backend)
|
|
- UFR-TODO-020을 Should로 변경하여 개발 복잡도 분산 권장
|
|
- UFR-COLLAB-010의 기술 리스크 대비 시간 확보 필요
|
|
|
|
### 도현(QA)
|
|
- Must 항목 18개로 축소하면 테스트 범위 집중 가능
|
|
- 실시간 협업(UFR-COLLAB-010) 부하 테스트 충분한 시간 필요
|
|
|
|
### 민준(PO)
|
|
- 차별화 전략과 일관성 유지를 위해 UFR-AI-050을 Must로 승격 승인
|
|
- MVP 범위를 명확히 하여 1차 출시 집중, 2차 출시 계획 수립
|