AI가 웹사이트를 읽는 방식과 그것이 개발자에게 의미하는 바

Takeshi Yokoyama — Onecarat Labs 작성

안녕하세요. 저는 Yokoyama입니다. 사이드 프로젝트로 로컬 퍼스트 (local-first) AI 텍스트 에디터와 몇 가지 실험적인 도구들을 만들고 있습니다. 이 작업들을 하면서 웹이 어디로 향하고 있는지에 대해 똑같은 질문에 계속 부딪히곤 합니다. 이 포스트는 그에 대한 하나의 관찰이자, 이를 테스트하기 위해 제가 직접 만든 작은 실험에 대한 내용입니다. 실제로 사용해 보실 수 있는 Chrome 확장 프로그램도 포함되어 있습니다.

요약하자면: 저는 웹사이트가 점점 더 AI 에이전트 (AI agents)를 통해 읽히고, 독자에 맞춰 즉석에서 재구성될 것이라고 생각합니다. 그리고 일단 그런 일이 일어나면, AI가 읽기 쉬운 사이트와 그렇지 않은 사이트 사이에 명확한 격차가 생길 것입니다.

일어나기 시작한 변화

지금까지 사람들은 웹사이트를 웹사이트로서 읽었습니다. 메인 페이지를 열고, 메뉴를 따라가고, 본문을 읽고, 버튼을 클릭하며 — 제작자가 설계한 경로를 따라갔습니다.

로컬 AI (local AI)와 AI 에이전트 (AI agents)가 일상이 되면, 이 방식은 깨집니다. 사람들은 페이지를 직접 열지 않습니다. 대신 AI에게 자신이 원하는 것을 말합니다 — "이걸 빠르게 써볼 수 있을까?", "그냥 안전한지만 확인하고 싶어", "요점만 알려줘" — 그러면 AI가 웹을 읽고 독자가 원하는 형태로 재구성합니다. 독자가 받는 것은 더 이상 제작자가 만든 레이아웃이 아닙니다.

이것은 추측이 아닙니다. AI가 독자를 위한 인터페이스를 생성한다는 개념은 이미 **생성형 UI (Generative UI)**라는 이름이 붙어 있으며, Google, Vercel 등이 이를 향해 나아가고 있는 현재 프론트엔드 (frontend) 분야에서 가장 뜨거운 영역 중 하나입니다.

하지만 거의 모든 버전의 이야기에서 누가 펜을 쥐고 있는지 주목해 보세요. 바로 사이트나 앱에 내장된 (embedded in an app) AI입니다. 즉, 제작자의 통제 하에 있는 무언가입니다. 제가 보고 있는 것은 그보다 한 단계 더 나아간 것입니다: 독자 자신의 손에 있는 로컬 AI가, 제작자의 개입 없이 어떤 사이트든 그 사람이 선호하는 형태로 재구성하는 것입니다. 주도권이 제작자에서 독자로 이동하는 것입니다.

개발자로서 저를 괴롭히는 부분

저 또한 소프트웨어를 만드는 사람입니다. 그래서 이러한 변화가 저를 계속 신경 쓰이게 합니다.

웹사이트에는 제작자의 의도와 권리가 담겨 있습니다. 요소들이 나타나는 순서, 무엇이 강조되는지, 그리고 어조까지 말입니다. 디자인, 카피, 흐름 — 이 모든 것은 의도된 것입니다. AI가 이를 조용히 재배열하고, 다시 쓰고, 어조를 바꾸는 것은 저에게 편안하게 느껴지지 않습니다.

하지만 다른 측면을 피할 수도 없습니다. AI가 제대로 읽을 수 없는 사이트는 존재하지 않는 것이나 다름없습니다. 사람들이 AI를 통해 검색하고 결정하게 되면, AI가 파싱(Parsing)할 수 없는 사이트는 독자가 보기도 전에 경쟁에서 탈락합니다. HTML을 아무리 정성스럽게 작성했더라도, AI가 읽기에 너무 노이즈가 많다면 그 정성은 기회의 상실로 변합니다.

결국 딜레마에 빠지게 됩니다. 동의 없이 형태가 재구성되는 것은 제가 원하는 바가 아닙니다. 하지만 읽히지 않는다는 것은 기회 자체를 완전히 잃는 것을 의미합니다. 이 두 가지 모두 동시에 사실입니다.

이 논의가 현재 진행 중인 위치

솔직히 말씀드려야겠습니다. 이 문제를 제기하는 것이 저뿐만이 아닙니다. "사이트는 AI 에이전트(AI agents)를 위해 기계가 읽을 수 있는 정보를 포함해야 한다"는 논의는 해외에서 **에이전틱 웹 (agentic web)**이라는 이름으로 활발히 진행 중입니다. 두 가지 참고 지점이 있습니다.

llms.txt (2024년 Jeremy Howard가 제안) — 사이트 루트(root)에 위치하여 AI에게 중요한 페이지를 안내하는 Markdown 파일입니다. 2026년 기준으로 채택률은 약 10% 정도이며, 주요 크롤러(Crawlers)들은 이를 거의 가져오지 않지만, 점점 더 "B2A (Business-to-Agent)" 전략으로 프레임화되고 있으며, Cursor나 Claude Code와 같은 IDE 에이전트들은 이를 일상적으로 읽습니다. 흥미롭게도 여러 분석에 따르면, 생태계가 하나의 사이트 수준 파일에서 페이지별 기계 판독 가능 신호(machine-readable signals)로 이동할 것으로 예상됩니다.

NLWeb (Microsoft, Build 2025에서 발표) — 사이트가 이미 보유하고 있는 Schema.org 구조화 데이터(structured data)를 재사용하여, 사이트를 AI가 자연어(natural language)로 쿼리(query)할 수 있는 형태로 변환합니다. 모든 NLWeb 인스턴스는 MCP 서버로도 작동합니다.

따라서 인간을 위한 웹과 AI를 향한 인터페이스가 나란히 공존하는 거대한 방향성은 더 이상 가설이 아닙니다. 이미 움직이고 있습니다.

그렇다면 실제로 새로운 것은 무엇이라고 생각하는가?

이 모든 상황을 고려할 때, 기존의 노력들이 채우지 못하고 있다고 생각하는 두 가지 공백이 있으며, 이것이 바로 이 글의 핵심입니다.

첫째, 기존의 작업들은 대부분 "나를 발견 가능하게 만들어라"라는 측면에 집중되어 있습니다. llms.txt와 NLWeb은 주로 클라우드 측(cloud-side) AI 검색이나 에이전트가 당신의 사이트를 찾아내고 인용하도록 하는 것, 즉 소유자가 정보를 밖으로 밀어내는 방식에 관한 것입니다. 제가 보고 있는 것은 그 반대편입니다. 독자의 손에 들린 로컬 AI가 그 개인의 의도(intent)에 맞춰 페이지의 디스플레이를 재구성하는 것입니다. 즉, 독자/시청자 측면입니다. 대부분의 논의는 "에이전트가 사이트를 발견하도록 돕는 것"으로 기울어져 있으며, "독자의 로컬 AI가 의도에 따라 페이지를 다시 렌더링(re-render)하는 것"에 대한 논의는 여전히 부족합니다.

둘째, AI 기반의 재구성(reshaping)이 원본의 권위(authority)와 어떻게 공존할 것인가에 대한 개념이 거의 없습니다. AI가 사이트를 요약하고, 순서를 바꾸고, 어조를 변경하는 시대에 제작자의 의도(intent)를 어떻게 보존할 수 있을까요? 이 질문은 llms.txt나 Schema.org에서 거의 다뤄지지 않습니다. 모두가 _보기(view)_가 어떻게 구축되는지에 대해서는 이야기하지만, _"그리고 원본은 주권을 유지한다"_라는 개념과 결합하는 사람은 거의 없습니다.

이 딜레마에 대한 저의 해답은 사이트를 두 개의 레이어(layer)로 나누고, 이 둘을 동시에 유지하는 것입니다.

저의 해답: 결합된 두 개의 레이어

원본(당신의 HTML)은 건드릴 수 없습니다. 제작자가 이를 완전히 제어합니다. 권리와 의도는 여기에 존재합니다. 제작자가 의도한 그대로를 원한다면, 원본을 읽으면 됩니다.

파생된 뷰(derived view)는 AI가 자유롭게 구축할 수 있는 영역입니다. 순서를 바꾸고, 요약하고, 어조를 바꾸는 것 — 모두 괜찮습니다. 원본을 건드리지 않기 때문입니다. 원본은 제작자가 만든 그대로 여전히 존재합니다. 파생된 뷰는 단지 한 명의 독자가 자신을 위해 바라보는 방식일 뿐입니다. 마음에 들지 않나요? 그럼 원본을 읽으세요.

이 자유로운 부분이 허용될 수 있는 이유는 다음과 같습니다. 원본이 보존되기 때문에, 파생된 뷰는 무엇이든 필요에 따라 자유롭게 변할 수 있습니다.

그렇다면 제작자는 실제로 무엇을 해야 할까요?

이것이 실무적인 부분입니다. 파생된 뷰를 구축하는 것이 AI의 몫이라면, 제작자는 그 뷰를 설계할 필요가 없습니다. 제작자는 정확히 한 가지 일만 하면 됩니다. AI가 사이트를 더 읽기 쉽게 만드는 것입니다.

AI에게 사람이 보는 HTML을 파싱(Parse)하도록 강제하면 오독(Misreading)과 불안정성이 발생합니다. 그보다는 사이트의 정보를 AI가 깔끔하게 읽을 수 있는 형태로 미리 제공하는 것이 더 낫습니다. 그래서 저는 각 페이지를 레이아웃(Layout)이 아닌 **소재(Material)**로 정의하며, 이를 HTML 옆에 위치한 JSON 파일에 담아 설명합니다. <head> 섹션에 한 줄을 추가하여 이를 가리키게 합니다.

<link rel="ai-source" type="application/json" href="index.ai.json" />

{
  "version": "0.1",
  "site":    { "name": "Onecarat Labs", "url": "https://onecarat.dev", "purpose": "..." },
...

핵심은 이 JSON이 AI에게 무엇을 어떻게 표시하라고 지시하는 명령어가 아니라는 점입니다. 이것은 AI가 깔끔하게 읽을 수 있도록 전달되는 소재(Material)입니다. 요약, 순서 변경, 어조(Tone) 변경에 대한 자유는 읽는 이의 AI에게 남아 있습니다. 제작자는 이를 제약하지 않습니다.

그 결과: 이렇게 하는 것은 AI가 사이트를 더 읽기 쉽게 만듭니다. 읽기 쉽다는 것은 기회의 손실이 적다는 것을 의미합니다. 기존 HTML은 건드리지 않은 채 그대로 유지되며, 이를 원하는 사람은 언제든 읽을 수 있습니다. 제작자는 오직 진입로(On-ramp)만을 구축할 뿐입니다. 뷰(View)가 어떻게 조립될지는 AI의 몫으로 남겨둡니다.

이는 렌더링 엔진(Rendering engine)보다는 SEO(검색 엔진 최적화)에 더 가깝습니다. 사이트 소유자는 구글의 결과 페이지를 위해 직접 구축하려고 시도하지 않습니다. 그들은 단지 발견되기를 원할 뿐이며, 따라서 사이트를 크롤링(Crawl)하기 쉽게 만듭니다. 결과 페이지가 어떻게 구성되는지는 구글의 역할입니다. 이것이 바로 그 방식의 변형이며, 검색 엔진이 있던 자리에 AI 에이전트(AI agent)가 들어온 것입니다. (참고로, 생태계는 사이트 수준의 파일에서 페이지별 신호로 이동하고 있다고 알려져 있는데, 이는 정확히 여기서 제시한 '페이지당 하나의 JSON' 형태와 일치합니다.)

Onecarat Lens — "읽혔다"는 느낌

말만으로는 한계가 있습니다. 그래서 직접 실행해 볼 수 있는 것을 만들었습니다: 크롬 확장 프로그램인 Onecarat Lens입니다. 이는 오픈 소스입니다.

🔗 https://github.com/onecarat-labs/onecarat-lens

Lens는 사이트가 제공하는 ai-source를 읽고, 로컬 AI인 Chrome 내장 Gemini Nano가 사용자의 의도에 맞춰 뷰를 조립하도록 합니다. 이 뷰는 기존 페이지 위에(on top of) 오버레이(Overlay) 형태로 그려집니다. 구체적으로 다음과 같은 기능을 수행합니다:

페이지에서 ai-source 링크를 찾습니다 (링크가 없으면 아무 작업도 수행하지 않음),
독자에게 의도(intent)를 묻습니다 — 프리셋 버튼(try-now / safety / overview / details / choose)과 자유 텍스트 박스를 제공합니다,
로컬 AI(local AI)가 무엇을 남길지, 어떻게 순서를 정할지, 어떻게 문구를 재구성할지를 결정하게 합니다,
결과물을 원본을 대체하지 않는 오버레이(overlay) 형태로 그립니다,
그리고 언제든지 손대지 않은 원본으로 되돌릴 수 있는 토글(toggle)을 제공합니다.

동일한 페이지에서, _"그냥 한번 써보고 싶어요(_I just want to try it)"_를 누르면 다운로드와 빠른 시작(quick-start) 정보가 상단으로 올라오고, _"안전한지 확인하고 싶어요(_I want to check it's safe)"_를 누르면 대신 로컬 우선(local-first), 클라우드 미사용(no-cloud), 코드 서명(code-signing) 관련 노트가 상단으로 올라옵니다. 같은 사이트이지만 형태는 다릅니다. 그리고 그 소스(source)는 HTML에서 긁어온 추측값이 아니라, 사이트가 직접 제공한 자료입니다.

여기서 제가 여러분이 느끼길 바라는 것은 이 뷰(view)의 매끄러움이 아닙니다. 사이트가 읽혔다는 사실 — 독자의 조건에 맞춰 깔끔하게 — 그리고 원본이 여전히 토글 하나 거리의 곳에 그대로 남아 있다는 사실입니다.

거친 부분들에 대해서는 솔직하게 말씀드리겠습니다. Gemini Nano는 작기 때문에, 무리하게 작동하면 서투른 요약(summary)을 내놓거나 성능이 저하(fallback)될 수 있습니다. Lens는 이러한 성능 저하를 숨기지 않고 투명하게 보여줍니다. 이는 의도된 것입니다. 이 실험의 핵심은 로컬 AI가 현재 무엇을 할 수 있고 무엇을 할 수 없는지에 대해 정직해지는 것입니다.

이 아이디어가 어디서 왔는지에 대하여

이 모든 아이디어는 잘못된 방향에서 시작되었습니다. Lens의 초기 버전은 사이트의 가공되지 않은 HTML(raw HTML)을 읽고 AI가 이를 직접 재구성하도록 했습니다. 그리고 그것은 제작자의 의도를 무시하는 것처럼 느껴졌습니다. 해결책은 AI를 더 예의 바르게 만드는 것이 아니었습니다. 원본이 주권을 유지하게 하고, 사이트가 자체적인 조건에 따라 AI를 위한 자료를 제공하게 만드는 것이었습니다. 그 깨달음이 바로 ai-source입니다.

마무리

"인간을 위한 HTML, AI를 위한 JSON"은 더 이상 단순한 가설이 아닙니다. llms.txt나 NLWeb처럼 이미 움직이고 있습니다. 제가 생각하기에 새로운 점은 두 가지입니다. 발견(discovery) 측면이 아니라, 의도(intent)에 따른 독자 측 로컬 AI의 재렌더링 (re-rendering), 그리고 뷰(view)에 대해 아무것도 선언하지 않고 단순히 사이트를 읽기 가능하게(readable) 만드는 제작자가 주권을 유지하는 원본과 결합된다는 점입니다.

로컬 AI (Local AI)는 점점 더 실용적으로 변할 것입니다. 하지만 로컬 AI는 새로운 정보를 가지고 있지 않기에, 웹을 읽으러 가라는 요청을 받게 될 것입니다. 그리고 오늘날 인간을 향한 웹은 AI가 읽기에 너무 노이즈가 많습니다. 따라서 사이트는 읽기 가능한 무언가를 제공하고, 원본은 온전하게 유지되며, 독자는 자신에게 맞는 형태로 자신의 로컬 AI를 통해 이를 보게 됩니다.

Onecarat Lens는 그러한 미래를 테스트하기 위한 작은 실험입니다. 이것은 웹을 대체하지 않습니다. 제작자의 측면에서, 의도적으로, 제작자의 조건에 따라 인간을 향한 HTML로 AI가 진입할 수 있는 온램프 (on-ramp)를 추가하는 것입니다.

로컬 AI 에이전트 (AI agents)가 일상이 된다면, 사이트 또한 AI에 의해 읽힐 것입니다. 그때까지 당신의 사이트를 읽기 가능하게 만들어 두었는지가 중요한 관건이 될 것입니다.

Code: github.com/onecarat-labs/onecarat-lens · Built by Onecarat Labs