이름은 검색 가능한 구조로 씁니다
컴포넌트가 많아질수록 이름 규칙이 중요해집니다. `Button 1`, `New Card`, `Frame copy` 같은 이름은 파일을 함께 보는 사람에게 아무 정보도 주지 못합니다.
버튼이라면 `Button / Primary / Large`, 카드라면 `Card / Article / Default`처럼 범주, 역할, 상태를 순서대로 적는 방식이 좋습니다. 검색 가능한 이름은 작업 속도를 직접적으로 높입니다.
Variants는 상태를 관리하기 위한 장치입니다
기본, hover, disabled, selected처럼 같은 컴포넌트의 상태가 여러 개라면 variants로 묶어야 합니다. 상태가 흩어져 있으면 화면마다 버튼 모양이 달라지고, 수정할 때 누락이 생깁니다.
상태값은 디자인 시스템의 언어입니다. 색, 테두리, 그림자, 글자 굵기가 왜 달라지는지 기준이 있어야 다른 사람이 같은 방식으로 확장할 수 있습니다.
Auto layout은 반응형 사고를 키웁니다
Auto layout은 정렬을 편하게 해주는 기능을 넘어 콘텐츠가 길어졌을 때 화면이 어떻게 버틸지 생각하게 만듭니다. 버튼 문구가 길어질 때, 카드 제목이 두 줄이 될 때, 아이콘이 사라질 때의 상태를 미리 확인할 수 있습니다.
웹으로 구현될 화면이라면 고정 위치만 믿어서는 안 됩니다. 실제 사용자는 다양한 화면 크기와 글자 길이를 만나기 때문에 Auto layout 기준으로 유연성을 확인해야 합니다.
컴포넌트 문서화는 포트폴리오 설명이 됩니다
컴포넌트를 만든 이유, 사용 범위, 예외 상황을 짧게 적어두면 파일은 단순한 시안이 아니라 설계 문서가 됩니다. 이 기록은 팀 작업에서도 좋고 포트폴리오에서도 강한 근거가 됩니다.
입문자가 디자인 시스템을 완벽히 만들 필요는 없습니다. 다만 한 화면 안에서 반복되는 버튼, 카드, 탭, 입력창 정도는 같은 규칙으로 묶는 습관이 필요합니다.
컴포넌트 이름 예시: 버튼 시스템 만들기
피그마 컴포넌트는 한 번 만들고 끝나는 요소가 아닙니다. 이름, 변형, 속성이 정리되어 있어야 여러 화면에서 일관되게 사용할 수 있습니다.
Button 1, Button copy처럼 이름이 쌓이기 시작하면 팀원이 어떤 버튼을 써야 할지 판단할 수 없습니다.
컴포넌트 명명 기준
| Button/Primary | 가장 중요한 행동에 사용하는 기본 버튼입니다. |
|---|---|
| Button/Secondary | 보조 행동이나 이전 단계 이동에 사용합니다. |
| State=Disabled | 클릭할 수 없는 상태의 색과 커서를 명확히 구분합니다. |
| Size=Mobile | 모바일 터치 영역을 기준으로 높이와 여백을 따로 둡니다. |
변형을 줄이는 판단
모든 색과 크기를 변형으로 만들기보다 실제 제품에서 반복되는 조합만 남겨야 합니다. 변형이 너무 많으면 시스템이 아니라 또 다른 파일 정리가 됩니다.
- 컴포넌트 이름만 보고 역할을 알 수 있는가?
- 상태값이 색상 이름이 아니라 기능 기준으로 정리되어 있는가?
- 모바일과 데스크톱의 터치 기준이 구분되어 있는가?
- 쓰지 않는 변형이 계속 남아 있지 않은가?
작성자 검수 메모
피그마 컴포넌트는 화면 제작 속도를 올리는 도구이면서 팀의 약속입니다. 이름이 정확하면 디자인 의사결정도 빨라집니다.
이 글은 피그마 컴포넌트를 이름, 변형, 상태, 크기 기준으로 정리하는 방법을 설명했습니다.
현장 적용 노트
컴포넌트 이름은 파일 내부의 검색 시스템입니다. 이름이 정확하면 팀원이 같은 버튼을 다시 만들지 않고 기존 요소를 찾을 수 있어 디자인 시스템의 중복이 줄어듭니다.
변형은 많을수록 좋은 것이 아닙니다. 실제 화면에서 반복되는 상태와 크기만 남겨야 사용자가 선택할 때 고민하지 않고 일관된 UI를 만들 수 있습니다.
포트폴리오 기록 포인트
작업 기록에는 컴포넌트 구조와 함께 잘라낸 변형도 남기면 좋습니다. 어떤 변형을 만들지 않았는지 설명하면 시스템을 가볍게 유지한 판단이 보입니다.
컴포넌트가 늘어날 때 무너지지 않는 규칙
피그마 컴포넌트는 처음 만들 때보다 화면이 늘어난 뒤에 관리 난도가 올라갑니다. 버튼 하나를 고칠 때 여러 화면이 동시에 바뀌어야 한다면 이름, 속성, 변형 기준이 분명해야 합니다. 상태를 색상 이름으로만 나누면 나중에 의미가 흐려지므로 사용 목적과 상태를 함께 적는 방식이 안정적입니다.
- Primary, Secondary처럼 역할을 먼저 정하고 색상은 그 다음에 둡니다.
- Hover, Disabled, Loading 상태가 같은 위치에 묶였는지 봅니다.
- 인스턴스에서 자주 바꾸는 값은 속성으로 노출합니다.
컴포넌트 설명을 파일 안에 남기기
피그마 컴포넌트가 많아지면 만든 사람만 규칙을 아는 상태가 되기 쉽습니다. 주요 컴포넌트 옆에는 사용 목적, 바꾸면 안 되는 속성, 자주 쓰는 변형을 짧게 적어두면 협업자가 실수 없이 사용할 수 있습니다.
문서가 길 필요는 없습니다. 버튼, 입력창, 카드처럼 반복 사용되는 요소에만 설명을 붙여도 파일의 신뢰도가 크게 올라갑니다.