PART 04-14. Computer Use - 데스크톱을 보고 클릭하는 에이전트

코드 밖으로 한 걸음 나가야 진짜 일이 끝난다

지금까지의 Codex는 아주 유능한 개발자 동료처럼 보였다. 파일을 읽고, 코드를 고치고, 테스트를 돌리고, PR까지 만든다. 그런데 실무에서는 이상하게도 일이 거기서 끝나지 않는다. 브라우저를 직접 열어 봐야 하고, iOS 시뮬레이터에서 버튼을 눌러 봐야 하고, 데스크톱 앱 설정을 바꿔 봐야 하고, 화면에만 나타나는 버그를 눈으로 확인해야 한다.

바로 그 틈을 메우는 기능이 Computer Use다. 이 기능을 켜면 Codex는 더 이상 코드만 읽는 에이전트가 아니다. 화면을 보고, 창을 고르고, 클릭하고, 입력하고, 실제 GUI를 따라가며 일을 확인하는 에이전트가 된다.¹

이 장의 핵심은 단순하다. 텍스트와 터미널만으로 충분한 일은 기존 Codex가 더 낫고, 일이 시각적인 순간부터는 Computer Use가 필요해진다. 이 경계를 이해하면 괜히 위험한 작업을 맡기지 않게 되고, 반대로 사람이 꼭 붙어 있지 않아도 되는 반복적인 GUI 작업은 과감히 넘길 수 있다.

Computer Use를 어떻게 이해해야 하나

Computer Use를 만능 리모컨처럼 생각하면 금방 실망한다. 더 정확한 비유는 이렇다. Codex에게 눈과 손을 잠깐 빌려주는 기능이다.

공식 문서 기준으로 Computer Use는 Codex 앱에서 플러그인 형태로 제공되며, 현재는 macOS에서 사용할 수 있다. 사용하려면 먼저 플러그인을 설치하고, macOS가 요청할 때 Screen Recording과 Accessibility 권한을 허용해야 한다.¹ Screen Recording은 화면을 보게 해 주고, Accessibility는 클릭·입력·창 이동을 가능하게 한다.³

중요한 점은 이것이 단순한 "원격 제어"가 아니라는 사실이다. Codex는 화면 상태를 보고 다음 행동을 추론한다. 즉, 셀레니움처럼 미리 짜 둔 좌표를 반복하는 것이 아니라, 현재 보이는 화면을 바탕으로 다음 클릭을 결정한다.⁴ 그래서 UI가 예상과 조금 달라도 버틸 때가 있고, 반대로 버튼이 너무 작거나 모달이 이상하게 뜨면 헷갈릴 때도 있다.

어디에 쓰면 빛나고, 어디에 쓰면 손해인가

Computer Use가 빛나는 순간은 "코드는 맞는 것 같은데, 화면에서 확인해야만 알 수 있는 문제"를 다룰 때다.

즉, Computer Use는 "아무 데나 붙이는 기능"이 아니라 마지막 한 칸이다. 예를 들어 Next.js + Supabase 프로젝트에서 회원가입 버그를 잡는다고 해 보자. 에러 로그와 소스만으로 원인이 보이면 굳이 GUI를 만질 필요가 없다. 하지만 브라우저에서만 특정 토스트가 안 뜨거나, 리다이렉트가 한 박자 늦거나, 소셜 로그인 팝업 이후 화면이 이상해진다면 그때는 Computer Use가 맞다.

반대로 GitHub 이슈를 읽거나 Slack 메시지를 가져오는 일은 플러그인이나 MCP가 훨씬 낫다. 화면을 보고 클릭하는 방식은 사람 눈에는 쉬워 보여도, 기계에게는 늘 애매하다. 구조화된 API가 있으면 그쪽이 거의 언제나 더 정확하다.²

할 수 있는 일과 못 하는 일을 먼저 구분하자

Computer Use를 잘 쓰는 사람은 "가능한 일"보다 "안 되는 일"을 먼저 안다. 이 제한을 알아야 위험한 기대를 하지 않는다.

공식 문서와 정리 자료를 기준으로, Computer Use는 다음과 같은 GUI 작업에 적합하다.¹³

• 브라우저에서 실제 화면을 열고 흐름을 따라가기

• 데스크톱 앱 설정을 클릭으로 바꾸기

• iOS 시뮬레이터 같은 GUI 환경에서 플로우 재현하기

• 플러그인이나 MCP가 없는 도구의 화면 정보 확인하기

• 화면에서만 재현되는 버그를 스크린샷 기반으로 디버깅하기

반대로 아래 작업은 할 수 없거나, 해서는 안 된다.³

• 터미널 앱 자동화

• Codex 자체 조작

• macOS 보안·개인정보 권한 팝업 승인

• 관리자 권한 인증 대행

이 제한은 불편해 보여도 사실 안전장치다. 터미널까지 자동화해 버리면 기존 샌드박스와 승인 정책을 우회할 여지가 커진다. Codex가 Codex 자신을 조작할 수 있게 두면 승인 절차가 무너진다. 그리고 관리자 인증이나 시스템 권한 승인까지 맡겨 버리면, 이제부터는 "도와주는 도구"가 아니라 "사람 대신 결정을 내려 버리는 주체"가 된다. OpenAI가 그 선을 일부러 막아 둔 이유가 여기에 있다.³

macOS에서 켜는 방법

설정 자체는 복잡하지 않다. 다만 권한의 의미를 알고 켜는 편이 좋다.

먼저 Codex 앱 설정에서 Computer Use 항목으로 들어가 플러그인을 설치한다. 그다음 macOS가 묻는 두 권한을 허용한다. Screen Recording은 화면을 보게 하는 권한이고, Accessibility는 클릭과 입력을 가능하게 하는 권한이다.¹

여기서 하나 기억할 점이 있다. macOS 시스템 권한과 Codex 내부 앱 승인은 별개다.³ 다시 말해, 운영체제 차원에서 "볼 수 있고 조작할 수 있다"를 허용했다고 해서, Codex가 곧바로 모든 앱을 자동으로 만지는 것은 아니다. 실제로 특정 앱을 쓰려 하면 Codex가 다시 승인을 요청한다. 이때 한 번만 허용할 수도 있고, 앞으로 계속 허용할 수도 있다.³

이 분리가 매우 중요하다. 노트북 전체를 한 번에 넘기는 느낌이 아니라, "이 앱에 한해서 지금 이 작업만"이라는 감각으로 운영할 수 있기 때문이다.

첫 작업은 반드시 좁게 시작하라

Computer Use를 처음 켤 때 많은 사람이 이렇게 말하고 싶어진다.

"내 컴퓨터를 보고 알아서 문제를 해결해 줘."

이건 거의 실패하는 프롬프트다. 화면 기반 작업은 범위를 좁힐수록 성공률이 오른다. 실전에서는 다음 다섯 가지를 같이 주는 편이 좋다.²

• 어떤 앱을 쓸지

• 어떤 화면이나 흐름을 볼지

• 무엇을 하지 말아야 하는지

• 성공 조건이 무엇인지

• 사람이 언제 개입할지

예를 들어 좋은 프롬프트는 이런 식이다.

@Chrome에서 http://localhost:3000/signup 을 열어.
테스트 계정으로 회원가입 흐름을 재현해.
첫 번째 실패 지점을 찾고, 실패 화면을 설명해.
코드 수정이 필요하면 가장 작은 수정만 적용하고,
같은 흐름을 한 번 더 실행해 통과 여부를 보고해.
실제 결제나 외부 계정 연동은 건드리지 마.

이 프롬프트가 좋은 이유는 멋있어서가 아니다. 앱 하나, 흐름 하나, 성공 조건 하나다. Computer Use는 추상적인 목표보다 좁은 작업에 훨씬 강하다.²

In-app browser와 무엇이 다른가

웹 작업이라고 전부 Computer Use가 필요한 것은 아니다. 오히려 로컬 웹앱을 확인할 때는 in-app browser부터 쓰는 것이 공식 권장 경로다.²

이유는 간단하다. in-app browser는 더 통제된 환경이다. 로컬에서 띄운 웹앱을 확인하고, 렌더링 결과를 보고, UI를 빠르게 점검하는 데 적합하다. 반면 Computer Use로 실제 브라우저를 만지기 시작하면, 이미 로그인된 세션, 확장 프로그램, 기존 탭, 개인 쿠키 같은 현실의 복잡함이 그대로 따라온다.⁴

둘의 차이는 이렇게 이해하면 쉽다.

실무 팁을 하나만 뽑자면 이렇다. 프런트엔드 이터레이션은 in-app browser부터, 실제 사용자 환경 재현은 Computer Use로 간다. 예를 들어 Next.js 관리자 페이지 레이아웃 깨짐을 볼 때는 in-app browser가 편하다. 하지만 네이버 소셜 로그인처럼 실제 브라우저 세션과 팝업 흐름이 얽히면 Computer Use가 필요해진다.

스크린샷 기반 디버깅이 왜 강력한가

개발자가 종종 잊는 사실이 하나 있다. 버그는 코드에만 있지 않다. 버그는 눈에 보이는 증상으로 발견되는 경우가 아주 많다.

예를 들어 이런 상황을 생각해 보자.

Next.js + Supabase 앱에서 회원가입 버튼을 누르면 서버 로그는 멀쩡하다. 테스트도 통과한다. 그런데 실제 브라우저에서는 로딩 스피너가 영원히 도는 것처럼 보인다. 이런 문제는 로그만 읽어서는 놓치기 쉽다. 하지만 Computer Use는 화면을 보고 "버튼이 비활성화된 채로 남아 있다", "에러 토스트가 화면 아래 접혀 있다", "리다이렉트가 일어나지 않았다" 같은 시각적 단서를 직접 확인할 수 있다.²

이때 좋은 디버깅 루프는 대개 다음 순서로 흘러간다.

1. 문제 흐름을 재현하게 한다.

2. 첫 실패 화면을 설명하게 한다.

3. 필요하면 스크린샷 맥락으로 코드 수정 후보를 찾게 한다.

4. 수정 후 같은 흐름을 다시 실행하게 한다.

5. 무엇이 실패했고 무엇이 바뀌었는지 짧게 요약하게 한다.

이 루프가 좋은 이유는 사람이 중간에 긴 설명을 다시 붙이지 않아도 되기 때문이다. 예전에는 "내가 브라우저에서 보니 버튼이 회색으로 남아 있고…"를 사람이 옮겨 적어야 했다. 이제는 Codex가 직접 보고 그 맥락을 유지한다. 바로 이 지점에서 Computer Use가 '코딩 도구'에서 '작업 에이전트'로 넘어간다.

실제로 잘 먹히는 디버깅 예시

예시 1. Next.js + Supabase 회원가입 버그

가장 대표적인 흐름이다. 목표는 http://localhost:3000/signup에서 회원가입 플로우를 재현하고, 첫 실패 화면을 찾는 것이다.

여기서는 먼저 in-app browser로 충분한지 본다. 단순한 로컬 폼 검증이나 레이아웃 확인이면 in-app browser가 더 안전하다.² 하지만 실제 브라우저 세션, 팝업, 매직 링크 흐름까지 얽히면 Computer Use가 낫다.

좋은 지시는 대략 이런 느낌이다.

@Chrome에서 localhost:3000/signup 을 열어.
테스트 메일 주소로 가입을 시도하고,
첫 실패 지점을 찾으면 화면 상태를 설명해.
원인이 프런트엔드 상태 관리인지, auth 응답 처리인지 추정해.
수정 후에는 같은 플로우를 한 번 더 반복해 통과 여부를 보고해.

이렇게 하면 Codex는 코드와 화면을 오가며 일할 수 있다. 사람은 결과 보고와 diff를 검토하면 된다.

예시 2. 슈퍼앱 클론의 결제 직전 화면 QA

쇼핑, 송금, 쿠폰, 멤버십이 한 화면에 얽힌 슈퍼앱 클론에서는 "렌더는 되는데 실제 사용감이 이상한 문제"가 자주 나온다. 탭 전환이 어색하거나, 모달 계층이 잘못되어 클릭이 안 먹거나, 모바일 뷰에서 버튼이 가려지는 식이다.

이 경우 Computer Use에게 Safari나 Chrome으로 스테이징 화면을 열게 하고, 특정 흐름만 좁게 검사하게 하면 좋다. 예를 들면 "장바구니 → 쿠폰 적용 → 결제 직전 확인 화면"까지만 보게 하는 식이다. 다만 실제 결제 버튼 누르기, 카드 정보 입력, 포인트 차감 같은 민감 단계는 반드시 사람이 붙어 있어야 한다.³

예시 3. macOS 앱 또는 시뮬레이터 흐름 확인

iOS 시뮬레이터는 터미널 로그보다 화면이 더 많은 것을 말해 준다. 화면 전환이 꼬이거나, 특정 시트가 가려지거나, 권한 팝업 뒤로 포커스가 날아가면 로그는 조용한데 앱은 멈춘 것처럼 보인다. 이런 경우 Computer Use는 실제 시뮬레이터를 따라가며 첫 이상 지점을 찾아내는 데 유용하다.³⁴

여러 에이전트가 동시에 돌아가도 괜찮은 이유

Computer Use 이야기를 처음 들으면 많은 사람이 걱정한다.

"그럼 내가 코딩하는 동안 마우스가 갑자기 움직이는 건가요?"

흥미롭게도 Codex의 Computer Use는 이런 불편을 줄이도록 설계되어 있다. macOS에서 에이전트는 사용자 커서와 분리된 배경 실행 맥락에서 앱을 조작할 수 있고, 여러 에이전트를 병렬로 돌리면서도 사용자는 다른 앱에서 계속 작업할 수 있다는 점이 큰 특징으로 소개된다.⁴

이 특성 덕분에 이런 조합이 가능해진다.

• 한 에이전트는 Safari에서 스테이징 QA를 수행한다.

• 다른 에이전트는 Xcode 시뮬레이터에서 온보딩 플로우를 본다.

• 사람은 그동안 VS Code에서 다른 작업을 한다.

다만 규칙이 하나 있다. 같은 앱에 대해 두 개의 Computer Use 작업을 동시에 걸지 말 것이다. 같은 Chrome 창을 두 에이전트가 번갈아 만지기 시작하면, 사람 둘이 같은 마우스를 동시에 잡는 것과 비슷한 혼란이 생긴다.⁴

권한 스코프는 기술보다 운영의 문제다

Computer Use를 안전하게 쓰는 핵심은 "모델을 얼마나 믿느냐"가 아니다. 권한을 얼마나 잘 좁히느냐다.

가장 먼저 구분해야 할 것은 세 층이다.

이 셋은 서로 대체하지 않는다.³ 예를 들어 Chrome을 Computer Use로 허용했다고 해서, 파일 시스템 바깥까지 마음대로 수정하는 권한이 생기는 것은 아니다. 반대로 workspace-write 샌드박스를 걸어 두었다고 해서, 브라우저 안에서 이미 로그인된 운영 콘솔 클릭 위험이 없어지는 것도 아니다. GUI 조작의 위험은 파일 샌드박스 바깥에도 존재한다.⁴

그래서 운영 원칙이 필요하다.

첫째, Always allow는 정말 자주 쓰는 안전한 앱에만 준다. Finder, Safari, Chrome, Figma 같은 앱도 업무 맥락에 따라 위험도가 다르다. Chrome이 안전한 게 아니라, "로그인 안 된 테스트용 브라우저"가 상대적으로 안전한 것이다.

둘째, 민감 흐름에서는 사람이 자리를 지킨다. 계정 설정, 보안, 결제, 개인정보, 운영 콘솔, 비밀번호 관리자처럼 잘못 클릭했을 때 되돌리기 어려운 화면에서는 무조건 사람이 붙어 있어야 한다.³

셋째, 필요 없는 앱은 미리 닫는다. Computer Use가 보는 화면은 작업 중 문맥으로 들어갈 수 있다. 열려 있는 브라우저 탭, 데스크톱 앱, 화면에 노출된 문서도 모두 맥락이 될 수 있다고 생각하는 편이 안전하다.³

넷째, 브라우저는 가능하면 분리한다. 평소 업무용 브라우저에 운영 계정, 개인 메일, 결제 수단이 다 로그인돼 있다면 거기는 사람이 쓰고, Codex에는 별도 브라우저를 지정하는 습관이 좋다. 공식 문서도 브라우저가 이미 로그인된 상태라면 그 세션을 그대로 사용할 수 있음을 분명히 경고한다.³

브라우저를 맡길 때 특히 조심해야 하는 이유

Computer Use의 위험은 파일 삭제보다 계정 행위에서 더 크게 튀어나올 때가 많다. 브라우저는 이미 로그인된 상태일 가능성이 높고, 웹페이지는 사람도 속이는데 모델도 속일 수 있다.

예를 들어 운영 중인 Supabase 콘솔, AWS 콘솔, PG 관리 화면, 결제 대시보드가 열린 브라우저를 그대로 Codex에게 맡기면, 그 순간부터 에이전트는 사실상 당신의 로그인 세션으로 움직이게 된다.⁴ 악의적인 페이지가 아니더라도, 비슷하게 생긴 버튼이나 애매한 확인 모달 때문에 의도치 않은 액션이 나올 수 있다.

그래서 브라우저 작업에는 두 가지 규칙이 거의 필수다.

• 인증이 필요 없는 로컬 페이지면 in-app browser를 먼저 쓴다.²

• 실제 브라우저가 필요하면 테스트 계정, 스테이징 환경, 별도 프로필을 우선 쓴다.

실무적으로 말하면, 프로덕션 관리자 콘솔보다 staging-admin.example.com이 훨씬 좋은 친구다.

"보이지만 리뷰에 안 보이는" 순간을 이해하자

Computer Use로 어떤 앱을 조작하다 보면, 사람 눈에는 분명 뭔가 바뀌었는데 Codex 리뷰 패널에는 바로 안 보일 때가 있다. 이유는 단순하다. 데스크톱 앱에서의 변경은 실제로 디스크에 저장되고 프로젝트가 추적해야 비로소 일반 리뷰 흐름에 잡히기 때문이다.³

예를 들어 GUI에서 설정 파일 값을 바꿨다고 해도, 그 앱이 저장 버튼을 누르기 전까지는 파일 변경이 생기지 않을 수 있다. 혹은 앱 내부 DB에만 저장되고 Git 추적 파일에는 반영되지 않을 수도 있다. 그래서 Computer Use를 쓸 때는 "화면에서 바뀌었다"와 "프로젝트 변경으로 남았다"를 구분해야 한다.

이 차이를 이해하면 보고도 더 좋아진다. 좋은 작업 종료 조건은 보통 이렇게 쓴다.

"화면상 수정 확인 후, 디스크에 저장됐는지 확인하고, 프로젝트 변경으로 추적되는 파일이 있으면 그 diff까지 요약해."

이 한 줄이 있으면 GUI 작업이 '봤다'에서 끝나지 않고 '남았다'까지 이어진다.

안전한 운영을 위한 실전 체크리스트

Computer Use는 기능보다 습관이 더 중요하다. 아래 기준으로 운영하면 사고 확률이 눈에 띄게 줄어든다.³

• 작업마다 목표 앱을 하나로 좁힌다.

• 한 번에 하나의 흐름만 맡긴다.

• 계정, 보안, 결제 관련 단계에서는 항상 사람이 대기한다.

• 민감한 앱과 문서는 미리 닫는다.

• 브라우저는 테스트용 프로필 또는 별도 브라우저를 우선 사용한다.

• Always allow는 최소화한다.

• 에이전트가 엉뚱한 창으로 가면 바로 중단한다.

이 체크리스트를 보면 별것 아닌 것처럼 보이지만, 실제로 사고는 거의 항상 "대충 넓게 맡겼을 때" 난다. Computer Use는 똑똑한 신입처럼 다루는 편이 맞다. 일을 꽤 잘하지만, 권한과 범위를 추상적으로 주면 이상한 자신감을 보일 때가 있다.

Windows 사용자는 무엇을 알아야 하나

이 책의 독자 중에는 Windows + WSL 조합이 메인인 개발자도 많다. 여기서 중요한 현실 하나를 분명히 해 두자. 현재 공개 문서 기준으로 Computer Use는 macOS 중심 기능이다.¹ Codex 앱 자체는 Windows에서도 제공되지만, macOS의 Computer Use와 같은 네이티브 데스크톱 조작은 동일하게 공개되지 않았다.²

즉, Windows 사용자는 지금 당장 이런 식으로 생각하는 편이 현실적이다.

• 코드 작업, Git, PowerShell, WSL, CLI 중심이면 Windows Codex도 충분히 강하다.

• 로컬 웹앱 확인은 브라우저 기능이나 in-app browser 성격의 도구를 우선 활용한다.

• 진짜 데스크톱 GUI 조작이 핵심이면, 현재는 macOS Computer Use가 앞서 있다.¹⁰

이 차이는 나중의 비교 챕터에서 더 정직하게 다루겠지만, 지금 단계에서는 "내 메인 머신에서 당장 가능한 범위"를 냉정하게 보는 것이 중요하다.

Computer Use를 잘 쓰는 사람의 사고방식

결국 차이는 프롬프트 기술보다 작업 분해 능력에서 난다. Computer Use를 잘 쓰는 사람은 작업을 이렇게 자른다.

"어떤 앱에서, 어떤 흐름을, 어디까지, 무엇을 건드리지 않고, 어떤 조건이면 성공인지."

이 다섯 가지가 분명하면 Computer Use는 놀랄 만큼 유용하다. 반대로 "보이는 대로 알아서 다 해줘"에 가까워질수록 불안하고 느리고 위험해진다.

이 장을 한 문장으로 요약하면 이렇다.

Computer Use는 키보드와 마우스를 넘기는 기능이 아니라, GUI가 필요한 마지막 한 구간만 Codex에게 위임하는 기능이다.

코드 작성은 이미 잘한다. 이제 화면 확인까지 맡길 수 있다. 그 순간 Codex는 단순한 코딩 도구를 넘어, 당신 대신 실제 작업을 끝까지 밀어 주는 에이전트에 가까워진다.

참고

¹Computer Use - Codex app | OpenAI Developers

²How to Use Codex Computer Use: A Practical Guide for Setup, Testing, and UI Work

³Codex App Computer Use | 桌面应用操作、权限与审批

⁴Codex App Computer Use: Background GUI Automation on macOS Without Surrendering Your Desktop

¹⁰Feature request: Full Computer Use support for Codex Desktop on Windows · Issue #19305 · openai/codex · GitHub