TradingAgents: 여러 에이전트로 동작되는 트레이딩 프레임워크

TradingAgents: LLM 애널리스트 팀이 토론해서 매매 결정을 만드는 멀티 에이전트 트레이딩 프레임워크

AI 에이전트가 코드를 짜고 문서를 읽고 업무를 자동화하는 시대가 왔지만, 정작 **“복잡한 의사결정을 팀처럼 나눠서 검토하는 시스템”**은 아직 많지 않습니다. 특히 트레이딩처럼 하나의 모델이 섣불리 결론을 내리면 위험한 영역에서는 더 그렇습니다.

TradingAgents는 이 지점을 정면으로 파고듭니다.
이 프로젝트는 “하나의 LLM이 종목을 찍는” 방식이 아니라, 시장 분석가, 뉴스 분석가, 펀더멘털 분석가, 강세/약세 연구원, 트레이더, 리스크 관리자를 역할별 에이전트로 쪼개고, 이들이 실제 운용사처럼 토론한 뒤 최종 결정을 내리게 만듭니다. 저장소 설명 그대로, 이 프레임워크는 실제 트레이딩 펌의 협업 구조를 모사한 멀티 에이전트 금융 트레이딩 시스템입니다. 2025년 논문으로 공개되었고, 2026년 3월 기준 저장소는 3만 4천 개 안팎의 스타를 받았으며 v0.2.1 릴리스가 올라와 있습니다. (GitHub)

 

GitHub - TauricResearch/TradingAgents: TradingAgents: Multi-Agents LLM Financial Trading Framework

 

---

프로젝트 소개

TradingAgents는 Tauric Research가 공개한 오픈소스 프로젝트로, 금융 트레이딩 의사결정을 멀티 에이전트 워크플로우로 분해한 Python 프레임워크입니다. 논문 제목도 그대로 Multi-Agents LLM Financial Trading Framework이고, 저장소 README 역시 “실제 트레이딩 회사의 역학을 반영한다”고 설명합니다. (GitHub)

기술적으로 보면 이 프로젝트의 중심은 세 가지입니다.

첫째, 역할 분리입니다. 시장/기술적 지표, 소셜·심리, 뉴스·거시, 펀더멘털을 각각 다른 에이전트가 분석합니다. 그다음 강세 연구원과 약세 연구원이 논쟁하고, 연구 매니저가 투자 플랜을 만들고, 트레이더가 매매 제안을 만든 뒤, 공격적/중립적/보수적 리스크 분석가가 다시 토론하고 최종 리스크 매니저가 BUY/HOLD/SELL을 결정합니다. (GitHub)

둘째, LangGraph 기반 오케스트레이션입니다. README에 LangGraph를 사용했다고 명시되어 있고, 실제 코드에서도 StateGraph, START, END, add_conditional_edges로 그래프 기반 워크플로우를 구성합니다. 즉 이 프로젝트는 단순 체인 호출이 아니라, 상태를 들고 순환하며 조건 분기하는 에이전트 그래프에 가깝습니다. (GitHub)

셋째, 데이터 공급자와 모델 공급자를 추상화했다는 점입니다. LLM은 OpenAI, Google, Anthropic, xAI, OpenRouter, Ollama까지 지원하고, 금융 데이터는 기본적으로 yfinance를 쓰되 Alpha Vantage로 대체하거나 fallback하도록 설계되어 있습니다. (GitHub)

개발 환경은 Python 중심입니다. pyproject.toml 기준으로 LangGraph, LangChain 계열 패키지, pandas, yfinance, stockstats, backtrader, redis, rich, typer 등이 들어가며, CLI도 같이 제공합니다. 즉 이 프로젝트는 “논문용 데모”에만 머무르지 않고, 실험·시뮬레이션·프롬프트 연구를 바로 해볼 수 있는 개발자 도구에 가깝습니다. (GitHub)

---

왜 이 프로젝트가 등장했을까

이 프로젝트가 흥미로운 이유는, 단순히 “트레이딩에 LLM을 붙였다”가 아니라 기존 단일 에이전트 접근의 한계를 구조적으로 해결하려고 했기 때문입니다.

논문 초록을 보면, 기존 금융 LLM 시스템은 대체로 단일 에이전트이거나 여러 에이전트가 있더라도 독립적으로 데이터만 모으는 수준이 많았고, 실제 운용 조직처럼 협업·반박·리스크 검토를 거치는 구조는 충분히 탐구되지 않았다고 문제를 정의합니다. 그래서 TradingAgents는 애널리스트, 연구원, 트레이더, 리스크 팀으로 구성된 협업 구조를 제안합니다. (arXiv)

개발자 관점에서 이 문제 정의는 꽤 설득력이 있습니다.

트레이딩 판단은 보통 다음 네 가지가 동시에 섞입니다.

• 가격과 거래량 같은 시계열 패턴
• 기업 자체의 재무 상태
• 뉴스와 거시 변수
• 군중 심리와 시장 내러티브

이 네 가지는 서로 충돌하는 경우가 많습니다. 예를 들어 기술적 지표는 강세인데, 펀더멘털은 부담스럽고, 뉴스는 악재일 수 있습니다. 단일 모델에게 이걸 한 번에 맡기면 보고서도 길어지고, 판단 근거도 뒤엉키고, 반대 논리를 충분히 검토하지 못하는 문제가 생깁니다.

TradingAgents는 이걸 사람 조직처럼 바꿉니다.
먼저 역할별 분석을 분리하고, 그 결과를 강세/약세 토론으로 부딪히게 만들고, 다시 리스크 팀이 다른 관점에서 재검토합니다. 다시 말해 이 프레임워크의 핵심은 “더 똑똑한 모델 1개”가 아니라, 서로 다른 편향을 가진 역할 10개 내외를 그래프로 조율하는 것입니다. 이게 이 프로젝트의 본질입니다. (GitHub)

---

핵심 기능

1. 역할 기반 분석 파이프라인

가장 먼저 눈에 띄는 건 Analyst Team입니다.
코드를 보면 market, social, news, fundamentals 네 종류의 애널리스트를 선택적으로 그래프에 넣을 수 있습니다. 각 노드는 자신만의 도구 세트를 사용합니다. 예를 들어 시장 분석가는 get_stock_data, get_indicators를 쓰고, 뉴스 분석가는 get_news, get_global_news를 쓰며, 펀더멘털 분석가는 재무제표 계열 툴을 사용합니다. (GitHub)

이 설계가 좋은 이유는 단순합니다.
개발자가 나중에 특정 역할만 바꾸기 쉽습니다. 예를 들어 소셜 분석 품질이 별로면 그 노드만 교체하면 되고, 펀더멘털 데이터 소스를 더 정교한 API로 바꾸고 싶다면 해당 툴 라우팅만 건드리면 됩니다.

---

2. 토론 기반 의사결정

이 프로젝트는 리포트를 단순 병합하지 않습니다.
강세 연구원과 약세 연구원이 서로 반박하고, 일정 라운드가 끝나면 Research Manager가 토론 기록을 바탕으로 투자 계획을 만듭니다. 이 라운드 수는 max_debate_rounds로 제어됩니다. 이후 Trader가 투자 계획을 바탕으로 매매 제안을 만들고, 다시 공격적/중립적/보수적 리스크 분석가가 토론합니다. 이 단계는 max_risk_discuss_rounds로 제어됩니다. (GitHub)

이게 중요한 이유는, 멀티 에이전트라고 해도 실제로는 “병렬 요약 후 마지막에 합치기” 수준인 프로젝트가 많기 때문입니다. TradingAgents는 적어도 구조상으로는 상반된 포지션 간 논쟁과 재판정 과정을 강제합니다. 즉, 정보 수집과 판단 생성이 분리되어 있습니다.

---

3. 메모리와 반성 루프

이 프로젝트는 한 번 판단하고 끝내지 않습니다.
reflect_and_remember()가 있고, FinancialSituationMemory라는 메모리 클래스가 있으며, 여기서 BM25 기반 lexical retrieval로 과거 상황과 반성 결과를 저장·검색합니다. README와 코드상으로 이 메모리는 오프라인 BM25를 사용하므로 별도 API 없이 동작합니다. 각 역할은 현재 시장 상황과 유사한 과거 반성 기록을 프롬프트에 주입받아 의사결정을 개선하도록 설계되어 있습니다. (GitHub)

여기서 포인트는 RAG를 벡터 DB로 하지 않았다는 점입니다.
금융 리포트 문맥이 길고 형식이 일정하지 않은데, 이 프로젝트는 아주 실용적으로 BM25를 택했습니다. 즉, “복잡한 메모리 인프라 없이도 회고 기반 개선 루프를 붙일 수 있다”는 좋은 예시입니다.

---

4. 공급자 추상화

TradingAgents는 LLM도, 데이터 API도 하드코딩하지 않습니다.

LLM 쪽은 create_llm_client() 팩토리로 공급자를 만들고, OpenAI/Google/Anthropic/xAI/OpenRouter/Ollama를 지원합니다. OpenAI 계열은 GPT-5 모델에서 temperature/top_p 충돌을 피하기 위해 파라미터를 정리하는 래퍼까지 둡니다. Google 쪽은 Gemini 응답 포맷 차이를 정규화합니다. (GitHub)

데이터 쪽은 route_to_vendor()가 핵심입니다.
카테고리별 기본 공급자를 설정하고, 필요하면 tool 단위 override도 가능하며, Alpha Vantage rate limit가 걸리면 다른 공급자로 fallback합니다. 즉 개발자가 “뉴스는 Alpha Vantage, 가격 데이터는 yfinance”처럼 섞어서 쓸 수 있습니다. (GitHub)

이건 실제 서비스 설계 관점에서 매우 중요합니다.
대부분 오픈소스는 한 API에 잠겨 있는데, TradingAgents는 모델 공급자 lock-in과 데이터 공급자 lock-in을 동시에 줄이려는 구조를 가지고 있습니다.

---

프로젝트 아키텍처 분석

TradingAgents의 핵심 클래스는 TradingAgentsGraph입니다.
이 클래스는 설정을 받고, LLM 클라이언트를 만들고, 메모리를 초기화하고, 툴 노드를 만들고, GraphSetup으로 LangGraph 워크플로우를 구성합니다. 이후 propagate(company_name, trade_date)를 호출하면 초기 상태를 만들고 그래프를 실행한 뒤, 최종 결정을 반환합니다. 또한 전체 상태를 JSON 로그로 저장하고, 이후 reflection 루프에 사용할 수 있게 설계되어 있습니다. (GitHub)

아키텍처를 단순화하면 아래와 같습니다.

이 구조에서 특히 볼 만한 점은 세 가지입니다.

1) 상태 중심 설계

AgentState 안에 메시지뿐 아니라 market_report, sentiment_report, news_report, fundamentals_report, investment_debate_state, risk_debate_state, final_trade_decision이 모두 들어갑니다. 즉 각 노드는 단순 프롬프트 호출기가 아니라, 공유 상태를 읽고 일부 필드를 갱신하는 상태 머신의 일부입니다. (GitHub)

2) 툴 호출과 리포트 생성을 분리

애널리스트 노드는 LangChain tool binding을 사용합니다. 마지막 응답에 tool call이 있으면 해당 tool node로 되돌아가고, tool call이 없으면 보고서를 state에 기록한 뒤 다음 단계로 넘깁니다. 이 conditional edge 로직이 should_continue_market, should_continue_news 같은 함수에 들어 있습니다. (GitHub)

이 패턴은 꽤 좋습니다.
왜냐하면 “도구를 언제 더 호출할지”와 “결과를 언제 확정할지”를 그래프 레벨에서 명시적으로 관리하기 때문입니다.

3) 이중 심사 구조

이 프로젝트는 결정을 두 번 압축합니다.

처음 압축은
애널리스트 리포트 → 강세/약세 토론 → Research Manager 투자 계획

두 번째 압축은
투자 계획 → 리스크 토론 → Risk Judge 최종 결정

즉, TradingAgents의 진짜 설계 철학은 “정보를 많이 모은다”가 아니라, 서로 다른 기준으로 두 번 합의한다입니다. 코드 흐름이 정확히 그렇게 짜여 있습니다. (GitHub)

---

코드로 보면 어떻게 쓰는가

README와 main.py 기준으로 가장 기본적인 사용법은 매우 단순합니다. TradingAgentsGraph를 만들고 propagate()를 호출하면 됩니다. (GitHub)

from tradingagents.graph.trading_graph import TradingAgentsGraph
from tradingagents.default_config import DEFAULT_CONFIG

config = DEFAULT_CONFIG.copy()
config["llm_provider"] = "openai"
config["deep_think_llm"] = "gpt-5.2"
config["quick_think_llm"] = "gpt-5-mini"
config["max_debate_rounds"] = 2
config["max_risk_discuss_rounds"] = 1

ta = TradingAgentsGraph(
    selected_analysts=["market", "social", "news", "fundamentals"],
    debug=False,
    config=config,
)

state, decision = ta.propagate("NVDA", "2026-01-15")
print(decision)

이 API가 좋은 이유는, 외부에서 볼 때 진입점이 거의 하나라는 점입니다.
복잡한 멀티 에이전트 시스템인데도 개발자는 propagate(ticker, date)만 기억하면 됩니다.

공급자 추상화도 설정 몇 줄이면 끝납니다.

from tradingagents.default_config import DEFAULT_CONFIG

config = DEFAULT_CONFIG.copy()

config["llm_provider"] = "google"
config["deep_think_llm"] = "gemini-3-pro"
config["quick_think_llm"] = "gemini-3-flash"

config["data_vendors"] = {
    "core_stock_apis": "yfinance",
    "technical_indicators": "yfinance",
    "fundamental_data": "alpha_vantage,yfinance",
    "news_data": "alpha_vantage,yfinance",
}

이런 설정은 실제로 실험 환경에서 유용합니다.
예를 들어 비용 때문에 빠른 모델과 느린 모델을 나누거나, 특정 데이터 API rate limit 때문에 fallback 체인을 걸고 싶을 때 곧바로 적용할 수 있습니다. 설정 구조상 그것이 가능하도록 이미 열어 둔 프로젝트입니다. (GitHub)

---

이 프로젝트의 진짜 장점

1. 멀티 에이전트를 “역할 조직”으로 구현했다

많은 멀티 에이전트 프로젝트는 사실상 “여러 프롬프트를 병렬 실행하는 래퍼”에 가깝습니다.
TradingAgents는 그보다 한 단계 더 나갑니다. 역할별 책임, 토론 구조, 판정자, 리스크 심사까지 있어서, 에이전트 간 상호작용 자체가 설계의 중심입니다. (GitHub)

2. 연구용으로 구조가 아주 좋다

분석가 수를 줄이거나, 토론 라운드를 바꾸거나, 특정 노드 프롬프트만 교체하거나, 데이터 공급자를 바꾸는 실험을 하기가 쉽습니다. 논문에서도 이 프레임워크가 baseline 대비 누적 수익률, Sharpe ratio, 최대 낙폭에서 개선을 보였다고 주장합니다. (arXiv)

3. 운영 경험을 염두에 둔 흔적이 있다

CLI가 있고, 상태 로그를 JSON으로 남기고, callback 기반 통계 핸들러를 붙일 수 있으며, 공급자 추상화와 fallback도 있습니다. 즉 이 프로젝트는 단순 논문 코드보다 도구로 계속 다듬으려는 방향이 보입니다. (GitHub)

---

아쉬운 점도 분명하다

이 프로젝트를 실제 서비스 관점에서 보면 한계도 명확합니다.

첫째, README에서 직접 밝히듯 연구 목적이며 금융 자문을 위한 것이 아닙니다. 매매 성능은 모델, 온도, 기간, 데이터 품질 등 비결정적 요인에 크게 좌우된다고 적고 있습니다. (GitHub)

둘째, 현재 구조는 프롬프트 기반 협업이 중심이라서,
에이전트들의 토론이 정말 “추론 개선”인지, 아니면 길어진 텍스트 재서술인지 평가가 어렵습니다. 이건 TradingAgents만의 문제가 아니라 대부분 멀티 에이전트 시스템의 공통 한계입니다.

셋째, 데이터 품질 의존도가 큽니다.
소셜 분석가도 실제로는 get_news 도구를 쓰고 있고, 완전한 실시간 소셜 파이프라인이라기보다 뉴스/심리 서술을 활용하는 형태에 더 가깝습니다. 즉 “소셜 미디어 분석”이라는 이름만 보고 트위터, Reddit, Stocktwits 같은 실시간 멀티소스 ingest를 기대하면 조금 다를 수 있습니다. (GitHub)

넷째, 실제 프로덕션 트레이딩에 바로 넣기엔 실행/검증/리스크 통제가 더 필요합니다.
브로커 연동, 포지션 관리, 슬리피지, 체결 모델, 거래비용, 모니터링, 재현성, 프롬프트 버전 관리, 가드레일 등은 별도 레이어가 필요합니다. 저장소도 최종 주문을 시뮬레이션된 교환소로 보낸다고 설명합니다. (GitHub)

---

개발자는 언제 쓰면 좋을까

이 프로젝트는 아래 같은 상황에서 특히 좋습니다.

1. 멀티 에이전트 아키텍처를 배우고 싶을 때

LangGraph 기반 상태 머신, 조건 분기, tool node, debate loop, reflection loop를 한 번에 볼 수 있습니다. “에이전트 오케스트레이션 예제”로 아주 좋습니다. (GitHub)

2. 금융 AI 리서치 프로토타입을 만들 때

주가 데이터, 뉴스, 재무제표, 기술지표를 함께 쓰는 실험 기반이 이미 깔려 있습니다. 직접 처음부터 조립할 필요가 적습니다. (GitHub)

3. “단일 모델 의사결정”의 한계를 줄이고 싶을 때

특히 고위험 도메인에서 찬반 토론과 리스크 심사를 강제하는 UX가 필요하다면, 이 구조는 꽤 좋은 출발점입니다.

반대로, 초저지연 HFT 시스템이나 실거래 자동매매 엔진을 기대한다면 이 프로젝트는 출발점은 될 수 있어도 완성품은 아닙니다. TradingAgents는 의사결정 레이어에 더 가깝고, 실행 레이어는 별도 설계가 필요합니다.

---

개인적으로 가장 인상적인 부분

저는 이 프로젝트를 “트레이딩 봇”보다 의사결정 조직 시뮬레이터로 보는 편이 더 정확하다고 생각합니다.

핵심 가치는 BUY/SELL 자체보다도,
왜 그렇게 판단했는지,
어떤 반대 근거가 있었는지,
어떤 리스크 관점이 최종 결정을 꺾었는지,
과거 실수로부터 무엇을 기억했는지를
구조화된 과정으로 남긴다는 데 있습니다.

이건 금융 외에도 그대로 확장할 수 있습니다. 예를 들어:

• 보안 경보 triage
• 투자 심사
• 의료 문헌 검토
• 정책 분석
• 코드 변경 위험 평가

즉 TradingAgents는 도메인이 금융일 뿐, 실제로는 “역할 분리 + 토론 + 판정 + 회고” 패턴의 참조 구현으로 읽는 것이 더 값집니다. 그 점에서 이 저장소가 큰 관심을 받는 이유도 이해됩니다. (GitHub)

---

마무리

TradingAgents는 “LLM으로 종목 추천하기” 수준의 프로젝트가 아닙니다.
이 프로젝트는 복잡한 의사결정을 하나의 모델에 몰아주지 않고, 역할 기반 멀티 에이전트 그래프로 분해해 협업하게 만드는 시스템입니다.

정리하면 이렇게 볼 수 있습니다.

• 무엇인가: 금융 트레이딩용 멀티 에이전트 의사결정 프레임워크
• 왜 나왔나: 단일 에이전트/단순 병렬 수집 방식의 한계를 넘기 위해
• 어떻게 동작하나: 애널리스트 → 찬반 토론 → 투자 플랜 → 리스크 토론 → 최종 판정
• 언제 쓰나: 멀티 에이전트 아키텍처 연구, 금융 AI 프로토타입, 고위험 의사결정 워크플로우 실험에 적합

개발자 입장에서 이 저장소의 진짜 매력은 성능 수치보다도,
멀티 에이전트 시스템을 어떻게 설계해야 하는지 코드로 보여준다는 데 있습니다.
그 점 하나만으로도 충분히 읽어볼 가치가 있는 프로젝트입니다. (GitHub