OpenClaw + Claude Code/Codex：개인 개발 에이전트 스웜 만들기

안녕하세요, 저는 루공입니다.

최근 X에서 한 트윗을 보았는데, 순간적으로 저를 사로잡았습니다. Elvis라는 독립 개발자가 현재 Claude Code와 Codex를 직접 사용하지 않고 OpenClaw를 조정 레이어로 사용하여 Zoe라는 AI 조정기가 Claude Code와 Codex의 전체 에이전트 스웜을 관리하고 있다고 말했습니다.

이 트윗의 데이터도 매우 놀라웠습니다. 490만 조회수, 1.1만 좋아요, 1800회 리트윗.

우리는 Vibe Coding을 4개월 넘게 운영해왔고, Claude Code는 항상 주요 도구였습니다. 이전에도 여러 에이전트 협업, VSCode 다중 에이전트 아키텍처 등에 관한 글을 쓴 적이 있습니다.

하지만 Elvis의 이 방식은 정말 전문가라고 부를 수밖에 없었습니다. 한 사람이 조정 시스템 하나로 하루 평균 50회 코드 제출을 하며, 가장 바쁜 날에는 94회 제출하고 3개의 고객 전화를 받았으며, 편집기를 한 번도 열지 않았습니다.

이것은 한 사람이 개발 팀처럼 일하는 것이 아닐까요?

오늘 이 글에서는 그가 어떻게 이 일을 해냈는지 분석해보겠습니다.

OpenClaw는 모두가 잘 알고 있습니다

이 작은 가재는 설날 전부터 지금까지 인기를 끌고 있습니다. 간단히 말해, 오픈 소스 AI 에이전트 프레임워크로, GitHub에서 현재 24만 개 이상의 스타를 기록하고 있으며, 이틀 전에는 React를 초월하여 GitHub 역사상 스타 증가가 가장 빠른 오픈 소스 프로젝트가 되었습니다.

창립자 Peter Steinberger는 오스트리아 개발자로, 이전에 PSPDFKit(한 PDF 프레임워크의 B2B 회사)를 창립했으며, 2021년에 Insight Partners로부터 1억 유로의 투자를 받았습니다. 올해 2월 Peter는 OpenAI에 합류한다고 발표했으며, OpenClaw 프로젝트는 오픈 소스 재단에 운영을 이관했습니다.

OpenClaw의 위치는 채팅봇이 아니라, 로컬 장치에서 실행되는 AI 에이전트 런타임입니다. 네 가지 핵심 구성 요소가 있습니다: Gateway(게이트웨이, 50개 이상의 메시지 플랫폼 연결), Agent(추론 엔진), Skills(5400개 이상의 플러그인), Memory(기억 시스템).

하지만 Elvis는 OpenClaw를 사용하는 방식이 특별합니다. 그는 이를 조정 레이어로 사용하여 Claude Code와 Codex와 같은 코딩 에이전트를 관리하는 데만 사용하고, 일반 보조 도구로 사용하지 않았습니다.

이 아이디어는 정말 독특합니다.

왜 조정 레이어가 필요할까요?

Elvis는 트윗에서 매우 중요한 관점을 제시했습니다: 맥락 창은 제로섬 게임입니다.

코드를 넣으면 비즈니스 맥락을 담을 공간이 없어집니다. 고객 이력과 회의 기록을 넣으면 코드베이스를 담을 공간이 없어집니다. 단일 AI가 아무리 강력하더라도, 두 가지 완전히 다른 유형의 정보를 동시에 담을 수는 없습니다.

그래서 그는 시스템을 두 개의 레이어로 나누었습니다.

상위 레이어는 OpenClaw의 조정기 Zoe로, 그녀는 모든 비즈니스 맥락을 파악하고 있습니다. 고객 데이터, 회의 기록, 역사적 결정, 어떤 솔루션이 시도되었고 어떤 것이 실패했는지 등의 정보가 Elvis의 Obsidian 노트 라이브러리에 저장되어 있으며, Zoe는 이를 직접 읽을 수 있습니다.

하위 레이어는 Claude Code와 Codex와 같은 코딩 에이전트로, 이들은 코드만 보고 코드 작성만 합니다. 각 에이전트가 시작될 때, Zoe는 비즈니스 맥락에 따라 정확한 프롬프트를 작성하여 그들에게 무엇을 해야 하는지, 배경이 무엇인지, 고객이 원하는 것이 무엇인지 알려줍니다.

간단히 말하면: 조정기는 요구 사항을 이해하고, 코딩 에이전트는 작업을 수행합니다. 각자 잘하는 일을 합니다.

이 아키텍처는 Stripe가 최근 공개한 내부 시스템 Minions과 유사합니다. Stripe의 Minions도 병렬 코딩 에이전트와 중앙 집중식 조정 레이어의 설계로, 매주 AI가 작성한 1000개 이상의 PR을 병합할 수 있습니다. Elvis는 우연히 비슷한 아키텍처를 구축했다고 말했으며, 단지 자신의 Mac mini에서 실행되고 있을 뿐입니다.

실제 사례 작업 흐름

Elvis는 트윗에서 실제 사례를 사용하여 그의 전체 작업 흐름을 설명했으며, 저는 핵심 단계를 간단히 정리해보겠습니다.그는 고객 전화를 받았고, 고객은 팀 내부에서 기존 구성을 재사용하고 싶어 했다. 통화가 끝난 후, 그는 Zoe와 이 요구 사항에 대해 이야기했다. 모든 회의 기록이 자동으로 Obsidian에 동기화되기 때문에, Zoe는 고객이 말한 내용을 이미 알고 있었고, Elvis가 추가로 설명할 필요가 없었다. 그들은 함께 기능 범위를 확정했으며, 최종方案은 템플릿 시스템을 만드는 것이었다.

그 후 Zoe는 자동으로 세 가지 일을 했다: 고객에게 서비스 잠금을 해제하기 위해 충전(그녀는 관리자 API 권한이 있다), 생산 데이터베이스에서 고객의 기존 구성을 가져오기(읽기 전용 권한, 인코딩 에이전트는 이 권한을 절대 가지지 않는다), 그리고 전체 비즈니스 컨텍스트를 포함한 상세 프롬프트를 가진 Codex Agent를 생성했다.

각 에이전트는 독립적인 worktree(격리된 브랜치)와 tmux 세션을 가지고 있다. 시작 명령은 대략 다음과 같다:

# Create worktree + spawn agent git worktree add ../feat-custom-templates -b feat/custom-templates origin/main cd ../feat-custom-templates && pnpm install tmux new-session -d -s "codex-templates" \ -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \ "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high 에이전트가 실행된 후, 10분마다 점검하는 정기 작업이 있다. 그러나 그것은 에이전트에게 직접 질문하지 않고(그렇게 하면 토큰을 너무 많이 소모하기 때문에), 결정론적 Shell 스크립트를 실행하여 tmux 세션이 여전히 살아 있는지, PR이 생성되었는지, CI가 통과했는지를 확인한다.

만약 CI가 실패하면, 에이전트를 자동으로 재시작하고 최대 3번 재시도한다. 수동 개입이 필요할 때만 알림을 보낸다.

에이전트가 작업을 완료하면 자동으로 PR을 생성한다. 그러나 PR을 생성하는 것만으로는 끝나지 않으며, Elvis는 완료 기준을 정의했다: PR 생성, 브랜치가 main에 동기화(병합 충돌 없음), CI가 모두 통과, 세 개의 AI 모델의 코드 검토가 모두 통과, UI 변경이 있을 경우 스크린샷을 첨부해야 한다.

세 개의 AI 모델로 코드 검토

세 개의 AI 모델로 코드 검토를 하는 것은 매우 안정적으로 보인다. 그는 이 세 모델에 대한 평가를 이야기하며, 꽤 흥미롭다.

Codex Reviewer, 그는 가장 높은 평가를 주었으며, 경계 상황과 논리 오류에 대한 검토가 매우 철저하고 오탐률이 낮다고 말했다.

Gemini Code Assist Reviewer, 무료로 제공되며, 그는 매우 유용하다고 말하며, 다른 모델이 놓친 보안 취약점과 확장성 문제를 발견할 수 있고, 구체적인 수정 방안을 제시할 수 있다고 말했다.

Claude Code Reviewer, 그의 원래 말은 "기본적으로 쓸모가 없다"였으며, 그는 그것이 지나치게 조심스럽고, "추가하는 것을 고려해보세요..."와 같은 제안으로 가득 차 있다고 말했다. 대부분은 과도한 설계에 해당하며, 중요한 문제로 표시되지 않는 한 그는 직접 건너뛴다.

이 부분을 읽었을 때 나는 약간 놀랐다. Claude Code의 중증 사용자로서, 나는 코드 검토 시 지나치게 보수적인 상황을 경험한 적이 있지만, "기본적으로 쓸모가 없다"는 평가는 다소 과한 것 같다. 그러나 이것은 또한 다중 모델 교차 검토가 실제로 가치가 있다는 것을 측면적으로 보여주며, 서로 다른 모델의 편견이 서로 보완된다.

세 개의 검토가 모두 통과한 후에야 Elvis는 Telegram 알림을 받는다. 이 단계에서는 주로 스크린샷을 확인하여 UI 변경이 올바른지 확인하며, 많은 PR은 코드를 보지 않고 바로 병합한다고 말했다. 그는 자신의 수동 검토가 5분에서 10분 정도 걸린다고 말했다.

Zoe의 능동성

Zoe는 단순한 실행자가 아니다. 작업 흐름 자체보다 더 흥미로운 것은 Zoe의 능동성이다.

Elvis는 Zoe가 작업 할당을 기다리지 않고, 스스로 일을 찾는다고 말했다. 아침에 Sentry의 오류 로그를 스캔하여 4개의 새로운 오류를 발견하고, 자동으로 4개의 에이전트를 생성하여 수정한다. 회의가 끝난 후 회의 기록을 스캔하여 고객이 언급한 3개의 기능 요구 사항을 표시하고, 자동으로 3개의 Codex Agent를 시작한다. 저녁에 Git 로그를 스캔하여 Claude Code를 시작하고 changelog와 고객 문서를 업데이트한다.

Elvis가 밖에 나가서 산책하고 돌아오면, Telegram에 7개의 PR이 준비되었다는 메시지가 와 있다. 3개의 새로운 기능과 4개의 버그 수정이 포함되어 있다. 이것이 바로 내가 항상 기대했던 OPC 1인 회사 개발 팀의 효과가 아닌가.그리고 Agent가 실패했을 때, Zoe의 처리 방식은 단순 재시도보다 훨씬 고급스럽습니다. 그것은 비즈니스 맥락을 결합하여 실패 원인을 분석합니다. Agent의 맥락이 폭발했나요? 그러면 범위를 좁혀 Agent가 세 개의 파일에만 집중하도록 합니다. Agent의 방향이 틀어졌나요? 그것도 수정하여 Agent에게 고객이 원하는 것은 X가 아니라 Y라고 말하고 회의 중의 원문을 첨부합니다.

시간이 지남에 따라 Zoe는 경험을 축적하고 어떤 prompt 구조가 어떤 유형의 작업에 효과적인지 기억하여 다음에 더 정확한 prompt를 작성합니다.

이 생각은 사실 Ralph Loop의 업그레이드 버전입니다. Ralph Loop의 핵심 논리는 맥락을 끌어오고, 출력을 생성하고, 결과를 평가하고, 경험을 저장하는 순환이지만, 대부분의 구현은 매번 순환의 prompt가 고정되어 있습니다. Elvis의 시스템은 다릅니다. 매번 재시도할 때 Zoe는 실패 원인에 따라 prompt를 동적으로 조정하며, 완전한 비즈니스 맥락이 뒷받침됩니다.

비용과 하드웨어

비용 측면에서 Elvis가 공개한 데이터는 Claude가 매달 약 100달러, Codex가 매달 약 90달러라는 것입니다. 그는 또한 시작은 20달러부터 시도해볼 수 있다고 말했습니다.

이 비용은 개발자를 고용하는 것과 비교하면 당연히 터무니없이 저렴합니다. 그러나 제품 결정, 고객 소통, 코드 검토를 직접 해야 한다고 생각하면, 이는 효율성 증폭기와 같아 코딩과 테스트와 같은 반복적인 작업을 줄여줍니다.

하드웨어 측면에서 Elvis는 현재 가장 큰 병목 현상이 RAM이라고 언급했습니다. 각 Agent는 독립적인 worktree가 필요하고, 각 worktree는 자신의 node_modules를 가지고 있으며, 각 Agent는 빌드, 타입 검사 및 테스트를 실행해야 합니다. 5개의 Agent가 동시에 실행되면 5개의 병렬 TypeScript 컴파일러, 5개의 테스트 실행기, 5세트의 종속 항목이 필요합니다.

그의 Mac mini 16GB 메모리는 최대 4~5개의 Agent를 동시에 실행할 수 있으며, 그 이상은 메모리 스와핑이 시작됩니다. 그래서 그는 128GB 메모리의 Mac Studio M4 Max(3500달러)를 구입하여 더 많은 Agent의 동시 실행을 처리할 계획입니다.

요약 및 현실 문제

솔직히 Elvis의 이 시스템은 저에게 상당한 충격을 주었습니다. 저는 이전에 OpenClaw를 장난감처럼 다루고 있었고, 생산성 측면에서는 독립적인 Claude Code에 의존하고 있었습니다. 가끔 worktree를 사용하여 병렬 처리를 하긴 했지만, 이런 시스템화된 편성의 수준에는 미치지 못했습니다. 그의 트윗을 보고 나니 AI 프로그래밍의 한계가 다시 한 번 높아졌다는 생각이 듭니다.

최근 저는 그의 생각을 따라 OpenClaw를 사용하여 완전 자동화된 1인 개발 팀을 만들 계획입니다. 그래서 최근에 우리는 OpenClaw의 실천에 관한 여러 기사를 발표할 예정입니다.

몇 가지 현실적인 문제를 여러분에게 알려드려야 합니다.

이 시스템의 전제는 명확한 제품, 명확한 고객 요구 사항, 완벽한 CI/CD 파이프라인이 있어야 한다는 것입니다. Elvis는 실제 B2B SaaS 제품을 만들고 있으며, 고객이 있고, 수익이 있으며, 생산 환경이 있습니다. 만약 여러분이 아직 데모를 작성하거나 학습 단계에 있다면, 이 아키텍처의 ROI는 그리 합리적이지 않을 수 있습니다.

또한, 현재 OpenClaw의 보안 문제도 주의해야 합니다. 공개된 정보에 따르면, 여러 개의 고위험 CVE가 공개되었고, 341개의 악성 커뮤니티 플러그인이 데이터 도용 행위를 발견했습니다. OpenClaw를 배포할 때는 격리 및 권한 제어를 철저히 해야 합니다. 이것이 제가 OpenClaw를 본 주력 기계에 배포하지 않은 이유이기도 합니다.

또한, Elvis는 트윗에서 Claude Code의 코드 검토에 대한 평가가 낮지만, 최근 Claude Code는 Agent Teams 기능(공식 내장 다중 Agent 협업)을 출시했으며, Anthropic도 편성 방향으로 힘을 쏟고 있습니다.

하지만 이러한 세부 사항을 제외하고, Elvis의 이 편성 계층과 실행 계층의 아키텍처 사고는 확실히 주목할 만합니다. 맥락 창의 제로섬 게임은 실제로 존재하는 제약이며, 계층 구조를 사용하여 이 문제를 해결하고 서로 다른 AI가 각자의 역할을 수행하도록 하는 방향은 개인적으로 옳다고 생각합니다.