거래 에이전트를 실제 트레이딩 API 워크플로우로 전환하는 방법

Ashley Innocent

Ashley Innocent

26 March 2026

거래 에이전트를 실제 트레이딩 API 워크플로우로 전환하는 방법

요약 / 빠른 답변

TradingAgents를 사용하는 가장 빠르고 실용적인 방법은 Python 패키지로 실행하고, 작은 FastAPI 서비스로 감싸서, Apidog에서 해당 서비스를 테스트하는 것입니다. 이를 통해 분석 트리거, 결과 폴링, 요청 계약 문서화, 팀과의 설정 공유를 위한 반복 가능한 워크플로를 얻을 수 있습니다.

서론

TradingAgents는 밖에서 보기에 감탄할 만합니다. GitHub 리포지토리는 다중 에이전트 거래 워크플로, 세련된 CLI, 여러 모델 제공업체 지원, 그리고 프레임워크 설계를 설명하는 연구 논문을 보여줍니다. 하지만 실제 엔지니어링 워크플로에서 사용하려고 할 때 더 어려운 부분이 시작됩니다.

대부분의 팀은 한 명의 개발자만 로컬에서 실행할 수 있는 리포지토리를 원하지 않습니다. 그들은 분석을 트리거하고, 티커와 날짜를 전달하며, 작업 ID를 반환하고, 나중에 결과를 검사하며, 모든 질문을 Python 디버깅 세션으로 만들지 않고 프론트엔드, QA 또는 플랫폼 팀원에게 해당 워크플로를 전달할 수 있는 반복 가능한 방법을 원합니다. 그리고 모든 거래 연구 시스템은 결국 실제 투자 결정을 알리는 데 사용될 것이기 때문에, TradingAgents를 누군가의 노트북에 일회성 스크립트로 남겨두는 대신 통제되고 문서화된 API로 래핑하는 것이 훨씬 더 중요합니다.

💡
Apidog는 이 워크플로에 자연스럽게 들어맞습니다. FastAPI에서 OpenAPI 스키마를 가져오고, 로컬 및 원격 배포를 위한 환경을 저장하고, 응답에서 변수를 추출하며, 폴링 요청을 시나리오로 연결하고, 팀의 나머지 구성원들을 위해 문서를 게시할 수 있습니다. Apidog를 무료로 다운로드하여 따라해 보세요.
버튼

TradingAgents는 무엇이고 무엇이 아닌가

코딩을 시작하기 전에 도구를 정확하게 정의하는 것이 도움이 됩니다.

TradingAgents는 오픈 소스 다중 에이전트 거래 프레임워크입니다. 이 리포지토리는 거래 회사의 구조를 반영하는 일련의 전문화된 역할을 설명합니다.

이 리포지토리는 또한 이 프레임워크가 LangGraph로 구축되었으며 OpenAI, Google, Anthropic, xAI, OpenRouter, Ollama를 포함한 여러 모델 제공업체를 지원한다고 명시합니다. 공개 기본 구성에서 이 프로젝트는 현재 다음과 같은 값을 사용합니다.

이는 여러분이 실제로 무엇을 다루고 있는지 알려주기 때문에 중요합니다: 바로 구성 가능한 Python 프레임워크이며, 드롭인 SaaS API가 아니라는 점입니다.

이 리포지토리는 또한 범위에 대해 신중합니다. TradingAgents는 금융 조언이 아닌 연구 프레임워크로 제시됩니다. 이를 내부적으로 사용하거나 이를 중심으로 소프트웨어를 구축하는 경우, 문서와 사용자 경험에 이 프레임워크를 명확하게 표시해야 합니다.

1단계: TradingAgents 설치

리포지토리에서 직접 설정을 시작하세요:

git clone https://github.com/TauricResearch/TradingAgents.git
cd TradingAgents
conda create -n tradingagents python=3.13
conda activate tradingagents
pip install .

이 튜토리얼에서 API 래퍼도 구축하려면 FastAPI와 Uvicorn을 추가하세요:

pip install fastapi uvicorn

TradingAgents 리포지토리에는 다음과 같은 제공업체 변수가 포함된 .env.example 파일도 있습니다:

OPENAI_API_KEY=
GOOGLE_API_KEY=
ANTHROPIC_API_KEY=
XAI_API_KEY=
OPENROUTER_API_KEY=

모델 및 데이터 선택에 따라 Alpha Vantage와 같은 다른 공급업체 자격 증명이 필요할 수도 있습니다.

여기서 두 가지 실용적인 규칙이 중요합니다:

  1. 자격 증명을 환경 변수 또는 비밀 관리자에 보관하세요.
  2. 나중에 공용 API 요청 본문을 통해 공급자 비밀을 전달하지 마세요.

이러한 분리를 통해 Apidog 환경이 더 깔끔해지고 보안 모델이 훨씬 안전해질 것입니다.

2단계: Python에서 TradingAgents 먼저 실행하기

어떤 API 래퍼를 구축하기 전에, 핵심 프레임워크가 여러분의 환경에서 실행되는지 확인하세요.

README는 최소한의 Python 사용 패턴을 보여줍니다:

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

ta = TradingAgentsGraph(debug=True, config=DEFAULT_CONFIG.copy())
_, decision = ta.propagate("NVDA", "2026-01-15")
print(decision)

이것이 올바른 첫 번째 체크포인트인 이유는 초기에 중요한 유일한 질문에 답하기 때문입니다. 즉, 여러분의 머신, 모델 설정 및 종속성이 실제로 TradingAgents 실행을 수행할 수 있는가입니다.

만약 그것이 작동한다면, 통제된 구성으로 넘어갈 수 있습니다. 리포지토리는 또한 기본 구성을 재정의할 수 있음을 보여줍니다:

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

ta = TradingAgentsGraph(debug=True, config=config)
_, decision = ta.propagate("NVDA", "2026-01-15")
print(decision)

두 번째 예시는 보이는 것보다 더 중요합니다. 이는 나중에 API에서 노출할 가치가 있는 매개변수가 무엇인지 알려줍니다:

이 로컬 Python 단계를 건너뛰고 HTTP로 바로 이동하면 디버깅이 필요 이상으로 어려워집니다.

3단계: TradingAgents 사용 방법 결정

이 시점에서 프레임워크를 사용하는 세 가지 일반적인 방법이 있습니다.

옵션 1: CLI만 사용

리포지토리에는 티커, 날짜, 제공업체 및 연구 깊이를 선택할 수 있는 대화형 CLI가 포함되어 있습니다. 이는 프로젝트를 빠르게 탐색하는 좋은 방법입니다.

다음과 같은 경우에 사용하세요:

다음 단계가 프론트엔드, 관리 도구, 공유 서비스 또는 QA 워크플로라면 여기서 멈추지 마세요.

옵션 2: Python만 사용

맞춤형 오케스트레이션이나 로컬 스크립트가 필요할 때 Python에서 TradingAgentsGraph를 직접 호출하는 것이 CLI보다 낫습니다.

다음과 같은 경우에 사용하세요:

이것은 여러 팀이 워크플로를 사용해야 할 때 여전히 부족합니다.

옵션 3: API 래퍼 + Apidog

이것이 가장 유용한 팀 설정입니다. TradingAgents를 실행 엔진으로 유지하고, 작은 FastAPI 서비스를 통해 노출하며, Apidog를 사용하여 계약을 테스트하고 문서화합니다.

다음과 같은 경우에 사용하세요:

대부분의 팀에게 이것은 'TradingAgents를 사용하는 방법'이 단순히 로컬 데모가 아닌 실제 구현 답변이 되는 지점입니다.

4단계: FastAPI 서비스에 TradingAgents 래핑하기

첫 번째 래퍼를 위한 가장 깔끔한 패턴은 작업 기반 API입니다.

왜 작업 기반일까요? 다중 에이전트 분석은 시간이 너무 오래 걸려 하나의 요청을 열어두는 것이 클라이언트에게 불편할 수 있기 때문입니다. 더 나은 패턴은 다음과 같습니다:

POST /analyses -> returns analysis_id
GET /analyses/{id} -> returns queued, running, completed, or failed

이러한 구조는 브라우저에 더 쉽고, QA에 더 쉬우며, Apidog에 문서화하기도 더 쉽습니다.

API 계약 생성

최소한의 계약은 다음과 같습니다:

엔드포인트목적
GET /health기본 상태 확인
POST /analysesTradingAgents 실행 트리거
GET /analyses/{analysis_id}작업 상태 및 최종 결과 가져오기

래퍼 구축

다음은 간결한 FastAPI 예제입니다:

from concurrent.futures import ThreadPoolExecutor
from datetime import date, datetime
from uuid import uuid4

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, Field

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

app = FastAPI(title="TradingAgents API", version="0.1.0")
executor = ThreadPoolExecutor(max_workers=2)
jobs: dict[str, dict] = {}

class AnalysisRequest(BaseModel):
 ticker: str = Field(..., min_length=1, examples=["NVDA"])
 analysis_date: date
 llm_provider: str = Field(default="openai")
 deep_think_llm: str = Field(default="gpt-5.2")
 quick_think_llm: str = Field(default="gpt-5-mini")
 research_depth: int = Field(default=1, ge=1, le=5)

def run_analysis(job_id: str, payload: AnalysisRequest) -> None:
 jobs[job_id]["status"] = "running"
 jobs[job_id]["started_at"] = datetime.utcnow().isoformat()

 config = DEFAULT_CONFIG.copy()
 config["llm_provider"] = payload.llm_provider
 config["deep_think_llm"] = payload.deep_think_llm
 config["quick_think_llm"] = payload.quick_think_llm
 config["max_debate_rounds"] = payload.research_depth
 config["max_risk_discuss_rounds"] = payload.research_depth

 try:
 graph = TradingAgentsGraph(debug=False, config=config)
 _, decision = graph.propagate(
 payload.ticker,
 payload.analysis_date.isoformat(),
 )
 jobs[job_id].update(
 {
 "status": "completed",
 "finished_at": datetime.utcnow().isoformat(),
 "result": decision,
 }
 )
 except Exception as exc:
 jobs[job_id].update(
 {
 "status": "failed",
 "finished_at": datetime.utcnow().isoformat(),
 "error": str(exc),
 }
 )

@app.get("/health")
def health() -> dict:
 return {"status": "ok"}

@app.post("/analyses", status_code=202)
def create_analysis(payload: AnalysisRequest) -> dict:
 analysis_id = str(uuid4())
 jobs[analysis_id] = {
 "status": "queued",
 "ticker": payload.ticker,
 "analysis_date": payload.analysis_date.isoformat(),
 "created_at": datetime.utcnow().isoformat(),
 }
 executor.submit(run_analysis, analysis_id, payload)
 return {"analysis_id": analysis_id, "status": "queued"}

@app.get("/analyses/{analysis_id}")
def get_analysis(analysis_id: str) -> dict:
 job = jobs.get(analysis_id)
 if not job:
 raise HTTPException(status_code=404, detail="Analysis not found")
 return job

서비스 시작:

uvicorn app:app --reload

서버가 시작되면 FastAPI는 다음을 노출합니다:

두 번째 URL은 Apidog가 직접 가져올 수 있기 때문에 특히 유용합니다.

5단계: API를 통해 TradingAgents 사용하기

이제 안정적이고 반복 가능한 방식으로 TradingAgents를 사용할 준비가 되었습니다.

분석 트리거

다음과 같은 본문으로 POST /analyses 요청을 보냅니다:

{
 "ticker": "NVDA",
 "analysis_date": "2026-03-26",
 "llm_provider": "openai",
 "deep_think_llm": "gpt-5.2",
 "quick_think_llm": "gpt-5-mini",
 "research_depth": 2
}

응답은 빠르고 작아야 합니다:

{
 "analysis_id": "88f9f0f5-7315-4c73-8ed5-d0a71f613d31",
 "status": "queued"
}

이것이 바로 여러분이 원하는 것입니다. 클라이언트는 최종 보고서를 즉시 필요로 하지 않습니다. 실행에 대한 안정적인 핸들이 필요합니다.

결과 폴링

진행 상황을 확인하려면 GET /analyses/{analysis_id}를 사용하세요:

{
 "status": "running",
 "ticker": "NVDA",
 "analysis_date": "2026-03-26",
 "created_at": "2026-03-26T06:00:00.000000",
 "started_at": "2026-03-26T06:00:01.000000"
}

워크플로가 완료되면 응답에 최종 결정이 포함될 수 있습니다:

{
 "status": "completed",
 "ticker": "NVDA",
 "analysis_date": "2026-03-26",
 "result": {
 "decision": "hold"
 }
}

뭔가 문제가 발생하면, 클라이언트가 추측하게 두는 대신 명확한 failed 상태와 오류 메시지를 반환하세요.

6단계: Apidog로 API 가져오기

여기서 워크플로를 유지 관리하기가 훨씬 쉬워집니다.

Apidog에서 다음으로부터 OpenAPI 스키마를 가져옵니다:

http://localhost:8000/openapi.json

가져오기 후에는 요청 및 응답 구조가 이미 설정된 엔드포인트를 볼 수 있어야 합니다.

그것은 몇 가지 즉각적인 이점을 제공합니다:

임시 cURL 테스트에서 전환한다면, 이는 의미 있는 업그레이드입니다. 요청 전용 도구에서 전환한다면, Apidog는 디자인, 테스트, 환경 및 문서를 한 곳에 유지할 수 있기 때문에 여기서부터 더 중요해집니다.

7단계: Apidog 환경 생성

API가 가져와지면, 로컬 서비스를 위한 환경을 생성합니다.

예시 변수:

base_url = http://localhost:8000
analysis_id =

API가 인증을 사용하는 경우, 그것도 포함하세요:

internal_api_key = your-local-dev-key

이 단계는 작아 보이지만, 많은 마찰을 방지합니다:

이것은 Apidog가 TradingAgents의 강력한 동반자가 되는 가장 간단한 이유 중 하나입니다. 프레임워크 자체는 분석 로직을 처리합니다. Apidog는 그 주변의 공유 워크플로를 처리합니다.

8단계: Apidog에서 전체 워크플로 테스트

이제 실제 클라이언트가 하는 방식대로 Apidog를 사용하여 TradingAgents를 테스트할 수 있습니다.

요청 1: 분석 생성

구성:

{
 "ticker": "NVDA",
 "analysis_date": "2026-03-26",
 "llm_provider": "openai",
 "deep_think_llm": "gpt-5.2",
 "quick_think_llm": "gpt-5-mini",
 "research_depth": 2
}

상태를 검증하고 ID를 저장하는 테스트 스크립트를 추가하세요:

pm.test("상태는 202", function () {
 pm.response.to.have.status(202);
});

const data = pm.response.json();
pm.expect(data.analysis_id).to.exist;
pm.environment.set("analysis_id", data.analysis_id);

요청 2: 분석 폴링

구성:

그런 다음 다음과 같은 어설션을 추가하세요:

pm.test("분석에 유효한 상태가 있습니다", function () {
 const data = pm.response.json();
 pm.expect(["queued", "running", "completed", "failed"]).to.include(data.status);
});

성공 경로 확인도 원한다면:

pm.test("완료된 작업에는 결과가 포함됩니다", function () {
 const data = pm.response.json();
 if (data.status === "completed") {
 pm.expect(data.result).to.exist;
 }
});

두 요청을 시나리오로 연결

이것이 Apidog가 단순한 API 클라이언트 이상이 되는 지점입니다. 다음을 수행하는 시나리오를 구축하세요:

  1. POST /analyses를 보냅니다.
  2. analysis_id를 저장합니다.
  3. 몇 초 기다립니다.
  4. GET /analyses/{{analysis_id}}를 실행합니다.

이를 통해 QA 및 엔지니어링 팀은 단일 엔드포인트가 200을 반환하는지 여부만 확인하는 대신, 수명 주기를 검증할 수 있는 재현 가능한 방법을 얻게 됩니다.

9단계: 팀을 위한 내부 문서 게시

요청이 작동하면, 테스트에서 멈추지 마세요.

Apidog를 사용하여 다음을 설명하는 내부 문서를 게시하세요:

이것은 TradingAgents를 잘 사용하는 가장 중요한 부분 중 하나입니다. 핵심 프레임워크는 영리하지만, 계약이 한 개발자의 머릿속에만 존재할 경우 영리한 프레임워크는 팀의 병목 현상이 됩니다.

Apidog를 무료로 다운로드하여 TradingAgents를 환경, 어설션, 재사용 가능한 팀 준비 시나리오를 갖춘 문서화된 API 워크플로로 전환하세요.

이러한 방식으로 TradingAgents를 사용할 때 흔히 저지르는 실수

프레임워크를 호스팅된 API처럼 취급하기

TradingAgents는 미리 만들어진 공용 서비스가 아닙니다. Python 프레임워크입니다. 리포지토리가 계약을 제공할 것이라고 기대하는 대신, 팀이 사용할 계약을 직접 구축하세요.

요청 본문을 통해 비밀 전달하기

제공자 키는 환경 관리에 보관하세요. 예시, 프론트엔드 호출 또는 공유 스크린샷으로 유출하지 마세요.

하나의 긴 동기 응답 반환하기

다단계 에이전트 워크플로의 경우, 작업 기반 API가 긴 블로킹 요청보다 관리하기 쉬운 경우가 많습니다.

너무 많은 구성 옵션 노출하기

리포지토리에는 유용한 구성 옵션이 있지만, API가 첫날부터 모든 내부 설정을 노출할 필요는 없습니다. 작고 안정적인 계약으로 시작하세요.

결과를 메모리에만 보관하기

튜토리얼 코드는 이해하기 쉽도록 인메모리 딕셔너리를 사용합니다. 프로덕션에서는 서비스 재시작으로 인해 활성 분석이 지워지지 않도록 작업 상태와 결과를 영구 백엔드에 저장하세요.

연구 면책 조항 숨기기

서비스가 TradingAgents를 래핑하는 경우, 프로젝트가 사용하는 것과 동일한 경고를 유지하세요. 이 프레임워크는 금융 조언이 아닌 연구 및 실험을 위한 것입니다.

결론

TradingAgents를 사용하는 가장 좋은 방법은 무엇을 하려는지에 따라 다릅니다. 프레임워크를 혼자 탐색한다면 CLI와 Python 패키지로 충분합니다. 안정적이고 반복 가능한 팀 워크플로를 원한다면 TradingAgents를 작은 API로 래핑하고 Apidog를 사용하여 테스트하고 문서화하세요.

GitHub 리포지토리에서 사용 가능한 팀 워크플로로 빠르게 전환하려면, TradingAgents를 설치하고, TradingAgentsGraph가 로컬에서 작동하는지 확인하고, POST /analysesGET /analyses/{id}를 추가한 다음, 스키마를 Apidog로 가져와서 하나의 엔드투엔드 시나리오를 구축하세요. 이 경로는 터미널 명령 모음과 부족 지식보다 훨씬 유지 관리가 쉽습니다.

버튼

자주 묻는 질문

TradingAgents를 처음 사용하는 방법은 무엇입니까?

리포지토리를 설치하고, 모델 제공업체 환경 변수를 설정하고, TradingAgentsGraph를 사용하여 Python 예제를 실행하는 것으로 시작하세요. 일단 작동하면, CLI만 필요한지 아니면 API로 래핑해야 하는지 결정하세요.

TradingAgents는 공식 REST API와 함께 제공됩니까?

2026년 3월 26일 검토된 공개 리포지토리 자료에 따르면 그렇지 않습니다. 이 프로젝트는 CLI 및 Python 패키지로 제공되며, 이것이 많은 팀이 얇은 FastAPI 계층을 추가하기를 원하는 이유입니다.

프론트엔드 앱에서 TradingAgents를 사용하는 가장 쉬운 방법은 무엇입니까?

프론트엔드에서 Python 프레임워크를 직접 호출하지 마세요. analysis_id를 반환하는 백엔드 API를 통해 노출하고, 프론트엔드가 결과를 폴링하게 하세요.

TradingAgents와 함께 Apidog를 사용하는 이유는 무엇입니까?

Apidog는 OpenAPI 스키마를 가져오고, 환경 값을 저장하고, 예시 요청을 저장하고, 어설션을 추가하고, Python 코드를 역설계할 필요가 없는 팀원들과 워크플로를 공유할 수 있는 깔끔한 공간을 제공합니다.

API에서 노출할 가치가 있는 TradingAgents 설정은 무엇입니까?

가장 안전한 시작 설정은 티커, 분석 날짜, 제공업체, 모델 선택 및 연구 깊이입니다. 사용 사례가 실제인 경우 나중에 언제든지 확장할 수 있습니다.

예제 작업 상태를 메모리에 유지할 수 있습니까?

학습 또는 프로토타이핑 용도로만 사용하세요. 프로덕션에서는 서비스 재시작으로 인해 활성 분석이 지워지지 않도록 작업 상태와 결과를 영구 백엔드에 저장하세요.

TradingAgents는 실시간 금융 결정에 적합합니까?

공개 프로젝트 자료는 이를 연구 프레임워크로 설명하며, 금융 또는 투자 조언이 아니라고 명시적으로 밝힙니다. 자체적인 통제, 검증 및 거버넌스를 추가하지 않는 한 연구 및 실험 시스템으로 취급하세요.

Apidog에서 API 설계-첫 번째 연습

API를 더 쉽게 구축하고 사용하는 방법을 발견하세요