UI가 생성된다는 것의 의미
Google I/O 2026에서 가장 눈길을 끈 발표 중 하나는 모델도, 에이전트도 아니었다. Antigravity 기반 생성형 UI였다. Google은 검색 쿼리 하나로 동적 레이아웃, 인터랙티브 비주얼, 심지어 결혼 준비나 이사 관리 같은 장기 과제를 위한 맞춤형 도구·대시보드를 즉석에서 생성하는 기능을 공개했다. 검색창이 곧 앱 빌더가 되는 순간이다.
이 발표를 프론트엔드 개발자 관점으로 다시 읽으면 질문이 하나 생긴다. UI가 AI에 의해 즉석에서 만들어진다면, 개발자는 무엇을 설계해야 하는가?
고정된 화면에서 유동적인 경험으로
지금까지 프론트엔드 개발자의 작업 단위는 '화면'이었다. 디자인을 받아 컴포넌트로 쪼개고, 상태를 관리하고, API를 연결했다. 하지만 Google의 Neural Expressive 디자인 언어가 보여주는 방향은 다르다. 텍스트 나열 대신 실시간 맞춤 응답, 풍부한 이미지, 인터랙티브 타임라인, 동적 그래픽이 모델 응답에 따라 유기적으로 구성된다. UI의 구조 자체가 콘텐츠에 반응해 변한다.
이 흐름에서 개발자의 설계 대상은 고정된 레이아웃이 아니라 '가능성의 범위'가 된다. 어떤 데이터가 들어왔을 때 어떤 컴포넌트 조합이 가장 유효한가, AI가 생성한 결과물이 사용자에게 안전하고 일관된 방식으로 전달되는가—이런 질문이 설계의 핵심으로 올라온다.
React use() hook이 보여주는 새로운 데이터 흐름
생성형 UI의 확산과 맞물려, React 생태계도 조용히 패러다임을 바꾸고 있다. use() hook은 그 변화의 단면이다. Server Component에서 promise를 내려받아 Client Component에서 use()로 읽고, Suspense가 로딩 상태를 처리하는 패턴은—복잡한 상태 관리 라이브러리 없이도—비동기 데이터 흐름을 선언적으로 다룰 수 있게 한다.
dev.to의 사례처럼, 버튼 클릭 시 이벤트 핸들러에서 promise를 즉시 생성하고 상태에 저장한 뒤 use()로 읽는 패턴은 응답성과 코드 단순성을 동시에 잡는다. 모듈 레벨 Map 캐시를 조합하면 동일 요청의 중복 호출도 제거된다. TanStack Query나 SWR이 필요한 순간—여러 컴포넌트 간 데이터 동기화, 백그라운드 재요청, 낙관적 업데이트—은 여전히 존재하지만, 단순한 케이스에서는 use() + 캐시 함수만으로 충분하다는 것이 이 패턴의 핵심 메시지다.
생성형 UI 환경에서 이 패턴은 더 중요해진다. AI가 응답을 스트리밍으로 흘려보내거나, 사용자의 질문에 따라 전혀 다른 구조의 데이터를 반환할 때, 데이터 레이어가 유연하게 대응할 수 있어야 하기 때문이다.
실전 채팅 UX 구현기에서 배우는 것
velog에 연재 중인 'Crack Clone 개발기' 3편은 생성형 UI 시대의 프론트엔드 문제를 가장 현실적인 형태로 보여준다. Claude API를 연결한 AI 채팅 인터페이스를 만들면서 마주친 문제들—감정 태그가 화면에 노출되고, 응답이 한 줄로 나오고, 마크다운이 제대로 렌더되지 않는—은 모두 AI 출력과 사용자 경험 사이의 간극에서 비롯됐다.
흥미로운 건 해결 과정이다. 처음엔 정규식으로 직접 포매터를 만들었지만 AI 출력의 다양성을 감당하지 못했고, react-markdown으로 전환하면서 문제가 해소됐다. 감정 태그 노출은 프롬프트가 아니라 렌더 직전 정규식 제거로 잡았고, 응답이 한 줄로 나오는 문제는 프롬프트도 렌더도 아닌 SSE 줄바꿈 분할 버그가 원인이었다. 개발자가 내린 결론은 명확하다. "원인은 프롬프트·렌더·전송 세 층위에 흩어져 있었다."
이 구조적 관찰은 AI 채팅 UX를 설계하는 누구에게나 유효하다. AI 출력 품질 문제는 모델만의 문제가 아니다. 전송 레이어, 렌더링 레이어, 프롬프트 레이어 중 어디서 문제가 발생했는지를 분리해 진단하는 능력이 필요하다.
시사점: 프론트엔드 설계의 새로운 세 축
세 소스를 관통하는 공통 질문은 결국 하나다. AI 시대에 프론트엔드 개발자가 설계해야 할 것은 무엇인가?
첫째, AI 출력의 컨테이너를 설계한다. 생성형 UI에서 AI는 콘텐츠뿐 아니라 구조를 만든다. 개발자는 그 결과물이 안전하고, 접근 가능하고, 브랜드 일관성을 유지하는 범위 안에서 동작하도록 경계를 설정해야 한다. react-markdown의 components prop으로 이미지와 링크 렌더링을 커스터마이징한 것처럼, AI 출력이 통과하는 렌더 파이프라인 자체를 설계 대상으로 봐야 한다.
둘째, 데이터 흐름을 유연하게 구성한다. use() hook과 Suspense의 조합이 보여주듯, 비동기 데이터가 언제 어디서 어떤 형태로 올지 모르는 환경에서는 선언적이고 조합 가능한 데이터 레이어가 필수다. 복잡도에 비례해 도구를 선택하는 판단력—언제 use()로 충분하고, 언제 TanStack Query가 필요한지—이 실력의 척도가 된다.
셋째, AI 출력과 사용자 경험 사이의 번역 레이어를 책임진다. 스트리밍 중 깜빡이는 미완성 태그를 숨기고, SSE 줄바꿈을 복원하고, 프롬프트로 잡을 문제와 코드로 잡을 문제를 구분하는 것—이 모든 작업이 프론트엔드 개발자의 고유 영역이 됐다.
전망: 설계력이 생존력이다
Google의 SynthID 확장—AI 생성 콘텐츠에 감지 불가능한 워터마크를 삽입하고, 이를 Search와 Chrome에서 검증하는 인프라—은 생성형 UI 시대의 또 다른 숙제를 예고한다. 화면에 보이는 것이 AI가 만든 것인지, 사람이 만든 것인지, 어떻게 편집됐는지를 사용자가 알 수 있어야 한다. 이 투명성 레이어를 UX 안에 자연스럽게 녹이는 것도 프론트엔드 개발자의 몫이다.
생성형 UI가 '앱을 만드는 문턱'을 낮추는 방향으로 이동하는 건 분명하다. 그러나 그것이 프론트엔드 개발자의 역할을 축소시키지는 않는다. 오히려 반대다. AI가 생성한 경험이 실제로 사용자에게 유용하고, 안전하고, 일관된지를 판단하고 설계하는 역할—경험의 품질을 보증하는 설계자—의 비중이 커진다.
'일단 돌아가게 만든 다음에야 더 나은 구조가 눈에 들어왔다'는 Crack Clone 개발기의 문장이 지금의 프론트엔드 생태계 전체를 관통한다. AI가 빠르게 만들어내는 세계에서, 무엇이 더 나은 구조인지를 판단하는 기준—그 설계력이 지금 개발자의 진짜 차별점이다.