4장. 컴포넌트와 변형 — 재사용 가능한 디자인의 시작

피그마를 배우다 보면 어느 순간 아주 비슷한 장면이 반복된다. 버튼을 하나 예쁘게 만들었다. 그다음 화면이 늘어난다. 로그인 화면에도 같은 버튼이 들어가고, 설정 화면에도 들어가고, 결제 화면에도 들어간다. 처음에는 복사해서 붙여 넣는다. 빠르니까. 그런데 며칠 뒤 누군가 말한다. "버튼 모서리를 조금만 더 둥글게 바꿔 주세요." 그 순간부터 복사해 둔 과거의 나와 싸우기 시작한다.

바로 여기서 컴포넌트가 등장한다. 컴포넌트는 같은 것을 여러 번 그리지 않게 해 주는 기능이 아니다. 더 정확히 말하면, 같은 것을 여러 번 그려도 한 번에 고칠 수 있게 해 주는 구조다. 그리고 변형은 그 구조에 유연성을 더한다. 버튼의 크기, 상태, 종류처럼 "비슷하지만 다른 것들"을 한 가족으로 묶어 주는 방식이다.¹

이 장은 기능 설명으로 끝나지 않는다. 목표는 하나다. 화면 한 장을 예쁘게 만드는 감각에서, 반복 가능한 제품을 설계하는 감각으로 넘어가는 것. 이 전환이 일어나면 피그마 파일이 더 이상 그림 모음이 아니라 작은 제조 공장처럼 보이기 시작한다.

컴포넌트는 복붙의 고급판이 아니다

컴포넌트를 처음 배울 때 가장 쉬운 비유는 도장이다. 원본 도장이 하나 있고, 여기저기 찍힌 도장 자국이 있다. 원본을 바꾸면 찍힌 것들도 함께 바뀐다. 피그마에서 원본은 메인 컴포넌트, 찍힌 것들은 인스턴스다.²

예를 들어 앱 전체에서 쓰는 기본 버튼을 생각해 보자. 배경색, 텍스트 스타일, 패딩, 모서리 반경, 아이콘 간격까지 한 번 정리해서 메인 컴포넌트로 만들어 둔다. 그다음 다른 화면에서는 그 버튼의 인스턴스를 꺼내 쓴다. 이제 버튼 색을 바꾸거나 높이를 수정해야 할 때, 스무 개의 화면을 돌아다니며 손으로 고칠 필요가 없다. 원본 하나를 손보면 연결된 인스턴스가 따라온다.²

이게 왜 중요할까. 이유는 간단하다. 제품은 반복으로 이루어져 있기 때문이다. 화면은 달라도 버튼은 반복되고, 카드도 반복되고, 입력창도 반복된다. 실무에서 시간이 드는 일은 새로운 것을 한 번 만드는 일이 아니라, 같은 것을 여러 번 맞추는 일이다. 컴포넌트는 바로 그 반복 비용을 줄인다.

그래서 컴포넌트를 만든다는 것은 예쁜 조각 하나를 저장하는 일이 아니다. "이 요소는 앞으로도 계속 다시 등장한다"라고 선언하는 일에 가깝다. 한 번 쓰고 말 장식은 그냥 레이어여도 된다. 하지만 제품의 문법이 되는 요소라면 컴포넌트여야 한다.

메인 컴포넌트와 인스턴스 — 연결된 복제의 감각

컴포넌트를 제대로 쓰려면 먼저 메인 컴포넌트와 인스턴스의 관계를 몸으로 이해해야 한다.

메인 컴포넌트는 기준본이다. 구조와 기본 스타일, 바뀌어야 할 규칙이 여기에 들어 있다. 인스턴스는 그 기준본을 화면에 가져다 놓은 사용본이다. 연결은 유지하되, 필요한 부분만 상황에 맞게 바꿀 수 있다. 예를 들어 버튼 인스턴스에서는 텍스트를 "저장"에서 "다음"으로 바꿀 수 있고, 카드 인스턴스에서는 썸네일 이미지만 다른 것으로 교체할 수 있다.

중요한 점은 모든 것이 마음대로 바뀌어서는 안 된다는 것이다. 초보자는 인스턴스를 놓고 이것저것 덮어쓰기 시작한다. 색도 바꾸고, 간격도 바꾸고, 구조도 바꾼다. 당장은 편하지만, 이런 인스턴스가 쌓이면 시스템은 금방 흐트러진다. 연결된 복제를 쓴다는 것은 "어디까지는 자유롭고, 어디부터는 기준을 따라야 하는가"를 함께 설계한다는 뜻이다.

2026년의 피그마가 이 부분을 더 중요하게 다루는 이유도 여기에 있다. 컴포넌트 속성은 인스턴스에서 바꿔도 되는 지점을 한곳에 모아 보여 주고, 2026년 3월부터는 간소화된 인스턴스가 사라지면서 이런 속성이 더 일관되게 드러난다.³ 쉽게 말해, 디자이너가 "여긴 바꿔도 되고, 여긴 건드리면 안 돼요"를 파일 자체로 말할 수 있게 된 것이다.

좋은 인스턴스 사용은 그래서 의외로 절제에 가깝다. 매번 뜯어고치는 대신, 필요한 변화가 반복된다면 메인 컴포넌트 쪽으로 끌어올린다. "이건 인스턴스에서 억지로 고칠 게 아니라 원래부터 선택 가능해야 하는 옵션이었네?"라는 생각이 들면, 그 순간이 시스템으로 한 단계 올라가는 순간이다.

좋은 컴포넌트는 단단한 뼈대와 바뀌는 지점을 함께 가진다

그렇다면 컴포넌트에서 무엇을 고정하고, 무엇을 열어 둬야 할까. 이 질문에 답하는 도구가 컴포넌트 속성이다.³

피그마의 컴포넌트 속성은 크게 이렇게 생각하면 쉽다.

• 텍스트 속성은 문구를 바꾸게 해 준다.

• 불리언 속성은 보이기/숨기기를 켜고 끄게 해 준다.

• 인스턴스 스왑 속성은 내부의 다른 컴포넌트를 갈아 끼우게 해 준다.

• 변형 속성은 상태나 크기처럼 구조적으로 다른 버전을 선택하게 해 준다.

• 슬롯 속성은 내부에 내용을 넣고 바꾸는 유연한 영역을 만든다.³

말이 조금 많아 보이지만, 버튼 하나로 생각하면 훨씬 쉽다. 버튼 텍스트는 텍스트 속성이다. 왼쪽 아이콘을 넣을지 말지는 불리언 속성이다. 아이콘 종류를 바꾸는 것은 인스턴스 스왑 속성이다. 그리고 버튼의 크기나 상태, 종류는 변형 속성으로 관리하는 편이 자연스럽다.

여기서 핵심은 "변화의 종류가 다르면 도구도 다르게 써야 한다"는 점이다. 단순히 텍스트가 달라지는 일과, 버튼이 hover 상태가 되는 일은 같은 수준의 변화가 아니다. 전자는 내용의 변화이고, 후자는 컴포넌트 상태의 변화다. 이 둘을 구분하지 않으면 모든 것을 변형으로 만들게 되고, 그러면 버튼 하나가 금방 괴물이 된다.

변형은 비슷한 것들을 한 세트로 묶는 법이다

변형은 서로 닮은 컴포넌트를 하나의 컴포넌트 세트로 묶는 기능이다. 예를 들어 버튼의 Primary, Secondary, Disabled, Large, Small 같은 버전을 제각각 흩어 놓는 대신, 하나의 Button 세트 안에서 관리하게 해 준다.¹

이 방식의 장점은 단순하다. 찾기 쉽고, 바꾸기 쉽고, 이해하기 쉽다. 사용하는 사람 입장에서는 에셋 패널에서 비슷한 버튼 다섯 개를 뒤지지 않아도 된다. Button을 하나 꺼내고 오른쪽 패널에서 Size, State, Type 값을 고르면 된다. 사용하는 경험 자체가 훨씬 제품답다.⁴

변형은 속성과 값으로 이루어진다. 속성은 무엇을 바꿀지 정하는 축이고, 값은 그 축에서 선택할 수 있는 옵션이다.¹ 버튼으로 말하면 이렇다.

• Size: Small, Medium, Large

• State: Default, Hover, Pressed, Disabled

• Type: Primary, Secondary, Tertiary

이 구조의 매력은 이름만 봐도 의도가 읽힌다는 데 있다. 그냥 버튼 세 개가 나열되어 있으면 보는 사람이 추측해야 한다. 하지만 Type=Primary, State=Disabled처럼 읽히면 설명 없이도 사용법이 보인다. 이건 단순히 정리의 문제가 아니라, 파일이 말문을 갖게 되는 일이다.

또 하나 기억할 점이 있다. 변형 세트 안의 각 조합은 서로 구분되는 고유한 조합이어야 한다.¹ 즉 Size=Medium, State=Default, Type=Primary가 두 개 있으면 안 된다. 생김새가 조금 달라도 값 조합이 같으면 시스템은 헷갈린다. 사람도 헷갈리고, 나중에 코드로 이어질 때도 헷갈린다.

작은 팁도 있다. 피그마는 변형 세트의 왼쪽 위에 놓인 것을 기본 변형처럼 다룬다.¹ 그래서 가장 대표적인 상태를 왼쪽 위에 두는 습관이 좋다. 대개는 Primary / Medium / Default 같은 가장 기본형이 그 자리를 차지한다.

언제 변형을 만들고, 언제 속성으로 빼야 할까

이 장에서 가장 중요한 실전 감각은 바로 이것이다. 비슷한 것은 다 변형으로 묶으면 될 것 같지만, 실제로는 그렇지 않다.

가장 흔한 실수는 버튼 하나에 가능한 모든 경우의 수를 다 변형으로 만들어 버리는 것이다. 크기 3종, 상태 4종, 종류 3종, 아이콘 유무 2종, 아이콘 위치 2종, 테마 2종을 곱하면 순식간에 144개가 된다. 버튼 하나가 아니라 버튼 농장이 된다.

그래서 실무에서는 "구조적 차이"와 "선택 가능한 옵션"을 나눠 생각해야 한다. Figma도 비슷한 방향을 권한다. 상태, 크기, 종류처럼 컴포넌트의 의미 있는 버전 차이는 변형으로 묶고, 아이콘 유무처럼 단순한 on/off는 불리언 속성으로, 아이콘 종류는 인스턴스 스왑으로 처리하는 편이 더 낫다.³⁴

특히 색상 테마나 브랜드 분기까지 변형으로 밀어 넣는 것은 대개 좋지 않다. 이런 값은 경우의 수를 폭발시키기 쉽고, 유지보수 비용을 크게 만든다. 이런 변화는 변형보다 변수와 모드로 다루는 편이 훨씬 안정적이다.⁴ 바로 앞 장에서 변수 이야기를 길게 한 이유가 여기서 드러난다. 변형은 구조를 바꾸고, 변수는 값을 바꾼다. 둘의 역할이 다르다.

간단히 기준을 세우면 이렇다.

• 사용자가 "이 컴포넌트의 종류나 상태를 고른다"면 변형을 먼저 생각한다.

• 사용자가 "이 컴포넌트의 일부를 켜고 끄거나 내용만 바꾼다"면 컴포넌트 속성을 먼저 생각한다.

• 값의 변화가 테마, 브랜드, 모드처럼 시스템 전반에 퍼진다면 변수 쪽을 먼저 생각한다.

이 구분이 잡히면 컴포넌트가 갑자기 가벼워진다. 그리고 가벼운 컴포넌트가 오래 산다.

이름을 잘 짓는 순간, 에셋 패널이 덜 무섭다

컴포넌트는 만드는 것만큼 이름 짓는 일이 중요하다. 피그마는 슬래시 /를 이용해 컴포넌트를 계층적으로 보여 준다. 그래서 이름만 잘 지어도 에셋 패널이 폴더처럼 정리된다.¹

예를 들어 Button/Primary, Button/Secondary, Input/Text, Input/Search처럼 정리하면, 라이브러리를 처음 보는 사람도 어디를 뒤져야 할지 감이 온다. 이미 만들어 둔 컴포넌트를 변형으로 바꾸고 싶을 때도 이 슬래시 구조가 도움이 된다. 이름 구조가 일정하면 피그마가 그것을 읽어 변형 속성과 값으로 바꾸기 쉽다.¹

여기서 중요한 것은 예쁘게 이름 짓는 것이 아니라, 판단 기준을 드러내는 이름을 짓는 것이다. Button/Blue/Big보다 Button/Primary/Large가 좋은 이유는 파란색이 나중에 보라색으로 바뀔 수 있지만, Primary라는 역할은 훨씬 오래가기 때문이다. 이름은 생김새보다 의미에 가깝게 붙이는 편이 시스템에 유리하다.

레이어 이름도 마찬가지다. 버튼 안의 텍스트 레이어가 어떤 변형에서는 Label이고, 다른 변형에서는 Text 4라면 나중에 속성을 연결하거나 오버라이드를 유지할 때 불편해진다. 컴포넌트는 겉만 맞는다고 되는 게 아니다. 안쪽 이름까지 질서가 있어야 오래 버틴다.

중첩 컴포넌트부터 시스템 사고가 시작된다

컴포넌트의 진짜 재미는 하나를 잘 만드는 데 있지 않다. 작은 컴포넌트를 엮어 더 큰 컴포넌트를 만들 때 비로소 시스템이 보인다.

예를 들어 카드 컴포넌트를 만든다고 해 보자. 카드 안에는 아바타, 배지, 제목, 설명, 버튼이 들어갈 수 있다. 이 요소들을 전부 카드 안에서 따로 그리면 카드 하나는 만들 수 있다. 하지만 그 순간부터 아바타 수정은 카드마다 따로 해야 하고, 배지 스타일이 바뀌면 모든 카드를 뒤져야 한다.

반대로 아바타, 배지, 버튼을 각각 독립된 컴포넌트로 만들고 카드 안에는 그것들의 인스턴스를 넣으면 이야기가 달라진다. 이제 카드의 구조는 카드가 책임지고, 버튼의 생김새는 버튼 컴포넌트가 책임진다. 문제가 생겨도 수정 범위가 선명하다. 이게 바로 중첩 컴포넌트의 힘이다.²⁵

이 관점은 디자인 시스템에서 아주 중요하다. 작은 단위가 먼저 안정되어야 큰 단위도 안정된다. 흔히 원자, 분자, 유기체 같은 말로 설명하는 이유도 여기 있다.⁵ 버튼과 아이콘 같은 작은 단위가 원자라면, 검색창이나 카드 헤더 같은 것은 그 원자들이 합쳐진 분자에 가깝다. 그리고 내비게이션 바나 상품 카드 리스트는 더 큰 단위가 된다. 꼭 이 용어를 외울 필요는 없다. 다만 "큰 UI는 작은 반복 가능한 조각들로 이루어진다"는 감각은 꼭 가져가야 한다.

이 감각을 가지면 화면을 대하는 태도도 바뀐다. 더 이상 카드 한 장을 완성하는 데서 멈추지 않는다. "이 카드에서 앞으로 반복될 조각은 무엇이지?", "어떤 부분은 다른 컴포넌트를 재사용해야 하지?" 같은 질문이 자연스럽게 따라온다.

변형을 잘 쓰는 사람은 '비슷함의 경계'를 잘 그린다

실무에서 가장 어려운 것은 변형을 만드는 기술이 아니라, 어디까지를 같은 가족으로 볼지 정하는 판단이다.

버튼의 Default, Hover, Disabled는 대개 한 가족이다. 크기가 Small, Medium, Large로 달라도 여전히 한 가족이다. 그런데 버튼과 링크는 어떨까. 겉으로는 비슷해 보여도 구조와 사용 목적이 다르면 굳이 한 세트로 억지로 묶지 않는 편이 낫다. 카드도 마찬가지다. 썸네일 위치만 다른 카드라면 변형일 수 있지만, 정보 구조 자체가 다르면 별도 컴포넌트가 더 명확할 수 있다.

좋은 기준은 "같은 질문에 답하는가"다. 같은 컴포넌트를 놓고 사용자가 State, Size, Type 같은 공통 질문으로 선택할 수 있다면 변형으로 묶기 좋다. 반대로 어떤 것은 이미지 중심이고 어떤 것은 표 중심이라서 아예 다른 판단 체계를 요구한다면, 이미 다른 컴포넌트일 가능성이 크다.

이 경계를 잘 그으면 에셋 패널이 정리되고, 팀의 언어도 정리된다. "그 버튼 써"가 아니라 "Button의 Secondary, Medium, Disabled 써"라고 말할 수 있게 된다. 말이 정리되면 작업도 빨라진다.

자주 하는 실수

컴포넌트와 변형은 강력하지만, 잘못 쓰면 오히려 파일을 더 무겁게 만든다. 특히 아래 실수는 초반에 자주 나온다.

• 인스턴스를 계속 고치다가 결국 모든 화면이 제각각이 된다.

• 단순한 텍스트 변경까지 변형으로 만들어 경우의 수를 불린다.

• 아이콘 종류마다 전부 변형을 만들어 라이브러리를 과하게 키운다. 피그마도 서로 다른 아이콘을 변형으로 묶는 방식은 권하지 않는다.¹

• 테마와 브랜드 차이까지 변형으로 처리해 세트가 지나치게 비대해진다.⁴

• 이름을 Button 1, Button Final, Button Final 2 진짜최종처럼 지어 나중에 아무도 찾지 못한다.

• 필요할 때마다 인스턴스를 떼어내고(detach) 다시는 연결하지 않는다.

이런 실수의 공통점은 하나다. 당장의 편의를 위해 구조를 포기했다는 점이다. 물론 급한 작업에서는 그럴 수 있다. 하지만 제품을 오래 운영할수록 구조의 빚은 반드시 돌아온다. 그리고 보통 월요일 오전에 돌아온다.

이제 화면이 아니라 시스템을 설계한다

이번 장의 핵심은 컴포넌트 기능을 익히는 데 있지 않다. 진짜 핵심은 사고방식의 전환이다.

한 번 그리는 디자이너는 화면 단위로 생각한다. 이 페이지, 저 페이지, 오늘 필요한 시안. 하지만 반복 가능한 제품을 만드는 디자이너는 규칙 단위로 생각한다. 버튼은 어떤 뼈대를 가져야 하는가. 카드에서 바뀌는 지점은 무엇인가. 상태 변화는 변형으로 다룰까, 속성으로 다룰까. 어디까지를 같은 가족으로 묶을까.

이 질문을 하기 시작하면, 피그마 작업 속도가 단순히 빨라지는 수준을 넘어선다. 팀이 같은 것을 같은 이름으로 부르게 되고, 수정이 두려움이 아니라 관리 가능한 변경이 된다. 그리고 다음 단계인 디자인 시스템으로 넘어갈 준비가 된다.

이제부터 중요한 것은 "컴포넌트를 만들 줄 안다"가 아니다. "컴포넌트로 사고할 줄 안다"다. 그 차이가, 한 번 그리는 사람과 반복 가능한 제품을 만드는 사람을 가른다.

참고

¹Create and use variants – Figma Learn - Help Center

²Components, styles, and shared library best practices

³Explore component properties – Figma Learn - Help Center

⁴Creating and organizing Variants

⁵Building a Future-Proof Component Library in Figma 2026: The Ultimate Guide