Agent Client Protocol 추천: 에디터와 AI 에이전트를 연결하는 새 표준 후보
MCP 다음에 볼 만한 editor-agent 연결 계층과 첫 테스트 방법
Agent Client Protocol 추천: 왜 지금 확인해야 하나
Agent Client Protocol은 에디터와 AI 코딩 에이전트를 분리해 연결하려는 프로토콜입니다. 2026년 6월 1일 기준 공식 GitHub 저장소와 registry 문서 업데이트가 이어지고 있어, Claude Code, Codex, Copilot, Gemini CLI를 비교하는 한국 개발자에게 실험해볼 만한 주제입니다.
Claude Code, Codex, Copilot, Gemini CLI를 번갈아 쓰다 보면 비슷한 불편이 생깁니다. 에이전트는 늘어나는데 에디터 UI와 런타임이 단단히 묶이면 비교도, 교체도 번거롭습니다.
`agentclientprotocol/agent-client-protocol`은 이 지점을 다루는 저장소입니다. 검색 키워드로 풀면 agentclientprotocol agent-client-protocol AI editor agent protocol에 가깝고, 요지는 에디터와 코딩 에이전트 사이의 통신 규칙을 맞추자는 데 있습니다.
제가 보기에는 ACP를 지금 확인할 이유가 "이미 표준이 됐다"는 데 있지 않습니다. 아직은 표준 후보로 보는 편이 정확합니다. 다만 2026년 6월 1일 확인 기준 GitHub stars 3,265개, forks 267개, pushed_at 2026-06-01T05:19:35Z이고 registry 문서도 계속 갱신되고 있습니다. 한국 사용자 입장에서는 특정 IDE 홍보 문구보다 "에디터와 agent를 분리하면 실제로 무엇을 점검해야 하나"가 더 중요한 질문입니다.
그래서 ACP와 MCP의 경계, 가장 작은 첫 테스트 경로, 팀 도입 전에 봐야 할 권한과 인증 항목을 같은 흐름으로 묶었습니다.
오늘 확인한 신호: stars보다 registry 업데이트를 봅니다
이번 추천의 근거는 단순한 star 숫자가 아니라 registry agents 문서와 ACP Registry가 계속 갱신된다는 점입니다. stars와 pushed_at은 채택 확정이 아니라 관심도와 유지보수 신호로만 읽어야 합니다.
이 저장소를 볼 때 star 숫자만 붙잡으면 판단이 얕아집니다. 관심도는 참고가 되지만, 개발자 도구는 문서와 registry가 계속 움직이는지가 더 직접적인 신호입니다.
2026년 5월 27일에는 v0.13.4 릴리스가 공개됐고, 2026년 5월 29일에는 `docs/get-started/registry.mdx`를 수정하는 registry agents 문서 업데이트 커밋이 확인됩니다. 2026년 6월 1일 기준 최신 main 커밋도 `docs: update registry agents (#1323)`입니다.
ACP Registry도 함께 봐야 합니다. 공식 registry 문서는 ACP-compatible agents를 찾고 설치하는 경로를 설명하고, registry JSON은 `<링크> 확인합니다. 리서치 기준 2026년 6월 1일 CDN JSON에는 36개 agent metadata가 노출되어 있었습니다.
> 제가 보기에는 ACP의 뉴스 가치는 "완성된 표준"이 아니라 "에디터와 agent를 분리하려는 흐름이 문서와 registry 단위로 계속 움직인다"는 점입니다.
ACP 타임라인: 갑자기 나온 유행어인지 확인하기
ACP는 2025년 저장소 생성 이후 release, protocol docs, registry 갱신이 이어진 프로젝트입니다. 다만 이 타임라인은 성숙도 판단의 출발점이지 업계 표준 확정 증거는 아닙니다.
날짜를 놓고 보면 이 프로젝트가 갑자기 붙은 이름인지, 아니면 꾸준히 다듬어지는 연결 규약인지 구분하기 쉽습니다.
| 날짜 | 확인 내용 | 의미 |
|---|---|---|
| 2025-06-23 | `agentclientprotocol/agent-client-protocol` 저장소 생성 | 프로젝트의 공개 출발점 |
| 2026-05-27 | v0.13.4 release 공개 | protocol과 SDK 변화가 릴리스 단위로 정리됨 |
| 2026-05-29 | registry agents 문서 업데이트 커밋 확인 | 지원 agent 목록과 문서 갱신 흐름 확인 |
| 2026-06-01 | GitHub API 기준 pushed_at 2026-06-01T05:19:35Z | 최근 활동 신호 확인 |
| 2026-06-01 | ACP Registry pushed_at 2026-06-01T03:37:11Z | registry 생태계도 함께 움직임 |
여기서 볼 부분은 "날짜가 있는 사실"입니다. AI 개발 도구 글은 star 숫자 하나로 쉽게 부풀려지기 때문에, `agentclientprotocol agent-client-protocol AI editor agent protocol`을 추천할 때도 release, commit, registry 같은 확인 가능한 신호와 해석을 분리해야 합니다.
실제로는 네 가지만 보면 됩니다. 저장소가 최근에 움직였는지, 호환 agent가 문서화되어 있는지, 릴리스 노트가 남는지, 실제 client에서 실행 경로가 있는지입니다. ACP는 이 네 조건에서 실험 후보로 볼 만합니다.
ACP와 MCP 차이: tool 연결이 아니라 editor-agent 연결
MCP가 AI 앱과 외부 도구, 데이터 소스, 워크플로를 연결하는 표준이라면 ACP는 에디터 또는 클라이언트와 코딩 에이전트 사이의 연결면을 다룹니다. 그래서 ACP는 MCP의 대체재가 아니라 AI 개발 도구 스택의 다른 계층입니다.
MCP를 이미 알고 있다면 ACP가 처음에는 비슷해 보입니다. 둘 다 프로토콜이고, 둘 다 AI 개발 도구 논의에서 같이 언급됩니다. 다만 연결하는 대상은 다릅니다.
MCP는 AI 애플리케이션이 데이터 소스, 도구, 워크플로에 접근하는 방식을 다룹니다. 반면 Agent Client Protocol은 에디터나 IDE 같은 client가 코딩 agent와 대화하는 흐름을 다룹니다. 공식 protocol overview 기준 ACP는 JSON-RPC 2.0 기반이며 `initialize`, 필요 시 `authenticate`, `session/new`, `session/prompt`, `session/update`, `session/cancel` 같은 흐름을 갖습니다.
| 구분 | MCP | ACP |
|---|---|---|
| 연결 경계 | AI 앱/agent와 tool, data, workflow | editor/client와 coding agent |
| 독자가 체감하는 문제 | 외부 시스템을 AI에 붙이기 | 여러 agent를 같은 에디터 경험에서 비교하기 |
| 도입 판단 | 서버, 권한, 데이터 접근 범위 | protocolVersion, capabilities, authMethods, agent runtime |
한국 개발자 입장에서는 이 구분이 중요합니다. "MCP를 이미 쓰는데 ACP도 봐야 하나"라는 질문에 대한 답은, 에이전트 UI와 런타임을 분리하고 싶을 때만 ACP가 의미 있다는 쪽에 가깝습니다. Notion, DB, GitHub 같은 외부 도구 연결이 목표라면 MCP 쪽을 먼저 보는 편이 맞습니다.
도입 시뮬레이션: 가장 작은 첫 테스트부터 시작하기
첫 테스트는 Zed external agents나 ACP Registry처럼 실제 client와 agent 목록을 함께 확인할 수 있는 경로에서 시작하는 편이 안전합니다. SDK부터 구현하기보다 registry JSON, protocolVersion, capabilities, authMethods가 실제로 보이는지 먼저 확인하는 흐름이 좋습니다.
ACP는 일반 앱처럼 설치 버튼 하나로 끝나는 물건이 아닙니다. protocol, SDK, registry, editor integration이 함께 움직입니다. 그래서 첫 테스트의 목표도 "설치 완료"보다 "연결 경계가 실제로 보이는가"에 두는 편이 낫습니다.
작게 시작하려면 세 단계면 충분합니다.
1. `curl <링크> registry JSON을 받고 `agents` 배열, `id`, `name`, `version`, `distribution`, `repository` 필드를 확인합니다.
2. Zed를 쓴다면 Agent Panel에서 registry 기반 agent 설치 경로를 확인합니다. Zed 문서는 v0.221.x부터 ACP Registry가 external agent 설치의 preferred path라고 설명합니다.
3. protocol 수준에서는 `initialize`에서 `protocolVersion` 1과 `clientCapabilities`를 보내고, agent가 `agentCapabilities`와 `authMethods`를 어떻게 돌려주는지 봅니다.
SDK 검토가 목적이면 공식 설치 명령도 분명합니다. TypeScript는 `npm install @agentclientprotocol/sdk`, Python은 `pip install agent-client-protocol` 또는 `uv add agent-client-protocol`, Rust는 `cargo add agent-client-protocol`입니다. 팀에서 custom client나 custom agent를 만들 생각이 아니라면 SDK 구현보다 Zed/Registry smoke test가 먼저입니다.
GitHub Copilot CLI도 테스트 경로가 있습니다. GitHub Docs는 ACP server 지원을 public preview로 설명하고, stdio 실행 예시로 `copilot --acp --stdio`, TCP 실행 예시로 `copilot --acp --port 3000`을 제시합니다. preview 기능은 운영 자동화에 바로 넣기보다 변경 가능성을 감안하는 쪽이 맞습니다.
운영 모델: 버전 숫자보다 capabilities를 봐야 합니다
ACP 호환성은 패키지 버전 숫자만으로 판단하면 위험합니다. 실제 운영에서는 initialize 단계의 protocolVersion, clientCapabilities, agentCapabilities, authMethods를 기록하고, stdio 로그와 파일/터미널 권한을 함께 확인해야 합니다.
공식 README는 stable ACP wire protocol version을 1로 설명하고, crate나 schema package version과 wire 호환성은 별개라고 안내합니다. 운영에서는 이 구분이 꽤 중요합니다. "SDK가 최신이다"보다 "client와 agent가 어떤 protocolVersion과 capability로 합의했는가"가 더 직접적인 판단 기준입니다.
운영 체크는 다음처럼 잡는 편이 좋습니다.
- `initialize`: `protocolVersion`, `clientCapabilities`, `agentCapabilities`, `authMethods`, implementation info를 로그로 남깁니다.
- transport: 가능한 경우 stdio를 우선 검토합니다. ACP transport 문서는 stdio에서 stdout에는 유효한 ACP 메시지만 쓰고 로그는 stderr로 보낼 수 있다고 설명합니다.
- 권한: 파일 읽기/쓰기, 터미널 실행, 이미지/오디오/embedded context, MCP HTTP/SSE 지원 여부를 capabilities로 확인합니다.
- Zed 디버깅: Zed에서는 external agent와 오가는 ACP 메시지를 log view로 확인하는 경로가 문서화돼 있습니다.
- 버전 관리: registry entry나 agent package version이 자동 갱신될 수 있으므로 팀 환경에서는 agent version과 registry JSON snapshot을 기록합니다.
다만 ACP를 "agent 품질 보증 장치"로 착각하면 곤란합니다. ACP는 editor-agent 연결 계약에 가깝습니다. 에이전트가 좋은 코드를 쓰는지, API 비용이 적절한지, 회사 소스코드 정책에 맞는지는 별도 검증이 필요합니다.
누가 써볼 만하고, 누가 보류해야 하나
ACP는 여러 AI 코딩 에이전트를 같은 에디터 경험에서 비교하려는 개인 개발자, 사내 개발자 도구팀, custom IDE integration 팀에 잘 맞습니다. 반대로 tool 연결만 필요하거나, 로컬 CLI agent의 파일/터미널 접근을 허용할 수 없는 팀은 보류하는 편이 낫습니다.
추천 대상은 비교적 명확합니다. Zed, VS Code extension, Neovim plugin, JetBrains plugin 같은 client에서 agent runtime을 분리해 보고 싶은 개발자에게 ACP는 좋은 탐색 주제입니다. Claude Agent, Codex CLI, Gemini CLI, GitHub Copilot, OpenCode, Qwen Code 같은 이름을 한 화면에서 비교하려는 흐름에도 잘 맞습니다.
| 상황 | ACP를 볼 이유 | 먼저 확인할 것 |
|---|---|---|
| 개인 개발자 | Codex, Gemini CLI, Copilot CLI를 editor-agent protocol 관점에서 비교 | Zed external agents, registry JSON, agent 인증 방식 |
| 사내 개발자 플랫폼팀 | custom coding agent를 IDE extension이나 Zed custom agent에 붙일 수 있는지 검토 | 파일 쓰기, 터미널 실행, audit log, authMethods |
| AI 도구 리서처 | MCP의 tool access와 ACP의 editor UX를 나눠 평가 | MCP 서버 경계, ACP capabilities, agent runtime |
보류해야 할 조건도 있습니다. 목표가 데이터베이스, SaaS, 파일 시스템 같은 외부 도구 연결이라면 ACP보다 MCP가 먼저입니다. 조직 정책상 로컬 CLI agent가 프로젝트 파일을 읽고 쓰거나 터미널을 실행하는 것을 허용하기 어렵다면 보안 설계 없이 도입하면 안 됩니다. 원격 transport가 필수인데 Streamable HTTP가 draft proposal 상태라는 점을 감당하기 어렵다면 기다리는 편이 안전합니다.
도입 전 리스크: preview, 인증, 권한을 분리해서 봅니다
ACP는 활발한 표준 후보로 소개해야 하며 업계 표준 확정이나 MCP 대체라고 단정하면 안 됩니다. 기업이나 팀에서는 API key 보관, 로컬 파일 접근, 터미널 실행, authMethods, preview 기능 변경 가능성을 먼저 점검해야 합니다.
`agentclientprotocol agent-client-protocol AI editor agent protocol`을 과장하지 않으려면 리스크를 같이 적어야 합니다. GitHub stars나 pushed_at은 실제 기업 채택률이 아닙니다. registry 등재도 운영 안정성을 보장하지 않습니다.
실무 도입 전 체크리스트는 짧게 잡아도 충분합니다.
- 인증: `authMethods`가 agent auth인지, terminal auth인지, OAuth callback용 로컬 HTTP server가 필요한지 확인합니다.
- 비밀값: `CODEX_API_KEY`, `OPENAI_API_KEY`, `GEMINI_API_KEY`, `GOOGLE_AI_API_KEY` 같은 provider별 키 저장 위치를 분리합니다.
- 파일 권한: agent가 workspace 파일을 읽고 쓸 수 있는지, 승인 UI가 있는지, 팀 정책과 맞는지 확인합니다.
- 터미널 실행: shell command 실행이 가능한 agent라면 audit log와 denylist를 따로 둡니다.
- preview 기능: Copilot CLI ACP server처럼 public preview로 표시된 기능은 명령 플래그와 출력 형식이 바뀔 수 있다고 가정합니다.
제 판단으로는 ACP를 "바로 전사 표준으로 채택"하기보다, 한 팀의 개발자 도구 실험으로 작게 시작하는 편이 맞습니다. 첫 주에는 registry JSON, Zed external agent, protocol log만 확인하고, 그다음에 provider별 비용과 데이터 처리 경계를 붙이는 흐름이 현실적입니다.
자주 묻는 질문
Q. Agent Client Protocol은 MCP와 무엇이 다른가요?
A. MCP는 AI 앱이나 agent가 외부 도구, 데이터, 워크플로에 접근하는 경계를 다룹니다. Agent Client Protocol은 에디터나 IDE 같은 client와 코딩 agent 사이의 연결 경계를 다룹니다. 그래서 ACP는 MCP 대체재가 아니라 다른 계층의 프로토콜로 보는 편이 정확합니다.
Q. ACP가 있으면 Codex, Copilot, Claude Agent, Gemini CLI를 같은 에디터에서 바꿔 쓸 수 있나요?
A. 가능성을 열어주는 방향은 맞지만 모든 에디터와 모든 agent가 완전 지원한다고 단정하면 안 됩니다. 공식 Agents 문서와 Zed external agents 문서에는 Codex CLI, Gemini CLI, GitHub Copilot, Claude Agent 같은 ACP-compatible agent 흐름이 보이지만, 실제 사용 가능 여부는 client, agent, 인증 방식, capabilities에 따라 확인해야 합니다.
Q. ACP를 처음 테스트하려면 무엇부터 보면 좋나요?
A. 가장 작은 테스트는 `curl <링크> registry JSON을 확인하고, Zed external agents에서 registry 기반 설치 경로를 보는 것입니다. custom 구현이 목적이면 그다음에 `npm install @agentclientprotocol/sdk`, `pip install agent-client-protocol`, `cargo add agent-client-protocol` 중 사용하는 언어의 SDK로 `initialize`와 `session/prompt` 흐름을 확인하면 됩니다.
Q. Agent Client Protocol은 지금 실무 표준인가요?
A. 현재는 활발한 표준 후보 또는 프로토콜 생태계로 보는 편이 안전합니다. 2026년 6월 1일 기준 GitHub 활동, registry 업데이트, Zed와 Copilot CLI 문서가 있지만, 이것만으로 업계 표준 확정이나 모든 주요 IDE 지원을 주장할 수는 없습니다.
Q. 팀에서 ACP 도입을 보류해야 하는 조건은 무엇인가요?
A. 로컬 CLI agent의 파일 읽기/쓰기와 터미널 실행을 허용할 수 없거나, provider별 API key와 OAuth 흐름을 분리 관리할 수 없다면 보류하는 편이 낫습니다. 원격 agent transport가 필수인데 draft 상태의 HTTP transport를 기다릴 수 없는 경우도 실험 범위를 줄여야 합니다.
Q. GitHub stars 3,265개는 실제 채택을 의미하나요?
A. 아닙니다. 2026년 6월 1일 기준 3,265 stars와 최근 pushed_at은 관심도와 유지보수 활동 신호로 해석해야 합니다. 실제 채택 판단에는 사용 중인 editor/client, agent runtime, 인증, 권한, 팀 보안 정책까지 별도로 확인해야 합니다.
함께 읽으면 좋은 글
참조 링크
- agentclientprotocol/agent-client-protocol — 추천 대상 공식 저장소이며 README, license, releases, commits 확인의 기준점
- GitHub REST API repository metadata for agentclientprotocol/agent-client-protocol — stars, forks, pushed_at, created_at 같은 변동 지표 확인 기준
- Agent Client Protocol Introduction — ACP의 목적과 editor-agent 연결 문제를 설명하는 공식 시작 문서
- Agent Client Protocol Overview — JSON-RPC 2.0 기반 흐름과 session lifecycle 확인에 사용
- Agent Client Protocol Initialization — protocolVersion, capabilities, authMethods 확인 근거
- Agent Client Protocol Transports — stdio 권장, stdout/stderr 로그 분리, HTTP draft 상태 확인 근거
- ACP Registry — registry JSON 확인과 ACP-compatible agents 탐색 경로
- agentclientprotocol/registry — registry 인증 요건, 배포 포맷, agent version 갱신 정책 확인
- Release v0.13.4 — 2026-05-27 최신 릴리스 확인 근거
- docs: update registry agents (#1323) — 2026-06-01 기준 registry agents 문서 업데이트 활동 신호
- External Agents | Use Claude Agent, Gemini CLI, and Codex in Zed — 실제 editor client에서 ACP external agents를 사용하는 adoption path
- Copilot CLI ACP server — GitHub Copilot CLI ACP server public preview와 실행 명령 확인
- TypeScript library for the Agent Client Protocol — TypeScript SDK 설치 명령과 connection helper 확인
- Python library for the Agent Client Protocol — Python SDK 설치 명령 확인
- Rust library for the Agent Client Protocol — Rust crate 설치 명령 확인
- What is the Model Context Protocol (MCP)? — MCP와 ACP의 연결 경계 비교에 사용한 공식 문서