PRO

설치 전 시식 · 로그인 없이 공개

microsoft/playwright 개발·테스트

배포 전, 주문 흐름을 다시 확인하는 법

상품을 담고 주문을 누른 뒤, 완료 결과까지 확인하려면? 손그림 영상과 설명도 3장으로 기대 결과·자동 대기·브라우저 격리·실패 추적을 읽고, 기존 Cypress를 유지할 조건도 비교합니다.

66초 영상설명도 3장선택 가이드

영상으로 먼저 보기 ↓바로 시작하기 ↓

01 · 영상으로 한눈에

배포 전, 중요한 흐름을 다시 확인해요

주문 흐름을 예로 든 6단계 손그림 설명입니다. Google Flow 한국어 나레이션과 자막을 사용하며, 실제 쇼핑몰 실행 결과를 보여주는 영상은 아닙니다.

02 · 실제 앱 화면

공식 문서의 실제 화면으로 먼저 보세요

Playwright 공식 문서에 실린 화면이에요. 예제 테스트 실행부터 보고서·UI Mode·Codegen·Trace까지, 설치한 다음 쓰는 순서대로 골라 볼 수 있어요.

명령줄에서 실행되는 Playwright 테스트 (공식 문서 이미지) — **명령줄에서 예제 테스트 실행**설치 문서가 '명령줄에서 실행되는 테스트'로 싣는 화면이에요. 원문은 기본 설정에서 테스트가 브라우저 창 없이 Chromium·Firefox·WebKit에 걸쳐 병렬로 돌고, 출력과 모은 결과가 터미널에 나온다고 설명해요.

화면: microsoft/playwright 공식 문서 이미지(docs/src/images/getting-started, v1.64.1), Apache-2.0. 깃밥이 너비 2000px 이하로 줄이고 WebP로 바꿨을 뿐 내용은 고치지 않았어요. 화면 속 사이트는 문서의 예제(playwright.dev, TodoMVC 데모)이고, Playwright 이름과 브라우저 로고 등은 각 소유자의 것이에요. 깃밥이 찍은 화면이 아니에요.

03 · 바로 시작하기

설치 명령 한 줄로 예제 테스트까지

가장 빠른 길은 설치 명령 한 줄이에요. 명령어 옆 복사 버튼을 누르고 프로젝트 폴더의 터미널에 붙여넣으면 돼요. VS Code를 쓴다면 확장으로도 같은 준비를 할 수 있어요.

원본 v1.64.1(2026-10-14 UTC 릴리스) 문서 기준 · 2026-10-19 확인 · 깃밥이 직접 설치하거나 실행해 보지는 않았어요. 원문이 엇갈려요: 설치 문서의 시스템 요구 사항은 Node.js 22.x·24.x·26.x 최신판을 적지만, @playwright/test 패키지 설정은 Node.js 20 이상을 받아요. 같은 문서는 macOS 14(Sonoma) 이상이라고 하지만, v1.59 릴리스 노트는 WebKit의 macOS 14 지원을 없앴다고 적어요. Windows는 11 이상·Windows Server 2019 이상·WSL, Linux는 Debian 12/13, Ubuntu 22.04/24.04/26.04(x86-64·arm64)예요. 깃밥 덧붙임: 두 쪽을 모두 만족하려면 Node.js 22·24·26 중 최신판, macOS 15 이상이 안전해요.

어떻게 설치할까요

설치 명령 (npm·yarn·pnpm)

새 프로젝트를 만들거나, 기존 프로젝트에 Playwright를 더할 때

playwright.config.ts
package.json
package-lock.json
tests/example.spec.ts

npm

npm init playwright@latest

yarn

yarn create playwright

pnpm

pnpm create playwright

질문 네 가지에 답해요: TypeScript/JavaScript(기본 TypeScript), 테스트 폴더 이름(기본 tests, 이미 있으면 e2e), GitHub Actions 워크플로 추가(CI용 권장 · 설치 도구 코드상 기본값이 예라 Enter만 눌러도 추가돼요), 브라우저 설치(기본 예). 끝나면 브라우저를 내려받고 위 파일들을 만들어요(yarn·pnpm은 yarn.lock·pnpm-lock.yaml). 기존 프로젝트라면 지금 package.json에 의존성이 더해지고, 원문은 다시 실행해도 기존 테스트를 덮어쓰지 않는다고 적어요.

설치 도구(create-playwright v1.17.139) 코드로 깃밥이 확인한 것: package.json이 없으면 먼저 npm init을 실행하고, @types/node가 없으면 함께 설치해요. package.json의 test 스크립트가 'no test specified' 기본값이면 지우고 package.json을 다시 써요. .gitignore에 node_modules/·/test-results/·/playwright-report/·/blob-report/·/playwright/.cache/·/playwright/.auth/ 줄을 더하고, CI를 고르면 .github/workflows/playwright.yml을 만들어요. 같은 이름의 파일이 이미 있으면 'Override it?'(덮어쓸까요)를 묻고 기본값은 No예요. Linux에서는 sudo가 필요한 운영체제 의존성 설치를 따로 물어요.

직접 추가 (패키지 + 브라우저)

질문 없이 기존 프로젝트에 패키지만 넣고 싶을 때

npm i -D @playwright/test
npx playwright install

README의 'Or add manually' 두 줄이에요. 테스트 도구를 개발 의존성으로 넣고, 브라우저를 내려받아요.

설치 문서는 설정 파일과 예제 테스트를 위의 설치 명령이 만든다고 적어요. 깃밥 덧붙임: 이 두 줄은 그 파일들을 만들지 않으니, 필요하면 직접 만들어요.

VS Code 확장

VS Code를 쓰고, Node.js(LTS 권장)가 있을 때

Test: Install Playwright

확장 보기(Ctrl+Shift+X / Cmd+Shift+X)에서 'Playwright'를 찾아 Microsoft 공식 확장을 설치한 뒤, 명령 팔레트에서 Test: Install Playwright를 실행해요. 테스트할 브라우저(예: Chromium·Firefox·WebKit)를 고르고, 원하면 GitHub Actions 워크플로도 더해요. 이 설정은 나중에 playwright.config.ts에서 바꿀 수 있어요.

그다음 활동 막대의 Testing 아이콘으로 테스트 목록과 Playwright 사이드바를 열어요. 테스트 옆 재생 아이콘으로 실행하고, 사이드바의 Record new·Pick locator로 기록·선택자 고르기를 하며, Show Trace Viewer를 켜서 Trace를 봐요.

v1.64.1 릴리스 페이지 ↗

설치한 다음

예제 테스트 실행
기본 설정이면 브라우저 창 없이(headless) Chromium·Firefox·WebKit에서 병렬로 돌고, 결과가 터미널에 모여 나와요. 창을 보려면 --headed, 한 브라우저만 돌리려면 --project=chromium을 붙여요. 깃밥 덧붙임: 템플릿 예제는 테스트 2개라, 세 브라우저면 결과가 6개로 나와요(직접 돌려 보지는 않았어요).
npx playwright test
HTML 보고서 열기
브라우저·통과·실패·건너뜀·불안정(flaky)으로 거를 수 있는 보고서예요. 테스트를 누르면 오류·첨부·단계를 볼 수 있어요. 실패가 있을 때만 자동으로 열리니, 모두 통과했다면 이 명령으로 직접 열어요.
npx playwright show-report
UI Mode로 단계별로 보기
감시 모드(watch), 단계별 실시간 보기, 지난 단계로 돌아가 보는 디버깅(time travel)을 쓸 수 있어요. 원문은 내 PC에서 테스트를 만들고 고칠 때는 UI Mode를 쓰라고 해요.
npx playwright test --ui
Codegen으로 테스트 초안 기록
브라우저 창과 Playwright Inspector가 열리고, 페이지에서 클릭·입력하면 코드가 만들어져요. 툴바 아이콘으로 보이는지(assert visibility)·글자(assert text)·값(assert value) 검증도 넣을 수 있어요. 끝나면 record 버튼으로 멈추고 copy 버튼으로 코드를 복사해요.
npx playwright codegen demo.playwright.dev/todomvc
실패 원인을 Trace로 보기
기본 설정은 Trace를 실패한 테스트의 첫 재시도(on-first-retry)에서만 남기고, 재시도는 CI에서 2번·내 PC에서 0번이에요. 그래서 내 PC에서 그냥 돌리면 Trace가 남지 않아요. UI Mode 없이 내 PC에서 남기려면 --trace on을 붙이고, HTML 보고서에서 테스트 파일 이름 옆 Trace 아이콘으로 열어요.
npx playwright test --trace on

업데이트와 버전 확인

Playwright를 올리면서 새 브라우저와 의존성을 함께 받을 때, 설치된 버전을 확인할 때 쓰는 원문 명령이에요.

업데이트 (브라우저·의존성 포함)

npm install -D @playwright/test@latest
npx playwright install --with-deps

설치된 버전 확인

npx playwright --version

--with-deps는 운영체제 의존성까지 설치해요. Linux에서는 관리자 권한이 필요할 수 있으니, 실행하기 전에 확인하세요.

켜기 전에 알아둘 것

예제 테스트(tests/example.spec.ts)는 https://playwright.dev/ 에 접속해요. 깃밥 덧붙임: 인터넷이 막힌 곳에서는 예제가 실패해도 설치 문제가 아닐 수 있어요.
브라우저는 운영체제별 캐시 폴더에 내려받아요: macOS ~/Library/Caches/ms-playwright, Linux ~/.cache/ms-playwright, Windows %USERPROFILE%\AppData\Local\ms-playwright. 설치하면 수백 MB를 차지해요.
Linux에서는 설치 명령이 운영체제 의존성 설치를 따로 묻고, 이 단계는 sudo(root) 권한이 필요하다고 적혀 있어요. 업데이트 명령의 --with-deps도 브라우저와 운영체제 의존성을 한 번에 설치해요.
GitHub Actions 워크플로를 더하면 main/master 브랜치로의 push와 pull request마다 테스트가 돌고, 보고서를 30일 보관하는 설정이 들어가요. 깃밥 덧붙임: CI 실행 시간과 저장 공간은 팀이 부담해요.
WebKit 실행은 Safari 그 자체가 아니에요. 원문은 Playwright가 Apple이 배포하는 Safari 앱에서는 동작하지 않고, Safari에 가장 가까운 결과를 보려면 Mac에서 WebKit을 돌리라고 해요(예: 영상 재생).
깃밥 덧붙임: 실제 고객 계정·실제 결제·운영 서버를 대상으로 돌리지 말고, 매번 초기화할 수 있는 테스트 환경에서 시작하세요.

AI 앱에게 설치를 맡기려면

아래 명령문을 Claude Code나 Codex에 붙여넣으면, 고정된 v1.64.1 설치 문서대로 진행하고 Node.js 설치·기존 파일 덮어쓰기·CI 추가·브라우저 내려받기 전에는 먼저 물어보며, sudo는 실행하지 않고 명령만 알려 줘요. 명령문은 깃밥이 공식 문서를 바탕으로 썼어요.

AI 앱에 붙여넣을 설치 명령문

작업: Playwright Test를 설치하고 예제 테스트가 도는지 확인해 주세요.

따를 안내 (Playwright v1.64.1 공식 문서, 커밋 고정):
https://github.com/microsoft/playwright/blob/cfe490d941f992655948eee8fd4fd94e1c4234bf/docs/src/intro-js.md
'System requirements'를 먼저 확인해 주세요. macOS 14라면 v1.59부터 WebKit 지원이 빠졌다는 점(원문이 엇갈려요)을 먼저 알려 주세요. 그다음 'Installing Playwright' → 'Running the Example Test' → 'HTML Test Reports' 순서로 진행하고, 단계마다 결과를 확인한 뒤 다음으로 넘어가 주세요.

꼭 지켜 주세요
- Node.js를 새로 설치하거나 버전을 바꿔야 하면, 하기 전에 먼저 저에게 물어봐 주세요. (원문이 엇갈려요: 설치 문서는 Node.js 22·24·26, @playwright/test 패키지는 20 이상)
- 기본은 새 폴더에서 진행해 주세요. 기존 프로젝트에서 npm init playwright@latest를 실행해야 하면 먼저 물어보고, "Override it?"(덮어쓸까요) 질문에는 모두 No로 답해 주세요.
- "Add a GitHub Actions workflow?" 같은 CI 변경은 제가 허락할 때만 해 주세요. 허락이 없으면 No로 답해 주세요.
- Linux의 운영체제 의존성 질문에는 No로 답하고, sudo나 시스템 패키지가 필요한 단계(install-deps, --with-deps)는 직접 실행하지 말고, 필요한 명령만 알려 주세요.
- 브라우저는 운영체제 캐시 폴더(~/.cache/ms-playwright, ~/Library/Caches/ms-playwright, %USERPROFILE%\AppData\Local\ms-playwright)에 수백 MB를 내려받아요. 받기 전에 물어봐 주세요. 제가 원하면 Chromium 하나만 받아 주세요. Chromium만 받았다면 예제는 npx playwright test --project=chromium으로 돌려 주세요.
- 전역 설치(npm i -g @playwright/cli@latest), MCP 서버 등록, npx playwright init-agents 같은 AI 에이전트 설정은 하지 마세요.
- Playwright 업데이트, --update-snapshots, 기존 테스트·설정 파일 수정, 커밋·푸시는 하지 마세요.
- 테스트가 운영 서버, 실제 고객 계정, 결제를 향하게 하지 마세요.
- playwright/.auth/ 폴더 내용, 쿠키, 비밀 값은 대화·로그·파일에 출력하지 마세요.

끝나면 알려 주세요
- 실행한 명령과 그 출력
- npx playwright --version 결과
- 통과·실패한 테스트 수 (예제는 https://playwright.dev/ 에 접속하니 인터넷이 필요해요)
- 새로 만들거나 바꾼 파일 (특히 package.json과 .gitignore에서 바뀐 부분)
- HTML 보고서가 있는 곳과 여는 방법 (npx playwright show-report)

설치 문서 (intro-js.md) ↗시스템 요구 사항 ↗README 수동 설치 ↗VS Code 확장 ↗HTML 보고서 ↗Codegen ↗Trace Viewer ↗GitHub Actions 워크플로 ↗브라우저 저장 위치 ↗@playwright/test package.json (node >=20) ↗v1.59 릴리스 노트 (macOS 14 WebKit 지원 종료) ↗설치 도구 v1.17.139: 질문 ↗설치 도구: 만드는 파일 ↗설치 도구: .gitignore·package.json ↗설치 도구: 덮어쓰기 확인 (기본 No) ↗라이선스: Apache-2.0 ↗

작동 원리 설명도 3장 펼치기

영상의 주문 예시를 세 장의 설명도로 다시 읽습니다. 동작 순서에 기대 결과를 붙이고, 도구가 나누는 상태와 사람이 준비할 데이터를 구분해보세요.

01 / 기대 결과 설명도

클릭한 뒤, 무엇이 보여야 하나요?

상품 담기, 주문하기, 주문 완료 확인을 잇는 깃밥의 설명도 — 깃밥의 설명도근거 문서 ↗관련 문서 ↗설명도 크게 보기 ↗

이 그림이 설명하는 것: 상품을 담고 주문한 뒤, 완료 문구나 주문 내역이 기대한 상태인지 확인합니다. 클릭만 성공해도 테스트가 통과하도록 만들지 않는 것이 핵심이에요.
내 상황이라면: 변경할 때마다 사람이 반복해서 주문 화면을 확인하는 팀에 출발점이 됩니다.
직접 확인할 것: 테스트 전용 환경에서 계정·상품·주문 데이터를 준비하고, 실제 결제가 일어나지 않는 조건을 정하세요.

깃밥이 공식 문서를 바탕으로 만든 설명도입니다. 실제 쇼핑몰 검사·속도 비교·결제 실험을 진행하지 않았습니다.

설명도·영상: 깃밥. 근거: Microsoft·Playwright 공식 문서. 소스 확인: 2026. 10. 19. 원본 문서 라이선스 ↗

04 · 선택 가이드

내 조건이라면 어느 쪽을 고를까요?

내 상황에 맞춰 고르기

질문 세 개로 결론까지

답을 고르면 아래 비교와 판단 근거를 바탕으로 깃밥이 정리한 결론이 바로 나와요.

지금 E2E 테스트는?

아직 없어요Cypress로 필요한 흐름을 이미 안정적으로 검사해요

꼭 확인할 브라우저는?

WebKit 포함 세 엔진Chrome뿐이에요실제 iPhone Safari까지 보장해야 해요

실패를 읽고 고칠 담당자와 초기 데이터가 있나요?

네아직 없어요

세 가지를 고르면 결론이 나와요.

결론은 아래 비교와 '조건이 달라지면' 판단, 원래 분석의 추천·보류 조건을 그대로 옮긴 거예요. 공식 문서: WebKit과 Safari ↗

한눈에 비교

같은 '업데이트 뒤 주문 흐름 확인'을, 두 도구를 자체 CI에서 돌리는 기본 구성끼리 비교했어요(Playwright v1.64.1 문서 · Cypress 문서 2026-10-15 고정본).

기준	Playwright Test · 자체 CI 실행	Cypress App · 자체 CI 실행
필수 브라우저	Chromium·Firefox·WebKit 프로젝트	Chrome 계열·Firefox, WebKit은 실험 지원
실패를 읽는 방법	UI Mode·기록한 Trace	Open Mode Command Log (Cloud Test Replay는 별도)
기존 테스트가 있을 때	새로 작성, 이전은 추가 작업	기존 테스트를 같은 도구로 보완
CI·비용·보관	CI 설치·보고서 보관은 팀 부담	자체 CI 가능, Cloud 기록은 별도 결정·요금 확인

이럴 땐 Playwright Test · 자체 CI 실행새 E2E 테스트를 만들고, 여러 엔진과 CI에서 남길 실패 기록을 직접 관리할 개발자가 있을 때.

이럴 땐 Cypress App · 자체 CI 실행Cypress에 익숙한 팀이 필요한 브라우저를 이미 검사하고 있고, 이전으로 얻을 구체적 이익이 작을 때.

기준별 자세한 설명과 출처

필수 브라우저

Playwright Test · 자체 CI 실행: Chromium·Firefox·WebKit을 프로젝트로 설정합니다. WebKit은 실제 Safari 앱과 동일하지 않습니다.
Cypress App · 자체 CI 실행: Chrome 계열·Firefox를 지원하고 WebKit은 현재 실험 지원입니다.

WebKit 정기 검사가 필수이고 새로 시작한다면 Playwright를 먼저 검토합니다. 실제 iPhone 동작은 별도로 확인합니다.

1 ↗2 ↗

실패를 읽는 방법

Playwright Test · 자체 CI 실행: 로컬 UI Mode가 있고, 기록해 둔 Trace로 작업·화면·오류를 따라갑니다.
Cypress App · 자체 CI 실행: 로컬 Open Mode에서 Command Log와 당시 화면을 확인합니다. Cloud의 CI Test Replay와는 구분합니다.

어느 쪽도 자동으로 원인을 확정하지 않습니다. 팀이 실제로 읽고 고칠 수 있는 기록 방식이 중요합니다.

1 ↗2 ↗3 ↗

기존 테스트가 있을 때

Playwright Test · 자체 CI 실행: 새 프로젝트에 테스트와 데이터 준비·CI 설정을 작성합니다. 기존 다른 도구의 테스트 이전은 추가 작업입니다.
Cypress App · 자체 CI 실행: 기존 Cypress 테스트가 필요한 흐름을 다루고 있다면 같은 도구에서 보완할 수 있습니다.

브라우저 제약 같은 구체적인 부족함이 없다면 재작성 비용보다 기존 테스트의 빈틈을 메우는 편을 우선합니다.

1 ↗2 ↗

CI·비용·보관

Playwright Test · 자체 CI 실행: CI에서 브라우저·의존성을 설치하고 보고서를 보관합니다. CI 실행 시간·저장 공간·유지보수는 팀 부담입니다.
Cypress App · 자체 CI 실행: Cypress App도 자체 CI에서 실행할 수 있습니다. Cloud 기록을 쓸지는 별도 결정이며 조건·요금 확인이 필요합니다.

“오픈소스라 운영비 0원”으로 비교하지 않습니다. 같은 흐름·브라우저·보관 기간으로 예상 실행 횟수를 계산하세요.

1 ↗2 ↗

도입 전 확인 3가지

설치하기 전에 확인하면 헛걸음을 줄일 수 있어요. 체크는 이 화면에만 표시돼요.

우리 로그인·외부 인증 흐름을 반복할 수 있나요?개발자에게 테스트용 계정 발급, 인증 상태 준비, 초기화 방법을 확인하고 한 흐름만 시험합니다.
안 맞으면 매번 수동 인증이 필요하고 대안이 없다면 자동 실행 범위를 줄이거나 도입을 미룹니다.
실행·기록을 감당할 자원이 있나요?브라우저 수 × 변경 횟수 × 재시도와 보관 기간을 정하고, 한 CI 실행의 시간·파일 크기를 측정합니다.
안 맞으면 월 비용은 이 값과 CI 제공업체 조건을 확인한 뒤 계산합니다. 여기서는 비용 절감을 단정하지 않습니다.
무엇이 실패하면 배포를 멈출 건가요?운영자와 개발자가 상품 담기·주문·완료 확인의 합격 기준과 실패 담당자를 문장으로 정합니다.
안 맞으면 기준이 없으면 테스트가 초록색이어도 사업상 중요한 오류를 놓칠 수 있습니다.

깃밥이 가정한 예시 상황과 근거

새 쇼핑몰. 아직 E2E 테스트가 없고, 개발자 1명이 관리할 수 있습니다. 상품 담기·주문·완료 확인를 Chromium·Firefox·WebKit에서 확인하려 합니다. 외부 테스트 분석 서비스의 추가 계약은 우선 미룹니다.

목표: 주문의 핵심 흐름을 변경마다 확인. 전체 품질 보증을 대신한다는 가정은 하지 않습니다.
현재: E2E 테스트가 없고 JavaScript/TypeScript를 관리할 개발자가 있습니다.
운영: 테스트 환경과 초기 데이터, CI를 쓸 수 있습니다. 새 유료 분석 서비스 계약은 보류하되 CI 실행·보관 비용은 인정합니다.

Playwright 공식 문서는 2026년 10월 19일 v1.64.1 태그 커밋에 고정해 다시 확인했고, Cypress 비교 문서는 2026년 10월 15일 고정본 기준입니다. 이 글을 위해 실제 쇼핑몰을 설치·검사하거나 두 도구의 속도·비용을 측정하지 않았습니다. 조건부 추천은 깃밥의 판단이며 사용자 평가로 검증된 결과가 아닙니다.

쓰임부터 이해하는 레포 해설

주문 버튼을 누르는 것부터, 결과를 검증하는 것까지

완성한 사이트에 붙이는 개발·검수 도구입니다. 고객에게 새 기능을 제공하기보다, 코드를 바꿀 때 기존 기능이 약속한 결과를 내는지 확인하는 데 씁니다.

01 · 역할 나눠 보기

맡길 부분과 직접 챙길 부분

Playwright에 맡겨요

작성한 동작을 브라우저에서 실행하고 명시한 결과를 검증합니다.
설정한 보고서·추적 데이터로 실행 상태를 확인하게 합니다.

직접 준비하고 운영해요

고객에게 중요한 흐름, 합격 기준, 예외 상황을 결정합니다.
테스트 계정·데이터·CI·기록 접근 권한을 준비합니다.
화면과 업무 규칙이 바뀌면 검증문을 수정하고 불안정한 실패를 조사합니다.

한 흐름을 반복 실행하고, 일부러 어긋난 결과를 잡아내고, 다른 담당자가 실패를 설명할 수 있다면 다음 흐름으로 넓힐 준비가 된 겁니다.

공식 자료 1 ↗공식 자료 2 ↗공식 자료 3 ↗공식 자료 4 ↗공식 자료 5 ↗공식 자료 6 ↗공식 자료 7 ↗

더 자세히: 원본 해석과 확인할 사항

쇼핑몰의 상품 담기 → 주문 → 완료 확인을 테스트 환경에서 반복하려는 소규모 웹팀을 가정합니다. 목표는 모든 버그를 보증하는 일이 아니라, 중요한 한 흐름의 기대 결과를 코드로 남기고 실패 원인을 읽는 것입니다.

02 · 읽은 뒤, 여기부터

도입 후 첫 확인은 “테스트가 통과한다”보다 “잘못된 결과를 놓치지 않고 이유를 설명할 수 있다”입니다. 아래는 제안하는 확인 절차이며 실행 결과가 아닙니다.

내 조건에 맞춰 확인하기 위한 순서예요. 깃밥이 직접 실행한 결과를 뜻하지는 않아요.

테스트 환경에서 상품 담기 → 주문 → 완료 문구와 주문 내역 확인을 한 흐름으로 정합니다. 테스트용 주문 ID로 대상 주문을 구분합니다.
확인 후 남길 것클릭 순서와 별개로 “무엇이 저장되어야 하는지”를 팀원이 설명할 수 있습니다.
정상 상태를 확인한 뒤, 테스트 환경에서 기대한 완료 문구을 일부러 다르게 지정해 검증을 실패시켜 봅니다.
확인 후 남길 것올바른 흐름은 통과하고 잘못된 기대값은 실패해야 합니다. 오류가 나는지 확인한 뒤 기대값을 복원합니다.
CI에서 같은 테스트를 실행하고 다른 담당자가 보고서·Trace를 열어 원인을 설명해 봅니다.
확인 후 남길 것로컬에서만 되는 조건, 누락된 기록, 접근 권한 문제를 찾습니다. 성공 여부와 실행 시간은 이때 처음 측정합니다.

다음 단계로 진행

같은 초기 상태를 반복해서 만들 수 있고, 의도한 실패를 잡아내며, 담당자가 남은 기록을 읽고 고칠 수 있을 때 범위를 넓힙니다.

여기서 보류

정상 코드도 데이터·로그인·환경 차이 때문에 자주 실패하거나, 재실행만 해 통과시키고 원인을 설명하지 못한다면 확대를 멈춥니다.

판단 근거와 확인 항목 더 읽기

이름으로 찾고, 제한 시간 안에서 기다립니다

공식 자료에서 확인: 역할·이름 기반 locator로 버튼을 찾고, click은 보임·안정성·이벤트 수신·활성 상태를 확인합니다. web-first assertion은 조건을 재시도합니다.
깃밥의 해석: 임의의 긴 대기보다 동작 가능 조건과 기대 결과를 적는 방식입니다. 제한 시간을 넘기면 실패합니다.
도입 전 판단: 먼저 접근 가능한 버튼 이름과 명확한 완료 조건을 준비합니다.

근거 자료 1 ↗근거 자료 2 ↗근거 자료 3 ↗

세 브라우저와 실제 기기는 확인 범위가 다릅니다

공식 자료에서 확인: Chromium·Firefox·WebKit 프로젝트와 새 브라우저 컨텍스트를 사용할 수 있습니다. 문서는 Playwright가 Apple이 배포하는 Safari 앱에서는 동작하지 않으며, 코덱 같은 기능은 운영체제마다 다르고 Safari에 가장 가까운 결과는 Mac에서 WebKit을 실행해 얻는다고 적습니다.
깃밥의 해석: 브라우저 상태 격리가 서버 데이터 격리까지 자동으로 해주는 것은 아닙니다.
도입 전 판단: 별도 테스트 데이터와 실제 기기에서 남길 확인 항목을 함께 정합니다.

근거 자료 1 ↗근거 자료 2 ↗근거 자료 3 ↗

이런 상황에 잘 맞아요

개발자가 유지보수할 웹서비스에서 중요한 사용자 흐름을 반복 확인하고 싶을 때.
실패 당시의 화면·작업·오류를 남겨 다른 담당자와 조사하고 싶을 때.

다른 선택지도 비교해 보세요

설치하면 AI가 모든 업무 규칙을 알아서 테스트해줄 거라 기대할 때.
실제 iPhone의 Safari 확인을 WebKit 에뮬레이션 하나로 모두 대신하려 할 때.

써보기 전에 확인할 것

실패가 나면 누가 확인하고, 잘못된 테스트를 누가 고칠지 정했나요?
매 실행마다 같은 출발 상태를 만들 테스트 계정·데이터가 있나요?
자동 테스트 뒤에도 남는 실제 기기·접근성·업무 예외 확인을 구분했나요?

선정한 이유: 버튼을 누르는 자동화와 주문이 성공했는지 검증하는 일을 구분하기 좋은 예제입니다. 테스트 계정·서버 데이터·실패를 고칠 담당자까지 함께 봅니다.

출처와 확인 범위

공식 자료와 코드를 바탕으로 깃밥이 설명도와 영상을 만들었어요. 실제 기기를 조작한 녹화나, 새로 설치해 동작·도입 효과를 측정한 기록은 아니에요.

제작자: Microsoft and Playwright contributors
자료 확인일: 2026-10-19
라이선스: Apache-2.0 ↗

GitHub ↗공식 문서 ↗확인한 버전 · cfe490d ↗

배포 전, 중요한 흐름을 다시 확인해요

공식 문서의 실제 화면으로 먼저 보세요

설치 명령 한 줄로 예제 테스트까지

어떻게 설치할까요

설치 명령 (npm·yarn·pnpm)

직접 추가 (패키지 + 브라우저)

VS Code 확장

설치한 다음

예제 테스트 실행

HTML 보고서 열기

UI Mode로 단계별로 보기

Codegen으로 테스트 초안 기록

실패 원인을 Trace로 보기

업데이트와 버전 확인

켜기 전에 알아둘 것

AI 앱에게 설치를 맡기려면

클릭한 뒤, 무엇이 보여야 하나요?

내 조건이라면 어느 쪽을 고를까요?

한눈에 비교

필수 브라우저

실패를 읽는 방법

기존 테스트가 있을 때

CI·비용·보관

도입 전 확인 3가지

주문 버튼을 누르는 것부터, 결과를 검증하는 것까지

맡길 부분과 직접 챙길 부분

Playwright에 맡겨요

직접 준비하고 운영해요

도입 후 첫 확인은 “테스트가 통과한다”보다 “잘못된 결과를 놓치지 않고 이유를 설명할 수 있다”입니다. 아래는 제안하는 확인 절차이며 실행 결과가 아닙니다.

테스트 환경에서 상품 담기 → 주문 → 완료 문구와 주문 내역 확인을 한 흐름으로 정합니다. 테스트용 주문 ID로 대상 주문을 구분합니다.

정상 상태를 확인한 뒤, 테스트 환경에서 기대한 완료 문구을 일부러 다르게 지정해 검증을 실패시켜 봅니다.

CI에서 같은 테스트를 실행하고 다른 담당자가 보고서·Trace를 열어 원인을 설명해 봅니다.

이름으로 찾고, 제한 시간 안에서 기다립니다

세 브라우저와 실제 기기는 확인 범위가 다릅니다

이런 상황에 잘 맞아요

다른 선택지도 비교해 보세요

써보기 전에 확인할 것

출처와 확인 범위