llms-full.txt는 페이지 렌더링에 사용되는 배열과 동일한 배열에서 생성된 574,626 바이트입니다

export type ContentPage = {
  slug: string;
  label: string;        // breadcrumbs, cards, footer links
...

export type Block =
  | { type: "p"; text: Rich }
  | { type: "list"; items: Rich[]; ordered?: boolean }
...

export const RICH_TOKEN = /([^\)]+[^\]]+)\[([^\]]+\)\([^\]\s]+\)|\*\*([^\*]+)\*\*/g;

// The inline markup content is written in: [label](href) and **bold**. Kept to
// two forms so the same string is valid markdown for llms-full.txt.
```}{

이것이 마크다운 생성기가 의존하는 트릭입니다. 페이지 렌더러는 토큰을 순회하며 `<a>`와 `<strong>`를 출력하고, 마크다운 생성기는 문자열을 변경 없이 그대로 출력합니다. 왜냐하면 그 문자열 자체가 이미 마크다운이었기 때문입니다. 코드베이스 어디에도 직렬화(serialiser) 과정도 없고, 이스케이프 처리(escaping pass) 과정도 없으며, HTML을 마크다운으로 변환하는 과정도 없습니다. 마크업, 메타 태그 및 구조화된 데이터 없이 텍스트가 필요한 두 소비자(consumer)는 다른 대체 함수를 사용하여 동일한 정규 표현식(regex)을 호출합니다:

## 생성기는 하나의 스위치

`block()`은 블록을 마크다운으로 변환하며, 컴파일러는 유니온 타입이 포괄적(exhaustive)이고 함수가 `string`을 반환하기 때문에 이를 잊도록 허용하지 않습니다:

여기에 아홉 번째 블록 타입을 추가하면, 해당 파일을 사용하는 페이지가 배포되기 전에 컴파일이 실패합니다. 이것이 제가 원했던 유일한 강제(enforcement)였습니다. 출력 모양이 올바른지 테스트하는 것이 아니라, 출력이 존재할 수 없다면 타입 에러를 발생시키는 것입니다.

여기에 있는 두 가지 세부 사항은 나머지 파일보다 더 많은 고민을 필요로 했습니다:

**링크는 호스트를 가져야 합니다.** 콘텐츠 링크는 사이트 상대(site relative)이며, 이는 페이지에는 적합하지만 누군가 다운로드하는 텍스트 파일에는 부적절합니다. 완성된 문서에 한 번 적용되는 하나의 정규 표현식은 다음과 같습니다:

**테이블 셀은 단락이 아닙니다.** 셀 내부의 파이프(`|`)는 셀을 종료시키고, 셀 내부의 개행 문자(`
`)는 행을 종료시키므로, 셀은 결합되기 전에 이스케이프되고 평탄화(flattened)됩니다:

[llms.txt](https://nakodo.app/llms.txt)에는 세 번째 경우가 있습니다. 사양의 형태는 링크 뒤에 노트가 오는 것이며, 자체 링크를 포함하는 노트를 링크 목록에서 읽으면 무의미하게 보이므로, 해당 노트는 `plain()`을 거치고 요약(summary)의 링크들은 제거됩니다:

const link = (path: string, name: string, text: string) =>
  `- [${name}](${absoluteUrl(path)}): ${plain(text)}`;

## 두 파일 모두 정적입니다

라우트는 각각 8줄로 구성되어 있습니다:

`force-static`은 보이는 것보다 더 중요합니다. `llmsFullTxt()`는 모든 페이지의 모든 섹션을 연결(concatenate)합니다. 비용이 많이 드는 것은 아니지만, 공짜도 아닙니다. 그리고 이것을 두 번 실행할 이유가 없습니다. 빌드 시점에 한 번 실행되며 그 결과는 CDN에 있는 파일이 됩니다.

크기가 사람들이 궁금해하는 부분입니다. `llms.txt`는 35,064 바이트이며, 제품 페이지와 모든 콘텐츠 페이지를 링크 및 한 줄 요약 형태로 그룹화한 것입니다. `llms-full.txt`는 574,626 바이트, 92,301 단어, 6,345줄로 구성되어 있습니다: 전체 사이트를 하나의 마크다운 문서로 만들고, 각 페이지 앞에 해당 소스 URL과 `updated` 날짜를 붙이며, 이들을 `---`로 구분합니다. 두 파일 모두 페이지와 비교(diff)할 수 있습니다. [가이드 인덱스](https://nakodo.app/guides)에서 아무 페이지나 골라 H1을 검색해보세요. 본문 텍스트는 동일한 문자열이기 때문에 같습니다.

## 이것이 할 가치가 있는 이유

레지스트리에는 상단에 하나의 주석이 있으며, 이것이 진짜 논거입니다:

여섯 개의 소비자, 하나의 목록입니다. 이것이 제거하는 실패 모드는 충돌(crash)이 아닙니다. 그것은 존재하고 렌더링되며 잘 읽히지만, 그에 대해 알려줄 수 있는 단 하나의 파일에서 빠져있는 페이지입니다. 아무도 한 달 동안 알아차리지 못합니다.

같은 목록 덕분에 테스트가 테이블 셀 내부를 포함하여 콘텐츠의 어느 곳에 있는 깨진 내부 링크도 거부할 수 있습니다:

삭제한 페이지로 연결되는 링크는 몇 주 후 크롤링에서 실패하는 것이 아니라, `pnpm test`를 실패하게 만듭니다.

제가 다르게 할 한 가지는 여기서부터 시작하는 것입니다. 이 페이지들에 대한 저희의 첫 번째 시도는 파일들로 이루어졌고, 그것들을 객체로 변환하는 과정은 지루한 하루였습니다. 콘텐츠 타입들은 변환되기 전에 나온 것이 아니라, 변환을 통해 도출되었습니다. 아마도 그래야만 하는 방식일 겁니다. 5페이지를 작성하기 전에는 63페이지의 형태를 설계할 수 없기 때문입니다.