Playwright 공식 브라우저 문서는 Chromium, Firefox, WebKit의 세 엔진을 안내합니다. 일반적인 교차 브라우저 회귀에는 Playwright WebKit을 먼저 사용하고, 정식 Safari 동작을 승인해야 한다면 macOS에서 Safari WebDriver 테스트를 추가하세요. WebKit 테스트 통과를 Safari 실측 통과로 처리해서는 안 됩니다.
Playwright 엔드투엔드 테스트를 맡은 프런트엔드 엔지니어라면 Safari 호환성 검증의 범위를 판단하는 데 도움이 됩니다.
교차 브라우저 CI를 관리하는 QA·DevOps 엔지니어라면 어떤 작업을 Mac으로 분리할지 결정할 수 있습니다.
Safari 전용 기능을 개발한다면 실제 브라우저 검증과 테스트 증거를 나눠 관리할 수 있습니다.
공통 회귀 테스트의 범위
Playwright WebKit은 링크 이동, 폼 입력, 메뉴 열기, 화면 상태 변화처럼 브라우저 엔진 전반에 걸친 일반적인 상호작용을 반복 확인하는 데 적합합니다. Chromium, Firefox와 함께 프로젝트를 구성하면 코드 변경으로 기본 흐름이 깨졌는지 빠르게 확인할 수 있습니다.
다만 테스트가 통과해도 모든 사용자의 Safari 환경을 대표하지는 않습니다. 브라우저 빌드, 실행 플랫폼, Playwright 프로젝트 설정이 달라지면 결과의 적용 범위도 달라집니다. CI 기록에는 적어도 실행한 브라우저 프로젝트와 빌드, 운영체제, 테스트 커밋을 남기세요. 어떤 환경의 결과인지 모르면 회귀를 찾았을 때도 재현 조건을 좁히기 어렵습니다.
| 테스트 방식 | 확인에 적합한 범위 | 결과로 단정하면 안 되는 것 |
|---|---|---|
| Playwright WebKit | 공통 UI 동작과 브라우저 엔진 회귀 | 정식 Safari에서 동일하게 동작한다는 보장 |
| macOS의 WebKit | Safari와 가까운 WebKit 계열 동작 비교 | 브랜드 버전 Safari의 실제 동작 |
| macOS Safari WebDriver | 정식 Safari에서의 자동화 흐름과 버전별 동작 | 별도 확인하지 않은 사용자 환경 전체 |
Playwright는 자체적으로 조정된 WebKit 빌드를 사용합니다. 공식 문서는 macOS에서 WebKit을 실행하면 Safari에 더 가까운 테스트 환경을 얻을 수 있다고 설명하지만, 이를 Safari 자체 테스트와 동일시하지 않습니다. Playwright의 브라우저 빌드와 플랫폼 안내를 기준으로 테스트 목적을 구분하세요.
Safari에 가까운 WebKit 검사가 필요한 경우
Safari 사용 비중이 높은 화면에서 레이아웃이나 입력 동작의 이상을 미리 찾고 싶다면 macOS WebKit 검사가 도움이 됩니다. 하지만 테스트 결과에는 사용한 빌드와 플랫폼을 함께 남겨야 합니다. 결과가 좋더라도 공식 Safari 승인 근거로 바꾸어 읽을 수는 없습니다.
예를 들어 프런트엔드 팀이 공통 결제 흐름을 수정했다면 기존 CI의 WebKit 프로젝트로 주요 화면 전환과 입력 검사를 수행할 수 있습니다. 이후 Safari 전용 승인 조건이 없다면 그 결과를 공통 회귀 신호로 활용하면 됩니다. 특정 Safari 버전에서의 동작을 출시 조건으로 삼는다면 다음 단계에서 실제 Safari 검사를 추가하세요.
Playwright는 WebKit, Firefox, Chromium을 별도 브라우저 프로젝트로 구성할 수 있습니다. 프로젝트가 여러 환경을 실행한다면 브라우저 프로젝트 설정 문서의 설명을 바탕으로 결과 파일과 환경 식별자를 분리해 보관하세요. 그래야 WebKit 실패와 Safari 실패를 같은 원인으로 뭉뚱그리지 않습니다.
정식 Safari 검증이 필요한 경우
사용자가 실제 Safari에서 겪는 문제를 확인하거나 Safari 버전별 동작을 승인해야 한다면 macOS Safari에서 별도 검사를 실행하세요. Apple의 Safari WebDriver 사용 안내는 safaridriver를 이용한 Safari 자동화 경로를 설명합니다. Playwright WebKit 프로젝트를 정식 Safari 실행 방식으로 바꾸는 기능이라고 해석해서는 안 됩니다.
Safari WebDriver를 CI에 넣기 전에는 Apple의 Safari WebDriver 활성화 및 테스트 안내에 따라 Safari의 자동화 허용 설정을 확인하세요. 드라이버가 동작한다는 점은 자동화 실행의 근거일 뿐입니다. 테스트 대상 기능이 모두 자동화 가능하다거나, 테스트 결과가 모든 Safari 환경을 보장한다는 뜻은 아닙니다.
실행 환경에서는 브라우저 버전과 테스트 커밋을 결과에 묶으세요. Safari를 업데이트한 뒤 기존 결과와 비교할 수 있도록, 업데이트 시점과 실패 화면 또는 로그도 보관하면 좋습니다.
미디어와 플랫폼 기능의 검증
영상 재생, 미디어 형식, 플랫폼 기능에 기대는 화면은 WebKit에서 문제가 발견되는지 살펴본 뒤 Safari에서 실제 결과를 확인하는 편이 안전합니다. WebKit 엔진 검사는 잠재적인 호환성 문제를 찾는 증거이고, 정식 Safari 검사는 대상 브라우저에서 실제 사용자 흐름을 확인하는 증거입니다. 둘은 같은 결과로 합쳐지지 않습니다.
테스트에 사용하는 미디어 파일, Safari 버전, 실행 플랫폼을 기록하세요. 예를 들어 자동 재생이 중요한 제품이라면 단순히 재생 API 호출이 성공했는지만 보지 말고, 프로젝트에서 사용하는 미디어와 실제 사용자 조작 흐름을 Safari에서 확인해야 합니다. WebKit의 Safari 미디어 기능 변경 기록도 기능 범위를 살필 때 참고할 수 있지만, 특정 서비스의 재생 성공을 대신 증명하지는 않습니다.
| 테스트 시나리오 | 먼저 실행할 검사 | Safari 실측이 필요한 조건 |
|---|---|---|
| 공통 메뉴·폼·화면 전환 | 기존 CI의 Playwright WebKit 회귀 | 정식 Safari 동작이 출시 승인 항목인 경우 |
| Safari 전용 동작 | WebKit 검사로 초기 이상 탐지 | 대상 Safari 버전에서의 동작을 확인해야 하는 경우 |
| 동영상·미디어 흐름 | WebKit에서 잠재 문제 탐지 | 실제 미디어와 사용자 흐름의 재생 결과가 중요한 경우 |
파이프라인 분리와 Mac 도입 판단
기존 CI에서 일반 WebKit 회귀를 계속 실행하고, 정식 Safari 확인은 macOS Safari WebDriver 작업으로 분리하세요. 두 종류의 근거가 모두 필요한 팀은 분리된 단계로 구성하면 됩니다. 실패 원인과 승인 근거를 환경별로 확인할 수 있기 때문입니다.
다음 항목을 체크해 보세요.
- [ ] 출시 승인 기준에 정식 Safari 브라우저 동작이 명시되어 있나요?
- [ ] 지원 대상 Safari 버전과 테스트할 사용자 흐름을 정했나요?
- [ ] WebKit 결과와 Safari WebDriver 결과를 별도 작업과 산출물로 저장하나요?
- [ ] Safari 자동화 허용 설정과 실행 계정의 관리 책임자가 정해져 있나요?
- [ ] 테스트 실패를 재현할 때 필요한 브라우저 빌드, 플랫폼, 커밋 정보를 기록하나요?
- [ ] Safari 검사 실행 빈도와 Mac 환경을 직접 유지할 담당자를 정했나요?
Safari 검증이 출시 조건이 아니고 일반 회귀만 필요하다면 기존 크로스 플랫폼 CI의 WebKit 검사로 시작할 수 있습니다. 반면 Safari 전용 동작이나 실제 Safari 결과가 승인 근거라면 Safari WebDriver 작업을 분리하세요. macOS Safari 자동화 안내와 Playwright Trace Viewer 문서는 각각 Safari 자동화와 Playwright 테스트 기록의 목적을 살필 때 참고할 수 있습니다. 서로 다른 도구의 결과를 같은 브라우저 검증으로 간주하지 마세요.
Playwright WebKit만 사용하는 CI는 기존 환경을 유지하기 쉽지만 정식 Safari 확인을 제공하지 않습니다. 반대로 Safari 검사를 추가하면 Mac 실행 환경과 자동화 설정을 관리해야 합니다. Mac을 직접 보유해 상시 운영하는 방법도 있지만, 실제 Safari 테스트가 간헐적이거나 팀이 장비 관리를 원하지 않는다면 원격 Mac을 시험 운영하는 선택지가 있습니다. 다만 물리 장비 접근이 필요하거나 지속적인 고부하 작업이 주목적이라면 구매 또는 기존 인프라 유지가 더 적합할 수 있습니다.
먼저 Safari 테스트의 실행 빈도, 그래픽 세션 필요 여부, 운영 책임을 정리하세요. 그다음 KVMNODE의 원격 Mac 이용 정보와 Mac mini 대여 가격 안내를 비교해 Safari WebDriver 작업을 Mac 노드로 분리할 필요가 있는지 판단하면 됩니다. Mac을 보유하지 않은 팀이라면 실제 Safari를 쓰는 테스트만 원격 Mac에서 운영하는 방식으로 시작할 수 있습니다.