분석축 루브릭 (10축)

한 줄 요약

서로 다른 7개의 코딩 에이전트(하네스)를 똑같은 10개의 잣대로 분해하고 1~5점으로 점수 매기기 위한 공통 채점표다. → 왜 배우나: 잣대가 제각각이면 “A가 B보다 낫다”는 비교가 말장난이 되어버린다. 모든 분석가(Claude·Codex)가 같은 자를 들고 재야, 나중에 표 하나로 깔끔하게 줄 세우고 내 하네스에 무엇을 베낄지 결정할 수 있다.

그림

7개 대상이 똑같은 10축 채점표를 통과해 하나의 비교 매트릭스로 모이는 흐름이다.

flowchart TD
  subgraph 대상["분석 대상 7개"]
    T1["Claude Code"]
    T2["Codex"]
    T3["OMC"]
    T4["gajae-code"]
    T5["ouroboros"]
    T6["fable-ish"]
    T7["내 패턴"]
  end

  대상 --> R["공통 루브릭 10축<br/>(각 축 1~5점)"]

  R --> A1["1. 아키텍처/포지셔닝"]
  R --> A2["2. 컨텍스트 엔지니어링"]
  R --> A3["3. 툴/확장"]
  R --> A4["4. 오케스트레이션"]
  R --> A5["5. 가드레일/안전"]
  R --> A6["6. 검증 루프"]
  R --> A7["7. 자기개선/반복"]
  R --> A8["8. 상태/영속성"]
  R --> A9["9. 배포/DX"]
  R --> A10["10. 철학/차별점"]

  A1 & A2 & A3 & A4 & A5 & A6 & A7 & A8 & A9 & A10 --> OUT["대상당 산출물<br/>(점수표 + 근거 + 교차검증)"]
  OUT --> MX["비교 매트릭스<br/>7개 한눈에 줄 세우기"]

쉽게 풀기

비유: 요리 경연 심사표. 참가자 7명이 각자 다른 요리를 내놓는데, 누가 1등인지 정하려면 심사위원마다 “나는 매운맛 좋아”식으로 제멋대로 채점하면 안 된다. 그래서 먼저 공통 채점표를 만든다 — 간, 식감, 플레이팅, 창의성… 이렇게 항목을 고정하고 각 항목에 1~5점을 준다. 그러면 요리가 아무리 달라도 같은 칸끼리 비교할 수 있다.

이 문서가 바로 그 채점표다. 다른 점은 요리 대신 코딩 에이전트(하네스) 7개를 채점한다는 것뿐이다.

채점 항목은 10개의 “축(axis)“이다. 축이란 “이 하네스를 들여다볼 때 꼭 봐야 할 한 가지 관점”을 말한다. 10개 축은 크게 세 덩어리로 묶어 기억하면 쉽다.

무엇으로 만들어졌나 (뼈대) — 1번 아키텍처, 2번 컨텍스트, 3번 툴. “어디에 얹히고, 모델에 뭘 보여주고, 무엇을 시킬 수 있나.”
어떻게 일을 굴리나 (동작) — 4번 오케스트레이션, 5번 가드레일, 6번 검증, 7번 자기개선, 8번 상태. “여러 일꾼을 부리고, 사고를 막고, 결과를 확인하고, 스스로 고치고, 기억을 남기는 방식.”
사람에게 어떤가 (가치) — 9번 DX, 10번 철학. “깔고 쓰기 쉬운가, 그리고 이게 뭐가 특별한가.”

점수는 1~5점이다. 헷갈리지 않게 양 끝만 기억하면 된다.

1점 = 그 기능이 거의 없거나 매우 약함.
5점 = 그 하네스의 핵심 강점(자랑거리).

중요한 규칙 하나 — 점수만 적으면 안 되고, 항상 **근거(파일 인용)**를 같이 붙인다. “5점”이 아니라 “이 파일 이 줄에 이렇게 되어 있어서 5점”이라고 써야, 나중에 다시 봐도 신뢰할 수 있고 Codex와 교차검증도 가능하다.

핵심 정리

10개 축이 각각 “무엇을 들여다보는지”와 “비개발자 식으로 풀면 무슨 질문인지”를 정리한 표다.

#	축	비개발자 관점 한 줄 질문
1	아키텍처/포지셔닝	”어디에 얹히고 무엇으로 만들었나”
2	컨텍스트 엔지니어링	”모델에 뭘 보여주나”
3	툴/확장	”무엇을 시킬 수 있나”
4	오케스트레이션/멀티에이전트	”여러 일꾼을 어떻게 부리나”
5	가드레일/안전	”함부로 못 하게 어떻게 막나”
6	검증 루프	”제대로 했는지 어떻게 확인하나”
7	자기개선/반복	”스스로 고쳐가며 반복하나”
8	상태/영속성	”기억을 어떻게 남기나”
9	배포/개발자경험(DX)	“쓰기/깔기 얼마나 쉽나”
10	철학/차별점	”이건 무엇이 특별한가”

[!note] 각 축에서 구체적으로 찾아볼 단서 점수를 매길 때 아래 항목이 있는지 뒤져보면 된다. (있으면 점수↑)

1 아키텍처 — 호스트-플러그인형 vs 독립 에이전트형 vs Agent OS형, 어떤 언어/런타임으로 짰나

2 컨텍스트 — CLAUDE.md/AGENTS.md, 메모리, spec-driven(명세 기반), 컨텍스트 압축

3 툴/확장 — MCP, hooks(훅), commands(명령), skills(스킬), 확장점 설계

4 오케스트레이션 — 위임, 팀, 병렬 실행, 서브에이전트 라우팅

5 가드레일 — 샌드박스, 권한, 승인 정책

6 검증 — 검증 게이트, 테스트, ‘다 됐다(done)’ 판정 기준

7 자기개선 — self-improve, ralph/ouroboros 같은 반복 루프, 재시도

8 상태 — state, notepad, memory, wiki, 세션 유지

9 DX — 설치, 플러그인 패키징, 설정 편의성

10 철학 — 포지셔닝, 고유 주장(thesis)

대상 하나를 분석할 때마다 아래 4가지를 산출물로 남긴다.

한 줄 정의 + 아키텍처/언어
10축 점수표 + 근거(파일 인용)
독창적 아이디어 / 강점 / 약점
Claude 분석 ↔ Codex 교차검증 결과(불일치·보정)

실제 예시

아래는 한 대상(예: Claude Code)을 이 루브릭으로 채점할 때 산출물이 어떤 모양이 되는지 보여주는 견본이다. 실제 점수가 아니라 형식 예시다.

<!-- 위치 예시: /mnt/d/6study/10_프레임워크분석/1_ClaudeCode/CC_개요.md -->

## 한 줄 정의
Claude Code = 터미널에서 도는 호스트-플러그인형 코딩 에이전트 (TypeScript/Node 런타임)

## 10축 점수표
| # | 축 | 점수 | 근거(파일 인용) |
|---|----|------|------------------|
| 1 | 아키텍처/포지셔닝 | 5 | CC_개요.md: 호스트+플러그인 구조 |
| 2 | 컨텍스트 엔지니어링 | 5 | CC_20_prompt-assembly.md: CLAUDE.md 계층·compact |
| 3 | 툴/확장 | 5 | CC_30_hooks.md, CC_70_mcp-and-tools.md |
| 6 | 검증 루프 | 4 | CC_10_agent-loop.md: Stop 훅 block 재진입 |
| ... | ... | ... | ... |

## 강점 / 약점 / 독창 아이디어
- 강점: 훅 기반 확장점
- 약점: (근거와 함께)
- 독창: Stop 훅으로 자동 반복 루프 구성

요약 & 셀프체크

이 문서는 7개 하네스를 똑같은 10축으로 1~5점 채점하기 위한 공통 자(루브릭)다.
10축은 “뼈대(1~~3) / 동작(4~~8) / 가치(9~10)” 세 덩어리로 묶어 외우면 쉽다.
점수는 반드시 파일 인용 근거와 함께 남기고, 마지막에 Codex와 교차검증한다.

스스로 답해보기:

누군가 “OMC가 Codex보다 검증이 강하다”고 주장한다면, 이 루브릭에서 몇 번 축을 근거로 들어야 하고 무엇을 인용해야 할까?
점수에 근거(파일 인용)를 반드시 붙이라는 규칙은 왜 있을까? 근거가 없으면 무엇이 무너지나?
1점과 5점의 뜻을 한 문장씩으로 말해보라.

연결

HOME · 하네스엔지니어링이란 · 비교 매트릭스