Build a Finance Research Agent with Live Web Search + Scraping Using Firecrawl

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Firecrawl로 실시간 금융 자료를 검색·수집·구조화하고 LLM은 이를 분석하도록 분리하는 금융 리서치 에이전트의 설계와 일부 TypeScript 구현을 소개한다.

📌 핵심 요약

• 금융 리서치 에이전트는 실행할 때마다 SEC EDGAR, 기업 IR 페이지, 금융 뉴스 등에서 자료를 가져와 LLM 학습 데이터의 시점 한계를 보완한다.
• 원문이 인용한 2025년 연구는 197,000개 이상의 금융 질문에서 매출 답변 정확도가 2017년 자료의 경우 기업의 54%, 1995년 자료는 6%였다고 보고하며, FailSafeQA는 적대적 입력에서 금융 질문의 환각률을 41%로 제시한다.
• 원문은 유료 금융 데이터 서비스의 비용과 yfinance의 요청 제한을 대안 탐색의 배경으로 제시한다. 공개 자료 중 기업 IR 페이지는 실적 발표를 가장 빠르게 제공하는 출처인 경우가 많고, 해당 10-Q는 SEC EDGAR에 며칠 뒤 올라올 수 있다고 설명한다.
• Firecrawl은 JavaScript 렌더링, 본문 중심 마크다운 변환, Zod 스키마 기반 JSON 추출을 제공하며, /parse로 PDF·DOCX·스프레드시트도 처리한다. Alexandria는 검색 과정에 Fiscal.ai, SEC EDGAR, FRED 등의 데이터 도구를 연결한다.
• 에이전트는 Search → Scrape → Extract → Analyze 순서로 구성하며, 긴 공시는 제목별로 나누고 LLM 입력에 출처 URL과 수집 시각을 포함한다. TypeScript 예시는 tools.ts와 agent.ts로 나뉘지만, 제공된 본문은 첫 검색 도구의 입력 스키마 작성 중 잘려 있어 전체 구현은 확인할 수 없다.

🧩 주요 포인트

1. 학습 데이터의 시점 한계와 기간별 정확도 차이 → 금융 수치는 실행 시점에 수집하고 LLM의 역할을 제공된 근거의 분석으로 제한하는 설계가 핵심이다.
2. 기업 IR 페이지와 SEC EDGAR의 게시 시차 및 URL 변화 → 질문의 시급성과 자료 유형에 맞춰 출처를 선택하고 Search로 현재 주소를 찾는 과정이 중요하다.
3. Firecrawl의 마크다운·JSON 변환과 출처 URL·수집 시각 → 다양한 금융 자료를 공통 분석 입력으로 정리할 수 있지만, 제공된 TypeScript 코드의 완결성은 확인되지 않는다.

🧠 상세 정리

1. 학습된 금융 지식에서 실행 시점의 근거로

Hiba Fathima의 글은 LLM이 기업의 최신 실적에 대해 구체적인 숫자를 자신 있게 제시하더라도, 그 숫자가 이전 시기의 정보일 수 있다는 문제에서 출발한다. 원문은 이를 단순한 정보 날조와 구분하면서, 학습 데이터의 마감 시점과 분기마다 갱신되는 금융 정보의 주기가 일치하지 않는 데 주목한다. 금융 리서치 에이전트는 실행할 때마다 SEC EDGAR, 기업 IR 페이지, 금융 뉴스에서 관련 자료를 가져와 모델에 전달하는 방식으로 이 한계를 보완한다. 따라서 학습된 지식을 바탕으로 응답하는 금융 챗봇과 달리, 사실의 공급은 실시간 검색·수집이 맡고 LLM은 새로 확보한 근거를 해석하는 역할을 맡는다는 것이 글의 중심 주장이다.

2. 금융 답변의 정확도 문제를 보여주는 연구

원문은 2025년 초까지의 자료로 학습한 모델이 Q4 2025 실적 발표 내용을 알 수 없으며, 최신 분기를 묻는 질문에 과거 기간의 수치를 답할 위험이 있다고 설명한다. 이어 197,000개 이상의 금융 질문을 평가한 2025년 arXiv 연구를 인용하며, 매출 질문에 정확히 답한 기업 비율이 2017년 자료에서는 54%였지만 1995년 자료에서는 6%였다고 제시한다. 연구자들이 'retrograde knowledge bias'라고 부르는 이 현상은 오래 공개된 정보라도 기간에 따라 정확도가 불안정할 수 있다는 근거로 사용된다. 별도로 FailSafeQA의 적대적 입력 조건에서는 금융 질문의 환각률이 41%였다고 소개하며, 원문은 조금 모호하거나 불완전한 실제 사용자 질문에서도 이 문제가 중요하다고 연결한다.

3. 유료 서비스와 비공식 수집 방식의 제약

원문은 2026년 5월 기준 제3자 거래 기록을 근거로 Bloomberg Terminal의 연간 좌석당 비용을 약 28,320~31,980달러로 제시하면서, Bloomberg가 공식 가격을 공개하지 않는다고 명시한다. FactSet은 사용자당 약 4,000달러에서 모듈에 따라 30,000달러까지, LSEG Workspace는 사용자당 10,000~42,000달러라고 소개하며 개발자에게 비용 부담이 크다고 주장한다. 대안으로 널리 쓰이는 yfinance는 Yahoo Finance에서 과거 가격·기초 재무정보·실적 자료를 가져오는 오픈소스 Python 라이브러리이지만, 원문은 이를 정식 API가 아닌 HTML 수집 방식으로 설명한다. 또한 Yahoo가 2024년 초 무렵 제한을 강화한 뒤 하루 4~5회 요청만으로 YFRateLimitError를 경험했다는 개발자 보고를 인용하며, 이런 불안정성이 에이전트 운용의 제약이라고 지적한다.

4. 출처별 역할과 검색을 먼저 수행하는 이유

원문은 SEC EDGAR의 10-K·10-Q·8-K 공시, 기업 IR의 실적 발표, 금융 뉴스, Federal Reserve와 Treasury의 경제 자료 등을 주요 수집 대상으로 제시한다. 여기에 실적 발표 통화 기록, 시장 정보 집계 사이트, 채용 공고·리뷰·웹 트래픽 같은 대체 데이터도 포함하며, 표준화된 재무제표와 공시 목록 등은 Alexandria를 통한 데이터 도구 연결로 다룬다. 기업 IR의 구조는 자주 바뀌고 특정 SEC 공시의 URL은 추측하기 어렵기 때문에, 고정 주소에 의존하기보다 Search로 현재 자료의 주소를 찾은 뒤 수집하는 순서를 권한다. 특히 기업 IR에는 실적 발표 직후 자료가 게시되고 해당 10-Q는 EDGAR에 며칠 늦게 올라올 수 있다고 설명하며, 시간에 민감한 분석에서는 이런 게시 시차가 출처 선택에 영향을 준다고 강조한다.

5. 웹 금융 문서의 렌더링과 구조화

원문은 SEC EDGAR의 공시 뷰어와 React 기반 기업 IR 페이지처럼 동적으로 표시되는 문서를 일반적인 fetch와 HTML 파서로 처리하면 내용이 비거나 불완전할 수 있다고 설명한다. Firecrawl은 서버에서 JavaScript를 렌더링하므로 정적 HTML과 JavaScript 중심 페이지에 동일한 API 호출을 사용할 수 있다고 소개한다. 또한 탐색 메뉴·푸터·쿠키 배너·광고 요소를 제거하고 본문을 마크다운으로 반환해, LLM 입력에서 불필요한 토큰을 줄이는 효과를 주장한다. 구조화된 수치가 필요할 때는 사이트별 CSS 선택자나 XPath 대신 Zod 스키마에 원하는 필드를 정의하고 LLM 보조 추출을 사용하며, 이를 통해 서로 다른 기업 IR 화면에서도 공통된 JSON 구조로 자료를 받을 수 있다는 설명이다.

6. 로컬 파일과 데이터 도구로 넓어지는 입력 범위

글은 금융 업무의 입력이 웹페이지에만 한정되지 않으며, 내려받은 10-K PDF, 이메일로 받은 연구 보고서, 내보낸 스프레드시트도 자주 사용된다고 설명한다. Firecrawl의 /parse는 PDF·DOCX·스프레드시트를 직접 받아 웹페이지의 /scrape와 같은 형태의 마크다운이나 구조화된 JSON을 반환하고, 표의 읽기 순서도 보존한다고 소개한다. 이 방식의 의미는 웹 자료와 로컬 파일을 별개의 처리 체계로 나누지 않고 동일한 분석 흐름에 넣을 수 있다는 데 있다. 한편 Alexandria는 sources: ["web", "alexandria"]를 사용하는 검색과 alexandria 블록을 포함한 수집을 통해 Fiscal.ai, SEC EDGAR, FRED 등의 도구를 연결하며, 원문은 표준화된 재무제표·공시 목록·13F 보유 내역·거시경제 시계열 등을 관련 데이터로 제시한다.

7. Search에서 Analyze까지 이어지는 처리 흐름

에이전트의 기본 흐름은 Search, Scrape, Extract, Analyze의 네 단계이며, 앞의 단계들이 확보한 근거를 마지막 LLM 분석에 전달한다. Search는 자연어 질의로 URL과 제목을 찾고 선택적으로 페이지의 마크다운 본문도 반환하므로, 간단한 질문은 검색 결과만으로 충분해 별도 수집을 생략할 수 있다고 설명한다. Scrape에서는 onlyMainContent: true로 본문을 가져오며, 수백 페이지에 이르는 10-K는 보존된 제목 구조를 기준으로 나눠 모델에 전달하도록 권한다. Extract는 Zod 스키마로 매출·EPS·가이던스 같은 값을 JSON으로 추출하고, Analyze에서는 수집한 본문과 수치를 바탕으로 추론하게 하되 출처 URL과 수집 시각을 프롬프트에 포함해 결과에서 근거를 인용할 수 있도록 한다.

8. TypeScript 구현의 구성과 제공 범위

원문은 구현을 두 파일로 나누어 tools.ts에 Firecrawl 기반 도구 세 개를 정의하고, agent.ts에서 금융 전용 시스템 프롬프트와 generateText 반복 처리에 연결한다고 안내한다. 실제로 제공된 코드에는 firecrawl, ai, zod의 가져오기와 환경 변수 FIRECRAWL_API_KEY를 사용하는 Firecrawl 초기화가 나타난다. FinancialMetricsSchema는 company_name과 reporting_period를 필수 문자열로 두고, 매출·순이익·주당순이익·다음 분기 매출 가이던스·주요 위험을 선택 필드로 정의한다. 다만 본문은 searchFinancialSources의 query 설명 문자열 중간에서 끝나므로, 도구 세 개의 전체 정의나 agent.ts의 실행 흐름은 확인할 수 없으며 목차에 있는 후속 활용·운영 확장 내용도 구체적인 설명으로 제공되지는 않는다.

🧾 핵심 주장 / 시사점

• 실시간 수집은 학습 데이터의 시점 한계를 보완하지만, 인용된 기간별 정확도 차이와 환각률은 별도의 연구 조건에서 나온 결과이므로 이를 곧바로 이 에이전트의 성능 수치로 볼 수는 없다.
• 기업 IR 페이지와 SEC EDGAR의 게시 시차는 같은 기업의 자료라도 질문의 시급성과 필요한 문서 유형에 따라 적절한 출처가 달라질 수 있음을 보여준다.
• Firecrawl의 공통 출력 형식은 자료 처리의 일관성을 높이는 설계 요소이며, 출처 URL과 수집 시각은 분석에 사용한 근거와 기준 시점을 드러내는 역할을 한다.

✅ 액션 아이템

• 금융 수치를 실행 시점에 수집하고 LLM은 제공된 근거를 분석하도록 역할 분리를 적용한다.
• 기업 IR 페이지와 SEC EDGAR의 게시 시차를 고려해 출처를 선택하고 Search로 현재 URL을 확인한다.
• LLM 입력에 출처 URL과 수집 시각을 포함하고, 제공된 TypeScript 코드의 누락 부분을 확인한다.

❓ 열린 질문

• 기업 IR 페이지와 SEC EDGAR의 게시 시차를 고려할 때 어떤 질문에서 기업 IR 페이지를 우선할 것인가?
• Search 결과만으로 분석하기에 충분한 경우와 Scrape가 추가로 필요한 경우를 어떻게 구분할 것인가?
• 제공된 TypeScript 코드에서 확인할 수 없는 tools.ts의 나머지 도구와 agent.ts의 전체 구현은 어디에서 확인할 수 있는가?