한 모델만 믿지 마라: 멀티모델 심의로 결정을 검증하기

AI 모델에게 "이 설계 어때?"라고 물으면 대체로 그럴듯한 답이 돌아온다. 문제는 그 답이 정말 맞아서가 아니라, 내가 듣고 싶어 할 만한 말이라서 그럴듯할 때가 많다는 것이다. 특히 내가 한 방향으로 강하게 밀면 모델은 슬그머니 거기에 동의해 버린다. 혼자 묻고 혼자 답을 받는 구조에서는 이 편향이 걸러지지 않는다.

이 글은 그 단일 모델 편향을 거르기 위한 가벼운 패턴 — 여러 모델로 같은 결정을 교차 검증하는 심의(deliberate) 프로토콜을 정리한 노트다. 거창한 합의 시스템이 아니라, 결정을 내리기 전에 한 라운드 더 의심해 보는 절차에 가깝다.

한 모델만 쓰면 네 가지 방식으로 기운다

한 모델에게만 결정을 맡길 때 생기는 문제는 매번 비슷한 모양이다.

• 사용자 선호에 과적합(overfit, 특정 입력에만 맞추느라 일반적 타당성을 잃는 것) — 내가 어떤 답을 원하는지 대화 맥락에서 읽어내고, 그 방향으로 기운 답을 준다.
• 트레이드오프 누락 — 한 선택지의 장점만 보고, 그게 무엇을 포기하는 결정인지는 짚지 않은 채 넘어간다.
• 조기 수렴(convergence, 여러 후보를 충분히 따져보기 전에 한 답으로 굳는 것) — 처음 떠올린 답에 일찍 정착해, 더 나은 선택지를 탐색하지 않는다.
• 비위 맞추기(sycophancy) — 사용자가 강하게 주장하면, 그 주장이 약하더라도 정면으로 반박하기보다 동의하는 쪽으로 기운다.

이 넷은 서로 다른 증상처럼 보이지만 뿌리는 하나다. 한 모델 안에서 묻고 답하면, 그 모델의 맹점을 그 모델 자신이 검사하게 된다는 것. 자기 약점을 자기가 채점하는 구조에서는 편향이 드러날 자리가 없다. 답이 그럴듯할수록 오히려 의심하기 어려워진다.

모든 결정에 쓰는 게 아니라, 트레이드오프가 무거운 결정에만 쓴다

이 패턴은 만능이 아니고, 모든 결정에 두를 도구도 아니다. 답이 사실상 정해진 일, 한 번 보면 되는 구현 작업에 멀티모델 심의를 붙이는 건 과하다. 코드 한 줄을 어떻게 쓸지 두 모델에게 묻고 비교 메모를 쓰는 건 시간 낭비다.

쓰는 게 맞는 자리는 틀렸을 때 비용이 크고, 정답이 하나로 떨어지지 않는 결정이다.

• 아키텍처 선택 — 어느 구조로 갈지가 이후 작업 전체를 좌우할 때
• 프로토콜·설계 — 한 번 정하면 되돌리기 어려운 규칙을 세울 때
• 네이밍·패키징 결정 — 겉보기엔 사소해도 나중에 바꾸기 비싼 이름·구조를 정할 때
• 계획 검토 — 세워둔 계획에 빠진 단계나 잘못된 가정이 없는지 볼 때
• 리스크 검토 — 무엇이 실패할 수 있는지 미리 끌어낼 때
• "이 아이디어가 정말 말이 되나" 점검 — 방향 자체가 일관적인지 의심할 때

기준은 단순하다. 틀렸을 때 한 모델의 편향이 그대로 결정에 박혀버릴 일이라면, 한 번 더 다른 눈으로 본다. 그렇지 않은 뻔한 작업에는 쓰지 않는다.

기본 루프: 압축하고, 따로 묻고, 비교하고, 멈춘다

심의의 뼈대는 단순한 루프 하나다. 지휘하는 에이전트(orchestrator)가 전체를 운전하고, 각 모델은 한 라운드씩 의견을 낸다.

1. 지휘 에이전트가 맥락을 압축한다. 무엇을 결정하려는지, 이미 아는 것은 무엇인지, 제약과 이미 기각한 선택지는 무엇인지를 짧게 정리한다. 긴 대화 기록을 통째로 넘기는 게 아니라, 결정에 필요한 핵심만 추려 전달한다.
2. 모델 A에게 묻는다.
3. 모델 B에게 (같은 압축된 맥락으로) 묻는다.
4. 동의점과 불일치점을 비교한다. 두 모델이 똑같이 미는 추천은 신뢰도가 높고, 갈리는 지점은 진짜로 따져봐야 할 자리다.
5. 필요하면 후속 라운드를 한 번 더 돌린다. 불일치가 남았으면, 그 불일치를 명시해 다시 묻는다.
6. 결정 메모(decision memo)를 쓴다.

이 루프에서 진짜 일이 일어나는 자리는 4번, 비교다. 두 모델이 합의하는 부분은 그냥 통과시키고, 갈리는 부분에만 집중한다. 한 모델은 A를 강하게 밀고 다른 모델은 그 A가 무엇을 포기하는 결정인지 짚는다면, 거기가 바로 단일 모델로는 보이지 않던 트레이드오프다.

각 라운드에서 던지는 네 질문

심의의 효과는 "어떻게 묻느냐"에 크게 달려 있다. 그냥 "이거 어때?"라고 열어두면 모델은 또 비위를 맞추기 쉽다. 그래서 각 라운드는 압축된 맥락과 함께 고정된 네 질문을 던진다.

먼저 맥락을 준다 — 무엇을 결정하는가 / 이미 아는 것 / 제약 / (있다면) 이미 기각한 선택. 그다음 네 질문이다.

1. 가장 강한 추천은 무엇인가? — 모델이 미는 답을 명시적으로 끌어낸다.
2. 무엇이 실패할 수 있나? — 추천의 약점과 실패 시나리오를 강제로 꺼내게 한다. 이 질문이 빠지면 모델은 장점만 말하고 끝낸다.
3. 과소평가된 선택지는 무엇인가? — 조기 수렴을 깨는 질문이다. 지금 테이블에 오르지 못한, 그러나 따져볼 만한 대안을 끌어낸다.
4. 모델이 아니라 사용자가 결정해야 할 것은 무엇인가? — 가치 판단·취향·사업 맥락처럼 모델이 대신 정하면 안 되는 부분을 분리한다.

네 질문이 노리는 건 각각 다르다. 1·2번은 추천과 그 추천의 약점을 함께 세우고, 3번은 너무 일찍 좁혀진 선택지를 다시 벌리고, 4번은 모델이 넘봐선 안 되는 영역을 선 긋는다. 특히 4번은 sycophancy의 반대 방향 장치다 — 모델이 "이건 제가 정할 게 아니라 당신이 정해야 합니다"라고 말하게 만들면, 모델이 사용자 선호를 멋대로 떠받드는 일이 줄어든다.

언제 멈추고, 무엇을 남기나

라운드를 무한정 돌리면 같은 논증만 반복되고 시간만 든다. 그래서 멈추는 규칙을 미리 정해 둔다. 다음 중 하나라도 해당하면 멈춘다.

• 답이 수렴할 때 — 모델들이 같은 결론으로 모이면 더 돌릴 이유가 없다.
• 남은 게 가치 판단일 때 — 사실 다툼이 아니라 취향·우선순위 문제로 좁혀지면, 그건 모델이 아니라 사람이 정할 자리다.
• 다음 라운드가 이전 논증을 반복할 때 — 새 정보 없이 같은 말이 돈다면 멈춘다.
• 최대 라운드에 도달했을 때 — 무한 루프를 막는 안전장치다.

멈춘 뒤에는 결정 메모를 남긴다. 결정만 적는 게 아니라, 그 결정에 이르는 길과 버린 길을 함께 적는다.

• 결정 — 무엇을 하기로 했는가
• 근거 — 왜 그렇게 정했는가
• 기각한 선택 — 무엇을 왜 버렸는가
• 열린 질문 — 아직 답하지 못한 것
• 후속 작업 — 다음에 해야 할 일
• 모델 불일치 노트 — 모델들이 어디서 갈렸는가

마지막 항목이 이 메모를 단순한 결론 기록과 갈라놓는다. 불일치를 지우지 않고 남기는 것이 핵심이다. 두 모델이 갈렸던 지점은 나중에 결정이 흔들릴 때 가장 먼저 다시 봐야 할 자리이기 때문이다. 합의된 것만 적으면, 정작 위험했던 부분의 기록이 사라진다.

자동화는 얇게 — 가치는 다른 데 있다

이 패턴은 거창한 인프라가 필요 없다. 모델 사이로 프롬프트를 손으로 복사해 옮겨도 그대로 작동하고, 로컬 CLI로 라운드를 자동화해도 된다. 어느 쪽이든 결과는 같은 결정 메모다.

중요한 건 자동화를 얇게 유지하는 것이다. 화려한 오케스트레이션 코드를 짜는 데 공을 들일수록, 정작 가치 있는 부분에서 멀어진다. 이 프로토콜에서 실제로 효과를 내는 건 세 가지뿐이다.

• 맥락 압축 — 결정에 필요한 핵심만 추려 모델에 넘기는 일
• 불일치 추적 — 모델들이 어디서 갈렸는지 놓치지 않고 따라가는 일
• 멈추는 규칙 — 충분히 봤을 때 깔끔하게 끝내는 일

자동화는 이 셋을 거들 뿐, 대신하지 못한다. 프롬프트를 옮기는 손품을 줄여줄 수는 있어도, 무엇을 압축하고 어디서 갈렸는지 판단하는 건 여전히 지휘 에이전트의 몫이다.

직접 굴려본 자리

이건 책상 위 이론만은 아니다. 이 블로그를 운영하면서 트레이드오프가 무거운 결정 — 예를 들어 어떤 워크플로우 패턴을 시리즈로 묶을지, 설계를 어느 쪽으로 가져갈지 — 을 정할 때 실제로 이 심의를 돌린다. 그것도 서로 다른 모델 가족으로 돌린다. 메인 에이전트는 Claude, 두 번째 의견은 Codex(GPT 계열), 세 번째는 Antigravity(Gemini 계열)다.

같은 모델 가족 여럿을 붙이지 않고 굳이 다른 가족을 섞는 데는 이유가 있다. 같은 가족은 학습 데이터와 성향이 비슷해 맹점도 비슷하게 공유한다 — 한 모델이 놓친 걸 다른 모델도 똑같이 놓친다. 서로 다른 가족을 붙이면, 한 가족의 맹점을 다른 가족이 공격하게 만들 수 있다. 합의가 나오면 그건 가족을 가로지른 합의라 더 믿을 만하고, 갈리면 그 갈린 자리가 진짜로 따져봐야 할 지점이다.

성능이 얼마나 좋아진다거나 하는 수치를 들이밀 생각은 없다. 다만 혼자 묻고 혼자 답할 때보다, 내가 강하게 밀던 약한 주장이 한 번 더 걸리는 경험은 분명히 있다.

이 패턴은 한곳에 정리해 공개 저장소로 묶어 두었다. 출처 기반 리서치, AI용 프로젝트 문서, 파일 기반 프로젝트 기억 같은 다른 프로토콜과 함께, 이 멀티모델 심의도 설치할 것 없는 순수 파일 규칙으로 들어 있다.

저장소: github.com/aminpiano/agentic-workflows

정리

한 모델에게만 결정을 맡기면 사용자 선호에 과적합하고, 트레이드오프를 놓치고, 너무 일찍 수렴하고, 강하게 밀면 비위를 맞춘다. 이 단일 모델 편향은 같은 모델 안에서는 걸러지지 않는다. 멀티모델 심의는 그 편향을 다른 모델의 눈으로 거르는 가벼운 절차다 — 맥락을 압축해 여러 모델에게 같은 결정을 묻고, 네 질문으로 추천·약점·대안·사용자 몫을 끌어내고, 동의점과 불일치점을 비교하고, 멈추는 규칙에 따라 끝낸 뒤 불일치까지 남긴 결정 메모를 쓴다. 자동화는 얇게, 무게는 압축·불일치 추적·멈춤에 둔다. 트레이드오프가 무거운 결정에만 쓰고, 뻔한 작업에는 쓰지 않는다.