AI가 Figma에서 디자인할 때

데모는 대개 프롬프트 하나와 빈 파일에서 시작한다. 첫 결과는 완성된 것처럼 보인다. 그런데 다시 돌리면 토큰 이름이 바뀐다. --ds-primary였다가 --color-primary, 그다음엔 --main-blue. 버튼에는 hover, focus, disabled 상태가 없다. 간격은 토큰이 아니라 24px로 박혀 있어서 더 좁은 프레임에 넣으면 auto layout이 깨진다.

도구가 잘못한 게 아니다. 문제마다 아무도 내리지 않은 결정이 있다. 이름을 뭐라고 부를지, 어떤 상태가 있는지, 무엇을 무엇에 연결할지. 그래서 결정이 먼저 온다. 그리고 그 결정은 에이전트가 그리기 전에 읽는 파일에 들어간다.

모든 건 입력 두 개에서 시작한다.

브랜드 가이드라인이 주는 건 기본값이다. 브랜드 컬러, 서체, 가끔은 타입 스케일. 의미 토큰은 주지 않는다. 어느 파란색이 주요 액션이고 에러 영역은 어떻게 보이는지 적힌 브랜드 북은 없다. 그 층은 제품의 결정이고, 내가 정한다. 브랜드 팔레트가 거의 다루지 않는 전체 색 스케일과 피드백 색도 함께 정한다.

컴포넌트 인벤토리는 무엇이 있어야 하는지 정한다. 프론트엔드 레퍼런스 세 곳, MUI, Angular Material, Material Design 3를 조사해서 스프레드시트로 만들었다. 마스터 시트는 기준 컴포넌트 72개를 세 라이브러리에 대응시키고 빈 곳을 표시한다. Angular Material에는 Rating이 없고, M3는 Autocomplete를 Search와 Menus로 조합한다. 라이브러리마다 시트가 따로 있는 건 컴포넌트를 구성하는 방식이 저마다 달라서다. MUI는 label과 error를 TextField 안에 두고, Angular Material은 입력을 Form Field로 감싸고, M3는 text field의 구조를 스펙에서 직접 정의한다.

이 시트들에서는 컴포넌트 × variant × 상태 하나가 한 행이다. MUI 942행, Angular Material 572행, M3 587행. 상태는 M3의 용어(enabled, hovered, focused, pressed, dragged, disabled)를 기준으로 하고, 해당될 때만 error, readonly, selected 등을 더한다. 어느 시트를 쓸지는 제품이 쓰는 라이브러리가 정한다.

두 입력 모두 Figma로 바로 가지 않는다. LLM이 이걸 마크다운 스펙으로 바꾸고, 나는 LLM이 쓴 걸 고친다. 구조는 Figma to Code에서 쓰는 것과 같다. 맨 위에 design-system.md, 그 아래에 foundations/(색, 타이포그래피, 간격, 모션, 접근성), components/, patterns/, templates/. 옆에는 Google Labs의 공개 형식을 따른 DESIGN.md를 둔다. 토큰은 YAML front matter에, 그 이유는 아래 본문에 적는다.

같은 파일을 나도, 개발자도, 모든 에이전트도 읽는다. 스펙 묶음 맨 위에는 규칙 하나가 있다. 값을 추측하지 말 것. 스펙에 적혀 있지 않은 값은 아직 존재하지 않는다. 에이전트는 값을 골라 넣지 말고 비어 있다고 말해야 한다.

스펙이 무엇을 다뤄야 하는지는 인벤토리가 정한다. 자동으로 만드는 리포트가 기준 컴포넌트 72개 중 무엇이 문서화됐고 무엇이 빠졌는지 보여 준다. 컴포넌트 스펙마다 스프레드시트의 열에서 가져온 아홉 가지 기준(구조, prop, 상태, 가이드라인, 접근성 등)으로 점수를 매긴다. 빠진 기준은 빠진 섹션이다.

에이전트가 Figma에 무엇을 그리기 전에, 스펙만으로 충분한지부터 확인한다. 새 에이전트에게 md 파일만 준다. Figma도, 코드도, 나에게 물어볼 길도 없다. 이 에이전트가 컴포넌트 몇 개를 만든다. 스펙에서 가져온 값에는 SPEC: 파일:줄 주석을 달고, 스스로 정해야 했던 값에는 INVENTED를 표시한다.

INVENTED 목록이 곧 할 일 목록이다. 항목 하나하나가 스펙에 빠진 결정이고, 고치는 곳은 컴포넌트가 아니라 md다. 그리고 고친 스펙으로 다시 돌린다. 스펙이 제대로 돌아가게 만드는 건 이 반복이다. 결과를 보고, md를 고치고, 다시 돌린다.

숫자가 그냥 줄어들지는 않는다. 초반 회차에서는 컴포넌트 하나를 아예 만들 수 없었다. 스펙을 고치자 만들 수 있게 됐고, 만들다 보니 에이전트가 전에는 닿지도 못했던 결정들이 드러났다. 그래서 총합은 보지 않는다. 같은 빈칸이 다시 나오는지를 본다. 한 번 고친 빈칸이 다시 INVENTED가 되면 안 된다.

그리는 일과 검수하는 일은 에이전트를 나눈다.

그리는 에이전트는 스펙을 읽고 use_figma로 Figma에 쓴다. 빌드의 뼈대는 Figma의 figma-generate-library skill이 잡는다. 탐색, 파운데이션, 파일 구조, 컴포넌트, 그리고 통합과 QA. 단계가 끝날 때마다 멈추고 내 검토를 기다린다. 만든 ID는 전부 상태 파일에 기록하고, 무언가를 만들기 전에 이름으로 먼저 찾는다. 그래서 두 번째 회차는 새 이름을 지어내지 않고 첫 번째 결과를 고친다. fill, padding, radius, gap은 variable에 연결하고, variant 이름은 Property=Value(State=Hovered) 형식으로 쓴다. 이 skill은 코드베이스를 기준으로 삼도록 되어 있다. 여기서는 md 스펙이 그 자리를 맡는다.

검수 에이전트는 그리지 않는다. 결과를 룰북과 스펙에 비춰 보고, 실패를 원인이 있는 곳으로 돌려보낸다. Figma to Code에서 QA가 실패를 나눠 보내는 것과 같다. 스펙의 빈칸은 md로, 어떤 규칙에도 없던 실수는 새 규칙으로, 그리기 실수는 그리는 에이전트에게 돌아간다.

제약은 현실적인 것들이다. 호출 한 번에 출력이 20KB로 제한돼서 라이브러리 하나에 호출이 수십 번 든다. 이미지와 커스텀 폰트는 쓸 수 없다.

스펙은 무엇을 만들지 말한다. 룰북은 무엇을 틀리지 말지 말한다. 룰북은 .claude/rules/에 있고, 스펙과 같은 방식으로 나눈다.

foundations/는 간격, 색, 타입, radius를 다룬다. 하드코딩 값 금지, 간격은 스케일에서만, 형제 요소 사이 간격 일치. ui-patterns/는 버튼, 검색, 입력, 선택 같은 단일 패턴을 다룬다. ux-patterns/는 흐름을 다룬다. 폼 제출, 에러에서의 복구, 빈 상태. figma/는 만드는 방식을 다룬다. 모든 fill과 gap은 variable에 연결, variant 이름은 Property=Value, 고정 위치 대신 auto layout.

규칙은 실수에서 시작한다. 들쭉날쭉한 간격이나 빠진 focus 상태가 두 번 나오면, 그건 더 이상 리뷰 코멘트가 아니라 규칙이 된다. 그때부터는 내가 보기 전에 검수 에이전트가 잡는다. Figma도 같은 방향을 가리킨다. create_design_system_rules 도구는 팀의 적히지 않은 관례를 에이전트가 읽는 규칙 파일로 옮기려고 만들어졌다.

반복은 더 나은 프롬프트가 아니다. 회차마다 스펙과 룰북이 조금씩 더 채워지는 것이다. 그리는 일과 검수는 에이전트가 한다. 그 파일들 안의 결정은 여전히 내 몫이다.