ivada-infra/DOCS
3
0
Fork 0
Code Issues 1 Pull Requests 5 Actions Packages Projects Releases Wiki Activity

Move completed plan documents to archive (251223, 251225, 251217)

Browse Source
This commit is contained in:
Claude-51124 2025-12-25 23:45:18 +09:00
parent a859cbfa8d
commit 0e56097be6
10 changed files with 149 additions and 564 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

88
journey/plans/251206_skill_calendar_자동배포_구성.md
View File

@ -1,88 +0,0 @@
# skill-calendar 51124 서버 자동 배포 구성 (계획)
**날짜**: 2025-12-06
**작성자**: admin
**관련 파일**: `skill-calendar/.gitea/workflows/deploy.yml` (생성 예정)
---
## 현재 상태
**skill-calendar는 여전히 수동 배포 상태이며, 이 문서는 자동 배포를 위한 계획 초안입니다.**
## 목표
skill-calendar 서비스를 Gitea Actions를 통해 51124 서버에 자동 배포하도록 구성
## 배경
- 현재 상태: skill-calendar는 자동 배포 미설정 (AGENTS.md:29)
- 문제: `.github/workflows/deploy.yml` 존재하나 Gitea Actions는 `.gitea/workflows/` 경로만 인식
- 참고: skill-rag-file, skill-slack, rb8001 등은 이미 자동 배포 구성 완료
## 아키텍처
### 서버 관계
- **51123 서버**: Gitea Actions runner (self-hosted)
- **51124 서버**: 배포 대상 서버 (192.168.219.52, SSH 포트 51124)
- **배포 플로우**: 51123 runner → SSH(51124) → git pull → docker 재시작
### 필수 Secrets
- `SSH_PRIVATE_KEY_51124`: 51124 서버 SSH 키
- `SSH_HOST_51124`: 192.168.219.52
- `SSH_USER_51124`: admin
## 구현 계획
### Phase 1: 워크플로우 파일 생성
- 경로: `skill-calendar/.gitea/workflows/deploy.yml`
- 참고: `skill-rag-file/.gitea/workflows/deploy.yml`, `rb8001/.gitea/workflows/cicd.yml`
### Phase 2: SSH 연결 설정
- SSH 키 설정 (`~/.ssh/deploy_key`, chmod 600)
- known_hosts 추가 (`ssh-keyscan -p 51124`)
- 연결 테스트 (`ConnectTimeout=10`, `StrictHostKeyChecking=no`)
### Phase 3: 배포 스크립트
- 경로 이동: `/home/admin/ivada_project/skill-calendar`
- Git pull: `git pull origin main --rebase`
- .env 파일 확인 (없으면 exit 1)
- Docker 재시작: `docker compose down || true`, `docker compose up -d --build`
### Phase 4: 헬스체크
- 엔드포인트: `http://localhost:8512/health`
- 재시도: 최대 10회 (5초 간격)
- 실패 시: 컨테이너 로그 출력 후 exit 1
### Phase 5: 에러 처리
- `set -e`로 에러 즉시 중단
- 빌드 실패 시 로그 확인 (`docker compose logs --tail=50`)
- 컨테이너 상태 확인 (`docker ps | grep skill-calendar`)
- SSH 키 정리 (`rm -f ~/.ssh/deploy_key`)
## 주의사항
- YAML 문법: heredoc 사용 시 따옴표 처리 주의 (참고: `250904_admin_skill-news_zombie_process_gitea_actions.md`)
- Actions 캐시: 워크플로우 수정 시 `/root/.cache/act/` 캐시 삭제 필요할 수 있음
- DB 연결: skill-calendar는 51123 PostgreSQL(main_db)에 연결하므로 DB 네트워크/권한 설정도 함께 고려해야 함 (`docker-compose.yml:14`)
## 구현 체크리스트
실제 구현 시 다음 항목을 확인하고 이 문서에 업데이트:
- [ ] `.gitea/workflows/deploy.yml` 파일 생성 완료
- [ ] Gitea Secrets 설정 확인 (`SSH_PRIVATE_KEY_51124`, `SSH_HOST_51124`, `SSH_USER_51124`)
- [ ] Actions runner 설정 확인 (self-hosted)
- [ ] 첫 배포 성공 로그 확인
- [ ] 헬스체크 정상 작동 확인
## 참고 문서
- `DOCS/journey/troubleshooting/250728_happybell80_nginx프록시및CI배포문제해결.md`: SSH 인증 실패 해결
- `DOCS/journey/troubleshooting/250820_happybell80_skill-email_DB통합및Actions배포.md`: 경로 문제 해결
- `DOCS/journey/troubleshooting/250929_actions_cache_problem.md`: Actions 캐시 문제
- `DOCS/book/300_architecture/312_문서_작성_원칙.md`: 문서 작성 원칙
---
**구현 완료 시**: 이 문서를 `journey/troubleshooting/`으로 이동하고 구현 섹션 삭제

97
journey/plans/251215_coldmail_email_db_storage.md
View File

@ -1,97 +0,0 @@
# 콜드메일 이메일 원본 데이터 DB 저장 계획
**날짜**: 2025-12-15
**작성자**: Auto
**관련 파일**:
- `rb8001/app/services/coldmail_processor.py`
- `rb8001/app/state/ir_valuation_repository.py`
---
## 목표
콜드메일 처리 시 이메일 원본 데이터(제목, 본문, 보낸사람)를 DB에 저장하여 나중에 분석(대표 이름 추출 등) 가능하도록 함.
---
## 배경
### 현재 문제
- 이메일 원본 데이터가 DB에 저장되지 않음
- 이메일 본문에서 대표 이름 추출 등 분석 불가
- skill-email은 실시간 조회만 하고 저장하지 않음
### 데이터 저장 전략
- **DB 저장 (분석용)**: 이메일 원본 데이터 전체 (제목, 본문, 보낸사람 등)
- **Slack Lists (보여주기용)**: 투자 검토용 핵심 정보만 (회사명, 대표명, 이메일 주소, IR Deck 파일)
---
## 구현 계획
### Phase 1: 테이블 스키마 변경
**파일**: `rb8001/app/state/ir_valuation_repository.py`
**변경 내용**:
- `ir_deck_evaluations` 테이블에 `email_metadata JSONB` 컬럼 추가 (nullable)
**스키마**:
```sql
ALTER TABLE ir_deck_evaluations
ADD COLUMN email_metadata JSONB;
CREATE INDEX IF NOT EXISTS idx_ir_deck_eval_email_metadata
ON ir_deck_evaluations USING GIN (email_metadata);
```
**JSONB 구조** (콜드메일인 경우):
```json
{
"email_id": "skill-email 원본 ID",
"subject": "이메일 제목",
"body": "이메일 본문",
"from_email": "보낸사람 이메일",
"from_name": "보낸사람 이름",
"received_at": "수신일시 (ISO 8601)"
}
```
**참고**: Slack/프론트엔드에서 업로드한 IR 자료는 이메일이 아니므로 `email_metadata = NULL`
---
### Phase 2: 콜드메일 처리 시 저장 로직 추가
**파일**: `rb8001/app/services/coldmail_processor.py`
**변경 내용**:
- `process_coldmail()` 함수에서 이메일 정보 추출
- IR 평가 결과 저장 시 `email_metadata` 포함
**구현 위치**: `coldmail_processor.py:107` (IR 분석 후)
**저장 시점**:
- IR Deck 평가 결과와 함께 `ir_deck_evaluations` 테이블에 저장
- 또는 별도 `IRValuationRepository.create_evaluation()` 호출 시 `email_metadata` 파라미터 추가
---
### Phase 3: 대표 이름 추출 로직 개선
**파일**: `rb8001/app/services/coldmail_processor.py`
**변경 내용**:
- 이메일 본문에서 대표 이름 추출 로직 추가 (LLM 또는 정규식)
- 우선순위: 이메일 본문 → IR Deck PDF → From 헤더
**참고**: 현재는 From 헤더 우선 → IR Deck PDF 순서로 되어 있음 (최근 수정됨)
---
## 참고 문서
- `journey/troubleshooting/251014_coldmail_ir_analysis_scenario.md`: 콜드메일 처리 시나리오
- `journey/troubleshooting/251206_ir_deck_system_current_status.md`: IR Deck 시스템 현황
- `book/300_architecture/312_문서_작성_원칙.md`: 문서 작성 원칙

90
journey/plans/251217_bayesian_seminar_presentation_plan.md
View File

@ -1,90 +0,0 @@
# 베이지안 세미나 발표 계획
**작성일**: 2025-12-17
**발표자**: 김종태
**참가자**: 강일신, 곽서현, 김하영, 홍태주, 문유리, 문정현, 김종태 (7명)
**발표 시간**: 30분
**페이지 수**: 8페이지 (타이틀 포함, 인터랙티브 섹션 포함)
## 발표 목적
베이지안 업데이트를 체험으로 학습하고, 이를 스타트업 평가에 적용하는 과정을 보여주며 로빙을 소개
## 발표 구조
### 1. 퀴즈 섹션 (페이지 2, 인터랙티브 단일 페이지)
- 자루 속 흰공/검은공 비율 추정
- 섹션 1: 7명이 각자 초기 확률 입력
- 섹션 2: 공을 하나씩 꺼내며 베이지안 업데이트 (5회, 동적 표시)
- 섹션 3: 실제 비율 공개
- 섹션별 표시/숨김 처리로 하나의 페이지에서 진행
### 2. 스타트업 IR 평가 섹션 (페이지 3, 인터랙티브 단일 페이지)
- 섹션 1: 실제 IR Deck 선택
- 섹션 2: 단계별 정보 공개 (대표자 프로필, 사업 규모, BM, 시장 규모, 매출액)
- 각 정보 공개 후 7명이 성공 확률 업데이트
- 섹션 3: 최종 평가 비교
- 실시간 확률 분포 그래프
- 섹션별 표시/숨김 처리로 하나의 페이지에서 진행
### 3. 로빙 소개 및 마무리 (페이지 4-7)
- 페이지 4: 로빙이 이렇게 평가합니다
- 페이지 5: 로빙의 평가 과정
- 페이지 6: Slack Lists 자동 등록
- 페이지 7: 마무리
## 디자인 요구사항
### 타이틀 페이지 (페이지 0)
- **색상**: 보라색(#5C00E6) 배경 + 흰색 텍스트 (company-x.partners 스타일 참조)
- **타이포그래피**: 큰 타이포그래피로 제목 강조 ("Expert. Execute. Explore." 스타일)
- **레이아웃**: 여백을 충분히 활용한 미니멀 디자인
- **요소**:
- 제목: "스타트업을 어떻게 평가할까? - 베이지안 투자 판단과 로빙 v0.2.0"
- 하단 문구: "7명이 함께하는 인터랙티브 세미나"
- 로빙 아이콘/로고 (흰색 또는 파란색 포인트)
- "시작하기" 버튼 또는 자동 전환
### 전체 디자인 통일성
- 메인 컬러: 보라색(#5C00E6) - company-x.partners 스타일 참조
- 텍스트: 흰색 (보라색 배경 시) / 검은색 (흰색 배경 시)
- 로빙 브랜드 포인트: 파란색 계열 (간단히 언급)
## 화면 구성 요구사항
### 디스플레이 환경
- 모니터 스크린: 1920x1080 기준 (일반적인 발표 환경)
- 브라우저: Chrome (크롬)
- 전체 레이아웃: 상단 제목 영역(10%), 중앙 콘텐츠 영역(80%), 하단 버튼 영역(10%)
### 인터랙티브 요소
- 섹션별 표시/숨김 처리 (단일 페이지 내에서 상태 관리)
- 실시간 그래프 업데이트 (Chart.js 또는 Recharts)
- 애니메이션 효과 (공 꺼내기, 섹션 전환)
- 입력 필드 실시간 검증 및 피드백
## 기술 요구사항
- 반응형 인터랙티브 웹페이지 (프론트엔드 + 백엔드)
- 실시간 그래프 (Chart.js 또는 Recharts)
- 베이지안 계산 로직
- 상태 관리 (섹션 표시/숨김, 입력 데이터)
- 7명 입력 필드 및 결과 저장
## 구현 예정
- 프론트엔드: React + TypeScript + TailwindCSS
- 백엔드: FastAPI
- 엔드포인트: 참가자 등록, 공 꺼내기, IR 정보 업데이트, 결과 조회
## 구현 완료 (2025-12-17)
### BallQuiz 페이지 베이지안 업데이트 로직
- **누적 odds 변환**: 각 회차마다 입력한 확률(%)을 odds로 변환하여 이전 alpha, beta에 누적
- 초기 50% → alpha=1, beta=1 → 1회차 60% → alpha=2.5, beta=2 → 2회차 65% → alpha=4.36, beta=3
- 5회차까지 진행 시 alpha + beta > 10
- **그래프 색상 점진적 변화**: 초기 연보라에서 5회차 진한 보라로 점진적 변화
- **5회차 피크 값 표시**: Beta 분포 피크 공식으로 계산하여 그래프 하단에 표시
- **종합 행 회차별 값 표시**: 각 회차별 참가자들의 평균 확률 계산하여 확률(%)과 odds(x:1) 형식으로 표시
- **상세 내용**: `journey/troubleshooting/251216_bayesian_presentation_ballquiz_redesign.md` 참조

75
journey/plans/251223_짧은_후속_질문_LLM_우선_해결_계획.md
View File

@ -1,75 +0,0 @@
# 짧은 후속 질문 LLM 우선 해결 계획
**작성일**: 2025-12-23
**목표**: 실패하는 질문 18개를 LLM 우선 접근 원칙으로 해결
**원칙**: `311_FastAPI_구조_원칙.md` 섹션 13 참고
**테스트 결과**: `rb8001/tests/test_failed_questions_results.md`
---
## 문제
**실패한 질문 18개** (총 23개 중 78%):
- 짧은 후속: "어디서?", "언제?", "누구랑?", "뭐야?"
- 맥락 의존: "그거 어떻게 됐어?", "결과는?", "그럼 어떻게 할까?"
- 모호한: "어떻게 생각해?", "괜찮아?"
- 부정/거부: "안 해도 돼", "취소해줘", "보내지 마"
- 비교/선택: "어느 게 나아?", "A와 B 중에 뭐가 좋아?"
- 시간 모호: "언제 했어?"
- 상태 확인: "지금 뭐 하고 있어?", "작업 끝났어?"
- 정보 요청: "너는 뭘 할 수 있어?"
**현재 문제**: CONTEXT_FOLLOWUP Intent 구현되어 있으나 패턴 매칭 미작동, 규칙 기반 접근으로 정확도 저하
---
## 아키텍처
### 워크플로우
```
사용자 질문
↓
FastPath (명확한 케이스만) → 성공 시 즉시 처리
↓ 실패
짧은 질문 감지 (len <= 10 또는 확신도 < 0.7)
↓
LLM 질문 확장 (맥락 포함)
↓
LLM 의도 분류 (맥락 포함)
↓
LangGraph 워크플로우 (엔티티 추출 → 스킬 선택)
↓
스킬 실행
```
### 필요 작업
1. ✅ LLM 질문 확장 기능 추가 (완료)
2. ✅ LLM 의도 분류 맥락 포함 강화 (완료)
3. ✅ LangGraph 기반 워크플로우 구현 (완료, 기본 활성화)
4. ✅ 세션 맥락 LLM 전달 (완료)
---
## 구현 단계
| Phase | 작업 | 상태 |
|-------|------|------|
| 1 | LLM 질문 확장 구현 | ✅ 완료 → `troubleshooting/251223_짧은_후속_질문_LLM_Phase1234_구현.md` |
| 2 | LLM 의도 분류 강화 | ✅ 완료 → `troubleshooting/251223_짧은_후속_질문_LLM_Phase1234_구현.md` |
| 3 | LangGraph 워크플로우 | ✅ 완료 → `troubleshooting/251223_짧은_후속_질문_LLM_Phase1234_구현.md` |
| 4 | 세션 맥락 통합 | ✅ 완료 → `troubleshooting/251223_짧은_후속_질문_LLM_Phase1234_구현.md` |
---
## 목표
- 실패한 질문 18개 → 3개 이하 (78% → 13%)
- 짧은 후속 질문 정확도: 30% → 90% 이상
- 맥락 의존 질문 정확도: 30% → 85% 이상
---
## 참고
- `311_FastAPI_구조_원칙.md` (섹션 13: LLM 우선 접근 원칙)
- `context_followup_question_solutions.md` (연구 문서)

177
journey/plans/251225_admin_dashboard_code_refactoring.md
View File

@ -1,177 +0,0 @@
# Admin Dashboard 코드 리팩토링 계획
**날짜**: 2025-12-25
**목표**: Monolithic 코드 분리 및 계층 구조 개선
**원칙**: 311_FastAPI_구조_원칙.md, 313_React_구조_원칙.md
---
## 현재 상태
### Frontend 문제점
- `app.js`: 1360줄 (1000줄 이상 - Monolithic Component)
- UI + API + State + Events 모두 혼재
- React 원칙 위반: 300줄 이상 분리 검토 필요, 1000줄 이상 리팩토링 필수
### Backend 문제점
- `admin_routes.py`: 1053줄 (300줄 초과)
- FastAPI 원칙 위반: router 파일은 300줄 이하 권장
- `routers/users.py`, `routers/robeings.py`는 이미 분리됨
---
## 리팩토링 계획
### 1. Frontend 구조 개선
**현재**: `app.js` 1360줄 (모든 로직 혼재)
**목표 구조**:
```
frontend/
├── app.js # 메인 로직만 (~200줄)
├── services/
│ └── api.js # API 통신 로직
├── utils/
│ └── helpers.js # 유틸리티 함수 (markdownToHtml, showError 등)
└── modules/
├── dashboard.js # 대시보드 데이터 로딩
├── system.js # 시스템 모니터링 (loadSystemOverview, loadServiceStatus 등)
├── containers.js # 컨테이너 관리
├── users.js # 사용자/팀 관리
├── robeings.js # 로빙 관리
└── diary.js # 일기 관리
```
**분리 기준**:
- API 통신: `services/api.js` (apiCall, fetch 로직)
- 유틸리티: `utils/helpers.js` (markdownToHtml, showError, showLoadingBar 등)
- 기능별 모듈: `modules/*.js` (각 기능별 데이터 로딩 함수)
- 메인 로직: `app.js` (초기화, 네비게이션, 이벤트 핸들링)
**원칙 준수**:
- 각 파일 300줄 이하
- UI 렌더링과 비즈니스 로직 분리
- API 통신 로직 분리
### 2. Backend 구조 개선
**현재**: `admin_routes.py` 1053줄 (시스템 관련 엔드포인트 포함)
**목표 구조**:
```
backend/
├── routers/
│ ├── system.py # 시스템 모니터링 (~300줄)
│ ├── users.py # 사용자/팀 관리 (이미 분리됨)
│ └── robeings.py # 로빙 관리 (이미 분리됨)
├── services/
│ ├── system_service.py # 시스템 비즈니스 로직
│ ├── user_service.py # 사용자 비즈니스 로직 (이미 존재)
│ └── robeing_service.py # 로빙 비즈니스 로직 (이미 존재)
└── admin_routes.py # 라우터 등록만 (main.py에서 사용)
```
**분리 기준**:
- `admin_routes.py`의 시스템 관련 엔드포인트를 `routers/system.py`로 이동
- 시스템 비즈니스 로직은 `services/system_service.py`로 분리
- `admin_routes.py`는 라우터 등록만 담당 (또는 제거하고 main.py에서 직접 등록)
**원칙 준수**:
- router → service → repository 계층 분리
- 각 파일 300줄 이하
---
## 구현 단계 (TDD)
### Phase 1: Red - 테스트 작성
1. Frontend 기능 테스트 작성
- 각 모듈별 함수 동작 확인
- API 호출 정상 동작 확인
- UI 업데이트 정상 동작 확인
2. Backend 기능 테스트 작성
- 시스템 엔드포인트 동작 확인
- 기존 엔드포인트와 동일한 응답 구조 확인
### Phase 2: Green - 리팩토링 구현
1. Frontend 모듈 분리
- `services/api.js` 생성
- `utils/helpers.js` 생성
- `modules/*.js` 생성
- `app.js` 리팩토링
2. Backend 라우터 분리
- `routers/system.py` 생성
- `services/system_service.py` 생성
- `admin_routes.py` 리팩토링 또는 제거
### Phase 3: Refactor - 코드 개선
1. 중복 코드 제거
2. 네이밍 개선
3. 에러 처리 개선
---
## 완료 상태
### Phase 1: Red - 테스트 작성 ✅
- [x] Backend 기능 테스트 작성 (`tests/test_backend_refactoring.py`)
- [x] 시스템 엔드포인트 동작 확인
- [x] 기존 엔드포인트와 동일한 응답 구조 확인
- [x] 모든 테스트 통과 (8 passed)
### Phase 2: Green - 리팩토링 구현 ✅
- [x] Frontend 모듈 분리
- [x] `services/api.js` 생성 (API 통신 로직)
- [x] `utils/helpers.js` 생성 (유틸리티 함수)
- [x] `modules/diary.js` 생성 (일기 관리)
- [x] `app.js` 리팩토링 (1360줄 → 1132줄)
- [x] Backend 라우터 분리
- [x] `routers/system.py` 생성 (시스템 모니터링)
- [x] `services/system_service.py` 생성 (비즈니스 로직)
- [x] `routers/admin_static.py` 생성 (정적 파일 서빙)
- [x] `admin_routes.py` 리팩토링 (1053줄 → 96줄, 인증만 남김)
### Phase 3: Refactor - 코드 개선 ✅
- [x] 중복 코드 제거
- [x] 네이밍 개선
- [x] 에러 처리 개선
- [x] FastAPI 구조 원칙 준수 (main.py는 라우터 등록만)
- [x] 테스트 수정 및 검증 완료
## 배포 및 설정 변경
### Nginx 설정 변경 ✅
- `/admin/` 전체를 FastAPI(8000)로 프록시하도록 변경
- FastAPI에서 정적 파일과 API 모두 처리
- `routers/admin_static.py`에서 정적 파일 서빙 처리
### 해결된 이슈
- ✅ 일기 API 경로 매칭: `/diary/list`를 `/diaries`로 변경하여 경로 충돌 방지
- ✅ FastAPI 경로 매칭 순서: 라우터 등록 순서 명시 (API 경로 우선, 정적 파일 마지막)
- ✅ 정적 파일 서빙: `main.py`에서 분리하여 `routers/admin_static.py`로 이동 (원칙 준수)
## 결과
### 파일 크기 개선
- `app.js`: 1360줄 → 1132줄 (228줄 감소)
- `admin_routes.py`: 1053줄 → 96줄 (957줄 감소)
### 구조 개선
- Frontend: 모듈화 완료 (services, utils, modules 분리)
- Backend: 계층 분리 완료 (router → service)
- 원칙 준수: FastAPI 구조 원칙, React 구조 원칙 준수
### 테스트
- 모든 테스트 통과 (8 passed)
- 엔드포인트 존재 확인 완료
- 경로 변경 검증 완료
## 참고
- `311_FastAPI_구조_원칙.md`
- `313_React_구조_원칙.md`
- `troubleshooting/251204_admin_dashboard_business_integration.md`

34
journey/plans/archive/251206_skill_calendar_자동배포_구성.md Normal file
View File

@ -0,0 +1,34 @@
# skill-calendar 51124 서버 자동 배포 구성
**날짜**: 2025-12-06
**작성자**: admin
**상태**: 구현 완료
---
## 목표
skill-calendar 서비스를 Gitea Actions를 통해 51124 서버에 자동 배포하도록 구성
## 구현 완료
→ 상세: `troubleshooting/251225_skill_calendar_자동배포_구성.md`
## 아키텍처
### 서버 관계
- **51123 서버**: Gitea Actions runner (self-hosted)
- **51124 서버**: 배포 대상 서버 (192.168.219.52, SSH 포트 51124)
- **배포 플로우**: 51123 runner → SSH(51124) → git pull → docker 재시작
### 필수 Secrets
- `SSH_PRIVATE_KEY_51124`: 51124 서버 SSH 키
- `SSH_HOST_51124`: 192.168.219.52
- `SSH_USER_51124`: admin
## 참고 문서
- `troubleshooting/251225_skill_calendar_자동배포_구성.md`: 구현 완료 기록
- `troubleshooting/250728_happybell80_nginx프록시및CI배포문제해결.md`: SSH 인증 실패 해결
- `book/300_architecture/312_문서_작성_원칙.md`: 문서 작성 원칙

33
journey/plans/archive/251217_bayesian_seminar_presentation_plan.md Normal file
View File

@ -0,0 +1,33 @@
# 베이지안 세미나 발표 계획
**작성일**: 2025-12-17
**상태**: 구현 완료
---
## 목표
베이지안 업데이트를 체험으로 학습하고, 이를 스타트업 평가에 적용하는 과정을 보여주며 로빙을 소개
## 구현 완료
→ 상세: `troubleshooting/251216_bayesian_presentation_ballquiz_redesign.md`
## 발표 구조
### 1. 퀴즈 섹션
- 자루 속 흰공/검은공 비율 추정
- 7명이 각자 초기 확률 입력
- 공을 하나씩 꺼내며 베이지안 업데이트 (5회)
### 2. 스타트업 IR 평가 섹션
- 실제 IR Deck 선택
- 단계별 정보 공개 후 성공 확률 업데이트
- 실시간 확률 분포 그래프
### 3. 로빙 소개 및 마무리
## 참고
- `troubleshooting/251216_bayesian_presentation_ballquiz_redesign.md`: 구현 완료 기록 (BallQuiz 페이지 베이지안 업데이트 로직)

43
journey/plans/archive/251223_짧은_후속_질문_LLM_우선_해결_계획.md
View File

@ -1,27 +1,17 @@
# 짧은 후속 질문 LLM 우선 해결 계획 # 짧은 후속 질문 LLM 우선 해결 계획
**작성일**: 2025-12-23 **작성일**: 2025-12-23
**목표**: 실패하는 질문 18개를 LLM 우선 접근 원칙으로 해결 **상태**: 구현 완료
**원칙**: `311_FastAPI_구조_원칙.md` 섹션 13 참고
**테스트 결과**: `rb8001/tests/test_failed_questions_results.md`
--- ---
## 문제 ## 목표
**실패한 질문 18개** (총 23개 중 78%): 실패하는 질문 18개를 LLM 우선 접근 원칙으로 해결
- 짧은 후속: "어디서?", "언제?", "누구랑?", "뭐야?"
- 맥락 의존: "그거 어떻게 됐어?", "결과는?", "그럼 어떻게 할까?"
- 모호한: "어떻게 생각해?", "괜찮아?"
- 부정/거부: "안 해도 돼", "취소해줘", "보내지 마"
- 비교/선택: "어느 게 나아?", "A와 B 중에 뭐가 좋아?"
- 시간 모호: "언제 했어?"
- 상태 확인: "지금 뭐 하고 있어?", "작업 끝났어?"
- 정보 요청: "너는 뭘 할 수 있어?"
**현재 문제**: CONTEXT_FOLLOWUP Intent 구현되어 있으나 패턴 매칭 미작동, 규칙 기반 접근으로 정확도 저하 ## 구현 완료
--- → 상세: `troubleshooting/251223_짧은_후속_질문_LLM_Phase1234_구현.md`
## 아키텍처 ## 아키텍처
@ -42,34 +32,13 @@ LangGraph 워크플로우 (엔티티 추출 → 스킬 선택)
스킬 실행 스킬 실행
``` ```
### 필요 작업
1. ✅ LLM 질문 확장 기능 추가 (완료)
2. ✅ LLM 의도 분류 맥락 포함 강화 (완료)
3. ✅ LangGraph 기반 워크플로우 구현 (완료, 기본 활성화)
4. ✅ 세션 맥락 LLM 전달 (완료)
---
## 구현 단계
| Phase | 작업 | 상태 |
|-------|------|------|
| 1 | LLM 질문 확장 구현 | ✅ 완료 → `troubleshooting/251223_짧은_후속_질문_LLM_Phase1234_구현.md` |
| 2 | LLM 의도 분류 강화 | ✅ 완료 → `troubleshooting/251223_짧은_후속_질문_LLM_Phase1234_구현.md` |
| 3 | LangGraph 워크플로우 | ✅ 완료 → `troubleshooting/251223_짧은_후속_질문_LLM_Phase1234_구현.md` |
| 4 | 세션 맥락 통합 | ✅ 완료 → `troubleshooting/251223_짧은_후속_질문_LLM_Phase1234_구현.md` |
---
## 목표 ## 목표
- 실패한 질문 18개 → 3개 이하 (78% → 13%) - 실패한 질문 18개 → 3개 이하 (78% → 13%)
- 짧은 후속 질문 정확도: 30% → 90% 이상 - 짧은 후속 질문 정확도: 30% → 90% 이상
- 맥락 의존 질문 정확도: 30% → 85% 이상 - 맥락 의존 질문 정확도: 30% → 85% 이상
---
## 참고 ## 참고
- `troubleshooting/251223_짧은_후속_질문_LLM_Phase1234_구현.md`: 구현 완료 기록
- `311_FastAPI_구조_원칙.md` (섹션 13: LLM 우선 접근 원칙) - `311_FastAPI_구조_원칙.md` (섹션 13: LLM 우선 접근 원칙)
- `context_followup_question_solutions.md` (연구 문서)

32
journey/plans/archive/251225_admin_dashboard_code_refactoring.md Normal file
View File

@ -0,0 +1,32 @@
# Admin Dashboard 코드 리팩토링 계획
**날짜**: 2025-12-25
**상태**: 구현 완료
---
## 목표
Monolithic 코드 분리 및 계층 구조 개선
## 구현 완료
→ 상세: `troubleshooting/251117_admin_dashboard_code_refactoring_loading_optimization.md`
## 결과
### 파일 크기 개선
- `app.js`: 1360줄 → 1132줄 (228줄 감소)
- `admin_routes.py`: 1053줄 → 96줄 (957줄 감소)
### 구조 개선
- Frontend: 모듈화 완료 (services, utils, modules 분리)
- Backend: 계층 분리 완료 (router → service)
- 원칙 준수: FastAPI 구조 원칙, React 구조 원칙 준수
## 참고
- `troubleshooting/251117_admin_dashboard_code_refactoring_loading_optimization.md`: 구현 완료 기록
- `311_FastAPI_구조_원칙.md`
- `313_React_구조_원칙.md`

44
journey/troubleshooting/251225_skill_calendar_자동배포_구성.md Normal file
View File

@ -0,0 +1,44 @@
# skill-calendar 자동 배포 구성
**날짜**: 2025-12-25
**작성자**: Auto
**관련 파일**: `skill-calendar/.gitea/workflows/deploy.yml`
---
## 목표
skill-calendar 서비스를 Gitea Actions를 통해 51124 서버에 자동 배포하도록 구성
## 해결
### 워크플로우 파일 생성
- `skill-calendar/.gitea/workflows/deploy.yml` 생성
- skill-rag-file 워크플로우 참고하여 skill-calendar에 맞게 수정
- 포트: 8512, 헬스체크: `/health`, 컨테이너명: `skill-calendar`
### 배포 스크립트
- SSH 연결 설정 (포트 51124)
- Git pull (`git pull origin main --rebase`)
- .env 파일 확인
- Docker 빌드 및 재시작 (`docker compose build --no-cache` → `docker compose up -d`)
- 헬스체크 (최대 10회, 5초 간격)
### 정리
- 기존 `.github/workflows/deploy.yml` 삭제 (Gitea Actions는 `.gitea/workflows/`만 인식)
## 구현 완료
- 커밋: `7ab505c` (워크플로우 추가), `592e728` (.github/workflows 삭제)
- 배포 테스트: 정상 작동 확인
## 교훈
- **Gitea Actions 경로**: `.github/workflows/`가 아닌 `.gitea/workflows/` 경로 사용 필수
- **기존 패턴 재사용**: 다른 스킬(skill-rag-file 등)의 워크플로우를 참고하여 빠르게 구현 가능
- **불필요한 파일 정리**: 사용하지 않는 `.github/workflows/` 파일은 즉시 삭제하여 혼란 방지
## 참고
- `skill-rag-file/.gitea/workflows/deploy.yml`: 참고한 워크플로우 파일