디자인 시스템을 AI가 읽을 수 있게 만드는 과정 - BizSpring BLOG
핵심 요약
- 바이브코딩으로 실제 서비스 화면을 만들 때 프롬프트만으로는 UI 일관성이 무너지는 문제를 겪었다.
- 기존 피그마 토큰(color, spacing, radius, typography)을 JSON으로 추출해 클로드로 AI가 읽기 쉬운 구조로 재정리했다.
- 피그마 MCP로 버튼·Form·Table 등 반복 컴포넌트를 추출해 variant, 상태값, spacing 규칙까지 함께 구조화했다.
- 정리된 md/json 파일을 러버블에 첨부해 디자인 시스템 라이브러리를 구성하고, Tailwind 기반 생성과 충돌하는 부분은 프롬프트로 계속 보정했다.
- 완벽하지는 않지만 약 70% 수준의 일관성을 확보해 MVP 화면 제작과 아이디어 탐색 단계에서 생산성을 높일 수 있었다.
디자인 시스템을 AI가 읽을 수 있게 만드는 과정 - BizSpring BLOG
콘텐츠로 건너뛰기
내비게이션 메뉴
인사이트
테크
활용 방법/사례
활용 방법/사례
성공사례
성공 사례 일반
광고/마케팅 에이전시
이커머스
미디어/콘텐츠
금융/핀테크
의료/헬스케어
통신/인터넷
뉴스/트렌드
릴리즈 노트
인터넷트렌드 ↗
웹사이트 ↗
# 디자인 시스템을 AI가 읽을 수 있게 만드는 과정
2026년 05월 11일 2026년 05월 11일
활용 방법/사례
이전에 바이브코딩으로 소개용 홈페이지를 만든 적이 있습니다. 지난 포스트 보기 : 디자이너의 바이브 코딩 실전 후기 → 그때는 정말 말 그대로 바이브 에 가까웠습니다. 물론 기획을 꼼꼼히 한 상태에서 진행했지만, 원하는 분위기와 느낌을 자연어로 설명하고 결과물을 보면서 조금씩 수정하는 방식이었습니다. 소개 페이지 정도는 이 방식만으로도 꽤 빠르게 만들 수 있었습니다. 실제로 이와 같은 랜딩 페이지나 브랜드 소개 페이지는 적당한 프롬프트만으로도 어느 정도 완성도가 나왔습니다.
하지만 기능이 들어가는 실제 서비스 화면은 이야기가 달라집니다. 버튼 상태, 테이블 구조, 필터 UI, spacing 규칙처럼 반복적으로 사용되는 요소가 많아질수록 결과물의 일관성이 빠르게 무너지기 시작했습니다. 화면 하나만 보면 괜찮았지만, 여러 페이지를 이어서 보면 점점 같은 서비스처럼 보이지 않는 문제가 생겼습니다. 특히 러버블과 같은 바이브 코딩 환경은 Tailwind CSS 기반의 생성 흐름이 강했기 때문에, 프롬프트 작성 요청만으로는 한계 가 있었습니다.
그래서 이번에는 AI가 먼저 참고할 수 있는 디자인 시스템 라이브러리를 만드는 쪽으로 접근을 바꿔봤습니다.
figma tokens studio
기존 피그마 토큰으로 관리하던 디자인 규칙을 재정리
우선 가장 먼저 한 작업은, 기존에 피그마 토큰으로 관리하던 디자인 규칙을 다시 정리하는 일이었습니다. color, spacing, radius, typography 같은 기본 규칙들은 이미 토큰 형태로 어느 정도 관리되고 있었지만, 문제는 이 구조가 사람이 보기에는 편해도 AI가 바로 참고하기에는 애매하다는 점이었습니다. 그래서 피그마 토큰 데이터를 JSON 파일 형태로 추출한 뒤, 클로드를 통해 다시 정리하는 과정을 거쳤습니다.
어떤 토큰이 실제로 자주 사용되는지
어떤 naming이 중복되는지
semantic token과 primitive token이 어떻게 연결되는지
버튼이나 카드처럼 반복 컴포넌트에서 어떤 규칙이 우선되는지
특히 이 과정에서 의외로 중요했던 건 네이밍의 일관성 이였습니다.
AI에서 제어하는 네이밍과, 제가 입력한 네이밍과의 충돌이 있었습니다. 결국 이번 작업은 디자인 시스템을 새로 만드는 과정이라기보다, 기존 규칙을 AI가 참조하기 쉬운 언어로 다시 번역하는 과정에 더 가까웠습니다.
claude에서 디자인 시스템 토큰 구조화
파일 재구성 : 클로드 활용하기
이 토큰 정보를 기반으로 클로드에서 가장 작은 단위의 아톰(Atom) 컴포넌트를 만들었습니다.
컬러, typography, spacing 같은 기본 규칙이 먼저 정의되고 나니, 그 위에 버튼, Input, Badge 같은 공통 UI 요소들을 하나씩 조합할 수 있게 됐습니다. 이후에는 피그마에서 기존에 컴포넌트화해두었던 요소들을 다시 정리하는 작업을 진행했습니다. 특히 버튼, Form, Table처럼 반복 사용되는 컴포넌트 그룹은 피그마 MCP를 연결해 JSON 형태로 추출한 뒤, 이를 다시 클로드에서 러버블이 인지하기 쉬운 구조로 재가공했습니다. 단순히 데이터를 변환하는 수준은 아니었습니다. 어떤 variant가 존재하는지, 어떤 상태값을 가지는지, 어떤 spacing 규칙을 사용하는지처럼 실제 UI 생성에 필요한 맥락까지 함께 정리해야 했습니다. 결국 중요한 건 컴포넌트를 저장하는 게 아니라, AI가 반복적으로 참조할 수 있는 형태로 구조화하는 일이었습니다.
lovable에 json 구조 코드 추가
러버블에서는 우선 AI가 공통적으로 참조할 수 있는 디자인 시스템 라이브러리를 만드는 작업부터 진행했습니다. 클로드를 통해 정리 및 재가공한 md/json 파일들을 러버블에 첨부한 뒤, 이를 기반으로 디자인 시스템 라이브러리를 구성하도록 했습니다. 이 과정에서 중요한 건 단순히 파일을 넣는 것이 아니라, 러버블이 어떤 규칙을 우선적으로 이해하고 재사용하는지를 계속 확인하는 일이었습니다. 특히 러버블 환경은 Tailwind CSS 기반의 생성 흐름이 강했기 때문에, 기존 디자인 시스템과 충돌하는 경우도 자주 발생했습니다.
spacing scale이 다르게 적용되거나, radius 기준이 흔들리거나, typography hierarchy가 무너지는 경우가 반복적으로 나타났습니다. 이런 부분은 결국 프롬프트 명령을 통해 다시 방향을 교정하는 방식으로 해결해야 했습니다. 완벽하게 디자인 시스템을 강제하는 구조라기보다는, 라이브러리를 지속적으로 참조시키고 필요한 규칙을 추가로 보정하는 운영 방식에 가까웠습니다.
다만 이전처럼 추상적인 표현을 반복하는 대신, 이미 정의된 컴포넌트명과 variant, token naming을 기반으로 훨씬 더 짧고 명확한 프롬프트를 사용할 수 있게 되었습니다. 결과적으로 디자인 시스템은 AI와 커뮤니케이션하기 위한 공통 언어에 가까워지고 있었습니다.
lovable에 생성된 디자인 시스템 라이브러리
이렇게 만들어진 디자인 시스템은 기존 피그마에 정리해두었던 문서만큼 간결했고, 누구나 읽기 쉬운 형태로 구성되었습니다. 개인적으로도 이 부분이 꽤 인상적이었습니다. 단순히 디자인 자산을 옮겨놓은 수준이 아니라, AI가 읽고 참조하기 쉬운 구조로 다시 정리되면서 이전보다 규칙 자체가 더 명확하게 보이기 시작했기 때문입니다. 이후에는 실제로 바이브코딩 환경에서 화면을 생성할 때, 해당 디자인 시스템 라이브러리를 우선적으로 참조하도록 설정해보았습니다. 물론 처음부터 완벽하게 적용되지는 않았습니다. 러버블 환경 자체가 Tailwind CSS 기반의 생성 흐름을 강하게 가지고 있다 보니, spacing이나 typography 같은 일부 규칙은 자연스럽게 Tailwind 방식으로 다시 정리되거나 충돌하는 경우도 많았습니다. 그래서 결국 몇 차례의 추가 프롬프트를 통해 디자인 시스템 라이브러리를 우선적으로 참고하도록 계속 방향을 교정해야 했습니다. 예를 들어 특정 컴포넌트 네이밍을 강제하거나, variant를 우선 사용하도록 명령하는 방식이었습니다. 이렇게 정의된 라이브러리를 바탕으로, 새 프롬프트에서 MVP 화면을 제작하기 시작했습니다.
체감상으로는 완벽으로 이어지지 않고 약 70% 정도 의도한 방향성을 따라오는 수준에 가까웠습니다. 하지만 오히려 이 정도의 결과가 현실적으로는 더 의미 있게 느껴졌습니다. 반복되는 UI 패턴이 일정하게 유지되고, 우리 서비스답지 않은 화면이 나오는 빈도가 줄어들었다는 점이 가장 크게 체감됐습니다. 물론 세밀한 인터랙션이나 완성도 높은 프로덕션 수준의 화면은 여전히 사람이 직접 다듬는 편이 더 빠르고 정확했습니다. 다만 MVP 화면을 빠르게 제작하거나, 새로운 기능 아이디어를 탐색하는 단계에서는 이 정도 수준의 일관성만으로도 충분히 높은 생산성을 만들 수 있었습니다.
화면을 빠르게 만드는 시대에 규칙은 더 중요해졌습니다.
이번 작업 역시 처음부터 가능했던 건 아니었습니다. 디자인 시스템이 이미 피그마 안에서 어느 정도 구조화되어 있었기 때문에, 그 규칙들을 다시 AI가 읽을 수 있는 형태로 변환할 수 있었습니다. AI가 갑자기 디자인을 이해하게 되었다기 보다 사람이 오랫동안 정리해두었던 구조를 기반으로 움직이기 시작한 것에 더 가까웠습니다. 바이브코딩 시대에 가장 중요해지는 건, 얼마나 화려한 프롬프트를 쓰느냐보다 얼마나 잘 구조화된 시스템을 가지고 있느냐일지도 모르겠습니다.
최신 마케팅/고객 데이터 활용 사례를 받아보실 수 있습니다.
비즈스프링 뉴스레터 구독하기 →
Related Posts via Categories
콘텐츠가 답인 걸 모르는 사람은 없습니다 — 문제는 지속입니다
GEO를 위한 글쓰기를 위한 작은 노하우
사이트 주소만 넣으면, 진단은 알아서 시작됩니다
콘텐츠런처로 하나의 원고를 여러 채널에 발행하기
AI가 추천하는 쇼핑몰이 되는 법: 카페24 셀러를 위한 GEO Care
병·의원 전용 AI 검색 최적화 서비스, GEO Care for Clinic이란?
GEO vs SEO, 무엇이 다를까요? 2026년 AI 검색 시대 마케팅 전략 완전 정리
국내 쇼핑몰에 GA4보다 로거(LOGGER)가 더 잘 맞는 이유가 있을까?
정보를 정리했더니, AI가 우리를 이해하기 시작했다
그럴듯한 AI 결과물이 오히려 위험하게 느껴지는 순간
다음에 대해 검색하기...
최신 글 둘러보기
기존 SEO와 무엇이 같고 무엇이 다른가
콘텐츠가 답인 걸 모르는 사람은 없습니다 — 문제는 지속입니다
광고비를 늘리지 않고 매출을 늘린 회사들은 무엇을 했나
코호트로 비교하면 광고 예산 판단이 달라집니다
GEO를 위한 글쓰기를 위한 작은 노하우
(해외동향) 광고주가 광고플랫폼 리포트에서 자체 측정으로 옮겨가고 있다.
구글애즈가 정확검색·구문검색 키워드까지 AI 모드에 노출하기 시작했다 — 자동화 상품 없이 AI 답변 화면에 들어가는 첫 실험
AI가 React 앱을 직접 디버깅 – Agent 기반 디버깅
ChatGPT 광고가 픽셀·전환 API·맞춤 오디언스를 갖췄다 — 답변 화면이 측정 가능한 광고 매체가 되는 순간
마케팅 자동화, 무엇부터 자동화해야 할까?
출처: https://blog.bizspring.co.kr/%ed%99%9c%ec%9a%a9-%eb%b0%a9%eb%b2%95-%ec%82%ac%eb%a1%80/%eb%94%94%ec%9e%90%ec%9d%b8-%ec%8b%9c%ec%8a%a4%ed%85%9c%ec%9d%84-ai%ea%b0%80-%ec%9d%bd%ec%9d%84-%ec%88%98-%ec%9e%88%ea%b2%8c-%eb%a7%8c%eb%93%9c%eb%8a%94-%ea%b3%bc%ec%a0%95/
자주 묻는 질문
프롬프트만으로 서비스 화면을 만들면 안 되나요?
랜딩 페이지나 브랜드 소개 페이지 정도는 프롬프트만으로도 괜찮은 완성도가 나옵니다. 하지만 버튼 상태, 테이블 구조, 필터 UI처럼 반복 요소가 많은 실제 서비스 화면은 여러 페이지를 이어보면 일관성이 빠르게 무너지는 문제가 있었습니다.
기존 피그마 토큰을 그대로 쓰면 안 되나요?
기존 피그마 토큰 구조는 사람이 보기엔 편하지만 AI가 바로 참고하기엔 애매했습니다. 그래서 JSON으로 추출한 뒤 클로드를 통해 AI가 참조하기 쉬운 언어로 다시 정리하는 과정을 거쳤습니다.
러버블에 디자인 시스템을 적용하면 바로 완벽하게 반영되나요?
아닙니다. 러버블 환경은 Tailwind CSS 기반 생성 흐름이 강해서 spacing scale이나 radius, typography hierarchy가 자주 충돌했습니다. 몇 차례의 추가 프롬프트로 디자인 시스템 라이브러리를 우선 참조하도록 계속 방향을 교정해야 했습니다.
이렇게 해서 결과물 품질은 어느 정도까지 개선됐나요?
체감상 약 70% 정도 의도한 방향성을 따라오는 수준이었지만, 반복되는 UI 패턴이 일정하게 유지되고 서비스답지 않은 화면이 줄어드는 효과가 컸습니다. 다만 세밀한 인터랙션이나 프로덕션 수준의 완성도는 여전히 사람이 직접 다듬는 것이 더 빠르고 정확했습니다.
이 작업의 핵심은 결국 무엇이었나요?
AI가 갑자기 디자인을 이해하게 된 것이 아니라, 사람이 오랫동안 정리해둔 구조를 AI가 참조할 수 있는 형태로 번역한 것에 가까웠습니다. 화려한 프롬프트보다 잘 구조화된 시스템을 갖추는 것이 더 중요하다는 점을 확인했습니다.