개요

Mealio의 디자인 시스템을 구축하기 위해 한 달 동안 AI에게 최대한 많은 일을 시켜보았습니다. 결과적으로 절반은 성공, 절반은 실패했습니다. 이 글은 그 과정에서 세운 워크플로우와, 어떤 접근이 왜 실패했는지에 대한 기록입니다.

목표와 준비물

최종 목표는 Product UI(Figma Design) 를 완성하는 것입니다.

활용한 리소스는 다음과 같습니다.

  • PRD
  • IA
  • 플로우차트

이 리소스를 바탕으로 다음 목표 리소스들을 만들어내고자 했습니다.

  • 디자인 원칙/토큰
  • 와이어프레임
  • 컴포넌트 라이브러리
  • 완전한 UI 디자인

워크플로우

정리한 프로세스는 다음과 같습니다.

  1. LLM에 PRD, IA, 플로우차트를 넣어 디자인 원칙과 토큰을 생성합니다.
  2. Figma Make에 디자인 원칙과 토큰, PRD, IA, 플로우차트를 넣어 아이디어 수준의 UI를 뽑습니다.
  3. 아이디어를 참고해 Figma에 와이어프레임을 그립니다.
  4. Figma Make에 디자인 원칙과 토큰, 와이어프레임, PRD, IA, 플로우차트를 넣어 완전한 UI를 만듭니다.
  5. 완성된 UI를 Figma Design에서 컴포넌트화합니다.

와이어 프레임을 직접 그린 이유는 AI로 와이어프레임을 생성했을 때 결과물의 품질이 페이지마다 편차가 심했고, 일관성이 없었기 때문입니다. 무엇보다 원하는 방향으로 수정하는 시간이 더 오래 걸릴 것이라 판단했습니다.

첫 번째 문제: LLM은 와이어프레임을 진짜 디자인으로 착각한다

이 문제는 예상 밖이었습니다. LLM이 Figma에 작성한 와이어프레임을 "진짜 디자인"으로 인식해 버립니다. 러프한 박스와 텍스트 배치일 뿐인데, 그 안의 의미 없는 스타일까지 그대로 답습하려 듭니다.

이를 피하고자 와이어프레임에 사용된 margin, padding, size, font weight, radius, color 같은 값은 전부 무시하고, 실제 스타일은 반드시 디자인 원칙과 토큰에서만 가져오도록 프롬프트를 강화하였습니다. 이마저도 결과물마다 편차가 있었습니다.

와이어프레임에서는 오직 컴포넌트 배치와 레이아웃 구조만 참고해야 하는데, 와이어프레임 또한 Figma Design에서 프레임 형태로 가져오는 형식이다 보니 LLM이 잘 인지하지 못하는 것 같았습니다.

두 번째 문제: 레퍼런스가 부실하면 바로 AI 냄새가 난다

Cursor로 생성하든 Figma Make로 생성하든, AI가 뽑아내는 디자인은 결과물이 서로 비슷하고 특유의 AI 냄새가 납니다.

이 지점에서 얻은 결론은, 어느 방향으로 가든 레퍼런스가 가장 중요하다는 것이었습니다. 디자인에 대한 평가는 어느 정도 주관적이고, AI는 사용자가 원하는 '멋진 디자인'에 대해서 모르기 때문에 결국 레퍼런스가 탄탄해야 만족스러운 결과물이 나오는 것 같습니다.

그래서 애초에 디자인 감각이 부족한 사람은 아무리 좋은 AI를 써도 프로덕션 수준의 디자인을 만들기 어렵다고 생각합니다. 원하는 디자인을 어떠한 형태로든 설명해야 하는데, 아이디어가 없다면 결국 "알아서 잘해줘" 라고 하게 됩니다.

레퍼런스로 크몽, 엔카, 무신사, 당근을 참고하였고, 기존 결과물에 레퍼런스의 스타일을 첨가하여 전보다 훨씬 나은 디자인을 만들어냈습니다.

세 번째 문제: 컴포넌트화는 수동으로 해야 한다

프로페셔널 시트로 업그레이드한 가장 큰 목적이 Figma Make의 결과물을 Figma Design에 프레임 형태로 복사하기 위해서였습니다. 그러나 생각과는 달리, 복사한 프레임은 오토 레이아웃이 전혀 적용되어있지 않았고, 모든 값이 디자인 토큰 참조 없이 하드하게 할당되어 있었습니다.

결국 디자인은 뽑아내더라도, 컴포넌트화는 직접 해야만 했습니다. 일일이 오토 레이아웃 설정하고 토큰 할당해 주는 과정이 필요했고, 특히 variant와 컴포넌트 상태에 따른 속성 설정이 전체 디자인 시스템 구축 과정에서 가장 피로했습니다.

노가다와 별개로 컴포넌트 체계를 구축하는 과정에 상당한 고민과 노력이 필요했습니다. 네이밍, variant, 공통화를 최선의 방향으로 결정하는 것이 쉽지 않았습니다. 그나마 이 부분은 LLM의 도움을 받을 수 있었습니다.

Figma API를 활용할 순 없었나?

Figma MCP에는 컴포넌트화에 필요한 Figma API 활용 스킬을 갖춘 use_figma 도구가 있습니다. 페이지에 포함된 컴포넌트들을 컴포넌트 라이브러리에 직접 생성하도록 에이전트에게 맡기고, Variable/Style/Variant/Property를 반드시 활용하도록 지시했습니다.

일부 스타일이나 속성은 의도대로 채워졌지만, 결과적으로 써먹을 수준은 아니었습니다. use_figma 도구의 Figma API 커버리지 자체가 강력했기 때문에 순조로울 것이라 예상했지만, 에이전트가 디자인 시스템을 활용하고 컴포넌트를 다양한 방법으로 잘 생성하는 데에는 한계가 있었습니다. 오히려 원본 프레임을 직접 컴포넌트화하는 쪽이 훨씬 유리했습니다.

디자인 시스템 운영하기

이렇게 만든 디자인 시스템을 운영하는 방식은 다음과 같습니다.

  • Figma에서 실제로 컴포넌트를 만들어가며 토큰을 지속적으로 보완한다.
  • Figma MCP를 활용하여 전체 Figma Design을 분석하고, 사용된 변수/스타일을 바탕으로 CSS 토큰을 만든다.
  • 컴포넌트는 Figma Design + CSS 토큰으로 LLM이 작성하고, 페이지는 직접 컴포넌트를 조합하여 만든다.

그리고 가장 중요한 원칙은 SSOT(Single Source of Truth) 입니다. Figma Design → CSS 토큰 → 컴포넌트 스타일로 이어지는 흐름이 한 번이라도 생략되면 그 순간부터 동기화가 무너지고, 에이전트는 모든 것을 스스로 판단하게 됩니다.

회고

"AI로 디자인 시스템을 구축한다"라는 발상 자체는 충분히 말이 됩니다. 문제는 여기에 Figma가 포함되는 순간 난이도가 급상승한다는 점입니다. 한 달을 시행착오로 보낸 이유이기도 합니다.

"그냥 Figma 없이 에이전트로 UI를 쭉쭉 뽑아냈으면 더 쉽지 않았겠느냐?" 이 질문에는 반만 공감합니다. Storybook이 아무리 편리해도, 개발자가 아니라 디자이너 관점에서 지속 가능한 디자인 프로세스를 만들려면 결국 Figma에 디자인 시스템을 구축하는 것이 맞는 방향이라고 생각합니다.

사실은 두 가지 워크플로우를 시도해 봤습니다. Figma Make → Figma Design → Code 순서로 진행했지만, Figma Make 없이 Agent → Code → Figma Design 순서로 가도 괜찮을 것 같았습니다. 그래서 양방향 워크플로우를 다 구축해 봤는데, 막상 후자의 결과물이 더 별로였고 현업 프로세스와도 괴리가 있어서 결국 Figma Make를 쓰는 쪽으로 정착했습니다.

워크플로우 자체를 연구해 본 것과는 별개로, 디자인 결과물의 퀄리티는 아직 만족스러운 수준은 아닙니다. 좋은 퀄리티를 뽑아내려면 결국 레퍼런스와 아이디어가 핵심인 것 같습니다. 도구가 아무리 좋아져도, 무엇을 만들지에 대한 안목은 여전히 사람의 몫입니다.