AI-SDLC 실천: Claude Code와 Codex의 여섯 가지 능력 활용

Claude Code와 Codex는 모두 곧바로 프로세스 구축에 사용할 수 있는 여섯 가지 능력을 제공합니다: AGENTS.md/CLAUDE.md, Skill, Subagent, Hook, MCP, 권한과 샌드박스.

이 글에서는 세 가지를 다룹니다:

- 여섯 가지 능력 각각의 역할과 적용 시나리오;

- 우리가 AI-SDLC의 다섯 단계에서 이들을 각각 어떻게 활용했는지;

- 동일한 엔지니어링 체계가 어떻게 Claude Code와 Codex를 동시에 지원하는지.

본문에 나오는 플랫폼 동작은 양측의 2026년 11월까지의 공식 문서를 기준으로 합니다.

Agent = Model + Harness: Harness가 관리하는 것은 컨텍스트 윈도

Coding Agent는 두 부분으로 나눌 수 있습니다: Model은 추론을 담당하고, Harness는 모델 외의 모든 것을 담당합니다. 여기에는 대화 루프, 도구 호출, 컨텍스트의 조립과 압축, subagent의 생성과 회수, 권한 확인, 외부 연결이 포함됩니다.

Claude Code와 Codex의 Harness는 이미 상당히 완성되어 있어, 이 부분들은 다시 직접 만들 필요가 없습니다.

우리가 해야 할 일은 먼저 호스트의 능력을 파악하고 최대한 재사용하며, 호스트에 없는 부분만 보완하는 것입니다:

- CLI: 워크플로를 추진하고 Agent에 보조 도구를 제공합니다(제00편에서 호스트, Agent와의 분업을 다루었습니다);

- 지식 베이스: 아키텍처 규범과 코딩 규칙을 축적하여 Agent가 생성하는 코드의 품질을 높입니다.

Harness의 가장 핵심적인 작업은 매 라운드 모델에 보내는 컨텍스트 윈도 안에 무엇을 담을지 결정하는 것입니다. 시스템 프롬프트, AGENTS.md/CLAUDE.md, 도구 정의, skill 목록, 이력 메시지, 도구 결과가 모두 같은 공간을 두고 경쟁합니다.

양측의 공식 문서에는 예산 수치가 적지 않습니다:

- Codex가 AGENTS.md를 결합할 때 합계 기준 기본적으로 앞부분 32 KiB만 읽고, skill의 초기 목록은 기본적으로 최대 컨텍스트 윈도의 2%를 차지합니다;

- Claude Code는 단일 CLAUDE.md를 200줄 이내로 유지할 것을 권장하며, skill의 설명이 목록에서 1,536자를 초과하면 잘립니다.

이 수치들은 호스트 스스로도 윈도 안의 모든 내용을 엄격하게 통제하고 있음을 보여줍니다. AI-SDLC가 해야 할 일은 Harness가 제공하는 능력을 이용해, 윈도가 각 단계에서 해당 단계에 필요한 것만 담도록 하는 것입니다.

요구 이해 단계에서는 이전 작업의 컴파일 로그를 가지고 있어서는 안 되고, 리뷰 역할은 개발 역할의 시행착오 과정을 보아서는 안 됩니다. 윈도 안의 무관한 내용이 적을수록 Agent는 더 집중하고, 판단도 더 안정적입니다.

여섯 가지 능력: 각각 윈도의 어느 위치에 작용하는가

AGENTS.md/CLAUDE.md는 윈도에 상주하고, skill은 사용할 때 들어오며, subagent는 별도 윈도를 열고, hook은 정해진 시점에 내용을 보충하며, MCP는 외부에서 내용을 끌어오고, 권한과 샌드박스는 윈도 밖에서 호스트가 강제로 집행합니다.

AGENTS.md/CLAUDE.md: 매 라운드 윈도 안에 있음

프로젝트 루트 디렉터리의 AGENTS.md/CLAUDE.md는 세션 시작 시 윈도에 들어오고, 이후 매 라운드 요청에 함께 포함됩니다.

컨텍스트 압축 시 이는 이력 대화와 함께 요약되지 않고 원래대로 윈도에 다시 들어갑니다: Claude Code의 공식 문서에는 디스크에서 다시 주입한다고 명시되어 있고, Codex의 오픈소스 구현도 압축 후 AGENTS.md를 다시 컨텍스트에 삽입합니다.

예외는 온디맨드 로딩 부분입니다. Claude Code에서는 하위 디렉터리의 CLAUDE.md와 paths: 가 붙은 규칙은 Agent가 해당 디렉터리의 파일을 읽거나 쓸 때에야 로드되며, 압축 시에는 일반 대화와 함께 요약되고, 다음에 관련 파일을 접할 때 다시 로드됩니다. Codex는 저장소 루트부터 현재 디렉터리까지 경로상의 AGENTS.md를 읽어 단계별로 결합합니다.

- 적합: 매 세션마다 반드시 알아야 하는 소량의 하드 규칙, 그리고 프로세스 입구가 어디인지;

- 부적합: 특정 단계에서만 쓰는 방법. 매 라운드 윈도를 차지하므로, 쓰이지 않는 라운드에서는 낭비입니다.

Skill: 사용할 때 전체를 읽음

양측의 skill은 모두 Agent Skills 개방 표준을 따릅니다. 평소에는 윈도 안에 skill의 이름과 설명만 있고, 모델이 사용해야 한다고 판단할 때 SKILL.md 전체를 읽어 들입니다.

호출 방식은 두 가지입니다: 모델이 설명에 따라 자동으로 선택하거나, 명시적으로 호출합니다(Claude Code는 /이름 을 입력하고, Codex는 $이름 을 입력합니다).

- 적합: 특정 단계의 방법, 템플릿, 체크리스트;

- 부적합: 매번 적용되어야 하는 제약. 모델이 호출하지 않으면 적용되지 않습니다.

프로세스 내의 핵심 단계에서는 자동 트리거를 꺼야 하며, 프로세스가 명시적으로 호출해야 합니다:

- Claude Code: frontmatter에 disable-model-invocation: true 를 설정;

- Codex: agents/openai.yaml에 allow_implicit_invocation: false 를 설정.

Subagent: 하위 작업에 깨끗한 윈도를 제공

subagent는 독립된 윈도에서 작업하고 결과만 메인 세션으로 가져오므로, 메인 윈도가 그것이 읽은 대량의 파일로 가득 차지 않습니다.

양측 모두 사용자 정의 역할을 지원합니다: Claude Code는 .claude/agents/ 아래의 markdown 파일에, Codex는 .codex/agents/ 아래의 TOML 파일에 작성하며, 둘 다 model과 effort를 별도로 지정할 수 있습니다.

- 적합: 병렬 개발, 독립 리뷰, 대량의 파일을 읽어야 하는 검색;

- 부적합: 메인 세션과 빈번하게 주고받아야 하는 작업.

subagent의 마지막 응답은 요약일 뿐이며, 산출물로 삼을 수 없습니다. 역할 파일에는 직무, 입력, 산출물, 금지 항목만 작성하고, 방법은 skill에 남겨 두며 skill 본문을 복제하지 않아야 합니다. 그렇지 않으면 두 내용이 점차 어긋나게 됩니다.

Hook: 정해진 시점에 컨텍스트를 보충하거나 동작을 차단

hook은 호스트가 세션 생명주기의 정해진 시점에 자동으로 실행하는 스크립트입니다. 호스트는 이번 이벤트의 정보(세션, 도구 이름, 파라미터 등)를 JSON으로 스크립트에 전달하고, 스크립트의 출력에 따라 다음 단계를 결정합니다.

양측이 공통으로 가진 시점을 한 세션의 순서대로 나열하면:

- 세션 시작 (SessionStart): 윈도에 컨텍스트 한 단락을 보충;

- 사용자 제출 (UserPromptSubmit): 컨텍스트를 보충하거나, 이번 제출을 가로막아 모델로 들어가지 못하게 함;

- 도구 호출 전 (PreToolUse): 이번 호출을 가로막거나, 파라미터를 고쳐 쓰거나, 컨텍스트 한 단락을 보충. 권한 확인이 필요할 때는 PermissionRequest도 있어 사람을 대신해 승인하거나 거절할 수 있음;

- 도구 호출 후(PostToolUse): 도구는 이미 실행이 끝났으므로 hook이 되돌릴 수 없고, 컨텍스트를 보강하거나 모델에 피드백을 주는 것만 가능하다;

- subagent 시작과 종료(SubagentStart / SubagentStop): 시작할 때 subagent에 컨텍스트를 보강하고, 종료할 때 한 라운드 더 수행하도록 요구할 수 있다;

- 턴 종료(Stop): Agent가 끝나지 않도록 하고 계속하라고 요구할 수 있다;

- 압축 전후(PreCompact / PostCompact): 압축 전에 먼저 기록을 남길 수 있고, 이번 압축을 막을 수도 있으며, 압축 후 이벤트는 기본적으로 기록 용도로만 쓴다. 압축 이후에 내용을 보강하려면 출처가 compact인 세션 시작 이벤트를 사용한다.

정리하면 hook이 할 수 있는 일은 세 가지뿐이다. 컨텍스트 보강, 작업 차단, 계속 요구. 윈도우에 보강되는 내용에도 예산이 있어서, Codex는 기본적으로 hook당 약 2,500 token이다.

- 적합: 세션 시작과 압축 이후에 최소한의 복구 인덱스를 보강하고, 매 라운드 제출 시 현재 단계를 알리며, 명확한 위험 명령을 차단하는 것;

- 부적합: 코드 자동 수정, 프로세스 상태 진행.

hook의 신뢰성에는 한계가 있다. 양쪽 모두 hook에서 오류가 나거나 타임아웃이 나면 기본적으로 도구 호출을 막지 않는다. Codex 문서에는 명확히 적혀 있다. 도구 hook은 유용한 가드레일로 취급하고, 완전한 강제 경계로 보지 말라고.

Claude Code는 개별 hook에 onFailure: "block"을 설정해 실패 시 차단으로 바꿀 수 있지만, Codex 문서에는 대응하는 옵션이 없다. 또한 호스트의 신뢰를 얻지 못한 hook은 아예 실행되지 않는다.

MCP: 외부 사실을 윈도우로 끌어오기

MCP는 요구사항 문서, 디자인 시안, 결함 시스템 같은 외부 소스를 연결하고, Agent가 필요에 따라 도구를 호출해 내용을 윈도우로 읽어 들인다.

- 적합: 외부의 사실 출처를 읽는 것;

- 부적합: 진실 원천 역할을 하는 것.

MCP가 반환하는 것은 이 순간 읽어 들인 내용이며, 불완전할 수도 있고 읽기에 실패할 수도 있다. 도구 정의 자체도 윈도우를 차지하므로 쓰지 않는 도구는 꺼야 하고, Codex는 enabled_tools와 disabled_tools로 범위를 좁힐 수 있다.

권한과 샌드박스: 윈도우 밖의 단단한 경계

권한과 샌드박스는 윈도우에 들어가지 않고, 호스트가 모델 밖에서 강제 집행한다.

Claude Code는 allow, ask, deny 세 가지 규칙을 쓰고 deny, ask, allow 순서로 판정하며, allow는 deny 안에 예외를 열 수 없다. Codex는 샌드박스 모드와 승인 정책으로 범위를 정하고, 다시 명령 접두사 규칙으로 샌드박스 밖 명령을 제어한다.

- 적합: 반드시 지켜야 하는 제약, 예를 들어 특정 디렉터리에 쓰기 금지, 푸시 금지, 네트워크 연결 금지;

- 부적합: 「어떻게 할지」에 대한 방법을 서술하는 것.

여섯 가지 능력을 함께 놓고 보면, 어떤 제약을 어디에 둘지는 그것이 얼마나 신뢰할 만해야 하는지에 달려 있다. 알려주기만 하면 되는 것은 윈도우에 넣어 AGENTS.md/CLAUDE.md나 skill에 맡긴다; 반드시 막아야 하는 것은 권한과 샌드박스에 맡기고 hook은 보충으로만 쓴다; 위반하지 않았음을 반드시 증명해야 하는 것은 다음 절의 Checker에 맡긴다.

우리가 다섯 단계에서 이 여섯 가지 능력을 어떻게 쓰는가

AI-SDLC의 다섯 단계는 윈도우에 담기는 내용이 각기 다르다. 아래에서는 단계별로 각 윈도우가 어떤 능력으로 조립되는지 설명하고, 구체적인 방법은 후속 각 편에서 펼친다.

요구사항 이해(제03편). 단계 skill은 프로세스가 명시적으로 로드한다. 요구사항 문서와 디자인 시안은 MCP를 통해 읽고, 결론을 파일로 남길 때 출처를 함께 붙인다; 읽지 못하면 「소스 사용 불가」로 기록하고 계속하며, 기억으로 보완하지 않는다.

저장소에서 확인할 수 있는 사실은 Agent가 스스로 조회하고, 목표, 범위, 권한 부여 또는 인수 기준을 바꿀 수 있는 질문만 사람에게 가져가 묻는다.

설계 및 검토(제04편). 설계 검토는 검토 subagent에 맡긴다. 그 윈도우에는 설계 자체와, 설계가 참조하는 인터페이스 계약, 컴포넌트, 설계 자료만 들어 있고 설계 작성자의 추론 과정은 넣지 않는다. 그래야 검토 결론이 작성자로부터 독립적이 된다.

개발(제05편). 작업 그래프에 따라 개발 subagent를 파견하고, 각각은 하나의 컨텍스트 목록만 받는다. 어떤 파일을 읽을지, 왜 읽는지를 나열하며, 여기에는 지식 베이스에서 이 코드와 관련된 아키텍처 규범과 코딩 규칙이 포함된다(지식 베이스는 제08편 참조).

subagent를 몇 개 파생할지, 언제 끝낼지는 CLI가 작업 그래프에 따라 계산하며 skill에 맡기지 않는다. 산출물은 먼저 디스크에 쓴 뒤 완료를 보고한다.

검증 및 통합 테스트(제06편). 검토와 테스트는 동일한 동결된 후보 버전에서 병렬로 진행된다. 검토 subagent와 프로세스 게이트는 동일한 Checker를 호출하며, 두 가지 표준이 존재하지 않는다.

전달(제07편). 호스트의 권한 규칙과 프로세스 내 동작별 권한 부여가 두 개의 관문을 구성한다. 푸시, 병합, 테스트 제출은 항목별로 확인하고, 앞 항목의 권한 부여는 다음 항목으로 이어지지 않는다.

단계 횡단(제02편). hook은 세션 시작, 컨텍스트 압축 전후, 매 라운드 제출 시 실행되어 세 가지를 보강한다. 현재 어느 단계에 있는지, 다음에 무엇을 할지, 반드시 읽어야 할 파일이 무엇인지. hook은 경로와 요약만 출력하고 프로세스 상태는 쓰지 않는다.

호스트 밖의 한 조각: Checker

여섯 가지 능력은 모두 Agent가 더 잘하도록 만들 뿐이고, 결과가 맞는지 판단하는 역할을 맡는 것은 하나도 없다. 이 조각은 우리가 CLI에서 채운다. 각 단계의 출구에는 결정론적 검사가 있어 pass 또는 blocked를 출력하고, blocked일 때는 path:line을 붙인다.

Checker는 디스크 위의 산출물만 읽고, 모델이 자기 작업을 어떻게 설명하는지는 보지 않는다. 컴파일과 테스트 통과도 경계를 넘은 수정을 상쇄하지 못한다.

하나의 엔지니어링이 Claude Code와 Codex를 동시에 지원하는 방법

같은 프로세스가 두 호스트 모두에서 쓸 수 있어야 한다. 양쪽에 각각 설정을 따로 쓴다면 몇 달 뒤에는 반드시 어긋나게 된다.

우리의 방식은 이렇다. 역할, skill, hook 같은 설정을 하나의 범용 형식으로 한 번만 쓰고(이하 중립 소스라 칭함), 스크립트로 양쪽에 각각 필요한 파일(이하 프로젝션이라 칭함)을 생성한다.

프로젝트 디렉터리는 대략 이렇다:

<저장소 루트>/ ├── AGENTS.md # 양쪽이 공유하는 진입 파일 ├── CLAUDE.md # 한 줄짜리 @AGENTS.md ├── agents/ # 중립 소스: 역할 정의 ├── skills/ # 중립 소스: 각 단계의 skill ├── docs/ # 지식 베이스: 아키텍처 규범, 코딩 규칙 ├── .claude/ # Claude Code 프로젝션 │ ├── agents/ # sync 생성 │ ├── skills/ # sync 생성 │ └── settings.json # hook과 권한 규칙, 저장소와 함께 커밋 ├── .agents/ │ └── skills/ # Codex가 읽는 skill, sync 생성 └── .codex/ # Codex 프로젝션 ├── agents/ # sync 생성 ├── hooks.json # 저장소와 함께 커밋 └── config.toml # MCP 등 설정

사람은 AGENTS.md, 중립 소스, 지식 베이스만 수정한다. 역할과 skill의 프로젝션은 CLI가 생성하며, 양쪽의 hook 설정은 저장소와 함께 커밋된다.

프로젝션은 어떻게 생성되는가: 세션 시작 시 hook이 sync를 호출

프로젝션은 CLI의 sync 명령으로 생성된다. 양쪽의 세션 시작 hook은 모두 동일한 명령으로 설정되어 sync를 호출한다:

- 중립 소스의 역할과 skill을 읽는다;

- 양쪽 각자의 형식에 맞춰 프로젝션을 작성한다: 역할은 Claude Code의 markdown과 Codex의 TOML로 작성하고, skill은 각각 .claude/skills/ 와 .agents/skills/ 에 넣는다;

- 생성 시 동일 이름 충돌을 검사하고, 한쪽만 지원하는 기능이 어떻게 강등되는지 기록한다.

이렇게 하면 세션을 열 때마다 프로젝션이 자동으로 중립 소스의 최신 버전에 정렬되므로, 누군가 수동으로 동기화하는 것을 기억할 필요가 없다. 중립 소스에서 skill 하나를 수정하면 다음 세션에서 바로 적용된다.

구현 시 처리해야 할 세 가지 세부 사항이 있다:

- 이번 세션에서 즉시 사용할 수 있는가. Claude Code는 보통 세션 시작 hook이 끝나기 전에 skill을 스캔하므로, hook이 새로 작성한 skill이 첫 번째 프롬프트에間に合わない 수 있다. hook이 reloadSkills: true 를 반환하면 Claude Code는 hook 종료 후 다시 스캔한다. 역할 파일의 변경은 Claude Code가 몇 초 안에 감지할 수 있다. Codex는 skill의 변경을 자동으로 감지한다.

- sync를 트리거하는 hook 설정은 sync가 생성할 수 없다. 이는 전체 동기화의 출발점이므로 저장소와 함께 커밋해야 하며, 내용은 CLI를 호출하는 명령 하나로 고정된다. 설정이 바뀌지 않으므로, Codex도 특정 동기화 때문에 이 hook을 다시 심사하도록 요구받지 않는다.

- sync는 빨라야 하고, 실패해도 길을 막지 않아야 한다. 이는 세션 시작 경로에서 실행되며, Claude Code의 첫 번째 응답은 세션 시작 hook이 끝날 때까지 기다려야 한다. 동기화가 실패하면 세션은 평소대로 시작되고, 직전 프로젝션을 사용하며, 사전 점검이 프로젝션이 만료되었음을 보고한다.

sync는 프로젝션 생성 시 세 가지 규칙을 지킨다:

- 프로젝션을 직접 수정하지 않는다: 프로젝션 파일에는 생성 표시가 붙고, 매 동기화마다 중립 소스에 따라 다시 생성되므로 직접 수정한 내용은 덮어씌워진다;

- 동일 이름 충돌은 즉시 실패한다: Codex는 동일 이름 skill을 만나면 병합하지 않고 둘 다 나타난다; Claude Code는 같은 디렉터리의 동일 이름 역할 중 하나만 로드하며, 어느 것이 로드될지는 확정된 순서가 없다. sync는 동일 이름을 발견하면 실패하고, 호스트에게 선택을 맡기지 않는다;

- 기능 차이는 명시적으로 강등한다: 한쪽만 갖춘 기능(예: 아래의 읽기 전용 subagent)은 프로젝션 시 강등 방식과 보완 수단을 기록하고, 몰래 버리지 않는다.

프로젝션 생성 시 양쪽의 다음과 같은 차이를 고려해야 한다:

기능 Claude Code Codex AGENTS.md/CLAUDE.md CLAUDE.md 와 .claude/rules/ ; CLAUDE.md가 없으면 AGENTS.md를 읽음 AGENTS.md 단계별 연결, 기본 상한 32 KiB 권한 allow / ask / deny 규칙과 권한 모드 샌드박스 모드, 승인 정책, 명령 접두사 규칙 Skill .claude/skills/ .agents/skills/ 사용자 정의 역할 .claude/agents/*.md .codex/agents/*.toml subagent 권한 각 역할별로 도구와 권한 모드를 개별 제한할 수 있고, 독립 worktree에서 작업 가능 주 세션의 권한을 따르며, 역할 파일은 소수 기능만 끌 수 있음 Hook 프로젝트 디렉터리를 신뢰한 후 실행; 단일 hook에 실패 시 차단 설정 가능 각 hook을 개별 심사하며, 설정 변경 후 재심사 필요; 같은 시점의 여러 hook이 동시에 시작 MCP 프로젝트 레벨 .mcp.json , 승인 필요 config.toml 의 [mcp_servers] , 프로젝트 레벨은 신뢰하는 프로젝트에서만 적용

양쪽 동작이 다른 세 가지 지점

하나, 특정 역할을 단독으로 읽기 전용으로 설정할 수 있는가.

Claude Code에서는 가능하다. 리뷰 역할의 정의 파일에 tools: Read, Grep, Glob 를 적으면 이 역할은 파일을 수정하는 도구를 받지 못하며, 호스트가 이를 보장한다.

Codex에서는 불가능하다. subagent의 권한은 이를 시작한 주 세션을 따라간다: 주 세션이 파일을 쓸 수 있으면 subagent도 쓸 수 있다. 역할 정의 파일은 shell 등 소수 기능만 끌 수 있고, 역할 설명에 "파일을 수정하지 말 것"이라고 적는 것은 그저 하나의 힌트일 뿐이다.

그래서 Codex에서 진짜 읽기 전용 리뷰가 필요할 때는 별도로 읽기 전용 세션을 열어 실행하고, CLI가 그 출력을 파일로 작성한다; subagent로 실행할 때는 리뷰 종료 후 Checker가 리뷰 디렉터리 이외의 파일을 변경했는지 검사한다.

둘, hook 설정을 변경한 후에도 여전히 실행되는가.

Claude Code는 프로젝트 디렉터리를 기준으로 신뢰를 확인한다. 확인되면 이 디렉터리에 설정된 hook이 실행된다.

Codex는 각 hook을 개별적으로 심사한다. 각 hook 설정의 지문을 기록하며, 설정이 바뀌면 누군가 재심사할 때까지 이 hook은 건너뛰어진다. 같은 시점에 트리거되는 여러 hook은 여전히 동시에 시작되며 선후 순서가 없다.

그래서 우리는 hook 설정을 CLI를 호출하는 명령 하나로 고정했다(세션 시작 시 이 명령이 sync를 호출하는 주체다). 같은 시점에는 이 한 줄만 걸어 두고, 구체적인 로직은 CLI 안에 두고 반복 개선한다. 설정은 거의 수정할 필요가 없어서 팀 구성원이 거듭 재검토할 필요도, 여러 hook의 순서를 걱정할 필요도 없다. 양쪽의 hook 이벤트 이름은 거의 일치하므로, 이 명령이 이벤트 이름에 따라 분기하면 된다. 자세한 내용은 제02편에서 펼친다.

三、skill은 어느 디렉터리에 두는가.

양쪽은 각자 자기 디렉터리를 읽는다. Claude Code는 .claude/skills/ 를, Codex는 .agents/skills/ 를 읽으며, 서로 상대방의 것을 읽지 않는다.

AGENTS.md의 경우는 다르다. 프로젝트에 CLAUDE.md가 없으면 Claude Code는 AGENTS.md를 직접 읽고, CLAUDE.md가 있으면 그 안에 @AGENTS.md 한 줄을 써서 끌어올 수도 있다.

그래서 AGENTS.md는 양쪽이 한 부를 공유하고, skill은 중립 소스에 한 번만 작성해 두고 생성 시 각각 두 디렉터리에 넣는다.

동일한 리뷰 역할의 두 가지 투영

아래는 동일한 방안 리뷰 역할을 양쪽에 정의한 것으로, 모두 중립 소스에서 생성된다. 리뷰 결론은 파일로 작성해야 하므로, 두 설정 모두 파일 쓰기 능력을 유지했다.

Claude Code( .claude/agents/plan-reviewer.md ):

--- name: plan-reviewer description: 对照接口合同和设计材料评审技术方案，只写评审结论 tools: Read, Grep, Glob, Write model: inherit effort: high maxTurns: 30 --- 只读取方案及其引用的合同文件。 评审结论写入评审目录下的一个文件，不修改其他文件。

Codex( .codex/agents/plan-reviewer.toml ):

name = "plan-reviewer" description = "对照接口合同和设计材料评审技术方案，只写评审结论" model_reasoning_effort = "high" developer_instructions = """ 只读取方案及其引用的合同文件。 评审结论写入评审目录下的一个文件，不修改其他文件。 """ [features] shell_tool = false

Claude Code 쪽은 Bash와 Edit를 제거했고, Codex 쪽은 shell 도구만 끌 수 있으며 어떤 파일을 쓸 수 있는지는 상위 세션의 샌드박스가 결정한다. 양쪽 모두 쓰기 범위를 리뷰 디렉터리로 한정할 수 없어서, "리뷰 파일만 수정"은 최종적으로 Checker가 확인한다.

동기화됨, 신뢰됨, 실행됨은 세 가지 일이다

sync가 끝났다는 것은 투영이 제자리에 작성되었다는 뜻일 뿐, 호스트가 그것을 신뢰한다는 뜻이 아니다. Claude Code에는 워크스페이스 신뢰와 프로젝트 MCP 승인이 있고, Codex에는 프로젝트 계층 신뢰와 각 hook에 대한 개별 심사가 있다. 호스트가 신뢰했다 해도 이번 세션에서 정말로 실행되었다는 뜻도 아니다.

그래서 사전 점검 단계에서 CLI가 항목별로 확인한다. 투영이 최신인지, 필수 hook과 MCP가 신뢰되었는지, 사용 가능한지를 본다. 세션이 끝난 뒤에는 다시 세션 로그로부터 실제 트리거 상황을 확인한다.

프로세스의 정확성은 "hook은 반드시 실행된다"는 가정 위에 세워질 수 없다. 제02편은 이 지점에서부터 단계 계약, 상태 머신과 복구를 이야기한다. hook이 실행되지 않았을 때, 세션 중간에 압축되거나 중단되었을 때 프로세스가 무엇에 기대어 이어지는가를 다룬다.

ZzT

모바일 @水团子

110

글

155k

읽음

166

팬