# The Website Specification

> Clean Markdown view of GeekNews topic #30066. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30066](https://news.hada.io/topic?id=30066)
- GeekNews Markdown: [https://news.hada.io/topic/30066.md](https://news.hada.io/topic/30066.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-01T09:55:58+09:00
- Updated: 2026-06-01T09:55:58+09:00
- Original source: [specification.website](https://specification.website/)
- Points: 4
- Comments: 1

## Topic Body

- 좋은 웹사이트가 갖춰야 할 기술 기능을 플랫폼과 무관하게 정리한 명세로, `&lt;title&gt;`부터 `llms.txt`까지 다룸  
- 사람과 **에이전트**를 모두 대상으로 하며 WHATWG, W3C, IETF RFCs, WCAG, MDN 등 현대 웹 표준을 레퍼런스  
- WordPress, Next.js, Django 앱, 순수 HTML 등 배포 방식과 관계없이 **명세 자체는 동일**하며 구현 힌트도 포함  
- 전체 주제는 Foundations, SEO, Accessibility, Security, Performance 등 **10개 영역**으로 나뉘고 널리 수용된 표준에 매핑됨  
- 공개 **MCP 서버**, Agent Skill, `/llms.txt`, Markdown 응답을 제공해 에이전트와 운영자가 감사·학습·개선 흐름에 활용 가능  
  
---  
  
### 좋은 웹사이트를 위한 플랫폼 독립 명세  
- **The Website Specification**은 좋은 웹사이트가 갖춰야 할 기술 기능을 플랫폼과 무관하게 정리한 명세로, `&lt;title&gt;`부터 `/.well-known/security.txt`, WCAG 대비, `llms.txt`까지 다룸  
- 사람과 에이전트를 모두 대상으로 하며, 각 주제는 **WHATWG, W3C, IETF RFCs, WCAG, MDN** 등 현대 웹 표준 출처와 연결됨  
- WordPress, Drupal, TYPO3, Next.js, Astro, Hugo, Django 앱, 순수 HTML 등 어떤 방식으로 배포하든 **명세 자체는 동일**하고, 구현 힌트는 그 뒤에 붙음  
- 모든 페이지에 [Edit on GitHub](https://github.com/jdevalk/specification.website) 링크가 있으며, PR을 받을 수 있고 각 페이지에는 출처가 표시됨  
- ## 다루는 영역  
  - [전체 주제](https://specification.website/spec/)는 널리 수용된 표준에 매핑된 10개 영역으로 나뉨  
  - **Foundations**: 14개 항목으로 HTML, head, 문서 기본 요소를 다룸  
  - **SEO**: 13개 항목으로 `robots.txt`, 사이트맵, canonical, 구조화 데이터 등 검색 노출 요소를 포함함  
  - **Accessibility**: 20개 항목으로 모든 능력의 사용자가 사이트를 쓸 수 있도록 WCAG 기반 규칙을 제시함  
  - **Security**: 12개 항목으로 방문자를 안전하게 보호하는 헤더, 전송, 정책을 다룸  
  - **Well-Known URIs**: 9개 항목으로 `/.well-known/` 아래의 표준 합의 경로를 정리함  
  - **Agent Readiness**: 18개 항목으로 AI 에이전트와 크롤러가 사이트를 읽을 수 있게 하는 요소를 다룸  
  - **Performance**: 19개 항목으로 Core Web Vitals, 캐싱, 이미지, 폰트, 네트워크 동작을 포괄함  
  - **Privacy**: 6개 항목으로 동의, 신호, 방문자 선택 존중을 다룸  
  - **Resilience**: 5개 항목으로 오류 페이지, 오프라인, 리디렉션 같은 우아한 실패를 다룸  
  - **Internationalisation**: 12개 항목으로 언어, 로케일, 방향, 번역 콘텐츠를 다룸  
  
### 에이전트와 사이트 운영자를 위한 사용 방식  
- 전체 명세는 읽기 전용·인증 없는 공개 [MCP](https://modelcontextprotocol.io/) 서버로 제공됨  
- 호환 에이전트가 언제 어떻게 명세를 사용할지 알려주는 [Agent Skill](https://specification.website/.well-known/agent-skills/specification-website/SKILL.md)이 게시되어 있음  
- 각 명세 URL은 `/llms.txt`와 `Accept: text/markdown`을 통해 페이지별 Markdown을 제공함  
- MCP 서버 설정 예시는 다음과 같음  
```json  
{  
  "mcpServers": {  
    "specification-website": {  
      "transport": "http",  
      "url": "https://mcp.specification.website/mcp"  
    }  
  }  
}  
```  
- ## 사용 흐름  
  - **Audit**: [체크리스트](https://specification.website/checklist/)를 훑으며 각 항목을 “사이트가 이것을 하는가 — 예/아니오”로 확인함  
  - **Learn**: 각 항목에서 그것이 무엇인지, 왜 중요한지, 어떻게 구현하는지 확인함  
  - **Improve**: 빠진 부분, 오래된 사실, 누락된 주제를 찾으면 출처를 붙여 PR을 열 수 있음

## Comments



### Comment 58696

- Author: neo
- Created: 2026-06-01T09:55:59+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48343683) 
- **Agent Readiness**는 "Web 4.0 Blockchain Integration"처럼 시간이 지나면 민망해질 가능성이 큼  
  에이전트가 의미 없어질 거라서가 아니라, 설령 중요해져도 사이트가 에이전트용 예외 처리를 해줘야 한다면 본래 취지를 해침  
  결국 악의적 행위자가 에이전트가 보는 것과 사람이 보는 것을 다르게 만드는 데 쓰일 테고, 그래서 의도적으로 무시될 것 같음
  - 2000년대로 돌아가고 싶음. 그때는 기본이 그냥 **순수 HTML**과 약간의 CSS였고, 브라우저 기본 스타일시트만으로도 반응형에 가까운 레이아웃, 읽기 쉬운 텍스트, 사용자 친화적인 GUI가 나왔음  
    요즘 웹사이트는 모든 게 컴포넌트임. 유한한 목록을 가진 단순 드롭다운 하나에도 자체 로더가 있고 이유 없이 fetch 요청을 10번 날림. 과장이 아니라 Instagram과 Facebook 웹을 보면 됨  
    이런 명세들은 다 집어치우고, 새 JS 프레임워크가 판을 바꿀 거라고 우기는 React 같은 것들로 난독화되지 않은 원본 HTML이나 줬으면 함
  - 처음엔 반박하려 했지만 더 생각해보니 결론엔 동의함. 다만 이유는 조금 다름  
    웹은 기본적으로 **적대적 환경**이고, 웹사이트를 운영하는 쪽 상당수가 스스로 악의적 행위자라고 봄. 사람이 보는 것과 에이전트가 보는 것을 다르게 만드는 일은 검색엔진에 하던 것처럼 웹사이트들이 의도적으로 쓸 것임  
    "Agent Readiness"가 오래가지 못할 이유는 사이트 운영자들이 곧 에이전트가 사실상 **접근 자동화**라는 걸 떠올릴 것이기 때문임. 그건 그들이 계속 싸워온 대상이고, 수익화 능력을 위협함
  - 웹사이트가 이렇게 비대해지고 광고투성이가 된 걸 보면, 사람에게도 **순수 텍스트 버전**이 있으면 좋겠음. 에이전트가 사람용 복잡한 걸 처리하게 두고 싶음  
    다만 실제로 그렇게 될지는 의심스러움. 악의적 행위자 문제는 오래전부터 가능했음. 예를 들어 검색엔진 크롤러에게는 사용자 클릭 후 보이는 것과 다른 콘텐츠를 제공하는 식임. 기억이 맞다면 Google이 이런 사이트를 페널티 주던 시기도 있었음
  - 사이트의 전반적인 아이디어는 괜찮지만 AI/블록체인 헛소리는 싫다면, 이런 체크리스트는 꽤 흔함. 몇 년째 제일 좋아하는 건 이쪽임  
    [https://frontendchecklist.io/rules](<https://frontendchecklist.io/rules>)
  - Agent readiness는 완전히 도움이 되는 단계로 보임. 내 웹사이트에서 사람들은 블록체인을 쓰지 않지만 **AI**는 쓰고 있고, AI가 사람처럼 웹사이트를 사용할 필요는 없음  
    사람은 보기 좋은 웹사이트를 원하고, 순수 HTML만으로도 그럴 수 있음. 에이전트는 그것조차 필요 없고, 이상적으로는 페이지 내용을 Markdown으로만 보면 됨  
    에이전트 버전이 왜 안 되겠나? 클라이언트 에이전트와 웹사이트 호스트의 시간과 돈을 아껴줌  
    llms.txt 같은 표준으로 "에이전트는 사람이 보는 것의 원시 Markdown 버전인 이 미러를 대신 방문하라"고 지정할 수 있으면 좋겠음  
    이 사이트의 agent readiness 일부는 AI용 SEO에 해당함. 반대로 AI 크롤링을 원치 않는 사이트라면 그 반대 역할도 함

- 로그인 폼 같은 영역의 **모범 사례**가 있으면 좋겠음. 예를 들면 비밀번호 관리자가 인식하는 표준 입력 필드 이름 사용, 로그인 필드의 자동완성과 자동 대문자화 비활성화, 이메일이면 올바른 HTML5 input type 사용, 이메일만 입력시키고 다시 클릭해야 비밀번호를 입력하게 만드는 폼 피하기, NIST SP 800-53을 따라 SMS 2단계 인증이나 임의의 비밀번호 주기적 변경·조합 규칙을 피하는 것 등임  
  입력이 하나뿐인 폼에서 자동으로 포커스를 주지 않는 사이트도 너무 많음
  - Adam Silver의 블로그에서 폼 **모범 사례**를 읽는 게 꽤 재미있었음  
    [https://adamsilver.io/blog/form-design-from-zero-to-hero-all...](<https://adamsilver.io/blog/form-design-from-zero-to-hero-all-in-one-blog-post/>)  
    이후로도 새 글을 많이 올렸고, 웹에서 가장 좋은 UX 자료 중 하나일 가능성이 큼
  - 비밀번호 입력 전에 로그인 이메일만 제출하게 하는 건, 사소하지 않은 인증 시스템이라면 사실상 필요함  
    사용자를 제출받기 전까지 그 사용자가 비밀번호를 쓰는지, 아니면 다른 방식을 쓰는지 알 수 없음
  - 몇 년째 frontendchecklist를 써왔고, 이런 종류의 규칙과 모범 사례 모음이 있음. 아쉽게도 최근 사이트가 **ai-readiness**를 받아들이는 쪽으로 바뀐 듯하지만, 규칙은 여전히 남아 있음  
    [https://frontendchecklist.io/rules/html/input-types](<https://frontendchecklist.io/rules/html/input-types>)  
    UI 컴포넌트를 처음부터 만들 때는 이 사이트를 정말 좋아함  
    [https://component.gallery/](<https://component.gallery/>)  
    여러 디자인 시스템의 컴포넌트로 연결해주고, 그중 다수는 접근성, 국제화 같은 가이드라인도 깊이 있게 포함. 문서화가 특히 좋은 예로 Salesforce의 Lightning Design System과 StackOverflow의 Stacks가 있음  
    [https://www.lightningdesignsystem.com/2e1ef8501/p/99642e-car...](<https://www.lightningdesignsystem.com/2e1ef8501/p/99642e-carousel/b/74d5d4>)  
    [https://stackoverflow.design/system/forms/checkbox](<https://stackoverflow.design/system/forms/checkbox>)
  - 입력 하나뿐인 폼에 자동 포커스를 주지 않는 건, **웹 스택**이 네이티브 UI 도구킷에서는 기본이던 기능을 모든 웹사이트가 직접 구현하길 기대하는 사례임  
    그러면 대부분의 웹사이트는 우선순위로 보지 않거나 아예 고려할 항목인지도 모르고, 결국 지금 같은 상태가 됨
  - 이메일만 먼저 넣게 하는 로그인 폼이 특히 대형 기술 기업 사이트에서 늘어나는 것 같음. 개인적으로도 짜증남  
    사이트들이 이 패턴으로 바꾸는 이유가 있다고 늘 생각했음. 예를 들어 봇 방어에 더 좋다든가. 더 아는 사람이 있는지 궁금함

- 겉보기엔 거의 전부 **AI 생성물**처럼 보여서 전달 방식이 잘 먹히지 않을 수 있음. 그래도 여러 항목을 읽어보면 Agent 섹션을 제외한 나머지는 탄탄한 웹 위생을 꽤 명확히 전달하고 있어서, 이제 막 성장하는 웹 개발자에게 보내도 괜찮겠다고 봄  
  다만 사이트 자체가 자기들이 "필수"라고 한 관행조차 적용하지 않는 건 아이러니함
  - "Compression (gzip, brotli, zstd): required"와 "cache-control: required"라니, 처음부터 끝까지 **AI 찌꺼기**임

- [https://validator.w3.org/nu/?doc=https%3A%2F%2Fspecification...](<https://validator.w3.org/nu/?doc=https%3A%2F%2Fspecification.website%2F>)  
  이 웹사이트의 목표를 모르겠음. 명세라고 광고하지만, 대체 무엇을 명세한다는 건지 모르겠음  
  모든 항목이 다른 "진실의 원천"을 출처로 삼고 있음
  - **모범 사례** 모음이고, 한곳에서 보는 체크리스트로는 가치가 있음
  - LinkedIn[1]에 올라온 걸 봤는데, 작성자는 이렇게 썼음  
    "단일 권고를 뒷받침하려고 여섯 가지 출처를 가리키는 데 지쳤다. HTML은 WHATWG, 접근성은 WCAG, 헤더는 IETF, 구조화 데이터는 schema.org, 나머지는 MDN, web.dev, Google Search Central이었다  
    현대 웹사이트가 실제로 무엇을 해야 하는지에 대한 단일하고, 의견이 분명하며, 플랫폼에 중립적인 명세가 없었다  
    그래서 하나 썼다"  
    [1] [https://www.linkedin.com/posts/jdevalk_the-website-specifica...](<https://www.linkedin.com/posts/jdevalk_the-website-specification-share-7466108556518277121-bS5J/>)

- 여기에 있는 것들이 얼마나 흔한지 궁금함. **/.well-known/change-password**는 있으면 좋겠지만 [https://news.ycombinator.com/.well-known/change-password](<https://news.ycombinator.com/.well-known/change-password>)와 google.com/.well-known/change-password를 보면 구현되어 있지 않은 듯함
  - Safari와 Chrome에서는 동작하는 것으로 보임: [https://web.dev/articles/change-password-url](<https://web.dev/articles/change-password-url>)  
    실제로 쓰이는 건 들어본 적 없음  
    Google의 URL은 [https://accounts.google.com/.well-known/change-password](<https://accounts.google.com/.well-known/change-password>)에 있고, 메인 도메인에는 없음
  - security.txt는 있으면 항상 이 폴더 아래에 있음. Let's Encrypt도 인증서나 갱신 실패 관련으로 이 위치를 사용함

- 이건 **찌꺼기 공장**에서 나온 것처럼 보임. "SEO", "Agent-readiness"라니. 좋은 웹사이트가 하지 말아야 할 바로 그 일임  
  아니나 다를까, Claude LLM을 쓰는 Wordpress "SEO" 전문가이자 개인 투자자가 만든 것임. 광고 찌꺼기로 우리가 사랑하던 인터넷을 망가뜨려 부를 쌓은 사람이 이제 LLM 찌꺼기로 남은 것마저 망가뜨리려 함
  - 긴 대시와 문장 패턴, 예를 들어 "X가 아니라 Y" 같은 표현과 중복 콘텐츠를 보면 내겐 거의 **AI 생성**임이 드러남  
    "stable URLs"를 "agent readiness"로 분류한 건 작성자가 사람보다 AI를 더 신경 쓴다는 신호로 보임. 이 도메인은 차단 목록에 넣을 것임. 웹 개발 정보를 검색하는 일을 더 나쁘게 만들 게 벌써 보임
  - about 페이지([https://specification.website/about/](<https://specification.website/about/>))에는 이렇게 되어 있음  
    "프레임워크가 아니다. 가이드도 아니다. 명세다 — 무엇이 필수이고, 무엇이 권장되며, 무엇을 피해야 하는지."  
    사이트의 어느 정도가 LLM 찌꺼기인지는 말하기 어렵지만, 일부 문구는 확실히 그렇게 보임
  - 순수 **AI 찌꺼기**로 보임. 나는 [https://tropes.fyi/vetter](<https://tropes.fyi/vetter>)를 씀
  - 단일 페이지 전체 명세는 요즘 **AI 찌꺼기 웹개발**의 대표 포스터 같음  
    https://specification.website/llms-full.txt
  - 내게도 찌꺼기 신호가 켜짐  
    첫째, required, optional, recommended 같은 작은 색상 태그  
    둘째, 아무도 읽지 않을 미친 분량의 콘텐츠  
    셋째, 약한 아이디어를 고통스러울 정도로 세세하게 밀어붙인 전개

- 이런 걸 직접 만들 생각이 있었는데, 이걸 아무 에이전트 채팅에 붙여넣으니 아주 잘 동작함  
  방금 로컬 모델(**Qwen3.6 27B / pi**)로 오래된 Hugo 사이트에 빠진 필수 표준 목록을 만들고, 할 일 목록을 만든 뒤 하나씩 처리하게 했고, 각 변경은 내가 검토할 수 있게 해줬음  
  빠진 favicon도 로고에서 심볼을 잘라 만들어줬는데 꽤 괜찮게 나왔음
  - `pi`를 얼마나 만져봤는지 궁금함. 짧은 에이전트/시스템 프롬프트의 **무부하** 느낌은 좋지만, 임의의 작업을 그냥 맡기면 기다림과 막다른 길이 꽤 생길 것 같음

- MacBook에서 사이트를 열었더니 **CPU 사용률**이 50%를 넘김  
  웹사이트가 어떠해야 하는지에 대한 명세라는 점을 생각하면 꽤 아이러니함
  - 여기서는 같은 현상이 보이지 않음. 사용자 쪽에서 무슨 일이 벌어지는지 확인해보는 게 좋겠음

- 일부 내용은 꽤 좋지만, **128개 항목 체크리스트**로 표준화하는 게 사람들이 웹사이트 만드는 걸 겁내게 만들지는 않았으면 함

- 내가 제일 좋아하는 명세는 **환각된 명세**임. 잘했다고 해야 하나  
  에이전트 주도 ISO 대안이나 LLM이 운영하는 슬롯머신이 벌써 기대됨
