블로그의 문제와 트러블슈팅 섹션을 실제 구현 근거와 연결한다.
| 케이스 | 운영 리스크 | 관련 상세 문서 |
|---|---|---|
| AI 답변 신뢰성 | 데이터 품질이 낮아도 AI가 자연스러운 답변을 생성 | RAG와 AI Provider 운영 |
| 실전 주문 경계 | 검증되지 않은 AI 판단이 실제 매수로 이어질 수 있음 | 자동매매 안전장치와 장애 대응 |
| 비동기 작업 관측성 | 스케줄러/RAG/provider/reviewer 실패 지점 추적이 어려움 | DB Migration과 테스트 근거 |
| 항목 | 내용 |
|---|---|
| 운영 리스크 | 오래된 뉴스, missing embedding, provider fallback 상황에서도 AI가 자연스러운 답변 생성 |
| 조치 | source health, stale warning, missing embedding warning, provider warning 분리 |
| 처리 방식 | RAG 상태 경고와 provider fallback으로 운영 경고 노출 |
| 검증 관점 | provider fallback과 경고 노출이 작동하는지 확인 |
| 남긴 기준 | AI 답변보다 데이터 품질과 provider 상태를 먼저 노출 |
| 항목 | 내용 |
|---|---|
| 운영 리스크 | AI 판단이 실제 매수로 이어질 수 있음 |
| 조치 | paper/live 분리, live BUY lock, entry gate, TP/SL, max buy weight |
| 처리 방식 | entry gate, shadow mode, paper/live 분리로 신규 주문 위험 차단 |
| 검증 관점 | 자동매매 안전장치와 정책 백테스트 흐름 확인 |
| 남긴 기준 | 실전 BUY는 기본 잠금, 검증되지 않은 판단은 paper/shadow 기록 |
| 항목 | 내용 |
|---|---|
| 운영 리스크 | 스케줄러, RAG ingestion, provider 호출, reviewer 판단이 서로 다른 시점에 실행 |
| 조치 | analysis log, chat session, portfolio snapshot, provider warning, SSE activity UI |
| 처리 방식 | 멀티 에이전트 routing, scheduler, portfolio fallback으로 비동기 운영 흐름 정리 |
| 검증 관점 | 대시보드 fallback과 포트폴리오 briefing 흐름 확인 |
| 남긴 기준 | 최종 응답뿐 아니라 중간 상태와 실패 지점까지 화면과 로그에 남김 |
| 기준 | 설명 |
|---|---|
| 잘못 동작할 때 멈출 수 있어야 한다 | live BUY lock, entry gate, TP/SL |
| 실패 원인을 다시 볼 수 있어야 한다 | logs, warnings, snapshots, sessions |
| AI 답변만 믿지 않는다 | RAG/provider/source health를 함께 노출 |
<aside> 💡 이 문서가 설명하는 것: 운영 트러블슈팅 케이스
</aside>
| 항목 | 내용 |
|---|---|
| 관련 운영 리스크 | 문제 해결이 기능 수정으로만 보이고 운영 기준이 드러나지 않음 |
| 대표 구현 근거 | RAG, safety, observability 상세 문서 |
| 관련 테스트 | provider, executor, dashboard, portfolio tests |
<aside> 🛠️ 트러블슈팅은 내부 파일명이 아니라, 문제를 어떻게 운영 기준으로 고정했는지에 집중했다.
</aside>