
왜 스캘핑은 '아이디어'부터 시작하면 실패하는가

스캘핑처럼 하루에 수십~수백 번 진입하는 고회전 전략은 보통 '어떤 신호로 진입할까'부터 고민한다. 하지만 실제로 KR·US·코인 4개 시장의 스캘핑 연구 계획을 검토하면서 확인한 결론은 반대였다. 전략 아이디어보다 비용·데이터·실행 레이턴시가 먼저 전략의 생사를 결정한다.
이유는 단순하다. 회전이 빨라질수록 한 번의 왕복에서 발생하는 수수료·슬리피지가 기대 수익을 잠식하고, 검증에 필요한 데이터가 애초에 존재하지 않으며, 신호가 맞아도 실행 지연 때문에 그 가격에 못 들어간다. 이 세 가지 전제조건이 충족되지 않으면 백테스트 성적이 아무리 좋아도 실거래 성과와 검증 신뢰도가 크게 훼손될 수 있다.
이 글은 특정 전략의 매매법이 아니라, 고회전 전략을 시작하기 전에 먼저 계산해야 하는 세 가지 관문과 그것을 확인하는 순서를 다룬다.
3대 충돌: 계획 검토에서 실제로 확정된 것들

연구 계획(SCALPING_RESEARCH_PLAN.md)을 단계형으로 재구성하는 과정에서 세 가지 구조적 충돌이 확정됐다. 이건 시장별 개별 문제가 아니라 고회전 전략 전반에 적용되는 관문이다.
| ①비용 수학 | 익절 0.3%는 전 시장 왕복비용 이하 → 신호가 맞아도 손실 | 익절 하한을 실비용×3으로 사전 고정 |
| ②데이터 부재 | 체결강도·호가는 과거 이력 API가 없음 → 백필 불가 | 수집기를 먼저 돌려 데이터를 직접 쌓기 시작 |
| ③실행 모델 | KR 텔레그램 승인 방식은 스캘핑과 양립 불가 | 자동 전환은 별도 결정으로 분리, 지금은 성립하는 시장부터 |
특히 ②가 결정적이었다. 분봉 백테스트가 지금 당장 성립하는 시장은 업비트뿐이었다. 나머지 시장은 검증하고 싶은 구간의 호가·체결 데이터 자체가 없었다.
왜 첫 산출물이 백테스터가 아니라 수집기인가
여기서 가장 반직관적인 원칙이 나온다. 호가·체결 데이터는 백필(과거 소급 수집)이 불가능하다. 대부분의 데이터 제공자는 일봉·분봉 OHLCV는 과거 이력을 주지만, 초 단위 호가창 스냅샷이나 체결강도 같은 마이크로 데이터는 '지금부터' 저장하는 것만 가능하다.
즉 2월 데이터를 검증하고 싶다면, 늦어도 몇 달 전부터 수집기를 켜 놨어야 한다. 그래서 스캘핑 연구 계획의 첫 번째 산출물이 백테스터가 아니라 수집기가 된다. 아이디어를 다듬는 동안에도 시계는 흐르고, 수집을 미룬 하루는 되돌릴 수 없다.
잘못했을 때 어떻게 되는가? 수집기 준비를 미루고 아이디어와 백테스트 코드부터 만들면, 정작 검증 단계에서 '검증할 데이터가 없다'는 벽에 부딪힌다. 이때는 다시 수개월을 기다려야 데이터가 쌓인다. 연구 전체가 그 지연만큼 통째로 밀린다. 이 손실은 코드 품질과 무관하게 발생한다.
따라 할 수 있는 확인 절차
- 왕복 실비용을 먼저 계산한다. 매수·매도 수수료 + 예상 슬리피지 + (해당 시 세금)을 합산한다. 이 값이 익절 목표의 하한을 정한다. 여유를 두려면 실비용의 3배 이상에서 익절 하한을 잡는다.
- 검증에 필요한 데이터가 백필 가능한지 확인한다. 사용할 API 문서에서 '과거 호가/체결 이력 조회'가 되는지 명시적으로 찾는다. 없으면 그 시장은 호가·체결 기반 검증이나 해당 스캘핑 가설의 백테스트가 지금 당장 불가능하다고 판정한다.
- 수집기를 먼저 배포한다. 백테스터보다 먼저. 수집이 안정적으로 돌기 시작한 날짜를 기록한다. 이 날짜는 검증 가능 구간의 출발점일 뿐이며, 실제 검증에는 필요한 기간만큼 데이터가 더 축적돼야 한다.
- 실행 모델이 회전 속도와 양립하는지 본다. 수동 승인·알림 기반 체결 구조라면 스캘핑 주기와 맞지 않는다. 자동화 전환은 되돌릴 방법과 승인 단계를 따로 설계한다.
- 채택 기준을 착수 전에 고정한다. 사후에 기준을 조정하면 자기기만이 된다.
실제 계획에서는 채택 기준을 PF≥1.3, 표본 500건 이상, OOS(아웃오브샘플) 생존, 페이퍼 트레이딩 통과, 기존 전략 대비 우위로 사전 고정했다. 그리고 시장 순서를 코인 파일럿 → 페이퍼 검증 → US → KR 단계형으로 배치했다. 지금 데이터가 성립하는 곳부터 시작하고, 실행 모델이 까다로운 시장은 뒤로 뺀 것이다.
체크리스트와 한계
착수 전 최소 점검 항목:
- 왕복 실비용을 계산했고, 익절 하한을 실비용 배수로 고정했는가?
- 검증 구간의 호가·체결 데이터가 실제로 존재하는가(백필 가능 여부 확인)?
- 수집기를 백테스터보다 먼저 돌리기 시작했는가?
- 실행 지연·승인 구조가 회전 속도와 양립하는가?
- 채택 기준(PF·표본 수·OOS·페이퍼)을 착수 전에 문서화했는가?
- 실패 시 되돌릴 방법과 자동화 승인 단계를 마련했는가?
한계와 주의: 위 수치(익절 하한 실비용×3, PF≥1.3, 500건)는 특정 연구 계획에서 사전 고정한 기준이지 모든 전략에 통하는 정답이 아니다. 시장·상품·회전 주기에 따라 적정 값은 달라진다. 또한 이 글은 특정 전략의 수익을 보장하지 않으며, 백테스트 통과가 실거래 성과를 담보하지도 않는다. 그리고 세 관문의 영향은 서로 다르다 — 호가·체결 데이터가 없으면 그 데이터에 기반한 고회전 전략은 지금 당장 백테스트로 검증하는 것 자체가 불가능하고, 비용과 레이턴시는 검증을 막지는 않지만 기대수익과 실전 적용 가능성을 훼손한다. 실제로 같은 검토에서도 데이터가 성립하는 업비트는 분봉 백테스트가 가능하다고 구분했다. 강조하는 것은 순서의 문제다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
'실전 원칙' 카테고리의 다른 글
| 인프라를 계약으로 만들면 기능 추가가 10파일로 끝난다 — 재사용 가능한 코어 설계법 (0) | 2026.08.12 |
|---|---|
| AI가 만든 '성공' 판정, 부호만 맞으면 통과시키는 함정 — 최소격차·표본 가드로 막는 법 (0) | 2026.08.10 |
| 자동화에 판단을 맡길 때 '긴급도'와 '실행 권한'을 반드시 분리해야 하는 이유 (0) | 2026.08.09 |
| 여러 채널을 함께 운영할 때, 합쳐야 할 것과 끝까지 분리해야 할 것 (0) | 2026.08.09 |
| AI가 검사자 역할을 할 때 절대 시키면 안 되는 네 가지 (0) | 2026.08.09 |