Goal Mode 기본값, Codex 운영층의 새 대기시간

OpenAI가 2026년 5월 21일 Codex changelog에 앱 26.519와 CLI 0.133.0 업데이트를 올렸습니다. 겉으로 보면 Appshots, Goal Mode, locked computer use, browser annotation, plugin sharing, permission profile 같은 기능 묶음입니다. 하지만 이 업데이트를 따로 봐야 하는 이유는 명확합니다. Codex가 단순히 "더 많은 곳에서 코드를 고치는 도구"가 아니라, 긴 작업을 목표 단위로 붙잡고, 다른 앱의 맥락을 받아들이고, 잠긴 컴퓨터 뒤에서도 제한된 실행을 이어가는 운영층으로 이동하고 있기 때문입니다.

지난 5월 14일 OpenAI는 Codex를 ChatGPT 모바일 앱에서 원격으로 다루는 기능을 공개했습니다. 그때의 핵심은 사용자가 자리 밖에서도 Codex thread를 보고, 질문에 답하고, 방향을 바꾸고, action을 승인할 수 있다는 점이었습니다. 이번 5월 21일 업데이트는 그 다음 질문에 답합니다. 사람이 휴대폰에서 승인할 수 있다면, Codex는 어떤 단위로 오래 일해야 합니까. 다른 앱을 보며 일할 때 맥락은 어떻게 줘야 합니까. Mac이 잠기면 computer use는 어디까지 허용해야 합니까. 팀은 이 권한과 플러그인을 어떻게 관리해야 합니까.

그래서 이번 뉴스의 무게중심은 제품 기능보다 작업 루프입니다. 코딩 에이전트 경쟁은 모델 벤치마크만으로 설명하기 어려워졌습니다. 같은 모델을 쓰더라도 에이전트가 멈추는 지점은 다릅니다. 목표를 잃어서 멈추고, 앱 맥락을 몰라서 멈추고, 사용자가 자리를 비워 승인하지 못해 멈추고, 권한 정책이 불분명해 멈춥니다. OpenAI의 이번 Codex 업데이트는 이 멈춤 지점을 하나씩 제품 표면으로 끌어올린 사건입니다.

Appshots는 복사 붙여넣기 비용을 겨냥합니다

Codex 앱 26.519에서 가장 눈에 띄는 기능은 Appshots입니다. OpenAI는 macOS Codex 앱에서 양쪽 Command 키를 눌러 전면 앱 창을 Codex thread에 보낼 수 있다고 설명합니다. 전송되는 것은 단순 이미지가 아니라 스크린샷과 가능한 텍스트입니다. 사용자가 브라우저, 디자인 도구, 문서, 에러 창, 내부 앱을 보다가 "이 화면을 기준으로 고쳐 달라"고 말할 때, 긴 설명을 직접 쓰지 않아도 되는 방향입니다.

이 변화는 작아 보이지만 코딩 에이전트의 실제 사용에서는 중요합니다. 개발 작업은 코드 파일만으로 이뤄지지 않습니다. 에러는 브라우저 콘솔에 있고, 요구사항은 문서에 있고, 스타일 피드백은 디자인 화면에 있고, 재현 단계는 사내 도구의 특정 상태에 있습니다. 지금까지는 사용자가 이 맥락을 텍스트로 옮기거나, 스크린샷을 따로 첨부하거나, 에이전트가 브라우저를 직접 열게 해야 했습니다. Appshots는 그 중간 비용을 줄입니다.

하지만 Appshots가 더 흥미로운 지점은 "에이전트의 입력"을 prompt box 밖으로 넓힌다는 점입니다. 프롬프트 엔지니어링은 사용자가 정확한 문장으로 요구를 설명한다고 가정합니다. 실제 개발 현장에서는 사용자가 정확히 설명하기 전에 이미 화면을 보고 있습니다. "여기 버튼 간격이 어색하다", "이 승인 모달의 카피가 안 맞다", "이 테이블 정렬이 깨졌다"는 문제는 화면 맥락이 먼저이고 언어가 나중입니다. Appshots는 Codex가 그런 시각적 작업 맥락으로 들어가는 입구입니다.

Goal Mode는 실험에서 운영 단위로 올라왔습니다

이번 업데이트에서 더 큰 변화는 Goal Mode 정식화입니다. OpenAI는 Goal Mode가 더 이상 experimental feature가 아니며 Codex 앱, IDE extension, CLI에서 사용할 수 있다고 설명합니다. changelog는 Codex가 특정 objective를 향해 몇 시간 또는 며칠 동안 나아갈 수 있다고 표현합니다. CLI 0.133.0에서는 goals가 기본 활성화되고, dedicated storage와 progress tracking을 갖는다고 적었습니다.

이것은 코딩 에이전트의 단위를 바꾸는 신호입니다. 짧은 chat turn에서는 "이 함수 고쳐줘"가 자연스럽습니다. 하지만 실제 장시간 작업은 목표와 성공 조건을 잃기 쉽습니다. dependency migration, 테스트 복구, 접근성 개선, 보안 리뷰, 문서 정리, 여러 PR 코멘트 반영은 중간에 실패와 우회가 생깁니다. 에이전트가 한두 번 답하다가 멈추는 구조에서는 사용자가 계속 상태를 재구성해야 합니다. Goal Mode는 그 상태를 제품 안에 저장하고 진행률을 추적하는 방향입니다.

이 지점은 최근 AI 코딩 도구의 공통 흐름과 맞물립니다. GitHub Copilot cloud agent는 plan과 research 단계를 강조하고, Claude Code 생태계에서는 작업 목표와 completion 조건을 명확히 하는 패턴이 중요해졌습니다. Codex가 Goal Mode를 기본값으로 끌어올린 것은 OpenAI도 같은 문제를 보고 있다는 뜻입니다. 코딩 에이전트가 "좋은 답변"보다 "완료 조건을 놓치지 않는 실행자"가 되어야 한다는 압력입니다.

잠긴 Mac에서 일한다는 말의 조건

가장 민감한 부분은 locked computer use입니다. OpenAI release note는 eligible Mac Computer Use 사용자가 Mac이 잠긴 뒤에도 Codex가 remote and secure하게 작업을 이어갈 수 있다고 설명합니다. Codex changelog는 이 기능이 active, trusted computer use turns에 한정되고, short-lived authorization, covered displays, local input 시 relock, manual-unlock fallback 같은 안전장치를 포함한다고 적었습니다.

이 기능은 "Mac이 잠겨도 AI가 마음대로 컴퓨터를 쓴다"로 과장하면 안 됩니다. OpenAI가 명시한 제약과 안전장치가 있고, eligible user와 regional constraints도 있습니다. 하지만 개발 조직 입장에서는 충분히 큰 변화입니다. 컴퓨터 잠금은 지금까지 에이전트 실행의 자연스러운 경계였습니다. 사람이 자리를 떠나면 화면과 입력이 잠기고, 많은 desktop automation도 멈춥니다. locked computer use는 그 경계를 조건부로 다시 엽니다.

왜 필요할까요. 장시간 코딩 에이전트 작업은 종종 desktop app, browser, local terminal, design preview, test runner를 오갑니다. 사용자가 회의에 들어가거나 노트북을 잠근 동안에도 에이전트가 실패 원인을 확인하고, UI를 살펴보고, 다음 diff를 준비할 수 있다면 대기 시간이 줄어듭니다. 특히 5월 14일 모바일 원격 제어와 결합하면, 사용자는 휴대폰에서 승인하고 Codex는 잠긴 Mac 뒤에서 제한된 작업을 이어가는 형태가 됩니다.

다만 이 조합은 보안팀이 그냥 지나칠 수 없습니다. 잠긴 상태에서 desktop app을 사용할 수 있다는 것은 화면 노출, local credential, browser session, 승인 범위, audit trail 문제가 한꺼번에 붙는다는 뜻입니다. OpenAI가 covered displays와 relock on local input 같은 장치를 언급한 이유도 여기에 있습니다. 개발팀은 이 기능을 켜기 전에 어떤 앱과 어떤 action까지 허용할지, 화면 캡처와 로그가 어디에 남는지, 모바일 승인 시 어떤 위험도가 표시되는지 확인해야 합니다.

CLI 0.133은 운영팀이 볼 업데이트입니다

Codex 앱의 Appshots와 locked computer use가 사용자 경험 쪽이라면, CLI 0.133.0은 플랫폼팀과 도구 운영자가 봐야 할 업데이트입니다. OpenAI changelog에 따르면 goals는 기본 활성화되고 dedicated storage와 progress tracking을 갖습니다. codex remote-control은 foreground command처럼 실행되어 readiness를 기다리고 machine status를 보고하며, 명시적인 daemon-style start와 stop 명령을 유지합니다.

이 변화는 원격 제어를 "어딘가 켜져 있는 비밀스러운 백그라운드 프로세스"가 아니라, 상태를 보고 시작과 중지를 명확히 하는 실행면으로 다루려는 방향입니다. 에이전트 원격 제어가 널리 쓰이면 사용자는 지금 어떤 machine이 reachable한지, 어떤 host가 ready인지, 어떤 remote-control process가 켜져 있는지 알아야 합니다. 장시간 작업에서 투명성은 UX가 아니라 안전 조건입니다.

Permission profile 강화도 중요합니다. changelog는 list APIs, inheritance, managed requirements.toml support, runtime refresh behavior, stronger Windows sandbox integration을 언급합니다. 이것은 "Codex가 더 똑똑해졌다"가 아니라 "Codex가 어떤 권한으로 어디서 실행되는지 더 관리 가능해졌다"에 가깝습니다. 코딩 에이전트가 shell, file system, browser, MCP server, plugin을 쓸수록 권한 프로필은 설정 파일 수준의 부가 기능이 아니라 운영 정책이 됩니다.

Plugin discovery 역시 같은 흐름입니다. marketplace-aware list output, installed versions, visible marketplace roots, remote collection support는 팀이 어떤 plugin bundle을 쓰는지 추적하는 데 필요합니다. 플러그인은 skill, app integration, MCP server, lifecycle hook을 묶을 수 있습니다. 이것은 생산성을 높이지만 공급망과 권한 위험도 만듭니다. 최근 devlery가 다룬 NVIDIA Verified Agent Skills나 TanStack npm 공급망 사고와 연결되는 지점입니다. 에이전트 플러그인은 설치되는 순간 개발자의 파일, 터미널, 브라우저, 내부 API 근처에 놓입니다.

브라우저 개선은 프론트엔드 작업의 승인 언어를 바꿉니다

이번 changelog에는 in-app browser annotations와 browser-use reliability 개선도 들어 있습니다. OpenAI는 annotation으로 font size, color, spacing 같은 스타일을 직접 표시해 Codex에 더 명확한 신호를 줄 수 있다고 설명합니다. 또 page image asset extraction, structured data extraction, read-only JavaScript sandbox, Chrome extension tab clutter 개선, browser-use reliability 개선을 언급합니다.

이 부분은 프론트엔드 개발자에게 특히 중요합니다. 코딩 에이전트가 UI를 고칠 때 가장 어려운 것은 "어떤 부분이 틀렸는지"를 언어로 설명하는 일입니다. 사용자는 화면을 보고 있지만 에이전트는 DOM, screenshot, console, test output을 따로 봅니다. Annotation이 좋아질수록 사용자는 diff 설명이 아니라 화면 위의 문제 지점을 가리킬 수 있습니다. Codex는 그 신호를 코드 변경으로 번역합니다.

물론 이것도 완전한 해결책은 아닙니다. 브라우저에서 보이는 문제와 코드 원인은 다를 수 있습니다. 한 화면에서 spacing을 고치면 다른 viewport에서 깨질 수 있고, color 변경은 design token 정책과 충돌할 수 있습니다. 그래서 annotation은 "명령"이라기보다 "증거"에 가까워야 합니다. 에이전트는 annotation을 보고 바로 고치는 동시에, 왜 그 코드가 해당 시각 문제를 만들었는지 확인해야 합니다. 그래야 UI 에이전트가 화면 맞춤 노동이 아니라 재현 가능한 개발 작업이 됩니다.

커뮤니티 반응은 기능보다 실행 습관에 가깝습니다

Reddit r/codex의 5월 21일 업데이트 스레드는 remote computer use, Appshots, Goal Mode를 빠르게 요약하며 사용자들이 실제 개발 습관과 연결해 반응했습니다. 한 사용자는 Roo/Kilo에서 Codex로 옮겨왔고 context window 크기를 신경 쓰는 점이 마음에 든다고 썼습니다. r/CodexAutomation의 스레드는 Codex app 26.519와 CLI 0.133.0을 묶어 정리하면서 npm install -g @openai/codex@0.133.0 설치 명령, goals 기본 활성화, remote-control 구조 변경, permission profiles, plugin discovery를 실무 항목으로 받아들였습니다.

이 반응에서 보이는 것은 "새 기능이 멋지다"보다 "에이전트를 어떻게 오래 돌릴 것인가"입니다. 코딩 에이전트 사용자는 이미 여러 도구를 비교하고, context window, remote control, CLI release cadence, approval flow, plugin ecosystem을 실제 업무 조건으로 보고 있습니다. 이제 도구 선택의 기준은 모델 이름만이 아닙니다. 어떤 도구가 장시간 작업을 덜 멈추게 하는지, 어떤 도구가 실패 상태를 잘 보여주는지, 어떤 도구가 조직 정책과 충돌하지 않는지가 중요합니다.

동시에 우려도 현실적입니다. mobile approval과 locked computer use는 편하지만, 잘못 설계되면 성급한 승인과 권한 과잉을 만들 수 있습니다. 작은 화면에서 긴 command와 diff를 충분히 읽지 못한 채 허용할 수도 있고, 잠긴 Mac에서 어떤 앱 상태가 노출되는지 팀이 이해하지 못할 수도 있습니다. community가 기능을 환영하는 것과 별개로, 조직 도입에서는 "무엇을 못 하게 할 것인가"가 먼저 정의돼야 합니다.

Codex가 멈추는 지점을 찾아야 합니다

이번 발표를 개발팀 관점에서 받아들이는 가장 좋은 방법은 기능 목록을 켜는 것이 아니라, 우리 팀의 Codex가 어디에서 멈추는지 보는 것입니다. 목표가 모호해 멈춘다면 Goal Mode와 명확한 success criteria가 필요합니다. 화면 맥락을 설명하느라 시간이 낭비된다면 Appshots와 browser annotation이 가치가 있습니다. 사용자가 자리를 비워 승인 대기 시간이 길다면 mobile remote access와 locked computer use를 검토할 수 있습니다. 권한과 플러그인이 개인 설정에 흩어져 있다면 permission profile과 plugin inventory가 먼저입니다.

각 기능은 서로 연결됩니다. Goal Mode는 오래 일하게 만들고, 오래 일하면 중간 승인이 필요하며, 중간 승인은 모바일로 이동하고, 모바일 승인은 잠긴 Mac 뒤의 computer use와 만납니다. Appshots는 다른 앱의 맥락을 주고, browser annotation은 화면 피드백을 구조화하며, permission profile은 이 모든 작업이 어디까지 허용되는지 정합니다. 한 기능만 보면 편의 개선이지만, 함께 보면 Codex 작업 루프의 운영 체계입니다.

실무에서 가장 위험한 도입 방식은 "개발자 개인이 알아서 켜는 것"입니다. 에이전트가 파일만 읽고 작은 patch를 제안하는 단계에서는 개인 도구로 볼 수 있습니다. 하지만 desktop app을 보고, 잠긴 상태에서 움직이고, 원격 승인과 plugin marketplace를 거치면 팀 도구가 됩니다. 이때는 security policy, audit, secret handling, 승인 기준, 실패 복구가 같이 필요합니다. 코딩 에이전트의 생산성은 권한과 분리되지 않습니다.

다음 경쟁은 코드 생성기가 아니라 작업 지속성입니다

OpenAI의 이번 Codex 업데이트는 코딩 에이전트 전쟁의 다음 전장을 잘 보여줍니다. 모델이 더 좋은 코드를 쓰는가도 중요하지만, 실제 팀에서는 다른 질문이 더 자주 등장합니다. 에이전트가 목표를 잊지 않고 며칠짜리 작업을 이어갈 수 있습니까. 화면과 문서와 브라우저 맥락을 자연스럽게 받아들입니까. 사용자가 자리를 비웠을 때도 안전하게 대기 시간을 줄입니까. 권한과 플러그인을 조직이 추적할 수 있습니까.

이 질문들에 대한 답은 아직 완성되지 않았습니다. Goal Mode가 모든 장기 작업을 안정적으로 끝낸다는 보장은 없습니다. Appshots가 민감한 화면을 잘 걸러낸다는 뜻도 아닙니다. Locked computer use는 지역, 자격, 안전장치의 제약을 받습니다. Permission profile은 강력해질수록 설정과 운영 부담도 커집니다. 하지만 제품의 방향은 선명합니다. Codex는 이제 프롬프트를 기다리는 코드 생성기가 아니라, 목표와 맥락과 승인과 권한 위에서 오래 움직이는 개발 에이전트가 되려 합니다.

개발팀이 이번 뉴스를 통해 얻어야 할 결론은 간단합니다. 코딩 에이전트 도입의 핵심 질문을 "어떤 모델이 더 똑똑한가"에서 "우리 작업 루프의 어느 대기시간을 줄일 것인가"로 바꿔야 합니다. OpenAI가 Goal Mode를 기본값으로 올리고, Appshots로 앱 맥락을 붙이고, locked computer use로 잠금 상태의 경계를 다시 설계한 것은 그 질문에 대한 제품적 답입니다. 앞으로의 경쟁은 코드 한 줄을 더 잘 쓰는 도구가 아니라, 사람이 승인하고 조직이 감사할 수 있는 방식으로 작업을 계속 밀고 가는 도구 사이에서 벌어질 가능성이 큽니다.