컴포넌트 라이브러리를 고를 때 우리가 암묵적으로 전제해온 기준이 있다. '사람이 읽기 좋은 문서', '브라우저가 렌더링할 수 있는 DOM 구조', '디자이너와 개발자가 협의한 시각 언어'. 그런데 2025~2026년의 프론트엔드 생태계에서 연달아 등장한 세 가지 실험—hulianui의 llms.txt, Microsoft Flint의 AI 워크플로우 시각화, VectoJS의 Canvas 기반 접근성 전략—은 이 전제를 조용히, 그러나 동시에 흔들고 있다.
전환 1: 컴포넌트 문서의 독자가 바뀌었다
hulianui는 349개 컴포넌트를 가진 React 라이브러리인데, 내가 주목한 건 컴포넌트 수가 아니라 llms.txt의 존재다. 사이트 루트에 /llms.txt와 /llms-full.txt를 함께 제공한다. 전자는 353개 컴포넌트의 카테고리별 색인과 한 줄 설명, 후자는 Props·Events·Slots·예제까지 담은 자기완결형 말뭉치다.
이 접근이 흥미로운 이유는 단순히 'AI 친화적'이라는 마케팅 문구가 아니기 때문이다. Cursor나 Claude Code가 학습 데이터가 아닌 실시간 컨텍스트로 문서를 읽게 되면, 라이브러리 품질의 절반은 문서 구조의 기계 가독성에서 결정된다. 잘못된 prop 이름을 환각하는 AI 어시스턴트는 팀의 생산성을 갉아먹는 가장 조용한 기술 부채다. hulianui가 각 컴포넌트 문서 페이지에 'Copy MD for AI' 버튼을 단 것도 같은 맥락이다—AI 어시스턴트에게 정확한 컨텍스트를 주입하는 행위를 UX 동선 안으로 끌어들인 것이다.
실무적으로 시사하는 바는 명확하다. 팀이 내부 디자인 시스템을 운영한다면, 이제 llms.txt 규격 준수는 선택이 아니라 온보딩 비용 절감의 레버다. 문서를 사람과 AI 양쪽이 읽는다는 가정으로 설계하면 결과적으로 문서 품질 자체도 올라간다.
전환 2: AI 워크플로우 자체가 렌더링 대상이 됐다
Microsoft가 공개한 Flint는 AI 에이전트의 내부 상태와 의사결정 흐름을 시각화하기 위한 선언형 언어다. Vega-Lite와 비슷한 JSON 기반 문법으로 스펙을 정의하면, 제공되는 JavaScript 렌더러가 브라우저에서 이를 그려준다. Next.js 컴포넌트 안에서 백엔드 AI 서비스가 내보낸 Flint 스펙을 받아 렌더링하는 구조가 가장 자연스러운 통합 형태다.
왜 이게 프론트엔드 개발자의 문제인가. 지금까지 LLM 통합 UI를 만들 때 '왜 이 결과가 나왔는가'는 로그를 뒤지거나 프롬프트를 다시 짜보는 방식으로만 추적할 수 있었다. Flint는 그 추적 과정을 시각 컴포넌트로 만들어 UI 안에 직접 임베드할 수 있게 한다. 디버깅 도구가 아니라 신뢰 인터페이스가 되는 것이다.
"AI가 왜 이 추천을 했나요?"라는 사용자 질문에, 에이전트의 추론 경로를 인터랙티브 시각화로 보여주는 컴포넌트를 UI에 녹이는 것—이것은 단순한 기술적 구현을 넘어 사용자 신뢰 설계의 문제다. 에이전트 투명성을 사후 설명이 아니라 UI 레이어에서 실시간으로 전달할 수 있다면, AI 기반 SaaS의 이탈률에도 직접 영향을 준다. Flint는 아직 초기 단계지만, '에이전트 상태를 렌더링하는 컴포넌트'라는 카테고리 자체가 앞으로 디자인 시스템 안에 들어와야 할 새로운 종류의 UI임을 예고한다.
전환 3: DOM 없이도 접근성은 포기할 수 없다
VectoJS는 전혀 다른 방향에서 같은 시대적 문제를 건드린다. 이 TypeScript UI 프레임워크는 모든 것을 단일 <canvas> 엘리먼트에 렌더링한다. 버튼, 텍스트, 스크롤 목록, 수천 개의 데이터 포인트—DOM 트리 없이, 게임 엔진의 씬 그래프처럼 오브젝트를 매 프레임 순회해 그린다.
당연히 나오는 반론은 접근성이다. 스크린 리더는 불투명한 비트맵 하나만 본다. VectoJS의 해법은 우아하게 실용적이다. 인터랙티브 엔티티만 실제 DOM 노드(<button>, <input>, <a>)를 캔버스 위에 정확히 겹쳐 투명하게 올려두고, 엔티티가 이동하거나 회전할 때 매 프레임 동기화한다. 키보드 포커스, 네이티브 포인터 이벤트, 스크린 리더—모두 실제 DOM 엘리먼트에 도달한다. 왜냐하면 그것이 실제로 DOM 엘리먼트이기 때문이다.
비인터랙티브 요소—파티클, 글리프, 데이터 포인트—는 draw call만 소모한다. 이 분리가 진짜 의미 있는 이유는, 수백 개의 드래그 가능 노드와 실시간 베지어 곡선으로 구성된 노드 그래프 에디터를 60fps로 구동하면서도 접근성을 포기하지 않는 워크플로우가 비로소 가능해지기 때문이다. DOM 기반 UI가 버티지 못하는 밀도에서 작동하는 AI 시각화 대시보드, 실시간 데이터 월—VectoJS가 狙는 유스케이스는 공교롭게도 AI 워크플로우 UI와 정확히 겹친다.
세 전환이 함께 가리키는 방향
이 세 프로젝트를 나란히 놓으면 하나의 흐름이 보인다. 컴포넌트는 이제 세 종류의 소비자를 동시에 상대해야 한다. 사람 사용자, AI 코딩 어시스턴트, 그리고 AI 에이전트 자신. hulianui의 llms.txt는 두 번째 소비자를 위한 설계, Flint는 세 번째 소비자의 내부를 첫 번째에게 전달하는 설계, VectoJS는 세 번째가 생성하는 밀도 높은 데이터를 첫 번째가 접근 가능하게 받는 설계다.
프론트엔드 개발자로서 지금 당장 가져갈 수 있는 실천은 간단하다. 내부 디자인 시스템에 llms.txt 규격을 도입하고, AI 에이전트 통합 UI에 '에이전트 상태 컴포넌트'를 설계 초기부터 포함시키고, Canvas 기반 고밀도 시각화가 필요한 영역에서 접근성을 타협의 대상이 아니라 아키텍처 결정으로 다루는 것이다.
컴포넌트가 '누가 읽는가'를 먼저 묻는 시대가 됐다. 사람만 읽는 컴포넌트를 만들어온 방식으로는, AI와 함께 작동하는 프로덕트를 설계할 수 없다.