AgentConnect: Claude Code, Codex와 팀원이 같은 스레드에서 일하는 오픈소스 멀티 에이전트 플랫폼

해결하려는 문제

AgentConnect는 Apache-2.0 라이선스로 공개된 오픈소스 플랫폼입니다. 사람과 여러 AI 에이전트가 팀이 이미 쓰고 있는 대화와 워크플로 안에서 함께 일하도록 만드는 것이 목표입니다. README는 첫머리에서 스스로를 "Claude Tag의 오픈소스 멀티 에이전트 대안"이라고 소개하고, 구호는 "@ any agent"입니다. 일이 벌어지는 곳 어디서나 에이전트가 팀과 서로 나란히 일하며 계속 배운다는 뜻입니다.

배경에는 익숙한 문제가 있습니다. 대부분의 코딩 에이전트는 여전히 한 사람의 터미널 안에서만 도는 개인 도구입니다. 동료는 에이전트가 무엇을 하는지 볼 수 없고, 세션을 넘겨받을 수 없으며, 결과물을 검토할 수 없습니다. 에이전트가 쌓은 컨텍스트도 노트북 한 대에 머뭅니다. 그래서 모든 팀이 메시지 채널, cron 작업, 자격 증명 처리, 컨텍스트 연결 같은 똑같은 접착 코드를 다시 작성합니다. AgentConnect는 이 접착 계층을 플랫폼으로 만들겠다는 제안입니다.

핵심 아키텍처: 세 구성요소와 두 평면

README의 아키텍처 설명에 따르면 구성요소는 세 가지입니다. 첫째는 Daemon입니다. 자신이 소유한 ACP(Agent Client Protocol) 연결 위에서 배치된 에이전트를 실행합니다. 작업 공간과 세션 상태를 관리하고, 각 채팅 플랫폼과의 직접 연결과 스케줄을 유지하며, 모델 제공자로 가는 트래픽도 직접 보냅니다. 둘째는 선택 사항인 Relay입니다. 콜백 방식의 수신과 웹 채팅을 받고, 중앙에서 관리되는 MCP와 OpenConnector 접근을 중계하며, 메시지를 담당 Daemon으로 곧바로 전달합니다. 영구 저장은 하지 않습니다. 셋째는 Control Plane과 Web UI입니다. 인증, 설정, 배치, 권한, 메타데이터, 관측 가능성을 맡습니다. 명시적으로 승인된 조직 지식과 스킬 개정본은 저장하고, 그 밖에는 필요할 때 Daemon에 대한 제한된 읽기를 중계합니다.

핵심 설계는 데이터 평면과 제어 평면의 분리입니다. 실시간 플랫폼 메시지와 ACP 업데이트 스트림은 Daemon과 Relay 경로에만 머뭅니다. 승인된 조직 지식과 크기가 제한된 스킬 번들을 제외하면, Control Plane은 조정용 메타데이터만 저장합니다. 메시지 본문, 첨부 파일, 대기 중인 Dream 제안, ACP 세션 스트림은 저장하지 않습니다. README는 장애 시 동작도 분명히 적습니다. Control Plane이 잠시 불가용해도 이미 맺어진 세션과 Daemon 로컬 스케줄은 계속 동작하고, 새 할당과 설정 변경만 재연결 뒤에 재개됩니다. 현실적인 장애 모델입니다.

기술 포인트 1: ACP를 통한 런타임 중립

AgentConnect는 특정 에이전트 런타임에 묶이지 않습니다. Claude Code, Codex, Grok Build, DeepSeek, Pi, 그리고 ACP 호환 런타임이 나란히 동작합니다. 에이전트마다 런타임, 모델, 작업 공간, 도구, 실행 머신을 따로 설정할 수 있습니다. README에 따르면 하나를 바꿔도 그 주변 워크플로를 다시 만들 필요가 없습니다.

ACP는 공용 콘센트 역할을 합니다. Daemon이 모든 에이전트와 같은 프로토콜로 대화하므로, 라우팅, 권한, 기억 같은 상위 계층을 도구마다 따로 만들 필요가 없습니다. 이미 여러 코딩 에이전트를 함께 쓰는 팀이라면 도구마다 채팅 봇을 따로 연결하는 것보다 유지보수가 쉽습니다.

기술 포인트 2: Decisions와 Jev 라우팅

두 번째 주목할 장치는 Jev(TypeSafe)가 구동하는 재사용 가능한 Decisions입니다. 에이전트가 언제 응답할지, 새 대화를 어느 전문 에이전트에게 넘길지, 새 세션에 어떤 런타임과 모델을 쓸지를 결정합니다.

README는 두 가지 사례를 듭니다. 지원 문의 분류에서는 Jev가 새 문의를 알맞은 전문가에게 보내고, 사람과 에이전트가 한 스레드에서 조사하며, 수정과 검증 과정이 처음부터 끝까지 보입니다. 맞춤형 코드 리뷰에서는 새 GitHub 풀 리퀘스트마다 Jev가 리뷰어를 고르고 리뷰 세션마다 런타임과 모델을 고릅니다. 일반, 아키텍처, 보안 리뷰어는 각자 지침, 저장소 접근 권한, 도구, 샌드박스 정책을 가질 수 있습니다.

결과적으로 "누가 하는가"와 "무엇으로 하는가" 사이에 설정 가능한 정책 계층이 생기며, 규칙이 봇 스크립트 안에 묻히지 않습니다.

기억, 지식, 경계

각 에이전트는 자기 기억과 스킬을 가집니다. 검토를 거친 Knowledge를 게시하면 모든 에이전트가 필요할 때 찾아 쓸 수 있고, 배포 가이드에는 선택 사항인 Mem0 설정도 나옵니다. 경계 측면에서는 각 에이전트와 세션을 누가 볼 수 있는지, 어떤 저장소와 도구를 쓸 수 있는지, 어떤 다른 에이전트를 호출할 수 있는지를 정할 수 있습니다. 작업은 메시지, 이슈, 풀 리퀘스트, 웹훅, 스케줄에서 시작할 수 있습니다.

배포 방법

셀프 호스팅 경로는 두 가지입니다. 가장 빠른 것은 Docker로, 저장소를 클론하고 docker compose up -d --pull always를 실행하면 웹 콘솔, Control Plane, Relay, PostgreSQL이 시작됩니다. localhost:3000을 열어 콘솔에서 Daemon을 추가하고, 생성된 명령을 실행한 뒤 첫 에이전트를 만듭니다. 기본 스택은 127.0.0.1에서만 수신하며 평가용 로컬 무인증 모드로 동작합니다.

클러스터에는 릴리스마다 같은 버전 번호로 공식 Helm 차트가 게시됩니다(oci://ghcr.io/agentconnect-md/charts/agentconnect). 루프백 8091 포트에서 동작하는 Setup Server는 Logto 기반 브라우저 인증, GitHub, Slack, Google, Lark/Feishu 앱, 사전 설정 에이전트의 동작을 구성합니다. 저장소에는 설정 스킬도 들어 있어 Claude Code나 Codex가 대화형 튜토리얼로 설치를 안내합니다. 개발에는 Node 24.12.0 이상과 pnpm 11이 필요합니다.

생태계에 미치는 영향

개발자에게 가장 큰 가치는 에이전트를 개인 터미널에서 팀 공유 공간으로 옮길 수 있다는 점입니다. 같은 Slack 스레드에서 사람이 에이전트의 작업을 넘겨받고, 검토하고, 고칠 수 있습니다. 기업에게는 Apache-2.0과 셀프 호스팅의 조합 덕분에 에이전트 실행과 작업 공간을 직접 운영하는 환경에 둘 수 있어, 규정 준수에 민감한 팀에게 중요합니다. 여러 런타임을 병행하면 단일 모델 공급자에 대한 의존도도 낮아집니다.

한계와 열린 질문

분명히 해야 할 점이 있습니다. README에는 벤치마크, 지연 시간, 비용 수치가 없습니다. 따라서 이 글은 성능에 대한 주장을 하지 않습니다. 평가할 때 살펴볼 점은 다음과 같습니다.

첫째, 기본 스택은 인증 없는 평가 모드입니다. 운영 환경에서는 인증, 공개 URL, Linux 샌드박스 요건을 갖춰야 합니다. 둘째, 에이전트가 다른 에이전트를 호출하면 비용과 오작동의 영향 범위가 커질 수 있으므로 권한 경계와 호출 그래프를 신중히 설계해야 합니다. 셋째, Decisions는 외부 구성요소인 Jev에 의존하므로 성숙도와 대체 가능성을 따로 따져봐야 합니다. 넷째, README는 Claude Tag 자체를 자세히 설명하지 않으므로 비교는 공식 문서로 확인해야 합니다.

전망

멀티 에이전트 작업이 일상이 되면 병목은 개별 에이전트의 능력에서 라우팅, 권한, 기억, 관측 가능성 같은 조직 차원의 문제로 옮겨 갑니다. AgentConnect는 오픈소스, 셀프 호스팅, 런타임 중립이라는 형태로 이 계층에 걸고 있습니다. 표준이 될 수 있을지는 ACP 생태계의 확장 속도와, 보안과 비용 통제에 대한 모범 사례가 커뮤니티에서 자라는지에 달려 있습니다. 지금도 팀이 직접 써 보고 자기 근거로 판단할 만한 참조 구현입니다.