Codex 업데이트 대응법: GPT-5.4 종료와 멀티 저장소 리뷰가 바꾸는 개발 흐름

Codex 업데이트를 쓰는 개발팀이라면 8월 말 전에 모델 설정과 리뷰 흐름을 한 번 점검해야 한다. OpenAI는 2026년 7월 31일 Codex에서 ChatGPT 로그인 사용자 기준 GPT-5.4와 GPT-5.4 mini를 8월 31일 종료한다고 공지했다. API 키로 인증한 Codex 세션과 OpenAI API에서는 유지되지만, 데스크톱 앱·워크스페이스 기본 모델·커스텀 에이전트·예약 작업에 남아 있는 설정은 교체가 필요하다.

이번 변화는 모델 이름 하나가 사라지는 수준이 아니다. 7월 Codex 릴리스는 ChatGPT 데스크톱 앱 통합, 멀티 저장소 리뷰, PR Chat, 원격 플러그인, MCP 연결 안정화, 프록시 환경 개선까지 한꺼번에 묶여 있다. 실무 개발자에게 중요한 질문은 “새 기능이 멋진가”가 아니라 “우리 팀의 자동화가 어느 지점에서 깨질 수 있는가”다.

무엇이 바뀌었나

OpenAI changelog 기준 핵심 변화는 네 가지다. 첫째, GPT-5.4 계열의 Codex 내 사용 종료 일정이 생겼다. 권장 교체 모델은 GPT-5.6 Terra와 GPT-5.6 Luna다. 둘째, Codex가 7월 9일부터 ChatGPT 데스크톱 앱 안으로 들어갔다. 기존 Codex 앱 사용자는 프로젝트와 설정을 유지할 수 있지만, 기본 화면과 플러그인 관리 방식은 바뀌었다.

셋째, 7월 30일 업데이트에서 멀티 폴더 프로젝트와 멀티 저장소 리뷰가 강화됐다. 여러 저장소를 하나의 프로젝트로 묶고, 저장소별 변경 라인을 한 화면에서 본 뒤 Review로 diff를 확인할 수 있다. 프론트엔드·백엔드·인프라 코드가 각각 다른 레포에 있는 팀에는 꽤 현실적인 변화다.

넷째, GitHub openai/codex 릴리스에는 Agent Plugins manifest, workspace plugin publishing, Amazon Bedrock과 Claude Code 플러그인 마켓플레이스, remote Code Mode host의 WebSocket 연결, MCP 인증·재연결 수정, 프록시 설정 반영 같은 항목이 들어 있다. 사내망, VPN, 프록시, 내부 도구를 붙여 쓰는 조직일수록 영향이 크다.

왜 모델 종료부터 확인해야 하나

모델 종료는 가장 지루하지만 가장 자주 장애를 만든다. 개발자가 앱에서 수동으로 모델을 바꾸면 끝이라고 생각하기 쉽지만, 실제 팀 환경에는 여러 곳에 모델 이름이 박혀 있다. 예를 들어 워크스페이스 기본값, 저장된 agent config, CI에서 호출하는 Codex 작업, 야간 코드 리뷰 cron, 온보딩 문서의 실행 예시, 사내 템플릿 저장소까지 확인해야 한다.

문제는 종료 당일에만 터지지 않는다. 일부 사용자는 ChatGPT 로그인으로 Codex를 쓰고, 일부 자동화는 API 키 인증으로 돌 수 있다. 같은 이름의 모델이 어떤 경로에서는 동작하고 어떤 경로에서는 실패하면 원인 파악이 더 어렵다. “내 컴퓨터에서는 되는데 팀원의 데스크톱 앱에서는 안 된다”가 가장 피곤한 장애 유형이다.

따라서 8월 31일 전에 grep으로 모델 문자열을 찾는 것이 첫 작업이다. gpt-5.4, gpt-5.4-mini가 설정 파일, 문서, 프롬프트 템플릿, 스케줄러에 남아 있는지 확인한다. 교체 모델을 고를 때도 무조건 상위 모델로 바꾸지 말고 작업 성격을 나눠야 한다. 대규모 설계·리팩터링·복잡한 리뷰는 Terra, 단순 수정·요약·반복 검사는 Luna처럼 기준을 세우는 편이 낫다.

멀티 저장소 리뷰는 어디에 유용한가

멀티 저장소 리뷰는 마이크로서비스 팀보다 작은 팀에게 더 유용할 수 있다. 실제 제품은 웹, 앱, 서버, 관리자 페이지, IaC가 나뉘어 있어도 한 기능 변경은 여러 저장소를 동시에 건드린다. 지금까지 AI 리뷰는 한 저장소 안 diff에는 강했지만, API 타입 변경이 프론트엔드 호출부와 백엔드 스키마를 함께 바꿨는지 보는 데 약했다.

Codex의 멀티 폴더 프로젝트와 멀티 저장소 review는 이 간극을 줄인다. 예를 들어 결제 상태 enum을 바꾸는 작업에서 백엔드 DB migration, API 응답 타입, 웹 대시보드 렌더링, 모바일 앱 fallback 처리가 한 번에 바뀌었는지 질문할 수 있다. PR Chat까지 쓰면 GitHub pull request의 변경 맥락 안에서 inline feedback을 만들고, 제안 패치를 검토할 수 있다.

단, 이 기능을 켠다고 리뷰 품질이 자동으로 올라가지는 않는다. 에이전트가 여러 저장소를 볼 수 있게 되면 실수 범위도 넓어진다. 리뷰 요청에는 “수정하지 말고 위험만 분류”, “마이그레이션과 호출부 불일치만 찾아라”, “테스트 실행은 읽기 전용 명령만 허용”처럼 범위를 좁혀야 한다.

원격 플러그인과 MCP는 편하지만 위험도 커진다

Agent Plugins와 MCP 연결이 안정화되면 Codex는 단순히 파일을 읽는 도구가 아니라 사내 시스템을 호출하는 작업자가 된다. 이때 편의성과 위험은 같이 커진다. 플러그인이 Jira, Notion, DB, observability, 배포 시스템에 접근한다면 모델의 잘못된 판단이 실제 변경으로 이어질 수 있다.

GitHub 릴리스에서 프록시, MCP authorization, remote execution, WebSocket, redirects 관련 수정이 많이 보이는 이유도 여기에 있다. 엔터프라이즈 환경에서는 인터넷이 자유롭지 않고, 프록시와 인증 토큰, 만료된 세션, 사내 인증서가 얽힌다. 연결이 불안정하면 에이전트가 실패를 잘못 해석해 엉뚱한 우회 작업을 시도할 수 있다.

실무에서는 플러그인을 한 번에 전면 허용하지 말고 단계적으로 열어야 한다. 처음에는 read-only 도구만 붙이고, 쓰기 작업은 사람이 승인하게 둔다. MCP 서버별로 scope를 나누고, 민감 데이터는 요약값만 노출한다. 특히 production DB, 결제, 고객 개인정보, 배포 버튼은 “AI가 직접 호출할 수 있는 도구”가 아니라 “AI가 요청하고 사람이 승인하는 도구”로 설계하는 편이 안전하다.

팀이 바로 해야 할 마이그레이션 순서

첫날에는 inventory를 만든다. Codex를 쓰는 경로를 데스크톱 앱, CLI, 모바일 remote, CI, GitHub PR 리뷰, 사내 플러그인으로 나누고 담당자를 붙인다. 둘째 날에는 모델 이름을 교체한다. 설정 파일에서만 바꾸지 말고 문서와 온보딩 예시까지 함께 고친다. 셋째 날에는 대표 작업 세 개를 골라 회귀 테스트한다. 예를 들어 “작은 버그 수정”, “멀티 레포 API 변경 리뷰”, “MCP 도구를 통한 로그 조회” 정도면 충분하다.

그다음은 권한 점검이다. Full access, Ultra, remote execution처럼 위험한 옵션은 기본값을 낮추고, 필요한 프로젝트에만 켠다. 플러그인과 MCP 서버는 접근 도메인, 토큰 보관 위치, 감사 로그, 실패 시 재시도 정책을 문서화한다. 마지막으로 팀원에게 “모델 종료일 이후 어떤 오류 메시지를 보면 어디에 알려야 하는지”를 공유한다.

실행 체크리스트

• 워크스페이스, 커스텀 에이전트, cron, CI에서 gpt-5.4와 gpt-5.4-mini 문자열을 검색한다.
• 복잡한 설계·리뷰 작업과 단순 반복 작업을 나눠 Terra/Luna 같은 교체 기준을 정한다.
• 멀티 저장소 프로젝트는 primary folder와 secondary folder를 명시하고, 리뷰 요청 범위를 좁힌다.
• PR Chat에는 “수정 금지/위험 분류/테스트 제안”처럼 역할을 먼저 준다.
• 원격 플러그인과 MCP 서버는 read-only부터 열고, 쓰기 작업에는 사람 승인 단계를 둔다.
• 프록시, VPN, 사내 인증서 환경에서 로그인·플러그인 다운로드·MCP 인증이 모두 되는지 따로 테스트한다.
• 종료일 전후 장애 대응 문구와 담당 채널을 정해 팀에 공유한다.

출처: OpenAI ChatGPT & Codex changelog, openai/codex GitHub releases.