바닥부터 만드는 디자인 시스템 (part.2 개발자편)
안녕하세요 넥스트유니콘 프론트엔드 개발자 Ryan입니다. 개발자로서 UX와 프로덕트 개선에 더 집중할 수 있어서 디자인 시스템 구축은 정말 효과적이었는데요! 바닥부터 넥스트유니콘 고유의 디자인 시스템을 만들어간 이야기를 공유 드립니다.
어쩌다가 만들었지?
웹 개발이 너무 힘들고 재미가 없어서 관심을 가지게 됐던거 같아요. 비슷해 보이는 디자인 요소를 재활용하는게 어려워서 힘들었던거 같아요. 비슷해 보이는 디자인을 컴포넌트로 재활용하려고 하면, 플래그가 너무 많이 들어가서 알아보기 힘든 코드가 되곤 했어요. 매번 스프린트를 할 때마다 똑같은 일을 하는 것처럼 느껴졌어요. 권태로워지기 쉬운 때였던 것 같아요. 우연히 Brad frost의 atomic design 책을 읽고 웹 개발을 힘들게 하는 문제들을 탐구 했어요. 좋은 책 하나 건졌다고만 생각하고 있었는데, pxd에서 나온 디자인 가이드/디자인 시스템은 왜 필요한가라는 블로그를 보니 atomic design이 디자인 시스템 역사에서 꽤 중요한 위치에 있는 것 같아요.
책을 읽고 웹 개발을 힘들게 하는건 반복 작업만이 아니라는 걸 알게 됐어요.
출처: https://atomicdesign.bradfrost.com/table-of-contents/
이렇게 많은 기기들을 다 대응해야된다는걸 심각하게 생각하지 않고 있었던 것 같아요. 모니터 스크린, 티브이, 게임 콘솔, 태블릿, 냉장고에 딸린 스크린까지 다 지원해야된다는 것도 책에 나와 있어요. 티브이나, 게임 콘솔 같은건 지금 대응하고 있지 않지만 웹 개발의 어려움을 느끼는데 더 도움이 됐던거 같아요. 다양한 브라우저를 대응해야하는 것도 문제라고 다시 생각하게 됐어요. atomic design은 이 어려움들을 해결하기 위해서 modularity를 이용하라라고 말하는 것 같아요. modularity를 이용하면 디자인팀과 같은 용어를 쓸 수 있어요.
출처: https://atomicdesign.bradfrost.com/table-of-contents/
atomic design은 디자인 시스템을 협력과 소통으로 만드는거라고 말하는 것 같아요. 디자인을 모듈화하기 위해서 디자인팀과 얘기하기 시작했어요.
디자인 시스템을 만들면서 힘들었던게 뭐였더라?
앞으로 어떤 디자인으로 일할지 정하는건 그 동안 다음 스프린트만 바라보면서 일해오던 방식과 근본적으로 다른 일 같았어요. 이전에 생각해오던 방식과 다른 방식으로 생각할 필요가 있을것 같았고, 생소했던 것 같아요. 이런 방식이 이전에 일하던 방식보다 더 재밌어요. 저는 디자인을 하고 있지 않고 있어서, 앞으로 어떤 디자인으로 일할지 정하는 일에 별로 도움이 되지 못했어요.
일관성?
modularity 개념을 이용해서 일관성 있는 유아이를 만들면 좋겠다고 생각했어요. atomic design을 읽으면서 유저가 같은 기능을 쓸 때 비슷한 유아이 배치를 보고, 비슷한 유아이를 쓸 수 있으면 덜 혼란스럽겠구나 생각했어요. 되돌아보면 일관성 없는 사이트를 방문할 때마다 모든게 의심스러웠던 것 같아요. 이 회사… 내 개인 정보는 똑바로 관리하고 있을까?…
프론트엔드 개발자가 직접 일관성 있는 화면을 만드는건 아니지만 일을 할 때 왜 하는지 아는 것과 모르는건 차이가 있을 것 같아요.
어떻게 구현했더라?
디자인팀에서 디자인을 모듈화해서 주셨어요. 디자인을 받고 제일 먼저 했던건 css와 javascript를 나누는거였어요. css에서 문제가 생기면 css를 바로 볼 수 있게 자바스크립트가 들어가는 파일 이름 뒤에 컴포넌트 이름을 붙여서 css와 javascript를 분리했어요.
평소에는 스타일과 자바스크립트를 한 파일에 놓고 써요. 하지만 이번에는 기능을 확장할 때 기존 코드를 건드리지 않고, 확장할 수 있는 구조, 수정이 있을 때 예상하지 못한 버그를 만들지 않는 구조를 만들기 위해서 나눠야겠다고 생각했어요. 스타일과 자바스크립트 사이에 경계를 그었습니다. 그래서 분리된 비지니스 로직이 들어가는 파일이 필요하면 그냥 새로 만들고 분리해놓은 스타일을 넣을 수 있게 만들었어요. BEM을 이용해서 독립적인 것 (Block)을 개념화 해뒀기 때문에 새로운 파일이 필요하면 기존 코드를 건들 필요 없이 Block을 그냥 불러와서 만들 수 있게 만들었어요.
지금 이 시점이 아니라 앞을 보고 이렇게 경계를 그었어요. 앞으로 어떤 형태로 컴포넌트를 만들더라도 기존 컴포넌트들에게 영향을 주지 않고, 다 수용할 수 있게요. 저에게 앞으로 어떤 요구사항이 올지는 알 수 없다고 생각해요. 지금 요구 사항이 어떻게 바뀔지 모른다는 사실은 맞고 틀리고하는 문제도 아니고, 틀린게 아니라 의견이 다른 것도 아니라고 생각해요. 시간이 지나면 계절이 바뀐다는 받아들여야만 하는 사실처럼요. 계절이 바뀌는걸보고 그것이 맞냐 틀리냐 하는 사람은 없는 것처럼요.
개인적으로 디자인 팀과 약속한 디자인 요소 자체는 경계 건너, 스타일에 있다고 생각해요. 경계를 긋고보니 스토리북에서 제시한 경계
“디자인 시스템은 순수해야 하고 프레젠테이션 컴포넌트만을 포함해야 합니다. 이들은 props에 대해서만 변화하고, 어떠한 비즈니스 로직을 포함하지 않으며, 데이터 로드 방식에 구애받지 않아야 합니다. 이는 컴포넌트를 재사용하기 위해서 필수적으로 지켜야하는 속성입니다.”
출처: https://storybook.js.org/tutorials/design-systems-for-developers/react/ko/architecture/
보다 더 스타일쪽을 향해서 그은것 같아요.
스토리북에서 제시한 Presentational and Container Components 이라는 글에서 저자는 이 시점에서 더 이상 이런식으로 나누는걸 원하지 않는다고 서두에서 밝혔지만, 아직 글을 쓸 때 활용했던 아이디어 자체는 유용한 것 같아요. Presentational components에 Are concerned with how things look, Have no dependencies on the rest of app 같은 아이디어요. 스토리북에서 말하고 싶은 바도 이런 것 같아요.
그리고 BEM을 이용해서 css를 구조화했어요.독립적인 것, 재활용할 수 없는 것, 외형을 바꾸는 것을 나눴어요.
출처: http://getbem.com/introduction/
독립적인 것(block)으로 작은 요소에서 큰 요소를 만들 수 있어서 좋은 것 같아요. 재활용할 수 없는 요소 (element)는 디자인 요소들이 어지럽게 재활용되서 변경하기 힘든 스타일 구조를 만드는걸 막아줄 수 있을 것 같아서 마음에 들었어요. 외형을 바꾸는데 사용하는 modifier도 모듈을 구현하고 보니 코드가 단순해 보여서 흡족했어요. BEM으로 구조화하고 보니 디자인을 세부적인 요소가 아니라 Block으로 볼 수 있어서 코드를 인터페이스처럼 내부를 생각하지 않고 Block 그 자체로 단순하게 생각할 수 있었어요.
코드는 이 아이디어를 스타일드 컴포넌트로 구조화한 선각자가 있어서 대부분 따랐습니다. Alan B Smith의 Structuring our styled components 시리즈에서 잘 소개되고 있어요.
디자인 시스템과 직접적인 관계는 없지만, 한번 모듈을 만들면 광범위하게 사용될 것 같아서 변경하기 쉬운 구조를 만드는게 중요할 것 같다고 생각했어요.
앞으로는?
저는 스토리북에서 말하는 것(https://storybook.js.org/tutorials/design-systems-for-developers/react/ko/introduction/) 처럼 디자인 시스템이 모든 문제를 해결해준다고 생각하지 않아요. 저도 스토리북이 말하는 것처럼 소규모 서비스라면 인프라를 구축하는 대신 그냥 자주 쓰이는 컴포넌트를 모아 놓은 폴더를 쓰는게 더 생산적이라고 생각해요. 하지만 앞으로 더 커질 서비스를 생각하면, 인프라를 구축해야할 거 같아요. 지속 가능하게요.
디자인 시스템을 지속 가능하게 해주는 요소들로는 문서화, 테스트, 디자인 시스템 컴포넌트 설계 원칙, 배포 시스템 같은게 있는 것 같아요. 이 요소들을 지원해주는 플랫폼은 스토리북이 유일한 것 같아요. 디자인 시스템으로 잡아야하는 건 modularity 뿐만이 아닌거 같아요, 디자인 시스템은 pxd(디자인 시스템 1편 — 디자인 가이드/디자인 시스템은 왜 필요한가)에서 말하는 것 처럼 UI, UX 가이드라인, UI 패턴, 디자인 원칙을 포괄하고 있어요.
광범위한 영역을 커버하고 있는… 대기업의 디자인 시스템들..
출처: https://story.pxd.co.kr/1435
이를 위해서는 문서화는 필수인 것 같아요. 위에서 일관성에 대해서 업급했는데요. 일관성이 필요한 곳은 UI 패턴만이 아닌거 같아요. 예를 들면, 브랜드에도 일관성이 필요한거 같아요. 브랜드를 느끼게 해줄 수 있는 UI 요소가 일관성이 없으면 유저가 혼란을 느끼고 서비스 자체를 신뢰할 수 없을 것 같아요. UI, UX 가이드라인, UI 패턴, 디자인 원칙을 코드에 담을 수는 없을 거 같아요. 이 모든걸 코드와 가까운 곳에 문서화할 필요 없다고 생각해요. 하지만 예를 들어서 어떤 간격으로 모듈을 배치할 것인지 같은 약속처럼 코드와 가까운 것들은 스토리북에 문서화를 하는 것이 바람직한 방향인 것 같아요.
출처: https://story.pxd.co.kr/1467
스토리북에 UX 가이드라인, 디자인 원칙 등을 문서화할 수 있다는 건, 프론트엔드 개발자를 좀 더 능동적으로 일하게 만든다는 걸 의미하는 것 같아요.
front-end developers are often relegated to crude production machines that are brought into the project only after all the design decisions are made.
This is a huge mistake. Including front-end development as a critical part of the design process requires changes to both project structure and team members’ mentalities.
출처: https://atomicdesign.bradfrost.com/chapter-4
물론 brad frost는 모션, 성능, 인터렉션 같은 요소가 다 디자인에 포함되기 때문에 위 글과 같은 주장을 하는것이지만, 디자인 원칙이나 UX 가이드라인 같은 것도 프론트엔드 개발자가 컴포넌트와 같이 보면서 더 빨리 더 자주 디자인 의사 결정에 참여할 수 있다면 더 능동적으로 일하는것이 아닌가 싶어요.
테스트를 위해서도 스토리북 도입이 필요해보여요.
출처: https://storybook.js.org/tutorials/design-systems-for-developers/react/ko/test/
수정이 필요할 때 컴포넌트 상태를 일일이 확인하기 어려울 것 같아요. 그림에 나와있는 화면 대응이나 접근성 대응은 포기한다고 하더라도, 컴포넌트가 구성하는 컴포넌트도 경우의 수가 충분히 많기 때문이에요. 버그 때문에 필요하게된 수정이 더 많은 버그를 만드는건 아닌지 확인할 수 있어야할거 같아요.
출처: https://storybook.js.org/tutorials/design-systems-for-developers/react/ko/test/
버그 때문에 어떤 수정이 더 많은 버그를 만든다면, 오히려 가만히 있는게 더 나을 것 같아요. 테스트를 위해서라도 스토리북이 제시하는 시각적 테스트를 활용할 필요가 있을거 같아요.
앞으로 확장될 서비스 규모를 생각하면 스토리북 (https://storybook.js.org/tutorials/design-systems-for-developers/react/ko/architecture/)에서 말하는 것처럼 디자인 시스템을 모든 프로젝트로부터 독립적으로 사용할 수 있어야할 것 같아요. 스토리북에서 말하는 것처럼, 하나의 앱을 서비스하는게 아니라 전체 조직에서 사용할 수 있는 시스템을 구축해야하기 때문이에요. 디자인 시스템을 독립적으로 사용하기 위해서도 스토리북을 활용할 필요가 있을 것 같아요. 디자인 시스템을 마치 npm 디펜던시처럼 사용할 수 있도록 테스트부터 문서화, 배포까지 정말로 괜찮아보이는 솔루션을 제시하기 때문이에요.
디자인 시스템을 만날 수 있었던걸 감사하게 생각해요. 디자인 시스템을 만나지 못했다면 코드만 볼 줄 아는 코드에 갇힌 개발자가 됐었을 것 같아요. 디자인 시스템을 만난 후로 제 시야가 디자인이나 브랜딩, 소통 같은 곳까지 넓어졌어요. 아직 아는건 별로 없지만, 디자인이나 브랜딩 같은것 까지 관심을 가질 수 있게 된것에 대해서 감사하게 생각해요. 또, 디자인 시스템을 작게나마 만들면서 협업이 얼마나 중요한지도 알게 됐어요. 디자인 시스템은 협업하지 않는다면 디자인 시스템의 단 1퍼센트도 만들수 없다는 걸 경험으로서 알게 됐어요. 개발자들과 디자인 시스템을 개발하는데 도움을 준 디자인팀이 없었다면 코드를 한 줄도 짤 수 없었을 거에요. 협업이 중요하다는 사실은 저도 사람인지라 자주 까먹고 매번 실수 하곤 합니다. 어느날 아침에 갑자기 도가 트여서 협업왕 개발자가 되면 좋겠어요. 더 깊게 공부해서 더 깊이 있는 개발자가 되고 싶어요. 주저리 주저리 긴 글 읽어주셔서 감사합니다.
참고한 글?
https://storybook.js.org/tutorials/design-systems-for-developers/react/ko/introduction/
https://brunch.co.kr/@thinkaboutlove/320
https://atomicdesign.bradfrost.com/table-of-contents/
https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0
https://alanbsmith.medium.com/structuring-our-styled-components-part-i-2bf21fa64b28
http://getbem.com/introduction/
https://kentcdodds.com/blog/aha-programming/
