잠긴 맥에서도 일한다, Codex 목표 모드의 새 경계

OpenAI가 Codex에 Appshots, Goal mode GA, locked computer use를 추가했습니다. 코딩 에이전트가 장시간 작업자로 바뀌는 신호를 짚습니다.

AI 요약

무슨 일: OpenAI가 Codex에 Appshots, Goal mode GA, locked computer use를 묶어 추가했습니다.
- 2026년 5월 21일 ChatGPT 릴리스 노트와 Enterprise/Edu 릴리스 노트에 동시에 반영된 업데이트입니다.
의미: 코딩 에이전트의 단위가 단발 프롬프트에서 목표, 화면, 원격 승인, 조직 지표로 넓어집니다.
실무 영향: 프론트엔드 검증, GUI 버그 재현, 장시간 리팩터링은 쉬워지지만 권한·토큰·원격 제어 정책이 더 중요해집니다.
- Enterprise 관리자는 remote_computer_use = false 같은 정책과 Codex analytics를 함께 봐야 합니다.
주의점: locked computer use는 일반 원격 잠금 해제가 아니라 활성 computer use turn에 묶인 좁은 기능입니다.

OpenAI가 2026년 5월 21일 Codex 업데이트를 조용하지만 꽤 중요한 방식으로 밀어 넣었습니다. ChatGPT 릴리스 노트에는 “richer context, goal mode, browser improvements, and remote locked use”라는 제목으로, Enterprise/Edu 릴리스 노트에는 “goal mode, browser improvements, remote locked use, admin analytics, and plugin sharing status”라는 제목으로 올라왔습니다. 이름만 보면 기능 묶음처럼 보입니다. 하지만 한 줄로 압축하면, Codex가 “코드 한 번 고쳐주는 도구”에서 “목표를 들고 화면을 보며 오래 작업하는 에이전트” 쪽으로 더 멀리 이동한 업데이트입니다.

이번 묶음의 핵심은 네 가지입니다. Appshots는 사용자가 보고 있는 Mac 앱 창을 Codex thread에 바로 넘깁니다. Goal mode는 Codex가 목표와 완료 조건을 붙잡고 여러 단계의 작업을 계속하도록 만듭니다. In-app browser annotations와 browser-use 개선은 웹 UI를 눈으로 확인하고 주석으로 피드백하는 흐름을 강화합니다. Locked computer use는 사용자의 Mac이 잠긴 뒤에도, 조건이 맞으면 Codex가 desktop app을 조작하는 작업을 이어가게 합니다.

이것은 단순히 편의 기능이 아닙니다. 코딩 에이전트가 실제 팀의 작업 단위 안으로 들어오려면 세 가지가 필요합니다. 첫째, 현재 맥락을 빨리 받아야 합니다. 둘째, 긴 목표를 잊지 않아야 합니다. 셋째, 로컬 앱과 브라우저처럼 CLI로 설명하기 어려운 표면도 검증해야 합니다. OpenAI의 이번 Codex 업데이트는 이 세 가지를 한꺼번에 겨냥합니다.

Appshots, 복사 붙여넣기의 끝은 아니지만 압축은 크다

Appshots는 Codex 앱 on macOS에서 앞쪽 앱 창을 thread에 첨부하는 기능입니다. OpenAI Developers 문서에 따르면 사용자는 양쪽 Command 키, 또는 설정한 사용자 단축키를 눌러 appshot을 찍을 수 있습니다. Appshot에는 보이는 창 이미지가 들어가고, 앱이 제공하는 경우에는 보이는 텍스트와 화면 밖 일부 텍스트까지 포함될 수 있습니다. 첨부 뒤에는 일반 이미지나 파일처럼 Codex attachment로 동작하고, 세션 파일 안에 로컬로 저장됩니다.

이 기능이 흥미로운 이유는 “컨텍스트 수집”을 사용자 인터페이스의 첫 동작으로 만들기 때문입니다. 지금까지 코딩 에이전트에게 GUI 상태를 설명하려면 긴 문장, 스크린샷 업로드, 로그 복사, 브라우저 DOM 검사 결과를 따로 건네야 했습니다. Appshots는 그 과정을 “지금 보고 있는 앱 창을 보여준다”로 줄입니다. API reference, 이메일, 캘린더, 디자인 preview, 설정 화면, 에러 대화상자처럼 말로 설명하면 길어지는 맥락이 한 번에 들어갑니다.

물론 Appshots가 모든 문제를 해결하지는 않습니다. OpenAI 문서는 Google Docs, Gmail, Google Sheets, Google Slides 같은 앱과 웹사이트에서는 전체 문서나 화면 밖 텍스트가 아니라 보이는 screenshot만 받을 수 있다고 설명합니다. 이런 경우에는 해당 plugin이 있으면 구조화된 접근이 더 낫습니다. 즉 Appshots는 데이터 통합의 대체재라기보다 “시각 상태를 빠르게 공유하는 입구”에 가깝습니다.

그래도 코딩 에이전트의 사용 습관에는 큰 차이를 만듭니다. 사용자는 이제 “이 화면을 보고 이 흐름을 고쳐줘”라고 말하기 쉬워집니다. 디자인 QA, admin panel 설정, 앱 preview, 문서화되지 않은 SaaS 화면, 로컬 macOS 앱 버그처럼 파일만 읽어서는 알 수 없는 문제가 Codex thread 안으로 더 자연스럽게 들어옵니다. 에이전트가 잘못 이해할 여지는 여전히 있지만, 최초 설명 비용은 확실히 줄어듭니다.

Goal mode는 프롬프트를 작업 계약으로 바꾼다

Goal mode는 이번 업데이트에서 가장 중요한 구조적 변화입니다. OpenAI의 Codex prompting 문서는 Goal mode를 “긴 작업에서 Codex가 계속 붙잡고 갈 persistent objective”로 설명합니다. 사용자가 /goal로 목표를 설정하면, 그 목표 문장은 시작 프롬프트이면서 동시에 완료 기준이 됩니다. Codex는 작업 중 다음에 무엇을 해야 하는지, 지금 끝났는지 판단할 때 이 목표를 기준으로 삼습니다.

이 말은 코딩 에이전트의 기본 interaction이 바뀐다는 뜻입니다. 기존 프롬프트는 보통 “이 버그를 고쳐줘”, “이 컴포넌트를 만들어줘”처럼 한 번의 요청에 가깝습니다. Goal mode는 “이 코드베이스를 TypeScript strict mode로 옮기고 explicit any 없이 빌드되게 하라”처럼 검증 가능한 상태를 목표로 잡습니다. 작업이 여러 시간 또는 여러 turn을 넘어가도, Codex가 스스로 현재 상태와 목표 사이의 거리를 계속 확인하도록 설계된 셈입니다.

OpenAI 문서는 좋은 goal에는 구체적 outcome, 측정 가능한 target, test criteria가 들어가야 한다고 안내합니다. 예를 들어 “home page의 time to interactive를 1초 아래로 낮춘다” 같은 목표는 성공 여부를 확인하기 쉽습니다. 반대로 “코드를 더 좋게 만들어줘”는 Goal mode에 맞지 않습니다. 이것은 개발자에게도 중요한 신호입니다. 에이전트가 오래 일할수록, 모호한 요청은 더 큰 비용과 위험을 만듭니다.

최근 코딩 에이전트 경쟁은 모델 성능보다 “작업 유지력” 쪽으로 이동하고 있습니다. Claude Code, Codex, Google Antigravity, Cursor류 도구가 모두 긴 맥락, repo 탐색, test 실행, PR 수정, 브라우저 확인을 강조합니다. Goal mode는 이 흐름에서 OpenAI가 내놓은 명시적인 작업 계약 레이어입니다. 사용자에게는 편의 기능이지만, 팀 단위로 보면 task spec 작성법과 review 기준을 바꾸는 기능입니다.

Codex in-app browser에서 로컬 웹 앱 preview와 주석을 함께 다루는 공식 OpenAI Developers 예시입니다.

브라우저 주석은 프론트엔드 피드백의 형식을 바꾼다

In-app browser 자체는 이미 Codex의 중요한 축이었습니다. OpenAI Developers 문서는 in-app browser를 Codex와 사용자가 thread 안에서 rendered web page를 함께 보는 shared view라고 설명합니다. 로컬 개발 서버, file-backed preview, 로그인 없는 public page가 주요 대상입니다. 로그인 상태, browser extension, 기존 tab, cookie가 필요한 작업은 regular browser나 Codex Chrome extension을 쓰라는 제한도 분명히 적혀 있습니다.

이번 릴리스 노트는 in-app browser annotations와 browser-use improvements를 함께 언급합니다. Enterprise/Edu 릴리스 노트는 browser-use 개선으로 advanced annotation mode, faster asset extraction, read-only JavaScript context, tab grouping usability, Chrome extension tab clutter 감소, reliability 개선을 나열합니다. ChatGPT 릴리스 노트도 더 정밀한 styling feedback을 위해 in-app browser annotations를 강조합니다.

프론트엔드 개발에서 이 변화는 꽤 현실적입니다. “모바일에서 세 번째 카드의 가격 badge가 너무 아래에 있다”는 피드백은 텍스트로 전달하기 어렵습니다. 스크린샷에 화살표를 그려도 코드와 연결하려면 다시 설명이 필요합니다. In-app browser comment는 시각 피드백을 thread 안에서 바로 남기고, Codex가 그 위치와 상태를 참고해 수정하도록 만듭니다. 코딩 에이전트가 diff만 보는 것이 아니라 rendered result를 작업 루프의 일부로 삼는 방식입니다.

여기서 중요한 점은 browser가 완전한 production browser가 아니라는 점입니다. OpenAI 문서는 in-app browser가 authentication flows, signed-in pages, regular browser profile, cookies, extensions, existing tabs를 지원하지 않는다고 못박습니다. 즉 local preview나 공개 페이지 검증에는 좋지만, 실제 계정 상태가 필요한 결제 flow, admin console, SaaS dashboard는 Chrome extension이나 computer use가 필요합니다. 이 경계는 보안상 중요합니다. 에이전트가 어디까지 볼 수 있고 어디부터 별도 승인이 필요한지 분명해야 하기 때문입니다.

Locked computer use, 가장 강한 기능은 가장 좁아야 한다

이번 업데이트에서 가장 논쟁적인 기능은 locked computer use입니다. OpenAI의 Computer Use 문서는 computer use가 Codex에게 macOS GUI를 보고 조작하게 하는 기능이라고 설명합니다. Screen Recording과 Accessibility 권한이 필요하고, 사용자가 허용한 앱에서 클릭, 입력, 메뉴 이동, clipboard interaction 같은 작업을 할 수 있습니다. CLI나 structured integration으로는 확인하기 어려운 desktop app, iOS simulator flow, browser flow, 설정 변경, GUI-only bug 재현이 대표적인 사용처입니다.

Locked computer use는 여기서 한 단계 더 나갑니다. 사용자가 Mac을 잠근 뒤에도, 연결된 기기에서 시작한 Codex 작업이 desktop app을 계속 써야 할 때 활성화할 수 있습니다. OpenAI 문서는 이 기능이 Apple authorization plug-in을 설치해 macOS unlock flow에 참여한다고 설명합니다. 다만 일반적인 remote unlock 경로는 아닙니다. 활성 상태의 trusted computer use turn에 대해 짧은 window에서만 허용되고, 다른 앱이나 local process가 컴퓨터를 unlock하는 기능도 아닙니다.

보호 장치도 구체적으로 적혀 있습니다. Codex는 화면을 임시로 unlock하는 동안 모든 display를 덮고, local keyboard나 pointer input을 감지하면 Mac을 다시 잠그고 사용자가 직접 unlock할 때까지 자동 unlock을 중단합니다. 자동 unlock은 active computer use turn에만 가능하고, authorization window는 짧게 제한됩니다. 기능 자체가 강하기 때문에, OpenAI도 “좁게 설계됐다”는 점을 문서에서 반복합니다.

Codex Computer Use가 macOS 앱을 조작하기 전 사용자 승인을 요청하는 공식 OpenAI Developers 예시입니다.

MacRumors는 이 업데이트를 “Codex가 잠긴 Mac에서도 앱을 사용할 수 있다”는 사용자 관점의 변화로 소개했습니다. 기사에 따르면 OpenAI Developers의 X 게시물은 사용자가 phone에서 Codex 작업을 보내고, Mac 화면이 꺼져 있거나 잠겨 있어도 Codex가 앱을 사용할 수 있다고 설명했습니다. 이 문장은 강한 인상을 줍니다. 하지만 실제 제품 경계는 더 복잡합니다. Computer Use plugin 설치, Screen Recording 및 Accessibility 권한, app별 승인, 지역 제한, admin policy, 민감 작업 승인 같은 조건이 모두 붙습니다.

Enterprise/Edu 릴리스 노트에서 특히 볼 대목은 관리자가 remote_computer_use = false 정책으로 이 기능을 끌 수 있다는 점입니다. 개인 사용자에게 locked use는 “집 밖에서도 작업을 이어가게 해주는 기능”처럼 보입니다. 조직에게는 다릅니다. 회사 Mac이 잠긴 뒤에도 에이전트가 GUI를 조작할 수 있다면, 보안팀은 어떤 앱을 허용할지, 어떤 지역에서 가능할지, 어떤 작업은 금지할지, 로그와 승인 기록을 어떻게 볼지 정해야 합니다.

코딩 에이전트의 관리 표면이 넓어진다

이번 릴리스 노트에서 비교적 덜 주목받았지만 중요한 항목은 Enterprise admin analytics입니다. OpenAI는 global admin console에 Codex analytics가 들어가며 active users, credits and tokens, threads and turns, user leaderboards, plugin usage, accepted lines of code, model usage, console-aligned UI를 제공한다고 설명합니다. 이것은 Codex가 더 이상 개인 생산성 도구로만 머물지 않는다는 신호입니다.

팀이 코딩 에이전트를 본격적으로 쓰기 시작하면 관리자는 세 가지를 봐야 합니다. 첫째, 비용입니다. Goal mode와 장시간 작업은 token과 credit 사용량을 키울 수 있습니다. Reddit의 r/codex에도 Goal mode 사용 중 토큰 소모가 커졌다는 사용자 반응이 올라왔습니다. 개별 사례만으로 일반화할 수는 없지만, 장시간 에이전트 작업이 비용 관리 문제와 연결된다는 신호로는 충분합니다.

둘째, 권한입니다. Appshots는 화면과 텍스트를 Codex에 보냅니다. In-app browser는 page content를 untrusted context로 취급해야 합니다. Computer Use는 사용자의 signed-in browser나 desktop app 상태와 만날 수 있습니다. Locked use는 잠긴 화면 이후의 자동화까지 다룹니다. 각각의 기능은 유용하지만, 승인 prompt, allow list, region constraint, admin policy가 없으면 조직에서 쓰기 어렵습니다.

셋째, 품질입니다. accepted lines of code 같은 지표는 유혹적이지만 충분하지 않습니다. 에이전트가 만든 코드가 실제로 build를 통과했는지, test를 추가했는지, rollback이 쉬운지, 보안 검토를 거쳤는지 함께 봐야 합니다. Goal mode가 긴 작업을 잘 이어갈수록 review 단위도 커집니다. 관리 지표는 “얼마나 많이 썼나”보다 “어떤 위험과 어떤 산출물이 생겼나”를 설명해야 합니다.

기능	해결하는 병목	새로 생기는 통제 질문
Appshots	앱 화면, 에러, 디자인 상태를 긴 설명 없이 전달합니다.	민감 화면과 off-screen text가 thread context에 들어가도 되는지 정해야 합니다.
Goal mode	긴 리팩터링, 성능 개선, 반복 수정의 완료 기준을 유지합니다.	목표가 검증 가능하지 않으면 비용과 변경 범위가 쉽게 커집니다.
In-app browser	렌더링된 웹 UI를 보고 주석 기반으로 수정할 수 있습니다.	로그인 없는 preview와 signed-in browser 작업의 경계를 분리해야 합니다.
Locked computer use	원격 기기에서 시작한 GUI 작업을 Mac 잠금 이후에도 이어갑니다.	앱 허용 목록, 지역 제한, 승인 로그, admin disable 정책이 필요합니다.

경쟁은 IDE 기능보다 작업 운영으로 간다

이번 업데이트는 Codex만의 단독 사건으로 보기 어렵습니다. Anthropic의 Claude Code, Google Antigravity, Cursor, GitHub Copilot coding agent는 모두 “코드를 제안한다”보다 “작업을 맡긴다”는 방향으로 움직입니다. 차이는 어느 표면을 더 강하게 잡느냐입니다. 어떤 도구는 IDE 안에서 강하고, 어떤 도구는 cloud task와 PR review에 강하며, 어떤 도구는 terminal-first workflow에 맞습니다. Codex는 이번 업데이트로 Mac app, browser preview, mobile remote access, Goal mode, Enterprise analytics를 하나의 흐름으로 묶으려 합니다.

이 전략의 장점은 분명합니다. 개발자는 작업 도중 다른 앱을 보여주고, 목표를 걸고, 브라우저에서 결과를 확인하고, 자리를 비운 뒤 phone으로 승인할 수 있습니다. 특히 프론트엔드, 디자인 시스템, internal tool, QA 자동화, GUI 버그 재현에는 유용합니다. 코드만 바꾸는 것이 아니라 “보이는 결과까지 확인하는 에이전트”가 되기 때문입니다.

반대로 위험도 같은 지점에서 나옵니다. 에이전트가 화면을 보고 앱을 누를 수 있으면, 사용자는 더 많은 권한을 맡깁니다. signed-in browser를 조작하면 웹사이트는 그 행동을 사용자 계정의 행동으로 볼 수 있습니다. Appshots로 공유한 화면에는 민감한 고객 정보나 내부 문서가 있을 수 있습니다. Goal mode가 오래 달리면 작은 오해가 큰 diff로 커질 수 있습니다. 편의와 통제가 같이 커지는 구조입니다.

그래서 이 업데이트의 핵심은 “Codex가 잠긴 Mac도 만진다”는 자극적인 한 문장이 아닙니다. 더 정확히는 “코딩 에이전트가 계속 일하려면 어떤 권한 모델이 필요한가”라는 질문입니다. OpenAI는 기능을 넓히면서도 문서 곳곳에 제한을 적어두었습니다. In-app browser는 로그인 없는 page에 적합합니다. Computer Use는 app별 허용이 필요합니다. Locked use는 일반 remote unlock이 아닙니다. Enterprise 관리자는 정책으로 기능을 끌 수 있습니다.

개발팀은 어떻게 받아들여야 하나

실무 팀이 이번 업데이트에서 당장 배울 점은 기능 사용법보다 작업 설계입니다. Goal mode를 쓴다면 목표를 testable하게 써야 합니다. “리팩터링해줘”가 아니라 “이 모듈을 새 API로 옮기고 기존 test suite와 pnpm build가 통과해야 한다”처럼 완료 조건을 적어야 합니다. 긴 작업은 처음부터 review checkpoint를 넣고, 에이전트가 만든 diff를 작은 단위로 끊어야 합니다.

Appshots와 Computer Use를 쓴다면 화면 공유 정책을 세워야 합니다. 고객 데이터, 결제 화면, admin 권한, production console, credential manager처럼 민감한 앱은 기본적으로 닫아두는 것이 좋습니다. OpenAI 문서도 sensitive apps는 필요한 경우가 아니면 닫아두고, account, security, privacy, network, payment, credential 관련 설정에서는 사용자가 present해야 한다고 권고합니다.

브라우저 검증은 더 적극적으로 써볼 만합니다. 로컬 개발 서버나 공개 preview는 Codex in-app browser에 잘 맞습니다. 특히 layout overflow, hover state, chart label, mobile breakpoint처럼 test만으로 잡기 어려운 문제는 browser comment와 screenshot verification이 좋은 보조 수단이 됩니다. 다만 로그인, extension, cookie, 기존 browser profile이 필요한 흐름은 in-app browser의 범위를 벗어나므로 Chrome extension이나 Computer Use로 분리해야 합니다.

관리자라면 Codex analytics를 비용 통제용 dashboard로만 보지 않는 편이 낫습니다. active users와 tokens는 시작점입니다. 더 중요한 것은 어떤 plugin이 사용되는지, 어떤 모델이 비용을 끌어올리는지, 어느 팀이 accepted lines of code를 많이 만들지만 review failure도 많은지, locked computer use 같은 고권한 기능이 어디서 켜져 있는지입니다. 에이전트 관리의 목적은 사용량을 줄이는 것이 아니라 위험한 자동화를 보이게 만드는 데 있습니다.

작은 릴리스 노트가 가리키는 큰 방향

OpenAI의 5월 21일 Codex 업데이트는 대형 모델 발표처럼 화려하지 않습니다. 새 benchmark 숫자도 없고, “몇 배 더 똑똑해졌다”는 메시지도 중심이 아닙니다. 대신 실제 개발자가 에이전트를 오래 쓰다 보면 부딪히는 문제를 제품 표면으로 끌어냈습니다. 맥락을 어떻게 줄 것인가. 목표를 어떻게 유지할 것인가. 화면을 어떻게 확인할 것인가. 사용자가 자리를 비운 뒤에도 작업을 어디까지 이어갈 것인가. 조직은 이 모든 것을 어떻게 통제할 것인가.

이 질문들은 앞으로 코딩 에이전트 시장을 가를 가능성이 큽니다. 모델 성능은 계속 좋아지겠지만, 팀이 실제로 도입하는 순간에는 권한, context, review, observability, cost, rollback이 더 크게 보입니다. Codex의 Appshots와 Goal mode는 developer experience 기능입니다. Locked computer use와 Enterprise analytics는 governance 기능입니다. 이번 업데이트가 의미 있는 이유는 이 둘이 같은 릴리스 묶음에 들어왔다는 점입니다.

코딩 에이전트는 이제 “autocomplete의 다음 단계”라는 설명만으로는 부족합니다. 더 정확히는 사람의 개발 환경 일부를 임시로 빌려 쓰는 작업자에 가까워지고 있습니다. 작업자가 되려면 목표가 있어야 하고, 화면을 봐야 하며, 필요한 순간 권한을 받아야 하고, 조직은 그 행동을 추적할 수 있어야 합니다. 잠긴 Mac에서도 일한다는 말은 그래서 기술 과시라기보다 경계 설정의 시작에 가깝습니다. Codex의 새 경계는 편의의 경계이면서 동시에 통제의 경계입니다.