OpenCode vs Codex CLI: 터미널 AI 코딩 에이전트 비교 (2026)

OpenCode (별 190k 개, MIT, 모든 모델 지원) vs Codex CLI (Rust, Apache-2.0, GPT-5-Codex). 하나는 모델 불가지론적 (model-agnostic)이며, 다른 하나는 OpenAI 네이티브 (OpenAI-native)입니다. 당신의 스택에 따라 선택하세요.

요약 (TL;DR): 어떤 것을 선택해야 할까요?

이미 제약 사항을 알고 있다면 긴 글은 건너뛰셔도 좋습니다. 시나리오별 결정 가이드는 다음과 같습니다.

5분 비교

2026-07-29 기준으로 각 프로젝트의 저장소(repository)와 문서를 검증하여, 일상적인 사용감을 결정짓는 사양들을 정리했습니다.

OpenCode: 모델 불가지론적 (Model-Agnostic) 하네스

OpenCode는 모델을 제품 결정 사항이 아닌 런타임 인자 (runtime argument)로 취급합니다. 기본 제공되는 프로바이더(provider) 없이 배포됩니다. 처음 실행할 때 하나를 연결하며, 그 이후부터는 models.dev를 통해 연결된 75개 이상의 프로바이더 목록에서 세션별 또는 메시지별로 모델을 선택할 수 있습니다. Claude, GPT, Gemini, GLM, 로컬 Ollama 빌드 등 모두 /models 내의 항목일 뿐입니다.

이러한 설계는 몇 가지 실질적인 결과를 가져옵니다.

당신은 그 누구의 로드맵에도 얽매이지 않습니다. 새로운 모델이 출시되어 models.dev 레지스트리에 나타나면, 클라이언트 업데이트 없이도 OpenCode에 바로 나타납니다. 이 하네스(harness)는 모델을 누가 만들었는지 상관하지 않으며, 그것이 바로 핵심입니다.

이것은 단순한 얇은 래퍼 (thin wrapper)가 아닌 완전한 에이전트 (agent)입니다. OpenCode는 플랜 에이전트 (plan agent)와 빌드 에이전트 (build agent)를 실행하며, 키 하나로 전환할 수 있습니다. 플랜 모드 (Plan mode)는 읽기 전용이며 파일을 건드리지 않고 접근 방식을 제안합니다. 빌드 모드 (build mode)는 이를 실행합니다. 이 도구는 언어 서버 프로토콜 (Language Server Protocol, LSP) 서버를 통합하므로, TypeScript, Python, Rust, Go 및 기타 수많은 언어에 대해 모델이 원시 텍스트 (raw text)에서 추측하는 대신 실제 타입 정보 (type information)와 컴파일러 진단 (compiler diagnostics)을 볼 수 있습니다. 또한 MCP를 지원하고, 커스텀 도구 (custom tools)를 지원하며, 동일한 프로젝트에서 여러 세션을 병렬로 실행할 수 있습니다.

단순히 터미널 도구인 것만은 아닙니다. TUI (Text User Interface)와 더불어 데스크톱 앱과 IDE 확장 프로그램이 제공됩니다. 에이전트 루프 (agent loop)는 원하지만 터미널은 원하지 않는 경우, OpenCode는 당신을 위한 인터페이스를 갖추고 있습니다. 반면 Codex는 터미널과 실행 파이프라인 (exec pipeline)에 더 집중합니다.

단점: 모델 불가지론 (model-agnostic) 방식은 실패 모드 (failure modes)를 포함하여 모델 결정권을 사용자가 갖게 된다는 것을 의미합니다. OpenCode를 성능이 낮거나 잘못 설정된 제공자 (provider)로 지정하면 성능이 낮거나 잘못 설정된 출력을 얻게 되며, 하네스 (harness)가 잘못된 라우팅 선택으로부터 당신을 구해 주지는 못합니다. 또한 제공자 레지스트리 (provider registry)에 알려진 거친 부분이 있습니다. 완전히 새로 설치한 경우, 레지스트리 캐시 (registry cache)가 아직 작성되지 않았기 때문에 새로 추가된 제공자가 첫 번째 호출 시점에 나타나지 않을 수 있습니다. run the models 명령을 한 번 실행하여 캐시를 예열(warm)하면 해결됩니다. 설정을 스크립트화하고 첫 번째 호출이 권위적이라고 가정하기 전에 이 점을 알아둘 가치가 있습니다.

OpenCode는 모델을 제품 결정 사항이 아닌 런타임 인자 (runtime argument)로 취급합니다. 그 단 하나의 선택이 OpenCode가 멀티 모델 (multi-model) 사례에서는 승리하고, "설치 즉시 바로 작동함 (just works out of the box)" 사례에서는 패배하는 이유입니다.

Codex CLI: OpenAI의 퍼스트 파티 에이전트 (First-Party Agent)

Codex CLI는 OpenAI에서 제작되었으며, 이는 모든 설계 결정에서 드러납니다. Rust로 작성되었기 때문에 Node 프로세스가 아닌 빠른 단일 바이너리 (single binary) 형태입니다. OpenAI 자체 엔드포인트 (endpoint)와 Codex에 최적화된 GPT-5 모델을 대상으로 제공되므로, 기본 사용자에게는 설정이 전혀 필요 없음을 의미합니다. 설치하고, ChatGPT 계정이나 API 키로 인증한 다음, 바로 코딩을 시작하면 됩니다.

강점은 신뢰성과 안전성(trust and safety)을 중심으로 모여 있습니다.

이 비교군 중에서 샌드박스(sandbox) 기능이 가장 뛰어납니다. Codex는 macOS의 seatbelt, Linux의 Landlock 및 seccomp와 같은 OS 레벨의 프리미티브(primitives)를 사용하여 명령 실행을 격리하며, 그 위에 승인 모드(approval modes)를 추가합니다. 사용자는 에이전트에게 어느 정도의 권한을 줄지 선택할 수 있습니다: 제안만 하기(suggest only), 워크스페이스 내 자동 편집(auto-edit within the workspace), 또는 샌드박스 내부에서의 완전 자동화(full auto inside the sandbox) 중 하나를 선택합니다. 에이전트가 실행하는 rm 명령은 모델이 행동을 잘 선택해서가 아니라, 구조적으로(by construction) 제한됩니다. 만약 사용자가 작업을 자동 승인하거나 직접 작성하지 않은 코드를 실행한다면, 그 격리 기능이야말로 당신이 실제로 구매하고 있는 핵심 가치입니다.

OpenAI 스택의 퍼스트 파티(first-party) 구성 요소입니다. /review 명령은 작업 트리(working tree)를 건드리지 않고 인라인 코드 리뷰(inline code review)를 수행합니다. 서브 에이전트(Subagents)는 작업을 병렬화합니다. Codex Remote를 사용하면 ChatGPT 모바일 앱에서 연결된 Mac 또는 Windows 호스트를 제어할 수 있습니다. /import 명령은 Cursor 및 Claude Code의 설정, MCP 서버, 플러그인 및 명령을 Codex로 가져오므로, 마이그레이션(migration)을 주말 내내 걸리는 작업이 아닌 명령어 한 줄로 끝나는 작업으로 만들어 줍니다.

기본 설정에도 불구하고 OpenAI에 종속되어 있지는 않습니다. ~/.codex/config.toml에 호환 가능한 게이트웨이(gateway)를 가리키는 [model_providers.<id>] 블록을 추가하면, Codex는 해당 게이트웨이가 제공하는 무엇이든 호출합니다. 문은 열려 있습니다. 단지 당신이 직접 손으로 열어야 할 뿐인데, 이것이 문이 기본적으로 열려 있는 OpenCode와의 정직한 차이점입니다.

문제는 어떤 프로토콜이 호환되는 것으로 간주되느냐 하는 것이며, 그 답이 바뀌었습니다. Codex는 과거에 wire_api = "chat"을 허용했으며, 이는 모든 Chat Completions 엔드포인트를 의미했습니다. 이제 그 값은 사라졌습니다. 0.146.0 소스 코드에서 WireApi 열거형(enum)에는 Responses라는 단 하나의 변체(variant)만 남아 있으며, chat을 전달하는 것은 무시되는 것이 아니라 엄격한 시작 오류(hard startup error)를 발생시킵니다:

wire_api = "chat"은 더 이상 지원되지 않습니다. 해결 방법: 프로바이더 설정(provider config)에서 wire_api = "responses"로 설정하십시오.

해당 메시지는 "Codex에서 chat/completions 지원 중단(Deprecating chat/completions support in Codex)"이라는 제목으로 등록된 discussion #7782로 연결되며, 이는 지원 중단(deprecation)에 있어 더할 나위 없이 명확한 내용입니다. Chat Completions는 거의 보편적인 방언(dialect)과 같습니다. 하지만 Responses API는 그렇지 않습니다. 해당 변경 사항 이전에 작성된 모든 튜토리얼은 이제 로드되지 않는 설정을 생성하며, Chat Completions만을 프록시(proxy)하는 모든 게이트웨이는 이제 접근할 수 없게 되었습니다.

문제점: OpenAI 우선(OpenAI-first)의 기본 설정은 떠나고 싶어지기 전까지는 안락함을 줍니다. Codex에서의 모델 자유도는 메뉴 선택이 아닌 설정(config) 작업이며, 프로토콜 경계는 실재하며 OpenAI 측에 유리하게 이동했습니다. base_url을 Anthropic의 네이티브 API로 지정하고 작동하기를 기대할 수는 없습니다. 왜냐하면 그것은 Responses API가 아니기 때문입니다. OpenAI가 아닌 모델을 사용하려면 Responses 기능을 갖춘 게이트웨이를 통해 라우팅하거나, 아예 라우팅하지 말아야 합니다. 그리고 다음 섹션에서 보여주듯, "Responses 기능 지원"은 게이트웨이 단위가 아닌 모델 단위의 속성임이 드러납니다.

정면 승부: 일상을 바꾸는 차이점

여섯 가지 차원과 각 차원의 승자를 살펴봅니다. 여기서 "승자(Winner)"는 보편적인 판결이 아니라 "해당 축을 최적화하려는 대부분의 사람들에게 더 나은 것"을 의미합니다.

설정 및 일상 워크플로우 측정

임의로 만들어진 품질 점수는 잊으십시오. 정직하고 확인 가능한 차이점은 각 도구가 동일한 작업을 수행하는 데 필요한 단계의 수와 마찰(friction)이 어디에서 발생하는지에 있습니다.

기본값이 아닌 모델로 첫 응답을 얻기. OpenCode에서는 제공업체의 키를 내보내고(export), TUI를 연 다음, /models를 실행하여 선택하기만 하면 됩니다. 편집해야 할 파일이 없습니다. 반면 Codex에서 OpenAI가 아닌 모델을 사용하려면, 먼저 config.toml에 model_providers 블록을 작성한 다음, 원하는 모델이 Responses API를 통해 실제로 제공되는지 확인하고 나서 선택해야 합니다. OpenCode는 설계 단계부터 멀티 모델(multi-model) 케이스를 위해 단계 수를 줄였으며, Codex는 원하는 모델이 OpenAI 모델일 경우 단계가 0단계가 되므로 그 경우에 단계가 더 적습니다.

작업 도중 모델 전환하기. OpenCode는 실행 중인 세션 내에서 /models를 통해 실시간으로 교체합니다. Codex는 호출(invocation)마다 --model을 사용하거나 이름이 지정된 프로필을 로드하여 모델을 변경하는데, 이는 핸들을 살짝 조절하는 것보다는 차선을 변경하는 것에 더 가깝습니다. 만약 당신의 워크플로우가 "비싼 모델로 추론한 뒤, 저렴한 모델로 편집 작업을 수행하게 하는 것"이라면, OpenCode는 이를 2초 만에 전환할 수 있게 해줍니다.

셸 명령(shell command) 실행하기. OpenCode는 권한을 요청합니다. Codex는 당신이 설정한 승인 모드에 따라 샌드박스(sandbox) 내부에서 명령을 실행하므로, 당신이 승인하더라도 격리(isolation) 상태가 유지됩니다. 겉보기에는 동일한 프롬프트처럼 보이지만, 내부적인 폭발 반경(blast radius)은 매우 다릅니다.

프로젝트 지침(Project instructions). 두 도구 모두 Cursor 등이 채택한 것과 동일한 관례인 AGENTS.md를 읽습니다. 따라서 이미 해당 파일이 있는 저장소(repo)는 변경 없이 두 에이전트 모두에서 작동합니다. 이것이 지난 1년 동안 얻은 조용한 승리입니다. 이제 프로젝트의 에이전트 지침은 도구 간에 이식(portable)이 가능해졌습니다.

첫 실행, 나란히 비교하기

차이점을 느끼는 가장 빠른 방법은 두 가지를 모두 설치하고 첫 응답을 얻어보는 것입니다. 사용자가 직접 모델을 제공하는 OpenCode의 경우:

npm i -g opencode-ai
export OFOX_API_KEY=sk-your-key      # 모든 OpenAI 호환 제공업체 사용 가능
cd your-project
...

Codex가 최적화되어 있는 방식인 OpenAI 기본 설정을 사용하는 경우:

npm i -g @openai/codex
cd your-project
codex                                 # ChatGPT 또는 OPENAI_API_KEY로 인증

각 명령어가 무엇을 가정하고 있는지 주목하십시오. OpenCode의 해피 패스(happy path)는 사용자가 프로바이더(provider)를 지정할 것을 기대하며, 그 보상으로 메뉴를 제공합니다. Codex의 해피 패스는 사용자가 OpenAI 사용자임을 가정하며, 그 보상으로 설정 과정이 전혀 없는 경험을 제공합니다. 둘 중 어느 것도 틀리지 않았습니다. 이들은 서로 다른 첫 사용자들을 위해 최적화되어 있으며, 설치 경험을 통해 각 팀이 어떤 사용자를 상정했는지 알 수 있습니다.

확장성: MCP, 스킬(Skills), 그리고 서브에이전트(Subagents)

모델에 대한 질문을 넘어, 두 에이전트 모두 유사한 형태의 확장성을 갖추고 있지만 각 영역에서의 성숙도는 다릅니다. 이 지점에서 "퍼스트 파티(first-party)" 지원이 철학이라기보다는 완성도(polish)로서 나타나기 시작합니다.

둘 다 MCP를 지원하므로, 동일한 컨텍스트 서버와 도구 통합(tool integrations)을 어느 쪽에도 연결할 수 있습니다. Codex는 구조화된 확장 모델, 스킬(skills), 네임스페이스화된 MCP, 그리고 제품을 출시하는 팀이 관리하는 듯한 느낌을 주는 슬래시 명령어(/commands)에 집중합니다. OpenCode는 인터페이스(surfaces)에 집중하여, 터미널, 데스크톱 창, 에디터에서 동일한 에이전트를 사용할 수 있게 하며, 세션을 팀원에게 전달하기 위한 /share 흐름을 제공합니다. 읽기 전용(read-only) 기능은 이들의 철학을 잘 보여주는 거울입니다. OpenCode는 사용자가 전환하여 사용할 수 있는 전용 플랜 에이전트(plan agent)를 제공하는 반면, Codex는 사용자의 트리(tree)를 건드리지 않고 비평만 수행하는 /review 명령어를 제공합니다. 목표는 같지만, 두 가지 관용구(idioms)를 사용하는 셈입니다.

속도에 관한 실질적인 참고 사항입니다. Codex는 Rust 바이너리이므로 시작이 빠르고 가볍게 유지됩니다. OpenCode는 Node 위에서 실행되는데, 모델이 생각하는 동안 사용자가 느낄 수 있을 정도로 느리지는 않지만, 대기 상태(at rest)에서는 더 무거운 프로세스입니다. 대부분의 사람들에게는 모델의 지연 시간(latency)이 도구의 지연 시간보다 압도적으로 크기 때문에 이 차이는 중요하지 않습니다. 하지만 헤드리스(headless) 에이전트 군단을 스크립트로 제어한다면 이 차이가 중요해질 수 있습니다.

하나의 키, 매우 다른 두 가지 모델 메뉴

이 지점부터 두 철학은 추상적인 논의를 넘어, 우리가 직접 추측을 멈추고 실제로 실행해 본 결과로 이어집니다. 두 에이전트 모두 게이트웨이 기본 URL (gateway base URL)을 수용하므로, 하나의 키로 Claude, GPT, Gemini, 그리고 오픈 웨이트 (open-weight) 모델들의 비용 결제를 처리할 수 있습니다. 하지만 하나의 키가 두 에이전트 모두가 모든 모델에 접근할 수 있음을 보장하지는 않습니다. 우리는 2026-07-29에 ofox.ai를 대상으로 두 에이전트를 모두 설정했으며, 그 결과는 대칭적이지 않았습니다.

OpenCode: 하나의 환경 변수, 설정 파일 제로. ofox가 models.dev 레지스트리의 내장 프로바이더 (built-in provider)이기 때문에, OpenCode는 키가 존재하는 즉시 이를 발견합니다.

export OFOX_API_KEY=sk-your-key
opencode            # /models 명령 시 ofox/... 항목이 나열되며, 하나를 선택합니다

이것이 설정의 전부입니다. 파일도, 프로바이더 블록 (provider block)도 필요 없습니다. 또한 OpenCode는 채팅 완성 (Chat Completions) API를 사용하기 때문에, 게이트웨이가 제공하는 모든 것이 메뉴에 포함됩니다.

Codex CLI: 하나의 설정 블록, 그리고 예상보다 짧은 메뉴. Codex는 ~/.codex/config.toml에 게이트웨이를 한 번 선언해야 합니다.

toml
model = "openai/gpt-5.5"
model_provider = "ofox"

...

wire_api = "responses"는 선택 사항이 아니라 현재 출시된 Codex 버전이 수용하는 유일한 값입니다. 따라서 귀하의 게이트웨이는 단순히 채팅 완성 (Chat Completions)뿐만 아니라 Responses 호환 엔드포인트 (endpoint)를 노출해야 합니다. requires_openai_auth = false는 기본값이며, Codex가 ChatGPT 로그인 흐름을 표시하지 않도록 하여 env_key에서 키를 읽도록 합니다. 전체 키 목록은 Codex 설정 참조에서 확인할 수 있습니다.

실제로 실행된 내용