AI가 피그마 파일을 '프레임 무더기'로 보는 이유 — 디자인 시스템을 기계가 읽게 만드는 10가지 방법

AI가 디자인 워크플로의 필수 도구가 되고 있어요. Figma 파일을 읽고, UI 레이아웃을 생성하고, 디자인을 코드로 변환하는 것까지 가능한 시대죠.

근데 한계가 있습니다. 오늘날 대부분의 디자인 시스템은 오직 사람만을 위해 만들어졌거든요. 시각적으로는 잘 정리되어 있어도 기계가 보기엔 구조적으로 불분명한 상태예요. AI 입장에서 많은 피그마 파일은 프레임과 사각형, 그룹들이 무작위로 뒤섞인 집합체에 불과합니다.

AI를 진짜 협업 파트너로 쓰고 싶다면, 디자인 시스템도 진화해야 해요. 단순한 비주얼 라이브러리를 넘어 구조화된 시스템으로.

왜 AI가 읽을 수 있는 디자인 시스템이 필요한가

기존 디자인 시스템은 팀이 일관성을 유지하고 컴포넌트를 재사용하는 데 초점이 맞춰져 있었어요. 근데 AI 도구는 거기에 더해 구조와 의미를 함께 전달할 수 있는 추가적인 요소를 필요로 합니다.

디자인 시스템이 제대로 구조화되어 있다면 AI 도구가 할 수 있는 일이 완전히 달라져요. 기존 컴포넌트를 활용한 UI 레이아웃 생성, 디자인을 프로덕션 레디 코드로 변환, 디자인 과정에서 적절한 컴포넌트 추천, 디자인 의도와 제약 사항 이해까지. 구조가 없으면 AI는 단순한 도형과 레이어만 인식하지만, 구조가 갖춰지면 요소들 간의 관계망으로 이루어진 시스템을 보게 됩니다.

차이가 큽니다. 같은 AI인데 뭘 읽느냐에 따라 결과물이 달라지는 거죠.

네이밍 규칙이 AI한테 보내는 첫 번째 신호다

네이밍은 AI가 읽을 수 있는 가장 중요한 신호 중 하나예요. 컴포넌트가 예측 가능한 패턴을 따를 때, 기계는 각 요소가 서로 어떻게 연결되는지 이해할 수 있거든요.

단순한 계층 구조만으로도 충분합니다.

Category / Component / Variant / State / Size

예를 들면 `Button / Primary / Default / Medium`, `Button / Primary / Hover / Medium`, `Input / Text / Error / Default` 같은 식이죠.

여기서 중요한 팁 몇 가지. `Pri`나 `Btn` 같은 약어 사용은 지양하고, `/`와 같은 일관된 구분자를 쓰고, 계층 구조를 예측 가능하게 유지하는 거예요. 네이밍이 일정한 패턴을 따르면 AI는 컴포넌트의 계열과 변형을 쉽게 인식합니다.

토큰 중심으로 갈아타면 AI가 "왜"를 이해한다

디자인 토큰은 디자인 시스템의 데이터 레이어 역할을 합니다. 색상, 간격, 타이포그래피 같은 시각적 속성을 구조화된 형태로 표현하는 거죠.

컴포넌트 내부에 값을 직접 하드코딩하는 대신 토큰을 쓰세요. `color.primary.500`, `spacing.16`, `radius.medium`, `font.body.medium` 같은 식으로요.

근데 여기서 한 발 더 나가야 합니다. 시멘틱 토큰은 목적을 표현하기 때문에 훨씬 유용해요. `color.background.primary`, `color.text.secondary`, `color.button.primary.background`처럼 쓰면 AI가 단순히 값이 무엇인지뿐만 아니라 왜 존재하는지도 이해하게 됩니다. (이 차이가 생각보다 크거든요.)

토큰 관리에는 Figma Variables, Tokens Studio, Style Dictionary 같은 도구가 도움이 돼요.

변형마다 컴포넌트를 새로 만들지 마세요

디자인 시스템 구축할 때 흔히 하는 실수가 있어요. 모든 변형마다 별개의 컴포넌트를 만드는 것. Button Primary, Button Secondary, Button Large, Button Small... 이러면 시스템이 금방 복잡하고 무거워집니다.

대신 피그마의 Component Properties를 활용하면 돼요. 버튼 하나에 Variant(Primary, Secondary, Ghost), Size(Small, Medium, Large), State(Default, Hover, Disabled, Loading), Icon(True, False) 같은 속성을 붙이는 거죠.

이렇게 구조를 잡으면 AI는 시각적인 차이를 넘어서 해당 컴포넌트가 작동하는 로직까지 이해할 수 있어요. 별개의 컴포넌트 10개를 보는 것과 속성이 있는 컴포넌트 1개를 보는 건 완전히 다른 경험이거든요.

Auto Layout — 디자이너와 기계 모두를 위한 구조

Auto Layout은 디자이너와 기계 모두에게 요소가 어떻게 동작하는지를 알려줍니다. 패딩, 요소 간 간격, 정렬, 반응형 동작을 정의하는 거죠.

`Padding: spacing.12 spacing.16`, `Gap: spacing.8`, `Radius: radius.medium` 같은 식으로요.

Auto Layout이 없으면 AI는 요소를 정적인 상태로 인식해요. 고정된 좌표에 배치된 그림일 뿐이죠. Auto Layout이 적용되면 비로소 요소의 구조와 동작 방식이 드러납니다. 정적인 그림에서 동적인 시스템으로 바뀌는 순간.

기계가 읽을 수 있는 문서를 컴포넌트에 붙여라

디자인 시스템은 시각 요소뿐 아니라 의도까지 포함하고 있어요. 컴포넌트, 스타일, 토큰에 대한 설명을 추가하면 AI 도구가 어떻게 사용해야 하는지 이해하는 데 도움이 됩니다.

예를 들어 버튼 컴포넌트에 이런 설명을 붙이는 거죠. 목적은 "인터페이스에서 주요 동작을 유발하는 트리거", 사용 규칙은 "섹션당 기본 버튼은 하나만 사용", "보조 버튼은 기본 동작을 보조", "어두운 배경에서는 버튼이 보이지 않도록 함". 접근성 기준으로는 최소 높이 40px, 최소 명암비 4.5:1.

이렇게 하면 디자인 시스템은 단순한 컴포넌트 라이브러리를 넘어 하나의 지식 베이스로 확장돼요.

파일 구조 정리는 동료만을 위한 게 아니다

깔끔한 파일 구조는 동료 디자이너뿐만 아니라 AI에게도 훨씬 수월한 탐색 환경을 제공합니다.

페이지 구조 예시를 보면요. `00 Foundations`(Colors, Typography, Spacing, Radius, Elevation), `01 Tokens`(Semantic Tokens, Dark Mode Tokens), `02 Components`(Buttons, Inputs, Cards, Navigation), `03 Patterns`(Forms, Lists, Modals), `04 Templates`(Screens), `05 Documentation`.

이런 계층 구조가 파운데이션, 컴포넌트, 사용 패턴을 명확하게 구분해 줍니다. 사람이 보기 편한 구조가 AI에게도 편한 구조인 셈이에요.

토큰 매핑 — 일관성의 보증 수표

컴포넌트는 가공되지 않은 원시값 대신 반드시 토큰을 참조해야 해요. 버튼을 예로 들면 `background → color.button.primary.background`, `text → color.button.primary.text`, `padding → spacing.16`, `radius → radius.medium`.

AI가 UI를 생성하거나 디자인을 코드로 변환할 때, 이런 참조 관계가 디자인의 일관성을 보장해줍니다. 원시값 `#4F46E5`를 쓰면 AI는 그냥 색상 코드 하나를 보는 거예요. 토큰 `color.primary.500`을 쓰면 시스템 내에서의 역할과 관계를 함께 보는 거고요.

레이어 이름이 Rectangle 23이면 AI는 포기한다

레이어 이름. 대부분의 팀이 생각하는 것보다 훨씬 중요합니다.

`Rectangle 23`, `Frame 124`, `Group 17` — 이런 이름은 피하세요. 대신 `Button Container`, `Button Label`, `Button Icon`, `Input Field`, `Input Label`, `Input Helper Text`처럼 의미 기반 네이밍을 쓰는 거예요.

의미 있는 레이어 이름은 AI가 UI 구조를 해석하기 쉽게 만들어 줍니다. (솔직히 이건 사람한테도 마찬가지죠. Rectangle 23이 뭔지 아는 사람은 만든 당사자뿐이에요.)

사용 규칙까지 명시해야 AI가 "쓸 수 있는" UI를 만든다

디자인 시스템에는 디자이너가 직관적으로 이해하지만 기계는 이해하지 못하는 규칙들이 있어요. "Primary 버튼은 섹션당 한 번만 표시되어야 한다", "최소 터치 영역: 44px", "Input label은 항상 입력 필드 위에 표시되어야 한다", "양식에서 아이콘은 레이블 없이 사용해서는 안 된다".

이 규칙들을 명확하게 명시하면 AI가 시각적으로 맞는 UI가 아니라 실제로 사용 가능한 인터페이스를 생성하도록 도울 수 있어요. 규칙 없이 만들면 예쁘기만 하고 쓸 수 없는 UI가 나옵니다.

디자인과 코드가 같은 토큰을 공유할 때

디자인 토큰이 엔지니어링 시스템과 직접 연결될 때 AI 워크플로우는 진짜 힘을 발휘해요.

토큰 매핑 예시. `color.primary.500 → #4F46E5`, `spacing.16 → 16px`, `radius.medium → 8px`. 이런 토큰은 JSON 형식으로 내보내서 개발 프레임워크에서 바로 사용할 수 있어요.

```json { "color": { "primary": { "500": "#4F46E5" } }, "spacing": { "16": "16px" } } ```

디자인과 코드가 동일한 토큰 구조를 공유하면 AI가 그 사이의 간극을 훨씬 더 효과적으로 메울 수 있습니다. 디자이너가 토큰을 바꾸면 코드도 따라 바뀌고, AI도 그 변경을 이해하는 구조.

네 개의 레이어로 본 AI 네이티브 디자인 시스템

디자인 시스템은 진화하고 있어요. 단순한 컴포넌트 라이브러리에서 AI 기반 디자인, 자동화된 UI 생성, 디자인-코드 워크플로우를 가능하게 하는 구조화된 인터페이스 플랫폼으로요.

AI 지원 디자인 시스템은 네 가지 계층으로 구성됩니다. 디자인 레이어(Figma에서 구축된 컴포넌트와 레이아웃), 토큰 레이어(시각적 속성을 정의하는 구조화된 토큰), 논리 레이어(컴포넌트의 속성과 상호작용 규칙), 지식 레이어(문서화와 사용 제약 조건).

이 네 계층이 함께 작동할 때, 디자인 시스템은 디자이너와 엔지니어뿐 아니라 지능형 시스템까지 이해할 수 있는 형태로 변환돼요.

AI가 디자인 시스템을 대체하진 않을 겁니다. 오히려 디자인 시스템의 중요성이 더 커지고 있어요. AI는 시스템이 구조화되고 예측 가능하며 의미 있는 상태일 때 가장 잘 작동하거든요. 토큰, 일관된 네이밍 규칙, 컴포넌트 프로퍼티, 명확한 문서화와 강력한 파일 구성. 이걸 갖추면 팀의 확장성을 확보할 뿐만 아니라 기계도 이해할 수 있는 디자인 시스템이 됩니다.

결국 미래의 디자인 시스템은 제품의 외형을 정의하는 걸 넘어서, 인터페이스가 어떻게 생성되고 확장되는지를 정의하게 될 거예요. 사람과 AI 모두한테요.