Published on

Codex CLI와 Codex App: 같은 에이전트, 다른 운영 표면

Authors

Codex CLI · Codex App · Worktrees · Cloud Tasks · Sandbox · Developer Workflow

OpenAI Codex를 쓴다는 말은 이제 한 가지 제품을 뜻하지 않는다. 같은 모델 계열과 같은 ChatGPT 계정 위에 있지만, 실제 작업 표면은 적어도 네 갈래로 나뉜다. 터미널에서 바로 쓰는 Codex CLI, 데스크톱 작업 허브인 Codex app, VS Code 계열에 붙는 IDE extension, 그리고 GitHub 저장소를 연결해 클라우드에서 돌리는 Codex web / cloud다.

이 글의 결론부터 말하면 단순하다. CLI는 “내 손 안의 로컬 에이전트”이고, App은 “여러 에이전트 작업을 운영하는 데스크톱 관제실”이다. 둘 다 코드를 읽고, 고치고, 테스트를 돌릴 수 있다. 하지만 좋은 사용처는 다르다. CLI는 깊게 파고드는 단일 작업, 즉시 확인해야 하는 수정, 기존 터미널 습관과 맞물리는 작업에 강하다. App은 여러 스레드, 워크트리, 자동화, Git 작업, 클라우드 위임을 묶어 “작업 포트폴리오”를 관리할 때 빛난다.

Codex CLI와 Codex App 비교 커버

OpenAI의 Codex 제품 페이지는 Codex를 “AI로 빌드하고 출시하도록 돕는 코딩 에이전트”로 설명한다. 여기까지는 평범하다. 중요한 변화는 그 다음이다. OpenAI는 Codex app을 “agentic coding의 command center”로 포지셔닝하고, CLI는 로컬 터미널에서 돌아가는 빠르고 개방적인 에이전트 harness로 둔다. 즉 모델의 문제가 아니라 작업을 어디에 놓고, 어떤 권한으로, 얼마나 오래, 몇 개나 병렬로 돌릴 것인가의 문제로 바뀌고 있다.

CLI는 제품이라기보다 “로컬 런타임”에 가깝다

Codex CLI 문서는 첫 문장에서 성격을 분명히 한다. Codex CLI는 터미널에서 로컬로 실행되는 OpenAI의 코딩 에이전트이며, 선택한 디렉터리 안의 코드를 읽고, 변경하고, 명령을 실행할 수 있다. GitHub의 openai/codex README도 “runs locally on your computer”라고 못박고, 설치 방법을 npm i -g @openai/codex 또는 Homebrew cask로 안내한다.

이 차이는 생각보다 크다. CLI를 켜는 순간 작업의 기본 단위는 “현재 디렉터리”다. 이미 터미널에서 repo를 열어 놓았고, 로컬 브랜치와 untracked 파일과 .env가 있으며, 테스트 명령과 빌드 캐시와 개발 서버가 있다. Codex CLI는 그 현장에 바로 들어온다. 별도 UI에서 프로젝트를 다시 정의하는 것이 아니라, 개발자가 지금 서 있는 작업 디렉터리를 에이전트의 현실로 삼는다.

Codex CLI 로컬 런타임

그래서 CLI는 다음 유형의 작업에 강하다.

  • 지금 열어 둔 브랜치에서 작은 버그를 바로 고치기
  • 테스트 실패를 보고 원인을 추적하기
  • 로컬 개발 서버, DB, fixtures, 캐시가 필요한 작업을 함께 다루기
  • git diff, pytest, pnpm test, node scripts/... 같은 습관적 명령 흐름에 붙이기
  • 에이전트의 판단을 자주 끊고 사람이 바로 확인해야 하는 작업

OpenAI 문서의 Codex CLI features는 이 방향을 그대로 보여 준다. 인터랙티브 TUI, /model 기반 모델·reasoning 전환, 이미지 입력, 로컬 코드 리뷰, subagents, 웹 검색, codex exec 스크립팅, MCP, approval modes가 한 화면에 묶여 있다. 특히 로컬 코드 리뷰는 CLI적이다. Codex가 base branch와 merge base를 기준으로 diff를 보고, PR을 열기 전에 큰 리스크를 잡아 주는 흐름이다.

CLI의 장점은 “작업을 시작하는 마찰”이 낮다는 점이다. 반대로 한계도 명확하다. 여러 작업을 오래 병렬로 굴리고, 각 작업의 상태를 나중에 다시 찾고, 결과를 inbox처럼 triage하고, worktree를 자동 정리하고, 데스크톱 알림까지 받는 운영 표면은 CLI만으로는 불편하다. 물론 CLI에도 codex cloud 명령과 non-interactive mode가 있다. 하지만 기본 체감은 여전히 “지금 이 terminal session에서 같이 코딩한다”에 가깝다.

App은 채팅 앱이 아니라 worktree 운영 도구다

Codex app 문서는 앱을 “focused desktop experience for working on Codex threads in parallel”이라고 설명한다. 여기서 핵심 단어는 desktop도, chat도 아니다. threads in parallel이다. Codex app의 목적은 에이전트와 대화하는 창을 예쁘게 만드는 것이 아니라, 여러 코딩 작업을 동시에 열고 관리하는 것이다.

Codex app features를 보면 방향이 더 분명해진다. 프로젝트를 여러 개로 나누고, Local / Worktree / Cloud 모드를 선택하며, Git diff pane에서 변경을 보고, 특정 chunk를 stage 또는 revert하고, 앱 안에서 commit, push, pull request 생성까지 할 수 있다. 각 thread에는 프로젝트나 worktree에 scoped 된 integrated terminal이 붙고, 배경 작업 완료 또는 approval 필요 시 notification을 보낸다.

Codex App 데스크톱 관제실

이건 개발자용 “카톡”이 아니다. 오히려 작은 agent PM 툴에 가깝다. App은 작업을 thread로 만들고, thread를 local checkout이나 worktree나 cloud에 배치하고, 결과를 diff와 Git 액션으로 수렴시킨다. 사람이 코드를 직접 쓰는 시간이 줄어들수록 중요한 것은 “어떤 작업을 어디에 맡겼고, 어떤 branch가 생겼고, 어떤 diff가 안전한가”가 된다. App은 바로 그 지점에 UI를 얹는다.

특히 Worktrees 문서는 App이 왜 별도 제품 표면이어야 하는지 보여 준다. Codex app의 worktree는 같은 Git repo 안에서 여러 독립 작업을 서로 방해하지 않게 돌리기 위한 장치다. Local은 foreground, Worktree는 background로 생각하면 된다. Codex는 thread를 Local과 Worktree 사이에서 handoff할 수 있고, 이때 필요한 Git 작업을 앱이 처리한다. 작업이 충분히 검증되면 worktree에서 branch를 만들고, push하고, GitHub PR을 열 수 있다.

CLI에서도 사람이 직접 git worktree add를 쓰면 비슷한 일을 할 수 있다. 하지만 자동화된 에이전트 작업에서는 “비슷하게 가능하다”와 “운영 가능한 기본값이다” 사이의 차이가 크다. worktree가 많아지면 disk 사용량, branch checkout 제한, snapshot, cleanup이 문제가 된다. Codex app은 기본적으로 최근 Codex-managed worktree를 관리하고, 삭제 전 snapshot을 남기는 방식까지 문서화한다. 이건 터미널 명령 하나가 아니라 운영 계층이다.

Cloud와 App을 섞으면 “내 컴퓨터의 에이전트”가 “작업 큐”가 된다

Codex web / cloud는 또 다른 축이다. Codex web 문서는 GitHub 계정을 연결해 Codex가 저장소 코드로 작업하고, 결과로 pull request를 만들 수 있게 한다고 설명한다. 클라우드 작업은 백그라운드와 병렬 실행을 전제로 한다. 로컬 개발 환경이 아니라 GitHub 저장소와 cloud environment가 작업의 기준점이 된다.

Codex app은 이 cloud 축을 데스크톱 흐름에 섞는다. App의 새 thread에는 Local, Worktree, Cloud 모드가 있고, CLI features 문서에도 codex cloud 명령으로 터미널을 떠나지 않고 cloud task를 triage하거나 launch할 수 있다고 나온다. 즉 OpenAI가 만들고 있는 구조는 “CLI vs App”이라는 단순 대체재 경쟁이 아니다. CLI, App, Cloud가 서로 다른 latency와 trust boundary를 가진 실행 면으로 분화되는 중이다.

실무적으로는 이렇게 나누는 편이 맞다.

작업 유형더 맞는 표면이유
실패한 테스트 하나를 즉시 고치기Codex CLI현재 shell, local state, 빠른 확인 루프가 중요하다
긴 refactor를 별도 공간에서 돌리기Codex App Worktreeforeground 작업과 분리하고 diff/branch로 수렴시키기 쉽다
반복적인 점검·리포트·triageCodex App Automationschedule, inbox, thread context, background run이 필요하다
GitHub repo 기반 feature/bugfix 위임Codex Web / Cloud 또는 App Cloud mode로컬 컴퓨터 상태보다 repo와 PR 흐름이 중요하다
PR 전 리스크 리뷰Codex CLI 또는 App review 흐름base branch 기준 diff와 사람이 보는 최종 판단이 중요하다
여러 agent 작업을 동시에 굴리기Codex Appthread, worktree, notification, Git action이 운영 표면을 만든다

이 구분을 놓치면 Codex를 과소평가하거나 과대평가하기 쉽다. CLI만 써 보면 “좋은 터미널 에이전트네”에서 멈출 수 있다. App만 보면 “또 하나의 AI IDE인가?”라고 볼 수 있다. 하지만 둘을 같이 보면 OpenAI가 진짜로 노리는 것은 IDE 대체가 아니라 소프트웨어 작업을 작은 에이전트 단위로 쪼개고, 로컬·워크트리·클라우드에 배치하고, Git으로 수렴시키는 운영 모델이다.

Sandbox와 approval은 두 제품을 가르는 보안 언어다

Codex를 팀에서 쓰려면 “얼마나 똑똑한가”보다 “어디까지 해도 되는가”가 먼저다. OpenAI의 Sandbox 문서는 이 점을 정확히 분리한다. sandbox는 Codex가 사용할 수 있는 파일·네트워크·명령 범위를 정하는 기술적 경계이고, approval policy는 그 경계를 넘을 때 언제 멈춰서 사람에게 묻는지를 정한다.

CLI와 App 모두 이 구조 위에 있다. 다만 사용감은 다르다. CLI에서는 approval prompt가 터미널 루프 안에 들어온다. 사람이 바로 보고, 허용하거나 거부하고, 다음 명령으로 넘어간다. App에서는 thread, worktree, automation, notification과 결합한다. 특히 자동화는 unattended run이므로 sandbox 기본값이 훨씬 중요해진다. Automations 문서는 background automation이 기본 sandbox settings를 사용하고, read-only / workspace-write / full access에 따라 파일 수정, 네트워크, 앱 접근이 달라진다고 설명한다.

여기서 실무적인 해석은 보수적이어야 한다. CLI는 사람이 보고 있는 동안 움직이는 경우가 많아 일시적으로 권한을 넓혀도 리스크가 상대적으로 통제된다. App automation이나 cloud task는 오래 돌고, 나중에 결과를 보게 되며, 여러 작업이 동시에 움직일 수 있다. 이 경우 기본은 workspace-write에 가깝게 두고, 위험한 network나 외부 앱 접근은 rule과 approval로 좁히는 편이 낫다. “에이전트가 빨리 해 준다”보다 “나중에 왜 바뀌었는지 추적 가능하다”가 팀에서는 더 중요하다.

App 자동화는 cron이 아니라 context를 가진 작업자다

Codex app에서 가장 흥미로운 부분은 Automations다. 문서상 automation은 반복 작업을 background에서 자동화하고, 결과가 있으면 inbox에 findings를 남기며, 보고할 것이 없으면 자동 archive할 수 있다. project-scoped automation은 앱이 실행 중이고 프로젝트가 disk에 있어야 하며, Git repo에서는 local project 또는 dedicated background worktree 중 하나를 선택할 수 있다.

이건 단순한 cron wrapper가 아니다. Codex automation은 skills, plugins, sandbox, worktree, thread context와 결합한다. 예를 들어 매일 아침 “최근 telemetry error를 보고 원인 후보를 정리하라”는 automation과, “새 review feedback이 달리면 PR을 다시 확인하고 작은 수정까지 제안하라”는 automation은 같은 0 9 * * *라도 완전히 다른 운영 의미를 가진다. 하나는 독립 실행이면 충분하지만, 다른 하나는 특정 thread context를 유지해야 할 수 있다.

App 문서는 thread automation과 standalone/project automation을 구분한다. thread automation은 같은 대화로 돌아오는 heartbeat에 가깝고, standalone automation은 매번 새 run으로 시작한다. 이 구분은 꽤 중요하다. 반복 작업이 “이전 대화의 상태”를 필요로 하면 thread automation이 맞고, 매번 같은 체크리스트를 새로 실행하면 standalone이 맞다. CLI의 codex exec가 스크립팅에 적합하다면, App automation은 “반복되는 판단 작업”을 제품 표면 안에 넣는 쪽이다.

무엇을 써야 하나: 선택 기준은 UI 취향이 아니라 작업의 수명이다

Codex 선택 기준

개인 개발자라면 시작점은 여전히 CLI가 맞다. 이유는 간단하다. 설치가 빠르고, 현재 repo에 바로 들어오며, 실패하면 끄면 된다. 새 도구를 배울 때 가장 큰 비용은 “작업 환경을 다시 모델링하는 비용”인데 CLI는 이 비용이 낮다. 이미 터미널에서 하는 일을 Codex가 같이 하게 만드는 정도로 시작할 수 있다.

반대로 여러 작업을 동시에 맡기기 시작하면 App이 필요해진다. 예를 들어 한 repo에서 “로그인 플로우 리팩터”, “billing test 보강”, “문서 업데이트”, “성능 회귀 조사”를 동시에 돌린다고 하자. 이걸 모두 CLI 세션과 수동 worktree로 관리할 수는 있다. 하지만 곧 문제가 생긴다. 어떤 작업이 어느 checkout에 있는지, 어느 branch를 만들었는지, 어떤 diff가 안전한지, 어떤 작업은 멈췄고 어떤 작업은 사람 승인이 필요한지 추적해야 한다. App은 이 추적 비용을 줄인다.

팀이라면 Cloud와 enterprise control까지 봐야 한다. Help Center의 Codex with ChatGPT plan 문서는 Codex가 Plus, Pro, Business, Enterprise/Edu 플랜에 포함되고, web 또는 cloud delegated usage는 Compliance API에 잡히지만 local environments usage는 잡히지 않는다고 설명한다. 이 문장은 팀 운영에서 중요하다. 로컬 CLI 사용은 빠르지만 중앙 감사·분석 관점에서는 cloud delegated task와 다르게 보일 수 있다.

실제 추천 조합

내가 팀에 도입한다면 이렇게 시작할 것이다.

  1. 개인 루프는 CLI로 표준화한다.
    각 개발자가 자기 repo에서 Codex CLI를 쓰게 한다. 기본 sandbox는 보수적으로 두고, 테스트 실행·코드 리뷰·작은 수정부터 습관화한다. AGENTS.md, rules, MCP, project-specific commands를 정리해 “이 repo에서 Codex가 어떻게 일해야 하는지”를 먼저 만든다.

  2. 두 개 이상의 병렬 작업이 생기는 순간 App worktree를 쓴다.
    CLI 세션을 여러 개 띄우고 사람이 worktree를 직접 관리하는 단계가 오면 App의 가치가 생긴다. App의 Local / Worktree 전환과 Git diff pane을 통해 작업을 branch와 PR로 정리한다.

  3. 반복 점검은 App automation으로 올린다.
    매일 실패한 CI를 보고 원인을 요약하거나, 특정 dependency update를 점검하거나, review feedback을 다시 확인하는 작업은 CLI보다 automation이 낫다. 단, automation prompt는 테스트한 뒤 등록하고, sandbox는 최소 권한으로 둔다.

  4. 조직 단위 위임은 Cloud / Web을 분리해서 운영한다.
    GitHub 연결, PR 생성, cloud environment, Compliance API, RBAC가 필요한 작업은 로컬 CLI와 별도의 운영 규칙을 가져야 한다. “개인 생산성 도구”와 “조직 작업자”를 같은 보안 기준으로 보면 둘 다 망가진다.

실전 해석: Codex App은 IDE 경쟁자가 아니라 agent scheduler다

Codex App을 Cursor나 VS Code extension의 경쟁자로만 보면 핵심을 놓친다. App은 코드 편집기가 되려는 것이 아니라, 에이전트 작업의 lifecycle을 관리하려는 쪽에 가깝다. thread를 만들고, Local/Worktree/Cloud에 배치하고, terminal과 browser와 computer use를 붙이고, Git diff와 PR로 수렴시키며, automation으로 반복 실행한다. IDE는 여전히 사람이 코드를 깊게 읽고 고치는 공간이고, App은 그 주변의 agent work queue를 관리하는 공간이 된다.

Codex CLI도 마찬가지다. 단순한 chat-in-terminal이 아니다. Rust 기반 오픈소스 로컬 에이전트 harness이고, 로컬 파일·명령·approval·sandbox·MCP를 묶은 실행 환경이다. 개발자가 이미 터미널 중심으로 일한다면 CLI는 가장 자연스러운 진입점이다. 다만 CLI만으로 모든 에이전트 운영을 해결하려 하면 곧 사람이 scheduler가 된다. 여러 작업의 상태를 머릿속과 shell history로 관리하게 되는 순간 App의 필요성이 생긴다.

결론

Codex CLI와 Codex App 중 하나만 고르는 질문은 조금 틀렸다. 더 정확한 질문은 “이 작업은 얼마나 오래 살고, 몇 개나 병렬로 움직이며, 어떤 권한 경계 안에서 끝나야 하는가”다.

  • 짧고 깊은 로컬 수정은 CLI.
  • 여러 작업을 분리해 돌리는 병렬 개발은 App Worktree.
  • 반복 점검과 background follow-up은 App Automation.
  • GitHub repo 기반 위임과 PR 생산은 Codex Web / Cloud.

OpenAI가 Codex로 밀고 있는 방향은 코딩 챗봇이 아니다. 로컬 터미널, 데스크톱 앱, 클라우드 작업 큐를 하나의 Codex 계정과 권한 모델로 묶는 agent operating surface다. 개발자에게 중요한 것은 새 UI에 익숙해지는 것이 아니라, 작업을 이 표면들에 올바르게 배치하는 감각이다. CLI는 손에 붙는 도구이고, App은 일이 쌓였을 때 필요한 운영 도구다. 둘을 같은 잣대로 비교하기보다, 작업의 수명과 위험도에 맞게 나눠 쓰는 쪽이 훨씬 생산적이다.

참고한 출처

Discuss on Twitter • View on GitHub