<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>고연정</title>
  <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@2BNf" />
  <author>
    <name>icoppico</name>
  </author>
  <subtitle>UI/UX 디자이너로 일하며 디자인 시스템과 사용자 경험을 기록합니다 ☺️</subtitle>
  <id>https://brunch.co.kr/@@2BNf</id>
  <updated>2016-11-18T10:09:24Z</updated>
  <entry>
    <title>아이콘 시스템 구조 - UI 컴포넌트 구조화하기</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@2BNf/5" />
    <id>https://brunch.co.kr/@@2BNf/5</id>
    <updated>2026-04-08T02:38:04Z</updated>
    <published>2026-04-01T22:22:50Z</published>
    <summary type="html">아이콘은 작은 요소지만, 제품의 완성도를 크게 좌우한다. 그럼에도 불구하고 많은 제품에서 아이콘은 의외로 쉽게 무너집니다. 크기가 조금씩 다르고 Stroke 굵기가 제각각이며 구조 처리 방식도 통일되어 있지 않습니다. 이 상태에서 아이콘을 컴포넌트화하면 문제가 더 명확해집니다.  같은 아이콘인데 상태에 따라 색이 다르게 보이고 투명도를 적용하면 의도하지 않&lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.kakaocdn.net%2Fbrunch%2Fservice%2Fuser%2F2BNf%2Fimage%2FZIcf2DxFdCA3Q29mDpR8iZ3mZzk.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>맑은 고딕을 버리고 Pretendard를 선택한 이유 - 익숙한 폰트가 불편해지는 순간</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@2BNf/4" />
    <id>https://brunch.co.kr/@@2BNf/4</id>
    <updated>2026-03-23T06:05:26Z</updated>
    <published>2026-03-23T03:00:16Z</published>
    <summary type="html">현재 우리 소프트웨어 UI는 오랫동안 맑은 고딕을 사용해왔다. 그리고 어느 순간 질문이 생겼다. UI를 리뉴얼하는데 폰트도 그대로 써도 괜찮을까? 디자인을 조금만 만져보면 바로 느껴진다. 맑은 고딕은 나쁜 폰트가 아니다. 오히려&amp;nbsp;굉장히 잘 만든 폰트다. 다만 문제는 시대다.  맑은 고딕은 처음부터 UI 폰트로서 매우 현실적인 목표를 가지고 설계됐다. 작은 &lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.kakaocdn.net%2Fbrunch%2Fservice%2Fuser%2F2BNf%2Fimage%2FXS4TYWpHLVtNRLmB-ldBslvlsww.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>텍스트 토큰 구조 정의 - Figma variables로 텍스트 토큰화하기</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@2BNf/3" />
    <id>https://brunch.co.kr/@@2BNf/3</id>
    <updated>2026-03-23T06:04:42Z</updated>
    <published>2026-03-19T22:08:41Z</published>
    <summary type="html">소프트웨어와 웹을 동시에 운영하다 보면 어느 순간 이런 일이 자연스럽게 발생합니다. 같은 역할의 텍스트인데도 제품마다 크기가 다르고 어떤 곳은 얇고, 어떤 곳은 두껍습니다. 처음에는 큰 문제가 아닌 것처럼 보입니다. 하지만 시간이 지날수록 점점 더 많은 비용을 만들어냅니다.  디자인 시스템을 수정할 때 어디까지 영향이 가는지 알기 어렵고 검수에 시간이 많이&lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.kakaocdn.net%2Fbrunch%2Fservice%2Fuser%2F2BNf%2Fimage%2F2Tdup_cBFqXVd5a9LIrhDw393lg.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>컬러 토큰 구조 정의 - Figma Variables로 컬러 토큰화하기</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@2BNf/2" />
    <id>https://brunch.co.kr/@@2BNf/2</id>
    <updated>2026-03-23T05:58:50Z</updated>
    <published>2026-03-13T08:51:13Z</published>
    <summary type="html">디자인 시스템을 정리할 때 가장 먼저 정리해야 하는 요소 중 하나가 컬러입니다. 컬러는 대부분의 UI 요소에 공통적으로 사용되기 때문에 기준이 명확하지 않으면 디자인과 개발 과정에서 작은 차이가 점점 누적되기 쉽습니다.  특히 디자인 파일과 실제 제품에서 컬러의 명칭이나 사용 목적이 서로 다르게 관리되는 경우, 수정 작업이 반복되거나 협업 과정에서 혼선이 &lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.kakaocdn.net%2Fbrunch%2Fservice%2Fuser%2F2BNf%2Fimage%2FdLjgEd-DV6cS-V3q87g2776yR5M.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>UI 요소 및 컴포넌트 구조 - Figma Variables로 UI 컴포넌트 구조화하기</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@2BNf/1" />
    <id>https://brunch.co.kr/@@2BNf/1</id>
    <updated>2026-03-23T05:56:15Z</updated>
    <published>2026-03-11T09:05:08Z</published>
    <summary type="html">여러 제품을 운영하다 보면 업데이트 시기가 서로 다르고, 디자이너가 생성한 Figma UI 요소 또한 제품마다 다른 방식으로 사용되는 경우가 많습니다. 특히 컬러, 버튼, 아이콘, 레이아웃과 같은 기본 UI 요소의 일관성이 부족해지면서 디자인, 개발, QA 과정에서 불필요한 검증과 수정 작업이 반복되기도 합니다.  이러한 문제를 줄이기 위해 여러 제품에서 &lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.kakaocdn.net%2Fbrunch%2Fservice%2Fuser%2F2BNf%2Fimage%2FHe3uHuez2CHLdiWcWXjAfYyjkQ0.png" width="500" /&gt;</summary>
  </entry>
</feed>
