Quant Trading Fleet
전략 봇, 브로커 추상화 계층, 실행 데이터, 제어 기능, 로그와 모니터링 대시보드를 연결한 자동매매 검증 시스템을 구축하고 라이브 서버에서 모의투자(paper trading)로 점검하고 있습니다.
기간 · 2025년~현재
역할 · 개인 프로젝트
01 · 비즈니스·연구 질문
무엇을 확인하려 했는가
개별 매매 규칙을 단독 스크립트가 아니라 운영자가 통제하고 관찰할 수 있는 서비스로 전환하려면 어떤 인프라가 필요할까?
02 · 근거와 데이터
어떤 자료를 사용했는가
03 · 분석 과정
어떻게 분석하고 구현했는가
- 01
전략과 broker 로직 분리
거래소별 데이터와 주문 처리 차이를 분리하기 위해 브로커 추상화 계층을 설계했습니다.
- 02
상태와 이력의 가시화
봇 상태, 설정, 실행 이력과 운영 로그를 SQLite에 저장하도록 구성했습니다.
- 03
운영자 제어 기능 구현
FastAPI 서비스와 비동기 봇 제어, React·TypeScript 대시보드를 구현했습니다.
- 04
운영 검증
서비스를 컨테이너화하고 라이브 서버에서 모의투자 기반 운영 검증을 시작했습니다.
04 · 해석
무엇을 알 수 있었는가
자동매매는 전략 개발뿐 아니라 운영 설계의 문제이기도 합니다.
사용 가능한 서비스가 되려면 상태 확인, 로그, 파라미터 관리, 테스트 모드, 복구 절차와 사람의 감독이 필요합니다.
이 프로젝트를 통해 금융 서비스 데이터가 생성·저장·모니터링·관리되는 구조를 구체화했습니다.
05 · 실무적 시사점
어떤 판단에 활용할 수 있는가
전략의 실행 과정을 관찰 가능한 형태로 만들고, 실거래를 고려하기 전에 모의투자 환경에서 체계적으로 검증할 수 있는 운영 기반을 구축했습니다.
06 · 추가 검증
한계와 다음 과제
- •정식 모의투자 검증 보고서를 추가로 작성해야 합니다.
- •가동시간, 주문 실패, 대사, 중복 주문, 재시작과 로그 기준을 명확히 정의해야 합니다.
- •안정적인 시스템으로 표현하기 전 모든 전략과 broker mode를 처음부터 끝까지 검증해야 합니다.
07 · 시각적 근거
확인된 근거와 해석 범위
운영 시스템 구조
원자료 확인전략, 브로커 추상화 계층, 실행 데이터, 제어 API와 모니터링의 연결을 보여줍니다. 구조가 구현되어 있다는 근거이며, 실거래 운영이나 수익률·승률·수익성을 증명하지 않습니다.
근거 · Current FastAPI/React architecture and portfolio codebase
모의투자 운영 검증표
원자료 확인- 라이브 서버 모의투자검증 진행 중
- 봇 상태·설정 제어구현
- 실행 이력·운영 로그구현
- 주문 실패·대사 기준정의 필요
- 중복 주문·재시작 기준정의 필요
- 정식 검증 보고서작성 필요
- Paper-trading 검증 전용 · 실거래 운영 및 수익 성과를 주장하지 않습니다.
현재 구현된 운영 기능과 아직 정의해야 할 검증 기준을 함께 표시합니다. 완료되지 않은 항목을 숨기지 않으며, 어떠한 실거래 성과도 보고하지 않습니다.
근거 · Implemented controls plus documented validation gaps
대시보드·실행 이력 화면
추가 검증 필요공개용 redacted 화면 준비 후 추가
봇 이름·계좌 관련 값·성과 필드를 비식별화하고 모의투자 고지를 화면 안에 포함해야 합니다.
현재 화면에는 모의투자 계좌 잔고와 손익(paper equity·PnL) 필드가 있어 맥락 없이 공개하면 실거래 성과로 오해될 수 있습니다. 민감값을 가리고 모의투자 표기를 유지한 공개용 화면이 준비되기 전에는 placeholder로 둡니다.