AI 에이전트를 위한 만능 리모컨, ACP 소개

URL: https://www.youtube.com/watch?v=tOPsby-irKY
날짜: 2026-09-13
채널: Tech Bridge

---

📌 핵심 질문 / 에이전트를 조종하는 공통 인터페이스가 필요한 이유

==AI 에이전트가 특정 애플리케이션에 갇히지 않고 어떤 클라이언트에서도 동일하게 실행되려면, 클라이언트와 에이전트 하네스를 연결하는 개방형 표준이 필요하다.==

• 에이전트 하네스(agent harness)는 많아졌지만 하네스를 조종하는 클라이언트 인터페이스는 대체로 맞춤형·독점적이다.
• MCP(Model Context Protocol)는 에이전트가 외부 도구와 데이터에 접근하는 방향의 공통 표준을 만들었지만, 클라이언트가 에이전트에 작업을 주고 진행 상태를 받는 반대 방향의 표준은 아직 충분하지 않다.
• ACP(Agent Client Protocol)는 JSON-RPC(JSON Remote Procedure Call) 기반 메시지, 세션, 기능 협상, 도구 호출 알림, 권한 요청, 스트리밍 응답을 제공해 이 공백을 메우려 한다.
• Zed·JetBrains에서 시작된 아이디어는 편집기를 넘어 데스크톱·모바일·터미널·헤드리스 클라이언트와 원격 클라우드 하네스까지 연결하는 생태계로 확장될 수 있다.

서로 다른 클라이언트가 같은 에이전트 하네스를 재사용하면 사용자는 작업 방식과 기기에 맞는 인터페이스를 고를 수 있고, 개발자는 모든 하네스마다 별도 통합을 만들 필요가 없어진다. ACP가 충분히 채택되면 클라이언트 자체가 하나의 경쟁적 시장이 되어 AI 사용 경험의 품질도 올라간다.

1. 발표 배경과 문제 제기

1.1. Alex Hancock의 배경과 ACP로 이어진 경로

1. Block에서의 소프트웨어 개발 경험

   1. 소속: Alex Hancock은 Cash App, Square, Tidal의 모회사인 Block에서 소프트웨어 엔지니어로 일한다.
   2. 업무 이력: 오랫동안 Block에서 일하며 Square와 Cash App 관련 업무를 맡았고, 최근 몇 년 동안 오픈소스 AI에 집중했다.

2. Goose와 오픈소스 활동

   1. 프로젝트의 시작: Goose는 Block 내부 프로젝트로 출발한 오픈소스 에이전트 하네스(agent harness)다.
   2. 재단 이관: Goose는 오픈소스로 공개된 뒤 Linux Foundation에 기증됐고, 지식재산권(IP)은 재단에 귀속됐다.
   3. 지속적인 기여: Block 출신 구성원 다수가 기증 이후에도 Goose 개발에 계속 참여한다.
   4. 현장 반응: Goose 팬이 있는지 묻는 듯한 순간에 청중의 반응이 포착되며 프로젝트의 커뮤니티 기반을 드러낸다.

3. MCP와 ACP 유지보수 경험

   1. MCP 역할: Alex Hancock은 MCP(Model Context Protocol) 유지보수자이며, 해당 프로젝트의 Rust SDK를 맡고 있다.
   2. ACP 참여: 최근 ACP(Agent Client Protocol) 작업도 시작했고, 이 작업이 클라이언트와 하네스를 연결하는 표준 제안으로 이어진다.

1.2. 시작을 여는 농담과 문제의식

1. 이전 발언에 대한 반박

   1. 앞선 주장: 앞선 발언은 MCP 클라이언트 유지보수자가 작업(tasks) 지원을 구현하지 않은 이유를 “똑똑하기 때문”이라고 표현했다.
   2. 자기 고백: MCP 클라이언트 유지보수자인 Alex Hancock은 작업 지원이 없는 이유가 똑똑해서가 아니라 자신이 게을러서 아직 구현하지 않았기 때문이라고 농담한다.
   3. 농담의 기능: 구현 부족을 능력의 문제로 포장하지 않고, 실제 생태계가 아직 작업 전달과 상태 갱신을 제대로 표준화하지 못했다는 문제를 가볍게 꺼낸다.

2. 제안의 전개 방식

   1. 문제 제시: 현재 에이전트 하네스가 가진 인터페이스의 파편화를 문제로 제시한다.
   2. 해법 제안: 문제를 설명한 뒤 팀이 작업 중인 개방형 표준 ACP를 해결책으로 추천한다.

2. 에이전트 하네스 생태계의 단절

2.1. 하네스는 늘었지만 클라이언트는 종속된다

1. 다양한 하네스의 등장

   1. 공급 주체: AI 연구소(labs)가 만든 하네스, 여러 기업이 만든 하네스, 오픈소스 프로젝트가 만든 하네스가 함께 존재한다.
   2. 현재의 역설: 하네스의 내부 기능과 수는 늘었지만 외부에서 하네스를 조작하는 인터페이스는 통일되지 않았다.

2. 맞춤형 인터페이스의 비용

   1. 관행: 하네스에 연결하는 인터페이스가 custom 또는 bespoke 방식으로 만들어지는 경우가 많다.
   2. 최악의 경우: 어떤 하네스는 제어할 수 있는 클라이언트 애플리케이션이 사실상 하나뿐이다.
   3. 사용자 제약: 사용자는 같은 에이전트 능력을 다른 편집기나 터미널에서 사용하고 싶어도 하네스가 허용한 애플리케이션에 머물러야 한다.
   4. 개발자 제약: 클라이언트 개발자는 하네스마다 별도의 통합 코드를 만들어야 하므로 생태계 전체의 발전 속도가 느려진다.

2.2. 웹 브라우저가 보여주는 상호운용성의 기준

1. 브라우저 비유

   1. 가정: 모든 웹사이트에 접속하려면 사이트마다 정해진 브라우저 하나 또는 전용 프로토콜 하나를 써야 한다고 가정한다.
   2. 결과: 그런 구조라면 오늘날의 개방형 웹(open web)은 성립하기 어렵다.
   3. 대응 관계: 웹사이트와 브라우저의 관계처럼 에이전트 하네스와 클라이언트도 공통 프로토콜을 통해 상호운용돼야 한다.

2. 표준이 만드는 생태계

   1. 시장 형성: 표준은 연결 방식을 통일해 여러 구현이 참여할 수 있는 생태계와 시장을 만든다.
   2. 선택권 확대: 하나의 클라이언트만 강제하지 않으면 사용자는 작업 방식, 기기, 사용자 경험에 맞춰 도구를 선택할 수 있다.
   3. 개방성의 기준: 중요한 것은 특정 표준의 기능 목록 자체보다 많은 구현이 같은 표준을 채택해 서로 연결되는 사실이다.

2.3. MCP가 해결한 방향과 남은 방향

1. MCP가 표준화한 에이전트의 외부 행동

   1. 도구 호출: 에이전트가 도구를 호출해 다른 시스템에서 작업을 수행할 수 있다.
   2. 외부 시스템의 행동: 에이전트가 다른 시스템에 명령을 보내고 상태를 바꿀 수 있다.
   3. 리소스·데이터 읽기: 에이전트가 외부 리소스와 데이터를 읽을 수 있다.

2. MCP의 가장 강력한 점은 채택 자체다

   1. 공동체 효과: MCP의 가장 강력한 점은 개별 메시지나 기능이 아니라 모두가 MCP를 사용한다는 사실이다.
   2. 서버 규모: 이러한 공통 채택 덕분에 전 세계에 수천 개 또는 수만 개의 MCP 서버가 생겼다.
   3. 연결 효과: 여러 에이전트가 같은 서버에 연결해 외부 시스템에서 행동할 수 있다.

3. ACP가 겨냥하는 반대 방향

   1. 작업 전달: 클라이언트 소프트웨어가 에이전트에 무엇을 할지, 어떤 작업을 맡을지 전달해야 한다.
   2. 작업 범위 지정: 클라이언트가 에이전트에 무엇을 작업할지 구체적으로 알려야 한다.
   3. 상태 수신: 클라이언트가 작업 결과와 진행 상태 업데이트를 받아 사용자에게 보여줘야 한다.
   4. 표준의 공백: 이 클라이언트→에이전트 방향에는 MCP만큼 널리 쓰이는 좋은 표준이 아직 없다.

3. ACP의 출발점과 설계 목표

3.1. 편집기에서 시작된 Agent Client Protocol

1. 제안 주체

   1. Zed: Zed 텍스트 편집기를 만드는 팀이 클라이언트 표준의 필요성을 제기했다.
   2. JetBrains: IntelliJ를 비롯한 JetBrains 제품을 만드는 팀이 Zed 팀과 협력했다.
   3. 공동 제안: 두 편집기 회사가 클라이언트가 여러 하네스를 제어할 수 있는 표준으로 ACP를 제안했다.

2. 편집기 회사가 원한 단일 구현

   1. 고품질 클라이언트: Zed나 IntelliJ 같은 편집기 안에서 한 번만 고품질 클라이언트 구현을 작성한다.
   2. 하네스 범용 제어: 동일한 클라이언트 구현으로 어떤 에이전트 하네스든 제어한다.
   3. 작업·결과 교환: 작업을 보내고 결과를 돌려받는다.
   4. 파일 상태 확인: 어떤 파일이 편집되고 있는지 확인한다.

3.2. 편집기를 넘어서는 중립적 범용성

1. Goose 팀의 관찰

   1. 범위 확장: ACP의 효용은 편집기 통합에만 한정되지 않는다.
   2. 중립적 설계: ACP에는 특정 편집기에 종속된 기능이 많지 않으므로 편집기 밖의 클라이언트에도 적용할 수 있다.

2. 확장 가능한 클라이언트 층

   1. 앱 유형: 사용자가 직접 쓰는 애플리케이션뿐 아니라 기기에서 실행되는 헤드리스(headless) 애플리케이션도 클라이언트가 될 수 있다.
   2. 기능 분리: 클라이언트가 사용자 인터페이스를 담당하고, 하네스가 도구 호출 루프를 담당하는 식으로 역할을 나눌 수 있다.
   3. 재사용성: 하네스는 클라이언트별 UI를 다시 구현하지 않아도 되고, 클라이언트는 하네스별 제어 로직을 다시 만들지 않아도 된다.

3.3. 연결·세션·메시지로 구성된 흐름

1. 연결과 기능(capability)

   1. 연결 수립: ACP는 클라이언트와 에이전트 하네스 사이에 연결을 만든다.
   2. 기능 표현: 각 연결에는 상대방이 지원하는 기능 집합이 연관된다.
   3. 능력 기반 상호작용: 클라이언트는 연결에서 제공되는 기능을 알고 그에 맞는 작업을 요청할 수 있다.

2. 세션(session)

   1. 세션 생성: 연결 위에서 세션을 만들고 개별 작업 흐름을 유지한다.
   2. 사용자 메시지 전달: 사용자가 앱에 직접 입력한 메시지 또는 클라이언트 소프트웨어가 생성한 메시지를 세션 안에서 보낸다.
   3. 상태 지속: 세션은 요청과 응답을 하나의 연속적인 에이전트 작업 맥락으로 묶는다.

3. 에이전트의 응답 유형

   1. 텍스트: 에이전트는 텍스트를 반환한다.
   2. 멀티미디어: 이미지, 오디오, 텍스트 등 여러 형태의 결과를 반환할 수 있다.
   3. 진행 업데이트: 하네스에서 어떤 일이 벌어지고 있는지 상태 업데이트를 보낸다.

4. 도구 호출과 권한 요청

   1. 도구 호출 알림: 도구가 호출되면 어떤 도구가 호출됐는지와 메타데이터가 무엇인지 알려준다.
   2. 사용자 승인 흐름: 클라이언트는 “이 도구 호출을 실행할까요?”라는 질문을 사용자에게 보여줄 수 있다.
   3. 예·아니오 전달: 사용자의 승인 또는 거절 응답도 ACP를 통해 전달할 수 있다.

3.4. JSON-RPC와 커뮤니티 주도 확장

1. 단순한 메시지 형식

   1. 기반 기술: ACP는 JSON-RPC(JSON Remote Procedure Call) 메시지를 사용한다.
   2. 의미와 전송의 분리: 같은 메시지와 프로토콜 의미를 유지하면서 통신 전송 방식은 별도로 바꿀 수 있다.
   3. 구현 진입장벽: 단순한 메시지 모델 덕분에 클라이언트와 하네스 구현자가 프로토콜을 실험하기 쉽다.

2. 사용자 정의 메서드

   1. 기본 프로토콜의 한계 회피: “바닐라” ACP에 정의된 기능만 사용할 필요가 없다.
   2. 명명 규칙: 사용자 정의 메서드는 밑줄(_)을 붙인 뒤 메서드 이름을 시작하는 관례를 따른다.
   3. 프로젝트별 확장: Goose 팀, Codex 팀, 클라이언트 팀 등이 각자의 추가 메서드를 실험할 수 있다.

3. 사용량이 표준을 다듬는 방식

   1. 공통 패턴 발견: 여러 하네스와 클라이언트가 구현한 사용자 정의 메서드를 비교하면 반복되는 요구를 확인할 수 있다.
   2. 표준 승격: 충분히 많은 프로젝트에서 같은 방식이 반복되면 표준 트랙에 올려 ACP 본체로 가져올 수 있다.
   3. 커뮤니티 형성: 무엇이 필요한지 먼저 사용 사례로 검증한 뒤 커뮤니티가 프로토콜을 형성한다.

4. 로컬 클라이언트 상호운용성 데모

4.1. Zed에서 Goose를 제어하는 흐름

1. 단일 HTML 프로젝트

   1. 프로젝트 구성: Zed에서 간단한 프로젝트를 열고, 프로젝트는 HTML 파일 하나로 구성된다.
   2. 입력: Zed 클라이언트에 “이 프로젝트를 설명해줘(Tell me about this project)”라고 입력한다.

2. Goose의 ACP 응답

   1. 하네스 확인: Zed에서 실행되는 에이전트는 Goose이며, Goose의 ACP 인터페이스를 사용한다.
   2. 스트리밍 텍스트: Goose는 텍스트를 실시간으로 돌려준다.
   3. 도구 호출 정보: Goose가 파일을 읽고 무엇을 했는지 보여주는 도구 호출 정보를 보낸다.
   4. 결과: Goose는 프로젝트가 HTML 파일 하나로 구성됐다는 사실을 찾아내고 그 구조를 설명한다.

4.2. Poolside AI 터미널 클라이언트로 같은 하네스 사용하기

1. 두 번째 클라이언트

   1. 클라이언트 유형: Poolside AI에서 만든 터미널 기반 클라이언트를 사용한다.
   2. 동일한 요청: 같은 프로젝트에 다시 “이 프로젝트를 설명해줘”라고 요청한다.

2. 동일한 경험의 재현

   1. 서버 측 변경 없음: 하네스 쪽 구현은 하나만 두고 클라이언트만 바꾼다.
   2. 결과의 일관성: 터미널 클라이언트도 텍스트 결과, 도구 호출 정보, 스트리밍 요약을 차례로 받는다.
   3. 핵심 증명: Zed와 터미널이라는 서로 다른 클라이언트가 같은 Goose 에이전트와 통신하면서 동일한 기본 경험을 제공한다.

3. 로컬 표준 입출력(standard I/O)

   1. 데모 방식: 두 클라이언트는 이 시점에 로컬 standard I/O를 통해 같은 에이전트와 대화한다.
   2. 의미: 클라이언트와 하네스 사이의 연결 방식이 표준화되면 UI가 달라도 요청·응답·도구 상태의 의미를 공유할 수 있다.

5. 원격 전송과 에이전트 스택 재배치

5.1. 로컬만으로는 부족한 이유

1. 클라우드 실행 환경

   1. 원격 필요성: ACP 생태계가 확산되려면 로컬 프로세스 연결만으로는 충분하지 않다.
   2. 실행 위치 변화: 에이전트는 앞으로 클라우드에서 실행되는 경우가 많아진다.
   3. 제품 조건: 클라이언트가 로컬 하네스뿐 아니라 컨테이너와 클라우드의 하네스에도 연결돼야 한다.

2. 초기 ACP의 공백과 보완

   1. 당시 상태: Goose 팀이 ACP를 살펴봤을 때 ACP에는 원격 지원이 아직 없었다.
   2. 팀의 기여: Goose 팀은 원격 통신을 위한 HTTP 전송(transport)을 사양에 추가했다.

5.2. HTTP와 WebSocket 업그레이드

1. 새 전송 방식

   1. HTTP 버전: ACP 메시지를 HTTP 전송으로 주고받을 수 있다.
   2. WebSocket 전환: 필요할 때 WebSocket 업그레이드를 사용할 수 있다.

2. 프로토콜 의미의 보존

   1. 동일한 메시지: 로컬 방식과 원격 방식에서 주고받는 메시지는 같다.
   2. 동일한 의미론: 프로토콜의 의미와 상호작용 규칙도 같다.
   3. 추가되는 유연성: 전송 계층만 바뀌므로 같은 클라이언트 라이브러리로 로컬과 원격을 오갈 수 있다.

5.3. 네 가지 구성요소로 보는 에이전트 스택

1. 클라이언트(client)

   1. 사용자용 앱: 사용자가 직접 사용하는 애플리케이션이다.
   2. 헤드리스 앱: 특정 기기에서 사용자 인터페이스 없이 실행되는 애플리케이션도 클라이언트가 될 수 있다.

2. 하네스(harness)

   1. 실행 프로그램: 모델과 도구를 연결해 에이전트의 작업을 실행하는 프로그램이다.
   2. 도구 호출 루프: 모델의 판단에 따라 도구를 호출하고 결과를 다시 모델에 넣는 루프를 구현한다.

3. 도구(tools)

   1. 외부 행동 수단: 에이전트가 파일·서비스·다른 시스템과 상호작용할 수 있게 하는 구성요소다.
   2. MCP와의 관계: 도구 계층은 흔히 MCP를 통해 연결된다.

4. 모델(model)

   1. 판단 계층: 작업을 해석하고 다음 행동을 결정하는 모델이다.
   2. 원격 엔드포인트: 모델은 오래전부터 Responses API 같은 원격 엔드포인트를 제공해 왔다.

5.4. 표준 전송이 가능하게 하는 배치 조합

1. 모든 구성요소를 한 기기에 배치하기

   1. 단일 머신: 클라이언트, 하네스, 도구, 모델을 모두 같은 머신에 둘 수 있다.
   2. 개발 편의성: 로컬에서 빠르게 실험하고 디버깅하기 좋은 배치다.

2. 클라이언트와 하네스 분리하기

   1. 다른 머신: 하네스를 클라이언트와 다른 머신에서 실행할 수 있다.
   2. 원격 에이전트: 클라이언트는 로컬에서 사용하면서 실행 비용이 큰 하네스는 서버나 클라우드에 둘 수 있다.

3. 모델만 원격으로 두기

   1. 분리된 모델 계층: 하네스와 도구는 로컬에 두고 모델만 원격 API로 연결할 수 있다.
   2. 유연한 선택: 로컬 도구 접근성을 유지하면서 원격 모델의 성능이나 기능을 활용할 수 있다.

4. 도구만 원격으로 두기

   1. 분리된 도구 계층: 클라이언트·하네스·모델은 로컬에 두고 도구만 원격 MCP 서버에 둘 수 있다.
   2. 외부 시스템 연결: 데이터와 업무 시스템에 대한 접근을 원격 서비스로 분리할 수 있다.

5. 두 표준이 만나는 지점

   1. ACP의 원격 전송: ACP가 클라이언트와 하네스 사이의 원격 연결을 맡는다.
   2. MCP의 원격 전송: MCP가 하네스와 외부 도구 사이의 원격 도구 호출을 맡는다.
   3. 재배치 효과: ACP와 MCP가 모두 원격 전송을 지원하면 네 구성요소를 한 덩어리로 묶지 않고 필요에 따라 배치할 수 있다.

6. 원격 ACP 데모와 구현 진입장벽

6.1. 하룻밤 사이 만든 클라이언트

1. 간단한 클라이언트 제작

   1. 제작 방식: Alex Hancock은 클라이언트 구현이 얼마나 쉬운지 보여주려고 전날 밤 바이브 코딩(vibe coding)으로 간단한 클라이언트를 만들었다.
   2. 요청: 클라이언트에 “시를 써줘(Write a poem)”라고 입력한다.

2. 네트워크를 통한 Goose 연결

   1. 연결 대상: 클라이언트는 앞선 데모에서 사용한 같은 Goose 프로세스에 연결한다.
   2. 전송 경로: 이번에는 네트워크를 통해 메시지를 주고받는다.
   3. 실행 위치: 데모에서 Goose 프로세스는 같은 머신에 있지만, 동일한 구조를 컨테이너나 클라우드에 그대로 옮길 수 있다.

3. 로컬·원격 전환

   1. 메시지 동일성: 로컬이든 원격이든 ACP 메시지는 동일하다.
   2. 라이브러리 동일성: 클라이언트가 사용하는 라이브러리도 동일하다.
   3. 전환 비용: 배치 설정만 바꿔 로컬 연결과 원격 연결 사이를 매우 쉽게 전환할 수 있다.

6.2. 참여 방법

1. 클라이언트 만들기

   1. 개인 구현: ACP를 지원하는 개인용 클라이언트를 직접 만들 수 있다.
   2. 제품 구현: 편집기, 데스크톱 앱, 모바일 앱, 터미널 도구에 ACP 클라이언트 기능을 넣을 수 있다.

2. 하네스에 ACP 추가하기

   1. 서버 측 참여: 기존 에이전트 하네스에 ACP 인터페이스를 추가할 수 있다.
   2. 확장 실험: 사용자 정의 메서드를 사용해 하네스 고유의 기능을 실험하고, 반복되는 패턴을 표준화 과정에 제안할 수 있다.

3. 시작점

   1. 공식 사이트: Agent Client Protocol 사이트가 구현을 시작하는 방법을 제공한다.
   2. 기존 구현 활용: 이미 여러 클라이언트와 에이전트 서버가 존재하므로 처음부터 모든 요소를 만들 필요는 없다.

7. ACP 생태계의 확장 가능성

7.1. 현재 참여 범위

1. 다양한 클라이언트 형태

   1. 편집기: Zed와 JetBrains 제품처럼 코드 편집 환경에 통합할 수 있다.
   2. 데스크톱 애플리케이션: 일반 데스크톱 앱이 하네스를 제어하는 클라이언트가 될 수 있다.
   3. 모바일 애플리케이션: 모바일 기기에서 원격 하네스를 호출하는 클라이언트를 만들 수 있다.
   4. 터미널 도구: Poolside AI 사례처럼 터미널 기반 클라이언트도 같은 하네스를 사용할 수 있다.

2. 확산의 의미

   1. 구현 증가: 편집기부터 모바일과 터미널까지 클라이언트가 늘어나면 생태계의 구현 수가 빠르게 증가한다.
   2. 상호운용성: 클라이언트와 하네스가 특정 제품 조합에 묶이지 않고 서로 교체 가능해진다.

7.2. 개인·도메인·기업별 클라이언트

1. 개인용 오케스트레이션

   1. 개인 클라이언트: 사용자가 자신의 취향과 작업 흐름에 맞는 클라이언트를 직접 만들 수 있다.
   2. 에이전트 조정: 하나의 클라이언트에서 여러 에이전트를 원하는 방식으로 오케스트레이션(orchestration)할 수 있다.

2. 업무 도메인 전용 클라이언트

   1. 전문 분야: 특정 비즈니스 도메인에 맞춘 클라이언트를 만들 수 있다.
   2. 기업 내부 사용: 개별 회사가 자체 업무 프로세스에 맞춘 클라이언트 집합을 만들 수 있다.

3. 화이트 라벨(white-label) 클라이언트

   1. 브랜드 맞춤화: 회사가 자체 브랜드와 업무 경험을 반영한 화이트 라벨 클라이언트를 구성할 수 있다.
   2. 하네스 범용성: 특정 회사 브랜드의 클라이언트가 여러 하네스와 연동될 수 있다.

7.3. 클라이언트 시장이 만드는 사용자 경험 경쟁

1. 새로운 제품 범주

   1. 시장 형성: ACP가 새로운 클라이언트 카테고리를 만들면 여러 제품이 같은 하네스에 경쟁적으로 연결된다.
   2. 선택의 기준: 기능 호환성뿐 아니라 사용성, 흐름, 응답 표시, 권한 처리 같은 경험이 경쟁 기준이 된다.

2. 사용자의 발로 하는 투표

   1. 선택권: 여러 클라이언트가 있으면 사용자는 자신의 필요를 충족하지 못하는 제품을 떠날 수 있다.
   2. 품질 압력: 클라이언트 제작자는 사용자가 떠나지 않도록 사용자 경험의 품질을 높여야 한다.
   3. AI 경험의 개선: 이러한 경쟁이 전반적인 AI 사용 경험을 끌어올릴 수 있다.

주요 발언 모음

“MCP의 가장 강력한 점은 MCP 자체의 어떤 기능이 아니라, 모두가 MCP를 사용한다는 사실이다.”

“에이전트가 무엇을 할지 알려주고, 어떤 작업을 진행할지 지정하고, 업데이트를 받는 클라이언트 소프트웨어를 위한 좋은 표준은 아직 없다.”

“ACP는 편집기만을 위한 것이 아니다. 편집기 특화 기능이 많지 않기 때문에 더 넓은 범위의 클라이언트 소프트웨어로 확장될 수 있다.”

“메시지는 같고 사용하는 라이브러리도 같으므로 로컬과 원격 사이를 아주 쉽게 전환할 수 있다.”

“생태계나 마켓플레이스가 형성되고 선택지가 많아지면, 사용자는 필요를 충족하지 못하는 클라이언트에 발로 투표할 수 있다.”

핵심 데이터 & 수치

• 수천~수만 개: MCP가 널리 채택된 결과 전 세계에 수천 개 또는 수만 개의 MCP 서버가 존재한다고 언급된다.
• 네 가지 구성요소: 에이전트 스택은 클라이언트, 하네스, 도구, 모델로 나뉜다.
• 두 가지 원격 전송 방식: ACP에는 HTTP 전송과 WebSocket 업그레이드가 제시된다.
• 두 클라이언트 데모: Zed와 Poolside AI 터미널 클라이언트가 하나의 Goose 하네스를 각각 제어한다.
• 하룻밤의 프로토타입: 간단한 ACP 클라이언트가 전날 밤 바이브 코딩으로 제작돼 원격 연결 데모에 사용된다.
• 약 10분 33초: 전체 발화 구간은 00:00부터 약 00:10:33까지 이어진다.

결론 및 시사점

1. 클라이언트와 하네스를 분리하라

   1. 클라이언트는 사용자 경험과 작업 입력을 담당하고, 하네스는 도구 호출 루프와 에이전트 실행을 담당하게 설계한다.
   2. ACP를 사용하면 두 계층이 특정 제품에 종속되지 않고 교체 가능해진다.

2. MCP와 ACP를 서로 다른 방향의 표준으로 이해하라

   1. MCP는 에이전트가 외부 도구와 데이터로 나가는 연결을 표준화한다.
   2. ACP는 클라이언트가 에이전트 하네스에 작업을 보내고 결과·상태·권한 흐름을 받는 연결을 표준화한다.

3. 로컬에서 시작하되 원격 전송을 고려하라

   1. standard I/O 기반 로컬 연결로 기능을 검증할 수 있다.
   2. HTTP와 WebSocket 전송을 지원하면 같은 의미와 라이브러리로 컨테이너·서버·클라우드로 확장할 수 있다.

4. 사용자 정의 확장을 실험하라

   1. 밑줄로 시작하는 사용자 정의 메서드를 통해 하네스와 클라이언트의 고유 요구를 먼저 구현한다.
   2. 여러 구현에서 반복되는 패턴을 표준으로 승격하는 방식으로 커뮤니티와 함께 ACP를 발전시킨다.

5. 클라이언트 생태계의 경쟁을 활용하라

   1. 개인·도메인·기업용 클라이언트를 만들면 사용자가 에이전트를 조정하는 방식이 다양해진다.
   2. 제품 선택지가 늘어날수록 클라이언트는 사용자 경험의 품질로 경쟁하게 되고, 이는 AI의 실제 사용성을 높인다.

6. 지금 할 수 있는 일

   1. Agent Client Protocol의 공식 사이트에서 기존 클라이언트와 에이전트 서버를 확인한다.
   2. 새 클라이언트를 만들거나 기존 하네스에 ACP 지원을 추가해 상호운용성 실험에 참여한다.

핵심 요약 (20줄)

• ACP(Agent Client Protocol)는 클라이언트가 에이전트 하네스에 작업을 보내고 결과를 받기 위한 개방형 표준이다.
• Alex Hancock은 Block에서 Cash App·Square·Tidal 관련 소프트웨어를 개발했고 오픈소스 AI에 집중해 왔다.
• Goose는 Block 내부 프로젝트로 시작해 오픈소스로 공개된 뒤 Linux Foundation에 기증된 에이전트 하네스다.
• Alex Hancock은 MCP 유지보수자이자 MCP Rust SDK 기여자이며 ACP 개발에도 참여한다.
• 현재 많은 에이전트 하네스가 맞춤형 인터페이스를 사용해 특정 클라이언트에 종속된다.
• 하네스마다 전용 클라이언트가 필요한 구조는 웹사이트마다 전용 브라우저가 필요한 상황과 비슷하다.
• 표준은 여러 구현이 참여하는 생태계와 시장을 만들고 사용자에게 클라이언트 선택권을 준다.
• MCP는 에이전트의 도구 호출·외부 시스템 행동·리소스 읽기를 공통 방식으로 연결한다.
• MCP의 가장 큰 힘은 개별 기능보다 수천 개 또는 수만 개의 서버가 같은 표준을 사용한다는 사실에 있다.
• ACP는 클라이언트가 에이전트에 작업과 지시를 보내고 진행 상태를 받는 표준의 공백을 겨냥한다.
• Zed와 JetBrains는 편집기 안에서 하나의 클라이언트로 여러 에이전트 하네스를 제어하려고 ACP를 제안했다.
• ACP는 편집기 특화 기능이 적어 데스크톱·모바일·터미널·헤드리스 클라이언트로 확장될 수 있다.
• ACP 연결은 기능 집합을 표현하고 그 위에 세션을 만들어 사용자 메시지와 에이전트 응답을 교환한다.
• 에이전트는 ACP를 통해 텍스트·이미지·오디오와 진행 업데이트·도구 호출 알림을 보낼 수 있다.
• 클라이언트는 ACP 권한 요청으로 사용자에게 도구 호출을 승인할지 물을 수 있다.
• ACP는 JSON-RPC 메시지를 사용하고 밑줄로 시작하는 사용자 정의 메서드 확장을 허용한다.
• Zed와 Poolside AI 터미널 클라이언트는 같은 Goose 하네스에서 텍스트·도구 호출·요약을 재현했다.
• HTTP와 WebSocket 전송은 ACP 메시지와 의미를 유지하면서 클라이언트와 하네스를 원격으로 분리한다.
• 클라이언트·하네스·도구·모델을 독립적으로 배치하면 로컬·컨테이너·클라우드 조합을 자유롭게 선택할 수 있다.
• ACP 생태계의 다수 클라이언트 경쟁은 사용자의 선택과 사용자 경험의 품질을 함께 끌어올릴 수 있다.