Codex의 Computer use 사용법 3가지

Computer Use, Chrome, Browser는 언제 어떻게 써야 할까?

AI 에이전트가 코드를 짜는 시대는 이미 익숙해졌다.
그런데 이제 중요한 질문은 조금 달라졌다.

“AI가 코드를 쓰는 것을 넘어, 실제 컴퓨터 화면을 보고 조작할 수 있다면 무엇이 달라질까?”

OpenAI Codex에는 컴퓨터를 다루는 방식이 여러 가지 있다.
겉으로 보면 비슷해 보인다. 모두 웹사이트를 열 수 있고, 화면을 볼 수 있고, 사용자를 대신해 작업할 수 있다.

하지만 실제로는 목적이 다르다.

Codex가 컴퓨터를 사용하는 대표적인 방식은 크게 세 가지다.

1. Computer Use
2. Chrome Extension
3. In-app Browser

여기에 추가로 Appshots라는 기능이 있다.
Appshots는 Codex가 직접 조작하는 도구라기보다, 사용자가 보고 있는 화면을 Codex에게 “이거 봐” 하고 보여주는 방식에 가깝다.

이 글에서는 세 가지 방식의 차이와 실제 활용법을 정리해본다.

---

1. Computer Use: 가장 넓은 범위의 컴퓨터 조작

Computer Use는 세 가지 중 가장 넓은 조작 범위를 가진다.

Codex가 macOS나 Windows의 그래픽 인터페이스를 보고, 창을 열고, 메뉴를 누르고, 키보드 입력을 하고, 클립보드를 사용할 수 있게 해주는 방식이다.

쉽게 말하면 사용자가 허용한 앱 안에서 Codex가 사람처럼 컴퓨터를 조작하는 것이다.

예를 들어 이런 작업에 적합하다.

• Spotify 같은 데스크톱 앱 조작
• Xcode나 iOS 시뮬레이터 테스트
• iPhone Mirroring을 통한 모바일 앱 확인
• 시스템 설정 변경 확인
• API가 없는 금융 앱, 업무 앱, 내부 프로그램 사용
• 여러 앱을 오가야 하는 복합 워크플로우

Computer Use의 장점은 명확하다.
API나 플러그인이 없는 앱도 사용할 수 있다.

반대로 단점도 있다.
화면을 보고, 클릭하고, 반응을 기다리고, 다시 화면을 확인하는 방식이기 때문에 구조화된 API 호출보다 느리다.

예를 들어 GitHub 플러그인이 있다면 GitHub 웹사이트를 눈으로 보며 클릭하는 것보다 플러그인을 쓰는 편이 더 정확하고 검토하기 쉽다. Slack 스레드를 읽는 것도 마찬가지다. Slack 플러그인이 있다면 화면을 클릭하는 것보다 API 기반으로 가져오는 편이 낫다.

그래서 기본 원칙은 이렇다.

구조화된 도구가 있으면 먼저 그것을 쓰고, 화면 조작은 마지막 경계에서 쓴다.

Computer Use는 “사람만 할 수 있던 GUI 작업”에 강하다.
하지만 사용자의 컴퓨터를 넓게 다룰 수 있는 만큼 신뢰 경계도 넓다.

그래서 계정, 결제, 금융, 개인정보, 보안 설정과 관련된 작업은 사용자가 직접 확인하는 절차를 두는 것이 좋다.

---

2. Chrome Extension: 로그인된 브라우저 상태가 필요할 때

두 번째 방식은 Codex Chrome Extension이다.

이 방식은 사용자의 로그인된 Chrome 상태를 사용할 수 있다는 점이 핵심이다.
쿠키, 계정 세션, 브라우저 프로필, 열려 있는 탭 등이 필요한 작업에 적합하다.

예를 들어 이런 경우다.

• Gmail 확인
• LinkedIn 메시지 확인
• Salesforce나 고객지원 콘솔 사용
• 사내 대시보드 접근
• 로그인된 상태에서 여러 사이트를 오가며 리서치
• 브라우저 확장 프로그램이 필요한 폼 작성

Computer Use도 브라우저를 조작할 수는 있다.
하지만 Chrome Extension은 브라우저 작업을 더 자연스럽게 이해한다.

특히 여러 탭을 다루는 작업에 유리하다.
예를 들어 한 탭에는 고객 계정 페이지가 있고, 다른 탭에는 고객지원 티켓이 있고, 또 다른 탭에는 내부 문서가 열려 있다고 해보자.

이때 Chrome Extension은 같은 작업에 필요한 여러 탭을 묶어 비교하고, 필요한 정보를 찾아서 정리할 수 있다.

예시 프롬프트는 이런 식이다.

@Chrome을 사용해서 열린 고객 계정 페이지와 다른 탭의 지원 티켓을 비교하고, 누락된 필드를 초안으로 작성해줘. 제출은 하지 마.

여기서 중요한 부분은 마지막 문장이다.

“제출은 하지 마.”

Chrome Extension은 사용자의 로그인 상태로 동작한다.
즉, Codex가 클릭하는 버튼이나 작성하는 메시지는 웹사이트 입장에서는 사용자가 직접 한 행동처럼 보일 수 있다.

따라서 자동화의 경계를 명확히 해야 한다.

• 조사하기
• 비교하기
• 정리하기
• 초안 작성하기

여기까지는 자동화하기 좋다.

하지만 다음 작업은 사용자의 확인을 거치는 편이 안전하다.

• 보내기
• 게시하기
• 결제하기
• 제출하기
• 계정 설정 변경하기

Chrome Extension은 “로그인된 웹 업무”에 가장 적합한 표면이다.
작업 전체가 브라우저 안에서 끝난다면 Computer Use보다 Chrome을 먼저 고려하는 것이 좋다.

---

3. In-app Browser: 내가 만들고 있는 웹사이트를 테스트할 때

세 번째 방식은 In-app Browser다.

이것은 Codex 앱 안에 들어 있는 브라우저다.
사용자와 Codex가 같은 렌더링 화면을 보면서 작업할 수 있다.

가장 잘 맞는 용도는 웹 개발이다.

예를 들어 이런 작업이다.

• 로컬 개발 서버 확인
• Vite, Next.js, React 앱 테스트
• 로그인 없는 공개 페이지 확인
• 반응형 레이아웃 점검
• 시각적 버그 재현
• 특정 요소에 디자인 피드백 남기기

In-app Browser의 핵심 특징은 격리다.

일반 Chrome 프로필을 쓰지 않는다.
쿠키, 로그인 세션, 확장 프로그램, 기존 탭을 공유하지 않는다.

이것은 단점이기도 하고 장점이기도 하다.

로그인이 필요한 서비스에는 부적합하다.
Google 로그인, 패스키, 브라우저 확장 프로그램 의존성이 있는 페이지라면 Chrome Extension이 더 맞다.

하지만 개발 중인 웹앱을 테스트할 때는 오히려 좋다.
불필요한 계정 상태나 확장 프로그램의 영향을 덜 받기 때문이다.

예시 프롬프트는 이렇게 쓸 수 있다.

@Browser로 localhost:3000을 열고 모바일 화면에서 overflow 버그를 재현해줘. 수정한 뒤 데스크톱과 모바일 화면에서 다시 확인해줘.

이 방식의 장점은 피드백 루프가 짧다는 것이다.

Codex가 코드를 수정한다.
브라우저에서 결과를 본다.
스크린샷을 확인한다.
다시 코드를 고친다.
다시 렌더링을 확인한다.

이 과정을 한 스레드 안에서 반복할 수 있다.

특히 디자인 작업에서 유용하다.
텍스트로 “좀 더 깔끔하게 해줘”라고 말하는 것보다, 실제 화면의 특정 영역을 클릭하고 “여기 계층이 이상해”, “이 카드 느낌을 줄여줘”, “이 버튼 간격을 넓혀줘”라고 남기는 편이 훨씬 정확하다.

이때 화면 자체가 요구사항 문서가 된다.

---

Appshots: 조작 도구가 아니라 “가리키는 도구”

Appshots는 Computer Use, Chrome, Browser와 조금 다르다.

앞의 세 가지가 Codex가 무언가를 조작하는 방식이라면, Appshots는 사용자가 보고 있는 화면을 Codex에게 전달하는 방식이다.

Mac에서는 특정 단축키로 현재 앞에 있는 창을 캡처해 Codex 스레드에 첨부할 수 있다.
이미지와 가능한 텍스트 정보가 함께 전달된다.

예를 들어 이런 상황에서 유용하다.

• 에러 메시지를 보여줄 때
• 이메일 내용을 설명할 때
• 디자인 화면을 보여줄 때
• 설정 패널을 보여줄 때
• 익숙하지 않은 입력 폼을 분석시킬 때

정리하면 이렇게 볼 수 있다.

Appshots는 “이걸 봐”라고 가리키는 방식이고,
Browser, Chrome, Computer Use는 “이걸 처리해”라고 맡기는 방식이다.

Appshots는 특히 맥락 전달에 좋다.
전체 데스크톱을 열어주는 것이 아니라 현재 창 중심으로 보여줄 수 있기 때문에 비교적 좁은 범위의 컨텍스트를 전달할 수 있다.

---

세 가지 방식은 어떻게 구분하면 될까?

실무에서는 다음 기준으로 선택하면 된다.

1. API나 플러그인이 있으면 먼저 그것을 쓴다

가장 좋은 자동화는 화면 클릭이 아니라 구조화된 도구 호출이다.

Slack 메시지를 읽어야 한다면 Slack 플러그인이나 MCP가 더 낫다.
GitHub 작업을 해야 한다면 GitHub 플러그인이 더 낫다.

이유는 간단하다.

• 더 빠르다
• 더 정확하다
• 결과를 검토하기 쉽다
• 실패 지점을 파악하기 쉽다

화면 조작은 구조화된 도구가 닿지 않는 마지막 구간에서 쓰는 것이 좋다.

---

2. 데스크톱 앱이면 Computer Use

작업 대상이 브라우저 밖이라면 Computer Use가 맞다.

예를 들어 Spotify 앱을 열거나, Xcode를 조작하거나, iOS 시뮬레이터에서 버그를 재현해야 한다면 Computer Use를 쓰는 것이 자연스럽다.

다만 범위가 넓기 때문에 한 번에 너무 많은 권한을 주기보다, 하나의 앱 또는 하나의 흐름으로 좁혀서 맡기는 것이 좋다.

---

3. 로그인된 웹 업무면 Chrome

Gmail, LinkedIn, Salesforce, 사내 관리자 페이지처럼 로그인 상태가 필요한 웹 작업은 Chrome Extension이 적합하다.

특히 여러 탭을 비교해야 하는 업무라면 Chrome이 강하다.

하지만 로그인된 상태로 행동하는 만큼, 자동 제출이나 자동 전송은 주의해야 한다.

좋은 지시 방식은 다음과 같다.

조사하고, 비교하고, 초안까지 작성해줘.
하지만 보내기, 제출, 결제는 하지 마.

---

4. 웹앱 개발과 UI 디버깅은 In-app Browser

내가 만들고 있는 웹사이트를 열어보고, 버그를 재현하고, 레이아웃을 점검하고, 디자인 피드백을 반영해야 한다면 In-app Browser가 좋다.

특히 로컬 서버와 궁합이 좋다.

개발자는 “코드를 고치고 → 화면을 확인하고 → 다시 수정하는” 반복 작업을 많이 한다.
In-app Browser는 이 루프를 Codex 안으로 가져온다.

---

실무 프롬프트 예시

Computer Use 예시

@Computer를 사용해서 Spotify를 열고 Discover Weekly 플레이리스트를 찾아 재생해줘. 계정 설정이나 구독 설정은 변경하지 마.

Chrome 예시

@Chrome을 사용해서 열린 고객 계정 페이지와 지원 티켓을 비교해줘. 누락된 정보를 정리하고 입력 초안을 만들어줘. 제출은 하지 마.

In-app Browser 예시

@Browser로 localhost:3000을 열고 모바일 화면에서 레이아웃이 깨지는 부분을 찾아줘. 수정 후 모바일과 데스크톱 화면에서 다시 검증해줘.

Appshots 예시

이 에러 화면을 보고 원인을 분석해줘. 가능한 해결 순서를 알려줘.

---

핵심은 “가장 좁은 표면”을 선택하는 것

AI 에이전트에게 많은 권한을 주는 것이 항상 좋은 것은 아니다.

오히려 중요한 원칙은 반대다.

필요한 만큼만 보여주고, 필요한 만큼만 조작하게 한다.

브라우저 안에서 끝나는 일이라면 Computer Use까지 열 필요가 없다.
로그인이 필요 없는 개발 테스트라면 Chrome 프로필을 쓸 필요가 없다.
API로 가능한 일이라면 화면 클릭을 시킬 필요가 없다.

이 원칙을 지키면 자동화는 더 빠르고, 더 안전하고, 더 검토 가능해진다.

---

마무리: Codex는 코딩 도구를 넘어 작업 표면을 다루는 에이전트가 되고 있다

지금까지의 AI 코딩 도구는 주로 코드 편집기 안에서 일했다.
파일을 읽고, 코드를 고치고, 테스트를 실행하는 방식이었다.

하지만 Computer Use, Chrome Extension, In-app Browser가 결합되면 Codex의 역할은 달라진다.

이제 Codex는 코드만 보는 것이 아니라, 실제 앱 화면과 브라우저, 로컬 개발 서버, 로그인된 업무 도구까지 연결해 작업할 수 있다.

다만 중요한 것은 도구를 많이 쓰는 것이 아니다.

중요한 것은 상황에 맞는 표면을 고르는 것이다.

• 데스크톱 앱은 Computer Use
• 로그인된 웹 업무는 Chrome
• 웹앱 개발과 UI 디버깅은 In-app Browser
• 현재 보고 있는 화면을 전달할 때는 Appshots
• API나 플러그인이 있으면 먼저 구조화된 도구

이 구분만 명확히 해도 Codex를 훨씬 안정적으로 활용할 수 있다.

AI 에이전트 시대의 생산성은 단순히 “프롬프트를 잘 쓰는 능력”에서 끝나지 않는다.
이제는 어떤 작업을 어떤 표면에 맡길지 설계하는 능력이 중요해지고 있다.

Codex를 잘 쓰는 사람은 단순히 명령을 잘 내리는 사람이 아니다.
작업의 경계, 권한의 범위, 검토 지점을 설계할 줄 아는 사람이다.