여러 구직 사이트를 돌아다니다 보면 취업 외에 얻을 수 있는 것들이 많다는 것을 느낀다.
나 같은 경우는 어떤 일을 하고 싶다는 뚜련한 업종이 없었는데 구경(?)하다보니 나 이런 쪽에 일을 하고 싶었구나! 라는 흥미가 생기는 글들이 많다. 또한 내가 부족한 영역 그리고 기존 프로젝트에서 어떤 걸 더 발전시켜야 할지 알게 된다.
나는 사용 목적이나 목표를 모르면 머리에 아예 들어가지 않고 기억도 나지 않는 고지식한(?) 사람이라..
🍋 왜 사용하는가?
목적1 : 재사용 가능한 UI + 매뉴얼
Storybook은 컴포넌트를 독립적으로 관리하고, props 조합별 상태를 한눈에 볼 수 있게 해준다고 한다. 덕분에 디자인 시스템이나 공통 UI를 만드는 프로젝트에서는 자연스럽게 개발 → 문서화 → 검증 → 공유의 흐름이 만들어진다고 한다.
최근 프로젝트에서는 디자이너가 따로 없어서 프론트엔드가 직접 디자인까지 맡았다.
처음부터 “공통 컴포넌트로 만들기 쉬운 구조로 디자인하자”는 의도로 진행했는데,
한 60% 정도는 의도한 대로 잘 돌아갔다는 느낌이었다.
그래서 이번에는 Storybook을 활용해 컴포넌트를 리팩토링하면서
처음에 세웠던 구조를 더 체계적으로 다듬어볼 계획이다. 디자인과 개발의 경계가 명확하지 않은 프로젝트일수록, 이런 도구가 얼마나 큰 도움이 되는지는 실감해볼 예정..
목적2 : 디자이너와의 소통
나의 얕은 경험 중에서도 기획/디자이너가 따로 존재했던 프로젝트가 있는데 정적인 디자인을 보고 유추를 해야하는 경우가 많았다.
버튼 클릭하면 모달이 뜨는데 닫기 버튼이 없을 때 모달 바깥 영역을 클릭해야 닫히는지 아닌지부터 해서..드롭다운 메뉴가 hover로 열리는 건가 click으로 열리는 건가? 폼에서는 유효성 검사 실패 시 에러 메세지가 어디에 어떻게 어떤 식으로 뜨는거지? 스크롤 내렸을 때 어떤 요소에 동적인 기능을 넣어야 하지? 등등 피그마에 댓글 달기를 하고 확인하고 달고 확인하고.... 했던 적이 있다.
아무리 글로 세세히 전달해도 막상 서로 구현 했을 때 보여지는 모습이 다를 수 있으니 적어도 정적 디자인 보다는 행동·상태·맥락 공유가 가능한 살아있는 컴포넌트를 보여주는게 직접 보고 검증 받기 쉽다.
참고 아닌 보다는 필독.. : Storybook의 유용함
