복붙 지옥 탈출: Figma 컴포넌트 라이브러리 ‘정리 규칙’ 7가지(실무 템플릿)

-
Figma 컴포넌트 라이브러리 ‘정리 규칙’ 7가지를 제공합니다.

복붙 지옥 탈출: Figma 컴포넌트 라이브러리 ‘정리 규칙’ 7가지(실무 템플릿)

서론

안녕하세요~
Figma로 버튼, 탭, 입력 폼까지 열심히 만들었는데 어느 날 이런 순간이 오더라고요.
“그때 그 버튼… 어디 있더라?”
화면은 많아지고, 복사본은 더 많아지고, 결국 수정 요청이 오면 찾는 데 시간이 더 걸립니다.

저도 초반엔 화면 파일마다 컴포넌트를 만들고 그때그때 가져다 썼는데, 프로젝트가 커지니까 같은 UI가 조금씩 다른 버전으로 퍼지기 시작했습니다. 그때부터 깨달았어요. 만드는 실력보다 중요한 건 정리와 공유라는 걸요.

그래서 이번 글에서는 Figma 라이브러리를 기준으로 “복붙 지옥”을 끝내는 정리 규칙 7가지를 실무 템플릿 형태로 정리합니다. (오늘 글은 예쁜 말보다, 바로 써먹는 규칙 위주로 갑니다 🧾)

이 글을 읽고 나면: UI 자산(버튼/칩/탭/입력폼)을 한 곳에 모아 공유해도 망가지지 않는 구조로 운영할 수 있습니다.
글 마지막에 Figma 라이브러리 체크리스트가 있습니다.
복붙 지옥 탈출

본론

1) Figma 라이브러리란? (컴포넌트와 뭐가 다를까)

컴포넌트는 “원본과 인스턴스”로 재사용하는 방식이고, Figma 라이브러리는 그 컴포넌트를 팀이 공유해서 쓰는 ‘공용 자산’으로 만드는 단계입니다.

  • 컴포넌트: 내 파일 안에서 재사용
  • Figma 라이브러리: 다른 파일/팀원이 가져다 쓰도록 공유

즉, “내가 편해지는 단계”에서 “팀이 덜 망가지는 단계”로 넘어가는 거예요.

🔎 효율적인 컴포넌트 관리 보러가기

규칙 1) “원본 파일”과 “사용 파일”을 분리한다

가장 중요한 규칙입니다. 원본과 사용처를 섞으면 빠르게 무너집니다.

  • Library 파일: 버튼/칩/탭/입력폼 원본만 존재
  • Screen 파일: 실제 화면(시안)은 인스턴스로 조립
한 줄 공식: 원본은 한 곳에 모으고, 화면은 인스턴스로만 만든다.

규칙 2) 네이밍은 슬래시(/)로 ‘검색 가능’하게 만든다

Figma 라이브러리는 “만드는 것”보다 “찾는 것”이 더 중요합니다. 그래서 네이밍은 취향이 아니라 규칙입니다.

추천 네이밍 템플릿

  • Button/Primary, Button/Secondary
  • Chip/Filter, Chip/Tag
  • Tab/Underline, Tab/Pill
  • TextField/Base, TextField/Search
팁: “한글/영문”은 무엇이든 괜찮지만, 섞지 말고 통일하세요. 검색 속도가 체감으로 달라집니다.

규칙 3) Variants 속성은 공통 규칙(Type/Size/State)로 통일한다

버튼은 Type/Size/State가 잘 맞고, 칩/탭/입력폼도 기본 축을 통일해두면 Figma 라이브러리 운영이 편해집니다.

  • Type: 역할/스타일(Primary, Secondary / Underline, Pill 등)
  • Size: 규격(S, M, L)
  • State: 상황(Default, Disabled, Selected, Active, Error 등)

단, 속성은 2~3개가 한계입니다. 속성이 늘면 조합이 폭발합니다.

규칙 4) 컴포넌트 페이지는 ‘전시장’처럼 구역화한다

라이브러리 파일은 “창고”가 아니라 “전시장”이 되면 팀이 더 잘 씁니다. 찾기 쉬워지고, 사용 기준도 공유됩니다.

  • 섹션 예시: Buttons / Chips / Tabs / Forms / Icons
  • 각 섹션에: 사용 예시 1~2개(짧게) + 주의사항(한 줄)
실무 팁: “이 버튼은 CTA에만 사용” 같은 규칙이 같이 적혀 있으면 디자인 시스템처럼 작동합니다.

규칙 5) 바뀌는 값(토큰/스타일)은 중앙에서 관리한다

UI에서 자주 바뀌는 건 보통 색상/텍스트 스타일/간격입니다. 이걸 컴포넌트 내부에서 제각각 수정하면 “업데이트 지옥”이 열립니다.

  • 색상: 스타일(Styles)로 통일
  • 텍스트: 텍스트 스타일로 통일
  • 간격/패딩: Auto Layout 규칙으로 통일

이렇게 해두면 Figma 라이브러리 업데이트가 “한 군데 수정”으로 끝날 확률이 올라갑니다.

규칙 6) 공유 전 체크리스트로 ‘망한 배포’를 막는다

라이브러리는 공유하는 순간부터 “다른 사람이 쓰는 제품”이 됩니다. 그래서 배포 전 점검이 필요합니다.

  • 원본 컴포넌트가 화면 파일에 섞여 있지 않은가?
  • 네이밍이 통일되어 있는가?
  • Variants 속성명이 제각각이지 않은가?
  • 텍스트 오버라이드/이미지 슬롯이 필요한 곳에 준비되어 있는가?
  • 대표 사용 예시가 1개 이상 있는가?

규칙 7) 업데이트 루틴을 정해서 “버전 지옥”을 막는다

공유 이후 가장 흔한 문제는 “누가 어떤 버전을 쓰고 있는지”가 헷갈리는 것입니다. 그래서 업데이트 루틴을 간단하게라도 정해두는 게 좋습니다.

  1. 변경 요청을 모으는 곳(간단한 메모라도 OK)을 만든다
  2. 일정 단위로 반영한다(예: 주 1회)
  3. 변경 내용을 짧게 기록한다(예: 버튼 패딩 M: 12→14)
핵심: “바뀌었는지 몰라서 다시 만드는 상황”만 막아도 효과가 큽니다.

실무 템플릿(네이밍/구조/체크리스트)

1) 폴더/페이지 구조 템플릿

  • 00_Overview (사용 가이드/규칙)
  • 01_Buttons
  • 02_Chips
  • 03_Tabs
  • 04_Forms
  • 99_Archive (폐기/대체됨)

2) 네이밍 템플릿(슬래시 규칙)

  • Button/Primary, Button/Secondary
  • Tab/Underline, Tab/Pill
  • TextField/Base, TextField/Search

3) 배포 전 체크리스트(복사해서 사용)

  • [ ] 원본과 화면 파일이 분리되어 있다
  • [ ] 네이밍이 통일되어 검색이 된다
  • [ ] Variants 속성(Type/Size/State)이 통일되어 있다
  • [ ] 대표 예시가 있고, 사용 기준이 한 줄이라도 있다
  • [ ] 변경 이력(간단 메모)을 남길 자리(Overview)가 있다

위 템플릿만 적용해도 Figma 라이브러리 운영 난이도가 확 내려갑니다.

결론

컴포넌트를 잘 만드는 것만으로는 “복붙 지옥”이 끝나지 않습니다. 진짜 탈출은 Figma 라이브러리로 정리하고, 공유하고, 업데이트까지 굴릴 때 시작됩니다.

오늘 소개한 7가지 규칙은 거창한 디자인 시스템이 아니라, “내일 수정 요청이 와도 덜 흔들리는 실무 구조”에 초점을 맞췄습니다. 버튼/탭/입력폼이 많아질수록 이 규칙의 효과는 더 커집니다.

FAQ

Q Figma 라이브러리를 꼭 만들어야 하나요?

A 혼자 작업하는 작은 파일이라면 필수는 아닙니다. 하지만 화면이 늘어나거나, 반복 UI가 많아지거나, 공유가 시작되는 순간부터는 Figma 라이브러리가 “수정 비용”을 크게 줄여줍니다.

Q 네이밍을 통일하는 게 정말 그렇게 중요한가요?

A 네. 공유된 라이브러리는 “다른 사람이 찾는 속도”가 품질입니다. 슬래시(/) 규칙으로만 통일해도 검색이 빨라지고, 사용률이 올라갑니다.

Q Variants 속성은 모든 컴포넌트에 Type/Size/State를 써야 하나요?

A 꼭 그렇진 않습니다. 다만 가능한 한 공통 축을 맞추면 학습 비용이 줄어듭니다. 칩은 Selected, 탭은 Active처럼 필요한 상태만 State에 추가하는 방식이 실무적으로 깔끔합니다.

Q 업데이트가 생기면 기존 화면은 자동으로 다 바뀌나요?

A 인스턴스는 원본 변경의 영향을 받지만, 화면에서 오버라이드한 값은 예외가 될 수 있습니다. 그래서 배포 전 “오버라이드 최소화”와 “변경 이력 기록”이 중요합니다.

저장용 요약: Figma 컴포넌트 라이브러리 체크리스트

아래 체크리스트는 Figma 라이브러리 파일 첫 페이지에 그대로 복사해서 붙여두고 사용하는 용도입니다.

1️⃣ 파일 구조

  • [ ] 라이브러리 전용 파일과 화면(시안) 파일이 분리되어 있다
  • [ ] 라이브러리 파일에는 원본 컴포넌트만 있다
  • [ ] 화면 파일에는 인스턴스만 사용한다

2️⃣ 네이밍 규칙

  • [ ] 슬래시(/) 구조로 네이밍되어 있다 (예: Button/Primary)
  • [ ] 같은 UI에 다른 이름을 쓰지 않는다
  • [ ] 한글/영문 중 하나로 통일되어 있다

3️⃣ Variants 구조

  • [ ] Variants 속성은 2~3개 이하이다
  • [ ] Type / Size / State 역할이 섞이지 않았다
  • [ ] 반복되는 예외를 오버라이드로 처리하지 않았다

4️⃣ 레이아웃 안정성

  • [ ] 모든 컴포넌트에 Auto Layout이 적용되어 있다
  • [ ] 텍스트가 길어져도 레이아웃이 깨지지 않는다
  • [ ] Hug / Fill / Fixed 설정이 의도에 맞다

5️⃣ 스타일 관리

  • [ ] 색상은 Color Styles로 관리된다
  • [ ] 텍스트는 Text Styles를 사용한다
  • [ ] 컴포넌트 내부에 임의 값이 박혀 있지 않다

6️⃣ 사용 가이드

  • [ ] 컴포넌트가 카테고리별로 구역화되어 있다
  • [ ] 대표 사용 예시가 최소 1개 이상 있다
  • [ ] 사용 시 주의사항이 한 줄이라도 적혀 있다

7️⃣ 공유 & 업데이트

  • [ ] 공유 전 점검 체크를 완료했다
  • [ ] 변경 이력을 적는 공간이 있다
  • [ ] 예전 컴포넌트는 Archive로 이동했다

한 줄 요약
원본은 한 곳에, 규칙은 단순하게, 공유는 신중하게.
이 세 가지만 지켜도 Figma 라이브러리는 오래 갑니다.

📌 함께 보면 좋은 글
기획자용 피그마 텍스트 필드 베리언츠(Variants) 완벽 가이드
효율적인 컴포넌트 관리법
지금 바로 확인하기 →