Field Notes

디자인 시스템을 만들면서 계속 하나의 질문에 부딪혔습니다. 디자인 팀은 어디까지 책임져야 할까 기존 방식대로라면 시안을 보기 좋게 만들고, 구조 해석과 구현은 개발 단계에서 알아서 진행하도록 두는 것도 가능했습니다. 디자인은 결과물을 만들고, 시스템은 코드에서 완성되는 구조였습니다. 하지만 사내 프로젝트로 Figma MCP, Code Connect처럼 시안을 그대로 코드로 연결하는 환경을 전제로 하다 보니 이 방식이 더 이상 충분하지 않다는 점을 점점 체감하게 되었습니다. 그래서 이번 Select 컴포넌트를 설계하면서, DS를 새로 만들어보며 처음으로 시안 구조 자체를 코드 구조에 가깝게 가져가는 방향을 선택했습니다. 이 시점부터 Figma 시안을 단순한 화면 디자인이 아니라, 앞으로 반복적으로 재사용될 시스템 정의로 바라보기 시작했습니다. 디자인 팀 내부에서도 "이건 그냥 화면 디자인이 아니라, 앞으로 계속 재사용될 시스템 정의에 가깝다"는 이야기를 자주 나누게 되었습니다. 그 결과 시안을 설계할 때의 기준도 달라졌습니다. "이게 예쁜가 저게 예쁜가"보다 "이 레이어가 어떤 역할을 맡고 있는가"를 먼저 정리하게 되었습니다. 컴포넌트를 구성하는 레이어들은 시각적 그룹이 아니라 역할 기준으로 나누어 정의했습니다. 클릭을 담당하는 영역은 ListboxButton 옵션 패널은 ListboxOptions 반복되는 옵션 단위는 ListboxOption 레이어 이름과 annotation 역시 DOM 구조를 직접 지시하는 방식은 의도적으로 피하고, Headless UI에서 정의하는 역할 단위와 맞추는 방향을 선택했습니다. 이 방식은 Figma MCP 기준에서도 효과적이었고, 디자인 팀 입장에서도 "이 컴포넌트의 구조를 우리가 정의하고 있다"는 감각을 가질 수 있었습니다. 이 과정에서 또 하나의 태도 변화가 있었습니다.

두번 째로 손을 댄 영역은 Typography 토큰 구조입니다. 기존 시스템은 잘 동작하고 있었지만, 의미와 표현이 섞여 있었고 Text style과 토큰의 역할 경계가 애매했으며 AI가 이해하기에는 다소 모호한 구조였습니다. 그래서 이번에는 "사람 · 코드 · AI가 동시에 이해할 수 있는 구조"를 목표로 타이포그래피 토큰을 다시 정리해보기로 했습니다. 기존 문제점 기존 디자인 시스템에서는 다음과 같은 고민이 있었습니다. strong, secondary 같은 강조가 의미인지 표현인지 헷갈림 카드 타이틀, 섹션 타이틀이 Text style 이름으로만 구분 font-size, font-weight 같은 값이 직접 노출됨 "왜 이 텍스트가 이 크기인지" 설명하기 어려움 즉, 보이기는 하는데, 설명하기는 어려운 구조 IBM Carbon Typography 구조 참고 이 과정에서 IBM Carbon 디자인 시스템을 참고했습니다. Carbon을 보면 타이포그래피가 다음과 같이 나뉘어 있었습니다. Base (primitive) font-size line-height font-weight semantic layer heading body labelhelper

AI 기반 화면 자동화와 디자인 시스템 개편을 준비하면서, 기존 디자인 토큰 구조를 다시 점검하게 되었습니다. 특히 자동화를 고려할수록 UI를 구성하는 값들이 단순한 숫자에 머무르지 않고, 의미와 규칙을 가지고 있는지가 중요하다고 느꼈습니다. 이 과정에서 여백과 radius와 관련해 다음과 같은 질문들이 계속 생겼습니다. 이 위치의 여백은 왜 16px인지 카드 내부 여백과 섹션 내부 여백이 같은 개념인지 카드 가로 리스트와 세로 리스트에서 동일한 spacing을 사용해도 되는지 값은 이미 Figma와 코드에 정의되어 있었지만, 해당 값을 사용하는 기준을 명확하게 설명하기 어려운 상태였습니다. 이 문제를 정리하기 위해 디자인 시스템의 Figma 토큰 구조를 다시 살펴보게 되었습니다. 기존 DS 상태 값은 있지만 판단 기준이 부족한 구조 기존 spacing과 radius 토큰은 크기 단계(xs, sm, md 등) 위주로 정의 B2B 특성상 예외 화면이 많기도 하고 여러 구조가 존재하기 때문에 화면을 만들 때마다 여기는 '16px인가, 12px인가' 와 같은 쓸모없는 고민이 반복되었고 디자이너들끼리도 정리를 해두었지만 헷갈릴 때마다 확인해야 하는 불필요한 시간이 있었습니다. 개인의 감각이나 경험에 따라 판단이 달라질 수 있는 구조였고, 디자인 시스템 차원에서 사용 맥락을 충분히 설명하지 못하고 있다는 느낌이 들었습니다. 접근 방식 숫자보다 '의미'를 먼저 정리 문제의 핵심은 숫자 자체가 아니라 이 여백이 어떤 관계의 공간인지를 설명하지 못하고 있다는 점 → 이에 따라 spacing과 radius 토큰을 값(primitive) 과 의미(semantic) 로 나누어 정리하기로 했습니다.

피그마(Figma)가 AI 기반 웹사이트 제작 도구와 앱 프로토타입 생성 기능 등 다양한 신규 서비스를 발표했습니다. 디자이너들은 보통 피그마 내에서 웹사이트의 프로토타입을 구축하는데, 이 새로운 AI 기반 도구를 통해 웹사이트를 쉽게 만들고 게시할 수 있게 되었습니다. 사이트가 생성되면 협업자들은 프롬프트 없이도 편집기를 통해 사이트 요소를 쉽게 변경할 수 있으며 전환 효과, 애니메이션, 스크롤 효과를 추가하면서 반응형 사이트를 만들 수 있습니다. 피그마는 사이트에서 직접 블로그 게시물을 생성하는 기능도 추가 했습니다. 이는 피그마 사이트에 콘텐츠 관리 시스템(CMS)이 내장되어 있어 사용자가 블로그 디자인 내에서 게시물을 편집하고 썸네일과 슬러그 같은 다른 자산도 관리할 수 있음을 의미합니다. 주식 티커와 같은 인터랙티브 요소의 경우, 사용자 정의 코드를 추가하거나 AI를 사용하여 코드를 생성할 수 있습니다. ​ 반면 ‘피그마 메이크(Figma Make)’는 아이디어 구상과 프로토타입 제작에 더 초점을 맞춘 유사한 AI 기반 도구입니다. 사용자는 프롬프트를 입력하여 웹 및 앱 제품을 만들 수 있습니다. 프로토타입 앱은 협업이 가능하며, 사용자들은 특정 요소를 변경하거나 추가하도록 어시스턴트에게 요청할 수 있습니. 또한 팀에 개발자가 있다면 필요한 변경 사항을 적용하기 위해 코드를 직접 수정할 수도 있습니다. 사용자는 시계와 같은 작은 인터랙티브 요소를 생성하여 나중에 피그마 사이트를 통해 게시된 페이지에 삽입할 수도 있습니다. 개요 회사에는 아직 기술 블로그가 없어 항상 아쉬움을 느끼고 있었습니다. 회사 내부 각 팀의 기술적 고민이나 작업 과정, 인사이트를 외부에 공유할 창구가 없다는 점은 개인적으로도, 회사 전체적으로도 손해라고 생각했기 때문입니다. 그래서 사이드 프로젝트로 기술 블로그 템플릿을 직접 만들어보기로 했습니다. 💡장점1) 한국어 프롬프트 지원 원래는 영어 프롬프트만 지원하는 줄 알고 반신반의하며 접근했는데, 한국어 프롬프트도 매우 잘 인식해서 놀랐습니다. 프롬프트 하나로 전체 블로그 레이아웃이 쉽게 만들어지는 모습은 인상적이었습니다. 일부러 처음에 어떤 컨텐츠를 담아달라고 요청하지 않았는데도 단순히 텍스트 박스를 생성하는 수준이 아니라, 어느 정도 구조가 잡힌 페이지를 생성해주어서 초기 설계 시간을 크게 단축할 수 있었습니다. 💡장점2) 디자인 시스템 연동과 링크 퍼블리시 지원 MAKE의 장점 중 하나는 기존 디자인 시스템과의 연동입니다. 디자인팀에서 사용하는 디자인 시스템을 불러와 활용할 수 있었고, 이로 인해 완성된 템플릿도 기존 제품 스타일에 맞게 통일감을 유지할 수 있었습니다. 컴포넌트를 하나하나 연결해주는 방식이긴 했지만, 디자이너 입장에서는 톤앤매너를 유지할 수 있다는 점에서 큰 이점이었습니다. 또 하나 주목할만한 기능은 바로 퍼블리시 기능입니다. MAKE에서 만든 블로그를 퍼블리시하면, 곧바로 공유 가능한 링크 형태로 완성된 웹 페이지가 생성됩니다. 별도의 호스팅이나 설정 없이 클릭 몇 번으로 외부 공개가 가능하다는 점은, 디자이너나 개발자가 빠르게 프로토타입을 공유하거나 테스트해보기에도 아주 유용했습니다.

업무 중 아이콘 제작 요청이 들어올 때, 아이콘을 만드는 것보다 배포하는 과정이 복잡하고 어려워서 개선이 필요하다는 생각을 항상 가지고 있었습니다. 현재 자사 아이콘 배포 방식은 수작업이 많고 반복적인 과정을 포함하고 있어서, 이를 MCP 또는 사내 자동화 플랫폼으로 효율화할 수 있는 방법을 모색해보았습니다. ✅ 현재 자사 아이콘 배포 프로세스 요약 Figma에서 아이콘 제작 Icon Font Exporter 플러그인으로 export SVG, Font 파일을 NAS에 업로드 VS Code로 열고 코드화하여 사내 폴더에 업로드 🎯 MCP를 통한 자동화/효율화 방안 Figma에서 MCP 연동 자동 Export MCP가 Figma API 또는 Figma 플러그인 연동이 가능하다면: 특정 프레임/페이지에서 변경이 감지되면 MCP가 자동으로 export 수행 (SVG or font) 예) Figma Web API를 통해 아이콘이 포함된 프레임을 주기적으로 pull 또는 webhook 사용 SVG & Font 파일 자동 변환 및 정리 Export된 파일을 MCP에서 받아 정해진 naming rule에 따라 자동 정렬 및 리네이밍 SVG → web font (.woff, .ttf) 변환 자동화 스크립트 포함

실무를 경험하며 디자인 시스템이 단순한 스타일 가이드를 넘어서 제품의 효율성과 일관성, 그리고 사용자 경험 전반을 좌우하는 핵심 요소라는 걸 체감하고 있습니다. 최근에는 디자인 시스템의 개념을 다시 처음부터 정리하고 실제 업무에 어떻게 효과적으로 적용하며 퀄리티 좋은 디자인 시스템을 구성할 수 있을지 고민해보고 있습니다. 실제 업무 속에서는 이상적인 디자인 시스템이 언제나 그대로 적용되지는 않았습니다. 특히 자사 제품 특성상 복잡한 요구사항이 많아 그 과정에서 디자이너들이 겪은 현실적인 어려움이 분명히 존재했습니다. :: B2B 디자이너가 제품 디자인 과정에서 마주하는 어려움 :: 1) 단일한 기준이 어려운 디자인 요소들 제품 디자인 시 버튼 스타일이나 색상 등 UI 컴포넌트의 룰을 명확히 정의하기 어려운 이유는, 화면마다 위계와 강조 포인트가 모두 다르기 때문입니다. 예를 들어, 버튼 유형만 보더라도 다음과 같은 다양한 경우의 수가 존재합니다. 아이콘 + 텍스트 텍스트 + 아이콘 아이콘만 텍스트만 이 중 어떤 유형을 써야 하는지 명확한 기준을 세우기가 어려울 때가 많습니다. 설명이 필요한 버튼에는 아이콘과 텍스트를 함께 써야 하고, 정보가 단순한 화면에서는 아이콘 만으로도 충분한 경우가 많습니다. 이러한 이유로 화면 별로 버튼 구성에 대한 판단이 매번 필요하고, 디자이너마다 해석이 달라질 여지가 있습니다. 비슷한 고민은 색상 정의에서도 발생합니다. 예를 들어, 어떤 화면에서는 ‘임시 저장’이 주요 액션이므로 Primary 색상으로 표시하는 것이 타당합니다. 하지만 다른 화면에서는 ‘임시 저장’이 보조적인 기능이 되어버려 Primary 색상을 쓰는 것이 오히려 부자연스러워질 수 있습니다. 이처럼 UI 요소의 의미나 위계가 맥락에 따라 유동적이기 때문에, 단일한 규칙으로 모든 상황을 포괄하는 것이 어렵고, 디자이너 개개인이 각 화면에 맞는 판단을 해야 한다는 점이 주요한 고민거리입니다. 2) 디자인 아이디어 vs 개발 현실