누적 차액 정산

예시 하나로 따라가기

매수는 지정가 이하 호가부터 채우므로, 실제 체결가는 74,300 → 74,400 → 74,500으로 올라간다. 아래에서 색이 진한 구간이 그 회차에 새로 더해진 대금이고, 오른쪽 두 숫자가 누적 수수료와 거기서 뽑아낸 이번 회차 수수료다.

44원과 45원은 어디서 나왔나

수수료율은 0.01%, 원 단위 반올림이다. 두 방식이 갈리는 건 “무엇에 요율을 곱하느냐” 하나뿐이다.

나눠 사는 게 유리해지면 안 된다. 회차 수는 워커가 언제 돌았는지, 그때 호가에 물량이 얼마나 있었는지로 결정된다 — 사용자가 고른 게 아니다. 그것 때문에 수수료가 달라지면 설명할 방법이 없다. 지금은 1원이지만 금액이 커지고 분할 횟수가 늘면 오차도 같이 커진다.

숫자 전체

전량 체결이라 남은 동결액 700원은 예수금으로 환급된다. 지정가 74,500원으로 잡아둔 6주분(447,000원)보다 실제로 700원 싸게 샀기 때문이다. 부분 체결로 끝났다면 남은 동결액은 그대로 묶인 채 다음 체결이나 만료를 기다린다.

여기서 나오는 반직관적 결과

그래서 수량을 이진 탐색한다

동결액이 모자랄 때 “얼마나 살 수 있나”를 역산할 수 없다. 수량이 늘면 결제액도 늘긴 하는데, 누적 반올림 때문에 그 관계가 매끄러운 식이 아니다. 그래서 1주부터 최대 수량 사이를 재보면서 들어가는 최댓값을 찾는다.

long low = 1, high = quantity.longValueExact(), best = 0;
while (low <= high) {
    long mid = low + (high - low) / 2;
    LimitOrderSettlementResult candidate = calculate(..., BigDecimal.valueOf(mid), ...);
    if (candidate == null || candidate.netAmountKrw().compareTo(cash.subtract(BigDecimal.ONE)) > 0) {
        high = mid - 1;
    } else {
        if (candidate.isExecutable()) best = mid;
        low = mid + 1;
    }
}

확정 계층이 깐깐한 이유

이 방식은 previous, 즉 지금까지의 누적이 정확할 때만 성립한다. 한 번 틀어지면 이후 모든 회차의 차액이 틀어진다. 그래서 락을 잡은 직후, 체결 이력을 합산한 값과 주문에 저장된 누적 컬럼을 하나하나 대조한다.

if (previous.quantity().compareTo(order.getFilledQuantity()) != 0
        || previous.grossAmountKrw().compareTo(order.getGrossAmount()) != 0
        || previous.feeKrw().compareTo(order.getFee()) != 0
        || previous.taxKrw().compareTo(order.getTax()) != 0
        || executions.countByOrderId(...) != order.getExecutionCount()) throw internal("누적 체결 불일치");