LLM 멀티에이전트 투자 시스템(MAS) 완전 가이드: 분석·예측·결정·실행을 하나로 묶는 법

왜 단일 LLM이 아닌가: “똑똑함”보다 중요한 건 재현성·검증·안전성

단일 LLM로도 ‘그럴듯한’ 매매 코멘트는 만들 수 있습니다. 문제는 그 다음입니다.

단일 LLM이 자주 무너지는 3가지 지점

• 혼합 출력: 분석(근거)과 결정(행동)이 한 문단에 섞여서, 나중에 “왜 샀지?”가 안 남습니다.
• 근거 부재: 뉴스/공시/지표를 언급해도 “어떤 입력을 봤는지”가 로그에 안 남아 재현이 안 됩니다.
• 과신/환각: 틀릴 때도 단정적으로 말해 리스크가 커집니다(특히 변동성 급변 구간).

멀티에이전트(MAS)가 해결하는 3가지

• 책임 분리: “누가 무엇을 판단했는지” 분해되어 디버깅이 가능합니다.
• 구조화(계약): 각 에이전트 출력이 JSON 스키마로 고정되면 자동 검증이 됩니다.
• 제약(안전장치): 결정 에이전트가 아무리 공격적으로 말해도, 실행 레이어가 규칙 위반 주문을 막습니다.

실증 수치 예시

리스크 고지(필수)

이 글은 “수익을 보장하는 투자 조언”이 아니라 시스템 설계 방법을 설명합니다. 자동매매·레버리지·파생은 손실이 크게 확대될 수 있고, 백테스트 성과는 미래 성과를 보장하지 않습니다.

폐루프(Closed-loop) 프레임워크 한 장으로 보기: 분석→예측→결정→실행(+로그)

멀티에이전트 투자 시스템의 본질은 “AI가 똑똑하게 말한다”가 아니라, 입력→출력→검증→기록→개선이 반복되는 운영 루프입니다.

단계별 최소 입출력(핵심만)

• 분석(Analysis): 멀티소스(뉴스/공시/기술/매크로)를 “신호”로 구조화
• 예측(Prediction): 멀티호라이즌(T+1/T+5/T+20) 방향 확률 분포 출력
• 결정(Decision): 확률을 이산 포지션 조절(예: +20%, -40%)로 번역
• 실행(Execution): 계정 상태(Account State) + 제약 검증 후 주문 발행
• 로그(Logging): 입력 스냅샷·출력·검증 결과·주문·사유를 저장(리플레이 가능)

1단계: 분석 에이전트 설계 — 멀티소스 신호를 ‘구조화’로 바꾸기

역할 분리 기준(가장 먼저 결정)

• 분석은 “무슨 일이 벌어졌나/현재 상태는 어떤가”
• 예측은 “앞으로 어느 방향 확률이 큰가”
• 결정은 “얼마나(포지션을) 바꿀 것인가”

이 세 경계를 책임·입출력·금지 행동까지 정리한 문서는 멀티에이전트 역할 분리 설계(분석/예측/의사결정)다. 공시·이벤트·가격·시장 4종 예시와 복붙용 JSON 스키마는 (연구 기반 예시) 분석 에이전트 4종 템플릿에 있다.

(연구 기반 예시) 분석 에이전트 4종 템플릿

저변동 시장(예: 공모 REITs) 트레이딩을 다룬 LLM 멀티에이전트 연구에서는 분석 에이전트를 공지/공시(announcement), 이벤트(event), 가격 모멘텀(price momentum), 시장(market) 4종으로 분리해 서로 다른 관점의 신호를 만든 뒤 예측 에이전트가 통합합니다.

“사람이 읽는 요약”이 아니라 “기계가 쓰는 신호”로 만들기

분석 에이전트 출력은 문장 예쁘게 쓰는 게 목적이 아닙니다. 최소한 아래 4가지는 구조화하세요.

• claim(주장): “호재/악재/중립” 같은 결론
• evidence(근거): 어떤 입력에서 나왔는지(문서 ID/타임스탬프/지표 값)
• confidence(신뢰도): 0~1
• risk_flag(주의): “데이터 불충분/충돌 큼/급변동” 같은 경고

샘플 JSON (분석 에이전트 출력)

{
  "agent": "announcement_agent",
  "as_of": "2026-03-04T09:05:00+09:00",
  "asset": "REIT_X",
  "signals": [
    {
      "topic": "distribution_update",
      "claim": "neutral",
      "evidence": [{"source": "disclosure", "doc_id": "D-20260304-001"}],
      "confidence": 0.62,
      "risk_flag": ["needs_human_review"]
    }
  ]
}

2단계: 예측 에이전트 — 방향을 ‘단정’이 아니라 확률 분포로 출력하라

왜 확률인가? (의사결정이 “포지션 조절”이기 때문)

단정형 출력(“매수하세요”)은 시스템을 망치기 쉽습니다. 반면 확률 출력은 리스크 제약과 결합하기 쉽고, 틀려도 “얼마나 틀렸는지” 캘리브레이션(신뢰도 점검)이 가능하며, 충돌 신호를 “합의”로 다룰 수 있습니다.

멀티호라이즌(T+1/T+5/T+20)을 분리해야 하는 이유

• T+1은 뉴스/이벤트에 민감
• T+20은 레짐(시장 상태) 영향이 큼
• 같은 신호라도 기간별 의미가 달라, 하나로 뭉치면 결정이 흔들립니다

샘플 JSON (예측 에이전트 출력)

{
  "agent": "prediction_agent",
  "as_of": "2026-03-04T09:06:00+09:00",
  "asset": "REIT_X",
  "horizons": {
    "T1":  {"up": 0.38, "down": 0.22, "side": 0.40},
    "T5":  {"up": 0.44, "down": 0.18, "side": 0.38},
    "T20": {"up": 0.41, "down": 0.25, "side": 0.34}
  },
  "notes": ["side_probability_high"],
  "quality_checks": {"sum_to_one": true}
}

저변동 시장에서 핵심: “횡보(side)”를 정상 범주로 포함

저변동 자산(가격이 크게 요동치지 않는 자산)은 “조금 오르내리는” 날이 대부분입니다. 이런 시장에서 “오늘 1% 이상 움직이면 추세”처럼 퍼센트 하나를 고정해 두고 추세와 비추세를 나누면, 신호가 너무 자주 나와 오신호가 늘어납니다.

한 연구는 기준값(θ)을 “최근 변동성”에 맞춰 바꾸는 방식을 제안합니다. 오늘 하루는 이렇게 정하고, 며칠 뒤(T+5, T+20)는 √t 룰로 확장해 “횡보” 구간을 따로 잡습니다. 예시 설정에서는 거래일의 약 1/3이 횡보로 나와, “횡보도 정상적인 상태”라는 시장 구조를 반영한다고 설명합니다.

3단계: 의사결정 에이전트 — 예측을 ‘주문’이 아니라 포지션 조절로 번역

여기서부터 “수익률”보다 “생존”이 중요해집니다.

핵심: 이산(discrete) 액션 레더(사다리)로 과신 방지

연구 예시처럼 액션을 다음처럼 제한합니다. close(전량 청산), -40%, -20%, hold(유지), +20%, +40%, upper_limit(상한까지). 이렇게 하면 LLM이 아무리 확신해도 한 번에 올인/풀매도를 못 합니다.

시스템 레벨 리스크 제약 5종(추천)

1. 포지션 상한: 종목/전략별 최대 비중
2. 스텝 크기: 한 번에 바꾸는 비중 제한(+20% 등)
3. 페이스 제한: 포지션 구축은 n회에 나눠서만
4. 손실 트리거: 일정 손실/연속 손실 시 자동 축소/중지
5. 거래 빈도 제한: 과매매 방지(하루/주 최대 횟수)

샘플 JSON (의사결정 에이전트 출력)

{
  "agent": "decision_agent",
  "as_of": "2026-03-04T09:07:00+09:00",
  "asset": "REIT_X",
  "action": "increase_20",
  "rationale": [
    {"type": "probability", "detail": "T5 up(0.44) > down(0.18), side(0.38)"},
    {"type": "risk", "detail": "position_cap_ok, step_ok"}
  ],
  "constraints_applied": ["position_cap", "step_size", "trade_frequency_limit"]
}

결정 출력을 실제 주문으로 넘기기 전에 계정 상태를 어떤 필드로 두고, 검증 게이트를 몇 단계로 둘지 정리한 내용은 계정 상태·주문 실행(Execution) 레이어 설계에 스키마와 5개 게이트 순서까지 담겨 있다.

4단계: 실행(Execution) 레이어 — Account State, 주문 검증, 실패 방지

실전에서 시스템이 무너지는 곳은 대개 “결정”이 아니라 “실행”입니다. 실행 레이어는 LLM이 아니라 규칙 엔진으로 설계하는 것을 권합니다.

아래 스키마·게이트 목록은 요약일 뿐이고, 필드 정의·검증 순서·실패 시 처리까지 풀어둔 설계는 Account State·실행 레이어 설계에서 확인할 수 있다.

Account State 최소 스키마(이 정도는 있어야 함)

• 현금, 현재 포지션, 평균단가, 평가손익
• 최대 비중/스텝/빈도 등 제약 값
• 최근 주문(중복 주문 방지), 거래 가능 여부(시장 상태)

실행 입력 예시(요약)

{
  "account_state": {
    "cash": 10000000,
    "positions": [{"asset": "REIT_X", "weight": 0.20, "avg_price": 101.2}],
    "limits": {"max_weight": 0.60, "step": 0.20, "max_trades_per_day": 3},
    "flags": {"cooldown": false}
  },
  "decision": {"asset": "REIT_X", "action": "increase_20"}
}

실행 전 “검증 게이트” 6개(필수)

1. 상한 초과 여부
2. 스텝 위반 여부
3. 금지 시간/쿨다운 여부
4. 주문 중복 여부
5. 유동성/거래정지/시장중단 체크
6. 데이터 누락(스키마 불완전) 시 기본값=hold

시스템을 시스템답게 만드는 핵심: 출력 표준화(JSON 스키마)

LLM 기반 자동매매에서 “스키마”는 옵션이 아니라 안전벨트입니다. 스키마가 없으면 출력이 흔들림 → 검증 불가 → 로그 불량 → 개선 불가. 스키마가 있으면 자동 검증 → 재시도/폴백 → 리플레이 → 품질 관리.

분석·예측·결정 단계별로 어떤 필드를 두고, 허용 액션과 검증 규칙을 어떻게 둘지 복붙용 스키마와 함께 정리한 문서는 에이전트 출력 표준화(JSON 스키마) 설계 템플릿에 있다.

권장: “검증 실패 → 재시도 → 그래도 실패면 hold” 3단 방어

1. 1차: JSON 파싱/필수 필드 검증
2. 2차: 확률 합=1, 액션이 허용 집합인지
3. 3차: 실패 시 강제 hold + 로그에 실패 사유 기록

LLM 환각·과신을 줄이는 프롬프트 제약 + 근거/검증 루틴

프롬프트는 “말빨”이 아니라 제약 설계입니다.

제약 3종(효과 큰 순서)

1. 형식 강제: “오직 JSON만 출력” + 예시 제공
2. 근거 강제: evidence 없으면 claim 금지
3. 용어 사전: up/down/side, action set, risk flags를 고정

위 세 가지를 프롬프트에 어떻게 넣을지, 복붙용 문구와 검증 포인트까지 정리한 체크리스트는 LLM 환각을 줄이는 프롬프트 제약(용어/근거/형식) 체크리스트에 있다.

출처 표기 방식: 텍스트 근거는 “문서 ID/날짜/요약” 형태로 로그에 남기고, 핵심 수치(변동성, 분위수, 지표 값)는 “산출식/기간(window)”을 함께 남깁니다. 이렇게 해야 나중에 같은 입력으로 리플레이가 가능해집니다.

멀티소스 신호 충돌 해결: 우선순위·가중치·거부권(Stop Rule)

신호 충돌을 “더 똑똑한 모델”로 해결하려고 하면 보통 실패합니다. 규칙이 필요합니다.

충돌 3유형(현장에서 가장 많이 나옴)

• 텍스트(뉴스/공시) vs 가격(기술적)
• 단기(T+1) vs 중장기(T+20)
• 추세 신호 vs 횡보 신호

해결 룰 3종(권장 세트)

• 우선순위 테이블: 예) 공시>시장중단>리스크 트리거>기술적
• 가중치 합의: 분석 에이전트별 confidence 가중합
• 리스크 거부권(Stop Rule): 충돌이 크면 “안 한다(hold)”가 정답

뉴스·공시·기술·매크로가 엇갈릴 때 어떤 순서로 따르고, confidence를 어떻게 합칠지 케이스별로 정리한 문서는 멀티소스 신호(뉴스/공시/기술/매크로) 충돌 해결 규칙(우선순위/가중치)에 있다.

운영의 절반은 관측성: 로그·리플레이·리뷰로 ‘개선 가능한’ 시스템 만들기

성공한 시스템의 공통점은 “예측이 잘 맞았다”가 아니라 기록이 잘 남는다입니다.

로그에 반드시 남길 10개 필드(추천)

• 입력 스냅샷(가격/지표/문서 ID)
• 각 에이전트 출력(JSON)
• 검증 결과(성공/실패/재시도 횟수)
• 최종 액션과 이유
• 주문 결과(체결/실패/부분 체결)
• 제약 발동 내역(상한/스텝/쿨다운)
• 하루/주간 요약(규칙 위반률, 트레이드 수)

위 필드를 어떤 단위로 남기고, 리플레이로 같은 입력을 다시 돌릴 때 리뷰에 쓸 요약(규칙 위반률·트레이드 수)을 어떻게 집계할지는 전략 운영에서 로그/리플레이(리뷰) 구조 만들기에서 필드 설계와 리뷰 템플릿과 함께 다룬다.

모델 선택: 대형 모델 호출 vs 소형 모델 파인튜닝(성능·비용·리스크)

연구 사례처럼 예측 에이전트에서 대형 추론 모델 호출과 소형 모델(Qwen급) 파인튜닝(SFT+RL 정렬)을 비교하는 접근은 현실적입니다.

• 대형 모델(API) 장점: 개발 속도, 복잡한 추론, 초기 실험에 강함
• 소형 파인튜닝 장점: 비용/지연시간, 출력 일관성, 온프렘 운영 가능

비용·지연·온프렘 차이를 호출당 비용과 초기 학습 비용으로 나눠 숫자 기준으로 비교한 내용은 대형 모델 호출 vs 소형 모델 파인튜닝 시스템 비용 비교에 정리되어 있다.

성과 검증: CR·Sharpe·MDD로 “좋았다”를 숫자로 바꾸는 법(+한계 공개)

백테스트는 “자랑”이 아니라 검증 문서입니다. 최소한 아래는 포함하세요.

• 벤치마크(Buy&Hold 등)
• 거래비용/슬리피지 가정
• 과최적화 방지(기간 분리/워크포워드)
• CR(누적수익), Sharpe(위험조정), MDD(최대낙폭) 동시 제시

한계(솔직히 적기)

• 레짐 변화(금리/유동성)로 과거 규칙이 무력화될 수 있음
• 데이터 누락/라벨링 오류/뉴스 편향이 성과를 왜곡할 수 있음
• 실거래는 체결/슬리피지/호가 공백으로 백테스트보다 불리할 수 있음

시작하기: “오늘 만들 수 있는” 최소 기능(MVP) 로드맵

MVP(0→1): 딱 4개만 구현

1. 분석 에이전트 1개(가격 모멘텀만)
2. 예측: up/down/side 확률(T+5 하나만)
3. 결정: 이산 액션 레더(±20%, hold)
4. 실행: 상한/스텝/중복 주문 검증 게이트 + 로그

결론: 멀티에이전트 투자 시스템의 승부처는 ‘분업·계약·제약·관측성·검증’

• 분업(Agents)으로 책임을 나누고
• 계약(JSON)으로 출력을 고정하고
• 제약(Constraints)으로 손실을 제한하며
• 관측성(Logs)으로 개선 가능하게 만들고
• 검증(Backtest)으로 숫자와 한계를 함께 공개하세요.

참고 출처

• [1] arXiv:2602.00082 — Multi-Agent System for Automated Stock Trading