8월 19일, OpenAI는 개발자 블로그에 "Codex as a platform"이라는 글을 올려 Codex에 대한 공식 설명을 "터미널에서 실행되는 코딩 어시스턴트"에서 "누구나 그 위에 직접 구축할 수 있는 오픈소스 실행 계층"으로 바꿨다.
글은 서두에서 간과하기 쉬운 사실 하나를 짚는다. 대부분의 사용자는 데스크톱 앱, 커맨드라인, 또는 IDE 플러그인을 통해 Codex를 접하지만, 이 세 가지 진입 경로는 모두 동일한 기반 시스템을 공유하며, 그 시스템은 이미 GitHub에 공개돼 있다(저장소는 openai/codex, Apache 2.0 라이선스, 현재 스타 10만 9000개). 이번에 OpenAI가 한 일은 재포지셔닝이다. "자사 제품의 구현 세부사항"이었던 것을 "당신들의 기반"으로 다시 쓴 것이다.
모델을 둘러싼 층
OpenAI는 이 시스템을 "harness"라는 용어로 부르며, 정의는 매우 단순하다.
"That surrounding execution system is the harness."
세부적으로 보면 harness는 맥락 수집, 작업을 실행 가능한 단계로 분해, 턴 간 세션 상태 유지, 도구 호출, 설정된 샌드박스와 권한 경계 안에서의 실행, 사람의 판단이 필요할 때 승인을 기다리며 멈추는 것, 그리고 최종적으로 결과를 비즈니스 시스템에 돌려주는 것까지를 담당한다. 이 작업들은 모델 가중치와는 무관하지만, 얼마나 잘 만들었는지가 벤치마크 점수를 직접 좌우한다. OpenAI는 글에서 지난 7월 말 자체 ARC-AGI-3 데이터를 다시 인용했다. harness 계층에서 "추론 유지"와 "컨텍스트 압축" 두 가지 스위치만 켰을 뿐인데, GPT-5.6 Sol의 공개 평가 점수는 13.3%에서 38.3%로 올랐고 출력 토큰은 약 6분의 1로 줄었다. 모델은 바뀌지 않았다, 바뀐 것은 그 주변 층이다.
침습 정도별 세 단계 통합 방식
OpenAI는 통합 방식을 명확히 세 단계로 나눠, 개발자가 상황에 맞게 선택할 수 있도록 했다. 모든 걸 채팅창 안에 밀어 넣을 필요는 없다.
codex exec는 스크립트, CI 작업, 일회성 백그라운드 작업을 위한 것으로, 경계가 정해진 에이전트 흐름을 실행하고 구조화된 결과를 내놓으면 끝난다. Codex SDK는 코드 안에서 Codex 작업을 시작·재개·스트리밍으로 읽어야 하는 애플리케이션을 위한 것이다. Codex app-server는 가장 침습적인 단계로, 애플리케이션이 로컬 Codex 프로세스에 연결해 세션을 상시 열어두고, 이벤트 스트림을 받고, 언제든 중단시키고, 에이전트에 자체 도구를 노출하며, 승인 요청 처리까지 넘겨받는다.
app-server의 활용법을 설명하기 위해 OpenAI는 Relay라는 예시 애플리케이션을 만들었다. 가상의 화물 이상 처리 콘솔이다. 사용자는 프롬프트를 입력하지 않고, 먼저 화물 건을 선택한 뒤 "Compare recovery" 같은 버튼을 누른다. 애플리케이션이 관련 맥락을 전달하면, Codex는 애플리케이션 자체가 연결한 MCP 도구를 통해 최신 데이터를 가져와 선택 가능한 방안을 설명한다. 실제로 예약을 변경하려면 반드시 사람의 승인을 거쳐야 하며, 쓰기 작업이 데이터베이스에 반영된 뒤 애플리케이션이 자체 업무 화면을 새로고침한다.
이러한 설계 방향은 글에서 직설적으로 설명된다. 범용 채팅창으로 디스패치 보드, 타임라인, 지도, 티켓 화면을 대체해서는 안 된다는 것이다. 그런 화면들은 원래 사람이 현장을 이해하고, 판단을 내리고, 통제감을 유지하는 곳이기 때문이다.
이미 제품에 적용한 사례들
OpenAI는 세 가지 공개 사례를 열거했다. GitHub와 JetBrains는 각자의 IDE 워크플로에 Codex를 연동했다. Cisco는 Cloud Control 내 App Builder에 Codex SDK를 사용했다. Thrive Holdings와 Crete는 세무 신고 프로세스에 Codex를 도입해, 시범 단계에서 세무 신고 7000건을 처리했고 신고 준비 시간을 약 3분의 1 줄였다.
마지막 수치가 가장 구체적이다. 세무 신고는 반복도가 높고 오류 허용도가 낮으며 규제가 엄격한 대표적인 영역으로, 시범 규모와 비교 가능한 효율 지표를 제시할 수 있다는 점은 "생산성이 크게 향상됐다"는 식의 막연한 말보다 훨씬 유용하다. OpenAI는 이 사례를 계기로 이 모델이 엔지니어링팀만을 위한 것이 아니라는 점도 강조한다. 고객 지원 트리아지, 운영 조율, 보안 사고 등급 분류, 영업 배경 조사 모두 같은 형태를 띤다. 애플리케이션이 맥락, 도구, 승인 절차를 제공하고 Codex가 그 루프를 담당하는 구조다.
오픈소스는 어디까지인가
글에는 밑줄로 강조된 문장이 하나 있다. 오픈소스로 공개되는 것은 harness와 통합 인터페이스이며, 모델 접근과 호스팅 서비스는 여전히 별도로 계산된다는 내용이다.
이 문장을 세 단계 통합 방식과 함께 놓고 보면 OpenAI의 취사선택이 분명해진다. 실행 계층은 무료로 공개되고, 감사 가능하며, 마음대로 개조할 수 있어 누구나 자사 제품에 가져다 넣을 수 있다. 하지만 에이전트 루프가 한 번 돌 때마다 토큰은 여전히 OpenAI의 API를 거쳐야 한다. 오픈소스 부분이 잘 만들어질수록, 그리고 더 많은 제품에 내장될수록 모델 쪽 호출량은 늘어난다. 이는 Anthropic이 MCP로 도구 연동을 사실상의 표준으로 만든 것과 같은 종류의 전략이지만, 이번에 OpenAI가 내준 것은 더 무겁다. 런타임 전체를 통째로 내놓은 것이다.
중국 내 에이전트 제품을 만드는 팀들에게 당장의 이득은 중복 작업을 덜 수 있다는 점이다. 세션 상태, 이벤트 스트림, 도구 호출, 승인에 의한 중단 같은 요소들은 대부분의 팀이 이미 한 번씩 직접 만들어봤고, 만든 뒤에도 계속 손봐야 했던 것들이다. 이제 대규모로 검증됐고 한 줄씩 읽을 수 있는 구현체가 참고 대상으로 추가된 셈이다. 대략 계산해보면, harness 계층의 변경만으로 출력 토큰을 6분의 1로 줄일 수 있다면 같은 예산으로 다섯 번 더 실행할 수 있다는 뜻이고, 이 계산만으로도 대부분의 팀이 소스코드를 진지하게 읽어볼 이유가 된다.
대가도 분명하다. 연동이 깊어질수록 OpenAI의 과금 모델에 더 단단히 묶인다. app-server 단계에서 특히 두드러지는데, 이는 단순한 호출 관계를 넘어서 상대방의 프로세스를 자사 제품 안으로 직접 들이는 것과 다름없다.
참고 출처: OpenAI 개발자 블로그 "Codex as a platform", CocoLoop, GitHub 저장소 openai/codex(라이선스, 스타 수, 세 단계 통합 방식은 저장소와 공식 문서로 확인했으며, ARC-AGI-3 점수와 토큰 감소폭은 OpenAI가 자체 발표한 수치임).