AI Trade Manager는 추천 결과보다 데이터 품질과 주문 경계, 실패 추적, 운영 경고를 우선한 개인 트레이딩 운영 시스템이다.
| Problem | RAG 기반 전망만으로는 실제 운영 신뢰성이 부족했다 |
|---|---|
| Approach | 판단 근거와 데이터 품질, 주문 경계, 장애 대응을 시스템 경계로 분리 |
| Result | 대시보드와 AI 뱅커, 백테스트, 안전장치, 테스트 근거를 하나로 묶음 |
| 항목 | 내용 |
|---|---|
| 역할 | Backend / AI / Ops 설계 및 구현 |
| 핵심 목표 | AI 판단을 운영 환경에서 믿고 추적할 수 있는 구조 |
| 주요 스택 | FastAPI, React/Vite, PostgreSQL, OpenSearch, Upbit, Slack, APScheduler, Gemini/OpenAI |
| 운영 초점 | 주문 멱등성, 전역 kill switch, fail-closed 거래 모드, RAG 품질 경고, provider fallback, portfolio snapshot |
| 문서 위치 | 블로그는 요약 글, Notion은 상세 개발 일지와 구현 근거 |
AI 답변보다 데이터 품질과 주문 경계, 실패 대응이 더 중요했다. 뉴스 품질과 embedding 상태가 답변 신뢰성에 그대로 이어지니 RAG 상태는 화면에 드러내고, 실전 주문은 기능 완성도보다 안전 경계를 먼저 잡아 paper와 live를 나눴다.
운영 리스크는 감으로 관리하지 않고 migration과 test로 추적한다. 2026.07에는 주문 경계를 별도 층으로 뺐는데, 주문을 낼지 말지를 코드 곳곳에서 판단하면 사고가 안 난 이유를 설명할 수 없기 때문이다.
| 리스크 | 대응 |
|---|---|
| 낮은 품질의 뉴스 데이터 | source health, warning, fallback 상태를 화면과 로그에 노출 |
| 실전 주문 오작동 | live BUY lock, entry gate, max buy weight, TP/SL |
| AI provider 실패 | provider router와 fallback으로 응답 경로 분리 |
| 비동기 작업 추적 불가 | SSE activity와 실행 로그로 흐름을 확인 |
| 응답 유실 시 중복 주문 (2026.07) | 주문 의도 원장과 identifier를 먼저 확정, POST는 1회만, 복구는 조회로 |
구현 근거는 각 상세 페이지의 흐름 안에 함께 정리했다.