
최근 프로젝트에서는 디자이너 시절부터 꼭 개발자분들과 만들어보고 싶던 스토리북을 적용해보았어요! 프론트엔드 개발을 시작하고부터는 직접 구현할 수 있겠다는 생각에 설레었지만, 생각보다 기회가 생기지 않았었죠. 그런데 이번 프로젝트에서는 상황이 잘 맞아떨어졌습니다.
현재 구성된 디자인 파운데이션부터 버튼 컴포넌트까지 구현을 모두 하고보니 문득, 이참에 스토리북까지 적용해보자는 생각이 들었죠!

그동안의 마음으로는, 모르던 것을 새롭게 도입하겠다 하면 최소 공식문서를 모두 보고 난 뒤에 시작해야한다고 생각했었어요. 그런데 언제부턴가 그 패턴이 바뀌었습니다.

사용할 수 있는 상황과 소재가 주어졌을 때, 우선 어설프게라도 바로 시작하며 이론 학습과 실습을 동시에 진행하는 패턴으로 바뀌어 가고 있었죠. 이 패턴이 가능해진 것은 생성형 AI 덕분입니다! 답변 받은 코드를 초벌로 여기며, 그때 비로소 해당 부분을 공식 문서와 대조(진실을 판별)하며 학습하는 방식입니다.
우선 지식이 없는 상태지만 제가 만들어 놓은 컴포넌트를 기준으로 스토리북 구성을 어떻게 할지 질문했어요. 초기화부터 순차적으로 알려주었고, 그것이 진실이든 아니든 일단 따라했습니다.

Storybook은 UI 구성 요소와 페이지를 격리하여 빌드하기 위한 프런트엔드 워크숍입니다. 전체 앱을 실행할 필요 없이 도달하기 어려운 상태와 엣지 케이스를 개발하고 공유하는 데 도움이 됩니다. 수천 개의 팀이 UI 개발, 테스트 및 문서화에 이를 사용합니다. 오픈 소스이며 무료입니다.
Docs | Storybook
프로젝트에 구축된 디자인 시스템을 구현할 수 있는 개발 환경입니다. 그 구성에는 디자인 파운데이션(Color, Typography, Icon, Space 등)와 컴포넌트가 있죠.
특히 스토리북은 UI 컴포넌트를 독립적으로 개발하며 테스트할 수 있다는 큰 장점이 있고, 그 자체로 컴포넌트의 문서로서 사용될 수 있습니다!
저는 현재 VueJS로 프로젝트를 개발하고 있습니다. 진행 중인 프로젝트에 곧장 적용하기 위해, 스토리북 전반에 대해 학습하기보다는 아주 작은 목표를 먼저 잡았습니다.
목표: 현재 프로젝트에 어떻게
스토리북을 연동해서, 버튼 컴포넌트 하나를 어떻게스토리북에서 확인할 수 있을지 알아내기
npx storybook@latest init
npm run storybook
Storybook 설치와 초기화를 동시에 진행하면, package.json에 다음의 script가 자동 생성됩니다.

사실 스토리북은 초기화를 하자마자 샘플 스토리가 구성되어있는 상태입니다.

때문에 스토리(stories) 코드와 스토리북 로컬 서버에서 확인하면 어떤 식으로 스토리를 구성하는지 시각적으로 감을 잡을 수 있었어요!
그럼에도 우선 저는 시행착오를 줄이기 위해 Chat GPT에게 제가 만든 버튼 컴포넌트를 넘기며 현재까지 만들어진 컴포넌트를 스토리로 구성해보았습니다.

일전에도 스토리북에 관심을 가졌을 때, 이 페이지에서 컴포넌트를 확인하는 모습을 보았으나 기존에 만든 컴포넌트를 이쪽에서 어떻게 연동하는지가 궁금했었어요.

결과적으로는 샘플로 구성되어있는 스토리에서 확인했듯, 1 컴포넌트 1 스토리를 만들어야 하는 것이었어요. 그럼 2번 작업하는 셈이기 때문에 비용이 큰 것이 아닐까 싶었지만, 다행히도 기존에 만든 컴포넌트를 import하면 컴포넌트의 props가 자동완성으로 연결되어 작성하기 수월한 구조였습니다!
이제 Chat GPT가 넘겨준 코드가 진실인지를 검증해야하는 차례입니다. 스토리북 공식 문서에 들어가서 번갈아 대조하며 이해 하기 시작했어요.
막연히 a to z를 배워야한다고 생각했을 때는 장벽이 컸었는데, 실상 초벌 코드를 보고나니 쉽게 허물어졌어요. 학습과 실습을 동시에 한 셈이죠!
또한 학습 예제가 제가 만든 예제이기 때문에 재밌을 수 밖에 없었고, 학습의 몰입도가 높았습니다!

그렇게 어떤 흐름으로 만들어가는지 이해가 되었고, 계속해서 GPT와 함께 나머지 컴포넌트와 컬러에 대한 스토리를 만들었어요. 이제 진실을 판별할 수 있는 눈이 생긴 이상, 단순 노동은 저보다 빠르고 정확한 GPT에게 위임하는 것이 더 생산성이 높았습니다. 저는 잘못된 부분만 체크해주면 되는 것이죠.

그렇게 그럴듯한 스토리북 한판을 만들어냈습니다! 주어진 시간이 많지 않아 버튼만 넣으려 했었으나... 막상 첫 화면을 보니 살짝 정돈하게 되었어요.
디자인 시스템 작업자 입장에서도, 사용하는 팀원들 입장에서도 생산성이 높아지리라 생각합니다. 이미 저의 경우는 임의의 페이지에 import해서 확인하며 만들지 않아도 되니 너무나 간편했어요! 다른 팀원들도 모두 한 곳에서 동일한 코드, 컴포넌트를 보며 사용할 수 있으니 중복 생산의 우려도 줄어들 것이라 생각하고 있어요.
이제 함께하는 프론트엔드 개발자 동료들끼리 동일한 컬러, 아이콘, 컴포넌트 사용하는 환경이 만들어진 것입니다!

이전 이미지와 같이 스토리북은 로컬 서버를 이용하여 직관적으로 확인하기 좋은 환경을 제공하지만, 아직 배경이 없는 팀원들이 있을 수 있기 때문에, PR 코멘트를 이용하여 일종의 가이드 문서를 작성했습니다.
작업자 관점:Storybook 로컬 서버에서 간편하게 컴포넌트를 미리 보고 관리할 수 있습니다. 개발 중인 컴포넌트를 쉽게 테스트하고, 변경 사항을 즉시 확인할 수 있어 개발 효율성을 높입니다. 사용자 관점:Storybook에서 컴포넌트를 쉽게 확인하고, 이를 기반으로 의견을 나눌 수 있습니다. 코드와 디자인을 동시에 확인할 수 있어 커뮤니케이션을 보다 명확하게 하고, 이해도를 높일 수 있습니다.npm i(stroybook 의존성 설치)
script 실행
npm run storybook
Storybook 로컬 서버 경로인 http://localhost:6006/에서 디자인 시스템 확인
각 카드를 클릭하여 변수 이름을 복사해서 사용하실 수 있습니다.
각 props를 변경하며 시각적 변화와 소스 코드를 확인할 수 있습니다.
SCSS의 variables를 이용하여 Colorgraphy의 구성을 적용했습니다. 피그마와 연결하여 만약 컬러 코드에 변경이 있을 시 코드 단에서도 바로 연동이 될 수 있도록 하고 싶습니다.가장 큰 의의는 스토리북을 셋팅하는 것을 익혔다는 것이었어요. 또한 첫 시도 이후로 스토리북을 이용하여 컴포넌트를 만드는 방식에 적응이 되었어요. 컴포넌트를 생성하고 → 대응하는 스토리를 생성하고 → 스토리북에서 확인하며 개발을 완료하는 흐름, 즉1 컴포넌트 + 1 스토리가 익숙해진 것이죠.
무엇보다, 이번에 한번 경험 해보았기 때문에 다른 프로젝트에서도 디자인 시스템을 구성하고 스토리북을 만드는 과정까지 좀 더 익숙하게 해낼 수 있겠다는 자신감이 생긴 것에 의의가 컸습니다!

프로덕트 디자인을 하던 시절, 우리만의 멋진 디자인 시스템을 만드는 것을 동경했었어요. 항상 그 단계까지 못미쳐서 아쉬웠었는데, 이번에는 제가 직접 만들 수 있는 상황이 되어 몹시 뿌듯합니다!
이제 준비가 되었으니, 디자인팀과 멋진 디자인 시스템을 구축할 수 있는 상황이 되기를 기대합니다!!