AI가 고친 화면이 멀쩡해 보여도, 공유 전에 브라우저에서 확인할 4곳

AI가 버튼이나 폼을 고친 뒤 "이제 됩니다"라고 말하면, 페이지를 한 번 열어보고 링크를 공유하고 싶어집니다. 하지만 첫 화면이 보이는 일과 사용자가 끝까지 흐름을 통과하는 일은 다릅니다. 입력값이 비어 있을 때의 반응, 저장 뒤의 요청, 휴대폰 폭에서 사라지는 버튼은 처음 한 번의 화면 확인에서 빠지기 쉽습니다.

공유나 배포 전에 아래 네 곳만 같은 순서로 확인합니다. 바뀐 경로 → 입력과 오류 → 네트워크 결과 → 좁은 화면입니다. 하나라도 멈추면 다음 항목으로 넘어가지 말고, 첫 실패 장면을 AI에게 다시 고칠 근거로 전달합니다. 이 글은 품질을 보증하는 시험이 아니라, AI 수정 뒤 눈에 띄는 회귀를 빨리 잡는 짧은 스모크 체크입니다.

Tap to zoom

먼저 수정 범위가 넓었다면 AI가 바꾼 파일 범위를 먼저 좁히는 방법을 보고, 브라우저에서 확인할 기능 하나를 골라 둡니다. 배포 전 환경 변수나 비밀값이 보인다면 Git에 .env가 섞이기 전 확인하는 순서를 먼저 처리합니다.

화면을 보는 대신 사용자의 한 번의 경로를 끝까지 밟습니다

첫 번째는 "페이지가 열렸나"가 아니라 바뀐 기능을 실제 사용 순서로 한 번 끝까지 밟았나입니다. 예를 들어 AI가 저장 버튼을 고쳤다면, 페이지 진입만 하지 말고 값을 넣고 버튼을 누른 뒤 성공 메시지나 다음 화면까지 갑니다. 링크를 바꿨다면 클릭 후 주소와 돌아오기 동작까지 봅니다.

여기서 확인할 것은 많지 않습니다.

1. 시작 위치에서 바뀐 버튼·링크·입력이 보이는가
2. 클릭이나 입력 뒤 사용자가 기다리는 다음 상태가 나타나는가
3. 뒤로 가기나 새로고침 뒤에도 흐름이 엉뚱한 곳으로 가지 않는가

한 항목이 실패하면 "화면이 이상해요"라고 넓게 요청하지 않습니다. 어느 페이지에서 → 무엇을 눌렀고 → 무엇이 보여야 하는데 → 실제로 무엇이 보였는지를 적습니다. 이 형식은 AI가 불필요한 파일까지 다시 고치는 일을 줄입니다.

빈 입력과 잘못된 입력도 한 번은 일부러 만듭니다

두 번째는 정상 입력만 확인하고 끝내지 않는 것입니다. 이름이나 이메일처럼 필수 입력이 있는 화면이라면 빈 값으로 제출해 보고, 형식이 맞지 않는 값도 넣어 봅니다. 브라우저의 제약 조건 검증은 제출을 막거나 유효성 상태를 드러낼 수 있으므로, 화면에 오류 문구가 보이는지만이 아니라 사용자가 다음 행동을 알 수 있는지를 봐야 합니다. MDN의 클라이언트 측 폼 검증 안내도 이 검증 흐름과 제약 조건을 설명합니다.

Tap to zoom

이때 멈춰야 하는 신호는 단순합니다. 오류가 나도 제출이 진행되거나, 오류 문구가 남은 채 다시 시도할 수 없거나, 버튼을 눌렀는데 아무 상태 변화가 없다면 수정 요청에 넣습니다. 반대로 한 번의 빈 입력이 통과했다고 모든 예외가 해결된 것은 아닙니다. 지금 확인하는 범위는 방금 바뀐 사용자 흐름 하나로 제한합니다.

결과가 보이지 않으면 네트워크에서 방금 한 요청을 찾습니다

세 번째는 버튼을 누른 뒤 데이터가 실제로 오갔는지 보는 단계입니다. Chrome DevTools의 Network 패널은 열어 둔 동안의 네트워크 활동을 기록하고, 새로고침 뒤 요청 목록과 상태 코드를 보여 줍니다. Chrome DevTools의 Network 활동 확인 문서에 따르면 각 행에서 상태, 종류, 시작 원인, 전송 크기와 시간을 살필 수 있습니다.

방법은 간단합니다. DevTools를 열고 Network 탭을 켠 다음, 문제가 난 행동을 한 번 더 합니다. 방금 생긴 요청을 찾아 상태와 응답을 봅니다. 200이라는 숫자만 찾는 것이 목적은 아닙니다. 저장을 눌렀다면 저장 요청이 생겼는지, 실패라면 어떤 응답이 왔는지, 화면의 메시지와 요청 결과가 서로 맞는지를 연결합니다.

네트워크에 아무 요청도 없으면 클릭 처리나 입력 검증 단계로 돌아가야 합니다. 요청은 생겼는데 실패했다면 응답 내용과 상태를 기록합니다. 그러면 AI에게 "고쳐 주세요" 대신 아래처럼 범위가 좁은 요청을 보낼 수 있습니다.

페이지: /settings/profile
재현: 이름을 바꾸고 저장을 눌렀다.
기대: 저장 완료 메시지가 보이고 새로고침 뒤에도 이름이 남는다.
실제: 버튼은 눌리지만 완료 메시지가 없고, Network의 PATCH 요청은 500이다.
제한: 이 요청 처리와 화면 메시지만 확인하고 다른 파일 구조는 바꾸지 말아 달라.

좁은 화면에서 같은 경로를 한 번 더 통과시킵니다

마지막은 창 폭을 좁혀 같은 핵심 행동을 한 번 더 하는 일입니다. 반응형 웹은 보는 환경에 따라 배치와 크기가 바뀌므로, 데스크톱에서 보였던 버튼이 좁은 폭에서는 가려지거나 겹칠 수 있습니다. web.dev의 반응형 웹 디자인 기초는 다양한 환경에 맞춰 콘텐츠가 적응해야 한다는 점을 짚습니다.

모든 기기를 흉내 낼 필요는 없습니다. 창을 좁히거나 기기 도구 모음으로 폭을 바꾼 뒤, 첫 번째에서 고른 행동 하나를 다시 합니다. 다음 세 가지 중 하나라도 있으면 멈춥니다.

• 버튼이나 오류 문구가 화면 밖으로 밀린다.
• 입력 중 키보드나 고정 영역 때문에 제출 버튼이 보이지 않는다.
• 카드·메뉴가 겹쳐서 탭할 대상이 바뀐다.

자주 반복되는 흐름이라면 나중에 자동 확인으로 옮길 수 있습니다. Playwright의 assertion 문서는 웹용 assertion이 기대 조건이 맞거나 시간 제한에 닿을 때까지 재시도할 수 있다고 설명합니다. 다만 처음부터 테스트 코드를 크게 만들기보다, 수동으로 반복해도 가치가 큰 한 경로부터 옮기는 편이 안전합니다.

네 곳을 통과해도 멈출 때가 있습니다

이 체크는 AI가 만든 변경을 공유 전에 다시 보는 최소 루틴입니다. 보안, 접근성, 성능, 모든 브라우저와 기기에서의 동작을 보증하지는 않습니다. 결제·로그인·개인정보처럼 실패 비용이 큰 흐름이라면 실제 서비스의 테스트 기준과 리뷰 절차를 더 붙여야 합니다.

오늘은 가장 최근에 AI가 고친 화면 하나를 열어 네 곳만 적어 봅니다. 첫 실패가 없다면 그 기록을 남기고 다음 작업으로 넘어갑니다. 실패가 있다면 그 화면, 행동, 기대 결과, 실제 결과를 한 묶음으로 보내면 됩니다. AI의 완료 메시지보다 먼저 믿을 것은 재현 가능한 브라우저 결과입니다.

이 글은 AI 코딩과 개발 학습을 위한 일반 정보 제공 목적입니다. 도구, 모델, 커리어, 요금과 버전은 시점에 따라 달라질 수 있으므로 배포나 도입 전 공식 문서와 최신 릴리스 노트를 확인하세요.

참고 출처

• Inspect network activity: Chrome for Developers
• Client-side form validation: MDN
• Assertions: Playwright
• Responsive web design basics: web.dev