문서를 읽어 답하는 쪽을 위한 준비

검색이 링크 목록에서 답변으로 옮겨 가고 있습니다. 사람이 열 개의 파란 링크를 훑는 대신, 무언가가 문서를 읽고 답을 만들어 줍니다. 그 과정에 들어가려면 사이트가 읽히기 쉬워야 합니다.

세 가지가 실제로 차이를 만듭니다. 파일 하나, 구조화 데이터, 그리고 문장 쓰는 방식입니다.

1. llms.txt — 사이트를 한 장으로 설명합니다

/llms.txt 는 사이트가 무엇이고 어떤 문서가 있는지를 평문으로 적은 파일입니다. robots.txt 가 크롤러에게 규칙을 주듯, 이쪽은 문서를 읽는 쪽에 지도를 줍니다.

핵심은 각 주소가 무엇을 다루는지 한 줄로 함께 주는 것입니다. 주소만 나열한 목록은 결국 전부 크롤링하게 만듭니다.

# Shaile Wiki

> Practical notes from a studio in South Korea. Every page is written from work
> actually done on our own sites, with numbers measured rather than estimated.

## Static sites

- https://wiki.shaile.co.kr/ko/static-site/korean-webfonts/ — 한글 웹폰트 2MB 를
  300KB 로: 가변 축을 좁히고 상용 한글과 나머지를 갈라 필요한 조각만 받게 합니다.

“여기 없는 것”도 적어 두면 좋습니다. 이 위키의 llms.txt 는 마케팅 문구가 아니라는 것, 시간순 기록이 아니라는 것, 그것들은 어느 사이트에 있는지를 함께 적습니다. 읽는 쪽이 엉뚱한 데서 답을 찾지 않게 됩니다.

2. 구조화 데이터 — 기계가 읽을 형태로 한 번 더

사람이 읽는 화면과 별개로, 이 글이 무엇이고 누가 언제 썼는지를 JSON-LD 로 줍니다.

{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "한글 웹폰트 2MB 를 300KB 로",
  "description": "…",
  "inLanguage": "ko",
  "dateModified": "2026-09-04",
  "author": { "@type": "Organization", "name": "Shaile" }
}

Article 보다 TechArticle 처럼 좁은 타입을 쓰는 편이 낫습니다. 무엇을 다루는 글인지가 더 분명해집니다.

dateModified 는 손으로 적지 마십시오. git 이력에서 계산하면 실제로 고친 시점과 어긋나지 않습니다. 문서 도구가 대개 그 값을 제공합니다.

3. 인용해도 말이 되는 문장

이것이 가장 큰 부분이고, 도구로 해결되지 않습니다.

답을 만드는 쪽은 문서를 통째로 인용하지 않습니다. 문단이나 문장 단위로 떼어 갑니다. 그러니 떼어 놓아도 말이 되어야 합니다.

이렇게 쓰면 안 됩니다	이렇게 씁니다
“위에서 본 것처럼 이 방법이 더 낫습니다”	“가변 축을 좁히면 2,009KB 가 1,327KB 가 됩니다”
“여러 가지 방법이 있습니다”	“두 가지로 611KB 까지 줄였습니다”
“상당히 큰 차이가 있었습니다”	“한 페이지 2,619KB 가 611KB 가 됐습니다”

구체적으로 쓰면 세 가지가 한꺼번에 좋아집니다. 사람이 읽기 쉽고, 검색어와 맞아떨어지고, 인용해도 문장이 성립합니다.

결론을 먼저

각 절의 첫 문장이 그 절의 답이어야 합니다. 배경 설명으로 시작하면 인용할 때 배경만 떼어 가게 됩니다.

수치는 직접 잰 것으로

“성능이 크게 개선됐다” 보다 “3,598KB 가 1,189KB 가 됐고 LCP 는 1,644ms 에서 1,056ms 가 됐다” 가 낫습니다. 직접 잰 수치는 다른 데 없는 정보라 인용될 이유가 됩니다.

수치를 쓰려면 재야 합니다. 그게 이 방식의 비용이자 값어치입니다.

헤딩을 질문 모양으로

재는 방법, 어디까지 갈지, 무엇이 깨지는지 처럼 실제로 궁금해할 것을 헤딩으로 씁니다. 답을 찾는 쪽이 그 헤딩 아래 문단을 바로 집습니다.

틀린 것도 적으십시오

이게 의외로 큽니다. 헛짚었던 자리를 적어 두면 같은 질문을 하는 사람에게 가장 쓸모 있는 문단이 됩니다.

이 위키의 문서들이 “euc_kr 코덱이 CP949 확장까지 받아 준다”, “원문 grep 검사가 안 보이는 문자열에 걸린다” 같은 것을 적어 두는 이유입니다. 성공 사례는 어디에나 있지만 그 함정은 겪은 사람만 씁니다.

무엇을 하지 않아도 되나

키워드를 억지로 넣지 않습니다. 문장이 어색해지면 사람도 기계도 덜 읽습니다.
길게 쓰지 않습니다. 분량이 아니라 밀도입니다. 채운 문단은 인용되지 않습니다.
글자 수를 세지 않습니다. 제목과 설명은 폭으로 재야 합니다.

확인하기

배포 검증에 넣어 두면 새 문서가 조용히 빠지는 것을 잡습니다.

/llms.txt 가 200 이고 새 문서가 목록에 있는가
글 페이지에 JSON-LD 가 붙고 dateModified 가 실제 날짜인가
제목과 설명이 폭 기준 안에 있는가

세 가지 모두 자동으로 확인할 수 있습니다. 사람이 매번 세는 방식은 오래 못 갑니다.