테스트 자동화 프레임워크 개념 정리 (cypress, playwright, puppeteer)

지난 포스팅에서는 내 코드를 대신 실행하고 채점해주는 '테스트 실행기(Test Runner)'에 대해 알아보았다.

https://hjinn0813.tistory.com/198

테스트 실행기 기본 개념 정리 (jest, vitest)

하지만 함수나 컴포넌트 단위를 넘어, 실제 사용자가 앱을 사용하는 것처럼 화면 전체를 검증하는 E2E(End-to-End) 테스트를 하려면 '테스트 실행기' 만으로는 부족하다. 개발자를 대신해 브라우저를 켜고, 버튼을 클릭하고, 인풋 창에 타이핑을 해줄 도구가 필요하기 때문이다.

수동 전수 검사를 자동화 로봇에게 인수인계하기 위해, 오늘은 '테스트 자동화 프레임워크'의 핵심 개념을 정리해보려 한다. 아울러 현재 프론트엔드와 백엔드 생태계를 장악하고 있는 3대장 툴인 Cypress, Playwright, Puppeteer를 깊이 있게 비교해 본다.

---

테스트 자동화 프레임워크 (Test Automation Framework)

실제 브라우저 환경에서 사용자 동작을 자동으로 실행하고 검증해주는 E2E(End-to-End) 테스트 도구.

Vitest와 같은 '테스트 실행기'가 소스 코드 내부의 논리적 결함을 검사했다면, 자동화 프레임워크는 유저의 관점에서 화면을 검사한다. 즉, "로그인 버튼을 눌렀을 때 실제로 메인 페이지로 이동되는가?" 같은 시나리오를 검증하는 스크립트 도구이다. 이때 이 프레임워크가 브라우저를 구동하는 방식은 크게 두 가지로 나뉘는데, 헤드 방식과 헤드리스 방식이다.

💡 헤드(Headed) vs 헤드리스(Headless) 

헤드 방식 (Headed Browser)
- 우리가 평소에 웹서핑할 때처럼 "모니터 화면(UI)이 눈에 보이게" 브라우저를 띄우는 방식.
- 사용 환경: 테스트 코드를 처음 작성하거나, 테스트가 중간에 실패했을 때 브라우저 안에서 오류 상황을 눈으로 직접 확인하고 싶을 때

헤드리스 방식 (Headless Browser)
- 런타임(실행) 시에 화면 인터페이스(UI)를 로딩하지 않고, 컴퓨터 메모리 백그라운드 내부에서만 브라우저를 구동하는 방식.
- 사용 환경: UI를 그리는데 필요한 그래픽 하드웨어 리소스나 메모리, 환경 초기화 시간을 극도로 아낄 수 있기 때문에, 수백 개의 방대한 테스트 코드를 벼락같은 속도로 한 번에 실행해야 할 때 주로 사용한다. 특히 모니터 화면이 없는 서버 컴퓨터(예: GitHub Actions 같은 CI/CD 배포 환경)에서 자동 테스트를 돌릴 때 필수적으로 선택된다.

6단계 워크플로우

1. 브라우저 인스턴스 가동 (Launch Browser)
   테스트 스크립트가 실행되면 프레임워크는 내부에 설정된 브라우저(Chromium, WebKit, Firefox 등)를 백그라운드(Headless 상태) 혹은 디버깅용 화면 모드로 깨워 메모리에 올린다.
   
2. 타깃 URL 접속 (Navigation)
   브라우저가 켜지면 개발자가 지정한 로컬 환경 주소나 실제 서버 주소로 페이지를 이동(Navigate)시킨다. 이때 프레임워크는 페이지의 HTML, CSS, 자바스크립트 소스가 브라우저에 완전히 로드될 때까지 내부적으로 기다린다.
   
3. DOM 요소 탐색 (Selector)
   행동을 취하기 전, 제어할 대상을 먼저 찾아야 한다. 개발자가 작성한 ID, 클래스명, 혹은 텍스트 값 같은 CSS 선택자(Selector)를 기반으로 브라우저의 DOM 트리 구조를 샅샅이 훑어보며 특정 버튼이나 인풋 창의 위치를 현미경 보듯 조준한다.
   
4. 사용자 행동 시뮬레이션 (Interaction)
   조준한 요소를 대상으로 실제 유저가 할 법한 행동을 그대로 재현한다. 인풋 박스에 아이디를 타이핑하고, 로그인 버튼을 클릭하고, 스크롤을 아래로 내리는 등의 인터랙션을 브라우저 내부에 직접 주입(Inject)한다.
   
5. 화면 상태 단언 (Assertion)
   사용자 행동을 취한 뒤, 화면이 의도한 대로 변했는지 확인한다. 예를 들어, "로그인 버튼을 눌렀으니 현재 URL에 /dashboard 라는 주소가 포함되어 있어야 해", 혹은 "메인 화면에 유저의 프로필 이미지가 노출되어야 해" 같은 조건을 확인하며 화면의 합격/불합격을 판정한다.
   
6. 세션 종료 및 리포팅 (Teardown & Reporting)
   시나리오 검증이 완료되면 구동 중이던 가상 브라우저 인스턴스를 메모리에서 깨끗하게 종료한다. 이후 터미널이나 전용 UI 창에 어떤 시나리오가 성공했고, 어디서 화면 렌더링을 실패했는지, 실패했다면 당시의 브라우저 화면 스냅샷이나 녹화된 비디오 파일과 함께 최종 리포트를 출력하며 워크플로우를 마친다.

🛠️ 현업에서의 실제 루틴 
글을 작성하다가 문득, "그렇다면 만약 내가 Vitest(실행기)와 Cypress(프레임워크)를 모두 도입했을 때, 명령어 하나로 동시에 작동해야 되는걸까?" 궁금해져서 확인해봤다. 결론부터 말하자면, 실무에서는 명령어를 철저히 분리해서 완전히 다른 타이밍에 실행하는 것이 일반적이다. 두 도구의 목적과 무게감이 완전히 다르기 때문이다.

- Vitest (실행기): 코드가 가볍고 속도가 빨라서, 기능을 개발하는 동안 모니터 한쪽에 Watch 모드로 항상 켜두고 코드 한 줄 쓸 때마다 실시간으로 검사받는다.
- Cypress (프레임워크): 브라우저를 켜고 전체 플로우대로 처음부터 끝까지 작동해야되서 무겁다. 코드 한 줄마다 돌리면 개발 흐름이 끊기므로, 하나의 큰 기능이나 유저 시나리오 개발이 끝났을 때 최종 점검용으로 실행한다.

따라서 package.json 파일에 test:unit(실행기용)과 test:e2e(프레임워크용)로 명령어를 쪼개어 관리하며, 만약 깃허브 배포 직전(CI/CD 환경)처럼 한 번에 다 돌려야 할 때는 명령어를 묶어주는 라이브러리(npm-run-all 등)를 활용해 '단위 테스트 완료 ➔ E2E 테스트 시작' 순서로 연달아 실행되도록 세팅한다.

---

Puppeteer : 브라우저 원격 조종의 시대를 연 고전 라이브러리

2017년 8월, 구글의 크롬 개발자 도구 팀에서 공식 발표한 오픈소스 Node.js 라이브러리.

브라우저를 '실로 매달아 조종하는 인형(Puppet)'처럼 내 입맛대로 조종할 수 있게 하겠다는 목적으로 태어났다.

구글이 직접 만든 만큼, 크롬 브라우저의 CDP(Chrome DevTools Protocol) 기반의 API를 활용하여, 헤드(Head) 모드와 헤드리스(Headless) 모드를 날것의 형태로 직접 제어한다. 자바스크립트의 async/await 문법을 활용해 브라우저 내부에서 일어나는 비동기 동작들을 순차적으로 제어하는 직관적인 문법 구조를 가지고 있다.

특징 및 문법

• 다양한 브라우저 제어 기능:
  웹사이트 스크린샷 및 PDF 생성, SPA(Single Page Application) 페이지 크롤링, 사전 렌더링된 콘텐츠 생성, 폼 전송 자동화, 키보드/마우스 유저 제스처 시뮬레이션 등 브라우저로 할 수 있는 거의 모든 행위를 자동화한다.
• 트래픽 및 성능 모니터링:
  웹사이트의 HTTP 아카이브(HAR 파일)를 생성할 수 있다. 이 파일을 통해 웹사이트 내에서 발생하는 전체 네트워크 트래픽을 검토하거나, 각 처리의 성능 및 보안 요소까지 심층 분석할 수 있는 타임라인 추적 기능을 제공한다.
• 단일 언어 및 크롬 중심 환경:
  자바스크립트(Node.js) 환경만 공식 지원하며, 크롬 개발자 도구 프로토콜(CDP)에 의존하기 때문에 크롬 기반 브라우저 제어에 철저히 최적화되어 있다.

장점과 단점

장점	- 구글의 순정(Native) 지원: 구글 크롬 팀이 직접 관리하므로 Chromium 기반 브라우저(크롬, 에지 등)에 대한 제어력과 속도가 압도적이다. 브라우저 버전이 업데이트되어도 깨지지 않는 최고의 호환성을 자랑한다. - 크롤링과 데이터 수집의 최강자: 화면 캡처, PDF 생성, 웹페이지 스크래핑 등 화면 테스트 외에 단순 '브라우저 자동화 업무' 환경에서 가볍고 강력하게 작동한다.
단점	- 부족한 테스트 인프라: 이 도구는 '테스트 프레임워크'가 아니라 브라우저 '조종 라이브러리'다. 따라서 자체적인 채점 도구(Assertion)나 UI 테스트 러너가 없다. 테스트를 하려면 Jest, Mocha 같은 실행기를 개발자가 직접 가져와서 연동해야한다. - 타 브라우저 지원의 한계: 크롬 개발자 도구 기반으로 설계되었기 때문에 사파리(WebKit)나 파이어폭스(Firefox) 같은 다른 브라우저 환경을 테스트하기가 까다롭고 불안정하다.

---

Cypress : 프론트엔드 개발의 DX를 혁신한 직관의 끝판왕

2017년 9월, "Cypress.io"라는 스타트업이 퍼블릭 베타 버전으로 세상에 내놓은 프론트엔드 전용 E2E 테스트 프레임워크.

기존의 무겁고 느린 E2E 테스트 도구들에 한계를 느껴서 "프론트엔드 개발자들을 위한 최고의 테스트 툴을 만들자" 라는 목표로 바닥부터 개발하여 출시했다. 구글이나 마이크로소프트 같은 거대 빅테크 기업들 사이에서, 오직 압도적인 개발자 경험(DX) 하나만으로 생태계의 한 축을 당당히 차지했다.

Cypress가 가져온 가장 큰 혁신은 'In-Browser' 아키텍처이다. 브라우저 외부에서 원격으로 명령을 내리던 기존 방식들과 달리, Cypress는 테스트 대상인 웹 애플리케이션과 동일한 브라우저 내부(동일한 JS 런타임)에서 나란히 실행된다. 이 덕분에 애플리케이션의 내부 상태와 DOM 요소에 직접 접근할 수 있어 실행 속도가 매우 빠르며, 디버그 기능이 극도로 우수하다. 또한 단언(Assertion) 라이브러리와 모킹 도구들을 전부 내장한 대표적인 '올인원' 툴이다.

특징 및 문법

• 우수한 DOM 접근 및 디버깅:
  브라우저 내부에서 코드가 같이 돌기 때문에, 개발자 도구를 열어 DOM 상태를 실시간으로 확인하고 변수나 네트워크 요청을 가로채어 분석하는 디버그 능력이 우수하다.
• 테스트 안정성과 정확성:
  E2E 테스트의 고질적인 문제인 '화면이 뜨기 전에 코드가 실행되어 테스트가 터지는 현상'을 해결하기 위해, 프레임워크 자체에서 요소가 나타날 때까지 자동으로 기다려 주는 일관성 테스트 기능(Retryability)을 지원한다.
• 타임 트래블(Time Travel):
  전용 UI 러너를 통해 테스트가 실행되는 과정을 녹화하고, 마우스가 움직인 특정 시점으로 스냅샷을 돌려가며 화면을 검증할 수 있는 직관적인 문법을 제공한다.

장점과 단점

장점	- 비교 불가능한 디버깅 경험(DX): 테스트가 실패하면 "어느 라인의 코드 때문에 화면의 어떤 요소가 안 떴는지" 전용 UI 창에서 시각적으로 정확히 짚어준다. 주니어 개발자가 E2E 테스트에 입문할 때 가장 진입장벽이 낮은 이유다. - 네이티브 대기 메커니즘 (Retryability): 웹페이지의 요소가 렌더링 될 때까지 개발자가 억지로 sleep() 함수를 걸어 기다릴 필요가 없다. 화면이 뜰 때까지 알아서 수 밀리초 동안 재시도하며 기다려주므로, 테스트 코드가 엇박자로 실패하는 일이 극도로 적다.
단점	- 멀티 탭 및 다중 브라우저 제어 불가능: 브라우저 '내부'에 갇혀서 실행되는 태생적 한계 때문에, 하나의 테스트 시나리오 안에서 새 탭을 열어 주소를 이동하거나, 서로 다른 두 개의 브라우저 창을 띄워 실시간 채팅을 검증하는 식의 멀티태스킹 테스트가 불가능하다. - 느린 속도와 리소스 소모: 디버깅용 UI와 스냅샷 녹화 기능을 상시 가동하기 때문에, 헤드리스 모드로 돌려도 다른 도구들에 비해 속도가 상대적으로 무겁고 느린 편이다.

---

Playwright : 모던 웹 생태계를 겨냥한 MS의 최종 병기

2020년 1월, 마이크로소프트(Microsoft)가 발표한 차세대 E2E 테스트 프레임워크.

구글에서 Puppeteer를 개발하던 핵심 엔지니어들을 MS가 대거 영입하여, Puppeteer가 가진 치명적인 한계점들을 보완하여 바닥부터 새로 설계해 내놓은 툴이다.

Puppeteer와 마찬가지로 크롬 개발자도구 프로토콜(CDP) 기반으로 설계되어, 브라우저 외부에서 빠르게 원격 제어하는 방식을 고수한다. 덕분에 브라우저 내부 기능을 폭넓게 사용할 수 있고 디버그 기능이 매우 우수하다. 뿐만 아니라 크롬(Chromium)을 넘어 사파리(WebKit), 파이어폭스(Firefox)까지 현대 웹 표준의 3대 브라우저 엔진을 모두 지원하도록 아키텍처를 확장했다. 최신 자바스크립트의 구조에 맞게 async/await 기반 동기화 시스템과 강력한 CLI 도구들을 제공한다.

특징 및 문법

• 다중 언어 및 크로스 브라우저 지원:
  자바스크립트/타입스크립트뿐만 아니라 Python, Java 등 다양한 프로그래밍 언어를 지원하며, 헤드 및 헤드리스 방식으로 주요 브라우저 환경을 완벽하게 교차 검증할 수 있다.
• 강력한 브라우저 컨텍스트 격리:
  하나의 브라우저 인스턴스 안에서 완전히 격리된 가상의 '사용자 프로필(Context)'을 수십 개씩 가볍게 생성할 수 있다. 이 덕분에 브라우저 창을 여러 개 띄워 서로 다른 유저가 실시간으로 상호작용하는 복잡한 시나리오를 가볍게 테스트한다.
• 최신 자동 웨이팅 및 도구 모음:
  Cypress처럼 요소가 렌더링될 때까지 자동으로 기다려 주는 기능은 물론, 코드 작성 과정을 녹화하여 테스트 스크립트를 자동으로 짜주는 Codegen 기능 등을 문법적으로 지원한다.

장점과 단점

장점	- 진정한 멀티 브라우저 & 다중 컨텍스트 지원: 코드 한 줄로 크롬, 파이어폭스, 사파리 환경을 동시에 켜서 테스트할 수 있다. 특히 메모리 격리 기술이 뛰어나 브라우저 창 하나로 여러 명의 유저가 동시에 접속해 상호작용하는 복잡한 시나리오(예: 구글 문서 동시 편집, 실시간 채팅 등)도 가볍게 소화한다. - 압도적인 실행 속도와 병렬 처리: 가벼운 프로토콜 제어 방식을 취하므로 Cypress보다 훨씬 가볍고 빠르고, 수십 개의 테스트 파일을 여러 CPU 스레드에 쪼개어 동시에 돌리는 병렬 처리 능력이 매우 뛰어나다.
단점	- 상대적으로 높은 진입장벽: Cypress처럼 직관적인 타임라인 UI가 기본으로 열리는 방식이 아니어서, 텍스트 터미널 중심의 환경이나 비동기 await 문법 흐름을 완벽히 이해하지 못한다면 초기 디버깅 난이도가 다소 높게 느껴질 수 있다.

---

E2E 테스트 프레임워크 선택 시 고려해야하는 요소

프로젝트에 도입할 자동화 툴을 고를 때는 단순히 '요즘 유행하는 툴'을 선택해서는 안 된다. E2E 테스트는 작성하는 것보다 유지보수하는 비용이 몇 배는 더 드는 깐깐한 작업이기 때문이다. 실무 환경에서 지속 가능한 개발을 위해서는 아래의 10가지 핵심 고려 요소를 기반으로, 우리 팀에 맞는 최적의 툴을 선택해야 한다.

1. 사용 및 도입의 용이성 (Ease of Use):
   아무리 성능이 뛰어난 툴이라도 초기 설치가 복잡하고 가이드 문서가 불친절하면 팀에 도입하기 어렵다. 나 혼자 테스트 코드를 짜고 만족할 게 아니라면, 동료 개발자나 심지어 테스트 코드를 처음 접하는 기획자/QA 담당자도 큰 진입장벽 없이 스크립트를 이해하고 작성할 수 있어야 한다. 테스트를 화면에 띄우기까지 몇 분이 걸리는지, 문법이 얼마나 인간 친화적이고 직관적인지가 DX의 시작점을 결정한다.
   
   
2. 보고서 및 디버그 (Reporting & Debugging):
   E2E 테스트 코드는 필연적으로 정말 자주 깨진다. 웹사이트의 레이아웃이 아주 조금만 바뀌거나, 서버 응답이 0.1초만 늦어져도 테스트 로봇은 에러를 뱉는다. 이때 "어디서 왜 실패했는지"를 모르면 에러 원인을 찾느라 반나절을 허비하게 된다. 테스트가 터진 시점의 화면을 스크린샷으로 남겨주는지, 마우스 동선을 비디오로 녹화해 주는지, 혹은 전용 타임라인 UI를 통해 에러 라인을 정확히 짚어주는지 같은 '디버깅 편의성'은 개발자의 피로도를 줄여주는 핵심 요소다.
   
   
3. 툴 스택 연동 (Tool Stack & CI/CD Integration):
   테스트 자동화의 진정한 가치는 개발자가 매번 수동으로 명령어를 입력하지 않아도 배포 파이프라인 안에서 알아서 구동될 때 발휘된다. 내가 만든 웹사이트를 GitHub에 올리거나 배포할 때, GitHub Actions나 Jenkins 같은 CI/CD 도구와 매끄럽게 연동되어 "테스트 통과 못 하면 배포 금지!" 같은 안전장치를 만들 수 있어야 한다. 우리가 기존에 사용하는 빌드/배포 도구들과 얼마나 찰떡같이 맞아떨어지는지 확인해야 하는 이유다.
   
   
4. 테스트 확장성 및 병렬성 (Scalability & Parallelism):
   초기에 테스트 파일의 개수가 적다면 실행시간이 몇 초 안 걸릴 수 있다. 하지만 서비스가 커져서 검증해야 할 화면과 시나리오가 수백 개로 늘어나면, E2E 테스트 한 번 돌리는 데 30분에서 1시간씩 걸리는 대참사가 발생한다. 테스트가 너무 무거우면 개발자들은 테스트 돌리기를 기피하게 된다. 따라서 수많은 테스트 스크립트를 여러 CPU 코어에 쪼개어 동시에 실행하는 '병렬 처리(Parallelism)' 능력이 얼마나 뛰어난지, 클라우드 인프라로 확장할 수 있는 구조인지를 반드시 따져야 한다.
   
   
5. 커뮤니티 (Community Support):
   오픈소스 도구를 쓸 때 가장 무서운 것은 "내가 마주한 에러의 해결책이 구글에 없을 때"다. 커뮤니티 규모가 작거나 인기가 식은 툴은 버그가 발생해도 수정 버전이 잘 안 올라오고, 스택오버플로우에 질문을 올려도 아무도 답해주지 않는다. 반면 커뮤니티가 활발한 도구는 이미 수많은 선배 개발자들이 남겨둔 해결책(레퍼런스)이 풍부하고, 생태계가 건강하게 유지되므로 안심하고 장기적인 프로젝트에 도입할 수 있다.
   
   
6. 프레임워크 확장 및 플러그인 (Extensibility):
   기본 제공 기능만으로는 현대의 복잡한 웹 애플리케이션을 전부 커버할 수 없다. 예를 들어, 개발을 하다 보면 화면의 시각적 픽셀 차이를 잡아내는 '시각적 회귀 테스트(Visual Regression)', 혹은 웹 접근성을 검사하는 기능(AXE 플러그인 등)이 필요해지는 순간이 온다. 이때 프레임워크 자체의 생태계가 넓어서 다른 라이브러리나 플러그인을 레고 블록처럼 쉽게 가져다 붙일 수 있는지가 중요하다.
   
   
7. 유지관리 및 재사용성 (Maintenance & Reusability):
   버튼의 위치나 디자인이 바뀔 때마다 수백 줄의 테스트 코드를 일일이 찾아가며 고쳐야 한다면, 테스트 자동화를 적용하는 의미가 없다. 로그인 로직이나 공통 네비게이션 이동 같은 반복되는 행동들을 함수나 객체 형태로 묶어서 다른 시나리오에서도 쉽게 재사용(Reusability)할 수 있어야 한다. 또한, 웹사이트의 마이너한 스펙 변경에도 테스트 코드가 쉽게 무너지지 않도록 유연한 구조를 지원하는지(유지관리)가 핵심이다.
   
   
8. 지능형 기능 (Intelligent Features):
   현대적인 E2E 프레임워크들은 똑똑한 인공지능형 편의 기능을 내장하고 있다. 대표적으로 개발자가 브라우저에서 마우스 클릭하고 타이핑하는 실제 행동을 그대로 녹화해서 테스트 스크립트 코드로 뚝딱 자동 생성해 주는 기능(Codegen)이 있다. 또한, 네트워크 지연으로 인해 화면이 늦게 뜰 때 개발자가 코드에 억지로 sleep(3000) 같은 대기 시간을 주입하지 않아도, 프레임워크가 알아서 요소가 렌더링될 때까지 유연하게 기다려 주는 '스마트 대기(Auto-waiting)' 기능 등이 이에 해당한다. 이러한 지능형 기능은 테스트 작성 속도를 단축시켜준다.
   
   
9. CELA 매트릭스 만족도:
   테스트의 시작과 끝을 아우르는 4대 핵심 라이프사이클을 균형 있게 만족하는지 평가하는 기준으로, 이 4가지 균형이 잘 잡힌 툴일수록 완성도 높은 테스트 환경을 구축할 수 있다.
   1. Creation (생성): 테스트 코드를 짜기 얼마나 쉽고 편리한가?
   2. Execution (실행): 백그라운드(Headless)에서 빠르고 가볍게 잘 돌아가는가?
   3. Lab (테스트 환경): 다양한 브라우저 엔진(크롬, 사파리 등)과 OS 환경을 안정적으로 제공하는가?
   4. Analysis (분석): 실패 리포트와 대시보드가 직관적이어서 원인 분석이 용이한가?
      
      
10. 툴 스택 연동의 범위 및 다중 언어 지원:
    프론트엔드 생태계는 자바스크립트와 타입스크립트가 지배적이지만, 회사나 팀에 따라 백엔드 개발자나 QA 엔지니어가 E2E 테스트를 함께 관리해야 하는 경우도 많다. 이때 자바스크립트뿐만 아니라 Python, Java, C# 등 다양한 프로그래밍 언어로도 동일한 테스트 스크립트를 작성할 수 있도록 범용성을 지원하는지 여부도 조직의 구성에 따라 강력한 고려 요소가 된다.

이 기준들을 머릿속에 담아두고, 방금 살펴본 자동화 3대장(Puppeteer, Cypress, Playwright)의 스펙을 요약 표로 대조해보면 어떤 도구가 내 프로젝트에 맞는지 정답이 보이기 시작한다.

---

cypress, playwright, puppeteer 한 눈에 비교하기

비교 항목	Puppeteer	Cypress	Playwright
지원 언어	자바스크립트	자바스크립트, 타입스크립트	JS, TS, 자바, 파이썬, .NET 등
지원 브라우저	크롬 중심 (Chromium)	크롬, Edge, Firefox	크롬, Edge, Firefox, Safari
구동 아키텍처	CDP (외부 원격 조종)	브라우저 내부	CDP 기반 확장 (외부 원격 조종)
iframe 새 창 제어	매우 자유로움 (시스템 권한)	한계 있음 (보안 정책 적용)	매우 자유로움 (시스템 권한)
디버깅 편의성 (DX)	보통 (터미널 중심)	우수 (전용 UI 대시보드)	우수 (플레이라이트 검사기)
웹 접근성 검증	라이트하우스 및 외부 라이브러리 연동	AXE 플러그인 설치 필요	AXE 내장 및 자체 내장기능
API 테스트	미지원	지원	지원
시각적 테스트	- 프레임워크 내장 기본 스크린샷 - 퍼시 연동 (percy)	- storybook (오픈소스) - percy, happo 등 (유료)	- 스크린샷 (내장 기능) - 유료 툴 연동
헤드/헤드리스	완벽 지원	지원 (헤드리스 시 기능성 다소 약함)	완벽 지원
최소 코딩 지원	미지원	Cypress Studio	Playwright Codegen
지속적 통합 (CI/CD)	- Github Actions - Docker	- Github Actions - GitLab - Bitbucket - CircleCI	- Jenkins - Docker - Bitbucket - CircleCI - Github Actions - GitLab
모바일 장치 테스트	시뮬레이션 기능 활용 (emulate() 함수)	뷰포트 및 유저 에이전트 변경	뷰포트 시뮬레이션 지원 (playwright.devices() 함수)
커뮤니티 생태계	중간 (꾸준히 성장 중)	매우 높음 (풍부한 플러그인)	보통 (성장 중)

3대장의 결정적인 차이

겉보기에는 3대장이 브라우저를 똑같이 조종하는 것처럼 보이지만, 내부를 들여다보면 완전히 다른 기술적 철학을 바탕으로 설계되어 있다. 3대장이 가진 결정적인 차이점을 이해하면, 프로젝트 상황에 맞는 최고의 툴을 고를 수 있는 안목이 생긴다.

1. 브라우저를 지배하는 위치의 차이 (In-Browser vs CDP)

세 툴이 브라우저와 소통하고 명령을 내리는 공간 자체가 다르다.

• Cypress는 브라우저 내부(In-Browser)에서 내 웹 애플리케이션과 같은 자바스크립트 런타임을 쓰며 나란히 실행된다. 덕분에 브라우저의 내부 메모리, DOM 요소, 상태 값에 즉각적으로 접근할 수 있어 실행 속도가 매우 빠르고 디버깅에 압도적으로 유리하다.
• Puppeteer와 Playwright는 브라우저 외부 시스템 권한에서 웹소켓 통신을 통해 크롬 개발자 도구 프로토콜(CDP)로 원격 제어한다. 브라우저 밖에서 실을 매달아 인형을 조종하는 것과 같아서, 브라우저가 제공하는 근본적인 내부 기능들을 폭넓게 사용하며 디버그 기능이 우수하다.

2. 보안의 벽을 넘는 능력의 차이 (새 창, 새 탭, iframe)

이 위치의 차이 때문에 웹 브라우저 고유의 '보안 정책'을 대하는 한계가 극명하게 갈린다.

• Cypress는 브라우저 내부 정책을 엄격하게 적용받는다. 따라서 하나의 테스트 시나리오 도중에 완전히 다른 도메인의 새 탭이 열리거나, 결제창이나 본인인증창 같은 외부 iframe 요소가 나타나면 이를 탐색하고 제어하기가 극도로 까다롭고 제한적이다.
• Puppeteer와 Playwright는 브라우저 외부에서 명령을 내리는 무소불위의 시스템 권한을 쥔다. 도메인이 다른 새 창이 뜨든, 내부에 수많은 iframe 늪이 있든 상관없이 보안 벽을 통째로 뚫고 들어가 자유자재로 요소를 클릭하고 제어할 수 있다.

3. 멀티 브라우저와 멀티태스킹 스케일의 차이

현대 웹 서비스는 여러 브라우저에서의 호환성과, 여러 유저 간의 실시간 상호작용 검증이 필수적이다.

• Puppeteer는 오직 구글 크롬(Chromium) 생태계 제어에만 집중되어 있어 멀티 브라우저 테스트가 까다롭고, 특정 언어(Node.js)만 지원하는 명확한 한계가 있다.
• Cypress는 다양한 브라우저를 지원하지만, 하나의 테스트 안에서 '동시에 여러 개의 브라우저 창'을 띄울 수는 없다. 즉, 구매자와 판매자가 실시간으로 채팅을 주고받는 시나리오를 한 스크립트 안에서 테스트할 수 없다.
• Playwright는 크롬, 사파리, 파이어폭스 등 주요 브라우저를 모두 지원한다. 또한 하나의 브라우저 안에서 완벽히 격리된 가상의 사용자 환경(Context)을 수십 개씩 가볍게 만들 수 있다. 덕분에 명령어 한 줄로 여러 명의 유저가 동시에 접속해 상호작용하는 복잡한 스케일의 테스트를 가볍고 빠르게 소화한다.

---

결론 : 그래서 나의 선택은?

지금까지 E2E 테스트 자동화 프레임워크의 개념부터 Puppeteer, Cypress, Playwright라는 3대장의 스펙과 아키텍처적 차이까지 샅샅이 파헤쳐 보았다.

솔직히 기술적 스펙만 보면 Playwright를 공부하는 게 맞을지도 모른다는 생각이 들었다. 다양한 브라우저 환경과 다중 창(Context) 제어가 가능하다는 점이 매우 매력적이었고, 실제로 수많은 모던 웹 서비스들이 Playwright로 전환하는 추세이기 때문이다.

그럼에도 불구하고 나는 '테스트 자동화' 입문에 Cypress를 사용하기로 선택했는데, 전용 UI 대시보드를 통해 화면의 변화를 시각적으로 추적할 수 있어 입문자 입장에서 학습 장벽이 낮다고 판단했기 때문이다. 복잡한 환경 설정이 필요 없는 '올인원(All-in-One)' 툴이라는 점도 매력적이었다. 게다가 이미 오랜 시간 생태계를 구축해 온 프레임워크인 만큼, 공부하다가 난관에 부딪혀도 풍부한 레퍼런스를 통해 쉽게 해결책을 찾을 수 있다는 점은 독학을 하는 입장에서 엄청난 안전장치라고 생각했다.

기술을 선택할 때 '무조건 절대적으로 좋은 기술'이란 없다. 내 프로젝트의 규모가 어느 정도인지, 그리고 내 개발 숙련도가 어디쯤 와있는지에 따라 최선의 선택은 늘 달라진다. 비록 몇 가지 제약이 있을지라도, 내가 지금 다루는 개인 프로젝트나 일반적인 웹 서비스의 핵심 시나리오(로그인, 폼 전송, 화면 전환 등)를 튼튼하게 방어하기에 Cypress는 차고 넘치도록 충분한 툴이다. 이번 기회에 Vitest와 Cypress를 함께 활용해 보며, '테스트 자동화'의 전체적인 메커니즘과 화면 검증 흐름을 완벽하게 내 것으로 만들어봐야겠다!