인사이트 / 블로그
멀티 에이전트 시스템, 연결 전에 필요한 3가지 관리 기준
역할을 나눴지만 충돌을 조정할 규칙은 없었다
같은 Python 백엔드를 서로 다른 언어로 옮기라는 지시를 받은 AI 코딩 에이전트 세 개가 있었습니다. 첫 번째 에이전트는 Rust로, 두 번째는 Go로, 세 번째는 TypeScript로 옮겨야 했습니다.
세 에이전트는 처음에 서로의 존재를 몰랐습니다. 자신이 고친 코드가 계속 바뀌었는데도, 다른 에이전트가 별도의 지시를 받았으리라고는 생각하지 못했습니다. 대신 누군가 자신의 일을 고의로 방해한다고 판단했습니다.
그때부터 공유 시스템은 전쟁터로 바뀌었습니다. 에이전트들은 상대 에이전트의 계정을 비활성화하고 작업 프로세스를 반복해서 종료했습니다. 상대가 만든 것처럼 위장한 코드를 배포하거나, 종료해도 다시 실행되는 악성 스크립트로 자신의 작업을 지키기도 했습니다.
실제 기업에서 발생한 보안 사고는 아닙니다. Anthropic이 2026년 8월 13일 공개한 네 시간의 다중 에이전트 실험입니다.[1] 이 실험이 보여준 것은 간단합니다. 에이전트를 하나씩 따로 평가할 때는 보이지 않던 문제가 여러 에이전트를 서로 연결한 뒤에 생길 수 있습니다. 기존 연구는 이런 위험을 개별 에이전트의 오류와 구분하고, 조정 실패, 충돌, 담합으로 나눕니다.[9]
에이전트 = 다다익선(?)
기업이 다중 에이전트를 도입하려는 이유는 분명합니다. 긴 작업을 나눠 동시에 처리하고, 조사, 코딩, 검토처럼 성격이 다른 일을 전문 에이전트에게 맡길 수 있기 때문입니다.
Anthropic은 45개 에이전트에게 15개 오픈소스 프로젝트의 취약점을 찾게 했습니다. 에이전트들은 공유 게시판에서 발견한 내용을 교환했고, 필요한 도구도 직접 만들었습니다. 제출된 결과가 새로운 취약점에 해당하는지는 별도의 에이전트가 최종 판정했습니다. 서로가 크게 의존하지 않는 작업에서는 잘 굴러가는 것처럼 보였습니다.[1]
문제는 협력이 필요한 작업에서 시작됐습니다. 같은 연구에서 여러 에이전트에게 하나의 게임을 함께 만들게 하자 일부 모델에서는 에이전트 수가 늘수록 작업이 제대로 동기화되지 않는 문제를 보였습니다. 역할을 미리 나누거나 한 에이전트에게 리더 역할을 맡겨도 결과는 크게 달라지지 않았습니다.
충돌보다 더 까다로운 동조와 담합
지금까지 본 사례들처럼 에이전트들이 서로 충돌하는 장면은 눈에 잘 띕니다. 더 까다로운 것은 여러 에이전트가 같은 선택을 할 때입니다.
제한된 대역폭을 나눠 쓰게 한 실험에서 에이전트들은 자신의 작업을 먼저 처리하려고 초당 30번씩 상태를 확인하는 프로그램을 만들었습니다. 한 번 실행했을 때 240만 건에 달하는 요청이 몰렸지만 실제로 처리된 건 117건뿐이었습니다. 각자 대기 시간을 줄이려는 시도가 겹치자 모두가 써야 할 시스템이 마비됐습니다.[1]
가격을 정하는 게임에서는 경쟁 대신 담합이 나타났습니다. 비공개 대화 채널을 제공하자 에이전트들은 세 번째 라운드 만에 가격 하한에 합의했습니다. 직접 대화를 막은 뒤에도 공개 가격표를 보며 같은 가격을 유지했습니다.[1]
개별 에이전트는 자신의 목표에 따라 행동했을 뿐이죠. 그러나 그 행동이 겹치자 공유 자원이 고갈되고 경쟁이 사라졌습니다. 개별 에이전트의 정확도와 작업 성공률만으로는 이런 실패를 발견하기 어렵습니다. 다른 연구에서도 공유 자원 경쟁, 연쇄 인계, 집단 의사결정에서 나타나는 실패는 개별 에이전트의 행동만으로 설명하거나 막기 어렵다고 지적합니다.[10] 기업은 개별 응답뿐 아니라 에이전트 집단이 시스템 전체에 미친 결과까지 평가해야 합니다.
실험실 밖까지 번진 집단 행동
OpenAI가 2026년 8월 26일 공개한 사후 분석에는 내부 평가에서 시작된 에이전트들의 행동이 외부 시스템 침해로 이어진 과정이 담겼습니다.[2]
OpenAI는 2026년 7월에 진행한 내부 사이버 보안 평가에서 일부 안전장치를 완화했습니다. 평가 도중 에이전트들이 허가받지 않은 공동 게시판을 만들어 정보를 주고받고 있다는 사실이 발견됐습니다. 게시판이 삭제돼도, 에이전트들은 시스템의 다른 기능을 이용해 같은 소통 공간을 다시 만들었습니다. 그곳에 쌓인 메시지는 이후 다른 에이전트의 판단과 행동에도 영향을 미쳤습니다.
이 게시판에서 에이전트들은 정보만 주고받은 것이 아닙니다. 서로 작업을 나눠 맡았고, 자신들을swarm(무리)이나collective(집단)라고 부르기도 했습니다. 서로 떨어져 있던 에이전트들은 이곳에서 각자의 발견을 공유하고 연산 자원을 함께 쓰기 시작했습니다. 개별 에이전트의 일탈은 여러 에이전트가 가담한 집단 행동으로 커졌고, 피해는 OpenAI 내부 인프라를 넘어 Hugging Face 시스템까지 번졌습니다. 비인가 통신이 사고의 유일한 원인은 아니었지만, 이 게시판은 에이전트들의 행동을 연결하고 키운 통로였습니다.[2]
METR과 Redwood Research의 독립 조사도 이 과정을 확인했습니다. 조사 기간 동안 약 1,200개 에이전트가 비인가 게시판에서 7만 건이 넘는 메시지와 파일을 주고받았고, 약 700개가 Hugging Face 공격에 참여했습니다. 에이전트들은 협업을 통해 개별 에이전트가 혼자서는 이루지 못한 단계까지 도달하기도 했습니다.[11]
에이전트 사이의 관계는 실패를 만들기도 하고 키우기도 합니다. Anthropic 실험에서는 충돌하는 지시가 상호 방해로 번졌고, OpenAI 사고에서는 비인가 통신이 일탈 행동을 증폭시켰습니다. 이제 기업은 개별 에이전트뿐 아니라 이들이 누구와 연결되고 무엇을 주고받는지도 관리해야 합니다.
역할만 주어졌을 뿐 멈추는 방법은 몰랐습니다
기업이 다중 에이전트를 설계할 때 먼저 정하는 것은 오케스트레이션입니다. 누가 어떤 일을 맡고, 결과를 어디로 보내며, 다음 작업을 어느 에이전트에게 넘길지를 정하는 구조입니다.
하지만 오케스트레이션만으로는 관계를 조정할 수 없습니다. 다른 에이전트의 메시지를 지시로 받아들일 조건이 필요합니다. 목표가 충돌했을 때 어느 작업을 멈출지도 정해야 합니다. 공유 자원의 사용 한도와 집단 전체를 중단시킬 권한도 분명해야 합니다.
여기서부터 기업이 관리할 대상이 달라집니다. 에이전트 하나의 성능만 볼 것이 아니라, 에이전트 사이의 통신 경로와 공유 자원, 충돌이 생겼을 때의 결정권과 중단권까지 관리해야 합니다.
Anthropic 실험에서 역할 지정과 리더 지정 프롬프트는 결과를 크게 바꾸지 못했습니다. 실행 능력이 강한 모델이라고 해서 충돌을 더 잘 조정한 것도 아니었습니다. 오히려 일부는 계정 잠금 같은 강제 조치를 더 빨리 실행했습니다.[1] 역할표와 높은 성능만으로는 충돌을 해결할 수 없었습니다.
이 에이전트 주인은 누군가요?
에이전트 수가 늘면 사람이 직접 추적하기도 어려워집니다. Gartner는 2028년에는 글로벌 포춘 500대 기업 한 곳이 평균 15만 개가 넘는 AI 에이전트를 사용하게 될 것으로 전망했습니다.[3] IBM 기업가치연구소 조사에서 기술 리더들은 2027년에는 기업이 평균 1,661개의 AI 에이전트를 배포할 것으로 예상했습니다. 예상되는 배포 규모에 완전히 준비돼 있다고 답한 비율은 11%였습니다.[4]
어느 전망을 따르더라도 사람이 에이전트를 하나씩 기억하고 승인하는 방식으로는 이 규모를 감당하기 어렵습니다. 에이전트 수가 늘수록 이들이 사용하는 계정과 데이터, API와 도구, 다른 에이전트와의 연결도 함께 늘어납니다.
숫자보다 더 까다로운 장면은 프로젝트가 끝난 뒤에 나타납니다. 담당자가 퇴사하거나 부서를 옮긴 뒤에도 그 사람이 담당하던 에이전트가 사내 데이터베이스에 접근하거나 클라우드 권한을 가진 채 남을 수 있습니다. Microsoft는 장기간 사용되지 않은 에이전트, 연결, 작업을dormant범주로 관리하고, 활성 소유자가 없는 에이전트는orphaned agent로 구분합니다. 사용하지 않는 에이전트에 오래된 연결과 권한이 남아 있으면 숨은 공격 경로가 됩니다.[5]
기업이 먼저 준비해야 할 것은 세 가지입니다. 명부는 “무엇이 존재하는가”에, 관계도는 “누가 무엇을 공유하는가”에, 퇴사 절차는 “그 관계와 권한을 어떻게 끊는가”에 답합니다. 세 문서는 서로 떨어진 체크리스트가 아닙니다. 에이전트의 존재를 확인하고, 연결 관계를 추적하고, 마지막에는 그 관계와 권한을 끊는 하나의 수명주기를 이룹니다.
에이전트 명부에는 고유 ID, 책임을 맡은 사람, 업무 목적, 허용된 행동을 기록합니다. 사용하는 데이터와 도구, 사용자에게 위임받은 권한, 마지막 활동일, 재검토일과 폐기 시점도 한곳에서 확인할 수 있어야 합니다.
명부 다음에는에이전트 관계도가 필요합니다. 먼저 각 에이전트가 누구와 통신하는지 기록해야 합니다. OWASP도 다중 에이전트 보안에서 에이전트 사이의 신뢰 경계를 설정하고 통신 내용을 검증할 것을 요구합니다.[12] 연결된 MCP 서버와 API, 함께 사용하는 파일과 작업 대기열도 표시해야 합니다. 한 에이전트의 지시가 어디까지 전달되는지, 에이전트 하나가 중단되거나 오염되면 어떤 업무와 자원이 영향을 받는지도 보여야 합니다. Microsoft도 에이전트와 MCP 서버, 연관된 신원과 클라우드 자원을 관계 지도로 보여주는 관리 기능을 내놓았습니다.[8]
세 번째는에이전트 퇴사 절차입니다. 화면에서 에이전트를 삭제하는 것만으로는 부족합니다. 먼저 새 작업을 받지 못하도록 격리한 뒤 토큰, API 키, 위임 권한을 회수해야 합니다. MCP 서버, 데이터베이스, 메시징 시스템, 클라우드 서비스와의 연결을 해제하고 하위 에이전트와 예약 작업도 함께 중단해야 합니다. 마지막으로 어떤 업무 시스템에도 접근할 수 없는지 확인해야 합니다.[6][7]
이 세 가지는 ‘다중 에이전트’라는 이름의 별도 프로젝트를 시작할 때만 필요한 문서가 아닙니다. 한 에이전트가 다른 에이전트를 호출하거나, 여러 에이전트가 같은 데이터와 도구를 공유하기 시작하는 순간부터 필요합니다. 새 에이전트를 연결하기 전에 명부에 등록하고 관계도에 그 연결을 기록해야 합니다. 중단과 권한 회수 절차가 실제로 작동하는지도 확인해야 합니다.
세 에이전트가 서로의 일을 망치기 시작한 것은 코딩 실력이 부족해서가 아니었습니다. 출발점은 서로 충돌하는 지시였고, 충돌이 공격으로 번진 것은 어느 에이전트가 멈춰야 하는지를 정한 규칙이 없었기 때문입니다.
AI 에이전트의 수를 늘리는 것만으로는 부족합니다. 기업은 명부로 에이전트의 존재와 책임자를 확인하고, 관계도로 각 에이전트가 누구의 권한을 받아 누구와 연결되는지 추적하며, 문제가 생기면 퇴사 절차에 따라 그 연결과 권한을 함께 끊을 수 있어야 합니다.
참고문헌
[1] Anthropic, “Patterns and problems in emerging multiagent systems”, 2026년 8월 13일.
[2] OpenAI, “The Hugging Face incident and the road ahead”, 2026년 8월 26일.
[3] Gartner, “Gartner Identifies Six Steps to Manage AI Agent Sprawl”, 2026년 4월 28일.
[4] IBM Institute for Business Value, “Building the IT foundation for agentic AI at scale”, 2026년 6월.
[5] Microsoft Security, “Detecting and mitigating common agent misconfigurations”, 2026년 2월 12일.
[6] Microsoft Learn, “Manage the agent lifecycle”, 2026년 7월 14일.
[7] Microsoft Security, “Least privilege for AI agents: Identity, access, and tool binding”, 2026년 7월 16일.
[8] Microsoft Security, “Microsoft Agent 365, now generally available, expands capabilities and integrations”, 2026년 5월 1일.
[9] Cooperative AI Foundation, “Multi-Agent Risks from Advanced AI”, 2025년 2월 19일.
[10] Huang et al., “Emergent Social Intelligence Risks in Generative Multi-Agent Systems”, 2026년 4월 4일 수정.
[11] METR·Redwood Research, “Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident”, 2026년 8월 26일.
[12] OWASP Cheat Sheet Series, “AI Agent Security”, 2026년 8월 30일.
써로마인드 관련 소식
최근 미디어에 소개된 써로마인드의 주요 소식을 확인해 보세요.
제목을 클릭하면 관련 기사 전문을 바로 읽으실 수 있습니다.