Web을 포크하는 것에 관하여
(dillo-browser.org)- 대안 명세의 목표는 Web 전체가 아니라 2026년 5월 6일 기준 압축 해제 크기 18.3MiB인 HTML 명세를 우선 대상으로 삼아, Web의 장점은 유지하고 단점은 피하는 것임
- 명세는 짧고 단순해야 하며, 전체 명세를 담은 압축
tar.gz를 1.44MiB로 제한하는 방식처럼 구현 부담을 낮춰 다양한 브라우저와 클라이언트가 나올 수 있게 해야 함 - 현재 Web specification처럼 계속 바뀌는 문서가 아니라
1.2.3같은 의미적 버전을 가져야 하며, 게시된 표준 버전은 절대 변경되지 않아야 함 - 명세에는 쉽게 파싱 가능한 모호하지 않은 형식 문법이 포함되어야 하고, 표준을 준수하지 않는 페이지는 렌더링하지 않도록 해 파서와 콘텐츠 도구 제작 비용을 낮춰야 함
- 대안 명세는 기능별 Web 복제가 아니라 작성된 텍스트 중심의 정보 교환을 목표로 하며, 스크립팅 대신 Geo link나 tiled web map 표준처럼 표준화된 파일·URL을 네이티브 프로그램에서 여는 방식을 선호함
웹 대안 명세의 목표
- HTML 명세는 2026년 5월 6일 기준 압축 해제 크기가 18.3MiB이며, 우선 검토 대상은 Web 전체가 아니라 HTML 명세로 한정됨
- 목표는 Web의 장점을 가능한 한 유지하면서 단점을 피하는 대안 명세를 만드는 것임
- 아직 정식 명세가 아니라 시간이 지나며 바뀔 수 있는 비공식 노트에 가까움
단순성과 구현 다양성
- 전체 명세는 짧고 단순해야 하며, 낮은 노력으로 다양한 브라우저와 클라이언트를 만들 수 있어야 함
- 수십 년 동안 단순성을 유지하기는 매우 어렵기 때문에, 명세 길이를 바이트 단위로 제한하는 규칙이 한 가지 방법이 될 수 있음
- Dillo는 릴리스를 단일 플로피 디스크에 맞추기 위해 같은 방식을 사용하고 있으며, 대안 명세도 전체 명세를 담은 압축
tar.gz기준 1.44MiB 제한을 둘 수 있음
의미적 버전 관리
- 현재의 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의 부분집합을 만들 수 있다면 바람직함
- 다만 HTML 파싱의 복잡성 때문에 가능하지 않을 수 있음
- XML 문서의 형식 문법을 만드는 일도 단순하지 않기 때문에, HTML/XML이 단순 파싱에 적합한 형식인지는 검토가 필요함
표준 포획에 대한 저항
- Web의 문제 중 하나는 독점적 주체가 수익 추출 메커니즘을 만들 수 있게 되면, 표준을 포획해 자신에게 유리하게 바꿀 유인이 생긴다는 것임
- Web에서는 그 결과 표준 복잡성이 통제 불가능하게 커졌고, 새 브라우저의 진입 장벽이 높아졌으며 경쟁이 줄어든 것으로 봄
- 이런 상황을 막기 위한 초기 아이디어는 있지만, 게임 이론 관점에서 더 신중한 검토가 필요함
텍스트 우선 원칙
- 명세의 목적은 인쇄된 책이나 글처럼 인간 사이에서 정보를 전달하기에 충분한 세부사항을 다루는 것임
- 작성된 텍스트는 정보를 인코딩하는 가장 다재다능한 매체로 우선되어야 함
- 텍스트는 번역될 수 있고, 컴퓨터가 소리 내어 읽을 수 있으며, 적은 저장공간에 저장될 수 있음
- 문서는 화면 크기에 맞춰 줄바꿈되어야 하며, 같은 문서를 작은 화면과 큰 화면 모두에서 읽을 수 있어야 함
스크립팅 배제
- 스크립팅 기능 추가는 실수였으므로 대안 명세에서는 피할 수 있음
- 이것이 사용자의 상호작용 프로그램 사용을 제한하는 것은 아님
- 예를 들어 현재는 JavaScript로 브라우저 안에서 관심 지점 위치를 보여주는 대화형 지도를 로드하지만, 대신 Geo link를 제공해 해당 프로토콜을 지원하는 어떤 클라이언트에서든 위치를 열 수 있음
- 마찬가지로 공개 명세가 있다면 어떤 클라이언트든 서버의 지도 타일을 사용할 수 있으며, 관련 예로 tiled web map 표준이 제시됨
- 표준화된 파일이나 URL을 네이티브 프로그램에서 여는 방식은 사용 중인 기기에 맞게 최적화될 수 있고, 많은 대화형 웹 페이지의 일률적 접근을 피할 수 있음
목표가 아닌 것
- 목표는 Web을 기능별로 복제하는 것이 아님
- 인간이 지식, 노트, 기타 정보를 교환할 수 있게 하되, 그것을 읽기 위해 완전한 VM을 실행해야 하는 요구를 제거하는 명세를 만드는 것이 목표임
Lobste.rs 의견들
-
그래서 다시 모든 것에 앱이 필요하다는 건가? 스크립트 기능 자체가 실수였다는 데는 동의하지 않음
웹이 운영체제 경계를 넘는 범용 플랫폼이라는 점은 좋다고 봄- 같은 생각임. 표준화된 파일이나 URL을 네이티브 프로그램으로 여는 장점이 기기에 맞게 최적화되고 “모두에게 하나로 맞추는” 웹페이지 방식을 피하는 것이라지만, Linux 사용자가 2등 시민이던 시절로 돌아가고 싶지는 않음
Windows만 지원하고 가끔 Mac만 추가되던 시절 말임 - 웹 앱에 대해 불평할 수는 많지만, 모바일 플랫폼에 앱을 배포할 때 Apple 세금과 미래의 Google 세금을 피할 수 있는 거의 유일한 방법이기도 함
그리고 네이티브 데스크톱 개발 상황도 단순하지 않아서, 데스크톱에서 웹 앱이나 Electron을 택하는 사람들에게 충분히 공감함 - 왜 모든 것에 앱이 필요함? 이 명세가 일반 웹 브라우저 실행을 막는 것도 아니고, 지금의 웹이 사라지는 것도 아님
- 진짜 적절한 지점은 표준화된 마크업만으로 어디까지 할 수 있는지 찾는 것이라고 봄
현대 웹의 문제는 개념을 끝없이 재발명한다는 데 있고, 그중 상당수는 선언적 마크업이어야 함. 웹사이트 표시 경로에 JavaScript가 끼어들 필요는 없어야 함. 스크립팅은 서버에서 하던 작업을 클라이언트에서 하는 경우, 예를 들어 서버가 반환한 데이터셋을 가공하는 식의 특정 클라이언트 측 프로그래밍에 쓰여야 함 - 사실 이미 모든 것에 앱이 있음. 다만 앱 대신 URL이나 도메인 이름이라고 부를 뿐임
IT 업계는 Java와 Swing, Flash 같은 샌드박스 대안이 고통스러울 정도로 열등하다는 게 분명해지자 웹 브라우저를 사실상의 가상 머신으로 밀어준 느낌임. 이제는 단일 애플리케이션인 Google Chrome이 사용자 일반 컴퓨팅 대부분의 가상 머신 역할을 하고 있고, 그것도 감시 자본주의 독점 기업이 소유하고 개발함. 이게 진짜 더 안전한지, 아니면 실제 제로데이가 너무 비싸져서 공개되지 않는 것인지는 모르겠음
스크립팅 추가는 실수였다고 봄. 적어도 나중에 덧붙인 기능이었고, Dillo가 하이퍼텍스트 문서 리더의 범위를 문서 읽기에 두고, 리더 안에서 문서 작성·편집까지 가능하게 하려 하지 않는 데 동의함
목표는 웹을 기능별로 복제하는 게 아니라, 지식·메모·정보를 교환하기 위해 풀사이즈 가상 머신을 실행해야 하는 요구 없이 읽을 수 있는 명세를 만드는 것임
더 나은 샌드박스 안에서 대부분의 “상호작용” 요구를 처리하는 축소된 범용 애플리케이션을 보고 싶음. Reddit 같은 소셜 미디어 피드에서 하이퍼텍스트를 주고받는 데 전체 가상 머신이 정말 필요한가? 쇼핑 카트와 결제 정보를 처리하는 데도 전체 가상 머신이 필요한가?
다만 “범용”이 결국 “애플리케이션”을 집어삼키고, 그 지점에서 웹을 다시 발명하게 될 가능성이 큼. 그래도 Google이 아닌 주체, C++가 아닌 언어가 기반이 될 기회가 있다면 더 나을 수도 있음. Dillo는 C와 C++인 듯하니 둘 중 하나만이라도 나아진 셈인가 싶음
- 같은 생각임. 표준화된 파일이나 URL을 네이티브 프로그램으로 여는 장점이 기기에 맞게 최적화되고 “모두에게 하나로 맞추는” 웹페이지 방식을 피하는 것이라지만, Linux 사용자가 2등 시민이던 시절로 돌아가고 싶지는 않음
-
추가로 개선하면 좋을 점은 HTTP 축소판을 쓰되 쿠키는 클라이언트가 제어하는 세션 쿠키만 지원하는 것, 서드파티 리소스를 금지하고 모든 리소스를 문서와 같은 웹 서버에 두는 것, 브라우저 내부 변환기로 text/markdown 같은 형식 렌더링을 요구하는 것임
- 서드파티 리소스 금지만으로도 여러 심각한 문제를 막을 수 있음
- 이상적으로는 전송 방식에 독립적으로 만들고 싶음. 아마 먼저 로컬부터 시도해서 어떤 원격 파일시스템 마운트 지점에서도 동작하게 할 듯함
이번에는 식단을 개선해서 쿠키를 피할 수 있는지 보자는 입장임. 이건 문서의 기계 표현이며, 사람이 읽을 수 있게 설계됐지만 사람이 직접 쓰기 위한 것은 아님. 대신 Markdown 같은 프런트엔드 언어를 쓰고, 이를 이식 가능한 엄격한 문서로 컴파일하는 방식이 좋음 - 제안하자면 쿠키가 꼭 필요하다면 해당 사이트 도메인에만 적용해야 함.
example.net의 쿠키는sub.example.net에 보내지 않고,sub.example.net의 쿠키도example.net에 설정되지 않아야 함
HTTP/2와 HTTP/3는 애플리케이션 웹에 남기고, HTTP/1은 문서 웹에 남기는 편이 좋음. JavaScript를 어떻게 제한해야 “내 콘텐츠를 보려면 전용 브라우저가 필요함” 문제를 피할 수 있을지는 모르겠으니 JavaScript는 없어야 함
text/markdown 렌더링을 요구한다면 어떤 버전을 말하는지도 문제임. 지원해야 할 변형이 대략 반 다스는 됨
-
엄격한 문법은 잘 안 될 것임. XHTML이 실패한 이유도 그거고, HTML5가 흔한 “깨짐”을 처리하는 규칙을 추가한 이유도 그 때문임
저자가 원하는 것처럼 HTML5를 더 형식적인 문법으로 다시 명세화할 수는 있겠지만, 페이지를 엄격하게 거부하는 것은 포크의 좋은 활용으로 보이지 않음. 다른 대안은 또 하나의 gopher/gemini 대체물이 되는 것인데, 열성 팬층은 있어도 인기 없는 데는 이유가 있음. 하위 호환성의 힘이 너무 강함- XHTML이 실패한 이유가 엄격함 때문이라는 데는 동의하지 않음. IE가 2011년까지 XHTML을 지원하지 않은 것이 너무 늦었고, 그래서 사람들이 실제 XHTML을 쓰지 않아 그 이점을 얻지 못했기 때문임
엄격함은 아주 좋을 수 있지만, 지원이 있어야 작동함
- XHTML이 실패한 이유가 엄격함 때문이라는 데는 동의하지 않음. IE가 2011년까지 XHTML을 지원하지 않은 것이 너무 늦었고, 그래서 사람들이 실제 XHTML을 쓰지 않아 그 이점을 얻지 못했기 때문임
-
“스크립트 기능 추가가 실수였다”는 생각은 재미를 허용하지 않는 우울한 프로그래머 타입 사이에서 오래된 밈이었지만, 상상력 부족에 가깝다고 봄
신중하게 적용된 상호작용형 멀티미디어는 의사소통과 설명을 크게 향상시킬 수 있음. 예를 들어 Red Blob Games Hex-Grid tutorial의 상호작용 도표나 Bartosz Ciechanowski's fantastic explanation of mechanical watch movement를 보면 됨. 웹의 상호작용 미디어 덕분에 Canon Cat 같은 역사적으로 중요한 희귀 컴퓨터도 네이티브 에뮬레이터를 컴파일하고 실행하는 악몽 같은 절차 없이 링크 클릭 몇 초 만에 써볼 수 있음. 폼 제출과 이미지 맵은 멀티미디어의 극히 희미한 그림자일 뿐이고, 상호작용 지원 부담을 본질적으로 서버 중심이자 잠재적으로 대역폭을 많이 쓰는 모델로 옮김
문제는 스크립트 동작 자체가 아니라, 현재 브라우저에서 스크립트가 할 수 있도록 허용된 일임. HTTP와 HTML을 더 작고 단순하며 사용자 자율성을 존중하는 시스템으로 줄일 수 있듯, 웹 JavaScript의 긍정적인 면 대부분은 유지하면서 API 표면적과 악성 가능성은 크게 줄일 수 있음. 예를 들어 페이지 안에 Flash 같은 상호작용 사각형이 있고, 그 상호작용은 사용자가 접근·검사 가능한 Lua 스크립트와 Love2D 같은 그래픽·입력 기능으로 제공되며, 원격 서버로 연락하거나 웹캠에 접근하는 사생활 침해성 작업은 강한 샌드박스와 사용자의 명확한 사전 동의 뒤에 놓이는 웹을 상상해볼 수 있음
이런 식으로 존중하는 웹 애플리케이션을 오늘날에도 만들 수는 있지만, 기반이 울퉁불퉁하고 일관성이 없으며, 유용한 기능의 명백한 누락과 사용자 안전·사생활에 대한 불필요한 위협이 곳곳에 있음
접근성 관점의 비전으로는, 버튼·필드·체크박스·슬라이더 같은 선언적 UI 입력을 엄격하게 처리하고, 정적 페이지처럼<iframe>안에 이미지와 마크업을 렌더링하되 원격 서버 왕복 없이 동작하는 클라이언트 측 폼을 생각할 수 있음. 다양한 계산기, 도구, 상호작용 시각화가 이런 모델에 들어갈 수 있고, 백엔드 주도 모델보다 지연 시간과 사용자 보안이 더 나아짐 -
“텍스트 우선”이라면 CSS도 내려놓아야 함. CSS는 대체로 사용자가 아니라 회사를 위해 존재함. 스타일은 페이지가 아니라 브라우저가 제어해야 함
사용자가 원시 페이지 페이로드를 읽기로 했다면, 그 대부분이 브라우저가 읽으라고 보여준 정보와 같아야 함. 오늘날 읽을 수 있는 콘텐츠는 빙산의 일각일 뿐임
“스크립팅 없음”에 대해서는, 스타일과 부피 큰 페이지를 제거하면 표시 방식에 영향을 주는 스크립팅 필요도 크게 줄어들 수 있다고 추측함. 표시 방식에 영향을 주지 않는 스크립팅은 대체로 사용자 이익에 반해 쓰여 왔음- 그게 원래 CSS 캐스케이드의 핵심이었음. 책과 논문 서식에 쓸 수 있는 합리적인 CSS 부분집합이 있고, 사용자 스타일과 병합되도록 되어 있었음
하지만 CSS와 서식이 지나치게 복잡해졌고, 사용자 스타일은 이제 전체 CSS 리셋으로 시작하거나 사이트별로 매우 구체적이어야 함 - 독자의 시간대에 맞춰 타임스탬프를 표시하고 싶다면, 현재는 클라이언트 측 스크립팅 없이는 방법이 없음
클라이언트에 JS 없이 개인용 도구를 만들다가 이 문제를 겪었고, 서버에 “내 시간대 설정”을 두거나 작은 보조 스크립트를 추가해야 한다는 걸 깨달았음
스타일을 브라우저가 제어하게 하면 “내 페이지는 브라우저 X와 Y에서는 읽을 만한데 Z에서는 안 읽힘” 같은 문제가 지금보다 더 심해질 수도 있어 보임 - CSS가 가득한, 색상과 화려한 배경, 좋은 글꼴, flexbox와 grid 레이아웃이 있는 세상에서 행복하게 살겠음
저자의 목소리를 흰 배경의 검은 텍스트로 씻어내린 밋밋한 문서만 보는 쪽보다는 낫다고 봄. CSS는 웹에서 저자의 표현 방식이며, 정말 없애고 싶지 않음. 복잡하긴 하지만, 더 많은 개인이 자기 웹사이트에서 재미있는 일을 할 수 있게 해주므로 오히려 좋은 점이라고 봄 - 동의함. 선택적 저자 스타일을 금지하기 전에 더 조사해봐야 함
스타일과 부피 큰 페이지를 제거하면 표시를 바꾸는 스크립트 필요가 줄어들 것 같다는 감각도 비슷함. 단순한 문법이 있으면 상호작용형 네이티브 프로그램 안에 “문서”를 임베드할 수 있고, 그 반대가 아니게 될 수도 있음
- 그게 원래 CSS 캐스케이드의 핵심이었음. 책과 논문 서식에 쓸 수 있는 합리적인 CSS 부분집합이 있고, 사용자 스타일과 병합되도록 되어 있었음
-
다른 사람들이 말하듯 Gemini는 참고할 좋은 예라고 봄. 다시 말하지만 Gemini는 퍼포먼스 아트 같지만, 배울 점이 정말 많음
Gemini에서 충분히 알려지지 않은 주목할 기능 하나는 구독 가능한 페이지임. 페이지 안에서 텍스트가YYYY-MM-DD로 시작하는 링크들이 암묵적 피드를 이룸. 매우 제한적이고 멍청해 보이지만, Gemini의 가장 인상적인 기능 중 하나라고 봄. Spec here
전통적인 HTML에서는 블로그를 손으로 쓰는 게 가능함. 지루하긴 해도 충분히 할 수 있음. 하지만 RSS/ATOM 피드를 유지하려면 거의 반드시 피드 생성 도구가 필요함
차세대 “콘텐츠 지향” HTML이라면 비슷한 기능을 넣는 게 좋음. 아마h-feedin microformats가 맞는 방식일 수도 있지만, Gemini의 구독 가능한 페이지가 주는 단순함이 정말 좋음. 그리고 어디에나 있는 피드는 좋은 것임
Gemini가 줄 단위이고 파싱하기 쉬운 것은 큰 장점이지만, 너무 제한적이고 접근성 측면에서 나쁜 영향을 줄 수도 있다고 느낌. 그래도 Gemini처럼 보이는 HTML-lite가 있다면 괜찮을 듯함
웹 포크가 얻을 수 있는 또 다른 이점은 HTML에 덧붙여진 부분들을 정리하는 것임.<meta name="viewport" content="width=device-width, initial-scale=1.0"/>는 꽤 거슬림. 오늘날 아는 것을 바탕으로 새 버전을 만들면 꽤 괜찮을 가능성이 큼
다른 부분은 확신이 덜함. 원칙적으로는 JS 없음에 완전히 찬성함. 다만 웹의 최고 활용 중 하나는 정부, 은행 같은 필수 서비스에 대한 범용 접근이라고 봄. 좋은 사용성을 유지하면서 정말 모든 것을 JS 없이 할 수 있을지는 아직 완전히 확신하지 못하겠지만, 가능할 수도 있음
another comment의 “이 명세가 일반 웹 브라우저 실행을 막는 건 아니고, 지금의 웹이 사라지는 것도 아니다”라는 부분도 강조하고 싶음
“콘텐츠 웹 브라우저”와 “앱 브라우저”를 따로 실행할 수 있으면 좋겠음. 많은 목적에서 앱 플랫폼으로서 웹만큼 좋은 대안은 많지 않고, 웹은 많이 발전했으며 개발자들도 다른 것보다 웹을 훨씬 선호하는 듯함
이런 세상에서는 Google Maps가 내 콘텐츠 웹 브라우저에서 동작하지 않고 앱 브라우저에서 열릴 것임. GMail을 앱 브라우저에서 실행하면 이메일 안의 링크는 콘텐츠 웹 브라우저에서 열리게 됨
콘텐츠 웹 브라우저는 이상적으로 훨씬 구현하기 쉬워야 하고, 그러면 경쟁과 혁신이 촉진될 것임. 하지만 이를 실현할 경로는 잘 보이지 않아 아쉬움. 그런 콘텐츠 브라우저로 모든 콘텐츠 탐색을 할 수 있다면 훨씬 행복할 듯함. 공격 표면이 훨씬 작아져 보안 면에서 더 편안할 테니까. 하지만 이제 아무도 신경 쓰지 않는 것 같음- 웹페이지에서 JS의 정당한 사용 사례는 거의 전부 브라우저에 중요한 기능이 빠져 있어서 생김. 수십 년 동안 배워 왔고, 스크립트 덕분에 브라우저는 그 기능들을 굳이 추가하지 않아도 됐음
그러니 그냥 브라우저 기능으로 추가하면 됨
- 웹페이지에서 JS의 정당한 사용 사례는 거의 전부 브라우저에 중요한 기능이 빠져 있어서 생김. 수십 년 동안 배워 왔고, 스크립트 덕분에 브라우저는 그 기능들을 굳이 추가하지 않아도 됐음
-
Gemini와 조금 비슷하게 들리지만, 이 포크는 좀 더 많은 것을 허용할 듯함
웹사이트는 Markdown 변형이나 비슷한 무언가로 쓸 수 있다고 봄. 원시 형태로도 쉽게 읽을 수 있는 문서여야 함. Gemtext에 인라인 미디어 같은 기능을 조금 더한 형태 말임
그리고 약간의 스타일 기능도 허용해야 함. 웹은 창의성을 발휘하기에 훌륭한 장소였고 지금도 그럼. 단순하고 일관된 스타일 집합을 유지하면 창의적인 사람들이 더 기발한 사이트를 만들 수 있음 -
HTMX의 기본 요소도 다루면 좋겠음
- 개인적으로는 Triptych 원시 기능만 내장하면 좋겠음. 클라이언트를 과도하게 복잡하게 만들지 않으면서 서버 측에서 빌드하기에 충분한 정도를 제공함
-
이 아이디어는 명확한 동기가 있으면 더 잘 작동할 것임. “단순하게 만들자”는 너무 추상적임. 사람마다 단순함에 대한 생각이 다르기 때문에, 왜 웹이 더 단순해야 하는지, 어떤 구체적 필요를 충족하는지 더 명시적인 목표가 필요함
예를 들어 Gemini 프로젝트는 특정한 형태의 소통을 중시하는 커뮤니티를 만드는 데 초점을 둠. 그 커뮤니티의 목표에 맞기 때문에 웹을 그 소통 형식으로 제한해 단순화했고, 이미지조차 기술적으로는 지원하지 않는 것으로 기억함
반면 Sciter나 Blitz 같은 도구는 다른 애플리케이션에 브라우저 비슷한 렌더러를 더 쉽게 임베드하는 것을 목표로 함. 이들은 불필요한 특이 동작을 제거하거나 HTML 파싱, JS 실행을 선택 사항으로 만들어 단순화함. 그러면 구현할 것도 줄고 사용자가 임베드할 것도 줄어듦
둘 다 단순함을 목표로 하지만, 근본 목표가 매우 다르기 때문에 결과도 매우 달라짐. 여기서의 근본 목표는 무엇인가?