인터페이스가 바뀌고 있다. 개발자가 컴포넌트를 손으로 조립하던 시대에서, LLM이 UI를 직접 생성하는 시대로. Chrome v145가 버티컬 탭을 공식 지원하기 시작했고(chrome://flags/#vertical-tabs), OpenUI는 LLM 기반 UI 생성을 위한 오픈 표준 프레임워크를 공개했다. 표면적으로는 서로 다른 두 사건이지만, 둘 다 같은 질문을 가리킨다. 인터페이스의 형태는 누가, 어떤 기준으로 결정하는가?
OpenUI: UI 생성을 코드가 아닌 언어로
GitHub의 thesysdev 팀이 공개한 OpenUI는 단순한 UI 컴포넌트 라이브러리가 아니다. LLM이 UI를 생성할 때 쓰는 언어(OpenUI Lang), 토큰 단위로 점진적 렌더링하는 React 런타임, 그리고 허용된 컴포넌트만 모델이 출력하도록 제어하는 프롬프트 시스템까지를 하나의 풀스택 프레임워크로 묶었다. Vercel의 json-render 대비 최대 67% 토큰 절감, 3배 빠른 속도는 단순한 성능 수치가 아니라 LLM이 UI를 생성하는 방식 자체를 재설계한 결과다.
특히 주목할 부분은 '라이브러리 기반 프롬프트 제어'다. 모델이 임의의 마크업을 뱉는 게 아니라, 사전에 정의된 컴포넌트 세트 안에서만 출력하도록 제약을 건다. 이는 디자인 시스템의 일관성을 LLM 생성 결과물에도 강제한다는 뜻이다. npx @openuidev/cli로 앱 스캐폴딩과 시스템 프롬프트가 자동 생성되고, Claude Code·Copilot 같은 Agent와 연동해 OpenUI Lang 기반 앱을 생성·디버깅할 수 있다. 생성형 UI가 디자인 시스템을 해체하는 게 아니라, 디자인 시스템이 생성형 UI의 제약 조건이 되는 구조다.
브라우저 UI의 진화: 크롬의 버티컬 탭이 던지는 신호
크롬의 버티컬 탭 지원은 작은 UX 업데이트처럼 보이지만, 그 맥락은 훨씬 넓다. 탭이 수십 개를 넘어가는 게 일상이 된 지금, 수평 탭바는 이미 인지 과부하의 원흉이 됐다. 탭 접기·그룹·검색을 세로 레이아웃과 통합한 이 변화는 사용 패턴의 변화에 브라우저 UI가 뒤늦게 응답한 결과다. Edge가 일찌감치 도입했던 기능을 Chrome이 따라간 셈이지만, 중요한 건 방향이다. 브라우저 자체의 크롬(chrome, UI 껍데기)이 점점 사용자의 워크플로우에 맞게 재구성 가능해지고 있다는 것. 생성형 UI가 앱 레이어에서 인터페이스를 동적으로 구성한다면, 브라우저 레이어에서도 같은 방향의 움직임이 진행 중이다.
백악관 앱 디컴파일이 드러낸 것: 속도의 반대편
그런데 인터페이스 설계의 '빠른 진화' 이면에는 반드시 들여다봐야 할 그늘이 있다. 백악관 공식 앱이 디컴파일되면서 드러난 구조는, 현대 프론트엔드 개발의 공급망 리스크를 적나라하게 보여준다. React Native + Expo SDK 54 + Hermes 엔진으로 구성된 이 앱에는 68개 이상의 서드파티 라이브러리가 포함되어 있었고, GitHub Pages에서 외부 HTML을 로드하는 react-native-youtube-iframe, 샌드박싱 없이 실행되는 Elfsight 위젯, Mailchimp·Uploadcare·Truth Social 등 정부 인프라가 아닌 외부 상용 서비스들이 직접 연결되어 있었다.
더 심각한 건 WebView에 주입되는 JavaScript 코드다. 외부 링크를 열 때마다 쿠키 배너, GDPR 동의창, 페이월 요소를 자동으로 제거하는 스크립트가 실행된다. 기능만 보면 uBlock과 비슷해 보이지만, 정부 공식 앱이 제3자 웹사이트에 CSS와 JS를 주입하는 건 법적·윤리적 맥락에서 전혀 다른 문제다. 물론 HackerNews 커뮤니티에서는 위치 추적 관련 주장 일부에 대한 반론도 제기됐다. OneSignal SDK에 위치 추적 코드가 '포함'되어 있다는 것과 실제로 '활성화'되어 있다는 것은 다르며, 앱 매니페스트에 위치 권한 선언이 없다면 런타임 요청 자체가 불가능하다는 지적이다. 다만 조건이 충족될 경우 4.5분~9.5분 간격으로 GPS를 수집할 수 있는 파이프라인이 비활성 상태로 컴파일되어 있다는 사실 자체는 부인되지 않았다.
이 사례가 프론트엔드 개발자에게 던지는 질문은 명확하다. 우리가 npm install로 끌어오는 모든 의존성은 공급망의 일부다. 외주 개발사가 빠르게 앱을 찍어낼 때 기본 탑재되는 SDK들, 트리 쉐이킹이 제대로 되지 않아 남는 죽은 코드들, 프로덕션 빌드에 섞여 나간 개발용 URL과 expo-devmenu 잔재들. 이것은 백악관만의 문제가 아니라, 빠른 출시를 최우선으로 두는 모든 모바일 프론트엔드 프로젝트의 잠재적 민낯이다.
시사점: 생성형 UI 시대의 설계 기준은 '제어'다
세 가지 사례를 관통하는 키워드는 하나다. 제어(Control). OpenUI가 LLM의 출력을 허용된 컴포넌트 집합으로 제한하는 것, 크롬이 탭 레이아웃을 사용자가 직접 재구성할 수 있게 여는 것, 백악관 앱이 그 제어를 잃은 것—모두 같은 축 위에 있다.
생성형 UI가 개발 속도를 비약적으로 높이는 건 분명하다. 하지만 속도가 빨라질수록 '무엇이 렌더링되는지', '어떤 서드파티 코드가 실행되는지', '컨텍스트 경계가 어디서 무너지는지'에 대한 설계자의 감각은 오히려 더 정교해져야 한다. OpenUI의 프롬프트 제어 레이어가 흥미로운 이유도 그 때문이다. LLM에게 UI 생성을 위임하되, 시스템이 허용하는 범위를 명시적으로 정의함으로써 예측 가능성을 유지한다.
전망: 인터페이스 설계의 책임이 재분배되는 시대
앞으로의 프론트엔드 설계는 두 개의 레이어를 동시에 다뤄야 한다. 하나는 LLM이 동적으로 생성하는 UI의 제약 조건을 설계하는 레이어—어떤 컴포넌트를 허용하고, 어떤 인터랙션 패턴을 금지할 것인가. 다른 하나는 그 UI가 실행되는 런타임 환경의 신뢰성을 관리하는 레이어—어떤 외부 코드가 실행되고, 어떤 데이터가 어디로 흐르는가.
OpenUI의 openui.com/playground에서 실시간으로 생성형 UI를 테스트하는 경험과, 백악관 앱 WebView에서 제3자 스크립트가 조용히 실행되는 현실은 동전의 양면이다. 생성형 UI 시대의 프론트엔드 설계자에게 요구되는 것은 더 많은 코드 작성 능력이 아니라, 시스템이 만들어내는 것과 시스템이 허용하는 것의 경계를 정밀하게 설계하는 판단력이다.