AI를 위한 만능 리모컨: 에이전트 클라이언트 프로토콜(ACP)

URL: https://www.youtube.com/watch?v=YkNulwcc5jk 날짜: 2026-09-10 채널: aiDotEngineer

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 에이전트가 외부 세계로 나가는 통로뿐 아니라, 클라이언트가 에이전트 하네스(Agent Harness)에 작업을 맡기고 결과를 받는 통로까지 표준화하려면 어떤 구조가 필요한가?==

• Model Context Protocol(MCP)은 에이전트가 도구를 호출하고 다른 시스템의 리소스·데이터를 읽는 방향을 표준화했다.
• Agent Client Protocol(ACP)은 클라이언트 소프트웨어가 하네스에 작업을 보내고 상태·결과·권한 요청을 받는 반대 방향을 표준화한다.
• ACP, MCP, 모델의 원격 엔드포인트가 함께 정착하면 클라이언트·하네스·도구·모델 네 구성요소를 독립적으로 배치할 수 있다.

Alex Hancock은 에이전트 생태계가 특정 하네스마다 하나의 전용 앱을 요구하는 상태에서 벗어나야 한다고 주장한다. MCP가 강력한 이유는 설계의 특별함보다 생태계 전체가 채택했다는 사실에 있으며, 같은 채택 효과를 클라이언트와 하네스 사이에도 만들어야 한다. ACP는 Zed와 JetBrains가 어떤 하네스든 제어할 수 있는 고품질 편집기 클라이언트를 하나만 구현하려는 필요에서 출발했으며, 편집기를 넘어 데스크톱·모바일·터미널·도메인 전용 앱으로 확장될 수 있다.

1. 문제 제기: 하네스마다 달라지는 조작 인터페이스

에이전트 하네스의 실행 능력은 빠르게 발전했지만, 사용자가 하네스에 일을 시키는 인터페이스는 아직 표준화되지 않았다.

1.1. Alex Hancock과 문제의 출발점

1. Block에서의 배경

   1. 소속과 제품: Alex Hancock은 Cash App, Square, TIDAL 등을 거느린 Block의 소프트웨어 엔지니어로 일한다.
   2. 제품 개발 경험: 오랫동안 Square와 Cash App의 제품 업무를 맡았고, 최근 몇 년은 오픈소스 AI에 집중했다.

2. 오픈소스 프로젝트 참여

   1. Goose: Block 내부 프로젝트로 시작한 오픈소스 에이전트 하네스 Goose를 개발한다. 하네스는 도구 호출 루프(tool-calling loop)를 구현하는 프로그램이다.
   2. Linux Foundation 기부: Block은 Goose를 공개한 뒤 프로젝트의 지식재산권(IP)을 Linux Foundation에 기부했고, Block의 여러 구성원은 지금도 Goose 개발에 참여한다.
   3. MCP와 ACP: Hancock은 Model Context Protocol의 Rust SDK 유지관리자이며, 최근 Agent Client Protocol 작업에도 참여한다.

3. 짧은 농담으로 드러난 현실

   1. 이전 발언에 대한 반박: 앞선 발표자가 MCP 클라이언트 유지관리자가 tasks 지원을 구현하지 않은 이유를 “똑똑해서”라고 말하자, Hancock은 자신도 MCP 클라이언트 유지관리자라며 실제 이유는 “게을러서(lazy)”라고 정정한다.
   2. tasks의 의미: 클라이언트가 하네스에 작업을 맡기고 진행 결과를 받는 기능은 필요하지만, 유지관리자가 아직 구현하지 못한 상태라는 현실을 자조적으로 드러낸다.

1.2. 맞춤형 인터페이스가 만드는 단절

1. 하네스와 클라이언트의 일대일 결합

   1. 다양한 하네스: AI 연구소, 여러 기업, 오픈 표준 기반 프로젝트가 각각 훌륭한 하네스를 만들고 있다.
   2. 전용 조작 방식: 하네스에 접근하는 클라이언트 인터페이스는 대체로 custom 또는 bespoke 방식이며, 최악의 경우 하나의 하네스를 조작할 수 있는 애플리케이션이 하나뿐이다.

2. 웹 생태계와의 비교

   1. 브라우저 비유: 모든 웹사이트에 접속하려면 사이트마다 다른 브라우저나 전용 프로토콜을 써야 하는 상황과 같다.
   2. 개방형 웹의 조건: 브라우저가 공통 표준으로 여러 웹사이트에 연결되기 때문에 open web이 가능했다. 하네스에도 같은 상호운용성(interoperability)이 필요하다.
   3. 개선 가능성: 하네스의 내부 능력만 늘리는 것으로는 충분하지 않으며, 어떤 클라이언트가 어떤 하네스와 연결되는지에 대한 공통 계층을 마련해야 한다.

2. 표준이 만드는 생태계와 MCP의 성공

표준의 가장 큰 가치는 문서의 완성도가 아니라 여러 구현체가 같은 약속을 사용해 시장과 생태계를 만든다는 데 있다.

2.1. 표준의 네트워크 효과

1. 표준과 생태계의 관계

   1. 연결 규칙의 통일: 서로 다른 구현체가 동일한 표준을 따르면 각 구현체가 다른 모든 구현체와 별도 통합을 만들 필요가 없다.
   2. 시장 형성: 공통 규칙은 서버·클라이언트·도구가 서로 경쟁하고 조합되는 생태계와 시장을 만든다.

2. MCP가 보여준 채택 효과

   1. 에이전트의 외향적 행동: MCP는 에이전트가 도구를 호출하고, 다른 시스템에서 작업을 수행하고, 리소스와 데이터를 읽는 방식을 정리했다.
   2. 핵심 가치는 사용량: MCP의 가장 강력한 점은 프로토콜 자체의 특정 설계가 아니라 커뮤니티 전체가 MCP를 사용한다는 사실이다.
   3. 서버 생태계: 전 세계에 수천 또는 수만 개의 MCP 서버가 생겼고, MCP를 지원하는 에이전트는 같은 규칙으로 다양한 외부 시스템에 연결된다.

2.2. 아직 비어 있는 반대 방향

1. 작업 위임의 공백

   1. 클라이언트의 질문: 클라이언트 소프트웨어가 에이전트에게 “무엇을 할지”, “어떤 작업을 맡길지”, “무슨 작업을 진행 중인지”를 전달할 공통 방식이 없다.
   2. 결과와 업데이트: 하네스가 완료된 결과, 중간 상태, 도구 호출, 권한 요청을 클라이언트로 돌려보내는 표준도 부족하다.

2. ACP 제안

   1. 프로토콜의 역할: Agent Client Protocol은 클라이언트와 에이전트 하네스 사이의 연결·작업·업데이트를 표준화하는 선택지다.
   2. 목표 범위: ACP는 단순히 편집기 안의 코딩 보조 기능에 머무르지 않고, 어떤 클라이언트가 어떤 하네스든 제어할 수 있는 범용 계층을 지향한다.

3. ACP의 탄생 배경과 설계

ACP는 Zed와 JetBrains가 하네스별 통합 비용을 줄이고 하나의 고품질 클라이언트로 여러 하네스를 제어하려는 요구에서 출발했다.

3.1. 편집기 회사가 제안한 이유

1. Zed와 JetBrains의 공통 요구

   1. 단일 클라이언트: Zed 또는 IntelliJ 같은 편집기 안에 고품질 클라이언트 구현을 하나 만들고, 그 구현으로 모든 하네스를 제어하려 했다.
   2. 편집기 작업의 가시성: 사용자가 입력한 작업을 하네스에 보내고 결과를 받으며 어떤 파일이 편집되는지 확인하는 경험을 하려 했다.

2. 편집기 밖으로의 확장

   1. 중립적인 설계: ACP에는 편집기만을 위한 기능이 많지 않아서 특정 편집기 회사에 종속되지 않는다.
   2. Goose 팀의 판단: Goose 팀은 편집기 외에도 광범위한 클라이언트 소프트웨어가 같은 연결 계층을 활용할 수 있다고 봤다.

3.2. 연결과 세션의 기본 구조

1. 연결 수립

   1. capabilities: 클라이언트와 하네스가 연결을 맺을 때 해당 연결이 제공하는 capability 집합을 함께 설정한다.
   2. 상호 이해: 클라이언트는 하네스가 어떤 기능을 지원하는지 알고 그 범위 안에서 세션과 작업을 시작한다.

2. 세션 기반 상호작용

   1. 세션 생성: 연결 위에 세션(session)을 만들고, 특정 작업의 대화와 상태를 세션 단위로 관리한다.
   2. 사용자 메시지: 사용자가 앱에 입력한 문장이나 클라이언트가 생성한 지시를 user message로 하네스에 보낸다.
   3. 에이전트 응답: 하네스는 텍스트뿐 아니라 이미지와 오디오 등 다양한 응답을 클라이언트로 돌려보낸다.

3.3. 도구 호출·권한·확장 메시지

1. 진행 상황의 전달

   1. tool call notification: 에이전트가 도구를 호출하면 어떤 도구를 호출했는지와 관련 metadata를 클라이언트에 알린다.
   2. 사용자 가시성: 클라이언트는 도구 호출과 작업 진행을 화면에 표시해 에이전트가 무엇을 읽고 실행했는지 보여준다.

2. 권한 요청

   1. permission request: 하네스가 도구 호출 전에 사용자의 승인을 받아야 하면 권한 요청을 프로토콜로 보낸다.
   2. 승인 UI: 클라이언트는 “이 도구 호출을 실행할까? Yes 또는 No?”를 묻는 UI를 만들고, 사용자의 결정을 하네스에 돌려보낸다.

3. JSON-RPC와 확장성

   1. 기본 전송 형식: ACP 메시지는 JSON-RPC를 사용하므로 구현체가 비교적 단순한 메시지 교환으로 연결된다.
   2. custom method: vanilla protocol에 없는 기능은 underscore로 시작하는 custom method를 추가할 수 있다.
   3. 사용에서 표준으로: Codex 팀, Goose 팀, 각 클라이언트 팀이 만든 custom method를 생태계가 관찰하면 공통 패턴이 드러난다. 반복해서 사용되는 패턴은 이후 표준 트랙으로 올려 공식 프로토콜에 편입할 수 있다.
   4. 커뮤니티가 형성하는 규격: 처음부터 모든 요구를 예측해 거대한 표준을 만드는 대신, 실제 프로젝트가 사용하는 방식이 ACP의 확장 방향을 결정한다.

4. 로컬 ACP 데모: 두 클라이언트와 하나의 Goose

같은 하네스가 표준 인터페이스를 통해 여러 클라이언트에 연결되면 클라이언트와 하네스의 구현을 독립적으로 교체할 수 있다.

4.1. Zed가 Goose를 구동하는 흐름

1. 프로젝트와 요청

   1. 간단한 프로젝트: Zed에서 단일 HTML 파일로 구성된 아주 간단한 프로젝트를 연다.
   2. 사용자 지시: Zed에 “Tell me about this project.”라고 입력해 프로젝트 설명을 요청한다.

2. Goose의 응답 과정

   1. ACP 연결: Zed는 Goose의 ACP 인터페이스를 통해 작업을 전송한다.
   2. 스트리밍 텍스트: Goose는 처리 중인 텍스트를 클라이언트로 스트리밍한다.
   3. 도구 호출 정보: Goose는 무엇을 읽고 무엇을 실행했는지 tool call 정보로 보낸다.
   4. 결과: Goose는 프로젝트가 단일 HTML 파일이라는 사실을 찾아내고 그 구조를 설명한다.

4.2. Poolside 터미널 클라이언트가 같은 Goose를 구동하는 흐름

1. 두 번째 클라이언트

   1. Poolside AI: Poolside AI가 만든 터미널 기반 클라이언트를 같은 프로젝트에 연결한다.
   2. 동일한 요청: 터미널에서도 “Tell me about this project.”를 보낸다.

2. 동일 하네스·동일 경험

   1. 같은 결과 구조: 터미널 클라이언트도 텍스트 결과, 도구 호출, 스트리밍 요약을 차례로 받는다.
   2. 구현의 분리: 하네스 쪽은 Goose 구현 하나만 유지하면서 Zed와 Poolside 터미널 클라이언트가 각각 같은 에이전트를 제어한다.
   3. 핵심 효과: 사용자는 Goose를 쓰기 위해 Goose 전용 애플리케이션에 갇히지 않고, 자신의 작업 방식에 맞는 클라이언트를 선택할 수 있다.

5. 원격 전송과 네 부분으로 이동 가능한 에이전트 스택

로컬 표준 입출력(standard IO)만으로는 클라우드에서 실행되는 에이전트를 연결할 수 없으므로 ACP에도 원격 transport가 필요하다.

5.1. 로컬 연결의 한계

1. 표준 IO 데모의 범위

   1. 로컬 프로세스: Zed와 Poolside 클라이언트는 로컬에서 같은 Goose 프로세스와 standard IO로 대화한다.
   2. 확장 조건: 에이전트가 클라우드나 컨테이너에서 실행되는 현실에서는 같은 머신 안의 프로세스 연결만으로는 생태계가 커지지 않는다.

2. ACP의 원격 보완

   1. 기존 공백: Goose 팀이 ACP 프로젝트에 합류했을 때 ACP에는 remote support가 아직 없었다.
   2. 프로토콜 의미 보존: 원격으로 이동해도 메시지와 프로토콜 semantics는 동일하게 유지해야 한다.

5.2. HTTP와 WebSocket transport

1. 새 전송 계층

   1. HTTP transport: Goose 팀은 ACP 메시지를 전달하는 HTTP 버전을 명세했다.
   2. WebSocket upgrade: 양방향 실시간 통신을 위해 WebSocket으로 업그레이드하는 경로도 마련했다.

2. 로컬·원격 전환

   1. 동일한 메시지: standard IO와 HTTP/WebSocket은 전송 방식만 다르고 메시지와 프로토콜 semantics는 같다.
   2. 동일한 라이브러리: 클라이언트가 사용하는 라이브러리도 같기 때문에 로컬 프로세스에서 원격 프로세스로 쉽게 전환할 수 있다.

3. 직접 만든 원격 클라이언트

   1. 라이브 코딩: Hancock은 발표 전날 밤 원격 클라이언트의 일부를 직접 라이브 코딩했다.
   2. 짧은 시연: 클라이언트에 “Write a poem.”이라고 입력해 같은 머신의 Goose 프로세스에 네트워크로 지시를 보냈다.
   3. 배치 가능성: 현재 프로세스가 같은 머신에 있어도 transport는 네트워크를 통과하며, 동일한 구조를 컨테이너나 클라우드에 있는 Goose에도 적용할 수 있다.

5.3. 독립 배치 가능한 네 구성요소

1. 클라이언트(client)

   1. 사용자 앱: 사용자가 직접 쓰는 애플리케이션이거나 특정 머신에서 실행되는 headless 앱이다.
   2. 역할: 사용자 메시지를 만들고 하네스의 텍스트·이미지·오디오·도구 호출·권한 상태를 표시한다.

2. 하네스(harness)

   1. 실행 프로그램: tool-calling loop를 구현하고 모델과 도구를 조정하는 프로그램이다.
   2. 독립 이동: ACP 원격 transport가 있으면 클라이언트와 다른 머신·컨테이너·클라우드에 둘 수 있다.

3. 도구(tools)

   1. 외부 행동 계층: 에이전트가 읽고 실행하는 실제 시스템과 기능이며, 흔히 MCP 서버로 제공된다.
   2. 독립 원격화: MCP가 원격 tool-calling transport를 제공하므로 도구만 다른 위치에 둘 수 있다.

4. 모델(model)

   1. 추론 계층: 하네스가 작업을 판단하고 다음 도구 호출을 선택하는 데 사용하는 모델이다.
   2. 원격 엔드포인트: Responses API 같은 모델 원격 엔드포인트는 이미 오랫동안 사용되어 모델만 외부에 둘 수 있다.

5. 네 구성요소의 조합

   1. 한 머신 배치: 클라이언트·하네스·도구·모델을 모두 한 머신에 둘 수 있다.
   2. 혼합 배치: 하네스만 클라이언트와 다른 머신에 두거나, 모델만 원격으로 두거나, 도구만 원격으로 둘 수 있다.
   3. 이동성의 조건: ACP의 클라이언트-하네스 transport, MCP의 도구 transport, 모델의 원격 API를 표준화하고 transport 품질을 보장해야 스택 전체를 자유롭게 재배치할 수 있다.

6. 클라이언트 생태계가 만드는 사용 경험 시장

ACP 상호운용성이 정착하면 하네스를 만드는 회사뿐 아니라 사용자가 실제로 접하는 클라이언트도 독립적인 제품·시장으로 성장한다.

6.1. 가능한 클라이언트 유형

1. 범용 클라이언트

   1. 편집기: Zed나 IntelliJ 같은 개발 편집기가 여러 하네스를 제어한다.
   2. 데스크톱·모바일·터미널: 데스크톱 애플리케이션, 모바일 애플리케이션, 터미널 기반 클라이언트가 동일한 하네스 생태계에 참여한다.

2. 목적형 클라이언트

   1. 개인용 앱: 사용자가 자신의 방식대로 에이전트를 오케스트레이션하는 개인 클라이언트를 만든다.
   2. 도메인 전용 앱: 특정 비즈니스 영역에 맞는 클라이언트나 한 기업 내부 업무에 맞춘 클라이언트를 만든다.
   3. 화이트 라벨: 한 회사가 브랜드와 업무 흐름을 맞춤화한 white-label 클라이언트를 만들고 여러 하네스와 연결한다.

6.2. 경쟁이 사용자 경험을 끌어올리는 구조

1. 새 제품 카테고리

   1. 선택지의 증가: 클라이언트가 하나뿐인 구조에서 벗어나면 여러 팀과 회사가 각기 다른 사용 경험을 제공한다.
   2. 사용자 선택권: 클라이언트가 요구를 충족하지 못하면 사용자는 다른 제품으로 이동해 발로 투표할 수 있다.

2. 품질 경쟁

   1. 경쟁 요소: 클라이언트 제작자는 연결 가능 여부뿐 아니라 화면 구성, 진행 상태 표시, 권한 승인 흐름, 전체 UX 품질로 경쟁한다.
   2. AI 사용 경험의 상승: 생태계와 marketplace가 형성되면 클라이언트 품질 경쟁이 전체 AI 사용 경험을 끌어올린다.

6.3. 참여 방법과 마무리

1. 개발자 참여

   1. 클라이언트 제작: ACP 지원을 추가해 자신만의 클라이언트를 만들고, 편집기·데스크톱·모바일·터미널 경험을 실험한다.
   2. 하네스 통합: Goose 같은 하네스에 ACP 인터페이스를 추가해 여러 클라이언트가 연결되게 한다.
   3. 프로토콜 사이트: Agent Client Protocol 사이트에서 시작 방법과 이미 참여한 클라이언트·에이전트 서버 목록을 확인한다.

2. 최종 제안

   1. 상호운용성 실험: 클라이언트와 하네스 양쪽에서 ACP 지원을 실험해 실제 사용 패턴을 만든다.
   2. 생태계의 다음 단계: 실제 구현이 늘어나면 custom method에서 공통 규격이 도출되고, 개인·기업·도메인별 클라이언트 시장이 형성된다.
   3. 연락과 협력: Hancock은 행사 현장에서 대화하거나 이메일로 연락해 ACP 작업에 참여해 달라고 요청한다.

주요 발언 모음

“The most powerful thing about MCP is not anything about MCP itself, but it's that everyone uses MCP.”

“I would say that we don't yet have a good solution or a standard for client software to tell agents what to do.”

“It would be like if you had to use one browser or one given protocol to connect to every website.”

“Users can vote with their feet if clients aren't meeting their needs.”

“The reason I haven't done it is just because I'm lazy.”

핵심 데이터 & 수치

• 영상 길이: 약 11분(660초)이며, 핵심 흐름은 0:00 Goose·MCP·ACP, 1:23 bespoke interface, 2:21 standards, 3:02 ACP 설계, 6:17 두 클라이언트 데모, 7:24 원격 transport와 네 구성요소, 9:26 클라이언트 생태계로 이어진다.
• 하네스 배경: Goose는 Block 내부 프로젝트로 시작해 오픈소스로 공개됐고 Linux Foundation에 IP가 기부됐다.
• MCP 규모 표현: MCP 채택으로 전 세계에 수천 또는 수만 개의 서버가 생겼다고 언급된다.
• 메시지 형식: ACP는 JSON-RPC 메시지를 사용한다.
• 응답 유형: 텍스트, 이미지, 오디오, 작업 업데이트, 도구 호출 알림, 권한 요청을 전달할 수 있다.
• 확장 규칙: 표준 밖의 custom method는 underscore(_) 접두사를 사용한다.
• 전송 방식: 로컬 standard IO와 원격 HTTP, WebSocket upgrade를 사용할 수 있다.
• 이동 가능한 계층: client, harness, tools, model 네 구성요소가 같은 머신 또는 서로 다른 원격 위치에 배치될 수 있다.

결론 및 시사점

1. 에이전트 연결의 양방향 표준화: MCP가 에이전트에서 도구로 향하는 길을 열었고, ACP가 클라이언트에서 하네스로 향하는 길을 정리한다.
2. 하네스 종속성 완화: ACP를 지원하는 Goose는 Zed와 Poolside 터미널 클라이언트에서 같은 방식으로 제어되며, 사용자는 클라이언트를 바꿀 수 있다.
3. 원격 실행의 기반: HTTP/WebSocket transport는 클라우드·컨테이너의 하네스를 로컬 클라이언트와 연결하고, 동일한 메시지와 라이브러리로 로컬·원격 전환을 가능하게 한다.
4. 스택 재배치: client·harness·tools·model에 각각 좋은 표준 transport가 있으면 비용·보안·성능·운영 요구에 맞춰 네 계층을 독립적으로 배치할 수 있다.
5. 사용자 경험의 시장화: 상호운용성이 새 클라이언트 카테고리를 만들면 개인용·도메인용·화이트 라벨 제품이 경쟁하고 AI 사용 경험의 품질을 끌어올린다.
6. 표준은 사용에서 자란다: 모든 요구를 처음부터 고정하기보다 underscore 기반 확장으로 실제 공통 패턴을 수집하고, 충분히 검증된 패턴을 정식 표준으로 승격하는 접근이 지속 가능하다.
7. 실행 포인트: 클라이언트 제작자는 ACP 연결을 실험하고, 하네스 제작자는 ACP 인터페이스를 제공하며, 양쪽은 실제 사용에서 나타나는 공통 요구를 표준화 과정에 되돌려야 한다.

핵심 요약 (20줄)

1. Alex Hancock은 Block에서 Goose 오픈소스 하네스와 MCP Rust SDK를 개발하며 ACP 작업에도 참여한다.
2. Block은 내부 프로젝트로 시작한 Goose를 오픈소스로 공개하고 Linux Foundation에 지식재산권을 기부했다.
3. MCP 클라이언트 유지관리자가 tasks 기능을 아직 구현하지 않은 이유는 똑똑해서가 아니라 게을러서라는 농담이 현실의 공백을 드러낸다.
4. AI 하네스는 많아졌지만 하네스마다 custom 또는 bespoke 클라이언트 인터페이스를 요구한다.
5. 하네스마다 전용 앱이 하나씩 필요한 구조는 웹사이트마다 다른 브라우저가 필요한 상황과 같다.
6. 표준은 구현체들이 같은 약속을 사용하게 해 생태계와 시장을 만든다.
7. MCP의 가장 강력한 점은 특별한 설계보다 모두가 채택했다는 사실에 있다.
8. MCP 덕분에 에이전트는 수천 또는 수만 개의 서버에 연결해 도구를 호출하고 데이터를 읽을 수 있다.
9. 클라이언트가 에이전트에게 작업을 맡기고 진행 업데이트를 받는 방향에는 아직 널리 쓰이는 표준이 없다.
10. ACP는 Zed와 JetBrains가 하나의 고품질 편집기 클라이언트로 어떤 하네스든 제어하려는 요구에서 출발했다.
11. ACP는 편집기 전용 기능에 묶이지 않아 데스크톱·모바일·터미널 클라이언트로 확장될 수 있다.
12. ACP 연결은 capability를 협상한 뒤 세션 안에서 사용자 메시지와 에이전트 응답을 주고받는다.
13. 에이전트는 텍스트·이미지·오디오뿐 아니라 도구 호출 알림과 작업 업데이트도 클라이언트로 보낸다.
14. permission request는 클라이언트가 도구 호출의 실행 여부를 사용자에게 묻도록 만든다.
15. ACP는 JSON-RPC를 사용하고 underscore 접두사의 custom method로 실제 생태계의 요구를 흡수한다.
16. Zed는 Goose에 단일 HTML 프로젝트를 설명하라고 요청해 텍스트·도구 호출·스트리밍 결과를 받았다.
17. Poolside AI 터미널 클라이언트도 같은 Goose에 같은 요청을 보내 동일한 결과 구조를 얻었다.
18. Goose 팀은 ACP에 HTTP와 WebSocket transport를 추가해 로컬 standard IO와 원격 실행을 연결했다.
19. client·harness·tools·model 네 요소는 표준 transport를 통해 같은 머신이나 서로 다른 원격 위치에 배치될 수 있다.
20. ACP 생태계는 개인용·도메인용·화이트 라벨 클라이언트 경쟁을 만들고 AI 사용자 경험의 품질을 높일 수 있다.