OpenAI의 Codex CLI가 변경 로그에는 전혀 적지 않은 일을 해냈다. 약 하루 동안 지속적 배포 파이프라인이 0.143.0 트랙에서 순차 알파 빌드 10개를 잘라냈고, 그중 어느 것도 사람이 읽을 수 있는 릴리스 노트를 싣지 않았다.
CD 파이프라인이 막 내보낸 것: 이어진 Codex 알파 10개
2026년 6월 23일부터 6월 24일 사이, 오픈소스 Codex CLI 저장소는 단일 24시간 롤링 구간 안에서 rust-v0.143.0-alpha.4부터 alpha.13까지 순차 프리릴리스 태그 10개를 공개했다. 첫 번째인 alpha.4는 6월 23일 04:03 UTC에 올라왔고(커밋 c24447e, 에셋 151개) , 열 번째인 alpha.13은 6월 24일 03:24 UTC에 올라왔다(커밋 a67f3ac, 에셋 151개) . 경과 시간은 23시간 21분이었다.
요약 답변: Codex CLI는 2026년 6월 23일부터 24일까지 23시간 21분 동안 순차 0.143.0 알파 빌드 10개(alpha.4부터 alpha.13까지)를 공개했다. CD 파이프라인에서 나온 자동 프리릴리스였고, 각 전체 빌드는 크로스 플랫폼 에셋 151개를 포함했으며, 어느 빌드에도 선별된 "What's Changed" 노트는 없었다.
중간 태그들은 한 번에 쏟아진 것이 아니라 일정한 간격으로 그 구간을 채웠다. 6월 23일(UTC)에는 alpha.5가 08:23, alpha.6이 13:06, alpha.7이 16:34, alpha.9가 18:56에 올라왔다. 6월 24일에는 alpha.11이 01:17, alpha.12가 02:23에 올라왔다 . 이 순서가 UTC 기준 달력 날짜 두 개에 걸쳐 있기 때문에, "하루에 10개"라는 표현은 단일 UTC 날짜가 아니라 24시간 롤링 구간이라는 뜻에서만 정확하다.
각 전체 에셋 항목에는 x86_64와 aarch64용 macOS, Linux, Windows 바이너리와 체크섬, 서명까지 합쳐 크로스 플랫폼 바이너리 151개가 담겨 있다. 이는 사람이 직접 커밋한 것이 아니라 저장소의 자동 릴리스 워크플로가 내보낸 것이다 . 에셋 수가 단서다. 이는 손으로 정리한 마일스톤들의 연속이 아니라, 필요할 때 태그를 잘라내는 패키징 파이프라인이다.
이 트랙은 alpha.13에서 멈추지 않았다. 같은 0.143.0 시리즈는 6월 24일부터 25일까지 alpha.14, .15, .16, .21, .22, .25로 이어졌고, 앞선 alpha.1부터 alpha.5 빌드는 6월 22일부터 23일 사이에 등장했다. 그 결과 전체 알파 트랙은 나흘도 안 되어 공개 태그 20개를 넘겼다 .
alpha.8과 alpha.10의 에셋이 151개가 아니라 2개인 이유
두 항목은 패턴에서 벗어난다. 이 시리즈의 전체 알파 페이지는 모두 크로스 플랫폼 에셋 151개를 담고 있지만, alpha.8(커밋 f2a0f9d, 태그 시각 2026-06-23 17:17 UTC)과 alpha.10(커밋 1ec3def, 태그 시각 2026-06-23 23:51 UTC)은 각각 에셋이 2개뿐이다 .
출처도 다르다. 둘 다 이 트랙의 다른 모든 항목을 만든 저장소 자동 릴리스 워크플로가 아니라, 사용자 계정 rka-oai가 태그를 달았다 . 바이너리도, 체크섬도, 서명도 붙어 있지 않으므로 어느 태그도 설치 가능한 상태가 아니다. 최종 사용자 빌드로서는 사실상 쓸 수 없다.
| 태그 | 커밋 | 태그 시각(UTC) | 에셋 | 출처 |
|---|---|---|---|---|
| alpha.8 | f2a0f9d | 2026-06-23 17:17 | 2 | rka-oai |
| alpha.10 | 1ec3def | 2026-06-23 23:51 | 2 | rka-oai |
| 다른 알파 | 각각 다름 | — | 151 | release workflow |
증거만 놓고 보면 세 가지 해석이 모두 그럴듯하다.
- 의도적인 경량 마커 — 커밋을 표시하기 위해 수동으로 자른 최소 내부 태그이며, 바이너리 배포를 의도하지 않았을 수 있다.
- 부분 실행 또는 실패한 CI 실행 — 릴리스 작업이 일부만 실행되어 패키징 단계 없이 태그만 남았을 수 있다.
- 스테이징 산출물 — 배포 목적은 아니었지만 공개적으로 보이게 된 내부 스캐폴딩일 수 있다.
공개 기록만으로는 어느 쪽인지 결론낼 수 없다. 두 태그 페이지는 존재하고 색인도 가능하지만, 어느 쪽도 "What's Changed" 본문이나 별도의 설명을 달고 있지 않다 . 릴리스 목록을 훑는 사람에게 실무적인 신호는 더 단순하다. 의도가 무엇이든 에셋 수가 2개라면 설치할 수 없는 태그라는 뜻이다.
65개 리비전에 걸쳐 엔지니어링 변경이 다룬 것
무엇이 바뀌었는지를 가장 분명하게 보여주는 신호는 두 전체 에셋 엔드포인트를 비교한 GitHub 자체 결과다. base c24447e(alpha.4)와 head a67f3ac(alpha.13)를 놓고 보면, 두 ref는 갈라진 상태로 보고된다. alpha.13은 65개 커밋 앞서 있고 1개 커밋 뒤처져 있다 . 여기서 핵심은 그 모양새다. 단일 핫픽스가 아니라 여러 서브시스템에 넓게 걸친 변경이라는 점이다.
파일 단위 diff는 Codex App Server 프로토콜, MCP와 플러그인, Windows 파일시스템 샌드박스, 원격 실행과 신뢰, Code Mode 호스트 스캐폴딩이라는 다섯 영역에 동시에 걸쳐 있다 . 서버 API를 소비하는 쪽에는 스키마 수준의 이동이 가장 중요하다. TypeScript 출력에 새 ThreadExtra 타입이 추가되고, thread processor가 바뀌었으며, code-mode host 프로토콜 파일이 새로 들어간 변화는 기능 플래그로 미리 경고되지 않은 채 클라이언트까지 파급될 수 있다.
| 서브시스템 | 이 범위에서 보이는 대표 변경 |
|---|---|
| App Server 프로토콜 | 새 ThreadExtra TypeScript 타입, 변경된 thread processor, 추가된 code-mode host 프로토콜 파일 |
| MCP & 플러그인 | 툴 호출 오류 메트릭 추가, 설치/제거 분석을 로컬 플러그인 ID와 원격 플러그인 ID로 분리, manifest 경로 해석을 설치 위치와 분리 |
| Windows 샌드박스 | 샌드박스 헬퍼 호출 사이에 프록시 상태 보존, PAC/WPAD/static 프록시 지원, 안전 승인 필요 PowerShell 명령 처리 안정화 |
| 원격 실행 & 신뢰 | 선택된 환경에서 view_image 경로 해석, 신뢰된 Codex Apps의 app-review 메타데이터에 연결 계정 이메일 주입, exec-server가 작업 디렉터리 보고 |
함께 읽어보면, 커밋 메시지들은 헤드라인 기능이 아니라 통합과 안정화 흐름을 가리킨다. Windows 샌드박스 헬퍼의 프록시 상태 보존, provider auth를 통한 이미지 생성 허용, 도구에 현재 step 환경 사용, MCP 툴 호출 오류 메트릭 추가, 로컬과 원격 플러그인 분석 ID 분리, 오래된 approval-policy 테스트 참조 수정 등이 그렇다 . 추가되거나 업데이트된 테스트도 코드와 함께 많이 움직였고, 이는 출시보다는 경화 작업에 더 가깝다.
"프로토콜, 샌드박스, 텔레메트리에 이렇게 고르게 퍼진 65개 커밋은 선별된 마일스톤이라기보다 안정화 작업을 병합하는 CD 흐름처럼 읽힌다. 단서는 테스트 변경량이다." — 공개 compare 로그 기반 편집부 평가 (source: GitHub compare, alpha.4…alpha.13).
통합 담당자에게 실질적으로 남는 결론은 다시 테스트해야 할 표면이다. 클라이언트 호환성을 위한 App Server 스키마, 텔레메트리 파싱을 위한 MCP 오류 메트릭 경로, 샌드박스 실행을 위한 Windows 프록시와 PowerShell 승인 흐름이다. 이 중 어느 것도 사용자에게 보이는 기능으로 발표되지는 않았지만, 스키마와 신뢰 메타데이터 변경은 pin이 움직일 때 downstream 소비자를 조용히 깨뜨릴 수 있는 종류다.
어떤 alpha에도 정리된 릴리스 노트가 없다는 뜻
alpha.4부터 alpha.13까지의 페이지 어디에도 채워진 "What's Changed" 섹션은 없다 . 이것이 stable 라인과의 실질적인 차이다. 0.142.0과 0.142.2 항목은 /usage 크레딧, 플러그인 재구성, MCP 수정처럼 서브시스템별로 나눈 사람이 쓴 분류형 노트를 제공하지만, alpha들은 changelog 필드가 비어 있거나 희박하다 .
따라서 재구성할 수 있는 유일한 경로는 앞 절에서 쓴 방식뿐이다. 두 태그 커밋 사이의 원시 GitHub compare를 보는 것이다. diff는 미리 소화된 형태로 제공되지 않는다. alpha.4와 alpha.13 사이에서 무엇이 움직였는지, 즉 65개 커밋 앞서 있고 1개 뒤처진 내용을 알려면 커밋 로그를 직접 읽어야 한다 . 훑어볼 수 있는 빌드별 요약은 없다.
최신 alpha로 자동 업데이트하는 CI에서는 이 점이 구체적으로 중요해진다.
- 커밋 기록 외에는 감사 추적 없이 실행마다 동작이 바뀔 수 있다.
- 이 트랙은 나흘도 안 되어 20개가 넘는 빌드를 지나갔기 때문에
0.143.0-alpha.N에 pin을 걸어도 몇 시간 안에 뒤따르는 빌드가 나올 수 있다 . - 명시적으로 pin하지 않는 팀은 스키마와 신뢰 메타데이터 변경을 조용히 물려받는다.
호의적으로 읽으면, 이는 의도된 방식이다. 자동화된 pre-release 파이프라인의 alpha 태그는 downstream 소비자를 위한 커뮤니케이션 산물이 아니라 내부 QA 검증을 위한 스냅샷 참조다. OpenAI 자체 설치 문서도 대부분의 사용자를 alpha 트랙이 아니라 stable 채널로 안내한다 . 암묵적 계약은 이렇다. 공지되지 않은 빌드를 선택한다면, 커밋 로그가 유일한 changelog라는 점도 받아들이는 것이다.
알파 시리즈를 봐야 하는 사람과 무시해도 되는 사람
대부분의 팀에는 0.143.0 알파 트랙을 잡음으로 봐도 됩니다. 이 시리즈가 의미 있는 경우는 출시 전 동작을 의도적으로 확인하는 일부 실무자에 한정됩니다. 기본 설치 채널로 Codex를 쓰는 사람이라면 이 빌드를 보게 될 일도, 필요로 할 일도 없습니다.
다음에 해당한다면 알파 시리즈를 추적할 만합니다.
- 출시 전 채널에서 특정 수정 사항을 검증하는 경우 — 예를 들어 Windows 파일시스템 샌드박스의 프록시 상태 보존이나
view_image경로 해석 수정이 alpha.4부터 alpha.13 사이에 반영됐는지 확인하는 경우입니다 . - 미출시 app-server 스키마에 맞춰 플러그인이나 MCP를 통합하는 경우 — 새
ThreadExtra타입과 변경된 thread processor를 포함합니다 . - 대규모 배포 전에 Windows 샌드박스 프록시 동작을 엔터프라이즈 환경에서 검증하는 경우 — stable 0.142.x에 포함된 curated system-proxy 지원보다 앞서 확인하려는 경우입니다 .
npm 패키지 @openai/codex, Homebrew cask codex, 또는 표준 standalone installer로 Codex를 설치한다면 이 트랙은 완전히 무시해도 됩니다. 이런 기본 경로는 stable 채널을 사용하며 0.143.0-alpha.N 빌드를 자동으로 가져오지 않습니다 .
꼭 고정해야 한다면 두 가지 원칙이 있습니다. 첫째, 0.143.0-alpha.N은 몇 시간 안에 대체될 수 있으므로 pin은 안정 기준선이 아니라 특정 시점의 스냅샷입니다. 둘째, 151개의 크로스플랫폼 asset을 포함한 전체 asset 태그에만 고정해야 합니다. alpha.8이나 alpha.10처럼 2개 asset만 있는 lightweight tag는 실제 배포에 필요한 패키징된 바이너리가 없으므로 피해야 합니다 .
실질적인 결론은 분명합니다. 대부분의 팀에는 stable 0.142.2가 권장 대상입니다. 이 버전에는 Windows와 macOS system-proxy 지원, 여러 MCP 수정, dark-mode plugin logo를 다룬 완성된 curated note가 포함되어 있습니다 . 그 버전에 고정하고, 0.143.0이 자체 changelog와 함께 최종화된 뒤 다시 검토하면 됩니다. 그 전에는 아닙니다.
자주 묻는 질문
Codex 0.143.0-alpha는 무엇이고 왜 이렇게 많은 빌드가 빠르게 나왔나요?
Codex 0.143.0-alpha는 OpenAI의 오픈소스 Rust 기반 터미널 코딩 에이전트의 출시 전 개발 트랙입니다. 알파 태그는 사람이 정리한 마일스톤이 아니라 기계가 생성한 스냅샷입니다. continuous-delivery pipeline이 0.143.0 브랜치에 조건을 충족하는 merge가 들어올 때마다 새 pre-release tag를 자릅니다. 그래서 alpha.4부터 alpha.13까지, 연속된 10개의 버전 번호가 약 23시간 21분 동안 올라온 것입니다 . 이 속도는 특별 이벤트가 아니라 빠르게 움직이는 merge queue를 반영합니다.
alpha.8과 alpha.10은 왜 151개가 아니라 2개 asset만 있나요?
전체 알파 페이지에는 각각 151개의 크로스플랫폼 asset(macOS/Linux/Windows 바이너리와 checksum, signature)이 있지만, alpha.8과 alpha.10에는 2개 asset만 노출되어 있습니다 . 두 태그 모두 자동 release workflow가 아니라 개인 계정(rka-oai)이 각각 2026-06-23 17:17 및 23:51 UTC에 태그했습니다 . lightweight internal marker이거나 부분적인 CI job artifact일 가능성이 크지만, 공개 기록만으로는 어느 쪽인지 확인되지 않습니다.
alpha.4와 alpha.13 사이에는 실제로 무엇이 바뀌었나요?
GitHub의 공식 compare에 따르면 alpha.13은 alpha.4보다 65 commits ahead, 1 behind 상태입니다 . 파일 단위 변화는 단일 hotfix라기보다 폭넓게 퍼져 있습니다. 새 ThreadExtra 타입을 포함한 app-server protocol schema, MCP tool-call error metric, plugin install/analytics 변경, Windows sandbox proxy state, remote-environment 및 view_image 경로 처리, Codex Apps용 trust metadata, 그리고 다수의 추가 테스트가 포함됩니다 . headline feature라기보다는 통합과 안정화 흐름에 가깝습니다.
프로덕션이나 CI에서 Codex 0.143.0-alpha에 고정해야 하나요?
대부분의 팀에는 권장하지 않습니다. 이 시리즈의 어떤 알파에도 curated release note가 없고, 빌드는 몇 시간 안에 대체될 수 있으며, regression이 생겨도 별도 공지 없이 들어옵니다 . 조사일 기준 developer changelog도 여전히 0.142.2에서 끝나며 최종화된 0.143.0 항목은 없습니다 . Windows/macOS system-proxy 지원과 여러 MCP 수정에 대한 완성된 note를 포함한 stable 0.142.2가 0.143.0이 최종화될 때까지 올바른 대상입니다.
release note가 없을 때 특정 알파의 변경 사항은 어떻게 확인하나요?
관심 있는 두 tag commit 사이의 GitHub compare URL을 사용하면 됩니다. Files Changed view와 commit list가 유일한 changelog입니다. 이번 연속 릴리스의 경우 alpha.4(base c24447e)와 alpha.13(head a67f3ac)을 비교하면 전체 65-commit diff와 merge base 27f22b5가 드러납니다 . 이 시리즈의 어떤 알파에도 사람이 읽기 좋게 정리한 요약은 제공되지 않으므로, commit message 자체가 신호입니다 .
