바이브코딩 2026.05.26

잠긴 맥에서도 AI가 일한다: 사람이 자리를 비운 뒤에도 이어지는 작업

핵심 요약

퇴근길 지하철에서 휴대폰으로 “방금 만든 Mac 앱의 로그인 버그를 다시 재현하고 고쳐줘”라고 Codex에 맡긴다고 해보자. 책상 위 Mac은 잠겨 있고, 화면도 꺼져 있다. 예전이라면 여기서 작업은 멈췄다. 이제는 조건이 맞으면 Codex가 잠긴 Mac의 승인된 앱을 잠시 열어 GUI 흐름을 확인하고, 사용자는 휴대폰에서 승인 요청과 결과를 이어서 볼 수 있다.

OpenAI는 2026년 5월 21일 ChatGPT 릴리즈 노트에서 Codex 업데이트를 공개하며 Locked computer use를 추가했다고 밝혔다. 공식 설명에 따르면 이 기능은 eligible Mac Computer Use 사용자에게 제공되며, Mac이 잠긴 뒤에도 Codex가 원격으로 안전하게 계속 작업할 수 있게 한다. 단, 기존 Computer Use 지역 제한을 따른다. 같은 업데이트에는 Appshots, Goal mode, 브라우저 주석 개선도 함께 들어갔다. 출처: OpenAI Help Center 릴리즈 노트.

이 글의 핵심은 “AI가 내 잠긴 컴퓨터를 마음대로 쓴다”는 공포가 아니다. 더 정확히는 화면 잠금 이후에도 AI 작업을 계속 허용할 만큼 업무 자동화가 깊어졌고, 이제 사용자는 비밀번호보다 더 세밀한 질문을 해야 한다는 뜻이다. 어떤 앱은 항상 허용할 것인가. 브라우저에 로그인된 페이지를 Codex가 클릭해도 되는가. 결제, 계정, 개인정보, 회사 고객 데이터가 보이는 화면은 어떻게 막을 것인가. 이 질문에 답하지 못하면 기능을 켜지 않는 편이 낫다.

Codex Computer Use가 Mac 앱 사용 허가를 요청하는 공식 화면

이미지 출처: OpenAI Developers, Codex Computer Use 문서

쉽게 말해 무엇이 바뀌었나

Codex는 원래 코드 파일을 읽고, 수정하고, 테스트를 돌리는 코딩 에이전트에 가까웠다. 터미널과 파일 시스템 중심 작업에서는 강하지만, 사람이 보는 앱 화면을 직접 확인해야 하는 일에는 한계가 있었다. 예를 들어 Mac 앱의 설정 화면, iOS 시뮬레이터, 브라우저 안의 결제 흐름, 디자인 미리보기 창에서만 재현되는 버그는 파일만 읽어서는 판단하기 어렵다.

Computer Use는 이 빈틈을 메운다. OpenAI Developers 문서는 Codex 앱의 Computer Use가 macOS에서 데스크톱 앱을 보고 조작할 수 있게 한다고 설명한다. 사용자는 Computer Use 플러그인을 설치하고, macOS의 Screen Recording과 Accessibility 권한을 부여해야 한다. Screen Recording은 Codex가 대상 앱을 보게 하는 권한이고, Accessibility는 클릭, 입력, 탐색을 가능하게 하는 권한이다. 출처: OpenAI Developers, Computer Use.

Locked computer use는 여기에 “Mac이 잠긴 뒤에도”라는 조건을 더한다. 사용자가 기능을 켠 뒤, 연결된 기기에서 Computer Use 작업을 시작하면 Codex가 잠긴 Mac의 승인된 앱을 제한적으로 사용할 수 있다. OpenAI 문서에 따르면 이때 Codex는 Apple authorization plug-in을 설치해 macOS 잠금 해제 흐름에 참여한다. 하지만 이것은 일반적인 원격 잠금 해제 기능이 아니며, 다른 앱이나 로컬 프로세스가 컴퓨터를 잠금 해제할 수 있게 만드는 통로도 아니다.

이 차이가 중요하다. 사용자는 “내 Mac이 완전히 열린다”고 이해하기보다 “Codex의 활성 Computer Use 작업 한 턴을 위해 짧고 제한된 해제 창이 열린다”고 이해하는 편이 맞다. OpenAI는 잠긴 상태에서 앱에 접근할 때 Codex가 활성화된 신뢰 작업인지 확인하고, 그 짧은 창 밖에서는 자동 해제를 거부하며 수동 잠금 해제를 요구한다고 설명한다.

실제 업무에서는 어디에 쓸 수 있나

가장 현실적인 장면은 개발자와 제품팀의 야간 작업이다. 낮에 만든 기능이 있는데, 오류가 파일 수준 테스트에서는 잡히지 않고 앱 화면에서만 나타난다. Codex에게 “이 흐름을 앱에서 직접 재현하고, 원인을 찾고, 최소 수정 후 같은 흐름을 다시 확인해”라고 맡길 수 있다. Mac이 켜져 있고 Codex 앱이 실행 중이며 원격 연결이 살아 있다면, 사용자는 다른 장소에서도 후속 질문과 승인 요청을 처리할 수 있다.

두 번째 장면은 프론트엔드와 디자인 검수다. 버튼이 모바일 폭에서 잘리는지, 브라우저에서 특정 폼이 실제로 제출되는지, 로컬 앱의 설정 패널이 바뀌었는지 같은 문제는 화면을 봐야 한다. Codex가 브라우저나 앱을 열고 확인하면, 사용자는 “테스트 통과”라는 말만 듣는 대신 스크린샷, 터미널 출력, 변경 diff를 함께 볼 수 있다. 원격 연결 문서도 휴대폰에서 프롬프트를 보내고, 승인하고, 결과와 스크린샷을 검토할 수 있다고 설명한다. 출처: OpenAI Developers, Remote connections.

세 번째 장면은 직장인 생산성 자동화다. 개발자가 아니어도 “사내 웹앱의 설정을 확인해줘”, “데스크톱 앱에서 특정 옵션이 어디 있는지 찾아줘”, “브라우저에 열린 관리자 페이지에서 오류 메시지를 캡처해줘” 같은 작업을 떠올릴 수 있다. 다만 여기서부터는 위험이 커진다. 회사 계정, 고객 정보, 결제 페이지, 인사 자료, 보안 설정이 보이는 화면이라면 AI가 볼 수 있는 정보의 범위가 갑자기 넓어진다.

따라서 이 기능은 “밤새 AI에게 컴퓨터를 맡기는 기능”이라기보다 “사람이 정한 좁은 범위 안에서 GUI 확인을 이어가는 기능”에 가깝다. 잘 쓰면 퇴근 후에도 테스트와 재현 작업이 진행된다. 이 변화는 Codex가 코딩 도구를 넘어 ChatGPT, Codex, API를 단일 에이전틱 플랫폼으로 묶으려는 OpenAI 전략과도 맞닿아 있다. 잘못 쓰면 브라우저에 로그인된 계정과 데스크톱 앱 권한이 섞여, 어느 버튼을 누가 눌렀는지 설명하기 어려워진다.

켜기 전에 알아야 할 조건

첫째, 지금 기준으로 Computer Use는 Codex 앱의 macOS 기능이다. OpenAI Developers 문서는 출시 시점에 유럽경제지역, 영국, 스위스를 제외한 macOS에서 사용할 수 있다고 설명한다. Windows의 모바일 설정 지원은 별도 문서에서 아직 지원되지 않는다고 되어 있고, 향후 지원 예정으로 안내된다. 한국 사용자는 지역 제한 대상이 아니라면 macOS Codex 앱, ChatGPT 계정, 최신 모바일 앱 조합을 먼저 확인해야 한다.

둘째, Mac은 깨어 있고 온라인이어야 한다. Remote connections 문서는 Mac이 잠자기 상태에 들어가거나 네트워크를 잃거나 Codex가 종료되면 원격 접근이 멈춘다고 설명한다. 노트북이라면 전원 연결이 필요하고, 덮개를 닫은 상태에서는 외부 디스플레이가 필요할 수 있다. 장시간 작업을 맡길 계획이라면 “내가 쓰던 노트북”보다 항상 켜져 있는 Mac mini나 별도 개발용 Mac이 더 현실적이다.

셋째, 권한은 두 층으로 나뉜다. macOS 권한은 Codex가 화면을 보고 조작할 수 있게 하는 시스템 권한이다. Codex 내부 앱 승인은 어떤 앱을 사용하게 둘지 정하는 권한이다. OpenAI는 Computer Use에서 Codex가 사용자가 허용한 앱 안에서만 보고 행동할 수 있고, 새로운 앱을 쓰기 전에는 허가를 요청한다고 설명한다. 사용자는 Always allow를 선택할 수 있지만, 이는 앞으로도 해당 앱을 자동 허용한다는 뜻이므로 특히 조심해야 한다.

넷째, 파일 수정과 셸 명령은 별도 승인 체계를 계속 따른다. Computer Use가 켜졌다고 해서 파일, 명령어, 네트워크 접근 규칙이 사라지는 것은 아니다. OpenAI 문서는 파일 읽기, 파일 편집, 셸 명령이 여전히 스레드의 sandbox와 approval 설정을 따른다고 밝힌다. 반대로 말하면, 데스크톱 앱 안에서 저장된 변경은 프로젝트 리뷰 화면에 바로 보이지 않을 수 있다. 앱을 통해 파일이 저장되고 추적 대상이 되어야 diff에서 확인된다.

Codex 원격 연결에서 이 Mac을 제어할 수 있는 기기를 관리하는 공식 화면

이미지 출처: OpenAI Developers, Remote connections 문서

가장 중요한 보안 질문은 “잠금”이 아니다

Mac 잠금 화면은 보통 “사람이 물리적으로 못 들어오게 막는 장치”다. 하지만 Codex의 Locked computer use에서 더 중요한 경계는 물리적 잠금보다 앱 권한, 세션 권한, 로그다. 화면은 잠겨 있어도 Codex가 승인된 작업을 수행할 수 있다면, 보안 기준도 “컴퓨터가 잠겼는가”에서 “어떤 작업이 어떤 앱에서 승인됐는가”로 옮겨가야 한다.

OpenAI 문서는 이 기능이 일부 안전장치를 포함한다고 설명한다. 자동 해제 창은 현재 unlock attempt에 맞춰 짧게 열리고, 활성 Computer Use 턴에서만 Codex가 사용할 수 있다. 데스크톱이 일시적으로 열리는 동안에는 모든 디스플레이를 가리고, 로컬 키보드나 포인터 입력을 감지하면 Mac을 다시 잠그고 수동 해제가 필요하도록 멈춘다. 이 설명은 꽤 구체적이다. 하지만 구체적인 안전장치가 있다는 말과 모든 사용 사례가 안전하다는 말은 다르다.

가장 큰 위험은 Codex가 “보는 것”이다. OpenAI 문서는 Computer Use가 화면 콘텐츠, 스크린샷, 창, 메뉴, 키보드 입력, 클립보드 상태를 다룰 수 있다고 안내한다. 대상 앱에 열린 파일, 브라우저 페이지, 보이는 고객 정보는 작업 중 Codex가 처리하는 맥락이 될 수 있다. 특히 브라우저에서는 로그인된 사이트가 사용자의 계정 행동으로 승인된 클릭, 양식 제출, 페이지 조작을 받아들일 수 있다. 사용자는 이를 “내가 직접 하는 행동처럼 검토하라”는 OpenAI의 주의를 가볍게 넘기면 안 된다.

또 하나의 위험은 Always allow다. 계산기나 로컬 미리보기 앱처럼 위험이 낮은 앱에는 편할 수 있다. 하지만 브라우저, 이메일, 비밀번호 관리자, 회사 관리자 콘솔, 결제 화면, 클라우드 콘솔 같은 앱에 자동 허용을 걸면 사고 범위가 커진다. “이번 한 번만 허용”과 “앞으로 자동 허용”의 차이를 팀 규칙으로 정해두지 않으면, 편의성이 보안 정책을 앞질러 간다.

개인 사용자라면 이렇게 판단하자

개인 Mac에서 이 기능을 켤지는 세 가지 질문으로 판단하면 된다.

먼저, Codex가 봐도 되는 전용 작업 공간이 있는가. 개인 브라우저 프로필에 메일, 은행, 쇼핑, 회사 계정이 모두 로그인돼 있다면 위험하다. Codex용 브라우저 프로필이나 별도 브라우저를 만들어 로그인 범위를 줄이는 편이 낫다. OpenAI도 사용자가 브라우저를 계속 쓰고 싶다면 Codex에게 다른 브라우저를 쓰게 하라고 안내한다.

다음으로, 작업이 충분히 좁은가. “내 Mac에서 앱을 좀 봐줘”는 나쁜 요청이다. “Chrome에서 로컬 개발 서버의 checkout 페이지를 열고, 테스트 계정으로 배송지 입력 후 결제 직전까지만 이동해. 실제 결제 버튼은 누르지 마”처럼 앱, 계정, 금지 행동, 종료 조건을 명확히 해야 한다. Codex가 잘못된 창을 만지기 시작하면 즉시 취소할 수 있어야 한다.

마지막으로, 내가 바로 개입할 수 있는가. Locked computer use는 자리를 비우기 위한 기능처럼 보이지만, 계정, 보안, 개인정보, 네트워크, 결제, 자격증명 설정은 사용자가 현장에 있거나 적어도 휴대폰으로 승인 흐름을 볼 수 있을 때만 맡기는 편이 안전하다. OpenAI 문서도 secrets가 필요한 작업은 사용자가 승인할 수 있을 때만 진행하라고 안내한다.

회사라면 개인 설정으로 끝내면 안 된다

팀에서 이 기능을 쓰려면 “누가 켰는가”보다 “어떤 정책으로 켰는가”가 중요하다. OpenAI가 별도 글 Running Codex safely at OpenAI에서 강조하는 것도 이 지점이다. OpenAI는 내부 Codex 운영에서 네트워크 정책, 자격증명 보관, 규칙 기반 승인, 관리형 설정, 감사 로그를 함께 다룬다고 설명한다. 특히 Codex 활동에는 사용자 프롬프트, 도구 승인 결정, 도구 실행 결과, MCP 서버 사용, 네트워크 프록시 허용 또는 차단 이벤트 같은 로그를 남길 수 있다고 밝힌다. 기업 도입 관점에서는 Codex를 사내 서버로 가져오는 온프레미스 시나리오처럼 기기, 네트워크, 감사 로그를 한 세트로 설계하는 흐름과도 이어진다.

회사 관점에서 Locked computer use는 “개발자 편의 기능”이 아니라 새로운 운영 표면이다. 야간에 Codex가 브라우저와 데스크톱 앱을 열 수 있다면, 보안팀은 최소한 다음 기준을 정해야 한다. 최근 GitHub 내부 repo 유출 사건이 보여준 VS Code 확장 보안 문제처럼, 개발자 도구 하나가 로컬 자격증명과 사내 코드 접근권을 동시에 만지는 구조에서는 편의 기능도 보안 경계로 다뤄야 한다.

  • 자동 허용 가능한 앱과 금지 앱을 분리한다.
  • 브라우저는 Codex 전용 프로필을 원칙으로 한다.
  • 고객 데이터, 결제, 관리자 콘솔, 비밀번호 관리자, 사내 메신저는 기본 금지로 둔다.
  • 장시간 작업은 개인 노트북보다 전용 always-on Mac 또는 관리형 devbox에서 돌린다.
  • 원격 연결 기기 목록과 접근 해지 절차를 정기적으로 점검한다.
  • 승인 로그, 작업 결과, 스크린샷, diff, 터미널 출력이 감사 가능한 위치에 남도록 한다.

이 기준이 없으면 팀은 “AI가 똑똑해졌다”는 말만 믿고 운영 책임을 개인 개발자에게 떠넘기게 된다. 반대로 기준이 있으면 Codex는 야간 재현, UI 테스트, 반복 검수처럼 사람 시간을 많이 잡아먹는 일을 꽤 실용적으로 줄여준다.

지금 써도 될까

개인 개발자나 소규모 팀이 로컬 앱, 테스트 계정, 별도 브라우저 프로필, 제한된 앱 권한으로 쓰는 경우라면 지금 실험해볼 만하다. 특히 GUI에서만 재현되는 버그, 로컬 웹앱 확인, 디자인 미리보기, 시뮬레이터 흐름처럼 “사람이 화면을 보고 반복해야 했던 작업”에는 가치가 있다.

반대로 회사 계정이 복잡하게 얽힌 Mac, 고객 데이터가 보이는 브라우저, 결제·인사·보안 설정이 열린 환경이라면 기다리는 편이 낫다. 먼저 전용 기기, 테스트 계정, 앱 허용 목록, 로그 보관, 승인 절차를 만들어야 한다. 이 준비 없이 Always allow를 누르는 것은 편의 기능 사용이 아니라 운영 리스크를 여는 결정이다.

이번 업데이트의 진짜 의미는 잠긴 Mac을 AI가 “뚫었다”가 아니다. 개발 환경이 이제 파일과 터미널을 넘어 실제 화면, 로그인된 앱, 원격 휴대폰 승인까지 이어졌다는 점이다. 그래서 Codex의 다음 경쟁력은 모델 성능만이 아니라, 사용자가 믿고 맡길 수 있는 권한 설계와 감사 가능성에 달려 있다. AI에게 일을 맡기는 시대에는 “무엇을 시킬 것인가”만큼 “어디까지 허용할 것인가”가 제품 사용법의 일부가 된다.

사용 링크와 출처

AI 에이전트 Codex Computer Use Mac OpenAI 보안 원격 작업

공유

Threads X