codeArbiter 판단 및 첫 사용 가이드: Claude Code, Codex CLI, Pi에 게이트 기반 코드 거버넌스 도입

누구에게 적합한가

• Claude Code, Codex CLI 또는 Pi에서 작업하면서 변경 사항이 코드베이스에 들어가기 전에 강제 검사를 거치길 원하는 개발자와 팀에게 적합합니다. codeArbiter는 이 세 호스트를 위해 설계된 거버넌스 레이어(governance layer)로, 공식 저장소 제목이 그 동기를 보여줍니다. "When you can't trust yourself with your code base, trust Arbiter."(코드베이스를 스스로 믿을 수 없다면, Arbiter를 믿으세요.)
• 활성화하면 agent에 표현한 모든 의도는 gated skill 또는 reviewer agent로 라우팅되고, 게이트가 모두 통과하기 전에는 커밋이 이루어지지 않습니다. 판단은 SMARTS를 거치며, 감사 기록은 append-only(추가 전용)입니다. 적용 단위는 저장소 단위이며, opt in 대상은 개별 저장소입니다. 커밋 전 강제 게이트와 추적 가능한 판단 기록이 필요한 사람을 위한 것이 바로 이런 요구입니다. append-only는 감사 기록이 추가만 가능하고 삭제나 수정은 할 수 없다는 뜻입니다.
• "먼저 보고 나서 움직이는" 신중한 사용자에게 적합합니다. 공식 문서는 플러그인이 설치 후 기본적으로 휴면 상태이며, 저장소를 명시적으로 opt in하기 전까지는 해당 저장소에 아무 작업도 하지 않는다고 분명히 말합니다. 원문은 "That silence is intentional."(이 침묵은 의도된 것입니다). 설치 자체가 저장소의 기존 동작을 즉시 바꾸지는 않습니다.
• 적합하지 않은 경우: 게이트 방식의 프로세스를 원하지 않는 경우, 일회성 코드 분석이나 수정만 하려는 경우, 그리고 다음 절의 요구 사항을 환경이 충족하지 못하는 머신입니다. 어떤 프로그래밍 언어와 프로젝트 유형에 적용되는지는 공식 설명에 없으며 알 수 없습니다. 이는 채택 여부 판단에 직접 영향을 줍니다.
• Claude Code, Codex CLI, Pi 외의 agent 호스트를 지원하는지는 근거 자료에 없어 알 수 없습니다.

3분 만에 첫 사용 시도하기

• 전제 조건: Windows, macOS 또는 Linux. 공식 요구 사항은 Pi 0.80.10, Node.js 22.19 이상, Python 3, Git이며 계정이나 샘플 데이터는 필요하지 않습니다. 하나라도 빠져 있다면 먼저 환경을 갖춘 뒤 설치하세요.
• 설치 위치: 공식이 안내하는 설치 경로는 Claude Code의 plugin marketplace입니다. Claude Code에서 다음 두 명령을 순서대로 실행합니다. 첫 번째는 arbiterForge/codeArbiter를 marketplace 소스로 추가하고, 두 번째는 그 소스에서 ca라는 이름의 플러그인을 설치합니다.

/plugin marketplace add arbiterForge/codeArbiter
/plugin install ca@codearbiter

• 설치 후 성공 신호: hooks, commands, agents, statusline 배선이 자동으로 로드되고, 모든 명령은 /ca: 네임스페이스에서 해석됩니다. 즉 설치 후 수동 배선이 필요 없으며, /ca: 접두사가 붙은 명령은 인식되어야 합니다. 이 시점에도 플러그인은 여전히 휴면 상태인데, 이는 예상된 동작이며 설치 실패를 뜻하지 않습니다.
• 핵심 확인 사항: 저장소는 명시적으로 opt in된 후에야 거버넌스 흐름에 들어갑니다. 설치 완료는 곧 작동 시작이 아닙니다. opt in의 구체적인 명령은 공식 설명에 등장하지 않아 이 단계를 어떻게 수행하는지 알 수 없습니다. 공식 저장소 안의 설명을 기준으로 삼고, 명령을 임의로 추측하지 마세요.
• 첫 번째 작업: opt in 후에 agent에게 평범한 코드 분석이나 수정 의도를 전달하고 두 가지를 관찰합니다. 의도가 gated skill 또는 reviewer agent로 라우팅되었는지, 게이트가 모두 통과하기 전까지 커밋이 보류되는지. 의도가 라우팅되지 않거나 게이트가 모두 통과되지 않은 상태에서 커밋이 발생하면, 거버넌스 흐름이 공식 설명대로 작동하지 않는 것입니다. /ca: 아래에 어떤 구체적인 명령이 있는지는 근거 자료에 없어 그대로 옮겨 줄 수 없습니다.

사용 사례

• 사례 1: 개인 저장소에 게이트 기반 커밋 사용하기. 상황: 모든 변경이 커밋 전에 자동으로 검사되기를 원함. 방법: Claude Code에서 앞의 두 설치 명령을 실행해 ca 플러그인을 설치하고, hooks, commands, agents, statusline이 자동 로드되었으며 /ca: 명령이 해석되는지 확인합니다. 그다음 저장소를 opt in하고 agent에게 변경 의도를 전달합니다. 기대할 수 있는 것: 의도가 gated skill 또는 reviewer agent로 라우팅되고, 게이트가 모두 통과하기 전에는 커밋되지 않으며, 판단은 SMARTS를 거치고, 감사 기록은 추가만 가능합니다. 설치 후 휴면 상태이므로 이 사례의 모든 부수 효과는 opt in 단계부터 시작되며, 설치 명령 자체는 거버넌스 동작을 일으키지 않습니다. 설치된 모습만 먼저 보고 싶다면 "자동 로드, /ca: 해석" 단계에서 멈춰 관찰해도 되며, 서둘러 opt in할 필요는 없습니다.
• 사례 2: 팀의 변경 판단을 추적 가능하게 만들기. 상황: 여러 명이 협업할 때 변경마다 판단 기록이 남고 이력이 수정되지 않기를 원함. 방법: 이미 opt in한 저장소에서 agent에게 변경 의도를 전달하고 같은 게이트 워크플로를 거칩니다. 기대할 수 있는 것: 판단은 SMARTS로 기록되고, 감사 기록은 append-only이며, 이미 기록된 내용은 이후 작업으로 덮어쓰이지 않습니다. SMARTS와 구체적으로 어떻게 상호작용하는지, 어느 화면에서 기록을 볼 수 있는지는 근거 자료에 없으며, 확인 가능한 범위는 여기까지입니다.

사용상의 한계

• 부수 효과와 확인 사항: 설치 시 hooks, commands, agents, statusline 배선이 자동으로 로드됩니다. 이는 공식 설명에 있는 설치 시점에 발생하는 동작입니다. 초기 상태는 휴면이며, 저장소를 명시적으로 opt in하기 전까지 플러그인은 그 저장소에 아무 것도 하지 않습니다. 따라서 opt in하지 않으면 거버넌스 효과를 검증할 수 없습니다. opt in 자체를 취소할 수 있는지, 취소 방법은 무엇인지 근거 자료에 없어 알 수 없습니다. 되돌리기 비용이 걱정된다면 opt in 전에 이 부분을 먼저 확인하세요.
• 파일, 명령, 네트워크: 파일을 읽고 쓰는지, 어떤 명령을 실행하는지, 네트워크에 접근하는지는 모두 공식 설명에 없어 알 수 없습니다. 이 침묵을 근거로 그런 동작이 전혀 없다고 추단해서는 안 됩니다. 중요한 저장소에 연결하기 전에 버려도 되는 환경에서 opt in을 시험해 보는 것을 권합니다.
• 플랫폼과 클라이언트 차이: 공식이 그대로 안내하는 설치 경로는 Claude Code의 plugin marketplace뿐입니다. Codex CLI와 Pi는 거버넌스 레이어가 서비스하는 호스트로 나열되어 있지만, 두 클라이언트의 설치 방법은 공식 설명에 없어 알 수 없습니다.
• 아직 확인되지 않은 핵심 정보: opt in의 구체적인 명령, /ca: 네임스페이스 아래의 전체 명령 목록, SMARTS와의 상호작용 방식, 지원 프로그래밍 언어와 프로젝트 유형, Windows·macOS·Linux 외 시스템 지원, 제거하거나 일시적으로 비활성화하는 방법. 이 모든 것이 근거 자료에 없습니다. 채택 전에 공식 저장소에서 항목별로 확인하세요.