Codex CLI와 Claude Code 커스터마이징에서 핵심은 orchestration layer 구조

개요

oh-my-codex, oh-my-claudecode, claw-code를 묶어 보면 에이전트형 코딩 도구는 모델 자체보다 “운영체제 같은 orchestration layer”로 확장된다는 결론으로 수렴한다. 여기서는 Codex CLI와 Claude Code가 skill, agent, sub-agent, tmux worker, PR review, verification loop 같은 자동화를 붙일 수 있는 이유와 바닥 런타임 구조를 층으로 정리한다

핵심은 모델 튜닝이 아니라 다음 조합으로 행동을 바꾸는 접근이다

상위 지시문
skill, prompt, agent 카탈로그
상태 파일과 산출물 디렉터리
hook 또는 세션 부트스트랩
서브에이전트와 tmux worker
검증, 리뷰, 커밋, PR 프로토콜

에이전트형 코딩 도구의 6개 층

Codex CLI, Claude Code, claw-code 같은 도구는 보통 아래 6개 층으로 이해할 수 있다

1 모델 레이어

추론과 계획 수립, 코드 생성은 LLM이 담당한다. 다만 모델은 단독으로 일하지 않고 “현재 시스템 프롬프트 + 사용자 입력 + 사용 가능한 도구 목록 + 현재 상태”를 보고 행동한다. 성능은 모델 자체뿐 아니라 모델을 둘러싼 운영 구조에 크게 좌우된다

2 프롬프트 조립 레이어

시스템 프롬프트는 정적 문자열이 아니라 동적으로 조립된다. 예를 들면 기본 시스템 프롬프트, OS/날짜/작업 디렉터리, 프로젝트 지침 파일, git 상태, 설정 파일, 현재 활성 mode, skill로 주입된 추가 지시 같은 요소가 합쳐진다. 이 레이어가 강하면 행동 변화 폭도 커진다

3 툴 레이어

모델은 셸을 임의로 타이핑하는 존재가 아니라 대개 구조화된 도구 호출자다. 파일 읽기/쓰기/패치, 셸 실행, 웹 검색/가져오기, MCP 서버 호출, 질문하기, 태스크 생성, 서브에이전트 생성, 작업 계획 업데이트 같은 도구가 여기에 해당한다. 툴 레이어가 넓을수록 모델은 질답기를 넘어 실제 작업 에이전트가 된다

4 런타임 제어 레이어

툴 호출과 세션을 관리하는 부분이다. 권한 정책, 샌드박스, 툴 호출 전후 hook, 세션 저장/재개, 실패 처리, 컨텍스트 압축, usage/cost 추적 같은 요소가 포함된다. 이 레이어가 있어야 “실행 가능한 agent”가 된다

5 상태/메모리 레이어

장시간 작업을 하려면 대화 밖에 상태를 저장해야 한다. planning 중 여부, spec 확정, 어떤 worker가 어떤 task를 맡는지, review 결과, 다음 단계가 읽어야 할 handoff 문서 같은 정보를 파일이나 별도 스토어에 보관해야 세션이 끊겨도 이어갈 수 있다

6 오케스트레이션 레이어

마지막 층은 어떻게 일하게 만들 것인가다. 인터뷰를 먼저 할지, 계획을 승인할지, 바로 실행할지, review와 verification을 분리할지, 여러 worker로 병렬화할지 같은 결정이 이 층을 좌우한다. oh-my-codex와 oh-my-claudecode는 이 층을 강하게 설계한 프로젝트다

Claude Code가 확장 가능한 이유, hook surface

Claude Code 관련 저장소와 예제를 보면 커스터마이징 포인트가 비교적 명확하게 드러난다. 지침 파일 로드, settings 계층 구조, hook 이벤트, plugin 시스템, agent/skill/command 자산 로드, permission/sandbox 설정, subagent/task/worktree 관련 기능 같은 표면이 제공된다. Claude Code는 단순 터미널 챗봇이라기보다 확장 가능한 agent runtime에 가깝다

특히 hook이 강력하다. 공개 변경 로그와 예제에서 보이는 이벤트/기능은 예를 들어 PreToolUse, PostToolUse, PostToolUseFailure, TaskCreated, WorktreeCreate, SessionEnd, StopFailure, PermissionDenied 같은 것들이다. 이 구조라면 모델이 tool을 쓰기 직전에 개입하고, tool 결과 이후 후처리를 하며, 특정 이벤트에서 외부 스크립트나 플러그인이 런타임을 바꿀 수 있다

그래서 oh-my-claudecode는 hook 지점을 이용해 magic keyword 감지, skill 자동 주입, persistent mode 강제, 팀 상태 추적, learned skill 재주입 같은 일을 수행한다. OMC는 Claude Code 엔진을 다시 만드는 것이라기보다 event middleware에 orchestration policy를 주입하는 성격에 가깝다

또한 plugin/command/agent/skill이 분리돼 있어 리뷰용 에이전트만 추가하거나 특정 PR review command만 추가하거나 tool 차단/보강용 hook를 추가하는 식으로 부분 확장이 가능하다. 즉 Claude Code는 원래부터 런타임과 확장 생태계 형태로 설계돼 있고, OMC는 그 표면을 적극 활용한다

Codex가 확장 가능한 이유, AGENTS.md 중심 규약과 부트스트랩

Codex는 Claude Code와 결이 조금 다르다. 관찰 가능한 구조상 Codex에서 중요한 축은 AGENTS.md 같은 상위 운영 지침, native subagent, MCP/shell/patch/state update 같은 구조화된 tool surface, 세션별 프롬프트 컨텍스트다. 특히 AGENTS.md는 단순 참고 문서가 아니라 세션 전체 행동 규약을 바꾸는 “항상 로드되는 운영 계약”처럼 동작한다

그래서 oh-my-codex는 setup 시 .codex/prompts, .codex/skills, .codex/agents, .codex/config.toml, AGENTS.md 같은 자산을 설치한다. hook보다는 부트스트랩 단계에서 로드되는 orchestration brain이 핵심이다

oh-my-codex는 Codex를 대체하지 않고 Codex 위에 더 강한 시작 프롬프트, 상황별 skill 자동 라우팅 규칙, planning/execution/review 표준 workflow, .omx/ 아래 상태와 산출물 구조, team runtime을 덧붙인다. Codex에서 AGENTS.md에 넣을 수 있는 내용은 어떤 상황에서 어떤 skill을 쓸지, 언제 planning을 강제할지, 언제 subagent를 병렬로 돌릴지, 언제 verification 없이 종료하지 말지, 어떤 산출물이 planning 완료 조건인지 같은 세션 운영법이다

정리하면 Claude Code는 event-driven runtime customization 쪽에 강하고, Codex는 prompt/runtime scaffolding 쪽에 강하다. 그래서 OMC는 hook 중심, OMX는 AGENTS.md + setup + team runtime 중심의 차이가 생긴다

claw-code가 보여주는 바닥 런타임 구조

claw-code는 이런 도구가 내부적으로 어떤 부품으로 구성되는지 가장 구체적으로 보여준다. Claude 계열 CLI agent harness를 Rust로 구현한 프로젝트이며, 다음 구조가 드러난다

시스템 프롬프트 조립기

runtime/src/prompt.rs는 시스템 프롬프트가 정적 문자열이 아니라 조립물임을 보여준다. 작업 디렉터리를 기준으로 지침 파일을 탐색하고, git 상태/diff를 수집하며, 환경 정보와 설정 파일을 로드하고, instruction file을 예산 내에서 잘라 넣는다. 결과적으로 AGENTS.md, CLAUDE.md, skill, config를 바꾸는 것만으로 행동이 크게 달라진다

Conversation runtime

runtime/src/conversation.rs는 agent loop에 해당한다. user input을 세션에 추가하고, 시스템 프롬프트와 메시지들을 모델에 전달하며, 모델이 요청한 tool use를 수집한다. tool 전 hook 실행, permission 판단, tool 실행, tool 후 hook 실행, 결과를 세션에 적재, 필요 시 compaction 수행까지 이 레이어가 담당한다. 모델은 여기서 운영되는 존재다

Session persistence

runtime/src/session.rs는 세션 저장과 fork를 담당한다. 세션은 메시지 로그를 가지며 compaction 메타데이터와 fork provenance도 저장한다. 따라서 단일 대화창을 넘어서 세션 분기, 장시간 작업, 재개가 가능해진다

Tool registry

tools/src/lib.rs는 단순 파일/쉘 도구만 있는 게 아니고 1급 도구로 올라와 있는 것들이 있다. 예를 들면 Skill, Agent, AskUserQuestion, TaskCreate, TaskGet, TaskList, TeamCreate, MCP, TodoWrite, WebSearch, WebFetch 같은 항목이다. 모델은 skill을 불러오고 agent를 띄우고 사용자에게 질문하고 task를 만들고 team을 만들며 외부 시스템에 연결할 수 있다. 이것이 oh-my-*가 붙을 수 있는 이유다

Permission / sandbox / hook

permissions.rs, permission_enforcer.rs, plugins/src/hooks.rs를 보면 권한 모드, allow/deny/ask 규칙, tool 전후 hook 실행, hook에 의한 차단 같은 정책 집행이 모델 바깥에서 이뤄진다. 즉 에이전트의 동작은 모델만이 아니라 툴 정책과 hook 정책에 의해 결정된다. 그래서 “에이전트 OS” 같은 계층화가 가능하다

skill은 무엇인가, workflow DSL에 가깝다

skill은 흔히 실행 코드로 오해되는데 대개 “강하게 구조화된 운영 프로토콜 문서”에 가깝다. 예를 들면 deep-interview, ralplan, ralph, autopilot, team 같은 skill은 언제 사용해야 하는지, 언제 사용하면 안 되는지, 어떤 단계로 흘러가야 하는지, 어떤 아티팩트를 남겨야 하는지, 다음 단계로 무엇을 넘겨야 하는지, 어떤 도구나 에이전트를 써야 하는지를 정의한다

함수처럼 강력하게 보이는 이유는 주변 운영층이 있기 때문이다. keyword detector가 skill을 자동으로 켜고, AGENTS가 상황에 따라 반드시 써야 하는 skill을 강제하며, state 파일이 skill 활성 상태를 기록하고, stop hook이 중도 종료를 막고, team runtime이 실제 worker를 띄운다. 결론적으로 skill은 workflow DSL이고 실제 자동화는 런타임과 supervisor가 수행한다

oh-my-*의 핵심 방법론

두 프로젝트는 겉으로는 기능이 많아 보여도 핵심 방법은 몇 가지로 압축된다

표준 파이프라인 강제

대표 파이프라인은 deep-interview -> ralplan -> team/ralph -> review/verify다. 의미는 deep-interview로 요구사항 명확화, ralplan으로 설계와 트레이드오프 합의, team으로 병렬 실행, ralph로 끈질긴 단일 책임 completion loop, review/verify로 별도 승인 lane을 만드는 것이다. 중요한 점은 바로 구현하지 않고 먼저 명확화와 계획을 강제한다는 것이다

대화가 아니라 파일 아티팩트로 이어가기

두 프로젝트 모두 .omx/ 또는 .omc/ 아래에 산출물을 남긴다. context snapshot, spec, PRD, plan, task graph, handoff doc, state file, mailbox, review verdict 같은 형태다. 이렇게 해야 세션이 끊겨도 재개 가능하고 worker끼리 handoff가 가능하며 검증 기준이 대화 밖에 남는다

작성 lane과 승인 lane 분리

자동화 품질을 좌우하는 포인트다. writer/executor, reviewer, verifier, security reviewer, git finalizer 같은 식으로 분리해 자기가 만든 것을 같은 맥락에서 즉시 승인하지 않게 설계한다. 분리가 없으면 자동화는 빨라질 수 있지만 신뢰가 떨어진다

native subagent와 tmux worker 역할 분리

짧고 bounded한 병렬 작업은 native subagent로, 길고 durable한 병렬 작업은 tmux pane에 띄운 실제 CLI worker로 나눈다. 모델 내부 subagent만으로 모든 걸 처리하면 긴 작업 지속성이 약하고 관측성과 재시작성이 떨어지며 충돌 관리가 어려워진다. 오래 가는 작업은 실제 프로세스로 분리하는 편이 낫다

tmux는 단순 UI가 아니라 supervisor

tmux는 창을 예쁘게 보는 도구가 아니라 worker 프로세스를 유지하고 worker별 독립 CLI 세션을 보장하며 leader/worker 분리, pane별 상태 관찰, 죽은 worker 재기동, 트리거 전달까지 담당하는 쪽에 가깝다. 여기서 진짜 source of truth는 pane이 아니라 상태 디렉터리다. pane은 실행 표면이고 state dir은 제어면이라는 관점이 중요하다

PR, 리뷰, 머지 자동화는 무엇을 설계해야 하는가

PR 자동화의 본질은 GitHub API 호출 자체가 아니다. 필요한 것은 Git 조작 능력, 리뷰 프로토콜, 산출물과 검증 근거, 그리고 finalization lane이다

Git 조작 능력: branch, commit, diff, merge/cherry-pick/rebase
리뷰 프로토콜: 무엇을 bug로 볼지, 무엇을 style로 볼지, 어떤 기준으로 approve/request changes를 할지
산출물과 검증 근거: 어떤 변경이 있었는지, 어떤 테스트를 했는지, 남은 리스크가 무엇인지

병렬 팀 작업을 하면 runtime 중간 커밋이 많이 생긴다. 이걸 그대로 최종 히스토리로 쓰면 안 된다. 그래서 commit hygiene 같은 레이어가 필요하다. runtime 커밋은 임시 scaffolding으로 간주하고, 최종 semantic commit boundary를 다시 구성하며, conventional commit 기준으로 다시 정리한다. 코드 작성 자동화와 git history 정리 자동화는 별도 문제로 분리해 다뤄야 한다

사람이 최소한만 개입하는 자동화 시스템을 만들려면

목표는 skill 등 Codex/Claude 구조 이해, 설계부터 개발 리뷰 머지까지 자동화 이해, 그리고 사람이 최대한 덜 개입하는 개발 파이프라인 구축이다. 이를 위해 먼저 skill이 아니라 control plane을 설계해야 한다

control plane부터 설계

정해야 하는 것은 표준 workflow, 상태 스키마, 산출물 디렉터리 구조, worker 제어 방식, review/verify 규칙, stop/retry/resume 정책이다. skill은 이 위에 올라가는 workflow entrypoint다

꼭 파일로 관리해야 할 상태

최소한 context, spec, plans, tasks, handoffs, mailbox, worker status, review verdict, commit hygiene report 같은 파일 아티팩트를 남겨야 한다. 이게 없으면 긴 작업 자동화는 거의 반드시 불안정해진다

reviewer 분리

executor, code reviewer, security reviewer, verifier, git finalizer는 분리하는 걸 권장한다. 분리가 없으면 대충 된 것처럼 보이지만 실제로는 누락된 상태, 자기 합리화, 테스트 없이 완료 선언이 반복되기 쉽다

tmux / worktree는 장기적으로 거의 필수

무인에 가까운 자동화를 원하면 durable worker, 독립 프로세스, 분리된 작업 디렉터리가 필요하다. 그래서 짧은 작업은 native subagent, 긴 작업은 tmux + worktree가 현실적인 선택이다

알림/관측은 에이전트 밖으로 분리

human interface는 터미널 채팅이 아니라 방향 제시가 되어야 한다. 상태 알림, worker heartbeat, PR 상태, CI 결과, 질문 escalation 같은 것들은 agent context 바깥으로 빼는 event plane이 필요하다. 장기적으로는 orchestration plane, execution plane, notification plane을 분리하는 편이 좋다

마무리

정리하면 Codex와 Claude Code는 단순 챗봇이 아니라 동적 시스템 프롬프트 조립기, 구조화된 툴 호출기, 세션/권한/훅 런타임, 상태 저장기를 가진 agent platform이다. 커스터마이징은 모델 튜닝이 아니라 운영층 설계로 이뤄지고, skill만으로는 부족하다. skill 활성, persistent state, stop/retry enforcement, worker supervision, artifact handoff가 함께 있어야 한다

진짜 핵심은 control plane이다. 어떤 모델을 쓰는지보다 어떤 구조로 명확화하고, 어떤 기준으로 계획을 승인하고, 어떤 방식으로 병렬 실행하고, 누가 검증하고, 어떻게 최종 정리하는지가 품질을 좌우한다. 그리고 사람이 개입을 최소화하면서 기획부터 개발 리뷰 머지까지 자동화를 목표로 한다면 시작점은 skill 모음이 아니라 orchestration architecture 설계다. 먼저 workflow, state schema, artifact layout, worker runtime, review/verification contract, notification/escalation plane을 정하는 접근이 정답에 가깝다

개요#

에이전트형 코딩 도구의 6개 층#

1 모델 레이어#

2 프롬프트 조립 레이어#

3 툴 레이어#

4 런타임 제어 레이어#

5 상태/메모리 레이어#

6 오케스트레이션 레이어#

Claude Code가 확장 가능한 이유, hook surface#

Codex가 확장 가능한 이유, AGENTS.md 중심 규약과 부트스트랩#

claw-code가 보여주는 바닥 런타임 구조#

시스템 프롬프트 조립기#

Conversation runtime#

Session persistence#

Tool registry#

Permission / sandbox / hook#

skill은 무엇인가, workflow DSL에 가깝다#

oh-my-*의 핵심 방법론#

표준 파이프라인 강제#

대화가 아니라 파일 아티팩트로 이어가기#

작성 lane과 승인 lane 분리#

native subagent와 tmux worker 역할 분리#

tmux는 단순 UI가 아니라 supervisor#

PR, 리뷰, 머지 자동화는 무엇을 설계해야 하는가#

사람이 최소한만 개입하는 자동화 시스템을 만들려면#

control plane부터 설계#

추천 표준 workflow#

꼭 파일로 관리해야 할 상태#

reviewer 분리#

tmux / worktree는 장기적으로 거의 필수#

알림/관측은 에이전트 밖으로 분리#

마무리#

개요