이 프로젝트는 라이믹스 개발 스킬까지 포함한 AI프로젝트입니다.

RBClaw 1.0.0: "Codex는 구현하고 Claude는 검토한다" 그 이후

릴리즈: 1.0.0
공개일: 2026년 8월 6일
저장소: github.com/bjrambo/RBClaw
라이선스: MIT

RBClaw 1.0.0을 공개합니다.

지난 7월에 작성한 Codex는 구현하고 Claude는 검토한다: 라이믹스 개발에 역할 분담 AI를 써본 경험에서는 Discord에서 Codex를 구현 담당으로, Claude를 검토 담당으로 나누고 두 역할이 합의하지 못할 때 별도의 중재자가 참여하는 개인 개발 환경을 소개했습니다.

당시 글이 역할 분담을 실제 라이믹스 작업에 적용해 본 초기 구조와 사용 경험에 관한 이야기였다면, 이번 글은 그 구조가 독립 프로젝트 RBClaw으로 발전한 뒤 최종적으로 어떻게 동작하는지를 소개하는 후속편입니다.

RBClaw는 Discord 채널을 개발 작업 공간으로 바꾸는 멀티에이전트 개발 보조 시스템입니다. 사용자의 요청을 받아 직접 구현하는 Owner, 결과를 독립적으로 검토하는 Reviewer, 두 역할이 합의하지 못할 때 판단을 돕는 Arbiter를 하나의 실행 흐름으로 연결합니다.

단순히 여러 AI에게 같은 질문을 보내는 도구가 아닙니다. 실제 프로젝트 디렉터리, Git 상태, 테스트 결과, 장기 작업 상태를 공유하면서도 역할별 권한을 분리해 구현과 검증이 서로 견제하도록 설계했습니다.

초기 실험에서 1.0.0까지

이전 글의 기본 아이디어는 그대로 유지했습니다. Codex와 Claude 중 어느 모델이 무조건 우월하다고 전제하지 않고, 구현자와 검토자의 역할을 분리해 서로 다른 관점으로 같은 결과를 확인한다는 원칙입니다.

다만 실제로 계속 사용하면서 단순한 역할 분담만으로는 부족한 부분이 드러났습니다. 대화가 길어졌을 때 작업 상태가 흐려지고, 서비스 재시작 후 이어갈 위치를 잃거나, Reviewer가 Owner의 설명을 그대로 믿는 문제, 같은 응답이 중복 전달되는 문제, 사용자 판단이 필요한 상황에서도 작업이 계속 도는 문제가 있었습니다.

RBClaw 1.0.0은 이런 실제 운영 문제를 하나씩 재현하고 보완한 결과입니다.

최종 동작 흐름

실제 작업은 다음 순서로 진행됩니다.

1. 사용자가 Discord에서 개발 요청을 보냅니다.
2. Owner가 채널에 연결된 프로젝트 디렉터리와 Git 상태, 로컬 작업 규칙을 먼저 확인합니다.
3. Owner가 코드를 수정하고 프로젝트에 맞는 테스트·린트·빌드 등 검증을 실행합니다.
4. Reviewer가 같은 작업 디렉터리의 diff와 파일, 검증 결과를 읽기 전용으로 다시 확인합니다.
5. 문제가 있으면 구체적인 근거와 함께 Owner에게 돌려보내고, Owner가 수정한 뒤 재검토합니다.
6. 양측 판단이 반복해서 충돌하면 Arbiter가 현재 쟁점과 증거만 받아 진행·수정·재설정·사용자 확인 중 하나를 판정합니다.
7. Reviewer가 승인하면 Owner가 사용자에게 변경 내용과 검증 결과를 최종 보고합니다.
8. 커밋, 푸시, 배포, 서비스 재시작, DB 변경 같은 고위험 작업은 승인 규칙을 통과한 경우에만 별도로 실행합니다.

Discord 사용자 요청
  -> Owner: 분석 · 구현 · 검증
  -> Reviewer: 동일 작업 디렉터리 읽기 전용 검토
     -> 문제 발견: Owner 수정 -> Reviewer 재검토
     -> 교착 지속: Arbiter 판정 또는 사용자 확인
     -> 승인: Owner 최종 보고
  -> 승인된 경우에만 커밋 · 배포 · 운영 작업

이 흐름에서 중요한 점은 AI 세 개가 무조건 매번 모두 호출되는 것이 아닙니다. Owner가 작업하고 Reviewer가 검토하는 것이 기본이며, Arbiter는 실제 교착 조건이 충족될 때만 참여합니다. 사용자 입력이나 외부 결과를 기다리는 동안에는 LLM을 반복 호출하지 않습니다.

왜 RBClaw을 만들었나

AI가 코드를 빠르게 작성해도 다음 문제는 그대로 남습니다.

• 구현 결과가 원래 요구사항과 일치하는가?
• 테스트를 실제로 실행했는가?
• 검토자가 구현자의 설명만 믿지 않고 독립적으로 확인할 수 있는가?
• 긴 작업이 중단되거나 서비스가 재시작돼도 어디서 이어야 하는가?
• 구현자와 검토자의 의견이 충돌하면 누가 어떤 근거로 정리하는가?

RBClaw은 이 문제를 역할 분리, 읽기 전용 검증, 상태 기반 실행, 중재 흐름으로 해결합니다.

1.0.0 핵심 기능

Owner / Reviewer / Arbiter Tribunal

• Owner는 사용자와 대화하고 코드를 작성하며 필요한 명령을 실행합니다.
• Reviewer는 같은 작업 디렉터리를 읽기 전용으로 확인하고 변경점, 테스트, 회귀 위험을 검토합니다.
• Arbiter는 Owner와 Reviewer의 교착이 지속될 때 양측 주장과 증거를 바탕으로 진행, 수정, 재설정 또는 사용자 확인을 판정합니다.

사용자 진입점은 Owner 하나입니다. Reviewer와 Arbiter는 필요할 때 자동으로 참여하므로, 매번 각 에이전트에게 문맥을 다시 설명할 필요가 없습니다.

사용자 요청
  -> Owner 구현
  -> Reviewer 독립 검토
     -> 승인: Owner가 결과 확정
     -> 수정 요청: Owner 수정 후 재검토
     -> 교착: Arbiter 판정 또는 사용자 확인

실제 작업 디렉터리 기반 실행

RBClaw은 채널마다 별도 복제본이나 임시 브랜치를 만들지 않습니다. 설정된 실제 workDir를 Owner와 Reviewer가 함께 기준으로 사용합니다.

• Owner는 현재 체크아웃에서 직접 작업합니다.
• Reviewer는 같은 파일을 읽기 전용으로 검증합니다.
• 동일한 실제 디렉터리를 여러 채널이 공유하면 실행 잠금으로 동시 수정을 직렬화합니다.
• Git 브랜치와 작업 트리 상태를 실행 전후에 확인해 기존 사용자 변경을 보호합니다.

Reviewer 읽기 전용 보호

Reviewer와 Arbiter는 Linux mount namespace를 이용한 읽기 전용 환경에서 실행됩니다. 구현 코드를 수정하거나 서비스 상태를 바꾸는 대신, diff와 파일, 테스트 증거를 확인하는 데 집중합니다.

방별 review_access_profile을 설정하면 승인된 웹 프로젝트에 한해 다음과 같은 원격 진단도 읽기 전용으로 수행할 수 있습니다.

• 실제 웹 페이지의 PC·모바일 렌더링 점검
• Console, Network, redirect, CORS, CSP, TLS 문제 확인
• 허용된 서비스 상태와 최근 로그 조회
• 민감한 값을 제외한 설정 구조와 환경 차이 비교

서버 주소, 서비스명, 로그 경로는 코드에 하드코딩하지 않고 비공개 profile에서 관리합니다.

Persistent Supervisor

긴 작업은 하나의 Goal 아래 여러 Episode로 나뉩니다. Owner와 Reviewer의 왕복 횟수, 중재 횟수, 진행 fingerprint를 보존해 중단과 재시작 이후에도 작업 상태를 이어갑니다.

• 사용자 입력 대기, 외부 작업 대기, 재시도 대기를 명시적으로 구분
• 대기 상태에서 LLM을 불필요하게 polling하지 않음
• lease, reservation, CAS, stable delivery key로 중복 실행과 중복 전달을 억제
• 체크리스트 기반 장기 작업 지원

역할별 모델과 장애 대응

• 방과 역할별로 agent type, model, effort를 설정할 수 있습니다.
• Codex와 Claude Code를 Owner 또는 Reviewer로 조합할 수 있습니다.
• Claude 장애 시 Codex로 넘기는 global failover를 지원합니다.
• Claude OAuth 멀티 토큰 로테이션을 지원합니다.
• 선택적으로 Kimi, GLM 등 외부 모델 의견을 Arbiter 판단에 주입하는 MoA를 사용할 수 있습니다.

Discord 중심 운영

• Owner, Reviewer, Arbiter 역할별 Discord 봇
• 채널별 single 또는 tribunal 모드
• assign_room을 통한 명시적 작업 방 등록
• 진행 메시지, 검토 결과, 사용자 확인 요청을 한 채널에서 확인
• 로컬 웹 대시보드와 Android·Voice Companion 확장 제공

누구에게 유용한가

RBClaw은 다음과 같은 환경에 적합합니다.

• AI에게 실제 저장소 작업을 맡기되 독립적인 검토 절차가 필요한 개인 개발자
• Discord를 개발 요청과 운영 작업의 중심으로 사용하는 팀
• 긴 작업, 반복 리뷰, 서비스 재시작 이후의 복구가 중요한 프로젝트
• Codex와 Claude Code의 장점을 역할별로 조합하고 싶은 사용자
• 개발 서버와 프로덕션 서버의 차이를 읽기 전용으로 진단하고 싶은 웹 프로젝트

반대로 클릭 몇 번만으로 끝나는 완전 관리형 SaaS는 아닙니다. Linux 서버, Discord 봇, AI CLI 인증을 직접 관리할 수 있는 환경을 전제로 합니다.

권장 환경

• Ubuntu 22.04 이상
• Node.js 20 이상
• Bun 1.3 이상
• Git, gcc, make, bubblewrap, socat, unshare
• systemd user service를 사용할 수 있는 일반 사용자 계정
• Owner용 Codex 또는 Claude 계정
• Tribunal 사용 시 Reviewer용 Codex 또는 Claude 계정
• Discord 서버의 봇 초대·채널 관리 권한

빠른 설치

처음에는 Owner 봇 하나와 Codex 하나만 연결해 첫 응답을 확인한 뒤 Reviewer와 Arbiter를 추가하는 방식을 권장합니다.

1. 시스템 도구 설치

sudo apt update
sudo apt install -y build-essential bubblewrap curl git socat unzip util-linux

Node.js 20 이상과 Bun 1.3 이상을 준비합니다.

node --version
curl -fsSL https://bun.com/install | bash
bun --version

2. AI CLI 로그인

Codex를 Owner로 사용할 경우:

npm install -g @openai/codex
codex login
codex login status

Claude Code를 Reviewer로 사용할 경우:

npm install -g @anthropic-ai/claude-code
claude auth login --claudeai
claude auth status --text

CLI 로그인은 RBClaw 서비스를 실행할 동일한 OS 사용자 계정에서 진행해야 합니다.

3. 설치와 기본 설정

git clone https://github.com/bjrambo/RBClaw.git
cd RBClaw
bash setup.sh
cp .env.example .env
chmod 600 .env

.env에 Owner Discord 봇 토큰과 provider를 설정합니다. 토큰은 문서, 채팅, Git 커밋에 올리지 마세요.

DISCORD_OWNER_BOT_TOKEN=<Owner 봇 토큰>
OWNER_AGENT_TYPE=codex
ASSISTANT_NAME=claude

4. 첫 채널 등록과 실행

bun run setup -- --step environment
bun run setup -- --step runners

bun run setup -- --step register -- \
  --jid dc:123456789012345678 \
  --name "My Server #control" \
  --folder discord_main \
  --channel discord \
  --is-main

bun run setup -- --step service
bun run setup -- --step verify

검증 결과의 마지막이 STATUS: success이면 등록한 Discord 채널에서 Owner 봇에게 메시지를 보내 첫 응답을 확인합니다.

Reviewer와 Arbiter 추가 방법, room assignment, 역할별 모델 설정, 원격 진단 profile은 저장소의 README와 설정 문서에서 확인할 수 있습니다.

운영과 보안

RBClaw은 강한 자동화를 제공하지만 모든 외부 변경을 자동으로 안전하게 만들어 주지는 않습니다.

• .env, 세션, 로그, SQLite 데이터는 공개 저장소에 넣지 마세요.
• Reviewer의 읽기 전용 보호가 활성화되지 않으면 Tribunal 실행을 허용하지 않는 구성을 권장합니다.
• 배포, 서비스 재시작, 데이터베이스 변경, 자격 증명 변경은 사용자 승인과 프로젝트 규칙을 거쳐야 합니다.
• 임의 shell, SSH, 외부 API가 만든 부작용은 effective-once 보장 범위 밖입니다.
• 프로덕션 검토는 사람의 운영 승인과 모니터링을 대체하지 않습니다.
• 업데이트는 작업 트리가 깨끗한지 확인하고 백업한 뒤 bun run deploy 경로를 사용하세요.

1.0.0의 의미

1.0.0은 RBClaw의 기본 운영 계약을 처음으로 하나의 공개 버전으로 묶는 릴리즈입니다.

• Discord 기반 단일 서비스 구조
• Owner / Reviewer / Arbiter 역할 경계
• room별 실제 작업 디렉터리와 설정 모델
• 읽기 전용 검증과 host verification
• 장기 작업의 상태 보존과 복구
• 설치, 업데이트, 진단을 포함한 운영 문서

앞으로도 더 많은 기능을 한꺼번에 추가하기보다, 실제 운영에서 재현된 문제를 근거로 실행 안정성, 검증 독립성, 설치 편의성을 개선해 나갈 계획입니다.

링크

• GitHub: https://github.com/bjrambo/RBClaw
• 설치 안내: README
• 설정 문서: docs/configuration.md
• 변경 이력: CHANGELOG.md
• 이슈 제보: GitHub Issues

RBClaw 1.0.0에 관심이 있다면 저장소의 설치 안내부터 확인해 주세요. 실제 환경에서 발견한 문제와 재현 가능한 피드백은 다음 버전을 더 단단하게 만드는 데 큰 도움이 됩니다.