llms.txt란? AI가 읽는 사이트 요약 파일 만드는 법

개발자 커뮤니티에서는 두 가지 실용적인 실험이 눈에 띕니다. 하나는 언어모델에게 사이트를 어떻게 설명할지 고민하는 llms.txt 작성법이고, 다른 하나는 크로스플랫폼 앱이 macOS 네이티브 가상화 기능을 어떻게 끌어안았는지 보여주는 오픈소스 사례입니다. 두 이야기는 서로 다른 사건이지만, 모두 "표준이 없는 영역에서 개발자가 직접 규칙을 만들어가는" 최근 흐름을 보여줍니다.

llms.txt, 실제로 무엇을 담아야 할까

핵심: llms.txt는 크롤러가 아니라 언어모델을 위해 쓰는 평문 요약 파일이며, 아직 어떤 대형 AI 기업도 이를 읽는다고 확인하지 않았습니다.

llms.txt는 사이트를 한 장짜리 평문으로 요약해 언어모델에게 전달하려는 아이디어입니다. 2024년 9월 제레미 하워드가 제안한 것으로, 공식 표준이 아니라 하나의 제안(proposal)에 머물러 있습니다. dev.to에 실린 글의 필자는 이 점을 명확히 짚으며, "어시스턴트가 이 파일을 읽는지 여부"보다 "한 시간을 들여 이 파일을 쓸 가치가 있는지"가 더 중요한 질문이라고 설명합니다.

글에 따르면 사이트를 설명하는 파일은 네 가지가 있고 각각 답하는 질문이 다릅니다. robots.txt는 크롤러의 접근 허용 여부를, sitemap.xml은 무엇이 언제 바뀌었는지를, JSON-LD 형태의 스키마는 페이지가 데이터로서 무엇인지를 답합니다. llms.txt만 유일하게 산문(prose) 형식으로, 그 사업체가 무엇을 하는지, 누구를 위한 것인지, 무엇을 하지 않는지, 가격은 얼마인지, 어떤 주장을 하지 않는지를 서술합니다. 필자는 마크다운 형식으로 /llms.txt 경로에 두고, H1으로 사업체 이름을, 블록쿼트로 요약을 여는 구조를 권장하며, 여섯 가지 요소 중 하나로 "패러프레이즈(다른 말로 바꿔 표현)를 해도 살아남는 한 문장"과 "하는 일의 경계선"을 꼽습니다.

필자가 강조하는 진짜 가치는 파일 자체가 아니라 그것을 쓰는 과정에서 강제되는 결정입니다. 천 단어 이내로 마케팅 수식어 없이 사업의 본질을 정리하는 작업 자체가, 웹사이트 전반의 명료함으로 이어진다는 설명입니다. 이 관점은 이어서 살펴볼 오픈소스 프로젝트의 문서화 방식과도 맞닿아 있습니다. 표준이 없는 상황에서 개발자가 스스로 규율을 세워 결과물의 신뢰도를 높이는 접근이라는 공통점이 있습니다.

출처: dev.to | 원문 보기 ↗

WSL Manager, 애플 실리콘에서 Virtualization 프레임워크 얹기

핵심: 2021년부터 이어온 Flutter 데스크톱 앱 WSL Manager가 v2에서 애플 실리콘 네이티브 가상화를 지원하게 됐고, 그 작업의 대부분은 Flutter 바깥에서 이뤄졌습니다.

WSL Manager는 필자가 2021년부터 유지보수해온 Flutter 데스크톱 앱으로, wsl.exe 명령어 플래그를 일일이 입력하지 않아도 되게 해주는 도구입니다. 이번 v2 업데이트로 애플 실리콘에서 애플의 Virtualization 프레임워크를 통해 네이티브 리눅스와 macOS 가상머신을 관리할 수 있게 됐습니다. macOS용 설치는 brew install --cask wsl-manager 명령으로 가능하며, macOS 지원은 현재 베타 단계입니다.

기술적 구조를 보면, VZVirtualMachine 객체는 자신을 생성한 프로세스 안에서만 존재하기 때문에 Flutter가 직접 이를 들고 있을 수 없습니다. 그래서 앱 번들 안에 vmctl이라는 별도의 Swift CLI 헬퍼를 넣고, 모든 서브커맨드가 표준출력으로 JSON을 반환하도록 설계했습니다. Dart 코드는 이 CLI를 실행하고 결과를 파싱하는 방식이며, XPC나 소켓 통신은 쓰지 않습니다. VM마다 config.json, 스파스 raw 디스크 이미지, EFI 변수 저장소, cloud-init 시드 ISO, pid 파일과 로그가 담긴 run 폴더로 구성된 전용 디렉터리를 둡니다.

VM 프로세스가 살아있게 유지하는 방식도 흥미롭습니다. vmctl start는 자기 자신을 vmctl __run이라는 분리된 프로세스로 재실행시키고 5초간 pid 파일을 폴링해, 설정이 잘못됐을 때 조용히 실패하는 대신 커맨드라인에서 바로 오류를 드러내도록 했습니다. 데몬은 헤드리스 NSApplication으로 동작하며 SIGTERM은 ACPI 종료 요청으로, SIGUSR1은 화면 표시로 매핑됩니다. 게스트 IP 확인은 별도 게스트 에이전트 없이 macOS 자체의 /var/db/dhcpd_leases 파일을 읽는 방식으로 처리했다고 필자는 설명합니다.

출처: dev.to | 원문 보기 ↗

이게 나에게 의미하는 것

웹사이트나 서비스를 운영하며 AI 검색 노출을 신경 쓰는 사람이라면, llms.txt 작성 자체보다 "우리 서비스가 하지 않는 일"을 명확히 문장으로 정리해보는 과정이 더 값어치 있을 수 있습니다. 아직 표준으로 확정되지 않았고 대형 AI 기업의 채택 여부도 불확실하므로, 이 파일에 큰 리소스를 투입하기보다는 사이트 전반의 설명을 명료하게 다듬는 계기로 활용하는 편이 합리적입니다.

크로스플랫폼 데스크톱 앱을 만들거나 유지보수하는 개발자라면, WSL Manager 사례처럼 플랫폼별 저수준 기능(가상화, 시스템 API)을 별도 CLI 헬퍼로 분리하고 JSON으로 인터페이스를 맞추는 방식이 Flutter/Dart 코드베이스를 깨끗하게 유지하는 데 참고가 될 수 있습니다. 애플 실리콘 기반 가상화 도구가 필요하다면 이 프로젝트는 brew로 바로 설치해 베타 상태를 직접 확인해볼 수 있습니다.

정리: 오늘의 시사점

llms.txt는 여전히 검증되지 않은 제안 단계이지만, 그 작성 과정 자체가 사업 설명을 명료하게 만드는 부수 효과를 지닙니다. WSL Manager v2는 Flutter 앱이라도 플랫폼 고유 기능을 다룰 때는 별도 네이티브 헬퍼로 책임을 분리하는 것이 유효한 설계임을 보여줍니다. 두 사례 모두 표준이나 완성된 가이드가 없는 영역에서 개발자가 직접 실용적 규칙을 세워나가는 모습이라는 공통점이 있습니다.