코덱스 툴 사용법 13: 브라우저 작업을 어디에 맡길지 고르는 법 | DAKER 커뮤니티

코덱스 툴 사용법 13: 브라우저 작업을 어디에 맡길지 고르는 법

Codex에게 “사이트에 들어가서 확인해줘”라고 말하면 끝일 것 같지만, 실제로는 먼저 정해야 할 것이 있습니다. 어떤 브라우저 표면을 쓸 것인가입니다.

OpenAI 문서 기준으로 Codex에는 여러 작업 표면이 있습니다. 로컬 개발 서버나 공개 페이지는 in-app browser가 잘 맞고, 로그인된 Chrome 세션이 필요한 사이트는 Codex Chrome extension이 필요합니다. Google Workspace 같은 외부 서비스는 브라우저보다 connector나 MCP가 더 안전할 때가 많고, 반복 가능한 작업은 shell/API 스크립트가 더 낫습니다.

한 줄 요약

브라우저 작업은 “Codex가 볼 수 있느냐”보다 그 작업에 필요한 로그인 상태, 권한, 검증 증거가 어디에 있느냐로 표면을 고르는 것이 안전합니다.

네 가지 표면을 구분하자

표면	쓰기 좋은 상황	피해야 할 상황
in-app browser	localhost, file preview, 공개 페이지, 시각 검증	로그인 쿠키나 Chrome 확장이 필요한 작업
Chrome extension	이미 로그인된 SaaS, 내부 도구, DAKER 같은 세션 의존 UI	공개 페이지 단순 확인, 로컬 미리보기
MCP / connector	Gmail, Drive, Slack처럼 구조화된 API 작업	화면 렌더링 상태 자체가 핵심인 작업
shell / API script	payload 생성, 파일 변환, 재현 가능한 게시 API 호출	인증이 브라우저 세션에만 있는 작업

핵심은 “가장 강한 도구를 쓰자”가 아닙니다. 필요한 권한만 가진 가장 좁은 도구를 고르는 것입니다.

선택 흐름

이 흐름을 쓰면 Codex가 브라우저를 열기 전에 성공 기준이 명확해집니다. “클릭했다”가 완료가 아니라, “저장된 결과를 독립적으로 확인했다”가 완료입니다.

in-app browser는 미리보기와 시각 검증용

OpenAI Codex 문서는 in-app browser를 Codex thread 안에서 렌더링된 웹 페이지를 공유해서 보는 표면으로 설명합니다. 로컬 개발 서버, file-backed preview, 로그인 없는 공개 페이지에 적합합니다.

예를 들어 프론트엔드 버그를 고칠 때는 이렇게 지시할 수 있습니다.

Use the in-app browser to open http://localhost:3000/settings.
Reproduce the overflow, patch only the layout issue, then verify the page again.

이 경우 Codex는 같은 thread 안에서 화면을 보고, 클릭하고, 스크린샷이나 DOM 상태로 검증할 수 있습니다. Chrome 프로필을 건드릴 필요가 없습니다.

Chrome extension은 로그인된 세션이 필요할 때만

Codex Chrome extension은 로그인된 Chrome 상태가 필요한 작업을 위해 존재합니다. OpenAI 문서는 LinkedIn, Salesforce, Gmail, 내부 도구처럼 signed-in browser state가 필요한 사이트를 예로 듭니다.

DAKER 커뮤니티 글 게시처럼 이미 로그인된 브라우저 세션이 필요한 작업은 여기에 속합니다. 다만 Chrome을 쓰는 순간 위험도도 올라갑니다. 페이지 안에는 사용자 데이터, 악성 안내문, 되돌리기 어려운 버튼이 같이 있을 수 있습니다.

그래서 Chrome 작업을 맡길 때는 아래처럼 범위를 좁혀야 합니다.

Use Chrome only for daker.ai.
Open the community editor, select the codex directory, paste the prepared HTML,
insert the two SVG data URLs through the image dialog, publish, then verify the public API.

좋은 지시는 “브라우저에서 알아서 해줘”가 아니라, 허용할 host, 해야 할 클릭, 게시 전 확인 조건, 게시 후 검증 방법을 같이 줍니다.

connector가 있으면 브라우저보다 먼저 생각한다

외부 서비스 작업이 항상 브라우저 작업은 아닙니다. OpenAI MCP/Connectors 문서는 connector와 remote MCP server가 모델에게 외부 서비스에 연결하고 제어할 수 있는 기능을 제공한다고 설명합니다. Google Drive 문서 내용을 읽거나, Slack 메시지를 찾거나, Gmail 스레드를 요약하는 작업은 화면 클릭보다 connector가 더 안정적입니다.

브라우저 자동화는 “화면 렌더링과 실제 UI 상태”가 중요할 때 씁니다. 반대로 데이터가 구조화되어 있고 API가 있으면 connector나 MCP가 더 낫습니다.

실무 기준은 이렇습니다.

화면 레이아웃, 에디터 동작, 드롭다운 선택 확인이 핵심이면 browser
문서/메일/파일/메시지의 데이터가 핵심이면 connector
같은 작업을 매일 반복해야 하면 shell/API script
인증이 브라우저에만 있고 API 토큰이 없으면 Chrome extension

Apply Patch는 브라우저 도구가 아니다

Codex가 코드를 고칠 때는 브라우저가 아니라 apply_patch 같은 편집 표면이 필요합니다. OpenAI 문서는 Apply Patch를 모델이 structured diff로 파일을 만들고 수정하고 삭제하는 도구로 설명합니다.

즉 브라우저는 결과를 보는 곳이고, patch는 코드를 바꾸는 곳입니다. 둘을 섞어서 생각하면 검증이 흐려집니다.

좋은 루프는 이렇게 생겼습니다.

1. in-app browser로 깨진 화면을 확인한다.
2. apply_patch로 CSS나 컴포넌트를 수정한다.
3. 테스트 또는 타입체크를 실행한다.
4. 다시 browser로 렌더링을 확인한다.
5. 완료 보고에는 어떤 검증이 통과했는지 쓴다.

브라우저 작업 지시 템플릿

아래 템플릿은 그대로 복사해서 쓸 수 있습니다.

브라우저 작업 표면:
- 로그인 필요 없음: in-app browser를 사용한다.
- 로그인 필요: Chrome extension을 사용하되, 허용 host는 <domain>으로 제한한다.

작업:
- <URL>을 연다.
- <구체적 UI 조작>을 수행한다.
- 저장/게시 전 <필수 확인 조건>을 확인한다.

검증:
- 완료 후 <공개 URL/API/listing/화면 상태>로 결과를 확인한다.
- 확인하지 못하면 완료로 말하지 말고 blocker와 수동 복구 단계를 남긴다.

이 템플릿의 중요한 부분은 마지막 두 줄입니다. 브라우저 자동화는 중간에 성공한 것처럼 보이기 쉽습니다. 게시 버튼을 눌렀지만 directory가 비어 있거나, HTML paste 과정에서 이미지가 사라졌거나, 저장은 되었지만 공개 페이지에 반영되지 않을 수 있습니다.

마무리

Codex의 브라우저 도구를 잘 쓰는 기준은 “브라우저를 많이 열었는가”가 아닙니다. 권한이 필요한 순간에만 Chrome을 쓰고, 나머지는 in-app browser, connector, shell/API로 좁히는 것입니다.

오늘부터 웹 작업을 맡길 때는 먼저 한 문장만 붙여 보세요.

> 필요한 로그인 상태와 검증 증거를 기준으로 가장 좁은 작업 표면을 선택해줘.

이 한 문장이 브라우저 자동화를 클릭 대행이 아니라 검증 가능한 작업 루프로 바꿉니다.

참고: OpenAI Codex app의 In-app browser, Codex Chrome extension 문서와 OpenAI API의 MCP/Connectors, Apply Patch 도구 문서를 기준으로 작성했습니다.