Playwright로 반복 점검 등록 자동화하기: 버튼 이름 오류를 실제 실행으로 고친 기록

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

반복 점검을 등록할 때마다 같은 항목을 입력하고 버튼을 누른 뒤 목록에 들어갔는지 확인하는 일은 작지만 자주 끊긴다. 이번에는 Playwright 1.61.1로 외부 계정·운영 서비스 없이 로컬 테스트 페이지의 한 건 등록을 자동화했다. 기대한 결과는 ‘배포 후 오류 로그 확인’이 목록에 나타나고 완료 문구가 보이는 것이었다. 첫 시도는 버튼을 ‘저장’으로 가정해 0개를 찾았고, 실제 화면의 이름인 ‘등록’으로 locator를 바꾼 뒤 성공했다. 이 글은 그 실패와 수정, 실제 Chromium 출력, 남는 한계를 함께 기록한다.

업무자동화 실험

실행 기록 · Microsoft Playwright 공식 문서·GitHub 릴리스 · 2026. 6. 24

Playwright 1.61.1로 로컬 점검 목록 한 건을 등록하고 결과를 확인한 실험

macOS의 임시 디렉터리에서 Node.js 20.20.2, npm 10.8.2, @playwright/test 1.61.1, Chromium 149.0.7827.55로 실행했다. 개인 계정·토큰·외부 URL 없이 테스트 데이터 한 건만 사용했다.

반복 점검 등록은 작아 보여도 확인 단계가 빠지기 쉽다

배포 뒤 오류 로그를 확인한다는 일을 목록에 적는 데는 입력, 버튼 클릭, 목록 반영 확인이라는 세 단계가 있다. 수동으로는 몇 초면 되지만, 같은 흐름을 여러 내부 도구에서 반복하면 버튼 이름·성공 문구가 바뀐 순간 실수가 생긴다. 이번 범위는 실제 업무 서비스가 아니라 그 흐름을 축소한 로컬 테스트 페이지다. 그래서 자동화의 선택자와 검증 방식을 안전하게 확인할 수 있다.

선정 이유와 안전한 실행 범위

후보함의 Playwright 1.61.1은 공식 릴리스와 설치 문서가 있고, 브라우저 자동화의 가장 작은 성공·실패 사례를 한 번에 보여 주기 좋았다. 공식 설치 문서는 npm 프로젝트에 Playwright를 추가하고 브라우저를 설치하는 흐름을 안내한다. 이 실험은 별도 /tmp 디렉터리, 테스트 문구 한 건, headless Chromium만 사용했다. sudo, 비밀키, 개인 로그인, 운영 사이트 변경, 알 수 없는 설치 스크립트는 사용하지 않았다.

실제 실행 환경과 권한 범위

항목	기록
운영체제	macOS (임시 /tmp 디렉터리)
런타임	Node.js v20.20.2 · npm 10.8.2
도구	@playwright/test 1.61.1 · GitHub tag v1.61.1, commit 39e3553
브라우저	Chromium 149.0.7827.55
입력	배포 후 오류 로그 확인 (테스트 데이터 1건)
권한·범위	로컬 브라우저만 사용, 외부 계정·운영 서비스·토큰 없음

준비: 임시 프로젝트에서 버전을 고정했다

공식 문서를 읽은 뒤 임시 디렉터리에서 npm 초기화, Playwright 1.61.1 설치, Chromium 설치 순서로 진행했다. 프로젝트 저장소에는 node_modules나 실험용 패키지 파일을 넣지 않았다. 재현할 때도 업무 저장소 바깥의 빈 폴더에서 시작하고, 팀의 네트워크·브라우저 설치 정책을 먼저 확인하는 편이 안전하다.

RUN_DIR=$(mktemp -d /tmp/playwright-saturday-XXXXXX)
cd "$RUN_DIR"
npm init -y
npm install --save-dev @playwright/test@1.61.1
npx playwright --version
npx playwright install chromium

기대한 결과는 명확했다. 화면의 입력값 ‘배포 후 오류 로그 확인’을 유지한 채 등록 버튼을 누르면 목록에 같은 문구가 표시되고, ‘목록에 1건을 등록했습니다.’라는 완료 문구가 나타나야 한다. 클릭만 성공해도 화면 반영이 실패할 수 있으므로 두 결과를 함께 읽도록 했다.

클릭 전 실제 Chromium 캡처다. locator를 고치기 전에 테스트 대상의 입력값과 버튼 표시명을 화면에서 확인했다.

728x90

첫 시도: ‘저장’이라는 추측은 0개였다

처음에는 버튼 이름이 ‘저장’일 것이라고 추측했다. 실제로 role=button, name=저장 조건으로 개수를 확인하니 0개였다. 이 단계는 실패를 숨기지 않기 위해 남겼다. 화면의 실제 버튼은 ‘등록’이므로, 존재하지 않는 locator를 클릭하도록 계속 기다리는 대신 먼저 개수를 확인해 원인을 좁혔다.

const wrong = await page.getByRole('button', { name: '저장' }).count();
console.log(`ATTEMPT 1: role=button name=저장 -> ${wrong}개`);
// 실제 결과: 0개

await page.getByRole('button', { name: '등록' }).click();
const item = await page.locator('#list').innerText();
const done = await page.locator('#done').innerText();

실패를 버튼 이름의 불일치로 좁힌 뒤, 실제 접근 가능한 이름 ‘등록’으로 바꾸어 실행하는 흐름이다.

두 번째 시도: 목록과 완료 문구를 함께 확인했다

수정한 locator로 버튼을 누른 뒤 실제 로그는 PASS를 출력했다. 목록 항목은 ‘✓ 배포 후 오류 로그 확인’, 완료 문구는 ‘목록에 1건을 등록했습니다.’였다. 측정 시간이나 처리량은 측정하지 않았으므로 기록하지 않는다. 이 실험은 한 입력, 한 번의 수정 후 실행으로, 여러 사이트나 실제 업무 시스템의 안정성을 증명하지 않는다.

EXPECTED: 등록을 누르면 목록에 1건이 표시된다. ATTEMPT 1: role=button name=저장 -> 0개 RESULT 1: 실패 원인 확인 - 실제 버튼명은 등록 ATTEMPT 2: role=button name=등록 RESULT 2: PASS ITEM: ✓ 배포 후 오류 로그 확인 NOTICE: 목록에 1건을 등록했습니다. BROWSER: 149.0.7827.55

수동 방식과 자동화 방식의 차이

이번 실험에서 실제로 확인한 범위

단계	수동 점검	Playwright로 확인한 점
버튼 이름	눈으로 읽고 누름	role과 실제 표시명 ‘등록’이 일치하는지 확인
등록 결과	목록을 눈으로 다시 확인	목록 항목과 완료 문구를 각각 읽음
오류 원인	왜 실패했는지 추측하기 쉬움	‘저장’ locator가 0개라는 결과로 범위를 좁힘
이번에 검증하지 않은 것	운영 데이터·다중 사용자·네트워크 오류	동일하게 검증하지 않음

적용 한계와 되돌리는 방법

이 예제는 의도적으로 좁다. 실제 사내 도구에 바로 쓰려면 테스트 계정, 최소 권한, 읽기 전용 또는 되돌릴 수 있는 테스트 데이터, 승인 절차가 필요하다. 텍스트는 번역·디자인 변경으로 바뀔 수 있으므로 접근 가능한 역할과 이름을 먼저 다시 확인해야 한다. 실행을 끝낼 때는 임시 디렉터리를 삭제하면 설치한 패키지와 테스트 페이지가 함께 사라진다. 운영 데이터를 만들거나 수정한 적은 없으므로 복구 대상도 없다.

성공 확인은 클릭에서 끝나지 않는다. 목록 반영과 완료 문구를 확인한 뒤, 임시 실험 환경을 지우는 범위를 분리한다.

다음 반복 업무에 옮길 체크리스트

• 운영 서비스가 아닌 임시 페이지 또는 테스트 계정에서 먼저 재현한다.
• 화면의 실제 버튼 이름·역할·성공 문구를 기록하고 locator를 만든다.
• 클릭 뒤 바뀌어야 하는 목록·알림·파일 중 최소 두 신호를 확인한다.
• 실패하면 무작정 재시도하지 말고 locator 개수·화면 문구·로그로 원인을 좁힌다.
• 권한, 비용, 외부 전송 여부를 확인하고 테스트 데이터와 임시 환경을 정리한다.

브라우저 자동화는 ‘사람 대신 클릭하는 매크로’보다, 반복 업무의 성공 조건을 코드로 적어 두는 방법에 가깝다. 오늘처럼 작은 실험에서 실제 화면과 로그를 남겨 두면 다음 업무 도구를 자동화할 때도 무엇을 확인해야 하는지 기준이 남는다.

참고한 자료

• Playwright v1.61.1 release공식
• Playwright installation공식 문서
• Playwright locators공식 문서
• Playwright assertions공식 문서

함께 읽기

이어서 보면 좋은 글

• Cloudflare 캐시가 대륙을 우회하는 이유: Smart Tiered Cache 리전 힌트 설정법설정 변경 전에 적용 조건과 관찰 지표를 기록하는 방법을 이어서 볼 수 있다.
• 무료 사용자에게 찍힌 250억 원 청구, AI 서비스 요금 화면은 어떻게 확인해야 할까화면 알림을 추측하지 않고 실제 로그와 함께 확인하는 관점을 보완한다.

이번 실험의 핵심은 버튼을 누르는 코드가 아니라, 실제 화면에서 확인 가능한 이름으로 locator를 잡고 결과 문구까지 검증하는 습관이다. 작은 로컬 페이지에서 먼저 실패를 재현했으므로, 업무 도구에 적용할 때는 같은 순서로 읽기 전용·테스트 계정·되돌리기 경로를 준비하면 된다.

직접 확인해보려면다음 반복 점검 한 가지를 골라, 먼저 화면에 보이는 버튼 이름과 성공 뒤 나타나는 문구를 적은 뒤 최소 Playwright 예제로 확인해 보자.