에이전트 스택은 실시간으로 표준화되고 있다

이 블로그의 코드 저장소에는 AGENTS.md라는 평범한 텍스트 파일이 하나 들어 있습니다. 글 발행을 돕는 AI 에이전트에게 프로젝트의 디렉토리 구조, 파이프라인 작동 방식, 수정하면 안 되는 파일 규칙 등을 기계가 읽기 쉽게 정리해둔 안내문입니다. 에이전트가 작업 도중 무언가 실수를 할 때마다 규칙을 한 줄씩 덧붙이곤 합니다. 사람이 아니라 기계를 독자로 삼은 일종의 README인 셈입니다.

재미있게도 이 형식은 제가 고안한 것이 아닙니다. AGENTS.md는 이미 업계의 사실상 표준(de facto standard)으로 자리 잡았습니다. 불과 18개월 전에는 존재하지도 않던 이 규약이, 시장에서 치열하게 맞붙는 빅테크들의 합의를 거쳐 수만 개의 오픈소스 저장소에 똑같은 이름과 구조로 들어가 있습니다.

소프트웨어 역사에서 기술 표준이 이렇게 이른 시점에 정착되는 경우는 대단히 이례적입니다. 보통 표준은 늘 맨 마지막에 도착하기 때문입니다.

저는 지난 1년 반 동안 이 같은 프로토콜과 파일 규약 위에서 다양한 자동화 도구를 만들어왔습니다. 이 글은 그 생태계를 조망하는 첫 번째 지도입니다. 이어질 연재에서는 각 계층(프로토콜의 구체적인 명세, 장단점, 실제 구현 경험)을 깊이 있게 파고들 예정입니다. 그전에 전체 지형도를 펼치고 질문 하나를 던져보고 싶습니다. 도대체 왜 이번에는 표준화가 이렇게 이른 시점에, 믿을 수 없을 만큼 빠른 속도로 진행되고 있는 걸까요?

표준은 대개 맨 마지막에 도착하는 뒷정리반이었습니다

지금 우리가 당연하게 기대어 살고 있는 컴퓨팅 기반들이 어떻게 만들어졌는지 돌아보겠습니다.

인터넷의 근간인 통신 프로토콜들은 서로 호환되지 않던 파편화된 네트워크들이 수년간 난립한 뒤에야 표준화되었습니다. SQL은 상용 관계형 데이터베이스가 산업 현장에서 한참 돌아가고 나서야 국제 표준이 되었습니다. POSIX는 십수 개의 방언으로 쪼개져 서로 물고 뜯던 Unix 진영을 뒤늦게 봉합하기 위해 태어났습니다. USB 또한 PC 뒷면에 어지럽게 널려 있던 온갖 독점 포트들의 각축전 끝에 등장했습니다. 기술사에서 표준화는 늘 파티가 얼추 끝나갈 무렵 도착하는 뒷정리반에 가까웠습니다.

이런 순서가 되풀이된 데는 까닭이 있습니다. 경제적으로 지극히 합리적이었기 때문입니다. 너무 이른 표준화는 위험합니다. 문제의 본질을 제대로 이해하기도 전에 설익은 설계를 굳혀버릴 수 있고, 경쟁사들과 합의를 보느라 제품 출시 속도가 늦어지기 십상입니다. 그래서 모든 기업은 일단 자기만의 기술을 만들어 시장에서 치열하게 싸웠습니다. 소수의 승자가 추려지고 파편화의 고통을 더는 견딜 수 없게 되었을 때에야 마지못해 하나의 공통 규격으로 모여들곤 했습니다.

먼저 만들고 싸운 다음, 살아남은 승자를 기준으로 표준을 제정합니다. 수십 년간 이어져 온 불문율이었습니다.

에이전트 생태계에서는 표준이 먼저 만들어지고 있습니다

하지만 에이전트 영역에서는 이 순서가 완전히 뒤집혔습니다. 기술이 한창 발명되고 있는 도중에 실시간으로 프로토콜이 작성되고 있습니다. 십수 년의 세월이 아니라 불과 몇 달 만에, 밀실의 표준화 위원회 대신 누구나 열람할 수 있는 공개 GitHub 저장소에서, 게다가 서로를 시장에서 밀어내기 위해 사투를 벌이는 경쟁사들의 손으로 직접 쓰이고 있습니다.

최근의 타임라인을 살펴보면 그 속도감이 실감 납니다:

2024년 11월: Anthropic이 Model Context Protocol(MCP)을 오픈소스로 공개합니다. 에이전트가 로컬 파일, API, 데이터베이스 같은 외부 도구에 접근하는 공통 규약입니다. “AI를 위한 USB-C”라는 비유가 곧바로 업계 전반에 퍼졌습니다.
2025년 4월: Google이 에이전트 간의 상호 발견 및 작업 위임을 위한 A2A(Agent2Agent) 프로토콜을 발표합니다. 두 달 뒤인 6월에는 이 규약을 Linux Foundation에 기부했습니다.
2025년 8월: OpenAI와 개발 도구 생태계 전반에서 AGENTS.md가 급부상합니다. 코딩 에이전트에게 프로젝트 실행 맥락을 알려주는 경량 Markdown 규격입니다. 같은 달 Zed 에디터 진영은 코딩 에이전트를 위한 일종의 LSP 규격인 Agent Client Protocol을 선보였고, JetBrains가 곧이어 합류했습니다.
2025년 9월: Google이 에이전트 간 안전한 금융 결제를 위한 AP2(Agent Payments Protocol)를 발표합니다. W3C 분산 신원 증명 기술을 기반으로 설계되었습니다. 지금은 FIDO Alliance로 이관되어 관리되고 있습니다.
2025년 12월: Anthropic이 프롬프트 지침과 실행 스크립트를 묶는 Agent Skills(SKILL.md)를 개방형 표준으로 공개합니다. 직전에는 Linux Foundation 주도로 MCP, Block의 Goose, AGENTS.md 등을 포괄하는 중립 연합체인 Agentic AI Foundation(AAIF)이 출범했습니다.

또 하나 상징적인 사례는 ATIF(Agent Trajectory Interchange Format)입니다. 에이전트의 전체 상호작용 기록(사용자 프롬프트, 모델 내부의 사고 과정, 도구 호출 파라미터, 환경 관측 결과)을 체계적으로 담아내는 표준 JSON 스키마입니다. 이 포맷 하나로 디버깅, 성능 시각화, 회귀 평가, 강화학습 파이프라인까지 모두 대응하도록 설계되었습니다. Terminal-Bench를 개발한 Laude Institute의 Harbor 프레임워크에서 제안된 RFC 단계의 규격입니다. 에이전트가 프로덕션 환경에 완전히 보편화되기도 전에, 실행 세션 로그 스키마부터 미리 표준화하고 있는 셈입니다. 건물의 뼈대를 올리기도 전에 상하수도 규격부터 통일하고 있는 모습입니다.

가장 결정적인 신호는 AAIF의 구성원입니다. AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, OpenAI가 한자리에 모여 기반 인프라를 함께 관리하고 있습니다. OpenAI는 2025년 4월 Anthropic의 MCP를 발 빠르게 채택했고, 자사의 Apps SDK를 그 위에 구축했습니다. 프론티어 랩이 독자 규격을 밀어붙여 생태계를 쪼개는 대신 경쟁사의 인터페이스 표준을 전격 받아들였습니다. 과거 플랫폼 역사에서는 찾아보기 힘든 장면입니다.

에이전트 시스템의 이음매를 정리한 지도

알파벳 약어가 쏟아지니 헷갈리기 쉽습니다. 각 표준이 에이전트 아키텍처의 어느 지점을 연결하고 있는지 정리해보면 구조가 명확해집니다:

에이전트와 도구/데이터: MCP. 에이전트가 로컬 파일, 서드파티 API, 데이터베이스 등 외부 환경과 통신하는 통로를 표준화합니다.
에이전트와 에이전트: A2A 및 IBM/BeeAI의 Agent Communication Protocol. 독립적인 에이전트들이 네트워크를 통해 서로를 식별하고, 권한을 확인하며, 하위 태스크를 위임하는 방식을 표준화합니다.
에디터와 에이전트: Zed의 Agent Client Protocol. 개발자가 사용하는 IDE와 백그라운드 코딩 에이전트 간의 제어 명령을 표준화합니다.
기능 패키징 규격: Agent Skills (SKILL.md). 프롬프트 지침, 실행 스크립트, 레퍼런스 문서를 에이전트가 즉석에서 로딩할 수 있는 패키지 단위로 묶는 표준입니다.
프로젝트 맥락 주입: AGENTS.md. 에이전트가 저장소의 코드를 건드리기 전에 숙지해야 하는 프로젝트별 운영 지침을 제공합니다.
실행 궤적 기록: ATIF. 에이전트의 전체 턴 기록을 보존해 평가와 학습에 재활용할 수 있게 해주는 표준 로그 포맷입니다.
결제 및 경제적 신원: AP2 및 Visa의 Trusted Agent Protocol. 에이전트가 자율적으로 결제를 수행할 때 그 권한을 암호학적으로 보증하는 체계입니다.

자주 혼동되는 두 가지가 있습니다. 첫째, “ACP”라는 약어는 완전히 다른 두 프로토콜을 가리킵니다. IBM의 Agent Communication Protocol(에이전트 간 통신)과 Zed의 Agent Client Protocol(IDE와 에이전트 간 통신)은 같은 약자를 쓸 뿐 서로 다른 계층을 다룹니다. 둘째, MCP와 A2A는 경쟁 관계가 아니라 상호 보완적인 관계입니다. MCP는 에이전트가 자신의 손발이 되어줄 도구를 쥐는 규약이고, A2A는 에이전트가 동료 에이전트와 협업하는 규약입니다. 실제 운영 시스템에서는 두 프로토콜이 함께 쓰입니다.

왜 지금, 왜 이렇게 빠르게 진행되는가?

그렇다면 기술 표준이 늘 늦게 도착하던 관성을 깨뜨린 원동력은 무엇일까요?

첫날부터 조합 폭발(N×M 문제)이 터져 나왔기 때문입니다. 에이전트 환경에서 도구 연동 요구는 서서히 늘지 않고 즉각적으로 폭발합니다. 모든 프레임워크가 세상의 모든 SaaS와 데이터베이스에 붙고 싶어 합니다. 공통 규약이 없다면 N개의 에이전트와 M개의 도구마다 맞춤형 커넥터를 작성해야 하므로 유지보수 비용이 기하급수적으로 치솟습니다. 열린 표준은 이 부담을 N+M으로 압축해줍니다. 과거 기술들에서는 파편화의 고통이 수년에 걸쳐 천천히 쌓였습니다. 에이전트 생태계에서는 첫 연동 단계부터 마찰이 극심했기에 표준화가 곧바로 필요해졌습니다.

명세가 가볍고 직관적입니다. AGENTS.md와 SKILL.md는 사람이 눈으로 쉽게 읽을 수 있는 평범한 Markdown입니다. MCP와 ACP는 대중적인 JSON-RPC를 기반으로 설계되었습니다. 개발자 한 명이 오후 한나절이면 구현할 수 있는 실용적인 규약들입니다. 수백 명의 위원회가 십 년간 다듬은 수천 쪽짜리 난해한 통신 규격과는 거리가 멉니다. 진입 장벽이 낮으니 확산 속도가 빠를 수밖에 없습니다.

중립 재단을 통한 코피티션(Coopetition)이 가능해졌습니다. 빅테크들이 한 테이블에 앉을 수 있었던 것은 누구도 그 테이블을 독점하지 않기로 합의했기 때문입니다. 프로토콜을 Linux Foundation이나 FIDO Alliance 같은 중립 기구에 맡겨 특정 기업에 종속될 위험을 없애고 업계 전체의 공공재로 바꾸었습니다. 쿠버네티스와 파이토치를 성공으로 이끈 모델을 에이전트 진영이 기민하게 빌려 온 셈입니다. 파편화된 작은 파이를 독차지하려 다투기보다, 표준화로 거대해진 파이를 함께 나누는 편이 이득이라는 계산이 맞아떨어졌습니다.

또한 업계는 과거 브라우저 전쟁과 초기 모바일 플랫폼 파편화로 치렀던 막대한 비용을 여전히 또렷하게 기억하고 있습니다. 소모적인 분열의 역사를 되풀이하지 말자는 공감대가 있습니다.

현업 엔지니어가 이 표준들을 주목해야 하는 이유

저에게 이것은 관념적인 관전기가 아닙니다. 서두에 언급한 AGENTS.md는 제가 매주 일상적으로 다루는 도구의 일부입니다. 로컬 MCP 서버를 띄우고, 반복 작업은 Skill 패키지로 모듈화합니다. 에이전트가 오작동할 때면 실행 트레이스를 역추적합니다. 이 오픈 스탠다드들은 지금 제가 만들고 있는 모든 소프트웨어의 든든한 바닥판입니다. 그리고 그 바닥판이 우리가 발을 딛고 서 있는 바로 이 순간 실시간으로 굳어가고 있다는 점이 대단히 짜릿하고도 신선합니다.

기술 스택 전체가 공개된 광장에서 스스로의 문법을 실시간으로 합의해 나가는 광경은 소프트웨어 역사에서 흔치 않습니다. 이 규격들은 아직 젊고 유연합니다. 지금 이 기술로 제품을 만드는 엔지니어들의 피드백이 표준의 미래 형태를 직접 결정짓고 있습니다.

이 글을 시작으로 시리즈를 이어가려 합니다. 다음 글들에서는 MCP의 세부 동작 원리, 두 ACP 프로토콜의 차이점, 일반 프롬프트 엔지니어링을 뛰어넘는 Skill의 장점, 그리고 ATIF 같은 궤적 로그 규격이 왜 프로덕션 신뢰성의 핵심인지 하나씩 차례로 짚어보겠습니다.

우리가 딛고 서 있는 토대의 실체를 함께 확인해보겠습니다.

함께 읽으면 좋은 글: 에이전트는 작업실에 있지, 제품 안에는 없다, 사이트를 에이전트 친화적으로: llms.txt와 두 청중 문제, 그리고 출시는 싸고 방향성은 비싸다.