잠긴 맥에서도 계속 일한다, Codex가 겨냥한 장기 작업

AI 요약

• 무슨 일: OpenAI가 5월 21일 Codex에 Appshots, Goal mode, 브라우저 주석, locked computer use를 묶어 추가했습니다.
  • 공식 릴리스 노트는 더 풍부한 컨텍스트, 장기 작업, 브라우저 개선, 원격 잠금 후 사용을 한 업데이트로 설명합니다.
• 의미: 코딩 에이전트 경쟁의 중심이 모델 답변에서 화면, 목표, 브라우저, 로컬 권한을 묶는 작업 런타임으로 이동합니다.
• 주의점: 화면 캡처와 locked use는 편의 기능인 동시에 민감한 앱 상태와 승인 경계를 넓히는 기능입니다.
  • OpenAI 문서도 컴퓨터 사용 작업은 좁게 유지하고, 권한 프롬프트와 민감한 흐름을 직접 검토하라고 안내합니다.

OpenAI가 2026년 5월 21일 ChatGPT 릴리스 노트에서 Codex 업데이트를 한꺼번에 공개했습니다. 표면적으로는 Appshots, Goal mode, in-app browser annotations, locked computer use, browser use improvements 같은 기능 목록입니다. 하지만 이 묶음을 단순한 편의 기능으로 보면 중요한 흐름을 놓칩니다. Codex는 이제 "코드를 고쳐 주는 모델"에서 "사용자의 작업 상태를 계속 받아들이고, 목표를 들고 오래 달리며, 브라우저와 데스크톱 앱을 검증 표면으로 쓰는 로컬 에이전트 런타임"으로 이동하고 있습니다.

이번 업데이트가 흥미로운 이유는 새 모델 이름이나 benchmark가 앞에 나오지 않는다는 점입니다. OpenAI의 공식 릴리스 노트 제목도 성능 향상이 아니라 "richer context, goal mode, browser improvements, and remote locked use"입니다. 더 많은 컨텍스트, 더 긴 목표, 더 나은 브라우저, 잠긴 상태에서의 원격 사용입니다. AI 코딩 도구가 실제 개발자의 하루 안으로 들어갈수록 병목은 모델이 다음 줄을 얼마나 잘 맞히느냐만이 아닙니다. 사용자가 지금 보고 있는 오류를 어떻게 전달할지, 에이전트가 언제 멈춰야 하는지, 렌더링된 화면을 어떻게 검증할지, 사용자가 자리를 비운 뒤에도 어떤 권한으로 계속 일하게 할지가 더 중요해집니다.

이번 글은 Codex 기능을 사용법으로 풀지 않습니다. 뉴스의 핵심은 제품 사용 팁보다 방향성입니다. 코딩 에이전트 시장은 빠르게 "모델 호출"에서 "작업 표면"으로 옮겨가고 있습니다. OpenAI는 그 표면을 ChatGPT, Codex 앱, CLI, IDE extension, 모바일 원격 연결, 브라우저, Computer Use까지 넓히고 있습니다. 5월 21일 업데이트는 이 흐름이 더 이상 실험적 부가 기능이 아니라 Codex의 기본 경쟁축이 되고 있음을 보여줍니다.

무엇이 바뀌었나

공식 릴리스 노트에서 OpenAI는 Codex가 작업 컨텍스트를 이해하고 긴 작업을 계속 진행할 수 있는 방법이 늘어났다고 설명합니다. 첫 번째는 Appshots입니다. macOS Codex 앱에서 전면 앱 창을 Codex thread에 보낼 수 있습니다. 스크린샷뿐 아니라 해당 앱이 제공하는 접근 가능한 텍스트도 함께 들어갈 수 있습니다. 기본 동작은 양쪽 Command 키를 누르거나 사용자가 설정한 단축키를 누르는 방식입니다. 사용자가 방금 보던 에러 창, 디자인 도구, 문서, 설정 화면을 길게 설명하는 대신 하나의 첨부 컨텍스트로 넘기는 기능입니다.

두 번째는 Goal mode 일반 제공입니다. Codex 앱, IDE extension, CLI에서 /goal로 쓸 수 있습니다. Goal mode에서 목표 텍스트는 시작 프롬프트이면서 완료 기준입니다. Codex는 그 목표를 기준으로 다음 행동을 고르고, 작업이 끝났는지 판단합니다. 문서의 예시는 JavaScript 코드베이스를 TypeScript strict mode로 옮기거나, 홈페이지 time to interactive를 1초 미만으로 줄이는 식입니다. 핵심은 "한 번 답하고 끝나는 프롬프트"가 아니라 "완료 조건을 가진 장기 작업"입니다.

세 번째는 in-app browser와 browser use 개선입니다. Codex의 in-app browser는 사용자와 Codex가 같은 렌더링 페이지를 보고, 사용자가 시각적 코멘트를 남기며, Codex가 그 코멘트를 코드 수정으로 이어갈 수 있게 하는 표면입니다. 공식 문서는 로컬 개발 서버, 파일 기반 미리보기, 로그인 없는 공개 페이지에 적합하다고 설명합니다. Browser use는 여기서 한 단계 더 나아가 Codex가 직접 클릭, 입력, 스크린샷, asset extraction, read-only JavaScript inspection으로 화면 상태를 확인하게 합니다.

네 번째는 locked computer use입니다. 이 기능은 이름만 보면 위험하게 들립니다. 실제로도 조심해서 읽어야 합니다. OpenAI 문서는 이 기능이 일반적인 원격 잠금 해제 경로가 아니며, 사용자가 명시적으로 켜야 하고, active trusted computer use turn에 한정된 짧은 승인 창에서만 작동한다고 설명합니다. Codex가 잠긴 Mac 뒤에서 Computer Use 작업을 이어갈 수 있지만, 로컬 입력이 감지되면 다시 잠그고, 화면을 가리며, 관리자 인증이나 보안 권한 프롬프트를 승인할 수 없습니다. 즉 "사용자가 잠든 Mac을 마음대로 조작하는 기능"이 아니라, 원격으로 연결된 Codex 작업이 잠금 상태를 만나도 좁은 조건에서 계속 진행되도록 만든 권한 장치입니다.

프롬프트의 문제가 아니라 컨텍스트 전달의 문제

Appshots가 중요한 이유는 스크린샷 첨부가 편해졌기 때문만은 아닙니다. AI 코딩 에이전트를 실제로 써 보면 많은 실패는 모델이 코드를 전혀 모르는 데서 오지 않습니다. 사용자가 보고 있는 상태가 프롬프트에 제대로 들어가지 않았기 때문에 생깁니다. "버튼이 이상해요"라는 문장보다 실제 버튼이 어떤 화면 폭에서, 어떤 주변 요소와 겹치며, 어떤 색과 간격으로 보이는지가 더 중요합니다. 터미널 에러도 마찬가지입니다. 로그 한 줄만 복사하면 앞뒤 상태가 빠지고, 전체 로그를 붙이면 노이즈가 너무 많습니다.

Appshots는 이 간극을 줄이려는 기능입니다. 공식 문서에 따르면 전면 창의 이미지와 사용 가능한 텍스트가 함께 캡처될 수 있고, 추가된 appshot은 수동 첨부 파일처럼 Codex attachment로 동작합니다. 예시는 API reference page를 공유하고 스크립트를 쓰게 하거나, 이메일이나 캘린더 화면을 공유하고 다음 단계를 초안화하게 하거나, 이미지 편집기와 preview window를 보여 주고 관련 asset이나 코드를 수정하게 하는 식입니다.

이 방향은 최근 AI 개발 도구의 큰 흐름과 맞닿아 있습니다. Figma MCP는 디자인 표면을 에이전트 도구로 바꾸려 하고, Chrome DevTools for agents는 브라우저 런타임을 에이전트가 관측하게 만듭니다. GitHub Copilot과 Cursor도 에디터 상태, PR, 터미널 로그, background agent 상태를 더 많이 제품 안에 들입니다. Codex Appshots는 그중에서도 로컬 Mac 앱 전체를 "설명 가능한 작업 컨텍스트"로 바꾸는 시도입니다.

다만 컨텍스트가 늘어난다는 것은 노출면도 늘어난다는 뜻입니다. 공식 문서도 appshot이 캡처된 이미지와 접근 가능한 텍스트를 Codex와 공유한다고 분명히 말합니다. Google Docs, Gmail, Google Sheets, Google Slides 같은 일부 앱이나 웹사이트에서는 보이는 스크린샷만 들어가고 전체 문서 텍스트는 들어가지 않을 수 있다고도 적습니다. 개발팀이 이 기능을 표준 워크플로에 넣는다면 "어떤 앱 화면을 캡처해도 되는가"가 새로운 운영 규칙이 됩니다. 코드 에이전트에게 보여 주는 화면은 곧 프롬프트이자 데이터 입력입니다.

/goal은 자동화의 완료 조건을 제품 표면으로 올린다

Goal mode는 더 직접적으로 에이전트의 장기 작업 문제를 다룹니다. 일반적인 코딩 프롬프트는 한 번의 요청입니다. "이 버그를 고쳐줘", "테스트를 추가해줘", "이 컴포넌트를 반응형으로 만들어줘"처럼 시작하지만, 실제 작업은 여러 단계로 갈라집니다. 파일을 읽고, 계획을 세우고, 코드를 고치고, 테스트를 돌리고, 실패하면 원인을 찾고, 다시 수정합니다. 사용자는 중간에 설명을 요구하거나 방향을 바꾸기도 합니다. 여기서 에이전트가 무엇을 완료로 볼지가 흔들리면 작업은 길어질수록 취약해집니다.

OpenAI 문서는 Goal mode를 "persistent objective"라고 설명합니다. 목표가 여러 단계에 걸쳐 유지되고, Codex가 그 목표를 기준으로 진행 상태를 판단합니다. Codex 앱에서는 composer 위에 진행 상태와 pause, resume, edit, clear controls가 나타납니다. 목표가 분명하면 장점이 큽니다. "strict mode에서 explicit any 없이 compile되어야 한다"처럼 검증 가능한 기준을 주면 에이전트는 단순히 코드를 바꾸는 데서 멈추지 않고 성공 조건을 향해 반복할 수 있습니다.

하지만 여기에는 반대편 위험도 있습니다. 완료 조건을 잘못 쓰면 에이전트가 잘못된 목표를 성실하게 추적합니다. "성능을 개선해줘" 같은 모호한 목표는 어떤 metric으로 성공을 판단해야 하는지 불분명합니다. "테스트가 통과해야 한다"만 쓰면 사용자 경험이나 보안 경계가 뒤로 밀릴 수 있습니다. Goal mode가 일반 제공된다는 것은 사용자가 더 자주 장기 작업을 맡길 수 있다는 뜻이지만, 동시에 목표 작성 능력이 제품 사용 능력의 일부가 된다는 뜻입니다.

이 지점에서 Codex와 Claude Code, Cursor, GitHub Copilot coding agent, Google Antigravity의 경쟁이 닮아갑니다. 모두 모델 성능을 말하지만, 실제 제품은 계획, 실행, 검증, 리뷰, 승인, 중단, 재개를 어떻게 다룰지로 갈라집니다. 코딩 에이전트가 "조금 더 좋은 자동완성"이라면 goal은 필요 없습니다. 코딩 에이전트가 몇십 분 동안 repository를 읽고 test suite를 돌리며 여러 파일을 바꾸는 동료가 되려면 goal과 완료 조건은 핵심 UI가 됩니다.

브라우저가 검증 장치가 되는 순간

이번 업데이트에서 브라우저 관련 변화도 작지 않습니다. OpenAI 문서는 in-app browser를 사용자가 Codex와 같은 렌더링 페이지를 보며 visual comments를 남기는 공간으로 설명합니다. 브라우저 안에서 annotation mode를 켜고 특정 요소나 영역을 선택해 코멘트를 남길 수 있습니다. styling feedback은 더 세밀해져서 font, text, spacing, color 같은 값을 미리보기와 함께 전달할 수 있습니다.

프론트엔드 작업에서 이것은 단순한 UI 편의가 아닙니다. 코딩 에이전트의 약한 고리 중 하나는 "코드상으로 그럴듯하지만 화면상으로 틀린 결과"입니다. 테스트가 통과해도 버튼 텍스트가 넘치거나, tooltip이 데이터를 가리거나, 모바일 화면에서 카드 높이가 밀릴 수 있습니다. 사람은 스크린샷을 보고 바로 알아차리지만, 에이전트는 파일만 읽으면 그 상태를 놓치기 쉽습니다. In-app browser annotation은 사용자가 눈으로 본 문제를 구체적 작업 지시로 바꾸는 장치입니다.

Browser use는 그 다음 단계입니다. Codex가 로컬 개발 서버나 파일 미리보기, 공개 페이지를 직접 열고 클릭하고 입력하고 화면을 검사할 수 있습니다. 문서는 인증 흐름, signed-in pages, regular browser profile, cookies, extensions, existing tabs는 지원하지 않는다고 선을 긋습니다. 또한 페이지 컨텐츠를 untrusted context로 취급하고, 브라우저 흐름에 secrets를 붙여 넣지 말라고 경고합니다. 이 제한은 중요합니다. AI 브라우저 에이전트는 프롬프트 인젝션, 악성 페이지, 로그인 상태 오용의 위험을 같이 가져오기 때문입니다.

개발팀 관점에서는 이 기능이 테스트 전략과 맞물립니다. Playwright, Storybook, visual regression, Lighthouse 같은 기존 검증 도구가 이미 있다면 Codex의 브라우저 사용은 그 위에 얹히는 사람이 읽을 수 있는 검증 루프가 됩니다. 반대로 프로젝트에 시각 테스트가 거의 없다면 에이전트가 브라우저를 열어도 기준이 모호합니다. "이 페이지가 맞다"를 에이전트가 판단하려면 route, state, expected layout, forbidden behavior가 있어야 합니다. 결국 브라우저 에이전트도 테스트 문화가 약한 팀에서는 마법이 아니라 또 다른 불확실성이 됩니다.

잠긴 Mac 뒤의 에이전트, 편의와 권한의 교차점

Locked computer use는 이번 묶음에서 가장 민감한 기능입니다. Codex가 Mac 잠금 뒤에도 Computer Use 작업을 이어갈 수 있다는 설명은 개발자에게 매우 매력적입니다. 모바일에서 작업을 감독하다가 노트북이 잠겼을 때, 에이전트가 GUI 앱을 조금 더 확인해야 하는 상황은 충분히 생길 수 있습니다. 특히 로컬에서만 재현되는 데스크톱 앱 버그, iOS simulator, 사내 VPN 뒤의 브라우저 흐름, 디자인 도구 확인 같은 작업은 CLI만으로 끝나지 않습니다.

OpenAI 문서는 이 기능의 제한을 꽤 구체적으로 적습니다. 사용자가 Codex settings의 Computer Use에서 locked computer use를 켜야 하고, Apple authorization plug-in이 macOS unlock flow에 참여합니다. Codex가 잠긴 뒤 앱에 접근할 때는 일시적으로 Mac을 unlock하지만, local use를 막고 locked screen protections를 유지한다고 설명합니다. unlock 전에는 active trusted computer use turn인지 확인하고, 그 짧은 창 밖에서는 자동 unlock을 거부합니다. 디스플레이를 가리고, 로컬 키보드나 포인터 입력이 감지되면 다시 잠그고 자동 unlock을 중단합니다.

이 설계는 OpenAI가 위험을 알고 있다는 신호입니다. 하지만 위험을 없애지는 않습니다. Computer Use는 화면 내용, 스크린샷, 창, 메뉴, 키보드 입력, clipboard state를 다룰 수 있습니다. 사용자가 허용한 앱 안에서는 실제 계정 상태로 클릭과 입력이 일어날 수 있습니다. 공식 문서도 웹사이트는 승인된 클릭이나 form submission을 사용자의 계정에서 온 행동으로 취급할 수 있다고 경고합니다. 따라서 locked use는 "편리하니 켜 두자"가 아니라 "어떤 작업에만 켤 것인가"로 접근해야 합니다.

기업 개발 환경에서는 이 질문이 더 복잡해집니다. 개인 Mac에 사내 Slack, 이메일, 관리자 콘솔, 클라우드 대시보드, 고객 데이터가 함께 열려 있다면 에이전트의 작업 범위를 앱별로 좁혀야 합니다. OpenAI 문서는 민감한 앱을 닫고, 권한 프롬프트를 검토하고, 계정·보안·개인정보·네트워크·결제·자격 증명 관련 설정에서는 사용자가 직접 있어야 한다고 안내합니다. 실제 운영 규칙도 그 정도로 구체적이어야 합니다. "Codex 사용 가능"이 아니라 "이 앱, 이 route, 이 테스트 계정, 이 시간 동안만 가능"이어야 합니다.

경쟁은 모델보다 작업 경계로 간다

이번 Codex 업데이트는 OpenAI만의 이야기가 아닙니다. Google Antigravity 2.0은 AI Studio, Android, Firebase, Google Cloud를 잇는 agent command center에 가깝게 움직입니다. GitHub Copilot은 원격 제어, 모델 라우팅, 사용량 기반 과금, cloud agent를 묶고 있습니다. Anthropic Claude Code는 goal, plugins, MCP, 컴퓨트 한도, managed agent 방향으로 확장합니다. Cursor는 IDE와 cloud/background agent를 함께 밀고 있습니다.

이 경쟁에서 모델 성능은 여전히 중요합니다. 하지만 사용자가 체감하는 차이는 점점 runtime에서 나옵니다. 에이전트가 어느 화면을 볼 수 있는가. 어느 브라우저에서 검증할 수 있는가. 로컬 파일과 클라우드 작업을 어떻게 이어 붙이는가. 사용자가 자리를 비운 동안 어떤 승인을 요구하는가. 실패했을 때 어떤 로그와 diff를 남기는가. 토큰 비용과 컴퓨트 한도는 어디서 보이는가. 이런 질문이 실제 제품 선택의 기준이 됩니다.

Codex가 Appshots와 Goal mode, in-app browser, locked use를 함께 밀어 넣은 이유도 여기에 있습니다. 장기 작업을 맡기려면 목표가 필요합니다. 목표를 오래 유지하려면 컨텍스트가 필요합니다. 프론트엔드와 GUI 작업을 맡기려면 시각 검증이 필요합니다. 원격으로 계속 감독하려면 잠금 상태와 권한 모델이 필요합니다. 각각은 작은 기능처럼 보이지만, 묶어서 보면 코딩 에이전트의 작업 경계를 다시 그리는 부품입니다.

한국 개발팀에게 이 뉴스는 "Codex 새 기능이 나왔다"보다 조금 더 실용적인 질문을 던집니다. 우리 팀은 에이전트에게 어떤 화면을 보여 줄 수 있습니까. 장기 작업의 완료 조건을 테스트와 metric으로 쓸 준비가 되어 있습니까. 브라우저 검증을 맡길 route와 test state가 있습니까. 원격 또는 잠금 후 작업을 허용한다면 어떤 앱과 계정은 닫아야 합니까. 코딩 에이전트 도입은 더 이상 IDE 확장 설치로 끝나지 않습니다. 이제는 권한, 컨텍스트, 검증, 중단 조건을 설계하는 일입니다.

결론

OpenAI의 5월 21일 Codex 업데이트는 화려한 모델 발표가 아닙니다. 그래서 오히려 중요합니다. 코딩 에이전트가 실제 개발 업무로 들어가면 모델 이름보다 작업 환경을 어떻게 품는지가 더 자주 문제 됩니다. Appshots는 사용자가 보고 있는 화면을 컨텍스트로 바꿉니다. Goal mode는 장기 작업의 완료 조건을 제품 표면으로 올립니다. In-app browser와 annotation은 코드 변경을 렌더링된 결과와 연결합니다. Locked computer use는 원격 감독과 로컬 권한 경계 사이의 어려운 타협을 제품화합니다.

이 네 가지가 가리키는 방향은 같습니다. AI 코딩 도구는 점점 "대화형 도우미"가 아니라 "작업을 맡는 실행 환경"이 됩니다. 실행 환경이 되면 필요한 것은 더 강한 모델만이 아닙니다. 좋은 목표, 좁은 권한, 검증 가능한 화면, 안전한 원격 경계가 필요합니다. Codex의 이번 업데이트는 그 조건들이 이제 부가 기능이 아니라 코딩 에이전트 경쟁의 본체가 되고 있음을 보여줍니다.