콘텐츠 사이트 디자인은(는) 무엇을 하나요?

콘텐츠 사이트는 독자가 페이지를 찾고, 올바른 페이지인지 확인하고, 원하는 답이나 이해를 얻고, 다음 작업으로 넘어가기 위해 존재합니다. 대부분의 독자는 검색을 통해 깊은 페이지로 들어오고, 읽기 전에 훑어보며, 필요한 것을 얻으면 떠납니다. 모델이 흔히 저지르는 실수는 껍데기(히어로, 카드, 사이드바, 다크모드 토글)만 디자인하고 콘텐츠 자체의 구조(모호한 제목, 아무것도 알려주지 않는 헤딩("개요", "소개"), 세 번째 문단에나 나오는 답변, 튜토리얼과 레퍼런스와 의견이 섞인 페이지, "여기" 같은 링크 텍스트, 날짜 없음, 아무 쓸모 없는 사이트 검색)를 소홀히 하는 것입니다.

interface-guidelines의 우선순위 원칙(모두가 사용할 수 있어야 한다 > 진실을 말해야 한다 > 의도한 대로 전달되어야 한다 > 답변이 먼저 나와야 한다 > 실수가 치명적이지 않아야 한다 > 요소가 제자리에 있어야 한다 > 가능한 것이 보여야 한다 > 관행을 따라야 한다 > 세련되어야 한다)을 적용하세요. 해당 스킬이 설치되어 있다면 먼저 SKILL.md를 읽으세요. 본문 글꼴 크기, 줄 길이, 대비, 리플로우는 거기(references/human-interface.md 섹션 6과 7)에서 다룹니다. 이 스킬은 콘텐츠 구조, 탐색, 검색, 그리고 AI 에이전트 독자를 다룹니다.

브리프

사이트 종류: 문서, 도움말 센터, 지식 베이스, 에디토리얼/블로그, 또는 혼합. 혼합 사이트는 섹션별로 주요 작업을 명시합니다.
독자와 방문 경로: 검색을 통해 깊은 페이지로, 제품 내부("?" 링크)에서, 브라우징, 또는 구독. 신규 사용자와 전문가는 누구인가요?
최우선 작업: 독자가 가져오는 10~20개의 질문을 독자의 언어로 정리합니다. 검색 로그, 고객 지원 티켓, 포럼 게시글에서 가져오고, 조직도에서는 가져오지 마세요.
콘텐츠 유형: 문서의 경우 튜토리얼, 하우투, 레퍼런스, 설명 중 무엇인지; 에디토리얼의 경우 뉴스, 분석, 의견, 가이드 중 무엇인지.
최신성: 콘텐츠가 얼마나 자주 변경되는지, 각 페이지의 소유자, 제품 버전이 변경될 때 어떻게 처리할지.
AI 에이전트 독자: 문서를 읽는 코딩 에이전트, 페이지를 인용하는 검색/답변 엔진, 탐색하는 브라우저 에이전트. 이들이 정확히 수행해야 하는 것은 무엇인가요?
작성자: 직원만 작성하는지, 아니면 사용자(댓글, 커뮤니티 답변)도 작성하는지? 외부 작성 콘텐츠는 표시합니다.

규칙

태그: [E] 경험적, [S] 표준 또는 제도적, [P] 실무자, [J] 판단. 출처는 참조 파일에 있습니다.

페이지

답변을 먼저 제시하세요. 처음 두 문단에 핵심 내용을 담고, 세부 사항은 중요도가 내림차순으로 이어집니다(역피라미드 구조) [S: GOV.UK; P: NN/g]. 독자는 페이지 단어의 일부만 읽으며, Nielsen은 약 20~28%로 추정했습니다 [P: Nielsen 2008, Weinreich et al. 2008 데이터 기반].
한 페이지, 한 작업. 튜토리얼은 가르치고, 하우투 가이드는 안내하며, 레퍼런스는 설명하고, 설명은 논의합니다. 한 페이지에 섞지 마세요 [P: Procida, Diátaxis].
제목은 고유하고, 구체적이며, 핵심을 앞에 배치하고, 독자의 언어로 작성하며, 검색 결과에서 잘리지 않도록 약 65자 이하로 만듭니다 [S: GOV.UK]. 작업 페이지는 동사로 시작하고("API 키 회전"), 작업에 대한 안내는 -ing 형태를 사용합니다("API 키 회전하기") [S: GOV.UK].
제목 아래에 한 문장 요약을 160자 이하로 추가하여 제목에 없는 단어를 보충합니다. 이 텍스트는 메타 설명으로도 사용됩니다 [S: GOV.UK].
헤딩은 해당 섹션의 내용을 말하며, 핵심을 앞에 배치하고, "개요"나 "추가 정보"가 아니며, 질문 형태로 작성하지 않습니다. 헤딩을 제거해도 내용이 여전히 이해되어야 합니다 [S: GOV.UK]. 헤딩 수준은 구조를 따릅니다: 하나의 h1, 건너뛴 수준 없음 [S: WCAG 1.3.1, 2.4.6].
짧은 문장과 문단, 평이한 단어. 약 25단어가 넘으면 문장을 나누고, 문단은 5문장 이하로 유지하며, 전문 용어는 처음 사용 시 설명합니다 [S: GOV.UK]. 독자를 "당신"으로 지칭하고, 능동태를 사용하며, 조건을 먼저 제시한 후 지시합니다("프로젝트를 삭제하려면 설정을 여십시오") [S: Google 개발자 스타일 가이드].
단계에는 번호 목록, 집합에는 글머리 기호, 비교에는 표를 사용합니다 [S: Google 개발자 스타일 가이드; GOV.UK].
훑어보기에 최적화: 의미 있는 헤딩과 앞부분에 핵심을 배치하여 F자형 스캔(독자가 페이지의 오른쪽과 아래쪽을 건너뛰는 현상)에 대응합니다 [P: Pernice, NN/g 2017].
의미 있는 날짜: "마지막 업데이트: 2026년 11월 4일"과 함께 실질적인 변경 사항에 대한 간단한 변경 노트, 기사에는 발행일. 정확하지만 오래된 페이지는 "검토됨"으로 표시합니다 [S: GOV.UK 변경 노트; J].
각주: GOV.UK는 서비스 콘텐츠에서 각주를 금지합니다. 학술 및 장문 에디토리얼에서는 필요할 수 있습니다. 독자가 출처를 확인해야 하는지 여부로 결정합니다 [S: GOV.UK; J].

링크

링크 텍스트는 목적지를 명명하며, 핵심을 앞에 배치하고 페이지 내 목적지별로 고유해야 합니다. "여기를 클릭", "더 보기", "여기"는 절대 사용하지 마세요 [S: GOV.UK, WCAG 2.4.4].
링크가 사이트를 벗어나거나, 파일을 열거나, 언어를 변경하는 경우 명시하세요: "가격표(PDF, 240KB)" [S: GOV.UK].
링크는 도움이 되는 곳에 배치하고, 페이지 하단에 "추가 자료"로 모아두지 마세요. 작업 페이지 끝의 다음 단계는 구체적일 때 괜찮습니다 [S: GOV.UK].
모든 헤딩에는 안정적인 앵커(#rotate-a-key)가 있으며, 보이는 복사-링크 컨트롤이 있어야 합니다. 헤딩 이름을 바꾸면 이전 앵커도 계속 작동하도록 유지합니다 [J].
URL은 읽을 수 있고 영구적이어야 합니다. 페이지가 이동하면 이전 URL을 리디렉션하고, 문서 링크가 404가 되지 않도록 하세요 [J].

탐색

독자는 깊은 페이지로 바로 들어옵니다. 모든 페이지는 현재 위치(브레드크럼 또는 강조 표시된 섹션)와 다음 및 인접 내용을 보여줍니다 [S: WCAG 2.4.8; P: NN/g 브레드크럼].
탐색 레이블은 독자의 언어를 사용하고 내용을 예측하게 합니다 (정보 단서) [E: Pirolli and Card 1999].
페이지에 도달하는 방법은 최소 두 가지: 탐색 + 검색, 또는 사이트맵 [S: WCAG 2.4.5].
긴 페이지를 위한 페이지 내 목차는 h2와 h3에서 생성되며, 현재 섹션을 강조 표시합니다 [J].
아카이브 및 검색 결과에는 무한 스크롤 대신 페이지 매기기 또는 "더 보기"를 사용하여 독자가 푸터에 도달하고, 위치로 돌아오고, 위치를 공유할 수 있도록 합니다 [P: NN/g 무한 스크롤].
문서: 독자 작업 및 Diátaxis 유형별로 구성된 하나의 사이드바, 버전이 다른 경우 보이는 버전 전환기, 이전 버전 페이지에 현재 페이지로 연결되는 배너 [P: Procida; J].

검색

검색은 주요 경로이지 부가 기능이 아닙니다. 검색 상자는 모든 페이지에서 볼 수 있어야 하며, 데스크톱에서 아이콘 뒤에 숨겨져 있으면 안 됩니다 [P: NN/g; J].
결과는 페이지 제목, 섹션 또는 유형, 일치하는 단어가 포함된 스니펫, 날짜를 표시합니다. 실제 쿼리의 오타와 동의어를 허용합니다 [J].
결과 없음 페이지는 철자 수정, 더 넓은 용어, 인기 페이지를 제안하고 쿼리를 기록합니다 [J].
매달 결과 없음 쿼리와 상위 쿼리를 검토하세요. 각각은 누락된 페이지, 누락된 동의어, 또는 잘못된 제목을 나타냅니다 [P: 일반적인 문서 관행; J].

읽기 편의성

본문 글꼴, 치수, 줄 높이, 대비, 리플로우는 기본 원칙을 따릅니다. 휴대폰에서는 독자가 짧고 간단한 텍스트를 데스크톱만큼 잘 이해하지만 어려운 텍스트에서는 속도가 느려지므로, 어려운 콘텐츠는 모바일에서 추가 구조가 필요합니다 [P: Moran, NN/g 2016].
텍스트를 가리는 전면 광고나 고정 요소가 없어야 합니다. 광고와 뉴스레터 프롬프트는 답변의 첫 화면을 방해하지 않아야 합니다 [S: WCAG 2.4.11 초점; J].
정보를 전달하는 이미지에는 정보를 설명하는 대체 텍스트가 있어야 합니다. 장식용 이미지에는 빈 대체 텍스트를 사용합니다 [S: WCAG 1.1.1]. 다이어그램에는 근처에 텍스트 설명이 있어야 합니다 [J].
코드 샘플은 텍스트여야 하며, 이미지가 아니어야 합니다. 복사 컨트롤과 언어 레이블이 있어야 합니다. 언어 변형을 위한 탭은 모든 변형을 DOM에 유지합니다 [J].
인쇄 및 리더 모드는 탐색 크롬 없이 콘텐츠를 생성합니다 [J].

에이전트용

콘텐츠는 HTML에 있어야 하며, 서버에서 렌더링되어야 하고, 로드 후 클라이언트 JavaScript로 조합되지 않아야 합니다. 그래야 스크립트를 실행하지 않는 크롤러와 에이전트가 콘텐츠를 가져올 수 있습니다 [J].
시맨틱 구조가 인터페이스입니다: 헤딩, 목록, 표, 언어 클래스가 있는 code와 pre, figure와 figcaption [S: WCAG 1.3.1].
안정적이고 인용 가능한 URL과 앵커, 페이지별 표준 URL, 페이지의 날짜 [J].
각 문서 페이지의 깔끔한 Markdown 사본을 동일한 URL에 .md를 추가하여 제공하고, rel="alternate" type="text/markdown"으로 링크하면 코딩 에이전트에게 크롬 없이 콘텐츠를 제공하는 저렴한 방법입니다. 사이트 또는 문서 루트의 llms.txt는 커뮤니티 제안입니다. 일반 사이트에서는 수요가 낮은 것으로 측정되었지만, 코딩 에이전트가 읽는 문서에는 적합합니다 [P: Howard, llms.txt; 기초 에이전트 표면 섹션 6].
페이지 텍스트, 주석, 보이지 않는 요소에 에이전트를 위한 숨겨진 지시사항이 없어야 합니다. 이는 프롬프트 인젝션과 구분할 수 없습니다 [J; 기초 감독 섹션 5].
사용자 생성 콘텐츠(댓글, 커뮤니티 답변, 포럼 게시글)는 마크업과 시각적으로, 작성자와 날짜와 함께 표시되어 에이전트와 사람이 가치를 평가할 수 있도록 합니다 [J].

구축 순서

최우선 작업 및 콘텐츠 인벤토리: 각 기존 또는 계획된 페이지에 유형, 소유자, 마지막 검토일, 제공하는 작업을 기록합니다. 작업을 제공하지 않는 페이지는 삭제하거나 병합합니다.
정보 아키텍처: 독자 작업과 콘텐츠 유형에서 섹션을 도출하고, 독자의 언어로 레이블을 지정하며, 트리 테스트(사람들이 텍스트 전용 트리에서 다섯 가지 작업을 찾는 것)로 레이블을 테스트합니다 [P: NN/g 트리 테스팅].
콘텐츠 유형별 페이지 템플릿: 제목, 요약, 날짜, 본문 구조, 다음 단계. 문서의 경우: 튜토리얼, 하우투, 레퍼런스, 설명 템플릿(references/docs.md).
최우선 작업 페이지를 먼저 작성하거나 재작성합니다(references/writing.md 사용). 완전하고 좋은 페이지 하나가 스무 개의 빈 페이지보다 낫습니다.
시맨틱 HTML 셸: 랜드마크, 스킵 링크, 브레드크럼, aria-current가 있는 nav 사이드바, 페이지 내 목차, 푸터. 서버 렌더링.
검색: 로그 또는 최우선 작업 목록의 실제 쿼리로 검색을 구현하고, 동의어를 조정합니다.
에이전트 계층: 표준 URL, 앵커, Markdown 사본, 사이트맵, 선택적 llms.txt.
장시간 읽기를 위한 스타일링: 브랜드가 디자인을 소유합니다(brand-identity).
확인 (아래).

확인

렌더링 감사를 홈 페이지, 긴 기사 또는 레퍼런스 페이지, 검색 결과 페이지, 404 페이지에서 수행합니다:
```
node <interface-guidelines>/scripts/audit.mjs <dist-or-url> --out audit-output
```
최우선 작업 테스트: 각 최우선 작업에 대해 검색 엔진 쿼리 또는 홈 페이지에서 시작하여 답변에 도달합니다. 단계를 세고 정보 단서가 실패한 위치를 기록합니다. 사람이 키보드로 휴대폰 너비에서 한 번, 접근성 스냅샷만으로 에이전트로서 한 번 수행합니다.
콘텐츠 린트를 모든 페이지에서 수행합니다(references/writing.md 섹션 8에 스크립트 개요 있음): 하나의 h1; 건너뛴 헤딩 수준 없음; 제목이 고유하고 65자 이하; 요약이 있고 160자 이하; 일반적인 헤딩이나 링크 텍스트 없음("개요", "여기를 클릭", "더 보기"); 25단어 초과 문장 플래그; 누락된 대체 텍스트 이미지; 마지막 업데이트 날짜 있음.
링크: 깨진 내부 링크와 누락된 앵커를 크롤링하고, 이전 URL이 리디렉션되는지 확인합니다.
JS 없음 확인: curl로 페이지를 가져와 주요 콘텐츠와 헤딩이 HTML에 있는지 확인합니다.
검색: 상위 20개 쿼리와 5개의 오타를 실행합니다. 올바른 페이지가 상위 3개 안에 있어야 합니다.
에이전트 읽기: 에이전트에게 문서 페이지의 URL 또는 .md 사본만 제공하고 작업을 수행하도록 요청합니다. 현재 버전을 따르고 올바른 섹션 앵커를 인용하는지 확인합니다.

함정

문서 홈을 기사 미리보기 카드 그리드로 만들고 작업 진입점이나 검색이 없는 경우.
"소개", "개요", "세부 사항"으로 명명되거나 질문 형태로 작성된 헤딩.
관련 없는 질문을 모아서 답변하는 FAQ 페이지. 대신 질문이 발생하는 페이지에서 답변해야 합니다.
주제가 중요한 이유에 대한 긴 서문 아래에 답변이 묻혀 있는 경우.
중간에 레퍼런스로 바뀌는 튜토리얼, 또는 의견으로 덧칠된 레퍼런스.
날짜가 없는 기사, 모든 페이지의 "마지막 업데이트"가 빌드 날짜로 설정된 경우.
클라이언트 JavaScript로만 렌더링되는 콘텐츠, 숨겨진 패널이 DOM에 없는 탭, 스크린샷으로 제공되는 코드.
아카이브와 검색 결과의 무한 스크롤.
페이지에 숨겨진 AI 크롤러용 지시 텍스트.
제목, 헤딩, 검색이 여전히 고장난 상태에서 문서 사이트를 다시 스타일링하는 경우.

참조

파일	다음 경우에 읽으세요
`references/writing.md`	페이지 작성 또는 편집: 제목, 요약, 헤딩, 문장, 링크, 날짜, 숫자, 에디토리얼 세부 사항, 린트 개요
`references/docs.md`	문서 및 도움말 센터: 템플릿이 있는 Diátaxis 유형, API 레퍼런스 페이지, 코드 샘플, 버전, 체인지로그, 코딩 에이전트용 문서
`references/navigation-search.md`	사이트 구조, 레이블, 사이드바, 브레드크럼, 목차, 아카이브, 검색 결과, 404

콘텐츠 사이트 디자인