에이전트를 만들지 말고, 연결하라 — ACP가 바꾸는 멀티 에이전트 오케스트레이션

ACP 개념 해부

a) 프로토콜이란 무엇인가

“프로토콜"이라는 단어가 나오면 눈이 흐려지는 분들이 많다. 개발자도 그렇고, 비개발자는 더하다. 그래서 먼저 프로토콜을 일상 언어로 풀어보겠다.

프로토콜은 약속된 대화 방식이다.

택배를 생각해보자. 보내는 사람은 박스에 물건을 담고, 주소를 적고, 운임을 낸다. 받는 사람은 운송장 번호로 조회하고, 서명하고, 받는다. 이 절차가 전국 어느 택배사든 거의 동일하다. 그게 프로토콜이다. 만약 택배사마다 박스 규격, 주소 기입 방식, 수령 절차가 제각각이라면? 물건을 보내기 위해 택배사마다 다른 방법을 익혀야 한다. 카오스다.

인터넷이 지금처럼 작동하는 이유는 HTTP라는 프로토콜 덕분이다. 네이버 서버든 구글 서버든 카카오 서버든, 웹 브라우저는 동일한 방식으로 요청을 보내고 응답을 받는다. 서버가 어떤 언어로 만들어졌는지, 어떤 운영체제에서 돌아가는지는 관계없다. HTTP라는 공통 언어가 있기 때문에 모든 것이 연결된다.

HTTP가 등장하기 전, 웹 서버와 브라우저는 제각각의 방식으로 통신했다. 표준이 없었다. HTTP가 이것을 통일하자, 웹이 폭발적으로 성장했다. 하나의 표준이 생태계 전체를 바꾼 것이다.

b) 왜 에이전트에 프로토콜이 필요한가

AI 에이전트 세계는 지금 HTTP 이전의 웹과 비슷한 상태다.

Claude Code는 Claude Code의 방식이 있다. OpenAI Codex는 또 다른 API와 입력 형식을 쓴다. Google의 Gemini CLI는 또 다르다. 각 에이전트마다 실행 방법, 입력 형식, 출력 파싱, 오류 처리가 제각각이다.

그래서 “Claude Code와 Codex를 함께 써서, 하나가 코드를 짜면 다른 하나가 리뷰하게 만들고 싶다"는 아이디어는 간단해 보이지만, 실제 구현은 복잡하다. 각 에이전트의 실행 방식을 배우고, 출력을 파싱하고, 에러를 처리하고, 생명주기를 관리하는 코드를 직접 짜야 한다.

바로 여기서 ACP(Agent Client Protocol) 가 등장한다.

ACP는 서로 다른 코딩 에이전트들을 표준화된 인터페이스로 연결하는 프로토콜이다. Claude Code든, Codex든, OpenCode든, Gemini CLI든 — ACP를 통하면 동일한 방식으로 다룰 수 있다. 에이전트 오케스트레이터 입장에서는 “어떤 에이전트인지"를 몰라도 된다. 그냥 ACP로 부르면 된다.

HTTP가 “어떤 서버인지"를 몰라도 웹을 사용할 수 있게 해준 것처럼.

c) ACP의 핵심 설계 원리

ACP의 설계를 이해하면 왜 이 접근이 강력한지 알 수 있다. 핵심은 세 가지다.

격리(Isolation). 각 에이전트 세션은 독립적인 프로세스로 실행된다. A 에이전트가 폭주하거나 무한 루프에 빠져도 B 에이전트와 메인 오케스트레이터는 영향을 받지 않는다. 마치 브라우저 탭이 각각 독립적으로 실행되어, 하나가 크래시해도 다른 탭이 살아있는 것처럼.

표준화(Standardization). 세션 스폰, 메시지 전달, 결과 수신, 에러 처리가 모든 에이전트에 대해 동일한 인터페이스를 따른다. 에이전트를 교체해도 오케스트레이션 로직을 바꿀 필요가 없다.

생명주기 관리(Lifecycle Management). TTL(Time-To-Live) 설정으로 에이전트 세션이 자동으로 종료된다. 스레드 바인딩으로 특정 대화 맥락에 에이전트를 붙여둘 수 있다. 모델 오버라이드로 같은 에이전트를 다른 모델로 실행할 수 있다. 이런 생명주기 관련 관심사를 프로토콜 레벨에서 처리하기 때문에, 사용자는 “비즈니스 로직"에만 집중하면 된다.

d) MCP와의 관계/차이점

요즘 MCP(Model Context Protocol)도 많이 언급된다. MCP와 ACP는 비슷해 보이지만 해결하는 문제가 다르다.

MCP는 “모델에게 도구를 주는” 프로토콜이다. 웹 검색 도구, 파일 시스템 도구, 데이터베이스 도구를 LLM 모델이 사용할 수 있도록 표준화된 방식으로 연결한다. 주체는 모델이고, 도구는 모델의 능력을 확장하는 수단이다.

ACP는 “에이전트를 에이전트로 연결하는” 프로토콜이다. 이미 완성된 에이전트(Claude Code, Codex 등)를 또 다른 에이전트나 오케스트레이터가 표준 방식으로 호출하고 관리한다. 주체는 오케스트레이터이고, 에이전트는 독립적인 행위자다.

간단히 말하면: MCP는 “모델 + 도구”, ACP는 “에이전트 + 에이전트"다.

MCP가 “모델의 팔다리를 만들어줬다"면, ACP는 “그렇게 팔다리가 생긴 에이전트들이 팀으로 일하게 해주는” 프로토콜이다. 둘은 경쟁 관계가 아니라 서로 다른 레이어에서 동작하는 상호 보완적인 표준이다.

Agent-in-Agent vs Agent-via-Protocol: 철학의 차이

이제 핵심 대비로 들어가겠다. 이 두 접근의 차이는 단순히 기술적 선택의 문제가 아니다. 철학의 차이다.

Melanie Li의 실험: “직접 만드는” 방식

AI 엔지니어 Melanie Li는 멀티 에이전트 시스템 구축 경험을 공유했다. 요약하면 이렇다.

그는 OpenAI Agent SDK를 사용해서 서브 에이전트들을 직접 구현했다. 코딩 에이전트, 리뷰 에이전트, 테스트 에이전트를 각각 코드로 정의하고, 이들 사이의 통신 로직, 상태 관리, 오류 처리를 직접 작성했다.

결과는? 레이턴시 3배, 비용 3~5배, 디버깅 지옥.

왜 이런 일이 벌어졌을까. 에이전트가 에이전트를 “내부에서” 만들고 관리하면, 각 레이어마다 LLM 호출이 추가된다. 오케스트레이터가 서브 에이전트에게 작업을 설명하는 데도 토큰이 쓰이고, 서브 에이전트의 결과를 해석하는 데도 토큰이 쓰인다. 복잡성은 레이어가 쌓일수록 곱셈으로 늘어난다.

더 심각한 문제는 디버깅이다. 에이전트 A가 에이전트 B에게 내린 지시가 정확히 무엇이었는지, B가 그 지시를 어떻게 해석했는지 추적하기가 극도로 어렵다. 모든 것이 LLM의 컨텍스트 안에서 일어나기 때문에, 전통적인 프로그래밍에서 쓰는 디버깅 도구가 통하지 않는다.

이것이 “Agent-in-Agent” 방식의 본질적 한계다. 에이전트를 만들려는 시도가 오히려 에이전트의 능력을 갉아먹는다.

ACP의 접근: “연결하는” 방식

ACP의 철학은 정반대에서 출발한다.

이미 동작하는 에이전트를 만들지 말고, 연결하라.

Claude Code는 이미 탁월한 코딩 에이전트다. Codex도 마찬가지다. OpenCode도. 이들은 이미 수개월, 수년의 개발과 파인튜닝을 거쳐 완성된 에이전트들이다. 이들을 “내 에이전트 시스템 안에서 다시 만들려는 시도"는 처음부터 질 게 뻔한 싸움이다.

대신 ACP는 이렇게 접근한다: 각 에이전트를 독립된 프로세스로 실행하고, 표준화된 인터페이스로 메시지를 주고받는다. 오케스트레이터는 각 에이전트의 내부를 알 필요가 없다. 그냥 “이 작업은 Claude Code에게, 저 작업은 Codex에게” 라우팅하면 된다.

비유하자면 이렇다. Agent-in-Agent는 “내가 직접 직원을 교육해서 모든 일을 내 방식대로 하게 만드는” 방식이다. ACP는 “이미 해당 분야 전문가인 프리랜서를 프로젝트별로 계약하는” 방식이다. 전자는 통제감이 있지만 비용과 시간이 엄청나다. 후자는 처음엔 낯설지만, 전문가의 역량을 그대로 활용할 수 있다.

핵심 차이를 한 줄로: Agent-in-Agent는 “에이전트의 능력을 코드로 재구현"하고, ACP는 “에이전트의 능력을 프로토콜로 빌려쓴다.”

실전 사례: 내가 쓰고 있는 방법

개념만으로는 부족하다. 내가 실제로 어떻게 쓰는지 공유하겠다.

사례 1: 12시간 자율 개발 크론

매일 밤 12시, 크론 잡이 실행된다. GitHub 이슈 중 라벨이 붙은 항목들을 읽고, 각 이슈에 대해 ACP를 통해 Claude Code 세션을 스폰한다. Claude Code는 코드를 짜고 PR을 열고 세션을 종료한다. TTL이 설정되어 있어서 아무리 오래 걸려도 지정된 시간이 지나면 자동 종료된다.

이 모든 것이 설정 파일 몇 십 줄로 동작한다. Agent SDK로 같은 기능을 구현했다면? 세션 관리 코드, 재시도 로직, 오류 핸들링, 타임아웃 관리… 코드베이스가 3배는 커졌을 것이다.

사례 2: 멀티 에이전트 코드 리뷰

PR이 올라오면 두 개의 에이전트가 순차적으로 검토한다. 먼저 Codex가 코드 품질과 버그 가능성을 분석하고, 그 결과를 받아서 Claude Code가 아키텍처 관점에서 재검토한다. 두 에이전트는 서로 독립적인 프로세스로 실행되고, ACP가 결과를 중계한다.

Agent-in-Agent 방식으로 이걸 구현했다면, 오케스트레이터 에이전트가 “Codex 역할"과 “Claude Code 역할"을 번갈아가며 해야 한다. 결국 단일 LLM이 두 역할을 모방하는 것이고, 각 전문 에이전트의 실제 강점은 사라진다.

ACP 방식에서는 Codex는 진짜 Codex고, Claude Code는 진짜 Claude Code다.

사례 3: 스레드 바인딩 코딩 세션

Slack 스레드에서 “이 기능 구현해줘"라고 하면, 그 스레드에 바인딩된 OpenCode 세션이 생성된다. 이후 같은 스레드에서 나누는 대화는 모두 그 세션에 연결된다. 맥락이 유지된다. 세션을 닫기 전까지는 이전 대화를 기억하고 있다.

이게 가능한 이유는 ACP의 스레드 바인딩 기능 덕분이다. 세션 ID와 스레드 ID를 연결해두면, ACP 런타임이 메시지 라우팅을 알아서 처리한다. 내가 짠 코드는 거의 없다.

인사이트: 추상화 레벨을 올려라

이 경험들에서 얻은 핵심 인사이트를 정리하면 이렇다.

복잡성은 언제나 잘못된 추상화 레벨에서 나온다.

멀티 에이전트 시스템을 만들 때, 많은 사람들이 “LLM 레벨"에서 생각한다. 어떤 프롬프트를 쓸지, 어떻게 에이전트 역할을 정의할지, 컨텍스트를 어떻게 전달할지. 이 레벨에서 멀티 에이전트를 구현하면 Melanie Li의 사례처럼 된다.

ACP는 추상화 레벨을 한 단계 올린다. LLM이 아니라 에이전트 프로세스 레벨에서 생각한다. 각 에이전트는 독립적인 실행 단위이고, 프로토콜은 이들을 연결하는 인프라다. 오케스트레이터는 “어떤 모델을 쓸지"가 아니라 “어떤 에이전트에게 어떤 작업을 맡길지"를 결정하면 된다.

이것은 소프트웨어 공학의 고전적 원리와도 맞닿아 있다. 관심사의 분리(Separation of Concerns). 오케스트레이터는 “무엇을 할지"를 결정하고, ACP는 “어떻게 연결할지"를 처리하고, 개별 에이전트는 “실제로 어떻게 할지"를 담당한다.

MCP가 “모델의 능력을 확장"했다면, ACP는 “에이전트의 협업을 가능하게 한다.”

MCP 덕분에 LLM이 웹을 검색하고 파일을 읽고 코드를 실행할 수 있게 됐다. 그 다음 단계는 이렇게 능력이 확장된 에이전트들이 서로 협업하는 것이다. ACP는 그 레이어다. MCP가 “도구 생태계"를 만들었다면, ACP는 “에이전트 생태계"를 만드는 프로토콜이다.

HTTP → REST → 웹 생태계의 폭발적 성장. 이것이 MCP → ACP → 에이전트 생태계로 이어지는 흐름과 닮아 있다.

마무리: 만들지 말고, 연결하라

AI 에이전트를 처음 접하면 “직접 만들고 싶다"는 욕구가 생긴다. 내가 원하는 대로 동작하는 에이전트를 코드로 정의하고, 모든 것을 제어하고 싶다는 욕구. 이해할 수 있다. 나도 그랬다.

하지만 실무를 거치면서 깨달은 것이 있다. 이미 뛰어난 전문가들이 수년간 갈고닦은 에이전트를 “내 방식으로 다시 만들려는 시도"는, 비용과 시간 대비 효과가 극히 낮다.

HTTP가 웹을 통일한 것처럼, ACP는 에이전트 오케스트레이션의 표준이 될 수 있다. 지금은 아직 초기지만, 방향은 명확하다. 에이전트를 만드는 시대에서, 에이전트를 연결하는 시대로.

설정 파일 몇 줄로 Claude Code, Codex, OpenCode를 오케스트레이션하는 것을 처음 경험했을 때의 그 느낌이 아직도 생생하다. “이게 이렇게 쉬운 거였어?” 라는 느낌. 그 간결함이 곧 올바른 추상화의 증거다.

복잡한 것을 복잡하게 만드는 건 쉽다. 복잡한 것을 단순하게 만드는 게 진짜 엔지니어링이다.

이 글의 실전 사례는 OpenClaw ACP 런타임을 기반으로 합니다. ACP 공식 문서와 실험 결과는 별도 포스트로 정리할 예정입니다.