기업이 서로 협력하지 못하는 에이전트를 계속 만드는 이유와 이를 해결할 표준 런타임 제안

Schroeder는 기업들이 운영을 돕기 위해 자체 에이전트를 만들고 있다는 점에서 이야기를 시작한다. 그는 이것이 AI 분야의 통념과 어긋난다고 말한다. 통념에 따르면 AI로 기업을 돕는 올바른 방법은 기업의 부품과 구성 요소를 노출하는 MCP 서버를 만들고, 스킬 파일이나 agents.md 같은 마크다운 파일을 쓴 뒤, 이를 Claude나 Grok 같은 충분히 똑똑한 모델에 넘기는 것이며 그것으로 충분하다는 것이다.

그는 기업들이 단순히 실수하고 있어서 더 나은 조언이 필요하다는 해석도 있을 수 있음을 인정한다. 그러나 그 관점이 부분적으로는 맞을 수 있어도, 시장이 살펴볼 가치가 있는 무언가를 보여주고 있다고 말한다. 그리고 기업이 여전히 에이전트를 만드는 이유로 통합, 신뢰, 효과성이라는 세 가지를 제시한다.

Schroeder가 꼽는 첫 번째 이유는 통합이다. 그는 기업에 깊이 자리 잡은 프로세스는 작은 요소가 아니므로 제대로 다뤄야 한다고 주장한다. 그는 HVAC 수리 회사를 예로 들어, 보증 청구를 관리하고 청구가 보증 기간 안에 있는지 확인하는 일, 적절한 사람을 적절한 곳에 보내는 작업자 일정 관리, 주 정부에서 허가증 받아오기, 캠페인 관리, 계정 확장, 작업 자재 같은 프로세스를 열거한다.

그는 이것이 HVAC 수리에만 해당하지 않는다고 말한다. 대학에는 학자금 지원, 보조금 관리, 기숙사 배정 같은 프로세스가 있고, 클라우드 제공업체는 남용 사례와 청구 분쟁을 처리해야 한다. 그의 표현대로 기업은 사실상 자신의 프로세스이며, 모든 AI 통합은 그 프로세스를 제대로 다뤄야 한다는 것이다.

그는 기업이 프로세스를 신뢰하고, 시간이 지나도 안정적으로 실행되며, 같은 청구가 같은 결과를 내는 반복 가능한 성과를 원한다고 덧붙인다. 또한 각 기업은 유지하고 싶은 고유한 목소리와 어조가 있으므로 완전히 범용적인 도구는 원하지 않는다고 말한다.

두 번째 이유는 신뢰다. Schroeder는 자신과 팀이 즐겨 말하는 표현이 있다고 하며, 에이전트가 무엇이든 할 수 있다면 무엇이든 할 수도 있다는 뜻이라고 말한다. 이것은 책임 위험이며 기업에게는 받아들일 수 없는 일이라고 설명한다. 그는 에이전트가 쓸 수 있는 도구를 아주 세밀하게 조정된 집합으로 제한해야 한다고 제안한다.

그는 보증 청구 에이전트가 보증 포털에 로그인하지 못하자 새 계정을 만들거나, 이메일에 답장하거나, 선거 결과를 찾아보는 예를 든다. 똑똑한 모델은 보통 그런 실수를 하지 않지만, 에이전트가 그렇게 할 수 있는 도구를 가지고 있기 때문에 일어날 수 있다고 그는 말한다.

따라서 기업은 보증 청구가 들어오면 장비를 조회하고, 사진을 첨부하고, 청구를 제출하는 등 특정 도구를 가진 에이전트가 작동하는 명확한 워크플로를 원한다는 것이다.

Schroeder는 그러한 보증 청구 에이전트도 완전한 에이전트라고 주장한다. 여러 차례 턴을 수행하고, 실제 작업을 하고, 평가를 할 수 있으며, 자체 문맥을 가진다. 다만 그 범위는 실제로 수행할 수 있는 일로 제한된다.

그는 모델이 다른 일을 하지 않을 것이라고 믿는 것이 목표가 아니라, 모델이 할 수 있는 일을 제한하는 것이 목표라고 말한다.

Schroeder는 세 번째 필요를 효율성이 아니라 효과성이라고 부르며, 셋 중 가장 중요할 수 있다고 말한다. 핵심 질문은 일이 잘 되었는지다. 그는 모델이 충분히 똑똑한지, 또는 할당된 작업을 효율적으로 완수할 수 있는지를 묻는 것만으로는 부족하며, 중요한 것은 에이전트가 전체적으로 이전에 이루어진 일보다 기업이나 프로세스의 성과를 높이는지 여부라고 주장한다.

그는 HVAC 보증 청구로 돌아가, 청구 자체는 에이전트에게 작은 작업이지만 그 자체로 좋은 에이전트가 될 수 있다고 말한다. 여러 턴이 필요하고 정당한 에이전트이기 때문에 단순한 워크플로가 되지는 않는다는 것이다.

그는 또한 기업 프로세스는 평가할 수 있고 모델은 측정되는 것을 아주 잘하게 될 수 있다고 말한다. 벤치마킹은 잘못된 목표를 겨냥할 때만 부정적이며, 하나의 특정 작업에 맞춰 미세 조정된 에이전트에게는 긍정적이라고 설명한다. 하나의 프롬프트와 특정 도구를 가진 단일 모델도 그 작업만 맡는다면 매우 높은 효과성 비율과 평가 통과율에 도달할 수 있다는 것이다.

Schroeder는 작은 도메인 특화 에이전트가 그토록 가치 있다면 왜 어디에나 있지 않은지 묻는다. 그는 어떤 의미에서는 이미 어디에나 있다고 말한다. 많은 사람들이 지금 에이전트를 만들고 있기 때문이다. 문제는 결과가 엉망이라는 것이다. 에이전트는 서로 다른 언어로, 서로 다른 도구와 서로 다른 에이전트 루프로 작성된다.

그는 에이전트가 모델, 시스템 프롬프트, 도구, 메시지 기록으로 이루어져 단순해 보이지만 실제로는 만들기 어렵다고 설명한다. 빌더는 루프 오케스트레이션, 문제가 생기기 전에 몇 단계까지 실행할 수 있는지, 비동기 시스템이 필요한 병렬 도구 실행, 오류 후에도 재개할 수 있는 내구성을 처리해야 한다. 에이전트를 만든다는 것은 실제로는 하네스를 만드는 일이라고 그는 말한다.

그는 MCP만 쓰는 접근도 문제에 부딪힌다고 덧붙인다. 많은 기업이 추론도 필요하다는 것을 알게 되기 때문이다. 도구에 추론이 필요해지면 여러 추론 단계가 뒤따르고, 빌더는 MCP 안에 에이전트 시스템을 다시 만든 셈이 된다. 맞춤형 하네스조차 문제를 일으킨다. 두 개의 맞춤형 하네스는 쉽게 공유할 수 없고, 하나는 다른 하나의 호스팅 환경에서 실행되지 않을 수 있으며, 둘을 효율적으로 어떻게 조합할지도 불분명하다고 말한다.

Schroeder는 수백 개의 맞춤형 에이전트를 만들고 싶지 않다며 그것은 미친 짓이고 더 나은 무언가가 있어야 한다고 말한다. 그는 해결책이 한 사람이 모든 것을 쓰는 것이 아니라는 증거로 스킬을 든다. 스킬을 쓰는 사람들의 생태계 전체가 있고, 그것은 그저 마크다운 파일일 뿐이라는 것이다. 한 기업이 상호 운용 가능한 에이전트를 수백, 수천 개 만들 것을 기대하는 것은 어리석고, 대신 공유 가능한 에이전트의 생태계가 필요하다고 주장한다.

그는 표준이 답이며, 에이전트 생태계 상당 부분에 이미 표준이 존재한다고 말한다. 도구 배포에는 MCP, 프롬프트 형태로는 스킬과 agents.md, 상호 통신에는 A2A, 그리고 ACP와 결제에는 x402가 있다. 그러나 오늘날 하네스 자체에 대한 표준도, 에이전트 런타임도 없다고 말한다.

Schroeder는 명세가 속도를 제공한다고 말한다. 빌더가 에이전트를 만들 때마다 전체 시스템을 다시 발명할 필요가 없기 때문이다. 루프와 도구를 작성하는 방식을 명세로 정할 수 있으므로, 에이전트를 만드는 사람들이 생태계의 그 부분을 직접 만들 필요가 없다.

또한 일관성을 제공하며, 모든 에이전트가 같은 방식으로 만들어진다는 뜻이다. 그는 이것이 모든 에이전트가 마크다운 파일 하나일 뿐이라는 의미는 아니라고 설명한다. 에이전트는 여전히 깊은 맞춤화가 필요하지만, 그 맞춤화는 호환되는 모든 런타임에서 작동해야 한다는 것이다. 이식성은 에이전트를 묶어서 다른 사람에게 넘길 수 있다는 뜻이며, 그는 zip 드라이브나 USB 스틱에 넣을 수도 있다고 농담한다. 조합성은 작은 부품을 조립해 더 큰 것을 만드는 것을 뜻하며, 이것이 도메인 특화 에이전트를 시장에 내놓는 데 핵심이라고 말한다.

그는 지금까지 그런 명세가 없었다고 말하며, standardagentspec.org에서 이용할 수 있는 오픈소스 표준 에이전트 명세를 발표한다.

Schroeder는 팀이 명세에 따라 작성되는 모든 에이전트가 같은 언어를 쓰기로 했고 TypeScript를 골랐다고 말한다. 그는 팀이 TypeScript를 열렬히 좋아해서 고른 것은 아니라고 말한다. 대신 오늘날 언어 자체는 가치가 거의 없고 중요한 것은 생산되는 결과물뿐이라고 주장한다. 그의 관점에서 중요한 언어는 실제로 두 가지뿐이다. 매우 빠른 고성능 코드를 쓰는 Rust 또는 Rust 계열 시스템과 TypeScript다.

TypeScript는 엣지, 컴퓨터, 휴대폰을 포함해 어디서나 실행된다고 그는 말한다. 인터프리터 방식이기 때문에 에이전트는 빌드나 컴파일 단계 없이도 다른 에이전트를 작성하고 즉시 실행할 수 있으며, 이것이 설계에 필수적이라고 말한다. 그는 팀이 도구를 제공하려면 서버가 필요한 기존 MCP 모델을 피하고, 모든 것을 함께 묶어 두고 싶었다고 덧붙인다.

Schroeder는 모델, 프롬프트, 에이전트가 모두 TypeScript로 정의되며 엄격하게 타입이 지정된다고 설명한다. define model, define prompt, define agent를 사용한다. 코드로 정의된 모델은 에이전트가 실행되는 정확한 모델을 명시한다. 대체 모델도 포함할 수 있으며, 기본 모델이 실패하면 한 단계 더 높은 지능 수준으로 올리는 것을 권장한다.

그는 3D 선 정원을 만들어 사람들이 걸어 다닐 수 있게 하는 Model Zen Garden 프로젝트를 든다. 팀은 가격이 10센트인 한 모델이 다른 모델들보다 훨씬 저렴한 비용으로 3D 정원을 놀랍게 잘 만든다는 것을 발견했다. 그 모델이 전반적으로 아주 좋은 모델은 아니었다고 인정하지만, 그 한 가지 특성에서 뛰어났고, 도메인 특화 에이전트에서는 그런 좁은 강점이 방해가 아니라 이점이라고 말한다.

그는 이것을 모델을 아무렇게나 바꿔 끼워 보고 잘 되기를 바라는 흔한 관행과 대비하며, 이는 효과성의 원칙에 어긋난다고 말한다. 그리고 특정 공급자의 특정 양자화 수준으로 실행되는 아주 구체적인 모델을 에이전트에 고정하는 것이 거의 항상 더 낫다고 결론짓는다.

Schroeder는 프롬프트가 시스템 프롬프트이지만 대화의 한쪽만 담당한다고 말한다. 에이전트의 대화는 항상 어시스턴트와 사용자 사이의 양방향이며, 프롬프트는 그중 한쪽을 맡는다. 프롬프트는 다른 프롬프트를 포함할 수 있고, 이는 런타임에 렌더링된다. 공개 환경 변수는 런타임에 프롬프트에 넣을 수 있으며, 어조 프롬프트는 많은 하위 에이전트에 포함되어 모두가 사용자에게 같은 방식으로 말하도록 할 수 있다.

도구는 세 종류다. TypeScript 코드를 실행하는 함수, 프롬프트, 또는 하위 에이전트 전체다. 프롬프트 도구는 전체 하위 에이전트 없이 이미지를 생성하는 등 다른 곳에서 약간의 추론이 필요하거나, 기본 모델보다 사람처럼 말하는 데 더 나은 모델이 필요할 때 유용하다. 세 번째 종류는 도구로 호출할 수 있는 하위 에이전트 전체다.

그는 명세가 이 요소들을 다양한 방식으로 섞을 수 있게 한다고 말한다. 가장 익숙한 형태는 프롬프트가 사람에게 말하는 것이다. 결정론적 핸들러도 AI 없이 사람에게 말할 수 있고, 프롬프트는 한쪽이 하위 에이전트인 상태에서 사람과 말할 수도 있다고 설명한다.

Schroeder는 핸들러가 사람이나 AI에게 결정론적으로 말하는 예를 든다. 이 예에서는 두 에이전트가 서로 말하는데, 한쪽은 A이고 다른 쪽은 B이며 각 쪽에는 자체 프롬프트가 주어진다. 여기서는 에셋 워커와 에셋 리뷰어가 대화의 두 쪽을 이룬다.

그다음 그는 하위 에이전트를 각자 A측과 B측을 가진 완전한 에이전트라고 설명한다. 그의 예에는 같은 에이전트의 두 인스턴스를 가진 캘린더 에이전트가 있는데, 하나는 업무 캘린더용이고 다른 하나는 개인 캘린더용이며, 둘 다 같은 에이전트와 같은 프롬프트에 기반한다.

Schroeder는 부모 훅을 명세에서 흥미로운 개념이라고 설명한다. 부모 아래에 설치된 자식 하위 에이전트는 부모의 훅을 자동으로 노출하고 수정한다. 이를 통해 추가 설정 없이 조합할 수 있으며, 자식에게 하위 프롬프트가 있어 무언가를 한다고 부모 프롬프트에 알릴 필요도 없다.

그의 예는 Gmail 에이전트를 설치하는 것만으로도 부모가 그것을 어떻게 사용하는지 알기에 충분하다는 것이다. 그는 훅이 메시지 필터링, 도구 호출 전, 메시지 업데이트 후 같은 결정론적 이벤트이며, 에이전트 수명 주기의 특정 순간에 실행되고, 이것이 명세에 정의되어 있다고 설명한다.

그는 또한 효과를 예약된 코드로 설명한다. 개발자는 나중에 발생할 코드 조각을 작성한다. 예를 들어 알람 시계나 이메일 전송 같은 것이다. 도구 호출은 미래의 한 시점에 효과를 예약할 수 있어, 피아노 발표회를 알려 달라는 요청이 적절한 시간에 알림을 설정할 수 있다. 각 스레드는 작은 샌드박스에 비유할 수 있는 완전한 환경이라고 말한다.

Schroeder는 에이전트를 예를 들어 npm 패키지로 묶을 수 있어야 한다고 말한다. 게시되면 누구나 에이전트를 설치하고 로드할 수 있으며 바로 작동한다. 그는 명세가 에이전트가 실행되는 방식에 대한 명시적 규칙을 정하면서도 구현은 열어 둔다는 점에서 이것이 가능하게 하는 것은 런타임이라고 평가한다.

그는 예를 든다. 명세는 단계가 어떻게 처리되는지, 안전이 어떻게 강제되는지, 파일이 어떻게 저장되는지는 정의하지만 파일을 어떻게 읽는지는 말하지 않는다. 그의 팀은 Cloudflare durable objects에서 런타임을 호스팅하며, 여기서 파일 읽기는 데이터베이스에서 읽는 것으로 구현된다. 실제 파일 시스템은 없지만 스레드에는 파일 시스템이 보인다는 것이다. 그는 이것이 핵심 런타임 계약의 일부라고 말한다.

Schroeder는 표준 에이전트 명세를 위한 최초의 공개 런타임으로 Standard Agent Builder를 발표한다. 그의 팀은 이것을 얼마 동안 프로덕션에서 써 왔다고 말한다. 누구나 자신의 컴퓨터에 복제해 사용을 시작할 수 있고, 코딩 에이전트에게 새 에이전트를 만들어 달라고 요청할 수 있으며, 코딩 에이전트는 그 방법을 알고 있다. 코딩 에이전트가 하네스의 모든 부분을 다시 발명할 필요는 없고, 필요한 부분을 결정론적으로 정의하는 방법을 알고 있다는 것이다.

에이전트는 로컬에서 무료로 실행할 수 있고, 프로덕션용으로는 호스팅 클라우드를 쓸 수 있다. 명세가 공개되어 있으므로 사람들은 코딩 에이전트에게 명세를 가리키고 그것을 위한 런타임을 만들도록 할 수 있으며, 팀은 그런 런타임을 명세 사이트에 연결하겠다고 말한다.

이어서 그는 시연을 보여준다. 그날 앞서 그는 Claude Code에 전체 과정이 담긴 PDF를 주어, 앞의 HVAC 예와 비슷한 배터리 보증 청구 에이전트를 만들게 했다. 그는 영상을 빨리 감았다. 에이전트는 PDF에 정의된 모든 내용을 읽은 다음, 그 작업에 맞는 특정 도구를 쓰고 특정 모델을 정의했으며, 이 모든 것을 코드로 작성했다. 아키텍처가 이미 해결되어 있었기 때문에 에이전트는 사람들이 전통적으로 익숙한 것보다 훨씬 빠르게 이것을 할 수 있었다고 그는 말한다. 실시간으로 에이전트를 만드는 데 5분 21초가 걸렸다고 말한다.

Schroeder는 배터리 보증 에이전트의 Standard Agent Builder 관리자 화면을 보여준다. 모든 스레드를 나열하고 일어난 모든 일에 대한 세부 정보를 제공한다. 개발자는 호출된 모든 도구, 정확한 모델, 정확한 비용, 전송된 토큰 수를 볼 수 있다. 이번 실행에서 캐시 비율은 94퍼센트에 이르렀다.

화면에는 모델에 제공된 도구도 나타나는데, 이 경우 여섯 개였고 모델은 그중 하나를 골라 호출한다. 또한 LLM에 보낸 전체 요청 본문도 보여주며, 도구를 만들 때 이것이 가치 있다고 말한다. 이번 실행은 최종적으로 제품 교체 도구를 호출했다. 그는 그 도구들이 해당 프로세스를 위해 만들어진 명시적 도구이며 할당된 작업만 할 수 있었다고 설명한다.

그는 사용자가 에이전트에 접근하는 방법도 보여준다. 웹사이트의 챗봇이 그 위에 만들어졌는데, HTTP와 웹소켓 API가 명세의 일부이기 때문이다. 표준이기 때문에 같은 에이전트를 MCP 서버로도 노출할 수 있어, 챗봇 서비스를 쓰는 사람이 자신의 에이전트가 그것과 통신하도록 할 수 있다고 말한다.

Schroeder는 팀이 사람들이 런타임을 만드는 것을 보게 되어 기쁘다고 말한다. 런타임은 명세에 있는 TypeScript를 실행할 수 있다면 Rust나 Go 같은 어떤 언어로도 작성할 수 있다. 그는 명세를 준수하는 한 런타임은 완전히 열려 있으며, 사람들이 에이전트를 만들고 명세를 깨뜨려 보도록 권한다고 말한다.

그는 팀이 완성된 해법을 제시하는 것이 아니며, 명세를 발전시킬 도움을 찾고 있다고 인정한다. 그는 이 순간을 브라우저들이 각자 기능을 밀어붙이던 웹 초기에 비유하며, 열성적인 명세 애호가들의 모임이 웹을 전체 생태계가 소유한 명세로 바꾸는 데 도움이 되었다고 말한다. 그는 에이전트에서도 같은 일이 일어나기를 바란다고 말한다.