왜 DOM의 과거를 알아야 할까? 개발자가 얻게 되는 인사이트
프론트엔드 개발을 하다 보면 DOM API는 너무 익숙한 존재라, 그 배경을 깊게 생각해볼 일이 많지 않습니다. 하지만 DOM 표준이 어떤 과정을 거쳐 지금의 모습에 이르렀는지를 알고 나면, 우리가 매일 마주하는 웹의 동작 방식이 새롭게 보이기 시작합니다. 저 역시 이 부분을 살펴보면서 “왜 지금의 API들이 이런 형태를 하고 있는지”, “왜 Web Components가 자연스러운 흐름인지” 더 명확하게 이해할 수 있었습니다. 오늘은 그 흐름을 간단히 정리해보려고 합니다.
초기 DOM: 문서를 ‘트리(Tree)’로 바라보게 된 순간 (DOM Level 1)
1998년 DOM Level 1은 문서를 트리 구조로 정의한다는, 지금으로서는 너무 당연하지만 당시에는 매우 중요한 전환점을 제시했습니다.
노드(Node), 요소(Element) 같은 개념이 이 시기에 등장했고, 이후 모든 DOM API는 이 모델을 중심으로 진화하게 됩니다.
지금 우리가 쓰는 document.querySelector, element.childNodes 같은 API들도 결국 이때 마련된 트리 기반 사고방식 위에서 작동합니다. 즉, 이 시기가 "브라우저가 문서를 어떻게 이해해야 하는가"를 공식적으로 정립한 출발점입니다.
DOM Level 2: CSSOM의 시작과 이벤트 모델의 확립
2000년 DOM Level 2는 지금의 프론트엔드가 의존하는 여러 기반을 마련했습니다.
- Style: CSSOM의 초기 개념 등장
- Traversal & Range API 도입
- 그리고 무엇보다 브라우저 이벤트 흐름의 정립
현재 우리가 사용하는 캡처 → 타깃 → 버블 단계의 이벤트 모델도 이 시기에 만들어졌습니다.
즉, Vue나 React 같은 프레임워크의 이벤트 시스템도 결국 DOM Level 2 이벤트 흐름을 기반으로 동작하고 있습니다.
DOM Level 3: 정교함을 더한 시기
2004년 DOM Level 3는 DOM을 더 세밀하고 잘 정의된 시스템으로 발전시켰습니다.
- XPath 관련 기능 포함
- Load & Save API로 문서의 읽기/쓰기 모델 정리
- KeyboardEvent, MouseEvent 등의 명확한 정의
- 문서 및 노드 구조를 더 세밀하게 규정
이 시기의 변화는 특히 툴링과 브라우저 구현에 영향을 많이 줬습니다. DOM이 단순히 “트리 조작용 API”를 넘어서 “문서 구조 전체를 일관성 있게 다루는 시스템”으로 완성되어갔다고 볼 수 있습니다.
WHATWG와 Living Standard의 등장
이후 웹 기술이 폭발적으로 확장되면서 기존의 W3C 방식이 따라가기 어려운 시점이 왔습니다.
- 웹 기술 변화 속도가 너무 빠르고
- 각 브라우저가 실험적으로 기능을 구현하는 속도는 더 빨라지고
- 표준 문서가 브라우저 현실을 따라가지 못하면서
- HTML 표준과 DOM 표준 사이 중복까지 생기기 시작했습니다.
이 격차를 해소하기 위해 WHATWG는 DOM을 Living Standard, 즉 버전 없이 지속 업데이트되는 표준으로 전환했습니다.
여기엔 중요한 변화들이 포함됩니다.
- HTML과 DOM을 통합적으로 다루기
- Shadow DOM, Custom Elements 등 Web Components 반영
- MutationObserver 등 현대적인 API 포함
- 테스트 기반으로 안정성과 일관성 강화
- 브라우저 간 차이 축소
WHATWG사이트를 보면 지금도 꾸준히 업데이트되는 것을 확인할 수 있습니다.
이제 DOM은 더 이상 “버전 3까지 나온 API 집합”이 아니라, HTML과 함께 계속 진화하는 살아 있는 생태계라고 보는 것이 맞습니다.
왜 이 역사를 알아야 할까?
실제로 프론트엔드 개발에서 가장 중요한 역량 중 하나는 “변화의 방향을 읽는 능력”이라고 생각합니다.
DOM의 역사를 이해하면 다음과 같은 관점이 생깁니다.
1. 브라우저 API 설계의 의도를 이해하게 됩니다.
이벤트 모델이 왜 계층 구조를 따라가는지, DOM 조작이 왜 특정 방식으로 제한되는지를 이해할 수 있습니다.
2. 프레임워크 내부동작을 더 잘 파악할 수 있습니다.
React의 synthetic event, Vue의 가상 DOM 패치, Svelte의 컴파일 결과 등 대부분 DOM의 기본 원칙을 응용합니다.
3. 새로운 웹 기술을 받아들일 때 부담이 줄어듭니다.
Web Components, CSSOM 확장, 새로운 이벤트 API 등은 모두 기존 DOM의 진화 경로 위에서 등장한 기술들입니다.
역사를 이해하면 기술 변화가 갑작스럽게 느껴지지 않고,
맥락 안에서 받아들일 수 있게됩니다.
마치며
DOM은 우리가 매일 마주하지만 깊게 들여다볼 일이 많지 않은 기술입니다.
하지만 그 발전 과정을 이해하면 웹의 현재를 더 선명하게 바라볼 수 있고, 앞으로 등장할 기술도 더 편안하게 받아들일 수 있습니다.
DOM 표준의 진화는 단순히 “API가 새로 생김”의 이야기가 아니라 웹이 스스로 확장해온 역사라고 생각합니다.
앞으로도 웹은 빠르게 변화하겠지만, 그 속에서도 DOM이 어떤 역할을 해왔고 앞으로 어떻게 살아 있을지 계속 관심을 가지고 지켜보면 좋겠습니다.
Member discussion