IE 5.5에서 시작한 비표준 CSS zoom의 탄생과 혼란, 오해된 인기의 배경, 표준화 커뮤니티의 해법, 그리고 Interop 2025를 통한 현대적 지원까지를 돌아봅니다.
2000년 6월 19일을 기억하시나요? 멋진 날이었죠! 인류 전체가 함께 여름을 막 시작하며, 영화 _Gone in 60 Seconds_를 보려고 줄을 서고, 맥샐러드 셰이커를 파고들면서도, 우리를 더 높이 데려갈 누군가에 탐욕스레 기대하고 있었죠. 심지어 Microsoft Corporation(MSFT)도 최고의 순간을 누리며 인터넷 익스플로러(IE) 웹 브라우저 5.5 버전을 출시했답니다.
하지만, 우리는 너무도 순진했습니다! 그 들뜸과 헤어젤 아래에는 조그만 비표준 기능 하나가 도사리고 있었고, 이 기능은 시간이 지나며 괴물 같은 존재로 자라납니다. 그 과정에서 혼란, 버그 리포트, 우회책, 그리고 블로그 글을 양산했죠. 이름은 바로 zoom. 우리는 이제서야 그 폐해와 마주하고 있습니다.
zoom의 아이디어는 꽤 단순했습니다. 개발자가 임의의 요소를 눈으로 보기에 확대하거나 축소할 수 있게 하는 것. zoom: 2로 설정하면 요소 크기가 두 배가 되고, zoom: 0.1이면 10분의 1로 줄어드는 식이죠. 기타 등등! 당연히 주변 요소들은 그 새로운 치수에 맞춰 밀리고 끌리며 재배치됩니다.
문제는, 이 동작에 대한 정식 명세서를 아무도 작성하지 않았다는 점이었습니다. zoom은 브라우저들이 시장에서 차별화를 위해 넣던 많은 기능 중 하나였죠. 초기 웹 플랫폼의 파편화는 널리 기록되어 있지만, 요약하자면 이렇습니다. 개발자에게도, 웹 사용자에게도 좋지 않았어요.
그래서 존재 초기에 zoom은 대체로 디지털 치장 정도로만 채택되었습니다. 있으면 사이트가 좀 더 그럴싸해 보이긴 하지만, 없어도 동작은 하는 정도였죠.
zoom의 대체로 부차적인 성격은 모질라에게 중요했습니다. 모질라는 처음부터 표준 준수를 최우선으로 삼았으니까요. 2004년 파이어폭스의 안정 릴리스를 준비하면서 zoom은 과감히 무시하고, 명확한 합의 기준이 있는 기술에 집중할 수 있었습니다.
얼마 지나지 않아 웹 표준 기구들이 CSS transform을 설계했습니다. 이 새 속성은 개발자에게 zoom과 유사한 동작을 제공했을 뿐 아니라, 요소의 형태를 더 정교하게 제어할 수 있었고 저사양 기기에서도 더 효율적이었습니다. 물론 완전히 같지는 않았습니다(요소를 변형해도 이웃 요소의 위치에는 영향을 주지 않았죠). 그렇지만 모질라 입장에서는, IE의 zoom을 역공학해야 한다는 압박 대신 transform을 지원하면 되는 일종의 압력 해소 밸브가 되어 주었습니다.
애플은 더 확장적(그리고 비용이 많이 드는) 접근을 택했습니다. 다 구현해 버린 거죠. 사파리 3.5에서 transform을 지원했고, 그다음 릴리스에서는(피할 수 없었을지도 모를) 고유한 특성까지 얹은 zoom 지원을 추가했습니다.
그리하여 zoom은 웹 플랫폼에서 진정한 ‘경계 상태’로 들어갔습니다. 위원회는 무시하고, 일부 엔진은 제각각 구현하고, 다른 엔진은 거부하고, 웹 개발자들은 의심의 눈초리로 바라보는 상태였죠.
몇 해 전, 모질라와 보쿠프는 파이어폭스만 미지원인 기능을 우선순위화하는 프로젝트를 함께 진행했습니다. zoom도 목록에 있었지만, 그건 어디까지나 완결성을 위한 포함에 가까웠습니다.
우리는 웹 플랫폼 기능의 ‘인기’를 측정하기 위한 여러 지표를 만들었습니다. 자체 개발자 설문 결과, MDN 문서 트래픽, Stack Overflow 언급 수, 크롬 브라우저 텔레메트리, 심지어 HTTP Archive 데이터셋으로 본 실제 사용량까지 포함됐죠.
지금까지 zoom에 대해 들은 걸 떠올리면, 각 지표에서 낮은 순위를 예상할 겁니다. 그렇다면 다음 이야기는 앉아서 들으세요.
zoom은 대부분의 지표에서 상위권을 기록했고, 종합 2위를 차지했습니다.
단순히 “우리 지표가 형편없었다”고 결론내리기 쉬울 겁니다. 저한테 좀 관대하게 봐 주셨으면 하지만, 우린 서로 모르니까요. 뭐, 그러려니 하죠.
사실 zoom의 겉보기 인기는 놀랍지만 궁극적으로는 무관한 사용 사례 때문에 과대평가된 겁니다. zoom은 IE를 더 표준 준수 브라우저처럼 굴게 만드는 그 ‘기막힌 꼼수’이기도 했거든요. 짧게 말하자면: 기본값인 1을 설정하면 다른 브라우저에는 영향을 주지 않으면서 IE를 진정시킬 수 있었습니다. 하지만 그 기법은 점점 쓸모없는 상식이 되어 가고 있습니다. IE 8에서 문제가 수정되었고, IE 11로 IE 계보는 끝났죠. 오늘날엔 주로 예전 버전의 "clearfix 해크" 안에서만 이 패턴을 보게 됩니다.
만약 zoom을 1로 설정하는 게 오직 단종된 브라우저만 고친다면, 그런 사용은 집계에서 제외해야 마땅하겠죠? 모든 지표에 이런 필터를 적용할 수는 없었지만, 웹페이지 실사용량을 긁어올 때 zoom: 1은 제외하는 건 쉬웠습니다.
뭐, 거의 쉬웠습니다. 처음에 HTTP Archive에서 zoom 사용을 찾을 때, 우리는 오탐을 피하려고 다소 복잡한 정규식을 썼습니다.
\bzoom\s*:\s*([0-9]+%?|[0-9]*\.[0-9]+%?|normal|reset|inherit|initial|revert|revert-layer|unset)\s*[;\n}]
단순함은 미덕이지만, 우리는 오탐을 피하려고 ‘정규식 덕질’을 풀로 해버렸습니다. “zoom”은 현대 영어에서 꽤 흔한 단어라서, “Okay, zoomer” 같은 문구나 “Zoom이 개인 사용자 데이터를 재가공해 기계학습 모델을 학습시키는 데 썼다는 사실이 드러났다.” 같은 내용을 카운트하지 않도록 하고 싶었거든요. 그 패턴에서 1을 제외하려면, 정규식을 더 복잡하게 만들 수밖에 없었습니다1.
\bzoom\s*:\s*(\+?[0-9]*[02-9]|\+?[0-9]*[1-9][0-9]*1|\+?[0-9]+%|\+?[0-9]*\.[0-9]+%?|normal|reset|inherit|initial|revert|revert-layer|unset)[;\n}]
과연, 이 변경으로 매치 수가 94% 넘게 줄었습니다.
| zoom 값 | 페이지 |
|---|---|
| 임의의 값 | 20,161,142 |
| 의미 있는 값 | 1,123,519 |
어느 하나의 지표에서 이런 극적인 감소가 있다면, 다른 지표들에서도 의미 있는 감소로 반영되기 마련입니다. 우리는 모질라에 다른 데에 노력을 집중하자고 권했습니다.
물론 웹 상호운용성에 관한 결정을 수학적 분석으로만 환원할 수는 없습니다. 이를 보완하려고, 각 지표에 원하는 가중치를 적용해 볼 수 있는 인터랙티브 스프레드시트를 보고서에 포함시켰습니다. 하지만 그 멋진 스프레드시트로도 고려해야 할 풍부한 맥락을 담아내기엔 역부족이었죠. 감히 말하건대, 그 풍부함을 담아낼 만큼 멋진 스프레드시트를 만들 수 있는 사람은 아무도 없을 겁니다.
파이어폭스 버그 트래커에서는, 웹 개발자들이 zoom의 레이아웃에 영향을 주는 동작(transform으로는 재현할 수 없는 부분)의 중요성을 계속해서 주장했습니다.
그리고 이것이 소수의 관심사가 아님을 보여주듯, 트래픽이 매우 높은 애플리케이션들(웹용 Microsoft Excel, GMail 모바일 웹 앱)도 특히 레이아웃 효과를 필요로 했습니다. 2023년에 CSS 워킹 그룹은 영리한 전진 경로를 제시했습니다. 특성이 더 적은2 새로운 형태의 zoom 명세를 작성하고, 모두가 _그것_을 구현하도록 하자는 것이었죠. 그들은 명세를 작성했고, 우선 순위화를 제안했으며, Interop 프로젝트가 이를 Interop 2025에 채택했습니다. 오늘날에는 꽤 포괄적인 지원을 누리고 있죠.3
이 좌절과 슬픔의 이야기에서 무엇을 배울 수 있을까요? 이 역사를 지켜본 웹 개발자로서 겸허히 소회를 전하고, 이 변화를 보살핀 뛰어난 컨설턴트로서 거만하게 평가도 내려보겠습니다.
첫째: 웹을 과소평가하지 마세요. 합의는 가장 빠른 의사결정 방식은 아니지만, 전 세계 프로그래밍 플랫폼에 필요한 창의적이고 포용적인 해법을 키워 줍니다. 둘째: 독점 기술 위에 쌓지 마세요. 최선의 경우에도 폐쇄적인 기능을 굳혀 버리고, 최악의 경우엔 권리자가 마음을 바꾸거나 사라질 때 실망의 씨앗을 뿌리게 됩니다. 셋째: _Gone In Sixty Seconds_는 그냥 그랬습니다. 훌륭하진 않지만, 나쁘지도 않았어요.
부정형 선행 탐색(negative lookahead)이 있었다면 훨씬 쉬웠겠지만, BigQuery에는 없습니다.↩
물론 ‘특성 제로’는 아닙니다! 예를 들어, 어떤 웹사이트의 기능을 보존하기 위해 zoom: 0은 zoom: 1과 동일하게 취급됩니다. 여러분 중 일부가 zoom: 0을 썼고 그것이 아무 일도 하지 않기를 바란다는 사실은, 소프트웨어 개발자가 엔지니어로 분류된 직군 중 가장 혼돈스러운 이들이라는 제 주장을 더욱 뒷받침할 뿐입니다.↩
이 요약이 실제 구현까지의 고생을 덮어버린다는 점은 인정합니다. 예컨대 모질라는 zoom과 함께 -moz-transform을 사용해 모든 경우의 수를 덮는 페이지들을 고려해야 했습니다. 파이어폭스에 zoom을 그냥 추가하면 그 페이지들에서는 확대가 _두 배_로 적용됐을 테니까요. 진짜로 뒤엉킨 웹이죠.↩