Figma는 아직 안 죽었다 — 근데 Stitch + 제미나이 조합을 보면 좀 불안해진다

헤드라인

"AI로 디자인을 생성한다"는 말을 처음 들었을 때는 솔직히 반신반의했어요. 근데 실제로 Google Stitch에 프롬프트 한 줄 넣으면 Tailwind 기반 코드까지 뱉어내는 걸 보면, 기존 디자인 프로세스가 흔들리는 건 시간문제라는 생각이 들어요.

Figma가 당장 사라지진 않을 거예요. 근데 그 자리가 예전만큼 넓을까? 직접 써보고 나서 생각이 좀 복잡해졌어요.

갈릴레오 AI에서 Stitch로 — SVG 이미지가 코드가 되기까지

갈릴레오 AI 화면

갈릴레오 AI(Galileo AI)라는 게 있었어요. 이미 만들어진 컴포넌트를 조합하는 다른 AI 툴들과 달리, Figma에 맞게 레이어 구조를 잡아준 뒤 SVG 형태로 Figma에서 작업을 이어갈 수 있게 만들어준 도구였어요. 색상이나 Radius 조정도 가능해서 많은 관심을 받았죠.

근데 한계가 명확했어요. 디자인이 하나의 스타일로 제한되고, UI에 쓰이는 이미지 리소스 생성이 제한된 상태. Figma로 가져오면 레이어 구조가 잡혀 있어서 편리하긴 했지만, 실제로 활용하기는 어려웠거든요.

스티치 Tailwind 기반 코드 생성

스티치는 구글이 갈릴레오 AI를 인수해서 만든 거예요. 결정적인 차이? 제미나이를 사용한다는 것, 그리고 Tailwind 기반의 코드와 React/HTML로 생성해 준다는 것. 프롬프트를 UI로 만드는 걸 넘어서 바로 개발에 쓸 수 있는 코드를 뱉어내는 거죠.

갈릴레오 AI는 코드가 아닌 SVG 이미지로 생성했기 때문에 개발자가 바로 쓸 수 없었어요. 스티치는 이미 제작된 Tailwind 클래스를 조합해서 구조적인 코드를 생성하는 방식으로, 컨테이너 클래스 사용과 스타일 구분이 명확하고, 컴포넌트의 State(active, hover 등)까지 선언할 수 있어요. 프로젝트 내에서 추가 스크린을 만들 때 UI와 디자인 스타일의 일관성을 지킬 수 있는 구조.

텍스트뿐 아니라 이미지나 손으로 그린 화이트보드 사진도 입력으로 쓸 수 있어요. 제미나이 기반이라 멀티모달이 되거든요.

근데 디자이너가 직접 수정할 때는? 갈릴레오 AI 때에 비해 크게 나아지진 않았어요.

레스토랑 웨이팅 시스템을 제미나이 + 스티치로 만들어봤다

실제로 "식당에서 대기열을 등록하고 확인할 수 있는 디지털 프로덕트의 UI 디자인"을 요청해 봤어요. 제미나이 Pro 모드에서요.

제미나이가 이 대화를 "레스토랑 웨이팅 시스템 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의 사고 과정을 보면 사람의 모호한 질문에서 부족한 부분을 알아서 보충해요. "사용자의 목표와 핵심 기능, 특히 대기열 등록 및 상태 확인 기능을 분석하기 시작했습니다" — 이런 식으로요.

제미나이 기획안으로 생성한 UI

제미나이에서 만든 기획안을 스티치에 넣었더니, 보편적인 디자인으로 필요한 기능은 적절하게 들어 있었어요. 근데 실제 앱으로 개발하기 위한 장치들은 잘 보이지 않더라고요.

제미나이 Pro 사고 기반 생성 결과

흥미로운 건 기획안 원문 대신 제미나이 Pro의 사고 영역(사용자 모호 입력을 보충한 내용)을 스티치에 넣었을 때였어요. 기획안보다 결과물이 더 좋았거든요.

제미나이 최종 기획안 기반 결과

제미나이가 최종적으로 완성한 기획안을 모바일 옵션으로 생성한 버전은 세부항목이 훨씬 명확하고, 숙련된 인간 디자이너가 작업한 결과와 유사했어요.

디자인 시스템 연동 화면

디자인을 확장하려면 Design System을 추가해야 하고, 생성된 디자인을 유지하려면 반드시 "Create from~내가 선택한 스크린"을 선택해야 해요. 이렇게 하면 프로젝트 전체에 포함된 스크린의 Tailwind Config가 수정돼요.

Google AI Studio로 옮기면 생성된 UI를 실제로 작동하게 만들 수도 있어요. 예약을 진짜로 해보거나 예약 후 사용자에게 전송될 메시지를 테스트해 볼 수도 있고요. 충분히 테스트를 거치고 실제 제품으로 확장할 때는 Vertex AI를 활용할 수도 있죠.

피그마가 만들어낸 프로세스 vs AI가 만들어낸 프로세스

피그마 프로세스 다이어그램

여기서 잠깐 큰 그림을 볼 필요가 있어요. 기존 작업은 리서치 -> 현장 맥락 파악 -> 데이터/프로세스 정의 -> 디자인 정리 순서였고, 각 과정에서 숙련된 사람이 이전 작업을 이어받아 커뮤니케이션을 해야 했어요. (여기서 커뮤니케이션은 친근한 대화가 아니라, 다음 작업에 필요한 정보를 전달하는 거예요. 보통은 PPT나 엑셀로 된 명세서.)

피그마는 PPT와 엑셀 없이 각 개발자가 필요한 정보를 Dev 모드로 공급하는 프로세스를 만들었어요. 베리어블과 컴포넌트 베리언트를 지원하는 디자인 시스템으로 작업을 통합한 거죠. 숙련도가 낮아도 정리된 환경에서 디자인 리소스를 운영할 수 있게 됐어요. 비주얼 디자이너보다 적은 노력으로 큰 성과를 낼 수 있는 포지션을 만들어준 셈.

근데 그래서 전체 프로젝트의 방향성이 디자인에서 개발 쪽으로 한 발 더 움직이는 계기가 되기도 했어요.

AI 프로세스 다이어그램

AI를 사용한 프로세스는 여기서 숙련도를 더 제거해요. 디자인 리소스 조달을 통합하고, 아주 적은 정보만 줘도 제미나이가 숙련된 UX 디자이너처럼 조언을 해주는 구조. 스티치는 화려하진 않지만 기능 중심의 프로덕트를 만들 수 있는 초기 코드를 주고, AI 스튜디오를 쓰면 실제로 작동하는 것처럼 테스트해볼 수도 있어요.

피그마는 AI 프로세스에서 조금 더 보조적인 역할로 밀려나요. 스티치에서 생성한 디자인을 가져오는 건 가능하지만, 거기서 디자인을 이어가기는 여전히 어려워요. 숙련된 디자이너와 개발 팀은 계속 피그마를 쓰겠지만, 예전처럼 주니어가 대거 유입되면서 급성장하기는 어려워 보여요.

기능은 AI가 잡고, '유지보수'는 사람이 안는다

디자이너를 위한 시사점

피그마를 쓰는 디자이너가 유의해야 할 건 코드 중심의 디자인이에요. 제품을 개발할 때 기능부터 생각하는 사람은 적거든요. 대부분 비즈니스나 마케팅, 트래픽 같은 성과 중심으로 사고하죠. 근데 기능을 명확하게 설명해야 UX와 UI를 잘 만들 수 있어요. 구현되지 않으면 사용되지 않고, 사용되지 않으면 사용자는 없고, 개선도 없으니까요.

어느 시점부터 UX 트렌드가 약해지면서 리서치와 테스트 작업이 요식행위가 됐어요. 기획자 시절의 작업 형태로 돌아가버리면서 많은 작업이 형식적 절차로 변해버렸죠. 정해진 템플릿을 반복하면서 기존 방식을 응용하는 게 보편적인 프로세스가 된 거예요.

AI 디자인은 이 지점을 비집고 들어와요. 사용자 리서치가 아니라 기능 실현 중심에서 코드를 기반으로 실행하고, 불필요한 커뮤니케이션 없이 핵심 요소를 찾아내서 실행하는 거죠.

근데 — 여기서 냉정한 이야기가 나와요. AI 디자인 프로세스의 한계점은 꽤 명확하거든요. 사람이 일관성이나 목표를 관리하지 않으면, 의도한 결과를 얻기 어려워요. 실제로 제품을 완성해서 운영한 경험이 있는 사람이 그렇게 많지 않고, 각자 자기 영역 안에서만 AI가 모든 걸 바꾼다고 생각하는 경향이 있어요.

제미나이 + 스티치 + Tailwind 조합은 이론적으로 일관성 유지와 디자인 시스템 구성에서 높은 점수를 받을 수 있어요. 근데 실제로는 이렇게 만든 제품을 지속적으로 업데이트해서 시장에서 살아남게 해야 하잖아요. 개별 요소의 수정과 보강이 반드시 필요하고, 개발자들은 이걸 '유지보수'라고 부르죠. (제품 출시 당시 수준을 유지하는 게 아니라 경쟁 상황에서 품질을 유지하는 거예요.)

유지보수 과정에서 Tailwind 프레임워크는 검증되긴 했지만, 클래스 이름이 길고, AI가 알 수 없는 클래스를 추가해서 사람이 운영할 때보다 이해와 수정이 어려워지는 문제가 있어요. 시스템이 커질수록 이런 부분이 걷잡을 수 없이 늘어나고요. 디자인도 마찬가지로, 수정을 반복할수록 사람이 이해하기 어려운 상태로 변해가는 문제가 있어요.

기획 단계의 할루시네이션과 오판도 감시가 필요해요. 숙련된 인간 디자이너와 개발자도 뒷일을 생각 안 하면 며칠 만에 프로덕트를 만들어 게시할 수 있거든요. 근데 그 제품을 계속 운영하는 건 전혀 다른 스킬. 단순 납품처럼 한 철 장사로 운영하면, 피해는 해당 프로젝트를 운영하는 당사자가 질 수밖에 없어요.

AI는 강력한 도구지, 모든 것의 답은 아니다

기능이 완벽하면 미적 마무리가 부족하고, 미적으로 완벽하면 기능 사용이 불편해져요. 그럴 때마다 심사위원 역할을 자처하는 사람의 말이 실제 작업보다 더 큰 평가를 받곤 하죠. 비평과 비판이 더 큰 주목을 받으면, 실제로 일하는 사람은 떠나고 비평가만 남아요. 말하기는 쉽지만 책임지긴 어렵기 때문.

많은 툴이 노동의 시간을 줄이고 효율을 높였지만, 그건 디지털 작업 환경일 뿐이에요. 현실의 복잡성을 해결하려면 현실의 노력이 필요하고요. AI와 같은 강력한 제품이 어떻게 움직이고 무엇을 할 수 있는지 아는 것, 실제로 써보면서 장단점을 확인하는 것. 그게 투자예요. 모든 것에 답을 내리려면, 정말로 모든 것을 투자해야 하니까요.