피그마와 스티치

by 이선주

AI를 사용한 디자인 프로세스를 확인하고, 현재 가진 툴로 더 큰 생산성을 만들 수 있는 방법을 생각합니다. 구글의 Stitch를 통해서 또 여러 단계를 거치는 프로덕트를 AI와 구성해 보고, 장단점을 생각해봅니다.



갈릴레오 AI(Galileo AI)와 스티치(Google Stitch)


AI 디자인은 흔히 전문가들이 '자연어'라고 말하는 일상에서 쓰는 용어로 디자인 결과물을 얻을 수 있습니다. 바로 디자인을 얻을 수 있기 때문에 기존의 문서와 디자인 프로세스는 모두 사용하지 않게 됩니다.


스티치는 갈릴레오 AI를 구글이 인수하여 만들어진 프로덕트입니다. 사용방법은 비슷하지만 구글 제미나이를 사용해서 텍스트뿐 아니라, 이미지나 손으로 그린 화이트보드의 이미지를 사용해서 생성할 수 있습니다.


갈릴레오 AI는 이미 만들어진 컴포넌트를 조합해 주는 AI와 달리 피그마에 맞게 레이어 구조를 만든 후, SVG 형태로 피그마에서 작업을 이어갈 수 있게 만들어줬습니다. 이때, 만들어진 AI 결과물의 색상이나 Radius를 조정할 수 있어서 많은 관심을 받았습니다.


당시에는 피그마 레이어에 이름을 써주는 것도 황송하던 때였다.


하지만 갈릴레오 AI의 경우, 디자인이 하나의 스타일로 제한되고, UI에 사용되는 이미지 리소스의 생성 및 사용이 제한된 상태였습니다. 피그마로 가져올 경우, 장점은 레이어의 구조가 미리 잡혀 있어서 편리하지만, 활용하기는 어려웠습니다.



제미나이를 사용하는 스티치는 프롬프트를 UI로 만드는 것을 넘어서 테일윈드(Tailwind) 기반의 코드와 React/HTML로 생성해 줍니다. 그래서 Figma로 내보내기를 하는 경우의 장점은 좀 줄어들었습니다.


기존의 갈릴레오 AI의 경우, 코드가 아닌 SVG 이미지로 생성하기 때문에 개발자가 디자인을 바로 사용할 수 없었습니다. 스티치는 테일윈드를 사용하여 디자인을 바로 코드로 만들고, 그 코드의 디자인을 다시 피그마로 내보낼 수 있습니다.


테일윈드를 사용하면서 스티치는 이미지 생성보다는 코드를 생성하는 툴이 되었고, 코드도 바로 생성하는 게 아니라 이미 제작되어 있는 테일윈드 클래스를 조합하여 제작되는 방식으로 구조적인 코드가 생성됩니다.


특히 UI 제작에서 어려운 부분인 컨테이너 클래스 사용과 스타일의 구분이 명확하고 컴포넌트의 State(active, hover 등)를 선언할 수 있습니다. 그래서 스티치의 프로젝트에서 추가적인 스크린을 제작하는 경우 UI와 디자인 스타일의 일관성을 지킬 수 있습니다.


개발자가 사용하기는 쉽지만, 디자이너가 직접 수정할 때는 갈릴레오 AI에서 크게 나아지진 않았습니다.



나노 바나나와

스티치를 사용한 프로세스


Stitch는 왼쪽의 사이드바에서 프롬프트를 사용해서 결과물이 만들어가는 과정을 볼 수 있습니다. 작업을 진행하는 과정에서 이미 작업된 결과물에 수정을 반복해서 진행할 수 있다는 점이 장점입니다.


단 수정을 하게 되면 이전 버전을 덮어쓰게 되고, 되돌리기 어려우니까(방법을 찾지 못한 걸 수도...) 복제본을 만들어가며 작업하는게 좋을 듯 합니다.


디자인은 환경과 사용 방법에 따라 변수가 많아지기 때문에 AI와 대화를 통해 작업을 조정할 수 있는 절차가 추가되면서, 질문이 다소 부족해도 AI가 보강해줍니다. 사용자가 간단한 질문을 해도 스티치는 이 질문을 실행하기 위한 구체적인 정보를 추론하여 적절한 UI를 생성해 줍니다.


스티치는 추론과 생성 과정에서 구글에서 제공하는 AI인 제미나이를 사용하므로 제미나이와 나노 바나나를 통해서 생성해 보았습니다.


제미나이에서 만드는 기획안


일단 제미나이 Pro 모드로 "식당에서 대기열을 등록하고 확인할 수 있는 디지털 프로덕트의 UI 디자인을 생성."을 요청하면, 제미나이는 이 대화를 "레스토랑 웨이팅 시스템 UI/UX 기획안"으로 이름 짓습니다.


그리고 다음의 단계를 거쳐 기획안을 만듭니다.

Defining the User Interface

Visualizing the Interface

Crafting UI Elements

Detailing the Rationale

Generating the Final Visual

Shifting to Text-Based Design

Detailing User Flow and Considerations


전반적인 프로세스는 인간 디자이너와 비슷한 절차를 진행합니다. 각각의 프롬프트를 새로 생성하고, 질문을 새로 만든 후에 텍스트 결과물을 내놓습니다.


Pro의 사고 과정은 사람의 질문에서 부족한 부분을 보충해 줍니다.


"지금 레스토랑 대기자 명단을 관리하는 디지털 제품의 사용자 인터페이스 디자인에 집중하고 있습니다. 사용자의 목표와 핵심 기능, 특히 대기열 등록 및 상태 확인 기능을 분석하기 시작했습니다. 이러한 초기 분석은 디자인 범위를 정의하는 데 매우 중요합니다."


조금 더 구체적인 다음 단계를 보면,


"이제 세부적인 부분에 집중하여 등록과 상태 확인 모두에 대한 사용자 흐름을 설계하고 있습니다. 이미지 생성 도구를 활용한 시각적 표현과 간결한 UX 설명 작성에 주력하고 있습니다. 등록 UI는 크고 명확한 버튼과 직관적인 입력 과정을 강조할 것입니다. 상태 확인 화면에서는 대기 시간, 순서, 대기열 번호를 이해하기 쉬운 방식으로 표시해야 합니다."


디자인의 경험이 있다면, 어떤 부분이 AI에게 필요한지 확인할 수 있고, 인간이든 AI든 필요한 정보의 내용은 크게 다르지 않다는 것을 알 수 있습니다. 또 기획에 대한 사전 지식이 없더라도 프롬프트 처리 과정을 보강하여 더 좋은 프롬프트를 만들 수 있습니다.


제미나이에서 만든 텍스트로 나노 바나나로 이미지를 생성



제미나이에서 만들어진 기획안을 스티치를 통해서 생성해 봤습니다. 보편적인 디자인으로 필요한 기능은 적절하게 들어 있지만, 이 앱이 개발되기 위한 장치들은 잘 보이지 않습니다.


스티치에서 디자인 생성


프롬프트가 아닌 사고 과정(보강된 질문)을 통해 만든 경우


이 결과는 제미나이가 만든 기획안이 아닌, Pro의 사고 영역을 바탕으로 생성한 디자인입니다. 제미나이는 사고 과정을 볼 수 있는데, 사용자가 모호하게 입력한 내용에서 부족한 부분을 채워줍니다. 영문 내용을 그대로 사용하여 스티치에 생성을 요청했습니다.


제미나이가 생성한 기획안을 적용한 경우, AI가 질문을 보완하여 결과물의 질을 향상 시킵니다.


이 버전은 제미나이가 최종적으로 완성한 기획안을 사용하여 만든 결과물입니다. 스티치에서 모바일 옵션을 선택하여 만들었지만, 세부항목이 이미지에 비해서 훨씬 명확하고, 숙련된 인간 디자이너가 작업한 결과와 유사합니다.


프롬프트의 텍스트 외에도 제미나이 도입을 통한 멀티-모달 작업이 가능하기 때문에 스크린샷이나 화이트보드의 내용도 읽을 수 있습니다.



디자인을 확장하기 위해서는 스티치에서 계속해서 페이지를 생성하는데, Design System을 추가하셔야 합니다. 생성된 디자인을 유지하려면, 꼭 "Create from~내가 선택한 스크린"을 선택하셔야 합니다.


이렇게 생성하면, 해당 프로젝트 전체에 포함된 스크린에 반영되는 Tailwind Config 부분이 수정됩니다.


Google AI Studio


이 결과물을 피그마로 옮기거나 AI Studio로 옮겨서 사용할 수 있습니다. Google AI Studio는 생성된 UI 디자인을 실제로 작동하도록 만들 수 있습니다. 예약을 진짜로 해보거나 예약 후에 사용자에게 전송될 메시지를 테스트해 볼 수도 있습니다.


Google AI Studio와 Vertex AI가 있는데, Vertex AI는 Google Cloud Platform(GCP)가 필요합니다. Google AI Studio로 충분히 테스트를 거치고, 프롬프트에 제미나이가 어떻게 반응하는지 확인한 후에 실제 제품으로 확장할 경우 Vertex AI를 활용해 볼 수 있습니다.




디자인 프로세스의 변화


기존의 작업은 리서치부터 시작하여 현장의 맥락을 읽고, 데이터와 프로세스를 정의하여, 디자인으로 정리되는 과정을 거쳤습니다. 각 과정에 맞게 숙련된 인간 개발자가 이전 사람의 작업의 이어받아 작업을 하고, 이 작업에서 일관성을 유지하고, 품질을 높이기 위해서 커뮤니케이션이 필요합니다.


여기서 커뮤니케이션은 친근한 대화가 아니라, 다음 작업에 필요한 정보를 전달하는 겁니다. 보통은 PPT 혹은 엑셀로 구성된 명세서를 전달했습니다. 피그마는 PPT와 엑셀 없이 각 개발자가 필요한 정보를 Dev 모드를 통해 공급하는 프로세스를 만들고, 베리어블과 컴포넌트 베리언트를 지원하는 디자인 시스템으로 통합하였습니다.



피그마는 디자인 업무에서 작업의 통합과 일관성 있는 기준을 적용하는 프로세스를 만들어냈습니다. 숙련도가 낮아도 정리된 작업 환경에서 디자인 리서스를 운영할 수 있게 되었습니다.


반대로 말하면, 그래픽이나 비주얼 디자인을 하는 디자이너보다 적은 노력으로 큰 성과를 낼 수 있는 포지션을 얻었습니다. 하지만 전체 프로젝트의 방향성이 디자인에서 한걸음 더 개발 쪽으로 움직이는 계기가 되었습니다.



AI를 사용한 프로세스는 Figma의 프로세스에서 숙련도를 더 제거하고, 디자인 리소스의 조달을 통합한 상태입니다. 이론적으로 제미나이는 아주 적은 정보만 주어도 숙련된 UX 디자이너나 프로덕트 디자이너처럼 좋은 제품을 만들 수 있는 조언을 해줍니다.


스티치는 화려하진 않지만, 기능 중심의 프로덕트를 만들 수 있는 초기 코드를 줍니다. 여기에 AI 스튜디오를 사용하면, 실제로 작동하는 것처럼 테스트해 보고 보완할 수도 있습니다.


피그마는 AI 프로세스에서는 조금 더 보조적인 역할을 수행합니다. 스티치에서 생성한 디자인을 가져오는 일은 이전 갈릴레오 AI 때와 같고, 레이어의 구조도 구성되어 있지만, 여전히 여기서 디자인을 진행하는 것은 어려운 일입니다.


디자인 시스템이 구성되어 있지만, 피그마에서는 훨씬 더 많은 옵션을 활용하므로 작업에 방해가 됩니다. 그래서 여전히 피그마에서 작업 구성은 피그마에서 하는 것이 시간과 노력을 고려했을 때 유리합니다. 숙련된 디자이너와 개발 팀은 여전히 피그마를 사용하겠지만, 예전처럼 주니어의 급속한 유입으로 급성장하기는 어려워 보입니다.



피그마를 사용하는 디자이너가 유의해야 할 점은 코드 중심의 디자인입니다. 프로덕트를 개발할 때 기능부터 생각하는 사람은 적습니다. 대부분 비즈니스나 마케팅 혹은 트래픽처럼 성과 중심으로 생각합니다.


기능을 명확하게 설명해야 UX와 UI를 잘 만들 수 있습니다. 구현되지 않으면, 사용되지 않고, 사용되지 않으면 사용자는 없고, 개선도 없습니다. 하지만 어느 시점부터 UX 트렌드가 약해지기 시작하자 리서치와 테스트 작업이 요식행위가 되고, 다시 기획자 시절의 작업 형태로 돌아가버리면서 많은 작업이 형식적인 절차로 변해버렸습니다.


또 코드나 디자인을 무시하고, 정해진 템플릿을 반복하면서 기존의 방식을 최대한 응용하는 방식이 보편적인 프로세스가 되었습니다.


그에 비해 AI 디자인은 사용자 리서치가 아닌 기능의 실현 중심에서 코드를 기반으로 실행되고, 불필요한 커뮤니케이션 없이 핵심적인 요소를 찾아내어 실행합니다.




AI 디자인의

단점과 한계


AI 디자인 프로세스와 구성 요소의 연결은 효율적으로 보이지만, 한계점도 명확합니다. 사람이 일관성이나 목표를 관리하지 않으면, 의도한 결과를 얻기 어렵다는 점입니다.


믿기 어렵겠지만, 실제로 제품을 완성하여 운영한 경험이 있는 사람이 그렇게 많지 않고, 프로덕트 제작에 참여하는 인력들은 아직도 자신의 영역 안에 안주하는 경향이 있습니다. 자신의 업무 영역 안에서 이루어지는 AI 모델의 성과가 모든 것을 바꾸거나 인력을 대체한다고 생각합니다.


하지만 예시로 본 제미나이와 스티치, 테일윈드의 조합은 이론적으론 일관성 유지와 디자인 시스템 구성에서 높은 평가를 받을 수 있지만, 실제로는 이렇게 만들어진 제품을 지속적으로 업데이트하여 시장에서 살아남을 수 있게 성장시켜야 합니다.


그 과정에서 개별 요소의 수정과 보강이 꼭 필요하고, 이러한 활동을 개발자들은 보통 '유지보수'라고 부릅니다. '유지보수'는 제품의 출시 당시 수준을 유지하는 게 아니라 경쟁 상황에서 제품의 품질을 유지하는 겁니다. 유지보수는 다양한 측면에서 이루어지는데, 프로덕트가 앱스토어나 인터넷에 게시(Publish)된 후, 유입 트래픽 분석부터 신규 기능 추가까지 매우 다양한 영역을 포괄합니다.


'유지보수' 과정에서 테일윈드의 프레임워크는 검증되긴 했지만, 클래스 이름의 길이가 길고, 알 수 없는 클래스를 추가하여 사람이 운영할 때보다 이해와 수정이 어려워집니다. 몇 바이트 정도의 이름이지만, 시스템이 커질수록 이러한 부분이 걷잡을 수 없이 늘어나기 때문에 결국은 비효율적인 부분이 되기 쉽습니다.


디자인의 경우, 글자와 색상 정도의 일관성을 지킬 수는 있지만, 디자인 스타일 자체는 수정을 반복할수록 점점 사람이 이해하기 어려운 상태로 변해가는 문제도 있습니다.


기획 단계의 할루니제이션과 오판도 감시가 필요한 부분입니다. 숙련된 인간 디자이너와 개발자도 뒷일을 생각하지 않으면 며칠 만에 프로덕트를 만들어서 게시할 수 있습니다. 하지만 그 제품을 계속 운영하는 것은 전혀 다른 스킬을 요구하는 일입니다.


제품을 만드는 일은 단순 납품이나 한 철 장사는 프랜차이즈처럼 운영하면, 그 피해는 해당 프로젝트를 운영하는 당사자가 질 수밖에 없습니다.



모든 것을 대신할 수 있는 답은 없다.


실제 작업을 하는 디자이너가 비용과 일정에 정직하며, 모든 프로세스에서 최고의 결과를 위해 노력한다고 해도, 모든 면에서 완벽할 수는 없습니다. 기능이 완벽하면 미적 마무리가 부족하고, 미적으로 완벽하면 기능의 사용이 불편해집니다. 그럴 때마다 항상 심사위원 역할을 자처하는 사람의 말이 작업보다 더 큰 평가를 받습니다.


비평과 비판이 더 큰 주목을 받게 되면, 실제로 일하는 사람은 떠나고, 비평가만 남게 됩니다. 말하기는 쉽지만 책임지긴 어렵기 때문입니다. 많은 툴이 노동의 시간을 줄이고 효율을 높였지만, 그건 디지털 작업 환경일 뿐입니다. 현실의 복잡성을 해결하기 위해서는 현실의 노력이 필요합니다.


모든 것에 답을 내려면, 정말로 모든 것을 투자해야 합니다. 그 투자 중에 하나가 AI와 같은 강력한 제품이 어떻게 움직이고 무엇을 할 수 있는지 잘 아는 것이고, 실제로 그러한 기술을 사용해서 장단점을 확인하는 일이라고 생각합니다.

매거진의 이전글AI가 있는데, 피그마를 왜 배워요?