WHATWG

WHATWG 는 브라우저가 따를 웹 표준을 쓰고 고쳐 나가는 모임입니다. 웹 페이지를 읽고 그리는 핵심 규칙이 여기서 나옵니다. 판 번호를 매겨 끝내는 대신 한 문서를 늘 고쳐 씁니다.

상세

단골 식당 주방 벽에는 그날 들어온 재료에 맞춰 이름과 값을 지웠다 다시 쓰는 칠판 메뉴가 걸려 있습니다. 전단을 새로 돌릴 때가 되면 그날의 칠판을 옮겨 적은 종이 한 장을 따로 남깁니다. 손님에게 하는 약속은 지우지 않는 그 종이가 맡습니다.

WHATWG(Web Hypertext Application Technology Working Group)는 표준과 테스트로 웹을 발전시키려는 사람들의 공개 모임입니다. 이 모임이 다루는 것은 웹 브라우저가 구현할 수 있는 표준과 그 표준에 딸린 테스트입니다.

HTML(HyperText Markup Language) 문서를 읽는 규칙이 그런 표준입니다. 페이지를 객체 트리로 다루는 DOM(Document Object Model), 네트워크 요청을 보내는 절차를 정한 Fetch, 주소 문자열을 해석하는 URL(Uniform Resource Locator)도 이 모임이 맡습니다.

다른 표준화 기구와 나눈 몫

웹 표준을 내는 기구는 하나가 아닙니다. 가장 널리 알려진 곳은 W3C(World Wide Web Consortium)입니다. WHATWG 는 HTML Living Standard 를 맡습니다. 이 문서는 HTML 요소와 그 요소에 딸린 API(Application Programming Interface), 관련 기술을 어떻게 구현해야 하는지 적습니다.

JavaScript 의 바탕인 ECMAScript 표준은 또 다른 곳에서 나옵니다. Ecma 의 TC39(Technical Committee 39)가 정해 펴냅니다.

HTML 과 DOM 은 주로 WHATWG 에서 만듭니다. 2019년에 W3C 와 맺은 양해각서가 그렇게 정했습니다. W3C 는 그 대신 WHATWG 가 펴낸 사본에 의견을 냅니다. 그리고 그 사본을 자기 권고로 올리려 합니다. 권고는 W3C 가 정식 표준으로 확정한 문서를 부르는 이름입니다.

결정하는 사람

참여에는 회비가 없습니다. 누구나 기여할 수 있는 열린 과정입니다. 참여는 전부 인터넷으로 할 수 있습니다. 대면 회의에서는 구속력 있는 결정을 내리지 않습니다.

표준 한 편이 만들어지는 데는 네 역할이 얽힙니다.

모임은 기여자 사이의 느슨하고 비공식적인 합의(rough consensus)를 목표로 합니다. 모든 쪽의 의견을 본 뒤 그 표준의 편집자가 판단합니다. 편집자 판단에 동의하지 않는 참여자는 운영위원회에 이의를 낼 수 있습니다. 모임은 이것이 예외적인 경우이기를 바랍니다.

운영위원회의 결정은 느슨한 합의가 아니라 공식 합의 정책(formal consensus policy)을 따릅니다. 그 정책이 정한 절차는 자료에 없습니다(미확인).

운영위원회 구성원은 브라우저 엔진을 만드는 조직에서 임명합니다. 브라우저 엔진은 브라우저 안에서 페이지를 읽고 그리는 핵심 부분입니다.

운영위원회는 마지막 안전장치입니다. 편집자의 판단이 이 조직들이 구현할 내용과 어긋나지 않게 받칩니다.

Living Standard

WHATWG 의 표준은 Living Standard 라고 부릅니다. 웹 개발자 · 브라우저 제작사 · 도구 제작사 등 누구에게서든 의견이 들어오면 문서를 고칩니다. 새 기능도 시간을 두고 더합니다. 더하는 속도는 표준이 구현보다 조금 앞서되 구현이 따라가기를 포기할 만큼 멀어지지 않게 맞춥니다.

그렇다고 아무 때나 마음대로 바뀌지는 않습니다. 하위 호환은 이미 있던 페이지와 구현이 계속 돌게 지키는 것입니다. 무르익은 데다 구현까지 출시된 부분은 대개 아주 조심하지 않고는 하위 호환을 깨는 쪽으로 못 바꿉니다.

구현자는 표준대로 브라우저를 만드는 곳입니다. 하위 호환을 깨는 변경은 구현자가 그 변경을 구현하겠다고 먼저 약속할 때만 일어납니다.

끝나는 판이 없는 까닭은 웹이 늘 바뀌기 때문입니다. HTML 이 「완성」이라 불린 마지막 때는 넷째 판인 HTML4(HyperText Markup Language 4) 뒤였습니다. 그 뒤 몇 년 동안 개발이 멈췄습니다. HTML 은 그동안 정체됐습니다.

늘 바뀌는 문서에서도 한 시점을 가리킬 수 있습니다. 문서의 변경 하나하나는 커밋 하나로 남습니다. 커밋마다 그 시점의 문서를 얼린 스냅숏이 따로 발행됩니다. 「이 구현은 어느 시점의 표준까지 따라갔다」를 적을 때 이 스냅숏을 가리킵니다.

이와 별도로 편집자는 여섯 달쯤마다 Review Draft 를 펴냅니다. Review Draft 는 특허 검토의 기준으로 쓰려고 Living Standard 를 한 시점에 고정한 사본입니다.

특허 검토가 필요한 까닭은 표준을 구현하려면 피할 수 없는 특허 권리가 있을 수 있기 때문입니다. 그런 권리를 필수 특허 청구항이라고 부릅니다. 서명 참여자는 이 고정 사본을 기준으로 자기 필수 특허 청구항을 검토합니다. 라이선스를 내줄지 제외할지는 아래 「동작」의 마지막 소절이 다룹니다.

배경

2004년 무렵 Apple · Mozilla 재단 · Opera Software 의 사람들은 W3C 를 점점 걱정했습니다. 걱정은 셋이었습니다 — W3C 가 XHTML(Extensible HyperText Markup Language) 로 가는 방향, HTML 에 대한 관심 부족, 실제 웹 개발자의 필요를 외면하는 듯한 태도입니다. XHTML 은 HTML 을 XML(Extensible Markup Language) 문법 규칙에 맞춰 다시 정의한 언어입니다.

세 곳의 사람들은 W3C 워크숍을 마친 뒤인 2004년에 이 모임을 세웠습니다. 2017년에는 Apple · Google · Microsoft · Mozilla 가 지식재산권 정책과 운영 구조를 만드는 일을 도왔습니다. 네 회사는 관련 정책을 감독할 운영위원회도 함께 꾸렸습니다.

W3C 도 HTML 5.3 과 DOM 4.1 이라는 자기 판을 낼 계획을 세워 두고 있었습니다. 같은 표준이 두 갈래로 나뉘면 비용이 큽니다. 사람들도 서로 다른 문서에 나뉘어 매달립니다.

2019년 두 기구는 양해각서를 맺었습니다. 표준마다 개발 흐름이 하나일 때 웹 공동체에 가장 도움이 된다고 두 곳 모두 믿는다는 전제를 적었습니다. 그리고 HTML 과 DOM 은 주로 WHATWG 에서 Living Standard 절차로 개발한다고 정했습니다. W3C 는 HTML 5.3 · DOM 4.1 계획을 접었습니다.

flowchart TD
    subgraph before["양해각서 전"]
        A["W3C 의 HTML 5.3 · DOM 4.1 계획"]
        B["WHATWG 의 HTML · DOM Living Standard"]
    end
    subgraph after["양해각서 뒤"]
        C["W3C 는 계획을 접고 의견만 냄"]
        D["WHATWG 의 Living Standard"]
        E["Review Draft"]
        F["W3C 권고"]
    end
    A --> C
    B --> D
    D --> E
    C --> E
    E --> F

예시

아래 두 벌은 WHATWG 표준 문서의 머리입니다. 둘 다 URL 표준의 것입니다. 하나는 늘 고쳐 쓰는 Living Standard 입니다. 다른 하나는 한 시점에 고정한 Review Draft 입니다.

URL 표준의 Living Standard 머리

URL
Living Standard — Last Updated 10 September 2026
Commits:
GitHub whatwg/url/commits
Snapshot as of this commit
Tests:
web-platform-tests url/ (ongoing work)

제목 아래에 판 번호가 없습니다. 「Last Updated 10 September 2026」처럼 마지막으로 고친 날짜만 붙습니다.

「Snapshot as of this commit」 링크는 이 커밋 시점의 스냅숏 /commit-snapshots/8e14777cfa145b08a9fb735fe580ec0c366564c3/ 으로 갑니다. Tests 줄은 이 표준에 딸린 테스트가 web-platform-tests 의 url/ 묶음에 있다고 알립니다. 그 테스트는 작업이 진행 중이라고 표시돼 있습니다.

머리말은 특허 검토용 판을 보려면 Living Standard Review Draft 를 보라고 안내합니다. 그 링크는 /review-drafts/2026-08/ 입니다.

HTML 표준의 머리도 같은 꼴입니다. 「Living Standard — Last Updated 1 October 2026」 아래에 커밋 스냅숏 링크와 web-platform-tests 의 html/ 테스트 줄이 붙습니다.

URL 표준의 Review Draft 머리

URL Standard Review Draft August 2026
URL
Review Draft — Published 18 August 2026
This is a Review Draft of the standard

이 사본에는 고친 날짜 대신 펴낸 날짜가 붙습니다. 주소의 2026-08 이 그 달입니다.

머리말은 이 판이 주로 서명 참여자의 특허 검토용이라고 밝힙니다. Living Standard 를 가깝게 비추되 아직 정리되지 않았다고 표시된 글만 뺐다고 적습니다. 그 표시는 둘입니다 — 이의가 걸려 있다는 「Objection Pending」, 확인을 기다린다는 「Confirmation Pending」입니다.

이 판을 구현하지 말라는 경고도 붙어 있습니다. 권위 있는 문서로 인용하지도 말라고 합니다. 개발자가 볼 문서는 https://url.spec.whatwg.org/ 의 Living Standard 입니다.

동작

이 절은 WHATWG 표준 한 편에 변경 하나가 들어가는 순서를 봅니다. 무엇을 갖춰야 문서에 들어가는지, 들어간 뒤 특허 약속이 어떻게 걸리는지가 이 순서로 정해집니다.

flowchart TD
    A["웹 개발자 · 브라우저 제작사 · 도구 제작사의 의견"] --> B["편집자가 변경 조건 확인 · 구현자 지지는 반드시"]
    B --> C{"기능을 더하는 변경인가"}
    C -->|"예"| D["구현자 둘 이상의 지지가 더 필요"]
    C -->|"아니오"| E["Living Standard 에 반영 · 커밋마다 스냅숏"]
    D --> E
    E -->|"여섯 달쯤마다"| F["Review Draft 발행"]
    F -->|"45일 안에 제외하지 않으면"| G["필수 특허 청구항의 라이선스 약속"]

변경이 문서에 들어가는 조건

규범적 변경은 구현이 지켜야 할 규칙을 바꾸는 변경입니다. 이런 변경은 아래 조건을 따릅니다. 조건을 채웠는지는 편집자가 확인합니다. 표의 「사용자 에이전트」는 브라우저처럼 사용자를 대신해 웹에 접속하는 프로그램입니다.

구현이 제안된 변경과 어긋나도 테스트가 그 어긋남을 드러내지 못할 수 있습니다. 어긋남을 다른 경로로 알았다면 테스트부터 고쳐야 합니다(should).

기능을 더하는 변경에는 조건이 하나 더 붙습니다. 구현자 둘 이상의 지지가 있어야 합니다. 이 지지가 구현자를 묶지는 않습니다.

편집자는 구현이 표준을 따르는지, 표준이 구현을 따르는지를 보장할 책임을 집니다. WHATWG 는 이것을 「소설을 쓰지 마라(don't write fiction)」 규칙이라 부릅니다.

이견이 갈 곳

편집자의 선택이 여러 구현자의 지지를 못 얻으리라 보는 서명 참여자가 있을 수 있습니다. 편집자를 설득하지 못하면 그 참여자는 운영위원회에 정식으로 이의를 낼 수 있습니다. 운영위원회는 구현자의 자격으로 편집자의 결정을 바로잡거나 유지할 수 있습니다.

구현자는 언제든 다른 것을 구현해 편집자의 결정을 뒤집을 수 있습니다.

flowchart TD
    A["편집자의 결정"] --> B["서명 참여자가 편집자를 설득"]
    B -->|"설득하지 못하면"| C["운영위원회에 정식 이의"]
    C --> D["결정을 바로잡음"]
    C --> E["결정을 유지"]
    F["브라우저 엔진을 만드는 조직이 운영위원회 구성원을 임명"] --> C
    A --> G["구현자가 다른 것을 구현해 결정을 뒤집음"]

특허 약속이 걸리는 주기

편집자는 Review Draft 를 여섯 달쯤마다 펴냅니다. 앞 Review Draft 뒤로 바뀐 것이 없으면 그 차례는 건너뜁니다.

Review Draft 는 Living Standard 와 실질적으로 같습니다. 아직 정리되지 않았다고 표시된 글만 빼고 냅니다.

WHATWG 는 아래 설명을 규범이 아닌 쉬운 말로 적은 것이라고 밝힙니다. 서명 참여자는 지식재산권 정책에 서명합니다. 그 서명으로 자기가 가진 필수 특허 청구항에 라이선스를 내주기로 약속한 셈이 됩니다. 이 약속에서 빠지려면 Review Draft 가 나온 뒤 45일 안에 그 청구항을 제외해야 합니다.

사용처

WHATWG 표준을 구현하는 곳은 셋입니다. 표준의 논란을 마지막에 정리하는 브라우저 엔진 회사들, 그리고 브라우저 밖에서 같은 표준을 따르는 런타임 둘입니다.

브라우저 엔진을 만드는 회사

운영위원회의 첫 구성원은 자격을 갖춘 법인(Qualifying Entity) 네 곳입니다. Mozilla Corporation · Microsoft Corporation · Google LLC · Apple Inc. 입니다.

다른 곳이 더 들어오려면 그곳도 자격을 갖춘 법인이어야 합니다. 들어올 때의 운영위원회 구성원 전원이 동의해야 합니다. 위원회는 셋 이상 일곱 이하로 꾸립니다.

표준의 논란을 마지막에 정리하는 회사들이 곧 그 표준을 엔진에 구현하는 회사들입니다.

Node.js 의 URL 클래스

Node.js 의 node:url 모듈은 URL 을 다루는 API 를 둘 줍니다. 하나는 Node.js 에만 있는 옛 API 입니다. 다른 하나는 웹 브라우저가 쓰는 것과 같은 WHATWG URL Standard 를 구현한 새 API 입니다.

새 API 는 URL 클래스로 씁니다. 그래서 서버 코드가 브라우저와 같은 규칙으로 주소를 읽습니다.

옛 url.parse() 는 폐기 예정(Deprecated)으로 표시돼 있습니다. 대신 WHATWG URL API 를 쓰라고 안내합니다. url.parse() 는 표준이 아닌 느슨한 알고리즘으로 URL 문자열을 해석합니다. 그래서 호스트 이름 위장이나 사용자 이름 · 비밀번호의 잘못된 처리 같은 보안 문제가 생기기 쉽습니다.

Deno 의 fetch 와 이벤트

Deno 는 웹과 클라우드 개발을 단순하게 하려고 자체 API 대신 표준 웹 플랫폼 API 를 씁니다. 그 가운데 HTTP(HyperText Transfer Protocol) 요청을 보내는 fetch 는 WHATWG Fetch 표준대로 구현돼 있습니다. 이벤트를 보내고 듣는 CustomEvent · EventTarget 은 WHATWG DOM 표준을 따릅니다.

Deno 가 표준을 전부 따르지는 않습니다. 출처(origin)는 프로토콜 · 호스트 · 포트로 사이트를 가리키는 단위입니다. 셋이 모두 같아야 같은 출처입니다.

동일 출처 정책은 인증된 데이터가 다른 출처로 새지 않게 막는 브라우저 규칙입니다. Deno 에는 지금 출처라는 개념도 쿠키 저장소도 없어서 이 보호가 필요 없습니다. 그래서 Fetch 표준의 몇몇 절을 구현하지 않습니다.

관련 항목

WHATWG 가 쓰고 고치는 표준

HTML · DOM · Fetch · WHATWG URL 표준 · WHATWG Encoding Standard · Streams · Infra Standard · XMLHttpRequest · MIME Sniffing · HTML Living Standard

WHATWG 가 표준을 고치고 펴내는 절차

Living Standard · Review Draft · web-platform-tests · 하위 호환성 · 지식재산권 · 커밋

WHATWG 와 웹 표준을 나눠 맡는 표준화 기구

W3C · IETF · Ecma International · TC39

WHATWG 밖에서 정하는 이웃 웹 표준

ECMAScript · JavaScript · CSS · RFC 3986

WHATWG 표준을 구현하는 브라우저와 런타임

웹 브라우저 · 브라우저 엔진 · 사용자 에이전트 · Node.js · Deno · undici

WHATWG 표준이 정하는 웹 기술

URL · CORS · 동일 출처 정책 · 문자 인코딩 · 웹소켓

WHATWG 가 비롯된 배경

XHTML · XML · HTML4 · HTML5