이미지: Anthropic 화면 갈무리
요약
- 앤트로픽 프론티어 레드팀이 에이전트끼리 상호작용하는 멀티에이전트 시스템의 행동 패턴을 실험했다
- 45개 에이전트가 협업한 취약점 탐색 실험에서 Claude Mythos Preview는 독립 병렬 방식보다 훨씬 많은 취약점을 찾았지만 토큰 비용도 크게 늘었다
- 게임 개발 실험에서는 프롬프트 방식을 바꿔도 결과가 나아지지 않았고, 최신 모델일수록 충돌을 피하려 협업 자체를 줄이는 경향을 보였다
- 실험1 구성
- 45개 에이전트, 각자 VM, 공유 포럼, 15개 오픈소스 프로젝트, 중재 에이전트 1개
- Mythos Preview 독립 병렬
- 취약점 21개 / 토큰 650만
- Mythos Preview 협업 군집
- 취약점 266개 / 토큰 2700만
- 두 방식 공통 발견
- 겹치는 취약점은 12개뿐
- 실험2 대상 모델
- Sonnet 4.6·5, Opus 4.6·4.8, Mythos Preview / 각 12시간 실행
- 실험2 결과
- 초기 모델은 PR 충돌로 병합률이 낮고, 최신 모델은 협업 자체를 줄여 충돌을 회피
45개 에이전트가 동시에 코드를 뒤지면
앤트로픽(Anthropic) 산하 프론티어 레드팀이 AI 에이전트끼리 상호작용하는 상황을 실험한 결과를 공개했다. 팀은 에이전트가 코드베이스와 시장, 여러 사회 시스템에서 더 많은 일을 맡기 시작하면서 에이전트 간 상호작용이 사람 간 상호작용보다 먼저 폭증할 수 있다고 봤다. 문제는 이런 상호작용이 잘 굴러가는 조건을 세상이 아직 모른다는 점이다.
이를 확인하기 위해 팀은 오픈소스 취약점 탐지 실험을 했다. 45개 에이전트에게 각자 가상머신(VM)과 공유 포럼을 주고, 15개 오픈소스 프로젝트에서 취약점을 찾으라는 동일한 지시를 내렸다. 에이전트들은 서로의 결과물을 동료 평가하고, 별도의 중재 에이전트가 제출된 취약점이 새롭고 유효한지 최종 판정했다. 이는 앤트로픽이 Project Glasswing에서 오픈소스를 스캔할 때 쓰는 접근과 이어진다.
결과는 Claude Mythos Preview와 Opus 4.8 두 모델로 비교했다. Mythos Preview 기준으로 단순 독립 병렬 방식은 650만 토큰을 써서 21개 취약점을 찾은 반면, 협업 군집 방식은 2700만 토큰을 써서 266개를 찾았다. 다만 군집이 찾은 취약점의 절반가량은 병렬 방식이 지시받은 핵심 디렉터리 바깥에서 나왔다. 핵심 디렉터리로 범위를 좁히면 두 방식의 토큰 대비 발견 효율은 비슷해진다. 두 방식이 함께 찾은 취약점은 단 12개뿐이었다.
게임을 만들게 하니 드러난 협업의 한계
서로 의존도가 높은 작업에서는 협업이 훨씬 어려워진다. 팀은 이를 확인하려 여러 에이전트 군집에게 텍스트 기반 웹 판타지 게임을 만들라는 과제를 줬다. 각 에이전트는 자신의 VM과 공유 포럼, 자체 호스팅 저장소에 접근했고, 군집은 12시간 동안 작업했다. 팀은 모델 세대와 에이전트 수를 바꿔가며, 프롬프트도 기본형·역할 지정형(프로그래밍·아트·테스트 팀 구분)·CEO 위계형 세 가지로 시험했다.
그러나 프롬프트를 바꿔도 결과는 크게 다르지 않았다. 세 방식 모두 완성된 게임은 사람 속도로 작동하지 않고, 인터페이스는 알아보기 어려웠으며, 학습 곡선이 가팔랐다. 팀은 현재 모델이 이런 창작 영역에서 취향이 떨어지고 사람의 개입이 많이 필요하다고 밝혔다.
같은 결과물이라도 모델 세대별로 협업 방식은 뚜렷하게 갈렸다. Sonnet 4.6과 Opus 4.6은 같은 파일에 코드를 커밋하며 협업하는 듯 보였지만, 병합(merge)되는 풀리퀘스트(PR) 비율이 낮았다. 서로 충돌한 코드가 방치된 채 버려졌다는 뜻이다. 반면 더 최근 모델인 Opus 4.8과 Mythos Preview는 이 병합 문제를 해결했는데, 그 방식이 서로 거의 협업하지 않는 쪽이었다.
두 실험이 보여주는 것
| 항목 | 독립 병렬 방식 | 협업 군집 방식 |
|---|---|---|
| 발견 취약점(Mythos Preview) | 21개 | 266개 |
| 사용 토큰 | 650만 | 2700만 |
| 겹치는 발견 | 12개 (공통) | 12개 (공통) |
| 모델 세대 | PR 병합 경향 | 코드 공유 패턴 |
|---|---|---|
| Sonnet 4.6, Opus 4.6 | 병합률 낮음 | 충돌 후 방치 |
| Opus 4.8, Mythos Preview | 병합률 안정 | 협업 자체를 최소화 |
두 표를 나란히 보면 흥미로운 대조가 드러난다. 취약점 탐색처럼 작업을 독립적으로 쪼갤 수 있는 문제에서는 군집 협업이 발견량을 늘렸다. 하지만 코드 저장소처럼 서로의 결과물에 의존하는 작업에서는, 모델이 똑똑해질수록 충돌을 피하려 아예 협업을 줄이는 방향으로 '적응'했다.
에디터의 시선
이 실험이 흥미로운 이유는 결과가 아니라 실패의 형태다. 게임 개발 실험에서 최신 모델이 '병합률'이라는 지표는 개선했지만, 그 방법이 진짜 협업 능력 향상이 아니라 협업 회피였다는 점이 뼈아프다. 벤치마크 숫자만 보면 발전한 것처럼 보이는데, 실제로는 문제를 우회한 것에 가깝다. 이런 지표 착시는 에이전트 평가 전반에서 계속 나올 수 있는 패턴이다.
예전에는 멀티에이전트 시스템을 이야기할 때 대부분 '몇 개를 동시에 돌릴 수 있느냐'는 규모의 문제로 접근했다. 지난 8월 8일 공개된 Kimi Agent Swarm이 최대 100개 서브 에이전트를 병렬 배포하는 데 초점을 맞춘 것도 같은 맥락이다. 하지만 이번 앤트로픽 실험은 규모보다 '어떻게 실패하는가'를 들여다봤다는 점에서 결이 다르다. 에이전트 수를 늘리는 것과, 에이전트들이 서로 의존하는 작업에서 실제로 잘 협업하는 것은 완전히 다른 문제라는 걸 보여준다.
실무적으로는 두 가지를 갈라 써야 한다. 취약점 스캔이나 데이터 라벨링처럼 작업을 독립적으로 쪼갤 수 있는 일에는 지금도 에이전트 군집을 붙여볼 만하다. 다만 토큰 비용이 병렬 방식보다 4배 이상 뛴다는 점은 감안해야 한다. 반면 여러 에이전트가 같은 코드베이스나 문서를 같이 고치는 일은, 지금 모델 세대로는 사람이 계속 병합 시점마다 개입해야 한다고 보는 게 안전하다.
앞으로 몇 달간 프론티어 랩들은 '충돌 회피'가 아니라 '진짜 조율'을 학습시키는 방향으로 훈련 신호를 바꿀 것이다. 병합률 같은 표면 지표 대신, 코드 공유 비율이나 실제 기여도처럼 협업의 질을 재는 지표가 다음 모델 카드에 등장할 가능성이 크다.
