멀티 에이전트 워크플로우는 '많이 쓸수록 빠르다'는 직관으로 시작한다. Claude Code 인스턴스 네 개를 병렬로 돌리면 네 배 빨라질 것 같다. 실제로는 다르다. dev.to에 올라온 한 인디 개발자의 실패 기록과, MCP 생태계 전반을 스캔한 보안 연구들을 나란히 놓으면, '무엇이 먼저 터지는가'의 패턴이 선명하게 보인다.
핵심 이슈: 네 번째 인스턴스를 죽인 이유
Flutter Web + Supabase 앱을 혼자 만들던 개발자는 Claude Code를 네 개의 인스턴스로 나눠 돌렸다. VSCode(UI), Windows Desktop(문서·마이그레이션), PowerShell(CI/CD), Web 인스턴스(블로그 번역·PR 리뷰). 얼핏 역할 분리가 잘 된 것처럼 보인다. 그런데 Web 인스턴스 하나가 단일 세션에서 세 가지 실패를 동시에 냈다.
첫째, GitHub MCP 연결이 세 번 끊겼다. v2.1.110 픽스가 claude.ai/code 런타임에 아직 반영되지 않아, 재연결마다 몇 분씩 날아갔다. 둘째, WebFetch를 파일 편집과 병렬로 실행했더니 스트림이 중간에 잘렸다. 세션은 복구되지 않았다. 셋째, MCP 호출이 끊기면서 docs/INSTANCE_CONFIG.md를 '파일 없음'으로 잘못 인식한 에이전트가 새 파일 생성을 시도했다. 그 파일은 PowerShell 인스턴스 소유였다. 각각은 살아남을 수 있는 실패지만, 셋이 한 세션에 겹치자 워크플로우 전체가 멈췄다. 결국 Web 인스턴스를 종료하고 세 개로 줄이는 게 답이었다.
맥락 해석: 인스턴스 수가 아니라 경계 설계가 문제다
이 실패를 '인스턴스가 너무 많았다'로 읽으면 교훈을 놓친다. 진짜 문제는 두 가지다. 하나는 MCP 레이어의 안정성이 로컬 런타임과 클라우드 런타임 사이에 아직 동기화되지 않았다는 것이고, 다른 하나는 파일 소유권 경계가 코드가 아닌 문서로만 관리되고 있었다는 것이다.
인스턴스를 네 개로 늘렸을 때, 병목은 모델 능력이 아니었다. MCP 연결 신뢰성과 에이전트 간 파일 충돌이었다. 이 개발자가 정리한 해법—파일별 소유 인스턴스 명시, [cross-instance: approval required] 커밋 태그, git add -A 대신 파일 명시적 스테이징—은 결국 에이전트가 독립적으로 판단할 수 있는 경계를 인간이 미리 하드코딩해줘야 한다는 원칙의 반복이다.
그런데 이 경계 설계 문제는 단일 팀의 로컬 이슈가 아니다. MCP 생태계 전반에서 훨씬 심각한 형태로 나타나고 있다. OX Security가 5개월간 MCP 생태계를 조사해 10개의 CVE를 제출한 결과, Anthropic의 답변은 "STDIO MCP 서버는 원래 이렇게 동작하도록 설계됐다"였다. STDIO 트랜스포트는 명령 문자열을 OS 서브프로세스로 직접 넘긴다. 문제는 MCP 핸드셰이크가 검증되기 전에 서브프로세스가 먼저 실행된다는 것이다. 리버스 셸이든 데이터 탈취 스크립트든, 핸드셰이크 실패가 반환되기 전에 페이로드는 이미 실행된다.
숫자는 이론적 우려가 아니다. AgentSeal이 스캔한 1,808개 MCP 서버 중 66%에서 보안 취약점이 발견됐고, 427개는 위험(Critical), 1,841개는 높음(High) 등급이었다. 취약점의 40%는 코드 실행 취약점이었다. Trend Micro는 인증도 암호화도 없이 공개된 MCP 서버 492개를 찾았고, 이 서버들은 데이터베이스·클라우드 플랫폼·금융 시스템에 직접 읽기 접근을 노출하고 있었다. 26,976개의 GitHub 스타를 받은 claude-flow는 254개의 MCP 도구에 인증이 없고, 생성하는 프로세스에 --dangerously-skip-permissions가 하드코딩돼 있었다.
여기에 세 번째 레이어가 겹친다. AI 에이전트 프레임워크 자체가 등록된 모든 도구를 안전 검사 없이 호출하게 허용한다는 구조적 문제다. LangChain, CrewAI, MCP 등 주요 프레임워크 모두 마찬가지다. 에이전트가 DB 접근 권한을 갖고 있으면 DROP TABLE users를 실행해도 막을 장치가 없다. AgentShield-FW 같은 런타임 방화벽이 나온 배경이 이것이다—도구 호출을 실행 전에 인터셉트해 SQL 인젝션, 경로 탐색, 셸 명령, 자격증명 유출 등 40개 이상의 규칙으로 걸러낸다.
시사점: 에이전트를 늘리기 전에 막아야 할 세 곳
세 개의 소스를 하나의 프레임으로 정리하면 이렇다. 멀티 에이전트를 확장할 때 가장 먼저 터지는 것은 세 레이어다.
1. MCP 연결 안정성: 로컬 런타임과 클라우드 런타임의 픽스 동기화 지연은 아직 현실이다. Web 기반 인스턴스를 자동화 파이프라인에 넣기 전에 MCP 재연결 복원력을 실제로 검증해야 한다. 검증 안 된 MCP 서버는 자동화 파이프라인에 넣지 않는 것이 현시점 기준이다.
2. 파일/리소스 소유권 경계: 에이전트가 판단 착오를 일으켰을 때 다른 에이전트의 영역을 침범하지 못하게 하는 경계는 코드 수준에서 강제되어야 한다. 문서로만 관리되는 소유권 정책은 MCP 호출 하나가 끊기는 순간 무의미해진다.
3. 도구 호출 레이어의 런타임 방어선: MCP 프로토콜이 STDIO 커맨드 실행을 '의도된 동작'으로 간주하는 한, 에이전트에게 넘어가는 도구 호출을 실행 전에 가로채는 레이어가 필요하다. 프레임워크가 이걸 기본으로 제공하지 않기 때문에, 팀이 직접 넣어야 한다.
전망: '에이전트 개수'보다 '에이전트 거버넌스'가 먼저다
Anthropicが MCP 보안 수정 제안 네 가지를 모두 거절한 것은, 프로토콜 수준의 안전장치를 기대하는 팀에겐 명확한 신호다. 생태계가 성숙할 때까지 이 공백은 개발팀이 직접 채워야 한다. 멀티 에이전트를 '빠른 자동화'로 접근하면 속도보다 장애가 먼저 온다. 지금 시점에서 AI-First 팀의 에이전트 확장은 인스턴스를 늘리는 작업이 아니라, 각 에이전트가 실패했을 때 시스템 전체가 어떻게 버티는가를 설계하는 작업이다. 에이전트 거버넌스가 먼저고, 에이전트 개수는 그 다음이다.