테스트 통과가 브라우저 검수 완료를 뜻하나요?

아닙니다. Python 테스트 7개와 JavaScript 시뮬레이션 9개가 통과한 것입니다. 실제 브라우저, 세 화면 너비, 결함 발견 여부는 검증하지 않았습니다.

폼이 실제 저장됐는지 어떻게 확인하나요?

기존 수신 기록을 저장하고 이번 실행에만 쓰는 가상 이메일 주소를 제출합니다. 기존 기록이 그대로이며 일치하는 새 기록 하나만 추가됐는지 확인합니다. 성공 문구만으로는 부족합니다.

데스크톱 창 너비 변경이 모바일 테스트인가요?

지정 CSS 뷰포트의 레이아웃 확인입니다. 실제 휴대전화, 터치, 키보드, 기기 성능을 검증한 것은 아닙니다.

수정본에서는 왜 다른 주소를 쓰나요?

재검증 직전에 수신 기록을 다시 저장하고 새 가상 이메일 주소를 사용하면 과거 기록과 구분하고 중복을 확인할 수 있습니다. 두 실행의 근거를 각각 보관하세요.

Codex Computer Use로 랜딩 페이지 점검하기: 로컬 실습

랜딩 페이지 점검은 “괜찮아 보인다”가 아니라 다른 사람이 재현할 수 있는 결과로 끝나야 합니다. 이 실습은 깨진 링크, 저장하지 않고 성공을 표시하는 폼, 좁은 화면에서 살펴볼 레이아웃을 가진 가상 페이지를 제공합니다. 같은 절차로 비교할 수정 버전도 있습니다.

QA 실습 자료 받기. Python 서버, 두 페이지, 테스트, 결과 템플릿, 정답 설명이 포함됩니다. UI는 영어입니다. 이 글은 실제 브라우저 조작이나 화면 검수가 완료됐다고 주장하지 않습니다.

로컬 서버 시작하기

Python 3.9 이상을 준비하고 압축을 푼 qa-kit 폴더에서 실행합니다.

python3 -B server.py --port 8876

서버는 127.0.0.1에서만 요청을 받습니다. 허용된 브라우저에서 터미널에 출력된 주소를 엽니다. 포트가 사용 중이면 빈 포트를 고르고 계획의 주소를 모두 맞추되, 기존 접근 거부를 우회하는 데 사용해서는 안 됩니다. 종료할 때는 Ctrl-C를 누릅니다.

/는 결함 버전, /fixed는 수정 버전, /submissions는 로컬 수신 기록입니다. @example.test로 끝나는 가상 주소만 사용하세요. 실제 연락처, 구매, 외부 폼 전송은 필요하지 않습니다.

답을 먼저 알려주지 않기

Codex에 탐색 링크, 폼, 1440·390·320 CSS 픽셀 너비의 레이아웃을 점검하도록 요청합니다. 기대 결과와 실제 결과를 구분하고 증거를 보존하되 페이지는 수정하지 않게 합니다. 첫 점검에는 소스와 정답 설명을 주지 않아, 구현 설명을 관찰 결과로 옮겨 적지 않도록 합니다.

그래도 이것은 교육용 예시이며 블라인드 벤치마크는 아닙니다. 의도적으로 넣은 소수 결함으로 실제 사이트의 결함 탐지율을 계산할 수 없습니다.

첫 점검에 사용할 전체 지시문

첫 테스트에는 아래 지시문만 전달합니다. 이후에 나오는 결함 설명, 소스와 정답을 함께 주지 마세요. 환경마다 제어 방식이 다르므로 이미 사용이 허용된 브라우저를 선택합니다.

로컬 실습 페이지 http://127.0.0.1:8876/를 점검한다.
소스나 정답을 읽지 않고 페이지를 수정하지 않는다.
브라우저 버전, 시각, URL, 실제 뷰포트 크기를 기록한다.
1. /submissions의 현재 기록을 이번 실행의 기준으로 저장한다.
2. Working guide와 Pricing을 열어 최종 URL, 제목, 내용 적합성을 기록한다.
3. 빈 값, not-an-email, qa-run1@example.test를 각각 시험한다.
   매번 화면 피드백을 기록하고 /submissions를 새로 고쳐 결과를 저장한다.
4. 너비 1440, 390, 320 CSS 픽셀에서 잘림, 문서 전체의 가로 넘침,
   입력과 버튼 사용 가능 여부를 확인한다.
   크기를 설정하거나 읽을 수 없으면 pending으로 남기고 추측하지 않는다.
5. 재현 단계, 기대 결과, 실제 결과, 근거 경로를 보고한다.
   실행하지 않은 항목을 통과로 표시하지 않는다.
6. /fixed에서 수신 기록을 다시 저장하고 qa-run2@example.test로 반복한다.
7. 임시 뷰포트 설정을 복구한다. 실제 연락처는 입력하지 않는다.
접근이 거부되면 해당 자원을 기록하고 멈춘다. 우회하지 않는다.
관찰과 추측을 구분한다. 성공 문구를 저장 증거로 보지 않고,
데스크톱 창 너비 변경을 실제 휴대전화 테스트로 부르지 않는다.

run-01/original/과 run-01/fixed/를 나누고 각각 receiver-before.json, receiver-after.json, 너비별 화면과 보고서를 보관하면 비교하기 좋습니다. 이는 권장 파일 구성이지 이번에 실제로 찍은 화면이 있다는 뜻은 아닙니다.

링크는 목적지 내용까지 확인하기

Working guide와 Pricing을 각각 누르고 최종 URL과 제목을 적은 뒤 돌아옵니다. 404는 실패지만, 200이어도 약속한 내용과 무관하면 실패입니다. 수정된 Pricing은 존재하는 아무 페이지가 아니라 가상의 가격 설명으로 이동해야 합니다.

폼 입력을 세 가지로 나누기

다른 탭에서 /submissions를 열어 매번 기존 기록 수를 확인합니다. 입력 후 수신 기록 탭을 새로고침해서 오래된 화면을 새 결과로 오인하지 않게 합니다.

입력	기대 결과
빈 값	유용한 입력 안내, 새 기록 없음
`not-an-email`	형식 오류 안내, 새 기록 없음
`qa-run1@example.test`	화면 피드백과 정확히 한 개의 일치하는 새 기록

수정 버전에는 qa-run2@example.test를 사용하고, 이후에도 매번 새로운 주소를 씁니다. 건수와 실제 주소를 함께 확인하세요. 성공 배너만으로 저장을 증명할 수 없으며 중복 저장도 문제입니다.

결함 버전이 저장 없이 성공을 표시한다는 것은 소스에 설정된 성질이지, 브라우저 점검에서 이미 발견했다는 결과가 아닙니다. 정답과 이번 관찰을 분리해서 기록합니다.

개수뿐 아니라 수신 기록 내용 비교하기

아래 JSON은 판정 규칙을 설명하는 예시 데이터입니다. 브라우저에서 수집한 결과가 아닙니다.

{
  "before": [{"email": "old@example.test"}],
  "after": [
    {"email": "old@example.test"},
    {"email": "qa-run1@example.test"}
  ]
}

1개가 2개로 늘었다는 사실만으로는 부족합니다. 기존 기록이 그대로이고 추가된 주소가 이번 입력과 같은지 확인해야 합니다. 같은 주소가 두 번 추가되면 중복 제출이며 다른 주소라면 다른 실행의 기록일 수 있습니다. 실제 근거는 시간 필드까지 완전하게 저장하고 예시에 맞춰 이메일만 남기지 마세요.

빈 값과 잘못된 형식에서는 유용한 검증 안내와 추가 0개를 기대합니다. 수정본의 올바른 가상 이메일 주소에서는 일치하는 추가 1개를 기대합니다. 화면과 수신 측을 함께 보면 입력 검증, 거짓 성공 문구, 실제 저장을 구분할 수 있습니다. 이것이 다른 운영 폼의 신뢰성을 입증하지는 않습니다.

좁은 화면은 크기를 명시하기

각 너비에서 지표 카드, 탐색 영역, 입력창, 버튼을 살펴봅니다. 가로 방향으로 넘치는 콘텐츠, 가려진 글자, 접근하기 어려운 조작 요소를 기록하고 실제 뷰포트 크기와 스크린샷을 함께 저장합니다.

데스크톱 브라우저의 너비 변경은 뷰포트 시뮬레이션입니다. 실제 휴대폰의 터치, 키보드, 브라우저 동작과 성능까지 시험한 것은 아닙니다. 끝나면 임시 설정을 복원합니다.

원본과 수정본을 같은 기준으로 점검하기

다음은 소스에서 확인한 설계 동작입니다. 브라우저를 실행한 뒤 실제 결과 열을 별도로 작성하세요.

사례	원본 설계	수정본 설계	수집할 근거
Pricing	존재하지 않는 경로	가상 요금 안내 페이지	최종 URL, 제목, 확인 가능하면 응답 상태
빈 값·잘못된 형식	저장 없이 성공 표시	검증 안내, 추가 없음	피드백과 새로 고친 기록
올바른 가상 이메일 주소	저장 없이 성공 표시	일치하는 기록 1개 저장	전체 전후 기록과 입력 주소
좁은 지표 행	최소 너비 650 CSS 픽셀	카드 줄바꿈 허용	실제 뷰포트, 넘침, 조작 결과

390과 320 너비에서는 카드뿐 아니라 입력창과 버튼에 접근해 사용할 수 있는지도 봅니다. 표 자체의 컨테이너 안에서 가로 스크롤되는 것과 문서 전체가 넘치는 것은 다릅니다. MDN overflow 설명은 이 원리를 설명하지만 실습 페이지가 시각 검증을 통과했다는 근거는 아닙니다.

재현 가능한 보고서 만들기

URL, 환경, 정확한 입력, 단계, 기대 결과, 실제 결과, 증거 위치를 남깁니다. 빈 값 허용, 잘못된 형식 허용, 거짓 성공 표시는 하나의 처리 함수에서 생길 수 있으므로 독립적인 원인 세 개로 부풀리지 않습니다.

첫 점검 후 정답과 비교해 누락과 오탐도 기록합니다. 새 주소로 /fixed를 반복 점검하고, 새 작업에서 문서만 보고 같은 절차를 재현할 수 있는지 확인합니다.

실제로 쓸 수 있는 결함 보고서 형식

아래는 소스에 근거해 작성한 교육용 예시입니다. 브라우저가 발견한 문제나 이미 찍은 스크린샷을 가장하지 않습니다.

항목	예시
ID·범위	`FORM-01`, 원본 `/`
준비	기존 수신 기록 저장, 이번 실행에만 쓰는 가상 이메일 주소 준비
단계	`qa-run1@example.test` 입력, 한 번 제출, `/submissions` 새로 고침
기대	기존 기록 불변, 일치하는 기록 1개 추가
소스상 동작	성공을 표시하지만 저장하지 않음
브라우저 관찰	실행 후 작성, 현재는 미확인
근거	실행 후 실제 전후 기록과 화면 첨부
확인할 영향	사용자가 저장된 것으로 오해할 가능성
재검증	`/fixed`, 재검증 직전에 저장한 수신 기록, `qa-run2@example.test`

실제 보고서에서는 소스상 동작을 직접 관찰한 결과로 바꾸고 같은 실행의 근거를 붙입니다. 수신 기록을 볼 수 없다면 저장 여부는 미확인입니다. 화면이 없거나 탭이 오래됐다는 이유만으로 서버 장애를 단정하지 않습니다. 세 입력은 세 테스트 사례지만 같은 구현 문제에서 나올 수 있으므로 사례 수와 근본 결함 수를 구분합니다.

결과가 불분명할 때 확인할 것

증상	다음 확인	피할 판단·행동
연결할 수 없음	서버 실행 여부와 허용 환경의 주소	곧바로 페이지 결함으로 단정
명시적 접근 거부	자원 기록 후 정상 권한 설정으로 해결	다른 도구·호스트로 우회
포트 사용 중	본인의 불필요한 실행을 중지하거나 허용된 빈 포트를 일관되게 사용	거부 우회를 위한 포트 변경
이전 기록 존재	현재 수신 기록을 다시 저장하고 새 가상 이메일 주소 사용	과거 데이터를 이번 성공으로 계산
성공 문구만 표시	수신 측을 새로 고치고 양쪽 관찰 보존	연속 클릭으로 재시도 혼합
휴대전화처럼 보이는 화면	CSS 크기와 브라우저 환경 기록	실제 기기 테스트로 표시

서버는 로컬 submissions.jsonl에 기록하므로 재시작만으로 없어지지 않을 수 있습니다. 실행 증거를 보관하고 초기 상태가 필요하면 별도의 새 압축 해제본을 사용합니다. 경쟁사 조사 튜토리얼 역시 관찰한 사실과 미해결 항목을 나눠 기록합니다.

확인된 것은 오프라인 테스트

Python 3.9.6과 Node.js 24.13.0에서 Python 처리기 테스트 7개와 JavaScript 폼 시뮬레이션 9개가 통과했습니다. 새로 압축을 푼 사본에서도 통과했습니다.

python3 -B -m unittest discover -s . -p 'test_*.py' -v
node test_form.mjs

Python은 잘못된 길이·JSON, 가상 주소 검증, 기록 저장, 경로, 템플릿 치환을 검사합니다. JavaScript는 모의 document와 fetch로 폼 코드를 실행합니다. 브라우저를 열거나 네트워크 요청을 보내지 않습니다.

따라서 실제 전송, 레이아웃, Codex의 결함 발견 능력은 입증되지 않았습니다. 세 너비의 캡처와 수정 전후 브라우저 비교도 미검증입니다. 접근성·보안·성능·기기별 종합 검사를 대체하지 않습니다.

완료 여부를 코드로 판단하는 예시는 오프라인 컨트롤러, 브라우저 연결 문제는 권한 안내를 참고하세요.