UI의 '결정권'이 LLM으로 넘어가고 있다
지금까지 프론트엔드 개발자의 역할은 명확했다. 디자인 시스템을 구성하고, 컴포넌트를 설계하고, 사용자가 어떤 상황에서 무엇을 보게 될지 사전에 정의하는 것. 그런데 이 전제가 흔들리고 있다. LLM이 단순히 텍스트를 생성하는 데 그치지 않고, '지금 이 응답에 어떤 UI를 보여줄 것인가'를 스스로 결정하기 시작했다. Generative UI는 더 이상 미래의 개념이 아니다. 지금 당장 구현 가능한, 그리고 구현되고 있는 패러다임이다.
세 가지 구현 사례가 가리키는 하나의 방향
최근 등장한 세 가지 오픈소스 프로젝트는 각기 다른 도메인에서 동일한 패러다임을 실험하고 있다. 첫째는 OpenGenerativeUI다. Claude의 인터랙티브 시각화 생성 기능을 오픈소스로 재현한 이 프레임워크는 Next.js 16 + React 19 + Tailwind 4 기반 프론트엔드와 LangGraph + CopilotKit 기반 Python 에이전트를 Turborepo 모노레포로 묶는다. 핵심은 '시각화 결정 매트릭스'다. 사용자의 요청 유형에 따라 에이전트가 SVG, Chart.js, Three.js, D3.js 중 적합한 기술을 자동 선택하고, widgetRenderer 훅이 생성된 HTML을 샌드박스 iframe으로 렌더링한다. 개발자가 매번 if-else로 분기하던 렌더링 결정을 LLM이 대신 내리는 구조다.
둘째는 MCP 기반 대화형 TV 앱 사례다. dev.to에 공개된 이 프로젝트는 스트리밍 서비스 탐색 경험의 근본적인 문제를 짚는다. "좀 가볍지만 허접하지 않은 것, 두 시간 이내의 코미디드라마"라는 문장 하나가 기존 그리드 UI의 수십 번 스크롤을 대체한다. mcp-use SDK의 핵심 설계 원칙은 단순하다. AI가 무엇을 보여줄지 결정하고, 위젯이 어떻게 보여줄지 결정한다. 모델은 output(텍스트 요약)만 보고, 위젯은 structuredContent(구조화된 props)를 받아 렌더링한다. 모델의 컨텍스트 윈도우를 UI 데이터로 오염시키지 않는 깔끔한 분리다.
셋째는 Waypoint다. 표면적으로는 접근성 도구이지만, 본질적으로는 '의도 기반 웹 탐색 레이어'다. Gemini가 페이지 DOM을 분석해 Intent Surface Map을 생성하고, 사용자의 자연어 발화가 구체적인 DOM 액션으로 변환된다. 흥미로운 건 3단계 인덱싱 파이프라인이다. 0ms의 순수 DOM 파싱 → ~1초의 Gemini Flash 텍스트 풍부화 → ~2-4초의 멀티모달 비전 분석으로 이어지는 레이어는, AI 없이 처리할 수 있는 것은 AI 없이 처리하고 AI가 필요한 곳에만 AI를 투입하는 실용적 설계를 보여준다.
구현 레이어에서 진짜로 중요한 것
세 사례를 겹쳐보면 공통된 설계 원칙이 드러난다.
① 렌더링 결정과 렌더링 실행을 분리하라. OpenGenerativeUI의 에이전트는 '무엇을 그릴지'만 결정하고, widgetRenderer가 '어떻게 그릴지'를 담당한다. TV 앱의 AI 모델은 '어떤 콘텐츠를 추천할지'만 판단하고, React 위젯이 포스터 카드와 히어로 배너를 렌더링한다. Waypoint의 Gemini는 '어떤 표면이 존재하는지'를 분석하고, 액션 실행은 익스텐션의 execute() 함수가 담당한다. AI에게 렌더링 결정권을 넘기되, 실행 제어권은 코드에 남기는 것이 신뢰성의 핵심이다.
② 보안 샌드박스는 선택이 아닌 필수다. OpenGenerativeUI가 모든 시각 요소를 샌드박스 iframe 내에서 렌더링하고, Waypoint가 이중 iframe 샌드박스 아키텍처를 채택한 이유는 같다. LLM이 생성한 코드를 호스트 페이지와 격리하지 않으면 XSS 벡터가 열린다. AI가 생성한 콘텐츠일수록 더 엄격한 실행 경계가 필요하다.
③ 폴백 체인을 설계하라. Waypoint의 findTarget() 함수는 5단계 폴백 체인으로 DOM 요소를 탐색한다. data-wp-id 파싱 실패 시 CSS 셀렉터를, 그것도 실패하면 aria-label을, 그다음엔 텍스트 매칭을 시도한다. SPA 라우팅, 동적 렌더링, 캐시된 맵의 불일치 등 현실의 엣지케이스는 예외 없이 존재한다. AI 기반 UI일수록 우아한 저하(graceful degradation) 설계가 더 중요하다.
④ 컨텍스트 오염을 막는 데이터 계층 분리. TV 앱 사례의 structuredContent / output 분리는 단순한 아키텍처 패턴이 아니다. LLM의 컨텍스트 윈도우에 UI 렌더링 데이터까지 밀어 넣으면 추론 비용이 폭발하고 응답 품질이 저하된다. 모델이 알아야 할 것과 위젯이 알아야 할 것을 명확히 분리하는 것이 곧 비용 최적화다.
프론트엔드 개발자의 역할이 이동하는 방향
이 세 프로젝트가 시사하는 것은 단순히 'AI가 UI를 만들어준다'는 편의성이 아니다. 개발자가 설계해야 하는 레이어가 바뀌고 있다는 신호다. 컴포넌트를 직접 만드는 것에서, LLM이 컴포넌트를 올바르게 선택하고 안전하게 실행하도록 시스템을 설계하는 것으로. 시각화 결정 매트릭스를 정의하고, 샌드박스 실행 경계를 긋고, 데이터 계층을 분리하고, 폴백 체인을 설계하는 일—이것이 지금 프론트엔드 개발자에게 요구되는 Generative UI 구현 역량이다.
특히 Next.js + React Server Components 생태계는 이 패러다임과 높은 친화성을 갖는다. 서버에서 LLM 호출과 렌더링 결정을 처리하고, 클라이언트는 위젯 실행에만 집중하는 구조는 RSC의 서버/클라이언트 분리 철학과 자연스럽게 맞닿아 있다. OpenGenerativeUI가 Next.js 16을 기반으로 선택한 것은 우연이 아니다.
앞으로 프론트엔드 개발자가 물어야 할 질문
'이 UI를 어떻게 만들 것인가'보다 먼저 '이 UI를 누가 결정할 것인가'를 물어야 하는 시대가 됐다. 사전에 정의된 컴포넌트 트리가 아니라, 사용자의 의도에 반응해 런타임에 구성되는 UI—그것의 신뢰성, 보안, 성능을 책임지는 아키텍처를 설계하는 것이 프론트엔드 개발자의 다음 핵심 역량이 될 것이다. 세 오픈소스 프로젝트는 각각 그 설계의 서로 다른 단면을 미리 보여주고 있다.