자동매매 백테스트 환경 구축
백테스트 대시보드대학에서 통계를 배울 때, 우연히 자동매매에 관심이 생긴 적이 있었다. 때마침 학과 공부 때문에 C언어와 파이썬을 다룰 일이 있어서 겸사겸사 파이썬으로 자동매매를 구축해본 경험이 있었다. 수치해석이나 물리현상 시뮬레이션 코딩 정도가 전부였던 비전공자(그냥 물리학도)였던 내가 DB가 뭔지도 모른채 mysql을 설치하고 거기에 틱데이터를 모으며 백테스트를 하고, bybit가 제공해주는 api문서(지금은 친절해진)를 보고 인터넷을 뒤져가며 자동매매를 실행해본 추억이 떠오른다.
어찌저찌 프론트엔드 개발자로 개발을 시작했고 어쩌다보니 도커, 백엔드, DB 등 이것저것 경험해 볼 기회가 있어서 그 간의 경험을 바탕으로 예전에 미완성으로 남은 나의 숙원사업을 추억하며 개인 프로젝트로 자동매매 시스템을 만들어 보기로 했다.
프로젝트 구조
Bybit의 BTCUSDT 틱데이터는 25년 1월 기준 약 700만건, 500Mb 정도 규모이다. 틱데이터로 1년 백테스트 구상 시, 대략 일억건의 거래를 불러와야 하므로 DB구성이 필수로 여겨졌다. 이젠 개발 서버로 전락한 맥미니 M2에서 도커에 mysql 컨테이너를 올렸다. 이를 prisma로 연결하여 next.js에서 사용한다. DB는 Next.js의 서버 사이드에서 접근 가능하며, 클라이언트는 Next.js의 route handler를 통해 데이터에 간접 접근 한다. 지금은 백테스트 프로젝트로서 도커에 DB만 올라가 있지만, 백테스트 결과를 실전 매매로 구현할 때에는 코인 별로 컨테이너를 구성하여 올라갈 예정이다. 데모 확인
Prisma.schema
schema데이터라 할 것은 거래 데이터와 유저 정보가 전부이다. 현재는 유저는 스키마만 존재하고 사용되진 않는다. 나중에 개인 프로젝트로 도커에 올리면 서버 백테스트 진행, 자동매매 현황 확인등의 작업을 위해 권한 작업이 추가 될 예정이다.
데이터 시각화
백테스트를 진행하고 결과를 분석할 때, 어떤 거래가 어디서 어떻게 진행 됐는지 확인하는게 매우 중요하다. 내가 생각하는 아이디어에 사용되는 지표들과 캔들을 나열하고 거래가 어떻게 진행되었는지 시각화 하여 확인 것이 백테스트 아이디어를 구상하는데 매우 중요하다.
bybit 캔들차트를 참고한 캔들차트ECharts 에서 제공하는 candle chart는 바로 사용 가능할 정도로 최적화와 사용성이 좋다. 나름대로 커스텀도 가능해서 좋은 선택지가 될 수 있다. 그럼에도 나만의 맞춤 데이터 시각화를 위해 d3.js를 사용하여 커스텀 캔들차트를 그리기로 했다. 요즘은 AI가 있어서 그리는데 훨씬 수월하다. 1분봉을 기준으로 하루 1,440개 이므로 한달치를 그리는 데에만 4만 개 이상의 캔들이 그려지고 캔들과 함께 지표들도 그려질 것을 생각하면 svg보다는 canvas가 적절하다.
svg는 직관적이고 상호작용에 좋다. DOM 요소에 잘 스며드는 느낌이라 개발하면서도 기분이 좋다. 하지만 1000개 정도의 요소가 한계이다. 실제로 며칠 치 캔들만 그려도 조금씩 버거워 하는게 느껴지는 정도이다. 대신 canvas는 더 많은 데이터 요소에 적당하다. 캔들만 그리면 몇주 치 캔들도 한번에 띄울 수 있다. 자세한건 이어지는 포스트에서 다루도록 한다.
테스트 환경
일단 테스트는 1분봉으로 한다. RSI, VWAP 등의 지표들을 이용해서 매수(매도) 조건을 충족하면 거래가 진행 되는 형식이다. 실제 틱 데이터를 사용하지 않기 때문에 실제 거래와는 차이가 생길 수밖에 없다. 가령, 현재는 고가가 나의 매도가보다 높으면 자연스럽게 매도 되는 것으로 가정하였지만, 실제로는 다를 수 있다. 이런 경우, 작은 거래 규모는 틱데이터 백테스트로 보완 가능하다.
이 프로젝트는 아직 초기 단계로, 각 기능의 완성도나 전체적인 구조에서 개선할 부분이 많다. 기획안 없이 개발을 진행하다 보니 기능을 추가할 때마다 프로젝트의 안정성에 영향을 미치는 경우도 있었다. 그럼에도, 이번 포스팅에서는 현재까지의 프로젝트 구성과 핵심 아이디어를 정리해 봤다. 각 기능에 대한 자세한 구현 방법과 기술적 세부사항은 다음 포스팅에서 순차적으로 다루도록 한다.
