형제 서비스 스무 개의 llms.txt: 본진을 허브로, 앱은 가리키기만

듀오랩스 본진의 llms.txt를 다시 읽어 봤습니다. AI가 사이트를 이해하도록 요약해 두는 파일입니다. 서비스 상세로는 웹 개발 페이지 하나가 올라 있었습니다. 그런데 듀오랩스 이름으로 돌아가는 형제 앱은 스무 개입니다. 업무 시스템, AI 자동화, 3D, ERP 같은 데모까지, AI가 "듀오랩스는 무엇을 만드나"를 물었을 때 답이 될 앱 대부분이 이 파일에 없었습니다.

형제 앱 쪽을 보면 llms.txt가 있는 곳은 여섯 곳뿐이었습니다. 나머지는 AI가 앱을 이해할 요약이 아예 없었습니다.

앱마다 llms.txt를 충실히 쓰면 된다는 오해

가장 먼저 떠오르는 해법은 앱 스무 개가 각자 자기 llms.txt를 자세히 쓰는 것입니다. 각 앱이 자기를 가장 잘 아니까요.

저는 이 방식이 두 가지 이유로 맞지 않는다고 봤습니다. 첫째, 스무 개의 요약이 따로 놀면 회사에 대한 설명이 스무 가지가 됩니다. 어떤 앱은 회사를 "소프트웨어 개발사"로, 어떤 앱은 "디자인 스튜디오"로 소개할 수 있습니다. 둘째, AI가 질문에 답할 때 필요한 것은 앱 하나의 설명보다 "이 회사가 무엇을 하고, 무엇을 보여 줄 수 있는가"라는 전체 그림입니다. 그 그림은 한 곳에서 그려야 합니다.

본진은 허브, 형제는 가리키기

그래서 역할을 나눴습니다. 본진의 llms.txt가 허브가 됩니다. 형제 앱 전부를 한 줄 설명, 주소, 무엇을 보여 주는지로 적고, 개념 해설 글과 데모 소개 페이지, 콘텐츠 라이선스를 함께 적습니다. 형제 앱은 짧은 llms.txt만 갖습니다. 무엇인지, 어디까지 공개인지, 제작 문의는 본진으로, 그리고 본진 llms.txt로 가는 링크입니다.

회사에 대한 설명은 본진 한 곳에만 있고, 형제 앱은 그곳을 가리킵니다. 구조화 데이터에서 회사 식별자를 하나로 모은 것과 같은 원리입니다. 설명이 한 곳에 있어야 AI가 어느 앱에서 출발해도 같은 회사에 도착합니다.

형제 목록을 손으로 쓰지 않기

본진 llms.txt에 형제 스무 개를 적는 일을 손으로 하면, 앱이 하나 늘 때마다 누군가 이 파일을 기억해서 고쳐야 합니다. 그리고 반드시 한 번은 잊습니다. 본진 코드에는 이미 형제 앱 목록이 있습니다. 바닥 링크와 앱 런처가 쓰는 목록입니다. llms.txt도 이 목록에서 만들기로 했습니다. 앱이 늘면 런처에 추가하는 순간 llms.txt에도 들어갑니다.

크롤러가 읽을 본문이 없는 앱

허브를 만들다 보니 다른 빈틈도 보였습니다. 웹 데스크톱 앱은 검색에 색인되고 있었지만 크롤러가 읽을 본문이 거의 없었습니다. 앱마다의 설명이 마우스를 올리면 뜨는 툴팁과 검색 창 안에만 있었기 때문입니다. 사람에게는 충분한 설명이 기계에게는 보이지 않았습니다. 앱 목록과 설명을 서버에서 그리는 목록으로 한 번 내보내고, ItemList 구조화 데이터를 붙이는 것이 할 일로 남았습니다.

FAQ가 두 벌이라는 것도 이때 알았습니다. 랜딩 페이지와 llms 파일이 읽는 FAQ와, FAQ 페이지가 읽는 FAQ가 따로 저장돼 있었습니다. AI가 인용하는 답과 사람이 읽는 답이 갈라질 수 있는 구조입니다. 한 벌을 정본으로 정하고 나머지는 그것을 읽게 하기로 했습니다.

질문에 답하는 문장으로

마지막은 문장의 모양입니다. AI 검색이 인용하는 것은 제품 소개가 아니라 질문에 대한 답입니다. "듀오랩스 ERP 데모"보다 "사출 공장 ERP에서 금형 보전은 어떻게 관리하나"에 답하는 문장이 인용될 가능성이 높습니다. 데모 소개 페이지와 개념 글을 그런 질문의 모양으로 쓰고, 개념 글에서 "실제로 보기"로 데모를 잇는 것이 이 허브 구조의 마지막 조각입니다.

이 글에 적은 것은 아직 절반이 계획입니다. robots.txt와 회사 식별자 같은 기본기는 먼저 고쳤고, 허브 llms.txt와 형제의 짧은 안내는 다음 순서입니다. 다만 순서를 이렇게 잡은 이유는 분명합니다. AI가 우리를 찾아오게 하려면, 먼저 찾아올 문을 막고 있지 않아야 하고, 그다음에 문 안에서 한 가지 이야기를 들려줘야 합니다.