2026년 5월 6일 기준 TradingAgents는 TauricResearch의 Python 오픈소스 금융 트레이딩 LLM 에이전트 프레임워크다.
GitHub API 확인 기준으로 이 저장소는 약 69,249개 star와 13,343개 fork를 기록하고 있다.
README 기준 최신 릴리스 안내는 2026년 4월 v0.2.4이며, 핵심 변화는 structured output, LangGraph checkpoint resume, persistent decision log, Docker 지원, DeepSeek/Qwen/GLM/Azure provider 지원이다.
여기까지 보면 손이 근질근질해진다.
AI가 펀더멘털도 보고, 뉴스도 보고, 차트도 보고, 강세파와 약세파가 토론한 뒤 포트폴리오 매니저가 최종 판단한다니, 일단 설치부터 해보고 싶다.
그 마음은 이해된다.
나도 이런 프로젝트를 보면 터미널부터 열고 싶어진다.
하지만 TradingAgents는 설치 명령보다 먼저 정해야 할 것이 많다.
이걸 그냥 “AI가 주식 대신 골라주는 도구”로 보면 기대치가 이상한 방향으로 튄다.
잘못 붙이면 투자 보조 시스템이 아니라 비용 쓰는 분석 장난감이 된다.
그래서 이 글은 TradingAgents를 처음부터 끝까지 실행하는 튜토리얼이 아니다.
이미 이전 글에서 TradingAgents가 어떤 프로젝트인지와 누구에게 도움이 되는지는 정리했다.
이번 글은 그 후속편이다.
초점은 하나다.
설치 전에 무엇을 확인해야 하는가.
먼저 이 글의 위치부터 잡자
이 글은 TradingAgents 소개글이 아니다.
TradingAgents가 어떤 프로젝트인지, 왜 멀티 에이전트 구조가 흥미로운지, 개발자와 투자자에게 어떤 의미가 있는지는 이전 글에서 이미 다뤘다.
이 글은 그 다음 단계다.
프로젝트를 읽고 나서 “그럼 나도 한번 돌려볼까”라는 생각이 들 때 보는 점검표다.
그래서 여기서는 기술적 기대치를 조금 낮추고, 운영 관점의 질문을 앞으로 끌어온다.
예를 들면 이런 질문이다.
API 키는 몇 개가 필요한가.
한 번 실행하면 비용이 얼마나 튈 수 있는가.
어떤 데이터가 들어가고, 그 데이터는 실험 날짜 기준으로 안전한가.
에이전트가 낸 결론은 어디에 기록되는가.
중간에 실패하면 처음부터 다시 돌리는가.
그리고 제일 중요한 질문이 있다.
이 결과를 보고 실제 매수 버튼을 누를 사람은 누구인가.
TradingAgents는 연구 목적의 프레임워크라고 밝히고 있다.
README에는 trading performance가 모델, temperature, trading period, data quality, non-deterministic factors에 따라 달라진다고 적혀 있다.
또 투자 조언이 아니라고 명시한다.
이 문장을 대충 넘기면 안 된다.
금융 AI 프로젝트에서 면책 문구는 장식이 아니라 사용 범위를 정하는 울타리다.
빠른 판단표
먼저 빠르게 갈라보자.
TradingAgents를 지금 바로 설치해도 되는 사람과, 아직 문서만 읽는 편이 나은 사람이 있다.
| 상황 | 추천 행동 | 이유 |
|---|---|---|
| LLM 에이전트 구조를 공부하고 싶다 | 설치 전 README와 changelog를 먼저 읽는다 | 구조 학습 목적이면 실행보다 역할 흐름 이해가 먼저다 |
| 실거래 자동매매를 기대한다 | 보류한다 | 연구 프레임워크와 실거래 시스템은 다르다 |
| API 키와 비용 한도를 정해뒀다 | 작은 종목 1개로 샌드박스 실행을 검토한다 | 비용 폭주와 실험 범위를 통제할 수 있다 |
| Docker와 Python 환경이 익숙하다 | Docker 또는 가상환경 중 하나를 고른다 | 환경 꼬임을 줄일 수 있다 |
| 투자 리서치 기록 시스템이 없다 | 먼저 decision log 저장 위치를 정한다 | 결과를 남기지 않으면 실험이 회고로 이어지지 않는다 |
| 개인 투자 판단 루틴을 만들고 있다 | TradingAgents 구조를 체크리스트로 번역한다 | 실거래 연결보다 의사결정 분해가 먼저다 |
내 기준으로 TradingAgents는 “오늘 매수할 종목을 찾는 도구”보다 “투자 판단 조직도를 코드로 보여주는 샘플”에 가깝다.
그래서 첫 실행 목표도 수익률이 되면 안 된다.
첫 목표는 “이 프레임워크가 어떤 입력을 받아 어떤 중간 산출물을 만들고 어떤 결론을 남기는지 확인하기” 정도가 적당하다.
처음부터 수익률 검증으로 들어가면 금방 이상한 길로 빠진다.
백테스트 결과가 좋아 보이면 흥분하고, 안 좋아 보이면 모델 탓을 하게 된다.
그 전에 구조부터 봐야 한다.
체크 1. 내가 원하는 건 자동매매인가, 투자 리서치인가
TradingAgents를 보기 전에 목적을 먼저 나눠야 한다.
자동매매를 만들고 싶은 건지, 투자 리서치 도구를 만들고 싶은 건지, 에이전트 구조를 공부하고 싶은 건지에 따라 봐야 할 부분이 다르다.
이 셋을 섞으면 판단이 흐려진다.
자동매매는 실행 시스템이다.
주문 API, 체결 관리, 슬리피지, 포지션 관리, 장애 대응, 리스크 제한, 감사 로그가 필요하다.
투자 리서치는 의사결정 보조 시스템이다.
자료 수집, 분석, 반대 의견, 리스크 점검, 결론 기록이 중요하다.
에이전트 구조 학습은 개발 학습이다.
LangGraph 흐름, role decomposition, structured output, checkpoint, memory log 같은 설계를 보는 게 핵심이다.
TradingAgents는 이 세 영역 중 어디에 가장 가까울까.
내 기준으로는 투자 리서치와 에이전트 구조 학습 사이에 있다.
README에는 simulated exchange와 final decision 흐름이 나오지만, 이것을 바로 내 실계좌 주문 시스템에 붙이는 건 다른 문제다.
실사용 예시를 하나 들어보자.
내가 NVDA를 사고 싶은 마음이 이미 생겼다고 하자.
이때 TradingAgents를 “NVDA 매수해도 돼?”라고 답하게 하는 도구로 보면 위험하다.
대신 “NVDA에 대해 펀더멘털, 뉴스, 기술 분석, 강세 논리, 약세 논리, 리스크 플래그를 분리해서 보고서로 남기자”라고 쓰면 훨씬 현실적이다.
이 차이가 작아 보이지만, 실제 투자에서는 크다.
앞쪽은 결론 의존이고, 뒤쪽은 판단 과정 관리다.
체크 2. 실행 전에 비용 한도를 먼저 정했는가
멀티 에이전트 프레임워크는 비용이 조용히 늘어날 수 있다.
한 명의 모델에게 한 번 묻는 구조가 아니기 때문이다.
분석가가 여러 명이고, 리서처가 토론하고, 트레이더와 리스크 팀이 이어받으면 호출 횟수와 토큰 사용량이 늘어난다.
게다가 TradingAgents는 quick-thinking model과 deep-thinking model을 나누는 설정 예시를 보여준다.
빠른 데이터 처리에는 가벼운 모델을 쓰고, 깊은 판단에는 더 강한 모델을 쓰는 식이다.
이 구조는 합리적이지만, 비용 통제 없이는 위험하다.
먼저 정할 것은 세 가지다.
하루 실행 횟수.
종목 수.
한 번 실행당 허용 비용.
예를 들어 첫 실험은 이렇게 잡을 수 있다.
| 항목 | 첫 실험 기준 |
|---|---|
| 종목 수 | 1개 |
| 분석 날짜 | 하루 |
| 모델 provider | 1개만 선택 |
| debate rounds | 최소값 |
| 실행 방식 | 샌드박스 |
| 결과 사용 | 기록만 하고 매매 금지 |
여기서 중요한 건 “좋은 모델을 쓰지 말자”가 아니다.
처음부터 비용과 반복 횟수를 모르는 상태로 여러 종목을 돌리지 말자는 것이다.
AI 에이전트 실험은 첫날에 제일 신난다.
그 신남이 영수증으로 돌아오면 사람이 갑자기 차분해진다.
차분함은 좋지만, 청구서로 배우는 차분함은 좀 비싸다.
체크 3. API 키가 어디에 들어가는지 알고 있는가
README 기준 TradingAgents는 여러 LLM provider를 지원한다.
OpenAI, Google, Anthropic, xAI, DeepSeek, Qwen, GLM, OpenRouter, Ollama, Azure OpenAI 같은 선택지가 보인다.
또 Alpha Vantage API 키도 요구할 수 있다.
이 말은 단순히 “다양해서 좋다”로 끝나지 않는다.
API 키가 늘어나면 관리해야 할 비밀값도 늘어난다.
비밀값은 .env에 넣을 수 있다.
하지만 .env를 어디에 두는지, Git에 올라가지 않게 막았는지, 로그에 출력되지 않는지 확인해야 한다.
특히 투자 관련 실험에서는 API 키와 계좌 정보가 섞이면 위험하다.
TradingAgents 자체가 주문 API를 바로 다루지 않더라도, 사용자가 주변에 다른 자동매매 코드를 붙이기 시작하면 경계가 흐려질 수 있다.
첫 실행 전에는 아래를 확인하자.
| 확인 항목 | 봐야 할 것 |
|---|---|
.env 위치 |
프로젝트 루트에 두되 Git 추적 제외 |
| provider 키 | 하나의 LLM provider부터 시작 |
| 데이터 키 | Alpha Vantage 등 데이터 provider 필요 여부 확인 |
| 로그 | API 키 일부라도 출력되지 않는지 확인 |
| 권한 | 읽기용 키와 주문용 키를 절대 섞지 않기 |
실사용 예시는 이렇다.
처음에는 OpenAI와 Alpha Vantage만 설정하고, 다른 provider 키는 넣지 않는다.
동시에 .env.example을 복사해 .env를 만들되, 실제 값이 Git 상태에 뜨지 않는지 확인한다.
그리고 첫 실행 로그를 보고 키가 노출되지 않는지 확인한다.
이 단계는 재미없다.
하지만 재미없는 단계가 사고를 줄인다.
자동화에서 보안은 대체로 재미없고, 사고는 대체로 매우 생생하다.
체크 4. Docker로 갈지, 로컬 Python으로 갈지 정했는가
README는 두 가지 길을 보여준다.
하나는 Python 가상환경을 만들고 pip install .로 설치하는 방식이다.
다른 하나는 Docker를 사용하는 방식이다.
둘 다 가능하지만, 처음 실험에서는 환경을 하나만 고르는 게 좋다.
로컬 Python은 코드 읽고 수정하기 좋다.
환경이 익숙하면 빠르게 디버깅할 수 있고, 패키지 구조도 바로 볼 수 있다.
반면 Python 버전과 의존성 충돌이 귀찮을 수 있다.
README 예시는 python=3.13 가상환경을 만든다.
Docker는 환경 재현성이 좋다.
특히 v0.2.4 changelog에는 Docker 지원과 Docker permission issue 개선이 들어가 있다.
다만 Docker가 익숙하지 않으면 볼륨, 권한, .env 전달, 로그 위치에서 막힐 수 있다.
처음 선택 기준은 단순하게 가면 된다.
| 나는 이런 사람이다 | 추천 |
|---|---|
| Python 패키지 구조를 뜯어보고 싶다 | 로컬 가상환경 |
| 내 컴퓨터 Python 환경을 건드리기 싫다 | Docker |
| 팀원과 같은 환경을 맞춰야 한다 | Docker |
| 코드 수정과 실험을 자주 할 것이다 | 로컬 가상환경 |
| Ollama 로컬 모델도 같이 보고 싶다 | Docker profile 또는 별도 로컬 설정 |
예를 들어 “그냥 한번 돌려보고 싶다”면 Docker가 마음 편할 수 있다.
하지만 “LangGraph 노드가 어떻게 이어지는지 보겠다”면 로컬 가상환경이 낫다.
중요한 건 둘을 동시에 꼬지 않는 것이다.
처음부터 Docker도 만지고, 로컬 venv도 만들고, 글로벌 Python에도 설치하면 나중에 에러가 났을 때 원인을 찾기 어렵다.
에러 메시지는 하나인데 범인은 셋이다.
이런 추리물은 개발자 건강에 좋지 않다.
체크 5. 데이터 기준일을 통제할 수 있는가
AI 트레이딩 실험에서 아주 중요한 문제가 있다.
룩어헤드 바이어스다.
쉽게 말하면 과거 날짜를 분석한다고 해놓고, 실제로는 미래 정보를 슬쩍 섞는 문제다.
이건 백테스트를 예쁘게 만드는 데 아주 강력하다.
그리고 아주 위험하다.
TradingAgents changelog를 보면 v0.2.3에서 backtesting fetchers가 curr_date 중간 윈도우에서 look-ahead data를 새지 않게 고쳤다는 내용이 있다.
이런 변경이 있었다는 건 반대로 말하면, 금융 AI 프레임워크에서 날짜 처리와 데이터 창 관리가 핵심이라는 뜻이다.
실행 전에 확인할 질문은 이렇다.
분석 날짜를 내가 명확히 지정했는가.
그 날짜 이후의 뉴스나 가격 정보가 들어가지 않는가.
데이터 provider가 과거 시점 데이터를 어떻게 제공하는가.
LLM이 현재 지식을 섞어 과거 판단을 설명하지 않는가.
실사용 예시를 보자.
2026년 1월 15일의 NVDA 판단을 실험한다고 하자.
그러면 2026년 1월 16일 이후의 뉴스, 실적, 주가 흐름, 시장 반응이 분석에 들어가면 안 된다.
그런데 LLM은 본질적으로 현재 지식을 갖고 있을 수 있다.
그래서 프롬프트와 데이터 입력에서 “분석 기준일 이후 정보는 사용하지 않는다”는 제한을 명확히 해야 한다.
이 제한이 없으면 백테스트는 똑똑해 보이지만 실제로는 미래를 훔쳐본 셈이 된다.
미래를 훔쳐본 전략은 과거 차트에서는 멋지고, 현실 계좌에서는 갑자기 평범해진다.
체크 6. 에이전트 역할을 그대로 믿지 말고 출력 계약을 보자
TradingAgents의 매력은 역할 분리다.
펀더멘털 분석가, 감성 분석가, 뉴스 분석가, 기술 분석가가 있고, 강세와 약세 리서처가 토론한다.
그 뒤에 트레이더, 리스크 관리, 포트폴리오 매니저가 이어진다.
이 구조는 듣기 좋다.
하지만 이름만 멋진 역할은 별 의미가 없다.
중요한 것은 각 역할이 어떤 입력을 받고 어떤 출력을 남기는가다.
예를 들어 기술 분석가가 “RSI가 과매수입니다”라고만 쓰면 부족하다.
분석 기준 기간, 지표 값, 해석, 무효화 조건이 같이 있어야 한다.
뉴스 분석가도 마찬가지다.
“최근 뉴스가 긍정적입니다”가 아니라, 어떤 뉴스가 어떤 날짜에 나왔고 어떤 가정으로 긍정 판단했는지 남겨야 한다.
역할보다 출력 계약이 중요하다.
첫 실행 후에는 보고서를 이렇게 뜯어보자.
| 역할 | 확인 질문 |
|---|---|
| Fundamentals Analyst | 숫자와 출처가 있는가 |
| Sentiment Analyst | 감성 판단 근거가 분리되어 있는가 |
| News Analyst | 날짜와 이벤트가 명확한가 |
| Technical Analyst | 지표 값과 기간이 있는가 |
| Bull Researcher | 상승 논리와 전제가 분리되어 있는가 |
| Bear Researcher | 반대 논리가 실제로 날카로운가 |
| Trader | 결론이 앞 단계 근거와 연결되는가 |
| Risk Team | 포지션 크기와 손실 조건을 따지는가 |
| Portfolio Manager | 최종 승인/보류 이유가 기록되는가 |
실사용 예시는 간단하다.
처음 실행 결과를 보고 “Buy”인지 “Hold”인지만 보지 않는다.
각 역할의 출력이 다음 역할로 넘어가면서 정보가 보존되는지 확인한다.
중간 분석에는 리스크가 있는데 최종 결론에서 사라진다면 문제다.
반대로 최종 결론이 지나치게 보수적이라 모든 종목이 Hold로 끝난다면 그것도 문제다.
에이전트가 많다고 자동으로 균형이 생기지는 않는다.
역할이 많아도 같은 편견을 공유하면, 여러 명이 같은 방향으로 틀릴 수 있다.
체크 7. 리스크 게이트를 마지막 장식으로 두지 말자
AI 투자 도구에서 리스크 섹션은 자주 장식이 된다.
본문 끝에 “투자는 본인 책임입니다”를 붙이고 끝나는 식이다.
그건 리스크 관리가 아니다.
그건 면책 문구다.
TradingAgents 구조에서 리스크 팀과 포트폴리오 매니저가 뒤에 있는 이유는 최종 판단을 걸러내기 위해서다.
그러면 사용자의 실험에서도 리스크 게이트는 실제로 결정을 바꿀 수 있어야 한다.
리스크 게이트가 해야 할 일은 적어도 네 가지다.
포지션 크기 제한.
손실 시나리오.
무효화 조건.
매매 보류 조건.
예를 들어 NVDA 분석 결과가 강하게 긍정적이라고 하자.
그럼 리스크 게이트는 “좋다”를 반복하는 곳이 아니다.
이미 포트폴리오에서 NVDA 비중이 높은가.
실적 발표 전후 변동성이 큰가.
시장 전체가 위험 회피 구간인가.
손절 기준 없이 들어가는가.
이런 질문으로 결론을 바꿀 수 있어야 한다.
내가 개인 투자자에게 추천하는 방식은 proposal -> gate -> record -> review다.
먼저 AI가 제안을 만든다.
그 다음 리스크 게이트가 통과/보류/거절을 정한다.
그 결정을 기록한다.
나중에 결과를 리뷰한다.
이 순서가 없으면 AI 분석은 좋아 보이는 문장으로 끝난다.
문장이 좋아도 계좌는 별개다.
계좌는 문장 감상평을 써주지 않는다.
체크 8. persistent decision log를 어디에 둘 것인가
v0.2.4에서 눈에 띄는 기능 중 하나는 persistent decision log다.
README 기준 completed run의 decision이 ~/.tradingagents/memory/trading_memory.md에 append된다.
다음 같은 ticker 실행에서 실현 수익률과 SPY 대비 alpha를 해결하고, reflection을 만들어 Portfolio Manager prompt에 넣는 흐름도 설명되어 있다.
이 기능은 꽤 중요하다.
AI 투자 실험에서 제일 흔한 실패는 매번 새로 똑똑한 척하는 것이다.
지난번 판단이 맞았는지 틀렸는지 기억하지 않고, 매번 그럴듯한 새 분석을 만든다.
그러면 시스템은 발전하지 않는다.
decision log는 이 문제를 줄이는 장치다.
다만 로그가 있다는 것과 로그를 제대로 운영한다는 것은 다르다.
실행 전에 정할 것이 있다.
로그 위치.
로그 백업 방식.
개인정보나 민감한 투자 정보 포함 여부.
리뷰 주기.
실거래와 연결하지 않는다면, 로그는 더더욱 중요하다.
왜냐하면 실험의 목적이 “당장 매매”가 아니라 “판단 구조 개선”이기 때문이다.
예를 들어 매주 금요일에 같은 종목 3개를 대상으로 decision log를 리뷰한다고 하자.
그때 봐야 할 것은 수익률만이 아니다.
강세 논리가 반복적으로 과장됐는가.
약세 논리가 매번 너무 보수적이었는가.
리스크 게이트가 실제로 손실 가능성을 줄였는가.
포트폴리오 매니저가 이전 실수를 반영했는가.
이런 질문이 들어가야 decision log가 살아난다.
기록만 쌓이고 리뷰가 없으면 그냥 예쁜 무덤이다.
체크 9. checkpoint resume은 편의 기능이 아니라 운영 기능이다
멀티 에이전트 실행은 길다.
중간에 네트워크가 끊길 수 있고, provider가 rate limit을 줄 수 있고, 로컬 환경이 멈출 수도 있다.
이때 처음부터 다시 돌리면 비용과 시간이 다시 든다.
TradingAgents v0.2.4는 LangGraph checkpoint resume을 opt-in으로 제공한다고 설명한다.
--checkpoint를 켜면 각 node 이후 상태를 저장하고, 중단된 실행을 마지막 성공 지점부터 이어갈 수 있다.
per-ticker SQLite database는 ~/.tradingagents/cache/checkpoints/<TICKER>.db 아래에 저장된다고 README에 적혀 있다.
이 기능은 단순 편의가 아니다.
운영 기능이다.
특히 금융 분석은 실행 도중 중단되면 중간 산출물이 사라지는 문제가 크다.
펀더멘털 분석까지 끝났는데 뉴스 분석에서 실패했다면, 처음부터 다시 하는 건 낭비다.
처음 실험할 때는 checkpoint를 켠 실행과 끈 실행을 둘 다 이해해야 한다.
checkpoint를 켜면 복구가 쉬워지지만, 캐시와 상태 파일을 관리해야 한다.
--clear-checkpoints로 초기화하는 흐름도 알아둬야 한다.
실사용 예시는 이렇다.
첫날에는 checkpoint 없이 아주 작은 실행을 한 번 한다.
둘째 실행에서 checkpoint를 켜고, 일부러 중간 실패 상황을 상상해본다.
그리고 체크포인트 파일이 어디에 생기는지 확인한다.
이 과정을 해두면 나중에 긴 분석이 멈췄을 때 덜 당황한다.
실험 중단은 언제나 당황스럽다.
하지만 “어디서 이어지는지 알고 있음”과 “기도부터 함”은 아주 다르다.
체크 10. structured output을 왜 봐야 하는가
v0.2.4 changelog에는 Research Manager, Trader, Portfolio Manager가 structured-output decision agents로 바뀌었다는 내용이 있다.
OpenAI와 xAI는 json_schema, Gemini는 response_schema, Anthropic은 tool-use, OpenAI-compatible provider는 function-calling 방식을 쓴다고 설명한다.
이건 블로그 독자에게 조금 딱딱해 보일 수 있다.
하지만 중요한 변화다.
금융 AI에서 자유로운 문장 출력은 읽기 좋지만 검증하기 어렵다.
반대로 구조화된 출력은 저장, 비교, 리뷰, 자동화에 유리하다.
예를 들어 최종 판단이 markdown 문장으로만 남으면 나중에 “Buy였나 Hold였나”를 파싱해야 한다.
하지만 rating, rationale, risk flags, confidence 같은 필드가 구조화되어 있으면 훨씬 다루기 쉽다.
TradingAgents가 5-tier rating scale을 쓰는 것도 같은 맥락이다.
Buy / Overweight / Hold / Underweight / Sell 같은 등급이 일관되면, 나중에 판단 변화를 추적할 수 있다.
실사용 예시는 이렇게 볼 수 있다.
첫 실행 결과에서 최종 결론을 복사해 엑셀이나 노션에 붙이는 것보다, 어떤 필드가 구조화되어 있는지 먼저 확인한다.
내 시스템에 붙일 때도 자유 문장 전체를 저장하기보다 핵심 필드를 따로 보관한다.
예를 들면 ticker, date, rating, confidence, key_risks, invalidation_condition, next_review_date 같은 필드다.
이렇게 해야 나중에 비교가 된다.
비교가 안 되는 기록은 대체로 감상문으로 끝난다.
감상문도 좋지만, 투자 시스템은 감상문만 먹고 자라지 않는다.
체크 11. 로컬 모델을 쓸 때 기대치를 낮춰야 한다
README는 Ollama local model 설정도 언급한다.
로컬 모델을 쓰면 비용과 개인정보 측면에서 장점이 있다.
하지만 금융 리서치 품질까지 자동으로 좋아지는 것은 아니다.
로컬 모델은 환경에 따라 속도, 컨텍스트, 추론 품질이 크게 갈린다.
또 뉴스, 가격 데이터, 재무 정보는 어차피 외부 데이터 provider가 필요할 수 있다.
로컬 모델만으로 모든 것이 닫힌 환경에서 해결된다고 생각하면 안 된다.
특히 TradingAgents처럼 역할이 여러 개인 구조에서는 모델 품질 차이가 누적될 수 있다.
한 에이전트의 부정확한 분석이 다음 단계 토론으로 넘어가고, 그 토론이 최종 판단으로 이어질 수 있다.
비용을 아끼려고 낮은 품질 모델만 쓰다가, 결과 해석에 더 많은 시간을 쓰게 될 수도 있다.
처음에는 하이브리드로 생각하는 편이 현실적이다.
가벼운 요약과 형식 변환은 로컬 또는 저렴한 모델.
핵심 판단과 리스크 검토는 더 강한 모델.
이렇게 역할별 모델 품질을 나누는 게 낫다.
실사용 예시는 이렇다.
처음에는 로컬 모델로 전체 파이프라인이 실행되는지만 본다.
그 다음 같은 ticker와 같은 날짜를 강한 모델로 한 번 더 실행한다.
두 결과의 차이를 비교한다.
강세/약세 논리의 깊이, 리스크 플래그의 구체성, 최종 판단의 보수성, 근거 출처 사용 방식을 본다.
이 비교 없이 “로컬도 되네”로 끝내면 위험하다.
되는 것과 믿을 만한 것은 다르다.
체크 12. 첫 실행 종목은 재미보다 검증이 쉬운 종목으로 고르자
첫 실행 종목을 고를 때는 사람들이 보통 제일 궁금한 종목을 넣고 싶어 한다.
요즘 관심 있는 성장주, 급등한 테마주, 변동성 큰 코인을 넣고 싶어진다.
그런데 첫 실험에는 검증하기 쉬운 종목이 낫다.
대형주가 좋다.
뉴스가 많고, 재무 데이터가 비교적 잘 정리되어 있으며, 가격 데이터도 안정적으로 구할 수 있기 때문이다.
README 예시에는 NVDA가 나온다.
NVDA 같은 대형주는 첫 실험에 적당하다.
뉴스와 재무 정보가 풍부해서 에이전트 출력이 얼마나 근거를 잘 다루는지 확인하기 쉽다.
반대로 유동성이 낮은 종목이나 밈주식은 첫 실험에 부적합하다.
데이터 노이즈가 크고, 감성 분석이 과장되기 쉽고, 모델이 서사를 과하게 붙일 수 있다.
코인은 더 조심해야 한다.
24시간 거래, 펀딩비, 청산 구간, 거래소별 유동성, 온체인 데이터가 섞인다.
TradingAgents 구조를 그대로 코인 시장에 가져오면 빠지는 정보가 많다.
실사용 예시는 이렇게 잡자.
첫 종목은 NVDA 또는 AAPL 같은 대형주 1개.
분석 날짜는 최근이 아니라 이미 결과를 확인할 수 있는 과거 날짜 1개.
실행 후에는 실제 매매하지 않고, 그 날짜 이후의 결과와 decision log 구조만 비교한다.
이 정도가 첫 실험으로 알맞다.
처음부터 알트코인 10개를 돌리는 건 너무 매운맛이다.
매운맛은 좋지만, 실험 설계까지 매워질 필요는 없다.
체크 13. 결과를 볼 때 최종 rating만 보면 안 된다
TradingAgents 실행 결과에서 가장 눈에 띄는 것은 최종 판단일 것이다.
Buy, Hold, Sell 또는 5-tier rating 같은 결론이다.
하지만 이 결론만 보면 TradingAgents의 핵심을 놓친다.
멀티 에이전트 구조의 가치는 중간 판단의 차이에 있다.
펀더멘털 분석은 긍정인데 기술 분석은 조심스러운가.
뉴스 분석은 긍정인데 약세 리서처가 거시 리스크를 잘 잡아냈는가.
트레이더는 공격적인데 리스크 팀이 포지션 크기를 줄였는가.
포트폴리오 매니저가 이전 decision log를 반영했는가.
이런 질문이 중요하다.
최종 rating만 보면 단일 AI 추천과 다르지 않다.
그러면 굳이 멀티 에이전트를 쓸 이유가 줄어든다.
첫 결과를 리뷰할 때는 아래 표처럼 나눠보자.
| 리뷰 영역 | 좋은 신호 | 나쁜 신호 |
|---|---|---|
| 근거 | 날짜, 수치, 출처가 있다 | 일반론만 반복한다 |
| 토론 | 강세와 약세 논리가 실제로 다르다 | 둘 다 비슷한 말을 한다 |
| 리스크 | 포지션 크기와 실패 조건이 있다 | “조심해야 한다”로 끝난다 |
| 최종 판단 | 앞 단계 근거와 연결된다 | 갑자기 결론이 튄다 |
| 기록 | 다음 리뷰에 쓸 정보가 남는다 | 문장만 길고 필드가 없다 |
실사용 예시는 이렇다.
실행 결과를 읽고 최종 rating 옆에 “왜?”를 세 번 적는다.
왜 이 결론인가.
왜 이 리스크가 핵심인가.
왜 지금 실행해야 하거나 보류해야 하는가.
세 질문에 답이 안 나오면 결과를 실전 판단에 쓰면 안 된다.
AI가 길게 썼다고 깊게 생각한 것은 아니다.
길이는 착시를 만든다.
투자에서는 그 착시가 꽤 비싸다.
체크 14. 내 Wealth OS나 트레이딩 코치에 붙일 때는 역할만 가져오자
TradingAgents를 내 시스템에 붙이고 싶다면, 처음부터 코드를 통째로 이식할 필요는 없다.
오히려 먼저 가져올 것은 역할 구조다.
분석가, 반대 의견, 리스크 검토, 최종 승인, 기록.
이 다섯 개만 가져와도 개인 투자 루틴은 꽤 좋아질 수 있다.
예를 들어 내 투자 리서치 메모를 이렇게 나눌 수 있다.
| 단계 | 역할 | 출력 |
|---|---|---|
| 1 | 데이터 수집 | 가격, 뉴스, 실적, 매크로 요약 |
| 2 | 강세 논리 | 매수/비중 확대 근거 |
| 3 | 약세 논리 | 보류/축소 근거 |
| 4 | 리스크 게이트 | 손실 조건, 포지션 제한 |
| 5 | 사람 승인 | 실행/보류/거절 |
| 6 | 기록 | 결정 이유와 리뷰 날짜 |
이 구조는 자동매매보다 먼저다.
실제로 자동매매까지 가려면 주문 시스템, 장애 대응, 체결 로그, 세금 처리, 거래소 리스크까지 훨씬 많은 층이 필요하다.
하지만 투자 리서치 루틴으로는 위 구조만으로도 충분히 가치가 있다.
실사용 예시는 내 매매 전 메모다.
BTC나 NVDA를 보고 싶다면, 먼저 강세 논리와 약세 논리를 분리한다.
그 다음 리스크 게이트에서 “오늘 매매 적합도”와 “포지션 크기 제한”을 적는다.
마지막으로 사람이 승인한다.
이때 AI는 결정을 대신하지 않는다.
AI는 결정을 보이게 만든다.
TradingAgents에서 진짜 가져올 문장은 이쪽에 가깝다.
AI가 대신 투자한다.
이 문장보다 낫다.
AI가 투자 판단 과정을 분해해서 보여준다.
체크 15. 실거래 연결은 가장 마지막이다
이 부분은 일부러 세게 말해야 한다.
TradingAgents를 보고 바로 실계좌 주문 API에 붙이는 건 추천하지 않는다.
이유는 단순하다.
분석 시스템과 실행 시스템은 다르다.
분석 시스템은 틀릴 수 있다.
실행 시스템도 틀릴 수 있다.
둘을 붙이면 틀릴 수 있는 것끼리 결혼한다.
결혼식은 아름다울 수 있지만, 계좌는 축의금을 내주지 않는다.
실거래 연결 전에 필요한 최소 조건은 아래와 같다.
| 조건 | 설명 |
|---|---|
| 샌드박스 실행 | 실계좌와 분리된 환경에서 충분히 테스트 |
| 주문 권한 분리 | 읽기용 키와 주문용 키 분리 |
| 포지션 한도 | 종목별, 계좌별 최대 손실 제한 |
| kill switch | 자동 실행 중지 장치 |
| 감사 로그 | 누가, 언제, 왜 실행했는지 기록 |
| 사후 리뷰 | 결과와 판단 품질 정기 점검 |
이 조건이 없으면 자동매매가 아니라 자동불안이다.
TradingAgents는 연구 프레임워크다.
연구 프레임워크에서 배운 구조를 내 시스템에 옮기는 것은 좋다.
하지만 연구 프레임워크를 곧바로 돈이 걸린 실행층으로 올리는 것은 다른 문제다.
처음에는 paper trading 또는 기록용 리서치로 충분하다.
실계좌는 마지막에 와야 한다.
투자 자동화에서 가장 비싼 실수는 “일단 붙여보고 생각하자”다.
생각은 보통 체결 이후에 온다.
그때는 이미 시장이 내 생각을 대신 정리해준다.
실제 실행 전 10분 점검표
실제로 터미널을 열기 전에 아래를 한번 보자.
이 표를 통과하지 못하면 설치보다 설계가 먼저다.
| 번호 | 질문 | 통과 기준 |
|---|---|---|
| 1 | 목적이 명확한가 | 구조 학습, 리서치, 백테스트 중 하나로 정의 |
| 2 | 실거래와 분리했는가 | 주문 API 연결 없음 |
| 3 | 비용 한도가 있는가 | 종목 수와 실행 횟수 제한 |
| 4 | API 키가 안전한가 | .env Git 제외 확인 |
| 5 | 데이터 기준일이 있는가 | 분석 날짜와 데이터 범위 지정 |
| 6 | provider를 하나로 시작하는가 | 첫 실행 provider 1개 |
| 7 | checkpoint 사용 여부를 정했는가 | 끄거나 켜는 이유가 있음 |
| 8 | decision log 위치를 아는가 | 저장 경로와 리뷰 방식 확인 |
| 9 | 최종 판단 사용 범위를 정했는가 | 매매 금지 또는 paper trading |
| 10 | 리뷰 질문이 있는가 | rating보다 근거와 리스크를 봄 |
이 표가 귀찮아 보이면 정상이다.
좋은 체크리스트는 대체로 귀찮다.
대신 귀찮은 체크리스트는 나중에 더 큰 귀찮음을 줄여준다.
자동화에서 진짜 무서운 건 실패가 아니다.
어디서 실패했는지 모르는 실패다.
첫 실행은 이렇게 작게 시작하자
첫 실행 플랜을 아주 작게 잡아보자.
목표는 수익률 검증이 아니다.
목표는 파이프라인 이해다.
예시는 아래 정도면 충분하다.
git clone <https://github.com/TauricResearch/TradingAgents.git>
cd TradingAgents
cp .env.example .env
여기서 바로 실행하지 말고 .env.example을 먼저 읽는다.
필요한 provider 키를 확인한다.
하나의 LLM provider만 고른다.
데이터 provider 키가 필요한지 확인한다.
그 다음 설치 방식 하나를 고른다.
로컬 Python을 고르면 가상환경을 만든다.
Docker를 고르면 Docker compose 흐름을 본다.
둘을 동시에 시작하지 않는다.
첫 분석은 종목 1개, 날짜 1개로 제한한다.
README 예시처럼 NVDA 같은 대형주가 무난하다.
실행 결과는 매매에 쓰지 않는다.
대신 아래 네 가지를 확인한다.
분석가별 출력이 남는가.
강세와 약세 토론이 실제로 다른가.
리스크 검토가 최종 판단을 바꿀 수 있는가.
decision log가 다음 실행에 쓸 수 있게 저장되는가.
이 네 가지를 확인하면 첫 실행은 성공이다.
수익률은 그 다음이다.
첫날부터 수익률을 붙잡으면 구조를 못 본다.
구조를 못 보면 AI가 운 좋게 맞춘 것과 시스템이 잘 설계된 것을 구분하지 못한다.
기존 TradingAgents 글과 어떻게 이어 붙일까
이 글은 기존 글의 후속편으로 내부 링크를 걸기 좋다.
기존 글은 “TradingAgents는 누구에게 도움이 되는가”를 다뤘다.
이번 글은 “설치 전에 무엇을 확인해야 하는가”를 다룬다.
두 글의 역할이 다르다.
기존 글은 개념 허브다.
이번 글은 실행 전 점검표다.
내부 링크는 양방향으로 넣는 게 좋다.
기존 글 하단에는 “직접 실행 전 체크리스트” 링크를 넣는다.
이번 글 초반에는 “프로젝트 자체가 궁금하면 기존 분석 글을 먼저 보라”는 흐름을 넣는다.
이렇게 하면 검색 의도도 분리된다.
TradingAgents 분석을 찾는 사람은 기존 글로 들어온다.
TradingAgents 사용법이나 TradingAgents 설치 전 체크리스트를 찾는 사람은 이번 글로 들어온다.
같은 키워드를 놓고 내 글끼리 싸우는 것을 줄일 수 있다.
블로그에서 자기 글끼리 싸우면 좀 억울하다.
내가 쓴 글인데 서로 트래픽을 뺏는다.
가족회의가 필요해진다.
내가 가져갈 핵심은 세 가지다
TradingAgents에서 바로 가져갈 것은 세 가지다.
첫째, 역할 분리다.
한 명의 AI에게 모든 판단을 맡기지 않고, 분석과 반대 의견과 리스크 검토를 나눈다.
둘째, 결정 기록이다.
결론만 남기지 않고, 왜 그런 판단을 했는지와 나중에 어떻게 평가할지를 남긴다.
셋째, 복구 가능한 실행이다.
checkpoint와 log를 통해 긴 에이전트 실행이 중간에 멈춰도 이어갈 수 있게 한다.
이 세 가지는 금융에만 쓸 수 있는 패턴이 아니다.
코드 리뷰, 제품 기획, 리서치 자동화, 콘텐츠 제작에도 그대로 응용할 수 있다.
중요한 건 TradingAgents를 우상화하지 않는 것이다.
좋은 오픈소스 프로젝트는 그대로 베끼는 대상이 아니라, 내 시스템의 설계 질문을 더 선명하게 만드는 재료다.
TradingAgents도 그렇다.
이 프로젝트를 보고 “AI가 대신 투자하겠네”로 끝내면 아깝다.
“내 투자 판단을 어떤 역할과 기록으로 나눠야 하지”까지 가야 한다.
그 질문이 진짜 쓸모다.
설치 전에 자주 하는 실수 7가지
TradingAgents 같은 프로젝트를 볼 때 반복되는 실수가 있다.
대부분 기술 문제가 아니라 기대치 문제다.
첫 번째 실수는 star 숫자를 성과 검증으로 착각하는 것이다.
GitHub star는 관심도다.
관심도가 높다는 건 볼 가치가 있다는 뜻이지, 투자 성과가 검증됐다는 뜻은 아니다.
두 번째 실수는 “멀티 에이전트니까 더 안전하겠지”라고 생각하는 것이다.
에이전트가 많아도 같은 데이터와 같은 편향을 공유하면 같이 틀릴 수 있다.
안전성은 에이전트 숫자가 아니라 반대 의견, 리스크 게이트, 기록, 리뷰에서 나온다.
세 번째 실수는 실행 비용을 나중에 보는 것이다.
멀티 에이전트는 호출 수가 많아질 수 있다.
처음부터 종목 수와 실행 횟수를 제한하지 않으면 실험이 비용 실험으로 바뀐다.
네 번째 실수는 분석 날짜를 대충 잡는 것이다.
백테스트나 과거 분석에서 날짜가 흐리면 미래 정보가 섞일 수 있다.
룩어헤드 바이어스는 결과를 예쁘게 만들지만, 현실 성과를 설명해주지는 않는다.
다섯 번째 실수는 최종 rating만 보는 것이다.
TradingAgents의 가치는 Buy나 Hold 하나에 있지 않다.
중간 분석, 찬반 토론, 리스크 검토, 최종 승인 흐름을 봐야 한다.
여섯 번째 실수는 .env와 API 키 관리를 가볍게 보는 것이다.
읽기용 키, LLM provider 키, 데이터 provider 키가 섞이기 시작하면 관리 난도가 올라간다.
실거래 키는 초반 실험 환경에 넣지 않는 편이 낫다.
일곱 번째 실수는 첫날부터 실계좌 연결을 상상하는 것이다.
TradingAgents는 연구 프레임워크다.
실거래 실행 시스템은 별도의 안전장치와 운영 기준이 필요하다.
이 7가지만 피해도 첫 실험의 질이 꽤 달라진다.
처음에는 작게 돌리고, 많이 기록하고, 늦게 연결하는 편이 좋다.
AI 자동화에서 빠른 출발보다 중요한 건 멈출 수 있는 구조다.
FAQ
TradingAgents는 자동매매 프로그램인가
TradingAgents는 LLM 기반 금융 트레이딩 의사결정을 실험하는 멀티 에이전트 프레임워크에 가깝다.
README에서도 연구 목적이며 투자, 금융, 트레이딩 조언이 아니라고 밝힌다.
실거래 자동매매 시스템으로 보려면 주문 실행, 장애 대응, 포지션 제한, 감사 로그 같은 층을 별도로 설계해야 한다.
처음에는 실거래가 아니라 paper trading 또는 리서치 기록용으로 보는 편이 안전하다.
TradingAgents 사용법에서 제일 먼저 볼 것은 무엇인가
설치 명령보다 목적과 비용 한도를 먼저 봐야 한다.
내가 구조 학습을 하려는지, 투자 리서치 흐름을 만들려는지, 백테스트를 해보려는지 정해야 한다.
그 다음 API 키, 데이터 기준일, checkpoint, decision log를 확인한다.
설치는 그 다음이다.
터미널은 빠르지만, 목적 없이 빠르면 더 빨리 헤맨다.
GitHub star가 많으면 믿을 만한가
star는 관심도를 보여주지만 성과를 보장하지 않는다.
2026년 5월 6일 확인 기준 TradingAgents는 약 6.9만 star를 기록하고 있다.
이 숫자는 프로젝트가 많은 관심을 받고 있다는 신호다.
하지만 투자 성과, 데이터 품질, 운영 안정성은 별도 검증이 필요하다.
star는 입구다.
검증은 다른 방이다.
로컬 모델만으로 TradingAgents를 돌리는 것이 좋을까
로컬 모델은 비용과 개인정보 측면에서 장점이 있다.
하지만 금융 판단 품질이 자동으로 보장되지는 않는다.
특히 멀티 에이전트 구조에서는 한 단계의 약한 판단이 다음 단계로 전파될 수 있다.
처음에는 로컬 모델과 강한 provider 모델을 같은 ticker와 같은 날짜로 비교해보는 편이 좋다.
비교 없이 “돌아간다”만 확인하면 부족하다.
개인 투자자가 바로 써도 될까
개인 투자자는 실거래 도구보다 리서치 체크리스트로 쓰는 편이 낫다.
강세 논리, 약세 논리, 리스크 조건, 최종 승인, 사후 리뷰를 분리하는 구조만 가져와도 충분히 쓸모 있다.
AI에게 최종 판단을 맡기기보다, AI가 판단 과정을 보이게 만드는 데 쓰는 것이 현실적이다.
매수 버튼은 마지막까지 사람 손에 남겨두는 편이 좋다.
이전 TradingAgents 분석 글과 이 글은 무엇이 다른가
이전 글은 TradingAgents가 어떤 프로젝트이고 누구에게 도움이 되는지 설명했다.
이번 글은 설치하거나 실행하기 전에 점검할 항목을 다룬다.
그래서 기존 글은 개념 분석이고, 이번 글은 실행 전 체크리스트다.
두 글은 경쟁하는 글이 아니라 이어지는 글이다.
검색 의도도 다르다.
TradingAgents 분석은 기존 글.
TradingAgents 사용법이나 설치 전 체크리스트는 이번 글이 받는 구조가 좋다.
마무리
TradingAgents는 흥미로운 프로젝트다.
LLM 에이전트를 펀더멘털, 감성, 뉴스, 기술 분석, 강세/약세 토론, 리스크 관리, 포트폴리오 매니저로 나누는 구조는 분명 배울 만하다.
하지만 흥미롭다는 것과 바로 실계좌에 붙여도 된다는 것은 완전히 다르다.
설치 전에 목적, 비용, API 키, 데이터 기준일, 출력 계약, 리스크 게이트, decision log, checkpoint를 먼저 확인해야 한다.
이 과정을 통과하면 TradingAgents는 꽤 좋은 학습 재료가 된다.
통과하지 못하면 그냥 멋진 README를 가진 위험한 장난감이 될 수 있다.
내가 추천하는 첫 사용법은 단순하다.
종목 1개.
날짜 1개.
provider 1개.
매매 금지.
결과 기록.
그리고 리뷰.
이 정도로 작게 시작하면 TradingAgents의 진짜 가치를 볼 수 있다.
AI가 대신 투자해주는지보다 더 중요한 질문이 있다.
내 투자 판단 과정을 얼마나 잘게 나누고, 얼마나 잘 기록하고, 얼마나 냉정하게 다시 볼 수 있는가.
TradingAgents는 그 질문을 던지게 만드는 좋은 재료다.
그 질문까지 갔다면 이미 절반은 건진 셈이다.
관련 글
참고 자료
- TauricResearch/TradingAgents GitHub
- TradingAgents arXiv paper
- TradingAgents project page
- TradingAgents changelog
- 이전 글:
02.Areas/blog/ai_llm/260428 TradingAgents 분석 2026 - LLM 에이전트 금융 트레이딩 프레임워크는 누구에게 도움 될까.md - 로컬 요약 노트:
00.Inbox/260506_[요약] TradingAgents AI 트레이딩 데스크.md