디자인 시스템 전파의
디자인 시스템의 확산은 UI 키트나 컴포넌트 라이브러리를 만드는 기술적 작업만으로 이루어지지 않으며, 사람과의 협업을 통해 조직 문화로 정착되어야 한다. 특히 페어링은 다른 디자이너·엔지니어와 함께 작업하며 시스템의 문제를 발견하고, 비판을 협력으로 전환하며, 시스템의 가치를 자연스럽게 전파하는 가장 효과적인 방법이다. 디자인 시스템 팀은 “규칙을 지키라”고 요구하기보다 사용자의 일을 더 빠르고 높은 품질로 만들어 주는 파트너가 되어야 한다. ## 디자인 시스템은 기술 프로젝트가 아니라 문화 프로젝트 - UI 키트나 컴포넌트 라이브러리를 혼자 구축하는 것만으로는 조직의 불일치를 해결할 수 없다. - 디자인 시스템은 디자이너, 엔지니어, 제품 관리자, 고객 사이의 관계와 조직 문화를 반영한다. - “파란색을 쓰지 마라”, “이 컴포넌트를 왜 새로 만들었나”처럼 잘못을 지적하는 방식은 디자인 시스템 팀과 다른 팀을 대립 구도로 만들 수 있다. - Gusto는 다음과 같은 소통 장치를 마련했다. - 피드백과 질문을 위한 Slack 채널 - 디자인 시스템 팀의 오피스 아워 - 신규 구성원을 위한 UI 소개 키트 - 그러나 가장 효과적으로 시스템을 전파한 방법은 직접 함께 작업하는 페어링이었다. ## 페어링은 디자인 시스템의 사용자 조사다 - 다른 디자이너와 나란히 작업하면 실제 사용 과정에서 다음을 관찰할 수 있다. - 어떤 컴포넌트와 패턴이 혼란스러운가 - 문서나 Figma 파일에서 어떤 정보가 부족한가 - 기존 시스템에서 이상하거나 잘 작동하지 않는 부분은 무엇인가 - 팀이 사용자의 필요를 추측하는 대신, 실제 사용 데이터를 바탕으로 컴포넌트와 문서를 개선할 수 있다. - 페어링 중에는 다음과 같은 질문에 답할 수 있다. - 디자이너와 엔지니어가 컴포넌트 라이브러리의 존재를 알고 있는가 - HTML·CSS의 최신 모범 사례를 이해하고 있는가 - 특정 컴포넌트를 사용하는 것이 조직 전체에 왜 유리한지 설명하고 있는가 - 개인 작업에서 유용한 레이아웃을 공식 패턴으로 발전시킬 수 있는가 - 오피스 아워는 사용자가 언제 도움을 받아야 하는지 판단하지 못해 참여율이 낮을 수 있지만, 페어링은 실제 작업 흐름 안에서 문제를 발견한다. ## 비판을 협업으로 전환하는 페어링 - 디자인 시스템 팀과의 협업은 추가적인 디자인 리뷰가 아니라, 작업 속도를 높이고 향후 버그를 줄이는 과정처럼 느껴져야 한다. - 초기 디자인 시스템은 복잡하고 문서화가 부족한 경우가 많다. - 사용할 수 있는 색상이 제한되어 있다는 사실 - 이미 동일한 용도의 컴포넌트가 존재한다는 사실 - 특정 구현 방식이 접근성 기준을 위반한다는 사실 - 이런 규칙을 한꺼번에 강요하면 통제적으로 보일 수 있고, 엔지니어는 문서를 무시하며 디자이너는 기존 시스템과 어울리지 않는 UI를 만들 수 있다. - 페어링은 디자인 시스템 팀이 머릿속에만 보관하던 코드베이스의 제약과 조직의 지식을 직접 전달하게 한다. - 동시에 디자인 시스템 팀도 제품 디자이너가 실제로 어떤 일을 해야 하는지 이해하게 된다. - 결과적으로 디자인 시스템 팀은 현장의 요구를 파악하고, 제품 팀은 프런트엔드 컴포넌트와 패턴을 배우면서 양쪽 모두 더 빠르게 작업할 수 있다. ## 시스템의 지지자를 만드는 방법 - 페어링을 경험한 디자이너와 엔지니어는 디자인 시스템을 단순한 규칙 모음이 아니라 자신의 작업을 개선하는 도구로 이해하게 된다. - 직접 협업을 통해 얻은 지식은 각 팀으로 돌아가 자연스럽게 공유될 수 있다. - 디자인 시스템의 채택을 높이려면 규칙 준수를 감시하기보다, 시스템이 창의성을 제한하는 것이 아니라 작업에 “추진력을 더해준다”는 경험을 제공해야 한다. - 이런 경험이 축적되면 디자인 시스템 팀 외에도 시스템을 설명하고 추천하는 내부 전도자(evangelist)가 늘어난다. 실무적으로는 정기적인 페어링 세션을 실제 디자인·개발 과제와 연결하고, 세션에서 발견한 혼란과 요구를 컴포넌트·문서 개선으로 바로 반영하는 것이 좋다.
원문 읽기(새 탭에서 열림)