Codex CLI 비대화형 실행: 스크립트에서 작업 맡기고 검증하는 법

대화창 없이 스크립트에서 Codex CLI에 파일 수정을 맡기려면 codex exec에 작업 폴더와 -s workspace-write를 지정하고, 신뢰된 폴더나 Git 저장소가 아니면 --skip-git-repo-check를 더해야 한다.

이 결과는 설치와 인증을 마친 macOS arm64의 codex-cli 0.161.0에서, 대상이 수정 가능한 로컬 파일일 때 성립한다. 공식 문서와 로컬 실행은 모두 2026-11-03에 확인했다.

codex exec의 종료 코드 0은 수정 성공이나 테스트 통과를 보증하지 않는다. diff와 테스트 종료 코드로 따로 검증해야 한다.

Codex CLI 비대화형 실행은 왜 한 줄로 끝나지 않을까

OpenAI Codex 공식 문서는 codex exec를 TUI를 열지 않는 스크립트용 실행으로 설명한다. 그런데 이 실행에는 폴더 신뢰 검사와 읽기 전용 기본값이 걸려 있다.

그래서 폴더 지정, 검사 통과, 쓰기 허용, 실행 후 검증을 따로 다뤄야 한다.

세 번 실행해서 확인한 것

재현용으로 Git 저장소가 아닌 새 폴더에 파일 두 개를 만들었다. calculator.py는 고의로 뺄셈을 반환한다.

def add(a: int, b: int) -> int:
    return a - b

test_add.py는 두 수의 합을 검사한다.

from calculator import add

# Given two positive integers, when adding, then return their sum.
assert add(2, 3) == 5
print("PASS: add(2, 3) == 5")

처음 상태에서 /usr/bin/python3 -B test_add.py는 AssertionError, 종료 코드 1로 실패했다.

첫 번째 실험은 비 Git 폴더에서 아무 옵션 없이 실행했다.

/opt/homebrew/bin/codex exec -C <폴더> "Fix calculator.py so test_add.py passes."

0.232초 만에 종료 코드 1로 거부됐다. stderr에는 아래 문구가 나왔다.

Reading additional input from stdin...
Not inside a trusted directory and --skip-git-repo-check was not specified.

두 번째 실험은 검사 예외를 주고 -s read-only로 수정을 요청했다.

/usr/bin/time -p /opt/homebrew/bin/codex exec --skip-git-repo-check -C <폴더> -s read-only "Fix calculator.py so test_add.py passes. … Report whether the edit was blocked."

40.59초 뒤 종료 코드 0으로 끝났지만, 로그에는 차단 문구가 남았다.

patch rejected: writing is blocked by read-only sandbox; rejected by user approval settings

파일은 a - b 그대로였다. 따로 돌린 테스트도 종료 코드 1로 실패했다.

세 번째 실험은 -s workspace-write에 결과 캡처 옵션 --json과 -o를 더했다.

/usr/bin/time -p /opt/homebrew/bin/codex exec --skip-git-repo-check -C <폴더> -s workspace-write --json -o <폴더>/last-message.txt "Fix only calculator.py so test_add.py passes. … Report the change and test result."

20.78초 뒤 종료 코드 0으로 끝났다. 따로 실행한 diff -u calculator.before.txt calculator.py에서 아래 변경을 확인했다.

 def add(a: int, b: int) -> int:
-    return a - b
+    return a + b

같은 테스트를 다시 돌리니 PASS: add(2, 3) == 5와 종료 코드 0이 나왔다.

실험주요 옵션종료 코드파일 변경독립 테스트
기본 실행-C <폴더>1 (0.232초)없음, 실행 전 거부실행 안 함
읽기 전용--skip-git-repo-check -s read-only0 (40.59초)없음, 패치 차단1 (AssertionError)
쓰기 허용--skip-git-repo-check -s workspace-write --json -o0 (20.78초)a + b로 변경0 (PASS)

거부, 차단, 거짓 성공이 나뉜 이유

왜 결과가 셋으로 나뉘었을까.

첫째, 작업 폴더 지정과 폴더 신뢰 검사는 다른 기능이다. -C, --cd <DIR>는 작업 루트를 정할 뿐이다.

OpenAI Codex 비대화형 모드 공식 문서는 기본적으로 Git 저장소 안에서 실행하도록 요구한다. 비 Git 폴더는 --skip-git-repo-check로 허용한다고 설명한다. 첫 번째 실험의 오류 문구도 trusted directory와 이 플래그를 함께 언급한다.

둘째, 검사 통과와 쓰기 권한은 별개다. 같은 문서는 codex exec의 기본 권한을 read-only로 설명하고, 수정 작업에는 --sandbox workspace-write를 쓰라고 안내한다. 이전의 --full-auto는 문서상 더 이상 지원되지 않고, 로컬 0.161.0 도움말에도 없다.

셋째, 이번 실행에서 종료 코드 0은 에이전트가 실행을 마쳤다는 뜻에 그쳤다고 본다. 두 번째 실험의 마지막 답변은 테스트를 실행했다고 주장했지만, 로그에는 패치 거부 뒤 테스트 명령 이벤트가 없었다.

그래서 자연어 답변이나 종료 코드만으로 수정 완료를 판정하면 안 된다.

codex exec 실측 네 단계 그림: 폴더 검사에서 신뢰 폴더가 아니면 거부(종료 코드 1), 읽기 전용이면 패치 차단에도 종료 코드 0, workspace-write로 a - b를 a + b로 수정, diff와 테스트 PASS로 직접 확인. 종료 코드 0은 성공 보증이 아니다.

그림처럼 폴더 검사, 쓰기 권한, 수정을 모두 지나도 성공 판정은 마지막 직접 확인에서만 한다.

스크립트에 넣을 때의 순서

  1. -C <폴더>로 작업 루트를 지정한다. 신뢰된 디렉터리나 Git 저장소가 아니면 --skip-git-repo-check를 더한다.
  2. 파일을 고치는 작업이면 -s workspace-write로 읽기 전용 기본값을 바꾼다.
  3. 마지막 답변은 -o <파일>로 저장하고, 단계별 이벤트가 필요하면 --json으로 stdout의 JSON Lines를 받는다.
  4. codex exec가 끝나면 스크립트에서 따로 diff와 테스트를 실행해 실제 변경과 테스트 종료 코드 0을 확인한다.

매번 같은 규칙을 전달해야 한다면 설정과 지침 파일을 쓴다. 기본 설정 공식 문서는 ~/.codex/config.toml과 신뢰한 프로젝트의 .codex/config.toml보다 명령행 플래그와 -c key=value가 우선한다고 설명한다.

AGENTS.md 공식 문서는 전역 지침과 프로젝트 루트부터 현재 폴더까지의 AGENTS.md를 기본 32 KiB 한도 안에서 합쳐 읽는다고 설명한다. 이 파일은 모델에 주는 규칙이고 OS 권한 경계와는 다르다.

결과 파일이 분명한 작업도 같은 방식으로 넘길 수 있다. 2026-10-28 블로그 이미지 제작 기록에는 아래 형태의 명령이 남아 있다. 같은 날 다른 원고 묶음의 기록에도 표지·장면·순서도 아이콘 9개 작업이 같은 방식으로 적혀 있다.

codex exec --skip-git-repo-check -C images/gen -s workspace-write "Call the built-in image_gen tool exactly once. Image: <프롬프트> Copy the PNG into the current directory as <파일>"

0.161.0의 내장 image_gen을 한 번 호출해 PNG를 지정 폴더에 저장하게 한 사례로 본다.

확인하지 못한 것

이번 결과는 macOS arm64 한 대, codex-cli 0.161.0, 파이썬 파일 한 건을 한 번씩 실행한 관찰이다.

세 번째 실험에서는 개인 전역 지침 때문에 기존 TDD 스킬을 읽는 동작이 있었다. 아무 설정이 없는 환경과는 결과가 다를 수 있다.

에이전트 승인 및 보안 공식 문서에 따르면 workspace-write는 네트워크가 기본 비활성이고 .git 같은 보호 경로가 있다. 그래도 임시 디렉터리 등이 쓰기 범위에 들어갈 수 있어, 폴더 하나만 완벽히 격리된다고 볼 수는 없다.

stdout과 stderr 분리, --output-schema, 파이프 입력, codex exec resume, codex sandbox는 문서와 도움말만 봤다. 요금제 한도, 토큰 비용, Linux·Windows·CI 인증 환경, 계정별 이미지 생성 지원도 검증하지 않았다.

지침 파일이 모델 행동에 주는 영향은 하네스 엔지니어링 측정 1편 — AGENTS.md 비우면 Codex도 fail-fast 안 지킨다에서 볼 수 있다. 자동 검증을 묶는 방법은 하네스 엔지니어링 — CLAUDE.md만 쓴다고 끝나지 않는다에서 이어진다.

결론

스크립트에서 Codex CLI로 파일 수정을 맡기려면 codex exec에 -C, 필요하면 --skip-git-repo-check, 그리고 -s workspace-write를 지정한다.

결국 성공 기준은 종료 코드 0이나 마지막 답변이 아니라 실행 직후의 diff와 독립 테스트 종료 코드다.

지금 스크립트에 codex exec를 넣는다면 -o로 답변을 남기고, 바로 다음 줄에 테스트와 종료 코드 검사를 추가해 보자.

댓글

댓글 쓰기

이 블로그의 인기 게시물

AI 코딩 스킬, 많을수록 좋을까 — 자산이 부채로 바뀌는 손익분기

이미지
AI 코딩 스킬은 자산이다. 처음 몇 개는 그렇다. 그런데 수가 늘면 세금이 붙는다. 어느 스킬이 뜰지 예측이 안 되고, 도구 출력이 컨텍스트를 먹고, 모델이 바뀌면 쌓은 걸 전부 다시 만진다. 스킬을 관리하는 앱이 시장에 나온 게 그 신호다. 만들지 말라는 게 아니다. 만든 만큼 쳐내야 자산으로 남는다. 스킬은 자산으로 시작한다, 그런데 요즘 개발자들이 자기 .claude 디렉터리를 통째로 공개한다. TypeScript 교육자 Matt Pocock도 스킬 묶음을 GitHub에 올렸다. 제목이 “Skills for Real Engineers”이고, 소개가 “내 .claude 디렉터리에서 바로”다. skills.sh 같은 스킬 레지스트리도 생겼다. 스킬이 자산인 건 맞다. 손으로 반복하던 작업을 트리거 한 줄로 줄인다. 결과도 매번 일정해진다. 그래서 다들 쌓는다. 그런데 같은 GitHub에 묘한 게 같이 뜬다. 스킬을 “관리하고 동기화하고 정리”하는 데스크톱 앱이다. skills-manager는 Cursor·Claude Code·Codex 등 15개 넘는 도구의 스킬을 한곳에서 관리한다고 소개한다. 자산을 관리하는 전용 앱이 필요해졌다는 건, 그 자산이 관리 대상이 됐다는 뜻이다. 관리 대상은 곧 부담이다. 여기서 질문이 갈린다. AI 코딩 스킬은 많을수록 좋은가. 다음 중 하나라도 있나 비슷한 일을 하는 스킬이 둘 이상이라, 어느 게 뜰지 헷갈린 적이 있다. 스킬 하나를 고쳤더니 엉뚱한 데서 다른 게 어긋난 적이 있다. 내가 무슨 스킬을 만들어뒀는지, 목록을 열어봐야 기억나는 적이 있다. 셋 중 하나라도 해당되면 이미 부채 구간에 발을 걸친 것이다. 세 신호를 하나씩 본다. 신호 1 — 어느 스킬이 뜰지 예측이 안 된다 스킬이 늘면 비슷한 트리거를 여럿이 주장한다. “리뷰”라는 말에 코드 리뷰 스킬도 반응하고, 글 리뷰 스킬도 반응한다. 그러면 매 요청마다 “어느 스킬을 부를지” 판별하는 비용이 붙는다. 자동 라우팅 점...
자세한 내용 보기

M4 Max 128GB 로컬 LLM 4종 속도 비교 — 실측 기록과 한계

이미지
M4 Max 128GB에서 로컬 LLM은 얼마나 빠를까? 이 글의 과거 표에서는 gemma4:latest가 88 tok/s로 가장 높고, gemma4:26b는 85 tok/s다. gpt-oss:120b 47 tok/s, qwen3.6:35b-a3b 25 tok/s가 뒤를 잇는다. 처리량 표이지 정답률이나 코딩 품질 순위가 아니다. 작성자: 닥터조지. 2026년 4월 게시 당시 측정 기록 / 편집 보완: 2026-09-23. 기존 수치는 그대로 보존했고 이번에 모델을 다시 실행하지 않았다. 초판 제목의 llama3.3 표기와 “26B가 가장 빠르다”는 도입은 표와 일치하지 않아 바로잡았다. 원문의 장비·런타임·모델 표기는 당시 기록이다. 표의 qwen3.6:35b-a3b 는 원문에서 사용한 축약 표기이며, Q8과 qwen3.6:35b-a3b-q8_0 표기는 당시 본문 기록에서 가져왔다. 모델 파일이나 digest를 이번에 확인한 것은 아니다. 원 프롬프트 전문, 모델 digest, 반복 횟수와 개별 원시 응답이 이 글에 없어 표의 숫자를 그대로 재현했다고 확인할 수는 없다. 특히 latest 는 고정 버전 식별자가 아니다. 아래는 M4 Max 128GB 한 대에서 기록한 네 모델의 처리량이다. 모델 구조, 양자화, 크기가 동시에 다르므로 어느 한 요인만의 효과를 분리한 실험으로 읽으면 안 된다. 모델 크기만으로 속도를 예측하기 어려운 이유 원문은 gpt-oss:120b 를 총 117B, 활성 약 5.1B의 MoE로 기록했다. 활성 파라미터 수만으로 실제 생성 속도를 계산할 수는 없다. 모델 구조에 따른 메모리 접근 차이는 가능한 설명이지만, 이 표는 메모리 대역폭이나 접근 패턴을 직접 계측한 자료가 아니다. 생성 속도 차이만으로 병목의 원인을 확정하지 않는다. 당시 표의 gemma4:26b 는 gpt-oss:120b 보다 높은 생성 처리량을 보였다. 다만 이 결과를 모든 Dense 모델과 MoE 모델의 우열로 일반화할 수는 없다. 같은 ...
자세한 내용 보기

Opus 5는 더 잘 쓰고, 더 AI답게 쓴다 — 세 모델 첫날 실측

이미지
Claude Opus 5가 나온 다음 날, 세 모델에게 같은 시험지를 줬다. 결과부터 적는다. 글 품질 점수는 신형일수록 올랐다. 그런데 문장 리듬은 신형일수록 고르게, 그러니까 더 AI답게 변했다. 여기서 “AI답게”는 말투가 기계 같다는 뜻이 아니다. 문장 길이와 어미가 균질해진다는 뜻이고, 그 균질함이 통계 탐지기가 AI 글을 잡아낼 때 쓰는 바로 그 지문이다. 발표는 두 가지를 팔았다 새 모델이 나오면 벤치마크 표부터 보게 된다. 그 표는 전부 만든 쪽이 자기 시험지로 채점한 결과다. 내 작업에서 뭐가 달라지는지는 표에 없다. 그래서 표를 덮고 시험지를 직접 만들었다. 7월 24일 발표에서 Anthropic은 크게 두 가지를 내세웠다. 하나, 자기 작업을 검증하며 성공할 때까지 반복하는 능력이 강해졌다. 둘, 응답이 더 명확하고 간결해졌다. 벤치 수치는 여기 옮기지 않는다. 이 글이 확인할 건 저 두 문장이 내 작업물에서 어떻게 나타나느냐다. 같은 시험지 두 장 시험지는 두 장이다. 첫째는 글쓰기다. 주제·허용 사실·문체 규칙을 고정한 한국어 블로그 초안 스펙을 만들어 세 모델에 원샷으로 줬다. 둘째는 코딩 진단이다. 내 수집기에서 한 달 넘게 죽어 있던 실제 버그(reddit 수집 429 연쇄 실패)를 읽기 전용으로 진단하게 했다. 모든 주장에 파일과 행 번호 인용을 의무로 걸었다. 대상은 Opus 4.8, Fable 5, Opus 5. 각 모델의 정체는 시스템 프롬프트 자기보고로 확인했다. 채점은 사람 감이 아니다. 글은 발행 글 29편에서 뽑은 결정론 밴드(파이썬 스크립트)와 10점 감점제 루브릭으로, 진단은 미리 고정해 둔 정답표와 인용 실물 대조로 매겼다. 실측 1 — 더 잘 쓸수록 더 고르다 숫자부터 본다. 지표 Opus 4.8 Fable 5 Opus 5 발행 글 기준 문장 길이 변주(변동계수) 0.316 0.220 0.274 0.417 이상 행 길이 변주 0.266 0.23...
자세한 내용 보기