Playwright WebKit 대 Safari 27: 2026년 원격 테스트는 어떻게 선택할까

Playwright 공식 문서는 Playwright가 자체적으로 관리하는 WebKit 브라우저를 사용하며, 브랜드 버전의 Safari를 직접 실행하지 않는다고 설명합니다. 따라서 WebKit 엔진이 가깝다는 사실만으로 Safari의 브라우저 외피, 운영체제 통합, 권한 대화상자와 버전별 동작까지 같다고 볼 수 없습니다. Playwright 브라우저 문서는 이 차이를 명확히 구분합니다.

이 차이 때문에 “Playwright WebKit 통과”와 “Safari 27 통과”는 서로 다른 주장입니다. 전자는 특정 Playwright 실행 환경에서 웹 기능이 동작했다는 뜻이고, 후자는 실제 Safari와 macOS 조합에서 사용자 흐름이 재현되었다는 뜻입니다.

Safari 27은 2026년 9월 1일 기준 Apple 공식 자료에서 베타로 표시됩니다. 따라서 Safari 27의 WebDriver 변화가 공개되어 있더라도 안정 버전의 장기 지원이나 전체 호환성을 약속하는 근거로 사용해서는 안 됩니다. Safari 27 출시 기록을 확인한 뒤 베타와 안정 기능을 분리해 기록해야 합니다.

그렇지 않습니다. Playwright WebKit은 엔진 수준의 회귀를 찾는 데 강하지만 브랜드 Safari에서만 나타나는 플랫폼 동작까지 보장하지 않습니다.

다음과 같이 결과의 의미를 나누면 됩니다.

• 레이아웃, 기본 자바스크립트 흐름, 일반적인 탐색 회귀는 WebKit 빠른 검사에서 우선 확인합니다.
• Safari의 권한 요청, 시스템 글꼴, 키체인 접근, 파일 선택기와 같은 운영체제 통합은 실제 Safari에서 확인합니다.
• 오디오·비디오 코덱, 카메라·마이크 권한, 화면 공유, 장치 연결은 WebKit 단독 통과를 출시 증거로 삼지 않습니다.
• Safari 확장 기능과 Safari 고유 정책은 실제 Safari와 Safari WebDriver 조합으로 별도 검증합니다.

Linux에서 실행하는 Playwright WebKit은 Linux 환경의 글꼴, 그래픽 세션, 오디오 장치와 함께 동작합니다. 그러므로 Linux CI에서 발견할 수 있는 문제와 실제 Safari에서만 발견되는 문제의 범위가 다릅니다. Linux 검사는 빠른 이상 탐지에 사용하고, Safari 특유의 실패 여부는 원격 Mac에서 재현해야 합니다.

테스트 대상을 다음 세 범주로 나누면 환경 선택이 쉬워집니다.

WebKit 단독으로 충분한 경우

• 정적 콘텐츠 페이지의 기본 탐색
• 일반 폼 검증과 링크 이동
• 브라우저 간 공통으로 사용하는 자바스크립트 상태 변화
• 커밋마다 반복하는 안정적인 회귀 집합

실제 Safari를 추가해야 하는 경우

• 미디어 재생, 자동 재생 정책, 코덱 처리
• 카메라·마이크·알림·위치 권한
• 시스템 글꼴과 텍스트 입력 동작
• 키체인, 파일 접근, 장치 연동
• Safari 확장 기능 또는 Safari 고유 보안 정책

이중 테스트가 적합한 경우

• 결제, 로그인, 계정 복구처럼 출시 차단이 필요한 흐름
• 웹 앱의 핵심 편집 화면과 복잡한 드래그·파일 업로드
• 매일 바뀌는 프론트엔드와 여러 운영체제를 함께 지원하는 서비스
• Safari에서 신고된 결함이 아직 최소 재현으로 축소되지 않은 경우

운영 중 주의할 점
같은 실패가 WebKit과 Safari에서 모두 발생하면 사이트 결함일 가능성을 먼저 조사합니다. WebKit은 통과하고 Safari만 실패하면 Safari 고유 동작을 의심하되, 단 한 번의 실패만으로 결론을 확정하지 말고 동일한 입력과 브라우저 버전으로 다시 실행해야 합니다.

Playwright는 브라우저 실행, 컨텍스트, 추적 자료를 하나의 자동화 흐름으로 다루기 쉽습니다. 반면 실제 Safari 자동화는 Safari WebDriver와 safaridriver를 중심으로 구성되며, macOS에서 WebDriver를 활성화하고 그래픽 세션과 권한 상태를 관리해야 합니다. Apple의 Safari WebDriver 테스트 문서와 macOS WebDriver 활성화 안내는 이 설정 경계를 설명합니다.

브라우저 설치와 캐시 재사용은 Playwright 쪽에서 상대적으로 일관되게 관리할 수 있습니다. 실제 Safari 쪽은 브라우저만 준비하면 끝나지 않습니다. 화면 잠금, 사용자 세션, 권한 팝업, safaridriver 프로세스, 노드 재부팅 뒤의 자동 복구까지 운영 범위에 포함됩니다.

따라서 속도나 비용을 근거 없이 단정하기보다 테스트 빈도와 실패 영향으로 분리해야 합니다. 커밋마다 실행되는 큰 회귀 집합은 WebKit에 두고, 로그인·결제·미디어 같은 핵심 경로는 병합 요청이나 출시 후보 단계에서 실제 Safari로 보냅니다.

그대로 옮길 수 있다고 가정하면 안 됩니다. Playwright의 선택자와 대기 방식이 Safari WebDriver의 세션 관리, 권한 승인, 창 제어와 동일하지 않기 때문입니다.

먼저 기능 목록을 만들고 각 단계의 자동화 가능 여부를 확인합니다.

• 탐색과 선택자: CSS 선택자, 접근성 이름, 새 창 이동이 두 드라이버에서 같은 결과를 내는지 확인합니다.
• 대기 조건: 네트워크 유휴 상태에 의존하지 말고 화면에 나타난 상태와 업무 완료 조건을 함께 검사합니다.
• 권한 승인: 카메라, 마이크, 알림 요청이 자동 승인된 것처럼 보이지 않는지 실제 Safari에서 확인합니다.
• 파일 처리: 업로드 경로, 다운로드 저장 위치, 파일명과 권한을 원격 Mac의 사용자 세션에서 검증합니다.
• 창과 탭 관리: 팝업, 새 탭, 외부 인증 흐름이 safaridriver 세션에서 예상대로 돌아오는지 확인합니다.
• 베타 기능 경계: Safari 27 출시 기록에 언급된 새 WebDriver 기능은 베타와 안정 상태를 테스트 보고서에 따로 표시합니다.

실제 Safari를 CI에 붙일 때는 기존 Playwright 작업을 억지로 변환하기보다 테스트 계약을 먼저 정의하는 편이 좋습니다. 같은 테스트 데이터, 같은 최소 재현 절차, 같은 성공 조건을 공유하고 드라이버별 실행 코드는 분리하면 실패 원인을 더 쉽게 추적할 수 있습니다.

다음 흐름은 특정 도구에 종속되지 않으면서 운영하기 쉽습니다.

첫째, 커밋 단계에서는 Playwright WebKit으로 짧고 안정적인 공통 회귀를 실행합니다. 실패가 나면 개발자가 빠르게 수정할 수 있도록 콘솔 로그와 최소 화면 자료를 남깁니다.

둘째, 병합 요청 단계에서는 변경된 영역과 연결된 Safari 핵심 경로를 원격 Mac으로 보냅니다. 로그인, 결제, 파일 업로드처럼 사용자 영향이 큰 기능은 변경 범위가 작아도 제외하지 않는 편이 안전합니다.

셋째, 매일 실행하는 전체 회귀에서는 WebKit과 실제 Safari를 같은 테스트 데이터로 비교합니다. 환경별 결과를 한 리포트에 섞지 말고 브라우저, 운영체제, 드라이버와 실행 시각을 별도 필드로 기록합니다.

넷째, 출시 후보에서는 실제 Safari 결과를 배포 승인 조건으로 사용합니다. Safari 노드가 준비되지 않았거나 자동화 권한이 사라졌다면 “통과”가 아니라 “검증 불가”로 표시해야 합니다.

다섯째, 실패한 작업은 원격 Mac에서 재시도하기 전에 노드 상태를 확인합니다. 화면 세션, WebDriver 프로세스, 테스트 계정, 권한 팝업이 남아 있으면 재시도 결과가 원래 실패를 가릴 수 있습니다.

실제 Safari 테스트를 기존 지속적 통합 흐름에 연결하려면 전용 실행 대기열, 비밀값 저장소, 작업 제한 시간, 노드 재시작 정책을 함께 정해야 합니다. Safari WebDriver의 자동화 및 동시 실행 안내는 Safari 자동화 세션의 운영 조건을 검토할 때 사용할 수 있습니다.

Playwright는 Trace Viewer를 통해 화면 상태, 동작 순서와 네트워크 관련 자료를 묶어 확인할 수 있습니다. Playwright 디버깅 문서를 참고해 실패 시 추적 자료, 화면 캡처와 영상 기록을 저장하도록 구성합니다.

실제 Safari에서는 Safari Web Inspector와 WebDriver 로그가 다른 종류의 단서를 제공합니다. DOM 상태, 콘솔 오류, 네트워크 요청과 렌더링 상태를 확인하려면 Safari Web Inspector 공식 문서를 기준으로 팀의 재현 절차를 정해야 합니다.

각 실패에는 최소한 다음 정보를 붙입니다.

• 테스트 이름과 변경된 커밋
• 브라우저 이름과 버전, 운영체제와 WebDriver 방식
• 테스트 계정과 재현에 필요한 입력 데이터
• 실패 직전의 화면, 콘솔, 네트워크 자료
• WebKit에서는 통과했는지, Safari에서만 실패했는지
• 노드 재시작 뒤에도 동일하게 발생하는지

이 자료가 있어야 사이트 결함, WebKit 구현 차이, Safari 고유 문제를 구분할 수 있습니다. 성공한 한 번의 실행은 다른 브라우저와 운영체제에서의 호환성 증명이 아닙니다.

• 낮은 위험의 콘텐츠 페이지: Playwright WebKit을 주 검사로 사용하고 Safari는 변경 시점에 표본 검증합니다.
• 일반적인 상호작용 웹 앱: WebKit을 병합 전 회귀에 사용하고 로그인, 업로드, 핵심 편집 흐름은 실제 Safari로 확인합니다.
• 미디어 중심 서비스: 코덱, 권한, 재생 정책 때문에 실제 Safari를 필수 경로로 둡니다.
• Safari 확장 기능: Safari와 safaridriver를 중심으로 검증하며 WebKit 결과는 보조 자료로만 취급합니다.
• 출시 차단 업무: WebKit 빠른 검사와 Safari 승인 검사를 함께 운영합니다.

원격 Mac 테스트 노드를 도입하기 전에는 다음 항목을 체크해야 합니다.

• [ ] Playwright WebKit과 실제 Safari로 보낼 테스트 규칙이 문서화되어 있습니다.
• [ ] Safari 실행 및 자동화 권한을 새 노드에서 재현할 수 있습니다.
• [ ] 브라우저 버전과 운영체제 정보를 결과에 자동 기록합니다.
• [ ] Trace Viewer, 화면 자료, Web Inspector 로그를 함께 보관합니다.
• [ ] 노드 재부팅과 그래픽 세션 복구 절차를 검증했습니다.
• [ ] Safari 검증 불가 상태를 자동 통과로 처리하지 않습니다.
• [ ] 베타 기능과 안정 기능을 보고서에서 구분합니다.
• [ ] 일정 기간 뒤 WebKit 단독으로 되돌릴 조건과 실제 Safari를 확대할 조건이 정해져 있습니다.

결국 선택 기준은 “Playwright WebKit이 Safari와 얼마나 비슷한가”가 아니라 “실패했을 때 어느 정도의 증거가 필요한가”입니다. 낮은 위험의 반복 검사는 WebKit으로 유지하고, Safari 27 호환성과 출시 승인이 중요하면 실제 원격 Mac을 추가하며, 대부분의 지속적 배포 팀에는 두 환경을 나누는 이중 구성이 가장 현실적입니다.

Linux CI만 사용하는 현재 방식은 빠른 회귀에는 유리하지만 macOS 권한, 시스템 글꼴, 미디어 장치와 Safari 전용 동작을 확인할 수 없고, 실패 재현을 위해 별도 장비를 급히 확보해야 하는 단점이 있습니다. Mac을 직접 구매하면 물리 장비와 유지보수, 장기 유휴 비용이 생깁니다. 단기간에 출시 경로를 검증하거나 팀의 Mac CI 적합성을 먼저 판단해야 한다면 NUKCLOUD의 원격 Mac 환경에서 실제 Safari 실행, 자동화 권한, 진단 자료 수집과 재시작 복구를 먼저 시험하는 편이 합리적입니다. 장기적인 고정 부하나 물리 장치 연결이 핵심인 팀은 직접 장비를 운영하고, 임시 검증과 테스트 노드가 필요한 팀은 원격 Mac 요금 안내를 확인한 뒤 짧은 기간부터 시작하면 됩니다.

마지막 업데이트: 2026년 9월 1일. Playwright 브라우저 문서, Apple Safari 27 출시 기록, Apple WebDriver 및 Web Inspector 문서를 기준으로 내용을 확인했습니다.