브라우저 호환성(Browser Compatibility)은 모든 브라우저에서 화면을 픽셀 단위로 똑같이 만드는 문제가 아니다. 웹 표준으로 정의된 기능이 각 브라우저에 실제로 구현되는 시점과 범위가 다르기 때문에, 프로젝트가 지원할 환경을 정하고 기능 지원 여부를 판단한 뒤 핵심 기능이 유지되도록 설계하고 실제 브라우저에서 반복 검증하는 과정이다.

01. 브라우저 호환성이란 무엇인가

호환성 테스트(Compatibility Testing)는 웹 애플리케이션이 서로 다른 브라우저·운영체제·기기에서 의도한 기능을 수행하는지 확인하는 작업이다. 여기서 중요한 것은 ‘모든 환경에서 완전히 동일한 시각 결과’를 목표로 삼는 것이 아니라, 정해진 지원 환경에서 사용자가 필요한 콘텐츠와 기능을 이용할 수 있는지를 검증하는 것이다.

실제 웹사이트는 브라우저 하나만을 대상으로 실행되지 않는다. 같은 HTML·CSS·JavaScript라도 브라우저 엔진, 버전, 운영체제, 입력 장치, 화면 크기와 기능 지원 수준의 조합에 따라 결과가 달라질 수 있다. 따라서 호환성은 코드의 단일 속성이 아니라 웹사이트와 실행환경의 조합에서 확인해야 하는 상태에 가깝다.

02. 웹 표준과 브라우저 구현은 왜 다른가

웹 표준(Web Standard)은 브라우저와 각종 웹 소프트웨어가 구현할 기술의 공통 규칙을 정의한다. W3C는 웹 표준을 브라우저·검색엔진·저작 도구 등에서 구현되는 웹의 구성 요소로 설명하며, 상호운용성(Interoperability)을 중요한 목표로 둔다.^[1]

그러나 명세가 존재한다고 해서 모든 브라우저가 같은 시점에 해당 기능을 제공하는 것은 아니다. 표준화 상태, 엔진별 개발 일정, 플랫폼 제약, 구현상의 버그와 상호운용성 문제 때문에 실제 지원 시점에는 차이가 생길 수 있다. CSS의 경우에도 W3C의 CSS Snapshot은 명세의 안정성과 현재 CSS의 상태를 정리하는 문서이며, 브라우저 채택률 자체를 나타내는 목록은 아니다.^[2]

03. Baseline으로 지원 상태 판단하기

Baseline은 API, CSS 속성, JavaScript 문법 등 웹 플랫폼 기능이 주요 브라우저에서 어느 정도 사용할 수 있는지를 공통 기준으로 요약한다. 현재 Baseline은 Safari(iOS·macOS), Chrome(Android·desktop), Edge(desktop), Firefox(Android·desktop)를 핵심 브라우저 집합으로 사용한다.^[3]

Baseline의 장점은 복잡한 버전표를 매번 읽지 않고도 기능의 전반적인 지원 수준을 빠르게 판단할 수 있다는 데 있다. 하지만 Baseline 자체가 프로젝트의 ‘지원 브라우저 목록’은 아니다. MDN은 Baseline이 브라우저 지원의 요약이며 접근성·사용성·성능·보안 테스트를 대체하지 않고, 오래된 기기와 브라우저, 운영체제 WebView, 스크린리더 같은 보조기술의 동작까지 보장하지 않는다고 설명한다.^[3]

04. Target Browsers로 지원 범위 정의하기

모든 브라우저와 모든 과거 버전, 모든 기기 조합을 동일한 수준으로 테스트하는 것은 현실적으로 어렵다. MDN의 테스트 전략도 모든 조합을 검사하기보다 목표 사용자가 실제로 사용하는 중요한 브라우저와 기기를 식별해 테스트 범위를 구성하는 방식을 설명한다.^[4]

대상 브라우저(Target Browsers)는 프로젝트가 공식적으로 지원하기로 정한 브라우저·버전 범위다. 이를 코드 도구와 공유하는 대표적인 설정 체계가 Browserslist다. Browserslist는 Babel, Autoprefixer, PostCSS 계열 도구 등에서 공통으로 사용할 대상 브라우저 설정을 제공하며, last 2 versions, 사용률 조건, 지역별 통계, 프로젝트 자체 사용 통계와 같은 쿼리를 지원한다.^[5]

# 개념 예시 — 실제 프로젝트 정책은 사용자 통계와 요구사항에 따라 결정
> 0.5%
last 2 versions
Firefox ESR
not dead

따라서 Baseline과 Browserslist는 역할이 다르다. Baseline은 웹 플랫폼 기능의 공통 지원 상태를 설명하고, Target Browsers는 개별 프로젝트가 책임질 지원 범위를 정의한다. 둘을 혼동하면 “Baseline이므로 무조건 사용 가능하다”거나 “특정 브라우저가 목록에 없으니 웹 표준과 무관하다”는 잘못된 판단으로 이어질 수 있다.

05. Feature Detection으로 실행환경 확인하기

기능 탐지(Feature Detection)는 현재 브라우저가 필요한 기능을 실제로 지원하는지 실행 시점에 확인하고, 결과에 따라 다른 코드를 적용하는 방식이다. MDN은 이를 특정 브라우저 이름을 판별하는 브라우저 스니핑(Browser Sniffing)과 구분하며, 기능 지원 여부를 직접 검사하는 방식을 권장한다.^[6]

JavaScript API는 객체나 메서드의 존재 여부를 확인할 수 있고, CSS는 @supports 또는 CSS.supports()를 이용해 특정 속성·값 조합을 브라우저가 지원하는지 조건부로 판단할 수 있다.

/* CSS 기능 탐지 예시 */
@supports (grid-template-columns: subgrid) {
  .layout {
    grid-template-columns: subgrid;
  }
}

/* JavaScript API 존재 여부 확인 예시 */
if ("geolocation" in navigator) {
  // 지원되는 환경에서만 관련 기능 실행
}

Feature Detection도 만능은 아니다. 특정 선언이나 API 진입점이 존재한다는 사실은 그 기능이 모든 세부 조건에서 버그 없이 동작한다는 보증이 아니다. 따라서 기능 탐지는 런타임 분기의 도구이고, 실제 사용자 흐름의 정상 동작 여부는 별도의 브라우저 테스트에서 확인해야 한다.

06. Progressive Enhancement로 핵심 기능 유지하기

점진적 향상(Progressive Enhancement)은 가능한 많은 사용자에게 필수 콘텐츠와 기본 기능을 먼저 제공하고, 더 현대적인 기능을 실행할 수 있는 환경에서는 경험을 추가로 향상시키는 설계 철학이다. MDN은 오래된 브라우저나 기능이 제한된 기기에서도 단순하지만 사용할 수 있는 경험을 제공하고, 더 풍부한 기능을 지원하는 환경에서는 더 나은 경험으로 확장하는 접근으로 설명한다.^[7]

예를 들어 기본 폼 제출이 HTML만으로 가능하게 설계되어 있다면, JavaScript를 사용할 수 있는 환경에서는 실시간 검증이나 비동기 제출 같은 기능을 추가할 수 있다. 핵심은 최신 기능을 피하는 것이 아니라, 최신 기능이 없는 환경에서도 서비스의 본질적인 작업이 가능한 구조를 만드는 데 있다.

이 접근은 Feature Detection과 연결된다. Feature Detection이 “현재 환경에서 무엇을 사용할 수 있는가”를 판단한다면, Progressive Enhancement는 “지원 수준이 달라도 어떤 경험을 제공할 것인가”를 설계한다.

07. Cross-browser Testing과 Regression Testing

크로스 브라우저 테스트(Cross-browser Testing)는 정해진 대상 브라우저와 기기에서 사이트의 실제 동작을 확인하는 단계다. 여기서는 단순히 페이지가 열리는지만 보는 것이 아니라 레이아웃, 탐색, 입력, 폼 전송, 로그인, 모달, 미디어, 반응형 동작처럼 실제 사용자 작업이 정상적으로 수행되는지를 확인해야 한다.

MDN은 모든 브라우저·기기 조합을 테스트할 수 없으므로 목표 사용자에게 중요한 환경을 선택하고, 실제 기기·가상환경·자동화 도구 등을 조합하는 전략을 설명한다. 반복적인 검증은 Selenium/WebDriver나 Playwright 같은 자동화 도구, 원격 브라우저 테스트 서비스 등을 통해 일부 자동화할 수 있다.^[4][8]

회귀 테스트(Regression Testing)는 코드나 실행환경이 변경된 뒤 기존에 정상 작동하던 기능이 계속 정상인지 다시 확인하는 검증이다. 브라우저 호환성 문제를 수정한 뒤에도 다른 브라우저나 다른 페이지가 깨질 수 있으므로, 수정한 지점만 확인하지 않고 기존 핵심 기능을 다시 검사해야 한다. MDN 역시 브라우저 문제를 수정한 뒤 테스트 과정을 반복해 다른 위치나 다른 브라우저가 손상되지 않았는지 확인할 것을 설명한다.^[9]

08. Web Platform Tests가 검증하는 것

웹사이트 개발자가 수행하는 크로스 브라우저 테스트보다 한 단계 아래에는 브라우저 구현 자체의 상호운용성을 검증하는 체계가 있다. Web Platform Tests(WPT)는 웹 플랫폼 스택을 위한 크로스 브라우저 테스트 스위트로, 동일한 테스트를 여러 브라우저 구현에서 실행할 수 있도록 구성된다. 이를 통해 브라우저 프로젝트는 다른 구현과 호환되는 동작을 제공하는지 검증할 수 있다.^[10]

WPT에는 API 동작만 확인하는 테스트뿐 아니라 렌더링 결과를 기준 페이지와 비교하는 Reftest, 플랫폼별 기대 렌더링과 비교하는 Visual Test, 문서를 로드했을 때 브라우저가 충돌하지 않는지 확인하는 Crashtest, WebDriver 프로토콜을 검증하는 wdspec 테스트 등이 포함된다.^[11]

이 구분은 중요하다. WPT 결과가 좋다고 특정 쇼핑몰의 결제 과정이나 기업 홈페이지의 메뉴가 자동으로 검증되는 것은 아니다. 반대로 개별 사이트가 Chrome에서 잘 작동한다고 브라우저 엔진 전체의 표준 준수가 입증되는 것도 아니다. 브라우저 구현의 상호운용성 검증과 개별 사이트의 품질 검증은 서로 연결되지만 다른 테스트 층위다.