레이아웃 적응에서 의도 적응으로
지난 10년간 프론트엔드 개발자들이 가장 잘 해온 일은 '화면 크기에 맞춰 UI를 유연하게 바꾸는 것'이었다. 반응형 디자인은 "하나의 고정 레이아웃이 모든 기기를 커버할 수 없다"는 현실을 인정하면서 시작됐고, 미디어 쿼리와 유연한 그리드 시스템이 그 해법이었다.
그런데 지금 프론트엔드가 마주한 진짜 새로운 문제는 화면 크기가 아니다. 사용자의 의도다.
dev.to에 올라온 "Generative UI Is the New Responsive Design"은 이 전환을 날카롭게 짚는다. AI 제품이 단순 텍스트 스트리밍을 넘어서는 순간, '입력창 하나 + 응답 영역 하나'라는 인터페이스 패러다임은 금세 한계를 드러낸다. 항공편 검색 결과, 데이터 비교표, 파일 업로드 트리거—이 모든 것을 마크다운 덩어리로 뱉어내는 건 모델이 구조화된 데이터를 생산했음에도 UI가 그것을 '텍스트 컨테이너'에 가두는 셈이다.
구조화 출력이 없으면 Generative UI는 허상이다
Generative UI의 핵심은 모델 출력을 UI 결정으로 번역하는 중간 레이어다. Vercel AI SDK가 보여주는 방향이 정확히 그것이다—스키마로 출력 형태를 계약하면, 프론트엔드는 신뢰할 수 있는 구조를 받아 목적 있는 렌더링을 할 수 있다. 추천 항목은 카드로, 비교 데이터는 테이블로, 로딩 상태는 의미 있는 스켈레톤으로.
이건 단순히 "AI 응답을 예쁘게 보여주는 것"이 아니다. 컴파일 타임에 완전히 결정되지 않은 인터페이스 상태를 런타임 모델 결정에 따라 구성하는 아키텍처 패러다임이다. 반응형 디자인이 '뷰포트 조건에 따라 레이아웃을 결정'했다면, Generative UI는 '모델의 판단에 따라 인터페이스 형태를 결정'한다. 트리거가 다를 뿐, 사고방식은 같다. 제약을 정의하고, 유연한 프리미티브를 만들고, 런타임 조건이 최종 UI를 결정하게 하는 것.
Claude Design이 건드리는 것: 디자인-개발 경계의 용해
이 흐름에 기름을 붓는 사건이 동시다발로 일어나고 있다. Anthropic이 최근 공개한 Claude Design은 Claude Opus 4.7 기반으로 텍스트 입력만으로 인터랙티브 프로토타입, 슬라이드, 기획서를 생성한다. 팀의 기존 디자인 시스템(색상, 타이포그래피, 컴포넌트)을 코드베이스나 디자인 파일로 학습시키면 브랜드 일관성을 자동으로 유지하면서 결과물을 뽑아내고, Claude Code와 연결해 구현 단계까지 바로 이어진다.
어도비·피그마 주가가 출시 당일 즉각 반응한 것은 시장이 이 파급력을 직감했기 때문이다. 하지만 더 중요한 질문은 "피그마를 대체하느냐"가 아니다. Claude Design이 진짜로 건드리는 것은 디자이너와 개발자 사이의 핸드오프 구조 자체다. 프로토타입이 곧 코드로, 코드가 곧 디자인 시스템의 검증 결과로 순환하는 루프가 생기면, 기존의 선형적 디자인-개발 협업 모델은 근본부터 재설계가 필요해진다.
물론 현장의 시선은 복잡하다. "디자인 공해(Slop)가 넘쳐날 것"이라는 경고처럼, AI가 생성하는 결과물이 시각적으로는 그럴싸해 보여도 실제 사용성을 고려한 세밀한 설계나 독창성이 부족하다는 지적은 여전히 유효하다. 생성 속도와 설계 깊이 사이의 긴장은 Generative UI 시대에도 해소되지 않는 핵심 과제다.
MCP로 AI가 짠 코드의 품질을 잡는다
Generative UI가 UI 생성 쪽의 문제를 건드린다면, 생성된 코드의 품질 유지 문제는 또 다른 축이다. AI 코딩 에이전트들이 '동작하지만 유지보수가 어려운' 코드를 양산하는 현실은 이미 많은 팀이 체감하고 있다.
dev.to에 공개된 오픈소스 프로젝트 design-pattern-mcp는 이 문제를 MCP(Model Context Protocol) 레이어에서 구조적으로 다룬다. 두 가지 도구—suggest_pattern과 get_template—를 AI 에이전트에 노출함으로써, 에이전트가 코드를 생성할 때 GoF 패턴부터 CQRS, 헥사고날 아키텍처까지 35개 이상의 패턴 가이드를 컨텍스트로 주입받는다. 핵심은 토큰 효율성이다. 제안은 50~100토큰, 템플릿은 300~500토큰으로 압축해 컨텍스트 낭비 없이 구조적 제약과 안티패턴 경고를 전달한다.
이 접근의 의미는 단순히 '좋은 코드를 유도한다'는 것 이상이다. MCP가 AI 에이전트의 외부 도구 호출 표준으로 자리잡으면서, 소프트웨어 엔지니어링 모범 사례 자체를 에이전트 워크플로우에 인프라 수준으로 내재화하는 것이 가능해졌다. 데이터 접근 중심이었던 MCP 생태계에 코드 품질·아키텍처 가이드라는 새로운 카테고리가 열리는 것이다.
진짜 병목은 렌더링이 아니라 제어다
세 기사를 관통하는 공통 긴장이 있다. Generative UI 논의에서 자주 간과되는 것은 "모델이 멋진 컴포넌트를 즉석에서 렌더링한다"는 데모 차원의 흥미가 아니라, 모델이 UI 형태를 제안할 때 상태의 소유권은 누구에게 있는가라는 아키텍처 질문이다.
- 툴 결과가 느리거나 불완전할 때 fallback은 어떻게 처리하는가?
- 런타임에 일부가 결정되는 플로우를 어떻게 테스트하는가?
- 모델에게 얼마만큼의 UI 결정 자유를 줄 것인가?
이것은 프롬프트 엔지니어링 문제가 아니다. 상태 머신, 유효성 검증, 폴백 경로, 디버깅—전통적인 프론트엔드 아키텍처 문제 위에 확률적 시스템이 하나 더 얹히는 것이다. Claude Design이 디자인 시스템을 학습해 자동화하는 과정에서도, MCP 서버가 에이전트의 패턴 구현을 안내하는 과정에서도 동일한 질문이 반복된다—AI의 결정과 인간의 통제 사이에서 경계를 어디에 그을 것인가.
설계 원칙의 이동: 지금 프론트엔드 개발자가 챙겨야 할 것
Generative UI는 새로운 것처럼 보이지만, 결국 오래된 원칙의 재적용이다. 반응형 디자인이 "유연한 프리미티브 + 런타임 조건"으로 뷰포트 문제를 풀었듯, Generative UI도 같은 방식으로 의도 적응 문제를 푼다. 달라진 건 런타임 조건이 '화면 크기'에서 '모델의 구조화 출력'으로 바뀐 것뿐이다.
실무 차원에서 지금 챙겨야 할 세 가지를 정리하면 이렇다.
- 스키마 계약 먼저: 모델 출력을 raw 텍스트로 받는 순간 Generative UI는 막힌다. Zod나 JSON Schema로 출력 형태를 계약하고, 그 계약 위에서 컴포넌트를 설계하는 습관이 필요하다.
- AI UI 프리미티브 라이브러리 검토:
assistant-ui같은 컴포저블 AI UI 프리미티브는 헤드리스 컴포넌트 라이브러리가 디자인 시스템에 한 것을 AI 인터랙션에 반복한다. 바퀴를 재발명하기 전에 먼저 살펴볼 가치가 있다. - MCP 레이어의 코드 품질 거버넌스: AI가 생성한 코드가 코드베이스에 쌓이는 속도는 팀의 리뷰 속도를 앞선다. design-pattern-mcp처럼 구조적 제약을 에이전트 워크플로우에 인프라 수준으로 내재화하는 접근이 점점 현실적인 선택지가 된다.
Generative UI가 흥미로운 이유는 정확히 그것이 불편한 이유와 같다. AI 제품을 '진짜 소프트웨어 엔지니어링'의 영역으로 되돌려놓기 때문이다. 그리고 그 설계 원칙을 다시 쓰는 것은, 여전히 사람이 해야 할 일이다.