basenode

React Tailwind 디자인 토큰 연동: 효율적인 시스템 구축 가이드 프론트엔드 개발 현장에서 Tailwind CSS는 압도적인 생산성을 제공하지만, 프로젝트 규모가 커질수록 한계에 부딪히곤 합니다. 코드 여기저기에 text-[#3B82F6]이나 p-[17px] 같은 정체불명의 매직 넘버들이 흩뿌려지기 시작하면, 디자인 가이드가 변경될 때마다 수천 개의 파일을 뒤져야 하는 ‘유지보수의 재앙’이 시작되죠. 많은 팀이 테일윈드를 쓰면서도 디자인 시스템 구축에 어려움을 겪는 이유는 … 더 읽기

디자인 토큰 자동화: GitHub Actions 기반 CI/CD 파이프라인 구축 가이드 디자이너가 피그마에서 색상 변수 하나를 수정했을 뿐인데, 이를 반영하기 위해 개발자가 코드를 수정하고 다시 빌드하여 배포하는 과정을 거치고 있나요? 수동으로 데이터를 옮기는 과정에서 발생하는 오타나 누락은 서비스의 시각적 일관성을 해칠 뿐만 아니라, 팀 전체의 생산성을 갉아먹는 주범입니다. 진정한 의미의 DesignOps는 디자인 데이터가 인간의 개입 없이 … 더 읽기

다크 모드 디자인 시스템: 시맨틱 토큰 레이어로 자동화 구현하기 라이트 모드에서 정교하게 설계된 화면을 다크 모드로 전환했을 때, 단순히 색상만 반전시켜서 가독성이 깨지거나 브랜드 아이덴티티가 무너지는 경험을 해보셨나요? 특히 수백 개의 화면을 가진 대규모 프로젝트에서 일일이 하드코딩된 색상 값을 찾아 다크 모드 대응 코드를 추가하는 작업은 개발자에게는 야근을, 디자이너에게는 끝없는 검수 작업을 강요하는 비효율의 극치입니다. … 더 읽기

피그마에서 정성껏 정의한 디자인 토큰이 개발 환경으로 넘어오는 과정에서 “복사해서 붙여넣기”라는 원시적인 수작업에 의존하고 있지는 않으신가요? 디자이너가 헥사 코드를 하나 바꿀 때마다 개발자에게 슬랙을 보내고, 개발자는 소스 코드 어딘가에 숨겨진 변수를 찾아 수정하는 방식은 단순히 귀찮은 일을 넘어 휴먼 에러의 온상이 됩니다. 이런 소모적인 과정을 단번에 해결해 주는 도구가 바로 아마존에서 만든 Style Dictionary입니다. Style … 더 읽기

“이게 왜 blue-10인가요? 어제는 분명 blue-5 아니었나요?” 디자인 시스템 회의실에서 이런 소모적인 논쟁이 오가고 있다면, 이미 시스템의 기초인 ‘언어’가 무너지고 있다는 증거입니다. 디자인 토큰의 이름은 단순히 색상이나 수치를 지칭하는 라벨이 아니라, 디자이너의 의도와 개발자의 로직을 연결하는 유일한 인터페이스입니다. 이름 짓기에 실패한 시스템은 결국 유지보수의 늪에 빠지게 됩니다. 브랜드 컬러가 살짝 바뀌었을 뿐인데 수백 개의 컴포넌트 … 더 읽기

피그마 변수 vs 스타일: 상황별 선택 가이드와 실무 활용법 디자인 시스템을 구축하다 보면 가장 먼저 마주치는 난관이 있습니다. 바로 “이 색상을 스타일(Styles)로 만들 것인가, 아니면 변수(Variables)로 만들 것인가?” 하는 문제입니다. 두 기능은 겉보기에 비슷해 보이지만, 시스템의 확장성과 개발 연동 측면에서 완전히 다른 DNA를 가지고 있습니다. 과거에는 모든 것을 ‘스타일’로 해결해야 했지만, 이제는 변수의 등장으로 더 … 더 읽기

디자인 가이드가 업데이트될 때마다 개발자가 수동으로 컬러 코드와 간격 값을 코드에 옮겨 적는 비효율적인 상황, 아마 실무에서 한 번쯤은 겪어보셨을 거예요. 기껏 구축해 둔 디자인 시스템이 디자이너의 피그마 안에서만 머물고 개발 환경과 동기화되지 않는다면 그것은 살아있는 시스템이라기보다 정적인 문서에 가깝습니다. 이 글에서는 피그마의 변수(Variables) 기능을 활용해 디자인 토큰을 정의하고, 이를 Style Dictionary를 통해 실제 코드 … 더 읽기