많은 단점을 막으면서도 장점은 유지하는 대안적 Web 명세를 어떻게 만들 수 있을지에 대한 비공식 메모입니다.
2026-05-06에 Rodrigo Arias Mallo가 작성
이 문서는 Web에 대한 대안적 명세를 어떻게 구축할 수 있을지에 관한 비공식적인 메모 모음으로, 많은 단점을 막으면서도 여전히 많은 장점을 보존할 수 있기를 바라는 방향을 다룹니다. 이 문서는 명세 자체는 아니므로, 시간이 지나면서 변경될 수 있습니다.
Web은 여러 구성 요소로 이루어져 있으며, 각각을 검토해야 할 수 있습니다. 지금은 HTML 명세(2026-05-06 기준 비압축 크기 18.3 MiB)에 집중하고, 나머지는 나중으로 미루겠습니다.
명세를 만들기 전에, 무엇이 명세의 일부가 되어야 하고 무엇이 아니어야 하는지에 대한 결정을 이끌 명확한 목표 목록이 먼저 있어야 합니다.
전체 명세는 단순하고 짧아야 하며, 그래야 적은 노력으로 만들 수 있는 다양한 브라우저와 다른 클라이언트들의 존재를 보장할 수 있습니다. 시간이 지나면서(수십 년에 걸쳐) 단순함을 유지하는 것은 매우 어렵고, 어쩌면 불가능할 수도 있습니다. 가능한 규칙 하나는 명세의 길이(바이트 수)를 제한하는 것입니다. 우리는 이미 Dillo에서 릴리스를 단일 플로피 디스크 하나에 들어가도록 제한하기 위해 이 기법을 사용하고 있으므로, 같은 접근을 사용할 수 있습니다. 전체 명세를 포함한 압축 tar.gz의 한계를 1.44 MiB로 두는 방식입니다.
현재의 "Web specification"은 대략 매주 바뀌는 페이지입니다. 이 때문에 끊임없는 변경 없이 명세에 부합하는 클라이언트를 프로그래밍하는 것은 불가능합니다. 대신 명세는 1.2.3 같은 매우 정확한 시맨틱 버전을 가져야 하며, 그래야 1.2.3 버전에 부합하는 페이지가 1.2.3, 1.2.0 또는 1.3.0을 지원하는 브라우저에서는 올바르게 렌더링될 수 있지만, 1.1.0이나 2.0.0만 지원하는 브라우저에서는 그렇지 않다는 것을 알 수 있습니다.
시맨틱 버전이 있으면 작성자는 특정 웹 브라우저 구현의 현재 상태가 아니라 표준 자체에 집중할 수 있습니다. 예를 들어, 가령 브라우저의 90%가 이 표준을 지원한다는 것을 알고 1.2.0 버전을 목표로 삼을 수 있습니다.
한 번 공개된 표준 버전은 절대로, 절대로, 절대로, 절대로 바뀌지 않습니다. 오탈자는 패치 버전 번호를 올려 수정합니다. 하위 호환되는 새 기능은 마이너 버전을 올려 도입합니다. 그리고 호환성을 깨는 변경은 메이저 버전 증가가 필요합니다. 이는 1.2.0 표준의 인쇄본을 사서 무인도에서 그것을 사용해 완벽히 준수하는 브라우저를 프로그래밍할 수 있으며, 그 브라우저는 앞으로도 영원히 1.2.X 문서를 올바르게 구문 분석할 수 있음을 뜻합니다.
명세는 쉽게 파싱할 수 있는 모호하지 않은 형식 문법을 포함해야 합니다. 그러면 페이지를 표준에 대조해 준수 여부를 거부하거나 승인할 수 있습니다. 명세에 부합하지 않는 페이지는 렌더링되지 않습니다. 명세에 부합하지 않는 어떤 페이지도 클라이언트가 받아들이는 것은 명시적으로 금지됩니다. 이는 망가진 페이지를 고치기 위해 구현해야 하는 표준화된 악마 같은 규칙들을 막고, 명세가 이후 버전에서 스스로의 실수를 고치도록 강제합니다.
엄격한 문법을 가지면 사람들은 쓰기 쉽고 더 관대한 언어(예를 들어 Markdown)로 이동하게 될 가능성이 높으며, 이것이 의도된 효과입니다. 목표는 파서를 단순화하고, 콘텐츠를 다룰 수 있는 도구를 만드는 비용을 낮추는 것입니다.
특히 패치 버전 번호의 변경은 문구만 바꾸며, 문법은 그대로 유지됩니다.
기존 소프트웨어에서 최소한의 노력으로 동작할 수 있도록 HTML의 부분집합을 만들 수 있다면 좋을 것입니다. 그러나 HTML 파싱의 복잡성을 고려하면 이것이 가능하지 않을 수도 있습니다. 마찬가지로 XML 문서의 형식 문법을 만드는 일도 간단하지 않습니다. 따라서 HTML/XML이 단순한 파싱에 적합한 형식인지 검토가 필요합니다.
Web의 문제 가운데 하나는, 독점적 실체가 거기서 수익을 뽑아낼 수 있는 메커니즘을 만들 수 있게 되는 즉시 표준을 장악하고 자신들의 이익을 위해 바꾸려는 유인이 생긴다는 점입니다. Web의 경우 특히, 이는 복잡성이 통제를 벗어나 성장하는 표준으로 이어졌고, 새 브라우저의 진입 장벽을 높이며 경쟁을 줄였습니다.
이 상황을 막아 보려는 대략적인 아이디어가 몇 가지 있지만, 이는 게임 이론의 관점에서 더 신중하게 연구될 필요가 있습니다.
명세의 목표는 인쇄된 책이나 글이 하듯이, 사람들 사이에 정보를 전달하는 데 충분한 세부 사항을 포괄하는 것입니다. 기록된 텍스트는 번역될 수 있고, 컴퓨터가 소리 내어 읽을 수 있으며, 적은 저장 공간에 압축해 저장할 수 있으므로 정보를 부호화하는 가장 다재다능한 방식으로서 선호되는 매체여야 합니다.
텍스트는 화면 크기에 맞게 줄바꿈될 수 있어야 하며, 그래야 같은 문서를 작은 화면과 큰 화면 모두에서 읽을 수 있습니다.
스크립팅 기능을 추가한 것은 실수였으므로, 이제는 그것을 피할 수 있습니다. 그렇다고 사용자가 상호작용 프로그램을 가질 수 없다는 뜻은 아닙니다. 한 예로, 현재는 관심 지점의 위치를 보여 주기 위해 JavaScript를 사용해 브라우저에 불러오는 상호작용 지도 같은 것이 있습니다. 대신 그 위치를 여는 Geo link를 제공하면, 해당 프로토콜을 지원하는 어떤 클라이언트에서든 열 수 있습니다. 비슷하게, open specification이 존재한다면 어떤 클라이언트든 당신의 서버 타일을 사용할 수 있습니다.
표준화된 파일이나 URL을 불러오기 위해 네이티브 프로그램을 사용하는 것의 장점은, 그것이 사용 중인 기기에 맞게 최적화될 수 있고 많은 상호작용 Web 페이지의 "one size fits all" 접근을 막을 수 있다는 점입니다.
목표는 Web의 기능별 복제물을 만드는 것이 아니라, 사람이 지식을 교환하고 메모 및 다른 형태의 정보를 주고받을 수 있게 하되, 그것을 읽기 위해 완전한 VM을 실행해야 한다는 강제된 요구사항 없이 가능한 명세를 만드는 것입니다.
