피그마 컴포넌트 제대로 만들기 — 변형과 프로퍼티 설계

버튼 하나를 수정하려고 화면 마흔 개를 일일이 열어본 적이 있는가. 인스턴스마다 텍스트 크기가 다르고 아이콘 위치가 제각각이라면, 그건 컴포넌트가 아니라 그냥 복사해서 붙여넣은 도형 뭉치일 뿐이다. 피그마 컴포넌트를 제대로 만든다는 것은 나중에 바뀔 것과 바뀌지 않을 것을 미리 구분해두는 작업이다. 그 구분을 처음에 해두느냐 나중에 손대느냐의 차이가 프로젝트 후반부의 작업 속도를 가른다.

1. 그리기 전에 구조부터 그려라

많은 디자이너가 캔버스를 열자마자 바로 버튼을 그리기 시작한다. 하지만 컴포넌트 설계는 그리기 전에 메모장에서 먼저 끝내야 하는 작업이다. 이 버튼이 가질 수 있는 상태는 몇 가지인가, 기본과 호버와 눌림과 비활성을 모두 다룰 것인가. 크기는 몇 단계로 나눌 것인가.

이런 질문에 답하지 못한 채로 변형을 늘려가면 조합이 기하급수적으로 불어나 나중에는 관리가 불가능한 상태가 된다. 종이 한 장에 상태와 크기와 예외 케이스를 표로 그려보는 것만으로도 컴포넌트 구조의 절반은 끝난 셈이다.

2. 왜 굳이 컴포넌트인가

같은 모양을 여러 화면에 반복해서 그려도 당장은 문제가 없어 보인다. 문제는 나중에 그중 하나만 살짝 다르게 그려졌을 때 드러난다. 컴포넌트는 원본과 인스턴스를 연결해두어, 원본을 고치면 모든 인스턴스가 함께 바뀌게 만드는 장치다. 복사해서 붙여넣은 도형은 그 순간부터 원본과 아무 관계가 없어지지만, 컴포넌트의 인스턴스는 끝까지 원본과 연결된 채로 남는다.

3. 변형과 프로퍼티, 언제 나눠 써야 하나

변형은 서로 다른 인스턴스를 하나의 컴포넌트 세트 안에 묶어 드롭다운으로 전환할 수 있게 해주는 기능이고, 프로퍼티는 그 안에서 텍스트나 아이콘, 노출 여부를 세밀하게 바꾸는 기능이다. 실무에서 자주 하는 실수는 상태와 크기, 색상 테마까지 전부 변형 축으로 넣어 변형 개수가 수십 개로 불어나는 것이다.

색상처럼 디자인 토큰으로 관리할 수 있는 값은 변형이 아니라 변수 바인딩으로 분리하는 편이 낫다.

4. 중첩 컴포넌트와 라이브러리 배포 전 점검

버튼 안에 아이콘 컴포넌트를 중첩하고, 그 버튼을 다시 카드 컴포넌트 안에 중첩하는 구조는 실무에서 흔하다. 문제는 중첩이 깊어질수록 상위 인스턴스에서 하위 레이어를 오버라이드했을 때, 원본 컴포넌트가 바뀌면 그 오버라이드가 깨지거나 예기치 않게 리셋되는 경우가 생긴다는 점이다. 중첩 컴포넌트를 쓸 때는 하위 컴포넌트의 프로퍼티를 상위 컴포넌트 프로퍼티에 연결해 노출시켜두면 구조가 훨씬 안정적으로 유지된다.

컴포넌트를 팀 라이브러리로 게시하는 순간부터는 혼자 쓰는 파일이 아니라 여러 사람이 의존하는 공용 자산이 된다. 게시하기 전에는 이름 규칙이 팀 컨벤션과 맞는지, 설명란에 사용 맥락이 적혀 있는지, 변형 값 이름이 코드에서 그대로 매핑될 수 있는 영문 표기인지 확인해야 한다. 이런 준비 없이 게시하면 개발자가 Dev Mode에서 컴포넌트를 열었을 때 무엇을 의미하는지 몰라 다시 디자이너에게 물어보는 일이 반복되고, 결국 컴포넌트 라이브러리에 대한 신뢰가 낮아진다.

컴포넌트 구조를 잡을 때 색상이나 간격처럼 반복되는 값을 어떻게 다뤄야 하는지 궁금하다면 디자인 토큰이란 무엇인가 글을 함께 보면 도움이 된다. 팀 단위로 라이브러리를 운영하면서 반복 작업을 줄이고 싶다면 디자인 시스템에 AI를 넣는 방법도 참고할 만하다. 컴포넌트와 변형에 대한 공식 개념 정리는 피그마 공식 가이드에서 확인할 수 있다.

5. 마치며

결국 좋은 컴포넌트는 화면이 아니라 시스템을 위해 설계된다. 변형과 프로퍼티의 경계를 명확히 하고, 게시 전 체크리스트를 습관으로 만들면 팀이 커져도 컴포넌트가 발목을 잡는 일은 크게 줄어든다. 흔히 하는 오해는 변형을 많이 만들수록 유연한 컴포넌트라고 생각하는 것인데, 실제로는 변형이 늘어날수록 관리 부담도 함께 커진다. 오늘 작업 중인 컴포넌트 하나를 골라 이 체크리스트로 다시 점검해보자.