파일 하나를 추가하면 AI가 내 글을 더 잘 찾아줄까. 블로그를 운영하는 입장에서는 꽤 솔깃한 이야기다. 글을 다시 읽고 고치는 것보다 설정 하나를 바꾸는 일이 훨씬 명확해 보이니깐. 다만 그 설정이 실제로 무슨 일을 하는지는 다른 문제다.
Google의 AI 검색 최적화 안내에는 이 부분이 분명하게 적혀 있다. Google 검색의 AI 기능에 나오기 위해 llms.txt 같은 별도 파일이나 특별한 마크업을 만들 필요는 없다는 것이다. 기존 검색의 기본 조건은 여전히 적용된다. 페이지를 읽을 수 있어야 하고, 색인과 검색 스니펫의 대상이 될 수 있어야 한다. 조건을 갖췄다고 실제 노출까지 보장되는 것은 아니다.
그럼 아무것도 달라진 게 없다는 말일까. 나는 읽는 사람이 질문을 던지는 방식부터 생각해보고 싶다. 예전에는 ‘자바스크립트 문자열 길이’를 검색했다면, 이제는 ‘이름을 20자로 제한했는데 이모지가 두 글자로 계산돼. 어떻게 해야 해?’라고 물을 수 있다. 단어를 찾는 사람과 이미 겪은 문제를 설명하는 사람이 같은 페이지에 도착하는 셈이다.
이 질문에 답하는 글이라면 ‘문자열에는 여러 종류의 길이가 있다’는 설명만으로는 조금 아쉽다. 실제 입력 하나를 놓고 UTF-16 코드 단위와 코드 포인트, 보이는 문자 묶음이 어떻게 달라지는지 보여주는 쪽이 낫겠다. 화면의 글자 수 안내와 서버의 검증 규칙도 이어서 생각할 수 있고. 질문은 길어졌지만 답을 만드는 일은 오히려 더 구체적이어야 하는 것 같다.
내 글에서 가져갈 수 있는 부분
나는 AI가 인용하기 좋은 문장을 따로 끼워 넣기보다는, 사람이 읽고 가져갈 수 있는 예제를 만들고 싶다. 코드라면 실행한 환경과 입력이 있어야 한다. 비교라면 무엇을 고정했는지 알아야 한다. 한계도 그 예제 옆에 있어야 하고. 문서 뒤쪽에 작게 적은 조건 하나 때문에 앞의 결론이 달라진다면 읽는 사람에게도 불편한 글이다.
가령 ‘이 방법이 가장 빠르다’는 문장 대신 같은 입력을 두 방법에 넣은 결과를 남길 수 있다. 아직 실행하지 않았다면 실행 계획으로 적으면 된다. 결과가 없다고 글을 쓸 수 없는 건 아니다. 다만 제안과 결과를 섞으면, 나중에는 나도 어느 부분을 확인했는지 헷갈릴 것 같다.
기술적인 구조도 같은 방향으로 보고 싶다. 제목만 보이는 페이지와 본문까지 읽히는 페이지는 다르다. 제목은 문자열 길이 이야기인데 본문 대부분이 다른 도구를 권하는 내용이라면, 설정이 아무리 깔끔해도 질문에 답하지 못한다. 관련 글을 연결할 때도 그냥 ‘더 보기’가 아니라 다음에 생길 법한 문제를 이어주는 편이 낫겠다.
예를 들면 문자열 길이를 설명한 뒤에는 입력값을 지우는 것과 보내지 않는 것의 차이로 이어질 수 있다. 반대로 최근 글이라는 이유만으로 전혀 다른 뉴스 묶음을 붙일 필요는 없을 것이다. 링크 수를 늘리는 것보다 읽는 흐름을 잃지 않는 일이 먼저다.
Google은 비슷한 검색 표현마다 페이지를 대량으로 만드는 방식도 경계한다. 이 부분은 개인 블로그에도 꽤 현실적인 이야기다. 제목을 조금씩 바꾼 글 열 개보다, 내가 정말 설명할 수 있는 문제 하나가 오래 남을 수 있다. 물론 그 글이 검색에서 선택될지는 별개의 일이다.
결국 내 입장에서는 할 일이 조금 더 선명해졌다. AI를 위한 비밀 설정을 찾기 전에 글 하나를 골라서, 이 글을 읽은 사람이 무엇을 이해하거나 해볼 수 있는지부터 다시 보려 한다. 검색은 들어오는 길이고, 머물 이유는 글 안에 있어야 한다.
