Codex 대화형 모드와 codex exec 비교: 릴리스 점검은 어디에서 돌릴까

TL;DR

핵심 3줄 요약

이 글에서 다룰 내용

어떤 문제를 해결하는 기능인가

릴리스 점검에는 원인 조사와 반복 검사가 함께 들어갑니다. 원인도 모른 채 자동화부터 만들면 프롬프트와 권한이 자주 바뀝니다. 이미 정해진 검사를 매번 대화형 화면에서 되풀이하는 것도 결과를 파이프라인에 연결하기 어렵게 만듭니다.

Codex 대화형 모드는 로컬 저장소에서 파일을 살펴보고 수정하며 설치된 도구를 실행하는 터미널 작업 방식입니다. codex 로 시작한 뒤 모델·추론 수준·권한을 고릅니다. 진행 중인 결과를 보면서 후속 지시를 줄 수 있습니다.

codex exec 는 대화형 TUI를 열지 않고 스크립트와 CI에서 Codex를 실행하는 비대화형 모드입니다. 진행 상황은 stderr로 보내고 마지막 에이전트 메시지는 stdout에 출력하므로 다른 명령으로 넘기거나 파일에 저장할 수 있습니다.

선택 기준은 단순합니다. 사람과 함께 질문을 바꿔 가며 원인을 찾으면 대화형 모드, 이미 합의한 점검을 같은 형태로 반복하면 codex exec 입니다.

대화형 모드를 고를 때

1. 먼저 실패 상태를 재현합니다

릴리스 후보 브랜치에서 codex 를 열기 전에 현재 폴더, 브랜치, 변경 파일과 실패한 명령을 확인합니다. Codex에는 실패 로그와 실제 저장소 파일만 근거로 원인을 분류하라고 요청합니다.

pwd
git status
git diff --stat
codex

대화형 세션에서는 첫 가설을 바로 수정으로 연결하지 않습니다. 관련 설정과 테스트 파일을 읽은 뒤 재현 명령과 예상 영향 범위를 먼저 제시하게 합니다.

2. 후속 질문으로 조사 범위를 좁힙니다

오류가 코드, 의존성, 환경 설정 가운데 어디에서 시작됐는지 확인합니다. Codex가 짚은 파일과 명령을 사람이 읽고 다음 조사 범위를 승인합니다. 요구사항이 바뀌거나 확인할 파일이 늘어날 때는 이 과정을 반복합니다.

수정안이 나오면 실제 diff와 관련 테스트를 확인합니다. 대화가 자연스럽게 이어졌다는 이유만으로 이전 테스트 결과나 실행 중인 프로세스가 여전히 유효하다고 가정하지 않습니다.

codex exec를 고를 때

3. 반복할 입력과 완료 기준을 먼저 고정합니다

codex exec 는 CI, 사전 병합 검사, 예약 작업처럼 같은 절차를 되풀이할 때 적합합니다. 프롬프트에는 비교할 기준 브랜치, 읽을 수 있는 입력, 실행 가능한 명령, 출력 필드와 실패 시 처리 방식을 적습니다.

가장 단순한 실행 형태는 아래와 같습니다.

codex exec "현재 변경을 읽고 릴리스 위험을 근거 파일과 함께 요약하라"

공식 문서에 따르면 기본 sandbox는 읽기 전용입니다. 코드 수정을 허용해야 할 때만 --sandbox workspace-write 를 사용합니다. danger-full-access 는 격리된 CI 실행기나 컨테이너처럼 통제된 환경으로 제한합니다.

4. 사람이 읽을 출력과 기계가 읽을 출력을 나눕니다

최종 설명만 필요하면 stdout을 파일이나 다음 명령으로 넘길 수 있습니다. 실행 이벤트까지 수집하려면 --json 을 사용합니다. 이때 stdout은 JSON Lines 스트림이 되며 시작·완료·실패, 명령 실행, 파일 변경 같은 이벤트를 기록합니다.

codex exec --json "저장소 구조와 릴리스 위험을 요약하라" | jq

후속 단계에서 고정 필드를 받아야 한다면 --output-schema 로 JSON Schema에 맞춘 최종 응답을 요청할 수 있습니다. 다만 출력 구조가 맞는다고 내용까지 정확한 것은 아닙니다. 파일 근거와 실제 검사 결과는 따로 대조합니다.

한 릴리스 점검에서 무엇을 고를까

5. 첫 실행은 대화형으로 점검 기준을 만듭니다

새로운 저장소나 처음 보는 실패라면 대화형 모드에서 재현 명령, 확인할 위험, 허용할 파일과 최종 출력 형식을 정합니다. 이 과정에서 사람이 실제로 도움이 된 질문과 불필요한 질문을 구분합니다.

자동화로 옮길 것은 반복 가능한 항목뿐입니다. 기준 브랜치와의 diff를 읽고 위험 항목, 근거 파일, 재현 명령, 검토 상태를 내는 작업은 형식을 고정하기 쉽습니다. 원인에 따라 조사 방향이 달라지는 일은 대화형으로 남겨 둡니다.

6. 반복 실행은 codex exec로 옮기고 관찰부터 시작합니다

확정한 프롬프트를 버전 관리하고 읽기 전용 sandbox에서 먼저 실행합니다. 초기에는 Codex의 자연어 판단으로 파이프라인을 차단하지 않습니다. 실제 테스트·빌드 결과와 나란히 기록해 사람이 검토합니다.

출력의 근거가 충분하고 운영 기준이 합의된 뒤에도 배포 판정은 결정적 검사에 둡니다. codex exec 는 누락 가능성을 찾고 검토 메모를 만드는 보조 단계로 사용합니다.

7. 실패하면 대화형 모드로 돌아갑니다

비대화형 실행이 실패하면 JSONL의 turn.failed 나 error , stderr와 종료 상태를 확인합니다. 입력 누락, 필수 MCP 서버 초기화 실패, 권한 부족, 실제 코드 문제를 구분한 뒤 대화형 세션에서 원인을 조사합니다.

자동화 설정을 무작정 넓히지 않습니다. 필요한 파일과 명령을 확인한 뒤 sandbox와 네트워크 범위를 조정합니다. 변경 이유는 검토 기록에 남깁니다.

그대로 복사해 쓸 프롬프트

대화형 모드에서는 이 프롬프트로 조사한 뒤 후속 질문을 이어갑니다. codex exec 에서는 기준 브랜치와 허용 명령을 실행 환경에 맞게 고정하고 출력 스키마를 별도로 관리합니다.

실전 활용 팁

주의할 점

자주 묻는 질문

출처

마무리

릴리스 점검에서 Codex 대화형 모드와 codex exec 를 한 줄로 순위 매길 필요는 없습니다. 원인 조사는 후속 질문이 가능한 대화형 모드에서 합니다. 합의된 검토 절차만 비대화형 실행으로 옮깁니다.

처음에는 대화형으로 기준을 다듬습니다. 반복할 입력·권한·출력을 고정한 뒤 codex exec 를 관찰 모드로 붙입니다. 마지막 배포 결정은 재현 가능한 검사와 실제 diff, 사람 승인으로 마무리합니다.