OpenAI, 코덱스 "분해해서 팔았다"

이번에는 OpenAI가 코덱스를 '분해하여 판매'했기 때문입니다.

원래 Codex 뒤에 숨겨져 있고 에이전트가 계속 작업하고, 도구를 호출하고, 컨텍스트를 관리하고, 여러 에이전트를 조정할 수 있도록 하는 기능 세트를 추출하여 모든 개발자가 호출할 수 있도록 클라우드 API로 패키징했습니다.

코덱스를 서비스로?

사실 OpenAI는 오랫동안 코덱스를 해체해왔습니다.

이르면 2025년 4월 OpenAI가 o3 및 o4-mini를 처음 출시했을 때 Codex CLI를 오픈소스로 제공했습니다. 로컬 터미널에 직접 설치된 Claude Code의 OpenAI 버전과 약간 비슷합니다. 에이전트를 실행하는 방법과 도구를 호출하는 방법은 모두 GitHub에 명확하게 게시되어 있습니다. 기꺼이 노력할 의향이 있다면 다시 가져오고 수정하여 직접 실행할 수 있습니다.

하지만 당시에는 물건이 그냥 주어졌습니다. 사용할 수 있는지 여부와 사용 방법은 여전히 ​​귀하의 사업입니다.

한 달 뒤, 오늘날 우리에게 친숙한 제품인 Codex 클라우드 버전이 공식 출시되었습니다. 사용자는 코드 웨어하우스를 여기에 넘겨줄 수 있으며, 각 작업은 독립적인 클라우드 샌드박스에 해당합니다. Codex는 코드를 수정하고, 테스트를 실행하고, 버그를 수정하고, 여러 작업을 동시에 처리할 수 있습니다.

몇 달 뒤인 2025년 10월 OpenAI는 Codex SDK를 출시했습니다.

간단히 말하면 SDK는 개발자를 위한 툴킷이므로 Codex를 독립형 제품으로 사용할 수 있을 뿐만 아니라 다른 사람의 애플리케이션에 통합할 수도 있습니다. SDK를 사용하면 개발자는 몇 줄의 TypeScript 코드를 사용하여 Codex CLI를 구동하는 동일한 에이전트를 시작하고, 구조화된 출력을 얻고, 작업 상태를 유지하고, 일시 중지된 후에도 계속 실행할 수 있습니다.

그러나 SDK는 주로 프로그램에서 Codex를 호출하는 데 적합하며 아직 완전한 Codex 상호 작용 기능을 제공하지 않았습니다. 백그라운드 워크플로, 자동화된 스크립트 및 서버 측 프로그램에 매우 적합합니다. 하지만 Codex IDE와 같은 완전한 클라이언트를 만들고 싶다면 여전히 조금 어렵습니다.

그래서 OpenAI는 2026년 2월 Codex App Server를 공식 출시했고, Codex에서 Harness에 대해 처음으로 체계적으로 명확하게 설명했습니다.

OpenAI는 Codex Web, CLI, IDE 확장과 Mac App이 서로 다른 제품처럼 보이지만 실제로는 Agent Loop, Thread, 도구 실행, 인증 및 관리 상태를 담당하는 계층인 동일한 Codex Harness를 실행하고 있음을 명확하게 설명했습니다.

App Server는 이 전체 하네스 세트에 양방향 JSON-RPC 인터페이스를 추가합니다. JetBrains, Xcode 또는 기타 클라이언트는 에이전트 루프를 다시 생성할 필요가 없습니다. App Server를 직접 시작하여 전체 Codex를 구동할 수 있습니다.

App Server를 사용하면 다른 제품을 전체 Codex Harness에 직접 연결할 수 있습니다.

그러나 이 시점에서 해결해야 할 마지막 문제가 하나 남아 있습니다.

SDK는 로컬 Codex Agent를 제어하며 앱 서버 자체도 개발자가 시작하고 유지 관리해야 하는 상주 프로세스입니다. Codex를 제품에 통합하는 문제는 해결되었으나, 온라인 서비스에서 안정적으로 실행하는 것은 여전히 ​​다소 어렵습니다.

더 구체적인 예를 들자면, App Server를 사용하여 자신만의 Coding Agent 웹 사이트를 구축하는 경우 프런트 엔드가 Codex에 연결되어 있지만 사용자가 "이 웨어하우스 복구"를 클릭하면 여전히 수많은 후속 운영 및 인프라 문제를 해결할 수 있는 방법을 찾아야 합니다.

그리고 8월 19일이 왔습니다. 이날 OpenAI는 지난 1년 동안 오픈했던 CLI, SDK, App Server를 'Open Codex Harness'라는 플랫폼 내러티브로 통합하고, Codex를 제품에서 플랫폼으로 명확하게 업그레이드했다.

그리고 어제인 9월 10일(미국 시간)에 Agents API가 공개 테스트를 위해 공식적으로 공개되었습니다.

이번에는 개발자가 에이전트를 직접 생성하려면 작업, 모델, 도구, 실행 환경이라는 네 가지 사항만 API에 알려주면 됩니다. 긴 세션 컨텍스트 압축, 도구 예약 및 하위 에이전트 협업을 담당하는 Codex Harness는 OpenAI 자체에서 호스팅 및 유지 관리됩니다.

에이전트가 실제로 작동하는 시스템을 선택할 수도 있습니다. OpenAI의 샌드박스, 자체 인프라 또는 Cloudflare, E2B, Modal과 같은 타사 환경을 사용할지 여부를 선택할 수 있습니다. Harness는 OpenAI에서 제공하며, 실행 환경은 개발자가 결정합니다.

공식 성명은 매우 명확합니다. Agents API 자체에 대한 추가 비용은 없습니다. 즉, 하네스 호스팅, 장기 세션 관리 및 기타 기능은 별도의 에이전트 플랫폼 수수료 계층을 청구하지 않습니다.

개발자는 실제로 사용된 모델 토큰과 도구를 기준으로 비용을 지불합니다. OpenAI의 자체 호스팅 샌드박스를 사용하는 경우 컴퓨팅 리소스는 별도로 계산됩니다.

1년 넘게 OpenAI는 동일한 작업을 수행해 왔습니다. 즉, 특정 제품의 Codex를 재사용 가능한 기능으로 계층별로 분할하는 동시에 개발자가 스스로에 대해 걱정할 수 있도록 하는 것입니다.

이 제품 라인에 이름을 붙여야 한다면 이번에 서비스되는 소프트웨어가 아니라 Codex라는 점을 제외하면 실제로 당시 SaaS와 매우 유사합니다.

서비스로서의 코덱스.

하네스도 포크되기 시작했습니다

물론 Harness를 주목하는 것은 OpenAI만이 아닙니다.

DeepSeek Harness(이하 DSH)가 출시되었을 때 매우 시끄러운 방정식이 주어졌습니다.

에이전트 = 모델 + 하네스.

DeepSeek의 관점에서 모델은 에이전트의 절반에 불과하고 나머지 절반은 환경을 이해하고, 도구를 호출하고, 상태를 관리하고, 작업을 계속 실행하는 역할을 하는 하네스입니다. 두 가지가 서로 조정될 때만 에이전트가 실제로 작업을 수행할 수 있습니다.

DSH는 Harness 자체를 고도로 모듈화된 개방형 프레임워크로 만들었습니다. 모델, 도구, 기술, 세션, 샌드박스, 저장소, 에이전트 루프, 예약, UI까지 모두 교체할 수 있습니다.

'모든 것은 플러그인이다'라는 슬로건은 단순한 농담이 아닙니다. 모든 사람이 플러그인을 작성하고 DSH에 적응하는 것이 가장 좋습니다. 결국 DeepSeek이나 다른 모델이 위에서 실행되는지 여부에 관계없이 동일한 하네스 세트를 아래에서 사용할 수 있습니다.

이것은 OpenAI가 현재 취하고 있는 방향과 흥미로운 대조를 이룹니다.

OpenAI가 Codex 하네스도 오픈 소스로 공개했지만 Agents API는 분명히 다른 방향으로 가고 있습니다. 자신만의 하네스를 사용하거나 오픈 소스 하네스를 사용할 수 있지만 번거롭다고 생각되면 무시하고 제가 대신 준비하도록 하겠습니다.

그래서 우리는 이를 '서비스'에 더 가깝다고 생각합니다. OpenAI는 Harness를 호스팅하고 지속적으로 유지 관리하는 역할을 담당합니다. 개발자는 에이전트가 수행할 작업, 사용할 도구, 실행할 위치만 결정하면 됩니다. 향후 모델이 업그레이드되더라도 이에 맞춰 Harness가 변경된다면 OpenAI도 이를 함께 패키징할 준비를 하게 됩니다.

어떤 의미에서 하네스 수준에는 두 가지 모호한 경로가 있습니다.

DeepSeek이 대표하는 경로는 개발자가 스스로 조립할 수 있도록 모든 부분을 플러그인으로 만드는 개방형 생태계를 구축하는 것과 비슷합니다. OpenAI가 대표하는 파티는 클라우드 서비스에 베팅하여 돈과 수요를 제자리에 두는 것과 같으며 나머지는 해결하도록 도와드리겠습니다.

한 쪽은 Harness를 점점 더 Linux처럼 만들고 싶어하고, 다른 쪽은 Harness를 점점 더 AWS처럼 만들고 싶어한다고 생각할 수도 있습니다.

물론 이것은 단지 비유일 뿐입니다. OpenAI도 오픈소스 Codex Harness를 보유하고 있으며 DeepSeek이 향후 더 많은 호스팅 서비스를 제공하는 것이 불가능하지 않습니다. 하지만 적어도 현 단계에서는 두 제품의 초점이 확실히 다르다.

흥미롭게도 Harness를 서비스로 전환하는 데 있어서 Anthropic은 실제로 OpenAI보다 한 발 앞서 있습니다.

2025년 9월 초에 Anthropic은 Claude Agent SDK를 출시하여 Claude Code의 도구, 컨텍스트 관리, 권한 시스템 및 하위 에이전트 기능을 개발자에게 공개하여 다른 사람들이 이 세트를 에이전트로 사용할 수 있도록 했습니다.

올해 4월에는 OpenAI보다 훨씬 일찍 Claude Managed Agents를 출시했습니다. 세션, 하네스 및 샌드박스는 세 개의 독립적인 레이어로 분할됩니다. Anthropic은 하네스 및 장기 작업 호스팅을 담당합니다. 샌드박스는 Anthropic에서 제공하거나 다른 실행 환경에 연결할 수 있습니다. 이 아이디어는 실제로 오늘날의 Agents API와 매우 유사합니다. Anthropic 자체에서는 이를 "장기적인 에이전트 작업을 위한 호스팅 서비스"로 정의합니다.

그러니까 OpenAI는 이번에 Anthropic이 걸어온 길을 따라 계속해서 전진하고 있는 것입니다. 차이점은 OpenAI가 보다 "제품화된" Codex를 가지고 있다는 것입니다.

그러나 코덱스와 클로드코드는 오랫동안 서로 다른 제품 인상을 주었기 때문에 같은 이야기를 하더라도 전혀 다른 느낌을 불러일으킨다. Claude Code는 개발자가 터미널에 앉아 Agent와 함께 코드를 작성하는 것과 같은 느낌을 주는 반면, Codex App은 처음부터 "여러 장기 Agent를 동시에 감독"하는 인터페이스를 강조합니다.

그런데 Google은 이미 이 경로에 합류했습니다. 올해 5월 I/O 컨퍼런스에서 Gemini API는 Antigravity Harness와 샌드박스를 관리형 서비스로 전환하는 관리형 에이전트를 출시했습니다. 하지만 Google의 카드는 여기서 끝나지 않습니다. 이에 대해서는 나중에 논의하겠습니다.

그렇지만 누가 먼저인지는 그다지 중요하지 않은 것 같습니다... 물론, 결국 자신의 하네스를 개발자용 기본 레이어로 바꾸는 사람이 가장 큰 케이크를 먹을 수 있을 것입니다.

큰 승자는 누구일까요?

결국 모델 회사들이 이제 하네스를 잡기 시작하는 이유는 무엇일까요?

DSH에서 제공하는 방정식인 에이전트 = 모델 + 하네스와 마찬가지로 모델은 에이전트에게 다음에 수행할 작업을 알려줄 수 있지만 실제로 작업을 처음부터 끝까지 실행하려면 여전히 파일이 어디에 있는지, 어떤 도구를 호출해야 하는지, 오류가 발생할 때 복구하는 방법 및 결과가 최종적으로 기록되는 위치를 알아야 합니다.

즉, 모델이 에이전트 능력의 상한을 결정하고, 하네스는 점점 더 작업을 완료할 수 있는지 여부를 결정합니다.

경쟁의 차원이 '지능'에서 '실행'으로 바뀌면 가장 이점을 갖는 기업은 최고의 모델을 갖춘 AI 기업이 아닐 수도 있습니다.

에이전트가 실제로 작업을 시작한 후에는 이메일, 문서, 회의, 커뮤니케이션, 계정 권한 등 필요한 사항이 기존 플랫폼 회사의 손에 넘어가는 경우가 많기 때문입니다.

최근 중국에서 뜨겁게 달아오른 '오피스 에이전트 전쟁'은 사실 아주 전형적인 예다. 인터넷 플랫폼 시대에는 대기업들이 축적한 것들이 예전에는 각자의 생태계 기능의 일부에 불과했지만, 에이전트 시대에는 이러한 것들이 에이전트가 실제로 일할 때 호출해야 하는 도구가 됐다.

요즘은 다들 오피스 에이전트로 일하고 있어요. 표면적으로 그들은 다른 AI 직원보다 더 똑똑하고 능력이 뛰어납니다. 그 이면에서는 실제로 과거에 축적한 플랫폼 이점을 재사용하고 있습니다. 더 많은 기업 데이터, 문서, 도구 및 권한을 가진 사람은 에이전트가 작업을 완료하도록 더 쉽게 맡길 수 있습니다.

모범 기업은 보유하지 않은 포털에 대한 액세스 권한을 얻어야 하며, 10년 이상 사무용 소프트웨어와 인터넷 플랫폼을 제작해 온 기업은 이미 이러한 포털을 보유하고 있습니다.

즉,

AI 기업은 현실 세계와 다시 연결되기를 원하고, 플랫폼 기업은 이미 수많은 열쇠를 손에 쥐고 있습니다.

이 길을 따라가면서 가장 장점이 많은 '패밀리 버킷' 플레이어를 찾아야 한다면 아마도 Google이 가장 과장된 플레이어일 것입니다.

TPU, 클라우드 인프라, Gemini부터 검색, Workspace, Chrome, Android에 이르기까지 Google은 기본 기술부터 최종 사용자에 이르기까지 AI의 거의 모든 주요 측면을 다루고 있습니다. 검색, Gmail, 캘린더, 드라이브, YouTube, 지도 및 기타 제품은 자연스럽게 상담원이 호출할 수 있는 디지털 환경을 형성합니다. 이러한 자산은 이전 세대 인터넷에서는 독립적인 포털이었지만 Agent 시대에는 동일한 작업으로 재구성될 수 있습니다.

실제로 구글은 다양한 제품에 분산되어 있는 Agent 기능을 하단에 동일한 실행 시스템으로 통합하기 시작했습니다. Gemini Spark, Gemini API의 관리형 에이전트, 심지어 검색의 일부 에이전트 경험도 점차적으로 동일한 반중력 하네스를 공유하고 있습니다.

그러나 사용자 측면에서는 상황이 여전히 다소 지저분합니다.

현재 Google은 검색에 Gemini Spark, Workspace Studio, Antigravity, Gemini Enterprise 및 정보 에이전트도 제공합니다. 다양한 사용자와 시나리오에 직면하지만 일반 사람들의 경우 복잡한 문제를 Google에 넘겨주고 싶을 때 여전히 누구에게 의지해야 할지 모릅니다.

Google의 경우 이 모든 것을 달성하는 데 필요한 대부분의 조건이 이미 갖추어져 있습니다. 누락된 것은 충분히 간단한 제품 답변입니다.

그리고 Google이 이 문제를 정말로 이해한다면, 통합 에이전트 워크벤치를 만들거나 동일한 에이전트 실행 시스템이 전체 Google 생태계에 침투하여 사용자가 '문제가 있을 때 Google을 찾는' 데 익숙해지도록 한다면 글로벌 에이전트 시장의 경쟁 환경은 아마도 다시 바뀔 것입니다.

그렇지만 Google이 실제로 이 '가족용 버킷'을 에이전트에 넣더라도 국내 사용자는 이를 먼저 시청할 수 있을 것입니다.

국내 에이전트 전쟁을 먼저 살펴보고, 다음에는 어떻게 전개될지 살펴보겠습니다.