Codex CLI v0.133.0 Goals와 Remote-Control 데몬 구조
Codex CLI v0.133.0의 Goals 저장·체크포인트·재개 실행과 Remote-Control 데몬의 프로세스 및 IPC 구조를 분석한다.
2026-08-14 · 최초 발행 2026-06-10
일회성 명령에서 지속되는 목표로
2025년 5월 21일 릴리즈된 Codex CLI v0.133.0은 Goals를 실험적 플래그에서 기본 활성화 상태로 옮겼다. 동시에 codex remote-control은 포그라운드 준비 상태 표시와 데몬 방식의 시작·중지를 지원한다.
두 변화는 서로 맞물린다. Goals가 목표와 진행 상황을 저장한다면 Remote-Control은 그 목표를 수행하는 프로세스를 터미널 세션 밖에서도 계속 운영한다. CLI 에이전트의 역할이 한 번의 프롬프트를 처리하는 도구에서 장기 실행 자동화 프로세스로 넓어지는 구조다.
자연어 목표를 추적 가능한 객체로 바꾸는 Goals
Goals 파이프라인은 사용자가 자연어로 입력한 의도를 에이전트가 추적하고 평가할 수 있는 구조화된 목표 표현으로 변환한다. Goal 객체는 단순한 문자열 레이블이 아니다. 식별자(ID), 원문 서술(Description), 성공 기준(Success Criteria), 우선순위(Priority), 의존 목표(Dependencies), 생성 타임스탬프, 상태(Status)를 포함하는 JSON 스키마로 영속화된다.
이 구조에서 핵심은 성공 기준이다. 결과물 기반 기준(Artifact-Based Criterion)은 파일 생성 여부나 코드 컴파일, 테스트 케이스 통과처럼 산출물의 존재와 상태를 검사한다. 상태 기반 기준(State-Based Criterion)은 환경 변수, 프로세스 실행 여부, API 응답 코드와 같은 시스템 상태가 목표에 도달했는지 판정한다. 두 방식으로 다루기 어려운 주관적이거나 복합적인 조건은 LLM 평가 기준(LLM-Judged Criterion)으로 넘긴다. LLM 평가는 비용이 높으므로 결과물 또는 상태 기반 기준으로 확인할 수 없는 부분에 선택적으로 적용한다.
목표는 로컬 파일시스템의 ~/.codex/goals/ 아래에 목표별 JSON 파일로 저장된다. 저장소는 멱등성(Idempotency)을 중심으로 설계됐다. 같은 서술의 목표가 다시 생성되면 기존 상태를 초기화하지 않고 기존 레코드를 반환해 진행 상황의 유실을 막는다. 목표 ID는 서술 내용의 해시와 생성 시각을 조합해 만들며, 이를 통해 명시적인 충돌 없이 목표를 안정적으로 참조한다.
진행 이력과 중간 결과를 보존하는 체크포인트
Goal의 상태는 완료와 미완료만으로 구분되지 않는다. PENDING(대기), IN_PROGRESS(실행 중), BLOCKED(외부 의존성 대기), PAUSED(사용자 중단), COMPLETED(성공 완료), FAILED(실패), CANCELLED(취소)의 일곱 상태를 사용한다. 상태 전이는 이벤트 소싱(Event Sourcing) 방식으로 기록되므로 전체 변경 이력을 보존하고 특정 시점의 상태로 되돌릴 수 있다.
장기 작업의 중간 결과는 체크포인트로 영속화한다. 자동 체크포인트(Automatic Checkpoint)는 의미 있는 중간 목표(Sub-Goal)가 끝날 때마다 저장된다. 중간 목표는 최상위 Goal의 실행 계획을 이루는 원자적 단계(Atomic Step)이며, 단계가 완료되면 출력, 컨텍스트 스냅샷, 소요 토큰이 체크포인트 파일에 기록된다.
저장 시점을 사용자가 지정할 수도 있다. 수동 체크포인트(Manual Checkpoint)는 다음 명령으로 생성한다.
codex goal checkpoint <goal-id>
체크포인트는 ~/.codex/goals/<goal-id>/checkpoints/ 아래의 타임스탬프 기반 디렉토리에 배치된다. 각 디렉토리에는 상태 스냅샷인 state.json, 실행 컨텍스트인 context.json, 생성된 파일 목록인 artifacts.json, 실행 기록인 execution.log가 들어간다.
저장 용량을 관리하기 위해 기본적으로 최근 10개의 체크포인트만 유지하며 오래된 항목은 자동으로 정리한다. 보존 개수는 ~/.codex/config.json의 goals.checkpoint.maxCount 설정으로 조정할 수 있다.
중단 지점에서 실행을 잇고 성공을 판정하는 방식
네트워크 오류나 시스템 재시작, 사용자 강제 종료로 작업이 끊겨도 Goal 자체는 남는다. 다음 명령을 실행하면 마지막 체크포인트부터 작업을 재개한다.
codex goal resume <goal-id>
재개 과정에서는 저장된 컨텍스트 스냅샷으로 중단 당시의 상태를 복원한다. 완료된 단계는 다시 수행하지 않고 남은 단계부터 실행을 이어 간다.
목표의 완료 여부는 성공 기준별 평가기(Evaluator)를 주기적으로 호출하는 폴링(Polling) 방식으로 확인한다. 결과물 기반 평가기는 파일 존재 여부와 파일 내용 해시, 명령의 종료 코드를 검사한다. 상태 기반 평가기는 지정된 시스템 상태 쿼리의 결과를 기대값과 비교한다.
LLM 평가 기준을 사용하면 현재 상태의 스냅샷과 최초 성공 기준 서술을 하나의 프롬프트로 구성해 언어 모델에 전달한다. 모델은 PASS 또는 FAIL 레이블과 근거(Rationale)를 반환한다.
평가 간격은 목표의 예상 소요 시간과 우선순위에 따라 달라진다. 예상 소요가 1분 미만인 단기 목표는 10초마다 평가하고, 1시간 이상 걸리는 장기 목표는 5분 간격으로 평가한다. 정해진 주기와 별도로 개별 실행 단계가 끝날 때도 평가를 즉시 트리거해 조기 완료를 감지한다.
Remote-Control이 다루는 프로세스 생명주기
v0.133.0의 codex remote-control 서브커맨드는 포그라운드와 데몬 실행을 모두 다룬다. 포그라운드에서는 표준 터미널 출력 스트림에 실시간 상태를 렌더링한다. 연결된 에이전트 세션 수, 세션별 Goal 진행률, 도구 호출 빈도, 평균 응답 지연을 TUI(Text User Interface)로 보여 준다.
장기 자동화에서는 터미널 연결이 끊긴 뒤에도 프로세스가 살아 있어야 한다. 다음 명령은 remote-control 프로세스를 POSIX 데몬 방식으로 분리한다.
codex remote-control start --daemon
부모 프로세스는 자식 프로세스를 fork한 뒤 즉시 종료한다. 자식은 setsid를 호출해 새로운 세션 리더가 되고 제어 터미널에서 분리된다. 이후 표준 입출력 스트림은 /dev/null로 리다이렉션되고 실행 로그는 ~/.codex/logs/remote-control.log에 기록된다.
데몬의 생명주기는 ~/.codex/run/rc.pid에 저장된 PID 파일을 중심으로 관리한다. 시작할 때 파일을 만들고 정상 종료할 때 삭제한다. codex remote-control start --daemon을 다시 실행하면 PID 파일뿐 아니라 해당 PID가 실제로 실행 중인지 확인해 데몬의 중복 실행을 막는다.
비정상 종료로 PID 파일만 남은 Stale PID 상태에서는 다음처럼 기존 파일을 무시하고 새 데몬을 시작할 수 있다.
codex remote-control start --daemon --force
Unix Domain Socket을 통한 상태와 이벤트 교환
Remote-Control 데몬과 Codex CLI 인스턴스는 Unix Domain Socket(UDS)으로 통신한다. 같은 호스트에서 TCP 소켓보다 오버헤드가 낮고 파일 권한으로 접근을 통제할 수 있다는 특성을 이용한 설계다.
소켓 파일은 ~/.codex/run/remote-control.sock에 놓인다. 소유자(Owner)에게만 읽기와 쓰기 권한을 부여해 다른 사용자의 접근을 차단한다.
IPC 프로토콜은 길이-접두사 프레이밍(Length-Prefixed Framing)을 적용한 JSON 메시지를 사용한다. 메시지 앞에는 페이로드 길이를 나타내는 4바이트 빅엔디언 정수가 오고, 그 뒤에 JSON 페이로드가 이어진다.
메시지 교환은 Request-Response와 Server-Sent Event(SSE) 패턴을 함께 지원한다. 현재 활성 세션 목록이나 특정 Goal의 진행률처럼 한 번 조회하고 응답받는 작업에는 요청-응답 패턴을 쓴다. 실행 로그 스트리밍과 이벤트 알림 구독은 SSE 패턴으로 처리한다.
상태 갱신도 풀(Pull)과 푸시(Push)를 혼합한다. 포그라운드 TUI는 100ms 간격으로 소켓에 상태 조회 요청을 보내 화면을 갱신한다. Goal 완료, 에이전트 오류, 외부 트리거와 같은 비동기 이벤트는 데몬이 구독 클라이언트에 능동적으로 전달한다. 지속적인 화면 갱신과 중요 이벤트의 즉시 전달을 서로 다른 방식으로 해결한 것이다.
여러 세션을 제한하고 안전하게 종료하기
Remote-Control은 여러 Codex CLI 프로세스를 동시에 관리하는 멀티플렉서(Multiplexer)로 작동한다. 각 세션 레코드에는 고유한 세션 ID, 연결된 Goal 목록, 실행 중인 도구 호출 스택, 누적 토큰 소비량이 담긴다.
활성 세션의 상한은 기본값 8이다. 동시에 너무 많은 세션이 실행돼 API 요율 제한(Rate Limit)을 초과하지 않도록 둔 제약이다. 상한을 넘은 새 세션은 대기 큐로 들어가며, 활성 세션이 종료될 때 순서대로 실행 상태로 전환된다.
운영체제의 서비스 매니저와 연결하면 데몬의 시작과 중지도 자동화할 수 있다. macOS에서는 다음 명령이 ~/Library/LaunchAgents/ 아래에 plist 파일을 만들고 launchd에 데몬을 등록한다.
codex remote-control install-service
이 구성은 로그인 시 자동 시작, 비정상 종료 후 자동 재시작, 시스템 종료 시 graceful shutdown을 운영체제 수준에서 처리한다. Linux에서는 ~/.config/systemd/user/ 아래에 systemd user unit 파일을 생성해 같은 기능을 구현한다.
정상 종료에는 다음 명령을 사용한다.
codex remote-control stop
데몬이 SIGTERM을 받으면 새로운 세션 연결을 더 이상 수락하지 않고 활성 세션에 종료 예고(Shutdown Notice)를 보낸다. 각 세션은 현재 수행 중인 원자적 단계를 마친 뒤 체크포인트를 저장하고 종료한다. 모든 세션이 끝나거나 30초 타임아웃이 지나면 데몬이 종료되며 PID 파일과 소켓 파일도 정리된다.
즉시 종료해야 할 때는 다음 명령으로 SIGKILL을 전송한다.
codex remote-control stop --force
Goals가 기본 기능이 됐다는 의미
기능이 experimental 상태를 벗어나 default-on으로 전환되는 일은 플래그 하나를 바꾸는 데 그치지 않는다. 안정성, 성능, 하위 호환성, 오류 복구가 임의의 사용자에게 노출돼도 수용할 수 있는 수준에 도달했다는 프로젝트 팀의 판단을 뜻한다.
Codex CLI팀이 Goals의 졸업 기준으로 적용했을 것으로 추론되는 지표에는 평균 목표 완료율, 체크포인트 재개 신뢰도, 저장소를 오염시키지 않는 안전한 실패(Safe Failure)가 있다. 다양한 복잡도의 Goals를 다룬 내부 벤치마크에서는 재개 없이 첫 시도에 완료하는 비율이 일정 임계값인 추정 80% 이상이어야 한다. 임의 시점에 중단했다 재개해도 결과의 동등성이 보장돼야 하며, 부분 실패가 발생해도 Goals Store는 일관된 상태를 유지해야 한다.
사용 경로도 달라진다. 이전에는 --experimental-goals 플래그를 명시해야 했지만, 기본 활성화 이후에는 codex goal 서브커맨드가 최상위 명령어 계층에 직접 노출된다. CLI 도움말과 자동 완성에도 포함된다. Goals 기반 장기 실행 자동화를 Codex CLI의 핵심 사용 패턴으로 다루겠다는 제품 방향이 명령 체계에 반영된 셈이다.
다른 에이전트 도구와 구분되는 CLI의 자리
2026년 현재 AI 에이전트 코딩 도구는 IDE 통합형인 Cursor Bugbot과 GitHub Copilot Workspace, API/SDK 기반인 Claude Code Auto Mode와 OpenAI Codex API, CLI 네이티브인 Codex CLI로 나눠 볼 수 있다. 각 범주는 서로 다른 사용자와 워크플로우를 겨냥하며, 단순한 우열보다 역할의 차이가 크다.
Claude Code Auto Mode는 자율 실행의 깊이와 멀티파일 코드베이스 이해에 강점이 있지만 Claude Code 클라이언트인 IDE 또는 웹 실행 환경에 종속된다. Cursor Bugbot은 GitHub 이벤트와 PR 리뷰·버그 수정 사이클을 직접 연결해 CI/CD 파이프라인 자동화에 맞춰져 있으나 로컬 개발 환경에서 임의 셸 명령을 실행하는 권한은 제한적이다.
Codex CLI는 로컬 셸에 대한 완전한 접근과 사용자 정의 도구 체인(Custom Toolchain)의 통합을 전제로 한 터미널 네이티브 도구다. 도커 컨테이너 오케스트레이션이나 빌드 시스템 연동, 레거시 스크립트 래핑처럼 IDE에 종속되지 않는 자동화가 필요한 영역에서 구별되는 위치를 차지한다.
Goals의 기본 활성화와 Remote-Control 데몬은 이러한 CLI의 성격을 강화한다. 선택의 기준은 단일 프롬프트에서 생성되는 코드의 품질만이 아니다. 복잡한 멀티스텝 작업을 기존 터미널 흐름에 얼마나 자연스럽게 연결할 수 있는지도 중요하다. 체크포인트와 재개 실행은 작업의 지속성을 맡고, 백그라운드 데몬은 실행 환경의 지속성을 담당한다.
터미널 에이전트가 운영 인프라로 확장되는 방향
초기 AI 코딩 도구가 단발성 코드 생성(One-Shot Code Generation)에 집중했다면 Goals 기반 자동화는 에이전트를 태스크의 공동 실행자(Co-Executor)로 다룬다. 에이전트는 장기 목표를 추적하고 중간 상태를 평가하며 실패하면 재시도한다. 필요한 순간에는 사람에게 판단을 요청하는 반자율적(Semi-Autonomous) 실행자로 동작한다.
여기에는 지속성(Persistence), 관찰 가능성(Observability), 통합성(Composability)이라는 설계 방향이 함께 나타난다. 에이전트 상태는 메모리에만 머물지 않고 파일시스템에 기록돼 프로세스 경계를 넘는다. Remote-Control TUI 같은 모니터링 인터페이스도 편의 기능에 그치지 않고 실행 구조의 일부가 된다. 데몬 시작·중지와 서비스 매니저 연동은 Codex CLI를 운영체제 수준의 자동화 구성 요소로 편입한다.
향후에는 Goals 사이의 의존성을 DAG 기반 복합 목표 워크플로우로 정교하게 관리하거나, Goals Store를 서버와 동기화해 팀이 공유하는 방향을 예상할 수 있다. 웹훅, 파일 변경, cron 같은 외부 이벤트 트리거와의 통합도 자연스러운 확장 경로다. 이러한 확장이 실현된다면 Codex CLI는 개인 개발 도구에서 소규모 팀의 AI 기반 개발 자동화 플랫폼으로 위치를 바꿀 수 있다.
v0.133.0에서 결합된 Goals와 Remote-Control은 터미널 에이전트에 필요한 상태 저장, 실행 재개, 완료 판정, 프로세스 관리, 관찰 인터페이스를 하나의 흐름으로 묶는다. IDE와 분리된 셸 네이티브 자동화가 필요한 개발자라면 레거시 셸 스크립트 파이프라인을 대신할 실행 구조로 Codex CLI를 다시 평가할 만한 변화다.