[6월 TIL #10] 디자인 시스템 앞에서 자꾸 멈추는 이유

추진력이 좋은데, 왜 어떤 일은 잘 안 될까
오늘 재영 님과 커피챗을 했다. 여러 이야기를 나눴는데, 그중에서도 내 추진력에 대한 이야기가 기억에 남는다. 어제 회고에도 썼지만, 나는 어떤 일을 할 때 심리적인 장벽이 없어서 하는 것이 아니라 장벽이 있는데도 하는 쪽에 가깝다. 그런데 동시에 어떤 일은 이상하게 잘 밀어붙여지고, 어떤 일은 계속 우선순위 뒤로 밀린다.

다른 사람들을 보면서도 비슷한 생각을 할 때가 있다. “이건 그냥 하면 될 것 같은데 왜 안 하지?” 싶은 순간들이 있다. 그런데 그 사람에게는 그 사람만의 이유가 있을 것이다. 겉으로는 쉬워 보여도 실제로는 부담스럽거나, 우선순위가 애매하거나, 어디서부터 시작해야 할지 몰라서 딜레이되는 일이 있을 것이다. 나에게는 그게 디자인 시스템인 것 같다는 생각을 했다.

디자인 시스템은 좋은 의사결정의 모음인데
디자인 시스템은 결국 좋은 의사결정들을 모아놓는 일이다. 버튼은 어떻게 쓸지, 입력창은 어떤 상태를 가져야 할지, 모달은 어떤 구조를 가져야 할지, 여백과 컬러와 타이포그래피는 어떻게 정리할지에 대한 결정들이 쌓인 것이다. 그렇게 보면 디자인 시스템은 거창한 장식이 아니라, 제품을 더 일관되게 만들고 팀이 같은 기준으로 움직이게 하는 도구에 가깝다.

자료를 찾아보니 이 이해가 크게 틀리지는 않았다. NN/g는 디자인 시스템을 재사용 가능한 컴포넌트와 패턴으로 규모 있는 디자인을 관리하기 위한 표준이라고 설명한다. Figma도 디자인 시스템을 제품과 경험의 일관성을 유지하게 해주는 빌딩 블록과 기준의 묶음으로 설명한다. 결국 디자인 시스템은 예쁜 컴포넌트 모음이라기보다, 팀이 반복해서 같은 문제를 다시 풀지 않도록 돕는 공유된 기준에 가깝다.

그런데 나는 이 의사결정을 전부 내가 내려야 한다고 생각해서 더 부담을 느꼈던 것 같다. 사실 세상에는 이미 검증된 좋은 시스템들이 많다. 그런 시스템을 참고해서 쓰고, 거기에서 우리 제품에 맞게 조금씩 보완해가면 된다. 그런데도 막상 “디자인 시스템을 해야 한다”고 생각하면 일이 너무 커 보인다. 규모가 큰 일처럼 느껴지는 순간 시작하기가 어려워지고, 결국 당장 눈앞의 다른 일들에 밀리게 된다.

이게 꾸준히 할 수 있는 하네스가 없어서 더 그랬던 것 같기도 하다. TIL을 쓰듯이 아주 작게라도 계속 해왔다면, 처음 디자인 시스템의 중요성을 언급했던 시점부터 지금까지 무언가 꽤 쌓였을 것 같다. 하지만 이 일은 매일 조금씩 하게 만드는 구조가 없었고, 그래서 중요하다는 생각은 계속 있었지만 실제 행동으로 잘 이어지지 않았다. 최근에 검색 기능이 붙을 예정인데, 만약 디자인 시스템이 있었다면 훨씬 자연스럽게 붙일 수 있었을 것이라는 생각도 들었다.

내 고민은 꽤 일반적인 고민이었다
이 고민을 가지고 GPT와도 대화를 나눴다. 내가 궁금했던 것은 디자인 시스템이 정말 그로스 성과를 해칠 수도 있는지, 혹은 내가 괜히 무서워하는 것인지였다. 대화를 하면서 자료도 함께 찾아보니, 디자인 시스템에 장점만 있는 것은 아니었다. NN/g도 디자인 시스템은 만들고 유지하는 데 시간이 들고, 한 번 만들면 끝나는 것이 아니라 계속 진화해야 하며, 팀이 제대로 쓰려면 사용법을 알려주는 과정도 필요하다고 말한다.

Figma 역시 비슷한 이야기를 한다. 디자인 시스템은 일관성과 협업, 개발 효율을 높일 수 있지만, 지속적인 관리가 필요하고 효과가 늦게 나타나는 장기 투자에 가깝다. 당장의 프로젝트 목표와 충돌해 보일 수도 있고, 팀 안에서 이것을 실제로 쓰게 만드는 문화적 변화도 필요하다. 이걸 보고 나니 내가 괜히 겁을 먹은 것이 아니라, 이 일이 원래 초반 보상이 늦고 유지 비용이 있는 종류의 일이라는 생각이 들었다.

그래서 정리하자면, 디자인 시스템 자체가 그로스를 해치는 것은 아니다. 다만 너무 빨리, 너무 크게, 너무 경직되게 적용하면 오히려 방해가 될 수 있다. 전환에 중요한 화면을 단지 통일성만 보고 바꾸거나, 아직 검증되지 않은 컴포넌트를 모든 곳에 퍼뜨리거나, 실험 속도를 늦추는 방식으로 적용하면 문제가 될 수 있다. 반대로 잘 쓰면 반복 구현을 줄이고, 팀의 언어를 맞추고, 기능을 더 빠르게 붙일 수 있게 해준다.

실제로 Sparkbox에서 IBM Carbon 디자인 시스템을 사용해 진행한 작은 실험도 있었다. 8명의 개발자가 단순한 폼 페이지를 처음부터 구현했을 때와 Carbon 디자인 시스템을 사용했을 때를 비교했는데, 디자인 시스템을 사용한 쪽이 47% 더 빨랐다고 한다. 물론 샘플이 작기 때문에 이 수치를 절대적인 근거로 받아들이기보다는, 디자인 시스템이 반복 구현과 시각적 일관성에 도움을 줄 수 있다는 하나의 사례로 보는 편이 맞다.

이 답변과 자료들이 나에게 꽤 도움이 됐다. 나는 그동안 이 일을 못 하고 있다는 사실을 보면서 은근히 자책하고 있었다. 추진력이 좋다고 들으면서도, 왜 이 일은 계속 미루고 있을까 하는 생각이 있었다. 그런데 생각해보니 이 일은 내가 추진력이 없어서 못 한 것이 아니라, 당장 보상이 늦고, 범위가 크고, 의사결정을 혼자 떠안는 느낌이 강한 일이었다. 문제는 나의 성향 자체가 아니라, 이 일을 행동으로 바꿔주는 구조가 없었다는 데 있었다.

7일 동안 작은 결정들을 쌓아보기로 했다
그래서 내일부터 다음 주 수요일까지 딱 7일 동안 작은 챌린지를 해보기로 했다. 목표는 거대한 디자인 시스템을 완성하는 것이 아니다. 매일 하나씩 UI 의사결정을 저장해보는 것이다. 버튼 하나, 입력창 하나, 검색 결과 아이템 하나, 빈 상태 화면 하나여도 된다. 중요한 것은 “오늘 하나를 정리했다”는 감각을 만드는 것이다.

처음 며칠은 새로 만들기보다 현재 제품에 이미 존재하는 것들을 모아보는 데 집중하면 좋을 것 같다. 지금 우리가 버튼을 어떻게 쓰고 있는지, 입력창과 모달과 카드가 어떤 모양으로 흩어져 있는지, 로딩이나 empty state는 어떻게 처리하고 있는지를 먼저 보는 것이다. 그다음 검색 기능에 필요한 최소 컴포넌트만 골라 정리해보면 된다. 이렇게 하면 디자인 시스템이라는 큰 덩어리가 아니라, 당장 제품에 도움이 되는 작은 발판으로 느껴질 것 같다.

AI도 이 과정에서 잘 활용해보고 싶다. AI가 최종 의사결정을 대신 내려주는 것이 아니라, 내가 결정해야 할 덩어리를 작게 잘라주는 하네스가 될 수 있을 것 같다. 화면 캡처나 Figma를 보고 반복되는 컴포넌트 후보를 뽑게 하거나, 버튼 variant 이름을 제안하게 하거나, 검색 기능에 필요한 최소 컴포넌트 목록을 만들게 하는 식이다. 그러면 나는 처음부터 막막한 흰 화면 앞에 서는 것이 아니라, 이미 잘게 나뉜 후보들 중에서 선택하고 다듬는 일을 할 수 있다.

이번 대화를 통해 조금 마음이 가벼워졌다. 계속 우선순위에 대한 고민도 있었고, 왜 이 일은 잘 안 될까에 대한 답도 알고 싶었고, 사실은 자책하는 마음도 있었다. 그런데 오늘은 그 고민이 조금 해소된 것 같다. 해야 하는 일이 사라진 것은 아니지만, 적어도 어떻게 시작하면 되는지는 보이기 시작했다.

앞으로 가야 할 길은 여전히 있다. 디자인 시스템은 하루 만에 만들어지는 것도 아니고, 한 번 정리한다고 끝나는 일도 아니다. 하지만 지금 나에게 필요한 것은 완벽한 체계를 선언하는 것이 아니라, 매일 하나씩 좋은 의사결정을 저장하는 경험을 만드는 것이다. 내일부터 7일 동안 그 도전기를 해보고, 다시 가지고 와야겠다.

참고한 글: NN/g, Design Systems 101 / Figma, Design Systems 101: What is a design system? / Sparkbox, The Value of Design Systems Study