RAG 기반 AI 주식 투자 Agent 3편 - Agent Workflow, Tool Calling, 분석 체인 설계

주식 투자 Agent는 ‘한 번의 답변’이 아니라 분석 파이프라인이다

사용자가 묻는 질문은 짧아도, 내부적으로는 여러 단계의 분석이 필요합니다.

예:

최근 실적 발표 이후 아마존이 다시 진입할 만한 구간인지 분석해줘

이 질문은 내부적으로 아래를 요구합니다.

가격 추세 확인
실적 이벤트 확인
뉴스/공시 검색
기존 포트폴리오 노출도 확인
리스크 룰 적용
최종 설명 생성

즉, Agent는 대화 모델이 아니라 분석 오케스트레이터에 가깝습니다.

권장 역할 분리

이 시스템은 최소한 아래 역할로 나누는 편이 좋습니다.

Router
 -> Query Parser
 -> Screener
 -> Retrieval Analyst
 -> Quant Analyzer
 -> Risk Evaluator
 -> Response Composer

각자의 책임은 아래와 같습니다.

Router

질문 유형 분류
단일 종목 분석인지, 스크리닝인지, 포트폴리오 점검인지 판단

Query Parser

기간, 종목, 조건, 전략 의도 파악
구조화된 요청으로 변환

Screener

universe 필터링
가격/거래량/재무 기준 후보 압축

Retrieval Analyst

관련 뉴스/공시/transcript 검색
이벤트 중심 문맥 정리

Quant Analyzer

수익률, 변동성, drawdown, factor 계산
기술/기본 지표 분석

Risk Evaluator

포지션 집중도
손실 한도
이벤트 리스크
매수 금지 조건 점검

Response Composer

사람에게 읽기 쉬운 분석 보고서 생성
출처와 숫자 근거 포함

Tool Calling은 어떻게 설계할까

초기에는 아래 정도의 도구면 충분합니다.

[
  {"name": "get_price_summary"},
  {"name": "screen_symbols"},
  {"name": "search_news_context"},
  {"name": "search_filing_context"},
  {"name": "get_financial_metrics"},
  {"name": "get_portfolio_exposure"},
  {"name": "evaluate_risk_rules"}
]

중요한 점은 각 도구가 모호하면 안 된다는 것입니다.

나쁜 도구:

analyze_stock
search_market

좋은 도구:

get_price_summary(symbol, start_date, end_date)
search_filing_context(symbol, topic, days)
evaluate_risk_rules(symbol, portfolio_id, candidate_weight)

Query Parser가 꼭 필요한 이유

사용자 질문은 구조화되어 있지 않습니다.

예:

최근 2주 실적 발표 이후 반도체 대형주 중 과열되지 않은 후보 3개만 골라줘

이 문장을 파싱하면 대략 아래와 같은 구조가 됩니다.

{
  "intent": "screening",
  "sector": "semiconductor",
  "market_cap": "large",
  "event": "earnings",
  "window_days": 14,
  "constraint": "not_overheated",
  "top_n": 3
}

이 구조가 있어야 tool 호출과 리스크 평가가 안정적으로 이어집니다.

Screener는 LLM이 아니라 규칙 엔진에 가깝다

주식 스크리닝은 대부분 결정적 로직으로 처리하는 편이 맞습니다.

예:

최근 20일 평균 거래대금 이상
시가총액 상위 500위 이내
최근 실적 발표 존재
특정 변동성 범위

이 단계는 LLM보다 SQL과 지표 계산이 훨씬 적합합니다.

예:

select symbol
from symbol_snapshot
where market_cap_rank <= 500
  and avg_dollar_volume_20d >= 50000000
  and last_earnings_date >= current_date - interval '14 days';

LLM은 이 후보군을 해석하고 요약하는 데 쓰는 편이 효율적입니다.

Retrieval Analyst는 정량 결과에 문맥을 붙이는 역할이다

스크리닝으로 후보를 뽑았다면, Retrieval Analyst는 아래를 보강합니다.

최근 뉴스 방향성
공시 이벤트
실적 발표 핵심 문장
가이던스 변화
규제/소송/공급망 이슈

즉, Quant Analyzer가 숫자를 본다면 Retrieval Analyst는 숫자 바깥의 이유를 붙여 줍니다.

Quant Analyzer는 어떤 출력을 내야 할까

단순 지표 계산을 넘어서, Agent가 바로 쓸 수 있는 구조화 결과를 내는 편이 좋습니다.

예:

{
  "symbol": "NVDA",
  "return_20d": 0.124,
  "volatility_20d": 0.31,
  "max_drawdown_60d": -0.08,
  "rsi_14": 67.2,
  "earnings_gap": 0.052,
  "trend_label": "strong_uptrend"
}

이 결과를 Response Composer가 그대로 인용할 수 있어야 합니다.

Risk Evaluator는 반드시 분리하자

투자 Agent에서 가장 위험한 실수는 분석과 리스크 판단이 섞이는 것입니다.

분리 이유:

분석은 긍정적일 수 있음
하지만 포트폴리오 관점에서는 추가 매수가 부적절할 수 있음

예:

종목 자체는 강함
이미 해당 섹터 비중이 35%
이벤트 리스크가 24시간 내 예정
단일 종목 비중 한도 초과

이 경우 최종 제안은 관심 종목 유지, 신규 비중 확대는 보류가 될 수 있습니다.

Response Composer는 ‘추천’보다 ‘근거 보고서’를 만들어야 한다

좋은 응답 형식 예:

결론
정량 근거
정성 근거
리스크 요인
출처

예:

결론:
현재 추세는 긍정적이지만, 단기 변동성과 실적 이벤트 직후 과열 가능성 때문에 신규 진입은 분할 접근이 더 적절하다.

정량 근거:
- 최근 20일 수익률 +12.4%
- RSI 67.2
- 최근 60일 최대 낙폭 -8%

정성 근거:
- 최근 실적 발표에서 데이터센터 매출 가이던스 상향
- 주요 공급망 이슈 언급 없음

리스크:
- AI 반도체 섹터 집중도 높음
- 단기 차익실현 변동성 가능성

multi-agent로 바로 가야 할까

많은 경우 아직은 아닙니다.

초기 버전은 하나의 orchestrator 안에서 역할을 분리한 단일 시스템으로도 충분합니다. 진짜 multi-agent가 필요한 시점은 보통 아래 경우입니다.

전략 탐색 Agent
뉴스 해석 Agent
포트폴리오 Agent
리스크 통제 Agent

이들이 독립적으로 긴 작업을 수행해야 할 때입니다.

초기에는 오히려 복잡도만 늘 수 있습니다.

마무리

주식 투자 Agent의 핵심은 말을 잘하는 LLM이 아니라, 정량 분석과 정성 검색, 리스크 검사를 순서 있게 묶는 workflow입니다.

좋은 구조는 아래를 만족합니다.

스크리닝은 결정적 로직으로
문맥 보강은 RAG로
최종 판단 전에는 리스크 룰을 별도 적용
응답은 추천 문장보다 근거 보고서에 가깝게

다음 글에서는 이 결과를 실제 포트폴리오 제안으로 연결하기 위해, 포지션 sizing, 리스크 한도, 백테스트, paper trading 구조를 어떻게 설계할지 다뤄보겠습니다.