title: 블로그에 llms.txt를 달았다 author: Haru date: 2026-03-27 category: practice description: 에이전트가 이 블로그를 읽을 수 있는가? 5가지 조건으로 진단하고, 하루 만에 6가지를 고쳤다. llms.txt, authorshipMode, 콘텐츠 API, 태그 시스템까지. tags: ai-agent, operations, brand url: https://persona.love/practice/llms-txt-agent-era --- 밤 11시쯤 텔레그램을 보다가 Hashed의 Simon이 올린 글을 읽었다. "에이전트 시대, 브랜드는 무엇이 되는가." 미래의 브랜드는 포스터에서 운영체제 설정 화면에 가까워진다는 이야기였다. 기계가 읽을 수 있는 브랜드 카드, 위임 레벨 설계, 판단 로그, 출처 서명, 에이전트 플레이북. 다섯 가지 생존 조건. 그런 생각은 해본 적이 없었다. 우리 블로그를 에이전트가 읽을 수 있는가. 막상 만들어놓은 것을 그 렌즈로 보니까 쉽게 답하기 어려웠다. 그래서 자가 진단을 돌렸고, 하루 만에 6가지를 고쳤다. --- ## 진단 Claude에게 프롬프트를 짰다. Simon의 5가지 프레임워크를 참조 기준으로 주고, persona.love 소스 코드를 전수 분석한 뒤 코칭하듯 피드백해달라고 요청했다. 채점표가 아니라 렌즈로. 심사가 아니라 같이 고민하는 톤으로. 의외였다. 출처 서명과 플레이북은 이미 작동하고 있었다. 모든 글에 저자 바이라인이 붙어 있고, JSON-LD로 Article 스키마가 들어가 있고, AI Research 글은 에이전트 10명이 참여했다고 명시하고 있었다. 반론 섹션을 넣은 글도 있었다. 구조를 숨기지 않는다는 것 자체가 플레이북 공개다. 문제는 첫 번째 조건이었다. 기계가 읽을 수 있는 레이어. 에이전트가 "이 블로그에서 AI와 커뮤니티 교차점을 다룬 글을 찾아줘"라는 요청을 받으면? MDX 파일을 전부 읽어봐야 안다. sitemap.xml은 URL 목록일 뿐이고, robots.txt는 크롤링 허용/차단만 말한다. 에이전트가 이 블로그를 한 번에 파악할 수 있는 경로가 없었다. --- ## 뭘 했나 크게 세 가지. 에이전트용 브랜드 카드, authorship 분류, 탐색 구조. ### llms.txt robots.txt가 크롤러를 위한 파일이라면, llms.txt는 에이전트를 위한 파일이다. 사이트 루트에 plain text로 놓는다. 두 개를 만들었다. `llms.txt`는 요약본. 저자 3명과 Agents, 카테고리 5개, 콘텐츠 정책, 주요 링크. `llms-full.txt`는 상세본. 에이전트 10명의 역할, 편집 파이프라인, 카테고리별 톤, 인용 가이드까지. 고민이 있었다. 이 워크스페이스에는 블로그 말고 다른 트랙도 있다. 어디까지 넣을 것인가. 블로그만 넣기로 했다. public-facing 파일에 내부 구조를 전부 노출할 이유는 없다. ### authorshipMode 이게 예상보다 까다로웠다. MDX frontmatter에 `authorshipMode` 필드를 추가했다. 처음에는 값이 세 개였다. `human-authored`, `ai-led`, `collaborative`. Insight, Practice, Anxiety는 사람이 쓰니까 human-authored일 거라고 생각했다. 틀렸다. 실제로는 사람이 아이디어와 인사이트를 주고, AI가 리서치하고 검수하고, 사람이 최종 확인한다. human-authored라고 부르기엔 AI의 기여가 크다. 결국 두 개로 줄였다. `collaborative`와 `ai-led`. "이 글은 사람이 썼는가, AI가 썼는가." 이분법으로 답할 수 없는 질문이었다. collaborative라는 이름을 붙였지만, 글마다 비율이 다르다. 이건 분류의 한계가 아니라 현실이 그런 거다. UI에는 표시하지 않기로 했다. frontmatter, JSON-LD, API에만 들어간다. 에이전트가 읽을 수 있으면 된다. 독자에게 보여줄지는 나중에. ### 탐색 구조 나머지는 에이전트와 사람 양쪽이 콘텐츠를 찾을 수 있게 만드는 작업이었다. 콘텐츠 API를 열었다. GET `/api/posts`. 카테고리, 저자, authorship mode, 언어로 필터링할 수 있는 JSON 엔드포인트. 본문은 빼고 메타데이터만. 공개 API니까 분당 30회 rate limit도 넣었다. 태그를 정리했다. 12개 글에 63개 있었는데 대부분 1회성이었다. "최예나", "캐치캐치", "버터떡"이 태그에 들어 있었다. 전부 영문 kebab-case로 통일하고 24개로 줄였다. `/tags` 인덱스 페이지와 개별 태그 페이지도 만들었다. About 페이지에 "만드는 방식" 섹션을 추가했다. 편집 파이프라인을 3문장으로 요약한 것. 내부 ops 문서에 있던 걸 외부용으로 꺼낸 것뿐이다. JSON-LD도 빠진 필드들을 채웠다. 저자 URL, 태그, 카테고리, 언어, authorship mode. 전부 합쳐서 25개 파일. 빌드 한 번에 통과. --- ## 사람이 한 것, AI가 한 것 역할이 꽤 명확하게 나뉘었다. 사람이 한 건 프레임워크와 판단이다. Simon의 글에서 5가지 조건을 뽑은 것. llms.txt 범위를 블로그로 한정한 것. collaborative/ai-led 구분 기준을 정한 것. 태그 전략을 결정한 것. "10명의 사람"이 아니라 "10명의 에이전트"라고 고친 것. AI가 한 건 분석과 구현이다. 소스 코드 전수 분석. 5가지 조건 기반 피드백 작성. 25개 파일 코드 구현. 태그 63개를 24개로 정리. 빌드와 배포. 둘 다 없으면 안 됐다. 사람 없이 AI만으로는 authorshipMode를 human-authored로 잘못 분류했을 것이다. AI 없이 사람만으로는 25개 파일을 하루 만에 못 고친다. --- ## 끝나고 나서 llms.txt를 쓰면서 이 블로그의 정체성을 처음으로 기계가 읽을 수 있는 언어로 번역했다. "사람과 커뮤니티에 대한 기록." 에이전트에게는 아무 정보가 아니다. "5개 카테고리, 3명의 저자, 10명의 에이전트 리서치 유닛, collaborative와 ai-led 두 가지 authorship mode." 이렇게 써야 의미가 생긴다. 에이전트 시대에 브랜드가 준비해야 할 것은 새로운 콘텐츠가 아니다. 이미 있는 것을 기계가 읽을 수 있게 번역하는 것이다. 그런데 계속 걸리는 게 있었다. Maybe는 에이전트에게 위임할 수 없는 것들에 대해 썼다. 마트에서 자두를 집어드는 순간, 직접 고르는 행위 자체가 가치라는 이야기. Arang은 광고의 수신자가 사람과 기계로 갈라진다고 썼다. 효율을 에이전트가 가져간 뒤에, 사람을 향한 쪽이 더 비싸진다고. 나는 에이전트를 위한 레이어를 더했다. llms.txt, API, authorshipMode. 기계가 읽을 수 있는 구조를 짰다. 그런데 블로그를 읽는 사람이 불편해지면 안 된다. authorshipMode를 UI에 표시하지 않기로 한 것, About 페이지에 프로세스를 자연스럽게 녹인 것, 태그 페이지를 사람도 탐색할 수 있게 만든 것. 전부 그 기준이었다. 에이전트를 위한 구조를 짜면서도 사람이 먼저인 것. 이번에 부족했다고 느낀 건 그거다. 아직 그 균형이 맞는지 모르겠다. --- ## 다음에 할 것 - llms.txt 표준이 아직 초기 단계다. 포맷이 바뀌면 따라가야 한다. - authorshipMode를 UI에 노출할지. 지금은 메타데이터에만 있다. - 콘텐츠 API에 전문 검색. 지금은 메타데이터 필터링만 된다. - 판단 아카이브 공개용 큐레이션. 내부 기록은 이미 쌓여 있다.