컴포넌트 Detach. 디자인 시스템 운영자라면 이 단어만으로 속이 쓰리다.

디자이너가 인스턴스를 Detach하는 순간, 그 컴포넌트는 시스템에서 이탈한다. 색상 토큰이 바뀌어도 반영 안 되고, 스펙 문서와 Figma 파일 사이에 유령 같은 차이가 쌓인다. 그래서 디자인 시스템 팀은 "가능한 모든 변형을 Variant로 만들어야 한다"는 강박에 시달려왔다. 버튼 하나에 Variant 48개. 카드 컴포넌트에 Property 12개. 유지보수 비용은 기하급수적으로 불어난다.

Figma가 이번 3월에 공개한 Slots는 이 악순환을 정면으로 겨냥한다.

Slots가 바꾸는 것

Slots는 인스턴스 안에 동적으로 요소를 추가하거나 교체하되, 라이브 업데이트를 유지하는 기능이다. Detach 없이 아이콘 교체, 메뉴 항목 추가가 가능하고, 토큰 값이 바뀌면 확장된 인스턴스에도 그대로 반영된다.

Variant 48개 시대의 종말

여기서 내 핫테이크: 디자인 시스템 팀의 절반은 Variant 정리부터 다시 해야 한다.

지금까지 디자인 시스템 설계의 암묵적 규칙은 "Detach를 막으려면 모든 경우의 수를 미리 정의하라"였다. Slots는 이 전제 자체를 부순다. 모든 경우의 수를 정의할 필요가 없다. 확장 가능한 기본 구조만 잡으면 된다.

실무에서 어떤 차이가 나는지 구체적으로 보자. 네비게이션 바 컴포넌트를 만든다고 하면, 기존 방식에서는 메뉴 아이템이 3개인 버전, 4개인 버전, 5개인 버전을 각각 Variant로 만들거나, Boolean Property를 잔뜩 달아서 아이템을 표시/숨김 처리했다. 여기에 아이콘 유무, 뱃지 유무까지 조합하면 Variant가 20개를 넘기는 건 일도 아니다. Slots에서는 기본 네비게이션 바 하나에 아이템 Slot을 열어두고, 디자이너가 필요한 만큼 아이템을 넣으면 된다. Variant 수는 1개. 라이브 업데이트도 유지.

테이블 컴포넌트는 더 극적이다. 셀 안에 텍스트만 들어가는 경우, 아이콘+텍스트, 뱃지, 프로그레스바 — 이런 조합을 전부 Variant로 커버하려 했던 팀이라면 Slots 도입만으로 컴포넌트 복잡도가 한 자릿수로 줄어들 수 있다.

체감상 Detach의 70%는 사소한 이유에서 발생한다. 아이콘 하나 교체, 리스트 아이템 하나 추가, 텍스트 영역에 뱃지 하나 끼워넣기. Slots가 이 영역을 커버하면 Variant 수를 절반 이하로 줄여도 Detach 비율은 오히려 떨어진다. 디자이너는 시스템 안에서 유연하게 작업하고, 개발자는 스펙 불일치 지옥에서 벗어난다.

한 가지 비교해볼 만한 건 Subframe이나 Plasmic 같은 코드 기반 디자인 툴의 접근이다. 이쪽은 처음부터 컴포넌트를 코드 레벨에서 합성(composition)하기 때문에 Variant 폭발 문제 자체가 없다. React의 children prop 같은 개념을 디자인 단에서 쓰는 셈인데, Figma Slots가 결국 같은 방향으로 온 거다. 차이는 Figma가 이미 디자이너의 손에 깊이 들어와 있다는 점. 생태계 크기가 채택 속도를 결정한다.

Copilot x Figma MCP: 동기화까지 닫히는 루프

같은 주에 공개된 GitHub Copilot x Figma MCP 서버 연동도 이 맥락에서 봐야 한다. Figma 캔버스의 프레임을 코드로 풀링하고, 코드에서 렌더링한 UI를 다시 캔버스에 푸시하는 양방향 파이프라인이 열렸다. Slots로 Detach 없이 살아 있는 컴포넌트 + 코드 동기화. 디자인 시스템의 Single Source of Truth가 Figma 파일 그 자체가 되는 시나리오가 갑자기 현실적으로 변했다.

이전에도 Storybook 연동이나 Figma REST API를 활용한 디자인-코드 브리지 시도가 많았지만, 대부분 한쪽 방향이었다. 디자인에서 코드로 추출하거나, 코드 변경을 디자인에 수동으로 반영하거나. MCP 서버가 제공하는 양방향 파이프는 이 비대칭을 깬다. Slots가 Detach를 없애서 Figma 파일의 신뢰성을 높이고, MCP가 그 신뢰성 높은 파일을 코드와 실시간으로 묶는다. 두 기능이 따로 나온 것 같지만, 합쳐졌을 때 시너지가 뚜렷하다.

반론: Slots가 만능은 아닌 이유

구조적으로 완전히 다른 레이아웃이 필요하면 별도 Variant가 맞다. 모달의 사이즈별 버전처럼 내부 배치 자체가 달라지는 케이스, 반응형 분기점마다 골격이 바뀌는 케이스는 Slot으로 해결할 수 없다. Slot은 같은 골격 안에서 내용물을 바꾸는 도구다. 팀 규모가 크면 Slot의 자유도가 오히려 시각적 일관성을 무너뜨릴 수 있으니, 전환할 때 가이드라인과 Lint 규칙을 반드시 함께 만들어야 한다.

그래도 "Variant를 48개 만들어야 안심"이던 시대는 끝났다고 본다. 지금 라이브러리 열어서 Variant 목록부터 다시 보는 게 맞다. Slot으로 대체할 수 있는 Variant를 골라내고, 남겨야 할 Variant는 구조적 차이가 진짜 있는 것만 추리는 작업 — 이번 분기에 안 하면 다음 분기엔 더 미루기 어렵다.