codex exec가 유용한 순간과 아닌 순간

대화창이 꼭 필요할까

Codex CLI를 조금 쓰다 보면 갈림길이 생긴다.

같은 일을 시켜도 어떤 날은 대화형 세션이 편하고, 어떤 날은 codex exec 한 줄이 더 낫다. 문제는 그 기준이 처음에는 잘 안 잡힌다는 점이다. 기능 목록을 외워서 고를 일은 아니고, 지금 이 작업이 여러 번 주고받아야 하는 일인지 한 번에 끝나는 일인지부터 보면 선택이 쉬워진다.

exec 플래그를 사전처럼 훑는 글은 아니다. 실무에서 “지금은 exec”, “지금은 대화형”을 가르는 감각을 정리해 둔다. 인증은 ChatGPT 로그인(OAuth)을 기준으로 삼았고, API key 방식은 여기서 다루지 않는다.

앞선 글에서 설치 직후 상태를 확인했다면, 그다음에 올 질문이 이것이다. 공식 문서는 글 맨 끝에 모아 두었다.

한 장으로 보는 선택 기준

• 한 번에 끝나는 지시, 스크립트 호출, 로그로 남길 출력 → codex exec
• 방향을 같이 정해야 하거나, 승인·확인이 잦거나, 문맥을 오래 쌓아야 함 → 대화형 codex

1. 둘의 차이를 한 줄로

대화형 codex는 사람과 주고받으며 작업을 이어가는 모드에 가깝다. 질문이 바뀌고, 중간 결과를 보고, 다음 지시를 고쳐 나가는 흐름이다.

codex exec는 대화창 없이 한 번 실행하고 끝나는 쪽이다. 프롬프트를 넣고 끝나기를 기다렸다가, 받은 결과를 스크립트나 로그, 다른 명령 같은 다음 단계로 넘기는 데 맞춰져 있다. “같이 고민해 보자”보다 “이 한 건만 처리해”에 잘 붙는다.

먼저 CLI와 로그인 상태만 확인한다.

codex --version
codex login status

문제가 없다면 대략 이런 출력이 나온다.

codex-cli 0.144.5
Logged in using ChatGPT

Logged in using ChatGPT가 보이면 OAuth 세션으로 붙어 있는 상태다. exec도 같은 로그인 상태를 그대로 쓴다.

2. exec가 잘 맞는 순간

내가 exec를 고르는 조건은 단순하다.

1. 지시가 한 덩어리로 끝난다
2. 중간에 사람이 확인할 일이 거의 없다
3. 결과 텍스트를 파일이나 로그, 다음 명령의 입력으로 넘기고 싶다
4. 같은 패턴을 스크립트에서 반복해 호출할 일이 있다

이런 작업이 여기에 해당한다.

• 저장소 상태를 짧게 요약해 로그에 남기기
• 특정 파일/디렉터리 기준으로 질문 한 번 던지기
• CI나 launchd 같은 자동화 흐름 안에서 호출하기
• 출력을 다른 도구로 파이프하기

help로 옵션 골격만 훑어봐도 대화형과 목적이 다르다는 게 금방 보인다.

codex exec --help

앞부분은 이렇게 시작한다.

Run Codex non-interactively
Usage: codex exec [OPTIONS] [PROMPT]

Run Codex non-interactively, 그러니까 대화 없이 실행한다는 첫 줄이 이 명령의 성격을 그대로 말해 준다.

작업 루트를 고정하고 싶을 때는 -C를 같이 쓴다. git 저장소 루트를 기준으로 help를 여는 예시다.

codex -C "$(git rev-parse --show-toplevel)" exec --help

실제 작업을 시킬 때는 프롬프트를 인자로 넘긴다. 형태만 보면 아래와 같다. 설명용 예시라서, 환경의 사용량 한도나 권한에 따라 결과는 달라질 수 있다.

codex exec --sandbox read-only -C "$(git rev-parse --show-toplevel)" "현재 저장소 상태를 5줄로 요약해줘"

--sandbox read-only는 읽기 위주로만 돌려보고 싶을 때 자주 붙인다. 자동화를 막 붙이기 시작한 단계에서 이 명령이 건드릴 수 있는 범위를 줄여 두려는 것이다. sandbox 자체를 파고드는 이야기는 다음 글로 미뤄도 된다.

3. exec를 빼는 편이 나은 순간

반대로 이런 조건이면 대화형이 덜 피곤했다.

1. 목표가 아직 흐려서 같이 좁혀 가야 한다
2. 중간 결과를 보고 지시가 자주 바뀐다
3. 승인하고 확인할 지점이 많다
4. 긴 맥락을 한 세션에 계속 쌓아야 한다

가령 이런 작업이 그렇다.

• 설계 방향을 놓고 장단점을 주고받기
• 에러 하나를 보고 가설을 여러 번 바꿔가며 추적하기
• 패치 범위를 사람 눈으로 나눠 확정하기
• “일단 훑고, 그다음 파일로, 다시 돌아가서” 식의 탐색

이런 일을 exec로 쪼개면 명령만 늘어나고 맥락은 계속 끊긴다. 짧게 자동 호출한다는 장점도 그때부터는 남지 않는다.

한 줄로 줄이면 이렇다.

• 결정이 이미 섰고 실행만 남았다 → exec
• 결정을 아직 같이 해야 한다 → 대화형

4. 고르기 전에 보는 최소 체크

exec를 돌리기 전에 나는 이것만 먼저 본다.

codex --version
codex login status
pwd
codex exec --help

git 저장소 안에서 루트까지 보려면:

git rev-parse --show-toplevel

여기서 이미 답이 나오는 경우도 있다.

• 로그인 상태가 아니면: codex login을 먼저 하고 상태를 다시 확인
• 폴더가 의도와 다르면: 이동하거나 -C로 루트를 지정
• help조차 안 뜨면: exec 옵션이 아니라 CLI 설치나 PATH부터

exec가 실패하거나 결과가 비어 보일 때는 모델 탓부터 하지 말고 순서를 되짚는다.

1. 로그인 상태
2. 작업 디렉터리
3. 프롬프트가 한 번에 끝나는 지시로 충분한지
4. sandbox나 승인 설정이 너무 빡빡하지 않은지
5. 계정 사용량 한도에 걸린 건 아닌지

특히 자동화 파이프라인에서는 5번을 놓치면 “명령은 맞는데 결과가 없다”에 시간을 쓰게 된다. 한도 메시지가 보인다면 글 내용을 고칠 일이 아니라, 쿼터와 재시도 시점의 문제로 떼어 놓는 게 맞다.

복사해서 쓰는 판정 메모

작업을 시작하기 전에 네 줄만 적어 본다.

1. 이번 지시가 한 번에 끝나는가?
2. 중간에 사람이 확인할 일이 있는가?
3. 결과를 로그나 스크립트로 넘길 것인가?
4. 맥락을 오래 쌓아야 하는가?

판정은 이렇게 한다.

• 1=예, 2=아니오, 3=예, 4=아니오 → codex exec
• 2=예 또는 4=예 → 대화형 codex
• 애매하면 대화형으로 방향을 굳힌 뒤, 반복할 수 있는 조각만 exec로 옮긴다

무난한 기본값으로 자주 쓰는 형태는 이렇다.

codex exec --sandbox read-only -C "$(git rev-parse --show-toplevel)" "..."

다음에 보면 좋은 것

exec를 고르는 감각이 생기고 나면, 그다음은 명령이 건드릴 수 있는 범위를 좁히는 쪽으로 간다.

• 로그인 상태가 자주 헷갈릴 때 확인할 것
• --sandbox read-only를 언제 쓰면 좋은지
• CLI 자동화와 직접 API 호출을 언제 나누는지

설치 직후 상태를 확인했다면, 그다음은 대화형으로 풀 일과 exec로 넘길 일을 먼저 갈라 두는 게 순서에 맞다.

참고 링크

• Codex CLI
• Config basics
• Agent approvals & security
• 이전 글: Codex CLI 설치 후 가장 먼저 확인할 설정들