Codex Computer Use와 내장 브라우저 실전: 에이전트가 페이지를 보고 앱을 조작하고 프런트엔드를 반복하게 하기

프런트엔드를 수정해도 스크린샷만으로는 agent에게 페이지가 실제로 어떻게 보이는지 충분히 전달되지 않을 때가 있습니다. 그렇다면 agent가 직접 브라우저를 열고, 페이지를 보고, 그 자리에서 댓글을 남기고, 계속 진행하면 어떨까요?

macOS에서는 agent가 여러 앱을 백그라운드에서 병렬로 다루는 동안 당신은 코드를 계속 쓸 수 있습니다. Windows에서는 agent가 커서를 넘겨받기 때문에 다른 작업을 잠시 멈춰야 합니다. 프런트엔드 반복에서는 흐름이 아주 단순해집니다. 코드를 수정하고, agent에게 브라우저를 열게 하고, 페이지에서 댓글을 남기고, 다시 반복합니다. 이것이 Computer Use와 내장 브라우저의 실용적인 가치입니다. 플랫폼 차이가 작업 방식을 만들고, 안전 경계가 권한 범위를 정합니다.

1. Computer Use 기본: 커서로 앱을 보고, 클릭하고, 입력하기

1.1 완전 장악이 아니라, “목표를 주면 GUI를 조작한다”

Computer Use는 Codex가 자신의 커서로 컴퓨터의 앱을 보고, 클릭하고, 입력하도록 해줍니다. 공개 API가 없는 데스크톱 도구도 포함됩니다. 예를 들어 “이 PDF를 Word로 바꿔줘”라고 말하면 Codex가 포커스를 옮기고, 창을 클릭하고, 텍스트를 입력해 GUI 흐름을 완성합니다.

이것은 백그라운드 스크립트와 다릅니다. Windows에서는 Codex가 전면에서 커서를 넘겨받습니다. macOS에서는 백그라운드 병렬로 동작하므로 다른 앱에서 계속 작업할 수 있습니다.

주로 해결하는 것은 두 가지입니다.

1. API 없는 도구 조작: 디자인 소프트웨어, 시스템 설정, 데스크톱 앱처럼 GUI에서 끝낼 수 있는 작업.
2. 실제 인터페이스를 봐야 하는 작업: GUI 디버깅, 디자인 목업 재현, 데스크톱 상호작용 테스트.

1.2 macOS vs Windows: 백그라운드 병렬 vs 전면 장악

Computer Use에서 가장 큰 차이는 병렬 작업이 가능한지입니다.

특성	macOS	Windows	설명
동작 방식	백그라운드 병렬	전면에서 장악	macOS는 여러 agent가 병렬로 돌 수 있고, Windows는 커서를 넘겨받습니다
작업 방해	적음	큼	macOS에서는 다른 앱에서 계속 작업할 수 있습니다
다중 agent 병렬	지원	미지원	macOS에서는 여러 thread가 서로 다른 앱을 동시에 다룰 수 있습니다
적합한 상황	병렬 멀티태스킹	한 가지 일에 집중	워크플로에 따라 선택합니다
버전	초기 릴리스	26.527 (2026-05-29)	Windows는 5월 29일에 지원되었습니다
사용 가능성	EEA/영국/스위스 제외	EEA/영국/스위스 제외	EU와 영국으로 순차 배포 중입니다

macOS를 쓴다면 Computer Use는 “병렬 보조자”로 잘 맞습니다. 디자인 앱 하나를 agent에게 맡겨 두고, 당신은 편집기에서 계속 코드를 작성할 수 있습니다. Windows에서는 집중 블록을 따로 잡는 것이 좋습니다. Codex가 커서를 맡고, 다른 작업을 멈춘 뒤 끝날 때까지 기다리는 방식입니다.

2. 내장 브라우저: 프런트엔드 수정 -> 페이지 열기 -> 그 위에서 댓글 -> 계속 진행

2.1 프런트엔드 반복 흐름(4단계)

내장 브라우저가 해결하는 핵심 문제는 간단합니다. agent가 프런트엔드 코드를 수정해도 실제 렌더 결과를 볼 수 없다는 점입니다. 스크린샷만으로는 반복이 무거워집니다.

흐름은 다음과 같습니다.

1. 프런트엔드 수정: 스타일, 레이아웃, 상호작용 로직 변경.
2. 브라우저 열기: Codex에게 localhost 또는 로컬 웹 앱을 열게 함.
3. 페이지에서 댓글: 브라우저 위에서 직접 클릭, 주석, 댓글을 남겨 agent에게 정확한 지시를 전달.
4. 계속 수정: 댓글을 바탕으로 다시 조정하고 다음 렌더 결과를 확인.

이렇게 하면 프런트엔드 반복이 “코드 수정 -> 스크린샷 전달 -> 피드백 수신 -> 코드 수정”이 아니라 “코드 수정 -> 페이지 확인 -> 댓글 -> 코드 수정”으로 바뀝니다. agent는 렌더 결과를 직접 보므로 스크린샷을 계속 보낼 필요가 없습니다.

2.2 현재는 주로 프런트엔드와 게임 반복용

OpenAI의 현재 포지션은 분명합니다. 내장 브라우저는 localhost 웹 앱, 프런트엔드 개발, 게임 개발에 유용합니다.

브라우저 제어의 완전한 확장은 아직 진행 중입니다. 외부 사이트를 Codex가 조작하게 하고 싶다면, 예를 들어 운영 환경 디버깅이나 서드파티 페이지 테스트는 지금은 제한이 있으며 앞으로의 배포를 기다려야 합니다.

2.3 Developer mode: Codex에게 Chrome DevTools Protocol 주기

Developer mode는 2026-06-11에 6.609 버전으로 공개되었고, Codex에게 제어된 Chrome DevTools Protocol 접근을 제공합니다.

할 수 있는 일은 다음과 같습니다.

• 성능 분석: JavaScript 프로파일링과 렌더 시간 측정
• 네트워크 디버깅: 요청, 응답, 시간 확인
• 콘솔 출력: 런타임 오류와 console.log 읽기
• 페이지 상태 확인: DOM과 적용된 스타일 검사

이 기능은 반복 속도도 높입니다. DOM snapshot으로 반복 렌더와 스크린샷 전송을 줄일 수 있습니다. 복잡한 페이지에서는 매번 전체 페이지를 다시 불러올 필요 없이 snapshot에서 이어가므로, 반복이 최대 2배까지 빨라질 수 있습니다.

활성화 경로는 Settings > Browser > Enable full CDP access입니다. 조직에서 Developer mode를 비활성화했다면 로컬에서는 켤 수 없습니다. 이것은 개인 계정 설정이 아니라 조직 정책입니다.

3. Appshots: macOS에서 Command를 두 번 눌러 앱을 한 번에 Codex로 보내기

3.1 일반 스크린샷이 아니라 “스크린샷 + 숨은 텍스트”

Appshots는 2026-05-21에 공개되었고, 스크린샷의 아주 구체적인 문제를 해결합니다. 스크롤 영역 밖의 내용은 보기가 어렵다는 점입니다.

Command 키를 두 번 누르면 Codex가 최전면 앱 창의 스크린샷과 사용 가능한 텍스트를 가져오며, 스크롤 밖의 숨은 텍스트도 포함됩니다. 예를 들어 웹 페이지의 에러 스택이 보이는 영역 아래에 있다면 일반 스크린샷은 못 보여주지만, Appshots는 페이지 전체 텍스트를 추출할 수 있습니다.

3.2 사용 사례

Appshots의 대표적인 사용법은 다음과 같습니다.

• 웹 오류 디버깅: 스크롤 밖 에러 스택까지 포함한 브라우저 전체를 Codex에 보내기.
• 디자인 목업 재현: 디자인 앱 창을 agent에게 보내 레이아웃을 분석하게 하기.
• 선택 불가능한 PDF 텍스트 추출: PDF 창의 내용을 직접 읽기.

agent가 시각과 텍스트를 동시에 볼 수 있으니, 단순 스크린샷보다 효율적입니다.

3.3 Appshots 작업 흐름

1. 목표 앱 창을 열고 클릭해 포커스를 줍니다.
2. Command 키를 두 번 누르고 뗍니다.
3. Codex 아이콘이 오른쪽 아래에 약 1.2초 나타나면 캡처 성공입니다.
4. 최근 60초 내 활성 대화 스레드에 자동으로 첨부됩니다.

주의: Appshots는 macOS 전용이며 시스템 언어는 영어 또는 간체 중국어여야 합니다. 일본어와 한국어 환경에는 알려진 제한이 있습니다. 이 두 언어에서는 스크롤 밖 텍스트가 불완전할 수 있고, 선택 불가능한 텍스트를 제대로 캡처하지 못할 수 있습니다. 일본어 또는 한국어 시스템이라면 먼저 영어 또는 간체 중국어로 테스트하세요.

4. 안전 경계: 언제 전체 접근을 주지 말아야 하는가

4.1 기본은 sandbox, 권한은 필요할 때만

Codex는 기본적으로 sandbox 모드에서 실행되며, agent는 작업 폴더와 브랜치 안에 제한됩니다. 더 높은 권한이 필요한 작업은 승인이 필요합니다. Computer Use와 내장 브라우저는 더 높은 권한이 필요한 기능이므로 신중하게 허용해야 합니다.

기능	기본 권한	더 높은 권한 필요	권장
일반 코딩	sandbox	없음	기본값으로 충분
Computer Use	sandbox	추가 승인 필요	필요할 때만 허용, Windows에서는 앱별로 제한
내장 브라우저	sandbox	Developer mode 승인 필요	프런트엔드 반복 때만 켜기
Appshots	읽기 전용	없음	안전, 읽기 전용

Windows 사용자는 추가 제어가 가능합니다. Settings > Computer Use > Configure per-app access control로 Codex가 특정 앱만 조작하도록 제한할 수 있습니다.

4.2 언제 전체 접근을 주지 말아야 하는가

Computer Use의 권한은 매우 신중하게 판단해야 합니다. 다음 상황에서는 권장하지 않습니다.

• 신뢰하지 않는 서드파티 codebase. agent가 민감한 파일을 볼 수 있습니다.
• 운영 중인 데이터베이스. agent가 잘못된 변경을 할 수 있습니다.
• 고권한 시스템 설정. Windows의 앱별 제어가 중요합니다.

보수적인 규칙은 단순합니다.

• 기본은 sandbox로 두고, 작업이 분명히 필요할 때만 권한을 줍니다.
• Windows에서는 per-app access control로 범위를 줄입니다.

5. 선택 기준: 언제 Computer Use를 쓰고 언제 일반 코딩이 더 싼가

5.1 시나리오 표

Computer Use는 만능 도구가 아닙니다. 작업 유형으로 판단하세요.

시나리오	권장 방식	이유
프런트엔드 / UI 스타일 수정	내장 브라우저	실제 렌더를 볼 수 있고 반복 루프가 완성됨
API 없는 데스크톱 도구 조작	Computer Use	GUI만이 유일한 경로
단순 코드 생성	일반 코딩	Computer Use는 예산을 더 쓰고 비효율적
프런트엔드 성능 디버깅	Developer mode	CDP 성능 분석 + 네트워크 디버깅
앱을 빠르게 Codex에 보내기	Appshots (macOS)	한 번의 캡처 + 숨은 텍스트

핵심 규칙은 간단합니다. 일반 코딩으로 끝나면 Computer Use를 켜지 마세요. API 없는 도구를 조작하거나 실제 인터페이스를 봐야 할 때 그 가치가 나옵니다.

5.2 비용 안내: Computer Use와 브라우저는 더 비쌉니다

Computer Use와 내장 브라우저는 일반 코딩보다 비용이 더 듭니다.

• Computer Use는 캡처와 상호작용 때문에 토큰을 더 씁니다.
• 브라우저 반복은 한 라운드마다 호출이 발생합니다.

간단한 작업은 일반 코딩으로 처리하고, 복잡한 GUI 작업에만 Computer Use를 쓰는 것이 좋습니다.

6. FAQ: 자주 묻는 질문

Q1: Computer Use는 무엇이고 어디까지 할 수 있나요?

Computer Use는 Codex가 자신의 커서로 보고, 클릭하고, 입력해서 컴퓨터의 모든 앱을 조작할 수 있게 해줍니다. 공개 API가 없는 데스크톱 도구도 포함됩니다. 완전한 장악은 아니며, 목표를 설명하면 Windows에서는 전면에서, macOS에서는 백그라운드에서 GUI를 조작합니다.

Q2: macOS와 Windows의 차이는 무엇인가요?

macOS는 백그라운드 병렬 작업을 지원하므로 여러 agent가 다른 앱을 동시에 다루어도 다른 작업을 방해하지 않습니다. Windows는 현재 전면 작업만 가능하고 agent가 커서를 넘겨받으므로 다른 작업을 멈춰야 합니다. 둘 다 모든 앱을 조작할 수 있으며, 선택 기준은 워크플로입니다.

Q3: 내장 브라우저로 프런트엔드를 어떻게 반복하나요?

프런트엔드를 수정하고, 내장 브라우저에서 localhost 페이지를 열고, 페이지에서 직접 댓글을 남기고, agent가 계속 수정하도록 한 뒤, 다시 브라우저를 열어 결과를 확인합니다. 이렇게 edit-view-comment-edit 루프가 만들어집니다. 현재는 주로 프런트엔드와 게임 반복에 적합합니다.

Q4: 안전한가요, 전체 접근이 필요한가요?

기본은 sandbox이며 agent는 작업 폴더와 브랜치로 제한됩니다. 더 높은 권한은 승인 필요입니다. Computer Use와 브라우저는 더 높은 권한의 기능이므로 필요할 때만 허용하세요. Windows에서는 앱별로 제한할 수도 있고, 신뢰하지 않는 상황에는 절대 전체 접근을 주면 안 됩니다.

Q5: 언제 Computer Use가 가치 있나요?

API 없는 데스크톱 도구, 예를 들어 디자인 소프트웨어나 시스템 설정을 조작할 때, 그리고 agent가 실제 인터페이스를 봐야 하는 경우, 예를 들어 GUI 디버깅이나 목업 재현에 좋습니다. 단순 코드 생성은 일반 코딩이 더 저렴합니다.

Q6: Developer mode 브라우저는 무엇을 할 수 있나요?

Codex에 제어된 Chrome DevTools Protocol 접근을 주어 성능 분석, 네트워크 디버깅, 콘솔 출력, DOM 및 스타일 검사를 할 수 있게 합니다. 이 기능은 2026-06-11에 추가되었습니다. 경우에 따라 DOM snapshotting으로 반복 속도가 최대 2배 개선될 수 있습니다.

7. 다음 단계와 참고 자료

관련 글

• 상위: Codex 보안 sandbox와 권한 경계: 언제 전체 접근을 주지 말아야 하는가 (출간 예정)
• 하위: Codex Cloud Agent 워크플로: 원격 장치의 조작과 모니터링 (출간 예정)
• 하위: Codex 비용 실전: Computer Use, 브라우저, 장기 작업의 예산 관리 (출간 예정)

공식 리소스

• Codex 공식 문서
• Codex Changelog
• Codex for (almost) everything, 2026-04-16의 주요 업데이트

결론

Computer Use와 내장 브라우저가 해결하는 핵심은 같습니다. AI가 실제 인터페이스를 봐야 작업을 끝낼 수 있다는 점입니다. 프런트엔드 수정은 실제 렌더가 필요하고, API 없는 도구는 GUI가 필요합니다.

플랫폼 차이가 워크플로를 만듭니다. macOS에서는 agent가 앱을 백그라운드에서 조작하는 동안 당신은 계속 코딩할 수 있습니다. Windows에서는 집중 블록을 잡고 agent가 커서를 넘겨받게 해야 합니다.

안전도 절제가 필요합니다. 기본은 sandbox로 두고, 작업이 정말 필요할 때만 권한을 주며, Windows에서는 per-app access control로 범위를 줄이세요.

비용의 균형도 분명합니다. 단순한 작업은 일반 코딩이 더 저렴하고, 복잡한 GUI 작업에서 Computer Use가 제값을 합니다.

다음 추천 단계:

• macOS를 쓴다면, 디자인 앱을 백그라운드에서 돌리면서 편집기 작업을 계속해 보세요.
• 프런트엔드를 반복해야 한다면 내장 브라우저로 edit-view-comment-edit 루프를 만들어 보세요.
• 안전 경계가 아직 헷갈린다면, 전체 접근을 주기 전에 Codex의 보안 sandbox와 권한 경계를 먼저 읽어 보세요.