[실전 UI 디자인] CH3: 컴포넌트 설계의 목적

 

3-1) 컴포넌트 설계의 목적

 

컴포넌트로 설계될 수 있는 것

• 버튼, 인풋 필드, 카드 처럼 독립적인 기능을 가진 디자인 요소
• 검색창, 탭바처럼 인터랙션을 포함한 복합적인 UI 구조
• 배너, 상품 리스트, 게시물 피드처럼 반복 가능한 실제 디자인 패턴
• ▶️ 우리가 다루는 모든 UI 요소는 컴포넌트고, 의도적으로 사용되어야 함

컴포넌트 설계에서 중요한 것

• 왜 이 구조를 컴포넌트화하는 것이 효율적인가 판단할 수 있는 사고력

 

 

좋은 컴포넌트의 기준

• 사용성과 활용성을 고려해서 설계하는 게 핵심
• 기준
  • 재사용성: 다양한 페이지와 맥락에서 같은 의미로 사용될 수 있어야 함 (e.g. 버튼)
  • 유연성: 상황에 따라 상태나 데이터, 구조가 바뀌어도 무너지지 않아야 함 (e.g. 카드 UI에 이미지가 없는 경우에도 레이아웃이 깨지지 않도록)
  • 확장성: 다양한 조합으로 만들어져도 관리가 쉬운 구조여야 함 (e.g. 태그 컴포넌트를 강조나 속성 표시 등 다양한 상황에서 사용하더라도 동일한 컴포넌트에서 관리할 수 있어야 함)
    

    

    출처: 실전 UI 디자인(3-1)

  • 일관성: 제품 전체에서 동일한 기능은 동일한 방식으로 동작하고 보여야 함 (e.g. 항상 같은 높이/라운드/컬러로 유지)
  • 협업 친화성: 역할과 속성이 명확해야 함 (e.g. 네이밍, 상태명, 인터랙션 등이 잘 정리되어 있어야 협업에 용이)
• 기준이 필요한 이유
  • 디자인 변경이 생기면 컴포넌트를 이중으로 관리해야 하는 부담이 생김

---

3-2) 실무 컴포넌트 네이밍 컨벤션

 

컴포넌트 네이밍

• 검색, 재사용, 협업, 유지보수를 위해선 반드시 일관된 네이밍 전략 필요
• 컴포넌트 네이밍 컨벤션: 컴포넌트 이름 짓는 규칙

 

컴포넌트 네이밍의 핵심

• 단순히 이름을 짓는 게 아니라, 전체 컴포넌트들이 어떤 구조로 서로 연결되어 있는 지 알 수 있음
• 네이밍 ▶️ 구조적 사고의 표현
  • 구성 요소와 속성의 구조를 설명하는 도구
  • 이름만 봐도 어떤 속성을 가진 컴포넌트인지 추론 가능해야 함
• 컴포넌트 네이밍 ▶️ 협업과 유지보수 난이도를 낮춤

 

네이밍 구성 예시

• Component Type: 어떤 UI 요소인지 카테고리를 나타냄
• Style: 위계나 스타일을 알려줌
• State: 인터랙션이 있거나 상태가 바뀌는 경우를 나타냄
• Size: 크기가 다른 경우를 나타냄

출처: 실전 UI 디자인(3-2)

 

• 위를 모두 조합하면 아래와 같은 컴포넌트 이름은 이렇게 지을 수 있음
  
  • Button / Primary / Default / Medium

    

    출처: 실전 UI 디자인(3-2)

컴포넌트 네이밍 실전 팁

• 줄임말과 개인 기호는 지양하기
  • btn_primary_big ▶️ Button / Primary / Large
• 예외 상황도 구조를 유지한 채 명확히 처리하기
  • 한 번만 사용하는 버튼이라해도 Button / Primary / Large ▶️ Button / Primary / Large / Hero 
• 검색에 강한 구조로 예측 가능한 순서 유지하기
  

  

  출처: 실전 UI 디자인(3-2)

• 줄여도 되는 부분과 안되는 부분 구분하기
  • 사이즈 같은 경우는 줄이는 경우 존재
    

    

    출처: 실전 UI 디자인(3-2)

• 만드는 서비스 규모에 따라 네이밍 전략을 유연하게 사용하기
  • 3명 이상 함께 작업한다면 반드시 네이밍 컨벤션 필요함

---

3-3) 실무 배리언츠 & 프로퍼티 전략

 

실무 Variants & Properties 활용 전략

• Variants와 Properties는 피그마에서 컴포넌트를 구성할 수 있는 가장 강력한 도구지만 실무에서 기능적으로 만들 수 있다는 것과 실제로 유지보수 가능한 구조인지는 전혀 다른 문제

 

실무에서 자주 마주치는 상황

• 조합 폭발: 배리언츠 지옥에 빠질 때
  • 컴포넌트 규모가 점점 커지다보면 버튼 하나에 배리언츠 수가 몇십 개를 훌쩍 넘는 경우가 있음
  • 하지만 대부분의 경우 실제 제품 디자인에서는 10개 이내로 사용함
  • 이런 상황에서는?
    • 정말 모든 조합을 만들어야 할까?
    • 어떤 조합은 버려도 되는가?
    • 구조를 나눠서 관리해야 할까?
  • 실무에서 해결하는 일반적인 방법
    • 유지보수 하기 힘든 수준의 양일 경우 ▶️ 쪼개서 사용하는 것도 고려
    • 사용 빈도가 낮은 조합은 과감히 제외하기
    • 아이콘이나 테두리 여부 등은 Boolean 프로퍼티로 단순화하기
    • 공통 속성으로 묶이는 경우에만 배리언츠로 유지하기
    • 💡 자주 쓰이는 조합만 배리언츠로 만들고, 나머지는 프로퍼티로 처리하는 게 훨씬 효율적

 

• 배리언츠와 프로퍼티 구조의 경계 판단
  • 컴포넌트를 만들 때 배리언츠와 프로퍼티 중 어떤 걸로 해야 하는지 고민될 때가 있음
    • e.g. 아이콘 사용 여부, 닫기 버튼 여부, 동일한 컴포넌트의 색상 변경 등 스타일 교체
    • 어떤 속성은 단순 여부/스타일/교체 가능한 아이콘 
  • 판단 기준
    • 역할에 따라 어떤 방식이 가장 관리 효율적인지?
    • 협업 시 어떤 구조가 설명하기 좋은지?
  • 실무에서 해결하는 일반적인 방법
    • On/Off 여부만 존재 ▶️ Boolean
    • 복수 선택지(2개 이상) ▶️ Variant
    • 이미지나 컴포넌트 교체 ▶️ Instance Swap

 

트레이드 오프(Trade-off)

• 트레이드 오프란?
  • 어떤 것을 얻기 위해 다른 것을 포기하는 ‘상호 교환의 선택’
  • 디자인 시스템에서도 모든 조합을 완벽히 만들면 구조는 명확해지지만, 관리 비용은 급증
  • 반대로 단순하게 유지하면 누락이 생기거나 예외 처리가 복잡해짐
  • UI 디자이너는 어느 정도를 포기하고 어느 정도까지 챙길 것인지 판단할 수 있어야 함 

• 컴포넌트 트레이드오프를 판단할 때 고려할 것
  • 우리는 지금 MVP 단계인가?
  • 이 컴포넌트를 3명이 쓸까, 30명이 쓸까?
  • 앞으로 3개월 뒤에도 이 구조가 유효할까?
  • 이 속성이 사용자 경험에 큰 영향을 주는가?

---

3-4) 디자인 시스템과 컴포넌트 고도화

 

디자인 시스템과 컴포넌트 고도화

• 디자인 시스템은 결국 기준과 규칙이 모여서 하나의 매뉴얼을 만든다는 뜻

 

디자인 시스템 운용 전략

• 모든 컴포넌트를 구조화할 필요는 없음
  • 재사용이 불가능한 일회성 화면이나 이벤트성 배너는 굳이 컴포넌트로 만들지 않아도 됨
  • 재사용 가능성이 높은 요소부터 차근차근 구조화하는 것이 핵심
  • 어떻게 판단하는지?
    • 3번 이상 반복되는 요소인지
    • 콘텐츠가 바뀌어도 컴포넌트의 구조가 유지되는지
• 배리언트로 굳이 만들지 않아도 기본적인 UI는 갖출 수 있음
  • 처음부터 완성된 시스템을 가져가려고 하면 안됨 ▶️ 제품 방향이나 사용자가 우리 서비스를 쓰는 이유 등 더 중요한 논의에 힘을 써야 함
  • 프레임에 적당한 이름을 붙이고, 한 곳에 잘 정돈해서 모아두는 것만으로도 충분한 구조가 가능함
• 의도와 맥락을 이름에 담기
  • 컴포넌트에 적당한 이름을 잘 붙이는 것만으로도 충분한 정보를 담을 수 있음
  • 배리언츠로 복잡하게 만들지 않아도 네이밍 구조만으로도 유사한 구조와 맥락을 파악할 수 있음
  • 작은 조직, 초기 서비스, 혹은 혼자 일하는 디자이너에게 중요한 것 ▶️ 정교한 디자인 시스템이 아니라, 의도가 정리된 최소 요소들

 

실무에서 마주치는 디자인 시스템 문제

• 컴포넌트가 제각각이다
  

  

  출처: 실전 UI 디자인(3-4)

  • 먼저 공통 구조 파악하고 동일하게 사용되는 요소 추출하기
  • 개별 차이는 프로퍼티나 배리언츠를 활용해서 분리하기
  • 나머지는 하나의 컴포넌트로 통합하기
• 어디까지 컴포넌트로 만들지
  • 한 번만 쓰이는 구조는 컴포넌트화하지 않기
  • 반복되는 횟수 기준을 정해 그 이상 자주 사용하면 컴포넌트를 고려하기
  • 개발자와 같이 협업해야 하는 UI를 먼저 컴포넌트화하기
  • 💡 컴포넌트화는 확실히 편리하긴 하지만, 그만큼 시간과 비용이 필요하고 속도를 늦춤
  • 개발자와 같이 협업해야 하는 UI를 먼저 컴포넌트화하기
• 정돈된 UI처럼 보이지 않는 이유
  

  

  출처: 실전 UI 디자인(3-4)

  
  
  • 버튼, 카드, 리스트, 태그 등 기능별로 컴포넌트의 스타일을 통일하기
  • 스타일이 바뀔 땐 일관성 있는 규칙을 기반으로 바꾸기
  • 동일한 UI 요소는 색상, 여백, 라운드, 텍스트 스타일까지 완전히 동일하게 맞춰 줘야 함

 

일관성 있는 UI를 위한 관리 전략

• 무조건 Auto Layout 을 쓰지 않아도 됨
  • 피그마에서는 시각적인 작업 위주로 사용함 ▶️ 개발 단계에서는 구조적으로 맞지 않는 경우가 있음
  • 정보 구조를 해친다면 오토레이아웃은 사용하지 않아도 괜찮음
  • 동일한 형태를 반복적으로 사용할 수 있다면 오토레이아웃을 고려해보기
• 색상, 텍스트 스타일은 3가지 정도로 시작하기
  • 사용자의 목적을 정확하게 잘 짚어냈는지를 검증하는 초기 단계에서는 최대한 사용자도, 만드는 사람도 쉽게 인식할 수 있도록 3가지 정도만 사용하는 것이 권장됨
  • 서체: 제목, 본문, 캡션 or 작은 본문 정도
  • 색상: 기본 흑백, 텍스트 및 레이아웃용 그레이, 포인트 컬러면 충분
• 컴포넌트 상태는 ‘의미’ 중심으로 구분하기
  • Disabled / Active / Focused 등 행동 상태나 속성 순서에 따라 분리하기
  • 스타일의 차이보다는 상태나 조건같은 속성을 기준으로 나누는 게 유지보수나 검색에 용이함

 

컴포넌트 관리 참고 사항

• 지금 내가 만든 이 컴포넌트는 3개월 뒤에도 사용 가능한 구조인지?
• 반복되는데 컴포넌트화하지 않은 요소가 있진 않는지?
• 구조를 보면 누가 봐도 어떤 기능인지 이해할 수 있는지?
• 이름만 봐도 역할을 유추할 수 있는지?