디자이너가 자주 빠뜨리는 컴포넌트 상태들 — hover부터 skeleton까지 실무 체크리스트

이미지
  "디자인엔 없는데요?" — 개발자가 가장 많이 하는 말이에요. hover, disabled, loading, error, empty, skeleton… 실무에서 디자이너가 자주 빠뜨리는 컴포넌트 상태들, 빠졌을 때 개발에서 벌어지는 일, 그리고 다시는 놓치지 않는 체크리스트까지 한 번에 정리했어요!   디자이너 동료에게서 받은 컴포넌트 파일을 열었는데 버튼이 딱 하나예요. 기본(Default) 상태 하나. 개발자가 "hover는요? disabled는요? 로딩 중엔 어떻게 보여요?" 물어보면 "아 그건 알아서 해주세요~"가 돌아오는 그 상황. 😅 반대로 디자이너 입장에서도 억울해요. 솔직히 처음에 뭘 챙겨야 하는지 아무도 알려주지 않았거든요. 이 글은 디자이너를 탓하려는 게 아니에요. 실무에서 정말 자주 누락되는 상태들이 있고, 그게 빠졌을 때 개발 과정에서 어떤 일이 일어나는지, 그리고 앞으로 어떤 기준으로 체크하면 되는지를 같이 정리해 보려고 해요. 이 글 한 번만 읽으면 "디자인엔 없는데요?"라는 말을 훨씬 덜 들을 수 있을 거예요!   왜 상태(State)가 이렇게 중요한가요? 🤔 UI 컴포넌트는 언제나 딱 한 가지 모습만 가지지 않아요. 같은 버튼이라도 사용자가 마우스를 올리는 순간, 클릭하는 순간, 비활성화된 순간, 로딩 중인 순간에 모두 다르게 보여야 해요. 이 각각의 모습이 바로 "상태(State)"예요. 상태 디자인이 누락됐을 때 벌어지는 일은 크게 세 가지예요. 첫째, 개발자가 임의로 스타일을 만들어 넣어요. 그 결과는 브랜드 가이드와 전혀 다른 UI가 될 수 있어요. 둘째, 개발자가 기획자나 디자이너에게 다시 확인을 요청하면서 피드백 루프가 길어지고 일정이 지연 돼요. 셋째, 그냥 아무 처리도 안 한 채로 배포됐다가 사용자가 이상한 화면을 만나는 최악의 상황이 오기도 해요. ...

디자인 토큰 & Variables 운영 전략 — Figma부터 코드 매핑까지 완전 가이드

이미지
  디자이너는 "버튼 색 바꿨어요"라고 했는데 왜 화면에는 열다섯 군데가 다 다른가요? 디자인 토큰이 뭔지, Figma Variables로 어떻게 세팅하고, CSS Custom Properties와 Theme 객체로 코드에 매핑하는지, 그리고 실무에서 동기화가 깨지는 순간을 어떻게 막는지까지 — 이 글 하나로 다 정리해 드릴게요!   디자이너와 개발자 사이에 이런 대화, 다들 한 번쯤 겪어보셨을 거예요. "Primary 색상 조금 바꿨어요~" 한 마디에 개발자가 파일 열다섯 개를 열어서 색 코드를 하나씩 찾아 바꾸는 상황. 혹은 반대로, 개발자가 이미 코드에서 색을 바꿨는데 Figma 파일은 아직 옛날 색인 상황. 😅 이게 한두 번이면 모르겠는데, 프로젝트가 커질수록 이 문제는 기하급수적으로 커져요. 디자인 토큰은 바로 이 문제를 해결하기 위해 나온 개념이에요. "색, 간격, 폰트 크기 같은 디자인 결정 사항을 하나의 이름 붙인 변수로 관리하자"는 아이디어인데요, 말은 쉽지만 실제로 Figma Variables와 코드를 동기화해서 운영하는 건 생각보다 손이 많이 가요. 오늘은 그 전체 흐름을 처음부터 끝까지 정리해 드릴게요!   디자인 토큰이란 무엇인가요? 🔤 디자인 토큰(Design Token)은 UI를 구성하는 시각적 속성값을 이름 붙인 변수로 추상화한 것 이에요. 색상, 타이포그래피, 간격, 그림자, 모션 등 디자인 시스템에서 반복적으로 사용되는 값들이 모두 토큰의 대상이 될 수 있어요. 예를 들어 버튼의 배경색을 #6a1b9a 라는 HEX 값으로 직접 쓰는 대신, color.primary.500 이라는 토큰 이름으로 참조하는 거예요. 나중에 브랜드 색상이 바뀌어도 토큰 값 하나만 수정하면 그 토큰을 참조하는 모든 컴포넌트가 한꺼번에 업데이트되죠. 토큰의 3단계 계층 구조 실무에서 많이 쓰는 3-tier 구조를 알아두면...

Figma Auto Layout 안 쓰면 생기는 참사들 – 개발자가 울고 가는 디자인 파일의 비밀

이미지
  Figma에서 디자인은 예쁘게 뽑았는데, 개발자가 받으면 왜 멘붕이 올까요? Auto Layout 없이 고정 좌표로 찍어놓은 디자인이 개발 단계에서 어떤 참사를 일으키는지, 그리고 CSS Flexbox/Grid와 어떻게 대응되는지 Before/After 예시로 낱낱이 풀어봤어요.   솔직히 고백할게요. 저도 예전에 Figma에서 Auto Layout 없이 디자인한 적이 꽤 있었어요. 프레임 안에 요소를 드래그해서 눈대중으로 배치하고, 간격은 화살표 키로 1px씩 맞추고… 화면에서 보기엔 완벽했거든요. 😅 그런데 그 파일을 넘겨받은 개발자분이 조용히 슬랙으로 보내온 메시지가 아직도 생생해요. "이거… 간격이 위에서는 12px인데 아래에서는 13px이고, 이 버튼은 텍스트가 길어지면 어떻게 되는 건가요?" 그때부터 Auto Layout을 제대로 공부하기 시작했어요.   고정 좌표 배치 vs Auto Layout, 뭐가 다른 건가요? 🤔 가장 근본적인 차이부터 짚어볼게요. Figma에서 요소를 배치하는 방식은 크게 두 가지예요. 구분 고정 좌표 배치 Auto Layout 배치 방식 X, Y 좌표로 절대 위치 지정 방향·간격·패딩 규칙으로 자동 배치 내용 변경 시 다른 요소 수동으로 재배치 필요 자동으로 리플로우 반응형 대응 ...