생성형 AI가 UI/UX디자인을 다시 만드는 방법

위 글은 A16Z의 "How Generative AI Is Remaking UI/UX Design"를 번역한 글입니다.

개발자와 프로덕트 매니저였던 우리는 디자이너와 개발자 사이의 고된 협업 과정을 경험했습니다. "이 디자인이 기술적으로 가능한가요?"와 "이 단계에 다른 화면을 추가할 수 있나요?"와 같은 질문들이 매 회의마다 오갔습니다. 이런 교류는 종종 시간 소모적인 반복과 타협으로 이어졌고, 결국 디자이너가 가진 비전과 개발자 사이에 괴리가 생기곤 했습니다.

그러나 지난 10년 동안 브라우저와 프론트엔드 기술의 발전으로 이 과정은 크게 개선되었습니다. 디자인 팀은 디자인 시스템을 채택하고, 로컬에서 혼자 사용하던 디자인 도구에서 Figma와 같은 브라우저 기반 도구로 이동했습니다. 엔지니어링 팀은 Next.js, Flutter, shadcn/ui, Tailwind와 같은 프론트엔드 프레임워크와 라이브러리에 대해 다양한 선택지를 갖게 되었습니다. 이는 시각적 요구 사항과 기능적 요구 사항을 모두 충족할 수 있는 공통 기반을 마련합니다.

발전된 코드 생성 기술과 고급 이미지 모델은 아이디어를 완전한 제품으로 가는 시간을 크게 단축시켰습니다. 이러한 효율성 향상은 창의성의 가능성의 시대를 열어줍니다. 본 글에서는 빠르게 변화하는 AI 인터페이스 디자인 환경을 탐구하고, 이러한 기술들이 열어줄 흥미로운 가능성들을 살펴보고자 합니다.

 

 

예시: AI-Tamago

최근 AI-Tamago라는 사이드 프로젝트를 코딩하며 Vercel v0와 같은 생성 도구를 광범위하게 사용하여 UI를 설계했습니다.

단계는 아래에서 보시는 것과 같았습니다. 각 반복(iteration)에서 우리는 보고 싶은 내용을 더 자세히 설명했고, 때로는 다른 방향으로 되돌아가기도 하면서 LLM을 활용하여 우리가 생각하지 못했던 좋은 아이디어를 찾았습니다.

이 전체 과정은 약 30분 정도 걸렸습니다. 디자이너와 개발자를 동시에 진행하는 경우, 이는 위 사례와 같이 디자인과 구현 간의 여러 단계를 반복 하는 것이 훨씬 쉽습니다. 디자이너와 개발자로 구성된 팀과 협력할 때는 반복 과정은 더 많은 협의와 수정을 낳습니다. 이는 곧 더 복잡하고 번거로운 워크플로우로 이어지게 됩니다.

우리는 화면에 보이는 것(디자인)과 코드로 구현된 것의 차이를 메우기 위해 많은 시간과 에너지를 소비합니다. 제품이 많은 상태와 복잡한 예외 케이스를 가지는 경우, 디자이너가 디자인된 이미지에 모든 것을 적는 것은 어렵습니다. 그 결과 대부분의 문제는 QA 및 테스트 중에만 발견되며, 이를 수정하기 위해 여러 단계를 되돌아가야 합니다.

하지만 생성형 AI 기술은 빠른 프로토타이핑과 코드 완성에 적합하기 때문에 이 반복 과정의 많은 간극을 메울 수 있다고 믿습니다.

 

 

AI 기반 인터페이스 생성의 현황

오늘날의 생성형 AI 기술은 두 가지의 중요한 일을 합니다. 먼저 LLM이 디자인에 대한 의견을 제공합니다. 각 프롬프트가 목업을 제공하면서, 창의성을 고취시키는 데 초점이 맞춰집니다. 즉, 디자인 작업은 1px 단위의 픽셀 조작이 아닌, 창의적인 아이디어를 내는 것이 되었습니다. 디자이너는 세부 사항을 맞추는 대신 사용성과 구성 부분에 에너지를 쏟을 수 있습니다.

동시에, 디자인을 실제 작동하는 앱으로 만드는 시간이 극적으로 단축되어 빠른 프로토타이핑이 가능해졌습니다. 이제 코드와 디자인을 모두 작업하는 “디자인 엔지니어”가 눈에 띄게 많아졌고, 이들은 디자인과 구현 간의 괴리를 줄이며 프로토타입을 만듭니다.

이 두 가지 트렌드의 영향으로, 디자인에서 구현까지의 워크플로우를 혁신하는 도구들이 속속 등장하고 있습니다.

우리가 본 접근 방식은 세 가지 주요 기능으로 분류될 수 있습니다:

• 디자인 프로세스 해결
• 디자인 → 코드 변환 해결
• 코드 생성 해결

 

디자인 프로세스 해결

디자인 프로세스는 원래 복잡합니다. 그래서 디자이너에게 더 나은 도구를 제공하여 다양한 아이디어를 쉽게 탐색하고, 픽셀 단위로 맞추는 작업 등 소모적인 작업을 없애는 것이 매우 중요합니다.

“디자인을 위한 코파일럿”(아래에 Galileo를 사용한 예시처럼)은 이 아이디어에서 목업으로 가는 과정을 더 협력적이고 상호작용적으로 만듭니다. 디자이너가 빈 캔버스에 추상적인 아이디어를 그리는 대신, 대략적인 아이디어를 기반으로 새로운 디자인을 만들고 “알지 못하는 것을 탐색”하는 데 도움이 되는 방식으로 시각화할 수 있습니다.

 

디자인-코드 변환 해결

이 단계는 아마도 가장 많은 마찰이 발생하는 단계일 것입니다. 이는 마치 하나의 언어에서 다른 언어로 번역하는 것과 같습니다. 디자인과 엔지니어링은 다른 언어를 사용하며, 번역 과정에서 항상 무언가가 사라집니다. 그러나 생성형 AI 모델은 다양한 데이터셋에 대한 학습이나 미세 조정을 통해 프로그래밍 언어, 디자인 원칙 및 UX 지침에 대한 정교한 이해를 발전시켰습니다. 또한 Tailwind와 같은 UI 템플릿 및 프레임워크를 적용할 수 있는 능력을 갖춘 LLM은 이제 기능적이고 미적으로 만족스러운 UI 요소를 생성할 수 있습니다.

이 능력은 단순히 디자인 개념을 코드로 번역하는 것이 아니라, 최신 트렌드에 대한 인식과 모범 사례를 적용하고 기존 프레임워크를 활용하는 것입니다.

개발자로서 이 “번역”이 얼마나 깊이 이루어지는지 궁금할 것입니다. 스타일만 복제하는 것인가, 아니면 실질적인 내용도 복제하는가? 정적 자산을 사용하여 전달할 수 없는 상호작용은 어떻게 되는가? 로그인 페이지를 디자인하면 코드 생성이 Clerk와 같은 서비스를 사용하거나 React Email의 구성 요소를 사용하고 싶다는 것을 알고 있는가?

오늘날 대부분의 솔루션은 시각적 스타일을 복제하는 데 중점을 두고 있습니다. 그러나 더 많은 컴포넌트 서비스 회사들이 성숙해지거나 Devin과 같은 코딩 에이전트가 증가하면, 잘 정의된 기능과 React 라이브러리와 직접 통합하는 것이 가능해져 디자인에서 기능적인 앱으로의 사이클을 완성할 수 있을 것입니다. 특히 문제가 잘 정의되었거나 일반적인 UI 요소를 포함하는 경우, 이러한 워크플로우의 기능을 직접 다루는 미세 조정 모델을 볼 수 있을 것입니다.

인증, 사용자 관리, 이메일 전송, 알림, 문서화 및 차트 표시와 같은 사용 사례는 대부분의 비즈니스 애플리케이션에서 공통적입니다. Clerk, Mintlify, Knock, React Email(Resend), Tremor와 같은 수직적으로 통합된 컴포넌트 덕분에 LLM은 이러한 사용 준비가 된 컴포넌트를 활용하여 백엔드 시스템과 깊이 통합된 UI를 생성할 수 있습니다.

 

코드 생성 해결

디자인 목업과 그 구현은 결코 1:1이 아니기 때문에, 정적 목업은 최종 디자인이 어떻게 보여야 하는지에 대한 정보를 제한적으로 제공할 수밖에 없습니다. 엔지니어가 이 디자인을 구현할 때, 실현 가능성과 상호작용 역학, 그리고 미학에 대한 빈틈을 채워야 합니다.

이 때문에 빠르게 움직이려는 많은 팀들은 새로운 UI를 디자인할 때 코드를 기준으로 삼습니다. 이 팀들은 처음부터 디자인 개념을 기능적인 프로토타입으로 바꾸어 디자인 문제를 코딩 문제로 전환합니다. 이런 접근 방식은 특히 상호작용이 많은 제품이나 빠르게 반복하고 테스트해야 하는 프로젝트에 유리합니다. 이 방식은 체계적이거나 세부적이지 않을 수 있지만, 빠르게 움직이는 스타트업이나 개발 도구에 매우 적합합니다. 특정 디자인 단계를 생략하여, LLM은 기존 컴포넌트 시스템을 가진 앱의 관련 부분을 사용해 최종 제품의 반복을 훨씬 더 빠르게 만듭니다.

시장에서는 아직 이러한 문제를 해결하기 위한 초기 단계에 있으며, 디자인 스캐폴딩을 통한 코드 생성이 답이 될지는 두고 봐야 하지만, V0, MagicPatterns, RapidPages와 같은 제품들이 이 문제를 해결하기 위한 첫 번째 원칙적인 시도를 하는 것을 볼 수 있습니다.

 

미래를 그리다: 생성형 AI를 통한 동적 및 적응형 UI

멋진 기술과 개발자 및 디자이너를 위한 효율성 향상 외에도 동적 UI 생성을 활용한 새로운 소프트웨어 인터페이스에서 몇 가지 흥미로운 진전이 있습니다.

상태 기반 동적 UI

예를 들어, 기존 인터페이스는 종종 비즈니스 로직을 직접 반영합니다. 사용자 기반 A/B 테스트가 있지만, 이러한 테스트는 하드코딩되어 설정하고 모니터링하는 데 많은 인간의 개입이 필요합니다. LLM의 도구 사용 및 추론 능력은 이를 변화시키고 있습니다.

우리는 종종 "LLM과 상호작용하기 위한 올바른 인터페이스는 무엇인가?"라는 질문을 듣습니다. 그러나 UI/UX 디자인 분야에서 더 흥미로운 질문은 "기존 인터페이스 중 어떤 것을 제공하는 것이 가장 도움이 될 수 있도록 LLM에게 어떤 데이터를 제공해야 하는가?"입니다.

예를 들어, Vercel의 AI SDK에서는 채팅에 표시되는 구성 요소가 애플리케이션 상태에 따라 LLM이 선택한 것입니다. 사용자가 비행기를 변경해야 하면, 새로운 비행기를 선택하기 위한 적절한 구성 요소를 제공합니다.

또 다른 예로는 Coframe의 동적 이미지 및 텍스트 변형 제공 구현이 있습니다. 웹 앱에서 가장 작은 원자 요소는 텍스트와 이미지이며, LLM 및 이미지 모델은 둘 다에 대한 변형을 생성하는 데 뛰어납니다. 이 흐름에서 LLM은 실시간 데이터를 기반으로 언제 변형(생성된 텍스트 또는 이미지)을 제공할지를 결정하여 웹사이트 성능을 최적화합니다.

Using Coframe to dynamically update the tagline for the multi-modal starter kit.

위의 두 예시는 "함수 호출"의 UI 버전입니다. UI 구성 요소는 본질적으로 함수이며, LLM에게 탐색하고 추론할 수 있는 시각적 상태 공간을 제공합니다. 이는 동적 UI가 가까운 미래에 어떤 모습일지 형식화하는 첫 단계이며, 이후에는 텍스트/이미지의 가장 작은 단위에서부터 사용자 페르소나, 상태, 장치 및 환경 제약에 따라 인터페이스를 완전히 적응시키는 더 많은 맞춤화를 가능하게 합니다.

 

완전히 적응형 소프트웨어 인터페이스

그러나 오늘날의 동적으로 제공되는 UI는 정확성과 미학을 보장하기 위해 여전히 하드코딩된 구성 요소 상태를 필요로 합니다. 적응형 UI는 스펙트럼의 다른 쪽 끝에 있으며, 사용자 요구에 완전히 맞춘 인터페이스를 생성합니다.

예를 들어, Salesforce나 Netsuite를 사용해 본 사람은 끝없는 탭과 필드를 잘 알고 있을 것입니다. 워크플로우가 복잡해질수록 화면을 더 많이 차지합니다. 대부분의 엔터프라이즈 소프트웨어가 기본 데이터베이스 스키마를 반영하며, 각 읽기 및 쓰기는 자체 화면 자산을 필요로 한다고 해도 과언이 아닙니다.

사용자의 의도에 맞게 UI가 적응하는 세계에서는, 인터페이스가 중첩된 메뉴와 필드를 탐색하는 대신 간단한 프롬프트를 통해 구성 요소를 즉시 구성하거나 이전 작업에서 유추할 수 있습니다. 예를 들어, 상황 인식 CRM에서는 사용자가 "리드에 대한 기회를 입력"하라고 프롬프트하면, UI가 답변을 미리 선택하고 불필요한 필드를 삭제하여 워크플로우를 간소화할 수 있습니다.

이러한 적응형 UI의 영향은 고객 여정의 모든 단계에 깊은 영향을 미칠 것입니다. 새로운 사용자에게는 길고 복잡한 온보딩 및 교육 과정을 단축시켜 즉각적인 aha 순간과 가치 인식을 제공합니다. 숙련된 사용자에게는 다단계 워크플로우를 완료하기 위해 여러 화면과 수많은 클릭을 간소화합니다. 고정된 경계 상자가 사라지면서, 브라우저 자동화 산업에 대한 영향도 흥미로운 생각 실험이 될 것입니다. 워크플로우는 단순한 DOM 수준의 제어 대신 각 구성 요소의 의미에 따라 구동되어야 합니다.

한 걸음 더 나아가, API와 데이터 모델이 고정된 특정 앱의 경우, 사용자 인터페이스는 설계되지 않고 유추될 수 있습니다. 이는 주로 기존 데이터베이스에 대한 CRUD 작업이 주된 내부 애플리케이션에서 일반적입니다. 인터페이스의 주요 목표는 데이터 유형을 제어하고 검증하며 액세스를 제어하는 것입니다. Airtable이나 Smartsheet와 같은 기존의 노코드 앱은 데이터를 CRUD 앱으로 전환하여 순수 규칙 기반 접근 방식으로 이를 구현했지만, AI의 발전은 애플리케이션 개발을 다음 단계로 끌어올리고 있습니다.

 

 

앞으로의 길

일상 소프트웨어에서 생성형 UI의 적용은 여전히 초기 단계에 있습니다. 그러나 Vercel, Galileo, Coframe 등에서 제시한 예를 통해 미래가 가까워지고 있음을 알 수 있습니다. 이 생성형 UI의 물결이 흥미로운 이유는 엔지니어와 디자이너의 행동 변화를 가져왔을 뿐만 아니라, 이러한 변화를 가능하게 하고 미래 가능성을 창출하는 기술 때문입니다.

가장 흥미로운 기능 중 하나는 멀티모달 모델의 발전입니다. 모델이 시각적으로 본 것을 언어(코드를 포함한 형식 언어)로 정렬할 수 있다는 것을 이제 알고 있습니다. 이는 인간 디자이너 엔지니어가 하는 일을 반영합니다. 그들은 머릿속에 디자인할 아이디어를 가지고 있으며, 코드를 사용하여 세부 구현을 구체화합니다. 멀티모달 데이터로 훈련된 모델은 무엇을 생성할지, 어떻게 편집할지, 무엇을 제공할지 결정하는 데 더 중심적인 역할을 할 것입니다.

AI-Tamago를 코딩하면서 해결해야 했던 흥미로운 문제 중 하나는 LLM에게 ASCII 애니메이션 프레임을 생성하도록 가르치는 것이었습니다. 이를 통해 단어를 이미지 삽화로 직접 벡터 형식으로 생성하는 연구를 발견했습니다. 이 경우, 텍스트-이미지 확산 모델(VLM)을 사용하여 LLM이 간과할 수 있는 시각적 피드백을 제공했습니다. 이 작업은 잘 정의된 확산 기반 생성과 공식적인 프론트엔드 프로그래밍 언어 간의 균형점을 찾으면 UI 생성에 적용될 수 있습니다.

마지막으로, 미적으로 만족스러운 코드 생성은 구조화되고 고품질의 데이터를 자연스럽게 많이 보유하고 있는 드문 문제 중 하나입니다. 인터넷에는 Tailwind, Chakra UI와 같은 훌륭한 예시와 잘 만들어진 템플릿이 많이 있으며, 생성된 결과는 프레임워크 전용 코드를 추상화할 수 있습니다. 미래는 오늘날의 프론트엔드 프레임워크가 하위 수준 API를 추상화하는 것과 비슷하게 구조화된 코드가 있는 모델 기반 생성으로 보일 수 있습니다.

우리는 이 공간에서 제품이나 도구를 작업 중인 사람들의 더 많은 훌륭한 아이디어가 나올 것이라고 믿습니다. 이 주제에 대해 작업 중이라면, 여러분의 이야기를 듣고 싶습니다!