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

RBClaw 1.0.0을 공개합니다.

예전에 Codex는 구현하고 Claude는 검토한다라는 글을 올린 적이 있습니다. Discord에서 Codex에게 구현을 맡기고, Claude가 그 결과를 다시 검토하도록 만든 개인 개발 환경을 소개한 글이었습니다.

그때는 제가 쓰던 방식을 소개하는 정도였지만, 이후에도 실제 라이믹스 작업과 다른 프로젝트에 계속 사용했습니다. 쓰다 보니 단순히 AI 두 개를 이어 붙이는 것만으로는 부족했습니다. 작업이 길어지면 문맥이 흐려졌고, 같은 수정과 검토가 반복되거나 서비스 재시작 뒤에 진행 상태를 잃는 일도 있었습니다.

그 문제를 하나씩 고치면서 별도 프로젝트로 정리한 것이 RBClaw입니다.

지금은 이렇게 돌아갑니다

사용자는 Discord에서 Owner에게 작업을 요청합니다.

• Owner는 실제 프로젝트를 확인하고 코드를 수정한 뒤 테스트합니다.
• Reviewer는 같은 프로젝트의 변경 내용과 테스트 결과를 읽기 전용으로 다시 확인합니다.
• Arbiter는 두 역할의 의견이 계속 엇갈릴 때만 쟁점을 정리하거나 사용자 판단을 요청합니다.

Reviewer가 문제를 찾으면 작업은 Owner에게 돌아갑니다. Owner가 수정하면 Reviewer가 다시 확인하고, 승인이 끝나야 결과를 확정합니다.

역할이 셋이라고 해서 매번 셋이 모두 등장하는 것은 아닙니다. 기본 흐름은 Owner의 구현과 Reviewer의 검토입니다. Arbiter는 실제로 판단이 반복될 때만 참여합니다.

제가 사용하는 조합은 Codex Owner와 Claude Reviewer지만, 역할마다 사용할 모델은 바꿀 수 있습니다. 특정 모델보다 구현과 검토를 분리하는 구조에 더 의미를 두었습니다.

계속 쓰면서 보완한 부분

처음 소개했던 구조에서 가장 많이 달라진 부분은 운영 안정성입니다.

• Reviewer가 Owner의 설명만 믿지 않고 실제 파일과 변경점을 확인합니다.
• Reviewer와 Arbiter는 기본적으로 읽기 전용 환경에서 동작합니다.
• 긴 작업의 진행 상태를 저장해 중단되거나 재시작돼도 이어갈 수 있습니다.
• 사용자 입력이나 외부 결과를 기다릴 때는 AI를 계속 호출하지 않습니다.
• 커밋, 배포, 서비스 재시작, 데이터베이스 변경처럼 영향이 큰 작업은 사용자 승인을 거칩니다.
• 채널마다 프로젝트 경로와 역할, 모델을 따로 설정할 수 있습니다.

결국 목표는 AI가 코드를 더 많이 작성하게 만드는 것이 아니라, 실제 프로젝트에 적용하기 전에 한 번 더 확인하고 문제가 생겼을 때 어디서 잘못됐는지 찾기 쉽게 만드는 것입니다.

공개한 이유

처음에는 제 개인 환경에 맞춘 도구였지만, Discord에서 작업을 요청하고 다른 모델에게 검토를 맡기려는 분들이 있어 공개 프로젝트로 정리했습니다.

RBClaw은 설치만 하면 모든 일을 알아서 처리하는 서비스는 아닙니다. Discord 봇과 AI CLI를 직접 설정해야 하고, AI의 구현과 리뷰가 항상 맞는 것도 아닙니다. 중요한 변경의 최종 판단과 운영 책임은 여전히 사용자에게 있습니다.

그래도 AI 한 명에게 구현과 자기검토를 모두 맡기는 것보다, 역할을 나누고 서로 다른 관점에서 확인하는 방식이 필요한 분에게는 도움이 될 수 있다고 생각합니다.

설치와 자세한 내용

설치 방법과 설정 항목은 앞으로도 바뀔 수 있어 이 글에 길게 적지 않았습니다. 최신 내용은 저장소의 README와 설정 문서에서 확인해 주세요.

• GitHub 저장소
• 초보자 설치 가이드
• 설정 문서
• 변경 이력

실제로 사용하면서 발견한 문제나 재현 가능한 사례가 있다면 GitHub Issues로 알려주시면 감사하겠습니다.