AI 바이브코딩 — 바이낸스 선물 자동매매 실전

바이낸스 선물 자동매매 결과 2026년 7월

creator88837 — Mon, 3 Aug 2026 21:45:31 +0900

2026년 7월 봇별 운영 결과

7월 매매 결과

5개 봇 7월초·말 잔고, 거래횟수, 승률, PF, 순손익, 월 수익률 전체 수치.

2026년 7월 청산 사유별 손익 breakdown

청산 사유

EXIT_SIGNAL, STOP_LOSS, TAKE_PROFIT, RANGE_EXIT 사유별 건수와 손익 상세.

데이터 출처

바이낸스 API(fapiPrivateGetIncome, 잔고/실현손익/수수료/펀딩비) + 각 봇 로그 파일(거래횟수/승률/PF)
7월초잔고 = 6월말잔고 연결 / 7월말잔고 = 포지션 없을 때 안정적인 총잔고 기준

특이사항

1봇(BTC): 7월말잔고 $312.77은 Jul 31 17:00 RANGE_EXIT 청산 직후 무포지션 순간 잔고. TP 1건(+$48.67, Jul 1)이 월 수익 대부분 견인.

2봇(ETH): 7월 초 전략 교체 후 7/23 재설정, 7/24부터 첫 정상 거래. 7회 거래 중 SL 1건(-$11.02)이 손실 견인, 나머지 5승 순익 +$11.02로 PF 0.86.

3봇(ONDO): 순손익 -$12.28 = 7월초 출금 ~$156 + 7월말 입금 ~$143 + 거래 PnL +$1.51 (27회). 거래 자체는 소폭 플러스이나 입출금 조정으로 잔고 순감.

4봇(ONDO): 출금/입금 없이 순수 거래 +$60.01. 7/23 13:00 EXIT_SIGNAL +$50.91 (ONDO 급등 롱 보유) 1건이 월 수익 견인. PF 2.80으로 7월 전 봇 중 최고.

5봇(XRP): 7월말잔고 $248.03은 Jul 30 마지막 거래 청산 후 무포지션 잔고. 5봇 계좌 실자본은 7월 내내 $248~$256대.

바이낸스 선물 자동매매 결과 2026년 6월

creator88837 — Mon, 3 Aug 2026 21:27:21 +0900

2026년 6월 봇별 운영 결과

6월 매매 결과

5개 봇 6월초·말 잔고, 거래횟수, 승률, PF, 순손익, MDD, Sharpe 전체 수치.

2026년 6월 청산 사유별 손익 breakdown

청산 사유

EXIT_SIGNAL, STOP_LOSS, TAKE_PROFIT, 기타 사유별 건수와 손익 상세.

데이터 출처

바이낸스 API(잔고/실현손익/수수료/펀딩비) + 각 봇 로그 파일(거래횟수/승률/PF)
계산 방식: 6월초·6월말 잔고는 현재잔고에서 이후 발생한 income을 역산한 값. 계좌 내 입출금이 있었다면 오차 가능.
MDD·Sharpe는 거래소 실현손익 기준 자본곡선(실제 달러), 거래횟수·승률·PF는 봇 로그의 청산 기록 기준. 거래소 raw 데이터는 부분체결로 건수가 부풀려짐.

특이사항

1봇(BTC): 6월 내내 TP/SL이 수량 0으로 잡히는 버그 상태. EXIT_SIGNAL 청산 2건만 실제 발생. 6/30 버전 교체로 해결.

2봇(구 ONDO KDJ 2h): 6월 순손익 -$94.33(-65.05%)로 전 봇 중 최악. PF 0.41, Sharpe -7.74, MDD -66.97% 전 지표 최하. EXIT_SIGNAL 청산 30건에서 -$113.5 손실이 대부분을 차지함. TP/SL보다 반대신호 청산에서 훨씬 많이 잃음.

3봇·4봇(ONDO): PF 각각 0.74, 0.62로 6월은 손실 구조. ONDO 계열 봇 3개가 전부 마이너스 — 6월 ONDO 시장이 KDJ 전략에 불리한 횡보였을 가능성.

5봇(XRP): 승률 38.1%로 낮지만 PF 1.40, Sharpe 2.46으로 유일하게 플러스. 익절 크기가 손절을 압도하는 추세추종형 결과.

바이낸스 자동매매 TP SL 설정, 백테스트 수백 번으로 찾는 법

creator88837 — Sat, 25 Jul 2026 18:44:53 +0900

바이낸스 선물 자동매매 봇에서 같은 전략이라도 파라미터 설정에 따라 결과가 완전히 달라진다.
수익률 1,350%짜리 전략도 TP와 SL 수치를 잘못 잡으면 실전에서 손실이 난다.
이 글에서는 TP, SL, 레버리지 최적값을 어떻게 찾는지, 그 과정에서 주의할 점은 무엇인지를 실전 백테스트 경험을 바탕으로 정리한다.

파라미터란 무엇인가

파라미터는 봇의 동작을 결정하는 수치 설정값이다.
코드 안에 숫자로 박혀있고, 이 숫자를 바꾸면 봇의 행동 방식이 달라진다.

자동매매 봇에서 가장 중요한 파라미터는 세 가지다.

TP(Take Profit, 익절): 진입 가격 대비 몇 % 수익이 나면 자동으로 청산할지 설정한다.
TP가 5%면 진입 후 5% 오르면(LONG 기준) 자동 청산된다.

SL(Stop Loss, 손절): 진입 가격 대비 몇 % 손실이 나면 자동으로 청산할지 설정한다.
SL이 3%면 진입 후 3% 내려가면 자동 청산된다.

레버리지(Leverage): 내 증거금의 몇 배로 포지션을 잡을지 설정한다.
레버리지 5배면 $100 증거금으로 $500짜리 포지션을 잡는다.
레버리지가 높을수록 수익도 크고 손실도 크다.

이 세 가지 외에도 타임프레임, 진입 조건 수치(예: MACD 파라미터)도 파라미터에 해당한다.
하지만 TP, SL, 레버리지가 결과에 가장 직접적인 영향을 준다.

파라미터 하나가 전체 결과를 바꾸는 이유

전략 자체는 같아도 TP와 SL 비율을 어떻게 잡느냐에 따라 전혀 다른 봇이 된다.

TP를 낮게 잡으면 (예: 3%):
자주 익절된다. 승률이 올라간다.
하지만 한 번의 수익이 작아서 손절 한 번에 여러 번의 수익이 날아간다.
거래 횟수가 많아지고 수수료 부담이 커진다.

TP를 높게 잡으면 (예: 20%):
익절 조건이 까다롭다. 승률이 내려간다.
하지만 한 번 익절될 때 수익이 크다.
거래 횟수가 줄어들고 수수료 부담이 작아진다.

어느 쪽이 맞는지는 전략에 따라 다르다.
추세 추종 전략은 TP를 크게 잡아야 트렌드를 다 먹을 수 있다.
반전 전략은 TP를 작게 잡아야 빠르게 수익을 확정한다.

직접 수백 번 백테스트를 돌려서 알게 된 것이다.
처음에는 TP를 높이면 당연히 수익률이 올라간다고 생각했다.
실제로는 승률이 너무 낮아져서 MDD가 커지고 실전에서 버티기 힘든 구조가 됐다.
반대로 TP를 낮추면 승률은 높은데 수익이 너무 작아서 손절 몇 번에 다 깎이는 경우도 생겼다.
TP와 SL 사이의 균형점을 찾는 게 핵심이다.

파라미터 최적값을 찾는 방법

백테스트를 반복해서 비교하는 방법이 유일하다.
수치를 조금씩 바꿔가며 결과를 보고, 가장 균형이 좋은 조합을 선택한다.

순서는 이렇다.

1단계 — TP부터 고정하고 SL을 바꾼다.
TP를 10%로 고정하고 SL을 2%, 3%, 5%, 7%로 바꿔가며 백테스트를 돌린다.
각각의 수익률, MDD, 승률, 거래 횟수를 기록한다.

2단계 — SL을 고정하고 TP를 바꾼다.
1단계에서 가장 좋았던 SL 값을 고정하고 TP를 5%, 10%, 15%, 20%로 바꿔가며 돌린다.

3단계 — 레버리지를 바꾼다.
가장 좋은 TP/SL 조합을 찾은 후, 레버리지를 2배, 3배, 5배로 바꿔가며 결과를 비교한다.
레버리지가 높아질수록 MDD도 같은 비율로 커진다는 걸 확인한다.

[AI에게 시킨 명령어]
"TP를 5%, 10%, 15%, 20%로 바꿔가며 각각 백테스트 결과를 출력해줘. 수익률, MDD, 승률, 거래 횟수를 표 형태로 보여줘"

이 명령어 하나로 파라미터 비교 테이블을 자동으로 만들 수 있다.
수동으로 수치를 바꿔가며 돌릴 필요 없이 한 번에 여러 결과를 볼 수 있다.

TP·SL 조합별 백테스트 결과 비교

TP·SL 조합 4가지의 수익률, MDD, 승률, 거래 횟수를 비교한 예시 표.

실전에서 파라미터를 바꿔 결과가 달라진 경험

1봇 BTC 봇 업그레이드 과정에서 파라미터 변경으로 결과가 크게 바뀐 경험이 있다.

처음에는 TP 7%로 운영했다.
백테스트에서는 나쁘지 않았다.
실전 6개월을 운영하고 결과를 보니 수익이 났지만 MDD가 컸다.

타임프레임을 4시간봉에서 8시간봉으로 바꾸고 TP를 19%로 올렸다.
같은 KDJ 전략인데 파라미터만 바꿨다.
백테스트 결과가 달라졌다.
거래 횟수는 줄었지만 한 번 수익이 날 때 더 크게 났고, MDD가 안정됐다.

파라미터 변경 전후 비교:
타임프레임 4h / TP 7% → 거래 잦음, 수수료 부담 큼
타임프레임 8h / TP 19% → 거래 적음, 수익폭 큼

어느 쪽이 낫다고 단정할 수 없다.
코인의 특성, 시장 상황, 자신이 감당할 수 있는 MDD 수준에 따라 달라진다.
중요한 건 직접 백테스트로 확인하는 과정이다.
MDD가 왜 이렇게 중요한지 이해가 안 된다면 자동매매 백테스트에서 MDD가 중요한 이유(실용글 7)를 먼저 읽는 걸 추천한다.

과최적화를 조심해야 하는 이유

파라미터 최적화에서 가장 조심해야 할 함정이 과최적화다.
백테스트 데이터에만 딱 맞게 설정값을 찾다 보면, 그 기간에만 좋고 실전에서는 안 되는 파라미터가 나온다.

예를 들어 2023년~2025년 데이터로 최적화한 파라미터가 2026년 시장에서 작동 안 할 수 있다.
2023~2025 기간의 특수한 흐름에 딱 맞게 조정된 값이기 때문이다.

과최적화를 피하는 방법이 있다.

첫째, 백테스트 기간을 길게 잡는다.
최소 2~3년 이상의 데이터로 테스트하는 게 맞다.
단기 데이터로 최적화하면 그 구간의 특성에만 맞는 값이 나온다.

둘째, 최적값보다 안정적인 값을 선택한다.
백테스트에서 수익률이 제일 높은 값이 아니라, 여러 구간에서 꾸준히 좋은 값을 선택한다.
극단적으로 좋은 값은 그 기간에만 맞는 경우가 많다.

셋째, 실전으로 검증한다.
백테스트로 찾은 파라미터도 실전 소액 운영으로 1년 이상 검증해야 한다.
백테스트와 실전이 다르게 나오면 파라미터를 다시 점검한다.

결론

파라미터 최적화는 백테스트를 반복하는 과정이다.
TP, SL, 레버리지를 하나씩 바꿔가며 수익률, MDD, 승률이 어떻게 달라지는지 직접 확인해야 한다.

순서는 이렇게 잡는다.
TP를 먼저 고정하고 SL을 찾는다.
SL을 고정하고 TP를 찾는다.
마지막으로 레버리지를 조정한다.

주의할 점은 두 가지다.
TP가 높다고 무조건 좋지 않다. 승률이 낮아지고 MDD가 커진다.
백테스트에서 가장 좋은 값이 실전에서도 좋으리라는 보장이 없다.
과최적화를 피하려면 긴 기간 데이터로 검증하고, 실전으로 다시 확인하는 과정이 필요하다.

매일 새벽까지 백테스트를 돌린 시간이 지금의 봇 운영 기반이 됐다.
결국 TP와 SL에는 정답이 없다.
정답처럼 보이는 숫자는 직접 반복한 백테스트와 실전 검증을 통해서만 찾을 수 있다.

함께 읽으면 좋은 글

2026.05.30 - [바이낸스 선물 자동매매] - 7화 자동매매 백테스트, 수익률보다 MDD가 중요한 이유

2026.06.21 - [바이낸스 선물 자동매매] - 백테스트 파라미터 수정, 메모장으로 익절 손절 바꾸는 법

2026.06.14 - [바이낸스 선물 자동매매] - 11화 바이낸스 자동매매, 연 60% 수익에서 멈추는 이유

KDJ 자동매매 ONDO 백테스트, MDD -72%가 발목을 잡은 이유

creator88837 — Sat, 25 Jul 2026 18:32:55 +0900

바이낸스 선물 자동매매에서 KDJ 전략을 ONDO에 적용한 백테스트 결과를 정리했다.
수익률은 높게 나왔다.
문제는 MDD였다.
이 글에서는 KDJ 지표의 기본 개념부터 실전 백테스트 결과, 그리고 MDD가 왜 자동매매에서 결정적인 지표인지를 실제 데이터를 바탕으로 정리한다.

KDJ 지표란 무엇인가

KDJ는 스토캐스틱(Stochastic) 오실레이터를 발전시킨 지표다.
스토캐스틱은 현재 가격이 일정 기간의 가격 범위에서 어느 위치에 있는지를 보여주는 지표다.
KDJ는 여기에 J선을 추가해서 신호를 더 빠르게 포착한다.

세 개의 선으로 구성된다.
K선, D선, J선이다.

K선은 스토캐스틱의 기본 선이다.
일정 기간(기본값 9) 동안의 최고가와 최저가 범위에서 현재 종가의 위치를 0~100으로 표시한다.
가격이 최고점에 가까울수록 100에 가깝고, 최저점에 가까울수록 0에 가깝다.

D선은 K선의 이동평균이다.
기본값은 3기간이다.
K선보다 느리게 움직인다.

J선은 K선과 D선의 차이를 증폭한 선이다.
계산식은 3K - 2D다.
그래서 0~100 범위를 벗어나기도 한다.
가격 변화에 가장 먼저 반응하고, 변동폭도 가장 크다.

KDJ에서 매수·매도 신호를 읽는 법

KDJ는 두 가지 방식으로 신호를 읽는다.
과매수·과매도 구간과 크로스 신호다.

과매수·과매도 구간:
K와 D가 80 이상이면 과매수 구간이다. 가격이 너무 올라서 조정이 올 수 있다는 의미다.
K와 D가 20 이하이면 과매도 구간이다. 가격이 너무 내려서 반등이 올 수 있다는 의미다.

크로스 신호:
K선이 D선을 아래에서 위로 뚫으면 골든크로스다. 상승 신호로 본다.
K선이 D선을 위에서 아래로 뚫으면 데드크로스다. 하락 신호로 본다.

자동매매에서는 두 조건을 함께 쓰는 게 일반적이다.
과매도 구간(K, D 모두 20 이하)에서 골든크로스가 나오면 LONG 진입.
과매수 구간(K, D 모두 80 이상)에서 데드크로스가 나오면 SHORT 진입.
둘 중 하나만 쓰면 오신호가 많아진다.

J선은 단독 신호로 쓰기도 한다.
J선이 0 이하로 내려가면 극단적 과매도, 100 이상이면 극단적 과매수로 본다.
방향 전환이 올 가능성이 높은 구간이다.

KDJ를 자동매매 코드로 만드는 방법

파이썬에서 KDJ는 직접 계산 방식으로 구현한다.

[AI에게 시킨 명령어]
"2시간봉 기준으로 KDJ 지표를 계산하고, K가 D를 골든크로스할 때 LONG 신호, 데드크로스할 때 SHORT 신호를 잡는 코드 작성해줘. K와 D가 모두 20 이하일 때만 LONG, 80 이상일 때만 SHORT 허용하도록"

KDJ 계산 코드:
low_min = df['low'].rolling(window=9).min()
high_max = df['high'].rolling(window=9).max()
rsv = (df['close'] - low_min) / (high_max - low_min) * 100
df['K'] = rsv.ewm(com=2).mean()
df['D'] = df['K'].ewm(com=2).mean()
df['J'] = 3 * df['K'] - 2 * df['D']

LONG 진입 조건 코드:
long_signal = (
    (df['K'] > df['D']) &
    (df['K'].shift(1) <= df['D'].shift(1)) &
    (df['K'] < 20) &
    (df['D'] < 20)
)
K가 D를 아래에서 위로 돌파하고, K와 D가 모두 20 이하일 때만 LONG으로 진입한다.

SHORT 진입 조건 코드:
short_signal = (
    (df['K'] < df['D']) &
    (df['K'].shift(1) >= df['D'].shift(1)) &
    (df['K'] > 80) &
    (df['D'] > 80)
)
K가 D를 위에서 아래로 돌파하고, K와 D가 모두 80 이상일 때만 SHORT으로 진입한다.

ONDO 2h 백테스트 결과표

KDJ 전략 ONDO 백테스트 결과 비교표

초기 설정과 파라미터 최적화 후 결과를 나란히 정리한 표. 수익률, MDD, 거래 횟수, 승률 비교.

ONDO 봇 백테스트 결과

2봇에 ONDO/USDT 2시간봉 기준으로 KDJ 전략을 적용하고 백테스트를 돌렸다.
기간은 2024년 1월부터 2026년 4월까지, 초기 자본 $150, 레버리지 2배 기준이다.
거래 횟수는 1,153회였다.

실제로 2봇은 운영 초반에 전략을 여러 번 바꿨다.
지금 보는 수치는 KDJ 전략으로 전체 기간을 시뮬레이션한 백테스트 결과다.

수익률은 높게 나왔다.
2024년이 특히 컸다.
ONDO가 코인 출시 초반이라 방향이 뚜렷한 상승장이었기 때문이다.
KDJ는 추세가 있을 때 강하다.
방향이 잡히면 신호가 맞아 떨어지고 익절이 쌓인다.
2024년 결과가 크게 나온 건 이 때문이다.

2025년, 2026년으로 갈수록 결과가 줄어들었다.
ONDO의 상승 에너지가 꺾이면서 KDJ 신호가 자주 빗나가기 시작했다.

그리고 MDD가 문제였다.
전체 구간 MDD가 -72.78%였다.

KDJ 신호가 통하는 장과 통하지 않는 장

KDJ는 가격이 한 방향으로 움직이는 추세 장에서 강하다.
K선과 D선이 교차하면서 방향이 잡히고, 신호대로 수익이 쌓인다.

반대로 방향 없이 위아래를 반복하는 횡보 장에서는 약하다.
신호가 나올 때마다 진입하는데, 가격이 방향을 못 잡으니 진입할 때마다 손실이 쌓인다.

ONDO는 2024년 출시 초반에 강한 상승 추세를 탔다.
그 구간에서 KDJ 신호가 잘 맞아 떨어지며 수익이 쌓였다.
2025년부터는 흐름이 꺾이면서 횡보 구간이 길어졌다.
KDJ 신호는 계속 나오는데 방향이 없어서 잔손절이 반복됐다.

연도별 백테스트 수익률이 이 흐름을 그대로 보여준다.

2024년: +882% (백테스트 기준)
2025년: +229% (백테스트 기준)
2026년 (4개월): +103% (백테스트 기준)
누적 합계: +6,442% (백테스트 기준)

수익률 자체는 전부 플러스지만, 2024년 대비 이후 구간이 급격히 줄어든다.
시장 환경이 달라진 만큼 KDJ 신호의 정확도도 달라진 결과다.

MDD -72%가 실전에서 의미하는 것

MDD -72.78%는 원금의 70% 넘게 줄어드는 구간이 생긴다는 뜻이다.
백테스트 화면에서 보면 그냥 숫자다.

실제로 봇 운영 중 잔고가 $50 수준까지 줄어든 시기가 있었다.
전략을 여러 번 교체한 결과이지만, KDJ 전략의 높은 MDD가 영향을 준 건 분명했다.
그 구간에서 버티지 못하고 봇을 끄면 이후 반등을 전부 놓친다.
수익률이 아무리 높게 나와도 실전에서 봇을 계속 돌리지 못하면 의미가 없다.
보통 이 구간에서 버티지 못하고 봇을 끄게 된다.
봇을 끄는 순간 그 뒤에 오는 반등을 전부 놓친다.
수익률이 아무리 높게 나와도 실전에서 봇을 계속 돌리지 못하면 의미가 없다.

MDD가 높아진 이유는 KDJ 전략의 특성에 있다.
KDJ는 빠른 지표다.
신호가 자주 나온다.
추세 장에서는 이게 장점이지만, 횡보 구간에서는 신호가 나올 때마다 진입하다가 잔손절이 쌓인다.

실제로 2봇, 3봇, 4봇이 ONDO를 거래했는데 6월에 셋 다 같이 무너졌다.
ONDO가 횡보하던 구간이었다.
KDJ가 계속 신호를 냈고 봇은 계속 들어갔다 나오고, 들어갔다 나오기를 반복했다.
그 경험을 정리한 글이 있다.

2026.07.09 - [바이낸스 선물 자동매매] - 바이낸스 봇 리스크 분산, 같은 코인에 3개 몰았더니 다 같이 -$183

파라미터를 바꿔서 테스트해봤는데

MDD를 낮추려고 파라미터를 바꿔가며 여러 번 테스트했다.
period, signal, TP, SL, OB 값을 다르게 조합했다.

거래 횟수는 1,153회에서 858회로 줄었다.
MDD는 -72.78%에서 -66.28%로 소폭 개선됐다.

수치상으로는 줄었다.
하지만 여전히 -66%다.
$150이 약 $51로 줄어드는 구간이 생긴다는 뜻이다.
실전 기준으로 크게 다르지 않다.

파라미터를 바꾸는 방식으로는 이 전략의 MDD를 실전 운영이 가능한 수준까지 낮추기 어렵다는 결론이 나왔다.
전략 구조 자체의 한계였다.

결론

KDJ는 빠른 신호가 장점인 지표다.
추세가 뚜렷한 장에서는 백테스트 수익률이 높게 나온다.

하지만 MDD를 먼저 봐야 한다.
수익률이 아무리 높아도 MDD가 -70%를 넘으면 실전에서 버티기 어렵다.
파라미터 최적화로도 MDD가 안 내려온다면 전략 구조 자체를 바꿔야 한다.

백테스트를 볼 때 수익률과 MDD를 함께 보는 습관이 자동매매에서 가장 중요한 것 중 하나다.
높은 수익률보다 낮은 MDD가 실전에서 더 오래 살아남는다.
이번 ONDO KDJ 백테스트가 그 사실을 다시 확인한 사례였다.

함께 읽으면 좋은 글

2026.05.30 - [바이낸스 선물 자동매매] - 7화 자동매매 백테스트, 수익률보다 MDD가 중요한 이유

2026.07.25 - [바이낸스 선물 자동매매] - 바이낸스 자동매매 TP SL 설정, 백테스트 수백 번으로 찾는 법

바이낸스 헤지 모드와 원웨이 모드 차이, 자동매매는 무엇이 좋을까

creator88837 — Sun, 19 Jul 2026 17:56:12 +0900

바이낸스 선물 자동매매 봇을 만들 때 포지션 모드를 선택해야 한다.
헤지 모드(Hedge Mode)와 원웨이 모드(One-way Mode) 두 가지다.
인터넷에는 무조건 헤지 모드를 사용해야 한다는 설명이 많다.
하지만 봇 구조에 따라 오히려 원웨이 모드가 더 단순하고 오류도 적다.
이 글에서는 두 모드의 차이, 각각 어떤 경우에 맞는지를 실전 경험을 바탕으로 정리한다.

원웨이 모드와 헤지 모드의 차이

원웨이 모드(One-way Mode)는 한 코인에 한 방향만 포지션을 가질 수 있다.
LONG이 열려있으면 SHORT을 추가로 열 수 없다.
LONG 상태에서 SHORT 주문을 넣으면 기존 LONG이 청산되고 SHORT이 새로 열린다.
방향이 바뀌는 순간 기존 포지션이 자동으로 정리되는 구조다.

헤지 모드(Hedge Mode)는 같은 코인에 LONG과 SHORT을 동시에 가질 수 있다.
LONG이 열려있어도 별도로 SHORT을 열 수 있다.
두 포지션은 서로 독립적으로 존재한다.
코드에서 positionSide 파라미터로 각 주문이 어느 포지션에 해당하는지 명시해야 한다.

바이낸스 선물의 기본값은 원웨이 모드다.
계정을 새로 만들면 원웨이 모드로 시작된다.

원웨이 모드가 맞는 경우

봇이 순차적으로 거래한다면 원웨이 모드로 충분하다.

순차적 거래란 이런 구조다.
LONG 진입 → TP 또는 SL로 청산 → SHORT 진입 → TP 또는 SL로 청산 → 다시 LONG 진입.
한 번에 한 방향만 보유하고, 청산된 뒤에 다음 포지션을 연다.

이 구조에서 원웨이 모드의 장점은 코드가 단순하다는 점이다.
positionSide 파라미터를 넣을 필요가 없다.
MARKET 청산 주문에 reduceOnly를 써도 오류가 없다.
방향 전환도 자연스럽다. LONG 포지션이 청산되면 SHORT 주문을 넣으면 된다.

여러 봇을 운영하더라도 봇마다 바이낸스 서브계정을 따로 만들고 각자 API 키를 쓴다면 봇끼리 간섭이 없다.
봇 2가 XRP SHORT을 들고 있어도, 봇 3이 별도 서브계정에서 XRP LONG을 열면 완전히 독립적이다.
이 경우 원웨이 모드로 충분하다.

원웨이 모드 VS 헤지 모드 비교

바이낸스 헤지 모드 vs 원웨이 모드 비교표

봇 구조별로 어떤 모드가 적합한지, 코드 차이, 오류 위험을 한눈에 정리한 표.

헤지 모드가 필요한 경우

내가 운영해 본 자동매매 기준에서는 헤지 모드가 꼭 필요한 경우가 한 가지 있었다.
봇 하나가 LONG을 닫지 않은 채 SHORT을 추가로 열어야 할 때다.

예를 들어 이런 전략이다.
XRP LONG으로 진입한 뒤 하락 신호가 잡히면 SHORT을 추가로 연다.
LONG은 그대로 두고 SHORT을 헤지로 보유하는 구조다.
이 경우 원웨이 모드에서는 SHORT 주문이 LONG을 청산해버린다.
헤지 모드라야 두 포지션이 독립적으로 유지된다.

두 봇이 같은 코인의 반대 방향을 거래하는 경우는 헤지 모드가 필요 없다.
봇마다 서브계정을 따로 만들고 API 키를 각자 쓰면 봇끼리 포지션이 간섭하지 않는다.
서브계정 분리 구조라면 원웨이 모드로도 충분하다.

단순한 추세 추종이나 TP/SL 기반 전략은 한 번에 한 방향만 보유한다.
이런 전략에서 헤지 모드는 굳이 필요하지 않다.

헤지 모드에서 코드가 달라지는 점

헤지 모드를 쓰면 코드에 positionSide를 명시해야 한다.
모든 주문에 LONG 또는 SHORT 방향을 지정해야 한다.

SHORT 진입:
exchange.create_order('BTCUSDT', 'MARKET', 'sell', amount,
                      params={'positionSide': 'SHORT'})

SHORT 청산:
exchange.create_order('BTCUSDT', 'MARKET', 'buy', amount,
                      params={'positionSide': 'SHORT'})

원웨이 모드에서는 positionSide가 필요 없다.

SHORT 진입:
exchange.create_order('BTCUSDT', 'MARKET', 'sell', amount)

SHORT 청산:
exchange.create_order('BTCUSDT', 'MARKET', 'buy', amount,
                      params={'reduceOnly': True})

헤지 모드에서는 MARKET 청산 주문에 reduceOnly를 쓰면 -2022 오류가 난다.
원웨이 모드에서는 reduceOnly가 정상 작동한다.
실용글 20에서 다룬 -2022 오류가 바로 헤지 모드에서 reduceOnly를 쓴 게 원인이었다.

내 봇 운영에서 배운 것

처음 봇을 만들 때 헤지 모드로 설정하고 시작했다.
봇이 자동으로 양방향 거래를 한다고 생각했기 때문이다.

실제로는 서브계정마다 API 키가 달랐고, 각 봇은 순차적으로 거래하고 있었다.
헤지 모드가 굳이 필요하지 않은 구조였다.

그 결과 positionSide를 모든 주문에 넣어야 했고, reduceOnly를 헤지 모드에서 써서 -2022 오류가 났다.
원웨이 모드였다면 겪지 않아도 될 복잡함이었다.

지금 돌이켜보면, 순차적 거래 + 서브계정 분리 구조라면 원웨이 모드가 더 단순하고 오류도 적었을 것이다.

포지션 모드 설정 방법

포지션이 하나도 없는 상태에서만 변경할 수 있다.
포지션이 열려있으면 변경 버튼이 비활성화된다.

바이낸스 선물화면

바이낸스 선물 더보기 메뉴 진입 위치

거래 화면 우측 상단의 ... 버튼을 클릭하면 설정 메뉴로 진입할 수 있다.

바이낸스 선물모드

바이낸스 선물 Preferences 진입 경로

... 버튼 클릭 후 나오는 화면에서 Features 탭 → Preferences를 선택한다.

선물모드 선택화면

바이낸스 선물 포지션 모드 변경 화면

Preferences의 Trading Mode 탭에서 Position Mode를 클릭하면 원하는 모드로 변경할 수 있다.

설정 순서:
1. 바이낸스 선물 거래 화면에서 우측 상단 ... 버튼을 클릭한다.
2. Features 탭에서 Preferences를 선택한다.
3. Trading Mode 탭에서 Position Mode를 클릭한다.
4. 원하는 모드(One-way Mode 또는 Hedge Mode)를 선택한다.

서브계정을 쓰고 있다면 서브계정마다 따로 설정해야 한다.
메인 계정 설정이 서브계정에 적용되지 않는다.

결론

포지션 모드는 봇 구조에 맞게 선택하는 게 맞다.

순차적으로 거래하는 봇 + 서브계정 분리 구조라면 원웨이 모드가 단순하고 오류가 적다.
positionSide 없이 코드를 짤 수 있고, reduceOnly도 자유롭게 쓸 수 있다.

한 봇이 LONG을 닫지 않은 채 SHORT을 동시에 보유해야 하는 전략이라면 헤지 모드가 필요하다.

무조건 헤지 모드가 맞다는 게 아니다.
내 봇이 어떻게 작동하는지 먼저 파악하고, 그에 맞는 모드를 선택하는 게 순서다.

함께 읽으면 좋은 글

2026.05.23 - [바이낸스 선물 자동매매] - 바이낸스 자동매매 API 발급 순서, 서브계정이 먼저인 이유

2026.07.09 - [바이낸스 선물 자동매매] - 바이낸스 봇 청산 실패 -2022 오류, 고쳤는데 다음날 또 터졌다

2026.07.12 - [바이낸스 선물 자동매매] - 바이낸스 자동매매, TP/SL이 한 달 동안 작동 안 된 이유

바이낸스 자동매매, TP/SL이 한 달 동안 작동 안 된 이유

creator88837 — Wed, 15 Jul 2026 09:00:45 +0900

바이낸스 선물 자동매매 봇에서 TP/SL 주문이 한 달 내내 작동하지 않는 버그를 경험했다.
진입은 정상적으로 됐고, 봇 로그에는 "OCO 설정 완료"가 찍혔다.
그런데 실제로는 처음부터 손절도 익절도 걸려있지 않은 상태로 운영되고 있었다.
이 글에서는 원인이 뭐였는지, 어떻게 발견했는지, 어떻게 해결했는지를 실전 로그와 함께 정리한다.

TP/SL 버그를 발견한 과정

2026년 6월 30일, 서버를 재시작하고 점검을 하다가 이상한 걸 발견했다.
거래소에는 SHORT 포지션이 잡혀있는데, fetch_open_orders() 결과가 0건이었다.

포지션이 있으면 TP/SL 주문도 같이 잡혀있어야 정상이다.
그런데 열린 주문이 하나도 없다.

처음에는 서버 재시작 때 주문이 날아간 거라고 생각했다.
그래서 그 시점 이전에 이미 완료된 거래 이력을 직접 조회해봤다.

6월 22일 17:05 진입, 6월 23일 09:00 청산된 거래였다.
거래소 주문 이력에서 STOP_MARKET, TAKE_PROFIT_MARKET을 찾아봤다.
단 한 건도 없었다.

재시작이 원인이 아니었다.
처음부터 TP/SL 주문 자체가 생성되지 않고 있었던 것이다.

원인: closePosition과 수량을 동시에 보내면 수량이 0이 된다 h2

원인은 TP/SL 주문을 만드는 방식에 있었다.

봇이 TP/SL 주문을 걸 때 이렇게 보내고 있었다.

문제 코드:

exchange.create_order(symbol, 'STOP_MARKET', 'sell', amount,
                      params={'stopPrice': sl_price, 'closePosition': True})

closePosition: True는 "포지션 전체를 청산하겠다"는 의미다.
amount는 "이 수량을 청산하겠다"는 의미다.

이 두 가지를 동시에 보내면 충돌이 생긴다.
"전체 청산할게" + "0.008 BTC 청산할게"를 동시에 말하는 것이다.

이 계정에서 STOP_MARKET, TAKE_PROFIT_MARKET 주문은 바이낸스의 Algo 주문 시스템으로 처리된다.
이 시스템은 두 방식이 충돌할 때 에러를 반환하지 않는다.
대신 조용히 수량을 0으로 바꿔서 주문을 만들어버린다.

수량이 0인 주문은 가격이 닿아도 아무것도 안 한다.
이름만 손절/익절 주문이고 실제로는 빈 껍데기였다.

Algo 주문 전용 API로 직접 조회한 결과는 이렇게 나왔다.

type: STOP_MARKET, quantity: 0.0, algoStatus: NEW
type: TAKE_PROFIT_MARKET, quantity: 0.0, algoStatus: NEW

수량이 0인 채로 "열린 상태(NEW)"로 잡혀있었다.
가격이 닿아도 청산할 수량이 없으니 아무 일도 일어나지 않는다.

봇이 정상이라고 착각한 이유

더 큰 문제가 있었다.
봇은 이걸 전혀 모르고 있었다.

TP/SL 주문을 보내고 나서 봇 로그에는 이렇게 찍혔다.
"OCO 설정 완료"

봇이 확인하는 방법이 fetch_open_orders()였는데, 이 방법으로는 Algo 주문이 조회되지 않는다.

일반 조회와 Algo 전용 조회 결과가 다르다.

바이낸스 TP/SL 수량 0 버그

왼쪽은 일반 fetch_open_orders() 결과(0건), 오른쪽은 Algo 전용 조회 결과(수량 0짜리 주문 2건). 같은 계정인데 결과가 다르다.

일반 조회: 0건
Algo 전용 조회: STOP_MARKET / TAKE_PROFIT_MARKET, quantity: '0.0', algoStatus: 'NEW'

봇은 "주문을 냈더니 정상 완료됐다"고 판단하고 다음 단계로 넘어갔다.
그 사이에 수량 0짜리 빈 껍데기 주문이 Algo 시스템 안에 계속 쌓였다.

여기에 또 다른 문제가 있다.
이 수량 0 유령 주문이 "열린 상태(NEW)"로 남아있어서, 다음 진입 때 같은 방향으로 TP/SL 주문을 다시 생성하려 하면 -4130 오류가 나면서 거부됐다.

"이미 같은 방향 closePosition 주문이 있어서 안 된다"는 이유다.
처음엔 TP/SL이 빈 껍데기로라도 생성됐고, 이후 거래부터는 아예 생성조차 안 됐다.
갈수록 막히는 구조였다.

2345봇은 처음부터 왜 괜찮았나

같은 봇 코드로 만든 2봇, 3봇, 4봇, 5봇은 이 문제가 없었다.
차이는 TP/SL 주문을 거는 방식에 있었다.

항목          1봇 (버그 있음)                 2345봇 (정상)
────────────────────────────────────────────────────────────────
TP/SL 생성    closePosition: True + 수량 전달  reduceOnly: True + 수량 명시
취소 방법     fetch_open_orders → cancel_order fapiPrivateDeleteAllOpenOrders
                                                + fapiPrivateDeleteAlgoOpenOrders

2345봇은 "이 수량만큼 청산하고, 포지션 줄이는 용도로만 쓸게(reduceOnly)"라고 말했다.
충돌이 없었다.

1봇은 "전체 청산할게(closePosition), 근데 수량도 이만큼이야"라고 말해서 충돌이 생겼다.

취소도 마찬가지다.
2345봇은 일반 주문 취소 + Algo 주문 취소를 둘 다 호출했다.
1봇은 일반 주문 취소만 호출했다. Algo 주문이 남는 이유였다.

TP/SL 버그 수정 방법

수정은 두 곳이다.

첫 번째, TP/SL 주문 생성 방식 변경.

[AI에게 시킨 명령어]
"closePosition 대신 reduceOnly: True로 바꿔줘. 수량은 amount 그대로 쓰고. 2345봇과 동일한 방식으로"

[수정 전]

exchange.create_order(symbol, 'STOP_MARKET', 'sell', amount,
                      params={'stopPrice': sl_price, 'closePosition': True})

[수정 후]

exchange.create_order(symbol, 'STOP_MARKET', 'sell', amount,
                      params={'stopPrice': sl_price, 'reduceOnly': True,
                              'workingType': 'MARK_PRICE'})

두 번째, 주문 취소 함수 변경.
일반 주문 취소만 하던 것을 Algo 주문 취소도 함께 호출하도록 수정했다.

[수정 전]

orders = exchange.fetch_open_orders(symbol)
for o in orders:
    exchange.cancel_order(o['id'], symbol)

[수정 후]

exchange.fapiPrivateDeleteAllOpenOrders({'symbol': 'BTCUSDT'})
exchange.fapiPrivateDeleteAlgoOpenOrders({'symbol': 'BTCUSDT'})

결론

핵심은 두 가지다.

첫째, closePosition과 amount를 동시에 보내면 안 된다.
Algo 주문 시스템이 충돌을 에러 없이 처리하면서 수량을 0으로 만든다.
봇 로그에는 "설정 완료"가 찍히기 때문에 발견하기 어렵다.

둘째, TP/SL 주문 취소할 때 Algo 주문 API를 따로 호출해야 한다.
일반 fetch_open_orders()로는 Algo 주문이 조회되지 않는다.
취소 전용 API(fapiPrivateDeleteAlgoOpenOrders)를 반드시 함께 써야 완전히 정리된다.

이 버그는 실용글 3에서 다룬 취소 관련 절반(Algo 취소 API 필요)과 이어지는 내용이다.
취소는 알고 있었는데 생성 단계의 충돌은 이번에 처음 발견했다.

봇이 정상이라고 로그를 찍어도, 거래소에서 직접 Algo 주문을 조회해보는 습관이 필요하다.
특히 포지션이 있는데 열린 주문이 0건으로 나오면 Algo 시스템을 직접 확인해봐야 한다.

함께 읽으면 좋은 글

2026.05.24 - [바이낸스 선물 자동매매] - 바이낸스 TP/SL 취소 오류, Algo 주문 API 따로 있었다

바이낸스 TP/SL 취소 오류, Algo 주문 API 따로 있었다

바이낸스 선물 자동매매 봇에서 TP/SL 주문 취소가 안 되는 문제가 생겼다.익절이 됐는데도 손절 주문이 그대로 남았고, 봇이 다음 포지션을 잡을 때마다 충돌이 생겼다.1달이 넘도록 원인을 못

creator88837.tistory.com

2026.07.09 - [바이낸스 선물 자동매매] - 바이낸스 봇 청산 실패 -2022 오류, 고쳤는데 다음날 또 터졌다

바이낸스 봇 청산 실패 -2022 오류, 고쳤는데 다음날 또 터졌다

바이낸스 선물 자동매매 봇 청산 오류 -2022를 정리했다.고쳐서 테스트까지 통과했는데, 다음날 같은 오류가 재발했다.이 글에서는 -2022 오류의 두 가지 원인과 헤지 모드에서의 진짜 해결법을 코

creator88837.tistory.com

2026.07.09 - [바이낸스 선물 자동매매] - 바이낸스 봇 청산 실패 -2019 오류, 0.001 BTC를 1 BTC로 착각한 이유

바이낸스 봇 청산 실패 -2019 오류, 0.001 BTC를 1 BTC로 착각한 이유

바이낸스 선물 자동매매 봇 청산 오류 -2019를 정리했다.-2022를 잡고 다음날 발생한 오류로, 0.001 BTC 포지션을 1 BTC로 착각해 증거금 부족이 발생했다.이 글에서는 ccxt fetch_positions의 contracts 단위 오

creator88837.tistory.com

12화 바이낸스 자동매매, $300이 10년 뒤 $3만이 되는 이유

creator88837 — Mon, 13 Jul 2026 09:00:56 +0900

바이낸스 자동매매 전략이 연 60% 수익률을 10년 유지한다면, $300은 약 $3만까지 불어난다.
이번 글에서는 실제 백테스트 데이터를 바탕으로 복리 효과와 MDD의 중요성을 정리했다.

$300이 10년 뒤 어떻게 되는지 계산해봤다

지금 봇이 돌아가는 자본은 $300이다.
연 60% 복리로 10년을 굴리면 어떻게 될까.

1년차   $480
2년차   $768
3년차   $1,229
4년차   $1,966
5년차   $3,146
6년차   $5,033
7년차   $8,053
8년차   $12,885
9년차   $20,616
10년차  $32,985

10년이면 $32,985다.
$300이 110배가 됐다.

이 숫자를 보고 처음에는 실감이 안 났다.
그냥 계산기가 뱉은 숫자라고 생각했다.

근데 2023년부터 2025년까지 3년 연속으로 60%를 달성한 전략이 백테스트에서 실제로 나왔다.
그냥 이론이 아니다.
이미 데이터가 있다.

60% 캡 전략 연도별 수익률:
2023: +70%
2024: +63%
2025: +65%
2026: +59% (진행 중)

4년 중 3년을 달성했다.
2026년도 6월 기준으로 목표($2,192)에 거의 도달했다.

중요한 건 원금이 아니었다

처음에는 $300이라는 원금이 너무 적다고 생각했다.
이 돈으로 뭘 할 수 있겠나 싶었다.

비교를 해봤다.
$3,000으로 시작해서 연 30%를 10년 유지하면 어떻게 될까.

1년차   $3,900
5년차   $11,139
10년차  $41,373

원금이 10배 더 많다.
수익률은 절반이다.
근데 10년 후에는 $41,373 vs $32,985.

생각보다 차이가 작다.
원금 10배 차이인데 결과는 1.25배밖에 안 된다.

반대로 읽으면 이런 뜻이다.
원금을 10배로 늘리는 것과, 수익률을 2배로 높이는 것이 거의 같은 효과를 낸다.

원금을 10배로 늘리는 게 쉬울까.
수익률을 연 30%에서 60%로 올리는 게 쉬울까.

둘 다 쉽지 않다.
근데 이미 60%를 달성하는 전략이 백테스트에서 나왔다.
원금은 나중에 올리면 된다.

시간이 핵심인 이유

복리를 직접 계산해보기 전까지는 막연하게 좋은 거라고만 알고 있었다.
계산을 해보고 나서야 어느 구간에서 힘이 생기는지 보였다.

1년차에서 2년차: $480 → $768. 증가폭 $288.
9년차에서 10년차: $20,616 → $32,985. 증가폭 $12,369.

같은 60%인데 달러로 불어나는 금액이 43배 차이가 난다.
복리는 시작이 아니라 후반에 폭발한다.

초반 몇 년은 티가 안 난다.
$300이 $480, $768이 되는 과정은 답답하다.
이게 맞는 방향인지 의심이 드는 구간이다.

근데 7년차를 넘어가면서 달라진다.
$8,053 → $12,885 → $20,616 → $32,985.
3년 만에 4배가 된다.

그 7년을 버티는 게 핵심이다.
버티려면 전략이 살아있어야 한다.
전략이 살아있으려면 크게 잃으면 안 된다.

복리성장곡선

초반 6년은 거의 평탄하게 보이지만, 7년차를 넘어가면서 곡선이 급격히 꺾인다.
같은 60%인데 달러로 불어나는 금액이 후반으로 갈수록 기하급수적으로 커진다.

-50%짜리 해 하나가 10년을 망가뜨린다

만약 5년차에 -50%가 끼어들면 어떻게 될까.

5년차까지 연 60% → $3,146
6년차 -50% → $1,573
7년차부터 다시 60% → $2,517 → $4,027 → $6,443 → $10,309

10년 후 $10,309.
-50% 한 해가 없었으면 $32,985였을 자리다.
3분의 1이 됐다.

충격시뮬레이션

파란 선(정상 복리)과 빨간 선(5년차 -50% 충격)의 격차가 10년 뒤 3.2배까지 벌어진다.
-50%짜리 해 하나가 복리 곡선 전체를 무너뜨린다.

이게 MDD를 낮춰야 하는 이유다.
수익률을 더 올리는 것보다 큰 손실을 막는 게 훨씬 중요하다.

연 60% 캡 전략의 MDD는 -19.61%였다.
원본 전략의 MDD는 -42.98%였다.
같은 기간, 같은 봇인데 MDD가 두 배 이상 차이가 난다.

수익률은 원본이 앞선다.
+877% vs +624%.
그 격차가 큰 하락장 하나에 뒤집힌다.

원본 -40%, 캡 +60% 인 해가 오면
원본 $2,932 → $1,759
캡 $2,174 → $3,478
격차가 두 배로 벌어진다.

코인 시장에서 그런 해는 반드시 온다.
2022년이 그랬다.
언제인지는 모른다.
그냥 온다.

살아남는 구조를 만드는 것이 먼저인 이유

투자를 오래 해온 사람들이 하는 말이 있다.
"부자가 되는 건 수익률이 아니라 시간이다."

처음에는 이 말이 잘 와닿지 않았다.
수익률이 높아야 빠르게 불어나는 거 아닌가.

근데 복리 계산을 해보고 나서 다르게 읽혔다.
수익률보다 시간이 먼저라는 뜻이 아니었다.
수익률을 유지한 채 오래 살아남는 것이 핵심이라는 뜻이었다.

크게 잃으면 회복하는 데 시간이 오래 걸린다.
-50%를 당하면 원금으로 돌아오는 것만으로 +100%가 필요하다.
그 시간 동안 복리가 쌓이지 않는다.

60% 캡 전략은 피크에서 멈춘다.
더 벌 수 있는데 멈추는 게 아깝다.
근데 멈추는 순간 그해 드로다운을 안 겪는다.
다음 해를 더 큰 원금으로 시작한다.

원본이 수익 피크를 찍고 내려오는 동안, 캡은 멈춰서 기다린다.
그 차이가 복리로 쌓인다.

지금 이 순간에 드는 생각

$300이 작은 돈이라는 건 안다.
솔직히 부끄럽기도 하다.

근데 이제는 생각이 바뀌었다.
$300이 문제가 아니다.
이 전략이 실전에서도 통하는가가 문제다.

그게 증명되면 금액은 언제든지 올릴 수 있다.
지금은 전략을 검증하는 중이다.

백테스트는 백테스트다.
3년 연속 60%를 달성한 데이터가 있지만, 실전은 다르다.
실전이 쌓여야 숫자에 신뢰가 생긴다.

검증은 계속하고 있다.
결과가 나오면 다시 올린다.

※ 이 글의 10년 복리 계산은 단순 계산이며 세금·수수료를 포함하지 않는다.
60% 캡 전략 수치는 실제 백테스트 결과이지만, 미래 수익을 보장하지 않는다.

바이낸스 봇 리스크 분산, 같은 코인에 3개 몰았더니 다 같이 -$183

creator88837 — Sat, 11 Jul 2026 00:10:52 +0900

바이낸스 선물 자동매매 봇 6월 실전 결과를 정리했다.
총 5개 봇을 운영했고, 합산 순손익은 -$152.22였다.
이 글에서는 ONDO 봇 3개가 동시에 손실을 낸 원인과 리스크 분산 기준을 실제 수치를 바탕으로 정리한다.

1봇 BTC는 +$0.68.
5봇 XRP는 +$30.90.
이 두 봇은 플러스로 마쳤다.

문제는 나머지 세 봇이었다.
2봇 ONDO -$94.33.
3봇 ONDO -$41.61.
4봇 ONDO -$47.86.
합산 -$183.80.

ONDO가 6월 내내 약세였다.
그리고 그 코인에 붙어있던 봇 3개가 동시에 손실을 냈다..

봇이 5개라도 같은 코인이면 리스크 분산이 안 된다

투자에서 리스크 분산은 자산을 여러 곳에 나눠 담는 전략이다.
한 곳에 몰리면 그 자산이 흔들릴 때 전체가 흔들린다.
주식 투자에서 한 종목에 전 재산을 넣지 말라고 하는 이유다.

자동매매 봇도 같은 원리다.
봇을 5개 운영한다고 해서 리스크가 자동으로 분산되지 않는다.
봇이 바라보는 코인이 다 같으면, 봇이 5개든 10개든 리스크는 하나다.

코인 가격이 오르면 5개 봇이 동시에 수익을 내고,
코인 가격이 떨어지면 5개 봇이 동시에 손실을 낸다.
봇을 나눠놨지만 사실상 하나의 포지션과 같다.

ONDO 3개 배치가 -$183 동시 손실을 만든 이유

당시 봇 배치는 이랬다.

1봇: BTC
2봇: ONDO
3봇: ONDO
4봇: ONDO
5봇: XRP

ONDO에 봇 3개를 배치한 이유가 있었다.
백테스트 결과가 전략마다 달랐기 때문이다.
전략마다 다른 수익률이 나왔으니 "전략을 다르게 했으니 분산됐다"고 생각했다.

착각이었다.

전략이 달라도 코인이 같으면 가격 방향은 같다.
ONDO가 올라야 3개 봇이 다 수익을 낸다.
ONDO가 빠지면 3개 봇이 다 손실을 낸다.
전략의 차이는 진입 타이밍이나 익절 목표에만 영향을 줄 뿐이다.
방향 자체는 코인이 결정한다.

결과가 이를 증명했다.
2봇 MDD가 -66.97%였다.
초기 잔고 $145에서 최대 $97 가까이 빠진 셈이다.
3봇은 -31.17%, 4봇은 -23.33%.
전략이 달랐음에도 방향은 같았고, 손실 크기만 달랐다.

2026년 6월 봇별 실전 성과

같은 코인 집중 리스크가 백테스트에서 보이지 않는 이유

백테스트는 과거 데이터 기준이다.
특정 기간에 ONDO가 상승했다면, 그 기간 백테스트는 전략마다 다른 수익률을 보여준다.
각 전략이 다른 시점에 다른 수익을 냈기 때문이다.
"서로 다른 성과를 냈으니 분산 효과가 있다"는 결론이 나온다.

그런데 실전에서는 코인의 방향이 먼저 결정된다.
방향이 정해지면 전략마다 손익 크기가 달라질 뿐이지, 전부 같은 방향으로 움직인다.

6월 ONDO는 하락세였다.
전략이 달랐던 3개 봇은 전부 같은 방향으로 손실을 봤다.
손실 크기는 달랐지만 방향은 하나였다.

백테스트는 특정 기간의 승자를 보여준다.
그 기간이 지나면 시장 환경이 바뀐다.
전략이 달라도 코인이 같으면 환경이 바뀔 때 전략이 다 같이 흔들린다.

자동매매 봇 리스크 분산의 실제 기준 세 가지

이번 경험을 통해 정리한 기준이 있다.

첫째, 코인을 분산한다.
봇이 몇 개든 같은 코인에 여러 봇을 붙이지 않는다.
봇 수가 아니라 코인 수가 분산의 기준이다.
BTC 1봇, ONDO 1봇, XRP 1봇처럼 코인별로 1개씩이 원칙이다.

둘째, 코인 간 상관관계를 파악한다.
알트코인끼리는 상관관계가 높다.
BTC가 하락하면 ONDO도 XRP도 같이 빠지는 경향이 있다.
완전한 분산은 어렵지만, 최소한 종목을 달리해야 동시 손실 규모가 줄어든다.
6월 결과에서도 BTC와 XRP는 플러스였다.
ONDO만 유독 하락세였기 때문에 두 코인이 전체 손실을 일부 상쇄해줬다.
만약 5개 봇이 전부 ONDO였다면 손실은 훨씬 컸을 것이다.

셋째, 알트코인의 시즌 특성을 고려한다.
알트코인 자동매매는 BTC 상승장에서 주로 작동한다.
BTC가 횡보하거나 하락하는 구간에서 알트코인 봇은 성과가 나오기 어렵다.
알트코인은 BTC가 오를 때 따라 오르고, BTC가 빠질 때 더 크게 빠지는 특성이 있다.
알트코인 봇을 여러 개 운영한다면 BTC 흐름을 함께 참고하는 것이 낫다.
BTC가 하락 중이라면 알트코인 봇 전체가 불리한 환경에 놓인다.
알트코인 봇을 여러 개 가동할수록 BTC 방향에 더 크게 노출되는 셈이다.

결론

봇 5개라도 코인이 같으면 봇 1개와 위험 구조가 같다.

리스크 분산에서 코인 분산이 전략 분산보다 먼저다.
전략이 달라도 코인이 같으면 의미가 없다.
코인이 달라야 방향이 갈리고, 방향이 갈려야 한쪽이 빠질 때 다른 쪽이 버텨준다.

분산이 제대로 됐는지 확인하는 가장 쉬운 방법은 이 질문 하나다.
"지금 운영 중인 봇 중 같은 코인이 두 개 이상인가?"
그렇다면 그 코인에 집중된 만큼 리스크도 집중돼 있다.

6월에 ONDO 3개 봇이 동시에 -$183을 기록하고 나서야 이걸 실감했다.
백테스트에서는 보이지 않는 리스크다.
봇이 실제로 돌아가고 같은 방향으로 빠지는 걸 눈으로 봐야 와닿는다.

바이낸스 봇 청산 실패 -2019 오류, 0.001 BTC를 1 BTC로 착각한 이유

creator88837 — Fri, 10 Jul 2026 13:30:20 +0900

바이낸스 선물 자동매매 봇 청산 오류 -2019를 정리했다.
-2022를 잡고 다음날 발생한 오류로, 0.001 BTC 포지션을 1 BTC로 착각해 증거금 부족이 발생했다.
이 글에서는 ccxt fetch_positions의 contracts 단위 오류 원인과 해결법을 정리한다.

-2022를 잡았다.
청산 시장가 주문에서 reduceOnly 파라미터를 제거하고 정상 작동을 확인했다.
5월 27일에 수정을 완료했다.

5월 28일 새벽 1시.
또 청산 오류가 났다.
이번엔 다른 코드였다.

{"code": -2019, "msg": "Margin is insufficient."}

증거금이 부족하다는 뜻이다.
이상했다.
BTC 롱 포지션 0.001을 청산하는 건데 증거금이 왜 부족한가.

바이낸스 -2019 오류가 청산 도중에 발생하는 이유

-2019는 "증거금(Margin)이 부족하다"는 바이낸스 API 오류 코드다.

선물 거래에서 포지션을 열거나 주문을 낼 때 계좌에 충분한 증거금이 있어야 한다.
잔고가 주문에 필요한 증거금보다 적으면 바이낸스가 -2019로 거부한다.

일반적으로는 잔고 부족이 원인이다.
그런데 이번 경우는 잔고가 충분했다.
청산인데 증거금이 왜 부족하다는 건지 이해가 안 됐다.

청산이 신규 숏 진입으로 처리되면 -2019 오류가 발생한다

봇이 BTC 롱 0.001을 청산하려고 했다.
바이낸스가 -2019로 거부했다.

청산인데 증거금이 부족할 리가 없다.
청산은 포지션을 줄이는 행위이고, 증거금을 더 요구하는 게 아니라 오히려 돌려받는 쪽이다.

이건 청산이 청산으로 처리되지 않고 신규 주문으로 처리된 것이었다.

contracts 단위 오류로 수량이 1000배 부풀려졌다

-2022를 고치는 과정에서 실제 수량을 조회하기 위해 fetch_positions를 도입했다.
ccxt 라이브러리의 fetch_positions는 포지션 정보를 딕셔너리 형태로 반환한다.
그 딕셔너리 안에 'contracts'라는 키가 있다.

여기서 단위 오류가 발생했다.

바이낸스 선물에서 BTC/USDT의 최소 거래 단위는 0.001 BTC다.
ccxt의 'contracts'는 계약 수를 반환한다.
0.001 BTC = 1계약이다.
즉, BTC 0.001짜리 포지션이 있으면 contracts = 1을 반환한다.

봇이 이 값을 그대로 amount로 사용했다.
amount = 1.0으로 인식했다는 뜻이다.
그래서 봇이 1 BTC 매도를 시도했다.

계좌에 있는 포지션은 0.001 BTC다.
봇이 1 BTC 매도를 시도하면 어떻게 될까.
선물에서 보유량을 초과하는 매도 주문을 내면 초과분은 신규 숏 진입 시도로 처리된다.
0.001 BTC 청산 후 남은 0.999 BTC 매도는 신규 숏 0.999 BTC 진입 시도가 된다.
0.999 BTC 숏 포지션을 열려면 상당한 증거금이 필요하다.
그 증거금이 없으니 -2019가 반환된 것이다.

정리하면 이렇다.
청산하려 했는데 실제로는 "청산 + 대규모 신규 숏 진입 시도"가 됐고,
신규 진입에 필요한 증거금이 없어서 거부됐다.

ccxt fetch_positions 수량 단위 비교

2봇~5봇에 같은 문제가 없었던 이유

2봇~5봇을 확인했다.
모두 청산 수량으로 self.position['amount']를 그대로 사용하고 있었다.

봇이 포지션에 진입할 때 실제 체결 수량을 BTC 단위로 계산해서 JSON 파일에 저장한다.
BTC/USDT 선물 0.001 BTC 진입 → JSON에 amount = 0.001로 저장.
청산 시 이 값을 그대로 쓴다.

1봇은 -2022를 고치면서 fetch_positions로 실제 수량을 조회하도록 바꿨다.
그 과정에서 contracts 단위를 BTC 단위로 혼동한 것이다.
수정이 오히려 새 버그를 만들었다.

저장된 수량으로 되돌려서 -2019를 해결했다

AI에게 이렇게 요청했다.

"fetch_positions로 수량을 조회하도록 수정했는데 p['contracts']가 BTC 단위가 아니라 계약 수 단위라서 1 BTC로 잘못 인식하는 문제가 생겼다. 2봇~5봇처럼 self.position['amount']를 그대로 쓰는 방식으로 되돌려줘."

수정 전 코드 (문제):

```python
# contracts 단위 오류
positions = self.exchange.fetch_positions([self.symbol])
actual_amount = None
for p in positions:
    if float(p['contracts']) > 0:
        actual_amount = float(p['contracts'])  # 계약 수 반환 (0.001 BTC = 1계약 → 1.0 반환)
        break
amount = actual_amount  # 1.0으로 인식 → 1 BTC 매도 시도
```

수정 후 코드:

```python
# 2봇~5봇과 동일한 방식
amount = self.position['amount']  # 진입 시 저장한 BTC 단위 값 (0.001)
```

fetch_positions 로직 전체를 제거하고 원래 방식으로 되돌렸다.
수정 후 청산이 정상 작동했다.

결론

-2019가 청산 중에 발생하면 수량 단위를 먼저 의심해야 한다.

ccxt 라이브러리를 사용할 때 fetch_positions가 반환하는 'contracts'는 계약 수 단위다.
BTC/USDT에서 0.001 BTC = 1계약이므로 이 값을 그대로 쓰면 수량이 1000배 뻥튀기된다.
BTC 단위가 필요하면 'contractSize'를 곱하거나 'notional'을 현재가로 나눠야 한다.

가장 간단한 해결책은 진입 시 저장한 수량을 그대로 쓰는 것이다.
진입 시점에 이미 BTC 단위로 계산한 값이 JSON에 있다.
청산 시 굳이 다시 조회할 필요가 없다.

이번 버그 3연속 경험에서 공통적으로 느낀 것이 있다.
수정할 때 검증된 다른 봇의 방식을 참고하지 않고 새 로직을 추가하면 새 버그가 생긴다.
2봇~5봇은 처음부터 self.position['amount']를 써왔고 같은 문제가 단 한 번도 없었다.
기존 방식이 잘 되고 있을 때는 이유 없이 바꾸지 않는 것이 낫다.

바이낸스 봇 청산 실패 -2022 오류, 고쳤는데 다음날 또 터졌다

creator88837 — Fri, 10 Jul 2026 09:00:43 +0900

바이낸스 선물 자동매매 봇 청산 오류 -2022를 정리했다.
고쳐서 테스트까지 통과했는데, 다음날 같은 오류가 재발했다.
이 글에서는 -2022 오류의 두 가지 원인과 헤지 모드에서의 진짜 해결법을 코드와 함께 정리한다.

5월 25일에 -4509 오류를 잡았다.
진입 직후 OCO 주문 실패 문제였다.
sleep(5)를 추가해서 해결했고, 테스트에서 정상 작동을 확인했다.

다음날인 5월 26일 오후 1시.
EXIT_SIGNAL이 나왔다.
봇이 BTC 롱 포지션 청산을 시도했다.
이번엔 청산이 안 됐다.
로그에 찍힌 오류는 -2022였다.

{"code": -2022, "msg": "ReduceOnly Order is rejected."}

바이낸스 -2022 오류가 청산 주문을 거부하는 원인

-2022는 reduceOnly 주문이 거부됐다는 뜻이다.
reduceOnly는 직역하면 "포지션을 줄이는 용도로만 써라"는 조건이다.

선물 거래에서 청산 주문을 낼 때 이 조건을 붙이면 바이낸스가 해당 주문을 반드시 포지션 청산 목적으로만 처리한다.
실수로 포지션이 반대 방향으로 늘어나는 것을 막기 위한 안전장치다.

예를 들어 BTC 롱 0.001을 보유 중일 때,
청산 주문(매도)에 reduceOnly를 붙이면 0.001을 초과하는 매도는 자동으로 거부된다.
포지션을 줄이는 것만 허용한다는 뜻이다.

이 조건이 거부(-2022)됐다는 건 뭔가 이 조건을 충족하지 못하는 상황이 발생했다는 의미다.

OCO가 취소된 뒤 청산까지 실패하면 포지션이 무방비 상태가 된다

봇의 청산 절차는 두 단계로 진행된다.

1단계 — 기존 OCO(SL/TP) 주문을 취소한다.
2단계 — 시장가 청산 주문을 전송한다.

이날은 1단계(OCO 취소)는 성공했다.
그런데 2단계(시장가 청산)에서 -2022가 반환됐다.

결과적으로 SL/TP는 이미 취소됐고, 청산 주문도 실패한 상태가 됐다.
손절도 익절도 없고 청산 명령도 통하지 않는 무방비 상태로 포지션이 고착됐다.
봇은 정상 작동 중으로 표시되지만 포지션은 방치된 것이다.

처음에는 청산 수량 불일치가 -2022의 원인이라고 생각했다

로그를 분석했다.
봇이 JSON 파일에 저장한 포지션 수량은 0.001 BTC였다.
그런데 봇이 처음 진입했을 때 주문이 일부만 체결되는 경우가 있다.
0.001을 주문했는데 0.0009만 체결된 상태라면 실제 잔여 수량은 JSON과 다르다.

reduceOnly 조건이 붙어 있으면 바이낸스는 실제 보유량(0.0009)을 초과하는 수량의 청산 주문을 거부한다.
봇은 JSON에 저장된 0.001로 청산을 시도하고, 실제 보유량 0.0009와 불일치하니 -2022가 난 것이다.

AI에게 이렇게 요청했다.

"청산 시 봇이 JSON에 저장된 수량으로 주문을 내고 있다. 실제 바이낸스 포지션에서 현재 수량을 직접 조회해서 그 수량으로 청산하도록 수정해줘."

수정 전 코드:

```python
# JSON 저장값으로 청산
amount = self.position['amount']
self.exchange.create_market_sell_order(self.symbol, amount,
                                       params={'reduceOnly': True})
```

수정 후 코드:

```python
# 거래소 실제 수량 조회
positions = self.exchange.fetch_positions([self.symbol])
actual_amount = None
for p in positions:
    if float(p['contracts']) > 0:
        actual_amount = float(p['contracts'])
        break

if actual_amount is None:
    logging.warning("거래소 포지션 없음 — 상태 초기화")
    self.position = None
    return False

# 실제 수량으로 청산
self.exchange.create_market_sell_order(self.symbol, actual_amount,
                                       params={'reduceOnly': True})
```

수정 후 테스트에서는 정상 작동했다.
이걸로 해결됐다고 생각했다.

-2022 오류가 수정 후에도 다음날 재발했다

5월 27일 새벽 1시 10분.
또 -2022가 떴다.
이번에는 청산 시도가 있을 때마다 반복됐다.

수량을 확인했다.
실제 수량과 JSON 저장값이 동일했다. 0.001 = 0.001.
수량 불일치가 원인이 아니었다.
어제 수정한 게 원인이 아니었다는 뜻이다.

처음부터 다시 생각해야 했다.

헤지 모드에서 시장가 청산에 reduceOnly를 쓰면 -2022가 난다

2봇~5봇의 청산 로직과 비교했다.
4개 봇은 모두 정상적으로 청산이 되고 있었다.
그 코드를 확인했더니 차이가 바로 보였다.

봇 청산 주문 방식 비교

2봇~5봇은 청산 시장가 주문에 별도 파라미터를 붙이지 않는다.

```python
# 2봇~5봇 청산 방식
self.exchange.create_market_sell_order(self.symbol, amount)
```

1봇은 `params={'reduceOnly': True}`가 붙어 있었다.

```python
# 1봇 청산 방식 (문제)
self.exchange.create_market_sell_order(self.symbol, amount,
                                       params={'reduceOnly': True})
```

이 한 줄 차이가 원인이었다.

헤지 모드(Hedge Mode) 계정에서는 시장가 주문에 reduceOnly 파라미터를 지원하지 않는다.
reduceOnly는 OCO(SL/TP) 같은 조건부 주문에 쓰는 파라미터다.
청산 시장가 주문에는 붙일 필요가 없다.
헤지 모드에서는 포지션 방향(positionSide)이 이미 LONG/SHORT으로 구분되어 있어서 반대 방향 진입과 청산이 자동으로 분리된다.
따로 reduceOnly를 붙이지 않아도 청산 주문은 청산으로만 처리된다.

쉽게 설명하면 이렇다.
봇이 바이낸스에 이렇게 말한 셈이다.
"0.001 BTC 팔게. 근데 이 주문, 절대로 포지션 늘리는 데 쓰면 안 돼."
바이낸스가 "그 조건은 여기서 처리 못 해. 거부(-2022)"라고 응답한 것이다.
그냥 "0.001 BTC 팔게"라고만 했으면 됐는데, 불필요한 조건이 오류를 만들었다.

1차 진단에서 수량 불일치를 원인으로 봤던 것은 잘못된 진단이었다.
fetch_positions로 수량을 다시 조회하는 수정 후에도 reduceOnly는 그대로 남아 있었으니 -2022가 재발한 것이다.

reduceOnly 파라미터 제거로 청산 오류를 해결했다

AI에게 이렇게 요청했다.

"청산 시장가 주문에서 params={'reduceOnly': True}를 제거해줘. 2봇~5봇처럼 파라미터 없이 일반 시장가 주문으로 변경해줘."

수정 전:

```python
self.exchange.create_market_sell_order(self.symbol, amount,
                                       params={'reduceOnly': True})
```

수정 후:

```python
self.exchange.create_market_sell_order(self.symbol, amount)
```

두 글자 차이다.
수정 후 모든 청산이 정상 작동했다.

결론

-2022 오류가 나면 두 가지를 확인해야 한다.

첫째, 청산 수량이 실제 보유량과 일치하는지 확인한다.
JSON 저장값을 그대로 쓰면 부분 체결 시 불일치가 생길 수 있다.

둘째, 청산 시장가 주문에 불필요한 파라미터가 붙어 있는지 확인한다.
헤지 모드에서 시장가 청산 주문에 reduceOnly를 쓰면 -2022로 거부된다.

이번 경험에서 배운 것은 오류 진단을 단정 짓지 말아야 한다는 점이다.
같은 오류 코드라도 원인이 두 개 이상일 수 있다.
한 가지를 고쳐서 됐다고 해도, 재발하면 처음부터 다시 살펴봐야 한다.
그리고 같은 기능을 하는 다른 봇의 코드와 비교하는 게 빠른 해결 방법이다.