브라우저 계약의 층위
웹 화면은 하나의 프로그램이 아니라 여러 계약이 이어진 결과입니다. HTML은 문서 구조를 만들고 브라우저는 이를 DOM(Document Object Model, 문서 객체 모델)으로 표현합니다. CSS는 선택된 요소에 계산된 스타일을 제공하며, JavaScript는 DOM과 브라우저 API를 읽거나 바꾸고 사용자 입력에 반응합니다.
이 층위를 섞으면 “브라우저가 지원하지 않는다”는 말만 남습니다. 화면은 보이지만 버튼이 동작하지 않는다면 HTML 파싱은 통과했을 수 있고, 배포 산출물의 문법이 대상 엔진에 맞지 않거나 실행 중 필요한 API가 없을 수도 있습니다. 반대로 JavaScript 오류가 없어도 CSS 선언이 다른 규칙에 져서 포커스나 조작 단서가 사라질 수 있습니다.
웹 플랫폼은 표준 문서, 브라우저 엔진의 구현, 제품이 정한 지원 범위가 만나는 곳입니다. 표준에 정의된 동작이라고 해서 오래된 엔진 모두에 구현되어 있다고 말할 수 없고, 한 브라우저에서 동작했다고 제품의 모든 지원 환경을 증명할 수도 없습니다.
의존 경로와 호환성 경계
주소를 연 뒤 브라우저는 HTML을 받고 파싱하면서 추가 자원을 발견합니다. CSS와 스크립트가 언제 발견되고 실행되는지는 첫 화면과 상호작용 준비 시점에 영향을 줍니다. 이 경로를 고정된 한 줄의 순서로 외우기보다, 다음 단계가 앞 단계의 정보를 필요로 하는 의존 그래프로 보는 편이 정확합니다.
그림을 글로 읽기
- HTML·DOM: 문서 구조와 요소
- CSS·계산 스타일: cascade 결과
- JavaScript 실행: 문법과 API 사용
- 화면·상호작용: 사용자 입력 처리
- HTML·DOM → CSS·계산 스타일: 스타일 발견
- HTML·DOM → JavaScript 실행: 스크립트 발견
- CSS·계산 스타일 → 화면·상호작용: 배치·표시
- JavaScript 실행 → 화면·상호작용: 상태·이벤트 연결
예를 들어 HTML 응답이 200ms에 도착하고, HTML에서 발견된 CSS가 100ms 뒤인 300ms에 준비되며, 스크립트가 그 뒤 300ms 동안 메인 스레드를 점유한다고 합시다. 사용자는 HTML이 도착한 시점에 구조를 볼 수도 있지만, 스타일과 실행이 끝나야 정상적인 버튼을 누를 수 있습니다. 네트워크 시간과 실행 시간을 한 요청의 다운로드 시간으로 합치지 않아야 합니다.
이 경계는 기존 URL 입력부터 화면 표시까지의 의존 경로와 이어집니다. 그 노트가 연결·캐시·리소스 발견의 지연을 다룬다면, 이 장은 그 결과물이 각 브라우저에서 실행될 수 있는지와 어떤 변환이 필요한지를 다룹니다.
지원 매트릭스와 목표 환경
지원 범위는 “최신 브라우저” 같은 문장보다 구체적인 행으로 정합니다. 브라우저 제품군, 엔진, 운영체제, 최소 버전 또는 자동 업데이트 정책, 지원되는 입력 방식, 제외할 기능을 한 표에 적습니다. 버전 번호는 근거 없이 고정하지 않고 실제 제품의 배포 정책과 사용량 자료를 기준으로 갱신합니다.
| 질문 | 기록할 값 | 결정에 쓰는 이유 |
|---|---|---|
| 누구를 지원하는가 | 브라우저·OS·엔진 범위 | 테스트 대상과 fallback 범위 결정 |
| 어떤 기능이 필요한가 | 입력·저장·통신·레이아웃 기능 | 기능 감지 항목 도출 |
| 실패 시 무엇을 보장하는가 | 읽기 전용·기본 제출·안내 | 점진적 향상 수준 결정 |
| 언제 범위를 바꾸는가 | 사용량·장애·정책 검토 주기 | 임의의 브라우저 해킹 방지 |
같은 엔진 계열이라도 운영체제의 입력 처리나 글꼴, 하드웨어 가속이 달라질 수 있습니다. 따라서 호환성은 픽셀을 완전히 같게 만드는 과제가 아니라 핵심 작업을 지원하고 실패를 이해할 수 있게 만드는 계약입니다. 시각 차이가 허용되는지, 데이터 손실이 허용되지 않는지, 키보드만으로 제출해야 하는지는 각각 별도 요구입니다.
기능 감지와 점진적 향상
기능 감지(feature detection)는 브라우저 이름을 추측하는 대신 지금 실행 중인 환경이 필요한 기능을 제공하는지 확인하는 방법입니다. 점진적 향상(progressive enhancement)은 기본 HTML 작업을 먼저 성립시키고, 기능이 있으면 더 좋은 동작을 추가하는 설계입니다.
다음 조각은 실제 실행을 보장하는 테스트 결과가 아니라 구조를 보여 주는 JavaScript 예입니다. AbortController가 없는 환경에서도 검색 결과를 제출할 수 있도록 취소 기능만 선택적으로 더합니다. 이 예에서 fetch가 없는 환경까지 자동으로 지원하는 것은 아니므로, 그 경우에는 일반 HTML 제출이나 별도의 요청 경로가 필요합니다.
const controller = typeof AbortController === 'function'
? new AbortController()
: null;
const requestOptions = controller ? { signal: controller.signal } : {};
fetch('/search?q=book', requestOptions)
.then(response => {
if (!response.ok) throw new Error(`HTTP ${response.status}`);
return response.json();
})
.then(renderResults)
.catch(error => {
if (error.name !== 'AbortError') renderError(error);
});
기능 감지가 통과해도 서버의 인증·인가·입력 검사는 생략되지 않습니다. 브라우저에서 화면을 더 잘 만들 수 있는지와 서버가 요청을 받아도 되는지는 서로 다른 계약입니다. CORS preflight와 API 보호의 경계처럼 요청이 전송되었는지, 응답을 읽을 수 있는지, 서버 작업이 승인되었는지를 분리해야 합니다.
<input type="date">도 같은 방식으로 다룹니다. 기본 입력을 제공하고 날짜 입력의 표시가 제품 요구에 충분한지 확인한 뒤 보조 위젯을 추가할 수 있습니다. 보조 위젯이 실패해도 이름, 값, 제출 형식이 유지되어야 하며, div를 입력처럼 그린 뒤 키보드와 오류 연결을 다시 구현하는 방식은 더 큰 계약을 만듭니다.
번들 그래프와 배포 산출물
Webpack 문서에서 말하는 번들러는 진입점(entry point)에서 모듈 의존성 그래프를 만들고 필요한 모듈을 묶는 도구입니다. 따라서 번들은 소스 파일을 단순히 이어 붙인 결과가 아니라, 어떤 진입점에서 어떤 모듈에 도달할 수 있는지를 반영한 배포 산출물입니다.
그림을 글로 읽기
- 진입점: 앱 시작 모듈
- 의존성 그래프: import 관계 해석
- 번들·분할 자원: 배포 파일
- 브라우저 실행: 문법·API 확인
- 진입점 → 의존성 그래프: 모듈 탐색
- 의존성 그래프 → 번들·분할 자원: 결합·분할
- 번들·분할 자원 → 브라우저 실행: 다운로드·실행
작은 예로 main.js가 search.js와 date-format.js를 가져오면 세 파일의 관계가 하나의 그래프가 됩니다. 검색 화면을 열 때만 필요한 모듈을 분리하면 초기 자원은 줄일 수 있지만, 이후 청크를 발견하고 가져오는 지연과 실패 경로가 생깁니다. 모든 코드를 하나로 묶거나 무조건 잘게 나누는 규칙보다 첫 화면의 의존 경로와 캐시 재사용을 기준으로 선택합니다.
번들 크기를 줄였다는 결과도 파일 크기 하나로 끝나지 않습니다. 초기 다운로드, 압축 후 전송량, 파싱·컴파일·실행 시간, 캐시 적중, 청크 요청 실패를 함께 기록해야 합니다. 이 작업에서는 실제 빌드나 브라우저 전수 실행을 하지 않았으므로 특정 설정이 특정 수치를 낸다고 주장하지 않습니다.
문법 변환과 런타임 기능
Babel 문서는 syntax transform과 polyfill을 분리합니다. 문법 변환은 대상 엔진이 읽지 못하는 표현을 다른 문법으로 바꾸는 책임이고, 폴리필은 대상 환경에 없는 런타임 기능을 제공하는 별도 책임입니다. 화살표 함수가 일반 함수로 바뀌어도 Promise가 자동으로 생기는 것은 아닙니다.
Webpack도 필요한 오래된 브라우저 지원과 폴리필을 자동으로 모두 보장하는 도구로 설명하지 않습니다. 따라서 배포 절차에는 대상 브라우저 목록, 변환 설정과 실제 출력 문법, 사용하는 런타임 API와 그 공급 경로를 함께 남깁니다.
소스 문법 확인 → 대상별 syntax transform → 번들 생성
→ 필요한 runtime feature 목록화 → polyfill 또는 fallback 선택
→ 지원 매트릭스별 실행·키보드·네트워크 확인
위 흐름에서 화살표는 책임의 순서를 보이는 의사 절차이며 특정 빌드 도구 설정을 뜻하지 않습니다. 폴리필을 넓게 넣으면 호환성은 쉬워질 수 있지만 초기 자원과 전역 객체 변경 위험이 늘 수 있습니다. 반대로 전혀 넣지 않으면 화면은 보여도 특정 동작만 실패할 수 있습니다. 어떤 기능을 포기하고 어떤 기능에 fallback을 둘지는 제품 요구와 실제 사용 환경으로 결정합니다.
호환성 장애의 시간순 진단
구형 환경에서 제출 버튼이 보이지만 동작하지 않는 장애를 생각해 보겠습니다. 먼저 콘솔의 첫 오류와 오류가 발생한 파일·줄을 기록합니다. 출력 파일이 대상 엔진이 읽지 못하는 문법을 포함하면 syntax transform 문제를 먼저 의심하고, 실행은 시작됐지만 특정 생성자나 메서드가 없으면 runtime feature 문제를 분리합니다.
그다음 Network에서 제출 요청이 서버에 도착했는지 확인합니다. 요청이 없으면 이벤트 연결이나 실행 오류를 보고, 요청은 도착했지만 응답 접근이 막히면 CORS와 서버 응답 정책을 봅니다. 요청이 실행되어 상태를 바꿨는데 클라이언트가 응답만 읽지 못할 수도 있으므로, 브라우저 오류만 보고 서버 작업이 없었다고 결론 내리지 않습니다.
CSS 차이라면 computed style에서 매칭 선언과 탈락 이유를 확인하고, 포커스가 사라졌다면 reset이 native control의 책임을 제거했는지 확인합니다. CSS 선언의 승자와 상속 경계와 기본 스타일 정리와 폼 접근성 보존은 이 단계의 원인을 더 깊게 다룹니다.
구현과 운영의 확인 순서
구현 전에 지원 매트릭스의 각 행에 핵심 사용자 흐름을 하나씩 붙입니다. 날짜 입력, 검색 제출, 오류 표시, 키보드 포커스 이동을 정하고, 기능이 없는 환경에서는 어떤 기본 흐름이 남아야 하는지 문장으로 씁니다. 그 뒤 번들 target, 변환, 폴리필·fallback을 변경하고 산출물에서 실제 사용 API와 대상 범위를 대조합니다.
운영에서는 브라우저·OS별 오류율, JavaScript 첫 오류, 요청 도착률, CORS 실패, 폴리필 청크 실패를 같은 배포 버전으로 묶어 봅니다. 기능 감지 분기가 너무 넓어 특정 환경에서만 열리지 않는 경로를 만들 수 있으므로, 분기별 실제 사용량과 성공 흐름도 기록합니다.
“화면이 보임”, “클릭 가능”, “서버가 요청을 받음”, “응답을 읽음”, “접근 가능한 오류가 표시됨”은 서로 다른 결과입니다. 이 다섯 상태를 시간순으로 남겨야 호환성 장애를 재현하고 복구할 수 있습니다.
참고 자료와 검증 범위
- Fetch Standard — 2026-09-17 확인, WHATWG Living Standard, 번호가 표시되지 않은 현재 문서. request mode와 CORS safelisted method, preflight 개념의 근거로 사용했습니다.
- DOM Standard — 2026-09-17 확인, WHATWG Living Standard, 번호가 표시되지 않은 현재 문서. DOM과 이벤트 책임의 보조 근거로 사용했습니다.
- Webpack Concepts — 2026-09-17 확인, 현재 문서에 webpack 5 요구사항이 표시됨. 진입점·의존성 그래프·번들·폴리필 책임 구분에 사용했습니다.
- Babel Documentation — 2026-09-17 확인, 번호가 표시되지 않은 현재 문서. syntax transform과 third-party polyfill 구분에 사용했습니다.
- URL 입력부터 화면 표시까지의 의존 경로, CORS preflight와 API 보호의 경계, CSS 선언의 승자와 상속 경계, 기본 스타일 정리와 폼 접근성 보존 — 저장소의 기존 심화 노트입니다.
이 장의 200ms·300ms 예와 JavaScript 조각은 설명을 위한 것이며 실제 빌드나 브라우저 실행 결과가 아닙니다. 지원 브라우저 버전, 실제 Babel·Webpack 설정의 산출물, 폴리필의 크기와 성능은 목표 환경에서 별도로 검증해야 합니다. 2026-09-17 기준으로 버전별 지원을 확정할 수 없는 항목은 특정 최신 버전 주장으로 확장하지 않았습니다.