신호 충돌 해결 룰 설계: 뉴스·공시·기술·매크로가 싸울 때 ‘일관되게’ 결정하는 법

왜 충돌이 생기는가: 신호는 “틀린 게” 아니라 “시간축/의미/시장상태”가 다르다

1) 시간축이 다르면 같은 사실도 결론이 달라진다

뉴스는 T+1에 강하고, 매크로는 T+20에 강합니다. 기술적 신호는 “지금 가격 반응”이라 단기엔 유효하지만, 이벤트 충격엔 쉽게 뒤집힙니다.

2) 텍스트 신호는 ‘사건’, 가격 신호는 ‘반응’이다

공시/뉴스는 “무슨 일이 있었는가”, 기술적은 “시장이 어떻게 반응했는가”. 둘이 충돌할 수밖에 없습니다.

3) 시장 상태(추세/횡보/급변)가 신호 신뢰도를 바꾼다

저변동 시장에서는 “돌파/크로스”가 더 자주 가짜가 됩니다. 예를 들어 REITs 기반 멀티에이전트 연구에서는 동적 임계값(θ)로 sideways(횡보)를 정의할 때 약 33%가 횡보로 분류된다고 서술합니다. 즉 “횡보가 기본”인 시장에서는 기술적 매수 신호가 더 자주 충돌을 만든다는 뜻입니다.

충돌을 유형화하면 절반은 끝난다: 6가지 대표 충돌 패턴

아래 6개만 “패턴 라이브러리”로 만들어두면, 그날그날 감정이 아니라 규칙으로 처리됩니다.

해결의 핵심 3종 세트: 우선순위 + 가중치 합의 + Stop rule(거부권)

신호 충돌 해결은 “정답 찾기”가 아니라 “일관성 만들기”입니다. 아래 3가지를 세트로 씁니다.

룰 1) 우선순위 매트릭스: “상황별로” 우선순위를 바꿔라

고정 우선순위는 간단하지만 위험합니다. 시장 상태/이벤트 유형/데이터 품질에 따라 우선순위가 바뀌어야 합니다.

추천: 3축 우선순위 기준

• (A) 이벤트 확정성: 공시/규제(확정) > 주요 뉴스(준확정) > 소셜/루머(불확정)
• (B) 시장 상태: 급변동/리스크온오프 전환 시 매크로·리스크 트리거 상향
• (C) 데이터 품질: 출처 불명/중복 기사/추측형 문장 많으면 신뢰도 강등

실전 팁: 우선순위는 “누구 말이 맞냐”가 아니라 사고를 줄이는 장치입니다. 특히 공시처럼 확정 정보가 들어오면, 기술적 신호보다 우선하도록 해두는 게 일반적으로 안전합니다.

룰 2) 가중치 합의 모델: “신호 점수화”로 흔들림을 줄인다

우선순위로 ‘상위 룰’을 먼저 적용한 다음, 남은 신호는 가중치 합의(컨센서스)로 결정합니다.

최소 점수 모델(바로 쓰는 형태)

• 방향 s: 매수 +1 / 매도 -1 / 중립 0
• 신뢰도 c: 0~1
• 가중치 w: 신호 중요도(합=1 권장)
• 최종 점수: Score = Σ(wᵢ × sᵢ × cᵢ)
• 시간 감쇠(옵션): wᵢ(t) = wᵢ × exp(-λΔt) (뉴스는 빨리 만료)

위 가중치(0.35, 0.25, 0.25, 0.15)는 “정답”이 아니라 시작점입니다. 운영 로그로 튜닝하세요.

룰 3) Stop rule(거부권): “충돌이 큰 날은 안 하는 게 전략”을 규칙화

Stop rule은 신호 충돌 해결의 마지막 안전장치입니다. 모든 신호가 싸우면 시장보다 내 감정이 먼저 움직이기 때문입니다.

Stop rule 트리거(추천 5종)

• 충돌 점수 임계: |Score|가 너무 작다(합의가 약함)
• 신뢰도 낮음: 핵심 신호들의 c가 전반적으로 낮다
• 급변동/이벤트 리스크: 변동성 급등, 거래중단, 중요 이벤트 직전/직후
• 근거 부족: evidence(근거) 누락/출처 불명 비중 큼
• 리스크 룰 발동: 포지션 상한/스텝/손실 트리거 위반

HOLD도 결정으로 기록(사유 필수).

운영 포인트: Stop rule은 “아무것도 안 함”이 아니라 결정 하나를 한 것입니다. 반드시 “왜 hold였는지”를 로그에 남겨야 다음 주 리뷰에서 개선이 됩니다.

로그를 어떤 단위로 남기고, 나중에 같은 입력으로 다시 돌려보는(리플레이) 구조를 어떻게 잡을지는 전략 운영에서 로그/리플레이(리뷰) 구조 만들기에서 필드 설계·리뷰 템플릿과 함께 다룹니다.

멀티에이전트/LLM 시스템에 붙이는 방법: JSON 출력 → 검증 → 충돌 해결 엔진

충돌 해결은 “좋은 판단력”이 아니라 입력 형식이 고정되어야 돌아갑니다.

• 신호 입력 최소 필드: signal_type, direction, confidence, evidence, horizon, timestamp
• 충돌 해결 엔진 출력: final_action, reason, stop_rule_triggered, score_breakdown

final_action·score_breakdown 같은 필드를 쓰려면 에이전트 출력을 먼저 JSON으로 고정해야 한다. LLM 에이전트 출력 표준화: JSON 스키마 템플릿으로 분석→예측→결정 연결하기에서 분석·예측·결정 단계별 스키마와 필수 필드를 정리했다.

엔진이 낸 final_action을 실제 주문으로 넘길 때는 계정 상태(Account State)와 실행 레이어가 선행되어야 한다. 계정 상태(Account state)·주문 실행(Execution) 레이어 설계에서 최소 스키마와 5개 게이트를 다룬다.

실제 예시: “결정 흔들림”을 줄이는 Before/After

x축은 주(week), y축은 결정 변경 횟수(주간 합)입니다. 결정 변경이란 같은 자산·전략에서 하루/세션 안에 최종 결정이 바뀐 횟수를 주 단위로 더한 값입니다.Before는 룰 도입 전, After는 룰 도입 후 구간입니다. 차트의 세로 점선은 Rule Live가 적용된 시점을 나타냅니다.비교에 쓴 지표 예시는 결정 변경 횟수, 거래 빈도, 규칙 위반률이며, 데이터는 내부 로그를 사용했습니다.

결론: 신호 충돌 해결의 목표는 “정답”이 아니라 “일관성”이다

신호 충돌 해결은 유형화 → 우선순위 → 가중치 합의 → Stop rule → 로그/리뷰로 끝납니다. 오늘 해야 할 일은 딱 하나입니다. 내 결정을 흔드는 “충돌 패턴 6개”를 표로 만들고, 우선순위/가중치/거부권을 고정하세요.