기획, 디자인, 프론트, 백엔드가 동시에 프로젝트를 진행하다 보면 기능 구현보다도 UI 주변에서 새는 시간이 훨씬 많다는 걸 체감하게 된다.
“이 버튼 hover는 어떻게 되기로 했지?”
“모달 padding이 왜 페이지마다 달라?”
“여기서는 괜찮은데 저 페이지에서만 깨지네…”
팀 프로젝트를 몇 번 해보면서 느낀 건, 이런 문제들이 발생하는 이유가 협업 구조가 정리되지 않았기 때문이라는 점이었다.
앱잼을 준비하면서 나와 Comfit팀은 “이번에는 그냥 빨리 만드는 게 아니라, 덜 소모되게 만들고 싶다”는 생각을 했다. 그 고민의 결과가 Storybook 도입이었다.
개인 프로젝트에서는 페이지 단위로 UI를 만들어도 큰 문제가 없다. 하지만 팀 프로젝트에서는 화면 수가 늘어날수록 비슷한 UI들이 여기저기에서 복제되기 시작한다.
기존에는 보통 이런 흐름이었다. 페이지 하나를 만들고, 그 안에서 버튼이나 카드, 모달을 바로 구현한다.
그러다 “이거 다른 데서도 쓰겠네?” 싶으면 그때서야 컴포넌트를 분리한다.
문제는 이 방식에서는 UI의 기준점이 항상 페이지라는 점이다.
컴포넌트가 페이지 안에 섞여 있으면 이게 공용인지, 어디까지 책임져야 하는지, 어떤 상태까지 고려해야 하는지가 계속 애매해진다.
그래서 우리는 UI를 코드로 관리할 수 있는 명확한 기준점이 필요했고, 그 역할을 Storybook이 해줄 수 있다고 판단했다.
Storybook을 도입하면서 기대한 변화는 아주 거창하지 않았다. 다만 흐름을 이렇게 바꾸고 싶었다.