초다중검토 — 멀티 모델 심의 시스템 설계

문제: 하나의 모델은 하나의 관점만 갖는다

AI 모델에게 "이 구조 어때?"라고 물으면 대체로 괜찮은 답을 준다. 문제는 그 답이 그 모델의 학습 편향 안에서만 괜찮다는 것이다.

코딩에 강한 모델은 기술적 완성도에 집중하고, 범용 모델은 비즈니스 관점을 더 고려한다. 추론에 특화된 모델은 구조적 리스크를 잘 잡지만, 사용자 경험은 놓치기 쉽다.

하나의 모델에게 "다른 관점도 고려해줘"라고 프롬프트를 바꿔봐야, 결국 같은 모델의 같은 편향 안에서 돌아간다. 이걸 구조적으로 해결하고 싶었다.

핵심 아이디어: 서로 다른 모델이 서로를 비판하게 하자

코드 리뷰에서 작성자 본인이 리뷰하면 빈틈을 못 잡듯이, AI도 자기 출력을 자기가 검증하면 한계가 있다. 다른 학습 배경을 가진 모델이 교차 검증해야 실질적인 빈틈이 드러난다.

이 원리를 시스템으로 만든 것이 초다중검토(Hybrid Audit)다.

사용 모델과 역할 배정

OpenClaw에 연결된 Ollama Cloud 모델 풀에서, 각 모델의 특성에 맞게 역할을 배정했다.

역할	모델	선택 이유
기술·구현 관점	kimi-k2.6:cloud	에이전틱 성능이 높고, 코딩/기획 태스크에 가장 안정적
비즈니스·사용자 관점	qwen3.5:latest	한국어 품질이 좋고, 범용적 시각으로 사용자 측면을 잘 짚음
구조·리스크 관점	deepseek-v4-pro	1M 토큰 컨텍스트 + 깊은 추론. 구조적 허점 분석에 강함

핵심은 **"잘하는 모델 3개"가 아니라 "서로 다른 강점을 가진 모델 3개"**라는 점이다. 같은 성향의 모델을 3개 돌리면 같은 방향의 답이 3개 나올 뿐이다.

3단계 심의 프로세스

Stage 1 — 관점별 초안 생성

동일한 주제를 3개 모델에게 각각 다른 관점에서 분석하도록 요청한다.

[입력] "이 프로젝트 구조를 개선하려면?"

→ kimi-k2.6:cloud  — 기술적 구현 난이도, 코드 복잡도, 유지보수성
→ qwen3.5:latest   — 사용자 영향, 비즈니스 가치, 우선순위
→ deepseek-v4-pro  — 아키텍처 리스크, 의존성 문제, 확장성

여기서 중요한 제약이 하나 있다. Ollama Cloud Pro는 동시 실행 3개까지만 허용한다. Max 요금제는 최대 10개를 지원하지만, 시스템을 처음 설계하고 검증하는 단계에서 바로 상위 플랜을 쓸 이유가 없었다. 일단 Pro로 구조를 잡고, 병목이 확인되면 올리는 게 맞다고 판단했다.

Pro 기준으로 OpenClaw Gateway가 메인으로 하나를 쓰고 있으므로, 서브에이전트는 1개씩 순차 spawn해야 한다.

메인(kimi) + sub-1(qwen) → sub-1 완료 → sub-2(deepseek) 시작

병렬로 3개를 동시에 돌릴 수 없다. 속도는 느리지만, 동시 실행 제한을 넘기면 세션이 죽기 때문에 안정성을 우선했다. Max로 올리면 3개 병렬 spawn이 가능해지므로 Stage 1 소요 시간이 1/3로 줄어들 것으로 예상한다.

Stage 2 — 교차 비판

각 모델이 다른 모델의 초안을 비판한다. 자기 초안이 아니라 남의 초안을 읽고 허점을 지적하는 단계다.

kimi  → qwen 초안 비판 + deepseek 초안 비판
qwen  → kimi 초안 비판 + deepseek 초안 비판
deepseek → kimi 초안 비판 + qwen 초안 비판

이 단계에서 실제로 발견되는 것들:

"기술적으로는 가능하지만 사용자에게 혼란을 줄 수 있다" (kimi의 기술 중심 제안에 대한 qwen의 비판)
"비즈니스 가치는 높지만 현재 구조에서 의존성 충돌이 생긴다" (qwen의 제안에 대한 deepseek의 비판)
"구조적으로는 깔끔하지만 구현 비용 대비 효과가 낮다" (deepseek의 제안에 대한 kimi의 비판)

이 비판들을 모아 **수렴 리포트(convergence report)**를 생성한다. 3개 모델이 공통으로 동의하는 부분, 의견이 갈리는 부분, 한 모델만 지적한 부분으로 분류된다.

Stage 3 — 합의 검증

수렴 리포트를 기반으로 최종 합의도를 측정한다.

합의도 ≥ 80%  → 최종 결과 확정 [AUDIT-DONE]
합의도 < 80%  → 재시도 (최대 3회)
3회 실패      → 사람이 직접 판단 [AUDIT-HUMAN]

80%라는 기준은 실험적으로 정한 값이다. 너무 높으면 (90%+) 거의 모든 심의가 실패하고, 너무 낮으면 (60%) 의미 있는 의견 차이가 묻힌다.

3회 재시도해도 합의가 안 되면 [AUDIT-HUMAN] 태그와 함께 사람에게 넘긴다. **"AI가 결론 못 내린 문제"**라는 것 자체가 유의미한 신호다 — 그만큼 관점 차이가 크다는 뜻이니까.

실제 운영에서의 제약과 트레이드오프

속도

솔직히 느리다. 순차 spawn 때문에 Stage 1만 해도 모델 2개를 순서대로 돌려야 하고, Stage 2에서 또 순차로 비판을 생성한다. 전체 프로세스에 수 분이 걸린다.

그래서 모든 작업에 쓰지 않는다. 일반적인 코딩이나 문서 작성은 메인 모델 하나로 충분하다. 초다중검토는 기획 방향 결정, 아키텍처 설계, 중요한 구조 변경처럼 되돌리기 어려운 의사결정에만 사용한다.

비용

3개 모델을 순차로 돌리고, 교차 비판까지 하면 토큰 사용량이 단일 모델의 6~8배다. Ollama Cloud 기준으로 부담이 되는 수준은 아니지만, 무분별하게 쓰면 누적된다.

합의 실패

합의도 80%에 도달하지 못하는 경우가 생각보다 있다. 특히 "정답이 없는 기획 문제"에서 모델 간 관점 차이가 크다. 이때 [AUDIT-HUMAN]으로 넘어오면, 수렴 리포트에 각 모델의 의견이 정리되어 있어서 사람이 판단하기에도 더 수월하다.

메모리 시스템과의 연동

초다중검토 결과는 메모리 시스템과 연결된다.

심의 결과 중 반복 패턴이 발견되면 → corrections에 자동 기록
3회 이상 동일 패턴 → HOT 메모리 승격 후보
[AUDIT-HUMAN]으로 사람이 판단한 결과 → 향후 유사 심의의 참고 데이터

결국 초다중검토를 반복할수록 메모리에 패턴이 축적되고, 다음 심의 때 이전 판단을 참고할 수 있게 된다.

이 시스템이 아니었으면

단일 모델로 작업하던 시절과 비교하면 가장 큰 차이는 "내가 생각 못한 관점"의 발견이다.

혼자 기획하면 자기가 중요하다고 생각하는 것에 집중한다. 하나의 모델에게 물어봐도 마찬가지다. 그런데 서로 다른 모델이 교차 비판하면, "아 이건 고려 안 했네"라는 지점이 거의 매번 나온다.

이건 프롬프트 엔지니어링으로는 해결이 안 된다. 구조가 만들어내는 효과다.

설계하면서 배운 것

편향 제거는 프롬프트가 아니라 구조의 문제다 — "다양한 관점에서 분석해줘"라고 아무리 써봐야, 한 모델의 편향 안에서 돈다. 실제로 다른 모델을 붙여야 관점이 바뀐다.
느린 게 맞는 경우가 있다 — 순차 spawn, 교차 비판, 합의 검증까지 수 분이 걸린다. 하지만 되돌리기 어려운 결정에서 5분 투자로 빈틈을 잡는 건 충분히 가치 있다.
합의 실패도 가치 있는 결과다 — 3개 모델이 합의 못 한다는 건, 그 문제가 관점에 따라 답이 달라진다는 뜻이다. 그 자체가 사람에게 "이건 신중하게 판단해야 한다"는 신호가 된다.