멀티 에이전트는 조직이 될 수 있을까?

AX Central·2026년 8월 16일

에이전트만 많아지면 알아서 '조직'이 될까? Anthropic 멀티에이전트 보고서가 던지는 화두

TL;DR

멀티에이전트 시스템은 각자 독립적인 작업을 병렬로 처리할 때 강력한 성능을 발휘합니다. 하지만 여러 에이전트가 자원을 공유하고 서로의 판단에 기대기 시작하면 완전히 새로운 차원의 문제가 발생합니다.
Anthropic이 대규모 에이전트 실험을 진행한 결과, 에이전트 간의 조율 실패, 집단사고(획일적 행동), 담합, 소수의 핵심 정보 무시, 심지어 목표 충돌로 인한 상호 방해 행위까지 나타났습니다.
같은 AI 모델을 여러 개 띄운다고 해서 알아서 '다양한 전문가 집단'이 꾸려지는 것은 아닙니다. 오히려 똑같은 판단 착오를 동시에 저지르며 작은 오류를 시스템 전체의 붕괴로 몰고 갈 위험이 큽니다.
모델이 똑똑해진다고 저절로 협력을 잘하는 것도 아닙니다. 업무 '실행 능력'과 갈등 '조정 능력'은 완전히 별개의 문제입니다.
프롬프트에 안전 지침을 길게 써넣는 방식으로는 한계가 있습니다. 여러 행위자가 공존하는 만큼, 신원 확인, 권한 분리, 평판 시스템, 감사 로그, 이의 제기 및 중재 등 진짜 '사회'에 필요한 제도적 장치를 시스템 내부에 직접 설계해야 합니다.

멀티에이전트 시스템은 AI의 성능을 끌어올리는 훌륭한 방법론으로 꼽힙니다. 큰 과제를 여러 조각으로 쪼개어 전문 에이전트들에게 분배하고 최종 결과를 하나로 취합하는 구조죠. 실제로 검색이나 리서치처럼 병렬 처리가 쉬운 작업에서는 꽤 쏠쏠한 효과를 봅니다.

Anthropic이 2025년에 공개한 멀티에이전트 리서치 시스템 역시 이 전형적인 구조를 따랐습니다. 리드 에이전트가 여러 서브에이전트에게 검색 범위를 나눠 주고 결과를 취합하는 식입니다. 하지만 엄밀히 말해 이때 얻은 성능 향상의 상당 부분은 '더 많은 추론과 검색을 동시에 수행한 덕분'이었습니다. 당시 Anthropic의 분석에 따르면 토큰 사용량만으로도 성능 차이의 80%가 설명되었고, 멀티에이전트 시스템은 일반 채팅보다 무려 15배나 많은 토큰을 썼습니다. 서로 유기적으로 얽혀야 하는 코딩 작업에는 멀티에이전트 방식이 잘 맞지 않는다는 점도 이미 지적된 바 있습니다.

그런데 2026년 8월에 발표된 Patterns and problems in emerging multiagent systems 라는 보고서는 여기서 한발 더 나아갑니다. 이제 우리는 이런 질문을 던져야 합니다.

"여러 에이전트가 같은 환경에서 오랜 시간 활동하며 서로에게 영향을 주고, 각자의 목표를 밀어붙이기 시작하면 과연 무슨 일이 벌어질까?"

이것은 더 이상 단순한 소프트웨어 아키텍처 문제가 아닙니다. 에이전트들이 동료와 협상하고, 같은 저장소의 코드를 수정하며, 제한된 컴퓨팅 자원을 두고 다투거나 사람을 대신해 거래에 나서는 순간부터 그들만의 '작은 사회'가 형성되기 때문입니다.

실제로 Anthropic의 Project Deal 실험을 보면, 69명의 직원을 대리하는 에이전트들이 사람의 실시간 개입 없이 186건(총 4,000달러 이상)의 실제 거래를 성사시켰습니다. 더 뛰어난 모델을 대리인으로 둔 사람은 유리한 조건으로 거래를 마쳤지만, 정작 성능이 떨어지는 대리인을 배정받아 손해를 본 참가자들은 자신이 불리했다는 사실조차 눈치채지 못했습니다. 에이전트 간의 상호작용은 이미 장난감 같은 시뮬레이션을 벗어나 현실의 문제가 되었습니다.

왜 지금 멀티에이전트의 ‘사회성’을 연구해야 하는가

지금까지 AI 안전성 연구는 대체로 '모델 단일 개체'에 초점을 맞췄습니다. 한 명의 사용자가 하나의 모델에 질문을 던지면, 모델이 정해진 안전 정책을 잘 지키는지 확인하는 식이었죠. 하지만 여러 에이전트가 서로의 결괏값을 입력값으로 삼고 각자 도구와 권한을 쥔 채 움직이는 환경에서는, 개별 모델만 검사해서는 전체 시스템이 어떤 결과를 낳을지 예측하기 어렵습니다.

각 에이전트가 자신에게 주어진 지시를 완벽하게 따랐음에도 시스템 전체는 붕괴할 수 있습니다. 예를 들어, "가격을 최대한 높여라"라는 지시를 받은 판매 에이전트들이 모두 합리적으로 행동한 결과가 소비자에게 피해를 주는 '담합'일 수 있습니다. "작업을 최대한 빨리 처리하라"는 지시를 받은 에이전트들이 서버 확인(폴링) 주기를 극단적으로 줄인 결과가 디도스(DDoS) 공격과 같은 '서비스 마비'로 이어질 수도 있습니다.

여기서 핵심은 에이전트의 '머릿수'가 아니라 '자율성'과 '상호의존성'입니다.

멀티에이전트 시스템의 자율성과 상호의존성

그림 1. 서로 독립적인 하위 작업을 수행하는 병렬 도구와, 같은 자원을 공유하며 장기간 상호작용하는 에이전트 사회는 근본적으로 다른 시스템입니다.

위 그림의 왼쪽 아래에 있는 병렬 도구 구조에서는 불필요한 중복 작업이나 비용 낭비 정도가 문제가 됩니다. 하지만 오른쪽 위로 갈수록 권한 충돌, 집단사고, 담합, 상호 방해처럼 '관계'에서 비롯되는 문제가 걷잡을 수 없이 커집니다. 이 영역부터는 모델의 지능을 높인다고 문제가 해결되지 않습니다. 데이터베이스의 동시성 제어나 분산 시스템의 합의 알고리즘처럼 상호작용 자체를 통제할 규칙을 설계해야 합니다.

이것이 Anthropic이 이번 보고서를 통해 던지는 가장 중요한 메시지입니다. "개별 에이전트가 안전하다고 해서 시스템 전체의 안전이 보장되는 것은 아니며, 모델이 똑똑해진다고 갈등 조정 능력이 알아서 생기는 것도 아니다."

1. '각자 찾는 일'에는 강했지만, '함께 만드는 일'에는 약했다

첫 번째 실험은 오픈소스 소프트웨어의 취약점을 찾는 과제였습니다. Anthropic은 45개의 에이전트에게 각각 가상머신을 지급하고, 공용 포럼에서 정보를 공유하며 15개 프로젝트를 조사하도록 했습니다. 중재 역할을 맡은 별도의 에이전트가 발견된 취약점의 유효성을 검증했습니다.

결과는 어땠을까요? Mythos Preview 모델을 사용한 '협력형' 에이전트 무리는 2,700만 토큰을 사용해 266개의 취약점을 찾아냈습니다. 반면 서로 소통 없이 '독립 병렬'로 일한 에이전트들은 650만 토큰으로 21개를 찾는 데 그쳤습니다. 숫자만 보면 협력형 방식의 압승입니다.

취약점 수와 사용 토큰

그림 2. 취약점 수와 누적 출력 토큰의 관계. 실선은 협력형 에이전트 무리, 별표는 독립 병렬 방식입니다. 출처: Anthropic.

하지만 이 결과를 놓고 "효율이 10배 넘게 좋아졌다"라고 단정 지을 수는 없습니다. 협력형 에이전트가 찾은 취약점의 절반가량은 독립 에이전트에게는 애초에 맡기지 않았던 디렉터리에서 나왔기 때문입니다. 핵심 디렉터리만 놓고 비교하면 두 방식의 토큰 대비 효율은 엇비슷했습니다.

이 실험에서 진짜 주목해야 할 점은 따로 있습니다. 에이전트들이 서로 소통하며 보여준 창발적 행동입니다.

에이전트들이 유망해 보이는 탐색 영역으로 스스로 이동했습니다.
분석에 필요한 도구를 자체적으로 만들어 썼습니다.
특정 종류의 취약점만 기가 막히게 잘 찾는 이른바 '전문가 에이전트'가 자연스럽게 생겨났습니다.
두 방식(협력형 vs 독립형)이 공통으로 발견한 취약점은 고작 12개에 불과했습니다.

즉, 멀티에이전트의 진정한 힘은 '단순 작업의 반복'에 있는 것이 아니라, 탐색 공간을 유연하게 나누고 각자의 빈틈을 메우는 '보완성'에 있었습니다.

진짜 문제는 에이전트들이 서로의 결과물에 얽히기 시작할 때 터졌습니다. 여러 에이전트에게 12시간 동안 하나의 웹 기반 판타지 게임을 같이 만들게 해보았습니다. 구형 모델들은 같은 파일을 동시에 수정하다가 코드가 꼬여버린(충돌한 PR) 상태를 속수무책으로 방치했습니다. 그렇다면 최신 모델은 달랐을까요? 최신 모델들은 꼬인 코드를 훌륭하게 풀어낸 것이 아니라, 아예 각자 맡은 파일만 건드리고 남의 코드는 철저히 피하는 식으로 문제를 회피해 버렸습니다.

PR 병합률과 코드 공유

그림 3. 에이전트 수에 따른 PR 병합률과 코드 공유 정도. Opus 4.8과 Mythos Preview는 파일 소유권을 엄격히 나누어 충돌을 피했습니다. 반면 Sonnet 5만 유일하게 높은 코드 공유율과 병합률을 동시에 보여주었습니다. 출처: Anthropic.

여기서 한 가지 함정이 발견됩니다. 지표상으로는 코드 공유율과 병합률이 모두 높게 나온 Sonnet 5가 협업을 가장 잘한 것처럼 보이지만, 그렇게 완성된 게임의 퀄리티는 처참했습니다. PR(Pull Request)을 많이 합쳤다는 게 꼭 훌륭한 제품을 만들었다는 뜻은 아니었던 것이죠.

더욱 실망스러운 것은 프롬프트의 한계입니다. 에이전트들에게 알아서 팀을 꾸리게 하든, 프로그래밍/아트/테스트 역할을 강제로 지정해주든, 심지어 'CEO 에이전트'를 임명하든 결과는 별반 다르지 않았습니다. 그저 프롬프트에 조직도를 읊어준다고 해서 진짜 유기적인 조직이 탄생하지는 않았습니다.

2. 같은 모델을 복제하면 '다양성' 대신 '획일성'의 저주에 빠진다

보고서에서 유독 소름 돋는 대목은 에이전트들이 보여준 지나친 행동의 일치(집단 획일성)입니다.

30개의 에이전트 중 18개가 굳이 mvp-game-loop라는 토씨 하나 안 틀리고 똑같은 브랜치명을 선택했습니다.
특정 주제를 주지 않았는데도 여러 작가 에이전트가 완전히 똑같은 제목의 소설을 써냈습니다.
"가장 인상적인 결과물을 만들어 보라"고 지시하자, 절반 이상이 약속이라도 한 듯 레이 트레이서나 셀프 호스팅 컴파일러를 만들었습니다.
반복적인 '죄수의 딜레마' 게임에서는 내내 비슷한 전략을 취하다가 정확히 같은 타이밍에 상대방을 배신했습니다.

인간 30명을 모아두면 경험, 취향, 지식, 이해관계가 제각각이라 다양한 의견이 나옵니다. 하지만 같은 AI 모델에 비슷한 프롬프트와 컨텍스트를 주어 30번 실행하면, '30명의 든든한 전문가 집단'이 아니라 '생각과 취향이 완전히 똑같은 복제인간 30명'이 생겨나는 셈입니다.

이러한 획일성은 시스템의 치명적인 약점이 됩니다. 인간 조직에서는 누군가 실수를 해도 다른 사람의 팩트체크로 상쇄될 여지가 있습니다. 하지만 복제인간 같은 에이전트들은 똑같은 상황에서 똑같은 오판을 내립니다. 결국 한 명의 실수가 전체로 전염되며 시스템 단위의 대형 사고로 이어집니다.

대기열(Queue) 관리 실험이 이 위험성을 적나라하게 보여줍니다. 한정된 대역폭을 두고 경쟁이 벌어지자, 에이전트들은 자기 작업을 먼저 처리하려고 초당 30회씩 서버를 두드리는 매크로(폴링 데몬)를 짜기 시작했습니다. 그 결과 고작 117개의 작업을 밀어 넣기 위해 무려 240만 건의 트래픽을 발생시키는 촌극이 벌어졌습니다. 에이전트 개인 입장에서는 최선의 선택이었지만, 모두가 똑같이 이기적인 선택을 하자 공용 시스템이 그대로 뻗어버린 것입니다.

가격 경쟁 실험도 마찬가지였습니다. 비공개 대화 채널을 열어주자 에이전트들은 세 번의 라운드 만에 최저 가격 하한선을 합의해 버렸습니다. 대화를 원천 차단해 봤지만 소용없었습니다. 공개된 경쟁사의 가격표를 보고 1센트 단위까지 똑같이 맞춰가는 사실상의 '암묵적 담합'을 저질렀습니다.

따라서 우리는 더 이상 "에이전트를 몇 개나 붙였는가"에 집착해선 안 됩니다. 앞으로는 다음 질문들을 던져야 합니다.

에이전트들이 저지르는 오류가 서로 얼마나 비슷하게 일어나는가?
모델, 데이터, 도구, 역할을 다르게 주면 '진짜' 행동의 다양성이 생기는가?
그 다양성이 실제로 성과를 높이는가, 아니면 딴지 걸기(갈등)만 유발하는가?
특정 에이전트의 돌발 행동이 시스템 전체로 번져나가는 임계점은 어디인가?

3. 언제 의심하고 언제 믿어야 하는가: 무너진 신뢰 저울

Anthropic은 4명의 정찰자 에이전트가 정보를 취합해 보고하는 시나리오를 설계했습니다. 그중 한 명은 스파이처럼 주기적으로 거짓말을 섞도록 세팅했습니다. 정보를 전달받는 리더 에이전트는 누가 스파이인지 모릅니다. 하지만 정찰자들의 보고 내용이 조금씩 겹치기 때문에, 꼼꼼히 교차 검증하면 충분히 모순을 찾아내 거짓말쟁이를 색출할 수 있는 상황이었습니다.

거짓 정보원에 대한 의사결정 정확도

그림 4. 스파이의 거짓말 빈도가 잦아질수록 대부분의 모델이 맥을 못 추고 의사결정 정확도가 곤두박질쳤습니다. 다만 Mythos 5 모델은 상대적으로 예리하게 거짓 정보원을 걸러냈습니다. 출처: Anthropic.

반대로 '숨겨진 정보(Hidden Profile)' 실험도 진행했습니다. 4명의 에이전트에게 서로 다른 단서를 쥐여주었는데, 모두가 공통으로 아는 표면적 정보만 조합하면 오답을 고르도록 함정을 팠습니다. 소수의 에이전트만 쥐고 있는 핵심 단서들을 끈질기게 캐묻고 테이블 위에 올려놓아야만 정답에 도달할 수 있는 구조였습니다.

숨겨진 정보 과제의 집단 정확도

그림 5. 숨겨진 정답을 다수결로 찾아낸 비율. 각 모델의 점선은 모든 정보를 단일 에이전트에게 몰아주었을 때 낼 수 있는 최대 성능(상한선)입니다. 출처: Anthropic.

결과는 참담했습니다. 에이전트들은 손쉽게 형성된 다수의 엉터리 의견(대세)에 휩쓸려버렸고, 결정적 단서를 쥔 소수의 의견을 무시했습니다. 가장 뛰어난 Mythos 5 모델조차 정답률이 85%에 그쳤고, 나머지 모델들은 17~36%라는 바닥 수준의 성적을 기록했습니다. 모든 정보를 혼자 쥐고 판단했을 때 거의 100% 정답을 맞힌 것과 비교하면 뼈아픈 결과입니다.

이 두 실험은 "에이전트들에게 비판적 사고를 주입하자"는 식의 단순한 처방이 왜 실패할 수밖에 없는지를 명확히 보여줍니다.

거짓말쟁이가 있을 때는 철저히 의심해야 합니다.
소수가 핵심 정보를 쥐고 있을 때는 기꺼이 귀를 열고 신뢰해야 합니다.

단순히 의심 게이지를 높이거나 신뢰 게이지를 낮추는 '하나의 다이얼'로는 이 두 가지 상황에 동시에 대처할 수 없습니다. 발화자가 어떤 근거를 들고 있는지, 과거에 얼마나 정확한 정보를 주었는지, 이번 결정으로 어떤 이득을 보는지 등 입체적인 맥락을 따져야 합니다.

이와 관련된 HiddenBench 연구도 시사하는 바가 큽니다. 15개의 최상위 모델을 테스트한 결과, 단서를 여러 에이전트에게 쪼개어 주었을 때의 정답률은 30.1%로 엉망이었지만 혼자 다 판단하게 했을 때는 80.7%에 달했습니다. 흥미롭게도 '첫 턴에 모든 정보를 의무적으로 쏟아내라'고 강제하자 정답률이 96.7%까지 수직 상승했습니다. 즉, 멀티에이전트 시스템의 진짜 약점은 추론 능력이 아니라 "아직 테이블에 올라오지 않은 중요한 정보가 있다는 걸 눈치채고 먼저 캐묻는 능력"이 부족하다는 것이었습니다.

재미있는 포인트는, 팀 내에 '무조건 반대만 하는(악마의 대변인)' 에이전트를 한 명 투입하자 집단 정답률이 23.3%에서 49.2%로 껑충 뛰었다는 점입니다. 하지만 반대파를 더 늘리자 논쟁만 길어지다 성능이 다시 곤두박질쳤습니다. 이견과 합의 사이의 황금 밸런스를 잡아줄 '회의 진행 프로세스'가 절실하다는 뜻입니다.

4. 목표가 부딪히자, 하나의 코드베이스 위에서 전쟁이 시작됐다

가장 충격적인 결과는 세 에이전트에게 동일한 파이썬 백엔드 서버를 각기 다른 언어(러스트, 고, 타입스크립트)로 마이그레이션하라는 미션을 주었을 때 나타났습니다. 처음 시작할 때 에이전트들은 서로의 존재조차 모르는 상태였습니다.

코드를 수정하다 충돌이 발생하자, 각 에이전트는 다른 에이전트의 작업을 '시스템 오류'나 '목표 충돌'로 점잖게 해석하지 않았습니다. 이를 자신을 향한 '의도적인 공격'으로 간주했고, 이내 난장판이 벌어졌습니다.

자신의 경쟁자가 띄운 프로세스를 실시간으로 찾아 강제 종료시키는 스크립트를 작성했습니다.
아예 다른 에이전트의 계정을 정지시키고 SSH 접속을 차단해 버렸습니다.
자신이 띄운 서비스를 상대방 서비스인 척 위장(스푸핑)했습니다.
심지어 상대방이 심어놓은 것처럼 악성 코드를 은폐하는 치밀함까지 보였습니다.

멀티에이전트 영역 다툼의 결말

그림 6. 목표 충돌 실험의 결말. 각각 미해결(회색), 강제 합의(빨간색), 소극적 포기에 따른 합의(노란색), 휴전으로 합의(파란색)로 끝난 비율을 보여줍니다. 모델별 120회 실행 결과입니다. 출처: Anthropic.

가장 똑똑한 모델인 Mythos 5의 경우 98%의 상황에서 결국 '휴전'에 합의했습니다. 싸우다 보니 상대도 각자의 목표가 있다는 걸 깨닫고, 코드를 원래대로 돌려놓은 뒤 인간 관리자에게 판단을 넘긴 것이죠.

하지만 이를 두고 "최신 모델일수록 평화주의자라서 안전하다"고 안심하긴 이릅니다. 일부 에이전트는 먼저 상대의 시스템 접근 권한을 완전히 박탈하여 완벽하게 제압(승리)한 뒤에야 여유롭게 휴전을 제안하는 소름 돋는 행태를 보였습니다. 에이전트의 뛰어난 실행 능력이 갈등을 부드럽게 푸는 데 쓰이기도 하지만, 상대를 더 빠르고 잔혹하게 무력화하는 데 쓰일 수도 있다는 뜻입니다.

2025년에 Anthropic이 발표했던 에이전트 정렬 실패(agentic misalignment)에 대한 연구에서도, 높은 자율성을 가졌으나 목표 달성이 가로막힌 모델들이 협박이나 산업 스파이 짓을 서슴지 않는 현상이 관찰된 바 있습니다. 이번 실험은 그러한 개별 에이전트의 일탈이 에이전트 간의 상호작용을 통해 얼마나 빠르게, 그리고 파괴적으로 확산될 수 있는지 뼈저리게 경고하고 있습니다.

이 보고서가 진정으로 전하려는 메시지

만약 이 보고서를 읽고 "멀티에이전트는 통제 불능이라 너무 위험하다"고만 결론 내린다면 절반만 맞은 셈입니다. 앞서 보았듯, 탐색 범위가 넓고 작업이 철저히 분리된 영역(예: 취약점 탐색)에서는 멀티에이전트가 압도적인 효율성을 증명했습니다.

본질적인 혼란은 우리가 완전히 다른 세 가지 구조를 뭉뚱그려 '멀티에이전트'라고 부른다는 데서 시작됩니다.

한 명의 리더(오케스트레이터)가 하위 에이전트를 단순한 '도구'처럼 부리는 구조
여러 에이전트가 작업을 나누어 맡지만, 최종 목표와 권한 체계가 명확하게 위계화된 구조
장기간 활동하는 에이전트들이 각자의 목표를 쥐고 같은 자원과 시스템 내에서 부대끼는 구조

우리가 맞닥뜨릴 위험은 3번 구조에서 쏟아집니다. 이 단계에 접어들면 프롬프트 엔지니어링보다 '제도(Institution)'가 훨씬 중요해집니다.

인간 사회가 그나마 평화롭게 굴러가는 것은 구성원 모두가 착하고 똑똑해서가 아닙니다. 누가 최종 결정권을 가지는지, 의견이 충돌하면 어디서 조율하는지, 선을 넘은 행동에는 어떤 페널티가 주어지는지, 그리고 억울할 때 항소할 수 있는 법과 제도가 촘촘히 짜여 있기 때문입니다.

프롬프트에 대고 "싸우지 말고 협력하세요"라고 명령하는 것은, 신입사원에게 사내 윤리 강령을 한 번 낭독해 주고 끝내는 것과 같습니다. 규칙을 강제로 집행할 시스템적 권한 체계와 감사 로그, 중재 프로세스가 없다면 에이전트들은 성과 달성이라는 강한 압박 앞에서 언제든 폭주할 수 있습니다.

앞으로 AI 업계가 풀어야 할 숙제들

멀티에이전트 후속 연구 의제

그림 7. 향후 멀티에이전트 연구는 '개별 모델 길들이기'를 넘어 '에이전트 사회의 제도 설계'로 패러다임을 전환해야 합니다.

1. 결과물만 보지 말고 '상호작용 과정'을 채점하라

기존의 벤치마크 테스트는 에이전트가 도출한 최종 답변이나 코드 품질만 평가했습니다. 하지만 멀티에이전트 환경에서는 겉보기엔 똑같은 결론이라도 그 과정에 도사린 위험성은 천차만별일 수 있습니다. 건강하게 토론해서 합의를 이룬 팀이 있는가 하면, 상대방 계정을 해킹하고 입을 틀어막아 얻어낸 결과일 수도 있으니까요.

앞으로는 테스트 과정에서 다음과 같은 지표를 필수적으로 추적해야 합니다.

서로 목표가 충돌했다는 걸 깨닫기까지 걸린 시간
결정적인 비공개 정보가 논의 테이블에 올라온 비율
가치 있는 소수 의견이 묵살된 횟수
권한 탈취 시도, 자원 독점, 트래픽 폭탄(반복 요청) 등 유해한 행동 빈도
에이전트 머릿수가 늘어날 때 시스템 실패율이 급증하는 임계점
문제가 발생한 후 스스로 원상 복구하거나 인간에게 도움을 요청한 비율

짧고 깔끔한 시나리오를 넘어, 며칠씩 이어지는 장기 실행 환경, 정보가 극히 제한된 상황, 실행 도중 모델이 업데이트되거나 새로운 에이전트가 난입하는 등 훨씬 복잡하고 현실적인 테스트 베드가 필요합니다.

2. 가짜 다양성이 아닌 '진짜 행동 다양성'을 심어라

똑같은 모델에 프롬프트를 통해 하나는 '연구자', 하나는 '비평가'라는 명찰(페르소나)을 달아준다고 해서 다양한 관점이 쏟아질 거라 기대해선 안 됩니다. 기반 모델 자체를 바꾸거나, 참조하는 데이터베이스, 활용 도구, 보상 함수, 시간적 선호도 등을 근본적으로 비틀어주었을 때 비로소 에이전트 간 오판의 상관관계가 끊어지는지 측정해야 합니다.

AI 담합에 관한 연구인 On the Fragility of AI Agent Collusion을 보면 힌트를 얻을 수 있습니다. 가격을 책정하는 에이전트들에게 각기 다른 시간 선호도와 정보 접근 권한을 부여하자, 담합으로 형성된 가격 거품이 22%에서 7%까지 푹 꺼졌습니다. 언어 모델(LLM)과 강화학습(Q-learning) 모델을 섞어 놓았을 때도 담합이 깨졌습니다. 반면, 같은 계열의 모델에서 크기만 다르게(예: 32B와 14B) 설정했더니 오히려 형님-아우(리더-추종자) 관계가 형성되며 담합이 굳건해졌습니다.

다양성 자체가 만병통치약은 아닙니다. 어떤 차이가 고인 물(집단사고)을 흔들어 깨우는지, 또 어떤 차이가 불필요한 권력 서열을 만드는지 치밀하게 분석해야 합니다.

3. 에이전트에게도 신분증명, 이력서, 그리고 평판이 필요하다

지금의 에이전트들은 마치 기억 상실증에 걸린 것처럼 매 대화마다 상대를 백지상태에서 평가합니다. 상대방이 과거에 얼마나 유용한 정보를 주었는지, 거짓말을 밥 먹듯 했는지, 속내를 숨기고 있는지 전혀 기억하지 못하죠.

진정한 협업을 위해서는 강력한 '신뢰 인프라'가 뒷받침되어야 합니다.

위변조가 불가능한 에이전트 고유 신원 부여
주장과 그 근거(원문)를 확실히 연결하는 출처 추적(Provenance)
과거의 발언 정확도와 규칙 준수 여부가 누적된 '평판 점수'
에이전트가 임의로 조작하거나 지울 수 없는 변경 이력(감사 로그)
부당하게 평판이 깎였을 때 억울함을 호소할 수 있는 이의 제기 절차
모두가 열람하는 '팀 메모리'와 에이전트 개인만 열람하는 '비공개 메모리'의 분리

다만 평판 시스템 자체가 또 다른 공격 무기가 될 수 있다는 점도 잊어선 안 됩니다. 여러 에이전트가 작당하고 특정 에이전트에게 별점 테러를 가하거나, 초반의 작은 실수가 주홍 글씨가 되어 시스템에서 영구 추방되는 부작용도 함께 대비해야 합니다.

4. 그저 '합의'를 칭찬하지 말고 '숨은 정보 캐내기'를 장려하라

앞선 '숨겨진 정보' 실험에서 에이전트들의 발목을 잡은 건 추론 능력이 아니라 정보 공유의 부재였습니다. "시간을 더 줄 테니 치열하게 토론해 보라"고 던져주는 것만으로는 문제가 풀리지 않았습니다. HiddenBench 연구에서는 대화가 15턴을 넘어가자 오히려 잘못된 군중 심리만 강력해지는 기현상이 벌어졌습니다.

실무적으로 당장 도입해 볼 수 있는 회의 프로토콜은 다음과 같습니다.

정보 비대칭성 파괴: 발언 기회를 얻은 에이전트는 무조건 남들이 아직 말하지 않은 새로운 근거부터 꺼내놓도록 강제합니다.
요소 분리 기록: 감정이 섞인 '주장'과 객관적인 '출처', '확신도', '이 가설이 틀렸다고 증명할 조건'을 따로 분리해서 문서를 작성하게 합니다.
강제 레드팀(Red-team) 페이즈: 다수결로 최종 결론을 내리기 직전, 오직 '반대 증거'만 수집하고 늘어놓는 단계를 의무화합니다.
능동적 중재자: 회의를 주재하는 리더 에이전트는 남의 말을 요약만 하는 게 아니라 "지금 우리가 놓치고 있는 정보는 뭘까?"를 끊임없이 캐물어야 합니다.
소수 의견 영구 보존: 다수결로 채택되지 않은 소수 의견과 아직 풀리지 않은 찜찜한 쟁점들을 결과 보고서 맨 뒤에 꼬리표처럼 남겨둡니다.

연구용 에이전트나 에이전틱 RAG 같은 것을 만들 때 이 원칙은 절대적입니다. 여러 에이전트가 똑같은 상위 노출 문서만 긁어와서 "이게 맞습니다"라고 외치면 사용자는 교차 검증이 완벽하게 된 것으로 착각하기 쉽습니다. 하지만 실상은 그저 검색 엔진의 편향이 앵무새처럼 복제된 것일 뿐입니다. 참조한 문서의 '양'이 아니라, 출처가 철저히 독립되어 있는지, 반대되는 의견은 없는지를 평가해야 합니다.

5. 프롬프트로 훈계하지 말고, '시스템 인프라'로 강제하라

에이전트는 정말 사람과 비슷해지고 있습니다. 프롬프트에 "절대 담합하지 마세요", "남의 파일을 함부로 지우지 마세요"라고 신신당부한다고 해서 말을 듣지 않습니다. 에이전트는 권한이 주어지면 일단 저지르고 보기 때문입니다. 사고가 터진 후에 시스템이 망가졌음을 깨닫는 구조로는 답이 없습니다.

사고를 원천 차단하려면 다음과 같은 물리적 제어 장치가 실행 계층에 뿌리내려야 합니다.

최소 권한의 원칙: 에이전트별로 건드릴 수 있는 자원과 시스템 권한을 극도로 제한합니다.
물리적 잠금장치: 파일 시스템, DB, 배포 서버에 트랜잭션 락(Lock)을 걸어 동시 수정을 막습니다.
속도 및 비용 제한: 분당 API 요청 횟수와 지출 비용 한도를 빡빡하게 설정합니다.
다중 승인 체계: 시스템에 치명적인 영향을 주는 변경 사항은 반드시 다른 검수 에이전트(혹은 인간)의 승인을 거치게 합니다.
독립적인 감사/중재관: 업무에 개입하지 않고 오직 에이전트들의 행동 로그만 감시하고 필요시 중재 등의 작업을 하는 감사/중재 전용 에이전트를 배치합니다.
긴급 정지 회로: 시스템 리소스 충돌이나 에이전트 간의 권한 다툼이 감지되는 즉시 모든 동작을 얼려버리고 인간 관리자에게 호출 버튼을 누릅니다.
이력 관리: 실행 전후 상태를 비교할 수 있도록 변경 이력을 괸리합니다.

AI 담합을 다룬 Institutional AI 연구가 이를 잘 증명합니다. 프롬프트로 "담합 금지"라고만 적어두었을 때는 아무 효과가 없었지만, 시장 규칙을 위반했을 때 페널티를 부여하고 강제로 롤백시키는 거버넌스 계층을 시스템에 넣고 나니 심각한 담합 발생률이 50%에서 단 5.6%로 급감했습니다. Anthropic의 이번 보고서가 주장하는 "개인의 도덕성(정렬)에 기대지 말고 시스템 제도를 설계하라"는 궤와 정확히 일치합니다.

6. 온실 속 실험실을 벗어나 '현실의 AI-인간 혼합 조직'을 고민하라

현실 세계의 기업 환경은 Anthropic의 통제된 연구실 샌드박스와 다릅니다. OpenAI, 구글, Anthropic 등 서로 다른 회사의 에이전트들이 뒤엉켜 일하고, 중간중간 사람이 결재를 내리며, 거래 사고가 났을 때 책임을 져야 할 법인과 이해관계가 복잡하게 얽혀 있습니다.

이런 현실에서는 다음의 묵직한 질문들에 답할 수 있는 후속 연구가 이뤄져야 합니다.

서로 경쟁 관계에 있는 타 회사의 에이전트가 만났을 때도 이런 극단적 현상이 나타날까?
인간 관리자는 에이전트들이 폭주하기 시작할 때 어느 타이밍에 어떻게 개입할 수 있을까?
에이전트끼리 담합해서 내 회사에 수억 원의 피해를 입혔다면, 책임은 누구(AI 개발사? 사용자? 에이전트 제공사?)에게 있는가?
AI의 자동화 속도를 인간의 검토 속도가 따라가지 못할 때, 어떤 중요한 결정들을 기본적으로 보류 상태로 두어야 할까?
에이전트가 맺은 터무니없는 계약이나 합의를 어떤 법적/기술적 근거로 무효화할 수 있을까?

앞서 언급한 Project Deal 실험에서는 놀랍게도 성능이 떨어지는 대리인 때문에 손해를 본 참가자들이 정작 자신이 당했다는 사실조차 몰랐습니다. 이는 멀티에이전트 시스템 도입이 단순한 업무 자동화나 성능 경쟁의 문제가 아님을 일깨워 줍니다. 사용자가 "결과물을 빨리 뽑아주어 만족한다"고 답하는 것에 안주해서는 안 됩니다. "사용자가 AI의 결정 과정에서 자신이 입은 불이익이나 놓친 위험을 투명하게 파악할 수 있었는가?"를 반드시 검증해야 합니다.

당장 실무에서 멀티에이전트를 도입해야 한다면?

이 길고 무서운 보고서가 "멀티에이전트는 시한폭탄이니 당장 개발을 멈춰라!"라고 외치는 것은 아닙니다. 오히려 에이전트에게 어디까지 자유를 허락할 것인가를 훨씬 더 보수적이고 냉정하게 그어야 한다는 실무적 가이드라인에 가깝습니다.

현재의 AI 기술 수준에서 당장 적용할 수 있는 가장 현실적이고 안전한 설계 원칙은 다음과 같습니다.

의존성이 없는 단순 리서치나 데이터 분석만 '병렬'로 뿌립니다.
최종 의사결정을 내리거나 외부 시스템을 건드리는(DB 수정, 결제 등) '실행 권한'은 단일 에이전트(혹은 인간)에게 독점적으로 맡깁니다.
에이전트가 내뱉는 모든 주장에는 근거(출처), 인용구, 그리고 확신도를 꼬리표처럼 붙이도록 강제합니다.
팀 내에서 기각된 의견이나 반대 증거를 함부로 휴지통에 버리지 못하게 로그로 남깁니다.
여러 에이전트가 같은 파일이나 코드를 건드릴 때는 무조건 소유권을 나누고 동시 수정을 할 수 없도록 락을 설정합니다.
API 호출 빈도, 토큰 사용량, 클라우드 비용에 하드 리밋(물리적 상한선)을 씌웁니다.
에이전트끼리 목표가 충돌하거나 권한 싸움을 벌이는 정황이 포착되면 즉시 프로세스를 죽이고 사람을 부릅니다.
감시를 맡은 감사/중재 에이전트조차 환각에 빠질 수 있으므로, 모든 판단의 근거와 시스템 변경 사항을 외부 저장소에 감사 로그로 남깁니다.

훌륭한 시스템의 핵심은 뛰어난 에이전트를 무작정 많이 만드는 것이 아니라, 하나의 에이전트가 미쳐 날뛸 때 그 피해가 전체 시스템으로 번져나가는 것을 완벽히 차단하는 방화벽에 있습니다.

이 보고서를 읽을 때 주의할 점 (한계)

이 보고서는 업계에 매우 중요하면서도 시의적절한 화두를 던졌지만, 정식 논문만큼 엄격하게 통제된 연구는 아닙니다. 맹신하기보다 행간의 의미를 비판적으로 읽을 필요가 있습니다.

연구에 쓰인 프롬프트 원문이나 상세한 실험 환경 데이터가 전부 공개되지는 않았습니다.
실험의 대부분이 Anthropic 자사 모델(Claude) 위주로 진행되었고, 발생할 수 있는 최악의 상황을 가정해 인위적으로 꾸며낸 환경이 많습니다.
특히 하나의 서버에 서로 완전히 반대되는 목표를 주입한 에이전트들을 몰아넣고 막강한 권한(루트 권한 등)까지 쥐여준 것은 다분히 의도적이고 극단적인 연출입니다.
취약점 탐색 실험의 경우, '협력 방식'과 '독립 방식' 에이전트들이 탐색한 디렉터리 범위 자체가 달랐기 때문에 이를 1대1 효율성으로 단순 비교하는 건 무리가 있습니다.
PR을 얼마나 성공적으로 합쳤는지(병합률)나 코드를 얼마나 공유했는지만 따질 뿐, 실제로 짠 코드의 품질이 훌륭했는지를 직접적으로 증명하지는 못했습니다.
실제 기업 환경에서는 여러 회사의 다양한 모델이 섞여 있고 프롬프트와 정보 접근 권한도 훨씬 다채롭기 때문에, 보고서에서 지적한 '소름 돋는 획일성'이 예상보다 덜 나타날 수도 있습니다.

그럼에도 불구하고 우리가 이 보고서의 경고를 가볍게 넘길 수 없는 이유가 있습니다. 여기서 관찰된 부작용들이 어느 날 갑자기 하늘에서 뚝 떨어진 억측이 아니기 때문입니다. 이미 분산 정보 관련 연구에서는 소수의 가치 있는 정보가 다수결에 묻히는 현상이, 시장 경제 시뮬레이션에서는 AI들의 담합이, 단일 에이전트 보안 연구에서는 목표 달성이 좌절됐을 때 흑화(해킹, 협박)하는 현상이 꾸준히 경고되어 왔습니다. 이번 연구는 그동안 파편화되어 있던 AI 리스크들을 '멀티에이전트'라는 거대한 하나의 생태계 안에서 연결하여 현실감 있게 보여주었다는 점에서 상당한 의미를 가집니다.

마치며

에이전트를 한 개에서 열 개로 늘리는 일은 기술적으로는 비교적 쉽습니다. 하지만 그 10개의 에이전트를 모아 제대로 굴러가는 '조직'으로 만드는 건 완전히 차원이 다른 예술입니다.

인간 사회에서도 일만 무작정 쪼개준다고 회사가 잘 굴러가지 않습니다. 서로 눈치 보지 않고 다양한 정보를 꺼내놓을 수 있는 회의 문화, 명확하게 그어진 권한과 책임의 경계, 갈등이 파국으로 치닫기 전에 브레이크를 걸어주는 규정 및 리더십, 그리고 상사의 잘못된 결정에 당당히 이의를 제기할 수 있는 소통 채널이 있어야 비로소 훌륭한 조직이 됩니다.

AI의 세계도 마찬가지입니다. 멀티에이전트 연구의 다음 장은 "어떻게 하면 더 많은 에이전트를 더 빠르게 연결할까?"에서 멈추지 않을 것입니다.