웹사이트는 30년 동안 도서관이었다. 방문자가 스스로 메뉴를 뒤지고, 필터를 조작하고, 원하는 답을 찾아내야 하는 구조. 그 안에 채팅 위젯을 갖다 붙여도 본질은 바뀌지 않는다. 미로가 남아 있는 한, 위젯은 미로에 대한 안내판일 뿐이다.
이 구조를 정면으로 뒤집으려는 시도가 dev.to에 소개된 Librarian Pattern이다. Eduard Gutarin이 제안한 이 패턴의 핵심 역전은 단순하다. 사이트가 자신을 '전시'하는 대신, 방문자에게 먼저 묻는다. 그리고 의도를 인식한 즉시 화면을 조립한다. 페이지를 불러오는 것이 아니라, 인식된 맥락에 맞는 장면(scene)을 생성하는 것이다.
패턴의 구조를 뜯어보면 프로덕트 설계 관점에서 흥미로운 결정들이 보인다. 첫째, 단 하나의 입력창이 네비게이션 전체를 대체한다. 텍스트와 음성을 모두 받는 이 바(bar)는 사이트의 1순위 인터페이스다. 둘째, 화면 중앙은 고정된 페이지가 아니라 인텐트에 따라 실시간으로 재조합되는 장면이다. 전환은 리로드가 아니라 모프(morph)로 처리된다. 셋째, 대화 레이어는 목표 사다리를 가진 컨설턴트처럼 작동한다. 한 번에 하나의 다음 질문만 던진다. '세 가지 옵션 중 선택하세요' 같은 메뉴가 없다.
특히 눈에 띄는 것은 이중 버튼 시스템과 정적 섀도(static shadow) 개념이다. 전역 제안 칩과 인-씬 액션 카드를 시각적으로 분리함으로써 대화형 UI의 고질적 문제인 '버튼 과잉'을 구조적으로 막는다. 그리고 모든 동적 씬에는 서버 렌더링된 쌍둥이 페이지가 존재한다. 사람에게는 에이전트를, 크롤러와 AI 답변 엔진에는 완전한 텍스트를 제공하는 이 이중 구조는 GEO(Generative Engine Optimization)를 설계 레벨에서 내재화한 것이다. 실제로 레퍼런스 구현 askbar.pro는 공개 24시간 만에 Yandex Alice가 '차세대 웹사이트' 질의의 대표 사례로 인용하기 시작했다고 한다. 검색의 단위가 페이지에서 인용 가능한 답변으로 이동하고 있다는 신호다.
한편, 같은 날 dev.to에 올라온 또 다른 글은 전혀 다른 각도에서 같은 질문을 건드린다. AI 에이전트가 DOM이 없는 앱을 어떻게 제어하는가. Flutter Web이나 Canvas 렌더링 기반 앱은 화면에 보이는 모든 버튼과 패널이 픽셀로 칠해진 캔버스일 뿐, DOM에는 아무것도 없다. find로 엘리먼트를 잡으려 해도 반환값은 없다. 접근성 트리도 사실상 비어 있다.
저자는 Claude를 사용해 Flutter 기반 애니메이션 툴인 Rive 에디터를 자동화한 과정을 상세히 기록했다. 좌표 기반 자동화는 요소 기반보다 훨씬 취약하기 때문에, 생존 가능한 절차가 필요했다. 핵심은 네 가지 규칙으로 정리된다: ① 뷰포트가 완전히 안정된 후에만 행동한다(innerWidth를 두 번 읽어 일치 확인, devicePixelRatio도 함께 검증), ② 캔버스에 그려진 텍스트는 DOM에서 추출할 수 없으므로 해당 영역을 확대(zoom)해 이미지로 읽는다, ③ 클릭 후 반드시 시각적 증거(선택 하이라이트 등)를 스크린샷으로 확인한 뒤 다음 단계로 진행한다, ④ 더블클릭은 빠른 단일 클릭 두 번으로 분해해 타이밍 오차를 줄인다.
이 두 이야기는 얼핏 다른 주제처럼 보이지만 하나의 맥락으로 수렴한다. AI가 인터페이스를 소비하는 방식이 바뀌고 있다. Librarian Pattern은 AI 답변 엔진이 사이트를 어떻게 '읽는가'에 맞춰 콘텐츠와 구조를 재설계한다. Canvas 자동화는 AI 에이전트가 DOM 없는 UI를 어떻게 '조작하는가'를 역산해 절차를 설계한다. 둘 다 '사람이 보는 화면'과 '기계가 인식하는 인터페이스' 사이의 간극을 직시하는 작업이다.
프론트엔드 개발자 입장에서 이 흐름은 설계 단계에서부터 질문을 바꿔야 한다는 신호다. '사용자가 이 버튼을 찾을 수 있는가'에서 '에이전트가 이 인터페이스를 올바르게 인식하고 제어할 수 있는가'로. 접근성(a11y)이 스크린리더를 위해 시맨틱 마크업을 요구했듯, AI-First 설계는 에이전트가 인텐트를 파악하고 행동할 수 있는 구조적 단서를 요구한다. Canvas 렌더링처럼 DOM을 포기한 순간, AI 에이전트는 픽셀 좌표와 시각적 증거에만 의존하게 되고 자동화 비용은 기하급수적으로 올라간다.
실용적 시사점은 명확하다. 새 제품을 설계할 때 세 가지를 먼저 물어볼 것. 첫째, 이 콘텐츠는 AI 답변 엔진이 인용할 수 있는 구조인가(GEO 관점). 둘째, 이 UI는 에이전트가 요소를 식별하고 행동을 검증할 수 있는 계층을 갖추고 있는가(자동화 내구성 관점). 셋째, 대화형 인터페이스를 도입한다면 네비게이션을 대체할 것인가, 보완할 것인가(프로덕트 전략 관점). Canvas 기반 앱을 이미 운영 중이라면 좌표 자동화의 취약성을 인지하고 레이아웃 안정성과 시각적 검증 포인트를 명시적으로 설계에 포함시켜야 한다.
검색이 링크 목록에서 생성된 답변으로 이동하고, 자동화 에이전트가 사람 대신 UI를 조작하는 비중이 늘어나는 지금—인터페이스 설계의 첫 번째 독자는 더 이상 사람만이 아니다. Librarian Pattern이 '대화로 탐색을 대체하라'고 제안하는 동시에, Canvas 자동화 사례가 '기계가 읽지 못하는 UI의 비용'을 적나라하게 보여주는 것은 우연이 아니다. AI가 UI를 읽는 방식을 설계 제약 조건으로 받아들이는 팀과 그렇지 않은 팀 사이의 격차는, 앞으로 제품의 발견 가능성과 자동화 내구성이라는 두 축에서 동시에 벌어질 것이다.