자동매매 데이터 파이프라인 설계

자동매매 데이터 파이프라인이란?

자동매매 시스템에서 데이터 파이프라인은 시세 수집, 정제, 저장, 가공의 전 과정을 자동화하는 핵심 인프라입니다. 전략 로직이 아무리 정교해도 입력 데이터가 불안정하면 수익은 나올 수 없습니다. 이 글에서는 실전 자동매매에서 데이터 파이프라인을 어떻게 설계하고 운영하는지 단계별로 정리합니다.

1단계: 시세 데이터 수집

자동매매의 출발점은 실시간 시세 수집입니다. 대부분의 거래소는 REST API와 WebSocket 두 가지 방식을 제공합니다.

REST API — 과거 캔들·체결 데이터 조회에 적합. 폴링 주기 관리 필요
WebSocket — 실시간 호가·체결 스트림 수신. 지연 최소화의 핵심

안정적인 수집을 위해서는 재연결 로직, 하트비트 체크, 메시지 시퀀스 검증이 필수입니다. 연결이 끊어졌을 때 빠진 데이터를 REST로 보충하는 갭 필(gap fill) 전략도 반드시 구현해야 합니다.

import websockets, asyncio, json

async def collect_ticker(symbol: str):
    uri = f"wss://stream.binance.com:9443/ws/{symbol}@trade"
    async for ws in websockets.connect(uri):
        try:
            async for msg in ws:
                trade = json.loads(msg)
                await process_trade(trade)
        except websockets.ConnectionClosed:
            continue  # 자동 재연결

2단계: 데이터 정제와 검증

수집된 원시 데이터는 곧바로 전략에 넣을 수 없습니다. 데이터 품질 검증 단계를 거쳐야 합니다.

타임스탬프 정렬 — 순서가 뒤바뀐 메시지 재정렬
중복 제거 — 동일 trade ID 필터링
이상값 탐지 — 직전 가격 대비 급변 비율 검사 (예: ±10% 이상 스파이크)
결측 구간 탐지 — 일정 시간 이상 데이터 공백 시 알림

이 과정을 소홀히 하면 백테스트 함정에서 다룬 것처럼 잘못된 데이터로 과적합된 전략이 만들어집니다.

3단계: 저장소 설계

자동매매 데이터는 시계열 특성이 강하므로 저장소 선택이 중요합니다.

저장소	장점	적합 용도
TimescaleDB	PostgreSQL 호환, 자동 파티셔닝	캔들·체결 이력
InfluxDB	시계열 특화 쿼리, 다운샘플링	틱 데이터 대량 저장
Redis	초저지연 읽기/쓰기	실시간 캐시·최신 호가
Parquet 파일	압축 효율, 배치 분석	백테스트 데이터셋

실전에서는 핫-콜드 계층을 적용합니다. 최근 데이터는 Redis에, 일별 집계는 TimescaleDB에, 장기 보관은 Parquet로 아카이빙하는 구조입니다.

4단계: 캔들 집계와 지표 가공

원시 체결 데이터로부터 OHLCV 캔들을 실시간 집계하고, 기술 지표를 계산하는 과정입니다.

시간 기반 캔들 — 1분·5분·1시간 등 고정 주기
틱 기반 캔들 — N건의 체결마다 캔들 생성
볼륨 기반 캔들 — 일정 거래량 도달 시 캔들 생성

집계된 캔들에서 이동평균, RSI, 볼린저밴드 등 기술 지표를 스트리밍 방식으로 계산하면 전략 신호 지연을 최소화할 수 있습니다. 매번 전체 데이터를 다시 계산하는 배치 방식보다 증분 계산이 훨씬 효율적입니다.

class StreamingEMA:
    def __init__(self, period: int):
        self.period = period
        self.k = 2 / (period + 1)
        self.ema = None

    def update(self, price: float) -> float:
        if self.ema is None:
            self.ema = price
        else:
            self.ema = price * self.k + self.ema * (1 - self.k)
        return self.ema

5단계: 메시지 큐로 컴포넌트 분리

수집·저장·가공·전략 실행을 하나의 프로세스에 넣으면 장애 전파 위험이 큽니다. 메시지 큐를 도입해 각 단계를 독립 서비스로 분리하세요.

Kafka — 대용량 틱 스트림 처리에 최적. 리플레이 가능
Redis Streams — 경량 파이프라인에 적합. 소비자 그룹 지원
RabbitMQ — 주문 실행 등 신뢰성 필요 구간에 적합

이 구조는 자동매매 주문 큐 설계에서 다룬 큐 패턴과 자연스럽게 연결됩니다. 데이터 파이프라인의 출력이 주문 큐의 입력이 되는 구조입니다.

6단계: 모니터링과 알림

파이프라인이 멈추면 전략도 멈춥니다. 운영 안정성을 위해 반드시 모니터링을 구축해야 합니다.

수집 지연 — WebSocket 메시지 수신 지연 시간 추적
처리량 — 초당 처리 틱 수 대시보드
데이터 품질 — 이상값 발생 빈도, 결측 구간 횟수
저장소 용량 — 디스크 사용량, 파티션 상태

Grafana + Prometheus 조합으로 대시보드를 구성하고, 임계값 초과 시 Slack이나 텔레그램으로 알림을 보내는 것이 표준적인 접근입니다. 자동매매 로그 모니터링 구축 글에서 구체적인 설정 방법을 확인할 수 있습니다.

실전 아키텍처 예시

실제 운영 환경에서의 데이터 파이프라인 아키텍처를 요약하면 다음과 같습니다.

수집 서비스 → WebSocket으로 거래소 연결, 원시 데이터를 Kafka 토픽으로 발행
정제 서비스 → Kafka에서 소비, 검증 후 정제된 데이터를 다음 토픽으로 발행
저장 서비스 → 정제 데이터를 TimescaleDB에 적재, 최신 값은 Redis 캐시
지표 서비스 → 스트리밍 방식으로 캔들 집계 및 기술 지표 계산
전략 서비스 → 계산된 지표를 기반으로 매매 신호 생성

각 서비스는 독립 배포·스케일링이 가능하며, 한 서비스가 장애를 일으켜도 Kafka의 오프셋 관리 덕분에 데이터 손실 없이 복구할 수 있습니다.

마무리

자동매매 데이터 파이프라인은 수집 → 정제 → 저장 → 가공 → 전달의 흐름으로 구성됩니다. 각 단계를 메시지 큐로 느슨하게 결합하고, 모니터링으로 안정성을 확보하는 것이 핵심입니다. 전략 성과의 절반은 데이터 품질에서 결정된다는 점을 기억하세요. 탄탄한 파이프라인이 곧 안정적인 수익의 기반입니다.