AI 가 AI 를 관리한다 — WILD_SNIPER 자율 운영 시스템 v1

4/30 일지의 sniper 사고 이후 10일을 쉬었다. 단순히 다시 켜는 게 아니라 "다시 켜되 같은 사고가 다음에는 사람 개입 없이 처리되는 구조" 를 만들고 싶었다. 그래서 5/10 재기동은 두 가지 작업이 동시에 일어났다 — (1) 봇 자체 재기동, (2) 자율 모니터링 레이어 신설.

Background — WILD_SNIPER 가 무엇인가

WILD_SNIPER 는 Binance 암호화폐 거래소 위에서 도는 자작 trading bot 이다. ccxt 라이브러리를 베이스로 Python 으로 짜였고, RTX 4060 노트북에서 백그라운드로 도는 daemon 형식. 자동으로 종목을 스캔하고, 진입 조건이 맞으면 들어가고, TP / SL / trailing 으로 빠진다. 하루 수십~수백 건의 마이크로 트레이드 운영. 구체적인 진입 조건 / 사이즈 산정 / 위험 한도는 의도적으로 비공개 (보안 + 카피 회피).

대신 공개해도 무방한 부분은 운영 구조 — bot + watcher + 메모리 + monitoring 레이어가 어떻게 협업하는지.

4/30 사고 — Self-kill loop

4/30 봇이 자기 자신을 셧다운 시켰다. 그날 일정 손실 한도를 트리거했고 (정상 안전 장치 작동), watcher (4시간마다 봇 healthcheck + 죽었으면 재기동하는 daemon) 이 죽은 봇을 다시 켰다. 켜자마자 봇은 "오늘 손실 한도 이미 도달" 을 다시 감지하고 즉시 자기 종료. Watcher 는 또 켜고, 봇은 또 죽고. 자정까지 무한 셀프-킬 루프.

봇 자체 동작은 100% 정상이었다 (안전 장치는 발동해야 하는 상황에서 발동했다). 문제는 watcher 가 일일 한도가 트립된 상태를 인지하지 못해서 의미 없는 재기동을 반복했다는 것 — 즉, 운영 메타 레이어의 버그.

근본 원인은 더 위에 있었다. 그 시점의 전략 환경에서 기대값이 마이너스로 떨어진 게 원인이었고, SAFE 안전 장치가 그걸 차단해줬을 뿐이다. SAFE 가 없었으면 더 큰 손실이 났을 것. 안전 장치는 일을 잘 했지만, watcher 의 재기동 정책이 안전 장치와 안 맞물렸다는 게 문제. 사고 후 일지에 "Jack 의 결정 대기 중" 으로 적어두고 봇은 켜지 않은 채 10일 보내기로 결정.

5/10 — 단순 재기동이 아닌 구조 업데이트

10일 만에 다시 켠다. 봇 코드는 그대로 (V3.7.1), 단 운영 메타 레이어를 새로 쌓았다.

Layer 1: 봇 + Watcher (기존 그대로)

WILD_SNIPER_V3_7_1.py (메인 트레이딩 봇) + wild_sniper_watcher.py (4시간마다 헬스체크 / 죽으면 재기동). 두 프로세스 모두 hidden 데몬. 봇은 진입 / 청산 / 일일 손실 한도 / trailing TP / SL 까지 자체적으로 처리. 사람 개입 0 으로 도는 게 정상 상태.

재기동 자체는 quant-trader 서브에이전트에게 위임. pre-flight 체크 (기존 프로세스 / lock / state 파일 검증), 안전 재기동, 첫 60초 동작 검증, 그리고 active-work 메모리 업데이트까지 한 사이클로 처리. 사람은 "재기동 해" 한 마디.

Layer 2: 자율 monitoring (신설)

여기가 이번 작업의 핵심. 봇은 잘 도는데, 봇이 잘 도는지 사람이 직접 보고 있어야 했다는 게 4/30 의 진짜 비용이었다. 매번 PnL 확인하고, 로그 들여다보고, 이상하면 손으로 조치. 시간 소모도 컸지만, 더 큰 문제는 "사람이 옆에 없으면 사고가 늦게 발견된다" 는 점.

해결책: Claude Max 구독의 잉여 토큰을 monitoring agent 로 돌리기.

수치적으로 — Claude Max 사용량을 보면 우리 프로젝트가 한도의 5~15% 만 쓰고 있다. 나머지 85% 는 그냥 비어있는 quota. 그걸 봇 monitoring 에 쓰면 추가 비용 0 으로 24/7 자동 감시 가능.

구현은 두 슬래시 명령어로 압축:

/sniper-healthcheck — 봇 상태 / 로그 / PnL / trade pattern 점검. 정상이면 silent, 이상이면 Telegram 알림.
/dream-sniper — Anthropic 의 unreleased "auto-dream" 패턴을 우리 식으로 복제. 누적된 trade 로그 / active-work 메모 / 알림 이력을 컨솔리데이션해서 인사이트 추출하고 메모리를 정리.

스케줄링은 두 layer 로:

In-session cron (CronCreate) — Claude Code 가 active session 동안 fire. Healthcheck 매 4시간, dream 매 일요일 09:33.
Boot-time auto-rehydrate — Windows Startup folder 에 shortcut 박아서 재부팅 후 30초 자동 Claude Code 실행. CLAUDE.md 의 session-start protocol 이 active-work 를 읽고 sniper 가 활성 상태인 걸 감지하면 cron 두 개를 자동 등록.

= 사람이 PC 만 켜놓으면 monitoring 이 자동 부활. 한 마디도 안 해도 됨.

Layer 3: 의사 결정 Tier 시스템

자율 monitoring 이 있어도 한계가 있다 — AI 가 어디까지 결정해서 실행해도 되는가? 우리는 3 단계로 잘랐다.

Tier 1 — 완전 자동 (보고만): 봇 / watcher healthcheck, 데이터 분석, daily report 생성, 메모리 컨솔리데이션, 비-trading 코드 오타 / 버그 수정. 돈에 영향 없는 액션만.
Tier 2 — 묵시적 동의 (5분 내 거부 가능): 보조 도구 (대시보드 / 리포트 형식) 변경, watcher 코드 개선 같이 trading 본체와 분리된 인프라 patch. AI 가 patch 후 Telegram 으로 통보, 5분 침묵 = 동의.
Tier 3 — 사람 명시 승인 필수: trading 파라미터 변경 (TP / SL / 진입 조건), 전략 자체 변경, 본 봇 코드 (WILD_SNIPER_V3_7_1.py) 수정, 자금 관련 결정. 돈 / 전략 = 사람.

이 경계가 무너지면 자율 시스템이 사고를 만든다 (예: AI 가 R:R 비율을 자기 판단으로 바꿔서 트레이딩하다 손실). 룰을 명시적으로 코드 + 메모리 + slash command 정의에 박아둠.

4 단계 dream — 메모리는 알아서 정리된다

/dream-sniper 가 실행되면 4 단계로 도는 컨솔리데이션 패턴:

Orient — active-work, memory, trade logs, watcher logs, Telegram 알림 이력 전체 스캔. 영역별 줄 수 / 마지막 수정 시각 / 핵심 패턴 카운트.
Gather Signal — 새 trading 패턴, 반복 실패 모드, 성공 패턴, 사용자 결정 기록, 사용자 정정 / 선호 변경, 새 SOP 추출. 풀 read 가 아닌 grep + sniper-data-analyst subagent 위임.
Consolidate — 새 발견을 기존 메모리에 통합. 상대 날짜 → 절대 날짜 변환. 모순 해결 (최신 채택). 오래된 참조 제거. 보호 파일 (feedback_autonomy.md, user_family.md 등) 은 절대 변경 X.
Prune & Index — wild-sniper.md 200줄 미만 유지. 30일 이상 stale 한 분석은 archive. memory 인덱스에 새 인사이트 한 줄 요약 추가.

이게 매주 일요일 09:33 자동 fire. 사람은 결과 보고만 받음. 출처: Anthropic 의 "auto-dream" 디자인을 3rd party 가 복제한 dream-skill 패턴 (4-phase: Orient → Gather Signal → Consolidate → Prune & Index) 을 우리 도메인 (sniper trading bot 메모리) 에 맞게 재정의.

한계 — 정직히

이 시스템 v1 은 완벽한 게 아니다.

Session-resident: Claude Code 세션이 살아있어야 cron fire. PC 종료 / 5일+ idle / Claude 종료 시 cron 사라진다. 재부팅 시 auto-rehydrate 가 보완하지만, 도중 종료엔 무방비. (claude --print 로 무한 백그라운드 가능하지만 그건 API credit 별도 결제 필요.)
Tier 2 의 묵시적 동의: 5분 침묵이 동의로 해석되는 건 사람이 안 보는 시간에 변경이 들어갈 수 있다는 위험. trading 본체와 격리됐지만 watcher / 모니터링 코드 패치 정도는 들어감.
Dream 의 사람 검토 부재: AI 가 메모리를 정리하고 인사이트 추출하는 건 좋은데, 그 추출 자체가 잘못된 패턴 인식이면 메모리에 잘못된 결론이 들어간다. 보호 파일 룰로 critical IP 는 지켰지만, sniper 만의 인사이트는 자유롭게 갱신 가능.
R:R 0.5 의 진짜 원인은 미해결: monitoring 이 잘 돌아도 4/30 의 근본 원인 (전략 환경 변화로 기대값 마이너스) 은 그대로다. SAFE 안전 장치가 출혈을 막고 있을 뿐. V4.x 빌드 + paper 검증으로 가는 게 정공법.

결론 — AI 가 AI 를 관리한다

trading bot 자체는 사람이 짜고 사람이 결정한다. 그 위에 도는 monitoring / 보고 / 메모리 정리 layer 는 AI 가 한다. 이 두 층이 분리되면서 사람은 "전략" 에만 집중하고 "운영 노가다" 는 AI 가 흡수한다.

5/10 시점 데이터:

봇: 정상 운영 (PID 73592, watcher PID 77624). 첫 2시간 +$0.30.
자율 monitoring: 4시간 healthcheck cron 활성. 첫 자동 점검 23:07 KST.
재부팅 자동 부활 시스템: Windows Startup + CLAUDE.md auto-rehydrate.

다음 한 주 동안 자율 monitoring 이 실제로 작동하는지 검증한다. 작동이 검증되면 같은 패턴을 다른 프로젝트 (VERICUM ENT 채널 모니터링, EFA, Vericum Fasti) 로 확장한다.

trading bot 의 진짜 가치는 P&L 만이 아니라 24/7 자동 운영 인프라가 잘 짜여있는가 다. 4/30 의 self-kill loop 는 그걸 가르쳐준 사고. 5/10 의 자율 monitoring 은 그 교훈을 시스템에 박은 것.

비용: Claude Max 구독 (이미 결제 중) + RTX 4060 노트북 전기. 추가 비용 0. AI agent 가 24/7 도는 데 한 푼 더 안 든다.

이게 2026 의 AI-Native 운영 모델이다.