TestForge Blog
← 전체 포스트

RAG 기반 AI 주식 투자 Agent 2편 - 시장 데이터, 뉴스, 공시를 RAG 지식베이스로 만드는 방법

주식 투자 Agent의 핵심은 최신 문맥입니다. 시세, 뉴스, SEC 공시, 실적 발표 transcript를 어떻게 수집하고 정규화하며, 종목 중심 RAG 검색이 가능하도록 적재할지 데이터 파이프라인 관점에서 설명합니다.

TestForge Team ·

투자 Agent에서 RAG 데이터는 일반 RAG와 다르다

문서형 RAG는 보통 제품 매뉴얼이나 FAQ를 다룹니다. 하지만 투자 Agent는 시간이 지나면 정보 가치가 급격히 변합니다.

예:

  • 2시간 전 뉴스와 2주 전 뉴스의 의미가 다름
  • 전분기 실적과 최신 가이던스가 충돌할 수 있음
  • 공시 문서의 타입에 따라 중요도가 다름

즉, 이 시스템의 RAG는 최신성과 이벤트 우선순위를 반드시 반영해야 합니다.

어떤 데이터가 필요한가

초기 버전에서 필요한 데이터는 크게 4종류입니다.

1. 시세 데이터

  • 일봉 OHLCV
  • 분봉 또는 시간봉
  • 거래량
  • 변동성 지표 계산용 데이터

2. 뉴스 데이터

  • 종목 연관 뉴스
  • 섹터 뉴스
  • 매크로 뉴스
  • 투자 의견 리포트 요약 데이터

3. 공시 데이터

  • 10-K / 10-Q
  • 8-K
  • 실적 발표 자료
  • 가이던스 변경 문서

4. 실적 발표 transcript

  • earnings call transcript
  • management commentary
  • analyst Q&A

특히 transcript는 숫자보다 분위기와 우려 포인트를 파악하는 데 강한 재료가 됩니다.

저장 계층은 어떻게 나눌까

이 데이터는 성격이 다르기 때문에 저장 전략도 다르게 가야 합니다.

권장 구조:

PostgreSQL
- symbol
- price_bar
- corporate_event
- news_article
- filing_document
- transcript_document
- analysis_run

Object Storage
- raw JSON
- 원본 HTML/PDF
- transcript 원문

pgvector
- 뉴스 chunk embedding
- 공시 chunk embedding
- transcript chunk embedding

Redis
- 최신 질의 캐시
- 실시간 요약 캐시

원본과 정제본을 분리해 두는 것이 중요합니다.

종목 중심 스키마를 먼저 잡자

투자 Agent에서는 모든 데이터가 symbol 중심으로 연결되어야 합니다.

예를 들면 이런 형태입니다.

symbol: NVDA
 ├─ price bars
 ├─ earnings events
 ├─ filing documents
 ├─ news articles
 ├─ transcript chunks
 └─ embedding chunks

이 연결이 없으면 retrieval 시 종목 문맥을 정리하기 어렵습니다.

뉴스 수집 파이프라인

뉴스는 가장 변동성이 크고 노이즈도 많습니다.

파이프라인 예시:

News API Fetch
 -> duplicate filtering
 -> ticker mapping
 -> article body extraction
 -> event tagging
 -> chunking
 -> embedding
 -> vector store upsert

여기서 특히 중요한 건 ticker mapping입니다.

예:

  • Apple이라는 단어가 과일인지 기업인지
  • META가 메타인지 일반 단어인지
  • 동일 뉴스가 여러 배포사에 복제되는 경우

이 문제를 해결하지 않으면 검색 결과가 쉽게 오염됩니다.

공시 문서는 타입별로 다뤄야 한다

모든 공시를 똑같이 취급하면 안 됩니다.

예를 들어:

  • 8-K: 이벤트성 공시
  • 10-Q: 분기 실적
  • 10-K: 연간 사업 구조

검색 시에도 우선순위를 다르게 줄 수 있습니다.

권장 메타데이터:

{
  "symbol": "AAPL",
  "doc_type": "10-Q",
  "filing_date": "2026-04-15",
  "period": "Q1 2026",
  "importance": "high",
  "source": "sec"
}

transcript는 왜 중요한가

실적 발표 transcript는 숫자 데이터만으로는 잡히지 않는 맥락을 줍니다.

예:

  • 경영진이 특정 시장에 대해 조심스러운 톤을 보이는지
  • AI, 공급망, 가격 정책을 얼마나 자주 언급하는지
  • 애널리스트 질문에 방어적으로 대응하는지

이런 정보는 나중에 Agent가 정성 분석을 생성할 때 중요한 재료가 됩니다.

chunking 전략도 데이터 타입별로 달라야 한다

뉴스

  • 기사 1개 단위
  • 필요 시 본문 단락별 분할
  • 제목과 시간 정보 유지

공시

  • 섹션 기반 청킹
  • Risk Factors, Guidance, Financial Results 구간 분리

transcript

  • speaker turn 단위
  • Q&A 구간 별도 구분
  • CEO/CFO/Analyst 메타데이터 유지

예:

{
  "symbol": "MSFT",
  "source_type": "transcript",
  "speaker": "CEO",
  "section": "Prepared Remarks",
  "event_date": "2026-04-12"
}

시간 가중치를 검색에 반영하자

투자 Agent에서는 최신 뉴스가 더 중요하지만, 항상 최신이 정답은 아닙니다.

예:

  • 하루 전 루머보다 3일 전 공식 실적 발표가 더 중요
  • 1주 전 8-K가 오늘 일반 뉴스보다 중요할 수도 있음

따라서 retrieval score는 단순 유사도만으로 끝내지 말고, 아래 요소를 합성하는 편이 좋습니다.

  • semantic similarity
  • document type weight
  • recency weight
  • symbol relevance
  • source quality

간단한 예:

final_score = (
    similarity * 0.5
    + recency_score * 0.2
    + doc_importance * 0.2
    + symbol_match * 0.1
)

검색 시 어떤 필터가 필요한가

사용자 질문:

최근 2주간 테슬라 리스크 요인 정리해줘

필요한 검색 필터:

  • symbol = TSLA
  • date >= now - 14d
  • source_type in [news, filing, transcript]

이 필터가 없으면 관련 없는 섹터 뉴스까지 섞일 수 있습니다.

이벤트 정규화가 중요하다

시장 데이터와 뉴스는 그대로 두면 조합이 어렵습니다.

그래서 아래처럼 이벤트 레이어를 만드는 편이 좋습니다.

예:

corporate_event
- symbol
- event_type
- event_time
- source_ids
- summary

이벤트 타입 예:

  • earnings_release
  • guidance_change
  • analyst_downgrade
  • regulation_news
  • product_launch

이 레이어가 있으면 Agent가 최근 이벤트 흐름을 쉽게 요약할 수 있습니다.

추천 배치 설계

시장 데이터는 주기별로 다르게 가져가는 편이 좋습니다.

  • 시세: 분 단위 또는 일 단위
  • 뉴스: 5~15분 단위
  • 공시: 10~30분 단위
  • transcript: 이벤트 발생 후 배치 적재

초기 버전은 완전 실시간이 아니어도 괜찮습니다. 대신 적재 실패를 놓치지 않는 것이 더 중요합니다.

자주 하는 실수

최신성과 신뢰도를 같은 것으로 보는 경우

가장 최근 뉴스가 가장 믿을 만한 뉴스는 아닙니다.

종목 매핑이 부정확한 경우

관련 없는 종목 기사까지 retrieval에 들어가면 Agent 품질이 급격히 떨어집니다.

공시와 일반 뉴스를 같은 중요도로 처리하는 경우

투자 판단 기준이 흔들립니다.

마무리

RAG 기반 투자 Agent의 데이터 계층은 단순 문서 저장소가 아니라 시장 이벤트 지식베이스에 가깝습니다.

핵심은 아래 세 가지입니다.

  • 종목 중심으로 데이터를 연결하고
  • 문서 타입별로 구조를 다르게 보존하고
  • 최신성과 중요도를 검색 점수에 반영하는 것

다음 글에서는 이 지식베이스를 바탕으로 실제 Agent가 어떻게 종목을 스크리닝하고, 어떤 도구를 호출하며, 분석을 생성할지 workflow 중심으로 설계해보겠습니다.