왜 “tick 데이터 × 고사양 VPS”인가 #

tick은 “체결이 일어날 때마다”의 최소 단위 기록입니다. 스프레드 안쪽에서 무슨 일이 일어나는지, 급변 시 체결이 어느 쪽으로 쏠리는지—이런 마이크로 구조는 봉으로 뭉치는 순간 사라집니다. 그래서 단기 전략 검증에는 tick이 필요합니다. 그런데 tick은 데이터 양이 자릿수가 다르고, 수집·보관·계산 모든 곳에서 머신의 기초 체력이 시험받습니다. 본 기사는 “받았다고 생각했는데 실은 80%가 누락되어 있던” 실패와 그 수정까지, tick 데이터 수집에서 누구나 밟는 함정을 솔직하게 공유합니다.

무엇을 만들었나(성과물) #

전 공정 소요 시간(실측) #

제로부터 “분석 가능한 완전 2년치 tick 기반 ＋ 최적화 결과”까지, 실질 3시간 남짓입니다.

STEP 1: 데이터 취득 ― 무료 feed와 “두 가지 함정” #

과거 tick은 Dukascopy의 무료 데이터 피드에서 받을 수 있습니다(.bi5 = LZMA 압축 + 20바이트 고정 길이 레코드). 1시간=1파일이며, 순수 Python으로 디코드할 수 있습니다.

# .bi5(LZMA + 20B 고정 길이: ms_offset, ask, bid, ask_vol, bid_vol)를 시간 단위로 병렬 취득
import lzma, urllib.request, numpy as np, concurrent.futures as cf
REC = np.dtype([("t",">u4"),("ask",">u4"),("bid",">u4"),("av",">f4"),("bv",">f4")])
def fetch_hour(sym, y, m, d, h):
    url = f"https://datafeed.dukascopy.com/datafeed/{sym}/{y:04d}/{m-1:02d}/{d:02d}/{h:02d}h_ticks.bi5"
    raw = urllib.request.urlopen(url, timeout=30).read()
    return np.frombuffer(lzma.decompress(raw), dtype=REC)  # 가격 = points/(JPY는 1000, 그 외 100000)

함정①: HTTP 503(레이트 리밋)은 “총량”이 아니라 “버스트”로 발생 #

고속화를 위해 여러 대로 분산시키고 정지→즉시 재시작을 여러 번 반복했더니, IP 주소가 Dukascopy 측에서 일시적으로 503 → 무응답으로 차단되었습니다. 검증의 결론:

• 503의 방아쇠는 “요청 총량”이 아니라 “짧은 시간의 연결 버스트”(＝ 연속된 정지·재시작, 과도한 동시 연결 수).
• 한 번 차단되어도, 요청을 완전히 멈추면 5~10분에 자연 회복됩니다.
• 철칙은 “한 번만·절제된 동시 연결로·멈추지 말고 끝까지 흘려보낸다”. 이번에는 1쌍 24스레드 × 2쌍 병행(=48연결)이 안정대였습니다.

함정②(최중요): “사일런트 드롭” ― 받았다고 생각했는데 80% 누락 #

첫 취득은 겉보기엔 “완주”했지만, 나중에 커버리지를 재 보니 약 22%밖에 없었습니다. 원인은 다운로더가 HTTP 503을 “데이터 없음(404)”과 같은 취급으로 조용히 버리고 있던 것. 차단되지 않았어도 혼잡 시의 소프트한 503이 산발해, 그 시간대가 조용히 누락되고 있었습니다. “데이터가 흐른다 ＝ 완전”이 아닙니다.

🛠 어떻게 잡고, 어떻게 고쳤나(재현 가능한 체크리스트)

1. 완전성은 “흐르고 있나”가 아니라 “커버리지/누락률”로 검증한다. “nonempty 비율”이 거래 시간 예상(≈80%)을 크게 밑돌면 누락을 의심. 이번에는 다운스트림 분석에서 정렬이 극단적으로 야위어진 것(5분봉 패널이 본래 15만 개여야 할 곳이 200개대)으로 드러났습니다.
2. 404와 503을 구별한다. 404=정당한 휴장(재취득하지 않음), 503/타임아웃=재취득 필요. 둘을 동일시한 순간 누락은 비가시화됩니다.
3. 멀티 패스·갭 충전. 각 (일, 시)의 취득 결과를 기록하고, 실패한 시간만을 지수 백오프로 재취득 → 실패 0까지 반복.
4. 커버리지 리포트로 마무리한다. “total / data / 휴장(404) / 미취득”을 반드시 출력하고, 미취득 ≈0과 ticks/년이 예상대로인지 확인한 뒤에 신뢰합니다.

그 결과 커버리지는 22% → ≈100%(각 쌍 미취득 ≤6시간 / 15,048)로. 완전 2년치로 4.06억 tick을 확실히 취득했습니다.

STEP 2: 함정③ 메모리 ― tick 처리는 “RAM 바운드” #

tick 디코드는 대상 범위의 레코드를 한 번 메모리에 펼친 뒤 써냅니다. 즉 필요 RAM은 기간 × 쌍 수에 비례합니다.

검증에서는 RAM 1.9GB의 소형 VPS를 보조로 쓰면 다년 × 복수 쌍에서 즉시 OOM(메모리 부족으로 강제 종료). 반면 OptiMax(251GB RAM)는 완전 2년 × 6쌍을 통째로 메모리에 올려도 여유(분석 시 피크에서도 여유 다수).

tick 데이터 처리는 CPU보다 먼저 RAM이 벽이 됩니다. OptiMax의 대용량 메모리는 바로 이 용도를 위한 것입니다.

STEP 3: 설계의 핵심 ―”다운로드기”와 “계산기”를 나눈다 #

• 다운로드는 회선 품질(Dukascopy로의 경로)이 지배적.
• 분석·최적화는 RAM과 코어 수가 지배적.

서로 다른 머신의 장기이므로 역할을 나눕니다. 이번에는 클린 IP의 취득기 2대로 데이터를 모으고(IP당 레이트 리밋을 2배 회피＝분할의 진짜 효능), OptiMax를 “계산의 모함”으로 삼아 전송·집약·최적화에 전념시켰습니다. 약 1GB의 전송은 불과 51초. 어느 병목에도 끌려가지 않습니다.

STEP 4: 64코어로 “전략을 전수 최적화”한다 #

여기가 OptiMax의 본령입니다. MT5의 스트래티지 테스터 최적화와 같은 발상으로, 1시행=1코어에 할당해 전 코어를 다 씁니다.

포인트는 병렬의 단위. “통화쌍”만으로 병렬하면 6코어밖에 돌지 않습니다. (쌍 × 시그널 × 보유 시간 × 진입 임계값)의 모든 조합을 1시행으로 하면 시행 수가 단숨에 늘어 64코어를 꽉 채울 수 있습니다. 무거운 전처리(1초 그리드)는 한 번만 만들어 공유합니다.

# 무거운 전처리(1초 그리드)는 1회만 → fork pool로 공유(copy-on-write) → 모든 조합을 전수
import multiprocessing as mp
GRIDS = {p: build_grid(p) for p in PAIRS}            # 부모 프로세스에서 한 번만 구축(COW로 자식에 공유)
tasks = [(p,sig,H,thr) for p in PAIRS for sig in SIGNALS for H in HORIZONS for thr in THRESHOLDS]
with mp.Pool(64) as pool:
    results = pool.map(eval_combo, tasks)            # 각 combo = walk-forward + 비용 고려 + 부트스트랩 CI

실측: 1.41억 개의 1초봉 위에서 2,430가지를 약 60코어 점유·581초(그리드 구축 111s ＋ 스윕 470s)로 완주. 각 시행은 walk-forward(시계열 학습→검증 분할) ＋ 왕복 스프레드를 뺀 비용 고려 PnL ＋ 블록 부트스트랩 신뢰 구간까지 포함한 본격 검증입니다.

“백테스트라서 전 코어를 못 쓴다”는 오해입니다. 병렬의 단위를 “파라미터 조합”으로 잡으면 최적화는 코어 수만큼 순순히 빨라집니다. OptiMax의 64코어는 여기서 문자 그대로 풀 가동합니다.

결과(범용적인 배움) #

완전 2년·4.06억 tick·2,430 최적화 시행에서의 정량 결과:

• 시그널 자체는 “존재”한다: 비용 무시(GROSS) 샤프 지수는 최대 +429. 단기 가격 움직임에는 분명히 구조가 있습니다.
• 그러나 테이커(시장가)로는 못 가져간다: 왕복 스프레드를 빼면 2,430가지 중 어느 하나도 플러스가 되지 않습니다(NET>0이 0/2,430). 게다가 각 시행의 95% 신뢰 구간 상한조차 0/2,430이 플러스＝통계적으로도 “플러스가 될 수 있는” 조합이 제로(데이터를 완전화하니 노이즈에서 비롯된 “요행 양성”도 소멸).
• 이는 시장 마이크로 구조의 교과서적 결과(단기 엣지는 bid-ask 스프레드 안쪽에 들어가, 스프레드를 내는 쪽＝테이커는 회수할 수 없다)를, 대규모·완전 데이터로 엄밀히 재확인한 것입니다.

실무적 함의: 단기 엣지 연구는 “비용을 뺀 뒤”에만 의미가 있다. 그리고 그 대규모 검증을 현실적인 시간에 돌리려면 완전한 데이터·RAM·코어 수가 필요하다는 것입니다.

정리 #

tick 수준의 대규모 백테스트·최적화는 더 이상 특별한 계산기의 전유를 요구하지 않습니다. OptiMax VPS라면 필요할 때 필요한 만큼의 RAM과 코어를 확보해, 이 규모의 검증을 현실적인 시간에 돌릴 수 있습니다. 데이터 수집의 함정(503 버스트·사일런트 드롭·RAM 상한)도 본 기사의 체크리스트로 회피할 수 있습니다.