새 ChatOps supervised trading repo 골격과 1차 이식 순서표

새 프로젝트는 btc-trading-agents를 그대로 이어받는 방식이 아니라, 운영면 중심의 작은 코어를 먼저 만들고 검증된 부품을 순차 이식하는 방식이 가장 안전하다.

목표

이 문서는 새 ChatOps 감독형 자동매매 프로젝트를 시작할 때,

1. 어떤 디렉토리 구조로 출발할지
2. 어떤 파일을 먼저 만들지
3. 기존 btc-trading-agents에서 무엇을 어떤 순서로 옮길지

를 바로 실행 가능한 수준으로 정리한 골격 설계서다.

이 문서는 2026-04-22-open-source-automated-trading-stack-map와 2026-04-24-btc-trading-agents-reuse-map의 다음 단계다.

기본 원칙

1. 운영면 우선

이 프로젝트의 핵심은 “더 똑똑한 토론”이 아니라,

• 이벤트를 받고
• 제안 카드를 만들고
• 사람 승인을 받고
• 안전하게 실행하고
• 결과를 기록하는

운영 루프다.

2. 토론형 멀티에이전트는 후순위

초기 MVP에서는

• Bull/Bear debate
• Devil’s Advocate
• 다중 리스크 토론

같은 구조를 넣지 않는다.

처음에는 Rule Engine + AI Proposal + Risk Gate + Approval Gate면 충분하다.

3. 새 repo는 adapter 중심

실행 계층은 처음부터 추상화해야 한다.

ExecutionAdapter
├── PaperExecutor
├── UpbitExecutor
├── FreqtradeAdapter
└── KISAdapter

즉 “현재는 Upbit”여도, 구조는 “나중에 교체 가능”해야 한다.

추천 repo 구조

chatops-supervised-trading/
├── README.md
├── pyproject.toml
├── .env.example
├── src/
│   └── chatops_trading/
│       ├── __init__.py
│       ├── main.py
│       ├── config.py
│       ├── state.py
│       │
│       ├── event_router/
│       │   ├── __init__.py
│       │   ├── api.py
│       │   ├── schemas.py
│       │   └── dedupe.py
│       │
│       ├── context/
│       │   ├── __init__.py
│       │   ├── market_snapshot.py
│       │   ├── portfolio_snapshot.py
│       │   └── builder.py
│       │
│       ├── proposal/
│       │   ├── __init__.py
│       │   ├── rule_engine.py
│       │   ├── ai_summary.py
│       │   └── card_renderer.py
│       │
│       ├── risk/
│       │   ├── __init__.py
│       │   └── policy.py
│       │
│       ├── approval/
│       │   ├── __init__.py
│       │   ├── policy.py
│       │   ├── telegram_gate.py
│       │   └── timeout.py
│       │
│       ├── execution/
│       │   ├── __init__.py
│       │   ├── base.py
│       │   ├── paper_executor.py
│       │   ├── upbit_executor.py
│       │   ├── freqtrade_adapter.py
│       │   └── router.py
│       │
│       ├── portfolio/
│       │   ├── __init__.py
│       │   └── paper_portfolio.py
│       │
│       ├── notifications/
│       │   ├── __init__.py
│       │   ├── telegram.py
│       │   └── discord.py
│       │
│       ├── runtime/
│       │   ├── __init__.py
│       │   ├── loop.py
│       │   ├── scheduler.py
│       │   └── commands.py
│       │
│       ├── journal/
│       │   ├── __init__.py
│       │   ├── tracker.py
│       │   ├── trade_log.py
│       │   └── vault_writer.py
│       │
│       └── integrations/
│           ├── __init__.py
│           ├── tradingview.py
│           ├── upbit.py
│           └── freqtrade.py
├── tests/
│   ├── approval/
│   ├── risk/
│   ├── execution/
│   ├── event_router/
│   ├── runtime/
│   └── journal/
└── docs/
    ├── architecture/
    └── runbooks/

각 디렉토리 역할

event_router/

역할:

• TradingView webhook 수신
• 중복 이벤트 제거
• 이벤트 타입 표준화

초기 핵심 파일:

• api.py
• schemas.py
• dedupe.py

context/

역할:

• 현재 가격, 최근 캔들, 포지션, 리스크 상태를 한 번에 묶기
• Proposal 생성 전 필요한 스냅샷 생성

초기 핵심 파일:

• market_snapshot.py
• portfolio_snapshot.py
• builder.py

proposal/

역할:

• 규칙 기반 후보 생성
• AI 설명 생성
• Telegram 카드 렌더링

초기 핵심 파일:

• rule_engine.py
• card_renderer.py

초기에는 ai_summary.py를 아주 얇게 두고, 실제 AI 의존성은 나중에 붙여도 된다.

risk/

역할:

• 거래 전 정책 판정
• cap / block / liquidate 결정

이 폴더는 사실상 btc-trading-agents의 risk_gate.py를 바로 이식할 1순위다.

approval/

역할:

• 승인 필요 여부 판단
• Telegram approval/reject 흐름
• timeout 시 auto reject

이 폴더는 human_approval.py의 로직을 분리 이식할 자리다.

execution/

역할:

• paper / upbit / freqtrade / future KIS 실행 경로를 하나의 인터페이스로 정리

핵심은 여기서부터다. 이 프로젝트는 execution을 “전략 엔진”이 아니라 하위 adapter 계층으로 다뤄야 한다.

portfolio/

역할:

• paper trading 자산 상태 관리
• 포지션/손익 계산

notifications/

역할:

• Telegram 메시지 발송
• Discord 보조 알림

초기 우선순위는 Telegram이다. Discord는 나중에 붙여도 된다.

runtime/

역할:

• 루프 실행
• 정시 작업
• /scan, /status, /pause 같은 운영 명령 진입점

journal/

역할:

• 실행 로그
• 승인/거부 이력
• trade summary
• llm-wiki 저장

새 프로젝트에서 가장 먼저 필요한 파일

필수 8개

1. config.py
2. state.py
3. risk/policy.py
4. approval/policy.py
5. portfolio/paper_portfolio.py
6. execution/paper_executor.py
7. proposal/card_renderer.py
8. event_router/api.py

이 8개만 있어도 “신호 → 제안 카드 → 승인/거부 → paper execution”의 가장 작은 루프를 돌릴 수 있다.

1차 이식 순서표

Phase A — 로컬 검증 가능한 최소 코어

Step A1. Risk policy 이식

기존 source:

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

새 위치:

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

목표:

• 연속 손실 / 일일 손실 / 포지션 캡 정책 먼저 복구

이유:

• 이건 순수 함수라 의존성이 적다.
• 가장 안전하게 먼저 옮길 수 있다.

Step A2. Approval policy 이식

기존 source:

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

새 위치:

• src/chatops_trading/approval/policy.py
• tests/approval/test_policy.py

목표:

• live / low confidence / large position 조건 판정만 분리
• interrupt() 의존은 제거

이유:

• 새 구조에서는 LangGraph보다 Telegram gate가 우선이므로, 정책만 먼저 뽑아내야 한다.

Step A3. Paper portfolio 이식

기존 source:

• src/btc_analyzer/paper_trading/portfolio.py
• tests/test_paper_trading.py 중 portfolio 관련 부분

새 위치:

• src/chatops_trading/portfolio/paper_portfolio.py
• tests/portfolio/test_paper_portfolio.py

목표:

• 매수/매도/손익/연속 손실/일일 손익 계산 복구

Step A4. Paper executor 이식

기존 source:

• src/btc_analyzer/paper_trading/executor.py

새 위치:

• src/chatops_trading/execution/paper_executor.py
• tests/execution/test_paper_executor.py

목표:

• risk result를 받아 BUY/SELL/HOLD/LIQUIDATE 수행

이 4단계가 끝나면 최소한 아래는 가능하다.

proposal -> risk policy -> approval policy -> paper executor

Phase B — 운영면 연결

Step B1. Telegram 카드 렌더러 작성

새 파일:

• proposal/card_renderer.py
• notifications/telegram.py

목표:

• 제안 카드를 텍스트/버튼 포맷으로 렌더링

Step B2. Event Router 작성

새 파일:

• event_router/api.py
• event_router/schemas.py
• event_router/dedupe.py

목표:

• TradingView webhook과 수동 명령 수용

Step B3. Approval gate 구현

새 파일:

• approval/telegram_gate.py
• approval/timeout.py

목표:

• pending proposal 저장
• approve/reject 처리
• timeout auto-reject

이 단계가 되면 사실상 “ChatOps MVP”가 된다.

Phase C — 실거래 adapter 이식

Step C1. Upbit executor 이식

기존 source:

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

새 위치:

• execution/upbit_executor.py
• tests/execution/test_upbit_executor.py

목표:

• pyupbit 직결 adapter 복구
• dry_run / authenticated / buy/sell/liquidate 유지

주의:

• 이름은 RealTradeExecutor보다 UpbitExecutor가 더 정확하다.

Step C2. Execution base interface 작성

새 파일:

• execution/base.py
• execution/router.py

목표:

• paper / upbit / freqtrade 경로를 공통 인터페이스로 통일

Phase D — Freqtrade 연결

Step D1. FreqtradeAdapter 추가

새 파일:

• execution/freqtrade_adapter.py
• integrations/freqtrade.py

목표:

• 새 시스템의 상위 ChatOps 운영면에서 Freqtrade를 호출
• “직접 주문”과 “엔진 호출”을 분리

이 단계가 되면 이 원한 CCXT + Freqtrade + Telegram approval 구조로 넘어갈 수 있다.

실제 이식 우선순위 요약

순서	작업	이유
1	Risk policy	순수 함수, 의존성 적음
2	Approval policy	ChatOps 핵심 정책
3	Paper portfolio	검증 가능한 상태 관리
4	Paper executor	MVP 시뮬레이션 루프 완성
5	Telegram card/gate	운영면 연결
6	Event router	실제 webhook 연결
7	Upbit executor	실거래 adapter
8	Freqtrade adapter	안정적 실행 엔진 연동

처음부터 하지 않을 것

초기 1주차에는 아래를 하지 않는 게 좋다.

• debate graph 이식
• GLM 모델 라우팅 이식
• 뉴스/Reddit/Telegram 감성 수집 이식
• Discord 우선 구현
• KIS adapter 동시 개발
• 다중 심볼 동시 운영

즉 초반엔 “작고 단단하게” 가야 한다.

새 repo 시작 시 권장 README 한 줄

Telegram-driven supervised trading system with approval gates, risk policy, and pluggable execution adapters.

이 한 줄이 이 프로젝트의 본질을 가장 잘 설명한다.

제가 추천하는 실제 시작 단위

이 바로 손댈 수 있는 최소 범위는 이것입니다.

Sprint 1

• 새 repo 생성
• config.py
• state.py
• risk/policy.py
• approval/policy.py
• 테스트 통과

Sprint 2

• paper_portfolio.py
• paper_executor.py
• 테스트 통과

Sprint 3

• Telegram card renderer
• Telegram approval flow
• timeout rejection

Sprint 4

• TradingView webhook ingress
• Upbit executor 또는 Freqtrade adapter 연결

이 순서면 설계와 구현이 자연스럽게 이어진다.

결론

새 프로젝트는 운영면이 본체고, btc-trading-agents는 검증된 부품 공급원으로 보는 게 가장 맞다.

즉 바로 실행해야 할 것은:

1. 새 repo 골격 생성
2. risk / approval / paper executor 먼저 이식
3. Telegram gate 붙이기
4. 마지막에 Upbit/Freqtrade 실행 연결

이 경로가 가장 적은 리스크로 이 원하는 구조에 도달하는 길이다.

Related Notes

• 2026-04-22-open-source-automated-trading-stack-map
• 2026-04-24-btc-trading-agents-reuse-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
• moc-ai-agents-trading
• harness