만약 당신의 일상적인 워크플로우가 저와 비슷하다면, 실제 작업은 터미널에서 이루어질 것입니다.

지난 4월 Claude Code 참사 이후, 저는 Claude 생태계에서 벗어날 방법을 찾고 싶었습니다. Codex와 OpenCode는 고민할 필요도 없는 기본 선택지였습니다.

그래서 저는 지난 몇 달 동안 Codex와 OpenCode를 스트레스 테스트하며, 어떤 것이 실제로 저의 데일리 드라이버(daily driver)로서 Claude Code를 대체할 수 있을지 확인했습니다.

그 결과, 다음과 같은 사실을 알아냈습니다.

TL;DR: 빠른 참조

시간이 촉박하다면, 이 비교를 생각하는 가장 간단한 방법은 다음과 같습니다.

Codex는 더 나은 기본값(default)입니다. OpenCode는 더 나은 파워 유저(power-user)용 도구입니다. 속도, 세련됨, 그리고 적은 설정 결정이 필요할 때는 Codex가 승리합니다. 모델의 자유도, 낮은 비용, 로컬 실행(local execution), 그리고 에이전트 루프(agent loop)에 대한 더 많은 제어가 필요할 때는 OpenCode가 승리합니다.

섹션	승자	이유
온보딩(Onboarding), 설정(Setup), 그리고 일상적 UX	Codex	시작이 더 빠르고, 기본 설정이 깔끔하며, 일상적인 워크플로우가 더 쉬움
...
나의 의견: 저는 대부분의 사용자에게 먼저 Codex를 추천하겠습니다. 하지만 저처럼 높은 제어력이 필요한 워크플로우의 경우, 추가적인 설정이 유연성으로 변하기 때문에 시간이 지날수록 OpenCode가 더 매력적으로 다가옵니다.

1. 온보딩(Onboarding), 설정(Setup), 그리고 일상적 UX

온보딩과 일상적 UX는 서로 너무 밀접하게 연관되어 있어 별개의 섹션으로 다루기 어렵습니다.

처음 10분은 제가 얼마나 빨리 시작할 수 있는지를 결정합니다. 그다음 10일은 제가 실제로 이 도구를 계속 사용하고 싶은지를 결정합니다. Codex는 선택지를 제거함으로써 첫 번째 부분에서 승리합니다. OpenCode는 선택지가 제어권으로 변하기 시작하면서 나중에 더 흥미로워집니다.

측면	Codex	OpenCode
설치 속도	약 90초, 단일 경로	약 3~5분, 더 많은 결정 필요
...

Codex

저는 약 90초 만에 Codex를 설치했습니다:

npm i -g @openai/codex
codex

그 후 과정은 기본적으로 다음과 같았습니다:

• ChatGPT로 로그인,
• 프로젝트 선택,
• 코딩 시작.

그것이 바로 핵심적인 매력입니다. 모델이 이미 선택되어 있고, GitHub 통합이 네이티브하게 느껴지며, 기본 워크플로 (workflow)가 저에게 너무 많은 결정을 요구하지 않습니다. 저는 Codex를 열고, 작업을 설명하고, 차이점 (diff)을 검토한 뒤, 다음 단계로 넘어가기만 하면 됩니다.

이것이 중요한 이유는 매일 사용하는 코딩 에이전트 (coding agent)라면 코드가 아닌 에이전트 자체에 대해 더 많이 고민하게 만들어서는 안 되기 때문입니다.

Codex는 다음과 같은 상황에서 가장 강력한 성능을 발휘합니다:

• 스탠드업 (standup) 미팅 전 빠른 프로토타입 (prototype) 제작,
• PR (Pull Request) 리뷰,
• 좁은 범위의 작업을 위한 깔끔한 차이점 (diff) 생성,
• 백그라운드 리팩터링 (refactor),
• 프롬프트 (prompt)에서 패치 (patch)까지의 마찰 없는 경로.

트레이드오프 (tradeoff)는 Codex가 주관적 (opinionated)이라는 점입니다. 저는 모델 전략 (model strategy), 로컬 런타임 (local runtime), 또는 워크플로의 형태에 대해 많은 제어권을 갖지 못합니다. 대부분의 작업에는 괜찮지만, 에이전트를 제 개발 환경의 일부처럼 미세 조정 (tune)하고 싶을 때는 제한적입니다.

OpenCode

저는 다음과 같이 OpenCode를 설치했습니다:

curl -fsSL https://opencode.ai/install | bash
opencode

그 후 결정해야 할 사항들이 시작되었습니다:

• 어떤 제공자 (provider)를 원하는가?
• Go 티어 (tier)를 원하는가?
• 어떤 모델을 기본값으로 설정할 것인가?
• 어떤 API 키가 필요한가?
• 어떤 작업 디렉토리 (working directory)를 사용할 것인가?
• 처음에 얼마나 많이 설정할 것인가?

이로 인해 OpenCode는 첫날 사용 시 더 느리게 느껴집니다. 설정 결정을 싫어하는 사람에게는 추천할 만한 도구가 아닙니다.

하지만 시스템을 이해하고 나면 동일한 마찰 (friction)이 유용하게 변합니다. OpenCode는 Codex가 숨기는 부분들에 대해 제어권을 부여합니다:

• 작업 유형에 따라 제공자와 모델을 전환할 수 있음,
• Ollama 또는 LM Studio를 통해 로컬 모델을 사용함,
• 실행 전 계획 (plan)을 검토함,
• 단계별로 에이전트를 유도 (steer)함,
• 지침 파일 (instruction files)에 프로젝트 선호도를 인코딩함,
• 루프 (loop)를 제 리포지토리 (repo) 및 도구들과 가깝게 유지함.

이러한 점들 덕분에 OpenCode는 잘 다듬어진 단일 목적의 코딩 에이전트라기보다, 설정 가능한 개발 환경 (development environment)에 더 가깝게 느껴집니다.

단점은 인지적 부하 (cognitive overhead)입니다. OpenCode는 저에게 더 많은 참여를 요구하며, 이는 일상적인 업무에서 항상 제가 원하는 방식은 아닙니다. 하지만 진지한 리팩토링 (refactor), 디버깅 (debugging) 세션, 또는 에이전트가 행동하기 전에 생각하는 과정을 지켜보고 싶은 프로덕션 변경 (production changes)의 경우에는, 이러한 추가적인 제어권이 마찰 (friction)을 감수할 만큼 가치가 있습니다.

결론 (Verdict)

온보딩 (onboarding)은 Codex가 승리했습니다. 장기적인 제어권은 OpenCode가 승리했습니다.

마찰을 최소화하고 싶은 팀원에게 도구를 추천한다면, 저는 Codex를 추천할 것입니다. 시작하기 더 빠르고, 이해하기 쉬우며, 에이전트가 방해하지 않고 가만히 있기를 원하는 사용자에게 더 적합합니다.

만약 저 자신의 높은 제어력이 필요한 워크플로우 (workflow)를 위해 도구를 선택한다면, 시간이 지날수록 OpenCode가 더 매력적으로 다가옵니다. 설정은 더 무겁지만, 모델 유연성 (model flexibility), 로컬 실행 (local execution), 그리고 더 정밀한 조종 (tighter steering)이라는 보상이 따릅니다.

이 섹션에서는 첫 사용 경험과 기본 일상 경험이 더 깔끔한 Codex가 승리합니다.

OpenCode - 0, Codex - 1

2. 모델 (Models): Codex vs OpenCode

측면 (Aspect)	Codex	OpenCode
모델 가용성 (Model Availability)	GPT-5.5 전용	약 75개 제공업체, 1,000개 이상의 모델
...

Codex

GPT-5.5와 함께 Codex를 처음 실행했을 때, 시스템 전체가 이를 위해 특수 제작된 것 같은 느낌을 받았습니다.

OpenAI의 헤드라인은 "더 적은 토큰 (tokens)으로 더 나은 결과"입니다. 더 흥미로운 이야기는 그들이 어떻게 그 단계에 도달했는가 하는 점입니다. Codex는 프롬프트 (prompts), 컨텍스트 관리 (context management), 도구 호출 (tool-calling), 그리고 평가 루프 (evaluation loop)가 모두 GPT 모델에 최적화된 정밀하게 조정된 파이프라인 (pipeline)입니다. 이는 Claude와 유사합니다.

OpenAI는 에이전트 기반 코딩 (agentic coding)을 위해 GPT-5.5를 특별히 설계했으며, 이후 Codex를 조정하여 그 기능을 최대한 활용할 수 있도록 했습니다. GPT-5.5는 동일한 Codex 작업에서 GPT-5.4보다 출력 토큰을 40% 적게 사용합니다.

제가 Codex를 통해 실행하는 모든 작업은 이 동일한 조정된 파이프라인을 사용합니다. 이는 결정보다는 결과에 집중하며, 귀하의 워크플로우에 맞춰 특별히 훈련된 시니어 엔지니어를 두는 것과 같습니다.

OpenCode

OpenCode는 1,000개 이상의 모델에 걸쳐 약 75개의 서로 다른 제공업체와의 통합을 제공하며, 이로 인해 발생할 비용에 위축될 수도 있습니다. 저 또한 마찬가지였습니다.

하지만 벤치마크 (benchmark) 데이터를 살펴보니, 다음과 같은 사실을 발견했습니다:

• Qwen은 SWE-Bench Pro에서 60.6%로 최고치를 기록하며, GPT-5.5의 58.6%를 앞질렀습니다.
• MiMo-V2.5-Pro는 유사한 출력을 내는 데 GPT-5.4보다 40-60% 적은 토큰 (tokens)을 사용합니다.
• DeepSeek V4-Flash의 비용은 입력 100만 토큰당 $0.14 / 출력 100만 토큰당 $0.28인 반면, GPT-5.5는 입력 100만 토큰당 $30 / 출력 100만 토큰당 $180입니다.

숨겨진 통찰: 모든 작업에 동일한 모델을 사용할 필요는 없습니다.

• 아키텍처 (Architecture) 결정: Qwen.
• 보일러플레이트 (Boilerplate): DeepSeek.
• 버그 수정 (Bug fixing): MiMo.

자동화를 원한다면 OpenCode를 스마트 모델 라우터 (smart model routers)와 연결할 수도 있습니다. 라우터가 힘든 작업을 대신 처리해 줄 것입니다.

이것이 제가 앞서 언급했던 학습 곡선 (learning curve), 즉 모델 라우팅 (model routing)입니다.

판결 (Verdict)

제 의견을 묻는다면:

• GPT 5.5는 현재 오픈소스 (open-source)가 제공할 수 있는 그 어떤 것보다 부정할 수 없이 더 나은 모델입니다. 비록 Kimi 2.7과 GLM 5.2가 SOTA (State-of-the-Art)에 근접한 코딩 성능을 가진 훌륭한 모델들이긴 하지만 말입니다.
• OpenCode는 확실히 원하는 어떤 모델이든 선택할 수 있는 자유를 제공하며, 게다가 비용도 더 저렴합니다. 비용을 중시하는 사람들에게 이것은 분명한 USP (Unique Selling Proposition, 고유 강점)입니다.

GPT 5.5를 사용하는 Codex와 GLM 5.2를 사용하는 OpenCode는 실험실에서 만들어진 완벽한 조합입니다. 따라서 현 시점에서는 무승부입니다.

OpenCode - 1, Codex - 2

3. 가격 / 비용: Codex vs OpenCode

측면 (Aspect)	Codex	OpenCode
시작 가격 (Entry Price)	Plus 기준 월 $20	Go 티어 기준 월 $10
...	...	...

Codex

Codex는 월 $20의 ChatGPT Plus에 묶여 제공되는데, 헤비하게 사용하기 시작하기 전까지는 저렴하게 들립니다.

저의 실제 사용 패턴은 다음과 같습니다:

• 가벼운 작업: 하루 2-3 세션 (Plus로 충당 가능)
• 본격적인 리팩토링 (refactoring): 하루 4-7시간 (Plus 한도 초과)

Pro ($100/month)로 업그레이드했을 때 상황은 조금 더 원활해졌습니다. 한도에 걸린 적은 없었습니다. 하지만 저는 현재 실제로 사용하는 기능에 대해 연간 $1,200를 지불하고 있습니다.

이것은 단순한 숫자가 아닙니다. 하루 6시간 이상 코딩하는 전문가에게 발생하는 실제 비용이며, 이는 대략 월 $100-$200에 달합니다.

OpenCode

OpenCode Go는 월 $10 이하이지만, 이는 어떤 작업에 어떤 모델을 사용해야 할지 실제로 파악해야 한다는 전제 조건이 붙습니다.

저의 실제 사용 패턴은 다음과 같습니다:

• 1일 차: 모델 선택에 혼란을 겪음 (잘못된 모델 선택으로 토큰 낭비)
• 10일 차: 라우팅 (Routing) 방식을 파악함: 상용구 (Boilerplate) → 특정 모델, 아키텍처 (Architecture) → 다른 모델, 토큰 비용이 감소하기 시작함
• 30일 차: 스마트 라우팅 (Smart routing)이 최적화됨 (일상적인 작업은 DeepSeek, 복잡한 작업은 Qwen, 예외적인 케이스는 로컬 모델 사용), 비용이 월 $10 수준의 고정 비용으로 수렴함

2개월 차에 마침내 모델 라우팅 퍼즐을 풀었을 때, 저는 진정한 숨겨진 이점을 깨달았습니다:

캐시된 토큰 (Cached tokens)은 일반 가격의 아주 일부만 비용이 발생합니다. 따라서 세션당 $0.50였던 비용은 캐싱이 적용되어 실제로는 $0.15에 더 가까웠습니다.

추정치에 따르면, 스마트 라우팅을 사용하는 전문가의 실제 비용은 월 $10-$50 정도입니다.

이는 약 70%의 비용 절감이며, 이로 인해 전환은 선택이 아닌 필수가 됩니다.

결론 (Verdict)

명백하게, 이 항목에서는 OpenCode가 승리합니다.

OpenCode - 2 , Codex - 2

3. 기능 및 워크플로우 (Features and Workflows)

이 지점부터 Codex와 OpenCode는 근본적으로 다른 제품처럼 느껴지기 시작합니다.

Codex는 **위임 (Delegation)**을 중심으로 구축되었습니다. OpenCode는 **반복 (Iteration)**을 중심으로 구축되었습니다.

측면 (Aspect)	Codex	OpenCode
핵심 워크플로우 (Core workflow)	목표 정의 → 위임 → 결과 검토	계획 → 검토 → 실행 → 조정
...

Codex

Codex는 제가 위임할 수 있는 엔지니어링 팀 동료처럼 다룰 때 가장 강력한 성능을 발휘합니다.

이 앱은 더 오래 지속되는 실행을 위해 멀티 에이전트 워크플로우 (Multi-agent workflows)를 설정할 수 있게 해줍니다:

• 한 에이전트는 PR (Pull Request)을 검토하고,
• 다른 에이전트는 버그를 수정하며,
• 세 번째 에이전트는 문서를 업데이트합니다.

저는 노트북을 닫고 결과가 나올 때까지 기다렸다가 돌아옵니다. 이는 Codex를 대규모 리팩토링 (Refactor), GitHub 네이티브 워크플로우, 팀 위임, 그리고 백그라운드 엔지니어링 작업에 특히 유용하게 만듭니다.

여기서 과소평가된 기능은 Codex의 /goal 명령어입니다. 에이전트에게 "이 리포지토리를 개선해줘"와 같은 모호한 작업을 주는 대신, 제가 원하는 실제 결과물을 정의할 수 있습니다:

• 불안정한 테스트 (flaky tests) 줄이기,
• 모듈 마이그레이션 (migrate a module),
• 인증 로직 (auth logic) 정리,
• PR 준비가 된 리팩터링 (PR-ready refactor) 준비.

그 후 Codex는 해당 목표를 계획 (planning), 실행 (execution), 그리고 검토 (review)를 위한 앵커 (anchor)로 사용합니다. 이를 통해 장시간 소요되는 위임된 작업이 단순한 프롬프팅 (prompting)이 아니라, 범위가 지정된 엔지니어링 목표를 할당하는 것처럼 느껴지게 합니다.

OpenCode

OpenCode에는 /goal과 직접적으로 대응하는 기능은 없지만, 그 워크플로 (workflow)를 통해 동일한 문제를 다른 방식으로 해결합니다.

OpenCode는 저에게 목표를 할당하고 결과를 기다리라고 요청하는 대신, 저를 긴밀한 루프 (loop) 안에 머물게 합니다:

• 원하는 것을 정의하고,
• 제안된 계획을 검토하며,
• 접근 방식을 조정하고,
• 실행하고,
• 결과를 검토하며,
• 이를 반복합니다.

이 지점에서 계획 모드 (Plan mode)가 중요해집니다. 이는 중간 추론 과정을 숨기지 않으면서도 목표 지향적인 워크플로를 제공합니다. 저는 OpenCode가 코드베이스 (codebase)를 건드리기 전에 무엇을 의도하고 있는지 확인할 수 있는데, 이는 디버깅 (debugging)을 하거나, 익숙하지 않은 코드를 탐색하거나, 모든 단계에 대해 제어권을 갖고 싶은 리팩터링 (refactor)을 수행할 때 유용합니다.

또한 OpenCode는 AGENTS.md와 같은 리포지토리 수준의 지침 파일 (instruction files)과 잘 결합됩니다. 이로 인해 목표 설정이 Codex의 /goal만큼 세련되지는 않았지만, 더 맞춤화 (customizable)가 가능합니다. 프로젝트 컨벤션 (conventions), 테스트 기대치, 아키텍처 규칙 (architecture rules), 그리고 워크플로 선호도를 한 번 인코딩해 두면, 이후 세션 전반에서 재사용할 수 있습니다.

또 다른 주요 장점은 로컬 실행 (local execution)입니다. OpenCode를 Ollama 또는 LM Studio와 결합하여 API 호출 없이 제 자신의 기기에서 에이전트 루프 (agentic loop)를 실행할 수 있습니다. 보안에 민감한 작업, 규제가 있는 코드베이스, 또는 로컬 우선 개발 (local-first development)의 경우 이는 실질적인 이점이 됩니다.

결론 (Verdict)

이 선택은 제가 어떻게 일하고 싶은지에 달려 있습니다.

• 위임 (delegation)에는 Codex가 승리합니다: 범위가 지정된 목표를 주고, 실행하게 둔 다음, 나중에 결과를 검토하면 됩니다.
• 반복 (iteration)에는 OpenCode가 승리합니다: 계획을 검토하고, 에이전트를 조종하며, 피드백 루프 (feedback loop)를 긴밀하게 유지합니다.
• Codex는 더 세련된 느낌을 줍니다. OpenCode는 더 제어 가능한 느낌을 줍니다.

일상적인 백그라운드 작업에는 Codex를 선호합니다. 코드베이스 내부에서의 대화형 개발 (interactive development)과 학습에는 OpenCode를 선호합니다.

무승부.

OpenCode - 3, Codex - 3

4. Ecosystem (MCP + Skills + Plugins)

측면 (Aspect)	Codex	OpenCode
MCP 설정 (MCP Setup)	CLI 명령어 (codex mcp add)	.opencode/mcp-config.json을 통한 수동 설정
...

최고의 모델, 최고의 제공자(providers), 그리고 최고의 기능과 워크플로우(workflow)를 갖추고 있더라도, 모델이 실제 세상과 소통하고 지정된 방식으로 지정된 작업을 수행할 수 없다면 아무런 의미가 없습니다.

Codex와 OpenCode 모두 MCP, 플러그인(Plugin) 및 스킬(Skills)을 제공하지만, 작동 방식은 서로 다릅니다.

Codex

Codex는 MCP 통합을 지원합니다. 설치 방법은 다음과 같이 매우 간단합니다:

저는 Composio를 사용하겠습니다. 저는 보통 여러 개의 MCP 서버를 사용하는데, 각 서버를 안전하게 연결 및 설정하고 에이전트(agents)가 여러 도구 호출(tool calls)을 지능적으로 처리하도록 만드는 것이 번거롭기 때문입니다.

# Codex에 Composio MCP 서버 추가
codex mcp add composio

...

연결 여부를 확인합니다:

codex mcp list

이제 MCP가 제대로 작동하는지 확인하기 위해, 다음 명령어로 스킬(skills)을 추가할 수 있습니다: