Selenium·Cypress 대신 Playwright를 고르는 이유는 무엇인가요?

크로스 브라우저(Chromium·Firefox·WebKit)를 한 API로 다루고, 병렬 실행과 auto-wait이 기본에 가깝게 설계되어 E2E 유지 비용이 줄어듭니다. 팀이 이미 TypeScript/Node 기반이라면 도구·언어 정렬 측면에서도 유리한 경우가 많습니다.

CI에서 Playwright가 불안정할 때(플레이크) 무엇부터 조정하나요?

retries, trace(실패 시 추적), screenshot/video 설정을 점검하고, waitFor 대신 assert 기반 auto-wait을 유지하며, 동시 실행(workers)과 리소스 제한(메모리·포트)을 맞춥니다. 네트워크 의존 테스트는 API 모킹·고정 seed로 분리하는 것이 효과적입니다.

Playwright에서 권장하는 셀렉터(선택자) 전략은?

접근성과 안정성을 위해 getByRole, getByLabel, getByText 등 사용자 관점 셀렉터를 우선하고, 구조에 강한 data-testid를 보조로 씁니다. 깨지기 쉬운 긴 CSS 체인이나 순수 XPath 의존은 지양하는 편이 좋습니다.

로컬과 CI의 브라우저/실행 환경을 맞추려면?

playwright install(또는 CI용 --with-deps)로 브라우저 바이너리를 고정 설치하고, projects로 동일한 device 프로필을 재사용하세요. Docker·GitHub Actions 등에서는 캐시·의존성 설치 스텝을 문서화해 팀이 같은 조합을 재현하도록 맞추면 됩니다.

Playwright 완벽 가이드 | E2E 테스트·자동화·크로스 브라우저·CI/CD·실전 활용

2026년 4월 7일 · 3분 읽기 · 수정 2026년 4월 18일 중급

이 글의 핵심

Playwright로 E2E 테스트를 구현하는 완벽 가이드. 크로스 브라우저 테스트, 자동화, 스크린샷, CI/CD 통합까지 실전 예제로 정리. Playwright·E2E·Testing 중심으로 설명합니다. Start now.

이 글의 핵심

Playwright로 E2E 테스트를 구현하는 완벽 가이드입니다. 크로스 브라우저 테스트, 자동화, 스크린샷, CI/CD 통합까지 실전 예제로 정리했습니다.

실무 경험 공유: Cypress에서 Playwright로 전환하면서, 테스트 속도가 3배 빨라지고 크로스 브라우저 테스트가 간편해진 경험을 공유합니다.

들어가며: “E2E 테스트가 느려요”

실무 문제 시나리오

시나리오 1: 크로스 브라우저 테스트가 어려워요

Selenium은 복잡합니다. Playwright는 간단합니다. 시나리오 2: 테스트가 느려요

병렬 실행이 필요합니다. Playwright는 기본 지원합니다. 시나리오 3: 디버깅이 어려워요

에러 추적이 힘듭니다. Playwright는 강력한 디버깅 도구를 제공합니다.

1. Playwright란?

핵심 특징

Playwright는 Microsoft가 만든 E2E 테스트 프레임워크입니다. 주요 장점:

크로스 브라우저: Chromium, Firefox, WebKit
빠른 속도: 병렬 실행
Auto-wait: 자동 대기
강력한 Selector: CSS, XPath, Text
스크린샷/비디오: 자동 캡처

2. 설치 및 설정

설치

npm init playwright@latest

설정

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';
export default defineConfig({
  testDir: './tests',
  fullyParallel: true,
  forbidOnly: !!process.env.CI,
  retries: process.env.CI ? 2 : 0,
  workers: process.env.CI ? 1 : undefined,
  reporter: 'html',
  use: {
    baseURL: 'http://localhost:3000',
    trace: 'on-first-retry',
    screenshot: 'only-on-failure',
  },
  projects: [
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'] },
    },
    {
      name: 'firefox',
      use: { ...devices['Desktop Firefox'] },
    },
    {
      name: 'webkit',
      use: { ...devices['Desktop Safari'] },
    },
  ],
  webServer: {
    command: 'npm run dev',
    url: 'http://localhost:3000',
    reuseExistingServer: !process.env.CI,
  },
});

3. 기본 테스트

로그인 테스트

// tests/login.spec.ts
import { test, expect } from '@playwright/test';
test('로그인 성공', async ({ page }) => {
  await page.goto('/login');
  await page.fill('input[name="email"]', '[email protected]');
  await page.fill('input[name="password"]', 'password123');
  await page.click('button[type="submit"]');
  await expect(page).toHaveURL('/dashboard');
  await expect(page.locator('h1')).toContainText('Dashboard');
});
test('로그인 실패', async ({ page }) => {
  await page.goto('/login');
  await page.fill('input[name="email"]', '[email protected]');
  await page.fill('input[name="password"]', 'wrongpass');
  await page.click('button[type="submit"]');
  await expect(page.locator('.error')).toContainText('Invalid credentials');
});

4. Selector

CSS Selector

await page.click('button.submit');
await page.fill('#email', '[email protected]');

Text Selector

await page.click('text=로그인');
await page.click('button:has-text("Submit")');

Role Selector

await page.click('role=button[name="Submit"]');
await page.fill('role=textbox[name="Email"]', '[email protected]');

Chaining

await page.locator('.card').filter({ hasText: 'Premium' }).click();

5. API Mocking

test('API 모킹', async ({ page }) => {
  await page.route('**/api/users', (route) => {
    route.fulfill({
      status: 200,
      body: JSON.stringify([
        { id: 1, name: 'John' },
        { id: 2, name: 'Jane' },
      ]),
    });
  });
  await page.goto('/users');
  await expect(page.locator('.user')).toHaveCount(2);
});

6. 스크린샷 & 비디오

스크린샷

test('스크린샷', async ({ page }) => {
  await page.goto('/');
  await page.screenshot({ path: 'screenshot.png' });
  // 특정 요소
  await page.locator('.card').screenshot({ path: 'card.png' });
});

비디오

// playwright.config.ts
export default defineConfig({
  use: {
    video: 'on',
  },
});

7. CI/CD 통합

GitHub Actions

# .github/workflows/playwright.yml
name: Playwright Tests
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 20
      - name: Install dependencies
        run: npm ci
      - name: Install Playwright Browsers
        run: npx playwright install --with-deps
      - name: Run Playwright tests
        run: npx playwright test
      - uses: actions/upload-artifact@v3
        if: always()
        with:
          name: playwright-report
          path: playwright-report/

취업·면접과 연결하기

E2E·테스트 자동화 경험은 품질·협업 질문으로 잘 이어집니다. 영문으로도 정리한 [Playwright Complete Guide (English)](/en/blog/playwright-complete-guide/와, 면접·코테 병행은 기술 면접 완벽 대비 가이드·코딩 테스트 완벽 대비 가이드를 함께 보세요.

정리 및 체크리스트

핵심 요약

Playwright: E2E 테스트 프레임워크
크로스 브라우저: Chromium, Firefox, WebKit
Auto-wait: 자동 대기
병렬 실행: 빠른 속도
API Mocking: 네트워크 제어
CI/CD: GitHub Actions 통합

구현 체크리스트

같이 보면 좋은 글

Cypress E2E 테스트 가이드
Jest 테스트 가이드
GitHub Actions 가이드

이 글에서 다루는 키워드

Playwright, E2E, Testing, Automation, CI/CD, Browser, QA

내부 동작과 핵심 메커니즘

이 글의 주제는 「Playwright 완벽 가이드 | E2E 테스트·자동화·크로스 브라우저·CI/CD·실전 활용」입니다. 여기서는 앞선 설명을 구현·런타임 관점에서 한 번 더 압축합니다. 구성 요소 간 책임 분리와 관측 가능한 지점을 기준으로 생각하면, “입력이 어디서 검증되고, 핵심 연산이 어디서 일어나며, 부작용(I/O·네트워크·디스크)이 어디서 터지는가”가 한눈에 드러납니다.

처리 파이프라인(개념도)

flowchart TD
  A[입력·요청·이벤트] --> B[파싱·검증·디코딩]
  B --> C[핵심 연산·상태 전이]
  C --> D[부작용: I/O·네트워크·동시성]
  D --> E[결과·관측·저장]

알고리즘·프로토콜 관점에서의 체크포인트

불변 조건(Invariant): 각 단계가 만족해야 하는 조건(예: 버퍼 경계, 프로토콜 상태, 트랜잭션 격리)을 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
결정성: 동일 입력에 동일 출력이 보장되는 순수한 층과, 시간·네트워크에 의해 달라질 수 있는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
경계 비용: 직렬화/역직렬화, 문자 인코딩, syscall 횟수, 락 경합처럼 “한 번의 호출이 아니라 누적되는 비용”을 의심 목록에 넣습니다.

프로덕션 운영 패턴

실서비스에서는 기능 구현과 함께 관측·배포·보안·비용이 동시에 요구됩니다. 아래는 팀에서 자주 쓰는 최소 체크리스트입니다.

영역	운영 관점에서의 질문
관측성	요청 단위 상관 ID, 에러율/지연 분위수, 주요 의존성 타임아웃이 보이는가
안전성	입력 검증·권한·비밀 관리가 코드 경로마다 일관적인가
신뢰성	재시도는 멱등한 연산에만 적용되는가, 서킷 브레이커·백오프가 있는가
성능	캐시 계층·배치 크기·풀링·백프레셔가 데이터 규모에 맞는가
배포	롤백 룬북, 카나리, 마이그레이션 호환성이 문서화되어 있는가

운영 환경에서는 “개발자 PC에서는 재현되지 않던 문제”가 시간·부하·데이터 크기 때문에 드러납니다. 따라서 스테이징의 데이터 양·네트워크 지연을 가능한 한 현실에 가깝게 맞추는 것이 중요합니다.

문제 해결(Troubleshooting)

증상	가능 원인	조치
간헐적 실패	레이스 컨디션, 타임아웃, 외부 의존성 불안정	최소 재현 스크립트 작성, 분산 트레이스·로그 상관관계 확인
성능 저하	N+1 쿼리, 동기 I/O, 잠금 경합, 과도한 직렬화	프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거
메모리 증가	캐시 무제한, 클로저/이벤트 구독 누수, 대용량 객체의 불필요한 복사	상한·TTL·스냅샷 비교(힙 덤프/트레이스)
빌드·배포만 실패	환경 변수·권한·플랫폼 차이	CI 로그와 로컬 `diff`, 컨테이너/런타임 버전 핀(pin)

권장 디버깅 순서: (1) 최소 재현 만들기 (2) 최근 변경 범위 좁히기 (3) 의존성·환경 변수 차이 확인 (4) 관측 데이터로 가설 검증 (5) 수정 후 회귀·부하 테스트.

자주 묻는 질문 (FAQ)

Q. Cypress와 비교하면 어떤가요?

A. Playwright가 더 빠르고 크로스 브라우저 지원이 좋습니다. Cypress는 DX가 더 좋습니다.

Q. Selenium과 비교하면 어떤가요?

A. Playwright가 훨씬 간단하고 빠릅니다. Selenium은 더 오래됐지만 복잡합니다.

Q. 모바일 테스트도 가능한가요?

A. 네, 모바일 브라우저 에뮬레이션이 가능합니다.

Q. 프로덕션에서 사용해도 되나요?

A. 네, Microsoft, VS Code 등 많은 프로젝트에서 사용합니다.

이 글이 도움이 되셨나요?

여러분의 피드백은 더 나은 콘텐츠를 만드는 데 도움이 됩니다

문제가 있거나 개선 제안이 있으시면 연락처로 알려주세요.

Keyboard Shortcuts

이 글의 핵심

이 글의 핵심

들어가며: “E2E 테스트가 느려요”

실무 문제 시나리오

에러 추적이 힘듭니다. Playwright는 강력한 디버깅 도구를 제공합니다.

1. Playwright란?

핵심 특징

2. 설치 및 설정

설치

설정

3. 기본 테스트

로그인 테스트

4. Selector

CSS Selector

Text Selector

Role Selector

Chaining

5. API Mocking

6. 스크린샷 & 비디오

스크린샷

비디오

7. CI/CD 통합

GitHub Actions

취업·면접과 연결하기

정리 및 체크리스트

핵심 요약

구현 체크리스트

같이 보면 좋은 글

이 글에서 다루는 키워드

내부 동작과 핵심 메커니즘

처리 파이프라인(개념도)

알고리즘·프로토콜 관점에서의 체크포인트

프로덕션 운영 패턴

문제 해결(Troubleshooting)

자주 묻는 질문 (FAQ)

Q. Cypress와 비교하면 어떤가요?

Q. Selenium과 비교하면 어떤가요?

Q. 모바일 테스트도 가능한가요?

Q. 프로덕션에서 사용해도 되나요?

이 글이 도움이 되셨나요?