▲

에이전트 클라이언트 프로토콜(ACP)

 (agentclientprotocol.com)
12P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • Agent Client Protocol(ACP) 은 코드 에디터와 AI 코딩 에이전트 간의 통신을 표준화하기 위한 프로토콜
  • 기존에는 각 에디터가 특정 에이전트와 연결되려면 별도의 커스텀 통합 작업이 필요했고, 이는 호환성 제한과 개발자 락인 문제를 초래했음
  • ACP는 언어 서버 프로토콜(LSP) 처럼 표준화된 통신 방식을 제공해, 한 번 구현하면 모든 호환 에디터·에이전트 간에 자유롭게 연결 가능하도록 함
  • 에디터에서 에이전트를 서브 프로세스로 실행하고, JSON-RPC over stdio로 통신하며, UI 요소에는 diff 표시와 Markdown 기반 출력을 지원함
  • 현재 Zed, neovim(CodeCompanion 플러그인) 등이 ACP를 지원하고, 에이전트 측에서는 Gemini CLI가 호환되며 앞으로 지원 범위가 확대될 예정임

소개

  • Agent Client Protocol(ACP) 은 원격 개발, 포트 포워딩, 명령 실행 등과 같은 서버-클라이언트 간 상호작용을 표준화하는 목적으로 설계된 개방형 프로토콜임
  • 기존 문제점: AI 코딩 에이전트와 에디터는 긴밀히 연결되어 있지만, 상호 운용성이 기본적으로 보장되지 않음
    • 각 에디터는 지원하려는 에이전트마다 커스텀 통합을 구축해야 함
    • 에이전트는 특정 에디터 API를 구현해야 사용자에게 도달 가능
    • 이는 통합 오버헤드, 제한된 호환성, 개발자 종속성 문제를 초래
  • ACP의 해결책: ACP는 에이전트와 에디터 간 표준화된 프로토콜을 제공
    • ACP를 구현한 에이전트는 모든 호환 에디터에서 동작
    • ACP를 지원하는 에디터는 ACP 호환 에이전트 생태계 전체에 접근 가능
    • 독립적 혁신을 가능하게 하며, 개발자가 워크플로우에 최적화된 도구 선택 가능

ACP 개요

  • 운영 방식: 사용자가 주로 코드 에디터에서 작업하며, 특정 작업을 위해 에이전트를 호출
    • 에이전트는 에디터의 서브프로세스로 실행
    • JSON-RPC를 stdio를 통해 사용해 통신
  • 데이터 형식: MCP의 JSON 형식을 재사용하며, diff 표시와 같은 에이전트 코딩 UX 요소를 위한 커스텀 타입 포함
  • 텍스트 포맷: 사용자 가독성을 위해 마크다운 형식을 기본으로 사용
    • HTML 렌더링 없이도 풍부한 포맷팅 가능
  • 현재 프로토콜은 개발 중이나, 흥미로운 사용자 경험을 구축하기에 충분한 완성도 보유

현재 지원 현황

결론

  • ACP는 LSP의 성공 사례를 본떠, AI 코딩 에이전트와 에디터 간의 상호 운용성을 혁신적으로 개선
  • 개발자는 특정 에이전트나 에디터에 종속되지 않고, 최적의 도구 조합을 자유롭게 선택 가능
  • 프로토콜의 확장은 생태계 확장성을 높이며, 개발자 워크플로우의 효율성과 유연성을 증대 가능
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • Claude한테 AI 에이전트와 IDE/에디터 간 통신 프로토콜을 만들어 달라고 요청함, Node, Python, Rust 라이브러리도 개발하고, 랜딩 페이지가 있는 웹사이트까지 구축해달라는 생각을 해봄

    • 솔직히 Gemini가 이 프로토콜을 구현하는 Sublime Text 플러그인을 쓸 수 있는지 시험해보고 싶은 유혹이 있음, 최근 대부분의 사용자들이 VSCode 쪽으로 쏠리는 분위기임, 그래서 새로운 툴들은 지원을 거기로만 하게 되는 경향이 생김, Sublime을 더이상 지원하지 않아 강제로 이동당하는 건 피하고 싶음, Sublime은 정말 좋은 에디터이고, 거대 회사의 지원을 받는 것도 아님

    • 그리고 발자취를 숨기기 위해 Gemini만 지원하는 에이전트가 되도록 만들 수도 있을 것 같음

    • 웃김, 너무 자기중심적인 바람임

  • 이번 프로젝트 정말 잘 되길 바람, Zed가 협업의 본질로 돌아가고 있고, 이 흐름이 agentic IDE 카테고리에도 변화를 줄 수 있을 것 같음, 이렇게 되면 Zed는 직접적으로 경쟁하는 데 시간을 쏟지 않아도 되고, 차별점도 생김, CLI 에이전트들 사이에서 얼마나 채택될지 궁금함 (벌써 Gemini CLI가 연동된 것도 보기 좋음), LLM과 코딩 어시스턴트 시장의 치열한 경쟁은 언제나 환영임, 이런 변화들이 서로 간 전환 비용을 꾸준히 낮춰줄 거라 생각함

    • 나도 거의 Zed에 넘어갈 정도임, 몇 년간 원하던 에디터의 기능이 거의 다 들어있음, 내가 상상 못한 멋진 기능들도 많음, 기존 상태에 실망해 직접 에디터를 프로토타입 만들어 봤던 적도 있지만, 좋은 에디터 하나 만들려면 정말 많은 노력이 들어감, Zed는 그 노력을 해왔음, 오픈하게 협업하려는 그들 움직임 환영함

    • 진심임, 이번 변화가 허접한 VS Code 포크들이 사라지는 계기가 됐으면 함, Zed도 마땅한 인정을 받았으면 좋겠음, AI 에디터들이 정말 산업에 산소를 다 뺏어간 느낌임

  • Claude Code가 ACP를 사용할 수 있도록 도구를 만들고 있음 (내가 CC와 Zed를 자주 써서), 지금까지는 Claude Code SDK랑 ACP Client 라이브러리로 꽤 성공적으로 진행해 왔음, 아직 다듬어야 할 부분이 조금 있음, 내일쯤 조금 더 다듬어서 오픈할 예정임

  • 이미 agentcommunicationprotocol.dev 라는 ACP가 나온 상태라, 이름이 혼란스러울 수 있음, 두 프로젝트 사이에 차이가 있긴 하지만 이런 부분은 신경이 쓰임

    • 2025년 3월 IBM이 Agent Communication Protocol (ACP)를 발표했지만, 이제는 ACP라는 이름을 포기하고 ACP 관련 작업을 Google의 Agent2Agent (A2A) 프로토콜과 합치기로 결정함, 이 결정은 모든 ACP 개발팀이 해체 수순에 들어가면서, 업계가 Linux Foundation 주도로 A2A에 힘을 싣는 추세임, 이로써 AI 에이전트 표준의 파편화 문제를 피하고, 커뮤니티 주도 오픈 프로토콜로 통합을 노림 여기에서 자세히 보기

  • 가장 궁금한 점은 왜 LSP 서버나 LSP 프로토콜의 확장으로 LLM이 필요한 내용을 커버하지 못하는가임

    • LSP에는 AI 붐이 없기 때문임, AI는 지금 초창기 자바스크립트 라이브러리처럼 폭발적으로 여러 도구가 난립하는 시기를 겪고 있음, 이전의 축적된 경험과 지식을 완전히 무시한 채로 잘못된 문제를 잘못된 도구로 해결하고 있는 상황임, 결국 이런 접근은 JS 라이브러리처럼 복잡성과 비효율만 더 쌓게 될 것임, 문제를 잘못 풀면 또 새로운 문제들이 나오고 결국 더 많은 잘못된 해결책을 추가해야 하는 악순환이 생김

  • 나는 AI를 실제 사람 개발자처럼 다루는 게 편함, 예를 들어 AI한테 기능 구현이나 버그 수정, 리팩토링을 요청하고, 그 결과 커밋을 읽어봄, 커밋이 마음에 안 들면 "git reset --hard" 하고 프롬프트를 개선해 다시 AI에게 시킴, 이 방식에 대해 "프롬프트 코딩(prompt coding)"이라고 부름, 내 코딩 환경과 AI간의 직접적인 상호작용은 필요가 없음, 인간 개발자처럼 내 에디터를 건드리는 일 없이 일함 관련 설명

    • 요즘엔 프롬프트 작성이 더 낫다고 하는데, 그 부분은 좀 의심스러움, AI가 일부 아주 특정한 작업에는 도움이 되지만 아직도 헛소리가 많이 나옴, 특히 API같이 없는 이야기를 만들어 내는 게 용납하기 힘듦

    • 나는 AI에게 커밋까지 시키지는 않음, 거의 항상 AI 결과물을 여러 부분 수정해야 함, 재프롬프트(reprompt)를 반복하는 데 시간이 아까워 처음에 원하는 답을 못하면 그냥 직접 고치는 편임, 처음부터 내가 원하는 바를 이해하고 코드를 주면 그땐 AI에 대한 신뢰감이 커짐

  • 이번 아이디어가 더 확산됐으면 함, 한 가지 궁금한 점은 파일 검색이랑 저장 안 된 파일들의 차이임, 실제로 에이전트들이 파일 시스템 검색할 때 ripgrep 같은 걸 많이 쓰는데, 문제는 프로토콜에서 저장 안 된 파일까지 읽고 쓸 수 있게 한다면 정확도에 문제가 생김, ripgrep은 저장 안 된 파일을 검색하지 못함

  • Anthropic이 이 프로토콜을 Claude Code에 도입해주길 정말 바람, 최소한 VSCode에서 제공되는 수준의 연동은 기대함, 그리고 적어도 에디터의 진단 정보라도 접근할 수 있으면 좋겠음

  • MCP도 처음엔 stdio 위에서 JSON-RPC로 출발했음, GitHub Codespaces, devcontainers, "background agents" 같은 환경이 나오면서 JSON over SSE 같은 발전이 있을지도 궁금함, 현재 내 개발환경은 로컬에서 Claude Code를 사용하고 있고, 앱은 컨테이너에서 돌아감, 에이전트가 "docker compose exec backend"를 자율적으로 실행할 수 있음, git worktree 작업 방식 도입에 걸림돌은 데이터베이스 엔진 공유(로컬 자원 부족)와 초기 마이그레이션 시간임, 이런 부담을 클라우드로 오프로드하는 것도 흥미로운 시나리오임

  • 이런 프로토콜이 확산돼서 내가 항상 기존 IDE 하나에 묶이지 않아도 되길 바람

답변달기