"웹사이트 명세서"라는 농담 같지만 진지한 프로젝트, 우리가 잊고 있던 웹의 본질을 묻다

갑자기 등장한 "웹사이트 명세서"

최근 개발자 커뮤니티에서 흥미로운 사이트 하나가 회자되고 있어요. 이름이 무려 "The Website Specification(웹사이트 명세서)"인데요. 도메인 이름도 그냥 specification.website 입니다. RFC 문서처럼 격식 있는 형식으로, 마치 IETF나 W3C가 발표한 표준 문서처럼 보이는데 막상 읽어보면 "웹사이트란 무엇인가"를 다시 정의하려는 일종의 선언문에 가까워요.

이게 왜 지금 나왔을까요? 요즘 웹사이트들을 한번 떠올려 보세요. 단순한 블로그 글 하나 읽으려고 들어갔는데 자바스크립트 번들이 2MB씩 다운로드되고, 쿠키 동의 팝업이 화면을 가리고, 뉴스레터 구독 모달이 튀어나오고, 스크롤하면 광고가 따라붙고... 어느 순간부터 "웹사이트"라는 단어가 가리키는 게 점점 무거워지고 복잡해졌거든요. 이 명세서는 그런 흐름에 일종의 풍자 섞인 반박을 던지는 거예요.

이 문서가 말하는 "웹사이트의 정의"

명세서의 핵심 주장은 의외로 단순합니다. 웹사이트는 본질적으로 HTML 문서들의 모음이어야 한다는 거예요. 사용자가 URL을 입력하면 서버가 HTML을 돌려주고, 브라우저가 그걸 렌더링하면 끝. 그 외의 모든 것 — 자바스크립트 프레임워크, SPA(Single Page Application, 한 페이지에서 모든 화면 전환을 자바스크립트로 처리하는 방식), 클라이언트 사이드 라우팅, 무거운 트래킹 스크립트 — 은 "웹사이트"가 아니라 "웹 애플리케이션"의 영역이라고 선을 긋습니다.

문서는 RFC 2119에서 쓰는 MUST(반드시), SHOULD(권장), MAY(선택) 같은 키워드를 그대로 차용해서 진지한 척 규정을 나열해요. 예를 들면 "웹사이트는 자바스크립트 없이도 핵심 콘텐츠를 보여줘야 한다", "링크는 진짜 a 태그여야 하고 클릭 핸들러로 만든 가짜 링크는 안 된다", "폼은 자바스크립트 없이도 동작해야 한다" 같은 식으로요. 읽다 보면 웃음이 나면서도 "어... 맞는 말인데?" 싶어지는 묘한 매력이 있습니다.

특히 인상적인 건 접근성(Accessibility)과 점진적 향상(Progressive Enhancement) 을 거의 신조처럼 다룬다는 점이에요. 점진적 향상이 뭐냐면, 일단 가장 기본적인 HTML로 모든 사람이 쓸 수 있게 만들고 그 위에 CSS로 디자인을 얹고, 그 위에 자바스크립트로 부가 기능을 더하는 방식이거든요. 자바스크립트가 깨져도, 느린 네트워크여도, 스크린리더를 쓰는 사용자여도 콘텐츠는 무조건 닿아야 한다는 철학이죠.

왜 지금 이런 이야기가 나오는가

사실 이 명세서는 단독으로 등장한 게 아니에요. 최근 몇 년간 "웹이 너무 무거워졌다"는 반성이 꾸준히 있었어요. HTMX가 자바스크립트 프레임워크 대신 HTML 속성만으로 동적 동작을 만들자고 제안했고, 11ty(Eleventy)나 Astro 같은 정적 사이트 생성기가 "꼭 필요한 자바스크립트만 보내자"는 아일랜드 아키텍처를 들고 나왔습니다. Maciej Cegłowski의 "The Website Obesity Crisis" 강연부터 이어진 "웹 비만 위기" 담론의 연장선이라고 볼 수 있어요.

반대편에는 React, Next.js, Vue 같은 거대한 생태계가 있죠. 이쪽은 "사용자 경험을 위해 복잡함은 어쩔 수 없다"는 입장이에요. 인터랙티브한 대시보드나 협업 도구를 만들려면 SPA 방식이 필요하니까요. 그래서 이 두 진영은 항상 평행선을 달려왔는데, 최근 들어 후자 진영 안에서도 "우리 너무 멀리 온 거 아닌가" 하는 자성이 늘고 있어요. Next.js의 서버 컴포넌트도, Remix의 폼 기반 접근도 결국 "웹의 기본기로 돌아가자"는 흐름의 일부입니다.

한국 개발자에게는 어떤 의미인가

한국 웹 개발 현장은 솔직히 SPA와 React가 거의 표준처럼 자리 잡았어요. 신입 채용 공고만 봐도 React, Next.js, TypeScript가 거의 기본 옵션이고요. 그래서 "HTML만으로 웹사이트를 만들자"는 이야기가 좀 비현실적으로 들릴 수 있어요. 하지만 이 명세서를 단순히 "옛날로 돌아가자"는 복고 운동으로 받아들이면 핵심을 놓치는 거예요.

진짜 메시지는 "우리가 만드는 게 진짜 웹 애플리케이션이 맞는지 한번 점검해보자" 라는 거거든요. 회사 소개 페이지, 블로그, 랜딩 페이지, 문서 사이트처럼 콘텐츠 중심인 사이트를 굳이 Next.js로 만들고 클라이언트 하이드레이션까지 돌릴 필요가 있을까요? 검색 엔진 최적화도, 첫 로딩 속도도, 접근성도, 단순한 정적 HTML이 훨씬 유리한 경우가 많아요. 사이드 프로젝트 시작할 때 "create-next-app"부터 치는 습관 한번쯤 의심해볼 만합니다.

또 하나는 점진적 향상 사고방식을 익혀두는 것의 가치예요. 폼 하나를 만들더라도 자바스크립트가 죽었을 때 동작하는지, 키보드만으로 조작 가능한지, 스크린리더가 제대로 읽는지를 한 번 더 생각하는 습관이 결국 좋은 프로덕트로 이어집니다.

마무리

이 명세서는 진짜 표준 문서가 아니라 일종의 선언문이자 거울이에요. 우리가 만드는 "웹사이트"가 사실은 무거운 "웹 앱"이 된 건 아닌지, 사용자에게 정말 필요한 복잡함인지 자문해보게 만드는 거울이요. 한 줄로 정리하자면 "웹의 기본은 여전히 HTML이고, 그걸 잊지 말자" 는 메시지입니다.

여러분은 어떻게 생각하세요? 최근에 만든 프로젝트 중에 사실은 HTML과 약간의 자바스크립트만으로 충분했는데 과하게 프레임워크를 끌어다 쓴 적이 있나요? 아니면 "그래도 DX(개발자 경험) 때문에 React는 양보 못 한다"는 입장이신가요?