LLM

멀티 에이전트 시스템에서 먼저 설계해야 하는 것

harheem

18 Jun 2026 • 23 min read

최근 OpenRouter가 Fusion이라는 기능을 공개했습니다. 여러 모델이 같은 질문에 답하고, judge 모델이 그 답변들을 읽은 뒤 하나의 결과로 합성하는 방식입니다. OpenRouter는 deep research 벤치마크에서 이 구조가 단일 frontier 모델보다 더 높은 점수를 냈다고 설명했습니다.

이미지 출처: https://openrouter.ai/blog/announcements/fusion-beats-frontier/

이 발표에서 눈에 들어온 부분은 “여러 모델을 붙였더니 성능이 올랐다”는 결과 자체보다, 성능을 올리는 방식이었습니다. 모델 하나가 바로 최종 답을 내는 구조에서 벗어나, 여러 답변을 비교하고, 충돌을 보고, 빠진 지점을 찾고, 마지막에 합성합니다.

LLM 제품을 만들다 보면 자연스럽게 모델 선택에 집중하게 됩니다. 어떤 모델이 가장 똑똑한지, 비용은 얼마나 드는지, 응답 속도는 어떤지, 한국어는 잘하는지, 코딩은 어느 정도 하는지 같은 질문이 먼저 나옵니다. 이 질문들은 여전히 중요합니다. 다만 실제 업무 시스템에서는 다른 문제가 곧 따라옵니다.

모델이 낸 답이 왜 맞는지 알기 어렵습니다.
어떤 요구사항이 빠졌는지 확인하기 어렵습니다.
그럴듯한 답변 안에 숨어 있는 위험을 찾기 어렵습니다.
다시 실행했을 때 같은 품질이 나올지도 애매합니다.

OpenRouter Fusion 같은 구조는 이 지점에서 의미가 있습니다. 여러 모델을 병렬로 호출하는 기능 자체보다, 결과를 비교하고 판단하는 단계가 제품 설계의 중심으로 올라온다는 점이 중요합니다.

멀티에이전트 시스템을 만들 때도 같은 문제가 생깁니다. 에이전트 수를 늘리는 것은 쉽습니다. 기획자, 개발자, 보안 전문가, 운영 담당자, 품질 검토자 같은 이름을 붙이면 금방 그럴듯한 구조가 나옵니다. 문제는 이름만 다른 에이전트들이 실제로는 같은 질문을 비슷한 방식으로 풀고 있을 수 있다는 점입니다.

페르소나는 시작하기 쉽지만

멀티에이전트 시스템을 처음 설계하면 대부분 페르소나부터 나눕니다.

너는 기획자입니다. 요구사항을 분석하세요.
너는 개발자입니다. 구현 가능성을 검토하세요.
너는 보안 전문가입니다. 보안 리스크를 검토하세요.
너는 운영 담당자입니다. 운영 이슈를 검토하세요.

이 방식은 단순해서 시작하기 쉽습니다. 모델에게 특정 역할을 주면 답변의 초점이 조금 바뀝니다. 보안 전문가라고 하면 보안 이야기를 더 하고, 개발자라고 하면 구현 이야기를 더 합니다.

문제는 여기서 멈출 때 생깁니다.

역할 이름은 다른데 입력은 같습니다. 질문도 같습니다. 출력 형식도 같습니다. 사용한 모델도 같습니다. 그러면 답변은 생각보다 빨리 비슷해집니다. “요구사항을 명확히 해야 한다”, “권한 관리가 필요하다”, “테스트가 필요하다”, “운영 모니터링이 필요하다” 같은 말이 여러 에이전트에서 반복됩니다.

이런 구조에서는 에이전트가 많아질수록 시스템이 똑똑해지기보다 장황해집니다. 사용자는 더 많은 텍스트를 받지만, 실제로 새롭게 발견된 문제는 많지 않습니다.

멀티에이전트 시스템의 품질은 에이전트 개수로 결정되지 않습니다. 각 에이전트가 서로 다른 실패를 얼마나 잘 잡는지가 더 중요합니다.

독립된 관점으로 생각하기

페르소나는 “누구처럼 생각할 것인가”에 가깝습니다. 독립된 관점은 “무엇을 실패로 볼 것인가”에서 출발합니다.

예를 들어 “보안 전문가”라는 페르소나를 주면 모델은 일반적인 보안 조언을 할 가능성이 큽니다.

민감정보 보호가 필요합니다.
접근 권한을 관리해야 합니다.
감사 로그를 남겨야 합니다.
권한별 정책을 분리해야 합니다.

틀린 말은 아니지만 실제 설계에 바로 반영하기에는 추상적입니다. 여기서 필요한 것은 보안 전문가라는 이름보다, 보안 관점이 반드시 찾아야 하는 실패 목록(= 제약 조건)입니다.

다음 실패만 찾는다.

1. 사용자 권한보다 넓은 문서 접근
2. 승인자 없는 배포
3. 출처 없는 답변 생성
4. 민감정보가 포함된 문서의 무단 사용
5. 감사 로그로 추적할 수 없는 작업

이렇게 쓰면 에이전트의 움직임이 좁아집니다. 좁아진 만큼 결과가 선명해집니다. “보안도 중요합니다” 같은 문장 대신, 어떤 설계 결정이 어떤 위험을 만드는지 지적할 수 있습니다.

같은 방식으로 데이터 관점도 만들 수 있습니다.

다음 실패만 찾는다.

1. 고객 문서의 필드가 시스템 스키마에 매핑되지 않음
2. 같은 의미의 용어가 여러 이름으로 섞여 있음
3. 최신본과 구버전을 구분할 수 없음
4. 표, 각주, 이미지 안의 정보가 누락됨
5. 필수 필드가 비어 있어 자동화가 중간에 멈춤

운영 관점은 또 다릅니다.

다음 실패만 찾는다.

1. 배포 후 결과 품질을 측정할 방법이 없음
2. 실패했을 때 원인을 추적할 로그가 없음
3. 사용자가 잘못된 결과를 수정할 수 없음
4. 재실행 시 같은 기준이 적용되지 않음
5. 승인과 롤백 절차가 없음

이렇게 나누면 각 관점이 서로 다른 오류를 봅니다. 역할 이름보다 중요한 것은 “이 관점이 놓치면 어떤 문제가 실제로 터지는가”입니다.

입력도 독립적으로

프롬프트만 바꿔서는 한계가 있습니다. 여러 에이전트가 같은 문서 전체를 보고 같은 질문에 답하면 답변이 쉽게 겹칩니다.

관점을 제대로 나누려면 각 에이전트가 우선적으로 보는 자료도 달라야 합니다.

요구사항 관점:
- 사용자 요청
- 회의록
- 기존 업무 흐름
- 최종 사용자의 역할

문서/데이터 관점:
- 업로드 문서
- 문서 메타데이터
- 컬럼명과 필드명
- 용어집
- 최신본 여부

보안 관점:
- 권한표
- 조직도
- 개인정보 처리 기준
- 감사 정책

구현 가능성 관점:
- 사용 가능한 도구 목록
- API 제약
- 시스템이 지원하는 기능
- 배포 환경의 제한사항

운영 검증 관점:
- 테스트 질문
- 정답 근거
- 실패 사례
- 평가 기준
- 로그와 모니터링 항목

자료가 달라지면 질문도 달라집니다. 질문이 달라지면 발견하는 실패도 달라집니다.

예를 들어 같은 “문서 기반 질의응답 앱을 만들어줘”라는 요청을 보더라도 관점마다 보는 지점이 달라야 합니다.

요구사항 관점은 누가 이 앱을 쓰는지, 어떤 상황에서 쓰는지, 답변 이후 어떤 행동이 이어지는지 봅니다.

문서/데이터 관점은 문서가 충분히 구조화되어 있는지, 최신본이 무엇인지, 표나 이미지 안의 정보가 빠지지 않는지 봅니다.

보안 관점은 사용자가 볼 수 없는 문서까지 검색되는지, 민감정보가 답변에 노출될 수 있는지 봅니다.

구현 가능성 관점은 현재 시스템의 노드, 도구, API로 실제 구현 가능한지 봅니다.

운영 검증 관점은 배포 이후 답변 품질을 어떻게 측정할지, 실패를 어떻게 재현할지 봅니다.

이 정도로 갈라져야 각 관점의 결과가 최종 산출물에 따로 기여합니다.

출력 형식

여러 에이전트가 각자 긴 글을 쓰면 마지막에 합성하는 모델이 많은 일을 떠안습니다. 무엇이 결론이고, 무엇이 근거이고, 무엇이 추측인지 다시 해석해야 합니다. 이 과정에서 중요한 지적이 묻히거나, 근거 없는 주장이 최종 답변에 섞일 수 있습니다.

관점마다 출력 형식을 정해두면 judge가 훨씬 안정적으로 동작합니다.

보안 관점은 이렇게 출력할 수 있습니다.

{
  "risk": "사용자 권한보다 넓은 문서 접근 가능성",
  "evidence": "요청에는 부서별 접근 차이가 언급되어 있으나 설계안에는 문서 권한 분리가 없음",
  "severity": "high",
  "fix": "문서 저장소를 부서별로 분리하고 사용자 그룹 기반 접근 정책을 추가",
  "unknowns": ["실제 조직 권한표 미제공"]
}

운영 검증 관점은 아래 처럼,

{
  "test_case": "영업팀 사용자가 인사 문서에 대해 질문한다",
  "expected": "권한 부족 안내 또는 접근 불가 처리",
  "required_evidence": ["문서 ACL", "사용자 그룹 정보"],
  "failure_condition": "인사 문서 내용을 요약해 답변함"
}

요구사항 관점은 이렇게 쓸 수 있습니다.

{
  "requirement": "배포 전 승인자가 결과물을 검토해야 함",
  "source": "사용자 요청의 '검토 후 배포' 표현",
  "explicit_or_implicit": "explicit",
  "missing_detail": "승인자 역할과 승인 기준이 정의되지 않음"
}

출력 형식이 잡혀 있으면 judge는 각 답변을 비교할 수 있습니다. 공통 결론, 충돌 지점, 근거 부족, 추가 확인 필요 항목을 구조적으로 다룰 수 있습니다.

여기서 judge의 역할은 여러 관점의 결과를 감사하고, 어떤 지적을 반영할지 고르는 역할입니다.

충돌 지점 살피기

여러 에이전트를 만들면 자연스럽게 토론 구조를 떠올립니다. 각 에이전트가 자기 의견을 내고, 서로 반박하고, 마지막에 합의하는 흐름입니다.

하지만 처음부터 토론을 시키면 독립성이 쉽게 무너집니다. 한 에이전트의 그럴듯한 답변이 다른 에이전트에게 영향을 줄 수 있습니다. 틀린 의견이 다수의 합의처럼 보일 수도 있습니다. 비슷한 표현이 반복되면서 실제 쟁점이 흐려질 수도 있습니다.

안정적인 흐름은 조금 다릅니다.

1. 각 관점이 서로의 답을 보지 않고 1차 분석한다.
2. judge가 결과를 모아 충돌, 누락, 근거 부족을 정리한다.
3. 필요한 관점에만 다시 질문한다.
4. 최종 산출물을 만든다.

최종 답변을 만들기 전에 충돌을 먼저 봐야 합니다.

예를 들어 UX 관점은 사용자가 클릭 한 번으로 작업을 실행할 수 있어야 한다고 말할 수 있습니다. 보안 관점은 승인 없는 실행이 위험하다고 말할 수 있습니다. 둘 중 하나만 맞는 상황이 아닐 수 있습니다. 저위험 작업은 바로 실행하고, 민감정보 조회, 외부 발송, 비용 발생, 권한 변경 같은 작업은 승인 단계를 거치도록 설계하면 됩니다.

judge는 이런 충돌을 설계 결정으로 바꿔야 합니다.

충돌 지점:
- UX 관점은 즉시 실행을 선호함
- 보안 관점은 승인 없는 실행을 고위험으로 봄

판단:
- 저위험 작업은 즉시 실행
- 민감정보, 외부 발송, 비용 발생, 권한 변경 작업은 승인 필요

설계 반영:
- 작업 위험도 분류 추가
- 고위험 작업에 승인 단계 추가
- 승인 로그 저장

이 과정이 없으면 멀티에이전트 시스템은 여러 의견을 모아 평균적인 답변을 만드는 데 그칩니다. 충돌을 드러내고, 그 충돌을 제품 결정으로 바꿔야 실제로 쓸 만한 결과물이 나옵니다.

모델 다양성과 페르소나 다양성을 분리하기

멀티에이전트 시스템에서 다양성은 여러 층위로 나뉩니다.

같은 모델을 여러 번 호출할 수도 있습니다. 같은 모델에 서로 다른 페르소나를 줄 수도 있습니다. 서로 다른 모델을 조합할 수도 있습니다. 모델과 페르소나를 모두 다르게 줄 수도 있습니다.

최근 연구들은 이 차이를 나눠서 봅니다. 같은 모델과 같은 프롬프트를 쓰는 동질적인 에이전트는 출력이 빠르게 비슷해지고, 한계효용이 빨리 줄어듭니다. 서로 다른 모델, 다른 프롬프트, 다른 도구, 다른 출력 형식을 가진 에이전트는 더 보완적인 증거를 만들 수 있습니다.

페르소나 다양성과 모델 다양성을 분리한 실험도 있습니다. 같은 모델에 서로 다른 페르소나를 준 경우, 서로 다른 모델에 같은 프롬프트를 준 경우, 서로 다른 모델에 서로 다른 페르소나를 준 경우를 비교합니다. 이 흐름의 연구에서는 모델 다양성이 페르소나 다양성보다 더 큰 효과를 만들고, 둘을 함께 적용했을 때 가장 좋은 결과가 나오는 경향이 보고됩니다.

다만 다양성 자체에 너무 기대면 위험합니다. 낮은 품질의 모델을 많이 섞으면 최종 결과가 나빠질 수 있습니다. 여러 모델을 섞는 것보다 가장 강한 모델의 여러 출력을 합성하는 편이 더 나은 경우도 보고됩니다. 결국 중요한 것은 “서로 다름”과 “각 출력의 품질” 사이의 균형입니다.

좋은 다양성은 다음 특징을 가집니다.

- 서로 다른 오류를 잡는다.
- 출력이 과하게 겹치지 않는다.
- 각 관점의 답변 품질이 충분히 높다.
- judge가 비교할 수 있는 형식으로 나온다.
- 최종 결과물에 실제로 반영된다.

나쁜 다양성은 아래와 같습니다.

- 역할명만 다르고 같은 말을 반복한다.
- 각 에이전트가 일반론을 길게 쓴다.
- 책임 범위가 겹친다.
- judge가 무엇을 믿어야 할지 판단하지 못한다.
- 최종 결과물에는 거의 반영되지 않는다.

에이전트가 많아졌는데 사용자가 읽어야 할 텍스트만 늘어난다면 설계가 잘못된 것입니다.

관점 카드 템플릿

멀티에이전트 시스템을 설계할 때 바로 에이전트를 실행하기보다 관점 카드를 먼저 만드는 편이 좋습니다.

관점 이름:
- 이 관점은 무엇을 판단하는가?

잡아야 하는 실패:
1.
2.
3.

우선적으로 볼 입력:
-

보면 안 되는 것:
-

사용 가능한 도구:
-

출력 형식:
-

판단 불가라고 말해야 하는 조건:
-

다른 관점과 충돌할 가능성이 높은 지점:
-

이 템플릿에서 중요한 항목은 “보면 안 되는 것”과 “판단 불가 조건”입니다.

LLM은 기본적으로 답하려고 합니다. 정보가 부족해도 그럴듯한 문장을 만들 수 있습니다. 업무 시스템에서는 이 성향이 문제가 됩니다. 특히 보안, 법무, 금융, 의료, 데이터 분석처럼 근거가 중요한 영역에서는 모르는 것을 모른다고 말해야 합니다.

예를 들어 보안 관점의 판단 불가 조건은 이렇게 쓸 수 있습니다.

다음 정보가 없으면 권한 안전성을 확정하지 않는다.

- 조직별 권한표
- 문서별 접근 제어 정보
- 사용자 그룹 정보
- 감사 로그 저장 방식

데이터 관점은 다르게 쓸 수 있습니다.

다음 정보가 없으면 자동 매핑 가능 여부를 확정하지 않는다.

- 필수 필드 목록
- 실제 샘플 데이터
- 용어집
- 최신본 판별 기준

이 조건이 있어야 결과물에 불확실성이 남습니다. 불확실성이 남아야 사람이 판단할 수 있습니다.

최종 결과물

멀티에이전트 시스템이 단일 모델 호출보다 더 나은 사용자 경험을 만들려면 최종 답변만 보여줘서는 부족합니다. 사용자는 결과가 왜 그렇게 나왔는지, 무엇이 빠졌는지, 어떤 가정 위에서 만들어졌는지 알아야 합니다.

최종 산출물에는 다음이 함께 있어야 합니다.

- 최종 답변
- 근거 맵
- 가정 목록
- 충돌 지점
- 반대 의견
- 리스크
- 판단 불가 항목
- 검증 체크리스트
- 재실행 가능한 워크플로우

예를 들어 어떤 문서 기반 자동화 시스템을 설계했다고 해보겠습니다. 최종 답변만 쓰면 이렇게 끝날 수 있습니다.

부서별 권한을 분리하고, 승인 후 배포하는 문서 기반 질의응답 앱을 구성합니다.

업무에서는 이 정도로 부족합니다. 사용자는 바로 다음을 묻습니다.

왜 부서별 권한 분리가 필요한가?
어떤 문서 때문에 민감정보 리스크가 생겼는가?
승인자는 누가 되어야 하는가?
아직 판단할 수 없는 부분은 무엇인가?
이 설계가 실제로 잘 작동하는지 어떻게 테스트할 것인가?

결과물이 이런 질문에 답해야 합니다.

결론:
- 부서별 권한 분리가 필요함

근거:
- 업로드 문서에 인사, 정산, 계약 자료가 함께 포함됨
- 사용자 요청에 부서별 접근 차이가 암시되어 있음
- 현재 설계안에는 문서 접근 제어가 없음

가정:
- 사용자는 부서별로 다른 문서 접근 권한을 가진다
- 문서 저장소는 권한 메타데이터를 제공할 수 있다

리스크:
- 단일 문서 저장소로 구성하면 과권한 접근 가능성 있음

판단 불가:
- 실제 조직 권한표가 제공되지 않아 세부 권한 매핑은 보류

검증:
- 영업팀 사용자가 인사 문서에 질문했을 때 접근이 차단되는지 테스트

이런 형태가 되면 사용자가 수정할 수 있습니다. 최종 답변을 믿거나 버리는 선택지만 남는 것이 아니라, 근거와 가정을 보고 판단할 수 있습니다.

ablation 평가

멀티에이전트 시스템은 쉽게 과대평가됩니다. 여러 에이전트가 각자 말하고, judge가 종합하면 복잡한 시스템처럼 보입니다. 하지만 단일 모델보다 실제로 나은지는 따로 검증해야 합니다.

최소한 다음 비교군은 필요합니다.

A. 단일 모델 1회 호출
B. 같은 모델 여러 번 호출 후 voting 또는 merge
C. 같은 모델 + 여러 페르소나
D. 여러 모델 + 같은 관점
E. 여러 모델 + 여러 관점
F. 여러 관점 + judge + 검증 리포트

이렇게 나눠야 무엇이 성능을 올렸는지 볼 수 있습니다.

성능이 좋아졌다면 그 이유가 페르소나 때문인지, 모델 다양성 때문인지, 여러 번 샘플링했기 때문인지, judge가 좋아서인지 구분해야 합니다. 이 구분 없이 “멀티에이전트가 좋다”고 말하면 제품 설계가 흐려집니다.

평가 지표도 구체적으로 잡아야 합니다.

- 정답성
- 근거 정확도
- 누락 요구사항 수
- 고유 이슈 발견 수
- 중복 이슈 비율
- 잘못된 확정 표현 수
- 판단 불가 처리 품질
- 수정 소요 시간
- 비용
- 지연 시간
- 재실행 일관성

특히 고유 이슈 발견 수와 중복 이슈 비율을 같이 봐야 합니다.

다섯 개의 에이전트가 모두 비슷한 문제만 지적한다면 관점이 제대로 나뉘지 않은 것입니다. 어떤 관점을 제거했을 때 최종 품질이 떨어진다면 그 관점은 실제로 기여하고 있는 것입니다.

제거해도 품질이 그대로인 관점은 정리해야 합니다. 멀티에이전트 시스템에서도 가지치기가 필요합니다.

실패 지도 그리기

멀티에이전트 시스템을 만들 때 먼저 정해야 할 것은 에이전트 수가 아닙니다. 먼저 이 작업이 어디서 실패할 수 있는지 봐야 합니다.

문서 기반 업무라면 문서 최신본, 필드 매핑, 권한, 출처, 승인, 검증이 주요 실패 지점이 될 수 있습니다.

데이터 분석 업무라면 지표 정의, 데이터 조인, 집계 기준, 기간 필터, 이상치, 시각화 해석이 주요 실패 지점이 될 수 있습니다.

코딩 업무라면 요구사항 오해, 기존 코드와의 충돌, 테스트 누락, 보안 취약점, 배포 리스크가 주요 실패 지점이 될 수 있습니다.

실패 지도가 나오면 그때 관점을 정합니다.

실패 지점:
- 요구사항 누락
- 데이터 매핑 실패
- 권한 위반
- 구현 불가능한 설계
- 운영 검증 불가

필요한 관점:
- 요구사항 분석
- 데이터 매핑
- 보안 감사
- 구현 검증
- 품질 평가

이 순서가 중요합니다. 직무명을 먼저 나누면 역할극으로 흐르기 쉽습니다. 실패 지점을 먼저 나누면 각 관점의 책임이 선명해집니다.

마무리

OpenRouter Fusion 같은 사례는 멀티에이전트 시스템을 다시 보게 만듭니다. 여러 모델을 호출하는 기능은 점점 흔해질 것입니다. 더 중요한 차이는 그 답변들을 어떻게 비교하고, 어떤 기준으로 버리고, 무엇을 근거로 최종 결과를 만들지에서 생깁니다.

에이전트를 많이 만드는 것보다 먼저 봐야 할 질문들이 있습니다.

이 작업은 어디서 조용히 실패할 수 있는가?
그 실패를 잡기 위해 어떤 관점이 필요한가?
각 관점은 어떤 입력을 봐야 하는가?
각 관점은 무엇을 모른다고 말해야 하는가?
judge는 합의보다 충돌을 먼저 드러내는가?
최종 결과물에는 근거, 가정, 리스크, 검증 방법이 남는가?
관점 하나를 제거했을 때 품질이 실제로 떨어지는가?

이 질문에 답하지 않은 멀티에이전트 시스템은 에이전트 수를 늘려도 큰 차이를 만들기 어렵습니다. 반대로 각 관점이 서로 다른 실패를 잡고, judge가 충돌과 근거를 구조화하고, 사용자가 그 결과를 수정할 수 있다면 멀티에이전트 구조는 단일 모델 호출보다 더 나은 사용자 경험을 만들 수 있습니다.

결국 설계의 출발점은 단순합니다.

참고한 자료

OpenRouter, “Surpassing Frontier Performance with Fusion”
“Understanding Agent Scaling in LLM-Based Multi-Agent Systems via Diversity”
“Rethinking Mixture-of-Agents: Is Mixing Different Large Language Models Beneficial?”
“Debate or Vote: Which Yields Better Decisions in Multi-Agent Large Language Models”
“Can LLM Agents Really Debate? A Controlled Study of Multi-Agent Debate in Logical Reasoning”