OpenAI Codex 동향 — CLI에서 클라우드 에이전트까지
"Codex"라는 이름은 지난 몇 년 사이 완전히 다른 의미를 갖게 됐다. 2021년의 Codex는 GitHub Copilot을 돌리던 코드 특화 모델의 이름이었지만, 2026년 초 기준으로 Codex는 OpenAI의 코딩 에이전트 브랜드 전체를 가리킨다. 터미널에서 도는 CLI, 클라우드에서 비동기로 작업을 수행하는 원격 에이전트, IDE 확장까지 모두 Codex라는 우산 아래 묶여 있다.
이 글은 개발자 관점에서 Codex가 어떻게 진화해 왔고, ChatGPT 구독(Plus/Pro)과 API에 어떻게 연결되며, 로컬 CLI와 클라우드 실행이 어떻게 다른지, 그리고 실제 워크플로에서 어디에 끼워 넣으면 좋은지를 정리한다. 빠르게 바뀌는 부분이 많아, 구체적인 수치나 모델명은 "2026년 초 기준"으로 못박아 둔다.
Codex의 세 번의 변신
Codex의 역사를 한 줄로 요약하면 "모델 → CLI → 클라우드 에이전트"다.
1세대: Codex 모델 (2021)
첫 Codex는 GPT-3를 코드 코퍼스로 파인튜닝한 모델이었다. GitHub Copilot의 초기 자동완성 엔진이 바로 이것이었고, 별도의 code-davinci-002 같은 엔드포인트로도 잠깐 API에 노출됐다. 하지만 이후 GPT-4 계열이 코드 능력을 흡수하면서 독립된 "Codex 모델"이라는 개념은 한 번 사라졌다. 즉 지금 우리가 말하는 Codex는 이 1세대와는 계보만 공유할 뿐, 사실상 다른 제품이다.
2세대: Codex CLI (2025)
2025년, OpenAI는 터미널에서 도는 오픈소스 코딩 에이전트로 Codex를 부활시켰다. 이게 Codex CLI다. Claude Code, Aider, Cursor의 에이전트 모드와 같은 범주로, 로컬 저장소를 읽고 파일을 수정하고 명령을 실행하는 에이전트다. 핵심은 세 가지였다.
- 로컬 실행: 코드가 내 머신을 벗어나지 않고, 셸 명령을 직접 돌린다.
- 모델 선택: OpenAI의 추론(reasoning) 계열 모델을 백엔드로 사용한다.
- 승인/샌드박스 모델: 에이전트가 무엇을 실행할지 사용자가 통제한다.
3세대: 클라우드 / 비동기 Codex 에이전트 (2025~2026)
가장 큰 변화는 Codex가 로컬을 벗어난 것이다. 클라우드 Codex는 격리된 원격 컨테이너에서 저장소를 클론받아 작업을 수행한다. "이 버그 고쳐줘"를 던져 놓고 다른 일을 하다가, 완성된 diff나 PR을 받아 보는 비동기(async) 워크플로가 여기서 나온다. 여러 태스크를 병렬로 던질 수 있다는 점이 로컬 CLI와 결정적으로 다르다. 여기에 IDE 확장(VS Code 계열)이 붙으면서, 같은 Codex를 터미널·클라우드·에디터 세 곳에서 일관되게 부를 수 있게 됐다.
Codex가 노출되는 표면(Surface)들
2026년 초 기준으로 개발자가 Codex를 만나는 경로는 크게 네 가지다.
| 표면 | 실행 위치 | 특징 | 잘 맞는 작업 |
|---|---|---|---|
| Codex CLI | 로컬 터미널 | 내 머신, 셸 접근, 오픈소스 | 반복 개발, 로컬 디버깅 |
| Codex 클라우드 에이전트 | 원격 격리 컨테이너 | 비동기·병렬, PR 생성 | 대량 리팩터, 백그라운드 태스크 |
| IDE 확장 | 에디터 내부 | 컨텍스트 공유, 인라인 리뷰 | 코드 리뷰, 소규모 수정 |
| Responses/Agents API | 내 인프라 | 프로그래밍 방식 통합 | 자체 툴·파이프라인 구축 |
여기서 중요한 건 이 표면들이 각각 별도 제품이 아니라 하나의 에이전트를 다르게 부르는 것이라는 점이다. 로컬에서 시작한 대화를 클라우드로 넘기거나, 에디터에서 리뷰하다가 CLI로 이어받는 흐름이 설계 목표다.
ChatGPT 구독과 API — 어디로 결제되나
Codex 사용 권한이 어디에 묶이는지가 개발자 입장에선 은근히 헷갈린다. 2026년 초 기준 큰 그림은 이렇다.
- ChatGPT Plus / Pro 구독에 포함: Codex CLI와 클라우드 에이전트는 별도 API 키 없이 ChatGPT 로그인만으로 쓸 수 있는 경로가 있다. Pro는 Plus보다 넉넉한 사용량과 더 무거운 추론 모델 접근을 준다. 구체적인 한도는 계속 조정되므로 여기 숫자를 적진 않는다 — 공식 페이지에서 확인하는 게 맞다.
- API 키 기반(사용량 과금): 자체 파이프라인이나 CI에 Codex를 태울 때는 플랫폼 API 키로 토큰 단위 과금을 쓴다. 이쪽은 예측 가능한 종량제라 팀 자동화에 적합하다.
즉 개인 개발자는 ChatGPT 구독에 얹어 쓰고, 조직/자동화는 API로 붙인다는 두 갈래를 기억하면 된다. 참고로 이 구독형 정액제 경쟁 구도는 Claude Code $200 vs Codex $200 글에서 실사용 관점으로 비교했다.
로컬 CLI로 시작하기
CLI는 설치 후 저장소 루트에서 바로 부른다. 대략 이런 세션이 나온다.
bash# 설치 (2026년 초 기준, npm 배포) npm install -g @openai/codex # 저장소 루트에서 대화형 실행 cd my-project codex # 한 줄 태스크를 바로 던지기 (non-interactive) codex exec "src/api의 에러 핸들링을 표준화하고 테스트 추가해줘" # 승인 모드를 지정해서 실행 codex --approval-mode auto-edit "타입 에러 전부 수정"
대화형 모드로 들어가면 에이전트가 파일을 읽고, 수정 계획을 제시하고, 셸 명령(테스트 실행 등)을 돌리기 전에 승인을 요청한다. 여기서 핵심이 샌드박스 + 승인 모델이다.
샌드박스와 승인 모델
Codex CLI는 에이전트가 자기 판단으로 셸을 난사하지 못하도록 몇 단계의 승인 레벨을 둔다. 이름과 세부 동작은 버전마다 바뀌지만, 개념적으로는 이런 스펙트럼이다.
- 읽기 전용(suggest): 파일 수정과 명령 실행 모두 매번 사람 승인. 가장 보수적.
- 자동 편집(auto-edit): 파일 수정은 자동, 셸 명령은 승인. 로컬 리팩터에 실용적.
- 완전 자동(full-auto): 격리된 샌드박스 안에서 수정·실행 모두 자율. 네트워크 차단이 기본값.
클라우드 에이전트는 애초에 격리 컨테이너에서 돌기 때문에 이 자율성 부담이 훨씬 덜하다. 반대로 로컬 CLI에서 full-auto를 켤 때는 네트워크 차단과 디렉터리 스코프를 반드시 확인하는 게 안전하다. 에이전트에게 어떤 권한과 환경을 줄지 설계하는 관점은 AI 하네스 엔지니어링에서 더 깊게 다뤘다.
AGENTS.md — 에이전트에게 맥락 주기
Codex는 저장소에 놓인 AGENTS.md를 읽어 프로젝트 규칙을 인식한다. Claude Code의 CLAUDE.md와 같은 역할이며, 사실상 에이전트 생태계 공통 관례로 자리잡았다. 대략 이런 스케치다.
markdown# AGENTS.md ## 프로젝트 개요 Next.js 15 + TypeScript 블로그. 패키지 매니저는 pnpm. ## 명령어 - 개발 서버: `pnpm dev` - 테스트: `pnpm test` (수정 후 반드시 실행) - 린트/타입체크: `pnpm lint && pnpm typecheck` ## 코드 규칙 - 컴포넌트는 함수형 + named export - any 금지, 상태는 zustand로만 - 커밋 메시지는 Conventional Commits ## 하지 말 것 - public/markdown 자동 생성 금지 - 환경변수/시크릿 파일 수정 금지
이 파일 하나로 "테스트 돌려", "any 쓰지 마" 같은 지시를 매번 반복하지 않아도 된다. 클라우드 에이전트에서 특히 효과가 크다 — 사람이 중간에 개입하지 못하는 비동기 실행에서 이 문서가 사실상 유일한 가드레일이기 때문이다.
클라우드 / 비동기 에이전트의 실전 감각
클라우드 Codex의 사용 패턴은 로컬과 사고방식이 다르다.
- 던지고 잊기(fire-and-forget): 여러 이슈를 각각 태스크로 던져 놓고, 완성되면 PR로 받는다. 병렬성이 곧 생산성이다.
- 격리가 기본: 각 태스크가 자기 컨테이너에서 저장소를 클론받아 돈다. 내 로컬 상태를 오염시키지 않는다.
- 결과는 리뷰 대상: 에이전트가 만든 diff/PR을 사람이 리뷰·머지한다. 신뢰하되 검증하는 구조.
한계도 명확하다. 클라우드 컨테이너는 내 로컬 환경(설치된 툴, 시크릿, 실행 중인 DB)을 그대로 갖고 있지 않다. 그래서 환경 설정 스크립트나 의존성 명세가 부실하면 에이전트가 빌드조차 못 돌리는 경우가 생긴다. 환경 재현성이 곧 클라우드 에이전트의 성공률이라고 봐도 된다.
강점과 약점
강점
- 속도와 병렬성: 비동기 태스크를 동시에 여러 개 굴릴 수 있어, "여러 리포에 같은 수정" 같은 작업에서 압도적이다.
- OpenAI 모델 생태계: 추론 계열 모델의 코드·계획 능력이 강하고, 같은 계정으로 다른 OpenAI 제품과 자연스럽게 이어진다.
- 하나의 에이전트, 여러 표면: CLI·클라우드·IDE·API가 같은 브랜드로 묶여 컨텍스트 이동 마찰이 적다.
- 오픈소스 CLI: 로컬 CLI가 오픈되어 있어 동작을 뜯어보고 신뢰를 확인하기 쉽다.
약점 (2026년 초 기준)
- 빠른 변화: 모델명, 승인 모드 이름, 사용량 한도가 자주 바뀐다. 문서를 항상 최신으로 확인해야 한다.
- 클라우드 환경 재현성: 앞서 말한 대로 의존성/환경이 복잡한 프로젝트에서는 클라우드 실행이 헛돌 수 있다.
- 생태계 락인 경향: 구독·모델·표면이 OpenAI로 수렴하다 보니, 멀티 프로바이더 전략과는 마찰이 있다.
- 리뷰 부담: 자율성이 높아질수록 사람이 검증할 diff의 양도 늘어난다. 결국 병목은 리뷰로 옮겨간다.
개발 워크플로 어디에 끼울까
정리하면, 표면별로 이렇게 나눠 쓰는 게 2026년 초 기준 합리적이다.
- 로컬 CLI: 내가 옆에서 지켜보며 반복 개발·디버깅. 셸 접근이 필요한 작업.
- 클라우드 에이전트: 명세가 뚜렷하고 격리 가능한 태스크의 대량·병렬 처리. 자잘한 이슈 소진용.
- IDE 확장: PR 리뷰, 소규모 인라인 수정처럼 에디터 컨텍스트가 중요한 작업.
- API: CI/자체 파이프라인에 코딩 능력을 프로그래밍 방식으로 심을 때.
Codex는 이제 "자동완성 모델"이 아니라 여러 표면에 걸친 코딩 에이전트 플랫폼이다. Claude Code를 비롯한 경쟁 제품들과 함께 시장이 빠르게 재편되는 중이니, 전체 지형은 Claude Code 동향과 2026 AI 코딩 에이전트 지형도를 함께 보면 감이 잡힌다.