격리된 내 AI에 Claude Code를 붙이는 네 갈래 — 그리고 'ACP'라는 이름이 둘이었다

샌드박스와 방화벽으로 가둬 둔 내 로컬 AI 비서에, 이번엔 Claude Code 같은 외부 코딩 에이전트를 붙여 쓰고 싶어졌다. 찾아보니 방법이 여럿이라고 했다 — 모델 API로 직접 부르거나, ACP로 붙이거나, A2A로 붙이거나, 브리지를 쓰는 식이었다. 그런데 "ACP로 붙인다"를 파고들다가 멈칫했다. 내가 얼마 전에 "ACP가 A2A에 흡수돼 사라졌다"고 정리했던 바로 그 ACP를, 지금 오픈소스 도구들이 멀쩡히 쓰고 있었기 때문이다.

혼란은 나만의 것이 아니었다. 프로토콜 비교를 다룬 커뮤니티 글을 몇 개 찾아 읽었는데, 절반은 "ACP는 이제 없다"고 하고 절반은 "ACP로 Claude Code를 연결한다"고 했다. 같은 세 글자를 두고 정반대 이야기를 하고 있었다. 이유는 단순했다 — ACP라는 약어를 쓰는 프로토콜이 두 개이고, 둘은 하는 일이 거의 반대다. 이 글은 그 이름 충돌을 먼저 풀고, 외부 AI를 붙이는 네 갈래를 하나의 지도로 정리한 다음, 격리된 내 환경에서는 그 선택이 왜 방화벽에 구멍을 하나 더 뚫느냐 마느냐의 문제가 되는지까지 이어 본다.

먼저 이름 충돌 — 'ACP'는 서로 다른 두 프로토콜이다

같은 약어를 쓰지만 풀어 쓴 이름부터 다르다. 하나는 Agent Client Protocol(에이전트 클라이언트 프로토콜)이고, 다른 하나는 Agent Communication Protocol(에이전트 커뮤니케이션 프로토콜)이다. 각각이 무엇을 연결하는지를 나란히 놓으면 차이가 분명해진다.

▲ Agent Client Protocol (Zed 발) — 클라이언트가 에이전트를 실행한다

다이어그램 설명. Zed Industries가 2025년 8월 내놓은 Agent Client Protocol이 연결하는 두 주체를 보여준다. 한쪽은 코드 에디터나 그 역할을 하는 호스트 앱이고, 다른 쪽은 Claude Code 같은 코딩 에이전트다. 둘은 JSON-RPC(요청·응답을 정해진 형식으로 주고받는 규격) 2.0으로 대화하되, 통로가 stdio(표준입출력 — 프로세스의 기본 입출력)다. 즉 에이전트가 클라이언트의 자식 프로세스로 실행된다는 뜻이다. 이 프로토콜의 목적은 "에디터마다 에이전트 연동을 새로 짜는" 중복을 없애는 것 — 언어 지원을 표준화한 Language Server Protocol이 에디터와 언어 도구를 갈라놓았듯, 이쪽은 에디터와 에이전트를 갈라놓는다. 그래서 에디터를 안 바꾸고 에이전트만 갈아끼울 수 있다.

▲ Agent Communication Protocol (IBM 발) — 에이전트끼리 대화하다 A2A에 합류

다이어그램 설명. IBM 계열에서 나온 Agent Communication Protocol은 에디터와 에이전트가 아니라 에이전트와 에이전트를 잇는 규격이었다. 방식도 로컬 프로세스가 아니라 REST·HTTP 메시징이다. 그런데 이쪽은 2025년에 A2A(Agent-to-Agent) 프로토콜로 기술이 합쳐지면서 독립 규격으로는 아카이브됐다 — 내가 지난 글에서 "사라졌다"고 쓴 게 이것이다. 놓치기 쉬운 함정이 여기 있다. "ACP가 사라졌다"는 말은 Agent Communication Protocol에만 참이고, 지금 Claude Code를 붙이는 데 쓰이는 Agent Client Protocol은 멀쩡히 살아 활발히 쓰인다. 같은 세 글자를 보고 하나로 합쳐 읽으면 정반대 결론에 도달한다.

정리하면, 이 글에서 "ACP로 붙인다"고 할 때의 ACP는 Zed의 Agent Client Protocol이다. 실제로 내가 쓰는 로컬 도구도 이 규격의 구현체(패키지 이름에 agentclientprotocol, zed-industries/codex-acp가 그대로 박혀 있다)를 통해 Claude Code와 Codex를 붙인다.

API로 붙이면 '모델', ACP로 붙이면 '에이전트'

이름을 정리했으니 본질적인 질문으로 간다. 외부 AI를 붙인다고 할 때, 정확히 무엇이 딸려 오는가? 여기서 API 방식과 ACP 방식이 갈린다. 둘의 차이는 속도나 편의가 아니라 "얻는 물건 자체"가 다른 것이다.

▲ API 방식 — 날것의 모델을 얻는다

다이어그램 설명. 모델 API로 붙이면 오는 것은 모델 하나다. 프롬프트를 넣으면 답이 나오는, 딱 그 기능이다. Claude Code가 파일을 읽고 명령을 돌리고 스스로 다음 할 일을 정하는 그 모든 동작 — 도구 호출, 여러 번 반복하는 에이전트 루프, "이 명령 실행해도 되나" 묻는 권한 확인 — 은 따라오지 않는다. 그건 Claude Code라는 하네스(모델을 감싸 도구·루프·권한을 붙인 실행 껍데기)가 하는 일이지, 모델 자체가 하는 일이 아니기 때문이다. API로 모델만 받으면 그 껍데기를 내가 처음부터 다시 만들어야 한다.

▲ ACP 방식 — 에이전트를 통째로 얻는다

다이어그램 설명. 반대로 ACP로 붙이면 오는 것은 Claude Code라는 에이전트 통째다. 도구도, 스스로 반복하는 루프도, 권한 확인도 이미 그 안에 들어 있다. 내 시스템은 그 에이전트를 자식 프로세스로 실행하고 대화만 하면 된다. 두 방식을 한 문장으로 대비하면 이렇다 — API는 요리 재료를 받는 것이고, ACP는 요리사를 통째로 데려오는 것이다. 재료만 필요하면 API가 맞고, 완성된 조리 과정 전체가 필요하면 ACP가 맞다. 어느 쪽이 옳고 그른 게 아니라, 내가 만들려는 게 무엇이냐에 달렸다.

네 갈래의 지도 — 대체재가 아니라 서로 다른 층이다

이제 API·ACP에 나머지 둘(A2A·브리지)을 더해 전체 지도를 그린다. 흔한 오해는 이 넷을 "무엇이 이기나" 하는 경쟁 후보로 보는 것인데, 실제로는 각자 다른 층에서 다른 대상을 연결하는 상보재다.

다이어그램 설명. 격리된 내 시스템에서 뻗어 나가는 네 갈래를 보여준다. "모델 API"는 모델 하나를 부르는 가장 낮고 단순한 층이다. "ACP"는 Claude Code 같은 외부 하네스를 자식 프로세스로 실행해 통째로 붙이는 층이다. "A2A"는 내가 실행·소유하지 않는, 어딘가에서 독립적으로 도는 대등한 에이전트와 네트워크로 협업하는 층 — 조직이나 벤더를 넘는 수평 연결이다. 마지막 "브리지"는 나머지 셋과 성격이 다르다. 독립된 연결 방식이 아니라, 서로 규격이 안 맞는 둘 사이에 끼어 말을 번역해 주는 어댑터다. 이 지도의 핵심은 넷이 한 줄에 놓인 경쟁자가 아니라 각기 다른 높이에 있다는 점이다 — 도구만 필요하면 MCP(모델과 도구를 잇는 별도 규격), 모델만 필요하면 API, 에이전트 전체가 필요하면 ACP, 남이 소유한 에이전트와 협업하려면 A2A. 실제로 잘 짜인 시스템은 이들을 섞어 쓴다.

브리지가 왜 따로 필요한지는 바로 다음 편에서 자세히 다루지만, 지금 감만 잡아 두면 이렇다. Anthropic은 자기 Claude Code가 ACP를 네이티브로 말하도록 만들지 않았다. 그런데도 Claude Code가 ACP를 쓰는 여러 에디터·도구에서 도는 이유는, 중간에서 Claude Code를 감싸 ACP로 통역해 주는 브리지 어댑터가 있기 때문이다. 규격이 안 맞는 현실을 접착제로 메우는 층 — 그게 브리지다.

격리된 환경에선 이 선택이 방화벽을 가른다

여기까지는 어느 환경에나 해당하는 일반론이다. 그런데 내 경우처럼 AI를 샌드박스와 방화벽으로 가둬 둔 환경에서는 이 네 갈래가 하나의 실용적 질문으로 수렴한다 — "이 연결이 격리 경계를 넘느냐, 안 넘느냐?" 넘으면 방화벽 허용목록에 목적지를 새로 등록해야 하고, 그건 애써 좁혀 둔 나가는 통로에 구멍을 하나 더 내는 일이다.

다이어그램 설명. 같은 "외부 AI 연동"이라도 격리 경계를 넘는 것과 안 넘는 것이 갈린다는 걸 보여준다. ACP로 붙인 외부 하네스는 내 시스템의 자식 프로세스로 경계 안에서 태어나 stdio로 대화하므로, 그 연결 자체는 네트워크로 나가지 않는다. 반면 모델 API나 대등한 A2A 에이전트는 경계 밖에 있어 HTTP로 나가야 하고, 그 목적지를 방화벽 허용목록에 등록해야 한다. 다만 여기 정직하게 짚어야 할 함정이 하나 있다 — ACP가 네트워크를 아예 없애 주는 건 아니다. 내가 실행한 그 하네스(Claude Code)는 결국 자기 일을 하려고 자기 모델 서버를 부른다. 즉 ACP는 나가는 통로를 없애는 게 아니라, 그 통로가 열리는 위치를 내 시스템이 아니라 하네스 프로세스 쪽으로 옮긴다. 그래서 "그 하네스를 경계 안에 둘지 밖에 둘지"라는 새 결정이 따라온다. 앞선 글에서 다룬 크레덴셜 격리 문제가 여기서 다시 고개를 든다.

정리 — 무엇을 얻느냐, 그리고 그게 경계를 넘느냐

외부 AI를 붙이는 방법을 고를 때 나는 이제 두 가지만 먼저 묻는다. 첫째, 무엇이 딸려 오는가 — 날것의 모델(API)인지, 에이전트 통째(ACP)인지, 남이 소유한 피어(A2A)인지를 가른다. 둘째, 그 연결이 격리 경계를 넘는가 — 로컬 프로세스로 안에서 끝나는가(ACP의 stdio), 아니면 방화벽에 목적지를 등록해야 하는 네트워크 통로인가(API·A2A). 그리고 그 사이에는 규격이 안 맞는 둘을 억지로 잇는 브리지가 있다. 이름이 같아 헷갈리는 'ACP' 앞에서 멈추지 않으려면, 약어가 아니라 그게 무엇과 무엇을 잇는지부터 보면 된다. 다음 편에서는 이 중 ACP를 골라, 격리된 내 시스템이 Claude Code를 실제로 어떻게 실행하고 그 세션을 누가 소유하는지 — 그 동작 속을 열어 본다.

---

참고한 공개 자료:

• Zed — Agent Client Protocol: https://zed.dev/acp
• Zed Docs — External Agents (Claude Code·Gemini CLI·Codex 연동): https://zed.dev/docs/ai/external-agents
• Morph — Agent Client Protocol Explained (ACP vs MCP): https://www.morphllm.com/agent-client-protocol
• Zuplo — MCP, A2A, and Where ACP Went: https://zuplo.com/blog/agent-protocol-stack-mcp-a2a-acp-2026
• Medium (Sandi Besen) — An Unbiased Comparison of MCP, ACP, and A2A Protocols: https://medium.com/@sandibesen/an-unbiased-comparison-of-mcp-acp-and-a2a-protocols-0b45923a20f3
• Model Context Protocol — Transports (stdio·Streamable HTTP): https://modelcontextprotocol.io/specification/2025-03-26/basic/transports

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.