Scaling Agents on Kubernetes with ACPX and ACP
📺 원본 영상: Scaling Agents on Kubernetes with acpx and ACP — Onur Solmaz, OpenClaw 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-05-22 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
이 강연은 TextCortex의 파운딩 엔지니어이자 OpenClaw 메인테이너인 Onur Solmaz가 AI Engineer 컨퍼런스에서 발표한 내용이다. 강연자는 Kubernetes 환경에서 AI 에이전트를 실용적으로 확장하는 방법을 두 개의 큰 축으로 나누어 설명한다. 하나는 자신이 직접 개발한 CLI 도구 ACPX를 통한 ACP(Agent Client Protocol) 기반 에이전트 워크플로우 자동화이며, 다른 하나는 Kubernetes Pod 단위로 에이전트를 동적으로 생성하고 관리하는 오픈소스 오케스트레이터 Spritz다. OpenClaw라는 거대한 오픈소스 프로젝트가 실증 무대가 되어, 하루 수백 건의 PR을 에이전트가 처리하는 현실적인 자동화 사례가 발표의 뼈대를 이룬다.
강연자 배경: ChatGPT 이전부터 시작된 코딩 하네스(Harness) 여정
Onur Solmaz는 ChatGPT가 공개되기 몇 달 전부터 AI 코딩 도구를 직접 만들어온 인물이다. 그는 초창기 OpenAI Codex 모델(DaVinci Codex 계열)을 활용한 Jupyter Lab 확장을 개발했고, 그 하네스는 이후 수없이 해체되고 재조립되며 현재의 시스템으로 진화했다. 강연자는 이를 “테세우스의 배(Ship of Theseus)“에 빗대어 설명했는데, 처음과 구성 요소는 완전히 달라졌지만 목적은 그대로 이어져 왔다는 의미다.
Claude Bot이 Discord에 처음 등장했을 때 강연자는 즉시 그 가능성을 알아챘다. 다음 날 바로 회사 Kubernetes 클러스터에 설치했고, 구성원들의 반응은 폭발적이었다고 한다. 이미 엔터프라이즈 영업 환경에서 수년간 일해온 경험을 바탕으로 MS Teams 통합을 먼저 추가하는 실용적인 판단을 내렸으며, 그 과정에서 OpenClaw 프로젝트의 메인테이너가 되었다. 그의 주된 관심사는 에이전트 상호운용성(agent interoperability)과 오케스트레이션이며, 궁극적으로 엔터프라이즈 환경에서의 OpenClaw 채택을 가속화하는 것이 목표다.
Discord 기반 개발 환경: 이동 중에도 병렬 작업을
강연자가 “Discord-driven Development”라고 이름 붙인 워크플로우는 Discord 채널을 사실상의 코딩 IDE처럼 활용하는 방식이다. 그는 “TDD”라는 약어를 살리기 위해 Telegram-driven Development라고도 부른다고 농담처럼 언급했다. 초기에는 Claude(Opus)가 Codex에게 무언가를 전달하도록 지시하는 “전화 게임”식 방식으로 작업했는데, 프롬프팅에서 표현 하나하나가 중요한데도 중간에 다른 AI를 거치다 보니 의미가 희석되는 문제가 있었다. 그럼에도 어느 정도 동작하긴 했고, 강연자는 이것이 훨씬 더 나은 방식으로 자동화될 수 있음을 확신했다.
현재는 Discord 내에 다섯 개의 채널에서 각각 다른 Codex 에이전트 인스턴스가 병렬로 동작하는 환경을 구축했다.
03:58 - Discord 채널 구성 화면 — Codex 1~5번 에이전트 채널과 Claude ACP 테스트 채널이 나열된 Discord 사이드바
이 구성의 가장 큰 강점은 “이동 중 코딩”을 가능하게 한다는 점이다. ACP 문서를 비행기 탑승 전에 PDF로 변환해달라고 에이전트에게 Discord로 요청하고, 완성된 파일을 다른 채널로 받는 식이다. 강연자는 도구를 완벽하게 다듬을 시간이 없는 개발자로서 이 방식의 장단점을 정확히 파악하면서도 적극 활용하고 있으며, ACPX 자체도 이 Discord 기반 환경에서 개발되었다고 밝혔다.
ACP란 무엇인가: MCP와의 결정적 차이
강연에서 가장 중요한 개념적 구분은 MCP(Model Context Protocol)와 ACP(Agent Client Protocol)의 역할 차이다. 많은 사람들이 ACP를 MCP와 유사한 것으로 오해하지만, 강연자는 이 둘이 서로 다른 문제를 해결하는 프로토콜임을 명확히 짚었다.
MCP는 모델에게 도구(tool)를 제공하기 위한 프로토콜이다. 반면 ACP는 에이전트와 클라이언트(사람 또는 다른 시스템) 간의 상호작용 인터페이스를 표준화하는 프로토콜이다. ACP는 Rust로 작성된 저메모리·비-Electron(Non-Electron) 에디터 Zed 팀이 개발을 주도했는데, 그 문제의식이 선명하다. VS Code용 Claude Code 플러그인, Codex 플러그인, 각종 AI 에이전트 플러그인들이 제각각 독립적으로 구현되면서 중복 작업이 엄청나게 발생하고 있다는 것이다. ACP로 이 인터페이스를 단일 표준으로 만들면 한 번 구현으로 어떤 에이전트도 지원할 수 있다.
에이전트 관련 프로토콜 생태계는 현재 세 가지 경쟁하는 표준으로 구성된다. 에이전트 간 통신(agent-to-agent)을 위한 Agent Protocol, 사람과 에이전트 간 상호작용을 표준화하는 ACP, 그리고 모델에게 도구를 제공하는 MCP가 그것이다. ACP는 원칙적으로 사람과 에이전트 간의 통신을 위한 것이지만, 에이전트가 이 인터페이스를 통해 다른 에이전트를 호출하는 것도 가능하다. 강연자가 ACP를 선택한 이유는 실용적이었다. 당시 Codex와 Claude Code 어댑터를 구현해둔 곳이 Zed밖에 없었기 때문이다. 장기적으로는 모든 프로토콜을 지원하겠지만, 필요한 시점에 구현이 존재하는 것을 선택했다고 설명했다.
ACPX: ACP를 위한 스위스 아미 나이프
OpenClaw에서는 새 기능을 추가할 때 CLI를 통해 작업하는 것이 일반적인 패턴이다. 강연자는 이에 착안해서 ACP를 위한 전용 CLI를 만들기로 했고, 커맨드 라인에서 어떤 에이전트든 호출할 수 있는 도구로 시작했다. 이것이 ACPX의 출발점이었으며, 이후 점차 “ACP를 위한 스위스 아미 나이프”로 발전했다. 강연자가 ACPX를 Discord를 통해 직접 개발했다는 사실 자체가, 이 도구의 실용성을 잘 보여주는 사례이기도 하다.
ACPX의 핵심 기능은 DAG(Directed Acyclic Graph, 방향성 비순환 그래프) 방식의 워크플로우 엔진이다. 이 엔진은 Codex 세션을 구동하면서 JSON 구조화 데이터를 주고받는 방식으로 동작한다. 단순한 에이전트 실행 래퍼가 아니라, 여러 단계의 작업을 프로그래밍 방식으로 조합하고 조건 분기까지 처리하는 일반 목적 워크플로우 엔진이다. 강연자는 이 엔진이 에이전트로 해결할 수 있는 어떤 문제에도 “연고처럼 아낌없이 바를 수 있는(apply generously)” 도구라고 비유하며, PR 리뷰 자동화를 시작으로 다양한 용도로 확장할 수 있음을 강조했다.
11:49 - ACPX 워크플로우 엔진 데모 화면 — PR 하나가 버그 재현 → 리팩터 판단 → 리뷰 루프 단계로 처리되는 과정
PR 리뷰 자동화: 에이전트로 에이전트를 자동화하다
OpenClaw는 누적 PR이 6만 건을 넘어섰으며, 하루 평균 300~500건의 신규 PR이 쏟아진다.
07:40 - OpenClaw PR 통계 시각화 — 총 60K+ 누적 PR, 일일 300~500건 처리량 관련 수치 슬라이드
이 규모에서 PR을 사람이 일일이 검토하는 것은 현실적으로 불가능하다. 더 근본적인 문제는 대부분의 PR이 AI가 생성한 설명을 달고 오는 탓에, 실제 의도를 파악하는 것 자체가 어렵다는 점이다. 강연자는 AI가 제출한 PR을 무조건 버릴 수도 없다고 강조했다. 그것이 잘못된 수정이더라도, 어딘가 코드가 깨져 있다는 현장 피드백 자체는 소중한 데이터이기 때문이다. 즉, PR 하나하나를 분류하고 범주화하는 작업이 반드시 필요하다.
강연자는 PR을 받아볼 때마다 AI 코딩 어시스턴트에게 “이게 무엇을 하는가”, “이것이 최선의 수정인가”를 물어보는 과정을 반복하다가, 이 작업 자체를 자동화할 수 있음을 깨달았다. 그 결과물이 ACPX에 내장된 PR 처리 워크플로우다. 이 워크플로우는 PR 의도 파악 → 구현 방식 판단 → 충돌(conflict) 여부 확인 → 리뷰 루프 실행 → CI 통과 여부 확인 및 수정의 순서로 진행된다.
강연자는 특히 “review-refactor 루프”에 대해 흥미로운 입장을 밝혔다. 에이전트를 반복 실행하면 반드시 AI 슬롭(AI slop, 품질이 낮은 AI 생성물)이 생긴다는 통념을 정면으로 반박한 것이다. 핵심 설계 결정을 에이전트에게 맡기는 것이 아니라, 표면적인 버그를 탐지하고 쉽게 고칠 수 있는 것만 처리하도록 범위를 명확히 제한하면, 반복 루프가 품질 저하 없이 기계적 작업을 효율적으로 처리하는 도구가 된다고 주장했다. 충돌 해소도 마찬가지다. 과거에는 손으로 직접 해결해야 했지만, 현재 에이전트 수준에서는 충분히 자동화 가능한 작업이 되었다. 강연자는 이 일련의 작업을 “에이전트를 위한 표준 운영 절차(Standard Operating Procedure, SOP) 만들기”라고 정의했다.
엔터프라이즈 에이전트의 미래: 온디맨드 일회용 에이전트
강연자는 개인용 에이전트와 엔터프라이즈 에이전트 사이에 구조적인 차이가 생길 것이라고 전망했다. 개인 PC와 업무용 PC는 역사적으로 사용 패턴이 크게 다르지 않았지만, 에이전트 시대에는 엔터프라이즈에서 훨씬 많은 추론(inference) 연산을 소비하게 될 것이고, 이는 엔터프라이즈 AI 시장의 경제적 규모가 개인 시장을 압도할 것임을 의미한다.
이 비전을 실현하기 위한 핵심 개념이 “온디맨드 일회용 에이전트(on-demand disposable agents)“다. 현재 Slack이나 Teams에서 에이전트를 추가하려면 에이전트 하나당 별도의 앱을 만들고 앱 매니페스트를 수동으로 관리해야 한다. 강연자는 이것이 근본적으로 잘못된 UX(User Experience)라고 지적했다. 이상적인 미래는 마치 ChatGPT의 “GPTs” 개념처럼, 하나의 기반 시스템이 여러 에이전트를 동적으로 프로비저닝하고, 각 에이전트가 고유한 이름과 프로필 이미지를 가지며 독립된 채널에서 대화를 나눌 수 있는 구조다.
13:57 - 온디맨드 멀티 에이전트 UI 개념도 — ChatGPT로 생성한 에이전트 목록 동적 프로비저닝 목업 화면
그러나 Slack, Teams 같은 채팅 플랫폼이 아직 이런 멀티 에이전트 동적 프로비저닝 표준을 지원하지 않기 때문에, 강연자는 자체 UI를 구축해 이 비전을 현실화하고 있다. 이 아키텍처가 제대로 동작하려면 몇 가지 핵심 컴포넌트가 필요한데, Kubernetes 클러스터, 에이전트 하네스(Claude Code, Codex 등), ACP 기반 통신, GitHub 읽기/쓰기 접근 권한, 그리고 rsync 혹은 Dropbox 유사 알고리즘 기반의 상태 및 파일 동기화가 그것이다. 여러 에이전트가 동시에 파일을 생성하고 수정하면, 그 변경 사항이 모든 인스턴스에 일관되게 동기화되어야 하기 때문이다.
TextCortex Spritz: Kubernetes 기반 에이전트 오케스트레이터
강연의 후반부는 강연자의 본업인 TextCortex에서 개발 중인 오픈소스 프로젝트 Spritz(저장소: textcortex/spritz)를 소개한다. Spritz는 Kubernetes 오퍼레이터(operator) 방식으로 동작하는 에이전트 오케스트레이터로, 각 에이전트를 독립적인 Kubernetes Pod로 실행하는 것이 핵심 설계 철학이다.
자원 효율 측면에서는 낭비처럼 보일 수 있지만, 강연자는 “에이전트에게 완전한 컴퓨터를 주면 훨씬 더 강력해진다”는 OpenClaw의 철학과 같은 맥락이라고 설명했다. OpenHands 같은 프로젝트는 Firecracker 마이크로 VM 기반 가상화를 선택하는 등 각 프로젝트가 다른 가상화 전략을 택하고 있으며, Spritz는 Kubernetes Pod를 추상화 단위로 선택했다. 강연자는 아직 모든 가상화 프레임워크에 정통하지는 않지만, 동작하는 제품을 Kubernetes 위에서 실행하고 있다는 점을 강조했다.
16:09 - Spritz 시스템 Slack 데모 — 프로덕션 버그 발생 후 에이전트 디스패치를 요청하는 Slack 대화 화면
16:45 - Kubernetes Pod 기반 에이전트 작업 화면 — React UI에서 에이전트가 실시간으로 문제를 해결해 나가는 인터페이스
실제 사용 사례로는 에러 리포팅 자동화가 소개되었다. Slack에서 프로덕션 배포 후 새 버그가 발생하면, 슬랙봇에게 에이전트를 디스패치해 디버깅하도록 요청하는 방식이다. Helm 차트로 클러스터에 배포하며, 동일 클러스터에 React 기반 UI가 함께 호스팅된다. 이 UI는 Codex Web이나 Devin과 유사한 인터페이스로, 에이전트가 문제를 해결해 나가는 과정을 실시간으로 확인할 수 있다. ACP를 통해 에이전트를 추상화하기 때문에 특정 에이전트(Codex, Claude Code 등)에 종속되지 않는다는 점이 핵심 설계 원칙이며, 강연자는 이것을 “어떤 에이전트도 쉽게 교체할 수 있는 상호운용성(interoperability)“이라고 표현했다.
마무리 / 핵심 정리
Onur Solmaz의 발표는 AI 에이전트를 개인 실험 수준에서 엔터프라이즈 운영 수준으로 끌어올리는 현실적인 경로를 제시한다. 에이전트 반복 루프를 범위 제한을 통해 품질 저하 없이 활용하고, ACP라는 개방 표준으로 에이전트 간 상호운용성을 확보하며, Kubernetes Pod 단위의 일회용 에이전트로 확장성을 달성하는 세 가지 아이디어가 이 강연의 핵심이다.
특히 주목할 만한 점은 이 모든 것이 오픈소스 생태계 안에서 작동한다는 사실이다. Claude Code, Codex, ACP, OpenClaw, Spritz 모두 오픈소스이거나 오픈 표준이며, 특정 벤더에 종속되지 않는 아키텍처를 지향한다. 하루 300~500건의 PR을 처리해야 하는 OpenClaw라는 거대한 오픈소스 프로젝트가 실증 무대가 되어, 이 아키텍처의 실효성을 살아있는 형태로 검증하고 있다는 점이 설득력을 더한다. 에이전트 시대의 개발자 경험(Developer Experience)이 어떻게 재설계되어야 하는지를 직접 손으로 만들며 답을 찾아가는 강연자의 접근 방식은, 이론보다 현장에서 나온 인사이트로서의 가치가 크다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Scaling Agents on Kubernetes with acpx and ACP — Onur Solmaz, OpenClaw |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-05-22 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.
Related Reports
- 요즘 가장 핫한 AI툴 Buzz, 클로드코드·코덱스를 한 팀으로 쓰는 법!
- Lobster Trap - OpenClaw in Containers from Local to K8s and Back — Sally Ann O’Malley, Red Hat
- Skills are the New SDKs - Elvin Aghammadzada, DataRobot
- AI 잘 쓰는 사람들은 왜 까만창을 켤까? Codex·Claude Code·Gemini CLI | 버튼 없는 까만창이 더 많은 일을 할 수 있는 이유
- How this OpenAI engineer uses Codex + ChatGPT Work to automate everything