1. 베이스가 될 컴포넌트들을 만들다보니 컴포넌트에 대한 커스텀 권한이 어느 정도가 되어야할지 적정한 선에 대한 고민이 있다. 디자인에 맞게 변형이 너무 힘들면 그것도 불편하고 그렇다고 디자인 시스템을 너무 변형해서 사용하는 것도 디자인 시스템이라는 목적성에 맞는지 모르겠다.
오픈소스로 개방하고 개인적으로 여러 도메인에서 사용할 생각이라 변형이 쉽게 설계하고 개발하고 있긴하다. 기존의 antd나 부트스트랩 머테리얼 디자인등을 참고중 인데 해당 부분들이 UI 라이브러리긴 하지만 순수하게 디자인 시스템이라고 보긴 힘들어서 그런점도 있고 cloudscape-design와 같이 특정 도메인에 종속적인 느낌으로 가기엔 아직 결정한게 없다.
2. 컴포넌트 자체의 복잡도가 서로 다른 점 해당 시스템을 실제로 적용해서 작업 환경을 만들었을때 아토믹 패턴 같은 UI에 대한 레이어를 다루는 점이 어떻게 될지 분석해보고 있다.
아토믹 패턴을 기반으로 사고 할 경우 컴포넌트의 복잡도가 서로 다르긴하지만(atom,molecules...) 디자인 시스템 내부에서 컴포넌트 복잡도에 따른 레이어를 추가적으로 나누는 것은 추후로 미루었음. 디자인 시스템을 실제 개발에 적용한다 할 경우 프로젝트의 UI 자유도를 어느 정도로 보장할지는 고민이 되는 부분인데 디자인 시스템에 편입해야 할 요소와 편입해서는 안될 요소에 대한 정의가 모호해서 고민 다만 어느 정도 기준점이나 선은 생각이 끝남.
3. 디자인 시스템 개발을 위해서 피그마등의 디자이너 리소스를 지원해야하는 점이 있는데 해당 부분이 매우 귀찮다는걸 느낌 또 토큰을 더 견고하게 설계해야하는 부분이 있는데 이 부분에서 기존의 협업 도구들인 피그마등을 고려하지 않을 수 없어서 골치가 아프다.
디자이너가 아니다 보니 디자인 가이드 같은 것을 어떻게 해야할지 자료는 찾아보고 있지만 애매함. 토큰 등을 디자이너가 사용하기 쉽게 제공해야한다는 점 때문에 디자인 시스템이 아니라 디자인 라이브러리로 갈아타고 싶은 욕구가 생김.
디자이너 리소스에 대한 부분은 추후 제공을 하고 디자인 라이브러리로의 완성을 우선시할 생각도 있다.
4. 앱 지원 문제에 대한 고민 현재는 리액트 기반으로 한 웹뷰만을 고려하고 있지만 개인적으로 생각 했을때 해당 프로젝트가 유의미 해질려면 결국 사이드 프로젝트나 외주, 개인 앱을 개발하는데 사용해야 수익 창출의 의미가 있고 지속적으로 관리할 동인이 되지 않을까? 생각중이다. 그러자면 클라이언트 사이드 만을 사용한 앱이라고 할지라도 웹 대신 앱 네이티브 뷰를 지원하는게 인프라 리소스를 절약해서 앱테크에 용이하지 않을까?
추후 고민할 문제이긴 하지만. 이번 프로젝트를 계속 미뤄두었던 문제중의 하나인 개발에 필요한 리소스가 너무 많이 필요한 점 때문에 나중에 가능할지 의문이다. 사실 기존 디자인 시스템을 살펴봤을때 따로 개발하면서 점점 필요로 하는 부분들이 많아지고 있어서 더욱 그렇다. 적당히 타협하고 자기에게 실질적으로 필요한 부분들을 먼저 맞추는 방향성을 고민중.. 순수하게 재미의 영역으로 개발을 시작하긴 했지만 개발을 하다보니 생각이 많아진다.
'프로젝트' 카테고리의 다른 글
[메모장] Memo 프로젝트 -1- (0) | 2023.03.05 |
---|---|
유틸과 헬퍼함수를 정리해보기. (0) | 2022.12.21 |
오픈소스 디자인 시스템 만들기 -3- (0) | 2022.11.12 |
오픈소스 디자인 시스템 만들기 -2- (0) | 2022.11.11 |
오픈소스 디자인시스템 만들기 -1- (0) | 2022.10.14 |