(데이터 관리 1) 트레이딩에서 데이터 관리의 중요성과 난관

이 글은 매매 시스템 시리즈의 데이터 관리 첫 번째 글입니다.

이번 섹션에서는 매매 시스템의 데이터 관리에 대해 이야기해 보겠습니다. 시세·체결·주문 데이터를 어떻게 수신하고, 저장하고, 읽어 오는지, 그리고 지금까지 겪어 온 좌충우돌 경험담을 다룹니다.

데이터분석 섹션에서는 피쳐를 만들고 데이터를 정규화하는 작업을 소개합니다. 그러나 이러한 작업도 잘 정제된 데이터가 갖춰져 있어야 가능합니다. 데이터 관리는 트레이딩의 시작이라고 봅니다 (사견입니다).

---

알고리즘 트레이딩 전략은 크게 두 가지로 나뉘는 것 같습니다. 하이퍼파라미터 의존성이 큰 전략과 작은 전략이지요. 의존성이 작은 전략의 대표적인 예는 수급 위주로 보는 전략입니다. KRX라면 외국인 수급을 간접적·선행적으로 잡아내는 피쳐를 찾아낸다거나, 크립토 마켓이라면 Open Interest가 증가하는 가격대에서 청산 레벨을 찾아 공략하는 식이지요. 이런 전략들의 공통점은 참여자가 적다는 점입니다. 그래서 “하이퍼파라미터 의존성이 낮다”기보다 “유효한 파라미터의 범위가 넓다”는 쪽이 더 정확한 표현일 수 있겠습니다.

다른 한쪽은 일반적인 시장 미시구조 지표들의 부대찌개입니다. 베이시스, OFI, 체결강도 같은 것들이지요. 그런데 이쪽으로 가면 생각보다 특별한 무언가가 없습니다. 공개될 만큼 공개되어 있고, 어떻게 보면 가내수공업의 영역이지요. 정규화를 어떤 시간축으로 할지, 라벨링은 무엇을 쓸지 같은 디테일을 손으로 만져 가는 일입니다. 새로운 피쳐를 찾거나 피쳐 엔지니어링으로 피쳐군을 넓히는 작업에도 한계가 있습니다.

그러면 어떻게 해야 다른 사람들보다 정보 우위를 점할 수 있을까요? 좋은 데이터를 가지고 있으면 됩니다. 좋은 데이터에서 나온 피쳐는 더 나은 품질을 보장하고, 그 자체로 새로운 피쳐가 될 수 있습니다.

가능한 데이터는 옹골차게

조금 더 구체적으로 말씀드리면, 데이터에 가능한 한 빈틈이 없어야 합니다.

인포맥스, 체크, 블룸버그 같은 벤더는 거래소 데이터를 틱 단위(매 이벤트 단위)로 제공하지 않습니다. 보통 체결이나 최우선 호가 정도가 한계입니다. 거래소에서 직접 받을 수 있다면 이야기가 달라집니다. KRX 파생은 10호가까지 틱 단위로 내려오지요. 반면 벤더를 한 번 거치는 순간 그쪽의 지연 시간이 그대로 얹어지는데, 이 지연은 내가 타겟하는 라벨과의 시간 거리에도 그대로 더해집니다. 크립토 마켓도 베뉴마다 차이는 있지만 delta 기준 100ms 정도면 사실상 풀 레벨 스냅샷을 손에 쥘 수 있습니다.

어떤 시장의 데이터를 손에 쥐는지도 중요합니다. 일반적으로 거래가 많은 시장이 적은 시장을 리드합니다. 크립토라면 perpetual이 spot을 리드하고, 채권이라면 선물이 현물을 리드합니다. 다시 말해 전자가 후자의 피쳐가 된다는 뜻이지요. 이 두 경우는 다행히 데이터 제공처가 동일합니다. 크립토는 같은 베뉴에서 perpetual과 spot 데이터를 함께 주고, KRX는 선물과 현물 데이터를 같이 제공합니다.

그런데 달러(USDKRW) 시장은 사정이 다릅니다. 현물 시장이 선물 시장보다 10배 정도 큽니다. 당연히 현물 데이터를 가진 쪽이 유리하겠지요. 선물 시장은 KRX에 있는데, 현물 시장은 어디에 있을까요? 짜잔, 장외 시장에서 주로 거래됩니다. 일반인은 접근이 쉽지 않은 영역이고, 데이터는 SMB(서울외국환중개)에서 FIX로 제공합니다. 당연히 비용이 들지만, 그 비용을 쓰고도 돈을 벌 수 있다면 그것 또한 하나의 전략입니다.

수신 방식에도 여러 선택지가 있습니다. SMB와 데이터 계약을 맺은 뒤 인터넷으로 받을 것인지, 통신사로부터 전용선을 임차해(이것도 비용이지요) 더 빠르게 받을 것인지에 따라 도착 시간이 달라집니다. 크립토 마켓은 마켓 메이커나 VIP 등급에 따라 데이터 제공 쿼터 자체가 다르게 책정되는 곳도 있습니다. 예를 들어 OKX는 VIP 5 이상부터 체결률(fill ratio) 기반으로 레이트 리밋을 확장해 주고, Bybit은 별도의 마켓 메이커 프로그램을 통해 더 높은 한도와 저지연 연결을 제공합니다.

지금까지는 데이터 그 자체의 중요성에 대해 이야기했습니다. 이제부터 이 시리즈에서 주로 다룰 내용은 데이터를 어떻게 관리할 것인가입니다.

데이터 관리도 정말 중요하다

데이터를 어떻게 관리하느냐도 못지않게 중요합니다. 앞서 알고리즘 트레이딩 전략의 한 축이 가내수공업으로 흘러간다고 말씀드렸습니다. 다시 말해 데이터를 가지고 지지고 볶을 일이 많다는 뜻이지요. 데이터를 다루는 부분이 병목이 되면 알고리즘 트레이더로서의 인생이 괴로워집니다. 한번 안 좋은 예를 들어 보겠습니다.

KRX 패킷을 압축 없이 그대로 받으면 하루에 100GB 정도 됩니다. 패킷 사이 시간 간격은 평균적으로 200μs 정도이고, 하루에 패킷이 1억 개가량 들어옵니다. payload 길이는 대략 500바이트 정도로 생각하시면 됩니다. 어떤 트레이더가 이걸 한 달 정도 MongoDB에 저장했다고 가정해 봅시다. zstd 압축을 적용해도 하루 20GB, 영업일 20일을 곱하면 400GB가 쌓입니다. 일단 벌써부터 빡빡하지요.

이제 데이터 분석을 해보려고 합니다. 자산 A, B의 호가·체결 payload를 전부 읽어서 EDA(Exploratory Data Analysis)를 돌립니다. 그런데 문제가 생깁니다. 데이터를 읽는 데 반나절이 걸리거든요. 대참사입니다. EDA는 데이터를 읽는 작업을 수백 번 반복해야 하는데 말이지요. 경험담입니다. 처참하지요. 독자분께서는 이런 고통을 덜 겪으시길 바라며, 앞으로 이어지는 글에서는 저의 좌충우돌 경험담과 함께 데이터베이스의 종류, parquet 파일, rclone으로 S3 만들기 등에 대해 이야기 나눠 보겠습니다.