멀티에이전트 역할 분리 설계: 분석·예측·의사결정 에이전트를 나누는 기준(재현성·디버깅·안전성)

역할 분리를 해야 ‘시스템’이 된다: 단일 LLM의 3가지 구조적 실패

1) 혼합 출력: “왜 샀는지”가 남지 않는다

단일 LLM은 한 번의 응답에 근거→전망→행동을 섞어 말합니다. 그 결과:

• 근거(입력)가 로그에 남지 않거나
• “근거는 약한데 행동만 강한” 출력이 생기고
• 같은 입력이어도 문장 스타일에 따라 결론이 달라집니다.

2) 근거 부재/출처 누락: 리플레이(Replay)가 불가능

운영에서 가장 중요한 질문은 “맞았냐?”가 아니라 “다시 돌리면 같은 결론이 나오냐?”입니다. 출처/필드가 고정되지 않으면 리플레이가 깨지고, 개선도 불가능해집니다.

3) 과신/환각 + 과매매: 실전 리스크가 ‘주문’으로 전이

LLM이 단정적으로 말할수록 위험합니다. 특히 변동성 급변 구간에서 “확신”이 포지션 과확대로 연결되면 시스템이 한 번에 망가집니다.

역할 분리의 핵심은 “무엇을 하지 말아야 하는가(금지 행동)”를 정하는 것

역할 분리는 ‘업무 분장’이 아닙니다. 출력의 범위를 좁히고, 금지행동을 강제하는 설계입니다.

(핵심) 1장으로 끝내는 역할 정의서: 책임(RACI) + 입력/출력 + 금지 행동

아래 표를 팀의 “설계 명세서(Definition of Done)”로 쓰면, 역할 분리가 무너지지 않습니다. 분석 에이전트 4종과 예측·결정·실행·로깅으로 나누어 보기 쉽게 정리했습니다.

분석 에이전트 4종

예측·결정·실행·로깅

예시: 연구에서 사용된 ‘의사결정 이산 액션’(실제 값)

중국 공모 REITs를 대상으로 한 LLM 멀티에이전트 투자 시스템 연구에서는 의사결정 출력을 이산 포지션 조절 신호로 제한합니다. 예:

• close position
• reduce position by 40% / 20%
• hold unchanged
• increase position by 20% / 40%
• increase position to the upper limit

이 방식의 요지는 단순합니다. 모델이 아무리 확신해도 한 번에 과격하게 못 움직이게 만드는 것입니다.

핸드오프(연결) 설계: 에이전트가 만나는 지점은 ‘데이터 계약(JSON)’이다

역할 분리가 실패하는 가장 흔한 이유는 “역할”이 아니라 출력 포맷입니다. 포맷이 흔들리면 검증이 깨지고, 검증이 깨지면 운영이 깨집니다.

최소 계약 3종(이거 없으면 운영 불가)

• 분석 → 예측 계약: signals[], evidence, confidence, risk_flags
• 예측 → 결정 계약: horizons(T+1/T+5/T+20), probabilities(sum=1)
• 결정 → 실행 계약: action(허용 집합), constraints_applied, rationale

샘플(미니)로는 아래 정도만 있어도 충분합니다.

{
  "analysis": {"signals":[{"claim":"neutral","evidence":[{"doc_id":"D-001"}],"confidence":0.62}]},
  "prediction": {"T5":{"up":0.44,"down":0.18,"side":0.38}},
  "decision": {"action":"increase_20","constraints_applied":["position_cap","step_size"]}
}

에이전트 출력을 표준화하려면 에이전트 출력 표준화(JSON 스키마) 설계 템플릿을 참고하세요.

디버깅이 쉬워지는 구조: “문제는 어느 에이전트에서 생겼나?”를 5분 안에 찾는 법

역할 분리의 진짜 가치는 성능보다 원인 규명 속도입니다.

디버깅 루틴 5단계(리플레이 중심)

1. 입력 스냅샷 고정(가격/문서/지표 동일)
2. 분석만 재실행 → signals/evidence 품질 확인
3. 예측만 재실행 → 확률 합=1, 과신 여부 확인
4. 결정만 재실행 → action이 제약을 침범하는지 확인
5. 실행 게이트 확인 → 왜 주문이 막혔는지(또는 왜 통과했는지) 확인

전략 운영에서 로그·리플레이(리뷰) 구조를 만들려면 전략 운영에서 로그/리플레이(리뷰) 구조 만들기를 참고하세요.

안전장치(리스크) 관점에서의 역할 분리: LLM은 ‘결정’해도 실행은 ‘허가’받아야 한다

역할 분리만 해도 좋아지지만, 마지막 안전장치는 실행 레이어 검증 게이트입니다.

권장 제약 5종(최소 세트)

• 포지션 상한(position cap)
• 스텝(step size)
• 페이스(pace restriction)
• 손실 트리거(일일/연속 손실 제한)
• 거래 빈도 제한(과매매 방지)

운영 메모

어떤 게이트에서든 실패하면 기본값은 HOLD + 실패 사유 로그가 안전합니다. “불확실하면 하지 않는다”를 시스템에 박아두는 게 장기 생존에 유리합니다.

실증 사례: 역할 분리 + 이산결정이 성과·낙폭을 어떻게 바꿨나(공개 연구)

역할 분리(분석 4종 + 예측 + 이산 의사결정)를 포함한 멀티에이전트 프레임워크를 중국 공모 REITs에 적용한 공개 연구의 백테스트(2024-10~2025-10, 28개 펀드 평균)에서는, 에이전트 전략이 벤치마크(Buy&Hold) 대비 누적수익·샤프 개선 + 낙폭 축소를 보고합니다.

실증 수치 예시

※ 이 수치가 “수익 보장”을 의미하진 않습니다. 다만 역할 분리와 제약 설계가 운영 가능한 리스크 구조를 만드는 데 유리하다는 실증 사례로 참고할 만합니다. 출처: arXiv 2602.00082 Table 1.

자주 하는 오해 교정: 멀티에이전트 = 모델 여러 개? (꼭 그렇진 않다)

• 같은 모델이어도 역할 프롬프트 + 스키마로 에이전트화할 수 있습니다.
• 멀티에이전트의 목적은 “정확도”만이 아니라 감사 가능성(audit), 재현성, 안전장치입니다.
• 다만 에이전트가 과도하게 늘면 비용/지연/조정 복잡도가 급증합니다.

시스템 비용(대형 호출 vs 소형 파인튜닝) 비교는 대형 모델 호출 vs 소형 모델 파인튜닝에서 다룹니다.

바로 적용하는 체크리스트: 내 시스템은 ‘역할 분리’가 되어 있는가?

• 경계 체크: 분석이 행동을 말하지 않는가? 예측이 단정하지 않는가? 결정이 연속값을 내지 않는가?
• 계약 체크: JSON 스키마/필수 필드/검증 규칙/폴백(HOLD)이 있는가?
• 운영 체크: 입력 스냅샷·출력·게이트 결과·주문 결과가 리플레이 가능한가?

LLM 환각을 줄이는 “프롬프트 제약(용어·근거·형식)”은 LLM 환각 줄이는 프롬프트 제약 체크리스트에서 정리했습니다.

결론: 역할 분리는 “분업”이 아니라 “경계+계약+제약”이다

멀티에이전트 역할 분리의 핵심은 간단합니다. 경계(금지행동)로 섞임을 막고 → 계약(JSON)으로 흔들림을 막고 → 제약(리스크 룰)으로 실전 사고를 막으세요.