지식위키

축별 심층 분석

축별 심층 분석

한 줄 요약

7개 코딩 에이전트 하네스를 10개 평가 축으로 나눠, 각 축에서 누가 강하고·왜 그렇게 설계했고·무엇을 포기했는지(트레이드오프)를 비개발자 눈높이로 본다. 왜 배우나 — “뭐가 제일 좋냐”가 아니라 “이 도구는 어떤 상황에 맞고 그 대가는 무엇이냐”를 스스로 판단하는 안목을 기르기 위해서다.

[!note]- 펼쳐보기: 분석 대상 7종

  • Claude Code — 터미널 호스트 하네스
  • Codex — OpenAI, 120+ Rust 크레이트
  • OMC(oh-my-claudecode) — 종합 디스트리뷰션
  • gajae-code — 좁은 표면 멀티런타임
  • ouroboros — 스펙 우선 Agent OS
  • fable-ish — 경량 검증 게이트 플러그인
  • 내 패턴 — Claude+Codex 이중모델 하네스

그림

하네스란? — 두뇌에 작업 환경을 붙이는 일

flowchart LR
    A["AI 모델<br/>(두뇌만 있음)"] --> B["+ 작업대"]
    B --> C["+ 연장(툴)"]
    C --> D["+ 안전장치(가드레일)"]
    D --> E["+ 검수 절차(검증)"]
    E --> F["혼자 코딩하는 일꾼<br/>= 하네스"]

10개 축으로 일꾼을 평가하는 흐름

flowchart TB
    subgraph 정체성["정체성·기반"]
        ax1["1. 아키텍처/포지셔닝"]
        ax10["10. 철학/차별점"]
    end
    subgraph 일하는법["일하는 방식"]
        ax2["2. 컨텍스트 엔지니어링"]
        ax3["3. 툴/확장성"]
        ax4["4. 오케스트레이션"]
    end
    subgraph 믿음장치["믿을 수 있게 만드는 장치"]
        ax5["5. 가드레일/안전"]
        ax6["6. 검증 루프"]
        ax7["7. 자기개선/반복"]
    end
    subgraph 운용["오래 쓰기"]
        ax8["8. 상태/영속성"]
        ax9["9. 배포/개발자경험"]
    end
    정체성 --> 일하는법 --> 믿음장치 --> 운용

쉽게 풀기

출발점: “에이전트 하네스가 뭔가요?”

AI 모델(두뇌)만으로는 일이 안 된다. 두뇌에 작업대·연장·안전장치·검수 절차를 붙여 “혼자 코딩하는 일꾼”으로 만든 것이 하네스다. 아래 10개 축은 그 일꾼을 평가하는 잣대다. 한 축씩 “왜 이렇게 만들었나 → 무엇을 포기했나” 순으로 본다.


1. 아키텍처 / 포지셔닝 — “애초에 뭘 하려고 만든 것인가”

이 축의 만점은 “크다”가 아니라 **“정체성이 또렷하다”**이다.

  • Codex — 기능을 120+ 부품(크레이트)으로 물리적으로 쪼개, “안전 담당”과 “실행 담당”이 코드 차원에서 분리된다. 한 곳이 무너져도 옆을 못 침범한다.
  • ouroboros — “막연한 아이디어 → 검증된 코드”라는 단 하나의 여정을 끝까지 책임지는 OS.
  • fable-ish — “완료를 함부로 선언 못 하게 막는다”는 단 하나의 목표에 집중해 점수가 높다.
flowchart LR
    또렷한정체성["또렷한 정체성"] --> 비용["반드시 따르는 대가"]
    비용 --> c1["Codex: 거대한 덩치"]
    비용 --> c2["ouroboros: 가파른 학습곡선"]
    비용 --> c3["Claude Code: 핵심엔진 블랙박스"]
    비용 --> c4["gajae·내 패턴: 베타·검증 부족"]

트레이드오프: Claude Code는 핵심 엔진이 비공개라 내부를 볼 수 없고, gajae·내 패턴은 베타/개인 단계라 검증이 덜 됐다. 또렷한 정체성에는 늘 비용이 따른다.

[!example] 여기서 배울 점 좋은 도구는 “다 한다”가 아니라 “이건 하고 저건 안 한다”가 분명하다.


2. 컨텍스트 엔지니어링 — “AI에게 무엇을, 얼마나 보여줄까”

AI가 한 번에 읽는 분량(컨텍스트)은 정해져 있고 그 분량은 곧 돈이다. 책상 좁은 직원에게 서류를 다 쏟으면 정작 중요한 걸 못 본다.

  • Claude Code — 보조 직원(서브에이전트)·매뉴얼(스킬)을 필요할 때 불러오는(지연 로딩) 방식으로 책상을 비운다.
  • gajae·내 패턴 — “변하지 않는 머리말을 바이트 단위로 고정”해 제공사 **캐시(재사용 할인)**가 잘 걸리게 한다.

트레이드오프: fable-ish가 낮은 건 게으름이 아니라 “검증 게이트 하나만 잘하자”는 의도적 포기다. 반대로 gajae·ouroboros는 컨텍스트를 정교하게 다루는 대신 그 규칙 설명서가 수백 줄로 비대해져 오히려 책상을 다시 차지하는 역설을 안는다.

[!example] 여기서 배울 점 정보를 더 주는 게 아니라 “지금 꼭 필요한 것만” 주는 절제가 실력이다.


3. 툴 / 확장성 — “기능을 얼마나 쉽게 늘리고 갈아 끼우나”

확장성이란 콘센트 규격을 통일하는 일이다. 표준이면 남의 부품도 그냥 꽂힌다.

  • Claude Code — 플러그인·훅·스킬·MCP 네 종류의 표준 콘센트에 더해 “하네스를 만드는 하네스”(plugin-dev)까지 1급 기능으로 올렸다.
  • Codex — 도구를 그냥 호출하지 않고 **JS 코드로 조합 실행(code-mode)**해 토큰을 아낀다.
  • ouroboros — 어댑터 9종으로 여러 AI 회사 모델에 두루 꽂힌다.

트레이드오프: fable-ish는 훅 3개·스킬 1개로 끝나는 미니멀 설계라 확장성을 애초에 추구하지 않았다. “갈아 끼울 게 많다”는 “배우고 관리할 게 많다”는 뜻이라, 확장성 만점 도구는 예외 없이 진입 장벽이라는 청구서를 함께 보낸다.

[!example] 여기서 배울 점 규격이 표준화되면 남이 만든 부품도 그냥 꽂힌다.


4. 오케스트레이션 — “여러 AI를 어떻게 한 팀으로 부리나”

한 명의 천재보다 역할 나눈 팀이 나을 때가 많다.

  • OMCtmux 화면을 쪼개 여러 AI(codex·gemini·grok)를 실제 프로세스로 띄우는 팀 런타임.
  • 내 패턴비싼 모델(Claude)에 지휘·검수를, 격리된 워커(Codex)에 실제 글쓰기를 맡겨 “한 모델이 다 하다 맥락이 오염되는” 문제를 모델 경계로 끊는다.
flowchart LR
    작업["작업 요청"] --> 지휘["Claude<br/>(지휘·검수)"]
    지휘 -->|작업 위임| 워커["Codex 워커<br/>(격리된 글쓰기)"]
    워커 -->|결과 제출| 지휘
    지휘 -->|합격만 통과| 완료["완료"]

트레이드오프: Codex는 단일 에이전트 중심(협업은 나중에 보조로). 팀 잘 부리는 도구는 외부 환경 의존이 약점이다 — OMC 팀 기능은 tmux·외부 CLI가 없으면 핵심 가치가 통째로 사라진다. fable-ish는 팀 개념 자체가 없다.

[!example] 여기서 배울 점 “한 AI에게 다 시키지 말고 일을 쪼개 다른 AI에게 검수시켜라.”


5. 가드레일 / 안전 — “AI가 사고 치는 걸 어떻게 막나”

AI에게 컴퓨터를 맡기면 “전부 삭제” 같은 위험 명령도 실행할 수 있다. 그래서 안전엔 두 얼굴이 있다 — 결과를 검증하는 안전(맞는지 확인)과 행동을 사전 차단하는 안전(못 하게 막기).

flowchart TB
    안전["안전의 두 얼굴"] --> 검증["결과 검증<br/>(맞는지 확인)"]
    안전 --> 차단["행동 차단<br/>(못 하게 막기)"]
    검증 --> ex1["ouroboros: 최고 수준"]
    차단 --> ex2["Codex: 4겹 차단<br/>(샌드박스·규칙엔진·Guardian·fail-closed)"]
    차단 --> ex3["ouroboros: 약함<br/>(권한 차단을 호스트에 떠넘김)"]
  • Codex — 안전을 네 겹으로 쌓았다. OS 격리 상자(샌드박스) 3종 + 위험 규칙 엔진(Starlark)으로 git add . && rm -rf /처럼 끼워 넣은 나쁜 명령까지 쪼개 검사 + 사람 승인 자리를 **검토 AI(Guardian)**가 대신 보되 의심스러우면 무조건 막는(fail-closed) 쪽.
  • gajae-code — “완료를 sha256 영수증으로 증명”하고 직접 편집을 금지해 흔적을 남긴다.

트레이드오프: ouroboros검증은 최고지만 실행 권한 차단은 약하다. 구현 에이전트에 사실상 무제한 권한을 주고 파괴적 명령 차단을 호스트에 떠넘긴다. 또 차단을 빡빡하게 걸수록 AI가 자주 멈춰 사람에게 물어 느려진다 — Codex의 4겹은 그만큼의 마찰을 산 것.

[!example] 여기서 배울 점 안전은 “결과 검사”와 “행동 차단”이 서로 다른 일이다. 둘 다 있어야 진짜 안전하다.


6. 검증 루프 — “다 했다는 말을 어떻게 믿나”

AI는 종종 “끝냈습니다”라고 거짓 선언한다. 핵심 원리는 **“자기가 한 일을 자기가 합격시키지 못하게(자체 승인 금지) 한다”**이다.

  • 내 패턴 — 이 원칙을 산문이 아니라 validate.mjs·gate.mjs 같은 실제 코드로 강제, 통과 못 하면 강제 종료(exit 2).
  • fable-ish — 작지만 핵심은 같다. “코드 바꿔놓고 검증 없이 끝내려 하면 실제로 막는다.”
  • OMC — 검수 전담 AI(critic)가 “잘못 합격시키면 비용이 10~100배”라는 비대칭 논리로 깐깐하게 본다.
flowchart LR
    AI["AI: '다 했어요'"] --> 게이트{"제3자 검증<br/>(자체 승인 금지)"}
    게이트 -->|통과| 완료["완료 선언 허용"]
    게이트 -->|실패| 차단["exit 2<br/>완료 차단"]
    차단 --> AI

트레이드오프: 내 패턴만 최고점인 건 검증 독립성을 코드로 못 박았기 때문. 나머지의 공통 약점은 검증이 “AI가 AI를 심판(LLM-as-judge)“하거나 정규식(패턴 매칭)에 의존한다는 점이다. fable-ish는 자기가 비판한 정규식 한계를 그대로 안고(2회 막은 뒤엔 무조건 통과), Claude Code·Codex조차 “컴파일·테스트 통과”를 핵심 엔진이 강제하진 않는다.

[!example] 여기서 배울 점 “다 했어요”를 믿지 말고 증거를 요구하라 — 그 검사는 일한 사람이 아닌 제3자가 해야 한다.


7. 자기개선 / 반복 — “도구가 스스로 똑똑해지나”

가장 미성숙한 축이다. 이상은 “AI가 자기 코드를 스스로 고쳐 진화”이지만 현실은 대부분 못 미친다.

  • OMC — 여러 변형을 만들어 토너먼트로 우승작을 고르는 진화 엔진. 평가자 점수 조작 방지(sealed_files)까지 둠.
  • ouroboros — 이름값대로 평가 결과를 다음 세대 설계의 씨앗으로 되먹이는 진짜 루프.

트레이드오프: Claude Code·Codex·내 패턴은 “기억은 쌓되 스스로 진화하진 않는다”(Codex 기억 기능은 실험 단계, 기본 꺼짐). 자기개선을 켜면 매 반복마다 AI를 여러 번 호출해 비용·시간이 크게 든다. 그래서 대부분 “사람이 회고하고 다음 버전을 직접 재설계”하는 수동 방식(내 패턴 v1→v2)에 머문다 — 자동 진화는 비싸고 위험해 아직은 사람이 운전대를 쥐는 게 합리적.

[!example] 여기서 배울 점 지금은 “사람이 실패를 기록하고 다음에 반영”하는 회고 습관이 가장 현실적인 자기개선이다.


8. 상태 / 영속성 — “껐다 켜도 기억이 남나”

대화창을 닫으면 AI는 기억을 잃는다. 영속성은 그 기억을 디스크에 붙들어 두는 능력이다.

  • Codex — 작업 기록(jsonl)·상태(SQLite)·기억·스레드를 층층이 저장.
  • ouroboros — **모든 사건을 순서대로 기록(이벤트 소싱)**해 재부팅 후에도 되감아 작업을 그대로 복원·재현한다. 은행 거래 내역처럼 “무슨 일이 왜 일어났는지” 감사 가능.
  • OMC — 의사결정 맥락을 git 커밋 기록에 영구히 새긴다.
flowchart LR
    기억["기억 저장 방식"] --> md["마크다운·파일<br/>(Claude Code·내 패턴)"]
    기억 --> db["DB·이벤트 소싱<br/>(Codex·ouroboros)"]
    md --> md2["사람 친화 / 검색·집계 약함"]
    db --> db2["기계 친화 / 복잡·무거움"]

트레이드오프: Claude Code·내 패턴은 마크다운·파일 중심이라 사람이 읽기엔 좋지만 “조건 검색·집계”엔 약하고 지식이 대규모로 쌓이면 한계가 온다. SQLite·이벤트 소싱은 강력하나 복잡·무겁다. 사람 친화(마크다운)냐 기계 친화(DB)냐의 선택.

[!example] 여기서 배울 점 사람이 읽을 메모와 기계가 검색할 데이터는 용도가 다르다.


9. 배포 / 개발자경험(DX) — “설치·사용이 얼마나 편한가”

아무리 좋아도 설치가 어려우면 안 쓴다.

  • Codex단일 실행 파일(별도 의존 없음) + 여러 설치 경로 + 다언어 SDK + 무인 CI 모드 + IDE 연동까지 갖춘 완성된 제품.
  • ouroboros — 526개 테스트·3개 언어 문서로 기업급 완성도.
  • fable-ish — 규모는 작아도 의존성 0·복사만 하면 설치 끝이라는 다른 종류의 편함.

트레이드오프: 내 패턴은 개인용이라 문서와 코드가 어긋난다(계획을 구현으로 과대 기록). fable-ish는 기능이 작아 매뉴얼·명령어 불일치 같은 거친 면이 있다. DX 만점엔 막대한 다듬기 노동이 든다 — Codex의 매끄러움은 거대한 팀·시간의 산물이라 개인·베타 도구가 가장 따라잡기 어렵다.

[!example] 여기서 배울 점 “잘 만드는 것”과 “남이 쉽게 쓰게 만드는 것”은 별개의 노동이고, 후자가 더 오래 걸린다.


10. 철학 / 차별점 — “이 도구만의 한 방은 무엇인가”

점수가 높다는 건 **“흉내 낼 수 없는 자기만의 사상이 있다”**는 뜻이다(거의 전부 만점에 가깝다).

[!note]- 펼쳐보기: 7개 도구의 한 방 한 줄 요약

  • Claude Code — “하네스를 만드는 하네스.” 확장 표면을 1급 기능으로 만들어 도구를 도구로 재생산.
  • Codex — “위험 명령을 분해해 가장 엄격한 규칙 적용.” 끼워넣기 공격까지 잡고 사람 승인 자리에 검토 AI.
  • OMC — “잘못 합격이 10~100배 비싸다”는 비대칭 비용관으로 적대적 검수를 정당화, 결정 맥락을 git 역사에 영속화.
  • gajae-code — “수학이 준비됐다 할 때만 코딩 시작.” 모호함을 점수로 재 임계값 넘기 전엔 실행 차단.
  • ouroboros — “프롬프트 그만, 명세를 써라.” 막연함을 수식(1-Σ)으로 정량화해 게이트 통과해야 코드 시작.
  • fable-ish — “관찰 가능한 검증 통과 전엔 완료 금지” + 자기 한계까지 정직하게 문서화하는 역발상.
  • 내 패턴 — “Claude는 지휘·검증, Codex는 격리된 변환기” 이중모델 비대칭 분업으로 맥락 오염 차단.

트레이드오프: 철학은 양날의 검이다. gajae·ouroboros의 “준비될 때까지 시작 안 함”은 답답할 만큼 신중하고, Claude Code의 “확장이 곧 철학”은 무한히 커질 복잡도를 부른다. 뚜렷한 사상은 안 맞는 상황에선 곧장 단점으로 뒤집힌다.

[!example] 여기서 배울 점 좋은 도구는 “기능 목록”이 아니라 “세상을 보는 한 문장”을 가진다. 그 문장이 모든 설계 결정을 설명한다.


핵심 정리

10개 축 한눈에 — 누가 강하고, 그 대가는 무엇인가

가장 강한 곳대가(트레이드오프)
1. 아키텍처/포지셔닝Codex·ouroboros·OMC·fable-ish또렷할수록 덩치·학습곡선
2. 컨텍스트대부분 5점(fable-ish 예외)정교한 규칙이 설명서 비대화
3. 툴/확장성Claude Code·Codex·ouroboros확장 많을수록 진입 장벽 ↑
4. 오케스트레이션OMC·ouroboros·내 패턴팀 기능은 외부 환경(tmux·CLI) 의존
5. 가드레일/안전Codex·gajae-code차단 빡빡할수록 느려짐(마찰)
6. 검증 루프내 패턴빡빡한 검증 = 비용·지연 증가
7. 자기개선OMC·ouroboros(그래도 4점)자동 진화는 비싸고 위험
8. 상태/영속성Codex·OMC·gajae·ouroborosDB는 강력하나 복잡·무거움
9. 배포/DXCodex매끄러움엔 거대한 다듬기 노동
10. 철학/차별점거의 전부강한 사상은 안 맞는 상황엔 단점

목적별 추천 — “이게 궁금하면 여기를 봐라”

[!note] 무엇이 궁금하냐에 따라

  • 사고 방지(안전) → Codex(4겹 차단), gajae-code(영수증 증명)
  • “다 했다” 거짓말 걱정 → 내 패턴(코드 강제 게이트), fable-ish(경량 검증)
  • 여러 AI를 팀으로 → OMC(실제 멀티 CLI 팀), 내 패턴(지휘/검수 분업)
  • 껐다 켜도 이어서 일하기 → Codex, ouroboros(완전 재현), OMC
  • 막연한 아이디어 정리부터 → ouroboros, gajae-code(모호함 게이팅)
  • 설치·사용이 쉬운 완성품 → Codex(단일 바이너리 제품)

관통하는 교훈 셋

  • 절제가 실력이다 — 정보·기능·권한을 “필요한 만큼만” 줄 때 품질이 오른다(컨텍스트·툴·가드레일 축).
  • 자기 일은 남이 검사한다 — 자체 승인 금지·적대적 검수가 거짓 완료를 막는 거의 유일한 길(검증·오케스트레이션 축).
  • 또렷한 철학엔 또렷한 청구서가 따른다 — 모든 강점은 어딘가에서 마찰·비용·복잡도를 대가로 산다. 공짜 장점은 없다.

실제 예시

검증 루프(6번 축)의 핵심은 “자체 승인 금지”가 산문이 아니라 코드로 강제된다는 점이다. 위험 명령 차단(5번 축)은 Codex가 “좋은 명령에 끼워 넣은 나쁜 명령”을 분해해 잡는다.

[!note]- 펼쳐보기: 전체 코드 예시 (내 패턴 검증 게이트 + Codex 명령 분해)

// validate.mjs (내 패턴) — 검증 실패 시 "완료" 선언 자체를 막는다
// 통과 못 하면 exit 2로 프로그램 강제 종료 → 거짓 완료 차단
const passed = runChecks(); // 컴파일/테스트/규칙 검사
if (!passed) {
  console.error("검증 실패: 완료 선언 불가");
  process.exit(2); // 0이 아닌 종료코드 = 게이트가 막았다는 신호
}
# Codex의 규칙 엔진(Starlark)이 분해해서 검사하는 대상 예시
git add . && rm -rf /     # 앞은 안전, 뒤는 파괴적 → 분해 후 뒤쪽을 차단
# 한 줄로 합쳐도 토큰 단위로 쪼개 가장 엄격한 규칙을 적용한다

요약 & 셀프체크

  • 7개 하네스를 10개 축으로 평가하면 **만점은 “크다/많다”가 아니라 “정체성과 절제가 또렷하다”**에서 나온다.
  • 안전은 “결과 검증”과 “행동 차단”이 다른 일이고, 검증은 일한 당사자가 아닌 제3자가 해야 믿을 수 있다.
  • 모든 강점은 마찰·비용·복잡도라는 청구서를 동반한다 — 공짜 장점은 없다.

[!question] 스스로 답해보기

  1. “확장성이 좋다”는 칭찬이 동시에 어떤 단점을 뜻할 수 있나? (힌트: 진입 장벽)
  2. ouroboros는 검증은 최고인데 왜 가드레일 점수는 낮을까? “안전의 두 얼굴”로 설명해보라.
  3. 자기개선(7번 축)이 대부분 도구에서 아직 약한 가장 현실적인 이유는?

연결