Notice
Recent Posts
Recent Comments
Link
«   2026/07   »
일 월 화 수 목 금 토
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
Tags
more
Archives
Today
Total
관리 메뉴

mimizae 님의 블로그

DOM과 브라우저 본문

JS

DOM과 브라우저

mimizae 2025. 11. 18. 20:05

 

DOM Interface → 브라우저 구현 → JavaScript 주입 → JavaScript의 DOM 조작

 

위의 흐름, DOM과 브라우저와 JS의 연결성을 이 아티클을 작성하며 이해해 보도록 하자! 🔥🔥

 

브라우저의 렌더링은 HTML 문서를 파싱하여 브라우저가 이해할 수 있는 자료구조인 DOM을 생성한다.
DOM은 HTML 문서의 계층적 구조와 정보를 표현하며 이를 제어할 수 있는 API, 즉 프로퍼티와 메서드를 제공하는 트리 자료 구조이다.

 

이 정의를 조금만!! 더 풀어서 말하자면, 문서 객체 모델(DOM)은 HTML 문서 구조를 객체로 표현한 것이라는 의미이다!!

 

DOM은 HTML 문서의 요소들을 트리 형태로 표현하며, 각각의 노드는 문서의 각 요소(HTML 태그, 속성, 텍스트 등)를 나타낸다.

예를 들어, <html> 태그는 가장 최상위 노드이며, 그 아래에 <head>와 <body> 같은 자식 노드들이 있는 것이다.

 

이처럼 HTML 문서는 <body>, <p> 같은 여러 노드들이 계층적으로 구성되어 있다.

이 계층 구조를 그대로 반영해 만든 객체 트리가 바로 DOM이다.

 

렌더링 엔진이 HTML 문서를 파싱하여 생성한 DOM

 

 

이렇게 HTML 문서를 객체로 표현하면 JavaScript 같은 스크립트 언어가 웹페이지의 구조나 내용에 접근하고 조작할 수 있게 된다.

 

즉, DOM은 HTML로 구성된 웹 페이지와 스크립트 및 프로그래밍 언어를 연결시켜주는 Interface 역할을 하는 것이다!

 

DOM과 DOM Interface

잠깐!! DOM이 interface 역할을 한다면, DOM = DOM Interface 동의어가 아닌가? 왜 둘을 구분해서 말하는 걸까?

 

DOM이 interface 역할을 한다는 것은 그 개념에 대한 것이고, 둘은 전혀 다른 의미이다!

 

DOM은 웹 페이지(HTML)를 메모리 상에서 트리 구조로 표현한 것 그 자체이다.

  • HTML 문서를 브라우저가 파싱해서 만든 트리 구조
  • 노드(Node), 요소(Element), 속성(Attribute), 텍스트(Text) 등이 포함된다.
  • 즉, 브라우저 내부에 존재하는 실제 데이터 구조인 것이다!!!

 

반면, DOM Interface는 DOM 객체에 접근하고 조작하기 위해 JS가 사용할 수 있는 API 명세이다.

  • 브라우저가 DOM 객체에 구현해 놓은 속성/메서드 규약(Interface)
  • W3C/WHATWG에서 정의한 스펙
  • JavaScript는 이 Interface를 통해 DOM을 읽고 조작할 수 있다.

 

DOM의 핵심 인터페이스는 다음과 같은 것들이 있다!!

 

 

 

근데, 이런 규약이 왜 필요한 걸까? DOM 자체가 트리 구조이면...... JS가 바로 접근할 수 있는 게 아닌가?!

 

결론적으로 DOM Interface가 왜 필요한지 한 문장으로 말해 보자면,

브라우저가 만든 DOM 트리를 JavaScript가 직접 만지고 조작할 수 있게 표준화된 규칙을 제공하기 위함이다.

 

라고 할 수 있겠다. (조금 더 풀어서 설명해 보겠다...)

 

 

1. 브라우저 내부 구조(DOM 트리)는 JS가 직접 읽을 수 없다.

 

사실, 브라우저가 HTML을 읽어 만든 DOM 트리는 브라우저 엔진 내부의 C++ 구조체에 가깝고, JS가 바로 접근할 수 있는 형태가 아니다!!!

 

그래서 JavaScript가 DOM 내부 구조를 안전하게 다루도록 한 추상 레이어가 필요한데, 그게 DOM Interface인 것이다!

 

 

2. 표준화된 API가 없으면 브라우저마다 DOM 조작 방식이 달라질 수 있다.

 

당연히 브라우저의 종류마다 브라우저의 엔진도 다르다.

그래서, 이런 표쥰 규약이 없던 시절인 초기 웹(IE4, Netscape 시절)에는 DOM 접근 방식이 제각각이었다.

 

간단히 두 가지 예를 들어보겠다.

 

1) Netscape 4: document.layers[ ]

 

Netscape는 HTML 구조를 Layer(레이어)라는 개념으로 다뤘다.

document.layers["header"].document.write("Hi");

 

 

layers 배열로 특정 DOM 요소에 접근하며 <div>와 비슷한 구조이지만 표준이 아니기 때문에 다른 브라우저에서 이 방식은 전혀 동작하지 않는다.

 

(2) Internet Explorer 4: document.all[ ]

 

IE는 완전히 다른 DOM 접근 방식을 사용했다...

(개발자 지옥!! 🤯 이 시절에는 브라우저마다 작동되도록 코드를 두 번씩 짰을 것이다...)

document.all["header"].innerText = "Hello";

 

document.all은 IE 전용 API이라 다른 브라우저에서는 기본적으로 사용이 권장되지 않았다.

 

 

이런 브라우저마다 DOM 조작 방식이 다른 문제점을 해결하기 위해

W3C가 모든 브라우저가 이 규약 따라라! 하고 만든 것이 DOM Level 1/2/3 Interface이다.

 

또한 WHATWG가 비교적 현실적인 표준 DOM을 정리하면서, interface로 명세가 생겼기에 브라우저들이 동일한 DOM Interface를 구현하기 시작했다.

 

이러한 과정을 거쳐 웹 표준 기반 개발이 가능해지면서 지금처럼 어디서든 같은 DOM API가 동작하는 환경이 만들어진 것이다!!

(다행이다...)

 

3. DOM Interface는 JavaScript가 DOM 객체를 조작할 때 사용하는 속성과 메서드를 정의한다.

 

DOM Interface는 JavaScript가 DOM 객체에 대해 어떤 속성을 읽을 수 있고, 어떤 메서드를 호출할 수 있는지

그 규칙을 정한 문서이다!

 

만약 DOM Interface가 없다면?

div.className = "red"
 
 

이 코드가 작동할지, class 정보를 어떻게 바꿔야 하는지, 렌더링 엔진에 어떤 영향을 줄지 등등에 대해 전혀 보장할 수 없다.

 

이유는, 브라우저마다 내부 DOM 구조가 다르기 때문이다!!

 

크롬(Blink), 파이어폭스(Gecko), 사파리(WebKit) 모두 DOM을 C++ 또는 Rust 구조체로 내부에서 처리한다.

 

문제는… 어떤 구조체 이름을 쓰는지 class 정보를 어떤 필드에 저장하는지 스타일 적용 플래그를 어디에 저장하는지 브라우저마다 완전히 다르다.

 

그래서 표준화된 DOM Interface가 없다면

  • 어떤 브라우저는 className이라는 속성 자체가 없을 수 있고,
  • 다른 브라우저는 div.style.className 같은 이상한 구조로 만들 수도 있으며
  • 어떤 브라우저는 문자열 대신 배열로 class를 표현할 수도 있는 것을 캐치하지 못할 수 있다...

반대로, DOM Interface가 있으면?

 

Element 인터페이스에 아래와 같이 명시되어있다.

  • className은 문자열이다
  • 값이 바뀌면 DOM 내부 class 속성이 변경된다
  • 변경되면 브라우저가 필요 시 layout/paint를 다시 계산한다

즉, 모든 동작이 명세로 고정되어 있고, 모든 브라우저가 같은 방식으로 동작하게 된다.

 

이 때문에 Chrome, Firefox, Safari 등 어디서든 동일한 DOM API가 작동하는 것이다!!

 

4. DOM Interface는 DOM 객체의 “프로토타입 구조”까지 규정한다.

 

DOM은 단순한 JSON 구조가 아니라 객체(Object) + 프로토타입 상속 체계로 이루어져 있다.

 

예를 들어 브라우저의 DOM 객체는 다음과 같은 계층을 가진다.

Node
 └─ Element
      └─ HTMLElement
           └─ HTMLDivElement
           └─ HTMLImageElement
           └─ ...

 

이 계층 구조 안에는 어떤 프로토타입이 어떤 속성과 메서드를 가지는지, 어떤 하위 객체가 어떤 상위 객체를 상속받는지까지 모두 정의돼 있다.

 

이 구조를 명확히 표준화해야 브라우저마다 DOM 객체 구조가 달라지는 문제를 막을 수 있다!!

 

DOM Interface는 바로 이 상속 구조를 lnterface definition 형태로 명세한다.

  • Node 인터페이스가 갖는 공통 메서드: appendChild(), removeChild()
  • Element 인터페이스가 갖는 추가 속성: id, className
  • HTMLImageElement가 갖는 전용 속성: src, alt

즉, DOM Interface는 DOM 객체의 프로토타입 체계를 통째로 표준으로 고정한 문서다.

 

정리!! DOM Interface가 부재한다면... 브라우저마다 DOM 조작 방식이 달라서 개발자가 어떻게 DOM을 다뤄야 하는지 알 수 없으며 JavaScript가 DOM 구조에 직접 접근할 방법이 없다.

브라우저의 역할

DOM이 어떤 것이고 DOM Interface가 어떤 것인지, 왜 필요한지는 개념을 잡았다.

그럼 이 모든 게 언제 어떻게 만들어지는 것일까?


위에서 DOM Interface가 필요한 이유에 대해 설명하며 브라우저마다 DOM 조작 방식이 달라 이를 통일하기 위한 표준을 만들었기 때문에 브라우저들이 동일한 DOM Interface를 구현하기 시작했다고 했다.

 

브라우저가 DOM Interface를 어떻게 구현하는 걸까??

 

DOM Interface는 어디까지나 문서로 정의된 표준 명세일 뿐이다.

이 명세에 따라 실제로 동작하는 DOM 객체를 만들어내는 주체는 브라우저이다!

 

브라우저의 렌더링 엔진(Blink, WebKit, Gecko 등)은 DOM Interface에서 정의된 구조를 기반으로 다음처럼 구현을 진행한다.

  • Node, Element, Document, HTMLDivElement 같은 타입을 내부 코드(C++ 구조체/클래스)로 구현
  • DOM 트리를 실제 메모리 구조로 구성
  • 각 DOM 타입이 가져야 할 속성과 메서드를 명세대로 구현
    • appendChild()
    • querySelector()
    • innerText
    • className
    • 등등

이렇게 구현된 객체들이 브라우저 내부 DOM 트리이다. 하지만 이건 아직 JavaScript가 직접 접근할 수 있는 형태는 아니다.

 

그렇다면 JavaScript는 어떻게 이 DOM API를 사용할 수 있을까?

 

 

이 지점에서 중요한 역할을 하는 것이 브라우저와 JavaScript 엔진의 연결 구조이다.

 

JavaScript 엔진(V8, SpiderMonkey)은 브라우저가 제공한 DOM 객체를 마치 JS 객체인 것처럼 다룰 수 있도록 바인딩 계층을 통해 연결한다!!!!


덕분에 JavaScript는 브라우저가 구현한 DOM API를 자유롭게 호출할 수 있게 된다.

바로 아래처럼!!

document.querySelector()
element.appendChild()
div.className

 

즉, DOM Interface(표준) → 브라우저 구현(C++ 객체) → JS에게 공개된 DOM API 라는 흐름으로 이어지는 것이다.

 

브라우저와 자바스크립트

 

DOM Interface를 구현하는 브라우저의 동작 원리를 브라우저의 구조를 통해 알아보자!

 

브라우저는 User Interface, 브라우저 엔진, 렌더링 엔진, 자바스크립트 엔진, 네트워킹 레이어 등으로 구성된다.

 

1. User Interface

 

주소 표시줄, 이전/다음 버튼, 북마크 메뉴 등 유저와 가장 밀접하게 맞닿아있는 부분이다.

 

 

 

 

2. 브라우저 엔진

 

 

브라우저는 사실 여러 엔진'들'로 구성되어 있다.

예시로 Chrome 브라우저를 살펴보면 브라우저 엔진은 Chromium, 렌더링(레이아웃) 엔진은 Blink, JS 런타임(JS 엔진)은 V8이라 불린다.

 

브라우저 엔진이란 사용자 인터페이스와 렌더링 엔진 사이의 동작을 제어하는 엔진이다.

 

즉, 브라우저 내부에서 DOM을 업데이트하거나 렌더링 엔진에 "이 부분 다시 그려!!" 같은 명령을 전달하는 등의 제어 기능을 담당한다.

브라우저 엔진이 직접 화면을 그리는 것은 아니며, 렌더링 엔진에게 작업을 요청하는 상위 관리 레이어라고 볼 수 있다.

 

3. 렌더링 엔진

 

요청한 콘텐츠를 화면에 출력하는 엔진이다!

HTML과 CSS를 파싱해 최종적으로 화면에 그려주며, HTML 및 XML 문서와 이미지를 표시할 수 있다. 

렌더링 엔진의 기본 동작 원리

 

 


렌더링 엔진의 기본적인 동작 원리는 다음과 같다.

 

1) 브라우저는 서버로부터 HTML 문서를 모두 전달 받고, 렌더링 엔진은 전달받은 HTML 문서 파싱하여 DOM 트리를 구축한다.

→ DOM Interface가 구축되는 지점!!

2) 외부 CSS 파일과 함께 포함된 스타일 요소를 파싱한다. 

3) DOM 트리와 2)의 결과물을 합쳐 렌더 트리를 구축한다.

4) 렌더 트리의 각 노드에 대해서 화면 상에서 어디에 배치할 지 결정한다.

5) UI 백엔드 렌더 트리를 그리게 되고, 화면에 우리가 볼 수 있도록 출력된다.

 

 

다음은 다양한 렌더링 엔진의 종류들이다!!

  • Gecko : Mozilla 재단에서 만든 브라우저 엔진으로, 파이어폭스가 탑재하고 있다.
  • Webkit : KHTML에서 파생된 브라우저 엔진으로, 사파리가 탑재하고 있다.
  • Blink : 웹킷(Webkit)에서 파생된 브라우저 엔진으로, 크롬, 오페라가 탑재하고 있다.
  • Trident : 마이크로소프트의 브라우저 엔진으로, 아웃룩 익스프레스, 마이크로소프트 아웃룩 등이 탑재하고 있다.

 

 

4. 자바스크립트 엔진

 

자바스크립트 코드를 이해하고, 실행하고, 최적화하는 브라우저 내부의 실행 엔진이다.

대표적인 자바스크립트 엔진으로는, V8(Chrome, Edge), SpiderMonkey(Firefox), JavaScriptCore(Safari) 등이 있다!

 

 

첫 번째 그림과 같이 JS 엔진의 주요 구성 요소는 Call Stack과 Memory Heap이다.

 

콜 스택 (Call Stack)이란

함수 호출 순서를 관리하고 현재 실행 중인 함수의 정보를 저장하는 자료구조이다.

스택 형태로 동작하며 함수가 호출될 때마다 해당 함수의 실행 컨텍스트가 스택에 추가되고 함수 실행이 완료되면 스택에서 제거 된다. 

 

메모리 힙 (Memory Heap)이란

객체, 배열, 함수 등 동적으로 생성되는 데이터를 저장하는 메모리 공간이다.

힙은 상대적으로 크고 구조화되지 않은 메모리 영역으로 필요에 따라 메모리를 할당하고 해제한다.

 

이러한 구성을 가진 자바스크립트 엔진이 하는 일은 다음과 같다!

 

1) JS 코드를 분석/ 파싱

  • 코드 문자열 → 토큰화 → AST(Abstract Syntax Tree)

2) JS 코드를 실행

  • 인터프리터 실행
  • JIT 컴파일 → 최적화된 기계어 실행
  • 함수 호출 관리(call stack)

3) 메모리 관리

  • Heap(객체 저장 공간)
  • Stack(실행 컨텍스트)
  • Garbage Collection(쓸모없어진 메모리 회수)

 

→ 결국 엔진은 순수 JavaScript 실행기이다.

 

헐!! 나는 자바스크립트 엔진이 자바스크립트 엔진이니까, 비동기 제어나 우리가 자주 사용하는 setTimeout 같은 내장 함수들이 이 엔진에서 관리되는 줄 알았다.

 

하지만... 엔진은 순수하게 자바스크립트를 실행하는 역할을 맡고 있고 내가 생각했던 과정은 생각보다 좀 더 복잡하다.

 

그래서!!! 자바스크립트 엔진이 하지 않는 일에 대해 찾아 봤다.

 

자바스크립트 엔진이 하지 않는 일...

  • 타이머 실행 (setTimeout)
  • DOM 조작 (document.querySelector)
  • AJAX 요청 (fetch / XMLHttpRequest)
  • 이벤트 감지 (click, load 등)
  • 네트워크 통신
  • ...

이 모든 건 자바스크립트 엔진 영역이 아니다.

 

그렇다면, 우리가 정말 정말 자주 쓰던 setTimeout, DOM, fetch, click 이벤트는 어디서 오는 걸까?

 

이것들은 모두 브라우저(또는 Node.js)가 자체적으로 제공하는 API들이다.

 

JS 엔진은 단순히 이름만 알고 있을 뿐!! 실행은 하지 않는다.

 

이 API들을 Web API라고 한다. 이 Web API들은 브라우저 엔진(C++, Rust 등으로 구현) 안에 있다.

 

핵심은, Web API는 브라우저가 제공하고, JS 엔진은 그걸 호출할 수 있게 해줄 뿐이다!

 

JS 엔진이 제공하는 게 아니라, 브라우저가 제공하는 기능을 JS가 가져다 쓰는 것!!

 

 

그리고, 비동기 제어는 Web API + Event Loop가 담당한다!!!!

 

JS 엔진은 싱글 스레드라서 비동기 기능을 못 만든다.

 

그럼 비동기는 누가 만드는 것일까!!!!

setTimeout 흐름을 예로 들어서 위의 그림을 이해해보자.

 

(1) JS 엔진이 setTimeout() 호출을 만난다

 

JS 엔진은 setTimeout 함수의 이름만 알고 있으며, 실제 타이머는 Web API 타이머가 담당한다!!!

 

(2) Web API가 타이머를 백그라운드에서 실행

 

Timer API는 JS 엔진과 완전히 독립된 영역에서 동작한다.

  • 타이머 스레드에서 시간 1초 측정
  • 1초 지나면 “콜백 준비됨” 신호를 런타임에 반환

이 단계에서도 JS 엔진은 아무 일도 하지 않는다.
스택도 비어 있고 대기 상태이다!

 

(3) 시간이 끝나면 Web API는 콜백을 Callback Queue에 넣는다

 

1초가 지나면, Web API가 Callback Queue에 결과를 전달한다.

 

Timer API → Callback Queue에 콜백 등록!!

 

여기에서, Callback Queue는 JS 엔진의 스택과 독립된 대기열이다.

 

(4) Event Loop는 JS 엔진을 감시

 

Event Loop는 매우 간단한 원칙만 따른다

Call Stack이 비어 있으면, Callback Queue에서 콜백 하나를 스택으로 보낸다.

 

즉 Event Loop는 JS 엔진과 Web API 사이를 연결하는 조정자!!!이다.

 

(5) JS 엔진이 콜백을 실행한다

 

스택이 비면 콜백이 들어와 실행 된다. 이제야 엔진이 다시 일을 시작하는 것... 아하!!

Web API

바로 위에서 다룬 Web API란 타이머, 네트워크 요청, 파일 입출력, 이벤트 처리 등 브라우저에서 제공하는 다양한 API를 포괄하는 총칭이다.

 

 

Web API는 브라우저(Chrome)에서 멀티 스레드로 구현되어 있다.

 

그래서 브라우저는 비동기 작업에 대해 메인 스레드를 차단하지 않고 다른 스레드를 사용하여 동시에 처리할 수 있는 것이다!!

 

 

대표적인 Web API들의 예는 다음과 같다!!

 

1. DOM & Document 관련 API

HTML 문서를 JS로 조작하게 해주는 API이다.

  • document
  • window
  • Element, Node
  • querySelector, createElement
  • classList, style
  • addEventListener
  • MutationObserver

 

2. 비동기(Async) / Timer API

JS 엔진이 아니라 브라우저가 실행하는 비동기 기능이다

  • setTimeout
  • setInterval
  • clearTimeout
  • clearInterval
  • requestAnimationFrame

3. Network / HTTP API

네트워크 요청을 백그라운드에서 처리하는 기능이다.

  • fetch
  • XMLHttpRequest
  • navigator.sendBeacon
  • WebSocket API
  • Server-Sent Events (EventSource)

4. Storage / Data 저장 API

클라이언트 로컬에 데이터를 저장할 수 있는 기능이다.

  • localStorage
  • sessionStorage
  • IndexedDB
  • Cookies (document.cookie)
  • Cache API (Service Worker와 함께)

5. Browser History & Navigation API

  • history.pushState
  • history.replaceState
  • history.back
  • history.forward
  • location 객체 (location.href, location.reload 등)

JavaScript의 Web API 접근 메커니즘

 

JavaScript는 어떻게 Web API를 사용할 수 있을까?

브라우저 안에는 JavaScript 엔진(V8)만 있는 게 아니라, DOM, 네트워크, 타이머, 스토리지 같은 거대한 브라우저 기능들(Web API) 이 따로 존재한다. 

 

그런데... 여기에서 궁금한 점!! 자바스크립트 엔진과 Wen API 각각에 대해서는 알겠지만

 

JS 엔진은 언어만 실행한다는데… 어떻게 JS 코드가 document, fetch, setTimeout을 쓸 수 있는 걸까??

 

그 이유는 아래와 같다!

 

1) 브라우저가 Web API를 전역 객체(window)에 미리 주입해 둔다

 

브라우저가 새 페이지를 로드할 때 제일 먼저 하는 일 중 하나가 JS 엔진에게 전역 실행 환경(Global Execution Context) 을 만들어 주는 것이다.

 

이때 JS 엔진은 “전역 객체(window)”를 하나 생성한다. 그리고 이 시점에 브라우저가 이것저것들을 넣는다!!!

  • document (DOM API)
  • setTimeout, requestAnimationFrame (Timer API)
  • fetch, XMLHttpRequest (Network API)
  • localStorage, sessionStorage (Storage API)
  • history, location 등등...

즉, window 객체는 JS 엔진과 브라우저 기능이 만나는 접점이다.

 

자바스크립트 코드가 document를 사용할 수 있는 이유는 브라우저가 window.document 를 엔진에게 넘겨줬기 때문인 것이다.

 

2) JavaScript가 호출하면, 엔진이 실행하는 게 아니라 브라우저가 처리한다

 

예를 들어, 아래와 같은 코드가 있다면

 
document.querySelector("#a")

 

이때 JS 엔진(V8)은 아래만 한다.

 

document라는 객체가 있고, querySelector라는 메서드가 있다는 걸 알고 그걸 호출한다

 

하지만 내부에서 DOM 트리를 검색하는 로직은 JS 엔진이 하는 게 아니라 브라우저 렌더링 엔진(Blink 등)이 한다!!!

 

즉!!!! JS 엔진 → (document 객체 호출) → 브라우저의 DOM 모듈 → 결과를 JS 엔진에게 다시 전달

 

JS 엔진은 호출을 할 뿐이고, 진짜 일은 브라우저가 한다. (브라우저 힘내)

 

 

4) 호스트 객체(Host Object)라는 개념

 

JS 언어 자체에 포함된 객체는 Native Object (Object, Array 등)이다.

 

반면!!

  • document
  • window
  • fetch
  • setTimeout 등등... 은 브라우저가 만든 Host Object다.

브라우저가 JS 엔진 옆에 붙여놓은 “외부 기능 모듈”이라고 보면 된다.

 

 

정리하자면, 브라우저에서 JavaScript가 Web API를 쓸 수 있는 이유는 다음 과정 때문이다

  1. 브라우저가 JS 엔진에게 전역 객체(window)를 만든다.
  2. 그 안에 DOM, 타이머, 네트워크 등 브라우저 자체 기능들을 전부 넣어 준다.
  3. JS 코드는 이 window 기반 API를 호출하고
  4. 실제 동작은 전부 브라우저 내부 모듈이 처리한다.
  5. 처리가 완료되면 JS 엔진 쪽으로 다시 결과를 전달해 실행한다.

 

이제 "DOM Interface → 브라우저 구현 → JavaScript 주입 → JavaScript의 DOM 조작" 라는 흐름이 머릿속에 슬슬 들어오는 것 같다... 🤔 🤔 🤔

 

최종적으로 한 문장 정리를 해 보자면!

 

"DOM Interface는 표준 명세를 제공하고, 브라우저는 이 명세에 따라 내부 구조를 구현하며, 이 구현된 기능들은 Web API 형태로 전역 객체에 주입되어 JavaScript가 호출할 수 있게 된다. 최종적으로 JavaScript의 호출을 받은 브라우저가 실제 DOM 조작을 처리한다!"

 

힘들었다... ㅠ.ㅠ

참고 자료

'JS' 카테고리의 다른 글

JavaScript의 Event (2)  (0) 2025.12.01
JavaScript의 Event (1)  (0) 2025.12.01
클로저란(Closure)? (2)  (0) 2025.11.11
클로저(Closure)란? (1)  (0) 2025.11.11
this에 대해서  (0) 2025.11.11
'JS' Related Articles more