TradingAgents 리뷰 — 멀티에이전트 LLM이 트레이딩 팀을 흉내 낼 때 얻는 것과 잃는 것
저희 블로그 파이프라인에서 한 초안이 중복 검사에 다섯 번 걸렸습니다. 원인은 코드블록 들여쓰기 겹침이었는데, 사람이 4-gram을 직접 계산해서야 특정됐어요. TradingAgents는 트레이딩 판단을 8개 역할로 쪼개 LangGraph로 엮은 프레임워크인데, 이런 멀티에이전트 그래프를 굴릴 때 무엇이 먼저 깨지고 어떻게 관측하는지가 설계 평가의 핵심입니다.
왜 운영 관점으로 봐야 하나요?
멀티에이전트 구조는 투명성을 얻는 대신 어느 노드에서 실패가 나는지, 조용히 통과하는지 관측해야 하는 복잡도를 안게 됩니다. 저는 수집→작가→게이트→검증자로 이어지는 발행 파이프라인을 운영하면서 중간 산출물이 스키마를 벗어났을 때 다음 노드가 어떻게 오염되는지 실측했어요. TradingAgents를 이 기준으로 뜯어보면 운영 함정이 먼저 보입니다.
TradingAgents는 어떤 구조로 나뉘어 있나요?
TradingAgents는 펀더멘털·심리·뉴스·기술 분석가 4명, 강세/약세 리서처, 트레이더, 리스크 매니저를 노드로 나눴어요. 분석가 4명이 병렬로 돌고 리서처가 토론한 뒤 트레이더가 포지션을 결정합니다. 각 노드는 Pydantic 스키마로 입출력 형식을 정의하고 LangGraph가 흐름을 제어해요.
실제로 무엇이 먼저 깨지나요?
첫 번째 함정은 형식 이탈입니다. Pydantic 스키마로 강제하지만 모델이 벗어나면 다음 노드가 파싱 실패로 엉뚱한 방향으로 갑니다. 저희 파이프라인에서 한 에이전트가 "파일을 작성했습니다"라고 보고했는데 실제로는 만들지 않은 적이 있어요. TradingAgents에서 분석가가 자유 텍스트로 답하면 리서처 입력이 깨집니다.
두 번째는 후처리 오염입니다. 저희 파이프라인에서 이미지 삽입 단계가 거의 같은 파일명을 넣어 통과했던 중복 검사가 다시 실패한 적이 있어요. TradingAgents도 리서처가 결론을 안 내면 트레이더가 "보류"를 선택하는데, 이게 기회비용인지 과매매 방지인지 로그만으론 구분이 안 됩니다.
세 번째는 재실행 단위가 커지는 문제예요. 단일 모델은 1회 호출이지만 TradingAgents는 7~8회 필요합니다. 마지막 노드 실패 시 어디서부터 다시 돌려야 하는지가 운영 비용을 좌우해요.
그렇다면 어떤 상황에서 쓸 만한가요?
운영 복잡도를 감당할 이유가 분명한 경우는 추론 과정을 외부에 설명해야 하는 환경입니다. 펀드 운용처럼 매매 결정을 문서화해야 한다면 각 에이전트 출력이 구조화된 증거로 남는 점이 강점이에요. 또 상충하는 신호가 자주 등장하는 전략이라면 유용합니다.
반대로 빠른 백테스트 반복이 중요하다면 단일 모델이 현실적이에요. 파라미터 최적화로 수백 번 반복해야 한다면 7~8회 호출 오버헤드가 병목입니다.
운영 단계에서 보완해야 할 지점
리스크 매니저의 역할이 규칙 기반에 머문다는 점이 첫 번째예요. "포지션 크기 상한 초과 시 거부"하는 정량 체크만 수행하는데, 이 단계에서 조용한 실패가 나면 전체 파이프라인이 멈추지 않고 잘못된 신호만 흘러갑니다.
중간 노드 실패 시 전체 재실행 리스크는 로깅 체계로 보완해야 해요. 저희 파이프라인에서 사람이 4-gram 겹침을 직접 계산해야 했던 것처럼, 형식 이탈이 어느 노드에서 나는지 구조화된 로그가 없으면 디버깅이 막힙니다.
마무리 — 복잡도를 감당할 이유가 있을 때만
멀티에이전트 설계는 추론 과정 투명성을 얻는 대가로 7~8회 호출 오버헤드와 중간 노드 실패 시 전체 재실행 리스크를 짊어집니다. 근거 층위 분리와 상충 신호 추적이 전략 개선에 기여한다면 쓸 만하지만, 단순 지표 기반이라면 단일 모델이 현실적이에요. 가장 먼저 확인할 건 실패 관측과 재실행을 감당할 운영 체계가 있는지입니다. 일봉 이상 중장기 판단이나 연구 보조 용도에 맞고요.
자주 묻는 질문
Q. TradingAgents를 돌리려면 어떤 환경이 필요한가요?
A. Python 3.8 이상, LangGraph와 OpenAI API 키가 필수예요. 로컬 실행 시 에이전트 호출마다 비용이 드니 짧은 기간 백테스트로 먼저 가늠해보세요.
Q. 백테스트 결과를 신뢰해도 되나요?
A. 백테스트 수익률은 데이터 기간·수수료·슬리피지 설정에 크게 좌우됩니다. 실전 전에 거래 비용을 현실적으로 반영해야 하고, 프레임워크의 가치는 수익률보다 추론 과정 추적에 있어요.
Q. 중간 노드 실패를 어떻게 관측하나요?
A. 각 노드 출력을 구조화된 로그로 남기고, Pydantic 스키마 파싱 실패 시 예외를 명시적으로 잡아 어느 단계에서 형식 이탈이 났는지 추적해야 합니다. 조용한 실패를 막으려면 오케스트레이터가 중간 산출물 존재를 직접 확인하는 체크포인트가 필요해요.
Q. 리스크 매니저를 LLM 기반으로 바꿀 수 있나요?
A. 기술적으로는 가능하지만 기본은 규칙 기반이에요. LLM으로 바꾸면 호출 횟수가 더 늘어나므로, 정량 규칙으로 충분하다면 굳이 쓸 필요 없어요.
Q. 이 프레임워크를 암호화폐 트레이딩에도 쓸 수 있나요?
A. 데이터 소스만 바꾸면 암호화폐에도 쓸 수 있어요. 다만 변동성이 크고 뉴스 반응이 빨라서 7~8회 호출 레이턴시가 실시간 대응에 걸림돌일 수 있습니다. 일봉 이상이라면 괜찮지만 분봉 단위라면 단일 모델이 현실적이에요.