이번 주 서로 다른 두 팀이 같은 날 같은 결론을 냈습니다.

구글과 마이크로소프트는 ‘ARD(Agent Registry and Discovery)‘라는 에이전트 연결 표준을 공동 발표했습니다. 그리고 같은 시기에 LangChain 창업자 Harrison Chase는 Leve라는 프레임워크를 공개하면서 에이전트를 코드의 연속이 아니라 파일 디렉터리로 정의했습니다.

두 신호가 가리키는 방향은 하나입니다. 에이전트 전쟁의 다음 전선은 모델 성능이 아니라, 에이전트 간 연결 표준과 상태 관리입니다.

왜 모델 경쟁이 한계에 도달했는가

지금까지 에이전트 경쟁은 “어느 모델이 더 똑똑한가”를 중심으로 돌아왔습니다. Claude 4.8이냐, GPT-5.5냐, Gemini Pro냐. 벤치마크가 바뀔 때마다 순위가 바뀌고, 팀은 모델 선택 결정을 주기적으로 재검토했습니다.

하지만 실제 운영 환경은 다릅니다. 단일 모델 하나로 전체 워크플로를 처리하는 팀은 이미 드뭅니다. 코드 리뷰 에이전트, 문서 생성 에이전트, 배포 검증 에이전트가 순서를 정해 작업을 넘기고, 한 에이전트의 산출물이 다음 에이전트의 입력이 됩니다.

이 흐름에서 병목이 되는 것은 모델 성능이 아닙니다. 에이전트끼리 어떻게 연결되는가입니다.

구글과 MS가 ARD를 내놓은 이유가 여기에 있습니다. 에이전트 간 연결 표준이 없으면, 각 벤더의 에이전트는 제각각의 방식으로 정보를 주고받고, 조직은 어쩔 수 없이 단일 벤더 스택에 종속됩니다. ARD는 에이전트가 서로를 발견하고, 능력을 등록하고, 안전하게 작업을 위임하는 프로토콜을 표준화하겠다는 선언입니다. 오픈AI와 Anthropic을 견제하면서도, 조각난 에이전트 생태계를 하나의 인터페이스로 묶으려는 시도입니다.

상태를 파일로 남긴다는 것의 의미

Leve의 관점은 더 근본적인 질문을 건드립니다.

Harrison Chase는 에이전트를 함수 호출의 연속으로 보지 않습니다. 그는 에이전트를 파일로 정의되는 지속적 작업 단위로 설계했습니다. 에이전트의 스킬, 메모리, 작업 히스토리가 모두 파일 디렉터리 안에 존재합니다. 에이전트 프로세스가 중단되어도 파일은 남고, 재시작하면 파일에서 상태를 복원합니다.

agent/
├── SKILL.md      # 이 에이전트가 수행할 수 있는 것
├── MEMORY.md     # 누적된 맥락과 결정 히스토리
└── tasks/
    └── 2026-06-21.md  # 오늘의 실행 로그

이 구조는 낯설지 않습니다. CLAUDE.md나 AGENTS.md로 에이전트 동작을 선언적으로 정의하는 방식과 같은 철학입니다. 파일은 코드보다 오래가고, 파일은 에이전트가 바뀌어도 기억을 유지하며, 파일은 팀원 간 공유 가능한 운영 자산이 됩니다.

ARD가 에이전트 간 외부 연결을 표준화한다면, Leve는 에이전트 내부의 상태 관리를 표준화합니다. 두 축이 맞물릴 때 실제로 운영 가능한 멀티 에이전트 시스템이 만들어집니다.

PM이 지금 설계에서 점검할 것

이 두 신호는 에이전트를 설계하는 PM에게 세 가지 질문을 던집니다.

첫째, 에이전트를 단일 벤더 스택으로 묶고 있지 않은가.

많은 팀이 한 플랫폼 안에서 에이전트를 빠르게 구성합니다. 속도는 나지만, 나중에 다른 에이전트나 다른 벤더와 연결하려 할 때 비용이 큽니다. 연결 계층(connection layer)을 모델 선택과 분리해두지 않으면, ARD 같은 표준이 채택될 때 마이그레이션이 고통스러워집니다.

둘째, 에이전트의 상태가 어디에 살고 있는가.

에이전트를 교체하거나 업그레이드할 때, 이전 에이전트가 쌓아온 맥락은 어디로 갑니까? 코드에 묻혀 있으면 이식이 어렵습니다. Leve가 제안하듯 파일로 분리해두면, 에이전트를 바꿔도 기억은 남습니다. 지식이 모델이 아니라 파일에 사는 구조입니다.

셋째, 표준이 정착하기 전, 어떤 인터페이스로 설계하는가.

ARD가 아직 산업 표준이 된 것은 아닙니다. 그러나 구글과 MS가 동시에 같은 방향을 가리킨 이상, 이 흐름은 빠르게 정착할 가능성이 높습니다. 지금 에이전트를 설계하는 팀은 나중에 표준을 채택할 때의 마이그레이션 비용을 최소화하는 추상 계층을 미리 고민해야 합니다.

에이전트 경쟁은 모델 발표 사이클보다 빠르게 이동하고 있습니다. 성능 경쟁이 포화되면 다음 차별화는 연결 표준과 상태 관리 설계에서 나옵니다.

당신의 에이전트는 지금 어떤 기준으로 연결되어 있습니까?