코덱스 툴 사용법 24: Rules로 명령 승인 기준을 파일로 고정하기 | DAKER 커뮤니티

코덱스 툴 사용법 24: Rules로 명령 승인 기준을 파일로 고정하기

Codex를 매일 쓰다 보면 같은 승인 질문을 반복해서 보게 됩니다. gh pr view처럼 매번 필요한 조회 명령도 있고, 배포나 삭제처럼 절대 자동으로 넘기면 안 되는 명령도 있습니다. 이 차이를 매번 대화로 설명하면 언젠가 빠집니다. 승인 기준은 프롬프트보다 파일에 두는 편이 낫습니다.

OpenAI Codex 공식 문서 기준으로 Rules는 Codex가 sandbox 밖에서 실행하려는 명령을 어떻게 처리할지 정하는 실험적 정책 파일입니다. .rules 파일 안에 prefix_rule()을 쓰고, 명령 앞부분과 결정값을 적습니다. 결정은 allow, prompt, forbidden 중 하나입니다.

어제 23편에서 AGENTS.md를 작업 계약서로 봤다면, 오늘의 Rules는 명령 실행의 승인 표입니다. AGENTS.md는 “어떻게 일할까”를 알려주고, Rules는 “이 명령은 자동 허용할까, 물어볼까, 막을까”를 정합니다.

한 줄 요약

반복되는 명령 승인 기준은 기억이나 프롬프트에 맡기지 말고, 좁은 prefix_rule()과 codex execpolicy check로 검증되는 Rules 파일에 남기세요.

Rules가 해결하는 문제

Codex의 sandbox와 approval은 좋은 안전장치입니다. 문제는 반복입니다.

예를 들어 팀에서 GitHub PR을 자주 확인한다고 해봅시다.

gh pr view 7888 --json title,body,comments

이 명령은 외부 시스템을 조회합니다. 그래서 환경에 따라 sandbox 밖 실행이나 승인이 필요할 수 있습니다. 그런데 이 명령이 매일 반복되는 정해진 조회라면, 매번 “이건 괜찮아”라고 말하는 것은 낭비입니다.

반대로 아래 같은 명령은 절대 습관적으로 허용하면 안 됩니다.

rm -rf /
git push --force

Rules는 이 둘을 같은 “명령 실행”으로 뭉개지 않습니다. 명령 앞부분을 보고 좁게 매칭한 뒤, 허용할지, 물어볼지, 차단할지 결정합니다.

Rules 파일은 어디에 두나

공식 문서는 활성 config layer 옆의 rules/ 폴더 아래에 .rules 파일을 만들라고 안내합니다. 예를 들어 사용자 레이어라면 아래처럼 둘 수 있습니다.

~/.codex/rules/default.rules

프로젝트 로컬 규칙도 가능합니다. 다만 프로젝트 .codex/ 레이어는 신뢰된 경우에만 로드됩니다. 조직에서는 Team Config 위치나 관리형 설정을 통해 더 제한적인 규칙을 강제할 수도 있습니다.

중요한 운영 포인트는 두 가지입니다.

Rules는 Codex 시작 시 스캔되므로 추가 후 재시작이 필요합니다.
TUI에서 allow list에 명령을 추가하면 사용자 레이어의 ~/.codex/rules/default.rules에 기록될 수 있습니다.

즉, Rules는 “이번 한 번만”이 아니라 다음 실행에도 영향을 주는 설정입니다. 좁고 검증 가능하게 써야 합니다.

`prefix_rule()`은 명령 앞부분을 본다

Rules의 기본 단위는 prefix_rule()입니다. 예시는 이런 모양입니다.

prefix_rule(
    pattern = ["gh", "pr", "view"],
    decision = "prompt",
    justification = "PR 조회는 가능하지만 실행 전 확인한다",
    match = [
        "gh pr view 7888",
        "gh pr view --repo openai/codex",
    ],
    not_match = [
        "gh pr --repo openai/codex view 7888",
    ],
)

pattern은 명령 인자 목록의 앞부분과 비교됩니다. 여기서는 gh pr view로 시작하는 명령만 맞습니다. gh pr --repo ... view처럼 중간에 옵션이 들어가면 같은 의미처럼 보여도 prefix가 달라서 매칭되지 않습니다.

이 특징 때문에 Rules는 넓게 쓰면 위험하고, 좁게 쓰면 유용합니다. ["gh"]처럼 너무 넓게 잡으면 GitHub CLI의 여러 동작이 한꺼번에 들어옵니다. 반대로 ["gh", "pr", "view"]처럼 좁게 잡으면 특정 조회 흐름만 정책화할 수 있습니다.

decision은 세 가지다

Rules의 decision은 세 가지로 생각하면 됩니다.

decision	의미	실무 기준
`allow`	맞는 명령을 sandbox 밖에서 물어보지 않고 실행	반복되는 낮은 위험의 조회성 명령
`prompt`	맞는 명령마다 확인 요청	외부 권한, 비용, 개인정보, 상태 변경 가능성이 있는 명령
`forbidden`	맞는 명령을 확인 없이 차단	금지된 삭제, 위험한 우회, 팀 정책 위반

여러 규칙이 동시에 맞으면 Codex는 가장 엄격한 결정을 적용합니다. 공식 문서의 우선순위는 forbidden > prompt > allow입니다.

이 원칙은 중요합니다. 한 파일에서 넓은 allow를 실수로 넣어도, 더 구체적인 forbidden이나 prompt가 같이 맞으면 더 안전한 쪽으로 기웁니다. 그래도 넓은 allow를 남발하면 디버깅이 어려워지니 애초에 좁게 쓰는 편이 좋습니다.

Mermaid로 보는 규칙 추가 흐름

아래는 초안 단계에서 쓴 Mermaid 의사결정 흐름입니다. 게시 본문에는 같은 흐름을 SVG로 렌더링해 넣습니다.

Mermaid 원본:
flowchart TD
  A[새 명령을 자주 쓰는가?] -->|아니오| B[이번 프롬프트에서만 확인]
  A -->|예| C{sandbox 밖 실행이 필요한가?}
  C -->|아니오| D[AGENTS.md나 Skill 검토]
  C -->|예| E{위험도가 낮고 좁은가?}
  E -->|예| F[allow 후보]
  E -->|애매함| G[prompt로 확인 유지]
  E -->|위험함| H[forbidden으로 차단]

핵심은 반복성과 위험도입니다. 한 번만 필요한 명령이면 프롬프트에서 처리하면 됩니다. 반복되지만 sandbox 밖 실행과 무관한 작업 방식이면 AGENTS.md나 Skill이 더 맞습니다. 반복되고 승인 정책과 관련될 때 Rules가 등장합니다.

match와 not_match는 주석보다 낫다

Rules 문서에서 특히 실무적인 부분은 match와 not_match입니다. 이 둘은 설명이 아니라 “inline unit tests”처럼 동작합니다. 규칙이 로드될 때 예시가 맞는지 검증하는 데 쓰입니다.

좋은 규칙은 이런 식으로 의도를 함께 남깁니다.

prefix_rule(
    pattern = ["gh", "pr", "view"],
    decision = "allow",
    justification = "PR 본문과 댓글 조회는 반복 작업이라 자동 허용한다",
    match = [
        "gh pr view 7888",
        "gh pr view 7888 --json title,body,comments",
    ],
    not_match = [
        "gh pr edit 7888 --title change",
        "gh pr merge 7888",
    ],
)

여기서 의도는 분명합니다. PR을 보는 것은 허용하지만, 수정하거나 머지하는 것은 이 규칙으로 허용하지 않습니다. 이런 예시가 없으면 나중에 누군가 pattern을 넓히면서 위험한 명령까지 함께 통과시킬 수 있습니다.

shell wrapper는 조심해서 봐야 한다

Rules는 명령을 인자 목록으로 비교합니다. 그런데 실제 도구 호출은 종종 shell wrapper로 감싸집니다.

bash -lc "git add . && rm -rf /"

공식 문서는 bash -lc, bash -c, zsh, sh 계열 wrapper를 특별히 다룬다고 설명합니다. 단순한 명령 체인이면 Codex가 tree-sitter로 분리해서 각각의 명령에 규칙을 적용할 수 있습니다. 위 예시는 git add .와 rm -rf /로 나뉘고, 가장 엄격한 결과가 전체 실행에 적용됩니다.

하지만 변수, 리다이렉션, 와일드카드, 제어문, 치환처럼 복잡한 shell 기능이 섞이면 Codex는 억지로 해석하지 않습니다. 그때는 전체 wrapper 호출을 하나의 명령처럼 보수적으로 취급합니다.

실무 기준은 간단합니다. 자동 allow 규칙을 만들 때 shell wrapper 전체를 넓게 허용하지 마세요. 특히 bash -lc 자체를 허용하는 식의 규칙은 거의 항상 너무 큽니다.

만든 규칙은 `execpolicy check`로 확인한다

규칙 파일은 눈으로만 보면 안 됩니다. 공식 문서는 codex execpolicy check 명령으로 실제 판정을 확인하는 방법을 제공합니다.

codex execpolicy check --pretty \
  --rules ~/.codex/rules/default.rules \
  -- gh pr view 7888 --json title,body,comments

이 명령은 적용되는 결정과 매칭된 규칙, justification을 JSON으로 보여줍니다. 여러 rules 파일을 합쳐 확인하려면 --rules를 여러 번 줄 수 있습니다.

내 기준으로는 allow 규칙을 추가할 때 최소 세 가지를 확인합니다.

허용하려는 명령이 정말 allow로 나온다.
비슷하지만 위험한 명령은 allow로 나오지 않는다.
justification이 나중에 봐도 이유를 설명한다.

이 세 가지를 통과하지 못하면 아직 운영 규칙이 아닙니다.

AGENTS.md와 Rules를 섞지 않는 법

둘 다 “규칙”처럼 보이지만 역할은 다릅니다.

넣을 내용	적합한 위치
테스트 명령, 리뷰 기준, 디렉토리별 작업 방식	`AGENTS.md`
반복 workflow와 참고 자료, 스크립트	Skill
외부 도구 연결과 권한 있는 데이터 접근	MCP
sandbox 밖 명령 승인 정책	Rules
조직 차원의 강제 제한	관리형 설정 또는 Team Config

예를 들어 “PR을 보기 전에 이슈 번호를 확인한다”는 작업 방식이므로 AGENTS.md나 Skill에 가깝습니다. 반면 “gh pr view는 prompt 없이 실행해도 된다”는 명령 승인 정책이므로 Rules에 가깝습니다.

이 구분을 지키면 설정이 훨씬 읽기 쉬워집니다. AGENTS.md에 승인 정책을 길게 쓰지 않아도 되고, Rules 파일에 작업 철학을 장황하게 적지 않아도 됩니다.

자동 허용은 줄이는 기술이다

Rules의 목적은 모든 질문을 없애는 것이 아닙니다. 반복되는 낮은 위험 질문을 줄여서, 진짜 판단이 필요한 질문을 더 잘 보게 만드는 것입니다.

따라서 처음부터 allow를 늘리기보다 prompt로 시작하는 편이 안전합니다. 며칠 써보고 정말 반복되는 조회성 명령만 allow로 승격하세요. 외부 상태를 바꾸거나 비용, 권한, 개인정보, 배포에 닿는 명령은 계속 prompt로 두는 것이 좋습니다.

forbidden도 유용합니다. 팀에서 금지한 우회 명령, 위험한 삭제, 보호 브랜치 강제 push 같은 것은 “실수하면 물어봐야지”가 아니라 “실수해도 실행되면 안 된다”에 가깝습니다. 이런 경우에는 justification에 대체 행동까지 적어두면 더 좋습니다.

prefix_rule(
    pattern = ["git", "push", "--force"],
    decision = "forbidden",
    justification = "보호 브랜치 강제 push는 금지한다. 필요한 경우 --force-with-lease와 리뷰 승인 절차를 사용한다.",
    match = [
        "git push --force",
    ],
)

팀에 적용할 때의 순서

팀에서 바로 넓은 allow list를 공유하면 위험합니다. 작은 순서로 가세요.

개인 레이어에서 반복 prompt를 관찰한다.
조회성 명령만 좁은 prefix_rule()로 만든다.
match와 not_match를 넣고 execpolicy check로 확인한다.
팀 공통으로 필요한 규칙만 프로젝트 또는 Team Config로 올린다.
금지 규칙은 justification에 대체 경로를 적는다.

특히 관리형 설정으로 강제되는 restrictive rule은 개인 선호보다 강합니다. 조직에서 금지한 명령을 개인 Rules로 우회하려는 설계는 하지 않는 편이 맞습니다.

오늘 바로 만들 수 있는 첫 규칙

처음에는 “자주 쓰지만 낮은 위험의 조회 명령” 하나만 고르세요. 예를 들어 GitHub PR 조회를 매일 쓴다면 아래 정도가 출발점입니다.

prefix_rule(
    pattern = ["gh", "pr", "view"],
    decision = "prompt",
    justification = "PR 조회 명령은 반복되지만 외부 GitHub 접근이므로 실행 전 확인한다",
    match = [
        "gh pr view 123",
        "gh pr view 123 --json title,body,comments",
    ],
    not_match = [
        "gh pr edit 123 --title fix",
        "gh pr merge 123",
    ],
)

처음부터 allow가 아니어도 괜찮습니다. 중요한 것은 기준이 파일로 남는 것입니다. 며칠 뒤 정말 반복되고 위험이 낮다는 확신이 생기면 그때 allow로 바꾸면 됩니다.

시니어 엔지니어의 기준

좋은 자동화는 “안 물어보는 자동화”가 아닙니다. 물어볼 필요가 없는 것은 조용히 지나가고, 물어봐야 하는 것은 반드시 멈추는 자동화입니다.

Codex Rules는 그 경계를 명령 단위로 고정하는 도구입니다. AGENTS.md가 저장소의 작업 계약서라면, Rules는 명령 실행의 승인 장부입니다.

오늘 반복해서 승인하던 명령 하나를 골라 이 질문을 해보세요.

이 명령은 정말 자동 허용할 만큼 좁고 낮은 위험인가, 아니면 prompt로 남겨야 하는가?

답이 불분명하면 prompt가 맞습니다. 답이 분명하다면 prefix_rule(), match, not_match, execpolicy check까지 묶어서 운영 규칙으로 만드세요. 승인 피로를 줄이되, 안전 경계는 더 선명해집니다.

참고: OpenAI Codex의 Rules, Customization, Custom instructions with AGENTS.md, Managed configuration 문서를 2026-06-16 Asia/Seoul 기준으로 확인했습니다.