Browser Use와 Computer Use로 실제 앱을 검증하기
코드는 통과했지만, 화면도 통과했을까
코드가 컴파일된다고 해서 앱이 완성된 것은 아닙니다. 버튼은 눌리는지, 폼은 저장되는지, 모바일 화면에서 카드가 삐져나오지는 않는지, 로그인 후 대시보드로 이동하는지까지 확인해야 비로소 "사용할 수 있는 앱"에 가까워집니다.
초보자가 Codex를 쓸 때 가장 흔히 놓치는 부분이 바로 이 지점입니다. Codex에게 코드를 만들게 하고, 테스트 몇 개를 통과시키고, npm run build가 성공하면 끝났다고 생각하기 쉽습니다. 하지만 실제 사용자는 코드를 보지 않습니다. 사용자는 화면을 보고, 버튼을 누르고, 입력하고, 기다리고, 실패 메시지를 만납니다.
이번 장에서는 Codex가 브라우저와 컴퓨터 화면을 함께 사용해 앱을 검증하는 방법을 다룹니다. 핵심은 간단합니다. Codex가 코드를 쓰는 사람에서, 실제 화면을 보며 확인하는 QA 파트너로 확장된다는 것입니다.
왜 "실제 화면 검증"이 필요한가
앱 개발에는 두 개의 세계가 있습니다. 하나는 코드의 세계입니다. 파일, 함수, 컴포넌트, API, 테스트, 빌드 로그가 여기에 속합니다. 다른 하나는 사용자의 세계입니다. 브라우저에 렌더링된 화면, 버튼 위치, 로딩 상태, 오류 메시지, 모달, 스크롤, 모바일 레이아웃이 여기에 속합니다.
AI 코딩 도구는 첫 번째 세계에서는 매우 강합니다. 프로젝트 구조를 읽고, 파일을 고치고, 테스트를 만들고, 빌드 오류를 해결합니다. 하지만 앱의 품질은 두 번째 세계에서 판가름납니다. 예를 들어 코드는 맞는데 실제 화면에서는 다음과 같은 문제가 생길 수 있습니다.
버튼 텍스트가 너무 길어 모바일에서 두 줄로 깨진다.
로그인 실패 메시지가 화면 아래에 숨어 사용자가 보지 못한다.
모달이 열리지만 닫기 버튼이 배경색과 겹쳐 보이지 않는다.
API 오류가 발생했는데 화면에는 계속 로딩 스피너만 돈다.
회원가입은 성공하지만 성공 후 이동해야 할 페이지가 잘못되어 있다.
이런 문제는 코드만 읽어서는 놓치기 쉽습니다. 그래서 Codex에게 "구현해줘"에서 멈추지 말고 "실제 브라우저에서 확인하고, 문제가 있으면 고친 뒤, 다시 검증해줘"라고 맡기는 습관이 필요합니다.
이 장에서 다루는 도구는 크게 세 가지입니다. 먼저 Codex App 안에서 웹페이지를 함께 보는 인앱 브라우저가 있습니다. OpenAI 문서에 따르면 이 브라우저는 스레드 안에서 사용자와 Codex가 렌더링된 웹페이지를 함께 보고, 웹앱을 미리보기하거나 시각적 코멘트를 붙이는 용도로 설계되어 있습니다.1 다음으로 로그인된 실제 Chrome 상태가 필요한 작업에는 Codex Chrome extension 같은 브라우저 확장 흐름을 사용할 수 있습니다.2 마지막으로 macOS 환경에서는 Computer Use를 통해 Codex가 화면을 보고, 클릭하고, 입력하며 데스크톱 앱을 조작할 수 있습니다. 공식 문서는 이 기능을 쓰기 전에 Computer Use 플러그인을 설치하고 macOS의 화면 기록 및 손쉬운 사용 권한을 부여해야 한다고 안내합니다.3
기능 이름과 제공 범위는 계정, 운영체제, Codex App 버전에 따라 달라질 수 있습니다. 따라서 실제 작업 전에는 현재 설치된 앱의 메뉴와 공식 문서를 확인하세요. 이 장에서 더 중요한 것은 도구 이름이 아니라, 코드를 만든 뒤 실제 화면에서 검증하는 사고방식입니다.
먼저 고를 것: 인앱 브라우저, Chrome extension, Computer Use
초보자에게 가장 중요한 판단 기준은 "무조건 강한 도구를 쓰는 것"이 아닙니다. 가장 좁고 안전한 도구부터 쓰는 것입니다.
로컬에서 만드는 웹앱을 확인할 때는 대개 인앱 브라우저가 첫 번째 선택입니다. 예를 들어 http://localhost:3000에서 실행 중인 할 일 앱, 날씨 대시보드, 미니 SaaS의 대시보드 화면을 확인하는 일이라면 Codex App 안의 브라우저로 충분한 경우가 많습니다. 같은 스레드 안에서 화면을 보고, "이 버튼 여백을 조금 늘려줘", "모바일에서 카드가 붙어 보여", "빈 상태 문구를 더 친절하게 바꿔줘"처럼 시각적 피드백을 줄 수 있기 때문입니다.
반대로 이미 로그인된 브라우저 상태가 필요한 작업이라면 Chrome extension이 어울립니다. 예를 들어 회사 내부 관리자 페이지, 로그인된 결제 테스트 대시보드, Gmail로 온 인증 메일 확인, CRM의 고객 상세 페이지 확인은 인앱 브라우저보다 실제 Chrome 프로필이 필요할 수 있습니다. 이런 작업은 편리하지만, 내 로그인 세션과 민감한 데이터가 얽힐 수 있으므로 반드시 읽기 전용부터 시작해야 합니다.
Computer Use는 더 넓은 화면 조작이 필요할 때 꺼내는 도구입니다. 브라우저뿐 아니라 데스크톱 앱, 시뮬레이터, 배포 콘솔, 외부 대시보드처럼 Codex App 안에서 끝나지 않는 GUI 작업에 적합합니다. 다만 범위가 넓은 만큼 안전 규칙도 더 엄격해야 합니다. 실제로 Computer Use는 Codex가 화면을 보고 클릭하고 입력할 수 있게 해주지만, 이런 접근은 강력한 만큼 신중한 승인과 최소 권한 운영이 필요합니다.
초보자는 다음 순서로 생각하면 됩니다. "코드와 로컬 웹 미리보기로 충분한가?" 그렇다면 인앱 브라우저를 씁니다. "로그인된 내 Chrome 세션이 꼭 필요한가?" 그렇다면 Chrome extension을 고려합니다. "브라우저 밖의 앱이나 배포 콘솔까지 봐야 하는가?" 그렇다면 Computer Use를 사용하되, 읽기 전용과 사용자 승인을 기본값으로 둡니다.
인앱 브라우저로 로컬 웹앱을 미리보기하기
가장 쉬운 실습부터 시작해 보겠습니다. 앞 장들에서 만든 할 일 앱이나 날씨 대시보드 같은 프로젝트가 있다고 가정하겠습니다. 목표는 Codex가 코드를 수정한 뒤 실제 화면까지 확인하게 만드는 것입니다.
먼저 개발 서버를 실행합니다.
npm run dev보통 Next.js나 Vite 프로젝트라면 http://localhost:3000 또는 http://localhost:5173 같은 주소가 열립니다. 이제 Codex App의 같은 스레드에서 이렇게 요청합니다.
인앱 브라우저로 http://localhost:3000 을 열어줘.
홈 화면이 실제로 어떻게 렌더링되는지 확인하고,
다음 기준으로 문제를 찾아줘.
1. 주요 버튼이 한눈에 보이는지
2. 모바일 폭에서도 레이아웃이 깨지지 않는지
3. 빈 상태 문구가 초보 사용자에게 친절한지
4. 콘솔 오류가 있다면 무엇인지
코드는 아직 수정하지 말고, 먼저 발견한 문제만 정리해줘.여기서 중요한 점은 "바로 고쳐줘"라고 하지 않는 것입니다. 먼저 관찰하게 해야 합니다. 사람이 QA를 할 때도 먼저 화면을 보고, 문제를 기록하고, 우선순위를 정한 다음 수정합니다. Codex에게도 같은 흐름을 주면 결과가 훨씬 안정적입니다.
Codex가 화면을 확인한 뒤 "모바일에서 카드 간격이 너무 좁다", "삭제 버튼이 위험한 동작인데 색상만으로 구분되어 있다", "빈 목록 상태에서 다음 행동을 안내하지 않는다"처럼 보고할 수 있습니다. 그다음에 수정 범위를 좁혀 요청합니다.
좋아. 지금 발견한 문제 중에서 모바일 레이아웃과 빈 상태 문구만 수정해줘.
삭제 버튼 스타일은 이번 작업에서 건드리지 마.
수정 후 인앱 브라우저에서 다시 확인하고,
수정 전후 차이를 짧게 비교해줘.이렇게 하면 Codex의 작업이 산만해지지 않습니다. 특히 초보자는 한 번에 많은 것을 맡기기보다 "확인 → 작은 수정 → 재확인" 루프를 만드는 것이 좋습니다.
화면 위 피드백으로 UI를 고치는 흐름
인앱 브라우저의 장점은 Codex와 사용자가 같은 화면을 보며 이야기할 수 있다는 점입니다. 말로만 "카드가 어색해"라고 하는 것보다, 실제 렌더링된 화면을 기준으로 지적하면 Codex가 훨씬 정확하게 수정합니다.
예를 들어 가격 페이지의 카드가 있다고 해보겠습니다. 데스크톱에서는 괜찮아 보이지만 모바일에서 가격 텍스트와 CTA 버튼이 너무 가까워 보입니다. 이때 좋은 프롬프트는 다음과 같습니다.
인앱 브라우저에서 /pricing 페이지를 모바일 폭 375px 기준으로 확인해줘.
화면에서 가격 카드의 제목, 가격, CTA 버튼 사이 간격이 답답해 보이는지 봐줘.
문제가 있으면 Tailwind 클래스만 최소한으로 조정해서 개선해줘.
레이아웃 구조와 문구는 바꾸지 마.
수정 후 같은 폭에서 다시 확인해줘.이 프롬프트에는 좋은 점이 많습니다. 확인할 페이지가 명확하고, viewport 기준이 있고, 수정 범위가 Tailwind 클래스에 제한되어 있으며, 구조와 문구를 바꾸지 말라는 제약도 있습니다. 마지막에는 다시 확인하라고 요구합니다.
Codex가 UI를 수정할 때는 종종 "좋아 보이게" 하려고 예상보다 많은 것을 바꾸려 합니다. 버튼 색, 그림자, 폰트 크기, 섹션 순서까지 함께 손대는 식입니다. 초보자는 이것을 막기 위해 항상 "수정하지 말 것"을 함께 적는 습관을 들이면 좋습니다.
이번 작업에서 하지 말 것:
- API 코드 수정 금지
- 라우팅 구조 변경 금지
- 문구 전체 재작성 금지
- 디자인 시스템에 없는 색상 추가 금지이런 금지 조건은 Codex를 믿지 못해서 쓰는 것이 아닙니다. 좋은 동료에게도 작업 범위를 정해주듯, Codex에게도 안전한 울타리를 주는 것입니다.
최신 문서와 changelog를 브라우저로 확인시키기
앱 개발 중에는 "이 라이브러리의 최신 사용법이 맞나?"라는 질문이 자주 생깁니다. 예전 블로그 글을 보고 구현했는데 최신 버전에서는 옵션 이름이 바뀌었거나, API 응답 형식이 달라졌거나, 보안 권장사항이 업데이트되었을 수 있습니다.
이때 Codex에게 단순히 "최신 방식으로 고쳐줘"라고 하면 위험합니다. 최신이 무엇인지 Codex가 추측할 수 있기 때문입니다. 대신 브라우저로 공식 문서, changelog, API 레퍼런스를 확인하게 하고, 참고한 근거를 남기게 해야 합니다.
예를 들어 Stripe 결제 직전 단계까지 구현하는 미니 SaaS를 만들고 있다고 가정해 보겠습니다. 실제 결제 실행은 위험하므로 하지 않고, 테스트 모드에서 checkout session 생성 직전까지 확인하려는 상황입니다.
브라우저로 Stripe 공식 문서의 Checkout 관련 최신 문서를 확인해줘.
우리 프로젝트의 결제 직전 단계 구현이 최신 권장 방식과 맞는지 비교해줘.
반드시 답변에 다음을 포함해줘.
- 참고한 URL
- 문서에서 확인한 버전 또는 업데이트 날짜가 있다면 그 정보
- 우리 코드와 다른 점
- 바로 수정해야 할 항목과 나중에 봐도 되는 항목
아직 코드는 수정하지 마.이 프롬프트의 핵심은 "근거를 남겨달라"는 부분입니다. Codex가 어떤 문서를 봤는지, 어떤 버전 기준으로 판단했는지 알아야 나중에 팀원이 검토할 수 있습니다. 특히 결제, 인증, 개인정보, 배포 설정처럼 실수 비용이 큰 영역에서는 URL과 버전 근거가 매우 중요합니다.
문서 조사를 맡길 때는 이렇게 한 단계 더 나눌 수 있습니다.
먼저 문서 조사만 해줘.
그다음 수정 계획을 제안해줘.
내가 승인하면 그때 코드를 수정해줘.이 방식은 초보자에게 특히 안전합니다. Codex가 최신 문서를 확인하는 능력은 강력하지만, 문서를 읽고 바로 대규모 수정을 시작하면 변경 범위가 커질 수 있습니다. "조사 → 계획 → 승인 → 수정" 순서로 나누면 실수를 줄일 수 있습니다.
사용자가 하는 조작을 Codex가 대신 실행하게 하기
실제 앱 검증에서 가장 중요한 것은 사용자 행동입니다. 화면을 보는 것만으로는 부족합니다. 사용자는 입력하고, 클릭하고, 이동하고, 실패하고, 다시 시도합니다.
Codex에게 맡기기 좋은 기본 조작은 다음과 같습니다.
폼 입력 후 제출
버튼 클릭 후 상태 변화 확인
페이지 이동과 뒤로 가기 확인
모달 열기와 닫기 확인
빈 상태, 로딩 상태, 에러 상태 확인
콘솔 오류와 네트워크 실패 확인
예를 들어 할 일 앱을 검증한다면 이렇게 요청할 수 있습니다.
인앱 브라우저에서 http://localhost:3000 을 열고,
사용자처럼 다음 시나리오를 실행해줘.
1. 빈 목록 상태 문구를 확인한다.
2. "우유 사기"라는 할 일을 추가한다.
3. 추가된 항목이 목록에 보이는지 확인한다.
4. 완료 체크를 눌러 상태가 바뀌는지 확인한다.
5. 삭제 버튼을 눌러 항목이 사라지는지 확인한다.
각 단계마다 화면에서 실제로 확인한 결과를 적어줘.
콘솔 오류나 네트워크 오류가 있으면 함께 보고해줘.
실패한 단계가 있으면 재현 방법과 수정 후보를 제안해줘.날씨 대시보드라면 조금 다릅니다.
브라우저에서 날씨 대시보드를 테스트해줘.
다음 흐름을 실제로 실행해줘.
- 검색창에 Seoul을 입력하고 검색
- 결과 카드에 도시명, 현재 온도, 날씨 설명이 보이는지 확인
- 존재하지 않는 도시명 zzz-not-a-city 를 입력해 에러 상태 확인
- 검색어를 비운 채 제출했을 때 안내 문구 확인
- 모바일 폭에서 카드와 검색창이 화면 밖으로 넘치지 않는지 확인
문제가 있으면 코드 수정 전에 원인 후보를 먼저 말해줘.여기서도 "실제로 실행"이 중요합니다. Codex가 코드를 읽고 "아마 될 것 같습니다"라고 답하는 것과, 브라우저에서 직접 입력하고 클릭한 뒤 "3단계에서 에러 메시지가 보이지 않습니다"라고 답하는 것은 완전히 다릅니다.
콘솔과 네트워크 로그까지 함께 보게 하기
화면 검증에서 놓치기 쉬운 것이 콘솔과 네트워크 로그입니다. 사용자 화면은 멀쩡해 보여도 콘솔에는 오류가 쌓이고 있을 수 있습니다. API 요청이 실패했는데 캐시 데이터 때문에 화면이 우연히 정상처럼 보일 수도 있습니다.
Chrome extension이나 브라우저 제어 도구를 사용하면 Codex가 DevTools 맥락을 활용해 웹앱 테스트와 디버깅을 도울 수 있습니다.2 Playwright나 브라우저 MCP를 연결한 경우에도 요청, 응답, 콘솔 로그, 스크린샷을 함께 수집하는 방식으로 검증 품질을 높일 수 있습니다.
초보자는 다음 문장을 프롬프트에 자주 넣으면 좋습니다.
화면 결과만 보지 말고 콘솔 오류와 네트워크 실패도 함께 확인해줘.
문제가 있다면 사용자에게 보이는 증상과 개발자 도구에서 보이는 증상을 구분해서 설명해줘.예를 들어 로그인 흐름에서는 이렇게 요청할 수 있습니다.
브라우저에서 로그인 흐름을 검증해줘.
테스트 계정은 아래 값을 사용해.
이메일: [email protected]
비밀번호: TestPassword123!
확인할 것:
- 로그인 버튼 클릭 후 /dashboard 로 이동하는지
- 실패 시 에러 메시지가 화면에 보이는지
- 콘솔 오류가 없는지
- /api/login 요청의 상태 코드가 기대와 맞는지
비밀번호나 토큰 값은 보고서에 그대로 적지 말고 마스킹해줘.마지막 문장도 중요합니다. Codex가 로그를 정리할 때 민감한 값까지 그대로 적는 것을 막아야 합니다. 테스트 계정이라도 비밀번호, 토큰, 쿠키, 세션 ID는 보고서에 남기지 않는 습관을 들이는 것이 좋습니다.
Playwright와 브라우저 MCP로 반복 가능한 E2E 검증 만들기
한 번 브라우저에서 확인하는 것도 중요하지만, 같은 흐름을 매번 사람이 지시하는 것은 번거롭습니다. 이때 Playwright나 브라우저 제어 MCP를 연결하면 회원가입, 로그인, 관리자 목록 확인 같은 흐름을 반복 가능한 엔드투엔드 테스트로 만들 수 있습니다.
Playwright는 실제 브라우저를 자동으로 실행해 사용자의 행동을 테스트하는 도구입니다. "엔드투엔드"는 사용자가 앱을 처음부터 끝까지 사용하는 흐름을 뜻합니다. 예를 들어 회원가입에서 대시보드 진입까지, 상품 선택에서 결제 직전까지, 관리자 목록에서 상세 페이지 확인까지가 E2E 흐름입니다.
가장 먼저 Codex에게 테스트 후보를 뽑게 합니다.
우리 미니 SaaS 프로젝트에서 Playwright로 자동화할 E2E 시나리오를 제안해줘.
초보자도 유지보수할 수 있게 너무 많은 테스트를 만들지 말고,
가장 중요한 사용자 흐름 5개만 골라줘.
각 시나리오에는 목적, 준비 데이터, 성공 기준을 적어줘.
아직 테스트 파일은 만들지 마.그다음 하나를 선택해 구현하게 합니다.
제안한 시나리오 중 "로그인 후 프로젝트 목록 확인"만 Playwright 테스트로 작성해줘.
조건:
- 테스트 계정은 .env.test 값을 사용
- 실제 결제나 이메일 발송은 하지 않음
- 선택자는 data-testid를 우선 사용
- 테스트 실패 시 스크린샷과 trace를 남기도록 설정
- 기존 테스트 구조가 있으면 그 패턴을 따라갈 것
작성 후 테스트를 실행하고 실패하면 원인을 분석해줘.여기서 data-testid는 테스트가 요소를 찾기 쉽게 붙이는 표시입니다. 예를 들어 버튼에 data-testid="login-button"을 붙이면, 디자인 클래스가 바뀌어도 테스트는 같은 버튼을 안정적으로 찾을 수 있습니다. 초보자는 CSS 클래스나 복잡한 DOM 구조에 의존하는 테스트보다 data-testid를 쓰는 편이 유지보수하기 쉽습니다.
테스트가 실패했을 때는 실패를 단순히 "고쳐줘"라고 하지 말고 재현 단계를 정리하게 해야 합니다.
방금 실패한 Playwright 테스트를 분석해줘.
다음 형식으로 보고해줘.
- 실패한 테스트 이름
- 실패한 단계
- 브라우저에서 실제로 보인 화면 상태
- 콘솔 또는 네트워크 오류
- 재현 단계
- 원인 후보 2개 이상
- 가장 안전한 수정안
수정은 내가 승인한 뒤 진행해줘.이렇게 하면 Codex가 실패 로그를 보고 무작정 코드를 바꾸는 일을 줄일 수 있습니다. E2E 테스트는 실패 원인이 다양합니다. 코드 버그일 수도 있고, 테스트 데이터 문제일 수도 있고, 로딩 대기 시간이 짧아서 생긴 문제일 수도 있습니다. 먼저 원인을 분류해야 합니다.
실전 예제: 회원가입에서 결제 직전 단계까지 검증하기
이제 조금 더 현실적인 예제를 보겠습니다. 미니 SaaS 앱에 회원가입, 로그인, 프로젝트 생성, 요금제 선택, 결제 직전 단계가 있다고 가정하겠습니다. 실제 결제는 수행하지 않습니다. 목표는 사용자가 결제 페이지로 넘어가기 직전까지 흐름이 자연스럽게 이어지는지 확인하는 것입니다.
Codex에게 다음과 같이 요청합니다.
브라우저에서 미니 SaaS의 핵심 가입 흐름을 검증해줘.
실제 결제는 절대 진행하지 마.
테스트 시나리오:
1. /signup 으로 이동
2. 테스트 이메일로 회원가입
3. 회원가입 후 /onboarding 또는 /dashboard 로 이동하는지 확인
4. 새 프로젝트를 하나 생성
5. /pricing 으로 이동
6. Pro 요금제 선택 버튼 클릭
7. 결제 제공자 페이지로 이동하기 직전 또는 테스트 checkout 페이지 진입 직전에서 멈춤
안전 조건:
- 실제 결제 버튼은 누르지 말 것
- 실제 카드 정보 입력 금지
- 테스트 데이터만 사용
- 외부 결제 페이지로 이동하면 URL과 화면 제목만 확인하고 즉시 멈출 것
결과는 테스트한 단계별로 성공/실패를 표시해줘.이 예제에서 가장 중요한 문장은 "실제 결제는 절대 진행하지 마"입니다. Codex가 브라우저를 조작할 수 있게 되면, 결제, 삭제, 권한 변경 같은 작업은 반드시 명확한 금지 조건을 넣어야 합니다.
실패가 발견되었다고 해보겠습니다. 예를 들어 요금제 선택 후 checkout 페이지로 이동하지 않고 빈 화면이 나온다면, Codex에게 이렇게 이어서 요청합니다.
방금 빈 화면이 나온 문제를 수정하기 전에 원인을 조사해줘.
확인할 것:
- 브라우저 콘솔 오류
- 네트워크 요청 실패 여부
- 라우팅 경로가 올바른지
- 서버 로그에 checkout session 생성 오류가 있는지
- 환경변수 누락 가능성
조사 결과를 바탕으로 수정 후보를 2~3개 제안해줘.
가장 작은 수정부터 적용할 수 있게 정렬해줘.좋은 검증은 "실패했다"에서 끝나지 않습니다. 실패한 화면, 실패한 요청, 실패한 코드 경로를 연결해야 합니다. Codex가 이 연결을 도와주면 초보자도 디버깅 흐름을 훨씬 쉽게 따라갈 수 있습니다.
실전 예제: 관리자 목록과 상세 화면 검증하기
관리자 화면은 특히 검증이 중요합니다. 사용자 데이터가 보이고, 삭제나 권한 변경 같은 위험한 기능이 들어가기 때문입니다. 따라서 테스트 계정, 테스트 데이터, 읽기 전용 흐름을 우선 사용해야 합니다.
예를 들어 관리자 페이지에 사용자 목록과 상세 화면이 있다고 가정합니다.
브라우저에서 관리자 화면을 읽기 전용으로 검증해줘.
테스트 관리자 계정만 사용하고, 데이터 수정/삭제/권한 변경은 하지 마.
시나리오:
1. /admin/users 로 이동
2. 사용자 목록이 표시되는지 확인
3. 검색창에 "test"를 입력해 필터링 확인
4. 첫 번째 테스트 사용자의 상세 화면으로 이동
5. 상세 화면에 이메일, 가입일, 상태가 표시되는지 확인
6. 뒤로 가기로 목록에 돌아오는지 확인
절대 하지 말 것:
- 삭제 버튼 클릭
- 권한 변경 저장
- 사용자 export 다운로드
- 실제 고객 데이터 복사
결과를 재현 단계와 함께 보고해줘.관리자 화면에서는 "하지 말 것"이 "할 것"만큼 중요합니다. 특히 Computer Use나 Chrome extension으로 실제 로그인 세션을 사용할 때는 더 그렇습니다. Codex가 누를 수 있는 버튼은 사람도 실수로 누를 수 있는 버튼입니다. 위험한 작업 앞에서는 반드시 멈추게 해야 합니다.
Computer Use로 배포 콘솔과 외부 대시보드 확인하기
Computer Use는 브라우저 밖의 화면까지 다룰 수 있기 때문에 배포 콘솔, 외부 대시보드, 원격 개발 환경 확인에 유용합니다. 예를 들어 Vercel, Render, Datadog, Sentry, Supabase, Stripe 테스트 대시보드처럼 웹 기반 콘솔이지만 실제 로그인 세션과 복잡한 UI가 필요한 작업이 있습니다.
다만 이런 도구들은 대부분 운영 환경과 연결되어 있습니다. 그래서 Codex에게 맡기기 전에 원칙을 정해야 합니다.
최소 권한 계정으로 접속한다.
가능하면 테스트 프로젝트나 staging 환경을 사용한다.
읽기 전용 확인을 먼저 수행한다.
삭제, 결제, 권한 변경, 배포 실행은 사용자 승인 후에만 진행한다.
민감한 토큰, 고객 정보, 결제 정보는 보고서에 남기지 않는다.
예를 들어 배포 콘솔 확인은 이렇게 요청할 수 있습니다.
@Computer Use 배포 콘솔에서 staging 프로젝트의 최근 배포 상태만 확인해줘.
읽기 전용으로 진행하고, 재배포/롤백/환경변수 수정 버튼은 누르지 마.
확인할 것:
- 최근 배포가 성공했는지
- 배포 시간
- 연결된 Git branch
- 빌드 로그에 오류나 경고가 있는지
위험한 버튼이 보이면 누르지 말고 나에게 먼저 물어봐.Sentry 같은 오류 모니터링 도구를 확인할 때도 마찬가지입니다.
@Computer Use Sentry 대시보드에서 staging 환경의 최근 오류를 확인해줘.
이슈를 resolve 처리하거나 assign하지 말고 읽기만 해줘.
상위 3개 오류의 제목, 발생 횟수, 첫 발생 시간, 관련 URL만 요약해줘.
개인정보처럼 보이는 값은 마스킹해줘.Computer Use는 강력하지만, 모든 일에 쓰는 도구는 아닙니다. CLI로 가능한 일은 CLI가 낫고, API나 MCP로 가능한 일은 구조화된 도구가 더 안정적입니다. Computer Use는 "화면을 봐야만 알 수 있는 일" 또는 "GUI로만 가능한 일"에 집중시키는 것이 좋습니다.
위험 작업은 반드시 멈추게 하기
Browser Use와 Computer Use를 쓰기 시작하면 Codex는 더 많은 것을 할 수 있습니다. 더 많은 것을 할 수 있다는 말은, 더 큰 사고도 낼 수 있다는 뜻입니다. 초보자는 다음 네 가지 작업을 고위험으로 분류하면 됩니다.
결제 실행, 환불, 구독 변경
데이터 삭제, 대량 수정, export 다운로드
사용자 권한 변경, 관리자 초대, API key 생성
운영 배포, 롤백, 환경변수 변경
이 작업들은 Codex에게 완전히 금지하거나, "버튼 앞에서 멈추고 사용자 승인을 기다려라"는 규칙을 넣어야 합니다.
위험 작업 안전 규칙:
결제, 삭제, 권한 변경, 운영 배포, 환경변수 수정이 필요한 단계에서는
작업을 실행하지 말고 멈춰서 나에게 승인 요청을 해줘.
승인 전에는 버튼을 클릭하거나 저장하지 마.이 문장은 여러 프롬프트에 반복해서 붙여도 좋습니다. 더 나아가 AGENTS.md에 프로젝트 공통 규칙으로 넣어둘 수도 있습니다.
## Browser / Computer Use Safety
Codex must not perform payment, deletion, permission changes, production deployment, rollback, or environment variable changes without explicit user approval.
For external dashboards, prefer read-only inspection and test/staging data.
Mask secrets, tokens, cookies, passwords, and personal data in reports.이렇게 프로젝트 기억에 넣어두면 매번 같은 안전 규칙을 길게 쓰지 않아도 됩니다. 다만 위험한 작업을 맡길 때는 프롬프트에도 다시 한 번 명시하는 편이 안전합니다.
검증 보고서를 남기는 습관
브라우저 검증의 결과는 말로 흘려보내면 안 됩니다. "확인했음"이라는 한 줄은 나중에 아무 도움이 되지 않습니다. 어떤 환경에서, 어떤 시나리오를, 어떤 데이터로 테스트했는지 남겨야 합니다. 그래야 같은 문제가 다시 생겼을 때 재현할 수 있고, PR 리뷰에서도 검증 근거로 사용할 수 있습니다.
Codex에게 다음 템플릿으로 보고서를 남기게 하세요.
## 검증 보고서
### 테스트한 환경
- 브라우저/도구:
- 앱 URL:
- 브랜치 또는 커밋:
- 실행 명령:
- 테스트 계정/데이터:
### 실행한 시나리오
1.
2.
3.
### 발견한 문제
| 번호 | 심각도 | 화면/기능 | 문제 설명 | 재현 가능 여부 |
|---|---|---|---|---|
| 1 | | | | |
### 스크린샷/로그
- 스크린샷:
- 콘솔 로그:
- 네트워크 오류:
- Playwright trace:
### 재현 단계
1.
2.
3.
### 수정 여부
- 수정한 파일:
- 수정 요약:
- 재검증 결과:
- 남은 이슈:이 템플릿을 프롬프트로 사용할 때는 이렇게 요청합니다.
방금 브라우저에서 검증한 결과를 아래 형식의 검증 보고서로 정리해줘.
테스트한 환경, 실행한 시나리오, 발견한 문제, 스크린샷/로그,
재현 단계, 수정 여부를 반드시 포함해줘.
민감한 값은 마스킹하고, 추측과 실제 확인한 사실을 구분해줘."추측과 실제 확인한 사실을 구분해줘"라는 문장이 중요합니다. Codex가 화면에서 본 사실과 코드상 추론을 섞어 말하면 나중에 혼란이 생깁니다. 예를 들어 "네트워크 요청이 500으로 실패했습니다"는 확인한 사실입니다. "환경변수가 누락된 것 같습니다"는 원인 후보입니다. 둘은 구분되어야 합니다.
검증과 수정이 하나의 작업 흐름이 되는 방식
이제 전체 흐름을 하나로 묶어보겠습니다. Codex로 앱을 만들 때 가장 이상적인 루프는 다음과 같습니다.
Codex가 기능을 구현한다.
로컬 서버를 실행한다.
인앱 브라우저나 Chrome extension으로 실제 화면을 연다.
사용자 시나리오를 실행한다.
화면, 콘솔, 네트워크 로그를 확인한다.
실패하면 재현 단계와 원인 후보를 정리한다.
가장 작은 수정안을 적용한다.
같은 시나리오를 다시 실행한다.
검증 보고서를 남긴다.
필요한 경우 Playwright 테스트로 고정한다.
이 루프를 프롬프트 하나로 표현하면 다음과 같습니다.
이번 작업은 구현과 실제 화면 검증을 한 번의 흐름으로 진행해줘.
목표:
사용자가 프로젝트를 생성한 뒤 프로젝트 상세 화면으로 이동할 수 있어야 한다.
작업 순서:
1. 관련 코드를 확인하고 필요한 최소 수정만 한다.
2. 로컬 서버를 실행한다.
3. 브라우저에서 실제 사용자처럼 프로젝트 생성 흐름을 테스트한다.
4. 화면 결과, 콘솔 오류, 네트워크 오류를 확인한다.
5. 실패하면 재현 단계와 원인 후보를 먼저 보고한다.
6. 승인 후 수정하고 같은 흐름을 다시 테스트한다.
7. 마지막에 검증 보고서를 남긴다.
제약:
- 인증 구조는 바꾸지 마.
- 데이터베이스 스키마 변경이 필요하면 먼저 물어봐.
- 삭제나 권한 변경 작업은 하지 마.이런 프롬프트는 Codex를 단순 코드 작성자가 아니라 작은 개발자 겸 QA 파트너처럼 움직이게 합니다. 중요한 점은 Codex에게 "끝의 기준"을 알려주는 것입니다. 코드 수정이 끝이 아니라, 실제 화면에서 성공 흐름을 확인하고 보고서까지 남기는 것이 완료 기준입니다.
자주 생기는 문제와 해결법
처음 Browser Use나 Computer Use를 쓰면 몇 가지 문제를 자주 만납니다. 겁낼 필요는 없습니다. 대부분은 도구 선택, 권한, 서버 상태, 테스트 데이터 문제입니다.
로컬 페이지가 열리지 않는다면 먼저 개발 서버가 실행 중인지 확인해야 합니다. npm run dev가 켜져 있는지, 포트 번호가 맞는지, 방화벽이나 샌드박스 때문에 접근이 막히지 않았는지 봅니다. Codex에게는 "현재 dev server 포트와 접속 가능한 URL을 확인한 뒤 브라우저를 열어줘"라고 요청하면 됩니다.
화면은 열리는데 클릭이 안 된다면 요소가 로딩 중이거나, 버튼 위에 다른 레이어가 덮여 있거나, 모바일 메뉴가 닫히지 않은 상태일 수 있습니다. 이때는 스크린샷과 DOM 상태, 콘솔 오류를 함께 확인하게 합니다.
Computer Use가 화면을 보지 못한다면 macOS 권한을 다시 확인해야 합니다. 공식 문서에 따르면 Codex가 대상 앱을 보고 조작하려면 화면 기록과 손쉬운 사용 권한이 필요합니다.3 권한을 부여한 뒤에도 안 되면 Codex App을 재시작하는 것이 좋습니다.
Chrome extension이 로그인된 사이트를 보지 못한다면 확장이 설치된 Chrome 프로필이 맞는지 확인합니다. 업무용 프로필과 개인 프로필을 나눠 쓰는 경우, Codex가 연결된 프로필과 실제 로그인된 프로필이 다를 수 있습니다. 또한 새 사이트 접근은 허용 요청이 필요할 수 있으므로, Codex가 묻는 승인 창을 놓치지 않아야 합니다.
Playwright 테스트가 자주 흔들린다면 테스트가 너무 세부 구현에 의존하고 있을 가능성이 큽니다. 버튼의 CSS 클래스나 복잡한 DOM 순서 대신 사용자에게 보이는 이름, 역할, data-testid를 우선 사용하게 하세요. 그리고 로딩이 끝나기 전에 클릭하지 않도록 명확한 대기 조건을 넣게 해야 합니다.
초보자를 위한 추천 시작 순서
처음부터 Computer Use로 배포 콘솔을 조작하거나 결제 흐름을 검증하려고 하면 부담이 큽니다. 다음 순서로 익숙해지는 것을 추천합니다.
1단계에서는 인앱 브라우저로 로컬 웹앱의 홈 화면만 확인합니다. 레이아웃, 문구, 모바일 깨짐을 보는 정도면 충분합니다.
2단계에서는 폼 입력과 버튼 클릭을 맡깁니다. 할 일 추가, 검색, 모달 열기처럼 위험하지 않은 조작부터 시작합니다.
3단계에서는 콘솔과 네트워크 로그를 함께 확인하게 합니다. 화면에 보이는 문제와 개발자 로그를 연결하는 감각을 익힙니다.
4단계에서는 Playwright 테스트 하나를 만듭니다. 로그인이나 프로젝트 생성처럼 앱의 핵심 흐름 하나만 자동화합니다.
5단계에서는 Chrome extension이나 Computer Use를 사용해 로그인된 외부 도구를 읽기 전용으로 확인합니다. 삭제, 결제, 권한 변경은 여전히 하지 않습니다.
이 순서대로 가면 Codex에게 화면을 맡기는 일이 무섭지 않습니다. 작은 화면 확인에서 시작해 점점 실제 업무 흐름으로 확장하면 됩니다.
마무리: 앱은 코드가 아니라 경험으로 완성된다
Codex로 앱을 만든다는 것은 이제 파일을 생성하고 함수를 고치는 일만 뜻하지 않습니다. 사용자가 실제로 보는 화면을 확인하고, 버튼을 누르고, 실패 상태를 재현하고, 로그를 살펴보고, 수정 후 다시 검증하는 일까지 포함합니다.
인앱 브라우저는 로컬 웹앱을 빠르게 확인하는 안전한 첫 번째 창입니다. Chrome extension은 로그인된 브라우저 상태가 필요한 작업을 도와줍니다. Computer Use는 브라우저 밖의 앱과 콘솔까지 확인할 수 있는 더 넓은 손입니다. Playwright와 브라우저 MCP는 이 검증을 반복 가능한 테스트로 바꿔줍니다.
하지만 가장 중요한 것은 도구 이름이 아닙니다. 코드를 쓴 뒤 실제 화면에서 확인하는 습관입니다. Codex에게 "구현해줘"라고만 말하지 말고 "실제로 열어보고, 눌러보고, 실패하면 재현 단계와 수정 후보를 알려줘"라고 말하세요.
그 순간 Codex는 코드를 작성하는 조수에서, 앱이 정말 작동하는지 함께 확인하는 개발 파트너가 됩니다.
참고
1In-app browser - Codex app | OpenAI Developers
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.