퀀트봇 운영 구조 - 프로세스 분리, 리포트, 성과 추적

하나의 스크립트가 다 하던 구조를 여러 프로세스로 나누고, 리포트와 성과 추적 방식도 함께 다듬어온 이야기입니다

퀀트봇의 겉으로 보이는 기능(매매 제안, 추천 리포트) 못지않게 신경 쓰는 부분이 있습니다. 이 시스템이 사람이 안 보고 있어도 계속 안정적으로 돌아가는지, 그리고 잘 돌아가고 있다는 걸 어떻게 확인하는지입니다. 오늘은 그 얘기를 정리해봤습니다.

왜 프로세스를 여러 개로 나눴나

처음엔 하나의 스크립트가 계산·감시·리포트를 다 했습니다. 무거운 앙상블 계산과 5분 주기 실시간 감시가 자원을 두고 부딪히는 문제가 있었습니다.

그래서 계산 전용 / 감시 전용 / 리포트 전용으로 나누고, 감시·리포트 쪽은 계산 결과를 디스크 캐시로만 읽게 만들었습니다.

여기에 더해서, 얼마 전 개발 환경이 한 번 죽었을 때 그 프로세스들이 같이 조용히 죽어버린 적이 있었습니다. 그래서 지금은 핵심 프로세스들을 운영체제 서비스로 등록해뒀습니다. 이제 개발 환경을 껐다 켜거나 죽어도 실제 매매/분석 프로세스는 영향을 안 받습니다.

여기서 한 걸음 더 나가서, 원래 텔레그램 봇 하나가 떠안고 있던 매매 관련 백그라운드 작업(미체결 주문 정리, 하루 시작/마감 자산 기록, 안전장치 점검 등)도 별도 프로세스로 떼어냈습니다. 봇은 이제 명령을 받고 처리하는 얇은 창구 역할만 합니다.

비슷한 교훈을 네트워크에서도 얻었습니다. 집 와이파이가 반나절 넘게 반쪽짜리 상태로 방치됐던 사고를 계기로, 네트워크 이상을 감지·복구하는 감시 프로그램을 별도 프로젝트로 만들었습니다. 자세한 이야기는 따로 글로 정리(새 창)했습니다.

리포트도 두 갈래로

정기 모델 리포트는 원래 하루 몇 번씩 정해진 시각마다 전체 종목을 훑어서 이상 급등락을 잡는 리포트가 따로 있었는데, 그 역할은 실시간 감시 쪽으로 옮겼습니다. 정해진 시각을 기다리는 대신, 이상이 생기는 즉시 알아채는 방식이 더 낫다고 판단했습니다.

리포트 자체도 두 갈래로 나눴습니다. 제가 직접 보는 내부용은 시장 상황 판단에 필요한 정보를 다 담고, 혹시 지인에게 보여줄 공유용은 절대 금액 같은 민감한 숫자는 아예 안 나가도록 분리했습니다.

리포트 맨 아래에는 "이 데이터가 얼마나 최신인지" 보여주는 신선도 표시도 붙였습니다. 예전에 데이터가 며칠씩 밀린 채로 조용히 돌아간 적이 몇 번 있어서, 이제는 리포트만 봐도 바로 알아챌 수 있게 했습니다.

추천이 맞았는지는 계속 기록한다

AI가 추천한 대로 했으면 실제로 얼마나 벌었을지 계속 계산해서 기록하고 있습니다. 만들고 나서 "느낌"이 아니라 이 기록을 보면서 기능을 다듬는 걸 원칙으로 하고 있습니다.

최근엔 여기에 더해서 "결정한 시점 가격과 실제 체결 가격의 차이"까지 별도로 재는 계기판도 붙였습니다. 전략 자체의 성과와, 그걸 실행하면서 새는 손실을 구분해서 보기 위해서입니다.

---

화려한 기능은 아니지만, 결국 이런 부분들이 쌓여야 "혼자 돌아가는" 시스템을 믿고 맡길 수 있게 되는 것 같습니다. 전체 프로젝트 구조가 궁금하시면 프로젝트 구조 글(새 창)도 함께 봐주세요.