RAG 기반 AI 주식 투자 Agent 4편 - 포트폴리오 구성, 리스크 룰, 백테스트 설계
좋은 종목 분석만으로는 투자 Agent가 완성되지 않습니다. 포지션 크기, 섹터 집중도, 손실 한도, 이벤트 리스크, 백테스트와 paper trading까지 포함한 실제 투자 시스템 관점의 설계를 설명합니다.
종목 분석과 포트폴리오 운용은 다른 문제다
AI Agent가 특정 종목을 좋게 본다고 해서 바로 매수 결론으로 이어지면 안 됩니다.
투자 시스템에서는 최소한 세 가지를 분리해야 합니다.
- 종목 품질
- 현재 포트폴리오 상태
- 리스크 허용 범위
예를 들어 어떤 종목이 매우 좋아 보여도 이미 비슷한 테마 비중이 높다면 신규 진입은 오히려 위험할 수 있습니다.
포트폴리오 계층을 따로 둬야 하는 이유
이 Agent는 단일 종목 분석 도구가 아니라, 최종적으로는 포트폴리오 관점 결정을 지원해야 합니다.
그래서 별도 계층이 필요합니다.
Signal Layer
-> Candidate Selection
-> Position Sizing
-> Portfolio Constraints
-> Risk Checks
-> Paper Order Proposal
여기서 Agent는 Signal Layer와 Candidate Selection에 강하고, 나머지는 비교적 결정적 로직으로 가는 편이 안정적입니다.
포지션 sizing은 어떻게 시작할까
처음부터 복잡한 최적화 모델을 넣지 않아도 됩니다.
초기에는 아래 원칙으로 시작하는 편이 좋습니다.
- 단일 종목 최대 비중 제한
- 섹터 최대 비중 제한
- 전략별 자본 한도
- 변동성 높은 종목은 smaller size
예:
def target_weight(volatility_20d: float) -> float:
if volatility_20d > 0.45:
return 0.02
if volatility_20d > 0.30:
return 0.03
return 0.05
이렇게 단순한 규칙만 있어도 “좋아 보이니 크게 사자” 같은 위험한 행동을 막을 수 있습니다.
리스크 룰은 LLM 밖에 있어야 한다
리스크 룰을 프롬프트 안에만 넣는 것은 위험합니다.
반드시 애플리케이션 레벨에서 검사해야 하는 룰:
- 단일 종목 최대 비중
- 섹터 최대 비중
- 1일 최대 신규 진입 수
- 최근 실적 발표 직전/직후 거래 제한
- 최대 허용 drawdown 초과 시 신규 포지션 중단
예시:
def evaluate_trade(symbol, candidate_weight, portfolio):
if portfolio.single_name_exposure(symbol) + candidate_weight > 0.10:
return "reject: single-name limit exceeded"
if portfolio.sector_exposure(symbol) + candidate_weight > 0.25:
return "reject: sector limit exceeded"
return "pass"
이 로직은 설명 가능한 형태로 남아야 합니다.
이벤트 리스크는 별도 체크가 필요하다
주식 투자에서 가장 큰 변동은 대개 이벤트에서 나옵니다.
예:
- 실적 발표
- FOMC
- CPI 발표
- 규제 발표
- 제품 출시
이벤트 직전 매수는 전략적으로 유효할 수도 있지만, 기본 모드에서는 보수적으로 접근하는 편이 좋습니다.
예:
if earnings_date <= now + 24h:
신규 포지션 금지
if FOMC day:
레버리지 전략 비활성화
백테스트는 어디까지 믿어야 할까
투자 Agent에서 가장 흔한 착시는 “백테스트 수익률이 좋으니 실제로도 잘 될 것”이라고 믿는 것입니다.
하지만 Agent 기반 전략은 특히 아래 문제가 큽니다.
- 미래 데이터 누수
- 뉴스 시점 정렬 오류
- 생존 편향
- 과최적화
- transaction cost 미반영
RAG 기반 시스템은 특히 문서가 언제 실제로 시장에 알려졌는가를 엄격하게 다뤄야 합니다.
백테스트 엔진에 필요한 요소
최소한 아래 요소가 필요합니다.
- universe 정의
- 시점별 데이터 snapshot
- 신호 생성 규칙
- 리스크 룰
- 거래 비용
- 슬리피지
- 성과 지표
성과 지표 예:
- CAGR
- Sharpe
- max drawdown
- hit ratio
- average holding period
- turnover
RAG 기반 전략의 백테스트가 어려운 이유
정량 전략은 과거 가격과 지표만으로 재현이 쉽습니다. 하지만 RAG 기반 전략은 문서 시계열이 핵심입니다.
예:
- 2026-04-15 08:30에 공개된 실적 자료
- 2026-04-15 09:10에 배포된 뉴스
- 2026-04-15 10:00에 transcript 요약 생성
이 타임라인을 정확히 보존해야 당시 기준 Agent가 접근 가능한 정보만 사용하게 할 수 있습니다.
즉, 백테스트용 데이터 저장소는 “최신 상태”가 아니라 시점별 snapshot을 제공해야 합니다.
paper trading은 백테스트와 다르다
paper trading은 실제 시장 타이밍과 운영 흐름을 검증하는 단계입니다.
검증할 수 있는 것:
- 스케줄링 문제
- 데이터 지연
- 중복 시그널 발생
- 승인 workflow
- 알림 시스템
- 주문 생성 로직
많은 팀이 백테스트만 보고 배포하지만, 실제 운영 문제는 paper trading에서 더 많이 드러납니다.
추천 workflow
초기 운영은 아래 흐름이 좋습니다.
- Agent가 매일 후보 종목 생성
- 리스크 엔진이 rule check 수행
- 통과한 후보만 paper order 생성
- 사람이 승인/거절
- 결과와 근거 저장
- 사후 성과 추적
이 구조면 기술적 실험과 운영 통제를 동시에 할 수 있습니다.
포트폴리오 관점 출력 예시
좋은 응답은 이런 형태가 될 수 있습니다.
후보 종목:
- NVDA 3%
- MSFT 4%
제외 종목:
- AMD: 반도체 섹터 비중 한도 초과
- TSLA: 실적 발표 12시간 전, 이벤트 리스크 높음
포트폴리오 영향:
- AI 인프라 노출 18% -> 22%
- 단일 종목 최대 비중 규칙 위반 없음
이런 출력이 있어야 Agent가 실제 운용 도구에 가까워집니다.
마무리
RAG 기반 투자 Agent가 실전 시스템이 되려면, 분석 엔진 뒤에 반드시 포트폴리오와 리스크 계층이 있어야 합니다.
핵심은 아래와 같습니다.
- 좋은 분석이 곧 좋은 주문은 아니다
- 포지션 sizing과 한도 규칙은 LLM 밖에서 결정해야 한다
- 백테스트는 시점 정합성이 생명이다
- 실전 전에는 paper trading으로 운영 흐름을 검증해야 한다
다음 글에서는 이 구조를 실제 서비스로 구현하기 위해 FastAPI, PostgreSQL, pgvector, Redis를 중심으로 한 개발 구조를 구체적으로 설계해보겠습니다.