창립이래 최초의 디자인시스템 구축하기(feat. 30년만에!)의 2편인 이번에는 시스템 구축을 위한 설계 과정, 사용법 그리고 시스템의 확장에 대한 부분에 대해 소개한다. 시스템 설계에 있어서 가장 기반이 되는 Foundation을 지정하게 되는데, 그중 디자인 토큰은 디자인 시스템 구축에 있어서 기반이 되고 공수가 많이 드는 작업 중 하나다. 다음으로는 설계한 토큰을 실제 컴포넌트에 어떻게 적용하고 피그마에도 활용할 수 있는지 확인하고 마지막으로 컴포넌트의 다형성(Polymorphism)을 위해 Type-Safe한 인터페이스를 만들어 더 확장성 있는 디자인 시스템을 구축하는 단계를 살펴보자. Foundation디자인 토큰 설계 시 아래 4가지를 고민하여 설계한다.브랜드 컨셉을 따르는 컬러와 폰트에 대한..

이번 포스팅은 회사 창립 이래 30년 만에 최초로 디자인 시스템을 본격적으로 구축하고, 사내 시스템으로 배포하기까지의 과정과 기술적으로 어떻게 구상하고 적용했는지에 대해 두개의 포스팅으로 공유하고자 한다.사실 최초라고 작성하긴 했지만, 재작년에 작성했던 "Storybook으로 퍼블리셔, 디자이너와 협업 그리고 디자인 시스템 구축까지"라는 글의 주제로 포스팅한 적이 있었다. 하지만 이때는 사내 시스템으로 배포에는 실패하고, 제품의 공통 컴포넌트로 사용하는 수준에서 그쳤다. 왜냐하면 사내에서 디자인 시스템을 구축하고 왜 이걸 하는지 타당한 이유가 부족했다.그래서 지난번의 디자인 시스템 구축에 실패했던 이유와, 이번에는 성공했던 이유 그리고 소통의 장애를 극복한 이야기에 대해 풀어보고자 한다. 최초의 디자인 ..

돌아보기눈 깜짝할 사이 한 해가 흘러갔다. 어김없이 이번에도 회고록을 작성하기 위해 노트북을 열었고, 지난 회고록("나는 어떻게 살아온 것인가, 2023년 회고"를 다시 읽어보았다. 다른 글보다 많은 정성이 들어갔고, 당시 작성했던 내 심정이 잘 드러나는 글이었다. 잘하기도 했고, 미흡하기도 했다. 그러면 2024년에는 어땠을까? 목표당시 회고록을 살펴보면 명확한 목표도 없고, 방법도 잘 몰라서 필요 이상의 시간을 쏟아부으며 움직이던 해였다. 그 때문에 다음 해에는 목표를 좁혀 부족한 것을 메꾸고, 해야 할 것에 시간을 투자하기로 마음먹고 움직였다. 이번에는 건강을 잃어가면서 불필요한 것에 시간과 체력을 소모하고 싶지 않았고, 시기적으로 중요한 시기로 접어들었기 때문이다.30대 남자라면 대부분은 앞으로의..

지난 글 [브라우저 최적화(1)] CRP의 이해와 브라우저 리소스 식별 방법 CRP에서 렌더링 및 파서 차단에 대해 종류 역할을 이해하고 브라우저의 리소스를 식별하는 방법에 대해서 알아보았다. 브라우저 리소스의 흐름을 파악하게 되면 비로소 브라우저 최적화를 할 수 있는 단계를 밟을 수 있게 된다.이번 글에는 라이브러리나 프레임워크에서 최적화하는 방법과 이를 의존하지 않는 방법에 대해 정리해본다. preloadpreload는 현재 페이지에서 바로 필요로 하는 리소스를 먼저 가져오는 방법이다. 이 리소스는 CRP 이전에 요청되어 더 빨리 사용할 수 있고, 페이지의 렌더링을 막을 가능성이 낮아져 성능을 향상한다. preload는 폰트나 이미지 등 CSS 내부에서 사용하는 리소스, 크기가 큰 이미지와 비디오 파..

웹 페이지는 최초 렌더링 단계나 네트워크에서 렌더링/파서 차단(redner-blocking, parser-blocking)을 어떻게 다루냐에 따라 성능에 크게 좌우가 된다. 그 중에서 CRP(Critical Rendering Path)가 어떻게 흘러가는지 이해하고, HTML 속성과 CSS 처리 옵션을 다룰 줄 알면 사용자 경험을, 개선을 크게 향상 시킬 수 있다.이번 글에선 브라우저 렌더링 단계에서 CRP가 무엇이고 어떤 단계에서 리소스가 차단되는지 그리고 렌더링 우선순위를 어느 위치에 잡아야 하는지 알아보고 브라우저에서 제공하는 기능들을 통해 브라우저 리소스 로딩을 최적화하는 방법을 알아보자. CRP(Critical Rendering Path)CRP란 브라우저가 서버로부터 HTML, CSS, Javas..

개요디자인 시스템 구축을 위해 `Radix-UI` 를 사용 중인데 내부 구조를 살펴보다가 이벤트 핸들링 방식에 대해 궁금하여 오픈 소스 코드를 살펴보던 중 2년전 React가 17에서 18로 업데이트 되면서 이벤트 처리에 대한 큰 변화로인해 트러블 슈팅을 겪은 사례에 대해 알게되어 조사하게되었다. (이 글은 저의 트러블 슈팅이 아닙니다...!) 사건의 발단으로는 하나의 이슈 사항으로 인해 PR이 머지 된 사례가 있었다. 이슈로는 `ContextMenu`에 대한 일관된 동작이 이루어지지 않는 다는 것. 이는 React 18의 핵심 변경 사항 중 하나로, 모든 이벤트 핸들러에 일관되게 자동 일괄 처리(automatic batching)를 도입한 것으로, 특정 이벤트만 일괄 처리를 적용이 가능했던 17버전과는..