Codex 0.139.0에서 code mode의 JavaScript를 통해 Web 검색을 직접 호출할 수 있게 되었습니다

에이전트에게 도구를 한 번 호출하게 할 때마다, 결과를 통째로 컨텍스트(Context)에 쌓고 모델에게 다시 한 번 왕복시킨다. 이 설계의 낭비를 각 기업이 거의 비슷한 시기에 깨닫고, "모델에는 코드를 작성하게 하고, 도구 호출의 합성(Composition)은 런타임 측에서 처리한다"는 방식으로 수렴하고 있다. Cloudflare의 Code Mode, Anthropic의 code execution with MCP, 그리고 OpenAI의 Codex CLI에 실험적 플래그로 들어가 있는 "code mode". 2026년 6월 9일에 출시된 Codex 0.139.0은 이 code mode에 남아 있던 큰 구멍, 즉 Web 검색을 드디어 메웠다.

릴리스 노트에서는 한 줄의 수수한 변경 사항이지만, 개인적으로는 이번의 핵심이 바로 여기라고 생각한다. 차례대로 살펴보겠다.

전제를 정리해 두겠다. code mode는 Codex의 config.toml에서 활성화하는 실험적 기능으로, 모델에게 보여줄 도구를 실질적으로 exec와 wait 두 가지로 압축할 수 있다. 모델은 개별 도구를 JSON으로 직접 호출하는 대신, 생(raw) JavaScript를 작성하여 exec에 전달한다. 코드는 Node가 아니라, Codex 프로세스에 내장된 V8 isolate(이번 릴리스에서 rusty_v8 149.2.0으로 업데이트됨)에서 비동기 모듈로서 평가된다. 파일 시스템도 네트워크도 console도 없는, 순수한 JS다.

대신 셸 실행이나 MCP 도구가 글로벌 tools 객체에 생성된다. await tools.exec_command(...)나 await tools.mcp__github__get_issue(...)와 같이, 등록된 도구를 정규화된 식별자로 호출할 수 있다. text()로 명시한 값만이 모델의 컨텍스트로 반환되며, 중간 결과는 store()/load()를 통해 세션 내에 유지할 수 있다. 루프나 조건 분기, 여러 도구의 합성이 스크립트 하나로 완결되어, 거대한 중간 출력을 모델에게 보여주지 않아도 된다. 토큰 소비 관점에서 JSON 함수 호출의 순차적 왕복과는 다른 경제성을 갖게 된다.

이 사양은 codex-rs/code-mode/src/description.rs에 모델에게 전달될 도구 설명문으로서 그대로 작성되어 있다. 숨겨진 기능의 동작을 알고 싶다면 프롬프트의 소스를 읽는 것이 가장 빠르다는 좋은 사례이기도 하다.

문제는 Codex의 standalone Web 검색이 이 세계에 들어와 있지 않았다는 점이다. 검색은 서버 측의 /v1/alpha/search 엔드포인트에서 실행되지만, PR #26719의 설명에 따르면 응답은 지금까지 encrypted_output, 즉 클라이언트의 스크립트에서는 내용을 다룰 수 없는 암호화된 형식이었다. 엔드포인트가 평문(Plaintext)인 output을 반환하게 됨에 따라, 검색이 tools 객체를 통해 code mode에 공개되었다.

통합 테스트에는 다음과 같은 코드가 등장한다.

const result = await tools.web__run({
search_query: [{ q: "standalone web search" }],
});
...

검색하고, 결과를 JS로 필터링하여 필요한 것만 다음 도구에 전달한다. 혹은 여러 쿼리를 던져 중복을 제거한 뒤 text()로 요약 대상만 반환한다. 지금까지 검색할 때마다 code mode 밖으로 나가 모델을 한 번 왕복시켜야 했던 처리가 isolate 내에서 완결된다. "조사한 뒤에 움직이는" 형태의 에이전트를 작성하는 사람일수록 효과적인 변경이다.

또 하나, MCP 사용자에게 직접적으로 영향을 주는 것이 스키마 처리의 개선(#24118, #27084)이다. 도구나 커넥터의 입력 스키마에 포함된 oneOf/allOf가 변환 시에 유지되도록 되었으며, 거대한 스키마를 압축할 때도 얕은 계층의 구조를 더 많이 남기게 되었다.

유니온 타입(Union Type)을 다용하는 MCP 서버에서는 지금까지 스키마가 평탄화(Flattening)되어 모델로부터 유효한 입력 형태를 볼 수 없게 되는 경우가 있었다. code mode에서는 모델이 스키마를 바탕으로 JS 호출 코드를 작성하므로, 타입 정보의 결손은 호출 실패로 직결된다. 수수하지만, code mode를 실용적인 수준으로 끌어올리기 위한 전제 조건 정비라고 읽어야 할 변경이다.

기능 스테이지는 UnderDevelopment이며 기본적으로 비활성화되어 있다. features/src/lib.rs에 플래그 정의가 있다. 최신 버전으로 업데이트한 후(npm이라면 npm i -g @openai/codex@latest...

codex --version 명령어로 0.139.0 이상인지 확인한 후, ~/.codex/config.toml에 다음 내용을 추가한다.

[features]
code_mode = true
# 모델에게 보여줄 도구(tool)를 exec / wait로만 제한할 경우
...

code_mode_only를 활성화하면 의존성 해결 과정에서 code_mode도 자동으로 활성화된다. 실험 단계이므로 플래그 명칭이나 동작이 예고 없이 변경될 수 있음을 전제로 사용하기 바란다. 검색 엔드포인트(endpoint) 경로가 /v1/alpha/search라는 점 또한 아직 확정되지 않았음을 시사한다.

마지막으로 한 가지 주의할 점이 있다. 검색 결과가 평문(plain text)으로 V8 런타임(runtime)에 들어간다는 것은, 외부 웹의 문자열이 모델의 검토를 거치지 않고 store()되어 다른 도구의 인자(argument)로 흘러 들어가는 경로가 생겼음을 의미한다. 스크립트를 작성하는 주체가 모델 자신이기 때문에 즉각적으로 위험하다고 단정할 수는 없으나, 프롬프트 인젝션 (Prompt Injection) 대책을 "모델이 모든 입출력을 보고 있다"는 전제하에 설계했다면, code mode에서는 그 전제가 무너진다. 동일한 릴리스에서 샌드박스(sandbox) 프록시(proxy)를 통한 네트워크 강제 적용(#27035)이 포함된 것은 결코 우연이 아닐 것이다. 도구 호출의 주도권이 런타임 측으로 이동할수록, 가드레일(guardrail) 역시 실행 환경 측에 배치할 필요가 생긴다. 에이전트(agent)의 설계가 오케스트레이션 (orchestration)에서 코드 생성 (code generation)으로 기울어지는 흐름은 멈추지 않을 것으로 보이지만, 보안 경계(security boundary)의 재설정은 아직 그 속도를 따라잡지 못하고 있다.