개발자를 위한 Algorithmic Trading 핵심 개념 정리
자동매매(Algorithmic Trading)는 사전에 정의한 규칙과 알고리즘에 따라 컴퓨터가 자동으로 매수/매도 주문을 실행하는 시스템이다. 사람의 감정이나 판단 지연 없이, 코드로 정의된 조건이 충족되면 즉시 거래한다.
| 항목 | 수동 매매 | 자동 매매 |
|---|---|---|
| 의사결정 | 사람이 차트 보고 판단 | 알고리즘이 조건 충족 시 실행 |
| 속도 | 초~분 단위 반응 | 밀리초 단위 반응 |
| 감정 영향 | 공포/탐욕에 취약 | 규칙 기반, 감정 배제 |
| 운영 시간 | 사람이 깨어 있는 동안 | 24시간 무인 운영 가능 |
| 확장성 | 동시 감시 종목 한계 | 수백 종목 동시 모니터링 |
자동매매 시스템은 다섯 가지 핵심 모듈로 구성된다. 각 모듈은 독립적으로 개발되지만 파이프라인으로 연결된다.
증권사가 제공하는 REST/WebSocket API를 통해 주문을 넣고 잔고를 조회한다. 인증 토큰 관리, rate limit 준수, 에러 재시도 로직이 핵심이다.
시장 데이터를 입력받아 매수/매도/홀드 시그널을 생성한다. 기술적 지표(RSI, MACD 등)나 ML 모델을 사용하여 판단한다.
시세 수집, 정제, 저장, 지표 계산을 담당한다. 실시간 스트리밍과 배치 처리 두 경로가 필요하다.
시스템 상태, 포지션 현황, 수익률을 실시간으로 추적한다. 이상 상황 발생 시 알림을 보내고 비상 정지를 트리거한다.
"오르는 종목은 계속 오른다"는 가정. 일정 기간 수익률이 높은 종목을 매수하고, 모멘텀이 꺾이면 매도한다.
"과도하게 벌어진 가격은 평균으로 돌아온다"는 가정. 볼린저 밴드 하단 터치 시 매수, 상단 터치 시 매도.
전일 변동폭의 일정 비율을 돌파하면 매수하는 전략. 래리 윌리엄스의 변동성 돌파 전략이 대표적이다.
과거 데이터로 학습한 모델이 가격 방향이나 수익률을 예측한다. 피처 엔지니어링과 과적합 방지가 핵심 과제.
자동매매 시스템의 데이터는 다음 다섯 단계를 거쳐 흐른다. 각 단계는 이전 단계의 출력을 입력으로 받는 파이프라인 구조이다.
증권사 API 또는 데이터 벤더로부터 실시간 체결가, 호가, 거래량을 수신한다. WebSocket 연결을 유지하며, 연결 끊김 시 자동 재연결 로직이 필수이다.
수집한 시세 데이터로 기술적 지표를 계산한다. 이동평균, RSI, MACD, 볼린저 밴드 등 전략에 필요한 지표를 실시간으로 업데이트한다.
계산된 지표를 전략 로직에 입력하여 매수(BUY), 매도(SELL), 홀드(HOLD) 시그널을 생성한다. 복수 전략의 시그널을 가중 합산하여 최종 결정을 내리기도 한다.
시그널이 BUY/SELL이면 브로커 API를 호출하여 주문을 접수한다. 시장가/지정가 선택, 수량 계산, 체결 확인, 미체결 관리까지 포함한다.
보유 종목의 수익률 추적, 손절/익절 조건 확인, 리밸런싱을 수행한다. 전체 포트폴리오 관점에서 비중 조절도 이 단계에서 처리한다.
자동매매에서 리스크 관리는 수익 전략보다 중요하다. "얼마를 벌 수 있는가"보다 "최악의 경우 얼마를 잃는가"를 먼저 설계해야 한다.
| 항목 | 설정 예시 | 초과 시 행동 |
|---|---|---|
| 종목당 최대 손실 | -3% | 즉시 매도 |
| 일일 최대 손실 | 총 자산의 -2% | 당일 거래 중단 |
| 최대 동시 보유 종목 | 5개 | 신규 매수 차단 |
| 단일 종목 최대 비중 | 20% | 초과분 매도 |
| 월간 MDD 한도 | -10% | 전략 비활성화 + 점검 |
| 구분 | 장기 투자 (Swing/Position) | 단타 (Day/Scalp Trading) |
|---|---|---|
| 보유 기간 | 수일 ~ 수개월 | 수초 ~ 당일 내 청산 |
| 의사결정 빈도 | 하루 1~2회 | 분/초 단위 수십~수백 회 |
| 주요 전략 | 추세 추종, 가치 기반 | 변동성 돌파, 스캘핑, 호가 분석 |
| 데이터 주기 | 일봉, 주봉 | 틱, 1분봉, 5분봉 |
| 거래 비용 영향 | 낮음 (거래 횟수 적음) | 높음 (수수료 + 슬리피지 누적) |
| 시스템 요구사항 | cron 기반, 저사양 가능 | 실시간 스트리밍, 저지연 필수 |
| 심리적 부담 | 상대적으로 낮음 | 높음 (빈번한 손실 발생) |
| 자동화 난이도 | 비교적 쉬움 | 높음 (실시간 처리, 예외 상황 많음) |
자동매매 시스템 구축에 일반적으로 사용되는 기술 스택이다. 정답은 없으며, 요구사항에 맞게 선택하면 된다.
| 계층 | 기술 | 역할 |
|---|---|---|
| 매매 로직 | Python | 전략 개발, 데이터 분석, ML 모델. pandas, numpy, scikit-learn 등 생태계가 풍부 |
| 대시보드 | Next.js / React | 포지션 현황, 수익률 차트, 설정 UI |
| 백테스트 | Python (backtrader, zipline) | 과거 데이터로 전략 시뮬레이션 |
| 구성요소 | 기술 | 용도 |
|---|---|---|
| 데이터베이스 | PostgreSQL | 시세 히스토리, 거래 기록, 포지션 관리 |
| 봇 서버 | Railway / AWS EC2 | 매매 봇 상시 구동 (24시간 서버) |
| 프론트엔드 | Vercel | 대시보드 배포 |
| 스케줄러 | cron / APScheduler | 장 시작/종료 시 작업 스케줄링 |
| 메시지 큐 | Redis / RabbitMQ | 모듈 간 비동기 통신 (선택) |
한국 주식의 경우 증권사 Open API를 사용한다. REST API로 주문/조회를 처리하고, WebSocket으로 실시간 시세를 수신한다.
WebSocket을 통해 체결가, 호가를 실시간으로 수신한다. 연결 유지, 재연결, 구독 관리가 주요 과제이다. 장 시간(09:00~15:30) 동안 안정적인 연결 유지가 필수이다.
백테스트에서 수익률이 높다고 실전에서도 잘 작동하리란 보장은 없다. 과거 데이터에 과도하게 맞춘 전략은 실전에서 실패한다.
주문 시점의 가격과 실제 체결 가격 사이의 차이. 유동성이 낮은 종목이나 큰 수량 주문에서 발생한다.
증권사 API는 장 시작/종료 시간대에 불안정할 수 있다. 네트워크 장애, 토큰 만료, rate limit 초과에 대한 방어 코드가 필수이다.