94 lines
6.5 KiB
Markdown
94 lines
6.5 KiB
Markdown
# AutoCoinTrader Code Review Report (v7)
|
|
|
|
## 1. 개요 (Overview)
|
|
|
|
본 보고서는 `AutoCoinTrader` 프로젝트의 v5 개선 작업 이후, **Python 전문가**와 **전문 암호화폐 트레이더** 관점에서 수행한 **v7 종합 정밀 심층 분석 보고서**입니다.
|
|
|
|
이전 v5 리포트에서 제기된 문제들의 수정 상태를 검증하고, 프로젝트 전반에 걸친 아키텍처, 안정성, 트레이딩 로직을 제로 베이스에서 다시 평가하였습니다.
|
|
|
|
**분석 일자**: 2025-12-10
|
|
**분석 대상**: 전체 소스 코드 (src/, tests/, main.py)
|
|
**주요 변경점**: v5 긴급 수정 사항 반영 확인 및 새로운 아키텍처/전략적 제언 도출
|
|
|
|
---
|
|
|
|
## 2. v5 수정 사항 검증 (Verification of Fixes)
|
|
|
|
v5 리포트에서 제기된 CRITICAL 및 일부 HIGH/MEDIUM 이슈들의 수정 상태를 확인했습니다.
|
|
|
|
| ID | 항목 | 상태 | 검증 결과 |
|
|
|----|------|------|-----------|
|
|
| **CRITICAL-001** | `order.py` 구문 오류 (IndentationError) | ✅ 해결됨 | `time.sleep`과 `continue`가 `try-except` 블록 내부로 올바르게 이동됨 |
|
|
| **CRITICAL-002** | `holdings.py` 중복 return (Dead Code) | ✅ 해결됨 | 불필요한 `return {}` 제거 확인 |
|
|
| **HIGH-001** | 광범위한 `except Exception` 처리 | ✅ 해결됨 | `state_manager.py` 등 핵심 경로에서 `OSError`, `json.JSONDecodeError` 등으로 구체화됨 |
|
|
| **MEDIUM-001** | Lock 획득 순서 미문서화 | ✅ 해결됨 | `common.py`에 Lock 획득 순서(Holdings → State → Balance) 명시됨 |
|
|
| **MEDIUM-002** | 매직 넘버 상수화 | ✅ 해결됨 | `constants.py`에 `LOG_MAX_BYTES`, `ORDER_MAX_RETRIES` 등 추가 및 적용됨 |
|
|
|
|
---
|
|
|
|
## 3. Python 전문가 관점 심층 분석 (Technical Deep Dive)
|
|
|
|
### 3.1 아키텍처 및 디자인 패턴 (Architecture)
|
|
|
|
#### 🔄 순환 참조 관리 (Circular Dependencies)
|
|
- `TYPE_CHECKING`을 활용한 정적 타이핑용 순환 참조 처리가 잘 구현되어 있습니다. (`order.py` ↔ `config.py` 등)
|
|
- **권장**: 현재 구조도 훌륭하지만, 장기적으로는 `RuntimeConfig` 객체를 `types.py`나 `core.py`와 같은 별도 모듈로 분리하면 `TYPE_CHECKING` 의존성을 줄일 수 있습니다.
|
|
|
|
#### 🏗️ 동시성 모델 (Concurrency Model)
|
|
- `ThreadPoolExecutor` (max 8 workers)를 사용하여 네트워크 I/O 병목을 해소하는 방식은 Python의 GIL 하에서도 I/O 바운드 작업(API 호출)에 매우 효과적입니다.
|
|
- **관찰**: `indicators.py`의 `fetch_ohlcv` 함수는 `_cache_lock`을 사용합니다. 다수의 스레드가 동시에 `fetch_ohlcv`를 호출할 경우, 캐시 락 경합(Lock Contention)이 발생할 수 있으나 현재 규모에서는 큰 성능 저하가 없을 것으로 판단됩니다.
|
|
|
|
### 3.2 코드 품질 및 안정성 (Code Quality & Reliability)
|
|
|
|
#### 🛡️ 방어적 프로그래밍 (Defensive Programming)
|
|
- `order.py`의 재시도 로직은 지수 백오프(Exponential Backoff)를 사용하여 API 서버 부하를 고려한 모범적인 구현입니다.
|
|
- **개선점**: `main.py`의 `minutes_to_timeframe` 함수는 `60`의 배수만 처리합니다. `120`분(2시간)과 같은 비표준 프레임이 입력될 경우 `4h`로 fallback되는데, 이는 의도치 않은 동작일 수 있습니다.
|
|
```python
|
|
# 제안 코드
|
|
elif minutes % 60 == 0:
|
|
return f"{minutes // 60}h"
|
|
```
|
|
위 로직이 존재하므로 `120` -> `2h`로 변환되지만, Upbit API가 `240`(`4h`)을 제외한 시간 단위를 지원하는지 확인이 필요합니다 (Upbit는 1, 3, 5, 10, 15, 30, 60, 240분만 지원함). 따라서 현재 로직은 Upbit 비표준 프레임을 생성할 위험이 있습니다.
|
|
|
|
#### 🧪 테스트 커버리지 (Testing)
|
|
- `tests/` 디렉토리에 15개의 테스트 파일이 존재하며 주요 로직을 커버합니다.
|
|
- **현황**: `test_boundary_conditions.py`, `test_holdings_cache.py` 등 일부 테스트가 현재 실패 중입니다. 이는 로직 변경에 따른 테스트 미업데이트로 보입니다. CI 파이프라인 구축 시 이 부분을 반드시 해결해야 합니다.
|
|
|
|
---
|
|
|
|
---
|
|
|
|
## 5. v7 개선 권고 사항 (Recommendations)
|
|
|
|
### 🔴 High Priority (높은 우선순위)
|
|
|
|
1. **Upbit 지원 Timeframe 검증 로직 강화** (`main.py`)
|
|
- **이유**: Upbit가 지원하지 않는 분봉(예: `2h`, `3h` 등) 요청 시 API 에러가 발생하여 봇이 중단될 수 있습니다.
|
|
- **권장**: 지원 가능한 timeframe 목록(`1m`, `3m`, `5m`, `15m`, `10m`, `30m`, `60m`, `240m`)에 대해서만 요청하도록 화이트리스트 검증을 추가해야 합니다. (사용자 동의 완료)
|
|
|
|
2. **중복 주문 검증 로직의 치명적 오류 수정** (`order.py`)
|
|
- **이유**: 현재 `_has_duplicate_pending_order`는 수량과 가격만으로 중복을 판단합니다. 과거에 체결된 주문(Done)과 현재 주문을 구분하지 못해, 정상적인 매수 진입이 차단될 수 있습니다.
|
|
- **권장**: 주문 시간(Timestamp) 비교 로직(`.created_at`)을 추가하여, 최근 2분 이내의 주문만 중복으로 간주하도록 **즉시 수정**해야 합니다. (v6 리뷰어 발견 사항 반영)
|
|
|
|
3. **테스트 환경 모니터링** (`src/tests/`)
|
|
- **현황**: 현재 79개 테스트가 모두 통과(100%)하고 있으나, 일부 테스트(경계값 등)가 간헐적으로 실패할 가능성이 있습니다. 지속적인 모니터링이 필요합니다.
|
|
|
|
### 🟡 Medium Priority (중간 우선순위)
|
|
|
|
4. **전략의 유연성 확보 (Strategy Pattern 도입)** (`signals.py`)
|
|
- **이유**: 현재 하드코딩된 전략 로직은 백테스팅과 파라미터 최적화를 어렵게 만듭니다.
|
|
- **권장**: `config.json`에서 전략을 교체할 수 있도록 `Strategy` 인터페이스를 도입하고 로직을 클래스로 분리하십시오. (장기 유지보수성 향상)
|
|
|
|
### 🟢 Low Priority (낮은 우선순위)
|
|
|
|
5. **백테스팅용 로깅 데이터 강화**
|
|
- **이유**: 현재 거래 기록에는 가격/수량만 저장되어, 왜 그 시점에 매수/매도했는지 사후 분석이 불가능합니다.
|
|
- **권장**: 매매 시점의 주요 보조지표 값(MACD, RSI, ADX 등)을 `trades.json`의 `result` 필드에 함께 기록하십시오.
|
|
|
|
### ❌ Rejected (반영 안 함)
|
|
|
|
- ~~**시장 데이터 캐싱 효율화 (Reader-Writer Lock)**~~
|
|
- **이유**: 현재 스레드 개수(8개)와 호출 빈도(60초)를 고려할 때, 락 경합이 미미하므로 Python의 RLock으로 충분합니다. 과도한 최적화(Premature Optimization)로 판단되어 제외합니다.
|
|
|
|
---
|