Intro

작성일 : 2022.10.30 / 수정일 : 2022.10.30

들어가며

최근 디자인 시스템을 정리하며, 스토리북을 사용할 기회가 생겼다.

스토리북을 안지는 좀 되었지만, 실제로 사용해보지는 않았는데, 그 이유는 크게 다음과 같았다.

스토리북을 찾아보던 시기는 한창 서비스를 위한 디자인 시스템을 개발하던 도중이었다.

당시의 가장 큰 고민은 기존 서비스의 컴포넌트를 분리하고, 최소 단위인 코어 컴포넌트를 만들어, 적용하는 것이었다.

코어 컴포넌트는 최소 단위의 기능을 하는 컴포넌트로 이해하여 제작하였고, Button, Input과 같은 컴포넌트가 이에 해당되었다.

컴포넌트 체계화를 위해, 스토리북을 도입해볼까 테스트해보았던 적이 있지만, 실제 도입하기는 위에 작성한 문제들이 있었다.

위 세 이유는 서로 연결 되어있다고 보아도 무방한데, 결론은 당시에는 도입의 필요성을 못 느꼈다.

시간이 지나며, 상황이 바뀌었다.

초기 디자인 시스템을 구축하고 서비스를 개발한지 시간이 꽤 흘렀다.

서비스의 규모는 점점 커져가고, 코어 컴포넌트가 조합된 다양한 컴포넌트도 수 없이 생겨났다.

핵심 기능들이 개발되고 나니, 이후에는 엣지 케이스를 찾고, 추가 기능에 대한 컴포넌트 작성하는데 어려움이 발생하기 시작했다.

피그마와 실제 컴포넌트 간 동기화도 문제였다. 빠르게 개발을 진행하고자 디자인 문서화보다 개발을 우선하게 되었고, 디자인 문서 업데이트가 진행되지 않은 채 컴포넌트만 업데이트 되는 일이 많아졌다.

위와 같은 문제들은 점점 서비스의 UI 개선을 어렵게하는 요인으로 다가오게 되었고, 이에 대한 대책이 필요하다고 느꼈다.

다행인 점은, 초기 디자인 시스템을 기반으로 한 디자인/UI 컴포넌트 구축이 다행히도 잘 적용되었다는 점이다.

코어 컴포넌트를 활용해, 점진적으로 컴포넌트를 늘려가는 아토믹 디자인 방식이 안정적으로 서비스 개발에 받아들여졌고, 코어 컴포넌트를 베이스로 다른 프로젝트에도 활용할 수 있게 되었다.

현재의 상황 역시 개발이 진행되며 새로운 기능에 대한 추가보다 기존 개발에 대한 개선(리팩토링)이 필요해진 상황이었다.

디자인 시스템이 정착되지 못한 점이 해결되고, 서비스 개선을 위한 방법을 필요로 하는 상황이 되자, 스토리북을 도입해보자는 생각에 도달하게 되었다.

스토리북을 도입하기 위해 여러 삽질 아닌 삽질을 겪었는데, 이 글들을 통해 한번 공유해보고자 한다.

이 글은 개인적인 경험을 기반으로 한다. 따라서 스토리북 사용과 적용에 주관적이다.

따라서 더 좋은 방법이 있다면 알려주고 공유해주길 바란다.