Cypress — Playwright·Selenium과 무엇이, 왜 다른가

개념

레슨 2에서 배운 것을 다른 도구로

레슨 2에서 Playwright로 브라우저를 코드로 조작하는 법을 배웠다. Cypress는 같은 목표(요소를 찾고, 행동을 흉내 내고, 결과를 검증하는 것)를 다른 방식으로 구현한 또 하나의 대표적인 웹 자동화 도구다. 문법도 비슷해 보인다.

// Cypress
it("로그인에 성공하면 대시보드로 이동한다", () => {
  cy.visit("https://example.com/login")
  cy.get("[data-testid=email]").type("user@example.com")
  cy.get("[data-testid=password]").type("password123")
  cy.contains("로그인").click()
  cy.url().should("include", "/dashboard")
})

레슨 2의 Playwright 코드와 나란히 놓아보면, page.goto ↔ cy.visit, getByRole ↔ cy.get/cy.contains처럼 구조가 대응된다는 걸 알 수 있다. 개념은 같고, 문법과 내부 동작 방식이 다르다.

근본적인 구조 차이 — 브라우저 안이냐 밖이냐

가장 큰 차이는 테스트 코드가 실행되는 위치다.

Playwright: 테스트 코드가 브라우저 "밖"에서 실행되며, 여러 브라우저
           엔진(Chromium/Firefox/WebKit)을 원격으로 조종한다
Cypress:    테스트 코드가 브라우저 "안"(같은 실행 컨텍스트)에서
           함께 돌아간다

이 구조 차이가 실무에서 체감되는 여러 차이로 이어진다.

왜 이런 차이가 생겼나 — 설계 철학의 차이

Cypress는 "프런트엔드 개발자가 자기 코드를 테스트하기 쉽게"라는 목표로 만들어져, 브라우저 안에서 실행되는 대신 얻는 빠른 피드백과 직관적인 디버깅 경험에 무게를 뒀다. Playwright는 "여러 브라우저·언어를 아우르는 범용 자동화"를 목표로, 브라우저 밖에서 원격 조종하는 구조로 더 넓은 지원 범위를 확보했다. 이건 레슨 1에서 배운 "도구 선택은 우열이 아니라 맥락의 문제"라는 원칙이 그대로 적용되는 사례다.

언제 어느 쪽을 고려하는가

• 프런트엔드 개발자가 컴포넌트 단위 테스트까지 함께 작성하는 팀 — Cypress의 브라우저 내 디버깅 경험이 강점으로 작용한다
• 여러 브라우저 호환성(특히 Safari/WebKit)을 반드시 확인해야 하는 서비스 — Playwright가 더 안정적으로 지원한다
• 이미 팀에 자동화 자산이 있는 경우 — 새로 배우는 비용보다 기존 자산을 유지하는 것이 대개 더 합리적이다(레슨 1의 ROI 관점)

실무에서 왜 필요한가

채용공고에 "Playwright 경험" 또는 "Cypress 경험"이 각각 따로 명시되는 경우가 흔하다. 한쪽만 알고 있으면 "이 도구, 우리가 쓰는 것과 다른데요?"라는 상황에서 위축되기 쉽다. 하지만 레슨 2에서 배운 핵심 개념(요소 찾기, 자동 대기, AAA 패턴)은 두 도구에 동일하게 적용된다 — 문법을 처음부터 다시 배우는 것과, 이미 아는 개념을 새 문법에 옮기는 것은 완전히 다른 난이도다. 이 레슨의 목적은 Cypress 문법을 통째로 암기하는 게 아니라, "아, 이건 Playwright의 그 개념이 이렇게 표현된 거구나"를 알아볼 수 있게 하는 것이다.

실습 과제

과제 1 — 코드 대응시키기 (10분)

레슨 2의 Playwright 예시 코드와 이 레슨의 Cypress 예시 코드를 한 줄씩 짝지어, 서로 대응하는 부분이 무엇인지 표로 정리한다.

과제 2 — 도구 선택 판단하기 (10분)

다음 팀에 Playwright와 Cypress 중 어느 쪽을 권할지 판단하고 이유를 적는다.

1. Safari 사용자 비중이 높은 이커머스 서비스로, QA 3명이 여러 브라우저 호환성 자동화를 새로 구축하려 한다
2. 프런트엔드 개발자들이 자신이 짠 컴포넌트를 직접 테스트하고, 실패 시 브라우저 화면에서 바로 원인을 확인하고 싶어 한다

자가 체크리스트

• Cypress와 Playwright가 같은 목적을 다른 구조(브라우저 안/밖)로 구현한다는 것을 설명할 수 있다
• 두 도구의 구조 차이가 실무에서 어떤 차이(브라우저 지원, 디버깅 경험)로 이어지는지 설명할 수 있다
• Playwright 코드의 개념(요소 찾기, 검증)을 Cypress 문법으로 대응시켜 읽을 수 있다
• 팀 상황에 따라 두 도구 중 어느 쪽이 더 적합한지 판단할 수 있다

흔한 실수

• Cypress와 Playwright 중 하나만 "정답"이라고 주장한다. 설계 철학과 강점이 다를 뿐, 우열의 문제가 아니다.
• 도구 문법을 처음부터 새로 외우려 한다. 레슨 2에서 배운 핵심 개념(요소 찾기, 자동 대기, AAA)을 먼저 확실히 하면, 새 도구의 문법은 그 개념을 표현하는 다른 방식일 뿐이라는 게 보인다.
• Cypress의 브라우저 내 실행 구조가 주는 제약(여러 탭·도메인 다루기 어려움)을 모르고 도입했다가 나중에 발목 잡힌다. 도입 전에 프로젝트의 요구사항(여러 도메인을 넘나드는 흐름이 있는지 등)을 먼저 점검해야 한다.

참고 자료

• Cypress 공식 문서 — Key Differences — Cypress의 설계 철학과 다른 도구와의 구조적 차이
• Playwright 공식 문서 — Why Playwright — Playwright의 설계 목표