TL;DR
인턴십 중 HTML을 PDF로 변환하는 과정에서 브라우저에서는 멀쩡한 화면이 PDF에서 깨지는 문제를 겪었다.
해결책은 “WebKit 문법 기준으로 HTML을 다시 작성하라”는 것이었다.
이 경험을 통해 WebKit은 레거시가 아니라 OS 레벨에서 렌더링 결과의 책임을 지는 엔진이라는 사실을 체감했다.
WebKit이 최신 CSS를 늦게 지원하는 이유는 기술력이 부족해서가 아니라 역할과 책임이 다르기 때문이다.
문제의 시작: HTML은 정상인데, PDF에서는 깨졌다
인턴십 중
HTML을 PDF로 변환하는 API를 사용하는 작업을 맡게 됐다.
상황은 단순했다.
- Chrome에서 HTML 렌더링 → 정상
- 동일한 HTML을 PDF 변환 API에 전달 → 레이아웃 깨짐, 요소 위치 어긋남, 일부 스타일 미적용
처음에는 흔한 원인들을 의심했다.
- CSS 작성 실수
- 폰트 로딩 문제
- PDF 라이브러리 버그
하지만 프론트엔드팀에서 받은 피드백은 예상과 달랐다.
“이 HTML, WebKit 문법 기준으로 다시 맞춰야 할 것 같아요.”
이때 “브라우저에서 잘 보인다”와 “렌더링 엔진 기준으로 안전하다”는 다르다는 걸 인식하게 됐다.
HTML to PDF 변환에서 실제로 무슨 일이 일어나는가
중요한 전제부터 짚어야 한다.
HTML을 PDF로 변환할 때 우리가 쓰는 대부분의 도구는 Chrome을 띄워서 캡처하지 않는다.
대신 내부적으로 다음 과정을 거친다.
- HTML 파싱
- CSS 해석
- 레이아웃 계산
- 렌더 트리 생성
- PDF로 출력
이때 2~4단계를 담당하는 렌더링 엔진이 WebKit 계열인 경우가 매우 많다.
- HTML에서 보이는 결과는 Blink(Chrome) 기준
- PDF에서 깨지는 결과는 WebKit 기준
이라는 엔진 불일치가 발생한 것이다.
여기서 자연스럽게 생기는 질문
WebKit이 레거시라서 최신 CSS를 못 따라오는 거 아닌가?
이 질문은 직관적으로는 자연스럽지만, 사실 WebKit의 위치를 정확히 설명하지 못한다.
WebKit은 왜 최신 CSS를 늦게 지원하는가
1. WebKit은 브라우저 엔진이 아니라 OS 컴포넌트에 가깝다
Blink와 WebKit의 가장 큰 차이는 업데이트 방식이다.
- Blink
- Chrome 내부 엔진
- 업데이트 = 브라우저 업데이트
- 실험적 기능 → 빠른 롤아웃 가능
- WebKit
- iOS / macOS에 내장된 시스템 컴포넌트
- 업데이트 = OS 업데이트
- 변경 하나가 Safari, WebView, 시스템 UI 전반에 영향
이 구조에서는 “일단 넣어보고 문제 있으면 뺀다”는 전략이 거의 불가능하다.
2. WebKit의 최우선 목표는 “최신 기능”이 아니라 “예측 가능한 결과”
WebKit이 사용되는 영역을 보면 공통점이 있다.
- iOS Safari
- iOS WebView
- 메일, 미리보기
- HTML to PDF 변환
이 환경들의 요구사항은 명확하다.
같은 HTML 입력 → 언제나 같은 렌더링 결과
최신 CSS 문법은 종종
- 명세가 완전히 안정되지 않았거나
- 브라우저별 해석 차이가 크다
WebKit은 이런 기능을 의도적으로 늦게 채택한다.
이건 기술 부족이 아니라 리스크 관리다.
3. Apple은 “표준을 빠르게 밀어붙이는 쪽”이 아니다
Blink vs WebKit 접근 방식 비교
| 주도 주체 | Apple | |
| 역할 성격 | 범용 웹 브라우저 엔진 | OS 레벨 렌더링 엔진 |
| 웹 표준 접근 | 빠른 도입, 선적용 | 명세 안정화 후 도입 |
| 실험적 기능 | 실험적 플래그 적극 활용 | 실험적 기능 도입에 보수적 |
| 비표준 확장 | 비교적 적극적 | 매우 제한적 |
| API 성격 | Chrome 중심 API 다수 | 표준 중심 API 위주 |
| 업데이트 단위 | 브라우저 업데이트 | OS 업데이트 |
| 변경 영향 범위 | Chrome 브라우저 중심 | Safari, WebView, 시스템 UI 전반 |
| 우선순위 | 기능 확장, 속도, 시장 확산 | 안정성, 보안, 프라이버시 |
| 렌더링 기준 | 최신 문법 수용 | 예측 가능한 결과 |
| 개발자 체감 | “Chrome에서는 된다” | “Safari에서는 안 된다”가 반복됨 |
그래서 결과적으로
Chrome에서는 되는데 Safari에서는 안 되는 기능
이 반복적으로 발생한다.
다시 돌아보는 경험
이제 처음 문제를 구조적으로 다시 보면 이렇게 정리된다.
- HTML은 Blink 기준으로 작성됨
- PDF 변환기는 WebKit 기준으로 렌더링함
- 일부 최신 CSS는 WebKit의 안정성 기준을 넘지 못함
- 결과적으로 PDF 출력이 깨짐
- 해결책: WebKit이 보장하는 문법만 사용
이건 “WebKit이 레거시라서”가 아니다.
렌더링 결과에 대한 책임을 지는 엔진의 기준을 고려하지 않았기 때문이다.
정리하면
WebKit은 레거시 엔진이 아니다.
다만 웹 표준 실험의 중심에서는 물러났을 뿐이다.
대신 결과물 중심 렌더링 영역에서는 여전히 현역 기준 엔진이다
그래서 이 경험 이후, “WebKit은 레거시일까?”라는 질문에 대한 내 답은 이렇게 바뀌었다.
WebKit은 레거시인가가 아니라 어디에서 렌더링 기준을 맡고 있는가의 문제다.