지금 무슨 일이 벌어지고 있나
멀티 에이전트 코딩 환경이 실험실을 벗어나 팀 도입 단계로 진입하고 있다. oh-my-kimi v1.1.0은 하나의 프롬프트로 여러 에이전트를 DAG(Directed Acyclic Graph) 스케줄러 기반으로 병렬 실행하고, 각 에이전트를 격리된 git worktree에서 독립적으로 작동시킨 뒤 결과를 병합한다. 단순한 데모가 아니다. lint·typecheck·test·build를 완료 조건으로 강제하는 quality gate, 실패 시 재시도와 폴백 역할 전환, Neo4j/Kuzu 기반 로컬 그래프 메모리까지 갖췄다. 동시에 OpenAI, Anthropic, Google, Microsoft, AWS가 에이전트 인프라를 Linux Foundation에 공동 기증하며 MCP를 사실상의 에이전트 간 표준 프로토콜로 굳히고 있다. 97억 건 월간 SDK 다운로드, Claude·ChatGPT·Gemini·Cursor·VS Code 전반에 걸친 채택—단순한 기술 트렌드가 아니라 인프라 전쟁의 종전 선언에 가깝다.
병렬화의 매력, 그리고 놓치기 쉬운 함정
에이전트를 병렬로 돌리면 왜 빠를까. 기존 CLI 코딩 에이전트는 단일 스레드로 태스크를 순차 처리한다. oh-my-kimi가 보여준 것처럼, 의존성 그래프를 분석해 병렬 실행 가능한 태스크를 분리하면 전체 사이클 타임이 줄어든다. git worktree 격리 덕분에 에이전트 간 파일 충돌도 없다. 이건 실제로 효과가 있다. 문제는 병렬화 자체가 아니라, 에이전트가 많아질수록 각 에이전트가 호출하는 도구의 계약이 느슨해질 위험이 커진다는 점이다.
MCP 보안 설계: 도구 설명이 곧 보안 경계다
dev.to의 MCP 보안 아티클이 정확하게 짚은 포인트가 있다. MCP 도구 설명은 인간이 읽는 문서가 아니다. 모델이 읽고 다음 호출을 결정하는 판단 근거다. query라는 이름에 "Run SQL against the database"라는 설명만 붙어 있으면, 모델은 어떤 테이블에 접근해도 되는지, 어떤 쿼리가 위험한지 스스로 추론해야 한다. 그건 보안 설계가 아니라 모델에게 책임을 떠넘기는 것이다.
멀티 에이전트 환경에서는 이 문제가 선형으로 증가하지 않는다. 에이전트가 3개면 위험 노출 지점이 3배가 아니라, 에이전트 간 체인 호출까지 고려하면 훨씬 복잡해진다. 실용적인 대안은 단순하다. query_customer_usage_readonly처럼 목적과 범위가 이름 자체에 드러나도록 설계하고, 허용 스키마와 결과 한도를 명시하고, 거부 이유를 에이전트가 다음 액션을 결정할 수 있는 수준으로 설명하는 것이다. "Permission denied"는 사람한테도 불친절하지만, 에이전트한테는 아예 쓸모없다.
에이전트 팀 도입 시 설계해야 할 세 가지 레이어
소스 기사들을 종합하면, 멀티 에이전트 코딩팀 도입에는 세 가지 레이어가 필요하다.
첫째, 실행 격리 레이어. git worktree처럼 에이전트별 작업 공간을 물리적으로 분리해야 한다. 공유 상태가 있으면 에이전트 간 충돌과 디버깅 지옥이 동시에 온다.
둘째, 도구 계약 레이어. MCP 도구 이름·설명·스키마·에러 메시지를 모델이 안전하게 판단할 수 있는 수준으로 명시해야 한다. 도구 설명이 느슨하면 에이전트는 즉흥 연주를 시작한다. 즉흥 연주는 프로덕션에서 사고가 된다.
셋째, 완료 판단 레이어. oh-my-kimi의 quality gate처럼, 에이전트가 "완료"라고 주장하는 것과 실제로 완료된 것 사이의 간극을 결정론적 기준으로 메워야 한다. lint·typecheck·test·build를 통과해야만 다음 DAG 노드로 넘어가는 구조가 그 예다.
분산 에이전트 아키텍처가 가리키는 방향
Linux Foundation의 Agentic AI Foundation 출범은 기술적 사건이 아니라 구조적 전환의 신호다. MCP(연결), goose(실행), AGENTS.md(지시)가 하나의 스택을 이루는 방식은, 단일 거대 모델이 모든 것을 처리하는 것이 아니라 전문화된 에이전트들이 표준 인터페이스로 협력하는 구조로 산업이 수렴하고 있음을 보여준다. 1988년 DARPA의 TCP/IP 철학, Unix의 파이프 철학, Kubernetes의 컨테이너 오케스트레이션—매번 승리한 것은 모놀리스가 아니라 단순한 규칙으로 연결된 분산 구성요소였다.
팀 도입 판단 기준
현재 멀티 에이전트 코딩팀 도입을 검토하는 팀이라면, 병렬화 효과에 앞서 두 가지를 먼저 확인해야 한다. 팀이 MCP 도구 설명을 보안 경계로 관리할 역량이 있는가. 그리고 DAG 스케줄러가 에이전트 실패를 어떻게 처리하는지 팀이 이해하고 있는가. 둘 다 "아직"이라면, 단일 에이전트 + quality gate 구조를 먼저 안정화하는 것이 맞다. 병렬화는 통제 구조가 단단해진 다음에 올려야 할 레이어다.
전망
6개월 안에 대부분의 AI-First 팀은 멀티 에이전트 환경을 실험하거나 이미 운영하고 있을 것이다. 그때 차이를 만드는 건 어떤 오케스트레이터를 쓰느냐가 아니라, MCP 도구 계약을 얼마나 엄격하게 관리하고, 에이전트 완료 조건을 얼마나 결정론적으로 정의했느냐다. 에이전트는 빠르게 실행한다. 통제 구조는 팀이 설계해야 한다.