빠른 흐름

in-app browser 검증 흐름
1. Codex app thread에서 in-app browser를 연다
2. 로컬 개발 서버, 파일 기반 preview, 공개 페이지를 띄운다
3. 화면에서 문제가 보이는 지점에 visual comment를 남긴다
4. Codex에게 기대 상태와 검증 기준을 함께 지시한다
5. 수정 후 같은 화면에서 다시 확인하고 diff와 테스트를 같이 본다

브라우저 검증

렌더링된 화면을 같은 맥락으로 보는 장점

in-app browser는 thread 안에서 사용자와 Codex가 렌더링된 웹 페이지를 함께 보는 표면입니다. 프론트엔드 문제는 파일만 읽어서는 의도를 놓치기 쉽습니다. 여백, 색 대비, 버튼 위치, 반응형 깨짐처럼 화면에서 바로 보이는 문제는 브라우저 화면을 기준으로 설명하는 편이 훨씬 정확합니다.

이 흐름은 "이 컴포넌트가 이상하다"보다 "이 페이지의 모바일 폭에서 CTA가 접히고, visual comment가 붙은 버튼은 아래 카드와 간격이 너무 좁다"처럼 증거를 화면에 묶어 전달할 때 효과적입니다. Codex가 같은 페이지 상태를 보고 작업하므로 재현 단계가 짧아지고, 수정 후 확인도 같은 thread 안에서 이어가기 쉽습니다.

visual comment는 위치와 기대 상태를 함께 적어야 한다

visual comment는 위치를 알려 주지만 기대 상태까지 자동으로 결정해 주지는 않습니다. 클릭한 지점이 "문제 위치"인지, "참고할 정상 위치"인지, "이 위치로 옮기라"는 뜻인지 명확히 적어야 합니다. 화면 주석에는 가능한 한 현재 문제, 원하는 변화, 유지해야 할 경계를 같이 남기는 편이 안전합니다.

좋은 visual comment
- 이 버튼은 375px 폭에서 텍스트가 두 줄로 접히지 않아야 한다
- 위 카드와 간격은 유지하고, 오른쪽 아이콘만 4px 안쪽으로 이동한다
- 색상은 기존 primary token을 사용하고 새 색상은 추가하지 않는다

로그인 상태가 필요한 페이지는 다른 표면을 고른다

공식 기준상 in-app browser는 로컬 개발 서버, 파일 기반 preview, 로그인 없는 공개 페이지에 잘 맞습니다. 로그인 상태, 브라우저 확장, 개인 Chrome profile이 필요한 작업은 일반 브라우저나 Codex Chrome extension 쪽이 더 적합합니다. in-app browser에서 열리지 않는 페이지를 억지로 붙잡으면 인증 문제와 UI 문제를 구분하기 어려워집니다.

어디에 쓸까

주의할 점

실패 예시
- visual comment에 "여기 이상함"만 남김
- 결과: spacing, 색상, 문구 중 무엇을 고쳐야 하는지 모호해짐
- 대응: 어떤 상태가 실패이고 어떤 상태가 통과인지 짧게 적는다