Codex CLI 0.152.0 업데이트: MCP 출력 제한, 무엇이 달라졌나
Codex CLI 0.152.0의 MCP 툴별 출력 토큰 제한이 모델 컨텍스트에 어떻게 적용되는지 살펴봅니다. 앱 서버 타임아웃, Vim 검색, Bedrock 인증 복구 등 6가지 변화와 Context7 설정법, 업그레이드 판단 기준을 실무 관점에서 정리했습니다.
Codex CLI 0.152.0은 2026년 9월 1일 6가지 새 기능과 함께 출시됐습니다. 하지만 이번 업데이트의 핵심은 기능 수보다, 툴 호출이 많고 오래 이어지는 작업에서 경계를 더 정교하게 관리할 수 있게 됐다는 데 있습니다. 가장 주목할 변화는 모든 MCP 툴에 똑같은 기본 정책을 적용하는 대신, 툴마다 모델에 전달할 출력량을 따로 제한할 수 있다는 점입니다.
Codex CLI 0.152.0 업데이트 핵심
이번 릴리스는 새 모델이나 요금제 변경이 아니라 제어력과 안정성을 높이는 업데이트입니다. Codex를 단순한 터미널 코딩 에이전트로 쓴다면, 개선된 사용량 제한 메시지와 한층 명확해진 자격 증명 복구 과정, 긴 초안 안에서 사용할 수 있는 Vim 검색이 가장 먼저 눈에 띕니다.
Codex를 MCP로 외부 시스템에 연결하거나 Codex 앱 서버를 기반으로 개발한다면 변화의 폭은 더 큽니다. Model Context Protocol의 약자인 MCP는 Codex가 문서 검색, Figma, GitHub, 사내 서비스 같은 툴을 호출하게 해주는 연결 계층입니다. 0.152.0부터는 이러한 툴마다 별도의 출력 예산을 지정할 수 있습니다.
이번 릴리스의 6가지 새 기능을 실제 영향을 받는 사용자별로 정리하면 다음과 같습니다.
이 가운데 가장 자세히 볼 만한 것은 첫 번째 항목입니다. Codex가 작업을 이어가며 보관하는 툴 출력의 양을 직접 바꾸기 때문입니다.
MCP 출력 제한은 실제로 어떻게 작동하나
MCP 툴의 반환값은 상당히 길어질 수 있습니다. 문서 질의 한 번에 긴 페이지 여러 개가 들어오기도 하고, 로그 검색 결과가 수많은 줄로 쌓이기도 합니다. Codex는 이 결과를 현재 작업의 단기 기억에 해당하는 모델 컨텍스트에 넣어야 합니다.
툴별 설정이 없으면 MCP 출력에는 현재 사용 중인 모델의 일반적인 잘림 정책이 기본으로 적용됩니다. 0.152.0에서는 특정 MCP 서버 아래의 특정 툴에 새로운 output_token_limit 설정을 추가할 수 있습니다. 그러면 Codex는 해당 툴에서 모델로 전달되는 결과를 지정한 토큰 예산에 맞춰 줄입니다.
핵심은 모델에 전달되는 출력이라는 표현입니다. MCP 서버가 수행하는 작업량은 줄지 않으며, Code Mode에는 여전히 원본 결과가 들어옵니다. 재개한 세션과 툴 실행 후 훅 응답에도 동일한 유효 예산이 이어지므로, 스레드를 다시 연다고 더 큰 페이로드가 조용히 복원되지는 않습니다.
이 변화가 중요한 이유
이제 질문은 “이 모델이 감당할 툴 출력은 어느 정도인가?”에서 “이 툴이 제 역할을 하는 데 실제로 얼마만큼 필요한가?”로 바뀝니다. 라이브러리 조회와 프로덕션 로그 덤프에 더는 같은 기준을 적용할 필요가 없습니다.
여기에는 두 가지 안전장치가 있습니다. 값은 양수여야 하므로 0과 음수는 거부됩니다. 플러그인 정책과 사용자 설정에 모두 제한이 있으면 더 작은 값이 적용됩니다. 툴 승인은 별개의 절차이므로 출력 예산을 줄여도 툴이 승인되거나 Codex가 호출 전에 승인을 요청하는 시점이 달라지지는 않습니다.
누가 어떻게 활용할 수 있나
출력이 많은 문서 툴을 쓰는 1인 개발자
1인 SaaS 개발자라면 광범위한 문서 검색이 코딩 작업의 나머지 컨텍스트를 잠식하지 않도록 막을 수 있습니다. 긴 페이지를 반환하는 툴에는 명시적인 예산을 두고, 정확한 조회 툴은 그대로 두면 저장소와 계획, diff에 쓸 작업 컨텍스트가 더 많이 남습니다.
0.152.0의 장점이 가장 분명하게 드러나는 사례입니다. 출력이 과도한 툴 하나 때문에 모든 툴의 예산을 일괄적으로 줄이지 않아도 되고, 잡음이 생기는 출처에 정확히 경계를 둘 수 있습니다.
오래 실행되는 앱 서버 작업을 운영하는 플랫폼 엔지니어
새 timeoutMs 필드는 앱 서버 메서드 thread/shellCommand에 속합니다. MCP의 tool_timeout_sec 설정과는 다릅니다.
이 구분은 중요합니다. 현재 MCP 툴의 기본 실행 타임아웃은 60초입니다. 반면 앱 서버의 셸 명령은 timeoutMs를 생략하거나 null로 두면 기본값 1시간을 유지합니다. 빌드, 마이그레이션, 테스트 스위트에 시간이 더 필요하다는 것을 아는 앱 서버 클라이언트는 이제 더 긴 제한 시간을 요청할 수 있습니다. timeoutMs를 0으로 설정하면 즉시 타임아웃되며, 잘못된 음수 값은 거부됩니다.
보조 명령이 타임아웃돼도 진행 중인 에이전트 턴은 중단되지 않습니다. 해당 턴을 계속 실행할지, 새 지시를 전달할지, 별도로 중단할지는 클라이언트가 결정해야 합니다.
긴 작업 지시서를 작성하는 Vim 중심 개발자
Vim 모드에서 이제 초안 자체를 검색할 수 있습니다. /는 앞쪽으로, ?는 뒤쪽으로 검색하며, n 또는 N을 누르면 끝에서 처음으로 이어가며 일치 항목을 반복 탐색합니다. 검색은 삭제, 변경, yank 작업과도 조합되고, 검색어는 프롬프트 본문에 들어가지 않습니다.
터미널에서 여러 문단짜리 작업 지시서를 쓰기 전까지는 사소해 보일 수 있습니다. 하지만 긴 초안에서 반복되는 이름 하나를 찾아 바꾸려고 편집기로 복사하던 번거로움은 사라집니다.
Bedrock을 사용하는 엔터프라이즈 팀
이전에는 제공업체 자격 증명이 만료되면 작업이 멈춘 것처럼 보이기 쉬웠습니다. 이제 Codex는 제공업체 인증 복구가 시작되고 완료될 때 안정적인 알림을 보냅니다. 대화형 TUI와 codex exec 양쪽에서 진행 상태도 표시합니다.
Amazon Bedrock을 경유하는 엔지니어링 팀이라면 운영 상태를 훨씬 명확하게 파악할 수 있습니다. 긴 정적 구간을 보고 추측하지 않아도 CI 로그에서 “에이전트가 작업 중”인 상태와 “제공업체 세션을 재인증 중”인 상태를 구분할 수 있습니다.
실제 패키지 이름을 그대로 쓰려는 플러그인 개발자
MCP 서버 이름에 이제 :, @, /, .을 사용할 수 있습니다. npm:@modelcontextprotocol/server-sequential.thinking 같은 이름도 mcp add, get, list, remove를 거친 뒤 런타임 툴 네임스페이스와 OAuth 자격 증명에서 같은 식별자를 유지합니다.
불필요하게 별칭을 만들던 문제가 사라집니다. 패키지 좌표와 설정 이름, 자격 증명 식별자를 하나로 맞출 수 있습니다.
사용량 제한에 자주 도달하는 팀
이제 터미널은 사용량 제한 알림을 다음 행동으로 연결할 수 있습니다. 지원되는 배너는 사용량, 크레딧, 재설정, 소유자 알림, 요금제 관리 페이지로 안내합니다. 복구 중에는 Codex가 사용량 정보를 새로 고치고, 오래된 응답을 거부하며, 상태가 최신으로 반영될 때까지 대기 중인 입력을 일시 정지합니다. 백엔드 배너를 통해 관련 없는 스레드 설정을 다시 쓰지 않고도 사용 가능한 첫 번째 대체 모델로 보낼 수도 있습니다.
사용 가능량 자체가 늘어나는 것은 아닙니다. 다만 한도의 의미가 명확해지고, 터미널이 사용자를 실질적으로 도움이 되는 곳으로 안내할 수 있게 됩니다.
실제 MCP 서버로 완성하는 Codex MCP 설정
새 설정의 형태를 가장 빠르게 확인하려면 Context7을 연결해 보면 됩니다. Context7은 Codex 설정 가이드에서 사용하는 문서 MCP 서버입니다. 이 서버의 query-docs 툴은 확인된 라이브러리 ID에 해당하는 문서를 가져오므로, 명시적인 출력 예산을 적용하기에 적합합니다.
릴리스 설치
새 설정 키를 쓸 수 있도록 버전을 고정해 설치합니다.
Bashnpm install -g @openai/codex@0.152.0Context7 추가
현재 Codex MCP 가이드에 나온 명령을 그대로 사용합니다.
Bashcodex mcp add context7 -- npx -y @upstash/context7-mcp툴 예산 설정
~/.codex/config.toml을 열고 Context7 서버 항목 아래에 다음 테이블을 추가합니다.TOML[mcp_servers.context7.tools.query-docs] output_token_limit = 3000030,000이라는 값은 Codex 자체 직렬화 테스트에서 가져왔습니다. 허용되는 설정 형식을 보여주는 값일 뿐, 어디에나 적용할 권장치는 아닙니다. 프롬프트에 필요한 근거를 유지할 수 있는 가장 작은 결과값에서 시작하고, 실제 출력이 잘릴 때 높이는 편이 좋습니다.연결 확인
codex mcp list를 실행해 서버가 설정됐는지 확인합니다. 터미널 UI에서는/mcp를 입력하면 현재 세션에서 사용할 수 있는 활성 서버가 표시됩니다.
알아둬야 할 한계
툴별 잘림은 안전장치이지 공짜 압축 기능이 아닙니다. 제한을 너무 낮추면 문제의 원인을 설명하는 핵심 로그 한 줄이나 문서의 중요한 단서가 Codex에서 빠질 수 있습니다. 플러그인 정책과 사용자 정책이 겹칠 때는 더 작은 값이 적용되므로, 플러그인 정책 때문에 실제 예산이 사용자 파일에 적힌 숫자보다 작아질 수도 있습니다.
설정한 예산 뒤에는 결과를 모델 요청에 담는 데 필요한 추가 구조를 고려해 표준 20% 직렬화 여유분이 적용됩니다. 따라서 이 값은 실용적인 예산으로 이해해야 하며, 직렬화된 모든 페이로드에 정확히 그만큼의 토큰이 담긴다는 보장은 아닙니다.
0.152.0의 나머지 변경은 유용한 유지보수 성격입니다. 호출자가 작업 디렉터리를 지정하지 않으면 재개된 스레드가 저장된 작업 디렉터리를 복원합니다. 자동 승인 검토는 기록 압축이 일어나도 더 많은 지시와 유효한 권한 부여를 보존합니다. 캐시 새로 고침과 원격 플러그인 변경 뒤에도 MCP 툴이 더 안정적으로 유지됩니다. 어느 것도 모델의 코딩 능력이나 요금제 가격, 사용 가능량을 바꾸지는 않습니다.
지금 무엇을 해야 하나
여러 MCP 툴을 운영하거나, 앱 서버를 내장하거나, Vim 모드에서 긴 프롬프트를 작성하거나, Bedrock을 경유하거나, 사용량 제한에 자주 도달한다면 이번 주에 업그레이드할 만합니다. 작업 흐름을 직접 개선하면서도 마이그레이션 범위는 좁은 변화들입니다.
조직에서 CLI 버전을 중앙 관리한다면 기다리는 편이 낫습니다. 공개 설정 문서에 아직 툴별 출력 키가 반영되지 않았으므로, 정책 번들을 담당하는 팀이 새 필드를 검증하고 실제 출력에 맞춰 제한값을 정할 시간을 두세요.
웹이나 모바일에서 ChatGPT만 쓴다면 이번 릴리스로 작업 방식이 달라지지는 않습니다. Codex가 현재 개발 방식에 맞을지부터 판단하는 단계라면, 더 폭넓게 다룬 Codex, Claude Code, Cursor 비교부터 읽는 편이 좋습니다.
개발 방식에 영향을 주는 릴리스를 쉬운 말로 정리한 운영 노트를 더 받아보려면 뉴스레터를 구독하세요.
2026년 9월 2일
Google에서 이 사이트를 우선하기
omidsaffari.com을 선호 소스로 지정하면 Google이 Top Stories, AI Overviews, AI Mode에서 우선적으로 보여 줍니다.
