원문은 hexisteme notes에 게시되었습니다.

저는 제 에이전트 군단(agent fleet)의 중대한 결정들 — 자금, 기술 도입, 그 외 모든 핵심적인 사항들 — 을 위해 소규모의 원장 기반 파이프라인(ledger-driven pipeline)을 운영하고 있습니다. 그리고 이 시스템에서 가장 큰 역할을 한 단 하나의 규칙은 부끄러울 정도로 단순합니다: 명시적인 반증 조건(falsification condition) 없이는 어떤 주장도 수용되지 않는다는 것입니다. "높은 신뢰도"가 아닙니다. 퍼센트(%)도 아닙니다. 만약 발생할 경우 그 주장이 틀렸음을 증명하는 구체적이고 관찰 가능한 사건이나 임계값(threshold)입니다.

제가 이 결론에 도달한 것은, 제 에이전트들이 분석의 탈을 쓴 채 유창한 언어 모델링(language modeling)에 불과한, 확신에 찬 것처럼 들리는 숫자들을 내놓는 것을 지켜보았기 때문입니다. "이 주식이 상승할 확률이 70%입니다." "이 접근 방식이 아마 작동할 것입니다." 이런 문장들은 결론처럼 읽힙니다. 하지만 그것은 결론이 아닙니다. 그것은 패턴 완성(pattern completion)입니다. 모델은 확신에 찬 수치적 주장이 권위 있게 들린다는 것을 학습했고, RLHF(인간 피드백 기반 강화학습)는 정확히 그 패턴에 보상을 주었습니다. 해결책은 더 나은 프롬프팅(prompting)이 아닙니다. 애초에 무엇을 수용 가능한 주장으로 간주할 것인가에 대한 구조적 제약(structural constraint)입니다.

AI 에이전트 출력에 적용된 Karl Popper의 반증 가능성(falsifiability) 기준: 반증될 수 없는 주장은 예측이 아니라 서사(narrative)입니다. 중대한 결정을 내리는 에이전트에게 있어, 수용된 모든 주장은 하나의 질문에 답해야 합니다 — 어떤 관찰 가능한 조건 하에서 이 주장이 거짓이 되는가? 답이 없다면, 그 주장은 불확실한 것으로 기록되거나 로그에 남을 수는 있지만, 의사결정의 근거가 될 수는 없습니다.

세 가지 구체적인 규칙

저는 이를 세 가지 강제 가능한 규칙으로 운영하며, 새로운 도메인이 나타날 때마다 매번 다시 논쟁하는 대신 동일한 로직이 재사용될 수 있도록 재사용 가능한 의사결정 단위(RDU-021, 022, 023)로 번호를 매겼습니다.

규칙 1: LLM의 확률 생성 금지

에이전트는 금융, 배포 결정, 기술 도입과 같은 어떠한 중대한 영역(consequential domain)에서도 수치적 확률을 출력할 수 없습니다. 실제로 확률이 필요한 경우, 언어 모델(Language Model)이 아닌 통계 모델(Statistical Model)이 이를 생성해야 하며, 해당 수치는 사용자에게 보여지기 전에 반드시 브라이어 점수(Brier-score) 검증을 통과해야 합니다. LLM의 역할은 숫자를 생성하는 것이 아니라, 그 숫자를 _해석(interpret)_하는 것입니다.

# 차단된 출력
"BTC가 향후 2주 내에 상승할 확률은 70%입니다."

...

규칙 2: 전진 분석 검증(walkforward validation) 필수

모든 정량적 전략이나 모델은 배포 결정에 근접하기 전에 반드시 전진 분석 검증(walkforward validation)을 통과해야 합니다. 즉, 훈련(training)과 검증(validation) 윈도우를 분리하여 유지하고, 진정으로 표본 외(out-of-sample) 미래 데이터로 평가해야 합니다. 인샘플(in-sample) 백테스트(backtest)는 아무리 결과가 좋아 보이더라도 증거가 될 수 없습니다.

규칙 3: 상관관계는 인과관계가 아님을 강제함

동시에 발생하는 사건이라 할지라도 명시적인 인과 식별(causal identification) 없이는 인과적이라고 라벨링할 수 없습니다. 에이전트가 기록하는 모든 관찰 데이터에는 다음 네 가지 라벨 중 하나가 부여됩니다:

반증 프로토콜(The falsifier protocol), 과거 금융 사례의 일반화

제가 이 방식을 적용하는 모든 의사결정 영역에서 동일한 구조가 유지됩니다. 반증 도구(falsifier)에는 정확히 세 가지 요소가 필요합니다. 즉, 관찰 가능한 조건(observable condition), 측정 가능한 임계값(measurable threshold), 그리고 이를 확인할 구체적인 날짜(concrete date)입니다:

falsifier:
  condition: [가설을 무효화하는 관찰 가능한 사건]
  threshold: [모호하지 않은 측정 가능한 값]
...

반증 도구가 없는 가설은 가설이 아니라, 형식이 더 잘 갖춰진 의견일 뿐입니다. 저는 이를 의사결정 전 단계(pre-decision gate)에서 강제합니다. 배포, 투자, 아키텍처 변경과 같이 중대한 영향을 미치는 모든 결정 중 명시적인 반증 도구가 누락된 결정은 어디로도 진행되기 전에 차단됩니다.

공허한 합의 문제(The empty-consensus problem)

멀티 에이전트 의회(multi-agent council)를 운영하면서 제가 완전히 예상하지 못했던 실패 모드(failure mode)가 드러났습니다. 바로 공허한 합의(empty consensus)입니다. 여러 에이전트가 어떤 주장에 대해 만장일치로 동의하지만, 그 주장은 여전히 실제로 검증 불가능한 상태인 경우입니다. 합의는 품질의 신호처럼 느껴졌지만, 대부분 그렇지 않았습니다.

제가 운영하는 8인 페르소나 의회 시스템에서 측정된 지표는 다음과 같습니다:

이 수치들 이면에 숨겨진 발견은 제가 시스템을 구축하는 방식을 바꾸어 놓았습니다. 모델의 다양성(model diversity)은 공허한 합의 문제를 해결하지 못합니다. 의회에 더 많고 다양한 모델을 추가한다고 해서, 검증 불가능한 사항에 대해 에이전트들이 동의하는 빈도가 줄어들지는 않습니다. 이를 해결하는 방법은 검증(verification)입니다. 즉, 의회의 모든 결론이 하중을 견디는(load-bearing) 결정으로 인정받기 전에 공식 엔진(formal engine)을 거치도록 라우팅하는 것입니다.

검증 브리지 (Verification bridges)

돈, 배포, 혹은 제가 실행할 결정과 같이 하중을 견뎌야 하는(load-bearing) 의회의 결론 중 수학적 또는 논리적 주장을 포함하는 경우, 저는 이를 수용하기 전에 검증 브리지를 통해 라우팅합니다:

• 산술적 주장 (Arithmetic claims) → 기호 수학 엔진(symbolic math engine) 또는 계산 지식 엔진(computational knowledge engine)
• 형식 논리 주장 (Formal logic claims) → 정리 증명 언어 서버(theorem-proving language server)
• 경험적 주장 (Empirical claims) → 웹 검색 요약이 아닌, 1차 자료(primary sources)와의 교차 검증

검증 결과는 루프를 닫고 의회가 다음번에 더 잘 보정(calibrate)할 수 있도록 개선하는 결과 보고(outcome-reporting) 단계를 통해 피드백됩니다. 이 피드백을 건너뛰면 보고율은 0에 가깝게 유지됩니다. 제 경우 0.036으로 측정되었는데, 이는 의회가 틀렸을 때 실제로 배우지 못한다는 것을 의미합니다.

진짜 병목 현상은 모델의 품질이 아니라 검증 가능성(verifiability)입니다. 확인이 불가능한 만장일치 의회 결론은 단 하나의 검증된 계산보다 가치가 낮습니다. 저의 공허한 합의 사례 대부분은 분석처럼 들리지만 어떤 ground truth(실제 정답)와도 대조하여 확인할 수 없는 주장들이었습니다.

실제 적용 모습

이 시스템의 최소 버전은 다음 네 단계로 구성됩니다:

1. 모든 의사결정을 하나의 질문으로 검증합니다: 이 결정에는 반증 조건(falsifier condition)이 있는가?
2. LLM의 확률 생성(probability production)을 구조적으로 차단합니다 — 지시문(instruction)을 통해서가 아니라, 출처가 없는 백분율을 포함하는 모든 출력을 가로채는 훅(hook)을 사용하여 차단합니다.
3. 원장(ledger)을 유지합니다: 모든 핵심적인 의사결정을 해당 반증 조건, 평가 날짜, 그리고 최종 결과와 함께 저장합니다.
4. 루프를 닫습니다(Close the loop): 평가 날짜가 도래하면, 실제 현실과 대조하여 반증 조건을 확인하고 원장을 업데이트합니다.

원장(ledger)이야말로 실제로 중요한 부분입니다. 원장이 없다면 반증 조건은 그저 선의에 불과합니다. 즉, 한 번 언급된 이후 다시는 확인되지 않는 조건이 되어버립니다. 이 모든 과정의 핵심은 확신에 찬 것처럼 들리는 주장들을 더 이상 신뢰하지 않는 것입니다. 아무도 다시 검토하지 않는 반증 조건은, 바로 그런 종류의 주장이 변장을 하고 있는 것과 다름없습니다.

추가 노트는 hexisteme.github.io/notes에서 확인할 수 있습니다.