크로스 브라우저 대응 전략 정리

항상 머릿속으로 어떻게 크로스 브라우징을 개발단계, CI단계, QA단계에서 효율적으로 대응 할 수 있을까? 란 생각을 했었던 것 같다. 실제로 실무 경험상 다양한 브라우저와 해당 브라우저에 대한 모든 지원 버전을 조합한 케이스를 모두 테스트 하는 건 현실적으로 리소스상 어렵지 않을까 하는 생각을 했었고, 그럴 필요가 있을까 하는 생각도 많이 했던 것 같다.

그렇다면 어떤 전략을 이용하여 효과적으로 크로스 브라우징을 대응할 수 있을까? 란 생각을 하며, 개인적인 의견을 정리해 보았다.

1. 지원 브라우저 범위 정의하기

가장 먼저 제품이 공식적으로 지원할 브라우저와 버전을 정해야 한다. 예를 들면 다음과 같은 정책을 세울 수 있다.

• Chrome과 Edge의 최신 2개 버전
• Firefox의 최신 2개 버전
• Safari 16 이상
• 필요한 경우 iOS Safari와 Android Chrome

지원 범위는 서비스의 사용자 통계, 비즈니스 요구사항, 브라우저별 시장 점유율과 유지보수 비용을 고려해 결정해야 한다. 모든 브라우저와 버전을 지원하겠다는 정책은 사실상 검증하기도, 유지하기도 어렵다.

정해진 범위는 보통 package.json의 browserslist 필드에 기록한다.

{
  "browserslist": ["last 2 Chrome versions", "last 2 Edge versions", "last 2 Firefox versions", "Safari >= 16"]
}

Browserslist는 그 자체로 코드를 변환하거나 호환성을 검사하는 도구가 아니다. Babel, Autoprefixer처럼 Browserslist를 사용하는 도구에 프로젝트의 대상 브라우저 정보를 전달하는 공통 설정에 가깝다.

browserslist 관련 참고 링크

• https://web.dev/articles/use-baseline-with-browserslist?hl=ko
• https://github.com/browserslist/browserslist

2. 개발 단계에서 호환성 확인하기

지원 범위를 정했다면 개발자는 새로운 Web API나 CSS 기능을 사용할 때 해당 기능이 대상 브라우저에서 동작하는지 확인해야 한다. 이때 Can I use와 MDN의 브라우저 호환성 표를 활용할 수 있다.

호환되지 않는 기능을 발견했을 때 아래와 같은 방법을 이용하면 될 것 같다

• 지원되는 다른 문법이나 API 사용
• 대체 동작 제공
• 필요한 폴리필 추가

CSS 기능은 지원되지 않을 때 단순히 무시될 수 있고, 일부 Web API는 폴리필로도 완전히 구현할 수 없다. 따라서 빌드 도구가 모두 해결해 줄 것이라고 가정해서는 안 된다.

3. 빌드 단계에서 트랜스파일링과 폴리필 적용하기

트랜스파일링과 폴리필은 서로 다른 문제를 해결한다.

• 트랜스파일링은 최신 JavaScript 문법을 이전 브라우저가 이해할 수 있는 문법으로 변환한다. (예: es6의 arrow function → es5의 function)
• 폴리필은 브라우저에 존재하지 않는 런타임 API를 코드로 보완한다.
• CSS 변환 도구는 벤더 프리픽스를 추가하거나 일부 최신 문법을 호환 가능한 형태로 변환할 수 있다.

예를 들어 optional chaining은 빌드 과정에서 이전 문법으로 변환할 수 있지만, structuredClone 같은 Web API는 문법 변환만으로 생기지 않는다. 대상 브라우저가 해당 API를 지원하지 않는다면 별도의 폴리필이나 대체 구현이 필요하다.

현재 이 프로젝트에서 사용하는 Next.js 16의 기본 지원 범위는 다음과 같다. ( 기재된 버전이상을 지원한다는 의미이다.)

{
  "browserslist": ["chrome 111", "edge 111", "firefox 111", "safari 16.4"]
}

필요하다면 위 지원범위와 다르게 package.json의 browserslist 설정으로 대상 브라우저를 별도로 지정할 수 있다.

Next.js는 최신 JavaScript 문법을 빌드 과정에서 변환하며, fetch, URL, Object.assign처럼 널리 사용되는 일부 기능의 폴리필도 제공한다.

이 폴리필은 필요한 브라우저에만 로드되고(사용자의 브라우저 환경에 따라), 의존성이 같은 폴리필을 중복으로 포함하면 프로덕션 빌드에서 중복을 제거한다.

하지만 Next.js가 모든 Web API의 폴리필을 자동으로 제공하는 것은 아니다.

폴리필 지원 범위에 없는 기능이 필요하다면 직접 폴리필을 추가해야 한다.

App Router에서는 instrumentation-client.ts에서 가져오거나, 기능이 필요한 시점에 조건부로 불러올 수 있다고 한다.

if (!('structuredClone' in globalThis)) {
  const { default: structuredClone } = await import('polyfills/structured-clone')
 
  globalThis.structuredClone = structuredClone
}

자세한 내용은 Next.js의 지원 브라우저와 커스텀 폴리필 문서에서 확인할 수 있다.

4. 실제 브라우저에서 검증하기

정적 호환성 정보와 빌드 단계만으로 모든 문제를 찾을 수는 없다.

기능 지원 여부가 같더라도 브라우저와 운영체제에 따라 화면 표시나 동작이 달라질 수 있다.

또한 영상 형식, 폰트, 마우스·터치·키보드 같은 입력 방식에 따라서도 문제가 발생할 수 있으므로 실제 환경에서 테스트해야 한다.

Playwright

Playwright는 Chromium, Firefox, WebKit에서 E2E 테스트를 실행할 수 있는 오픈소스 도구다.

Playwright는 각 버전과 호환되는 브라우저 바이너리를 내려받아 사용한다. 다만 기본 Chromium은 Google Chrome이나 Microsoft Edge 자체가 아니고, Playwright용 WebKit도 Safari 자체가 아니다. Firefox 역시 자동화에 필요한 패치가 적용된 빌드를 사용한다. 따라서 실제 사용자가 사용하는 정식 브라우저와 동작이 완전히 같다고 볼 수는 없다.

Chrome과 Edge는 브라우저 채널을 설정하여 정식 브라우저로 테스트할 수 있지만, 정식 Firefox와 Safari는 직접 지원하지 않는다. 특히 Safari를 가장 가깝게 검증하려면 macOS에서 Playwright용 WebKit 테스트를 실행하는 편이 낫지만, 이것도 실제 Safari 테스트를 완전히 대체하지는 못한다.

Playwright가 기본으로 제공하는 Chromium, Firefox, WebKit의 버전은 Playwright 버전에 종속된다. CLI에서 이 브라우저들의 임의 버전을 자유롭게 지정하는 방식은 공식적으로 지원되지 않는다. 특정 번들 브라우저 버전이 필요하다면 그 버전을 제공하는 Playwright 버전을 함께 고정해야 한다.

BrowserStack

BrowserStack을 사용하면 클라우드에 준비된 실제 데스크톱 브라우저와 모바일 기기에서 로컬 또는 배포 환경을 테스트할 수 있다고 한다.

다양한 브라우저·버전·운영체제 조합을 검증할 수 있다는 장점이 있지만, 유료 서비스이다.

5. 현실적인 테스트 전략 세우기

지원 범위의 모든 브라우저 × 버전 × 운영체제 × 기기 조합을 매번 테스트하는 것은 현실적으로 어려운거 같다. 조합을 무작정 늘리기보다 실행 시점과 위험도에 따라 테스트를 점진적으로 하는 편이 효율적이지 않을까란 생각을 한다.

개발환경

• 개발자는 새로운 기능을 구현할 때 지원 브라우저 범위를 확인하고, 변경된 기능을 대표 브라우저에서 직접 테스트한다. (예: Chrome, Edge, Firefox, Safari)
• 로그인, 회원가입, 결제 등 핵심 사용자 흐름에는 Playwright E2E 테스트를 추가하고 로컬에서 실행한다.

CI/CD 단계

• 단위 테스트 실행
• Playwright의 Chromium, Firefox, WebKit에서 핵심 E2E 테스트를 실행

QA 단계

• 실제 사용자가 많은 기기와 지원 브라우저의 최신 버전을 테스트한다.
• 필요한 경우 지원 범위의 최소 버전도 확인한다.
• 로컬에서 준비하기 어려운 환경은 BrowserStack 같은 클라우드 테스트 서비스를 이용한다.
• ( 모바일 환경도 지원범위라면 ) iPhone Safari와 Android Chrome처럼 사용자가 많은 모바일 환경을 확인한다.

결국 목표는 가능한 모든 조합을 검사하는 것이 아니라, 제품에 중요한 위험을 합리적인 비용으로 줄이는 것이다. Playwright를 빠르고 넓은 1차 안전망으로 사용하고, 실제 기기와 BrowserStack을 이용하여 실제 브라우저 테스트를 중요도가 높은 환경에 집중하는 방식이 현실적인 균형점이라 생각한다.