글
네이밍 컨벤션 — 디자이너와 개발자가 같은 언어로 대화하는 법
"레이어1", "그룹 복사본 3", "버튼-최종2" — 이 파일, 혹시 당신 거 아닌가요? 😅 레이어 이름부터 컴포넌트·페이지 구조까지, 디자이너와 개발자가 같은 언어로 대화할 수 있는 네이밍 컨벤션을 나쁜 예시와 좋은 예시를 직접 대비하며 정리해 드릴게요! 솔직히 고백하자면 저도 한동안 레이어 패널이 "Rectangle 45", "그룹 복사본 2", "Frame 123" 같은 이름들로 가득한 채로 작업했어요. 혼자 쓸 땐 큰 문제 없었거든요. 🙈 근데 개발자에게 파일을 넘기는 순간부터 달라졌어요. "이 레이어가 버튼이에요, 배경이에요?" "이 컴포넌트 이름이랑 코드 이름이 다른데 맞는 거예요?" 질문이 쏟아지더라고요. 네이밍은 단순한 정리 습관이 아니에요. 디자이너·개발자·기획자가 같은 단어로 같은 것을 가리킬 수 있게 해주는 공통 언어 예요. 오늘은 레이어·컴포넌트·페이지 구조 각각의 네이밍 원칙을 나쁜 예시 vs 좋은 예시로 대비해서 보여드릴게요. BEM, Atomic Design 같은 방법론과의 연결까지요! 왜 네이밍이 이렇게 중요한가요? 🤔 나쁜 네이밍이 실무에서 만들어내는 문제는 크게 세 가지예요. 탐색 비용 증가: "이 컴포넌트 어디 있더라?" 하고 레이어 패널을 뒤지는 시간이 쌓이면 하루에 몇십 분이 날아가요. 코드-디자인 불일치: Figma에서 "버튼-블루"인데 코드에선 ButtonPrimary 예요. 신규 입사자가 무엇을 참조해야 할지 몰라요. 인수인계 실패: 작업자가 바뀌면 파일을 처음부터 해석해야 해요. "이게 뭐지?" 시간이 온보딩의 절반을 잡아먹어요. 💡 핵심 원칙 먼저! ...
디자이너가 자주 빠뜨리는 컴포넌트 상태들 — 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 구조를 알아두면...