우리가 카지노 쿠폰을 처음부터 다시 만드는 이유
멀티브랜드 조직의 카지노 쿠폰 제작기
배경 : 카지노 쿠폰이 필요해
팀스파르타의 프로덕트 디자이너는 총 6명으로, 파트별로 프로덕트를 맡아 화면을 그리고 있어요. 1명 이상의 디자이너가 같은 프로덕트를 보는 파트도 있고, 하나의 파트에 프로덕트도 여러 개인 경우도 있습니다. 다양한 프로덕트를 여러 명의 디자이너, 개발자가 따로 맡아서 작업을 하다 보니 모두에게 비슷한 문제가 생기기 시작했어요.
- 여러 디자이너가 동시에 다양한 프로덕트의 화면을 작업하니사용하는 컴포넌트의 성격은 동일한데, UI가 비슷하면서도 통일되지 않는다.
- 사용하지 않는 컴포넌트 코드가 쌓인다.
- 디자이너와 개발자의 비효율적인 반복 작업이 계속 생긴다.
- 통일성이 떨어지는 UI 때문에 이미 개발되었던 컴포넌트를 다른 개발자가 다시 만드는 상황이 많다.
위와 같은 문제가 지속되자 디자이너와 개발자 모두가 그 필요성을 느껴 디자인시스템 구축이 시작되었습니다.
문제 1 : 명확한 DRI가 없다
디자인시스템은 매주 있는 디자인팀 내에서 주간 회의를 통해 천천히 구축하기 시작했어요. 그동안의 디자인시스템 주간회의는 다음과 같이 진행되었어요.
이번 주에 할 컴포넌트 작업 또는 개발 가이드 작성 [항상]
작업 중 필요한 의사결정 [항상]
새 아이콘 컴포넌트 추가 논의 (a.k.a 아이콘 심사대) [가끔]
모두 메인 프로덕트의 업무로 매주 리소스가 꽉 차있었기 때문에 디자인시스템은 주간 회의를 통해 작업하는 것이 전부였어요. 하지만 주 1시간으로는 진행에 박차를 가하기 어려웠죠. 기억 속 저 먼 곳으로 떠나고 있었던 지난주에 진행한 작업의 맥락을 다시 파악하는 것만으로도 충분하지 않은 시간이었으니까요. 심지어 6명이 동시에 작업을 진행하면 작은 의사결정에도 너무 많은 시간이 소요되었죠.
뿐만 아니라 개발자는 그때그때 업무에 틈이 나는 개발자 분을 배정해 주신 후에 개발이 진행되는 방식이어서 어떤 분과 소통을 해야 할지 파악하기 어려웠어요.
문제 2 : 공장식 프로세스는 혼란스럽다
디자인이 완료되면 개발 요청 가이드를 작성하고, 가이드를 전달받은 개발자가 개발을 진행했어요. 함께 의논하는 것이 아닌 공장식으로 전달받는 프로세스였죠. 결국 디자이너는 실제로 어떻게 구현이 될지 예상하지 못했고, 프론트 개발자는 디자인 의도에 대한 이해 없이 개발을 착수했어요. QA를 할 때가 되어서야 이런 대화가 오고 갔어요.
프로세스 앞 단계에서 개발자와 디자이너가 시스템의 목적과 역할을 다르게 이해하고 있어도 서로 알 길이 없었던 것이죠. 결국 개발이 95%나 진행된 후에도 수정을 해야 하는 상황을 마주했어요.
문제 3 : 멀티 브랜드 디자인 시스템은 그렇게 간단할 수 없다
팀스파르타는 다양한 프로덕트를 품고 있어요. 팀스파르타에서 디자인시스템이 목적을 달성하려면 모든 프로덕트에 공통으로 적용 가능한 멀티 브랜드 디자인 시스템이 필요해요.
디자인시스템 이전에 기존 디자인 라이브러리가 있었고, 이를 바탕으로 초기 디자인시스템이 구축되었어요. 하지만 공통 컴포넌트 개발과 함께 벽을 마주하게 되었습니다. 개발 효율을 위한 토큰 구조가 적용되지 않은 기존의 Foundation으로 공통 컴포넌트를 개발하기는 그리 간단하지 않았기 때문이었죠. 버튼 하나를 만들려고 해도 컬러 시스템의 팔레트가 충분히 준비되지 않아서 상태별로 모든 프로덕트의 컬러를 다르게 지정할 수 없었어요. 여러 방법을 고민해 보고 시도해 보았지만, 개발 후 결국 여러 프로덕트에 동시에 적용할 수 없는 상태가 되었어요. 열심히 만든 컴포넌트를 눈앞에 두고도 사용할 수 없는 상황은 정말 마주하기 싫은 순간이었죠...
솔루션 : 카지노 쿠폰 TF, 자 이제 시작이야~
실무자들이 지속적으로 늘어가는 상황에서, 이제는 정말 디자인시스템 구축에 박차를 가해야 될 때가 되었습니다.
?? : 하지만 이미 너무 많은 프로덕트가 고도화되어 버렸어!
우리 : 늦었다고 생각할 때가 진짜 늦었다. 그러니 지금 당장 시작해야 해!
지금까지 디자인시스템 구축을 하며 느꼈던 문제를 해결하기 위해 디자인시스템 TF를 결성하기로 했어요. TF가 결성되면 위 문제들이 이렇게 해결될 수 있습니다.
명확한 DRI가 없다 담당자가 생긴다.
한 명이 100%의 리소스를 투입하기는 어려운 상황이지만, 한두 명의 최종 의사결정자와 지정된 여러 명의 작업자가 있으면 기존보다 훨씬 빠른 구축이 가능해요. TF는 2명의 디자이너와 5명의 개발자로 구성되었지만, 디자인팀의 디자인시스템 주간회의는 유지하면서 리소스에 여유가 생기는 디자이너 분들이 작업에 도움을 주시기도 해요. TF에서는 주요 의사결정은 디자이너 한 명과 프론트엔드 개발자 한 명이 담당하고, 작업 시작 전 미리 DRI를 정하기로 했어요.
공장식 프로세스는 혼란스럽다 구조부터 합의하고 만든다.
앞에서 정해진 TF의 디자인, 개발 최종의사결정자는 디자인 가이드를 제작하기 전에 구조, 형태 등에 대해 깊이 소통하게 됩니다. 개발 시작 전 충분한 소통을 통해 가이드가 제작되면 개발 단계에서 소통은 최소화할 수 있어요. TF 출범과 동시에 디자인 시스템의 원칙을 세워두어서, 이제 의사결정이 길어질 때에도 원칙을 되새기며 효율적인 결정을 할 수 있어요. 자연스레 개발 후에 수정해야 하는 상황도 줄어들어요.
멀티 브랜드 디자인 시스템은 그렇게 간단할 수 없다 맞춤형으로 다시 만든다.
기존의 디자인시스템은 멀티 브랜드 시스템의 역할로 기능하기 어렵다는 판단 하에 TF에서는 토큰화부터 다시 시작하기로 했어요. 시간은 좀 더 걸릴지라도 다양한 프로덕트에 시스템을 사용하려면 꼭 필요한 구조이기 때문이죠. 토큰 구조를 잡는 것은 개발자와 소통이 중요한 일이기 때문에 TF가 꼭 필요했어요. 그리고 TF에는 각 프로덕트의 개발자들이 한 명씩 포함되어 있기 때문에 미리 적용 가능성을 파악할 수 있죠. 시스템이 만들어진 후에는 각 파트에 전파하는 역할까지 해줄 수 있어요.
이제 공장식 프로세스는 과거로 보내고, 디자인시스템 TF는 열심히 소통하며 시스템을 만들면 됩니다. 물론 쉬운 여정은 아니겠지만 모두가 같은 목표를 바라보고 있으니 목표를 향해 나아가는 일만 남았네요!
가랏, 카지노 쿠폰 TF!by 김다혜, 프로덕트 디자이너
