AI가 UI를 생성해주는 시대가 됐다. 프롬프트 한 줄에 컴포넌트가 튀어나오고, 노트 앱 안에서 인터랙티브한 포모도로 타이머가 실시간으로 렌더링된다. 그런데 이 흐름이 빨라질수록 역설적으로 더 중요해지는 것이 있다. AI가 생성한 결과물을 어떤 레이어 위에서, 어떤 격리 구조 안에서, 어떤 데이터 흐름으로 띄울 것인지—그 설계는 여전히 프론트엔드 개발자의 몫이다.
최근 세 가지 흐름이 동시에 이 질문을 가리키고 있다. 브라우저 네이티브 CSS만으로 완성하는 캐러셀 패턴, 노트 앱 안에서 AI 생성 컴포넌트를 스트리밍으로 렌더링하는 실험, 그리고 Server Component부터 use() 훅까지 정리된 React 데이터 페칭 지형도. 이 세 가지는 표면적으로 달라 보이지만 같은 메시지를 공유한다. AI가 코드를 만드는 속도보다, 그 코드가 안전하고 올바르게 실행될 수 있는 구조를 설계하는 속도가 더 중요하다.
1. 렌더링 레이어: 플랫폼이 흡수하는 복잡성을 활용하라
dev.to에 소개된 CSS 캐러셀 패턴은 단순한 기술 트릭이 아니다. scroll-marker-group과 ::scroll-button() 같은 2025-2026년 CSS 스펙은 점(dot) 네비게이션, 이전/다음 버튼, 키보드 접근성, 비활성화 상태까지 브라우저가 직접 소유하도록 설계되어 있다. 14KB짜리 캐러셀 라이브러리를 40줄 CSS로 대체하는 과정에서 핵심은 용량 절감이 아니라 접근성 책임의 이전이다. 직접 짠 ARIA 속성과 인덱스 추적 코드는 상태가 바뀔 때마다 어긋나지만, 브라우저 네이티브 컨트롤은 슬라이드가 런타임에 추가·삭제돼도 항상 정합성을 유지한다.
AI가 UI를 생성할 때 가장 자주 놓치는 것이 바로 이 레이어다. 모델은 동작하는 코드를 만들어내지만, 그 코드가 플랫폼의 어떤 기능을 불필요하게 재구현하고 있는지는 판단하지 못한다. scroll-snap으로 충분한 곳에 JS 스크롤 이벤트를 붙이고, :disabled로 처리될 버튼 상태를 클래스 토글로 관리하는 패턴이 AI 생성 코드에서 반복되는 이유다. 브라우저 네이티브 기능의 현재 지형을 아는 것은 AI에게 올바른 방향을 잡아주는 설계자의 역할이다.
2. 격리 구조: AI 생성 코드가 실행되는 경계를 직접 그려라
노트 앱 Fluxerv의 사례는 AI×프론트엔드 시너지의 가장 직접적인 실험이다. /ai 커맨드를 입력하면 Gemini 2.5 Flash가 컴포넌트를 스트리밍으로 생성하고, Tiptap 커스텀 노드 안의 iframe에 실시간으로 렌더링된다. 여기서 아키텍처의 핵심은 속도가 아니라 격리 설계였다.
sandbox="allow-scripts" 설정에서 allow-same-origin을 의도적으로 제외한 결정이 그것이다. AI가 생성한 코드는 localStorage, 쿠키, 부모 DOM에 접근할 수 없다. 스트리밍 중 잦은 리렌더링 문제는 useRef로 청크를 누적하다가 스트림이 닫힐 때 단 한 번만 노드를 업데이트하는 방식으로 해결했다. 결과적으로 에디터의 성능도 지키고, 보안 경계도 유지했다. AI가 만든 코드를 신뢰하되 격리하는 것—이것이 AI 생성 UI를 프로덕션에 올리는 설계의 핵심 원칙이다.
이 구조가 중요한 이유는 AI 생성 코드의 품질을 100% 보장할 수 없기 때문이다. 모델이 아무리 좋아져도 생성된 코드가 예상치 못한 사이드 이펙트를 가질 가능성은 항상 존재한다. 실행 경계를 명확히 그어두지 않으면, 도구가 편해질수록 리스크는 조용히 누적된다. 샌드박스 설계는 AI 워크플로우에서 선택이 아니라 전제 조건이다.
3. 데이터 페칭 전략: 선택지가 많아질수록 기준이 필요하다
React의 데이터 페칭 지형은 지금 그 어느 때보다 복잡하다. Server Component에서의 async/await 직접 호출, 클라이언트의 use() 훅과 Suspense 조합, TanStack Query와 SWR의 캐싱·자동 재요청, useSyncExternalStore까지—선택지가 늘었다는 것은 동시에 각 시나리오에 맞는 판단 기준이 없으면 코드가 금세 엉킨다는 의미이기도 하다.
dev.to의 React 데이터 페칭 가이드는 이 지형을 시나리오 표로 정리한다. 핵심 메시지는 단순하다. Server Component라면 async/await가 가장 자연스럽고, 복잡한 클라이언트 상태—페이지네이션, 뮤테이션, 자동 재요청—는 TanStack Query나 SWR이 적합하며, useEffect는 DOM 측정·이벤트 리스너·타이머처럼 정말 그것을 위한 것에만 써야 한다. AI가 생성한 데이터 페칭 코드가 이 기준을 따르는지 리뷰할 수 있는 것—그것이 지금 프론트엔드 개발자에게 요구되는 판단력이다.
AI는 동작하는 코드를 빠르게 만든다. 하지만 Server Component에서 처리해야 할 것을 클라이언트 useEffect로 내리거나, use() 훅으로 충분한 곳에 TanStack Query를 끌어오는 선택은 기능 관점에서 틀리지 않지만 아키텍처 관점에서는 낭비다. 데이터 흐름의 레이어를 설계하는 것은 AI가 대신해줄 수 없는 영역이다.
설계자로서의 프론트엔드
세 가지 흐름이 공통적으로 말하는 것은 결국 하나다. AI가 빠르게 생성하는 것들—컴포넌트, 인터랙션, 데이터 로직—이 실제로 잘 작동하려면, 그것이 올라설 레이어를 이해하고, 실행 경계를 설계하고, 데이터 흐름의 기준을 갖춘 사람이 필요하다. 그 역할이 프론트엔드 개발자의 중심으로 이동하고 있다.
프롬프트를 잘 쓰는 것과 설계를 잘 하는 것은 다르다. AI 시대의 프론트엔드 개발자는 코드를 덜 쓰는 대신, 코드가 실행되는 구조를 더 깊이 설계해야 한다. 브라우저 플랫폼의 최신 기능을 파악하고, 격리 경계를 의도적으로 그리고, 데이터 레이어의 선택 기준을 팀 안에 내면화하는 것—이 세 가지가 지금 프론트엔드에게 가장 필요한 설계 근육이다.