AI가 UI를 만드는 속도는 이제 논쟁거리가 아니다. v0.dev에 프롬프트 한 줄을 넣으면 그럴듯한 컴포넌트가 나오고, Cursor에게 폼 레이아웃을 맡기면 수 초 안에 JSX가 완성된다. 문제는 속도가 아니라 그 UI가 실제 사용자와 만나는 순간 무너지는 세 가지 지점이다. 상태가 사라지고, 키보드가 막히고, 렌더링이 찢긴다. 최근 세 편의 기술 아티클은 각기 다른 레이어에서 같은 경고를 보낸다.
핵심 이슈 ①: 사용자 입력이 증발하는 'Ephemerality Gap'
dev.to에 올라온 「The Ephemerality Gap」은 Generative UI(GenUI)가 안고 있는 구조적 결함을 정면으로 다룬다. AI 에이전트가 JSON 뷰 정의를 프론트엔드에 내려보내고, 프론트엔드가 이를 컴포넌트로 렌더링하는 방식은 겉으로 보면 매끄럽다. 사용자가 "필드 하나 더 추가해줘"라고 요청하면 AI가 즉시 레이아웃을 재생성한다. 문제는 그 순간 사용자가 이미 입력한 50개 필드의 데이터가 통째로 사라진다는 것이다.
원인은 단순하다. 대부분의 UI 프레임워크는 구조적 키(structural key)로 상태를 추적한다. AI가 계층을 바꾸거나 새 그룹을 삽입하면 키가 달라지고, 프레임워크는 이전 노드가 사라진 것으로 간주해 상태를 초기화한다. 키가 일치하더라도 타입이 string에서 object로 바뀌면 런타임 크래시가 터진다. 저자는 이 현상을 'Ephemerality Gap'이라 명명하며, 해결책으로 오픈소스 런타임 Continuum을 공개했다. 핵심 아이디어는 사용자 데이터를 뷰 구조와 분리해 영속적 의미론적 식별자(semantic identity)로 추적하는 것이다. 뷰가 바뀌어도 데이터는 detach 후 보관되고, AI가 해당 컨트롤을 재도입하면 즉시 rehydrate된다. AI가 사용자 입력을 덮어쓰려 하면 suggestion cache로 격리하고 사용자가 수락 여부를 결정한다.
이 문제의 본질은 기술적 버그가 아니라 설계 철학의 공백이다. AI는 레이아웃을 새로 그리는 데 능숙하지만, 그 레이아웃 위에서 살아가는 사용자의 시간과 의도를 기억하지 못한다. GenUI가 보편화될수록 '상태 보존'은 AI가 자동으로 해결하는 문제가 아니라, 사람이 명시적으로 설계해야 하는 아키텍처 레이어가 된다.
핵심 이슈 ②: 접근성 버그의 범주를 없애는 Popover API
GeekNews에 소개된 Popover API 아티클은 툴팁이라는 작은 UI 요소가 얼마나 많은 접근성 부채를 품고 있었는지를 적나라하게 보여준다. 기존 툴팁 구현은 트리거 요소, 숨겨진 툴팁 DOM, 둘을 중재하는 JavaScript라는 3단 구조였다. 키보드 사용자가 Tab으로 진입해도 툴팁이 표시되지 않고, 스크린 리더는 같은 내용을 두 번 읽거나 아예 건너뛰고, Esc로 닫히지 않으며, aria-expanded 상태를 손으로 동기화하다 하나라도 놓치면 접근성 트리가 오염된다.
popover 속성과 popovertarget 속성만으로 이 모든 관례(convention) 코드가 플랫폼 레이어로 내려간다. 브라우저가 열기/닫기, Esc 처리, aria-expanded 자동 동기화, 포커스 복원을 직접 담당한다. 저자가 강조하는 포인트는 코드 감소량이 아니라 책임의 전환이다. 이전에는 JavaScript가 툴팁을 '존재'시켰다면, 이제는 브라우저가 마크업의 역할을 이해하고 네이티브 접근성 트리에 참여한다. Lighthouse가 잘못된 ARIA 경고를 더 이상 표시하지 않는 이유는 개선한 것이 아니라 실수할 수 있는 커스텀 ARIA 상태 자체가 사라졌기 때문이다.
AI 코드 생성 도구는 툴팁을 만들라고 하면 예전 패턴—이벤트 리스너, 수동 ARIA, 커스텀 해제 로직—을 학습 데이터 기반으로 그대로 뱉어낼 가능성이 높다. 네이티브 API로의 전환은 단순한 모던화가 아니라, AI가 생성한 UI에 접근성 안전망을 시스템 레벨에서 깔아주는 구조적 업그레이드다. 호버 인텐트 딜레이나 중첩 스크롤 컨테이너 포지셔닝처럼 브라우저가 아직 추론하지 못하는 영역은 JavaScript가 얇게 보완하면 된다. CSS anchor positioning이 성숙하면 그 영역도 좁아질 것이다.
핵심 이슈 ③: React Signals의 렌더링 정합성 문제
dev.to의 「Signals in React (I)」는 세 편 중 가장 낮은 층위를 건드린다. Signals는 세밀한 반응성(fine-grained reactivity)을 구현하는 매력적인 패턴이지만, React의 렌더링 모델과 충돌할 수 있는 지점이 정확히 세 군데다. 렌더 중 createEffect 생성, 렌더 중 signal 쓰기, 그리고 오래 유지되는 클로저에서 get() 값을 캡처하는 것이다.
React의 Concurrent 렌더링은 렌더 페이즈를 여러 번 실행하고 중단·재시작할 수 있다. Signals의 스케줄러는 마이크로태스크 경계에서 사이드 이펙트를 병합한다. 두 타이밍 모델이 충돌하면 tearing—같은 외부 상태를 렌더 도중 다르게 읽는 현상—이 발생한다. 해결책은 useSyncExternalStore를 통해 Signals를 외부 데이터 소스로 취급하고, React가 커밋 직전 스냅샷을 재검증할 수 있도록 구독 인터페이스를 표준화하는 것이다. 사이드 이펙트 책임도 명확히 나뉜다: DOM 측정·애니메이션은 useLayoutEffect/useEffect, 비즈니스 로직은 createEffect, React의 외부 상태 구독은 반드시 useSyncExternalStore.
AI가 Signals 패턴 코드를 생성할 때 이 경계를 지킬 가능성은 낮다. 학습 데이터에는 올바른 패턴과 잘못된 패턴이 뒤섞여 있고, Concurrent 모드의 미묘한 타이밍 이슈는 테스트 환경에서 재현되지 않다가 프로덕션에서 터진다. 렌더링 정합성은 AI가 코드를 빠르게 생성할수록 사람이 더 꼼꼼히 리뷰해야 할 레이어다.
맥락 해석: 세 이슈가 가리키는 하나의 패턴
세 기사는 서로 다른 문제를 다루지만 구조가 동일하다. AI가 표면을 빠르게 완성할수록, 그 아래 층위—상태 보존, 접근성, 렌더링 정합성—는 더 잘 보이지 않게 된다. GenUI의 Ephemerality Gap은 AI가 레이아웃을 재생성하는 순간 발화하고, 접근성 버그는 생성된 툴팁 코드가 배포되는 순간 잠복하고, tearing은 Concurrent 렌더링이 예상치 못한 타이밍에 끼어드는 순간 드러난다. 세 문제 모두 눈에 잘 띄지 않고, 그래서 AI 코드 리뷰에서 빠지기 쉽다.
흥미로운 것은 세 기사 모두 해결책이 '더 많은 AI'가 아니라 플랫폼·아키텍처·규칙의 명시화라는 점이다. Continuum은 상태 보존 레이어를 AI와 프레임워크 사이에 명시적으로 삽입한다. Popover API는 접근성 책임을 브라우저 플랫폼으로 이전한다. useSyncExternalStore는 외부 상태 구독의 계약을 React 런타임이 강제하게 만든다. 공통 키워드는 '책임의 명시적 귀속'이다.
시사점: 지금 당장 설계에 반영할 것들
프로덕트 관점에서 세 이슈는 각각 다른 실패 시나리오로 연결된다. Ephemerality Gap은 사용자가 긴 폼을 작성하다 데이터를 잃는 치명적 이탈을 만든다. 접근성 버그는 키보드 사용자와 스크린 리더 사용자를 UI에서 조용히 배제하는 비가시적 차별로 이어진다. tearing은 금융·실시간 데이터 UI에서 사용자에게 잘못된 숫자를 보여주는 신뢰 붕괴를 초래한다.
실무 체크리스트로 정리하면 세 가지다. 첫째, GenUI를 도입할 때는 뷰 구조 변경과 사용자 입력 상태를 반드시 분리된 레이어로 설계한다. 둘째, AI가 생성한 툴팁·팝오버 코드는 Popover API 네이티브 패턴으로 리팩토링하고, 그 과정에서 삭제되는 코드의 양이 품질 지표다. 셋째, React에 Signals나 외부 상태를 통합할 때는 useSyncExternalStore 준수 여부를 코드 리뷰 체크리스트에 명시적으로 올린다.
전망: 속도와 품질의 격차가 벌어지는 2025년 하반기
AI 코드 생성 도구의 속도는 앞으로도 빨라진다. React Compiler가 안정화되고, RSC와 Partial Prerendering이 보편화되면 AI가 생성할 수 있는 UI의 복잡도 상한선도 올라간다. 그런데 역설적으로 그럴수록 Ephemerality Gap 같은 문제는 더 자주, 더 조용하게 발생한다. AI는 구조를 만드는 속도를 높이지만, 그 구조 위에서 벌어지는 사용자 경험의 디테일—데이터의 연속성, 접근성 계약, 상태 정합성—은 여전히 사람이 의도하고 설계하고 검증해야 한다.
빠른 프로토타이핑과 사용자 검증의 루프를 돌리는 것이 AI 시대 프론트엔드의 핵심 역량이라면, 그 루프의 출구 조건은 '동작하는가'가 아니라 '실제 사용자가 데이터를 잃지 않고, 키보드로 탐색하고, 올바른 값을 보는가'여야 한다. 세 기사가 모두 오픈소스 해결책이나 네이티브 API 전환을 제안하는 것은 우연이 아니다. 인터랙션 품질의 기준선을 높이는 작업은 커뮤니티와 플랫폼이 함께 담당해야 하고, 그 위에서 AI가 속도를 더하는 구조가 지속 가능하다.