최근 디자인 시스템 작업을 하면서 Storybook을 다시 정리했다.
처음에는 이미 Storybook도 있고, 컴포넌트별로 기본 상태나 Light/Dark 상태도 어느 정도 확인하고 있으니까 부족한 Story만 조금 추가하면 될 거라고 생각했다.
근데 멘토링 기준이랑 지금 있는 Storybook을 같이 보니까 애매한 부분이 있었다.
컴포넌트가 구현되어 있고 Storybook에서 보인다고 해서, 그 컴포넌트를 충분히 확인한 건 아니었다. 어떤 컴포넌트는 상태를 바꿔 볼 수 있었지만 어떤 컴포넌트는 안 됐고, 어떤 상호작용은 play로 확인하고 있었지만 어떤 건 그냥 눈으로만 보고 있었다.
그래서 처음에는 “Story가 부족한가?” 정도로 생각했다.
근데 계속 보니까 Story 몇 개를 추가하는 문제보다, 디자인 시스템 작업에서 Storybook을 어디에 두고 어떤 기준으로 봐야 하는지 정리하지 않았던 문제에 더 가까웠다.
Figma와 실제 화면 사이
디자인 시스템 작업을 하면서 Figma에서 상태와 구조를 정리하고, 실제 컴포넌트에도 반영하고 있었다.
근데 Figma에서 버튼의 상태를 정했다고 해서 실제 코드에서도 같은 상태가 다 확인되는 건 아니었다. 반대로 컴포넌트 코드가 있다고 해도, 그게 디자인에서 정한 상태를 모두 표현하는지 바로 알기는 어려웠다.
처음에는 Figma를 보고 바로 Production 화면에서 확인하면 되는 거 아닌가 생각했다.
근데 실제 화면은 route, 데이터, Relay, cache, 권한 같은 것들이 다 같이 얽혀 있다. 버튼 하나의 pressed나 disabled 상태를 보려고 해도 화면 전체를 띄우고 데이터를 준비해야 하는 경우가 생긴다.
그러다 보니 디자인 기준을 확인하는 작업과 실제 제품 흐름을 확인하는 작업이 섞이게 됐다.
그래서 Storybook을 그 중간에 두는 게 필요하다고 생각했다.
Figma에서 정한 컴포넌트 상태를 실제 Production 컴포넌트로 먼저 확인하고, 그다음에 실제 화면에 조립해서 데이터와 navigation까지 확인하는 식이다.
Storybook이 제품 화면을 대체하는 건 아니지만, 적어도 디자인과 코드가 같은 기준을 보고 있는지 확인하는 단계는 될 수 있을 것 같았다.
기존 Storybook도 계속 쓰고 있었는데
기존 Storybook이 비어 있었던 건 아니다.
컴포넌트별 Story도 있었고, interaction을 확인하는 play도 있었고, theme이나 viewport 같은 공통 설정도 이미 있었다.
문제는 기준이 한 곳에 정리되어 있지 않았다는 거였다.
어떤 Story는 기본 상태를 보여주고, 어떤 Story는 Playground처럼 props를 바꿔 볼 수 있고, 어떤 Story는 테스트 역할까지 같이 하고 있었다. 파일도 실제로는 flat하게 놓여 있는데 title은 계층적으로 되어 있어서, 새 Story를 추가할 때 어디에 두는 게 맞는지 조금씩 고민하게 됐다.
특히 규모가 큰 Story는 하나의 파일 안에서 여러 역할을 같이 하고 있었다.
처음에는 큰 Story를 전부 잘게 나눠야 하나 싶었다. 근데 그건 또 너무 큰 작업이었다. 이미 있는 검증을 괜히 흔들 수도 있고, 파일을 많이 쪼갠다고 기준이 생기는 것도 아니니까…
그래서 이번에는 기존 Story를 전부 다시 만들기보다, 어떤 역할인지 먼저 나누는 쪽으로 갔다.
Foundations, Components, Patterns, Screens처럼 찾기 쉬운 구조를 만들고, 기본 상태를 보는 Story와 조작해 보는 Playground, 테스트에만 필요한 Story를 조금씩 구분했다.
Playground가 있으면 테스트도 같이 바뀌어야 했다
Tabs Playground를 정리하면서 이 부분이 좀 더 확실하게 느껴졌다.
처음에는 탭 라벨이 고정되어 있었는데, Playground에서 라벨을 바꿔 볼 수 있도록 Controls를 추가했다.
근데 기존 play 테스트는 여전히 고정된 라벨을 기준으로 탭을 찾고 있었다.
사용자가 Playground에서 라벨을 바꿨는데 테스트는 예전 문자열만 찾고 있으면, 같은 화면을 보고 있는 게 아닌 것 같았다.
그래서 테스트도 Story의 args를 기준으로 동작하도록 바꿨다.
이걸 하면서 Controls는 그냥 편하게 값을 바꿔 보는 기능은 아니라는 생각이 들었다. 바꿀 수 있게 열어둔 값이면, 그 값이 바뀌어도 기본 동작이 유지되는지 같이 확인해야 했다.
반대로 모든 테스트를 Playground에 넣는 것도 맞지는 않았다.
일반적인 interaction은 Playground의 play에서 확인하고, timer나 fallback, lifecycle처럼 조금 더 특수한 상태가 필요한 경우만 test Story로 분리하는 쪽이 나았다. Light/Dark도 매번 Story를 따로 만들기보다 toolbar와 decorator로 확인할 수 있게 두는 편이 더 단순했다.
Storybook에서 확인했다고 끝난 건 아니었다
이번 작업을 하면서 가장 조심해야겠다고 생각한 건 Storybook을 너무 크게 보는 거였다.
Storybook에서 실제 컴포넌트를 렌더링하고, 상태와 interaction을 확인할 수는 있다. 근데 그게 실제 route에서 데이터가 바뀔 때도 같은지, Web과 Native에서 focus나 keyboard, screen reader가 제대로 동작하는지까지 증명해 주는 건 아니다.
Figma에서 화면을 정리했다고 runtime 구현이 끝난 게 아닌 것처럼, Storybook에서 상태를 확인했다고 제품 검증이 끝난 것도 아니다.
그래도 이전보다 조금 나아진 점은 있다.
디자인 시스템 작업을 하면서 Figma, Storybook, Production 화면을 전부 한 번에 끝내야 하는 큰 작업으로 보지 않고, 각각 어디까지 확인하는 단계인지 나눠서 보게 됐다.
아직 모든 컴포넌트에 같은 기준이 적용된 건 아니고, 앞으로 Story를 추가하면서 또 바뀔 수도 있다.
그래도 이제는 Storybook을 단순히 컴포넌트를 예쁘게 보여주는 곳으로만 보지는 않게 됐다. 디자인에서 정한 상태가 실제 컴포넌트에 있는지, 그리고 그 상태가 바뀌어도 기본 동작이 유지되는지 확인하는 중간 단계에 더 가까운 것 같다.
정리
- Figma와 Production 화면 사이에 실제 컴포넌트를 확인하는 단계가 필요했다.
- Storybook은 화면 구현을 대체하는 곳이 아니라 공용 UI를 먼저 확인하는 곳에 가까웠다.
- 기본 Story, Playground, test Story는 같은 역할이 아니었다.
- Controls로 바꿀 수 있는 값은 play 테스트도 같은 기준으로 봐야 했다.
- Storybook에서 확인한 것과 실제 Web/Native runtime에서 확인해야 하는 것은 구분하기.