btc-trading-agents 재사용 맵

jeongsk/btc-trading-agents는 새 ChatOps 감독형 자동매매 시스템의 기반 저장소라기보다, 검증된 부품을 추출해 재사용하기 좋은 source repo에 가깝다. 그대로 제품화하기보다, 새 구조로 재조립하는 편이 낫다.

한 줄 판단

• 그대로 베이스 repo로 쓰기: 비추천
• 부품 단위 재사용: 추천
• 새 구조에 이식할 가치가 높은 것: approval gate, risk gate, paper/live executor 분리, scheduler/loop, observability, portfolio state 일부

왜 그대로 쓰기 어렵나

1. 현재 목표보다 그래프가 무겁다

이 프로젝트의 중심은 README 기준으로 다음 구조다.

• Bull ↔ Bear 투자 방향 토론
• Devil’s Advocate 비판
• Aggressive / Conservative / Neutral 리스크 토론
• Research Manager / Portfolio Manager 최종 판정
• LangGraph StateGraph 기반 Phase 0/1/2/4 파이프라인

이 구조는 연구형 BTC/KRW 분석 시스템으로는 의미가 있지만, 이 지금 만들려는 것은 더 단순한 아래 구조다.

1. 이벤트 발생
2. 컨텍스트 수집
3. AI 제안 카드 생성
4. 사람 승인
5. 실행 엔진 호출
6. 결과 회신 / 저널링

즉 현재 repo는 debate-heavy, 새 시스템은 ops-heavy다.

2. BTC/KRW / Upbit 특화가 강하다

관찰값:

• 기본 심볼이 KRW-BTC
• pyupbit 직접 사용
• 업비트 실거래 실행기 포함
• 한국 뉴스 / 김치프리미엄 / BTC 분석 흐름이 곳곳에 배어 있음

새 아키텍처는 Upbit 실전형에서 시작하더라도, 장기적으로는 다음처럼 adapter 중심이 더 맞다.

ExecutionAdapter
├── FreqtradeAdapter
├── CCXTDirectAdapter
└── KISAdapter

즉 기존 repo는 도메인 특화 코드가 많아 범용 운영면으로 옮기려면 분리 작업이 필요하다.

3. LLM 결합이 특정 스택에 묶여 있다

src/btc_analyzer/llm/model_router.py를 보면 GLM/Z.AI 기반 모델 티어가 박혀 있다.

• glm-4.7-flash
• glm-4.7
• glm-5-turbo

이건 연구형 토론 그래프에는 맞지만, 새 ChatOps 감독형 구조에서는 LLM provider를 교체하기 쉬운 제안 카드 생성 레이어가 더 중요하다.

4. 문서와 구현 사이의 드리프트가 보인다

README에는 tools/telegram.py 같은 구조가 보이지만, 실제 코드에서는 Telegram 관련 구현보다 Discord webhook / config가 더 두드러진다. 즉 repo를 그대로 출발점으로 쓰면 먼저 정합성 정리가 필요할 가능성이 높다.

재사용 가치가 높은 부품

A. Human approval gate — 매우 높음

관련 파일:

• src/btc_analyzer/nodes/human_approval.py
• tests/test_human_approval.py

재사용 포인트:

• live 모드일 때 항상 승인 요구
• confidence 낮을 때 승인 요구
• position size 클 때 승인 요구
• interrupt() 기반 HITL 구조
• None-safe / 경계값 테스트가 이미 있음

새 시스템으로 옮길 때의 역할:

• approval_gate/service.py
• approval_gate/policy.py
• Telegram 승인 응답 처리기로 변경

주의:

• 현재 구현은 LangGraph interrupt()에 묶여 있으므로, 새 구조에서는 플랫폼 독립 ApprovalPolicy + Telegram 응답 어댑터로 쪼개는 편이 좋다.

B. Risk gate — 매우 높음

관련 파일:

• src/btc_analyzer/nodes/risk_gate.py
• tests/test_risk_gate.py

재사용 포인트:

• 연속 손실 차단
• 일일 손실 초과 시 LIQUIDATE
• 포지션 크기 cap
• 순수 함수 check_risk_gate() 존재
• 엣지 케이스 테스트가 잘 붙어 있음

새 시스템으로 옮길 때의 역할:

• risk/policy.py
• risk/tests/test_policy.py

판단:

• 이건 거의 그대로 가져와도 된다.
• 오히려 이 repo의 핵심 자산 중 하나다.

C. Paper trading executor — 높음

관련 파일:

• src/btc_analyzer/paper_trading/executor.py
• tests/test_paper_trading.py

재사용 포인트:

• ALLOW / BLOCKED / LIQUIDATE 상태 처리
• paper buy / sell / liquidate 흐름
• portfolio snapshot 반환
• 최소 주문 / invalid input / 손익 추적 테스트

새 시스템으로 옮길 때의 역할:

• execution/paper_executor.py
• portfolio/paper_portfolio.py

판단:

• MVP에서 가장 먼저 써먹기 좋은 자산이다.
• supervised live 전 단계 검증에 바로 유효하다.

D. Real trading executor — 높음

관련 파일:

• src/btc_analyzer/real_trading/executor.py
• tests/test_real_trading.py

재사용 포인트:

• dry_run 지원
• 업비트 인증 여부 처리
• 시장가 buy/sell
• 체결 검증 _verify_order()
• 실거래 상태/잔고 조회 보조 함수

새 시스템으로 옮길 때의 역할:

• execution/upbit_executor.py
• 이후 execution/ccxt_adapter.py 또는 execution/freqtrade_adapter.py와 분리

주의:

• 현재는 pyupbit 직결이므로 새 구조에서는 Upbit 전용 adapter로 위치를 명확히 해야 한다.
• 즉 “공통 execution engine”이 아니라 “한 개의 broker adapter”로 남기는 게 맞다.

E. Scheduler / loop runner — 중간 이상

관련 파일:

• src/btc_analyzer/scheduler.py

재사용 포인트:

• 반복 실행 루프
• 작업 래핑
• Discord notification 구조
• phase 실행 후 알림 전송

새 시스템으로 옮길 때의 역할:

• runtime/loop.py
• notifications/discord.py
• 장기적으로 notifications/telegram.py

주의:

• Discord webhook 중심이라, 새 목표에서는 Telegram 우선으로 바뀌어야 한다.
• 그래도 loop / wrapper 패턴은 재사용 가치가 있다.

F. Observability / decision tracker — 중간 이상

관련 파일:

• src/btc_analyzer/observability/tracker.py

재사용 포인트:

• 세션 단위 decision 기록
• agent별 비용/신뢰도 요약
• markdown/json export

새 시스템으로 옮길 때의 역할:

• journal/decision_tracker.py
• reports/explainability.py

판단:

• 멀티에이전트 토론을 줄이더라도, proposal card 생성과 사후 회고 추적에는 유효하다.

G. State schema — 부분 재사용

관련 파일:

• src/btc_analyzer/state.py

재사용 후보 필드:

• final_decision
• final_confidence
• position_size_pct
• risk_gate_result
• portfolio_state
• approval_required
• approval_status
• approval_reason
• trading_mode
• paper_trade_result
• real_trade_result

판단:

• 전체는 너무 크고 현재 목표에 비해 과하다.
• 하지만 핵심 필드 셋은 새 ProposalState / ExecutionState 설계의 출발점으로 좋다.

그대로 버리거나 축소할 것

1. Debate agents 전체

관련 파일:

• bull_researcher.py
• bear_researcher.py
• devils_advocate.py
• aggressive.py
• conservative.py
• neutral.py
• research_manager.py
• portfolio_manager.py
• debate_loop.py
• graph.py

판단:

• 연구 실험용으로는 의미가 있지만, 현 시점 MVP에는 과하다.
• 새 시스템의 본질은 토론이 아니라 이벤트 → 제안 → 승인 → 실행이다.
• 따라서 즉시 재사용보다는, 나중에 AI 분석 레이어를 심화할 때 일부 발상만 가져오면 된다.

2. GLM 전용 model router

관련 파일:

• src/btc_analyzer/llm/model_router.py

판단:

• provider lock-in이 강하다.
• 새 시스템에서는 provider-agnostic proposal layer가 더 적합하다.
• 역할 기반 tier 개념은 참고 가능하지만, 구현 자체는 새로 짜는 편이 낫다.

3. BTC/감성/뉴스 특화 데이터 수집층

판단:

• 현재 목표는 우선 실행 아키텍처 정리다.
• 뉴스/Reddit/Telegram 수집은 나중 단계에 붙이는 것이 맞다.
• 즉시 이식 우선순위는 낮다.

새 프로젝트에 옮길 권장 구조

chatops-trading/
├── app/
│   ├── state.py
│   ├── config.py
│   └── main.py
├── event_router/
│   ├── api.py
│   └── schemas.py
├── context/
│   └── builder.py
├── proposal/
│   ├── rule_engine.py
│   ├── ai_proposal.py
│   └── card_renderer.py
├── approval/
│   ├── policy.py          <- human_approval.py에서 규칙 이식
│   └── telegram_gate.py
├── risk/
│   └── policy.py          <- risk_gate.py 이식
├── execution/
│   ├── paper_executor.py  <- paper_trading/executor.py 이식
│   ├── upbit_executor.py  <- real_trading/executor.py 이식
│   ├── freqtrade_adapter.py
│   └── base.py
├── portfolio/
│   └── paper_portfolio.py
├── runtime/
│   └── loop.py            <- scheduler.py 일부 차용
├── notifications/
│   ├── telegram.py
│   └── discord.py
├── journal/
│   ├── tracker.py         <- observability/tracker.py 차용
│   └── vault_writer.py
└── tests/

파일별 재사용 매핑

기존 파일	새 위치	재사용 방식	판단
nodes/human_approval.py	approval/policy.py	로직 추출 후 Telegram 응답 어댑터와 분리	강추
tests/test_human_approval.py	tests/approval/test_policy.py	테스트 케이스 대부분 유지	강추
nodes/risk_gate.py	risk/policy.py	거의 그대로 이식	강추
tests/test_risk_gate.py	tests/risk/test_policy.py	대부분 그대로 유지	강추
paper_trading/executor.py	execution/paper_executor.py	상태 인터페이스만 맞춰 이식	강추
paper_trading/portfolio.py	portfolio/paper_portfolio.py	거의 그대로 이식 가능	강추
real_trading/executor.py	execution/upbit_executor.py	Upbit 전용 adapter로 이식	추천
tests/test_real_trading.py	tests/execution/test_upbit_executor.py	adapter 기준으로 조정	추천
scheduler.py	runtime/loop.py	notification 분리 후 차용	추천
observability/tracker.py	journal/tracker.py	naming만 정리 후 차용	추천
state.py	app/state.py	필요한 필드만 축소 채택	부분 추천
graph.py	없음	구조 참조만, 직접 이식은 비추천	비추천
llm/model_router.py	없음 또는 proposal/modeling.py	tier 아이디어만 참고	부분 참고

실제 재사용 우선순위

1순위 — 바로 옮길 것

• risk_gate.py
• human_approval.py
• paper_trading/portfolio.py
• paper_trading/executor.py

2순위 — 구조 정리 후 옮길 것

• real_trading/executor.py
• scheduler.py
• observability/tracker.py
• state.py 일부

3순위 — 나중에 참고만 할 것

• graph.py
• debate nodes 전체
• llm/model_router.py
• 소셜/뉴스/감성 파이프라인

현재 repo를 어떻게 위치시킬까

가장 좋은 위치 설정은 이렇다.

btc-trading-agents = 연구/실험/부품 저장소

새 ChatOps supervised trading repo = 운영면 중심 제품 저장소

즉 기존 repo는 버릴 필요는 없지만, 새 시스템의 메인 베이스로 삼기보다는 validated module source로 두는 편이 더 낫다.

실무적 다음 단계

1. btc-trading-agents에서 아래 4개를 먼저 추출
   • approval
   • risk
   • paper portfolio
   • paper executor
2. 새 프로젝트에 Telegram approval flow를 붙임
3. 이후 Upbit executor를 adapter로 이식
4. 마지막에 Freqtrade 연동 여부를 결정

즉 새 시스템 MVP는

기존 repo의 안정적인 의사결정/리스크 부품 + 새 ChatOps 운영면

으로 가는 것이 가장 현실적이다.

Related Notes

• 2026-04-22-open-source-automated-trading-stack-map
• 2026-04-22-open-source-automated-trading-stack-map
• 2026-04-22-open-source-automated-trading-stack-map
• 2026-04-24-breakawaych-x-post-external-link
• 2026-03-27-openclaw-trade
• 2026-03-27-multi-agent-trading-deployment-guide
• moc-ai-agents-trading
• harness