모델을 하나 더 붙이면 답이 정확해질까 — AI 자문 구조를 어떤 업무에 쓸지 정하는 기준

들어가며

AI에게 "이번 달 운영계획을 짜줘"라고 시켜 본 적 있으신가요? 표가 반듯하게 채워져서 돌아옵니다. 숫자도 붙어 있고, 근거처럼 보이는 문장도 달려 있습니다. 그런데 그 계획대로 실제 현금을 쓰려는 순간 손이 멈춥니다. 이 숫자가 맞는지 확인할 방법이 없기 때문입니다.

그래서 많은 분이 떠올리는 해법이 "모델을 하나 더 쓰자"입니다. ChatGPT에도 물어보고 Claude에도 물어보고, 돌아온 답 세 통을 나란히 놓고 비교하는 방식입니다. 문제는 그 비교를 사람이 한다는 것입니다. 확인해야 할 일이 오히려 하나 더 늘어납니다.

이걸 사람이 아니라 구조로 처리하는 방식이 **MoA(Mixture of Agents)**입니다. 여러 모델이 먼저 의견만 내고, 그중 한 모델이 그 의견들을 받아 최종 답을 쓰고 도구를 실행합니다.

이 글에서는 같은 과제 하나를 다섯 가지 구성으로 두 번씩 돌려 비교한 결과를 정리했습니다. 결론부터 말씀드리면, 이 비교에서는 숫자 정확도가 오르지 않았습니다. 대신 다른 것이 올랐습니다. 그 차이를 읽는 법과, 어떤 업무에 이 구조를 붙일지 정하는 기준도 함께 다룹니다.

모델을 여러 개 쓰는 두 가지 방식은 다릅니다

먼저 자주 섞여 쓰이는 두 개념을 갈라둡니다. 모델 라우팅과 MoA는 이름만 비슷하고 하는 일이 다릅니다.

라우팅은 비용을 아끼려고만 쓰는 개념이 아닙니다. 정확도, 속도, 도구 사용 능력, 긴 문서 처리 능력이 모두 선택 기준이 될 수 있습니다. 반면 MoA는 호출을 줄이는 쪽이 아니라 늘리는 쪽입니다. 그래서 아무 업무에나 켜 두는 설정이 아닙니다.

두 자리는 권한이 다릅니다

MoA 안에서 모델이 앉는 자리는 두 개입니다. 이 둘의 권한 차이가 이 구조의 전부라고 해도 됩니다.

Hermes Agent 공식 문서는 자문 모델이 "대화의 사용자·어시스턴트 텍스트만 받으며, 시스템 프롬프트나 도구 호출 기록은 받지 않는다"고 명시합니다. 공식 문서 기준으로 단정할 수 있는 것은 여기까지입니다. 자문 모델은 시스템 프롬프트와 도구 목록을 받지 못하고, 파일을 직접 열어보지도 못합니다. 파일 확인과 도구 실행은 최종 답을 쓰는 모델이 담당합니다. 자문을 다시 부르는 주기를 어떻게 잡느냐에 따라 그때까지의 진행 내용이 대화 텍스트로 자문 쪽에 함께 넘어갈 수는 있습니다.

💡 MoA는 특정 제품만의 발명이 아닙니다. 여러 모델이 먼저 응답을 내고 다음 단계가 그것을 참고해 종합하는 구조는 2024년 논문 「Mixture-of-Agents Enhances Large Language Model Capabilities」에서 제안된 방법론입니다. 논문이 보고한 수치는 오픈소스 모델만 조합해 AlpacaEval 2.0에서 65.1%, GPT-4 Omni는 57.5%였습니다. 그 벤치마크 하나에서 나온 값입니다. 아이디어의 출처는 분명하지만, 내 업무에서 무엇이 좋아지는지는 별개의 질문입니다.

자문을 붙이면 숫자가 더 정확해질까

이 질문을 확인하려고 같은 과제를 다섯 구성으로 돌렸습니다.

과제는 가상의 소규모 커피 브랜드 30일 운영계획입니다. 매출은 늘었는데 현금과 공헌이익은 나빠진 상황이고, 그 진단은 모델에게 알려주지 않았습니다. 모델이 받은 것은 원자료 CSV 7종과 지켜야 할 제약, 계산 정의, 출력 서식까지 파일 11개뿐입니다. 전부 합성 데이터이며 실제 고객 데이터가 아닙니다.

다섯 구성은 이렇습니다. 모델을 1등부터 5등까지 줄 세우는 실험이 아니라, 같은 모델을 다른 자리에 앉히면 결과가 어떻게 달라지는지를 보는 실험입니다.

각 구성을 2회씩, 총 10종의 결과물을 사람이 채점했습니다. 지시문, 입력 자료, 출력 형식은 글자 하나 바꾸지 않고 동일하게 넣었습니다. 고정한 범위는 여기까지입니다. 회차 사이의 실행 설정까지 같았다고는 보증하지 않으며, 그래서 점수 차이를 설정 탓으로 해석하지 않았습니다.

통합 결과

여기까지만 보면 "자문을 붙이니 점수가 올랐다"로 읽힙니다. 그런데 상위 3종은 평균이 2.5점 안(91.5 / 91.0 / 89.0)에 몰려 있습니다. 순위가 아니라 한 덩어리로 읽어야 하는 간격입니다.

어느 축에서 올랐는지가 중요합니다

같은 회차끼리 자문 구성과 최종 작성자 단독(GPT)을 축별로 대조했습니다. 여기가 이 실험의 핵심입니다.

차이가 보이나요? 이번 테스트에서 자문을 붙여 달라진 것은 정확도가 아니라 관점이었습니다. 숫자가 더 맞아떨어지길 기대하고 자문을 붙이면, 이 데이터 기준으로는 기대가 어긋납니다.

총점만 봐도 같은 함정이 있습니다. 2회차 총점 차이는 자문 1명 +3점, 자문 2명 +4점이었습니다. 그런데 그중 3점은 자문이 잘해서가 아니라 GPT 쪽 형식 실수 때문이었습니다. 요약란에 들어가면 안 되는 내부 경로 한 줄이 섞여 감점됐습니다. 이 3점을 빼면 실질 우위는 자문 1명 0점, 자문 2명 +1점입니다.

총점 차이를 그대로 효과로 읽으면 과대평가됩니다. 이번 비교에서도 총점만 봤다면 +3점, +4점을 자문의 성과로 적었을 겁니다. 점수가 어느 항목에서 왜 갈렸는지까지 열어봐야 실제로 무엇이 좋아졌는지 알 수 있습니다.

자문이 더해준 것과 지워준 것

그렇다면 "관점이 늘었다"는 게 실제로 무엇이었을까요. 결과물 10종을 대조해 세 가지를 확인했습니다. 판정 기준은 셋 다 만족하는 경우로 뒀습니다. 최종 작성자 단독 두 회차 모두에 없고, 자문 구성 결과물에는 있고, 그 자문 모델의 단독 결과물에도 있을 것.

세 번째는 실제 업무 데이터에서도 그대로 나올 수 있는 유형입니다. 빈칸은 0이 아니라 아직 관측되지 않았다는 뜻입니다. 이걸 0으로 계산하면 팔리는 상품을 재고에서 빼버리는 결정이 나옵니다.

더 큰 기여는 걸러내기였습니다

자문 모델들을 단독으로 썼을 때는 결함이 있었습니다. Kimi 단독 2회차는 확정된 작업 시간을 자기 계획의 사용 칸에 그대로 옮겨 적어 주차 한도를 넘겼습니다. DeepSeek 단독은 두 회차 모두 아직 들어오지 않은 예상 입금을 현금표에 섞었습니다. 그래서 실제 여유가 10만 원인데 안전하다고 판정했습니다.

그런데 이 결함들은 자문 구성의 최종 결과물로 넘어가지 않았습니다. 자문이 붙은 4종은 전부 중대 규칙 위반 0건이었습니다. 관점은 통과했고 규칙 위반은 통과하지 못했습니다. 이번 비교에서 최종 작성자가 실제로 한 일은 합치기보다 걸러내기에 가까웠습니다.

대신 잃은 것도 있습니다. 자문 1명 구성은 두 회차 모두 선물상자 90개 판매 상한을 놓쳤습니다. GPT 혼자였으면 두 회차 다 잡았을 항목입니다. 자문을 붙인다고 순증만 생기지는 않습니다.

⚠ 여기는 인과가 아니라 일치 패턴입니다. 자문 모델이 실제로 뭐라고 답했는지 원문을 저장하지 않았습니다. 그래서 "자문이 이걸 알려줬다"가 아니라 **"자문이 있는 구성에서만 반복해서 나타났다"**까지가 정확한 표현입니다. 직접 실험하실 때는 자문 응답 원문도 함께 저장해 두시면 이 확인까지 하실 수 있습니다.

평균보다 편차를 먼저 보십시오

이 실험에서 가장 실무적인 발견은 점수 순위가 아니었습니다. 같은 구성을 두 번 돌렸을 때 벌어진 간격이었습니다.

단독 오픈웨이트 두 구성에서 걸린 것은 평균이 낮다는 점이 아니었습니다. 두 번 돌린 결과의 품질이 크게 달랐다는 점입니다. 업무에 배치하는 관점에서 "평균 72점"과 "63점에서 81점 사이 어딘가"는 완전히 다른 정보입니다. 앞은 계획을 세울 수 있고, 뒤는 매번 사람이 전부 다시 읽어야 합니다.

그리고 이 간격은 한 번만 돌려서는 보이지 않습니다. 한 번 잘 나온 결과를 보고 "이 모델 괜찮네"라고 판단하는 순간이 가장 위험합니다.

💡 MoA를 쓰지 않더라도 오늘 바로 하실 수 있는 확인이 하나 있습니다. 업무에 쓸 프롬프트를 같은 조건으로 두 번 돌려보고 결과를 나란히 놓는 것입니다. 두 결과가 크게 다르면, 그 작업은 아직 사람이 매번 검토해야 하는 단계입니다. 두 결과가 비슷하면 검토 범위를 줄여도 됩니다. 비용이 거의 들지 않는 확인법입니다.

오픈웨이트 모델은 어디에 앉히면 좋을까

이번 실험에서 자문 자리에 앉힌 Kimi K3는 오픈웨이트로 공개된 모델입니다. 2026년 7월 말에 가중치가 공개됐습니다. 여기서 흔한 오해 두 가지를 먼저 정리합니다.

첫째, 오픈웨이트라고 내 PC에서 돌릴 수 있는 것은 아닙니다. 공식 자료 기준으로 Kimi K3는 총 2.8조 파라미터(활성 1,040억) 규모이고, 공식 블로그는 "가속기 64장 이상의 슈퍼노드 구성"을 권장 배포 환경으로 안내합니다. 사실상 데이터센터급 구성입니다. 공식 저장소의 파일 보관 용량은 확인 시점 기준 약 1.561TB였는데, 이건 파일을 받아 두는 용량이지 실행에 필요한 메모리가 아닙니다.

둘째, 오픈웨이트라고 저렴한 것도 아닙니다. 가중치를 공개했다는 것과 API 호출 단가는 별개입니다. 아래는 2026년 8월 초에 공식 블로그와 OpenRouter 모델 페이지에서 확인한 값입니다.

공식 캐시 미적중 단가와 OpenRouter 단가가 같은 자릿수입니다. 가중치를 공개했다고 해서 호출 단가가 내려가지는 않습니다. 단가는 수시로 바뀌니 쓰기 전에 각 페이지에서 다시 확인하십시오.

성능 위치도 공식 자료가 직접 밝히고 있습니다. Kimi K3 공식 블로그는 **"종합 성능은 여전히 가장 강력한 상용 모델인 Claude Fable 5와 GPT-5.6 Sol에 미치지 못한다"**고 적었습니다. 다만 코딩 계열 벤치마크 일부에서는 경쟁력 있는 결과를 보였습니다.

공식 자료의 이 서술과 이번 결과를 같이 놓으면 자리 배치가 보입니다. 이번 비교에서는, 잘하는 구간이 뾰족하지만 규칙 준수가 흔들린 모델을 최종 작성자가 아니라 의견을 내는 자리에 두었을 때 결과가 더 안정적이었습니다. 각 모델이 잘 본 것은 이렇게 갈렸습니다.

점수 순위가 아니라 이 성향 차이가 자리를 정한 근거입니다.

내 업무에 붙일지 정하는 기준

여기까지 정리하면 판단은 단순해집니다. 이 비교 결과만 놓고 보면, 기본값은 강한 단독 모델 하나이고 자문 구조는 특정 판단에만 얹어보는 쪽입니다.

처음 시험할 때의 순서

1. API 키에 지출 상한을 먼저 겁니다. 자문 구조는 호출 수가 늘어나는 방향입니다. OpenRouter를 쓴다면 키 단위로 상한을 걸고 일·주·월 단위로 리셋되게 설정할 수 있습니다. 처음에는 $10 정도로 낮게 잡고 시작하는 편이 안전합니다.
2. 세션 전체를 바꾸지 말고 한 턴만 돌려봅니다. Hermes에서는 /moa <프롬프트> 로 그 한 턴만 자문 구성으로 실행하고, 끝나면 원래 쓰던 모델로 돌아옵니다.
3. 같은 프롬프트를 단독 모델로도 돌려 나란히 놓습니다. 비교 대상 없이 자문 결과만 보면 좋아졌는지 알 수 없습니다.
4. 각각 2회씩 돌립니다. 편차를 보는 것이 이 확인의 핵심입니다.
5. 결과 본문을 구성별로 파일에 저장합니다. 저장하지 않으면 회차 비교 자체가 불가능합니다.

프롬프트에 넣으면 검증이 가능해지는 세 가지

모델을 바꾸는 것보다 결과 품질을 더 크게 바꾼 것은 요청하는 방식이었습니다. 이번 지시문에서 검증 가능성을 만든 부분은 셋입니다.

• 숫자마다 근거 파일명과 행 번호를 함께 적게 합니다. 사람이 되짚어 확인할 수 있게 됩니다. 근거가 없는 숫자가 가장 먼저 무너집니다.
• 직접 계산한 값과 가정으로 추정한 값을 나눠 표기하게 합니다. 추정을 계산인 척 섞으면 확인이 불가능해집니다.
• 계획을 멈춰야 하는 조건을 같이 내게 합니다. "2주차 잔여 현금이 최소 버퍼 아래로 내려가면 중단"처럼 임계값을 요구하면, 결과를 사람이 감독하기 훨씬 쉬워집니다.

받은 결과에서 사람이 확인할 것

자문을 붙였다고 확인이 끝난 것은 아닙니다. 이번 실험에서 점수가 갈린 지점이 그대로 확인 항목이 됩니다.

• 모든 숫자에 근거 파일명과 행 번호가 붙어 있다
• 계산값과 추정값이 나뉘어 있고, 가정이 따로 적혀 있다
• 시간·현금·수량 한도를 계획의 사용량과 직접 대조했다
• 계산 규칙이 금지한 항목이 표에 섞이지 않았다
• 데이터가 없는 항목을 0이 아니라 "미확인"으로 처리했다
• 같은 구성을 2회 이상 돌리고 회차별 결과를 따로 저장했다

🎯 한 가지는 구조와 무관하게 사람 몫으로 남겨두시는 편이 좋습니다. 자문 구조에서 도구를 실제로 실행하는 것은 최종 작성자 모델입니다. 발송, 삭제, 결제, 권한 변경처럼 되돌리기 어려운 작업은 마지막 버튼을 사람이 직접 누르십시오. 실험·데모를 돌릴 때도 합성 데이터로 시작하시고, API 키나 고객 정보는 프롬프트와 입력 자료 어디에도 넣지 않는 편이 낫습니다.

마무리

이 글에서 다룬 핵심을 정리합니다.

• 이번 비교에서 자문 구조의 이득은 정확도가 아니라 관점에서 나왔습니다. 정확도 축에서 앞선 회차는 0회, 전략 축에서는 4회 중 3회였습니다. 숫자가 더 맞기를 기대하고 붙이면 기대가 어긋납니다.
• 이번 비교에서 최종 작성자의 실제 역할은 합치기보다 걸러내기였습니다. 자문 모델들이 단독일 때 냈던 규칙 위반은 최종 결과물로 넘어가지 않았습니다. 다만 혼자였으면 잡았을 항목을 놓친 경우도 있었습니다.
• 평균보다 편차를 먼저 보십시오. 같은 모델이 회차마다 18점·32점씩 벌어졌습니다. 이건 한 번만 돌려서는 보이지 않습니다.
• 총점 하나로 판단하지 마십시오. 2회차 총점 차이 중 3점은 자문의 성과가 아니라 형식 실수 때문이었습니다.

이번 결과는 합성 사례 1건, 구성별 2회 범위 안에서만 유효합니다. 모델의 일반적인 성능 순위가 아니고, 문서 요약이나 코드 작성처럼 성격이 다른 과제에서 같은 순서가 나온다는 보장도 없습니다. 시간·토큰·비용은 이번 실험에서 재지 않았습니다. 호출 구조상 늘어나는 방향이라는 것까지만 말씀드릴 수 있습니다.

오늘 해보실 수 있는 것 하나를 남깁니다. 지금 업무에 쓰고 계신 프롬프트 중 가장 중요한 것 하나를 골라, 같은 조건으로 두 번 돌려 결과를 나란히 놓아 보십시오. 두 결과의 간격이 그 작업을 AI에게 어디까지 맡겨도 되는지 알려줍니다. 자문 구조를 붙일지는 그다음에 정해도 늦지 않습니다.

참고 자료 및 출처

본문의 점수와 관측은 자체 실험에서 나온 값입니다. 합성 데이터로 만든 과제 1건을 구성별 2회씩 돌려 사람이 채점했습니다.

설정 화면과 실행 과정을 눈으로 보고 싶으시다면 영상으로도 정리해 두었습니다 — Kimi K3 + GPT-5.6 Sol, Hermes MoA로 쓰면 더 좋아질까?