BTC/ETH Only 트레이딩 전략 전환 (2026-05-13)

kahan gunja-pair-hedge + multi-tenant 4 계좌(admin/16/24/27) 동시 적용

배경

2026-05-12 20:23 ~ 05-13 04:04 (8h) admin 계좌에서 ETH/NEAR 페어 7회 청산 6회 손실 누적 -$104.27 발생. 일일 net -$99.04 도달 → V4_ACCOUNT_DAILY_SL(-21%) 트리거 → 24h 신규 진입 차단.

근본 원인 (Bitget API ground truth + 메모리 feedback_gunja-db-vs-bitget-api-ground-truth):

• NEAR 변동성 13.7% vs ETH 4.2% → 페어 헤지 변동성 매칭 가정 깨짐
• ATM v1.3 옵션 B (Mirror 후 Pair A 청산) 패턴이 NEAR 추세 추종 실패
• Mirror SL -2% 임계 3회 연속 발동, 4시간 6회 churning

사용자 결정

전략: 진입 심볼 universe를 BTC/ETH만으로 제한 + 각 leg 진입 사이즈 20% 이상.

이유:

• BTC(3%)/ETH(4%) 변동성 거의 매칭 → 페어 헤지 가정 정상화
• BTC-ETH 상관 0.93+ → 헤지 안정성
• 깊은 유동성 → fee 비중 ↓
• 다른 가드(ATM Mirror, V4 daily SL, catastrophic gate, 레버리지 20-23x, distance 학습) 모두 보존

변경 사항 (/opt/gunja/src/trading/pair_hedge_executor.py)

위치	Before	After	영향
line 85 POSITION_SIZE_PCT	0.05 (5%)	0.20 (20%)	leg당 마진 4배
line 87 NOTIONAL_RATIO	1.2	4.5	단일 leg 노션 상한 cap 해소
line 225 ASSET_POOL	13 자산 (BTC, ETH, SOL, BNB, BCH, XRP, DOGE, SUI, ADA, LINK, AVAX, ARB, NEAR)	['BTC', 'ETH']	진입 universe 2자산만

ENTRY_POOL은 ASSET_POOL - ENTRY_EXCLUDED_ASSETS(BCH,BNB) 자동 계산 → ['BTC', 'ETH'] 결과. 메모리 pair_hedge_executor.py는 admin + multi-tenant 공통 모듈(line 28 명시)이라 단일 변경으로 4 계좌 동시 적용.

작업 흐름 (atomic close + restart)

admin (gunja-pair-hedge, paperclip → kahan)

1. 변경 사항 백업: pair_hedge_executor.py.bak-btc-eth-only-20260513, pair_hedge_executor.py.bak-notional-ratio-20260513
2. systemctl restart gunja-pair-hedge (PID 885160 → 2206890)
3. restart 시 페어 정합 false positive 발생 (5페어 → 0 active, "양쪽 모두 없음" 잘못 판정)
4. Bitget API ground truth 확인: 10 leg 실 OPEN
5. ccxt closePosition(symbol, side, params={"holdSide": side}) 10 leg 일괄 청산 — 실현 -$38.28
6. V4_ACCOUNT_PAUSED 수동 해제 (account_pause_admin.json.bak-manual-clear-20260513)
7. NOTIONAL_RATIO 4.5 추가 변경 + restart
8. 자동 BTC/ETH 페어 진입: BTC long 0.0157 + ETH short 0.46
9. restart 시 또 페어 정합 false positive (asset2=null) → pair_registry 수동 복구 (Bitget API 기반 asset2=ETH/short/0.41 채움)
10. 최종 active: 1 페어 (BTC/ETH, group_id=84fb58b2)

multi-tenant (user 16/24/27)

1. user 16 API key는 gunja_users.db.user_api_keys에서 Fernet 복호화 (UserManager.get_user_api_settings() 활용)
2. 첫 청산 후 multi-tenant 자동 재진입 → atomic stop/start 필요 결론
3. atomic 트랜잭션:
   • systemctl stop gunja-multi-tenant
   • user 16/24/27 모든 leg 청산 (ccxt close_position)
   • pair_registry_{16,24,27}.json 모든 active/single → closed 마킹
   • 만료 account_pause_*.json 백업 후 제거 (user 16/24)
   • user 27는 V4_PAUSED 활성 (-21.46% trigger 새로 발생) → 두 번째 atomic restart로 in-memory 해제
   • systemctl start gunja-multi-tenant
4. 새 cycle 자동 진입 결과:
   • user 16: BTC short 0.0156 + ETH long 0.55, margin 40.1% (BTC 20.0% + ETH 20.1%) ✅
   • user 24: 동일 (hedge-unify 패턴)
   • user 27: BTC/ETH HOLD 신호 (AI 신뢰도 0.00) → 다음 cycle 대기

실현 손익 (오늘 누적)

계좌	사항	금액
admin	20h ETH/NEAR churning + 기타	-$99.04
admin	10 leg 일괄 청산	-$38.28
user 16	10 leg 일괄 청산	-$14.28
user 27	10 leg 일괄 청산	-$8.05
user 24/16 잔존 청산	atomic restart 직전	-$2 추정
합계	모든 계좌 실현 손실	약 -$162

부작용 + 해결 패턴

부작용 1: 페어 정합 false positive (admin + user 27)

restart 시 disk pair_registry json은 active로 reload되지만 Bitget API와의 sync 로직에서 페어가 single로 판정 (asset2=null). 메모리 feedback_multitenant-restart-pair-reload-bug와 동일 패턴.

해결: pair_registry 수동 복구 — Bitget API ground truth로 asset1/asset2/contracts/group_id 직접 주입 후 restart. admin pair 1848761c에서 검증.

부작용 2: in-memory V4_PAUSED 잔존 (user 27)

disk account_pause_27.json 삭제 후에도 multi-tenant 프로세스 메모리에 PauseExecutor 객체 유지 ("Account pause 복원" log)

해결: multi-tenant restart 한 번 더 (disk 비어있으면 in-memory 새로 시작). admin은 별도 프로세스라 즉시 해제 가능했으나 multi-tenant는 양상 다름.

부작용 3: 자동 재진입 무한 loop

청산 직후 multi-tenant cycle이 즉시 옛 자산으로 재진입 (메모리에 옛 ASSET_POOL 13 자산 유지)

해결: systemctl stop → close → cleanup → start atomic 패턴. 30초 내 완료.

새 시스템 최종 상태

계좌	Capital	Active	Margin%	비고
admin	$787.77	1 페어 (BTC long + ETH short)	29%	첫 진입 6% size 흔적 잔존, 잠재 균형 회복
user 16	$315.04	1 페어 (BTC short + ETH long)	40.1%	의도 정확 달성
user 24	$315.03	1 페어 (BTC short + ETH long)	40.1%	user 16 hedge-unify
user 27	$244.10	0 (HOLD 대기)	0%	AI 신호 변경 시 자동 진입

보존 안전장치

• 트레이딩 stop은 atomic 청산 시점만 (< 30s), restart로 즉시 복구
• UFW/DB DROP 0건
• .env 변경 0건
• ATM Mirror SL · catastrophic gate · V4 daily SL · 레버리지 20-23x · distance 학습 모두 그대로
• Backup 파일 8개:
  • pair_hedge_executor.py.bak-btc-eth-only-20260513
  • pair_hedge_executor.py.bak-notional-ratio-20260513
  • pair_registry_admin.json.bak-post-close-20260513 / .bak-recover-asset2-20260513
  • pair_registry_{16,24,27}.json.bak-{post-close,atomic-close,final-clear}-20260513
  • account_pause_admin.json.bak-manual-clear-20260513
  • account_pause_{16,27}.json.bak-{expired,final-clear,manual-clear}-20260513

후속 모니터링 (사용자 결정)

• PAUSE 해제 직후 첫 24h BTC/ETH 진입 빈도 + win rate 측정
• catastrophic gate(-200%) 도달 위험: 페어 합산 노션 ~1600% capital (4 leg × 20% × 20x)
• BTC-ETH 같은 방향 강한 추세 시 페어 PnL 무수익 위험
• 1주 실측 후 사이즈/페어 추가 결정 (예: BTC/SOL, ETH/SOL 추가)

관련 메모리

• gunja-bitget-loss200-trend-20260429 — catastrophic gate -200% / trend mult / WIN distance 페어 학습
• gunja-v4-daily-sl-pair-recovery-20260511 — V4 5계좌 동시 트리거, hedge-unify 패턴
• atm-mirror-overhaul-20260512 — ATM v1.0 → v1.3 옵션 B, 24 페어쌍 학습
• feedback_multitenant-restart-pair-reload-bug — restart 시 페어 reload 깨짐
• feedback_gunja-db-vs-bitget-api-ground-truth — DB trades.net_pnl 0, Bitget API가 진실
• user_trading-philosophy-loss-diagnosis — "청산 측 가드가 본질"