📝

Draft article

This draft is visible to admins and superusers only. Sign in with an authorized account.

← 기사 목록으로
July 24, 2026
5분 소요

슬라이스 내부: 스케줄러와 거래소 사이의 자식 주문 전술

슬라이스 내부: 스케줄러와 거래소 사이의 자식 주문 전술
#execution
#child orders
#order tactics
#queue position
#maker-taker
#iceberg orders
#microstructure
#python

Almgren-Chriss 궤적은 하나의 숫자를 건넨다. 향후 5분간 4.2 BTC를 매도하라는 것이다. VWAP 스케줄도 다른 근거로 같은 종류의 숫자를 건넨다. 그러나 그 다음에 무슨 일이 벌어지는지는 둘 다 말해주지 않는다. 그 4.2 BTC가 하나의 시장가성 주문으로 호가창을 때릴지, 최우선호가에 앉아 메이커 수수료를 모을지, 0.3 BTC짜리 표시 물량 뒤에 숨을지, 아니면 흘러가는 호가를 쫓아 열한 번 리프라이싱될지는 전혀 다른 문제다. 이 두 번째 의사결정 계층이 바로 전술 계층이며, 수수료가 지배적인 크립토 호가창에서는 이 계층이 그 위의 스케줄러 선택보다 슬라이스당 훨씬 더 많은 손익을 좌우하는 경우가 흔하다. TWAP과 잘 튜닝된 Almgren-Chriss 사이의 구간 예산 차이는 전체 부모 주문에 걸쳐 임팩트 몇 bp 수준에 불과하지만, 메이킹이 가능했던 슬라이스에서 테이커 수수료를 내거나 부주의한 리프라이싱으로 큐 포지션을 갉아먹는 것은 시간당 그만큼의 비용을 발생시킨다. 이 글은 모두가 운용하지만 거의 아무도 문서화하지 않는 계층, 즉 각 자식 주문이 호가창과 어떻게 접촉할지를 결정하는 상태 머신에 관한 것이다.

두 계층, 하나의 좁은 인터페이스

Lehalle과 Laruelle의 Market Microstructure in Practice (2판, 2018)는 모든 실행 데스크가 수렴하는 지점을 공식화한다. 시간에 걸쳐 수량을 배분하는 전략 계층(스케줄러)과, 그 배분을 실시간 호가창에 대해 실행하는 전술 계층(마이크로트레이더)이다. 이 분리는 미학적인 것이 아니다. 두 계층은 서로 다른 시계와 서로 다른 데이터 위에서 산다. 스케줄러는 분 단위로 사고하고, 변동성과 거래량 예측을 소비하며, 변분 문제를 푼다. 전술 계층은 밀리초에서 초 단위로 사고하고, L2 델타와 큐 추정치를 소비하며, 작은 정지 문제들의 연속을 푼다.

스케줄러가 슬라이스 예산과 긴급도를 아래로 전달하고 전술 계층이 체결과 부족분을 위로 반환하는 2계층 실행 아키텍처

이 둘 사이의 인터페이스는 좁아야 한다. 슬라이스 kk마다 아래로 전달되는 것은 다음과 같다.

  • 예산 qkq_k — 이 구간에서 실행할 수량 (Almgren-Chriss의 nkn_k, 또는 VWAP의 거래량 곡선 증분);
  • 윈도우 τk\tau_k — 슬라이스 길이;
  • 긴급도 — Almgren-Chriss라면 자연스러운 후보는 κ=λσ2/η\kappa = \sqrt{\lambda\sigma^2/\eta}로, 이는 이미 위험회피 성향, 변동성, 유동성을 하나의 비율로 압축한다; VWAP 스케줄러라면 보통 밴드 거리("목표 곡선 대비 1.8% 뒤처짐")가 된다.

위로 전달되는 것은 타임스탬프와 수수료가 붙은 체결, 미체결 잔량, 그리고 구간 도착 중간가 대비로 측정된 슬라이스 단위 실행 부족분(implementation shortfall)이다. 마지막 항목이 중요하다. 스케줄러의 임팩트 파라미터 η\eta는 이미 비율 qk/τkq_k/\tau_k로 유동성을 요구하는 것이 마땅히 얼마의 비용이어야 하는지를 가격화하고 있다. 전술 계층의 임무는 한 줄로 요약된다. 부모 주문의 존재를 노출시키지 않으면서, η\eta가 암시하는 비용보다 더 나은 조건으로 체결을 실현하라. 측정된 슬라이스 부족분이 모델 비용보다 꾸준히 낮다면, 캘리브레이션된 η\eta를 낮출 수 있고, 스케줄러는 더 빨라지며, 전체 스택이 개선된다. 스케줄 비용과 별개로 슬라이스 부족분을 측정할 수 없다면, 어느 계층도 튜닝할 수 없다. 뭉뚱그려진 숫자 하나와 두 개의 손잡이만 남을 뿐이다.

잔여분 처리 정책도 계약의 일부다. 슬라이스가 미체결 수량으로 끝나면, 전술 계층이 강제 완결(잔량을 크로스하는 것 — 데드라인 긴급도 하에서는 기본값)하거나, 남은 슬라이스에 재분배하기 위해 스케줄러로 되돌려보내야 한다(낮은 κ\kappa의 스케줄 초반에는 허용되지만, 재분배가 조용히 누적되어 거대한 마지막 슬라이스가 되어버리는 데드라인 근처에서는 치명적이다).

에스컬레이션 사다리: 패시브 먼저, 데드라인이 다가올수록 공격적으로

이 분야에서 가장 오래된 결과는 Harris (1998)의 "Optimal dynamic order submission strategies in some stylized trading problems" (Financial Markets, Institutions & Instruments 7(2))다. 데드라인까지 거래를 완결해야 하는 유동성 트레이더에게 최적 전략은 동적이다. 시간이 저렴할 때는 지정가 주문으로 호가창에 서 있고, 데드라인이 다가오면 시장 쪽으로 리프라이싱하며, 마지막에는 크로스한다. 모든 프로덕션 전술 엔진은 이 형태의 후예다. 최우선호가에 포스트, 시간 경과, 에스컬레이션, 크로스. 현대의 수수료 체계와 큐 동역학이 여기에 더하는 것은 각 전환이 정확히 언제 발동하는지에 대한 산술이다.

크로스의 손익분기점

가격을 현재 중간가 기준으로 표현한, 단위당 작업량을 매수 기준으로 살펴본다. 지금 크로스하는 비용은 스프레드의 절반에 테이커 수수료를 더한 것이다.

ctake=s2+ft.c_{\text{take}} = \frac{s}{2} + f_t.

윈도우 τ\tau 동안 매수호가에 포스트하면 확률 pp로 체결된다. 체결되면 절반 스프레드를 벌고 메이커 수수료 fmf_m을 지불한다(리베이트라면 음수). 체결되지 않으면 윈도우 종료 시점에 크로스하게 되는데, 그때는 가격이 평균적으로 δ(τ)=E[불리한 중간가 변동미체결]>0\delta(\tau) = E[\,\text{불리한 중간가 변동} \mid \text{미체결}\,] > 0만큼 불리하게 움직인 뒤다 — 이는 엄격히 양수인데, 미체결과 불리한 드리프트가 사실상 같은 사건이기 때문이다. 시장이 매수호가로부터 멀어질 때 당신의 매수호가는 맞아떨어지지 않는다. 예상 포스팅 비용은 다음과 같다.

cpost=p(s2+fm)+(1p)(s2+ft+δ).c_{\text{post}} = p\left(-\frac{s}{2} + f_m\right) + (1-p)\left(\frac{s}{2} + f_t + \delta\right).

포스팅이 크로스보다 나은 것은 다음 조건이 성립할 때다.

  p  >  p\*=δΠ+δ,Π=s+ftfm  \boxed{\; p \;>\; p^\* = \frac{\delta}{\Pi + \delta}, \qquad \Pi = s + f_t - f_m \;}

여기서 Π\Pi상금이다 — 테이킹 대신 메이킹함으로써 포착하는 왕복 전체 가치, 즉 스프레드에 수수료 차이를 더한 값이다. 이것은 실행의 메이커-테이커 경제학 전체를 지배하는 것과 동일한 손익분기점을, 단일 슬라이스로 압축한 것이다.

숫자로 살펴보자. BTCUSDT 무기한선물, 중간가 $100,000, 스프레드는 1틱 s = \0.10,VIP0수준의수수료로메이커2bp/테이커5bp,, VIP0 수준의 수수료로 메이커 2bp / 테이커 5bp, 즉 f_m = $20,, f_t = $50(BTC).상금(BTC당). 상금 \Pi = 0.10 + 50 - 20 = $30.10 \approx 3bp다—스프레드가사실상기여하는바가거의없다는점에주목하라.타이트한크립토메이저에서는상금이수수료차이다.일간변동성3bp다 — 스프레드가 사실상 기여하는 바가 거의 없다는 점에 주목하라. 타이트한 크립토 메이저에서는 상금이 *곧* 수수료 차이다. 일간 변동성 3%(\sigma_{\text{day}} = $3{,}000))와 \delta(\tau) \approx 0.6,\sigma_{\text{day}}\sqrt{\tau/86400}$(0.6은 캘리브레이션해야 할, 그냥 믿어서는 안 되는 역선택 헤어컷이다)를 가정하면 다음과 같다.

  • τ=10\tau = 10초: \delta \approx \19,따라서, 따라서 p^* = 19/49 \approx 0.39$. 10초 내에 최소 39%의 체결 확률을 기대할 때만 포스트하라.
  • τ=60\tau = 60초: \delta \approx \47,따라서, 따라서 p^* = 47/77 \approx 0.61$.
  • 메이커 수수료 2bp 대신 1bp 리베이트가 있다면(f_m = -\10):): \Pi = $60.10이되고,10초임계값은이 되고, 10초 임계값은 p^* \approx 0.24$로 떨어진다.

여기서 두 가지 구조적 사실이 도출된다. 첫째, δ\deltaτ\sqrt{\tau}처럼 증가하는 반면 Π\Pi는 상수이므로 p\*(τ)1p^\*(\tau) \to 1이 된다. 인내심에는 하드 만료 시점이 있으며, 시간 경과 타이머는 휴리스틱이 아니라 두 곡선의 교차점이다 — 당신이 추정한 p(τ)p(\tau)(오목하며, 앞선 큐가 소진됨에 따라 포화하는)와 p\*(τ)p^\*(\tau)(상승하는) 사이의 교차점이다. 둘째, 거래하는 수수료 등급이 이 사다리를 물리적으로 이동시킨다. 테이커 수수료를 낮추는 등급 승급은 최적 전술을 공격적으로 만든다 — 대부분의 사람들은 VIP 재등급 이후 체결 통계가 바뀌고 나서야 이 상관관계를 발견한다.

Cont와 Kukanov의 "Optimal order placement in limit order markets" (Quantitative Finance 17(1), 2017; arXiv 2012)는 이를 단일 기간에서 엄밀하게 다룬다. SS 단위를 시장가와 지정가 주문(하나 또는 여러 거래소에 걸쳐) 사이에 분할하여 실행하는 기대 비용을, 부족분에 대한 페널티와 함께 최소화하는 문제다. 단일 거래소 해는 명시적이며 뉴스벤더 구조를 갖는다. 최적 지정가 주문 크기는 큐 유출의 분포에 의해 결정된다 — 앞선 큐가 예상 유출량에 비해 작을 때는 공격적으로 크게 포스트하고, 꼬리 위험은 시장가 주문으로 커버하라는 것이다. 이들의 다중 거래소 확장은 확률적 근사로 풀리며, 모든 스마트 오더 라우터의 패시브 배분 로직의 지적 핵심을 이룬다. 전술 엔진에 대한 실무적 함의는 이렇다. 위 손익분기점 수식의 pp는 상수가 아니라 큐 포지션과 소진율의 함수이며, 그렇기 때문에 전술 계층은 큐 포지션 추정기를 일급 입력값으로 소비해야 한다.

최우선호가에서의 패시브 포스팅에서 리프라이싱을 거쳐 데드라인에 잔량을 크로스하는 에스컬레이션까지의 슬라이스 타임라인

긴급도 파라미터는 이 사다리 전체를 압축한다. 스케줄러로부터의 높은 κ\kappa는 특성 시간 θ=1/κ\theta = 1/\kappa가 짧다는 것을 의미한다. 윈도우가 줄어들고, p\*p^\*가 상승하며, 엔진은 곧바로 크로스로 건너뛴다 — 이는 올바른 동작인데, 스케줄러가 이미 재고 위험이 수수료 절감보다 우선한다고 선언했기 때문이다. 낮은 κ\kappa는 패시브 국면을 늘린다. 전술 계층은 자신의 시장 관점으로부터 긴급도를 재도출해서는 안 된다. 그것은 스케줄러의 몫이며, 이를 중복하면 서로 불일치하는 두 개의 컨트롤러가 생겨난다.

큐 포지션을 태우지 않고 리프라이싱하기

일단 포스트되면 호가는 흘러간다. 이를 순진하게 쫓는 것 — 취소하고, 새 최우선호가에 재포스트하고, 반복하는 것 — 은 전술 엔진이 애초에 포스팅을 정당화했던 바로 그 체결 확률을 조용히 파괴하는 방식이다. 큐 포지션은 측정 가능한 달러 가치를 지닌 자산이며(Moallemi와 Yuan, 2016은 여기에 가격을 매긴다 — 유동성이 풍부한 FIFO 호가창에서 큐 맨 앞 포지션은 스프레드의 상당한 비율에 해당하는 가치를 지닌다), 모든 리프라이싱 결정은 하나의 거래다. 현재 큐 포지션을 팔고, 다른 가격 레벨의 맨 뒤에서 하나를 사는 것이다. 이 거래는 새 레벨의 가치가 기존 레벨의 가치에 메시징 비용을 더한 것을 초과할 때만 할 가치가 있다. 이를 위해서는 각 거래소의 amend가 실제로 당신의 줄 서기 순서에 무엇을 하는지 알아야 하는데 — 그 답은 놀라울 정도로 제각각이다.

CME Globex는 가장 깔끔한 시맨틱을 문서화한다. 주문 수량을 줄이면 시간 우선순위가 유지된다. 수량을 늘리거나 가격을 바꾸면 큐 맨 뒤로 보내진다. 이것이 기준 모델이다 — 수량 감소는 무료이고, 그 외 모든 것은 재큐잉이다.

Binance 현물은 역사적으로 POST /api/v3/order/cancelReplace만 제공했다 — 원자적으로 보이지만 명시적으로 비트랜잭션적인 취소-후-신규 방식이다. 두 가지 모드가 있다. STOP_ON_FAILURE(기본값 — 취소가 실패하면 신규 주문도 없음)와 ALLOW_FAILURE(취소가 실패해도 신규 주문을 넣는다 — 뜻하지 않은 이중 익스포저가 발생할 수 있다). 이 작업은 부분적으로만 성공할 수 있으며 HTTP 409로 신호가 온다. 따라서 OMS는 두 다리를 독립적으로 정합성 검증해야 하며, 신규 주문은 항상 새로운 큐 인생을 시작한다. 그러다 2025년에 Binance는 Order Amend Keep Priority(PUT /api/v3/order/amend/keepPriority)를 출시했다. 수량을 그 자리에서 줄이면서 시간 우선순위를 유지하고, 미체결 주문 개수 비용도 전혀 들지 않는다. CME 시맨틱을, 15년이 지나서야 — 그것도 수량 감소 절반에 대해서만.

Binance USDT-M 선물은 진짜 modify 엔드포인트(PUT /fapi/v1/order)를 갖고 있지만, 작은 글씨를 읽어야 한다. LIMIT 주문에만 적용되고, pricequantity를 모두 보내야 하며, *"수정된 주문은 매칭 큐에서 재정렬됩니다"*라고 문서가 명시한다 — 순수한 수량 감소에 대해서도 우선순위 유지를 약속하지 않는다. 모든 선물 modify를 큐 리셋으로 취급하되, 그것이 메시지 하나를 절약하고 주문 ID를 유지해준다는 정도로만 여겨라. 알아둘 만한 날카로운 함정 하나. GTX(post-only) 주문을 크로스하게 될 가격으로 수정하면 주문이 취소된다 — 거부되어 유지되는 것이 아니다. 이를 체크하지 않는 페그 구현체는 가끔 스스로를 소멸시킬 것이다.

OKXPOST /api/v5/trade/amend-order(newPx, newSz, amend 실패 시 자동 취소하는 cxlOnFail)를 노출한다. 단일 메시지이고, 주문 ID를 보존하며, 비동기로 확인된다 — sCode = 0은 "요청이 접수됨"을 의미할 뿐, 실제 결과는 orders 채널에 amendResult로 도착한다. 공개 문서가 눈에 띄게 명시하지 않는 것은 큐 우선순위 동작이다. 이 문서 공백을 낙관으로 채우지 마라. 직접 측정하라. 조용한 레벨에 마커 주문 두 개를 포스트하고, 하나의 사이즈를 아래로 amend한 뒤, 수백 번의 시행에서 어느 것이 먼저 체결되는지 관찰하라. 그 데이터를 확보하기 전까지는, 가격 변경은 어디서든 재큐잉을 유발하고 수량 감소만이 명시적으로 문서화된 경우에 한해 우선순위를 유지한다는 보수적 가정만이 유일하게 방어 가능하다.

어떤 amend 작업이 큐 우선순위를 유지하고 어떤 작업이 리셋하는지를 거래소별로 보여주는 매트릭스

정책적 결론은 다음과 같다.

  1. 페깅이 아니라 히스테리시스. 최우선호가가 당신의 대기 가격으로부터 밴드 bb틱 이상 벗어났을 때만 리프라이싱하라. 밴드 내부에서는 드리프트가 노이즈이며, 당신의 큐 포지션은 1틱의 가격 개선보다 더 가치 있다. 합리적인 시작 밴드는 단기 변동성으로 스케일된 1~3틱이다. 올바른 밴드는 한계 리프라이싱을 EV 중립으로 만든다. VnewVcur=cmsgV_{\text{new}} - V_{\text{cur}} = c_{\text{msg}}이며, VV는 Moallemi-Yuan 스타일의 큐 가치이고 cmsgc_{\text{msg}}는 당신의 레이트 리밋 섀도우 가격이다. Amend/cancel-replace 작업은 두 Binance 거래소 모두에서 주문 레이트 예산을 소비한다. 매 틱마다 페깅하는 전술 엔진은 시스템 나머지 부분의 메시지 용량을 굶주리게 만든다.
  2. 아래로는 amend, 절대 cancel-repost로 내리지 마라. 스케줄러가 진행 중에 슬라이스 예산을 삭감할 때(거래량이 마르는 것을 본 POV 스케줄러, 부분 체결 후 Almgren-Chriss 재계산), 우선순위를 보존하는 경로가 존재하는 곳에서는 그것을 사용하라. 이것이 전체 계층에서 유일한 공짜 점심이다.
  3. 리프라이싱에서의 비대칭적 긴급도. 시장 쪽으로(쫓아가는) 리프라이싱은 더 나쁜 가격에서 큐를 리셋한다 — 이는 오직 에스컬레이션 로직에서, 그것도 자신의 타이머에 의해서만 발동되어야 한다. 반대 방향(시장이 당신에게 다가온) 리프라이싱은 선물이다 — 이는 패시브 밴드를 통해서만 취하라. 현재 레벨이 어차피 곧 체결될 것이기 때문이다.

아이스버그, 표시 사이즈, 그리고 무엇이 의도를 노출시키는가

표시 사이즈는 세 번째 결정이며, 진정한 양면적 거래이지 공짜 은신 버튼이 아니다. 실증 기록은 다음과 같다.

  • Frey와 Sandås("The Impact of Iceberg Orders in Limit Order Books", 2009년 워킹 페이퍼; Quarterly Journal of Finance, 2017), Xetra 데이터 기반. 아이스버그 주문은 제출 거래량의 9.3%, 체결 거래량의 15.9%를 차지했고, 일반 지정가 주문의 12~20배 크기였다 — 그리고 핵심은, 다른 참가자가 아이스버그를 탐지하면 매칭되는 시장가 주문으로 반응한다는 것이다. 숨겨진 사이즈는, 일단 추론되면, 오히려 흐름을 끌어들인다. 잠재 유동성 탐색은 양방향으로 작동한다.
  • Bessembinder, Panayides, Venkataraman("Hidden liquidity: an analysis of order exposure strategies in electronic stock markets", JFE 94(3), 2009), 숨겨진 주문이 표본 거래량의 44%였던 Euronext Paris 데이터 기반. 숨기기는 실행 부족분을 낮추지만 완전 체결 확률도 낮추고 완결까지의 시간을 늘린다. 노출은 체결을 사고 그 대가를 임팩트로 지불한다. 이 옵션은 정확히 이론이 예측하는 대로 사용된다 — 공격적인 주문은 상대방을 끌어들이기 위해 노출하고, 인내심 있는 대형 물량은 숨는다.
  • Esser와 Mönch("The navigation of an iceberg", Finance Research Letters 4(2), 2007)는 피크 사이즈를 최적화 문제로 다룬다. 더 큰 표시는 더 빨리 체결되고, 더 작은 표시는 덜 노출되며, 최적점은 내부해다.

메커니즘을 먼저 짚어야 하는데, 이것이 최적화 자체를 제약하기 때문이다. 네이티브 아이스버그를 지원하는 거의 모든 거래소(icebergQty를 통한 Binance 현물, 아이스버그 알고 주문을 통한 OKX)에서 표시 피크가 리필될 때마다 그 가격의 큐 맨 뒤로 들어간다. 따라서 아이스버그는 "숨겨진 사이즈를 가진 하나의 주문"이 아니라, 각각 완전한 큐 대기를 치르며 자동으로 발사되는 작은 주문들의 시퀀스다. 위의 수수료 손익분기점에서 이는 중요한 의미를 갖는다. 피크당 유효 pp는 원래 포지션의 것이 아니라 큐 맨 뒤에서의 체결 확률이다. 깊은 큐는 작은 피크를 두 배로 벌준다 — 더 느린 체결과 더 많은 리필분의 역선택이다.

그다음은 시그널링 문제다. Frey와 Sandås 자신의 탐지 방법이 경고 사례다. 그들의 빈도주의적 탐지기는 가장 흔한 구현 게으름의 두 가지 패턴에 착안한다. 일정한 피크 사이즈체결 거래의 타임스탬프와 동일한 리필 타임스탬프다. 그런 탐지기를 돌리는 참가자라면(그리고 크립토 거래소에서는 많은 이들이 그렇게 한다 — 거래소 자체의 매칭 메타데이터가 콜로케이션된 흐름에게 이를 더 쉽게 만들어준다) 몇 번의 리필만으로 당신의 숨겨진 사이즈를 재구성해낸다. 실전에서 자주 목격하는 순서로 나열한 누출 경로는 다음과 같다.

  1. 일정하거나 딱 떨어지는 표시 사이즈(매번 0.5 BTC).
  2. 풀 피크 체결 후 즉각적이고 결정론적인 리필 — 동일 타임스탬프 시그니처.
  3. 결정론적인 에스컬레이션 타이머: 매 슬라이스 정확히 30초 지점에서 크로스하면 테이프에 메트로놈이 찍힌다.
  4. 고정된 리프라이싱 지연과 밴드 — amend 주기는 주문 사이즈만큼이나 식별력 있는 지문이며, 이는 디지털 지문과 트레이더 식별의 주제이기도 하다.

탐지당하는 비용은 가설이 아니다. Van Kervel과 Menkveld("High-frequency trading around large institutional orders", Journal of Finance 74(3), 2019)는 HFT가 처음에는 기관 메타주문에 반하여 기울어져(당신의 패시브 전술이 소비하는 유동성을 제공하며) 있다가, 그 지속성이 정보를 드러내는 순간 주문과 같은 방향으로 거래하는 쪽으로 전환하여 잔량을 백런하고 부모 주문의 비용을 상당히 끌어올린다는 것을 보여준다. 이들이 조사한 기관들은 투기적 수익과 탐지 위험을 저울질하며 대응했다. 당신의 전술 계층이 바로 그 트레이드오프가 구현되는 지점이다. 표시 사이즈를 무작위화하고(변동성으로 스케일된 기준값의 3070% 균등분포면 충분하다), 모든 타이머를 ±2030% 지터링하며, 가끔은 리필이 기다리게 놔두고, 두 개의 자식 주문이 사이즈, 타이머 위상, 지연 프로파일을 공유하지 않도록 하라. 이 중 어느 것도 측정 가능한 체결 품질을 희생시키지 않는다. 이 모두가 당신의 흐름에 탐지기를 맞추려는 누구에게든 노이즈 바닥을 높여준다.

최소한의 전술 엔진

위의 계층 전체는 슬라이스당 작은 상태 머신으로 압축된다. IDLE → POSTED → (리프라이싱 루프) → CROSSING → DONE이며, 진입 시 손익분기 게이트, 포스트된 동안의 히스테리시스 밴드, 데드라인 에스컬레이션이 있다. 아래 버전은 의도적으로 최소화되어 있다 — 거래소 어댑터도, 아이스버그 관리도 없다 — 하지만 이벤트 기반이고 부작용이 없어서, 체결 시뮬레이션 사다리의 4단계 큐 인식 시뮬레이터에 그대로 꽂힌다. 시뮬레이터가 on_tick/on_fill을 호출하고, 액션을 post → GTX/post-only, cross → IOC, cancel_replace/amend_down → 위 매트릭스의 거래소별 시맨틱으로 해석한다.

import math
from dataclasses import dataclass
from enum import Enum, auto

class State(Enum):
    IDLE = auto(); POSTED = auto(); CROSSING = auto(); DONE = auto()

@dataclass
class Fees:
    maker: float          # $ per unit; negative = rebate
    taker: float          # $ per unit

@dataclass
class Cfg:
    tick: float
    sigma_1s: float       # $ per sqrt(second), from your live vol estimator
    adverse_frac: float = 0.6   # E[adverse move | no fill] ~ 0.6 * sigma; calibrate
    reprice_band: float = 2.0   # ticks of touch drift tolerated before repricing
    escalate_frac: float = 0.7  # cross the remainder at this fraction of the window

class SliceTactic:
    """One instance per scheduler slice. Drive it from a fill simulator or OMS."""

    def __init__(self, side: str, qty: float, window: float, fees: Fees, cfg: Cfg):
        self.side, self.qty, self.window = side, qty, window
        self.fees, self.cfg = fees, cfg
        self.filled, self.state, self.px, self.t0 = 0.0, State.IDLE, None, None

    def p_star(self, spread: float, tau: float) -> float:
        """Break-even fill probability for posting over a window tau."""
        delta = self.cfg.adverse_frac * self.cfg.sigma_1s * math.sqrt(tau)
        prize = spread + self.fees.taker - self.fees.maker
        return delta / (prize + delta)

    def p_fill(self, queue_ahead: float, drain: float, tau: float) -> float:
        """Crude queue-drain estimate; swap in your calibrated fill model."""
        if drain <= 0: return 0.0
        return min(1.0, drain * tau / max(queue_ahead + self.qty, 1e-9))

    def on_tick(self, t, bid, ask, queue_ahead, drain):
        if self.state == State.DONE: return []
        if self.t0 is None: self.t0 = t
        left = self.qty - self.filled
        elapsed, remain = t - self.t0, self.window - (t - self.t0)
        touch = bid if self.side == "buy" else ask

        if elapsed >= self.cfg.escalate_frac * self.window and left > 0:
            self.state = State.CROSSING          # deadline: pay up, finish
            return [("cross", left)]

        if self.state == State.IDLE:
            if self.p_fill(queue_ahead, drain, remain) >= self.p_star(ask - bid, remain):
                self.state, self.px = State.POSTED, touch
                return [("post", touch, left)]    # GTX / post-only
            self.state = State.CROSSING           # posting is -EV here
            return [("cross", left)]

        if self.state == State.POSTED:
            if abs(touch - self.px) / self.cfg.tick > self.cfg.reprice_band:
                self.px = touch                   # hysteresis breached:
                return [("cancel_replace", touch)]  # accept the queue reset
        return []

    def on_fill(self, t, fill_qty):
        self.filled += fill_qty
        if self.filled >= self.qty - 1e-9:
            self.state = State.DONE
            return [("slice_done", self.filled)]
        return []

    def on_budget_cut(self, new_qty):
        """Scheduler revised the slice down: amend-down keeps queue priority
        where documented (CME, Binance spot amend/keepPriority)."""
        self.qty = new_qty
        left = new_qty - self.filled
        return [("amend_down", left)] if left > 0 else [("cancel",)]

정직한 세 가지 단서가 있다. 여기서 p_fill은 자리표시자 비율일 뿐이다 — 프로덕션에서는 체결 시뮬레이션 아티클에서 다룬, 버킷화되고 실시간으로 캘리브레이션된 모델이어야 한다. 왜냐하면 post/cross 게이트 전체가 이 추정치만큼만 좋을 수 있기 때문이다. adverse_frac은 이 글에서 가장 다루기 어려운 값을 감추고 있다(δ\delta는 국면 의존적이며 포스팅이 가장 유혹적일 때 정확히 급등한다). 이는 자신의 미체결 결과로부터, 변동성 국면별로 버킷화하여 추정해야 한다. 그리고 위 엔진은 무조건적으로 cancel-replace를 통해 리프라이싱한다 — 거래소를 인식하는 버전이라면 수량 감소 변경을 우선순위 보존 경로로 라우팅하고, 모든 액션을 메시지 예산에 대해 부과해야 한다.

어떤 파라미터든 믿기 전에 리플레이 테이프에 대해 시뮬레이터 안에서 돌려보라. 중요한 실험은 이렇다. 스케줄러를 고정하고, escalate_fracreprice_band를 스윕하며, 슬라이스 부족분을 η\eta가 암시하는 모델 비용에 대해 플롯하라. 그 표면에는 평평한 지대(근사 최적 파라미터의 넓은 밴드)와 두 개의 절벽이 있다. 너무 늦게 에스컬레이션하는 것(미체결 잔량이 모멘텀 속으로 크로스되는 것)과 너무 성급하게 리프라이싱하는 것(모든 큐 가치가 소진되는 것)이다. 프로덕션이 당신 대신 그 절벽을 찾아주기 전에, 어디에 있는지 미리 알아두어야 한다.

정리

  1. 두 계층, 하나의 계약. 스케줄러는 얼마나 많이, 언제까지를 결정한다. 전술은 어떻게를 결정한다. 인터페이스는 아래로는 예산, 윈도우, 긴급도이고 위로는 체결과 구간 도착 대비 슬라이스 부족분이다. 부족분을 어느 계층 탓으로 돌릴 수 없다면, 어느 쪽도 튜닝할 수 없다.
  2. post/cross 게이트는 감이 아니라 산술이다. Π=s+ftfm\Pi = s + f_t - f_m일 때 p>δ/(Π+δ)p > \delta/(\Pi + \delta)이면 포스트하라. 타이트한 크립토 호가창에서는 상금이 곧 수수료 차이이므로, 당신의 수수료 등급이 당신의 전술을 결정한다 — 재등급될 때마다 사다리를 재튜닝하라.
  3. 시간 경과 타이머는 두 곡선의 교차점이다 — 포화하는 체결 확률과 τ\sqrt{\tau}로 증가하는 역선택의 교차점이지, 민간전승 상수가 아니다.
  4. 큐 포지션은 자산이다. 그것을 쓰기 전에 각 거래소의 amend 시맨틱을 알아야 한다. CME: 수량 감소가 우선순위를 유지한다. Binance 현물: cancelReplace는 항상 재큐잉하며, 2025년의 amend-keepPriority는 수량 감소에 대해 우선순위를 보존한다. Binance 선물: 모든 modify가 재큐잉한다. OKX: 문서화되지 않았다 — 직접 측정하고, 그때까지는 최악을 가정하라.
  5. 아이스버그는 큐 맨 뒤 주문들의 시퀀스이며, 게으르게 구현된 것들은 읽힌다. 일정한 피크와 동일 타임스탬프 리필은 이미 발표된 탐지 시그니처다. 사이즈와 타이머를 무작위화하거나, 백런당할 각오를 하라.
  6. 상태 머신을 먼저 체결 시뮬레이터에 태워라. 전술 계층은 백테스트와 프로덕션이 가장 크게 갈라지는 스택 부분이다 — 바로 그렇기 때문에 나중에 덧붙이는 것이 아니라 시뮬레이터 안에 처음부터 속해 있어야 한다.

Useful links

  1. Harris, L. — Optimal Dynamic Order Submission Strategies in Some Stylized Trading Problems, Financial Markets, Institutions & Instruments 7(2), 1-76 (1998)
  2. Cont, R., Kukanov, A. — Optimal Order Placement in Limit Order Markets, Quantitative Finance 17(1), 21-39 (2017)
  3. Frey, S., Sandås, P. — The Impact of Iceberg Orders in Limit Order Books (2009)
  4. Bessembinder, H., Panayides, M., Venkataraman, K. — Hidden Liquidity: An Analysis of Order Exposure Strategies in Electronic Stock Markets, Journal of Financial Economics 94(3), 361-383 (2009)
  5. van Kervel, V., Menkveld, A. — High-Frequency Trading around Large Institutional Orders, Journal of Finance 74(3), 1091-1137 (2019)
  6. Moallemi, C., Yuan, K. — A Model for Queue Position Valuation in a Limit Order Book (2016)
  7. Lehalle, C.-A. — Market Microstructure Knowledge Needed for Controlling an Intra-Day Trading Process (2011)
  8. Binance Spot API — Order Amend Keep Priority
  9. Binance Spot API — Trading endpoints (cancelReplace semantics)
  10. Binance USDT-M Futures API — Modify Order
  11. OKX API v5 — Amend order
  12. CME Group — Order Functionalities (modification and time priority)

Citation

@article{soloviov2026childordertactics,
  author = {Soloviov, Eugen},
  title = {Inside the slice: child-order tactics between your scheduler and the exchange},
  year = {2026},
  url = {https://marketmaker.cc/blog/child-order-execution-tactics},
  description = {The tactics layer between execution schedulers and the exchange: passive-then-aggressive escalation with maker-taker break-even math, amend vs cancel-replace queue semantics across venues, iceberg anti-signaling, and a per-slice Python state machine for fill simulators.}
}
blog.disclaimer

Authors

Eugen Soloviov
Eugen Soloviov

Trading-systems engineer

Trading-systems engineer building bots since 2017: cross-exchange arbitrage (connected up to 30 venues), cointegration-based pairs arbitrage across spot and futures, scalping, news and sentiment-driven strategies, trend algorithms, and portfolio management and balancing algorithms. Also builds sub-millisecond order execution, big-data warehouses, backtesting engines, AI agents, and trading interfaces (incl. open-source profitmaker.cc). Stack: JS/TS, Python, Rust/Zig/Go, DevOps, backend, frontend, architecture.

Newsletter

시장에서 앞서 나가세요

뉴스레터를 구독하여 독점적인 AI 트레이딩 통찰력, 시장 분석 및 플랫폼 업데이트를 받아보세요.

귀하의 개인정보를 존중합니다. 언제든지 구독을 취소할 수 있습니다.