솔직히 말하면, 나는 지금 조금 무섭습니다
10년 넘게 Figma 시안을 px 단위로 뜯어보고, 디자이너와 '이 버튼 margin이 8px인지 12px인지'로 30분째 싸워온 사람으로서—GenUI 이야기를 처음 들었을 때 든 감정은 설렘이 아니라 불안이었습니다. 아니, 정확히는 "이거 기획자가 의도한 건지 아니면 그냥 AI한테 맡긴 건지"를 더 이상 구분할 수 없게 되는 시대에 대한 불안이었습니다.
제이콥 닐슨(Nielsen Norman Group 공동 설립자)이 최근 발표한 '2026년 18가지 UX·AI 변화 예측'은 그 불안에 이름을 붙여줬습니다. 그리고 dev.to에 올라온 Generative UI·MCP Apps·A2UI 표준 경쟁 분석은 그 불안이 실무에서 어떤 모습으로 구체화되는지를 보여줍니다. 두 글을 함께 읽고 나니, 프론트엔드 개발자로서 지금 당장 직시해야 할 것들이 보이기 시작했습니다.
핵심 이슈: UI가 '설계되는 것'에서 '생성되는 것'으로
GenUI(Generative UI)의 개념은 간단합니다. 모든 사용자에게 동일한 메뉴·버튼을 보여주는 정적 UI 대신, 사용자의 현재 의도와 맥락에 맞춰 인터페이스가 실시간으로 렌더링됩니다. 닐슨의 예시가 인상적입니다—은행 앱에서 사용자가 특정 결제 내역을 여러 번 확인했다면, 'My Page → 고객센터 → 청구 이의제기'를 찾아 헤매게 하는 대신, 해당 거래와 "이의 제기" 버튼만 크게 띄우는 일회용 인터페이스를 즉석에서 만드는 것이죠.
프론트엔드 개발자 입장에서 이 시나리오가 불편한 이유는 명확합니다. 지금 우리가 짜는 코드는 기본적으로 예측 가능한 상태 트리를 가정합니다. React의 컴포넌트 계층, Zustand나 Redux의 스토어, TypeScript의 타입 시스템—이 모든 것이 "UI는 정해진 규칙대로 렌더된다"는 전제 위에 있습니다. 그런데 모델이 런타임에 UI 구조 자체를 뱉어낸다면? 타입은 누가 보장하고, 접근성(a11y) 속성은 누가 붙이며, WCAG 대비는 누가 검수합니까.
맥락 해석: 표준 전쟁이 시작됐고, 우리는 그 한가운데 있다
dev.to의 분석이 정확히 짚은 지점이 여기입니다. Generative UI, MCP Apps, Google의 A2UI는 서로 다른 방식으로 같은 문제를 풀려 합니다—매번 네이티브 코드를 새로 배포하지 않고도, 맥락 인식형 인터랙티브 UI를 만들어내는 것. 그런데 각각의 트레이드오프가 극명하게 다릅니다.
- Generative UI (CopilotKit 등): 모델이 컴포넌트·레이아웃·동작을 구조화된 UI 명세로 출력하면 호스트가 렌더링합니다. 속도와 유연성은 최고지만, strict한 contract와 sanitization이 없으면 UI가 제멋대로 튀거나 보안 구멍이 생깁니다.
- MCP Apps (Model Context Protocol): 앱을 MCP 인식 호스트 안에서 돌아가는 조합 가능한 단위로 취급합니다. Claude Desktop 같은 MCP 호스트 안에 플러그인처럼 꽂히는 방식이죠. 컨텍스트 연속성은 훌륭하지만, 호스트마다 다른 extension 집합을 구현하면 파편화가 심해집니다.
- A2UI (Google): 에이전트가 인터페이스를 조율하되, 샌드박스 프로토콜로 안전성을 최우선합니다. 임의 코드 실행 없이 웹·모바일·데스크탑 전반에서 작동하는 것을 목표로 합니다.
dev.to 글이 "하이브리드 스택이 불가피하다"고 결론 내린 것은 맞습니다. 고객 대면 실험에는 Generative UI, 엔터프라이즈 핵심 기능에는 A2UI 계열 제약, 그 사이를 MCP가 잇는 구조. 문제는 이 복합 스택에서 개발자가 어디서 무엇을 책임지는가가 아직 아무도 정의하지 않은 영역이라는 겁니다.
실무 충격 1: Figma 기반 워크플로우의 붕괴
"Figma에서 볼 때는 괜찮았는데, 실제로 구현하면..." 이 말을 몇 번이나 해봤는지 모르겠습니다. 그런데 GenUI 환경에서는 이 말 자체가 성립하지 않습니다. Figma에 시안이 없으니까요.
닐슨은 2026년부터 UX 디자이너의 역할이 "화면을 직접 그리는 것"에서 "AI가 인터페이스를 조립하도록 디자인 토큰·제약·행동 규칙을 정의하는 시스템 디자이너"로 이동한다고 예측합니다. 프론트엔드 개발자 관점에서 번역하면 이렇습니다—우리가 받는 산출물이 Figma 링크에서 컴포넌트 스키마, 이벤트 contract, 행동 정책 문서로 바뀐다는 것.
사실 이건 Design Token과 디자인 시스템을 제대로 운영해온 팀에게는 낯설지 않은 방향입니다. color-surface-primary, spacing-4, border-radius-sm 같은 토큰이 있어야 AI가 조립할 때 브랜드를 유지할 수 있으니까요. 오히려 지금까지 "디자인 시스템은 대기업이나 하는 것"이라고 미뤄온 팀들이 GenUI 전환에서 가장 크게 휘청일 겁니다. 기술 부채가 AI 전환 부채가 되는 순간입니다.
실무 충격 2: 접근성과 성능 — 보장의 주체가 사라진다
이게 저를 가장 밤새우게 만드는 문제입니다.
지금은 제가 aria-label을 달고, tabIndex를 관리하고, Lighthouse 접근성 점수를 100에 맞추려고 씨름합니다. 스크린리더가 버튼을 제대로 읽는지 직접 VoiceOver로 테스트해보고, 색상 대비가 WCAG AA 기준인 4.5:1 이상인지 Figma 플러그인으로 확인합니다. 이 모든 행위의 전제는 내가 렌더링될 DOM 구조를 사전에 알고 있다는 겁니다.
GenUI 환경에서 모델이 런타임에 컴포넌트를 조립하면 누가 이걸 보장합니까? dev.to 글이 "모델 출력을 신뢰할 수 없는 입력(untrusted input)처럼 취급하고 모든 것을 검증하라"고 경고한 건 보안 관점이지만, 접근성에도 똑같이 적용됩니다. 모델이 생성한 UI는 a11y 관점에서 기본적으로 zero-trust여야 합니다.
Core Web Vitals도 마찬가지입니다. 런타임에 UI 트리가 동적으로 구성된다면 LCP(Largest Contentful Paint)와 CLS(Cumulative Layout Shift)는 예측 불가능해집니다. 사용자가 화면을 보는 순간마다 레이아웃이 달라질 수 있는데, 기존의 성능 측정 지표가 여기에 적합한지조차 불분명합니다. 솔직히 말하면 현재의 Lighthouse 점수 체계로는 GenUI를 제대로 평가할 수 없습니다.
실무 충격 3: 감사(Audit) 인터페이스라는 새로운 장르
닐슨이 던진 개념 중 가장 날카로운 것이 바로 이겁니다—"앞으로의 UX 과제는 프롬프트 UI가 아니라, 에이전트의 50단계 추론 과정을 한눈에 검증할 수 있는 감사(Audit) 인터페이스 설계".
프론트엔드 개발자로서 이 문장을 읽자마자 든 생각: "이거 사실 엄청나게 복잡한 데이터 시각화 문제잖아." 50단계 에이전트 체인을 타임라인으로 보여주면서, 각 단계에서 무슨 결정이 있었는지, 어디서 사용자 개입이 필요한지를 직관적으로 표현해야 합니다. 로딩 스켈레톤은 기본이고, 단계별 상태(pending / running / success / failed / awaiting-review)를 시각적으로 명확하게 구분해야 하며, 리뷰 피로(Review Fatigue)를 최소화하는 정보 계층 설계가 필요합니다.
이건 신규 컴포넌트 카테고리입니다. 기존의 <Toast>, <Modal>, <Dropdown> 과는 차원이 다른 복잡도를 가진 에이전트 감사 UI 컴포넌트. 그리고 이걸 설계하는 사람이 결국 프론트엔드 개발자일 수밖에 없습니다. 왜냐면 이 인터페이스는 기술적 구조를 이해하면서 동시에 사용자가 어느 지점에서 인지 과부하를 느끼는지 알아야 만들 수 있으니까요.
시사점: 우리가 지금 당장 해야 할 것
dev.to 글의 6가지 실행 지침 중 프론트엔드 개발자에게 가장 직접적으로 닿는 것은 3번과 5번입니다.
"인터페이스 contract를 명확히 설계하라"—컴포넌트 스키마, 이벤트 명세, sanitization 규칙을 사전에 정의해야 GenUI가 chaos가 아닌 시스템으로 작동합니다. TypeScript의 z.infer<typeof schema> 수준의 엄격함으로 모델 출력을 타입 가드해야 한다는 뜻입니다. 이미 Zod나 Valibot을 써온 팀은 유리합니다.
"관측성과 거버넌스 레이어를 첫날부터 만들어라"—모델이 어떤 UI를 생성했는지, 사용자가 어디서 수정했는지, 어떤 렌더 결정이 데이터 누출 신호를 보냈는지를 추적해야 합니다. 기존의 에러 모니터링(Sentry 등)과는 다른 차원의 telemetry입니다. 이건 지금 당장 설계를 시작해야 할 인프라입니다.
그리고 닐슨이 경고한 것 하나를 더 덧붙이고 싶습니다—Synthetic Users에 과도하게 의존하지 말 것. AI가 시뮬레이션한 가상 사용자로만 테스트하고 실제 사람을 관찰하지 않으면, 결국 GenUI는 "AI가 AI를 위해 최적화한 인터페이스"가 됩니다. 프론트엔드 개발자가 UX 관찰의 마지막 인간 방어선이 되는 시대가 옵니다.
전망: 픽셀 담당자에서 시스템 설계자로
결론적으로, 솔직하게 말하겠습니다.
GenUI 시대에도 프론트엔드 개발자는 사라지지 않습니다. 오히려 역할이 더 중요해질 수 있습니다. 하지만 그 역할의 내용이 근본적으로 바뀝니다. 닐슨의 표현을 빌리면: "화면을 생성하는 시스템의 제약을 설계하고, 판단력을 기준으로 채용"하는 직군으로.
지금 당장 실무에서 이 전환을 준비하는 방법:
- 디자인 토큰과 컴포넌트 스키마 정의에 익숙해질 것. Style Dictionary나 Tokens Studio를 써본 적 없다면 지금 시작하세요.
- 모델 출력을 검증하는 런타임 타입 가드 패턴을 익힐 것. Zod schema로 GenUI output을 검증하는 구조는 이미 실험해볼 수 있습니다.
- a11y를 자동화할 것. axe-core, Pa11y를 CI에 심어 최소한 모델 생성 UI에도 기계적 접근성 검증이 돌아가도록 해야 합니다.
- 에이전트 상태 시각화에 관심을 가질 것. XState나 상태 머신 패턴이 에이전트 감사 UI를 만드는 데 생각보다 훨씬 유용한 기반이 됩니다.
1px 어긋나면 밤을 새우는 성격이 GenUI 시대에 쓸모없어지는 것 아닐까요? 반대입니다. 시스템이 생성한 UI에서 1px의 오류가 어느 contract 위반에서 비롯됐는지 추적할 수 있는 사람이 필요합니다. 그게 우리입니다.