AutoCoinTrader Code Review Report (v7)

1. 개요 (Overview)

본 보고서는 AutoCoinTrader 프로젝트의 v5 개선 작업 이후, Python 전문가와 전문 암호화폐 트레이더 관점에서 수행한 v7 종합 정밀 심층 분석 보고서입니다.

이전 v5 리포트에서 제기된 문제들의 수정 상태를 검증하고, 프로젝트 전반에 걸친 아키텍처, 안정성, 트레이딩 로직을 제로 베이스에서 다시 평가하였습니다.

분석 일자: 2025-12-10 분석 대상: 전체 소스 코드 (src/, tests/, main.py) 주요 변경점: v5 긴급 수정 사항 반영 확인 및 새로운 아키텍처/전략적 제언 도출

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` 등 추가 및 적용됨

TYPE_CHECKING을 활용한 정적 타이핑용 순환 참조 처리가 잘 구현되어 있습니다. (order.py ↔ config.py 등)
권장: 현재 구조도 훌륭하지만, 장기적으로는 RuntimeConfig 객체를 types.py나 core.py와 같은 별도 모듈로 분리하면 TYPE_CHECKING 의존성을 줄일 수 있습니다.

ThreadPoolExecutor (max 8 workers)를 사용하여 네트워크 I/O 병목을 해소하는 방식은 Python의 GIL 하에서도 I/O 바운드 작업(API 호출)에 매우 효과적입니다.
관찰: indicators.py의 fetch_ohlcv 함수는 _cache_lock을 사용합니다. 다수의 스레드가 동시에 fetch_ohlcv를 호출할 경우, 캐시 락 경합(Lock Contention)이 발생할 수 있으나 현재 규모에서는 큰 성능 저하가 없을 것으로 판단됩니다.

order.py의 재시도 로직은 지수 백오프(Exponential Backoff)를 사용하여 API 서버 부하를 고려한 모범적인 구현입니다.
개선점: main.py의 minutes_to_timeframe 함수는 60의 배수만 처리합니다. 120분(2시간)과 같은 비표준 프레임이 입력될 경우 4h로 fallback되는데, 이는 의도치 않은 동작일 수 있습니다.
```
# 제안 코드
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 비표준 프레임을 생성할 위험이 있습니다.

tests/ 디렉토리에 15개의 테스트 파일이 존재하며 주요 로직을 커버합니다.
현황: test_boundary_conditions.py, test_holdings_cache.py 등 일부 테스트가 현재 실패 중입니다. 이는 로직 변경에 따른 테스트 미업데이트로 보입니다. CI 파이프라인 구축 시 이 부분을 반드시 해결해야 합니다.

Upbit 지원 Timeframe 검증 로직 강화 (main.py)
- 이유: Upbit가 지원하지 않는 분봉(예: 2h, 3h 등) 요청 시 API 에러가 발생하여 봇이 중단될 수 있습니다.
- 권장: 지원 가능한 timeframe 목록(1m, 3m, 5m, 15m, 10m, 30m, 60m, 240m)에 대해서만 요청하도록 화이트리스트 검증을 추가해야 합니다. (사용자 동의 완료)
중복 주문 검증 로직의 치명적 오류 수정 (order.py)
- 이유: 현재 _has_duplicate_pending_order는 수량과 가격만으로 중복을 판단합니다. 과거에 체결된 주문(Done)과 현재 주문을 구분하지 못해, 정상적인 매수 진입이 차단될 수 있습니다.
- 권장: 주문 시간(Timestamp) 비교 로직(.created_at)을 추가하여, 최근 2분 이내의 주문만 중복으로 간주하도록 즉시 수정해야 합니다. (v6 리뷰어 발견 사항 반영)
테스트 환경 모니터링 (src/tests/)
- 현황: 현재 79개 테스트가 모두 통과(100%)하고 있으나, 일부 테스트(경계값 등)가 간헐적으로 실패할 가능성이 있습니다. 지속적인 모니터링이 필요합니다.

전략의 유연성 확보 (Strategy Pattern 도입) (signals.py)
- 이유: 현재 하드코딩된 전략 로직은 백테스팅과 파라미터 최적화를 어렵게 만듭니다.
- 권장: config.json에서 전략을 교체할 수 있도록 Strategy 인터페이스를 도입하고 로직을 클래스로 분리하십시오. (장기 유지보수성 향상)

백테스팅용 로깅 데이터 강화
- 이유: 현재 거래 기록에는 가격/수량만 저장되어, 왜 그 시점에 매수/매도했는지 사후 분석이 불가능합니다.
- 권장: 매매 시점의 주요 보조지표 값(MACD, RSI, ADX 등)을 trades.json의 result 필드에 함께 기록하십시오.

~~시장 데이터 캐싱 효율화 (Reader-Writer Lock)~~
- 이유: 현재 스레드 개수(8개)와 호출 빈도(60초)를 고려할 때, 락 경합이 미미하므로 Python의 RLock으로 충분합니다. 과도한 최적화(Premature Optimization)로 판단되어 제외합니다.