STEP 04. AI 설계 시스템 — 실무에서 놓치는 Variables와 Design Token

 

이전 글에서 MVP는 빨리 만드는 게 핵심이고, 피그마를 쓸지 말지는 판단의 문제라고 했다.

판단의 문제라고 하긴 했지만 만드는게 맞습니다. 😎

당연히 서비스가 커지기 시작하면 판단의 여지가 없어진다.

디자인 시스템이 필요해진다.

 

찐망고 사주에는 디자인 시스템이 없다. 버튼 색을 바꾸고 싶으면 코드에서 직접 바꾸면 됐다.

코드로 이미 root에 컬러시스템을 박아둠.

하지만 화면이 열 개가 넘고, 버튼이 스무 개가 넘고, 같은 컬러를 서른 군데에서 쓰고 있으면 얘기가 완전히 달라진다.

한 곳을 바꾸면 나머지 스물아홉 곳을 찾아다녀야 한다. 이게 디자인 시스템 없이 커진 서비스의 현실이다.

수업에서는 이 문제를 Figma Variables로 가르친다.

디자인 파일에서 가장 많이 발생하는 사고는 "이 색이 뭐였지?"다.

프라이머리 컬러를 정했는데 화면마다 미세하게 다른 값이 들어가 있다. 간격도 마찬가지다.

어떤 카드는 16px이고 어떤 카드는 20px이다. 의도가 아니라 실수다.

이런 실수가 쌓이면 디자이너가 만든 것과 개발자가 구현한 것이 달라지고, 어느 쪽이 맞는지 아무도 모르게 된다.

Variables는 이 문제를 구조적으로 해결한다.

 

이론으로 설명하면 안 와닿는다. 수업에서는 실제 운영 중인 사이트를 카피캣으로 만들면서 가르친다.

학생들한테 먼저 Variables 없이 만들어보게 한다.

그 다음에 프라이머리 컬러를 바꿔보세요라고 하면, 화면 전체를 돌아다니면서 하나씩 바꿔야 한다.

그 다음에 Variables로 토큰화한 파일을 주고 같은 걸 시키면,

변수 하나만 바꾸면 끝이라는 걸 체감한다. 설명이 필요 없다.

컴포넌트 프로퍼티도 같은 원리다.

버튼에 아이콘이 있는 버전, 없는 버전, 사이즈별 버전을 각각 따로 만들면 컴포넌트 수가 늘어난다.

프로퍼티를 쓰면 하나의 컴포넌트 안에서 Boolean으로 아이콘을 토글하고,

Variant로 타입과 사이즈를 스위칭한다. 관리 포인트가 하나로 줄어든다.

이 구조를 직접 만들어본 학생은 왜 디자인 시스템이 필요한지를 몸으로 안다.

 

피그마에서 만든 컬러 토큰이 CSS 변수와 1:1로 대응된다는 걸 보여주면

디자이너와 개발자가 같은 언어를 쓰게 된다.

이전 프로젝트에서 Variables 시스템을 구매해서 커스텀한 적이 있는데,

결국 가장 오래걸린건 토큰 구조를 코드 쪽과 맞추는 작업이었다.

피그마에서 Primary/500이라고 이름 붙인 변수가 코드에서는 --color-primary-500이 된다.

간격도 마찬가지다. Spacing/md가 --spacing-md로 Radius/card가 --radius-card로 넘어간다.

 

말로 하면 추상적이니까, 실제로 확인할 수 있게 수업에서 만든 파일을 공개한다.
Step 03에서 공유한 피그마 파일을 그대로 코드로 옮긴 결과물이다.
피그마의 변수명과 CSS 변수명이 어떻게 대응되는지 직접 비교해볼 수 있다.

깃허브 레포: https://github.com/JJinMangGo/projectClass

라이브 페이지: https://jjinmanggo.github.io/projectClass/kkublack/index.html

 

이름이 조금이라도 다르면 결국 번역 작업이 생기고, 번역 작업이 생기면 실수가 생긴다.

찐망고 사주도 root에 컬러 변수를 박아둔 상태라,

나중에 피그마 파일을 만들게 되면 그 변수명을 그대로 가져가면 된다.

코드가 먼저있고 디자인이 따라오는 케이스인 셈;;

 

Step 03에서 Figma MCP를 이야기했는데, 디자인 시스템에서도 같은 변화가 일어나고 있다.

Claude Code 같은 에이전트가 코드베이스를 읽고,

거기서 토큰과 컴포넌트 스펙을 추출해서 피그마에 디자인 시스템을 자동으로 만들어줄 수 있다.

코드가 먼저고 디자인이 따라오는 방향이 가능해진 거다.

반대로 피그마에서 디자인 시스템을 먼저 잡으면 MCP를 통해 에이전트가 그 토큰을 참조해서 코드를 생성한다.

어느 쪽이 먼저든, 토큰이라는 공통 언어가 있으면 양방향으로 움직인다.

디자인 시스템을 잘 만들어놓으면 AI가 더 정확한 코드를 만든다.

디자인 시스템이 AI 시대의 생산성을 결정하는 인프라가 되는 거다.

 

찐망고 사주에는 디자인 시스템이 필요 없었다. 하지만 서비스가 커지면 필수가 된다.

Variables로 토큰화하고, 컴포넌트로 묶고, 코드와 같은 이름을 쓰게 만드는 구조가 디자인 시스템이다.

AI 시대에는 이 구조가 있느냐 없느냐가 에이전트의 코드 품질까지 결정한다.

예쁜 컴포넌트를 모으는 게 아니라, 팀이 같은 언어를 쓰게 만드는 게 핵심이다.

 

찐망고 사주풀이 | 달콤한 운명 리포트

 

시스템이 잡히면 다음은 실동작 프로토타입이다.

다음 글에서는 Claude의 Artifacts를 활용해서 디자인 단계에서 실제로 작동하는 컴포넌트를 만들고,

프로토타이핑의 속도를 바꾸는 과정을 다룰 예정

 

 

이 시리즈는 실제 운영 중인 서비스 찐망고 사주를 사례로 AI 서비스 기획부터 배포까지를 다루는 강의 노트입니다.
📌출강 및 커리큘럼 문의: spacejh72@gmail.com