Codex는 리서치와 코딩이 한 루프에서 검증될 때 의미가 있다

Codex CLI에 웹 검색이 붙으면 개발 흐름이 진짜 달라질까? 릴리스 노트 한 줄만 보면 “이제 리서치도 알아서 하겠지”라고 기대하는 게 자연스럽다. 최신 문서를 찾고, 관련 PR을 확인하고, 그 근거로 코드를 고치는 과정이 한 도구 안에서 이어질 것처럼 보이기 때문이다.

하지만 검색 기능이 붙었다는 사실만으로 자동화가 좋아지는 것은 아니다. 근거를 확인하지 않은 실행은 빠른 개발이 아니라 빠른 착각이 된다. 특히 에이전트가 리서치와 코드 수정을 분리해서 이해하면, 최신 정보를 가져와도 실제 변경은 엉뚱한 방향으로 흐를 수 있다.

그래서 내가 이번 v0.139.0에서 봐야 할 지점은 기능 추가 자체가 아니다. 핵심은 리서치, 코드 수정, 검증이 같은 루프 안에서 연결되는가다.

핵심은 검색 기능이 아니라 작업 루프의 압축이다

Codex CLI는 터미널에서 에이전트형 코딩 작업을 시키는 명령줄 도구다. 여기서 말하는 Code mode는 단순 채팅이 아니라 파일을 읽고, 명령을 실행하고, 코드를 고치는 작업 모드에 가깝다. v0.139.0의 핵심 변화는 Code mode 안에서 web search, 즉 웹 검색을 사용할 수 있게 된 점이다.

이걸 “검색창이 하나 더 생겼다” 정도로 보면 틀린 해석이다. 진짜 의미는 근거 수집과 코드 변경이 같은 맥락 안에 들어온다는 데 있다. 예전에는 브라우저에서 릴리스 노트나 이슈를 찾고, 내용을 요약해서 프롬프트에 붙이고, 다시 에이전트에게 파일을 고치라고 시켰다. 이 과정에서 링크 하나를 빼먹거나, 오래된 문서를 섞거나, 에이전트가 근거를 코드 작업과 분리해서 이해하는 일이 생겼다.

Code mode web search가 제대로 동작한다면 흐름은 달라진다. 에이전트가 최신 문서를 확인하고, 그 근거를 바탕으로 도구 호출 방식을 정하고, 실제 코드나 설정을 고친 뒤, 테스트 명령으로 검증한다. 결국 “검색 → 판단 → 수정 → 검증”이 한 번의 작업 루프로 압축된다.

이 지점이 v0.139.0에서 가장 중요한 판단 기준이다. 다만 여기서 과장하면 안 된다. 릴리스 노트와 관련 PR 기준으로도 web search가 모든 계정이나 모든 환경에서 보장되는 기능이라고 단정하면 위험하다. 내부적으로 언급되는 /v1/alpha/search 같은 경로를 공개 API처럼 전제해서도 안 된다. 운영 기준은 단순하다. 내 환경에서 검색이 켜져 있고, 검색 결과가 작업 로그와 검증 결과에 남는가를 먼저 확인해야 한다.

MCP 스키마 보존은 작은 차이를 크게 줄인다

MCP는 Model Context Protocol의 줄임말이고, 모델이 외부 도구나 데이터 소스와 통신하기 위한 표준화된 연결 방식이다. 사내 문서 검색, 이슈 조회, 배포 상태 확인 같은 기능을 MCP 서버로 붙이면 Codex CLI 같은 에이전트가 그 도구를 호출할 수 있다. 문제는 도구가 많아질수록 “어떤 입력을 넣어야 하는지”를 모델이 정확히 이해해야 한다는 점이다.

관련 PR에서 중요하게 볼 변경은 MCP의 oneOf와 allOf 같은 JSON Schema 구조 보존 개선이다. JSON Schema는 데이터가 어떤 형태여야 하는지 정의하는 규칙이고, oneOf는 여러 형태 중 하나를 허용한다는 뜻, allOf는 여러 조건을 모두 만족해야 한다는 뜻이다. 이 정보가 중간에서 뭉개지면 에이전트는 도구 설명을 대충 이해하고 잘못된 인자를 넣는다.

현장에서 자주 터지는 실패가 이 지점이다. 도구 자체는 멀쩡한데 에이전트가 필드 하나를 엉뚱하게 보내서 호출이 실패한다. 실패 로그를 보면 “모델이 멍청했다”기보다 “계약서가 흐릿했다”에 가깝다. 여기서 계약서는 tool contract, 즉 도구가 요구하는 입력과 출력의 약속이다. MCP 스키마 보존이 좋아지면 이 계약서가 모델에게 더 선명하게 전달될 가능성이 커진다.

하지만 이것도 만능 패치는 아니다. oneOf와 allOf 처리가 개선됐다고 해서 모든 MCP 호환성 문제가 사라지는 것은 아니다. 스키마가 복잡하거나, 서버가 실제로 받는 값과 문서화된 스키마가 다르거나, 필수 필드 설명이 애매하면 여전히 실패한다. 그래서 큰 사내 MCP 서버를 바로 붙이기 전에 작은 테스트 도구로 계약을 검증하는 쪽이 맞다.

따라 해볼 검증은 기능 소개보다 실패 조건을 먼저 본다

기능 검증은 “검색된다”는 감탄에서 시작하면 안 된다. 먼저 실패 조건을 잡아야 한다. 첫 번째 시나리오는 Code mode web search 확인이다. 최신 릴리스 노트나 특정 PR을 근거로 설정 파일을 바꾸게 시킨 뒤, 에이전트가 어떤 출처를 참고했는지와 실제 변경이 그 출처와 맞는지를 본다.

예시 흐름은 이렇다.

codex

Codex CLI를 실행한 뒤에는 이런 식으로 요청한다.

Codex CLI v0.139.0 릴리스 노트와 관련 PR을 확인해서,
현재 프로젝트에서 MCP 도구 스키마 검증에 필요한 최소 테스트 계획을 작성하고
실행 가능한 체크리스트 파일로 저장해줘. 변경 후 근거 링크와 검증 명령도 남겨줘.

여기서 검증 기준은 세 가지다.

1. 실제로 최신 릴리스나 PR을 근거로 삼았는가
2. 근거와 무관한 일반론으로 파일을 채우지 않았는가
3. 마지막에 실행 가능한 검증 명령이나 체크리스트가 남았는가

검색 결과를 예쁘게 요약하는 것보다, 그 요약이 코드 작업의 판단 기준으로 이어졌는지가 더 중요하다.

두 번째 시나리오는 MCP 스키마 계약 검증이다. 처음부터 복잡한 사내 도구를 붙이지 말고, 입력 형태가 명확한 작은 MCP 도구를 하나 만든다. 예를 들어 mode가 file 또는 url 중 하나여야 하고, 각각 필요한 필드가 다른 식으로 oneOf를 쓰는 도구가 좋다. 그다음 Codex CLI가 이 도구를 호출할 때 올바른 형태를 고르는지 본다.

체크리스트는 이렇게 잡을 수 있다.

- oneOf 분기에서 file 입력과 url 입력을 구분하는가
- allOf로 합쳐진 공통 필드를 누락하지 않는가
- 잘못된 입력을 줬을 때 에러를 읽고 재시도하는가
- 도구 호출 실패를 코드 수정 성공으로 착각하지 않는가
- 최종 결과에 호출 근거와 실패 로그를 남기는가

이런 검증은 귀찮지만 효과가 크다. 특히 팀에서 MCP 서버를 여러 개 붙이는 순간, “대충 되겠지”는 비용으로 돌아온다. 도구를 늘리기 전에 작은 계약 테스트를 먼저 통과시키는 쪽이 훨씬 싸다.

운영 체크리스트는 doctor, 캐시, 프록시까지 봐야 한다

v0.139.0 릴리스 맥락에서 같이 봐야 할 운영 포인트는 doctor, plugin cache, sandbox proxy다. 여기서 doctor는 환경 진단 명령에 가깝고, plugin cache는 플러그인이나 관련 구성요소를 재사용하기 위한 캐시, sandbox proxy는 샌드박스 환경에서 네트워크 접근을 프록시로 통제하는 장치로 이해하면 된다.

개인 실험이면 기능 하나만 켜고 써도 된다. 하지만 팀 운영으로 넘어가면 질문이 달라진다. 누가 어떤 버전으로 실행했는지, 플러그인 캐시 때문에 재현이 꼬이지 않는지, 네트워크가 의도한 프록시를 통해 나가는지 확인해야 한다. 특히 웹 검색과 외부 도구 호출이 섞이면 네트워크 통제가 중요해진다.

내 기준 운영 체크리스트는 이렇다.

- codex 버전이 v0.139.0 이상인지 확인한다
- doctor 계열 진단으로 로컬 환경 이상 여부를 먼저 본다
- 플러그인 캐시가 재현성에 영향을 주는지 확인한다
- MCP 서버별 스키마 계약 테스트를 최소 1개 이상 둔다
- sandbox proxy 설정이 실제 실행 프로필에 적용되는지 확인한다
- 웹 검색 결과를 최종 변경 근거로 기록하게 한다
- 테스트 실패 로그를 숨기지 않고 작업 결과에 포함하게 한다

여기서 중요한 건 “설정했다”와 “적용됐다”를 구분하는 일이다. sandbox proxy enforcement, 즉 샌드박스 프록시 강제 적용은 설정된 프록시와 프로필 범위 안에서만 의미가 있다. 다른 프로필로 실행하거나, 일부 명령이 샌드박스 밖에서 돌면 기대한 통제가 깨진다.

이 부분은 설정 파일만 보고 안심하면 안 된다. 실제 명령 실행 로그로 확인해야 한다. 운영에서 믿을 수 있는 것은 설정 의도가 아니라 실행 증거다.

리스크와 주의사항은 기능 미지원과 호환성 착각에서 나온다

첫째, web search availability는 환경마다 다를 수 있다

이번 변화에서 가장 조심할 부분은 availability, 즉 기능 사용 가능 여부다. web search가 릴리스에 들어갔다고 해도 모든 계정, 모든 배포 채널, 모든 실행 모드에서 동일하게 보장된다고 말하면 안 된다. 글을 읽는 사람이 그대로 따라 했는데 검색이 안 될 수도 있다. 그 경우에는 기능이 고장 났다고 단정하기보다 계정, 버전, 프로필, 실행 모드, 네트워크 정책을 순서대로 확인해야 한다.

둘째, 알파 엔드포인트를 공개 API처럼 쓰면 깨진다

두 번째 리스크는 비공개 또는 알파 성격의 엔드포인트를 공개 API처럼 쓰는 일이다. 관련 PR 맥락에서 언급되는 /v1/alpha/search는 공개 계약으로 전제하면 안 된다. 내부 구현이나 실험적 경로에 의존해서 자동화를 짜면 어느 날 갑자기 깨질 수 있다. 안정적인 워크플로우를 만들려면 CLI가 공식적으로 제공하는 사용 경로와 릴리스 노트를 기준으로 잡아야 한다.

셋째, MCP 스키마 개선을 과신하면 실패 원인을 놓친다

세 번째 리스크는 MCP 스키마 개선을 과신하는 것이다. 스키마 보존이 좋아져도 도구 설명이 부정확하면 호출은 실패한다. 서버 구현이 스키마와 다르면 더 위험하다. 에이전트는 스키마를 보고 판단하는데 서버는 다른 규칙을 적용하면, 실패 원인을 찾는 데 시간이 많이 든다. 그래서 MCP는 “연결됐다”가 아니라 “대표 입력이 성공하고, 잘못된 입력에서 예측 가능한 에러가 난다”까지 확인해야 한다.

결론은 새 기능보다 검증 가능한 워크플로우다

Codex CLI v0.139.0에서 봐야 할 것은 “웹 검색이 생겼다”가 아니다. 핵심은 리서치와 코딩이 같은 루프에 들어올 수 있는지다. Code mode web search는 근거 수집을 작업 흐름 안으로 끌어오고, MCP oneOf와 allOf 스키마 보존 개선은 도구 호출의 계약을 더 선명하게 만들 가능성이 있다.

하지만 가능성은 검증 전까지 가능성일 뿐이다. 계정별 기능 availability, MCP 서버별 호환성, sandbox proxy 적용 범위, plugin cache 재현성은 직접 확인해야 한다. 새 기능을 보고 바로 업무 자동화에 박는 건 성급하다. 작은 도구 하나로 계약 테스트부터 돌리는 게 덜 아픈 길이다.

최종 판단은 명확하다. Codex를 “코딩 도구”로만 보지 말고, 리서치 → 도구 호출 → 코드 수정 → 테스트 → 근거 기록을 묶는 워크플로우 도구로 검증해야 한다. 단, 검증 기준은 반드시 로그와 테스트 결과로 남겨야 한다. 그래야 기능 소개 글이 아니라 실제 팀에서 쓸 수 있는 운영 기준이 된다.

참고자료

• OpenAI Codex 릴리스 v0.139.0 — Codex CLI v0.139.0 변경 확인용
• Code mode web search 관련 PR — 웹 검색 기능 근거
• MCP oneOf/allOf 스키마 관련 PR — MCP 스키마 보존 변경 근거
• large tool schema 보존 관련 PR — 대형 도구 스키마 처리 관련 변경
• sandbox proxy enforcement 관련 PR — 샌드박스 프록시 적용 범위 확인용
• npm @openai/codex 패키지 정보 — 배포 패키지 확인용