2026 프론트엔드 피하기 대조표:
원격 Mac에서 Vitest·jsdom vs Safari·WebKit
Vitest와 jsdom이 모두 통과해도 Safari에서만 깨진다면, 테스트 품질 문제가 아니라 호환성 계약이 비어 있는 것입니다. 이 글은 프론트엔드·풀스택·웹 QA가 jsdom이 증명하는 범위와 WebKit에서만 증명되는 범위를 나누고, 원격 Mac을 릴리스 게이트로 쓰는 방법을 정리합니다. 이벤트·폰트·미디어·스토리지 등 대조표, 실행 가능한 로컬 대 실기 검증 플로우, CI 파라미터, FAQ를 포함합니다. 관련 글: Playwright Safari 호환, 실기·시뮬·클라우드 3단계, 블로그 목록.
01 차이·리스크 개요
jsdom은 Node에서 DOM 표준을 흉내 내는 구현체이지 브라우저가 아닙니다. Vitest는 Linux CI에서도 빠르게 돌아가지만, 레이아웃 엔진·실제 합성·이벤트 파이프라인의 공백을 그대로 물려받습니다. Safari는 Apple WebKit, ITP, GPU 기반 렌더링 등 정책이 Chromium과 다릅니다.
단위 테스트 통과는 "필요 조건"이지 "충분 조건"이 아닙니다. 스크롤·passive 이벤트 의미, 동영상 자동재생 정책, localStorage 파티셔닝, 서브픽셀 폰트 줄바꿈은 jsdom만으로는 보증하기 어렵습니다. iOS 기본 브라우저·macOS 엔터프라이즈 비중이 크다면 Apple 기기에서의 둘째 층 검증을 문서화해야 합니다.
모두가 Mac을 책상에 두기 어렵다면 원격 Mac으로 SSH·VNC·자동화 러너를 붙여 Safari·Playwright WebKit을 같은 스택에서 돌리면 됩니다. 도움말에서 SSH·VNC를 로그인 없이 확인하세요.
02 대조표: 핵심 API·렌더링
아래 표를 설계 리뷰·테스트 플랜에 붙여 쓰세요. "jsdom·Vitest"는 기본 environment: 'jsdom'을 가정합니다(happy-dom 등으로 바꾸면 행이 달라집니다).
| 영역 | jsdom·Vitest(일반적) | Safari·WebKit(원격 Mac) | 테스트 시사점 |
|---|---|---|---|
| 포인터·터치 이벤트 | 합성 이벤트, 실제 히트 테스트·브라우저식 passive 기본값 없음 |
네이티브 파이프라인, iOS 제스처 특성 | 스크롤 영역 드래그·휠·preventDefault Safari 수동 확인 |
| 포커스·키보드 | 프로그램 포커스는 되나 탭 순서 단순화 | focus-visible, 섀도 DOM, 키보드 전체 접근 | 폼·모달을 키보드만으로 스모크 |
| 레이아웃·CSS | 픽셀까지의 실제 레이아웃 없음 | WebKit 서브픽셀, flex/grid, 100dvh, backdrop-filter |
히어로·sticky 헤더는 시각 비교 또는 수동 |
| 폰트·텍스트 | 시스템 메트릭이 macOS·iOS와 다름 | Core Text, 가변 폰트, 하이픈·CJK 줄바꿈 | 말줄임·다국어 줄바꿈을 실제 Safari에서 비교 |
| 미디어(영상·오디오) | 목·스텁 위주, 코덱 미검증 | HLS, CORS, 자동재생 정책, 저전력 모드 | 스테이징에서 사용자와 유사 설정으로 재생 경로 1회 |
| 스토리지 API | localStorage가 메모리에 가깝고 할당·퇴거 미재현 |
ITP 파티셔닝, 저장소 압박 시 퇴거 | 로그인 지속성·오프라인 캐시를 사이트 데이터 삭제 시나리오로 확인 |
| 타이머·스케줄링 | requestAnimationFrame 근사 |
실제 프레임, Page Visibility | 애니메이션 플레이키 테스트는 WebKit E2E 쪽이 안전 |
| 네트워크·fetch | MSW·vi.stubGlobal 등 모킹 |
CORS 프리플라이트, 쿠키 SameSite, 서드파티 규칙 | 실제 오리진 또는 Playwright 네트워크로 통합 검증 |
03 로컬 vs 실기·원격 검증 플로우
아래 배포 전 3단계 게이트를 표준화하면 Vitest만으로 배포하는 실수를 줄일 수 있습니다.
- 1단계 — 로컬 또는 CI(Linux):
vitest run과 커버리지 임계값. 레이아웃·미디어에 닿는 테스트는 마커로 분리(describe.skip또는 파일 분할)해 jsdom에서 거짓 실패를 줄입니다. - 2단계 — 원격 Mac, Safari.app: 스테이징 URL을 Safari로 열고 P0 퍼널(인증·결제·미디어·업로드 등)을 대조표 기준으로 워크스루. 콘솔·성능은 원격 Mac Web Inspector FAQ를 참고하고, WebKit 디버깅 습관은 Safari 19·WebKit 디버깅 가이드와 맞춥니다.
- 3단계 — 자동화 패리티: 같은 Mac에서 Playwright
webkit프로젝트로 스테이징을 돌리고 trace를 보관합니다. 빌드·배포 후 Safari 확인 흐름은 Vite·Webpack 배포 후 Safari 검증 단계와 연결하면 좋습니다.
분석 기준과 Safari 메이저 버전을 맞추고, 스모크 시 확장 프로그램을 끕니다. OTT·웨비나는 창 모드·전체화면 재생을 둘 다 확인하고, ITP 시뮬을 위해 사이트 데이터를 한 번 비운 뒤 재방문 시나리오를 넣습니다.
04 CI 파라미터 제안
파이프라인을 쪼개세요: PR마다 빠른 jsdom, main·야간에 원격 Mac 러너에서 WebKit.
| 관심사 | 권장 설정 | 이유 |
|---|---|---|
| Vitest 워커 | --pool=threads, 공유 Mac에서는 maxWorkers를 CPU−1 수준으로 상한 |
Playwright와 동시에 돌 때 기아 현상 방지 |
| 타임아웃 | E2E는 testTimeout 여유, 단위는 엄격 유지 |
WebKit 콜드 스타트·영상 준비 시간 편차 |
| Playwright | macOS 에이전트에서만 npx playwright install webkit |
Linux WebKit ≠ Safari; 대시보드에 라벨을 명확히 |
| 아티팩트 | 실패 시 trace·video 항상 업로드 | 분석은 E2E 로그 트리아지 가이드와 같은 산출물 규칙이 유리 |
테스트 실행 전 Node·툴체인 정합은 원격 Mac Node·npm·Safari 호환 체크리스트와 함께 보세요.
05 FAQ
Vitest로 Safari 수동 확인을 없앨 수 있나요?
아니요. jsdom은 시뮬레이션 환경이고 Safari는 이벤트·스토리지·미디어·레이아웃이 다릅니다. 단위 → 원격 Mac WebKit·Safari 스모크 → 스테이징·실기 P0의 3단계를 유지하세요.
왜 원격 Mac에서 WebKit을 돌리나요?
실제 Safari는 macOS·iOS에 있습니다. 원격 Mac은 많은 사용자와 같은 WebKit·그래픽 스택을 제공하고, Linux CI에서는 진짜 Safari를 실행할 수 없습니다.
Playwright webkit이 Safari와 같나요?
macOS에서는 jsdom보다 훨씬 가깝지만 정책·GPU 경로까지 동일하다고 보기 어렵습니다. 회귀 자동화로 쓰고, 핵심 UX는 Safari.app에서 최소 한 번 확인하세요.
속도와 커버리지를 같이 잡는 저비용 패턴은?
푸시마다 jsdom, 전용 Mac 예약 WebKit 잡, 릴리스 티켓 Safari 체크리스트 미체크 시 배포 차단.
기능을 대조표에 매핑하고 Vitest는 속도, 릴리스는 원격 Mac에서 Safari·WebKit trace로 게이트하세요. jsdom 전용·WebKit 필수 테스트를 문서화해 CI 초록과 Safari 안전을 동치로 보지 마세요.
로그인 없이 다음을 이용할 수 있습니다: 도움말(SSH·VNC·시작하기), 요금 비교, 홈에서 Mac Mini 대여·구매 흐름. 관련 글은 블로그 목록에서 계속 보실 수 있습니다.
Vitest에 더해 WebKit 게이트를 올릴 원격 Mac
Apple Silicon에서 실제 Safari와 Playwright WebKit을 실행하세요. 계정 없이 대여·구매 안내, 요금, 도움말을 먼저 확인할 수 있습니다. 추천 읽을거리: Safari 호환성 테스트, 전체 기사.