Block 엔지니어가 밀어붙이는 ACP, 에이전트를 부리는 표준이 되나

Alex Hancock introduces himself as a software engineer at Block and as an MCP client maintainer. He points to the previous speaker's claim that MCP client maintainers are smart for not implementing support for tasks.

Hancock attributes the lack of task support in MCP clients to himself: 'it's just because I'm lazy.'

그는 Square와 Cash App 제품에서 일했고 지난 몇 년간 오픈소스 AI 쪽 작업을 해 왔다.

그가 작업하는 오픈소스 하네스 프로젝트 Goose는 Block 내부 프로젝트로 시작해 오픈소스로 공개되고 리눅스 재단에 기부됐다. 지적재산권은 재단에 있지만 Block 직원들이 여전히 작업하고 있다. 그는 모델 컨텍스트 프로토콜(MCP)의 유지관리자로 Rust SDK를 맡고 있고, 최근에는 이 발표의 주제인 에이전트 클라이언트 프로토콜(ACP) 작업을 시작했다.

실험실에서 나온 것, 각 회사에서 만든 것, 오픈 표준 기반의 것까지 다양한 하네스가 나와 있지만, 그 하네스로 가는 인터페이스는 대개 맞춤형이거나 일회성이라고 핸콕은 짚었다. 최악의 경우에는 그 하네스를 조종할 수 있는 클라이언트 애플리케이션이 문자 그대로 하나뿐인 경우도 있다.

그는 웹에 빗대어, 모든 웹사이트에 접속할 때 브라우저 하나나 특정 프로토콜 하나만 써야 하는 상황과 같다고 설명했다. 그런 개방성이 없었다면 열린 웹도 없었을 것이라는 게 그의 판단이다.

표준이 생태계와 시장을 만든다는 것이 그의 전제다. 에이전트 AI에는 에이전트가 밖으로 나가 도구를 호출하고 다른 시스템에서 행동을 취하고 자원과 데이터를 읽는 쪽의 좋은 표준이 이미 있다.

그는 MCP의 가장 강력한 점이 MCP 자체의 무엇이 아니라 모두가 MCP를 쓴다는 사실이라고 말했다. 그 결과 전 세계에 수천에서 수만 개의 서버가 있고 모든 에이전트가 여기에 접속할 수 있다. 반대로 클라이언트 소프트웨어가 에이전트에게 무엇을 하라고 지시하고, 작업을 주고, 무엇을 다룰지 말하고, 업데이트를 받는 쪽에는 아직 좋은 해법이나 표준이 없다고 그는 본다.

ACP는 에이전트 클라이언트 프로토콜의 약자로 에디터 회사들에서 나왔다. Zed 에디터와 JetBrains 쪽이 힘을 합쳐 클라이언트가 하네스를 제어할 수 있는 표준을 제안했고, 핸콕의 팀은 이것이 오픈 표준 영역에서 진행되는 작업이라고 소개했다.

에디터 회사들의 동기는 품질 높은 클라이언트 구현을 Zed나 IntelliJ에 한 번만 작성해서 어떤 하네스든 그것으로 제어하자는 것이었다. 그 클라이언트 하나가 작업을 보내고 결과를 받고 어떤 파일이 편집되는지 볼 수 있게 된다. Goose 팀은 ACP가 에디터 특화 기능이 적어 비교적 중립적이라고 판단했고, 그래서 에디터보다 더 넓은 클라이언트 소프트웨어로 퍼질 수 있다고 봤다.

ACP는 클라이언트와 에이전트 하네스 사이에 연결을 맺고, 그 연결에 특정 능력 집합을 붙인다. 연결 안에서는 세션이 만들어지고, 세션 안에서 클라이언트가 사용자 메시지, 즉 사용자가 타이핑한 것이나 클라이언트 소프트웨어가 보내려는 것을 전달한다.

에이전트는 텍스트나 이미지·오디오로 응답하거나 무슨 일이 벌어지는지에 대한 업데이트를 보낸다. 도구가 호출되면 도구 이름과 메타데이터가 담긴 도구 호출 알림을 보낼 수 있다. 클라이언트가 사용자에게 이 도구 호출을 할지 예/아니오로 물을 수 있도록 권한 요청을 보내는 것도 가능하다.

전송은 JSON-RPC 메시지를 쓴다는 점이 기본이고, 핸콕이 가장 마음에 들어 하는 부분은 확장성이다. 바닐라 프로토콜에 그치지 않고 관례상 밑줄로 시작하는 사용자 정의 메서드를 추가할 수 있다.

핸콕은 충분한 하네스나 클라이언트 프로젝트가 ACP를 채택하면 같은 사용자 정의 메서드가 여러 팀에서 나타나게 될 것이라고 본다. 그가 예로 든 것은 Codex 팀, Goose 팀, 그리고 클라이언트 팀 각자가 추가할 수 있는 사용자 정의 메서드다.

목표는 생태계에서 무엇이 떠오르는지, 무엇이 표준 트랙에 올라가 프로토콜 자체로 들어올 만한지 지켜보는 것이다. 프로토콜이 사용과 커뮤니티에 의해 빚어지게 하겠다는 구상이다.

데모는 HTML 파일 하나로 이뤄진 프로젝트를 Zed에서 열고 'Tell me about this project'를 프롬프트로 넣는 방식으로 진행됐다. 인터페이스 뒤에 있는 에이전트는 Goose이며 자신의 ACP 인터페이스를 통해 붙는다.

클라이언트는 무엇을 읽었고 무엇을 했는지에 대한 텍스트와 도구 호출 정보를 스트리밍으로 돌려줬다. 두 번째 클라이언트는 Poolside AI라는 회사의 터미널 기반 클라이언트였다. 같은 프로젝트, 같은 프롬프트, 같은 에이전트 동작으로 텍스트 결과와 도구 호출, 스트리밍 요약이 이어졌다. 하네스 쪽 구현은 하나이고 어떤 클라이언트든 쓸 수 있다는 것이 보여주려는 지점이었고, 이번 데모는 로컬에서 표준 입출력으로 이뤄졌다.

핸콕의 주장은 로컬로는 충분하지 않고 에이전트는 클라우드에서 돌아가게 될 것이라는 것이다. Goose 팀이 이 프로젝트에 왔을 당시 원격 지원이 없어서 HTTP 전송을 명세했다.

HTTP 버전과 웹소켓 업그레이드 두 가지로 이뤄진다. 메시지는 그대로이고 프로토콜 의미도 그대로이며 원격을 가능하게 하는 새 전송이 막 들어오는 중이라고 그는 설명한다.

Goose 팀은 에이전트 스택을 네 구성 요소로 본다. 사용자 대상 앱이나 기기에 있는 헤드리스 앱인 클라이언트, 도구 호출 루프를 구현한 프로그램인 하네스, 흔히 MCP인 도구, 그리고 모델이다.

ACP의 원격 전송이 클라이언트에서 하네스로 가는 구간을 덮고, MCP에는 도구 호출을 위한 원격 전송이 있으며, 모델은 오래전부터 responses API 같은 원격 엔드포인트를 갖고 있었다. 이 셋이 갖춰지면 네 조각을 자유롭게 배치할 수 있다. 같은 기계에 두거나, 클라이언트와 다른 기계에 하네스를 두거나, 모델만 원격으로 두거나, 도구만 원격으로 둘 수 있다.

표준에 합의하고 좋은 전송 체계를 확보하는 것이 에이전트 스택의 조각들을 옮겨 다닐 수 있게 해 줄 것이라는 게 핸콕의 설명이다.

핸콕은 클라이언트를 만드는 일이 얼마나 쉬운지 보여주려고 전날 밤에 직접 클라이언트를 라이브 코딩했다. 프롬프트는 'Write a poem'이었고, 이 클라이언트는 표준 입출력이 아니라 네트워크를 통해 그의 기계에 있는 같은 프로세스에 접속했다.

원격 에이전트는 컨테이너 안에 있을 수도 있고 클라우드에 올라가 있을 수도 있다. 메시지는 로컬의 경우와 같고 사용하는 라이브러리도 같아서 로컬과 원격을 매우 쉽게 오갈 수 있다고 그는 말했다.

시작 방법은 에이전트 클라이언트 프로토콜 사이트에서 안내한다.

이미 나와 있는 클라이언트와 에이전트 서버가 적지 않다고 그는 덧붙였다. 그가 든 범주는 에디터, 데스크톱 애플리케이션, 모바일 애플리케이션, 터미널 기반 도구이며, 그는 이를 하나의 확산이라고 표현했다.

상호운용이 실현되면 쓸 수 있는 사례가 매우 클 것이라고 핸콕은 본다. 사람들이 자기 에이전트를 원하는 방식 그대로 조율하는 개인용 클라이언트, 특정 업무 영역을 위한 클라이언트, 개별 회사를 위한 클라이언트나 한 회사가 내놓는 클라이언트 묶음 같은 것들이다.

모든 하네스와 함께 동작하는 맞춤형 화이트라벨 클라이언트도 그가 든 예다. 그의 인과적 주장은 생태계나 시장이 형성돼 선택지가 많아지면 클라이언트가 요구를 못 맞출 때 사용자가 발로 투표할 수 있다는 것이다. 그러면 사람들이 사용자 경험의 품질로 경쟁하게 되고, 전체적으로 AI 사용 경험이 끌어올려질 것이라는 전망이다.