코덱스 in-app browser 사용법: 웹 QA를 화면 확인까지 끝내는 방법 | DAKER 커뮤니티

Codex in-app browser는 Codex 스레드 안에서 렌더링된 웹 페이지를 함께 확인하는 기능입니다. 웹 앱 수정 뒤 “테스트는 통과했는데 화면이 깨지는” 문제를 줄이려면, 로컬 서버나 공개 페이지를 @Browser로 열어 수정 전후를 같은 화면에서 검증해야 합니다.

코덱스 in-app browser 웹 QA 대표 카드

코덱스 in-app browser 웹 QA 대표 카드

문제 상황: Codex로 코드를 고쳤는데 왜 화면 버그가 남을까?

한 줄 요약: UI 작업은 코드 diff와 테스트만으로 닫히지 않고, 실제 렌더링 화면을 다시 봐야 닫힙니다.

Codex에게 “이 컴포넌트 고쳐줘”라고만 맡기면 파일은 잘 바뀌어도 다음 문제가 남을 수 있습니다.

이 글은 코덱스 툴 사용법 25: 권한 프로필로 작업장 경계 고정하기처럼 작업 경계를 정한 뒤, 웹 화면 검증을 어디서 닫을지 정하는 실무 편입니다. 명령 승인 기준이 필요하면 코덱스 툴 사용법 24: Rules로 명령 승인 기준을 파일로 고정하기도 같이 보면 흐름이 이어집니다.

핵심 개념: in-app browser와 Chrome extension은 언제 나눠 써야 할까?

OpenAI 공식 문서 기준으로 in-app browser는 로컬 개발 서버, 파일 기반 미리보기, 로그인 없는 공개 페이지에 적합합니다. 반대로 로그인 상태, 쿠키, 기존 Chrome 프로필, 확장 프로그램, 사내 도구가 필요한 작업은 Codex Chrome extension을 쓰는 쪽이 맞습니다.

작업 상황

추천 표면

이유

localhost:3000/settings 화면이 깨지는지 확인

in-app browser

Codex가 코드와 화면을 같은 스레드에서 볼 수 있음

정적 HTML, Storybook, 파일 기반 프리뷰 검증

in-app browser

로그인 없이 빠르게 열고 스크린샷 기준으로 확인 가능

공개 랜딩 페이지의 모바일 CTA 검증

in-app browser

클릭, 스크롤, 읽기 전용 검사에 적합

Gmail, Salesforce, 사내 관리자 페이지 검증

Chrome extension

로그인 세션과 브라우저 프로필이 필요함

네트워크, 콘솔, DOM 상태를 깊게 봐야 하는 디버깅

Browser use 개발자 모드

설정에서 CDP 접근을 켠 뒤 명시적 승인으로 사용

핵심 질문은 간단합니다. “Codex가 로그인 없이 열 수 있는가?” 열 수 있으면 in-app browser가 보통 더 단순하고, 열 수 없으면 Chrome extension이나 전용 커넥터로 분기해야 합니다.

코덱스 웹 QA 표면 선택 워크플로

코덱스 웹 QA 표면 선택 워크플로

단계별 사용법: @Browser 프롬프트는 어떻게 써야 하나?

한 줄 요약: URL, 화면 상태, 기대 결과, 수정 금지 범위를 한 번에 적어야 재현과 검증이 같은 루프로 묶입니다.

  1. 개발 서버를 먼저 띄웁니다. 예를 들어 npm run dev나 프로젝트의 표준 개발 명령을 사용합니다.

  2. Codex에게 정확한 URL을 줍니다. /settings, /checkout/success, /empty-state처럼 상태가 드러나는 경로가 좋습니다.

  3. 확인할 상태를 지정합니다. 로딩, 빈 화면, 오류, 성공, 모바일 폭처럼 관찰 기준을 적습니다.

  4. 수정 범위를 좁힙니다. “CSS만”, “컴포넌트 구조 유지”, “API 로직 제외”처럼 경계를 둡니다.

  5. 수정 후 같은 URL에서 다시 검증하게 합니다. 스크린샷, DOM 상태, 콘솔 오류 중 필요한 증거를 남기게 합니다.

실무 프롬프트는 아래처럼 쓰면 충분합니다.

@Browser로 http://localhost:3000/settings를 열어 주세요.
모바일 폭에서 저장 버튼과 요금제 카드가 겹치는지 확인하고,
겹치면 레이아웃만 수정하세요. 카드 데이터 구조와 결제 로직은 건드리지 마세요.
수정 뒤 같은 화면을 다시 열어 스크린샷 기준으로 검증해 주세요.

코덱스 툴 사용법 23: AGENTS.md는 저장소의 작업 계약서다를 이미 쓰고 있다면, “웹 UI 변경은 수정 후 @Browser 재검증까지 완료한다”는 규칙을 AGENTS.md에 넣어두는 것도 좋습니다.

짧은 예시: PR 올리기 전에 붙여 넣을 웹 QA 요청은?

아래 요청은 작은 UI 변경 PR을 올리기 전 체크용으로 쓰기 좋습니다.

@Browser로 변경된 경로를 열어 주세요.
데스크톱과 모바일 폭에서 주요 CTA가 보이는지 확인해 주세요.
로딩, 빈 상태, 오류 상태 중 구현된 상태를 하나씩 확인해 주세요.
콘솔 오류가 있으면 원인만 요약하고, 관련 없는 리팩터링은 하지 마세요.
수정 후 같은 경로에서 다시 검증하고 결과를 짧게 보고해 주세요.

이 요청의 장점은 Codex가 “파일 수정자”에서 “화면까지 확인하는 작업자”로 바뀐다는 점입니다. 처음 Codex 흐름을 잡는 중이라면 Codex 앱 사용 매뉴얼: 설정부터 작업 맡기기까지에서 기본 설정을 먼저 맞춘 뒤 적용해도 됩니다.

실수 방지 체크리스트: in-app browser를 쓸 때 무엇을 조심해야 하나?

공식 출처: 2026년 6월 19일 기준 어디를 확인했나?

OpenAI 공식 문서에서 확인한 내용은 다음과 같습니다.

이 글은 공개 문서 기준의 사용법 정리입니다. 실제 조직 워크스페이스에서는 관리자 정책, 플랜, 플러그인 사용 가능 여부에 따라 보이는 메뉴나 승인 흐름이 달라질 수 있습니다.

자주 묻는 질문

Codex in-app browser는 로그인된 페이지도 볼 수 있나요?

공식 문서 기준으로 in-app browser는 인증 흐름, 로그인된 페이지, 일반 브라우저 프로필, 쿠키, 확장 프로그램, 기존 탭을 지원하지 않습니다. 그런 작업은 Chrome extension이나 전용 커넥터로 분리하세요.

Browser use를 켜면 Codex가 무엇까지 할 수 있나요?

Codex가 in-app browser 안에서 클릭, 입력, 렌더링 상태 검사, 스크린샷, 읽기 전용 페이지 검사 등을 수행할 수 있습니다. 더 깊은 콘솔, 네트워크, DOM 디버깅은 개발자 모드와 승인 범위를 확인해야 합니다.

로컬 개발 서버는 어떻게 연결하나요?

먼저 프로젝트에서 개발 서버를 띄운 뒤 @Browser로 http://localhost:3000/...처럼 정확한 경로를 줍니다. 화면 상태와 수정 범위를 함께 주는 것이 중요합니다.

in-app browser 검증은 테스트를 대체하나요?

아닙니다. 테스트는 로직과 회귀를 잡고, in-app browser는 실제 렌더링과 상호작용 문제를 확인합니다. UI 변경은 테스트와 화면 검증을 함께 쓰는 편이 안전합니다.

팀 규칙으로 만들려면 어디에 적어야 하나요?

저장소의 AGENTS.md나 팀 작업 가이드에 “웹 UI 변경은 수정 후 @Browser로 주요 경로를 재검증한다”처럼 짧게 넣으면 반복 작업에서 빠뜨리기 어렵습니다.

다음 웹 UI 변경을 Codex에 맡길 때는 URL 하나만 주지 말고, 상태와 재검증 기준까지 함께 적어 보세요.

Redirecting to 코덱스 in-app browser 사용법: 웹 QA를 화면 확인까지 끝내는 방법 | DAKER 커뮤니티...