이전에 바이브코딩으로 소개용 홈페이지를 만든 적이 있습니다.
지난 포스트 보기 : 디자이너의 바이브 코딩 실전 후기 →
그때는 정말 말 그대로 바이브에 가까웠습니다. 물론 기획을 꼼꼼히 한 상태에서 진행했지만, 원하는 분위기와 느낌을 자연어로 설명하고 결과물을 보면서 조금씩 수정하는 방식이었습니다. 소개 페이지 정도는 이 방식만으로도 꽤 빠르게 만들 수 있었습니다. 실제로 이와 같은 랜딩 페이지나 브랜드 소개 페이지는 적당한 프롬프트만으로도 어느 정도 완성도가 나왔습니다.
하지만 기능이 들어가는 실제 서비스 화면은 이야기가 달라집니다. 버튼 상태, 테이블 구조, 필터 UI, spacing 규칙처럼 반복적으로 사용되는 요소가 많아질수록 결과물의 일관성이 빠르게 무너지기 시작했습니다. 화면 하나만 보면 괜찮았지만, 여러 페이지를 이어서 보면 점점 같은 서비스처럼 보이지 않는 문제가 생겼습니다. 특히 러버블과 같은 바이브 코딩 환경은 Tailwind CSS 기반의 생성 흐름이 강했기 때문에, 프롬프트 작성 요청만으로는 한계가 있었습니다.
그래서 이번에는 AI가 먼저 참고할 수 있는 디자인 시스템 라이브러리를 만드는 쪽으로 접근을 바꿔봤습니다.
기존 피그마 토큰으로 관리하던 디자인 규칙을 재정리
우선 가장 먼저 한 작업은, 기존에 피그마 토큰으로 관리하던 디자인 규칙을 다시 정리하는 일이었습니다. color, spacing, radius, typography 같은 기본 규칙들은 이미 토큰 형태로 어느 정도 관리되고 있었지만, 문제는 이 구조가 사람이 보기에는 편해도 AI가 바로 참고하기에는 애매하다는 점이었습니다. 그래서 피그마 토큰 데이터를 JSON 파일 형태로 추출한 뒤, 클로드를 통해 다시 정리하는 과정을 거쳤습니다.
- 어떤 토큰이 실제로 자주 사용되는지
- 어떤 naming이 중복되는지
- semantic token과 primitive token이 어떻게 연결되는지
- 버튼이나 카드처럼 반복 컴포넌트에서 어떤 규칙이 우선되는지
특히 이 과정에서 의외로 중요했던 건 네이밍의 일관성이였습니다.
AI에서 제어하는 네이밍과, 제가 입력한 네이밍과의 충돌이 있었습니다. 결국 이번 작업은 디자인 시스템을 새로 만드는 과정이라기보다, 기존 규칙을 AI가 참조하기 쉬운 언어로 다시 번역하는 과정에 더 가까웠습니다.
파일 재구성 : 클로드 활용하기
이 토큰 정보를 기반으로 클로드에서 가장 작은 단위의 아톰(Atom) 컴포넌트를 만들었습니다.
컬러, typography, spacing 같은 기본 규칙이 먼저 정의되고 나니, 그 위에 버튼, Input, Badge 같은 공통 UI 요소들을 하나씩 조합할 수 있게 됐습니다. 이후에는 피그마에서 기존에 컴포넌트화해두었던 요소들을 다시 정리하는 작업을 진행했습니다. 특히 버튼, Form, Table처럼 반복 사용되는 컴포넌트 그룹은 피그마 MCP를 연결해 JSON 형태로 추출한 뒤, 이를 다시 클로드에서 러버블이 인지하기 쉬운 구조로 재가공했습니다. 단순히 데이터를 변환하는 수준은 아니었습니다. 어떤 variant가 존재하는지, 어떤 상태값을 가지는지, 어떤 spacing 규칙을 사용하는지처럼 실제 UI 생성에 필요한 맥락까지 함께 정리해야 했습니다. 결국 중요한 건 컴포넌트를 저장하는 게 아니라, AI가 반복적으로 참조할 수 있는 형태로 구조화하는 일이었습니다.
러버블에서는 우선 AI가 공통적으로 참조할 수 있는 디자인 시스템 라이브러리를 만드는 작업부터 진행했습니다. 클로드를 통해 정리 및 재가공한 md/json 파일들을 러버블에 첨부한 뒤, 이를 기반으로 디자인 시스템 라이브러리를 구성하도록 했습니다. 이 과정에서 중요한 건 단순히 파일을 넣는 것이 아니라, 러버블이 어떤 규칙을 우선적으로 이해하고 재사용하는지를 계속 확인하는 일이었습니다. 특히 러버블 환경은 Tailwind CSS 기반의 생성 흐름이 강했기 때문에, 기존 디자인 시스템과 충돌하는 경우도 자주 발생했습니다.
spacing scale이 다르게 적용되거나, radius 기준이 흔들리거나, typography hierarchy가 무너지는 경우가 반복적으로 나타났습니다. 이런 부분은 결국 프롬프트 명령을 통해 다시 방향을 교정하는 방식으로 해결해야 했습니다. 완벽하게 디자인 시스템을 강제하는 구조라기보다는, 라이브러리를 지속적으로 참조시키고 필요한 규칙을 추가로 보정하는 운영 방식에 가까웠습니다.
다만 이전처럼 추상적인 표현을 반복하는 대신, 이미 정의된 컴포넌트명과 variant, token naming을 기반으로 훨씬 더 짧고 명확한 프롬프트를 사용할 수 있게 되었습니다. 결과적으로 디자인 시스템은 AI와 커뮤니케이션하기 위한 공통 언어에 가까워지고 있었습니다.
이렇게 만들어진 디자인 시스템은 기존 피그마에 정리해두었던 문서만큼 간결했고, 누구나 읽기 쉬운 형태로 구성되었습니다. 개인적으로도 이 부분이 꽤 인상적이었습니다. 단순히 디자인 자산을 옮겨놓은 수준이 아니라, AI가 읽고 참조하기 쉬운 구조로 다시 정리되면서 이전보다 규칙 자체가 더 명확하게 보이기 시작했기 때문입니다.
이후에는 실제로 바이브코딩 환경에서 화면을 생성할 때, 해당 디자인 시스템 라이브러리를 우선적으로 참조하도록 설정해보았습니다. 물론 처음부터 완벽하게 적용되지는 않았습니다. 러버블 환경 자체가 Tailwind CSS 기반의 생성 흐름을 강하게 가지고 있다 보니, spacing이나 typography 같은 일부 규칙은 자연스럽게 Tailwind 방식으로 다시 정리되거나 충돌하는 경우도 많았습니다. 그래서 결국 몇 차례의 추가 프롬프트를 통해 디자인 시스템 라이브러리를 우선적으로 참고하도록 계속 방향을 교정해야 했습니다. 예를 들어 특정 컴포넌트 네이밍을 강제하거나, variant를 우선 사용하도록 명령하는 방식이었습니다. 이렇게 정의된 라이브러리를 바탕으로, 새 프롬프트에서 MVP 화면을 제작하기 시작했습니다.
체감상으로는 완벽으로 이어지지 않고 약 70% 정도 의도한 방향성을 따라오는 수준에 가까웠습니다. 하지만 오히려 이 정도의 결과가 현실적으로는 더 의미 있게 느껴졌습니다. 반복되는 UI 패턴이 일정하게 유지되고, 우리 서비스답지 않은 화면이 나오는 빈도가 줄어들었다는 점이 가장 크게 체감됐습니다. 물론 세밀한 인터랙션이나 완성도 높은 프로덕션 수준의 화면은 여전히 사람이 직접 다듬는 편이 더 빠르고 정확했습니다. 다만 MVP 화면을 빠르게 제작하거나, 새로운 기능 아이디어를 탐색하는 단계에서는 이 정도 수준의 일관성만으로도 충분히 높은 생산성을 만들 수 있었습니다.
화면을 빠르게 만드는 시대에 규칙은 더 중요해졌습니다.
이번 작업 역시 처음부터 가능했던 건 아니었습니다. 디자인 시스템이 이미 피그마 안에서 어느 정도 구조화되어 있었기 때문에, 그 규칙들을 다시 AI가 읽을 수 있는 형태로 변환할 수 있었습니다. AI가 갑자기 디자인을 이해하게 되었다기 보다 사람이 오랫동안 정리해두었던 구조를 기반으로 움직이기 시작한 것에 더 가까웠습니다. 바이브코딩 시대에 가장 중요해지는 건, 얼마나 화려한 프롬프트를 쓰느냐보다 얼마나 잘 구조화된 시스템을 가지고 있느냐일지도 모르겠습니다.
최신 마케팅/고객 데이터 활용 사례를 받아보실 수 있습니다.