ACP가 뭔지 물었더니, 같은 약자의 프로토콜이 두 개였다

AI 에이전트 이야기를 읽다 보면 MCP 옆에 ACP라는 약자가 같이 나오는 일이 점점 많아졌다. MCP는 직접 리뷰도 여러 번 해봤으니 대충 감이 있는데, ACP는 이름만 알고 무슨 일을 하는지는 몰랐다. 그래서 Claude에게 먼저 물어봤고, 그 답을 들고 공식 문서를 하나씩 열어봤다. 첫 답은 대체로 맞았지만, 그사이 이미 바뀐 것들이 있었다.

같은 약자, 다른 프로토콜 두 개 — Agent Client Protocol과 Agent Communication Protocol

첫 답부터 갈래가 둘이었다. “ACP”라는 약자를 쓰는 프로토콜이 실제로 두 개 있다.

하나는 Agent Client Protocol이다. 코드 편집기와 AI 코딩 에이전트 사이의 대화 방식을 정한 표준이고, 편집기 Zed를 만드는 팀이 처음 공개했다. 다른 하나는 IBM 연구소의 BeeAI 프로젝트가 2025년 3월에 내놓은 Agent Communication Protocol이다. 이쪽은 에이전트와 에이전트가 서로 일을 주고받는 방식을 정한 표준이었다.

여기에 헷갈리기 쉬운 이름이 하나 더 있다. 구글이 2025년 4월에 발표한 A2A다. A2A는 ACP의 다른 이름이 아니라 Agent2Agent Protocol의 약자로, 따로 만들어진 프로토콜이다. 다만 IBM의 Agent Communication Protocol과는 목표가 같았다. 둘 다 “에이전트끼리 어떻게 통신하고 협업할 것인가”를 각자 다른 방식으로 풀던 표준이었다.

그러니 같은 “ACP”라도 IBM의 것은 A2A와 같은 문제를 풀다가 A2A로 합쳐졌고, Zed의 것은 처음부터 A2A와 상관없는 다른 문제를 푼다. MCP와 나란히 이야기될 때의 ACP는 대부분 Zed의 Agent Client Protocol이다.

Agent Client Protocol은 편집기와 에이전트 사이의 LSP다

Agent Client Protocol 공식 문서는 스스로를 LSP(Language Server Protocol)에 비유한다. LSP가 나오기 전에는 편집기마다 언어별 자동완성·오류 표시를 따로 만들어야 했다. LSP가 그 둘 사이의 대화 방식을 표준으로 정하자, 언어 서버 하나를 만들면 어느 편집기에서든 쓸 수 있게 됐다.

AI 코딩 에이전트도 같은 문제를 겪고 있었다. Claude Code, Gemini CLI, Codex 같은 에이전트를 VS Code, JetBrains, Zed 같은 편집기에 붙이려면 에이전트와 편집기 조합마다 통합을 따로 만들어야 했다. 에이전트가 다섯 개, 편집기가 다섯 개면 통합은 스물다섯 개가 필요한 구조다. ACP는 그 사이의 대화 방식을 하나로 정해서, ACP를 지원하는 에이전트라면 ACP를 지원하는 어느 편집기에서든 돌아가게 만든다.

동작 방식은 단순하다. 편집기가 에이전트를 자식 프로세스로 띄우고, 표준 입출력으로 JSON-RPC 메시지를 주고받는다. 편집기는 사용자의 메시지와 열린 파일 같은 맥락을 보내고, 에이전트는 답변, 파일 수정 내용(diff), 터미널 명령 실행 요청, “이 파일을 고쳐도 되는가” 같은 권한 확인 요청을 돌려보낸다. 편집기는 그걸 자기 화면 방식대로 보여준다. 메시지 형식은 MCP에서 이미 쓰는 JSON 표현을 가능한 한 그대로 가져다 쓰고, 코드 수정처럼 편집기에만 필요한 것만 새 타입으로 정의했다. 원격에 있는 에이전트를 HTTP나 WebSocket으로 붙이는 방식은 공식 문서상 아직 작업 중이다.

시작은 2025년 8월 27일이었다. Zed가 자기 편집기에 외부 에이전트를 붙일 수 있게 하면서 이 프로토콜을 공개했고, 첫 연동 대상은 구글의 Gemini CLI였다.

MCP, ACP, A2A는 서로 경쟁하는 게 아니라 층이 다르다

처음에는 “MCP가 있는데 또 프로토콜이 필요한가” 싶었다. 정리해보니 셋은 연결하는 대상 자체가 달랐다.

그래서 한 번에 셋이 다 쓰일 수도 있다. Zed에서 ACP로 코딩 에이전트를 띄우면, 그 에이전트는 MCP로 GitHub이나 메모리 서버 같은 도구를 붙여 쓰고, 필요하면 A2A로 다른 에이전트에게 일을 넘기는 식이다. MCP가 에이전트의 “아래쪽”을 표준화했다면, ACP는 “위쪽”, 즉 사람이 에이전트를 만나는 화면 쪽을 표준화한 셈이다.

첫 답은 학습 시점 기준이었다 — ACP 에이전트 레지스트리와 IBM ACP의 A2A 합류

Claude의 첫 설명은 여기까지는 맞았다. 다만 스스로도 “학습 시점까지의 정보라 그 뒤에 바뀌었을 수 있다”고 덧붙였고, 실제로 공식 문서를 열어보니 몇 가지가 이미 달라져 있었다.

IBM의 ACP는 “합쳐지는 중”이 아니라 이미 합쳐졌다. 첫 답은 “A2A와 합쳐지는 방향으로 정리됐다”였는데, LF AI & Data 공지를 보면 2025년 8월 29일에 리눅스 재단 산하에서 A2A로 합류하는 것이 이미 확정됐다. 공지에 따르면 IBM 팀은 한 달 뒤 A2A가 나왔을 때 “에이전트끼리 통신하게 한다는 과제를 두 팀이 같은 방향으로 풀고 있다”는 걸 곧바로 알아봤고, “AI 에이전트가 소통하고 협업하는 방식에 대한 하나의 더 강력한 표준을 만들기 위해” 합치기로 했다. 설계는 달랐다. IBM 쪽은 별도 SDK 없이 일반 HTTP 요청(REST)만으로 쓸 수 있는 단순함을 내세웠고, A2A는 JSON-RPC 메시지와 에이전트 소개 문서(Agent Card)를 중심에 뒀다. 그래도 목표가 겹치는 표준 두 개를 따로 키울 이유는 없었던 셈이다. IBM 쪽 개발은 정리 단계에 들어갔고, ACP를 이끌던 IBM의 Kate Blair는 A2A 기술 운영위원회에 합류했다. 지금 “ACP”라고 하면 사실상 Agent Client Protocol만 남은 이유다.

에이전트를 찾아 설치하는 레지스트리가 생겼다. 2026년 1월, JetBrains와 Zed가 함께 ACP 에이전트 레지스트리를 열었다. 편집기 안에서 목록을 보고 설치 버튼만 누르면 에이전트가 붙는다. JetBrains 도움말에 따르면 레지스트리에 없는 에이전트도 설정 파일로 직접 추가할 수 있고, JetBrains AI 구독 없이도 쓸 수 있다. 다만 WSL 환경에서는 지원하지 않는다.

지원 범위가 꽤 넓어졌다. 공식 목록 기준으로 ACP를 지원하는 에이전트는 41개, 클라이언트(편집기와 앱)는 100개 가까이 된다. Gemini CLI, GitHub Copilot(공개 프리뷰), Cursor, Cline, OpenCode 같은 에이전트는 ACP를 직접 지원하고, Claude 에이전트와 OpenAI Codex CLI는 어댑터를 거쳐 붙는다. 편집기 쪽은 Zed와 JetBrains가 직접 지원하고, VS Code는 기본 기능이 아니라 확장 프로그램을 통해 붙는다. Neovim, Emacs, Sublime Text 같은 편집기와 모바일 앱까지 목록에 있다.

ACP v2 초안에서 바뀌는 것 — 대화 턴에서 벗어난다

2026년 7월 20일에는 ACP v2 초안이 나왔다. 굵직한 변화는 이렇다.

• 사용자가 말을 걸 때만 움직이는 구조에서 벗어난다. v1은 사용자 메시지 한 번에 에이전트 응답 한 번이 오가는 대화 턴 중심이었다. v2에서는 에이전트가 백그라운드에서 일하면서 언제든 진행 상황을 보낼 수 있다.
• 파일 수정 표현이 구조화된다. “바꾸기 전 텍스트와 바꾼 뒤 텍스트”를 보내던 방식에서, 추가·삭제·수정·이동·복사를 구분하고 바이너리 파일까지 다루는 형식으로 바뀐다.
• 권한 요청에 제목과 설명이 필수가 된다. 편집기가 “이 에이전트가 무엇을 하려고 하는지”를 사용자에게 더 분명히 보여줄 수 있게 하려는 변화다.

v1을 버리는 건 아니다. 공지는 “v1만 지원하는 쪽이 한동안 흔할 것”이라며, 구현하는 쪽은 두 버전을 함께 지원하라고 권한다.

A2A는 지금 어디까지 왔나 — 사양 1.0과 150개 넘는 조직

IBM의 ACP를 흡수한 A2A도 그사이 많이 진행됐다. 리눅스 재단이 A2A 발표 1주년인 2026년 4월 9일에 낸 발표문 기준으로 정리하면 이렇다.

• 첫 안정판 사양 1.0이 나왔다. 에이전트 소개 문서(Agent Card)에 서명을 붙여 진짜인지 확인할 수 있는 기능 등이 들어갔다.
• 지원하는 조직이 150곳을 넘었다. 깃허브 저장소의 스타는 2만 2천 개를 넘었다.
• 주요 클라우드에 들어갔다. 마이크로소프트의 Azure AI Foundry와 Copilot Studio, AWS의 Amazon Bedrock AgentCore Runtime이 지원하고, 실제 기업 서비스에서도 쓰이기 시작했다.
• 공식 SDK가 다섯 언어로 나와 있다. Python, JavaScript, Java, Go, .NET이다.
• 다음 과제로는 상호운용성 사양, 레지스트리 통합, 테스트·도구 확대, 보안과 배포 모범 사례를 꼽았다. 결제 쪽으로는 A2A를 확장한 AP2(Agent Payments Protocol)가 따로 나와 60곳 넘는 조직이 지원하고 있다.

공식 사양 1.0 기준으로 A2A의 구조를 짧게 보면, 각 에이전트는 자기가 할 수 있는 일과 접속 방법을 적은 Agent Card를 공개하고, 다른 에이전트는 그걸 보고 일을 “작업(task)” 단위로 맡긴다. 작업은 접수, 진행 중, 완료·실패·취소 같은 상태를 거친다. 메시지를 주고받는 방식은 JSON-RPC, gRPC, REST 중에서 고를 수 있다. IBM 쪽이 내세웠던 REST 방식도 이제 A2A가 지원하는 방식 중 하나로 들어가 있는 셈이다.

내가 쓰는 도구도 이미 목록에 있었다 — Hermes Agent와 Obsidian ACP 플러그인

목록을 훑다가 아는 이름 두 개를 발견했다.

하나는 내가 상주형 에이전트로 쓰고 있는 Hermes Agent다. hermes acp 명령 하나로 ACP 서버 모드로 뜨고, VS Code(ACP 클라이언트 확장), Zed, JetBrains에서 붙일 수 있다. 문서에 따르면 이렇게 붙여도 Hermes가 원래 갖고 있던 설정, 메모리, 스킬, 도구는 그대로 쓰고, 대화를 주고받는 창구만 편집기로 바뀐다. 파일 수정이나 명령 실행 같은 승인 요청에는 “이번 세션 동안만 허용” 단계가 따로 있고, 승인 대기는 기본 300초 뒤에 끝난다. 그동안 Hermes는 텔레그램이나 대시보드로만 써왔는데, 편집기 안에서 같은 에이전트를 부를 수 있는 길이 이미 열려 있었던 셈이다.

다른 하나는 Obsidian이다. 클라이언트 목록에 Obsidian용 플러그인이 네 개 있었다(Agent Client, Agent Console, Copilot for Obsidian, Obsidian Harness). Obsidian 안에서 외부 에이전트를 ACP로 불러 쓰는 플러그인들이다. Obsidian 플러그인을 직접 만들고 있는 입장에서는, “에이전트를 Obsidian 안에 직접 구현”하는 방식과 “이미 있는 에이전트를 ACP로 꽂아 쓰는” 방식이 나란히 놓인 셈이라 따로 들여다볼 만하다.

남는 생각

ACP 자체보다 더 기억에 남는 건 확인 과정이었다. AI의 첫 설명은 구조를 잡기에는 충분했다. 두 프로토콜을 구분하고, MCP와 층이 다르다는 걸 짚은 부분은 문서와 그대로 맞았다. 그런데 “합쳐지는 방향”이라고 말한 일은 이미 1년도 더 전에 끝나 있었고, v2 초안과 레지스트리, 그리고 내가 쓰는 Hermes가 지원한다는 사실은 아예 몰랐다. 표준이 빠르게 움직이는 분야일수록 AI의 설명은 지도로만 쓰고, 날짜가 붙은 사실은 공식 문서에서 직접 확인해야 했다.