IETF가 이번 주 비엔나에서 회의를 개최하며, 그 의제는 대부분의 AI 산업이 알아차리지 못한 이야기를 들려주고 있습니다. 세 개의 별도 BoF (Birds-of-a-feather) 세션이 AI 에이전트에 할애되었습니다: 에이전트 통신을 위한 agentproto, 발견 및 명명(naming)을 위한 DAWN, 그리고 게이트웨이 매개 협업을 위한 DMSC입니다. 에이전트 책임(accountability)을 다루는 네 번째 제안인 AUDIT은 선정되지 못하고 다음 회의를 기다리고 있습니다.

이러한 세션들 뒤에는 이 조직의 40년 역사상 전례가 없는 방대한 양의 문서들이 자리 잡고 있습니다. 저는 IETF 스트림 내에 있거나 이를 목표로 하는 모든 AI 에이전트 표준화 노력을 추적하는 라이브 문서를 유지하고 있습니다. 현재 집계된 수치는 17개의 서로 다른 카테고리에 걸쳐 250개가 넘는 Internet-Drafts (인터넷 초안)를 넘어섭니다. 에이전트 신원(identity) 및 권한 부여(authorization)만 해도 50개 이상의 경쟁 제안이 차지하고 있습니다. 발견 및 명명은 대략 20여 개입니다. 감사(Audit) 및 책임(accountability)은 12개의 문서 프로토콜 제품군을 제출한 단일 저자를 포함하여 30개가 넘습니다.

맥락을 위해 설명하자면, 현대 웹의 대부분을 뒷받침하는 권한 부여 프레임워크인 OAuth 2.0은 수년에 걸쳐 소수의 경쟁 제안으로부터 등장했습니다. 에이전트 분야는 약 18개월 동안 그보다 한 자릿수(order of magnitude) 더 많은 양의 문서를 만들어냈습니다.

Internet-Draft란 실제로 무엇인가

이 방대한 양을 결론짓기 전에, 이 양이 무엇을 의미하는지 이해하는 것이 도움이 됩니다. 누구나 Internet-Draft를 제출할 수 있습니다. 검토 관문도 없고, 멤버십 요구 사항도 없으며, 수수료도 없습니다. 문서는 갱신되지 않으면 6개월 후에 만료되며, IETF 자체의 boilerplate (상용구)는 독자들에게 모든 초안을 공식적인 지위가 없는 진행 중인 작업(work in progress)으로 취급하도록 안내합니다.

이러한 낮은 장벽은 하나의 특징입니다. 이것이 IETF가 항상 작동해 온 방식입니다: 거친 합의(rough consensus)와 실행 가능한 코드(running code)를 지향하며, 문서 작업은 대화를 시작하는 역할을 합니다. 하지만 이는 또한 250개의 초안 수치에 최소한 세 가지의 매우 다른 종류의 문서가 포함되어 있음을 의미합니다.

첫 번째 종류는 진지한 엔지니어링 (engineering)입니다. WIMSE와 같은 워킹 그룹 (working groups)의 초안, AIPREF의 헌장 문서, 그리고 Visa와 Mastercard가 이미 에이전트 결제 검증을 위해 채택한 Web Bot Auth 아키텍처 (architecture) 등이 이에 해당합니다. 이러한 문서들은 저자가 존재하며, 구현체 (implementations)가 있고, 제도적 무게감을 갖추고 있습니다.

두 번째 종류는 깃발 꽂기(flag-planting)로, 다른 이름으로는 임시 특허와 같습니다. 초안을 제출하면 Datatracker에 영구적이고 타임스탬프가 찍힌 공개 기록이 생성되는데, 점점 더 많은 스타트업이 "우리는 IETF에 제출했다"라는 문구가 피치 덱 (pitch deck)에서 잘 먹힌다는 사실을 발견했습니다. 몇몇 저명한 ID (identity) 초안들은 보안 고려 사항 (Security Considerations) 섹션이 자리 표시자 (placeholder) 상태로 배포되었는데, 이는 제출 전에 프로토콜 엔지니어링 (protocol engineering)이 얼마나 이루어졌는지를 잘 보여줍니다.

세 번째 종류는 실제 격차를 발견하고 공개적으로 생각을 나누는 실무자들의 진정한 탐구입니다. 저 자신도 이 그룹에 속합니다. 저는 에이전트 트래픽을 위한 전용 전송 기질 (transport substrate)인 AGTP를 정의하는 일련의 초안들을 제출했으므로, 저 또한 이 범람의 참여자이며 이것이 어떻게 해결되는지에 대해 명백한 이해관계가 있습니다. 이 점을 염두에 두고 다음의 모든 내용을 읽어주시기 바랍니다.

왜 이러한 범람이 일어나는가

이러한 양적인 팽창은 증상이며, 근본적인 상태는 실재합니다. AI 에이전트는 인터넷의 기존 프로토콜 스택 (protocol stack)이 구축되었던 가설들을 깨뜨립니다.

ID (identity) 시스템은 행위자가 인간이거나 고정된 워크로드 (workload)라고 가정합니다. 에이전트는 둘 다 아닙니다. 에이전트는 인간을 대신하여 행동하고, 하위 에이전트에게 권한을 위임하며, 몇 초 만에 생성되었다가 사라지고, 체인을 따라 내려갈 때 권한이 약화 (attenuate)되어야 합니다. OAuth는 이 중 그 어느 것도 고려하여 설계되지 않았으며, 이것이 50개 이상의 초안이 이를 개조하거나, 확장하거나, 또는 대체하려고 시도하는 이유입니다.

탐색 (Discovery) 시스템은 당신이 원하는 대상의 이름을 알고 있다고 가정합니다. 에이전트는 기능 (capabilities)을 찾아야 하고, 요청 시점에 계약을 협상해야 하며, 한 번도 본 적 없는 상대방에 대한 신뢰를 검증해야 합니다. DNS 역시 이 중 그 어느 것도 고려하여 설계되지 않았으며, 이것이 DNSOP가 갑자기 에이전트 명명 제안들로 가득 차게 된 이유이자 DAWN이 존재하는 이유입니다.

책임성 (Accountability)은 인터넷 계층 (internet-layer) 개념으로서 거의 존재하지 않습니다. 에이전트 체인 (agent chain)이 네 개의 조직에 걸쳐 금융 거래를 실행할 때, 누가 무엇을 승인했는지, 그리고 나중에 이를 어떻게 증명할 것인지에 대한 표준화된 답변이 없습니다. 규제 기관들은 이미 질문을 던지고 있습니다. EU AI Act의 로깅 (logging) 및 인간 감독 (human-oversight) 의무는 여러 초안에서 명시적인 동기로 나타나고 있으며, 이는 규제 준수 압박이 이제 배선 프로토콜 (wire protocols)을 형성하고 있음을 의미합니다.

이러한 격차들은 모두 정당합니다. 문제는 정당한 질문들에 대한 250개의 조율되지 않은 답변들이, 답변이 아예 없는 것과는 다른 종류의 실패를 야기한다는 점입니다.

파편화 아래의 파편화

초안 (draft)의 개수는 눈에 보이는 증상일 뿐입니다. 구조적인 문제는 장소의 확산 (venue sprawl)입니다. 에이전트 신원 (agent identity) 작업은 OAuth, WIMSE, SPICE, SCIM, RATS, 그리고 적어도 하나의 사이드 미팅 (side meeting)에 흩어져 있습니다. 탐색 (Discovery)은 DNSOP, DAWN 노력, 그리고 6개 정도의 독립적인 제출물에 걸쳐 있습니다. 감사 (Audit)는 AUDIT BoF가 연기된 이후 아예 안식처를 찾지 못했습니다.

한편, 현재 IETF 내에서 누구도 횡단적인 에이전트 보안 (cross-cutting agent security)을 담당하고 있지 않습니다. 에이전트 경계를 넘나드는 프롬프트 인젝션 (Prompt injection), 위임 체인 (delegation chains)에서의 혼동된 대리인 (confused-deputy) 실패, 도구 오염 (tool poisoning). 이러한 위협들은 모든 범주에 걸쳐 있으며, 이를 모델링하기 위해 구성된 작업 그룹 (working group)은 없습니다. 200개의 초안이 있지만, 가장 중요한 문서인 공유 위협 모델 (shared threat model)은 존재하지 않습니다.

이것은 이 분야에서 무언가를 구축하려는 모든 이들에게 제가 경고하고 싶은 패턴입니다. 표준화 기구는 그들이 수용하는 사고의 흐름과 동일한 선을 따라 파편화됩니다. 에이전트 신원이 OAuth 문제인지, 워크로드 (workload) 문제인지, 아니면 완전히 새로운 문제인지에 대해 장소들이 합의하지 못할 때, 그 불일치는 구조적 (architectural)인 것이며, 중복되는 초안을 제출한다고 해서 해결되지 않을 것입니다.

서류 작업을 형성하는 인센티브

이 초안들의 저자 목록(author lines)을 살펴보면 하나의 패턴이 나타납니다. 제안의 대다수는 자신들의 스폰서(sponsor)가 이미 출시한 제품을 확장하는 방식입니다. 신원 제공업체(Identity vendors)는 자신들의 디렉터리(directory)가 중간에 위치한다고 가정하는 신원 초안을 제출합니다. 클라우드 및 네트워크 제공업체는 자신들의 게이트웨이(gateway)를 가정하는 게이트웨이 초안을 제출합니다. 결제 네트워크는 자신들의 망(rails)이 이미 지원하는 검증 체계(verification scheme)를 뒷받침합니다. 각각의 제출은 저자에게는 합리적이지만, 그 총합은 시장 출시 속도와 상업적 입지에 최적화된 표준화 프로세스가 되어버렸습니다.

거의 모든 초안에서 결여된 것은 표준화 기구가 존재해야 하는 이유인 질문, 즉 "우리가 만들 수 있는 가장 최선의 표준은 무엇인가?"라는 질문입니다. 그 질문은 분기별 로드맵(roadmap)과 마주하는 순간 좀처럼 살아남지 못합니다. 인터넷의 기초 프로토콜들은 그럼에도 불구하고 그 질문을 던졌던 엔지니어들에 의해 작성되었으며, 이들은 종종 고용주의 단기적인 이익에 반하는 선택을 하기도 했습니다. 그 차이는 40년이 지난 지금 극명하게 드러납니다. 현재의 범람은 그 전통을 뒤집고 있습니다. 가장 빠른 경로와 가장 경제적으로 보상이 큰 경로가 기본 경로가 되었고, 올바른 경로에는 스폰서가 없습니다.

아무도 의제로 올리고 싶어 하지 않는 어려운 질문

250개의 초안 아래에는 구조적인 질문이 자리 잡고 있으며, 커뮤니티는 계속해서 이를 피해 가고 있습니다: 왜 모든 것이 HTTP 위에서 구축되고 있는가?

HTTP는 인간이 문서를 요청하는 것을 위해 설계되었습니다. 에이전트(Agent) 트래픽에는 네트워크 중단 상황에서도 유지되는 지속적인 세션(persistent sessions), 전송 계층(wire)에서 전달되는 위임 체인(delegation chains), 모든 동작에 결합된 귀속(attribution), 그리고 GET 및 POST보다 훨씬 더 풍부한 의도 의미론(intent semantics)이 필요합니다. 이러한 속성들 각각은 현재 애플리케이션 계층(application layer)에서 수십 개의 초안을 통해 독립적으로, 그리고 서로 호환되지 않는 결과물로 재구축되고 있습니다. 50개가 넘는 신원 제안들이 위임(delegation)에 대한 개념조차 없는 전송 계층(transport) 위에서 각각 위임을 재발명하고 있다면, 문제는 바로 그 전송 계층에 있는 것입니다.

저는 전용 에이전트 전송 기질(agent transport substrate)을 주장하는 초안(drafts)들을 제출해 왔으므로, 이 문제에 대한 제 입장은 분명히 밝혀두었습니다. 하지만 이 질문 자체는 그 자체로 논의될 가치가 있습니다. IETF가 QUIC을 표준화한 이유는 누군가가 기존 계층이 여전히 트래픽에 적합한지 질문할 의지가 있었기 때문입니다. 40년의 전례는 이 조직이 그러한 질문을 던지는 방법을 알고 있음을 보여줍니다. 하지만 에이전트(agents)에 대해서는 아직 의제(agenda)에 이 질문을 올리지 않았습니다.

프로토콜의 탈을 쓴 애플리케이션

세 번째 패턴은 범주 오류(category error)입니다. 프로토콜은 어떤 두 당사자라도 독립적으로 구현하여 상호 운용(interoperate)할 수 있는 규칙을 정의합니다. 반면 애플리케이션은 제품을 정의합니다. 제가 추적하는 문서 중 점점 더 많은 비중을 차지하는 것들은 첫 번째 형태(프로토콜)로 포맷된 두 번째 형태(제품)입니다. 즉, RFC의 정형화된 문구(boilerplate)로 감싸고 Datatracker에 제출된 벤더의 아키텍처, SDK 가정, 그리고 배포 모델입니다.

판별법은 간단합니다. 두 명의 낯선 사람이 이 문서를 읽고, 별도로 구현하며, 작성자의 플랫폼 개입 없이 상호 운용할 수 있는지 물어보십시오. 진정한 프로토콜이라면 대답은 '예'입니다. 하지만 현재 제출되는 많은 것들에 대한 솔직한 대답은, 결국 작성자의 제품을 실행하게 될 것이라는 점입니다. 애플리케이션을 표준화하는 것은 인터넷을 특정 벤더의 로드맵에 종속시키는 것이며, IETF는 지난 40년 동안 바로 그 일을 거부하며 시간을 보내왔습니다. 현재 밀려드는 문서의 양은 그러한 거부 의사가 여전히 유효한지를 시험하고 있습니다.

실제로 수렴하는 것

역사는 필터를 제공합니다. 프로토콜 전쟁은 세 가지 요소, 즉 실행 가능한 코드(running code), 배포 견인력(deployment pull), 그리고 장소 적합성(venue fit)에 의해 결정됩니다. Web Bot Auth는 이 사이클의 증명 사례입니다. 이는 제안에서 시작하여 위원회(chartered working group) 구성, 그리고 2년도 채 되지 않아 가장 큰 두 결제 네트워크에 채택되기까지의 과정을 거쳤습니다. Cloudflare가 이를 출시했고, 커머스 분야에서 필요로 했으며, 그 범위가 위원회(charter)를 유지할 수 있을 만큼 충분히 좁았기 때문입니다.

250개의 초안(drafts) 중 대부분은 조용히 만료될 것입니다. 6개월이라는 시간 제한은 IETF가 가진 가장 정직한 메커니즘입니다. 살아남는 것은 그 뒤에 구현(implementation)이 뒷받침되고, 이를 추진할 배포 이해관계자(deployment constituency)가 있으며, 합의(consensus)가 실제로 형성될 수 있는 장소를 갖춘 작업들일 것입니다. 그 외의 모든 것은 타임스탬프(timestamp)에 불과합니다.

에이전트 인터넷(agent internet)은 지금 이 순간에도 공개적으로, 6개월 단위로, 참석하는 데 수고를 아끼지 않는 사람들에 의해 설계되고 있습니다. 초안(draft)의 홍수가 보여주는 규모는 현재의 스택(stack)이 불충분하다고 믿는 사람이 얼마나 많은지를 말해줍니다. 하지만 그것이 누가 옳은지는 말해주지 않습니다.

따라서 귀하의 조직이 베팅하고 있는 어떤 에이전트 표준에 대해 던져볼 가치가 있는 질문은 다음과 같습니다: 그것이 실행 가능한 코드(running code), 배포 이해관계자(deployment constituency), 그리고 합의가 형성될 수 있는 장소를 갖추고 있습니까? 아니면 그저 제출 날짜와 벤더 로드맵(vendor roadmap)만을 가지고 있습니까?