简体中文

繁體中文

English

Tiếng Việt

한국어

日本語

ภาษาไทย

Türkçe

Partnered With:

Codex를 컴퓨터에서 사용하는 방법: 세 가지 진입 경로와 권한 경계

이 글을 읽으려면 25 분

핵심은 AI에게 더 많은 권한을 부여하는 것이 아니라, 올바른 행동 범위를 선택하도록 하는 것이다.

원문 제목: Three Ways Codex Can Use a Computer
원문 저자: jason
편집: Peggy, BlockBeats

편집자 주: 이 글은 Codex가 외부 환경을 조작하는 세 가지 진입점을 정리합니다: Computer Use, Chrome 확장 프로그램, 앱 내 브라우저입니다. 세 가지 모두 'Codex가 컴퓨터를 사용하게 한다'는 문제를 해결하는 것처럼 보이지만, 각각 다른 작업 시나리오, 권한 경계 및 신뢰 수준에 대응합니다.

그중 Computer Use는 가장 넓은 범위를 다루며, macOS/Windows에서 승인된 네이티브 앱, 시스템 설정, iOS 시뮬레이터를 직접 조작할 수 있고, 여러 앱을 넘나들며 워크플로를 완료할 수도 있습니다. API, 플러그인 또는 구조화된 도구를 지원하지 않는 GUI 프로세스에 적합하지만, 속도가 느리고 권한 경계도 가장 넓습니다. Chrome 확장 프로그램은 로그인 상태, 쿠키, 다중 탭 및 브라우저 신원에 의존하는 작업에 적합합니다. 예를 들어 Gmail, LinkedIn, Salesforce, 내부 백엔드 또는 여러 사이트에 로그인한 상태에서의 리서치 등이 있습니다. 앱 내 브라우저는 개발 및 디버깅 시나리오에 더 적합하며, 특히 로컬 서비스, 시각적 버그, 반응형 레이아웃 및 디자인 주석에 유용합니다. 사용자의 일반 브라우저 로그인 상태를 상속하지 않아 기능이 더 제한적이지만, 격리성은 더 강합니다.

이 글의 핵심 판단은 Codex가 컴퓨터를 사용하는 방식이 단 하나가 아니라는 점입니다. 진정으로 중요한 것은 작업에 따라 가장 좁고, 가장 안전하며, 가장 구조화된 조작 인터페이스를 선택하는 것입니다. 플러그인이나 MCP를 사용할 수 있다면 먼저 시각적 제어를 사용하지 말아야 합니다. 작업이 웹 개발에만 관련된다면 앱 내 브라우저를 우선 사용하고, 사용자 브라우저 신원과 로그인 상태가 필요할 때 Chrome으로 전환합니다. 구조화된 도구로 커버할 수 없고 작업이 데스크톱 그래픽 인터페이스에 의존해야 할 때만 Computer Use가 최후의 수단입니다.

Appshots는 네 번째 컴퓨터 제어 방식이 아니라, 현재 화면 컨텍스트를 Codex에 '가리키는' 도구입니다. 이는 컨텍스트 입력 문제를 해결하는 반면, Browser, Chrome 및 Computer Use는 행동 문제를 해결합니다. 종합해 보면, 이 계층 구조는 실제로 AI Agent 제품화의 핵심을 드러냅니다: 모델에 무제한 권한을 부여하는 것이 아니라, 특정 작업에서 권한을 지속적으로 좁히고 경계를 명확히 하며, 사용자가 중요한 행동에 대한 검토 권한을 유지하는 것입니다.

다음은 원문입니다:

Codex가 컴퓨터를 사용하는 세 가지 방식: Computer Use, Chrome 확장 프로그램, 앱 내 브라우저.

이들 사이에는 일정 부분 중복이 있으며, 정확히 혼란을 줄 만큼 겹쳐 있습니다.

이 글을 읽고 나면, 이 세 가지 방식을 각각 어떻게 설치하고 트리거하는지, 어떤 상황에서 사용해야 하는지, Appshots와 Developer mode가 어떻게 이들을 연결하는지, 그리고 AGENTS.md에 무엇을 작성해야 Codex가 스스로 적절한 조작 인터페이스를 선택할 수 있는지 알게 될 것입니다.

간단히 요약하면 다음과 같습니다:

그렇긴 하지만, 가능하다면 플러그인이나 MCP를 우선 사용하는 것이 좋습니다. 예를 들어 Slack 플러그인은 Slack 내에서 여기저기 클릭하는 것보다 더 정확하게 스레드를 검색할 수 있고, GitHub 플러그인이 생성하는 작업은 Codex가 웹페이지를 조작하도록 하는 것보다 확인하기 쉽습니다. 시각적 제어는 구조화된 도구의 기능이 한계에 도달한 곳에서 가장 적합합니다.

모든 것은 @Computer가 될 수 있다

Computer Use는 이 세 가지 조작 인터페이스 중 가장 광범위한 범위를 다룹니다. 이를 통해 Codex는 macOS와 Windows에서 그래픽 인터페이스를 보고 조작할 수 있으며, 여기에는 창, 메뉴, 키보드 입력, 그리고 사용자가 승인한 앱의 클립보드가 포함됩니다.

또한 일반적으로 가장 느립니다. 구조화된 플러그인은 API를 직접 호출할 수 있지만, Computer Use는 인터페이스를 관찰하고, 어디를 클릭해야 할지 판단하며, 앱의 응답을 기다린 후 다음 상태를 확인해야 합니다. 이 시각적 루프는 시간이 소요되지만, 동시에 Codex가 API를 전혀 사용할 수 없는 앱도 조작할 수 있다는 것을 의미합니다.

macOS에서는 느리다고 해서 반드시 사용자를 방해하는 것은 아닙니다. Computer Use는 사용자가 승인한 앱을 백그라운드에서 조작할 수 있으며, 사용자는 컴퓨터의 다른 부분을 계속 사용할 수 있습니다. 많은 경우, Codex를 사용하는 동안 특정 앱을 열었을 때 Codex가 이미 백그라운드에서 조용히 워크플로우를 완료한 것을 발견했습니다.

사용자 컴퓨터에 설치되고 승인된 앱에 따라, 이러한 조작 대상에는 Spotify, Xcode, System Settings, iOS 시뮬레이터, 심지어 iPhone Mirroring을 통한 iPhone 제어도 포함될 수 있습니다. 또한 여러 앱 간에 전환하며 다양한 앱에 걸친 워크플로우를 처리할 수도 있습니다.

작업이 다음에 의존할 때 사용할 수 있습니다:

Spotify나 금융 앱과 같은 네이티브 데스크톱 앱;

iOS 시뮬레이터, iPhone Mirroring, 또는 그래픽 인터페이스를 통해서만 조작할 수 있는 기타 프로세스;

시스템 또는 애플리케이션 설정;

플러그인이나 API가 없는 데이터 소스;

여러 애플리케이션 간 전환이 필요한 워크플로우;

특정 구조화된 통합에서 누락된 마지막 단계.

설치 방법: Codex의 Settings > Computer Use를 열고 Install을 클릭하세요.

트리거 방식: @Computer를 언급하거나, Codex에 Computer Use를 사용하도록 명시적으로 요청하세요. 모델 성능이 향상됨에 따라, 앞으로는 필요할 때 스스로 호출할 수도 있습니다.

몇 가지 예시를 먼저 시도해 볼 수 있습니다:

제가 가장 좋아하는 예시는 소포가 도난당한 사건에서 비롯되었습니다. Amazon에서 고객센터에 연결하려면 약 25분 정도 기다려야 한다고 알려왔습니다. 저는 Codex 스레드를 Computer Use에 넘겨 5분마다 채팅 창을 확인하게 하고, 상담원이 나타나면 1분마다 확인하도록 변경한 후 최선을 다해 환불을 받도록 했습니다. 제가 샤워를 마치고 돌아왔을 때, 환불은 이미 완료되어 있었습니다.

Use @Computer to open Spotify, find my Discover Weekly playlist, and start it. Do not change my account or subscription settings.Use @Computer to open iPhone Mirroring, reproduce the onboarding bug in the iOS app, and take a screenshot of the failing state. Fix the smallest relevant code path, then run the same flow again.

저는 또한 Computer Use를 구조화된 워크플로우의 '마지막 1km'로 사용합니다. 한 영상 게시 사례에서 Codex는 Slack에서 피드백을 읽고, 코드를 수정하며, 새 영상을 렌더링할 수 있었지만, 당시 해당 스레드의 Slack 통합은 파일을 업로드할 수 없었습니다. 그래서 Computer Use가 Add file을 클릭하여 이 누락된 단계를 보완했습니다.

또한 이는 세 가지 중에서 신뢰 경계가 가장 넓습니다. 한 번에 하나의 명확한 애플리케이션이나 프로세스만 할당하세요. 민감한 애플리케이션이 작업의 일부가 아닐 때는 꺼두고, 권한 팝업을 주의 깊게 확인하며, 금융, 계정, 결제, 자격 증명, 프라이버시 및 시스템 보안 변경과 관련된 경우에는 사람이 현장에서 감독하는 것이 좋습니다.

@Chrome으로 여러 탭과 로그인 상태 관리하기

Codex Chrome 확장 프로그램을 사용하면 Codex가 이미 로그인된 Chrome 상태에 접근할 수 있습니다. 작업이 계정, 쿠키, 브라우저 프로필 또는 이미 열려 있고 인증된 탭에 의존할 때 이를 사용해야 합니다.

이러한 작업 인터페이스는 다음 도구에서의 작업에 적합합니다:

Gmail 또는 LinkedIn;

Salesforce 또는 고객 지원 백엔드;

내부 대시보드;

여러 웹사이트에 걸친 로그인 상태의 연구;

계정 또는 브라우저 확장 프로그램에 의존하는 양식.

설치 방법: Codex의 Plugins를 열고 Chrome을 추가한 후 설정 과정을 따르세요. Codex가 Codex Chrome 확장 프로그램을 설치하고 Chrome 권한을 승인하도록 안내합니다. 확장 프로그램이 Connected로 표시되면 새 스레드를 시작하세요.

트리거 방법: @Chrome을 언급하거나 Codex에게 로그인된 Chrome 브라우저를 사용하도록 명시적으로 요청하세요:

@Chrome을 사용하여 열려 있는 고객 계정을 검토하고, 다른 탭의 지원 티켓과 비교한 후 누락된 필드를 작성하세요. 제출하기 전에 중단하세요.

Chrome 작업은 탭 그룹 내에서 실행되며, 이는 특정 Codex 스레드와 관련된 탭을 함께 모아두는 데 도움이 됩니다. 앱 내 브라우저와 달리 이 작업 인터페이스는 사용자의 브라우저 신원을 전달합니다. 이는 더 강력하면서도 더 민감하게 만듭니다.

또 다른 주요 장점은 다중 탭 제어입니다. Chrome을 사용하면 여러 탭을 동일한 작업에 연결하여 한 페이지에서 컨텍스트를 읽고, 다른 페이지에서 정보를 대조하며, 세 번째 페이지에서 워크플로를 계속할 수 있습니다. Computer Use도 시각적으로 브라우저를 구동할 수 있지만, Chrome은 작업을 일련의 화면 좌표 조작이 아닌 브라우저 워크플로로 이해합니다.

최근 한 스레드에서 이미 열려 있는 Strudel Composer 탭을 Codex에 넘겨 음악을 더 흥미롭게 만들도록 했습니다. Chrome은 선택된 탭과 이 페이지가 노출하는 WebMCP 도구를 제공했습니다. Codex는 곡 구조를 확인하고, 화성과 4분 전체 형식을 다시 작성했으며, 템포를 수정하고, 트랙을 저장한 후 계속 재생하도록 했습니다. 인터페이스에서 각 컨트롤을 시각적으로 찾을 필요가 없었습니다. Chrome이 탭 컨텍스트와 페이지가 제공하는 구조화된 기능을 결합할 수 있었기 때문입니다.

또한 이 기능을 사용해 장기 트위터 스레드를 운영하고 있습니다. 대략적인 지침은 다음과 같습니다:

매일 Chrome을 사용해 내 DM을 확인하고, 관련 뉴스를 읽고, 피드백이나 언급 중 알아야 할 사항을 찾아보세요. 중요한 내용은 내 보관함에 추가하세요. 게시물을 올리거나 메시지를 보내지 마세요.

흥미로운 점은 Codex가 Twitter를 열 수 있다는 사실이 아니라, 이 스레드가 장기적으로 동일한 로그인된 작업 환경으로 돌아가 발견한 내용을 로컬 파일에 연결하고, 제가 검토할 수 있는 결과를 남긴다는 점입니다.

여기서 신뢰 경계가 중요합니다. 웹사이트는 Codex의 클릭, 양식 제출 및 메시지 전송을 사용자 본인의 행동으로 간주할 수 있습니다. 웹 콘텐츠 자체도 신뢰할 수 없는 입력입니다. 결과가 중요한 단계는 명확히 구분해야 합니다: 연구, 탐색 및 초안 작성은 자동화할 수 있지만, 전송, 게시, 구매 또는 제출 전에는 사용자의 검토가 필요합니다.

전체 작업이 브라우저 내에서 완료된다면 Computer Use 대신 Chrome을 우선 사용하세요. Chrome은 이러한 작업에 필요한 브라우저 네이티브 컨텍스트를 제공하면서도 전체 데스크탑으로의 접근 범위를 확장하지 않습니다.

앱 내 @Browser로 개발 중인 웹사이트 처리하기

앱 내 브라우저는 Codex 스레드 내에 존재하는 브라우저입니다. 사용자와 Codex가 동일한 렌더링 페이지를 공유하므로, 웹 애플리케이션을 구축하고 디버깅하는 데 특히 적합합니다.

저는 보통 다음 작업을 여기서 시작합니다:

로컬 개발 서버;

파일 기반 미리보기 페이지;

로그인이 필요 없는 공개 페이지;

시각적 버그 재현;

반응형 레이아웃 확인;

페이지 요소에 대한 디자인 피드백 남기기.

가장 중요한 제약은 격리입니다. 앱 내 브라우저는 사용자의 일반 브라우저 프로필, 쿠키, 확장 프로그램, 로그인 세션 또는 기존 탭을 사용하지 않습니다. 이는 작업에 계정 인증이 필요할 때 제한 사항이지만, 계정이 필요 없는 작업에서는 유용한 경계로 작용합니다.

설정 방법: Codex의 Plugins를 열고 Browser 플러그인을 추가한 후 활성화하세요.

트리거 방식: 프롬프트에 @Browser를 언급하거나, Codex가 앱 내 브라우저를 사용하도록 명확히 요청하는 경우:

@Browser를 사용하여 http://localhost:3000/에서 vite 앱을 열고, 모바일 오버플로우 버그를 재현한 후 수정한 다음, 데스크톱 및 모바일 너비에서 동일한 경로를 다시 확인하세요.

이렇게 하면 긴밀한 피드백 루프가 형성됩니다: Codex가 코드를 편집하고, 페이지를 조작하며, 렌더링 상태를 확인하고, 스크린샷을 찍은 후, 수정 후 동일한 프로세스를 다시 검증할 수 있습니다.

제가 가장 좋아하는 부분은 주석 기능입니다. 로컬 앱을 리뷰할 때 특정 요소를 직접 클릭하거나 영역을 선택하여 댓글을 남길 수 있습니다. 스타일 컨트롤을 통해 텍스트, 글꼴, 간격, 색상을 더 정밀하게 미리 보고 피드백할 수도 있습니다. 저는 보통 이를 음성 입력 및 프로세스 가이드와 결합합니다: 페이지를 리뷰하고 댓글을 남기며, Codex가 현재 피드백을 처리하는 동안 추가 의견을 계속 큐에 추가합니다. 이 페이지 자체가 명세서가 됩니다.

이는 디자인 작업에 특히 유용합니다. 저는 종종 Codex에게 아이디어, 연구 패키지 또는 프로젝트 상태를 단일 파일 index.html로 정리한 후 앱 내 브라우저로 열도록 요청합니다. 다른 프롬프트에서 전체 디자인을 설명하려고 시도하는 대신, 실제 페이지에서 직접 주석을 달 수 있습니다: "이 계층 관계가 반대입니다", "여기는 카드처럼 보이지 않게 해주세요", "이 컨트롤에는 더 많은 공간이 필요합니다", 또는 "전체 사이트에 이 글자 크기 비율을 사용하세요". Codex는 관련 스크린샷과 요소 컨텍스트가 포함된 댓글을 받고, 파일을 수정한 후 동일한 페이지를 다시 열어 다음 라운드를 진행합니다.

이 프로젝트 브리프에 대한 단일 파일 index.html을 생성하고 앱 내 @Browser에서 여세요.

이 루프는 스크린샷과 텍스트 설명을 주고받는 것보다 디자이너와 동일한 캔버스에서 작업하는 느낌에 훨씬 가깝습니다.

앱 내 브라우저는 하이브리드 워크플로의 시작점으로도 적합합니다. 다른 스레드에서는 앱 내 브라우저로 X 게시물을 열고 Codex가 관련 토론을 조사하도록 했습니다. 보이는 페이지 덕분에 Codex가 제가 가리키는 게시물을 확인할 수 있었고, 이후 Codex는 Twitter CLI로 전환하여 브라우저 보기에서 숨겨진 중첩 답글을 포함한 38개의 답글을 검색했습니다. 이는 "가장 좁은 작업 인터페이스" 원칙을 실천한 사례입니다: 브라우저로 화면의 컨텍스트를 확인하고, 구조화된 도구로 더 깊이 있는 검색을 수행합니다.

여기에도 트레이드오프가 있습니다. 앱 내 브라우저의 격리성은 훌륭한 개발 인터페이스를 제공하지만, Google 로그인, 패스키 또는 브라우저 확장 프로그램에 의존하는 웹사이트를 처리하기에는 적합하지 않습니다. 신원이 중요할 때는 Chrome으로 전환하세요.