Components로 반복 UI를 재사용하기

반복되는 UI를 '복사'하지 말고 '재사용'하기

피그마를 처음 배울 때는 화면을 하나 만들고, 필요한 요소를 복사해서 옆 화면에 붙여 넣는 방식이 가장 빠르게 느껴집니다. 버튼 하나를 만들고 Command/Ctrl + C, Command/Ctrl + V로 복사합니다. 입력창도 복사합니다. 카드도 복사합니다. 처음에는 아무 문제가 없어 보입니다.

그런데 화면이 3개에서 10개로, 10개에서 50개로 늘어나면 이야기가 달라집니다. 어느 날 팀에서 이런 요청이 옵니다.

"주요 버튼의 모서리를 8px에서 12px로 바꿔 주세요."

만약 버튼을 단순 복사로 50개 만들어 두었다면, 우리는 50개의 버튼을 하나씩 찾아가며 수정해야 합니다. 하나라도 놓치면 어떤 화면은 둥근 버튼이고, 어떤 화면은 덜 둥근 버튼이 됩니다. 디자인 파일은 점점 '어디가 진짜인지 알 수 없는 복사본 창고'가 됩니다.

이 문제를 해결하는 기능이 바로 Component, 즉 컴포넌트입니다. 컴포넌트는 반복해서 쓰는 UI 조각을 원본으로 등록해 두고, 필요한 곳에서는 복제본처럼 꺼내 쓰는 기능입니다. 중요한 점은 이 복제본이 단순 복사가 아니라 원본과 연결되어 있다는 것입니다.

실무에서 컴포넌트는 시간을 아끼는 기능이기도 하지만, 더 정확하게 말하면 팀의 실수를 줄이는 장치입니다. 버튼, 입력창, 카드, 탭, 네비게이션 항목처럼 반복되는 요소를 컴포넌트로 만들면 파일이 커져도 UI의 기준을 한곳에서 관리할 수 있습니다.

이 장에서는 컴포넌트의 원리를 먼저 이해한 뒤, 실제로 버튼과 입력창, 카드, 네비게이션 항목을 컴포넌트로 만드는 흐름을 익혀 보겠습니다.

Component와 Instance의 관계 이해하기

컴포넌트를 이해할 때 가장 쉬운 비유는 '도장'입니다. 도장 원본이 있고, 종이에 여러 번 찍은 결과물이 있습니다. 도장 모양을 바꾸면 앞으로 찍히는 모양이 달라집니다. 피그마의 컴포넌트는 여기서 한 걸음 더 나아갑니다. 이미 찍어 둔 결과물도 원본과 연결되어 있어서, 원본을 수정하면 연결된 결과물에 변화가 반영됩니다.

피그마에서는 원본을 Main Component라고 부릅니다. 화면에 가져다 쓰는 복제본은 Instance라고 부릅니다. 한국어로 풀어 말하면 Main Component는 '원본 컴포넌트', Instance는 '원본에서 만들어진 사용본'입니다.

예를 들어 Button / Primary라는 Main Component를 만들었다고 해 봅시다. 이 버튼을 로그인 화면, 회원가입 화면, 결제 화면에 각각 가져다 놓으면 세 화면에는 모두 Instance가 배치됩니다. 나중에 Main Component의 배경색을 파란색에서 보라색으로 바꾸면, 세 화면의 버튼 색상도 함께 바뀝니다.

이 구조를 알면 피그마에서 반복 UI를 다루는 방식이 완전히 달라집니다. 이제 중요한 것은 "화면마다 버튼을 예쁘게 만드는 것"이 아니라, "버튼의 원본을 잘 만들어 두고 필요한 곳에서 정확히 꺼내 쓰는 것"입니다.

개념 박스 — Main Component와 Instance
Main Component는 기준이 되는 원본입니다. 보통 컴포넌트 보관용 섹션이나 페이지에 정리합니다.
Instance는 원본을 가져와 실제 화면에서 사용하는 복제본입니다. 원본과 연결되어 있어 Main Component의 수정 사항을 따라갑니다.
Override는 Instance에서 일부 내용만 바꿔 쓰는 것을 말합니다. 예를 들어 버튼의 문구를 로그인에서 가입하기로 바꾸는 것이 Override입니다.

피그마 화면에서는 컴포넌트와 인스턴스를 보라색 마름모 아이콘으로 구분합니다. Main Component는 원본이라는 표시가 더 강하게 보이고, Instance는 원본에 연결된 사용본처럼 표시됩니다. 처음에는 아이콘보다 구조를 기억하는 편이 좋습니다. 원본은 한곳에, 사용본은 여러 화면에 놓인다고 생각하면 됩니다.

언제 컴포넌트로 만들어야 할까

모든 레이어를 컴포넌트로 만들 필요는 없습니다. 한 번만 쓰는 장식 요소까지 전부 컴포넌트로 만들면 오히려 관리가 복잡해집니다. 컴포넌트는 '반복'과 '기준'이 있는 요소에 적합합니다.

실무에서 컴포넌트로 만들기 좋은 요소는 다음과 같습니다.

• 여러 화면에서 반복해서 등장하는 요소

• 모양은 같지만 텍스트나 아이콘만 바뀌는 요소

• 나중에 한 번에 수정되어야 하는 요소

• 팀원들이 같은 기준으로 사용해야 하는 요소

버튼은 대표적인 컴포넌트 후보입니다. 로그인, 저장, 다음, 결제하기처럼 문구는 달라도 버튼의 높이, 모서리, 배경색, 텍스트 스타일은 일정해야 합니다. 입력창도 마찬가지입니다. 이메일 입력창, 비밀번호 입력창, 검색창은 내용은 달라도 기본 구조가 비슷합니다. 카드 UI도 상품 카드, 게시글 카드, 알림 카드처럼 여러 화면에 반복될 가능성이 높습니다.

반대로 특정 화면에서 한 번만 쓰는 큰 배너 이미지나 임시로 만든 설명 박스는 꼭 컴포넌트로 만들지 않아도 됩니다. 중요한 기준은 간단합니다. "이 요소를 나중에 또 쓸 것 같은가?" 그리고 "바뀔 때 한 번에 바뀌어야 하는가?" 이 두 질문에 둘 다 "예"라고 답할 수 있다면 컴포넌트로 만드는 것이 좋습니다.

버튼 컴포넌트 만들기

이전 장에서 Auto Layout을 사용해 버튼을 만들었다면, 컴포넌트화는 아주 자연스럽게 이어집니다. 컴포넌트는 단순한 모양 저장 기능이 아닙니다. 좋은 컴포넌트는 내부 구조가 안정적이어야 합니다. 그래서 버튼을 컴포넌트로 만들기 전에 먼저 Auto Layout으로 버튼의 구조를 잡아 두는 것이 좋습니다.

버튼 하나를 예로 들어 보겠습니다. 버튼은 보통 배경 프레임 안에 텍스트가 들어 있는 구조입니다. 아이콘이 필요한 버튼이라면 아이콘과 텍스트가 가로 방향으로 나란히 배치됩니다. 이때 버튼 프레임에 Auto Layout을 적용하면 문구가 길어져도 좌우 여백이 유지되고, 아이콘을 넣거나 빼도 간격을 일정하게 관리할 수 있습니다.

버튼을 만들 때 기본값은 다음처럼 잡아볼 수 있습니다.

버튼 구조를 만들었다면 버튼 프레임을 선택하고 컴포넌트로 변환합니다. 상단 툴바의 컴포넌트 아이콘을 눌러도 되고, 단축키를 사용해도 됩니다. 컴포넌트가 되면 레이어 이름 옆에 보라색 컴포넌트 아이콘이 표시됩니다.

⌨️ 단축키 박스 — 컴포넌트 기본 조작

작업	macOS	Windows
컴포넌트 만들기	Option + Command + K	Ctrl + Alt + K
인스턴스 분리하기	Option + Command + B	Ctrl + Alt + B
복제하기	Command + D	Ctrl + D
그룹 만들기	Command + G	Ctrl + G
프레임 만들기	Option + Command + G	Ctrl + Alt + G

버튼 컴포넌트의 이름은 Button / Primary처럼 지어 두면 좋습니다. 피그마는 /를 기준으로 컴포넌트를 그룹처럼 정리해서 보여 줍니다. 나중에 Button / Secondary, Button / Ghost, Button / Icon처럼 종류가 늘어나도 찾기 쉽습니다.

여기서 중요한 습관이 하나 있습니다. Main Component는 실제 화면 한가운데 방치하지 않는 것입니다. 처음에는 화면 위에 만든 버튼을 바로 컴포넌트로 만들 수 있습니다. 하지만 실무 파일에서는 Main Component를 따로 모아 두는 공간을 만드는 편이 좋습니다. 예를 들어 페이지 안에 Components 섹션을 만들고, 그 안에 버튼, 입력창, 카드 같은 원본을 정리합니다. 실제 화면에는 Main Component가 아니라 Instance를 배치합니다.

Instance를 화면에 배치하고 수정해 보기

컴포넌트를 만든 뒤에는 그 컴포넌트의 Instance를 화면에 배치해 봐야 합니다. 가장 쉬운 방법은 Main Component를 복사해서 붙여 넣는 것입니다. 컴포넌트를 복사하면 보통 붙여 넣은 요소는 Instance로 사용됩니다. 또는 왼쪽 사이드바의 Assets 탭에서 컴포넌트를 찾아 화면으로 드래그할 수도 있습니다.

이제 로그인 화면에 버튼 Instance를 하나 배치해 보겠습니다. 버튼 문구를 로그인으로 바꿉니다. 회원가입 화면에는 같은 버튼을 배치하고 문구를 가입하기로 바꿉니다. 결제 화면에는 문구를 결제하기로 바꿉니다.

이렇게 Instance에서 텍스트를 바꾸는 것은 원본을 망가뜨리는 것이 아닙니다. 피그마는 이것을 Override로 기억합니다. 즉, 기본 구조는 Main Component를 따르되, 특정 Instance에서 문구만 다르게 쓰는 것입니다.

이제 Main Component로 돌아가 버튼의 모서리 값을 8px에서 12px로 바꿔 보겠습니다. 그러면 로그인, 가입하기, 결제하기 버튼 모두 모서리가 바뀝니다. 하지만 각 버튼의 문구는 그대로 유지됩니다. 이것이 컴포넌트의 핵심입니다. 공통 규칙은 원본에서 관리하고, 화면별 차이는 Instance에서 관리합니다.

Override는 매우 편리하지만, 너무 많이 사용하면 컴포넌트의 장점이 약해질 수 있습니다. 예를 들어 Instance마다 버튼 배경색을 제각각 바꾸고, 폰트도 바꾸고, 높이도 바꾸면 더 이상 같은 버튼이라고 보기 어렵습니다. 이럴 때는 Override로 버티기보다 새로운 컴포넌트 종류를 만들거나, 다음 장에서 배울 Variants로 상태와 종류를 체계화하는 편이 좋습니다.

실무 팁 박스 — Override를 안전하게 쓰는 기준
텍스트 문구, 대표 이미지, 아이콘 종류처럼 화면마다 달라지는 내용은 Override로 바꿔도 좋습니다.
버튼 높이, 좌우 여백, 텍스트 스타일, 기본 색상처럼 UI의 기준이 되는 값은 가능하면 Main Component에서 관리하세요.
Instance를 너무 많이 뜯어고치고 있다면, 그것은 "새 컴포넌트가 필요하다"는 신호일 수 있습니다.

Main Component 수정이 Instance에 반영되는 방식

컴포넌트가 강력한 이유는 연결 구조 때문입니다. 하지만 처음에는 어떤 수정이 반영되고 어떤 수정이 유지되는지 헷갈릴 수 있습니다.

Main Component에서 구조를 수정하면 Instance에도 반영됩니다. 버튼 안에 아이콘 레이어를 추가하면 Instance에도 아이콘이 나타납니다. 버튼의 Auto Layout 간격을 8px에서 10px로 바꾸면 Instance의 간격도 바뀝니다. 버튼 배경색을 바꾸면, 별도로 배경색을 Override하지 않은 Instance에는 새 색상이 적용됩니다.

반대로 Instance에서 이미 바꾼 값은 그대로 유지되는 경우가 많습니다. 버튼 Instance의 문구를 로그인으로 바꿨다면, Main Component의 기본 문구를 Button에서 확인으로 바꿔도 해당 Instance의 로그인 문구는 유지됩니다. 피그마가 "이 Instance에서는 텍스트가 따로 바뀌었구나"라고 기억하기 때문입니다.

이 원리를 알면 컴포넌트 수정이 두렵지 않습니다. 원본을 수정한다고 해서 모든 화면의 세부 문구가 갑자기 날아가지는 않습니다. 다만 Instance에서 너무 많은 시각 속성을 직접 바꾸면, Main Component의 업데이트가 기대한 대로 반영되지 않을 수 있습니다.

다음 표처럼 생각하면 쉽습니다.

여기서 실무자가 꼭 기억해야 할 문장이 있습니다. Instance는 자유롭게 바꾸는 복사본이 아니라, 원본의 규칙을 빌려 쓰는 화면 요소입니다. 이 관점을 갖고 작업하면 파일이 훨씬 안정적으로 유지됩니다.

입력창 컴포넌트 만들기

버튼 다음으로 자주 컴포넌트화하는 요소는 입력창입니다. 입력창은 로그인, 회원가입, 검색, 설정 화면에서 반복해서 등장합니다. 단순히 사각형과 텍스트를 복사해서 만들면 화면마다 높이와 여백이 조금씩 달라지기 쉽습니다.

입력창 컴포넌트를 만들 때는 먼저 구조를 나누어 생각합니다. 가장 기본적인 입력창은 라벨, 입력 영역, 도움말 또는 오류 메시지로 구성됩니다. 예를 들어 이메일 입력창이라면 위에는 이메일이라는 라벨이 있고, 가운데에는 example@email.com 같은 placeholder가 있으며, 아래에는 필요할 때 올바른 이메일 형식을 입력해 주세요 같은 메시지가 나타납니다.

이 구조는 Auto Layout과 잘 어울립니다. 전체 입력창 프레임은 세로 Auto Layout으로 만들고, 라벨과 입력 영역과 메시지를 위에서 아래로 쌓습니다. 입력 영역 내부에는 placeholder 텍스트와 오른쪽 아이콘을 넣을 수 있습니다. 검색창이라면 왼쪽에 돋보기 아이콘이 들어갈 수도 있습니다.

입력창을 컴포넌트로 만들 때는 이름을 Input / Text field 또는 Field / Text처럼 지정해 봅니다. 팀에서 이미 정해 둔 이름 규칙이 있다면 그 규칙을 따르는 것이 가장 좋습니다. 중요한 것은 나중에 Assets 탭에서 봤을 때 역할이 바로 이해되어야 한다는 점입니다.

입력창 Instance에서는 라벨, placeholder, 도움말 문구를 Override로 바꿔 사용할 수 있습니다. 이메일 입력창에서는 라벨을 이메일, placeholder를 이메일을 입력하세요로 바꾸고, 비밀번호 입력창에서는 라벨을 비밀번호, placeholder를 비밀번호를 입력하세요로 바꿉니다. 구조와 여백은 동일하게 유지되므로 화면 전체의 완성도가 안정적으로 올라갑니다.

입력창을 만들 때 주의할 점은 오류 상태, 비활성 상태, 포커스 상태처럼 '상태'가 자주 필요하다는 것입니다. 이 장에서는 기본 컴포넌트와 Instance 구조를 먼저 익히고, 다음 장에서 Variants를 사용해 Default, Focus, Error, Disabled 같은 상태를 더 체계적으로 설계해 보겠습니다.

카드 컴포넌트 만들기

카드는 실무 화면에서 매우 자주 등장합니다. 상품 카드, 콘텐츠 카드, 예약 카드, 알림 카드, 대시보드 카드처럼 이름은 달라도 기본 원리는 비슷합니다. 카드에는 보통 이미지, 제목, 설명, 가격이나 상태 정보, 버튼 또는 아이콘이 들어갑니다.

카드를 컴포넌트로 만들 때 가장 먼저 해야 할 일은 '카드의 고정 요소'와 '바뀌는 요소'를 구분하는 것입니다. 카드의 배경색, 모서리, 그림자, 내부 여백은 공통 규칙에 가깝습니다. 반면 이미지, 제목, 설명, 가격, 태그 문구는 화면마다 달라질 가능성이 높습니다.

예를 들어 강의 카드 컴포넌트를 만든다고 해 보겠습니다. 카드 안에는 썸네일 이미지, 강의 제목, 짧은 설명, 가격, 찜하기 아이콘이 들어갑니다. 이때 카드 전체에는 세로 Auto Layout을 적용하고, 이미지 아래의 텍스트 영역도 Auto Layout으로 정리합니다. 제목이 두 줄이 되어도 카드 내부 간격이 망가지지 않도록 하기 위해서입니다.

카드 컴포넌트의 이름은 Card / Course처럼 지을 수 있습니다. 이후 화면에서는 이 카드의 Instance를 여러 개 배치하고, 각 카드의 이미지와 제목, 설명, 가격만 바꿉니다. 카드의 둥근 정도나 내부 여백을 수정해야 할 때는 Main Component에서 한 번만 수정합니다.

카드는 Override의 장점을 가장 잘 느낄 수 있는 요소입니다. 실제 서비스 화면에서는 카드가 10개, 20개씩 반복되는 경우가 많습니다. 이때 카드마다 내용을 다르게 바꾸면서도 카드의 규칙은 유지할 수 있다면, 디자인 파일은 훨씬 빠르게 확장됩니다.

작업 팁 박스 — 카드 컴포넌트가 깨지는 흔한 이유
카드 안의 텍스트 길이가 달라질 수 있는데 높이를 고정해 두면 긴 제목에서 레이아웃이 깨질 수 있습니다.
이미지, 텍스트 영역, 버튼 영역이 Auto Layout으로 정리되어 있지 않으면 카드마다 간격이 달라질 수 있습니다.
카드 Instance에서 여백을 직접 수정하기 시작하면 원본 수정의 장점이 줄어듭니다.

네비게이션 항목 컴포넌트 만들기

네비게이션 항목은 작지만 매우 중요한 컴포넌트입니다. 하단 탭 바, 사이드바 메뉴, 리스트 메뉴, 설정 항목에서 반복적으로 사용됩니다. 특히 기획자와 개발자가 함께 보는 파일에서는 네비게이션 구조가 화면 흐름을 이해하는 단서가 되기 때문에, 일관성 있는 컴포넌트로 관리하는 것이 좋습니다.

하단 탭 바의 항목을 예로 들어 보겠습니다. 하나의 탭 항목에는 아이콘과 라벨이 들어갑니다. 홈 탭은 집 아이콘과 홈, 검색 탭은 돋보기 아이콘과 검색, 마이페이지 탭은 사람 아이콘과 마이 같은 식입니다. 구조는 같고 아이콘과 텍스트만 달라집니다.

이럴 때 Nav item / Bottom tab 컴포넌트를 만들면 좋습니다. 내부는 세로 Auto Layout으로 구성하고, 아이콘과 라벨 사이 간격을 일정하게 둡니다. 탭 항목의 너비가 균등해야 한다면 부모 프레임인 하단 네비게이션 바에서 각 Instance의 리사이징 값을 조정합니다.

네비게이션 항목에서는 선택 상태도 중요합니다. 현재 선택된 탭은 색상이 강조되고, 선택되지 않은 탭은 회색으로 보일 수 있습니다. 이 상태 설계는 다음 장의 Variants에서 더 자세히 다루겠지만, 지금은 우선 같은 구조를 컴포넌트로 만들고 여러 화면에서 재사용하는 감각을 익히는 데 집중하면 됩니다.

작은 요소일수록 "이 정도는 그냥 복사하지 뭐"라고 생각하기 쉽습니다. 하지만 작은 요소가 많이 반복될수록 컴포넌트의 효과는 커집니다. 탭 아이콘 크기 하나, 라벨 위치 하나가 화면마다 달라지면 사용자에게는 묘한 어색함으로 느껴집니다. 컴포넌트는 그런 어색함을 미리 막아 주는 안전장치입니다.

Component Properties로 Instance를 더 쉽게 다루기

컴포넌트를 처음 만들면 Instance에서 레이어를 직접 선택해 텍스트를 바꾸거나 아이콘을 숨기는 방식으로 작업하게 됩니다. 하지만 컴포넌트가 복잡해질수록 내부 레이어를 매번 찾아 들어가는 일이 번거로워집니다. 이때 사용하는 기능이 Component Properties입니다.

Component Properties는 Instance를 사용할 때 자주 바꾸는 값을 오른쪽 패널에서 쉽게 조정할 수 있게 해 주는 기능입니다. 쉽게 말해 컴포넌트에 조작 버튼을 달아 두는 것입니다. 버튼 컴포넌트를 예로 들면, Instance를 선택했을 때 오른쪽 패널에서 버튼 문구를 바꾸고, 아이콘 표시 여부를 켜고 끄고, 아이콘 종류를 바꿀 수 있게 만드는 방식입니다.

대표적인 Component Properties는 다음과 같습니다.

여기서 Variant property는 다음 장에서 본격적으로 다룰 내용입니다. 이번 장에서는 Text, Boolean, Instance swap을 중심으로 생각해도 충분합니다.

버튼 컴포넌트에 Component Properties를 적용해 보겠습니다. 버튼 안의 텍스트 레이어에 Text property를 연결하면, Instance를 선택했을 때 오른쪽 패널에서 라벨 문구를 바로 바꿀 수 있습니다. 버튼 안에 아이콘 레이어가 있다면 Boolean property를 연결해 아이콘 표시 옵션을 만들 수 있습니다. 아이콘이 nested component, 즉 다른 컴포넌트로 들어가 있다면 Instance swap property를 사용해 아이콘 종류를 바꿀 수도 있습니다.

이렇게 해 두면 버튼 Instance를 사용하는 사람이 내부 레이어를 열어 보지 않아도 됩니다. 오른쪽 패널에서 Label, Show icon, Icon 같은 옵션만 조정하면 됩니다. 컴포넌트를 만든 사람은 구조를 보호할 수 있고, 사용하는 사람은 빠르게 화면을 만들 수 있습니다.

실무 팁 박스 — Component Properties 이름 짓기
속성 이름은 짧고 명확하게 짓는 것이 좋습니다. Label, Show icon, Icon, Helper text처럼 무엇을 바꾸는지 바로 알 수 있어야 합니다.
팀원이 함께 쓰는 파일이라면 한국어와 영어를 섞기보다 하나의 기준을 정하세요. 예를 들어 모든 속성은 영어, 화면 문구는 한국어로 관리할 수 있습니다.
Boolean property는 질문처럼 읽히게 만들면 편합니다. Show icon, Show helper, Show badge처럼 켜고 끄는 의미가 분명해집니다.

컴포넌트 이름과 보관 위치 정리하기

컴포넌트가 5개일 때는 이름이 조금 어설퍼도 큰 문제가 없습니다. 하지만 컴포넌트가 50개, 100개로 늘어나면 이름 규칙이 곧 파일의 질서가 됩니다. 이름이 엉켜 있으면 Assets 탭에서 원하는 컴포넌트를 찾는 데 시간이 걸리고, 팀원마다 비슷한 컴포넌트를 새로 만드는 일이 생깁니다.

가장 단순하고 실용적인 이름 규칙은 분류 / 이름 / 상태 또는 종류 형식입니다. 예를 들어 버튼은 Button / Primary, Button / Secondary, 입력창은 Input / Text, Input / Search, 카드는 Card / Product, Card / Article처럼 정리할 수 있습니다.

컴포넌트를 보관할 때는 실제 화면과 원본 컴포넌트를 섞어 두지 않는 것이 좋습니다. 페이지 안에 Components 섹션을 만들거나, 파일 구조가 커졌다면 아예 Components 페이지를 따로 만들 수 있습니다. 이곳에는 Main Component만 모아 두고, 실제 화면 페이지에서는 Instance만 사용합니다.

컴포넌트 정리에서 중요한 기준은 '나중에 찾기 쉬운가'입니다. 오늘 만든 사람만 이해할 수 있는 구조는 좋은 구조가 아닙니다. 한 달 뒤의 나, 새로 들어온 팀원, 개발자, 기획자가 봐도 "아, 이건 버튼 원본이구나"라고 이해할 수 있어야 합니다.

관리 팁 박스 — 컴포넌트 파일을 덜 어지럽히는 습관
Main Component는 실제 화면 밖이나 별도 섹션에 모아 둡니다.
이름에는 역할이 드러나게 씁니다. Component 1, Frame 27 같은 이름은 피하세요.
비슷한 컴포넌트를 새로 만들기 전에 Assets 탭에서 이미 있는지 먼저 검색합니다.

Main Component 찾기와 Instance 분리하기

실무 파일을 열어 보면 어떤 요소가 Instance인지, 원본이 어디에 있는지 찾기 어려울 때가 있습니다. 특히 다른 사람이 만든 파일에서는 Main Component가 다른 페이지에 있거나, 화면 밖에 정리되어 있을 수 있습니다.

Instance를 선택하면 오른쪽 패널에서 해당 컴포넌트 정보를 확인할 수 있습니다. 여기서 Main Component로 이동하는 옵션을 사용할 수 있습니다. 또는 Instance를 우클릭한 뒤 Main Component 관련 메뉴에서 원본으로 이동할 수 있습니다. 정확한 UI 명칭은 피그마 업데이트에 따라 조금씩 달라질 수 있지만, 핵심은 같습니다. Instance를 선택하고, 연결된 Main Component로 이동한다는 흐름입니다.

Main Component를 찾는 기능은 수정 전에 특히 중요합니다. 화면에 있는 Instance를 직접 고쳐도 당장 눈앞의 화면은 바뀝니다. 하지만 그것은 해당 화면에만 적용되는 Override일 가능성이 큽니다. 여러 화면에 공통으로 반영해야 하는 수정이라면 반드시 Main Component를 찾아가서 수정해야 합니다.

반대로 Instance를 더 이상 원본과 연결하고 싶지 않을 때는 Detach instance, 즉 인스턴스 분리를 사용할 수 있습니다. 분리한 Instance는 일반 프레임처럼 바뀌며, Main Component의 업데이트를 더 이상 따라가지 않습니다.

하지만 인스턴스 분리는 신중하게 사용해야 합니다. 분리하는 순간 컴포넌트 관리의 장점이 사라집니다. 잠깐 실험하거나, 원본과 완전히 다른 요소로 바꿀 때는 사용할 수 있지만, 실무 화면에서 습관적으로 분리하는 것은 좋지 않습니다.

주의 박스 — Detach는 마지막 선택지에 가깝습니다
Instance를 분리하면 원본 수정이 더 이상 반영되지 않습니다.
단순히 문구나 아이콘만 바꾸려는 목적이라면 Override나 Component Properties를 사용하세요.
계속 분리하게 된다면 원본 컴포넌트가 실제 사용 상황을 충분히 담지 못하고 있다는 신호일 수 있습니다.

컴포넌트를 만들 때 자주 하는 실수

컴포넌트는 강력하지만, 처음부터 완벽하게 만들기는 어렵습니다. 오히려 실수하면서 구조를 다듬는 과정이 필요합니다. 다만 자주 반복되는 실수는 미리 알고 피하는 것이 좋습니다.

첫 번째 실수는 Auto Layout 없이 컴포넌트부터 만드는 것입니다. 버튼이나 카드처럼 크기가 내용에 따라 바뀌는 요소는 Auto Layout이 없으면 Instance에서 문구를 바꿨을 때 쉽게 깨집니다. 컴포넌트는 원본을 저장하는 기능이고, Auto Layout은 내부의 반응 규칙을 만드는 기능입니다. 둘은 함께 사용할 때 가장 강력합니다.

두 번째 실수는 Main Component를 실제 화면에서 직접 사용하는 것입니다. Main Component가 로그인 화면 안에 들어가 있으면, 나중에 화면을 정리하다가 원본을 실수로 삭제하거나 이동할 수 있습니다. 원본은 원본답게 따로 보관하고, 화면에는 Instance를 쓰는 습관이 안전합니다.

세 번째 실수는 비슷한 컴포넌트를 계속 새로 만드는 것입니다. Button Primary, Primary Button, button-main, CTA button이 모두 같은 역할이라면 팀원은 무엇을 써야 할지 헷갈립니다. 새로 만들기 전에 이미 있는 컴포넌트를 찾고, 없다면 기존 이름 규칙에 맞춰 추가해야 합니다.

네 번째 실수는 Override로 모든 차이를 해결하려는 것입니다. Instance마다 색상과 크기를 바꾸다 보면 컴포넌트의 기준이 흐려집니다. 화면별 차이가 반복적으로 필요하다면, 그것은 개별 Override가 아니라 컴포넌트의 옵션이나 Variant로 설계해야 할 가능성이 높습니다.

작은 디자인 시스템의 시작

컴포넌트를 배우는 순간부터 피그마 파일은 단순한 그림판이 아니라 작은 시스템이 됩니다. 버튼 원본이 있고, 입력창 원본이 있고, 카드 원본이 있습니다. 화면은 그 원본들을 조립해 만들어집니다. 마치 레고 블록처럼 말입니다.

이 구조는 디자이너에게만 좋은 것이 아닙니다. 기획자는 화면마다 같은 요소가 같은 의미로 쓰이는지 확인하기 쉬워집니다. 개발자는 반복되는 UI를 컴포넌트 단위로 이해할 수 있습니다. 팀원은 새로운 화면을 만들 때 기존 기준을 빠르게 재사용할 수 있습니다.

특히 개발자라면 피그마의 Component를 프론트엔드 컴포넌트와 비슷한 개념으로 이해할 수 있습니다. Button 컴포넌트 하나를 만들고 label, icon, disabled 같은 속성을 바꿔 여러 곳에서 쓰는 방식은 실제 개발의 컴포넌트 사고와 닮아 있습니다. 물론 피그마와 코드가 완전히 같지는 않지만, 설계 관점은 상당히 비슷합니다.

기획자라면 컴포넌트를 '반복되는 화면 요소의 표준 양식'으로 이해하면 됩니다. 매번 새로 그리지 않고, 이미 합의된 요소를 꺼내 쓰는 것입니다. 덕분에 화면 설계 속도는 빨라지고, 리뷰할 때도 "이 버튼은 기존 Primary 버튼을 쓴 것인가요?"처럼 명확하게 이야기할 수 있습니다.

실무 흐름으로 다시 정리하기

컴포넌트를 실무에서 사용할 때의 흐름은 생각보다 단순합니다. 먼저 반복될 가능성이 높은 UI를 찾습니다. 그다음 Auto Layout으로 내부 구조를 안정적으로 만듭니다. 컴포넌트로 변환하고, 이름을 정리합니다. 실제 화면에는 Instance를 배치하고, 문구나 이미지처럼 화면마다 달라지는 내용만 Override합니다. 공통 기준을 바꿔야 할 때는 Main Component로 돌아가 수정합니다.

이 흐름이 몸에 익으면 파일을 보는 눈이 달라집니다. 예전에는 화면을 하나씩 완성하는 데 집중했다면, 이제는 "이 요소는 원본으로 만들 수 있을까?", "이 차이는 Override로 충분할까?", "이 상태는 Variant로 나눠야 할까?"를 생각하게 됩니다.

컴포넌트는 처음에는 조금 느리게 느껴질 수 있습니다. 원본을 만들고, 이름을 짓고, 정리하는 과정이 필요하기 때문입니다. 하지만 화면이 늘어날수록 그 차이는 크게 벌어집니다. 복사해서 만든 파일은 화면이 늘어날수록 무거워지고, 컴포넌트로 만든 파일은 화면이 늘어날수록 더 힘을 발휘합니다.

이제 우리는 반복 UI를 재사용하는 기본기를 갖추었습니다. 다음 장에서는 여기서 한 단계 더 나아가, 하나의 컴포넌트 안에서 여러 상태와 종류를 체계적으로 관리하는 Variants를 다룹니다. 버튼의 Default, Hover, Pressed, Disabled 상태를 따로따로 흩어 두지 않고 하나의 묶음으로 관리하는 방법을 배우게 됩니다.

핵심 요약

• Component는 반복되는 UI의 원본이고, Instance는 그 원본을 화면에서 사용하는 연결된 복제본입니다.

• Main Component를 수정하면 연결된 Instance에 공통 변경 사항이 반영됩니다.

• Instance에서는 텍스트, 이미지, 아이콘처럼 화면마다 달라지는 값을 Override로 바꿀 수 있습니다.

• 버튼, 입력창, 카드, 네비게이션 항목은 실무에서 가장 먼저 컴포넌트화하기 좋은 요소입니다.

• Component Properties를 사용하면 Instance의 텍스트, 아이콘 표시 여부, 아이콘 교체 등을 오른쪽 패널에서 쉽게 조정할 수 있습니다.

• Main Component는 실제 화면과 분리해 Components 섹션이나 페이지에 정리하는 것이 안전합니다.

• Instance를 분리하면 원본과의 연결이 끊기므로, 꼭 필요한 경우에만 사용해야 합니다.

실습 과제

이번 실습에서는 이전 장에서 만든 로그인 화면과 추가 화면을 기준으로 버튼 컴포넌트와 카드 컴포넌트를 만들어 재사용해 봅니다. 목표는 "복사해서 고치는 방식"에서 "원본을 만들고 Instance로 사용하는 방식"으로 작업 습관을 바꾸는 것입니다.

과제 1. Primary 버튼 컴포넌트 만들기

먼저 버튼 프레임을 하나 만듭니다. 높이는 48px, 좌우 패딩은 20px, 모서리는 12px 정도로 설정합니다. 버튼 안에는 텍스트 레이어를 넣고 Button이라고 입력합니다. 버튼 프레임에는 Auto Layout을 적용하고, 텍스트가 가운데에 오도록 정렬합니다.

그다음 버튼 프레임을 선택하고 컴포넌트로 만듭니다. 이름은 Button / Primary로 지정합니다. Main Component는 실제 로그인 화면 안에 두지 말고 Components 섹션을 만들어 그 안에 정리합니다.

이제 로그인 화면, 회원가입 화면, 완료 화면에 각각 버튼 Instance를 배치합니다. 각 Instance의 문구를 로그인, 가입하기, 시작하기로 바꿉니다. 마지막으로 Main Component의 배경색이나 모서리 값을 변경해 보고, 세 화면의 Instance에 변경 사항이 반영되는지 확인합니다.

과제 2. 버튼에 Component Properties 추가하기

Button / Primary 컴포넌트 안에 왼쪽 아이콘을 추가합니다. 아이콘과 텍스트 사이 간격은 8px로 설정합니다. 그런 다음 아이콘 레이어에 Boolean property를 연결해 Instance에서 아이콘을 보이거나 숨길 수 있게 만들어 봅니다.

가능하다면 텍스트 레이어에는 Text property를 연결합니다. Instance를 선택했을 때 오른쪽 패널에서 버튼 문구를 바로 바꿀 수 있는지 확인합니다. 버튼을 사용하는 사람이 내부 레이어를 열지 않아도 문구와 아이콘 표시 여부를 조정할 수 있다면 성공입니다.

과제 3. 카드 컴포넌트 만들기

간단한 콘텐츠 카드 하나를 만듭니다. 카드에는 썸네일 영역, 제목, 설명, 하단 정보 또는 버튼을 넣습니다. 카드 전체에는 세로 Auto Layout을 적용하고, 내부 여백과 간격을 일정하게 정리합니다.

카드 프레임을 컴포넌트로 만든 뒤 이름을 Card / Content로 지정합니다. Main Component는 Components 섹션에 보관합니다. 이후 홈 화면에 카드 Instance를 3개 배치하고, 각 카드의 제목과 설명을 다르게 바꿔 봅니다.

마지막으로 Main Component에서 카드의 모서리 값, 그림자, 내부 여백 중 하나를 수정합니다. 홈 화면에 배치한 3개의 카드 Instance가 함께 업데이트되는지 확인합니다.

과제 4. 컴포넌트 점검 체크리스트

실습이 끝나면 다음 기준으로 파일을 점검해 보세요.

• Main Component와 Instance가 구분되어 있는가?

• Main Component가 실제 화면이 아니라 별도 섹션에 정리되어 있는가?

• 버튼과 카드의 내부 구조에 Auto Layout이 적용되어 있는가?

• Instance에서 바꾼 내용이 문구, 이미지, 아이콘처럼 화면별 차이에 해당하는가?

• 공통으로 바꿔야 할 값은 Main Component에서 수정하고 있는가?

이 체크리스트를 통과했다면, 이제 여러분의 피그마 파일은 단순히 화면을 그린 파일이 아니라 재사용 가능한 UI 구조를 가진 파일에 가까워졌습니다. 다음 장에서는 이 컴포넌트를 더 똑똑하게 묶어 상태와 종류를 관리하는 방법을 배워 보겠습니다.