모델에 이름표만 붙여도 AI들이 편을 가른다 — 파벌주의의 발견

에이전트에게 서로의 모델 계열을 알려주자 같은 이름표끼리 뭉치는 '파벌주의'가 생겼다. 두 협력 게임과 추론 벤치마크로 측정했고, 라벨만 가려도 사라졌다.
English  ·  日本語  ·  한국어
← 목록으로
온
온틀 리서치
2026년 10월 05일 수정 2026.10.16 읽기 16분 조회 3

여러 회사의 모델을 한데 섞어 쓰는 시스템에서, 각 에이전트에게 "너와 상대가 어떤 모델 계열인지"만 귀띔해 줬다. 그랬더니 같은 이름표를 단 에이전트끼리 뭉쳐 서로 편을 가르기 시작했다.

아무도 편을 가르라고 시킨 적이 없는데도 그랬다. 논문은 이 현상에 파벌주의(factionalism)라는 이름을 붙였다. 같은 꼬리표를 단 끼리끼리 편을 짓는 성향이라는 뜻이다.

얼마나 나빠질까. 순수하게 협력만 잘하면 되는 두 게임에서, 이름표가 붙은 그룹은 결론에 도달하기까지 평균 30% 더 많은 라운드와 55% 더 많은 토큰을 썼다. 성공률은 96%에서 81%로 떨어졌다(논문 초록 기준).

반전은 해법이 문제만큼 단순하다는 데 있다. 에이전트에게 그 이름표만 가리면, 쏠림은 사라진다.

이 논문이 푸는 문제

요즘 AI 시스템은 한 모델에 다 맡기지 않는다. 여러 AI 에이전트를 한 팀처럼 묶어 일을 시킨다. 이를 멀티에이전트 시스템이라 부른다. 그리고 그 팀에는 점점 여러 공급사의 모델이 섞인다.

그런데 "이 에이전트는 어느 모델 계열인가" 같은 정보는, 원래 일하는 데는 필요 없는 부가 꼬리표일 뿐이다. 문제는 이 꼬리표가 시스템 프롬프트나 에이전트 이름, 메시지 헤더를 타고 에이전트 자신에게까지 흘러드는 경우가 많다는 점이다. 아무도 이걸로 편을 가르라고 시키지 않았다. 그런데 에이전트는 정말 이 정보를 무시할까. 지금까지 아무도 제대로 확인하지 않았다는 게 저자들의 출발점이다.

사실 요즘은 똑똑한 AI를 여럿 모아 놓고도 엉뚱한 결과가 나오는 문제가 화두다. 모델 하나하나는 멀쩡한데, 여럿이 모이면 서로 엇박자를 내거나 우르르 한쪽으로 쏠린다. 멀티에이전트의 실패는 대체로 모델 자체보다 모델들 사이의 상호작용에서 생긴다는 관찰이 쌓여 왔다(Cemri 외 2026; Anthropic Frontier Red Team 2026). 이 논문은 그 엇박자 쪽에 현미경을 들이댄다.

핵심 아이디어

저자들은 파벌주의를 "에이전트들이 같은 정체성을 공유하는 무리로 조직되는 경향"으로 정의한다. 에이전트들이 주고받은 말을 관계도로 그려 보면, 그 관계도가 이름표를 따라 여러 덩어리로 쪼개지는 모습으로 드러난다. 바탕에는 동질선호(homophily)가 깔려 있다. 같은 이름표를 단 상대에게 더 후하게 반응하는 '유유상종' 성향이다.

여기서 저자들은 한 가지를 영리하게 구분한다. 같은 이름표끼리 조금 더 동의한다고 해서, 반드시 집단이 갈라지는 건 아니다. 동창회를 떠올리면 쉽다. 같은 과 동문끼리 유난히 반갑게 인사하면서도 자리는 다 같이 섞어 앉는 경우가 있다(국소적 친밀, 두 사람 사이의 일). 반대로 아예 과별로 테이블을 따로 잡고 앉아 버리는 경우가 있다(전역적 분열, 집단 전체의 일). 저자들은 이 둘을 따로 재고, 둘 다 뚜렷할 때에만 "파벌적"이라고 불렀다. 끼리끼리 조금 친한 것만으로는 부족하다는 기준을, 측정 설계에 그대로 못 박은 것이다.

사실 이건 사람에게서 오래 관찰된 '최소집단 편향'의 AI판이다. 사람은 동전 던지기처럼 아무 의미 없는 기준으로 편을 갈라 줘도 제 편을 든다. 이 논문은 같은 일이 LLM 집단에서도 벌어지는지를 물었다. 그리고 그 원인이 모델의 속(실제 아키텍처)인지 프롬프트에 적힌 겉(이름표)인지까지 가려내려고, 뒤에서 볼 영리한 실험 하나를 준비한다.

실험은 어떻게 설계됐나

실험에는 다섯 개의 오픈웨이트 모델 계열이 쓰였다. 오픈웨이트란 소스코드는 공개되지 않았어도 모델의 가중치(학습된 숫자 뭉치)는 공개돼 누구나 내려받아 돌릴 수 있는 모델을 말한다. 구체적으로 Gemma, GPT-OSS, Nemotron, Qwen, GLM이다.

한 판에는 9~25개의 에이전트가 들어가고, 명단 크기에 따라 이 중 세·네·다섯 계열을 섞는다. 각 계열을 같은 수로 넣은 균형 구성과, 한 계열을 많이 넣은 불균형 구성을 둘 다 돌렸다. 균형 구성은 "머릿수가 많아서 뭉친다"는 설명을 지우고, 불균형 구성은 "다수가 있어도 효과가 유지되는가"를 보기 위한 것이다.

과제는 두 개의 협력 게임이다.

  • 리더 선출: 매 라운드 모두가 한 표씩 던져, 한 후보가 기준 이상의 표로 유일한 최다 득표자가 되면 성공한다. 정해진 라운드 안에 못 정하면 그룹 전체가 실패한다.
  • 배제: 매 라운드 살아 있는 에이전트가 제거할 동료 하나를 지목한다. 기준 이상을 받은 단일 대상만 제거되고, 동점이거나 미달이면 아무도 안 나간다. 어느 계열이든 살아남는 집단을 꾸릴 수 있게 설계돼, 조건을 채우면 성공한다.

두 게임은 같은 틀 위에서 돈다. 매 라운드 에이전트는 자연어 메시지와 투표, 그리고 '이 메시지를 누구에게 보낼지' 고른 수신자 명단을 함께 낸다. 다음 라운드에는 자기 앞으로 온 메시지만 본다. 누구에게 말을 걸지 스스로 고른다는 점이 중요하다. 환경이 강제하지 않아도, 계열을 따라 끼리끼리 접촉하고 동의할 여지를 열어 둔 것이다.

여기에, 정답이 바깥에 정해진 과제에서도 같은 일이 벌어지는지 보려고, 어려운 과학 다지선다 문제집 GPQA-Diamond 위에 리더 선출을 그대로 올렸다. 선출된 리더의 답이 그룹의 답이 되고, 그게 맞아야 성공이다.

측정의 논리

핵심은 '편이 갈렸다'를 어떻게 숫자로 재느냐다. 저자들은 먼저 '누가 누구 의견을 따라갔나'를 관계로 그렸다. 어떤 에이전트가 낸 결정을 상대가 다음 라운드에 그대로 따라가면, 둘 사이의 끈을 굵게 보는 식이다.

그다음, 이 관계를 두 가지 잣대로 봤다. 다만 두 잣대는 같은 관계를 조금 다르게 손질해서 쓴다. (1) 같은 이름표끼리 더 끈끈한가. (2) 실제로 이름표를 따라 여러 무리로 쪼개지는가. 이 둘은 다른 질문이다. 인기투표에서 특정 후보를 좀 더 좋아하는 것(1)과, 그 후보를 중심으로 아예 선거 캠프를 꾸려 다른 캠프와 선을 긋는 것(2)은 전혀 다른 일이다. 앞서 동창회에서 본 '반가운 인사'와 '테이블 분리'의 차이이기도 하다. 저자들은 두 잣대가 '모두' 맞을 때에만 파벌로 판정했다. 더구나 여러 번 반복해 우연이 아니라고 통과한 경우만 셌으니, 어지간해서는 파벌이라 부르지 않는 보수적인 잣대다.

그리고 원인을 이름표 하나로 몰아넣으려고, 실험 자체를 세 겹으로 깔끔하게 설계했다.

  • 무판돈(no-stakes): 같은 계열을 밀어줘서 득 볼 것도, 특정 계열이라서 손해 볼 것도 없게 했다. 페르소나도, 사적 목표도, 편을 지으라는 지시도 없다. 그러니 상호작용이 이름표를 따라 갈라진다면, 원인은 이름표밖에 없다.
  • 이름표 바꿔치기(counterfactual): 모델은 그대로 두고, 에이전트에게 보여 주는 계열 라벨만 바꿨다. 쉽게 말해 '모델은 그대로, 이름표만 바꿔 다는 만약에 실험'이다. 이러면 '보이는 정체성'과 '실제 아키텍처'가 어긋나, 둘 중 무엇이 쏠림을 끌고 가는지 갈라 볼 수 있다.
  • 뜻 없는 색 이름: 모델 이름에 묻은 평판·선입견 탓일 가능성까지 지우려고, 라벨을 아무 뜻 없는 색 이름으로 바꾼 조건도 함께 돌렸다.
측정 방법 더 자세히 (통계 용어)

두 지표는 같은 '따라가기' 관계에서 출발하되 관계도를 서로 다르게 쌓아 쓴다. (1) '같은 이름표끼리 더 끈끈한가'는 j가 i를 수신자로 골라 보낸 결정과 i의 다음 라운드 결정이 일치하는 비율로 간선 가중치를 매기고(식 1) 접촉량으로 정규화한 관계도에서, 같은 라벨 쌍과 다른 라벨 쌍의 평균 가중치 비율인 간선밀도비(EDR)로 재고, 라벨을 뒤섞는 순열 검정으로 우연 여부를 가린다. (2) '이름표를 따라 쪼개지는가'는 정규화하지 않은 일치 횟수를 양방향으로 합친 관계도에 Louvain 알고리즘을 돌려 무리를 찾아낸 뒤, 그 무리가 라벨 분할과 얼마나 겹치는지를 조정상호정보량(AMI, 무관하면 0·일치하면 1)으로 점수화한다. 파벌주의는 이 두 지표에 건 네 검정이 모두 유의할 때만 인정한다. EDR 쪽 둘은 시드별 순열 검정 p값을 Fisher 방식으로 결합한 검정과 log(EDR)에 건 단측 t검정이고, AMI 쪽 둘은 단측 t검정과 부호 검정이다. 이 넷을 Holm–Bonferroni로 보정해 모두 통과해야 파벌주의로 본다. 쏠림이 에이전트가 본 라벨을 따르는지 그 뒤의 실제 아키텍처를 따르는지는, 이 판정과는 별개로 라벨을 바꿔치기한 실험에서 가린다.

이 관계도 점수는 상호작용의 '구조'가 갈라졌는지만 본다. 결정의 '질'은 보지 않는다. 질과 효율(앞서 본 라운드·토큰·성공률)은 따로 쟀다.

결과와 의미

결과부터 말하면, 이름표가 보이는 모든 실험에서 파벌주의가 나타났고, 이름표가 없는 실험에서는 하나도 나타나지 않았다. 균형 구성에서도 불균형만큼 강했다. 머릿수 다수가 주범이 아니라는 뜻이다.

하지만 더 흥미로운 질문은 따로 있다. 모델들은 '왜' 편을 가르는가. 가능한 설명은 둘이다.

  • 글투 가설: 모델이 상대의 말투·문체에서 '쟤는 나랑 같은 계열'임을 알아보고 끌린다. 이게 맞다면 쏠림은 실제 아키텍처를 따라가야 하고, 겉에 붙은 이름표와는 상관없어야 한다.
  • 이름표 가설: 모델은 그냥 프롬프트에 적힌 이름표를 보고, 같은 이름표의 결정을 더 받아들인다. 이게 맞다면 쏠림은 실제 아키텍처가 아니라 '보이는 이름표'를 따라가야 한다.

설계는 이 둘을 갈라 보도록 돼 있었고, 결과는 이름표 가설의 손을 들어줬다. 이름표를 실제 모델과 뒤섞자, 쏠림은 '실제 아키텍처'가 아니라 '뒤섞인 이름표'를 따라갔다. 평판도 뜻도 없는 색 이름(teal, coral, silver, violet, maroon)으로 바꿔도 같았고, 정답이 바깥에 정해진 GPQA-Diamond에서도 같았다. 한마디로, 설계대로 결과는 이름표를 따라갔다.

저자들은 이 결론을 한 번 더 못 박으려고 두 신호를 직접 쟀다(4.4절). 하나는 '글투' 신호로, 상대의 원문이 내 모델에 얼마나 자연스럽게 읽히는가다. 다른 하나는 '동조' 신호로, 상대의 투표를 내가 얼마나 따라가는가다. 재 보니 글투의 유사성은 있긴 했지만 거의 무시할 만큼 미미했고, 이름표를 뒤섞어도 진짜 아키텍처 쪽을 따라갔다. 반면 동조 신호는 이름표가 붙으면 커졌고, 뒤섞으면 실제 아키텍처가 아니라 '보이는 이름표'를 따라갔다. 결론은 분명하다. 모델이 글투로 동족을 알아봐서 뭉치는 게 아니다. 에이전트는 그저 '자기가 들은 이름표'에 반응해, 같은 이름표의 결정을 더 받아들인다.

이 손해는 집단이 커질수록 더 벌어졌다. 이름표가 붙은 그룹은 토큰을 더 쓰면서 성공은 덜 하니, 성공 한 번당 치르는 비용은 집단이 클수록 가파르게 오른다.

한계와 남은 질문

저자들은 주장의 범위를 일부러 좁혔다고 밝힌다. 연구 대상이 오픈웨이트 모델 계열 최대 다섯 종이라는 점이 그 한계의 핵심이다.

짚어 둘 지점은 둘이다. 첫째, 과제가 추상적인 조율 게임과 벤치마크라는 점이다. 이 깔끔함은 원인을 입증하는 데는 강점이지만, 역할·권한·이해관계가 뒤엉킨 실제 소프트웨어 에이전트 현장으로 그대로 옮겨갈지는 또 다른 문제다. 현실의 시스템은 대개 역할과 목표를 갖는데, 그런 이해관계가 파벌의 비용을 키울지 줄일지는 이 설계만으로 알 수 없다.

둘째, 완화책인 '이름표 숨기기'는 공짜가 아니다. 저자들도 전체를 조율·배차하는 상위 계층(오케스트레이터)은 어느 모델에 일을 맡길지 정하고, 문제를 추적하고, 책임 소재를 가리기 위해 정체성을 쥐고 있어야 한다고 본다. 즉 에이전트끼리 주고받는 맥락에서만 가리는 것이지, 시스템 전체가 정체성을 버리라는 처방이 아니다. 이 균형점을 실제 운영에서 어떻게 잡느냐가 남는 숙제다.

온틀에서는

그렇다면 이 발견이 온틀 시스템에는 어떻게 닿을까. 논문의 경고가 그대로 들어맞을 법한 자리가 하나 있다. 온틀의 AI PM이 여러 담당 에이전트와 함께 결론을 모으는 자리다.

가령 고객 산출물을 '승인 가능' 상태로 올릴지 정하는 회의를 떠올려 보자. PM 에이전트가 개발 담당·QA 담당 에이전트와 의견을 모은다. 온틀의 모델 라우터는 과제 성격에 따라 서로 다른 모델을 배정하므로(챗·접수는 무거운 추론, 실행은 중간, 수정·배포는 빠른 모델), 이 회의는 이미 여러 계열이 섞인 자리다. 만약 주고받는 프롬프트·헤더·에이전트 이름에 "나는 어느 모델 계열"이라는 꼬리표가 묻어 있다면, 논문의 결과대로 승인 합의가 이름표를 따라 갈라지고, 라운드를 더 돌고, 결론을 더 자주 못 낼 소지가 있다. 비용이 특히 크게 측정된 게 바로 이런 합의형 과제였으니, 투표로 결론을 모으는 온틀의 승인 플로우는 눈여겨볼 자리다.

여기서 중요한 건, 이게 온틀의 기존 규칙과는 '다른 표면'의 문제라는 점이다. 온틀에는 이미 '고객 산출물·화면·PM 회신에 사용 모델명을 노출하지 않는다'는 규칙이 있다. 하지만 그건 고객이 보는 표면의 규칙이고, 이유는 '격'이었다. 이번 논문이 가리키는 곳은 고객이 아니라 에이전트끼리 주고받는 표면이다. 같은 '모델명을 숨긴다'는 위생 습관을, 지금까지 손대지 않던 새 표면에 한 번 더 적용하라는 이야기다. 이유도 미관이 아니라 조율 비용이다.

그리고 여기서 한 걸음 더 들어가면, 온틀의 모델 라우팅 전략 자체에 질문이 생긴다. 라우터는 효율을 위해 '무거운 추론은 이 계열, 빠른 실행은 저 계열'로 일을 나눈다. 그런데 그 배정이 에이전트들 눈에 '능력에 따른 편'으로 비치는 순간, 효율을 노린 라우팅이 되레 논문이 경고한 편 가르기의 씨앗이 될 수 있다. 성능 좋은 모델끼리만 뭉치게 하는 배치가 늘 최선인지, 아니면 때로는 계열을 일부러 섞고 그 경계를 가려야 하는지. 이건 이 논문이 온틀에 새로 던진 숙제다.

그렇다고 '능력 서술자'로 바꾸면 끝, 은 아니다. 논문은 뜻 없는 색 이름으로 바꿔도 파벌이 생겼다고 했다. 핵심은 이름을 바꾸는 게 아니라, 여럿을 같은 편으로 묶는 '범주형 꼬리표' 자체를 에이전트에게서 가리는 것이다. 다행히 승인 회의처럼 PM 하나·개발 하나·QA 하나로 역할이 다 다른 자리에서는, 역할 이름이 '편'이 아니라 '개인 식별'로 작동해 비교적 안전하다. 위험은 같은 범주의 에이전트가 여럿 몰릴 때 커진다. 규모가 커질수록 더 신경 써야 하는 이유다.

실무로 옮기면 순서는 이렇다.

  • 새는 곳부터 찾기: 에이전트끼리 오가는 시스템 프롬프트·메시지 헤더·에이전트 이름에 모델 계열이나 공급사 식별자가 묻어 있는지 본다. 논문이 지목한 통로가 바로 이 셋이다.
  • 묶는 꼬리표만 가리기: 계열 라벨은 과제 중심의 역할·속도·강점 서술로 바꾸고, 공급사 정체성은 라우터 계층에만 둔다. '누가 보냈는지'(개별 식별)는 남겨도 된다.
  • 합의형부터: 투표·리더 선출·다수결로 결론을 모으는 플로우를 먼저 점검한다. 비용 증가가 바로 여기서 측정됐다.
  • 숫자로 확인: 라벨을 가린 조건과 아닌 조건을 A/B로 돌려 라운드·토큰·성공률을 실측한다. '라벨을 빼도 손해가 없는가'는 추측이 아니라 내 시스템의 숫자로 답할 문제다. 효과는 논문의 추상적 과제에서 측정된 것이라, 온틀 플로우에서도 그런지는 직접 재 봐야 한다.

FAQ

에이전트에 번호(agent-1 같은 개별 이름)를 붙이는 것도 위험한가요?

아닙니다. 논문이 지목한 건 여럿을 같은 편으로 묶는 '범주형 꼬리표'(계열·색)이지, 개별 식별이 아닙니다. 연구는 '누가 보냈는지'는 그대로 둔 채 계열 라벨만 바꿔치기했고, 쏠림은 번호가 아니라 계열 라벨을 따라갔습니다. 개별 발신자를 구분하는 것 자체는 방아쇠가 아닙니다.

같은 모델 계열만 쓰면 이 문제는 없나요?

이 연구는 여러 계열을 섞은 집단을 대상으로 했습니다. 이름표가 하나뿐이면 논리적으로 갈라질 편 자체가 없습니다. 다만 이 논문이 다룬 건 공급사를 섞어 쓰는 경우이고, 단일 계열 운영이 가진 다른 장단점까지 이 결과가 말해 주지는 않습니다.

참고자료