🙋 개발자 행사. FE CONF 2021-2. ⟪디자인 시스템, 그 다음은?⟫

📌 개발 공부 3개월 차인 to-be 개발자의 자습 blog🙂ﾠOct 24 ~ 30, 2021

이 발표를 본 이유

FE 개발자 지망생으로서 관심이 가는 주제가 많았다. 예를 들면

• Component, 다시 생각하기
• 상태 관리, 이제 Recoil 하세요
• Webpack 5 Module Federation으로 Mirco-frontends 운영하기
• 왜 나는 React를 사랑하는가
• SWC와 Web 개발의 미래
• Saas를 넘어 Daas, Monitoring을 위한 Dashboard

등등 아직 실무자로서 경력이 없는 내 입장에선 당연히 하나같이 알아야 할 것 같은, 공부해야 할 것 같은 주제들이었다. 하지만 그 많은 주제 중에서 이 내용에 이목이 끌린 이유는 'design system'이 이전 회사에서 많이 들어봤던 keyword였기 때문이다. 몇 해 전 내가 다녔던 회사의 design 부서에서 만들고 싶다고 한 게 바로 이 design system이었데, 결국 내가 퇴사할 때까지 원하는 만큼 완성하지 못한 걸로 알고 있다. 난 유관 부서 소속이 아니었기 때문에 그 배경과 이유는 잘 모르지만 같은 운영진으로서 생각되기로 사용자에게 더 나은 제품을 선보일 수 있는 기회가 미루어진 것 같아 아쉬웠다.

내가 이해한 design system은 단순히 UI에 일관성을 부여하고 작업 속도를 올릴 수 있다는 정도인데 이 design system이라는 게 무엇이며, 어떤 특징이 있고, 특히 이전 회사에서는 design 부서에서 주도했던 일이 TOSS에선 어떻게 개발자가 발표할 수 있을 정도로 개발과 밀접한 일인지 궁금했다.

/ / BROADEN YOUR EXPERIENCE / /

발표 들으면서 한 Memo

주제 : Do more, with less. 디자인 시스템, 그다음은?

발표 : 이병철 님

영상 : link

" Workflow Revolution : Front-end System Engineering "
" Maker의 유일한 병목이 '상상력'이 되게 한다. "

소감

우선 직함명이 UX Engineer이다. 일반적으로 쓰이는 이름인 Web Front-end Developer가 가지고 있는 의미 중 그 목적이 되는 사용자를 강조하기 위함인까. 아무튼 '사용자의 경헝을 설계한다.'라... 멋있다!

'design 부서가 design system을 만들면 designer도 개발자도 일하기 편하다.' 이 정도로 짐작했을 뿐 design system을 이렇게 양 team이 밀접하게 협업해서 만들 수 있는 과제인지 몰랐다. operator로서 일할 땐 Moments of truth가 내가 일할 때 수시로 상기하는 slogan같은 거였는데 design system에서는 흩어져있는 source를 design system 하나로 개편하는 *Single Source of Truth라는 것을 알게 되었다.

*data의 사본이 존재할 가능성이 없어서 원천이 되는 data를 갱신하면 그 data를 사용하는 system 전체에 변경 사항을 빠짐 없이 반영할 수 있음

이를 통해 UI에 통일감이 있고 일관성이 생겨 제품을 사용하는 사용자 경험에 긍정적인 영향을 주고, 업무에서 발생할 수 있는 막힘이 해소되는 효과가 있다고 한다.
운영팀에 있을 땐 설계하는 거라고 이해하고 딱히 찾아보지 않았는데 어떻게 설계하는지 개념을 알게 되

개인적으로 재밌었던 점은 발표자가 예전 TOSS의 UI를 보여주었을 때였다. 개인적으로 TOSS를 사용하면서 느낀 것이 UI가 참 깔끔하고, 명확하고, 세련됐다고 생각해왔는데 TOSS도 초창기엔 시행착오가 있었구나 하는 생각에 일종의 친근감이 느껴졌다. 동시에 이전 회사에서 제품의 UI 변천사가 떠올라 괜히 뭉클하기도 하고 이 service도 design system을 잘 구축했으면 design 부채도 줄이고 개발 조직의 생산성 향상에도 도움이 될 수 있었겠다는 생각에 다시 한번 아쉬웠다.

그런데 정말 놀라운 점은 이 다음이었다. design system을 만들어낸 것도 놀라운데 이것을 사용해보고 겪은 시행착오를 feedback 삼아 design system을 개선했고, 이 과정에서 tool을 직접 만들었다고 한다...! 완전 대단...!!!

design system을 통해 개발하면서 다음의 세 가지 문제에 봉착했다고 한다.

1. code를 design에 일치시키기가 어려움 (문구가 길어지는 등 예상치 못하게 design에 변경이 생기기도 하는데 이러한 변수를 design 단계에서 예측하고 준비해두기 어려움)
2. designer와 개발자가 소통할 때 서로의 언어를 기억해가며 소통해야 하는데 이 부분이 쉽지 않음 (visual 중심의 designer 언어와 기능 중심의 개발자 언어가 다름 e.g. "red" vs "warning")
3. design system의 엄격함과 유연함 사이에 균형을 찾기가 여러움

이렇게 문제점을 나열한 후 "우리는 이 녀석들을 더는 그대로 둘 수 없었어요🤨 (단호)" 이렇게 말씀하시는 대목에서 웅장함이 느껴졌다ㅎㅎ

이 중 두 번째가 앞서 언급한 놀라운 점이다. 즉 TOSS는 자체적으로 design handoff를 만들어 design에서 즉시 code를 볼 수 있게 하였다. 그래서 design을 보며 개발에 필요한 component 속성을 찾아 헤매지 않아도 되고, 여기에 더해 어디까지가 design system을 기반으로 한 design이고 어디까지가 custom으로 만든 건지 확인할 수도 있으며, designer와 개발자가 각자의 언어로 볼 수 있게 하였다.

내가 operator로서 일할 땐, team 내에서 자체적으로 tool에 가까운 효율화를 만들어내기엔 어렵고, 개발 조직과 협업해서 만들기엔 resource가 부족했으며, 결국 잘 만들어진 tool을 금액을 지불하고 사용하는 것이 최선 아닌 최선이었는데 이렇게 tool을 직접 만들어내는 곳이 있다니 정말 놀랍다. 이런 과정에서 React같은 게 나오는 건가?

아직 이전 회사에 소속감이 큰 상태에서 이런 발표를 보고 있자니 감탄스럽고, 많이 부러웠다.

FE CONF 2021

발표자 lineup
공식 YouTube