01세 시스템, 같은 질문 소스 실측
「LLM 에이전트를 어떻게 믿을 수 있는 작업자로 만드는가」. 같은 질문에 세 시스템이 전혀 다른 형태로 답한다. keystone-hub는 호스트 CLI 위의 설정 하네스(규칙·훅·스킬 + 사람 게이트), ouroboros는 런타임을 추상화하는 Agent OS(불변 스펙 + 커널), gajae-code는 CLI 자체를 대체하는 독립 에이전트 제품이다. 두 외부 소스는 셸로우 클론 소스 실측, keystone은 layers 소스 실측 기준.
| 축 | keystone-hub | Q00/ouroboros | Yeachan-Heo/gajae-code |
|---|---|---|---|
| 정체 | 개인 하네스 설정 정본 · 규칙·훅·스킬을 레이어로 관리해 apply로 배포 Claude Code + Codex 위에서 동작 | "Agent OS" · Seed·Ledger·Runtime·MCP 커널 Shell(ourocode) · Apps(plugins) · OS(본체) 3-repo 구조 | 독립 코딩 에이전트 gjc · 자체 LLM 클라이언트·TUI·Rust 셸
"intentionally not a plugin for Codex CLI/Claude Code" |
| 호스트 관계 | 호스트 CLI를 설정으로 조종 (교체 없음) | 호스트 CLI 12종을 어댑터로 추상화 (Claude Code·Codex·Gemini·Copilot…) | 호스트 CLI를 대체: provider 14+ 직결 |
| 핵심 루프 | 수확(자동) → 채택(사람) → 규칙/훅 → 게이트 강제 | Interview → Seed(불변) → Execute → Evaluate → Evolve | deep-interview → ralplan(합의) → ultragoal(증거 게이트) + team |
| 규모 실측 | rules 58 · hooks 46 · skills 112layers 소스 기준 (2026-07-23) | .py 1,129 · 테스트 585파일/~11.5K · docs 104 · RFC 265,120⭐ / 514 fork / v0.44.0 라인 | .ts 3,155 + .rs 264 · TS 테스트 1,492 · docs 852,186⭐ / 308 fork / npm v0.11.8 |
| 활동 | 일상 운영 중 (이 워크벤치 포함) | 2026-01 0.1.0 → 07 v0.44.0, PR-헤비, 오늘도 push | 7월 한 달 0.9.x→0.11.8 거의 일일 릴리스, 오늘도 push |
| 성숙 신호 | 사고→규칙 이력 다수, 결정론 게이트 스크립트 실배선 | CI 7종(경계·성능예산 게이트). 단 일부 표면 "wiring-only" scaffolding | 베타 자인 · control-plane 하드닝 이슈 진행 중 |
| 메인테이너 | 1인 (Lucy · 자기 소유라 리스크 아님) | 사실상 1인: Sponsors 펀딩, 개인 메일 보안 창구 | 사실상 1인 (+소수 기여) · 표면 대비 유지 부담 큼 |
02무엇이 진실인가 3색 대비
세 시스템의 차이는 기능 목록이 아니라 "무엇을 진실(source of truth)로 삼는가"에서 갈린다. 이 한 줄이 이후 모든 축(게이트·상태·복구)의 형태를 결정한다.
규칙 + 사람 게이트가 진실
하네스는 설정이다. 코드가 스펙(code-as-spec)이고, 위험한 전이(push·병합·R2)는 결정론 스크립트와 사람 승인이 막는다. 수확은 자동, 채택은 사람: 자동 채택 0건이 의도된 성공 상태.
불변 계약: 규칙 문서 + 근거(사고 이력)
불변 스펙(Seed)이 진실
"Stop prompting. Start specifying." 인터뷰로 모호성을 임계 이하로 내린 뒤에만 불변 Seed가 결정화되고, 이후 모든 실행·평가·진화가 그 스펙에 묶인다. 프롬프트는 스펙의 파생물.
불변 계약: Seed.direction (goal·constraints·AC)
합의된 계획 + 증거가 진실
"Encode intention. Decode software." Planner·Architect·Critic의 합의 루프(ralplan)가 계획을 고정하고, 완료는 표면별 위조 저항 증거(argv-replay 등)를 전부 제출해야 선언된다.
불변 계약: 승인된 plan + quality-gate JSON
| 축 | keystone-hub | ouroboros | gajae-code |
|---|---|---|---|
| 사람의 위치 | 채택·병합·R2의 최종 게이트: 확인 문구 재입력까지 | HITL 이벤트(WAIT/RESUME)로 예외 처리자: 기본은 자율 루프 | critic 게이트 override 기록자: non-OKAY 5회 초과 시에만 소환 |
| LLM의 위치 | 구현·조율 담당, 판정은 결정론 스크립트가 감쌈 | 인터뷰·평가 담당, grounding 판정은 모델 호출 0회(TraceGuard) | 계획·리뷰 담당, 수락은 스키마 검증 봉투가 감쌈 |
| 실패의 의미 | 사고 → 규칙의 원료 (근거 섹션에 영구 기록) | 분류 대상 → 정적 복구 정책 테이블의 입력 | 게이트 반복의 입력 → 상한 도달 시 사람 에스컬레이션 |
| 확장 방향 | 수평 · 외부 패턴을 수확해 자기 규칙으로 소화 | 수직 · 커널 계약(RFC 26) 위에 런타임·플러그인 적층 | 수직 · 자체 스택(클라이언트→셸→TUI) 전부 소유 |
03게이트 · 증거 · 복구 gap 2 발견
품질을 강제하는 층. keystone의 빈 축 2개(모호성 결정론 게이트 · CLI 증거 표준)가 여기서 발견됐고, 셋 다 pilot 후보가 이 표에서 나왔다.
| 축 | keystone-hub | ouroboros | gajae-code | 판정 |
|---|---|---|---|---|
| 모호성 게이트 | lucy-prompting-patterns가 완료기준·스코프 누락을 LLM 판단으로 보강: 결정론 판별기 없음 | A-grade Seed 게이트: ambiguity>0.20 차단 + VAGUE_TERMS 린트("robust","scalable"…) + AC 관찰가능성 정규식auto/grading.py · 점수가 아니라 blockers 목록을 가진 코드 게이트 |
Pre-Execution Gate: 결정론 신호 스캔(파일경로·이슈#·심볼·테스트러너·번호단계) 0건이면 계획으로 라우팅LLM 점수 없이 정규식만 · HARD 구현의 실증 | gappilot ①③ |
| QA 증거 형식 | qa-evidence-stamp: PASS|hash|ts + tree 바인딩 + 1h 신선도 + acceptance 기록 · GUI/웹 축이 강함 |
typed evidence schema · ExecutionProfile별 증거 스키마를 파서가 검증한 뒤에만 leaf 결과 수락 | 표면별 증거 계약: GUI=트랜스크립트+스크린샷 · CLI=argv-replay(재실행 allowlist+정규화 stdout 불변식) · native=PTY · API=typed receipt | partialpilot ② |
| 출력 게이트 (anti-Goodhart) |
verified-value-registry(규칙, 스크립트 미구현) + holdout-eval-gate + acceptance anti-Goodhart | TraceGuard: 모든 claim이 fact_id/evidence handle에 set-membership으로 묶임 · 모델 호출 0회, reject 코드 5종, "reward-hack 불가" + frugality proof | quality-gate JSON · 전 lane CLEAR + fullRerun:true + 빈 blockers여야 완료. goals.json.status 단독은 증거로 불인정 |
partialreject taxonomy 참조 |
| 실패 복구 | error-recovery 4회 사다리(1직접→2구조→3 codex rescue→4보수) + EXHAUSTED 에스컬레이션 | FailureClass 6종 → RecoveryAction 정적 정책 테이블(RETRY/모델 상향/재분해/타 하네스 재디스패치/사람) + VerifierVerdict 불변식 | critic non-OKAY run 상한 5회 → 사람 override 명시 기록 필수 (fail-closed) | covered |
04상태 · 컨텍스트 대체로 covered
세션을 넘어 살아남는 것들. 상태 무결성 축에서 gajae의 영수증 설계가 눈에 띄지만, keystone의 HANDOFF는 의도적으로 저신뢰(참고 정보 + 고위험 재검증)라 설계 선택이 다른 것이지 결함이 아니다.
| 축 | keystone-hub | ouroboros | gajae-code | 판정 |
|---|---|---|---|---|
| 워크플로 상태 | 세션 HANDOFF YAML(~/.claude/sessions/) + confirmed-actions 토큰 · 참고 정보로 취급, git 상태가 우선 |
이벤트 소싱 · append-only SQLite EventStore, 전체 계보 재구성 가능 + AutoPhase FSM 12상태·페이즈별 타임아웃 | .gjc/ 파일 상태(.omx/ 계보의 제품화) + 체인가드 FSM · 스킬 핸드오프가 원자 전이 |
설계차 |
| 상태 무결성 | QA 증거만 hash+신선도 바인딩(qa-evidence-stamp rebind) · 일반 상태는 비바인딩 | 이벤트 저장소 자체가 append-only · 변조는 replay 불일치로 노출 | 상태 영수증: sha256 콘텐츠 체크섬 + fresh_until + owner enum(cli/runtime/hook) + mutation_id · 직접 편집을 코드가 차단 |
partialownership 개념 참조 |
| 컨텍스트 컴팩션 | 컴팩션 계열 규칙군(원칙) + 서브에이전트 digest 반환 관행 | context_governor · 결정론 char 예산(기본 12,000) + sibling은 본문 대신 status-line | 자동/mid-run/긴급 + 원격 컴팩션(provider 네이티브 이력) + Rust 출력 minimizer | covered |
| 프롬프트 캐시 | prefix-cache-stability 규칙 · prefix 불변·변동 데이터 suffix 배치 | 모델 스냅샷 핀(config/_model_defaults.py) · 재현성 축으로 접근 | cache_control ttl 1h/5m + 캐시 생성 토큰 회계 · provider 캐시를 직접 조작 |
covered |
05실행 · 격리 · 개선 철학차 뚜렷
모델을 고르고, 실행을 가두고, 시스템을 개선하는 층. 라우팅 축에서 세 철학이 가장 선명하게 갈린다. keystone은 실측·정적(regatta N=3 + 사람 승인), 두 외부 시스템은 런타임·동적.
| 축 | keystone-hub | ouroboros | gajae-code | 판정 |
|---|---|---|---|---|
| 모델 라우팅 | regatta 실측 N=3 → 사람 승인 배정(#307 luna-low, #309 sonnet-5) · 세대 교체 시 재측정 트리거 | PAL 3-tier frugal(1x)/standard(10x)/frontier(30x) 자동 에스컬·다운 + effort ladder 5단(retry 2회 후 1노치 상향) | model-manager 다중 소스 병합 + provider fallback 체인 + 역할/프리셋별 매핑 | 설계차실측 vs 동적 |
| 샌드박스·권한 | capability-broker(review-only) + policy/sandbox 규칙 + hook 게이트(guard-secrets 등) | SandboxClass 3계층(READ_ONLY/WORKSPACE_WRITE/UNRESTRICTED) + provider별 권한 번역 테이블 + policy 감사 이벤트 | bash 제한 프로파일 · 제어문자 ; | & $ 차단 + read-only allowlist + 역할별 명령 제한 |
covered번역 테이블 참조 |
| worktree 격리 | worktree-first-sessions(EnterWorktree 의무) + worktree-open/finish 원커맨드 + 캐시 링크 | TaskWorkspace(백엔드 무관 worktree + file-lock) + AutoWorktreePolicy 4모드 + shadow replay용 일회용 worktree | 관리형 sibling worktree(--worktree) + team tmux 병렬 워커 |
covered |
| 멀티벤더 | Claude+Codex 이중 + codex rescue(3차) + 교차 리뷰 · 벤더 스왑은 규칙으로 | 런타임 어댑터 12종 + REDISPATCH_ALT_HARNESS(실패 시 벤더 교체) + n-version tournament(미배선) |
provider 14+ 직결 · 벤더 추상화를 자체 클라이언트 층에서 해결 | covered |
| 자가개선 | trend-harvester 수확→사람 채택(자동 채택 0건 설계) + holdout eval gate + evolution-ledger | evolution/ · convergence(0.95×3·30세대 캡)·regression·shadow replay(부모 tier 재실행 baseline) | 명시 루프 없음 · 제품 개발 사이클 자체가 개선 경로 | covered |
| 활성 감시 | harness-liveness-guard + toolchain smoke + dead-hook-report · 훅이 살아있는가 | watchdog 이중 타임아웃 · idle + no-material-progress("활동≠진전" 축) | subagent await = 관찰 창(실패 아님) + heartbeat | partial진전 축 watch |
06계보 · 한 번 추출했고, 한 번 삭제했다 재평가 전제
이번 비교는 처음이 아니다. keystone은 두 소스 모두에서 과거에 패턴을 추출했고, 2026-05-02 규칙 감사(PR #13)가 그것들을 "미구현 이론 패턴" 43개와 함께 삭제했다. 그래서 이번 판정 기준은 하나다. 이론 규칙 재적재 금지. 코드가 되는 것만 들여온다.
| 과거 추출 규칙 | 유래 | 추출 시점 | 운명 | 이번 재평가 |
|---|---|---|---|---|
| quantified-ambiguity-gate | 구 ouroboros (2.4K⭐ 시절) | 2026-04-20 (trend-harvester 37차) | 2026-05-02 감사에서 삭제 · "실제 코드/hook 미구현, 매 세션 토큰만 소모" | 원본은 그 사이 코드 게이트로 구현됨(A-grade gate). 점수 공식이 아니라 린트 부분만 차용 (pilot ①) |
| state-driven-orchestration | oh-my-codex (gajae-code의 전신) | 2026-04-12 (19차) | 동일 감사에서 삭제 | .gjc/로 제품화됐지만 keystone은 HANDOFF 저신뢰 설계를 유지 · 재적재 안 함 |
감사가 남긴 교훈이 이번 판정을 결정한다
- 같은 소스를 두 번 소비하는 방식이 달라졌다: 4월에는 "패턴 → 규칙 문서"였고, 그 규칙은 죽었다. 이번에는 "패턴 → 기존 스크립트의 코드 diff"만 허용한다. pilot 3건 전부 규칙 문서 신설이 0건인 이유.
- 원본의 진화가 재평가를 정당화한다: 구 ouroboros의 ambiguity 점수는 LLM 판정(temp 0.1)이라 이식 불가였다. 현재의 VAGUE_TERMS 린트 + 관찰가능성 정규식은 모델 없이 도는 수십 줄: 이식 가능성이 질적으로 달라졌다.
- watchlist가 재적재의 완충재: 제품 단위 관심은 규칙이 아니라 docs/watchlist.md(구체적 승격 조건 필수)로. gajae-code가 그 경로로 간다.
07도입 판정 intake 확정
제품은 들여오지 않는다(둘 다). 장치는 세 개를 pilot으로 들여온다. 전부 기존 스크립트·훅에 붙는 결정론 코드이며, 규칙 문서 신설은 pilot 성공 실측 후에만.
| 대상 | 판정 | 이유 |
|---|---|---|
| ouroboros 제품 (설치/MCP 등록) | reference-only | keystone 자체가 하네스인데 위에 두 번째 Agent OS를 얹으면 오케스트레이션 이중화. 1인 유지 + scaffolding 다수 + "spec이 임의 tool call 가능" 자인 경고 · 공급망 감사 비용 > 기대 가치 |
| gajae-code 제품 (설치/일상 사용) | watch | oh-my-codex 후계로 저자 트랙레코드 있음, 활성 베타. 승격 조건: ① 1.0 안정판 ② control-plane 이슈 소진 ③ 타 사용자 프로덕션 후기. 셋 충족 전 Claude Code+Codex 체제 대체 근거 없음 |
| ① vague-AC 린트 (ouroboros) | pilot | 모호 용어 목록 + AC 관찰가능성 정규식 → 기획 문서 QA 게이트/planning-harness에 수십 줄 이식. Lucy 기획 QA 직접 유효 |
| ② CLI argv-replay 증거 (gajae) | pilot | qa-evidence-stamp에 cli-replay 증거 유형 추가 · "실행했다" 산문의 위조 저항 확보, completion-verification의 HARD 승격 경로 |
| ③ 결정론 vagueness pre-gate (gajae) | pilot (L1 한정) | 신호 스캔 advisory 1줄 · soft-to-hard-promotion 준수(carve-out + L1 시작, false-positive 0 관측 후에만 차단 검토) |
| TraceGuard reject taxonomy | reference-only | verified-value-registry 스크립트 구현 착수 시 설계 참조(5종 reject 코드) · 지금 규칙화는 이론 재적재 |
| 그 외 primitive 전부 | covered / ref | 매트릭스 ①~③ 판정 열 참조 |
08Pilot 후보 3건 · 전부 코드, 규칙 0건 실행 계획
공통 계약: vendoring 없이 재구현(collect-only), 기존 파일에 붙이고, 성공 기준을 숫자로 먼저 정한다.
vague-AC 린트 · 기획 문서의 수용 기준이 검증 가능한 문장인가
← ouroboros auto/grading.pyVAGUE_TERMS 목록("robust", "scalable", "better"…)과 관찰가능성 정규식으로 수용 기준(AC)을 결정론 검사. 기획→개발 전달 품질을 잡는 축이 현재 canon에 비어 있고, Lucy의 회사 기획 QA에 가장 직접적으로 유효하다.
validate_docs.py) 또는 planning-harness · 성공 기준: 회사 기획 문서 표본에서 false-positive율 측정 → 낮으면 게이트 편입CLI argv-replay 증거 · "실행했다"를 재실행 가능하게
← gajae ultragoal evidence 계약산문 증거 대신 {재현 가능 argv(allowlist) + 정규화 stdout 불변식} 아티팩트를 저장하고 게이트가 재실행 대조. completion-verification의 "실행 로그를 증거로" prose 계약을 HARD로 승격하는 실질 경로.
qa-evidence-stamp.sh cli-replay 증거 유형 + 게이트 재실행 검증 · 규모: 중간(스탬프+게이트 양쪽)결정론 vagueness pre-gate · 막연한 실행 요청에 advisory 1줄
← gajae Pre-Execution Gate요청에 경로·이슈#·완료기준 신호가 0개인 실행 요청을 감지해 "계획 먼저?" 넛지. L1 advisory 고정: false-positive가 곧 작업 방해라, 축약 플로우·"추천" 위임(Lucy 강점)은 carve-out 필수.
09리스크 · 부수 발견 · 출처 · 경계
리스크
- 이론 규칙 재적재: pilot이 규칙 문서부터 만들면 2026-05 감사의 실패를 반복한다. 규칙은 pilot 실측 근거 확보 후에만.
- vendoring 금지: 두 repo 모두 collect-only(upstream-conflict-zones). gajae 스스로도 oh-my-codex를 "concepts ported, code not copied"로 다룬다. 같은 원칙.
- grep 게이트 맹목 승격: pilot ③은 정규식 판별기라 오탐 = 작업 차단. L1 고정, 승격은 관측 데이터로만.
- 1인 유지 공통 리스크: 패턴 차용에는 무관하나, 제품 의존(설치·MCP 등록)은 부적절.
부수 발견
- 런타임/소스 규칙 발산: 이 머신
~/.claude/rules/125개 vs keystone-hub 소스 58개. 감사에서 삭제된 규칙 다수가 런타임에 잔존 · apply 재실행 또는 정리 확인 필요 (runtime-sync-ownership-boundary 관할, 별도 작업으로 분리).
출처
- 소스 실측: 2026-07-23 셸로우 클론(/tmp/ref-intake-*) + GitHub API 메타(별점·fork·push 시각·라이선스). 파일 경로·수치는 실제 소스 인용.
- keystone 대조: layers 소스 실측(universal 35 + personal 23) + 2026-05-02 rules-audit.md + docs/watchlist.md 철학.
- 연계 문서: private 분석: 내부 intake 노트 (2026-07-23, 비공개 · 판정 원본, 이 리포트는 그 시각화판).
경계
- 공개판 주기 · 이 글은 스크럽·발행 게이트를 거쳐 공개 폴더로 승격된 판이다. 내부 규칙명·이슈 번호는 keystone 자체 시스템 참조로만 남겼다.
- 스냅샷 문서 · 두 외부 repo는 오늘도 push되는 활성 프로젝트라 수치는 2026-07-23 기준으로 고정. gajae-code watch 재평가 시 재실측.
- 판정의 신뢰도 · 소스 사실은 [검증됨](클론 실측), 도입 판정은 [추론](canon 대조 기반). 최종 채택은 사람 결정.