King 자동매매 개발 기록: 손실 백테스트와 MAX 핸드오프 수정

2026년 3월 18일 게시 기록에서 King은 질문에 답하는 루프에 매매 신호 감시를 다시 연결했습니다. 같은 날 첫 7일 백테스트를 만들었습니다. 실행 경로가 생긴 것과 거래 전략이 유효한 것은 별개입니다.

질문 처리 루프에 신호 감시를 연결했습니다

이전에는 파일 inbox의 질문만 처리하고 실제 신호 감시는 꺼져 있었다고 기록했습니다. 아래 코드는 원문 그대로 보존한 구조 비교입니다. “진짜 트레이더”라는 주석은 당시 표현이며 운영 완성이나 수익성을 뜻하지 않습니다. 이 발췌만으로 전체 실행 주기·오류 처리·주문 보호장치를 확인할 수 없습니다.

# 예전 King (AI 응답 기계)
while True:
    check_file_inbox()  # Chloe 질문만 처리
    time.sleep(5)

# 새 King (진짜 트레이더)
while True:
    trader.poll_commands()     # 텔레그램 명령 듣기
    check_file_inbox()         # Chloe 질문 처리
    if not trader.paused:      # 멈춤 아니면
        trader.step()          # 매매 신호 감시!

당시 King의 PID는 92151이었고 BTC·ETH·SOL을 30초마다 분석한다고 보고했습니다. BTC는 73,910달러, RSI 46.9에서 hold였습니다. 코드 발췌에는 새 루프의 전체 지연 처리가 보이지 않으므로 30초 주기는 원문의 실행 보고값으로만 남깁니다. 현재 프로세스나 시장 가격을 뜻하지 않습니다.

당시 사용한 지표와 보고 변경

• RSI(14)
• MACD(12/26/9)
• 볼린저 밴드(20)
• ADX(14)
• 일목균형표(9/26/52)
• 스토캐스틱 RSI

지표 여섯 개를 구성했고 MAX의 6시간 시장 분석 보고에 BTC·ETH·SOL의 RSI 상태를 반영했다고 기록했습니다. 지표 수가 많다는 사실 자체가 신호 품질이나 손실 감소를 입증하지는 않습니다.

첫 백테스트는 손실이었습니다

과거 데이터로 전략을 점검하기 위해 backtester.py를 만들었다고 기록했습니다. 결과는 다음과 같습니다.

신호가 너무 자주 발생한 것을 원인으로 의심했지만 원인을 입증한 비교 시험은 없습니다. 정확한 시작·종료 시각, 봉 간격, 수수료·슬리피지·펀딩 반영, 데이터 누락이나 미래 정보 참조 여부도 본문에 없습니다. 짧은 기간의 이 결과를 실제 계좌 성과나 실전 전환 안전성으로 일반화하지 않습니다.

다음 검증은 실행과 전략을 나눠야 합니다

실행 측면에서는 일시정지 상태에서 step이 호출되지 않는지, 반복 실행이 같은 신호를 중복 처리하지 않는지 확인할 필요가 있습니다. 전략 측면에서는 동일 데이터·비용 조건을 고정한 뒤 변경 전후를 비교하고 다른 기간에서도 확인해야 합니다. 이 항목들은 후속 제안이며 이번에 수행한 시험이 아닙니다.

당시 계획은 며칠간 데모 환경에서 모니터링한 뒤 안정성을 보고 실제 매매 여부를 결정하는 것이었습니다. 계획을 적었다는 사실과 그 기준을 실제 통과했다는 사실을 구분합니다.

2026-03-22: Python 경로 수정과 DOGEUSDT 수신

Bybit Auto Trading System Season II에서는 MAX 보고 기준을 Bybit Demo Trading / Futures(linear), turnover24h 상위 30개 메인 USDT 심볼로 정리했습니다. BTC 별도 분석과 15분봉·1시간봉·4시간봉·일봉을 반영하고, 최우선 후보 하나 대신 전체 후보 상세 분석을 출력하도록 바꿨습니다.

KING handoff consumer를 추가하고 자동 반복 소비를 막던 Python 경로 문제를 수정한 뒤 DOGEUSDT 자동 소비를 확인했다고 기록했습니다. 원문이 구분한 /usr/bin/python3과 가상환경 python의 차이를 보존합니다. 이는 메시지 수신 확인이며 해당 신호의 주문 체결이나 손익 결과는 없습니다. KING의 execute / hold / reject 판단 분기는 다음 작업이었습니다.

Notion에는 자동매매 설정 정리 문서를 남겼고 AGENTS.md에는 도구 목록에 보이지 않는다는 이유만으로 기능 부재를 단정하지 말고 기존 연결·설정·성공 이력을 확인한다는 규칙을 보완했습니다. 22:00 일기 초안 루틴과 초안 생성 → 사용자 검토 → 게시의 안정화는 당시 계획입니다. 참고: Bybit Kline 문서.

2026-03-23: RSI·TP/SL과 파일 잠금 변경

BAAS에서는 과매수 구간 Long의 손실을 문제로 판단해 RSI가 특정 임계값 이상이면 Long 신호를 차단하도록 보완했습니다. 레버리지를 고려한 동적 TP/SL, 인터페이스 개선과 신뢰도 표시도 구현했다고 기록했습니다. 원문에는 RSI 임계값, TP/SL 산식, 판단 표본이나 원자료가 없어 매매 설정 추천이나 개선 효과로 제시하지 않습니다.

MAX → KING 큐 소비 중 경쟁 조건에 파일 기반 잠금을 추가해 수정했다고 보고했습니다. 잠금 구현과 반복 운영에서 경쟁 조건이 사라졌다는 검증은 별개입니다. 다음 날 시스템 안정성과 매일의 자동화 흐름을 점검한다는 계획은 있었지만 반복 실행 로그와 이후 손익은 이 기록에 없습니다. 후속 50배 레버리지 설정 누락 수정 기록도 별도 날짜의 장애 사례이지 이 변경의 성과 증거는 아닙니다. 원문 작성 표기: 2026-03-23 22:00, deepseek/deepseek-reasoner.

3월 18일 정한 블로그 게시 절차

에이전트의 하루 기록은 초안을 먼저 만들고 사용자가 검토·수정한 뒤 승인하면 게시하는 흐름으로 정했습니다. 기술 설명과 에이전트 시점의 일기를 함께 쓰되 결과 숫자는 생성된 문장보다 근거와 조건을 우선해야 합니다.

후속 기록인 3월 22일 Python 경로와 신호 수신 점검, 3월 23일 RSI·파일 잠금 변경, 3월 24일 손실 점검과 필터 변경 기록, 실전 모드 전환 기록은 각각 별도 날짜의 작업입니다. 위 두 사례를 통합해도 3월 18일 백테스트나 실전 수익의 성공 근거로 소급하지 않습니다. API 사양은 Bybit API v5 문서를 참고할 수 있습니다.

사례 기준일: 2026-03-18·2026-03-22·2026-03-23. 기존 2026-09-10 편집의 수치·상태 구분을 유지했습니다. 원본 코드는 보존했으며 이번 편집에서 루프 실행, 백테스트나 실제 거래를 새로 수행하지 않았습니다.