llms.txt

사이트는 오랫동안 사람이 보라고 지어졌습니다. 위쪽 메뉴, 옆의 관련 글 목록, 쿠키 동의 띠, 문서 아래 붙는 문의 양식까지 전부 사람이 화면에서 길을 찾도록 돕는 장치입니다. 사람은 이 중에서 본문이 어디인지를 눈으로 단번에 가려냅니다.

모델은 그러지 못합니다. 모델에게 페이지는 메뉴와 본문과 광고가 한 덩어리로 섞인 글자 뭉치라서, 어디부터 어디까지가 읽을 값어치가 있는지를 스스로 추려야 합니다. 게다가 한 번에 밀어 넣을 수 있는 글자 수에 한계가 있어 사이트 전체를 훑고 판단할 형편도 못 됩니다. 도움말 문서가 300개인 사이트라면 모델은 크롤링으로 긁어 온 것 가운데 몇 개만 골라 읽고 답을 만듭니다. 크롤링은 수집 프로그램이 링크를 타고 다니며 페이지를 훑어 가는 과정인데, 링크를 따라가는 순서가 곧 중요도는 아닙니다.

페이지덱에서 실제로 이런 일이 있었습니다. 현우가 챗봇에 "페이지덱 팀 요금제 얼마냐" 고 물었더니 2년 전에 없앤 요금표를 그대로 읽어 줬습니다. 옛 공지가 지워지지 않고 남아 있었고, 모델이 하필 그 페이지를 집었습니다.

llms.txt 는 여기에 안내판을 하나 세워 보자는 제안입니다. 2024년에 처음 나왔고, 사이트 쪽에서 "우리는 이런 걸 만드는 회사이고 이 문서 열두 개부터 읽으면 된다" 고 미리 적어 두자는 발상입니다.

모델이 사이트에서 무엇부터 읽어야 할지 모르는 문제를 풉니다. 읽을 것을 사이트 주인이 미리 골라 목록으로 적어 두는 방식입니다.

파일은 사이트 주소 맨 뒤에 /llms.txt 를 붙인 자리에 둡니다. 내용은 마크다운으로 쓴 평범한 글이고, 보통 이런 순서로 채웁니다.

1. 제목 한 줄. 사이트나 제품 이름을 씁니다.
2. 한 줄 요약. 이 제품이 무엇인지 한 문장으로 적습니다. "페이지덱은 팀이 함께 쓰는 협업 문서 도구입니다" 정도면 됩니다.
3. 필요하면 짧은 설명 문단. 모델이 잘못 알아듣기 쉬운 것을 여기서 미리 정리합니다.
4. 문서 목록. - [팀 요금제 안내](주소): 인원별 가격과 결제 주기 처럼 링크 하나에 설명 한 줄을 답니다. 이 설명 줄이 모델에게는 "이 문서를 열어 볼지" 를 판단하는 근거가 됩니다.
5. 나중에 봐도 되는 것. 분량이 모자랄 때 건너뛰어도 되는 문서를 따로 묶어 둡니다.

핵심은 4번에서 무엇을 빼느냐입니다. 300개를 다 적으면 목록이 사이트를 한 번 더 복사한 것이 되고, 그러면 모델은 다시 처음 문제로 돌아갑니다. 실제로 쓸 만한 목록은 열 개에서 스무 개 사이입니다. 가장 많이 들어오는 질문 열 개를 뽑고 그 답이 든 문서만 남기는 식으로 줄입니다.

같은 문제를 푸는 방법은 이 파일 말고도 셋 더 있고, 셋 다 llms.txt 와 겹치지 않는 자리를 맡습니다.

1. 사이트맵 — 사이트의 페이지 주소를 전부 적어 검색 엔진에 넘기는 파일입니다. llms.txt 와 반대 방향입니다. 사이트맵은 빠뜨리지 않는 것이 목적이라 3천 개도 적고, llms.txt 는 추리는 것이 목적이라 열다섯 개를 적습니다. 둘 다 두는 것이 정상입니다.
2. 구조화 데이터 — 페이지 안의 어느 덩어리가 질문이고 어느 줄이 가격인지를 기계가 알아보는 표기로 붙여 두는 것입니다. 작동하는 단위가 다릅니다. llms.txt 가 사이트 전체에서 읽을 문서를 고르는 일이라면 이쪽은 고른 문서 안에서 뜻을 짚어 주는 일입니다.
3. 문서 자체를 고쳐 쓰기 — 답변 추출성과 인용 가능성을 높이는 손질입니다. 앞 문단을 읽어야 뜻이 통하는 문단을 그 자체로 답이 되게 고치고, 숫자에는 기준 시점을 답니다. 효과가 가장 확실한 대신 문서 수만큼 품이 듭니다.

셋 중에서는 3번이 본론이고 llms.txt 는 비용이 가장 싼 쪽입니다. 문서를 고치는 일이 몇 달짜리라면 그동안 파일 하나라도 올려 두는 선택은 합리적입니다. 다만 순서를 뒤집지는 않습니다. 파일만 올리고 문서를 그대로 두면 모델은 우리가 가리킨 문서를 읽고도 인용할 문장을 찾지 못합니다.

"llms.txt 올렸는데 왜 아직도 옛날 요금제로 답해요?"

파일을 두는 것과 모델이 그 파일을 읽는 것은 별개라는 점이 아직 정리되지 않은 상태입니다.

"llms.txt 목록에 이 문서 넣을까요? 문의 세 번째로 많이 들어오는 건데요."

목록에 넣을 것을 문의량 순서로 고르고 있다는 뜻입니다.

"그건 llms.txt 말고 robots.txt 에서 막는 거예요."

안내하는 파일과 차단하는 파일을 섞어 쓰고 있다고 바로잡는 말입니다.

페이지덱에서는 현우가 이 파일을 맡고 있습니다. 분기마다 문의가 많이 들어온 질문 열 개를 뽑아 그 답이 담긴 문서가 목록에 있는지 확인하고, 없으면 넣고 지워진 문서는 뺍니다. 요금제나 보안 정책처럼 자주 바뀌는 문서는 링크 옆 설명 줄에 "2026년 3월 기준" 같은 표시를 같이 답니다.

규원은 이 작업의 성과를 묻고 현우는 매번 답하기 어려워합니다. AI 개요에 페이지덱이 인용됐는지를 세어 보고는 있지만, 그 변화가 이 파일 때문인지 그동안 고쳐 쓴 문서 때문인지는 갈라내지 못합니다.

파일만 올리면 모델이 우리 사이트를 인용해 준다고 기대하는 경우가 많습니다. 사이트 뿌리에 둔 파일이라면 robots.txt 처럼 다들 읽어 갈 것 같으니 자연스러운 기대입니다. 하지만 이건 제안된 형식이지 합의된 규격이 아니고, 주요 검색·모델 사업자 가운데 이 파일을 읽는다고 공식적으로 밝힌 곳은 아직 드뭅니다. 이걸 성과가 보장된 작업으로 보고하면 몇 달 뒤 인용 수가 그대로일 때 생성 엔진 최적화 쪽 시도 전체가 효과 없는 일로 도매금에 묶입니다. 비용이 낮아 해 둘 만한 일로 다루는 것이 안전합니다.

많이 적을수록 좋다고 생각하는 것도 흔한 오해입니다. 안내판이니 정보가 많으면 도움이 될 것 같지만, 이 파일의 값어치는 적은 데서 나옵니다. 300개를 다 적은 llms.txt 는 목록이 아니라 사이트 복사본이고, 모델은 다시 그중 무엇을 읽을지 스스로 골라야 합니다. 그렇게 만든 파일은 만들지 않은 것과 결과가 같고 분기마다 관리할 일만 하나 늘어납니다.