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

이 블로그 저장소에는 AGENTS.md라는 평범한 텍스트 파일이 하나 있어요. 발행을 도와주는 AI 에이전트한테 이 프로젝트가 어떻게 생겼는지 — 콘텐츠는 어디 있고, 파이프라인은 어떻게 돌아가고, 뭘 건드리면 안 되는지 — 알려주는 파일이에요. 에이전트가 뭔가 틀릴 때마다 저는 거기에 한 줄씩 더해요. 별거 아니에요. 사람이 아니라 기계한테 보여주려고 쓴 README인 셈이죠.

이상한 건, 그 형식을 제가 만든 게 아니라는 거예요. AGENTS.md는 이제 표준이거든요. 똑같은 파일이 똑같은 모양으로 수만 개의 다른 저장소에 들어 있고, 서로 치열하게 경쟁하는 회사 몇 곳이 함께 합의한 거예요. 그런데 18개월 전만 해도 아예 없던 거고요.

이게 이렇게 빨리 될 일이 아니거든요. 표준은 거의 항상 늦게 오니까요.

저는 지난 1년 반 동안 바로 이런 파일이나 프로토콜 위에서 뭔가를 만들어 왔고, 그 이야기를 시리즈로 써보려고 해요. 이 글은 그 첫 지도예요. 다음 글들에서는 하나씩 한 겹 더 깊이 들어가 볼 거예요. 어떤 프로토콜이 실제로 뭘 말하는지, 뭘 잘했고 뭐가 아쉬운지, 그 위에서 직접 만들어 보면 어떤지요. 그 전에 먼저 전체 지형을, 그리고 저를 이 주제로 끌어들인 질문을 던져볼게요. 왜 이게 이렇게 빠르게, 또 이렇게 일찍 일어나고 있을까요?

표준은 보통 맨 마지막에 와요

우리 발밑에 깔린 토대들이 실제로 어떻게 만들어졌는지 한번 떠올려 봐요.

인터넷을 굴리는 프로토콜들은 호환도 안 되는 네트워크가 한참 난립한 뒤에야 표준이 됐어요. SQL은 관계형 데이터베이스가 이미 현업에서 한참 돌아가고 나서야 표준이 됐고요. POSIX는 이미 십수 개 방언으로 쪼개진 Unix 판을 봉합하려고 뒤늦게 나왔어요. USB는 몇 년 동안 PC 뒷면에서 서로 싸우던 커넥터들의 무덤을 정리하면서 등장했고요. 어느 경우든 표준화는 파티가 거의 끝나갈 무렵 도착한 뒷정리 팀이었어요.

이 패턴이 반복되는 건 그게 합리적이라서예요. 너무 일찍 표준을 정하는 건 비싸고 위험하거든요. 아무도 문제를 제대로 이해하기 전에 잘못된 설계를 굳혀버릴 수도 있고, 한창 제품을 내놓고 싶을 때 경쟁사랑 합의하느라 발이 묶이기도 하고요. 그래서 다들 일단 자기 걸 만들고, 시장이 몇몇 생존자를 추려내고, 그제서야 — 문제의 윤곽이 분명해지고 파편화 비용이 더는 못 버틸 만큼 커지고 나서야 — 업계가 마지못해 한곳으로 모여요.

먼저 만들고. 싸우고. 살아남은 쪽을 표준화하고. 매번, 늦게요.

에이전트에서는 표준이 먼저 와요

여기서는 순서가 뒤집혀 있어요. 프로토콜이 기술이 아직 만들어지는 중에 쓰이고 있거든요. 10년이 아니라 몇 달 만에, 닫힌 문 뒤가 아니라 지금 당장 열어볼 수 있는 GitHub 저장소에서요. 그리고 제가 아직도 잘 안 믿기는 부분인데, 한편으로는 서로를 시장에서 밀어내려고 기를 쓰는 회사들이 그걸 같이 하고 있어요.

날짜를 한번 보세요.

2024년 11월 — Anthropic이 Model Context Protocol(MCP)을 오픈소스로 공개해요. 에이전트가 도구랑 데이터에 닿는 표준적인 방법이에요. ‘AI를 위한 USB-C’라는 비유가 거의 곧바로 자리를 잡았고요.
2025년 4월 — Google이 A2A(Agent2Agent)를 발표해요. 에이전트가 다른 에이전트를 찾아내고 일을 맡기는 프로토콜이에요. 6월엔 Linux Foundation에 기부됐고요.
2025년 8월 — OpenAI랑 더 넓은 도구 생태계에서 AGENTS.md가 나와요. 코딩 에이전트한테 ‘네가 다룰 저장소가 이렇게 돌아간다’고 알려주는, 순수 Markdown으로 된 ‘에이전트용 README’예요. 같은 달에 Zed가 Agent Client Protocol을 내놨는데 — ‘코딩 에이전트를 위한 LSP’ 같은 거예요 — 곧이어 JetBrains도 합류했어요.
2025년 9월 — Google이 AP2(Agent Payments Protocol)를 공개해요. 에이전트가 결제까지 할 수 있게 해주는 건데, W3C Verifiable Credentials 위에 세워져 있고 지금은 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(네, 이것도 ‘ACP’예요 — 다른 물건이고요). 에이전트끼리 서로 찾아내고, 인증하고, 일을 맡기는 방법이에요. 여기엔 경쟁자가 좀 북적여요.
에디터 ↔ 에이전트: Zed의 Agent Client Protocol(또 다른 ‘ACP’요). 내 IDE가 그걸 굴리는 코딩 에이전트랑 대화하는 방법이에요.
능력을 묶는 방법: Agent Skills / SKILL.md. 지시문, 스크립트, 리소스를 에이전트가 필요할 때 불러 쓸 수 있는 한 덩어리로 묶는 방법이에요.
에이전트한테 주는 지시: AGENTS.md. 에이전트가 내 저장소에 손대기 전에 읽는, 프로젝트별 안내문이에요.
에이전트가 한 일의 기록: ATIF. 디버깅, 평가, 학습에 두루 쓰는 표준 궤적(trajectory)이에요.
돈과 신원: AP2, 그리고 Visa의 Trusted Agent Protocol 같은 인접 작업들. 에이전트가 결제하는 방법, 그리고 그 에이전트한테 그래도 되는 권한이 있다는 걸 누가 믿어주는 방법이에요.

사람들이 자주 헷갈리는 두 가지만 짚을게요. 첫째, ‘ACP’는 서로 아무 상관 없는 두 프로토콜을 가리켜요. IBM의 Agent Communication Protocol(에이전트–에이전트)이랑 Zed의 Agent Client Protocol(에디터–에이전트)이요. 글자는 같은데 이음매가 달라요. 둘째, MCP랑 A2A는 경쟁이 아니라 보완 관계예요. MCP는 에이전트를 도구에 연결하고, A2A는 에이전트를 다른 에이전트에 연결하거든요. 실제 시스템은 대개 둘 다 써요.

왜 지금일까, 왜 이렇게 빠를까

그럼 ‘표준은 늦게 정한다’는 평소 규칙을 뭐가 깨뜨린 걸까요? 제 생각엔 몇 가지가 있어요.

N×M 문제가 첫날부터 터져요. 에이전트에서는 통합이 폭발하는 게 서서히가 아니라 즉각적이에요. 에이전트마다 모든 도구를 쓰고 싶어 하고, 에이전트마다 다른 모든 에이전트랑 얘기해야 할 수도 있거든요. 공통 프로토콜이 없으면 N×M개의 맞춤 커넥터를 일일이 짜야 하는데, N도 M도 동시에 폭발하고 있어요. 표준은 이걸 N+M으로 줄여줘요. 대부분의 기술에서는 파편화의 고통이 충분히 천천히 쌓여서 수리를 몇 년쯤 미룰 수 있어요. 그런데 에이전트에서는 첫 통합부터 통증이 날카롭다 보니, 표준을 만들 동기도 일찍 찾아와요.

명세가 작아요. 이건 의외로 과소평가돼 있어요. AGENTS.md랑 SKILL.md는 그냥 Markdown이에요. MCP랑 두 ACP는 JSON-RPC고요. 위원회가 10년에 걸쳐 두들겨 만든 천 페이지짜리 통신 표준이 아니라, 오후 한나절이면 도입할 수 있는 작고 사람이 읽을 수 있는 약속이에요. 도입 비용이 낮으니까 곡선이 몇 년이 아니라 몇 달 만에 움직여요. AGENTS.md는 저장소 6만 개를 넘겼고, MCP는 첫해 안에 월 수천만 건 SDK 다운로드를 넘겼다고 해요. 표준을 들이는 게 싸면, 나머지는 네트워크 효과가 알아서 해줘요.

중립 재단이 ‘코피티션(coopetition)’, 그러니까 경쟁자끼리의 협력을 버틸 만하게 해줘요. 경쟁사들이 한 테이블에 앉을 수 있는 건, 그 테이블을 아무도 소유하지 않아도 되기 때문이에요. 프로토콜을 Linux Foundation에 (AP2라면 FIDO에) 기부하면 ‘Anthropic의 프로토콜’이 ‘업계의 프로토콜’이 되고, 그러면 나머지도 거기에 기꺼이 올라타거든요. 사실 이건 닳고 닳은 방식이에요. Kubernetes, PyTorch, Node.js가 중립 거점을 얻은 방식이고, W3C가 웹이 쪼개지지 않게 지킨 방식이죠. 에이전트 쪽은 그걸 놀랄 만큼 빨리 집어 들었어요. 베팅은 이거예요. 쪼개진 파이의 살짝 더 큰 조각보다, 다 같이 키운 더 큰 파이가 낫다는 거요. 적어도 지금까지는 그 베팅이 맞아 보여요.

그리고 어쩌면 제일 단순한 이유는 이거예요. 다들 초기 인터넷이 이런 합의 없이 자라는 걸 지켜봤고, 그 대가를 기억하거든요. 사람들이 꺼내 드는 비유들 — ‘AI를 위한 USB-C’, ‘표준 이전의 인터넷’, ‘에이전트를 위한 LSP’ — 은 그냥 멋부린 말이 아니에요. 업계가 ‘이 영화 우리 봤잖아, 이번엔 파편화 장면은 건너뛰자’고 말하는 거예요.

제가 이걸 신경 쓰는 이유, 그리고 왜 시리즈인지

저한테 이건 멀찍이서 명세나 구경하는 일이 아니에요. 첫머리에서 꺼낸 그 AGENTS.md 파일은, 제가 보통 한 주에 만지는 이런 표준들 중 하나일 뿐이거든요. MCP 서버를 붙이고, 반복되는 일은 Skill로 묶어요. 뭔가 망가지면 에이전트가 남긴 기록을 되짚으면서 어디서 틀어졌는지 찾는데 — 바로 ATIF가 어디서나 통하게 만들려는 그 기록이에요. 예전에 사이트를 에이전트 친화적으로 만드는 일을 썼을 때도, 발행하는 쪽에서 나온 똑같은 본능이었고요. 이 중에 멀리서 공부만 하는 건 하나도 없어요. 지금 제가 만드는 거의 모든 것의 토대거든요. 그리고 불안하면서도 짜릿한 건, 그 토대가 제가 그 위에 서 있는 동안 부어지고 있다는 거예요.

그래서 더더욱 찬찬히 적어둘 만하다고 생각해요. 우리는 지금 하나의 기술 스택이 먼지가 채 가라앉기도 전에, 실시간으로, 공개적으로 자기들의 문법에 합의하는 장면을 보고 있어요. 좀처럼 없는 일이고, 나중에 돌아보면 이 시대에서 꽤 중요한 일 중 하나로 기억될 것 같아요. 이 명세들 대부분은 아직 충분히 어려서, 그 위에서 뭔가 만드는 사람들이 사실상 그게 뭐가 될지를 같이 정하고 있는 셈이에요.

그래서 이 글은 시리즈의 시작이에요. 여기서부터 한 겹씩 내려가 보려고 해요. MCP를 열어서 실제로 뭐라고 적혀 있는지 보고, 두 ACP를 갈라서 보고, Skill이 그냥 프롬프트로는 안 되는 뭘 잘하는지 따져 보고, 그리고 네, ATIF 같은 세션 로그 형식이 들리는 것보다 왜 더 중요할 수 있는지도 파볼 거예요. 일단 지도부터요. 그다음에 확대하고요.

우리가 지금 뭐 위에 서 있는 건지, 같이 알아봐요.

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