우당탕탕 리얼월드 스튜디오 디자인 시스템 제작기 #1탄
안녕하세요, 리얼월드의 프로덕트 디자이너 김예인입니다! 이 글로 첫 번째 인사를 드리게 되네요.
저희 유니크굿컴퍼니는 두 가지 서비스를 운영하고 있습니다. 첫 번째가 방탈출형 미션 게임 앱인 리얼월드이고, 두 번째가 리얼월드에서 작동하는 게임을 만들 수 있는 웹 저작도구, 리얼월드 스튜디오예요.
그 중 게임 저작도구인 리얼월드 스튜디오가 최근 아주 적은 인원으로(1 디자이너와 2 프론트엔드 개발자…) 대규모 개편을 했고, 지난 2월 7일에 베타 릴리즈를 했어요!
저희는 그 개편 과정에서 리얼월드 스튜디오 디자인 시스템을 도입하고 프로젝트에 사용했습니다.
그렇게 디자인 시스템을 사용하여 스튜디오를 리뉴얼하는 6개월의 시간 동안, 열심히 만든 시스템을 실제 작업에 적용해보니 다른 분들께 공유 드리고 싶은 경험이 아주 많이 생겼어요. 특히 프로젝트를 진행하면서 느낀, 디자인 시스템 도입의 장점과 단점, 그리고 어려웠던 점에 대해 말씀드릴 수 있을 것 같아 이 글을 쓰게 되었습니다.
사실 작은 조직에서 디자인 시스템을 도입한다는 것은 꽤 큰 결정을 필요로 하는 일이기 때문에 저희의 경험이 궁금하신 분이 있을 거라고 생각했거든요!
그래서 저는 디자인 시스템을 만들 때의 고민과 결정, 그리고 사용하면서 좋았던 점과 불편했던 경험, 그리고 배포 후 개선한 경험을 시리즈로 공유해드리고자 합니다.
글은 총 세 편으로 구성할 예정입니다.
첫 글에서는 디자인시스템을 만든 배경과 디자인 시스템을 도입하고 느낀 효과,
두 번째 글에서는 디자인 시스템을 만드는 과정에서 고민했던 점과 어려웠던 점,
세 번째 글에서는 디자인 시스템을 유지/보수하는 이야기에 말씀드리려고 해요!
오늘은 그 첫번째 이야기, 디자인시스템을 만든 배경과 디자인 시스템을 도입하고 느낀 효과에 대해 말씀드리겠습니다!
1. 디자인 시스템, 왜 만들었나요?
이제는 익숙하게 느껴질 만큼 많은 서비스에서 도입하고 있는 디자인 시스템이지만, 사실 저희에게 디자인 시스템을 만들 기회가 올 거라고는 생각하지 않았습니다. 저희는 규모가 작은, 그리고 프로덕트 디자이너도 저 혼자(!)인 작은 조직이었으니까요.
보통 기업에서 디자인 시스템을 도입하는 첫 번째 이유는 여러디자이너들이 제각기 다른 방식으로 만드는 바람에 비효율적으로 생산, 사용되는 요소들을 규칙을 갖춘 컴포넌트로 만들기 위함이죠.
하지만 저희는 디자이너가 한 명임에도 디자인 시스템을 만들었어요. 그 이유에 대해서 먼저 설명드리도록 할게요.
1–1. 디자이너가 한 명인 조직에서도 디자인 시스템이 필요한가요?
디자인 시스템 도입을 결정할 때 가장 많이 고민한 부분입니다. 어차피 디자이너가 한 명이라면 다른 디자이너들과 협업할 일도 없고… 혼자서 컴포넌트 관리를 잘 하기만 하면 되는 거 아닐까? 하고요.
하지만 그래서 세 가지 이유를 들었습니다. 아마도 실무를 하시는 디자이너분이시라면 공감할 것이라고 생각해요.
첫 째, 놀랍게도(!) 과거의 저는 지금의 저와 같은 사람이 아닙니다.
이게 무슨 뜻이나고요? 제가 오늘 세운 규칙을 반 년 후에 되돌아보면 규칙이 아니게 되어있을 수 있다는 뜻입니다. 엄격하지 않은 규칙은 규칙이 아닙니다. 그리고 계획과 시간을 들여 세운 모두와 합의된 규칙과, 디자이너 개인이 작업을 진행하면서 세운 규칙에는 엄연한 차이가 있습니다.
네… 모두 과거의 제가 만든 버튼입니다… 같은 것 처럼 보이지만 뜯어보면 전부 다른 버튼이죠. 태어나서 처음 UI 만들었을 때부터 지금까지의 시간이 고스란히 담겨있네요!^^ 처음 해서 미숙했던 부분도 있고 화면에 타협해버려서, 혹은 이전에 만들어놓은 컴포넌트가 있다는 걸 까먹어서 이렇게 많아진 것이기도 합니다.
중간에 컴포넌트를 정리하려는 시도가 없었던 건 아닙니다. 하지만 시스템 설계에 집중할 일정이 마련되어있지도 않았을 뿐더러, 아무리 디자이너 혼자 계획을 세우고 컴포넌트를 관리한다고 한들 시간이 지나면 엣지케이스가 생겨나기 마련입니다. 그리고 그 엣지케이스를 기존의 컴포넌트에 집어넣으면서 혼자 세운 규칙을 유지하기란 쉽지 않은 일입니다.
둘 째, 디자이너 혼자서는 통일성을 만들 수 없습니다.
디자인 시스템을 만드는 목적은 단순 디자인의 편의성과 프로덕트의 편의성이 아닙니다. 그보다는 개발자와의 커뮤니케이션을 줄이는 게 진짜 목적이라고 볼 수 있죠.
아무리 디자이너가 열심히 규칙을 세우고 시스템을 세워두었다고 해서 전달받은 개발자가 디자이너가 설계한 것과 같은 구조로 개발할거라는 보장은 없습니다. 그리고 다르게 개발된 컴포넌트는 동일한 컴포넌트라고 볼 수 없습니다.
그 뿐일까요? 개발 쪽에서 다루는 컴포넌트에는 UI적 요소 뿐 아니라 눈에 보이지 않는 개발적 요소(기능)도 포함되어있습니다. 예시를 한 번 들어볼게요!
아래와 같은 모달이 있습니다.
디자이너와 개발자 모두 재사용성을 고려하여 아래의 모달을 만들었을 거예요. 그리고 결과적으로는 똑같은 모달이 만들어졌어요!
하지만 모양이 같음에도 불구하고 두 컴포넌트에는 큰 차이가 있을 수 있습니다. 그게 어떤 부분일까요?
자, 이게 디자이너가 전달한 모달의 프로토타입입니다.
디자이너는 프로토타입을 전달드리면서 다음 항목을 고려했습니다.
그리고 개발자는 디자이너의 프로토타입을 보고 똑같은 모양의 모달을 개발했습니다. 얼핏 보기에 똑같이 되어있는 것 같죠! 둘 다 만족합니다.
하지만 시간이 흐르고… 디자이너는 다른 프로젝트에 같은 컴포넌트를 활용한 모달을 개발해달라고 개발자에게 요청합니다.
아주 단순한 모달입니다. 타이틀과 바디가 있고, 버튼이 동일하게 두 개 들어갑니다. 알림 끄기 버튼을 누르면 알림이 꺼지고, 알림 계속 켜놓기를 누르면 모달창이 닫히게 해달라는 게 요청사항이었죠!
그런데 개발자의 표정이 뭔가 이상합니다.
상황은 이렇습니다. 두 사람이 처음에 모달을 만들 때 생각했던 게 달랐던 거예요.
그런데 디자이너가 새로 요청한 모달은 Footer 좌측의 회색 버튼을 눌렀을 때 모달이 닫히는 게 아니라, <알림을 끄는 액션>을 해야하죠. 하지만 현재 만들어진 모달 컴포넌트의 회색 버튼은 <취소>밖에 할 수 없는 버튼입니다.
그렇다면 디자이너가 디자인을 변경하지 않는 한 개발자는 기존의 컴포넌트를 수정해야 할 것입니다. 그럼 기존에 이 모달을 쓰고 있는 페이지에 모두 영향을 미칠 것이고, 그를 막기 위해서는 재사용을 포기하고 또 다른 모달을 만들거나, 혹은 신중하게 이 컴포넌트를 수정하는 작업을 거쳐야겠죠.
한 두번까지는 수정이 가능할지도 모르지만 이러한 과정이 반복된다면 컴포넌트의 재사용성은 극도로 떨어질 수 밖에 없을겁니다. 또한 컴포넌트를 재사용하려고 할 때마다 개발자와 디자이너가 계속 커뮤니케이션 해야하는 상황이 벌어질테고요!
마지막, 디자이너가 한 명이라고 개발자 역시 한 명인 건 아닙니다.
디자인 시스템 없이는 개발된 컴포넌트에 대한 이해를 공유하기 어렵습니다. 그 경우 여러 개발자가 작업을 할 경우 정말 꼼꼼하게 상황을 챙기지 않는 이상(불가능!) 같은 컴포넌트를 두 번 개발하는 불상사를 피할 수 없다고 생각합니다. 디자이너도 그러니까요!
물론 이미 알고있는 비효율이 있음에도 불구하고 디자인시스템을 만드는 것보다 페이지, 컴포넌트 단위로 개발하는 게 효율적인 경우도 분명 있으리라고 판단됩니다. 왜냐하면, 디자인 시스템을 만드는 것은 정말 많은 시간과 리소스가 필요한 작업이기 때문이죠. 이에 대한 판단은 각 서비스의 상황에 따라 내려져야한다고 생각합니다.
따라서, 사실은 저희도 디자인시스템을 만드는 건 시간과 리소스의 사정상 어려울 것이라고 생각했었습니다. 하지만 기회는 생각보다 예기치 않게 생기더군요!
1–2. 어떤 계기로 도입을 결심하게 되었나요?
유니크굿컴퍼니는 리얼월드라는 앱 서비스와 리얼월드 스튜디오라는 웹 서비스를 운영하고 있습니다. 그런데 그 중 웹 서비스인 리얼월드 스튜디오가 기술적인 이슈에 부딪혀 프론트엔드 개발 프레임워크를 전환하게 되었습니다.
개발 프레임워크를 전환한다는 것은 사실상 프로덕트를 새로 만드는 것과 다름이 없습니다. 개발 프레임워크를 전환한다고 서버 구조까지 같이 고칠 수는 없겠지만, 그래도 기획자와 프로덕트 디자이너 없이 만들어져 2년간 단 한 번도 손대지 못 했던 스튜디오의 UX와 UI를 개선할 기회가 생기게 된거죠.
그 말은 즉슨, 리얼월드 스튜디오에 있는 모든 화면을 말 그대로 새로 기획하고 디자인해서 만들어야한다는 뜻이었습니다.
서비스의 모든 화면을 일괄적으로 바꾸는 프로젝트는 디자인 시스템을 도입해보는데에 최적의 타이밍이라고 생각했습니다. 새로 개발될 화면의 UI적 통일성을 갖출 수 있을 뿐 아니라, 앞으로 본격적으로 서비스될 리얼월드 스튜디오의 확장성을 생각해봤을 때 레거시를 최대한 적게 만들 수 있는 방식으로 서비스를 만들 수 있었기 때문이죠.
또한 초반 비용은 많이 들 수 있겠지만, 디자인시스템을 만들어두면 UI에 대한 커뮤니케이션 비용이 줄 수 밖에 없기 때문에 장기적으로 보았을 때는 디자인시스템을 만들었을 때의 이점이 더 크다고 생각했습니다.
그렇게 구성원들의 의견이 합쳐서 디자인 시스템을 만들기 시작했습니다!
물론 마냥 좋을 것이다! 라는 생각은 무척이나 순수했기 때문에, 일정 산정부터 디자인 시스템 설계, 개발까지 상상하지도 못 한 고생을 하고 엄청난 시행착오를 겪게 되었지만…
결과적으로는 3개월의 시간을 거쳐 한 명의 디자이너와 두 명의 개발자가 리얼월드 스튜디오 디자인 시스템을 완성하게 되었습니다!
2. 디자인 시스템 이후, 어떻게 바뀌었나요?
그래서 어떻게 바뀌었냐고요? 당연히 엄청나게 많은 시행착오를 겪고 그 때문에 일정이 미루어지기도 했지만 그건 다음 글에서 조금 더 자세히 다루어보도록 하겠습니다.
하지만 예상보다 많은 일정을 쓰고, 예상보다 많은 시행착오를 겪었음에도 불구하고 저희는 디자인 시스템을 도입한 걸 후회하지 않아요! 그 이유를 여기서 말씀드리겠습니다.
2–1. 디자인 시간이 단축되었습니다.
디자이너 입장에서는 결과적으로 UI 키트가 생긴 셈이니 디자인 시간이 눈에 띌 정도로 단축될 수 밖에 없습니다. 컴포넌트의 state에 역시 일일히 신경 쓸 필요가 사라지고, 통일성을 지키기 위해 이전 화면을 둘러보는 수고가 사라졌습니다. 또한 디자인 시스템 내에 적용된 규칙 덕분에 여백, 타이포, 그림자에 대해 고민하는 시간이 줄었습니다.
곧 사소한 디자인 요소에 신경쓰느라 비효율적으로 소요되던 시간을 조금 더 효율적인, 사용자 경험에 대한 고민에 쓸 수 있게 된 것이죠.
또한 디자인 작업파일의 질도 좋아졌습니다. UI 작업 시 요소의 레이어명을 지정하는 것은 깔끔한 작업을 위해 꼭 필요한 작업이지만 정말 귀찮고 손이 많이 가죠. 그리고 누락하기도 매우 쉬운 작업입니다. 하지만 컴포넌트 중심의 작업을 하다보면 새롭게 사용되는 요소가 적기 때문에 레이어명 역시 깔끔하게 관리할 수 있었습니다.
2–2. 필요하다면, 기획자와 개발자 역시 화면을 만들 수 있습니다.
피그마라는 진입장벽이 있긴 하지만, 피그마를 활용할 수 있는 기획자와 개발자라면 디자인 시스템을 활용하여 디자이너 없이도 간단한 화면을 디자인할 수 있습니다.
예를 들어 중간에 기획이 추가되어 디자인이 누락된 모달의 경우에, 기획자가 간단하게 기존의 모달 컴포넌트를 가져와서 텍스트와 버튼 종류를 바꾸는 것 만으로도 디자인을 할 수 있는 것이죠.
2–3. 개발자와의 커뮤니케이션이 줄었습니다.
이전과 비교해봤을 때, 개발자와의 커뮤니케이션 양이 확실하게 줄었습니다. 전에는 요소를 하나 전달할 때마다 인터랙션에 대한 코멘트를 계속 첨부했어야 했는데, 디자인 시스템을 사용하여 개발하는 지금은 굳이 추가적인 코멘트 없이 컴포넌트의 이름만으로 모든 소통을 대신할 수 있습니다.
불필요한 디자인 QA 역시 줄어들었습니다. 개별 단위로 작업을 했을 때는 소위 1px에 대한 피드백이 많았습니다.
그런데 컴포넌트를 통일시켜서 재사용성이 늘어난 경우에는 1px에 대한 피드백을 할 일이 거의 사라졌습니다. 이미 만들어진 컴포넌트는 여백에 변화가 생길 일이 없고, 자잘한 UI가 깨질 일도 없기 때문이죠.
모든 컴포넌트를 디자인 시스템에 넣은 게 아니므로 디자인 QA가 모두 사라진 건 아니지만, 이 분량을 디자인 시스템 없이 진행했다면 UI를 QA하는 시간에만 엄청난 시간을 소요했을 것 입니다.
모바일용 UI를 작업하는 시간이 줄었습니다.
컴포넌트를 만들 때 모바일 화면을 고려해서 개발하기 때문에 모바일 UI를 따로 그리지 않아도 자동으로 대응이 가능해졌습니다. (야호!)
기능 QA 역시 줄었습니다.
디자인 시스템의 컴포넌트는 단순 UI뿐 아니라 기능을 포함한 컴포넌트를 만들고 사용하기 때문에 완성된 공통 컴포넌트를 사용하면 버그가 발생될 확률이 확연히 줄어듭니다. 이 역시 혹시 모를 경우를 위해 아예 하지 않을 수는 없지만, 그래도 작은 조직 안에서 이루어지는 QA 리소스를 조금 더 문제의 여지가 있는 곳에 집중할 수 있게 되었습니다.
커뮤니케이션의 간소화는 단순한 시간 절감을 의미하지는 않습니다. 비효율적이고 반복적인 일을 없애는 것은 시간을 절약하기도 하지만 무엇보다 작업자들이 커뮤니케이션 과정에서 소모하는 멘탈 리소스를 줄이기 때문이죠! (멘탈에 좋은…디자인시스템?^^)
디자인 시스템을 만들 때는 생각보다 볼륨이 커 디자인 시스템이 효율적으로 사용될 수 있을지에 대해 고민이 많았지만, 디자인 시스템 완성 후 6개월간 실제로 프로젝트에 적용해본 지금은 디자인 시스템을 만들기 위해 소비한 시간이 전혀 아깝게 느껴지지 않습니다. 되려 절약한 시간이 많아 다행이라는 생각이 드네요!
여기까지 유니크굿컴퍼니라는 작은 조직에서 우당탕탕 디자인 시스템을 만들게 된 계기와, 도입 후에 생긴 변화에 대해 말씀드렸습니다. 공감이 되시려나 모르겠네요!
그럼 첫 번째 이야기는 여기서 마치고, 다음으로는 저희가 디자인시스템을 만들며 겪었던 실무적인 우여곡절과 시행착오를 최대한 구체적으로 전달해드리고자 합니다! 최대한 실용적인 내용이 될 수 있게 꼼꼼히 정리했으니 도움이 되었으면 좋겠네요.
그럼 다음 편으로 찾아뵙겠습니다.
읽어주셔서 감사합니다!
