<aside> 📌 AI Trade Manager는 추천 결과보다 데이터 품질, 주문 경계, 실패 추적, 운영 경고를 우선한 개인 트레이딩 운영 시스템이다.
</aside>
<aside> ⚠️ Problem: RAG 기반 전망만으로는 실제 운영 신뢰성이 부족했다.
</aside>
<aside> 🧭 Approach: 판단 근거, 데이터 품질, 주문 경계, 장애 대응을 시스템 경계로 분리했다.
</aside>
<aside> ✅ Result: 대시보드, AI 뱅커, 백테스트, 안전장치, 테스트 근거를 하나로 묶었다.
</aside>
| 항목 | 내용 |
|---|---|
| 역할 | Backend / AI / Ops 설계 및 구현 |
| 핵심 목표 | AI 판단을 운영 환경에서 믿고 추적할 수 있는 구조 |
| 주요 스택 | FastAPI, React/Vite, PostgreSQL, OpenSearch, Upbit, Slack, APScheduler, Gemini/OpenAI |
| 운영 초점 | RAG 품질 경고, provider fallback, paper/live 분리, live BUY lock, portfolio snapshot |
| 문서 위치 | 블로그는 요약 글, Notion은 상세 개발 일지와 구현 근거 |
| 판단 | 이유 |
|---|---|
| 추천 AI보다 운영 콘솔 | AI 답변보다 데이터 품질, 주문 경계, 실패 대응이 더 중요했음 |
| RAG 상태 노출 | 뉴스/RSS 품질과 embedding 상태가 답변 신뢰성에 직접 영향을 줌 |
| paper/live 분리 | 실전 주문은 기능 완성도보다 안전 경계가 우선 |
| 테스트 근거 분리 | 운영 리스크를 감으로 관리하지 않고 migration/test로 추적 |
| 리스크 | 대응 |
|---|---|
| 낮은 품질의 뉴스 데이터 | source health, warning, fallback 상태를 화면과 로그에 노출 |
| 실전 주문 오작동 | live BUY lock, entry gate, max buy weight, TP/SL 기준 적용 |
| AI provider 실패 | provider router와 fallback 테스트로 응답 경로 분리 |
| 비동기 작업 추적 불가 | SSE activity와 실행 로그로 사용자가 흐름을 확인 |
구현 근거는 각 상세 페이지의 흐름 안에 함께 정리했다.
AI 판단은 주문 요청이 아니라 구조화된 판단 로그다. 분석 단계에서 입력 컨텍스트와 안전 규칙을 묶어 BUY / SELL / HOLD를 생성하고, 주문 실행 단계는 최신 로그와 entry gate를 다시 검사한다.