AI가 고친 웹페이지 버튼, 보내기 전에 확인하는 법: Git·Playwright 직접 실험

2026. 7. 25 (토) · 약 10분

AI에게 ‘공지 버튼을 추가해 달라’고 부탁한 뒤 코드를 훑어보고 바로 배포하면, 버튼 하나가 아무 반응 없이 멈춘 채 독자에게 닿을 수 있다. 이번에는 개인정보가 없는 로컬 공지 페이지에서 클릭 함수가 빠진 상태를 일부러 만들었다. 실제 브라우저로 버튼을 눌러 ReferenceError와 화면 정지를 확인한 뒤, 변경 한 덩어리만 고쳐 Git 커밋으로 남기고 다시 같은 버튼을 눌렀다. 목표는 AI의 답변을 평가하는 일이 아니라, 작은 수정도 보내기 전에 확인할 수 있는 짧은 안전망을 만드는 것이다.

업무자동화 실험

실행 기록 · Git 공식 문서 · 2026. 7. 25

AI 수정 버튼을 실제 클릭으로 검증한 Git·Playwright 실험

로컬 공지 페이지에서 빠진 클릭 함수를 실제 브라우저 오류로 확인하고, 작은 Git 복구 커밋 뒤 같은 버튼을 다시 눌러 결과를 비교했다.

AI 수정안은 ‘완성’이 아니라 클릭할 후보

문구와 버튼을 한 번에 고쳐 주는 AI 답변은 편하지만, 화면에서 가장 중요한 연결 하나가 빠질 수 있다. 이번 테스트에서는 공지 페이지의 ‘공지 열기’ 버튼에 showNotice() 호출만 남기고 함수를 일부러 넣지 않았다. 기대 결과는 클릭 뒤 안내문이 바뀌는 것이었다. 실제로는 브라우저 콘솔에 ReferenceError: showNotice is not defined가 기록됐고, 안내문은 ‘아직 공지를 열지 않았습니다.’에서 멈췄다. 이 글의 화면과 로그는 외부 계정·실서비스가 아닌 임시 로컬 페이지에서만 얻었다.

격리 환경과 준비한 입력

macOS에서 Python 3.9.6의 http.server로 127.0.0.1:8765만 열고, Node 20.20.2와 Playwright CLI로 그 주소를 읽었다. 입력은 제목, 버튼, 안내문만 있는 한 장의 HTML이었다. 버튼의 onclick에는 존재하지 않는 함수 이름을 두었고, 개인정보·토큰·외부 API는 사용하지 않았다. Git 저장소도 이 임시 폴더 안에서만 만들었다.

python3 -m http.server 8765 --bind 127.0.0.1 --directory /tmp/button-check
# 별도 터미널에서
playwright-cli open http://127.0.0.1:8765
playwright-cli snapshot
# snapshot의 ‘공지 열기’ 버튼을 클릭

실제 실패 화면. 버튼을 클릭했지만 안내문은 그대로였고, 같은 클릭에서 브라우저 콘솔은 showNotice가 정의되지 않았다고 기록했다.

오류를 본 뒤 바꾼 것은 한 함수뿐

실패를 확인한 뒤에는 페이지 디자인이나 문구를 다시 만들지 않았다. 안내문 요소를 찾아 실제 공지 문자열을 넣는 showNotice 함수만 추가했다. 그리고 git diff --check로 공백 오류가 없는지 먼저 확인하고 그 한 파일만 커밋했다. Git 공식 문서의 restore는 작업 트리의 변경을 특정 상태로 되돌릴 수 있다고 설명한다. 이번에는 함수 하나를 복구한 커밋을 남겼으므로, 다음 실험에서 문제가 생겨도 그 직전 상태와 비교하거나 되돌릴 기준이 남는다.

function showNotice() {
  document.querySelector('#notice').textContent =
    '공지: 금요일 16시에 문서 검토를 시작합니다.';
}

728x90

 

같은 로컬 버튼을 두 번 클릭한 결과

상태	클릭 뒤 화면	콘솔	다음 행동
함수 누락	안내문 그대로	ReferenceError	함수 존재와 선택자 확인
함수 복구	공지 문구로 갱신	새 JavaScript 오류 없음	diff 확인 후 커밋

복구 커밋 뒤 같은 버튼을 실제로 다시 누른 화면. 안내문이 공지 내용으로 바뀌어 기대 결과와 맞는지 확인했다.

화면 확인과 Git 기록은 서로 다른 안전망

브라우저 클릭은 사용자가 보는 결과를 확인하고, Git diff는 무엇이 바뀌었는지 확인한다. 둘 중 하나만으로는 부족하다. 화면이 정상이어도 무관한 파일이 섞일 수 있고, diff가 작아도 이벤트 연결이 틀릴 수 있다. 그래서 수정 전후 같은 버튼을 누르고, 커밋 전에는 diff와 diff --check를 보는 순서를 사용했다.

실제 화면이 아니라, 이번 실험의 클릭·오류 확인·작은 복구·재클릭 순서를 설명하는 기사 전용 도식이다.

실패를 키우지 않는 재사용 체크리스트

• 실서비스가 아니라 복사한 테스트 페이지와 가짜 문구로 먼저 확인한다.
• 한 번에 한 버튼 또는 한 사용자 흐름만 고르고, 기대 결과를 짧은 문장으로 적는다.
• 클릭 뒤 화면 변화와 브라우저 콘솔 오류를 같이 본다.
• 오류가 나면 큰 재작성 대신 함수·선택자·데이터 한 연결씩 좁힌다.
• 커밋 전 git diff --check를 실행하고, 동작한 상태를 작은 커밋으로 남긴다.
• 토큰·개인정보·운영 URL은 로그와 캡처에 넣지 않는다.

적용 범위와 되돌리는 방법

이 실험은 정적 HTML 버튼 하나만 검증했다. 로그인, 결제, 권한, 배포 환경 차이, 서버 응답 오류까지 대신 검증하지 않는다. 실제 제품에서는 테스트 계정과 별도 스테이징 환경, 팀의 리뷰 규칙이 필요하다. 임시 서버는 Ctrl+C로 멈추고 임시 폴더를 지우면 된다. 실제 저장소에서는 잘못된 변경이 커밋되기 전에는 git restore로 작업 트리를 되돌릴 수 있지만, 공유된 커밋을 무심코 강제 푸시로 덮어쓰면 안 된다.

AI 수정안을 받을 때 먼저 적을 한 줄

수정을 요청하기 전에 ‘이 버튼을 누르면 어떤 문구가 어디에 나타나야 하는가’를 한 문장으로 적었다. 이번에는 공지 열기 버튼을 누르면 안내문 영역이 금요일 16시 검토 일정으로 바뀌어야 한다는 문장이었다. 이 한 줄이 있으면 AI가 반환한 코드의 길이나 설명의 자신감 대신, 실제로 확인할 결과가 생긴다. 버튼이 여러 개라면 결제처럼 위험한 흐름부터가 아니라, 가장 짧고 되돌리기 쉬운 내부 페이지나 데모에서 이 기준을 연습하는 편이 좋다. 기대 결과가 모호하면 오류가 없더라도 수정이 맞았는지 판단할 수 없다. 예를 들어 저장 버튼이라면 저장되었다는 토스트가 보이는지, 목록 버튼이라면 목록 항목이 실제로 늘어나는지처럼 관찰 가능한 결과를 정한다. 색이 바뀌는 것만으로는 데이터가 반영됐는지 알 수 없으므로, 사용자가 다음에 하는 행동까지 연결해 적는다. 이 문장은 테스트 도구의 명령을 외우지 못해도 적용할 수 있고, AI에게 재수정을 요청할 때도 빠진 결과를 구체적으로 전달하는 기준이 된다.

오류 메시지는 원인 전체가 아니라 다음 질문

ReferenceError는 함수 이름을 찾지 못했다는 관찰일 뿐, 서비스 전체를 다시 만들라는 신호는 아니다. 먼저 철자가 같은지, 함수가 실제로 로드되는지, 클릭 대상과 선택자가 같은지처럼 연결 한 곳씩만 확인한다. 이번 페이지에서는 onclick 속성의 showNotice 호출은 있었지만 함수 선언이 없었다. 따라서 디자인을 바꾸거나 라이브러리를 추가하지 않고 함수 한 개만 넣었다. 수정 범위를 작게 유지하면 브라우저에서 다시 확인했을 때 무엇이 결과를 바꿨는지도 선명하다.

팀이나 실제 배포에서 추가할 경계

로컬에서 버튼 하나가 동작했다고 해서 운영 환경의 접근성, 권한, 네트워크 실패, 분석 태그, 모바일 레이아웃까지 검증된 것은 아니다. 실제 업무에서는 민감한 데이터가 없는 스테이징 계정으로 같은 흐름을 확인하고, 변경 내용은 동료가 읽을 수 있는 diff로 남긴다. 특히 권한이나 결제를 건드리는 AI 제안은 자동 실행하지 말고 승인 절차와 로그 보관 규칙을 먼저 적용해야 한다. 이 글의 절차는 큰 품질 보증을 대체하지 않고, 가장 싸고 빠른 첫 번째 확인으로 쓰는 것이 알맞다. 실행 결과를 공유할 때는 어떤 브라우저와 데이터로 확인했는지, 확인하지 않은 범위는 무엇인지도 함께 적는다. 그러면 다음 사람이 같은 결과를 재현하기 쉬워지고, 화면 캡처 한 장만 보고 운영 반영을 결정하는 일을 줄일 수 있다.

AI가 만든 수정안을 신뢰하는 가장 빠른 방법은 더 길게 읽는 일이 아니라, 사용자가 누르는 한 번을 실제로 확인하는 일이다.

참고한 자료

• Git restore공식 문서
• MDN ReferenceError: not defined참고 자료
• Playwright screenshots공식

함께 읽기

이어서 보면 좋은 글

• Dependabot 3일 쿨다운: 일반 업데이트와 보안 업데이트 차이, 설정법까지변경을 바로 적용하기 전 범위와 실행 조건을 나누어 확인하는 방법을 이어서 볼 수 있다.
• Cloudflare 캐시가 대륙을 우회하는 이유: Smart Tiered Cache 리전 힌트 설정법로컬 결과와 실제 배포 환경이 다를 수 있다는 점을 점검하는 데 연결된다.

AI가 만든 코드가 틀렸다는 사실보다 중요한 것은, 틀린 상태를 작은 범위에서 발견하고 되돌릴 수 있는가다. 버튼 하나를 눌러 보고, 오류가 나면 변경 범위를 좁혀 확인하고, 동작한 상태를 Git 커밋으로 남기면 다음 수정도 비교할 기준이 생긴다. 이 실험은 로컬 예제만 다뤘으므로 실제 서비스에서는 테스트 환경과 리뷰 절차를 별도로 갖춰야 한다.

직접 확인해보려면오늘 수정한 페이지에서 가장 중요한 버튼 하나를 고르고, 배포 전 브라우저 클릭과 Git diff 확인을 한 번씩 해 보자.