인프랩 프로덕트 디자인 파트 (왼쪽부터 엠제이, 스댕, 율무, 레슬리, 비케이)

인프런 디자인 시스템 구축기 (a.k.a. 4개의 디자인 시스템 관리하기)

21년과 22년에는 디자인 파트에 많은 변화가 있었습니다. 1년 새에 디자인 파트 팀원이 1인에서 5인이 되었고요. 여러 시행착오를 거쳐 디자인 시스템의 버전 1을 만들어가고 있어요. 인프랩의 프로덕트 디자이너와 함께 디자인 시스템의 지금을 점검하고 앞으로의 디자인 시스템에 관해 나눈 이야기를 공유합니다. 

디자인 시스템을 만들게 된 배경이 궁금해요. 어떻게 시작하게 됐는지 이야기를 들어보고 싶습니다. 

스댕 : 팀원이 많아지면서 하나의 서비스에 디자인과 기능의 파편화가 심화되고 있었어요. 디자인 시스템에 등록된 게 아니라 직접 디자인한 작업이 많아질수록 작업 전/후로 신경써야할 범위도 커지고, 제품 QA 할 때 리소스가 많이 들어가는데요. 제품을 빠르게 내보내야 되는 조직인데 업무 효율이 떨어졌던 것 같아요. 

비케이 : 디자인 시스템이 선택사항은 아닌 것 같아요. IT 쪽에서는 필수적인 부분이 된 것 같고요. 아무래도 일관성도 있고 재사용할 수 있다는 부분이 큰 것 같아요. 서비스 규모도 점점 커지고 관리 인력도 늘어가는데 재사용성이 낮으면 효율이 떨어지겠죠. 그래서 디자인시스템 도입이 자연스럽게 필요해졌다고 생각합니다.

레슬리 : 프로덕트 디자인 팀원이 1명에서 5명까지 늘어나는데 1년 정도 걸렸거든요. 서로 다른 스타일을 가진 디자이너가 모여 하나의 스타일을 만들기가 생각보다 어려웠어요. 

미묘하게 다른 디자인 때문에 유저의 학습 비용이 증가하는 부분도 있고요. A 페이지에서는 버튼을 A 방식으로 사용하는데 B 페이지에서 버튼이 다른 방식으로 사용되면 유저가 페이지를 옮겨 다닐 때마다 새롭게 학습을 해야 되잖아요. 

저희가 디자인 작업을 개발자에게 전달할 때 상태별로 다른 사항을 작성해서 전달해요. 비로그인 유저가 로그인했을 때, 클릭했을 때 등의 액션을 상세히 기록하는데 전달하는 과정에서 누락되는 경우가 많고요. 

기준이 불명확하다 보니 개발팀에서 수정 반영했던 부분이 디자인 의도와 맞지 않아 다시 수정할 부분들이 생기기도 해요. 그래서 디자인 작업 이후에도 리소스가 필요했어요. 본인이 작업한 영역이 아니면 히스토리 파악이 어려워 작업자를 직접 찾아가 어떤 기준이 적용되었는지를 물어보기도 했고요. 

엠제이 : 제가 합류했을 때 디자인 시스템은 외부 라이브러리를 사용하자라는 얘기가 나오고 있었어요. 디자인과 개발 파트 사이에 맵핑(Mapping)이 잘 이루어지지 않은 부분이 있어서, 두 파트에서 생산성과 일관성을 높이기 위해 만들게 되었어요. 각각의 영역을 디자인 하다보면 개발 파트와도 복잡한 커뮤니케이션들이 이루어지는데 이런 부분을 간소화해서 시간을 더 효율적으로 활용하는 게 가장 큰 목적이라고 생각해요.

* 디자인 시스템 초기 작업

디자인 시스템을 구축하기 위해서는 어떤 일들이 진행이 됐는지 구체적인 과정이 궁금해요. 설명해 주실 수 있을까요.

엠제이 : 시스템을 ‘0’에서부터 만드는 것이 비효율적이라고 생각해서 기존에 잘 만들어진 오픈소스 라이브러리를 활용해 발전시키는 방향으로 살펴봤어요. 

여러가지 오픈소스 라이브러리 중에서도 몇 가지를 선정하게 된 이유가 있는데요. 첫 번째로 피그마 디자인 키트 파일이 있는지 확인했고요. 현재 인프런에서 VanillaJS 로 구현된 페이지도 있지만 앞으로 ReactJS 로 지원할 페이지들도 있거든요. 그래서 이 두 가지를 다 지원하는지를 찾아봤어요. 

논의를 통해 VanillaJS는 부트스트랩(Bootstrap Library)을, ReactJS 는 만타인 라이브러리(Mantine Library)를 이용하기로 했어요. 부트스트랩과 만타인 모두 오픈소스로 제공하는 디자인 키트를 사용했는데요. 만타인 디자인 키트는 라이브러리 웹 페이지의 정보와 다른 지점이 있어서 그 부분은 페이지를 보고 따로 구축했어요. 현재는 피그마에 기본 형태를 구축하는 작업에 중점을 두었고, 다음 단계에서 변형 작업을 진행할 것 같아요.

비케이 : 22년 4월 7일에 전사적인 싱크업을 진행했어요. 디자인 시스템은 단순히 프로덕트 디자이너만의 도구가 아니기 때문에 프론트엔드 파트 | 프로덕트 디자인 파트 | CTO 향로가 모여 본격적인 논의를 시작했어요. 개발자와 싱크가 가능한지도 논의가 되었고요. 

율무 : 처음에 인프런 디자인시스템이 있었어요. 다만 굉장히 오랫동안 업데이트 되지 않았고 구현된 컴포넌트가 싱크가 안 맞는 부분이 많아서 이걸 디벨롭 하기 보다 새로 만드는 게 낫지 않겠냐부터 논의를 시작했고요. 디자인 파트나 개발 파트 모두 디자인 시스템을 ‘0’ 부터 끝까지 만들어 본 경험이 있는 팀원이 부족하기도 해서 라이브러리를 쓰게 되었어요. 

외부 라이브러리를 사용하는 팀도 있고 처음부터 구축하는 팀도 있군요.

비케이 :  네, 해외의 잘 만들어진 라이브러리를 사용하기도 하고 회사 내부에서 처음부터 끝까지 구축하여 사용하기도 해요.

율무 : 보통 스타트업은 디자인 시스템에만 리소스를 할애할 수 없기 때문에 효율적으로 일하려고 외부 라이브러리를 사용하는 경우가 있는 것 같아요. 대기업 같은 곳은 자체 구축하는 일이 많은 것 같긴 해요. 디자인 시스템을 구축하는 인력을 따로 빼서 아예 디자인 플랫폼 팀이 따로 있기도 하고요.

엠제이 : 자체 구축을 하더라도 시스템을 한꺼번에 서비스에 적용하는 건 많은 시간이 필요하기 때문에 한꺼번에 진행한 케이스는 거의 본 적이 없는 것 같고요. 디자인시스템 구축이 완료되면 페이지 디자인을 할 때마다 적용하는 방식인 것 같아요. 

라이브러리 선택 시 가장 주요하게 고려했던 게 유연한 커스텀이 가능한 지였어요. 저희가 현재는 4개의 디자인 시스템을 보유 하고 있는데 결국은 통합을 해야 하거든요. 그러기 위해서 1)커스텀 제약이 많지는 않은지 2)관련 개발 커뮤니티가 활성화 되어 있는지, 3)생산성을 떨어뜨리지 않는지를 고려해 외부 라이브러리 두 가지를 선택했어요. 

율무 : 하나는 기존 인프런 디자인 시스템이고요. 두 번째는 코드상으로 VanillaJS로 구현된 코드에 적용 가능한 디자인 시스템인 부트스트랩이고요. 리액트로 옮긴 페이지 적용되는 만타인이 세번째고 네번째는 랠릿이에요. 

레슬리 : 랠릿을 시작할 때는 디자인시스템 작업을 바로 할 수 없는 상태였어요. 

프로덕트 팀이 전체가 투입되었기 때문에 시간이 도저히 안 나서 그때 사용할 컴포넌트로만 디자인 시스템을 간단하게 만들었어요. 지금 만타인 디자인 시스템을 적용할 수 있는 상황이 아니지만 최종적으로는 만타인을 커스텀한 형태로 합칠 거예요. 

엠제이 : 맨 처음의 인프런 디자인 시스템은 다 없애는 게 목적이에요. 나중에는 부트스트랩과 만타인, 이 두 개만 남겨놓고 작업하는 거죠.


*인프랩 디자인 시스템 Foundation – Color

인프런 디자인 시스템이 다른 회사의 디자인 시스템과 차이점이 있다면 어떤 것들이 있을까요.

비케이 : 플랫폼 디자이너가 따로 있거나 디자인 시스템만 다루는 팀이 있는 회사도 있을 거예요. 저희처럼 프로덕트 디자이너가 관여해서 구축하는 팀도 있고요. 저희는 후자에 속하는 것 같아요.

스댕 : 디자인 시스템이 4개 (인프런 3개, 랠릿1개) 인 게 가장 큰 차이점인 것 같아요. (ㅎㅎ)  

엠제이 : 외부 라이브러리를 베이스로 하는 작업이 처음이에요. 웬만하면 스타트업에서도 디자인 시스템에 쓰는 시간이 많지 않기 때문에 라이브러리를 쓰면 좋지만 ‘0’에서부터 만드는 케이스가 많았는데요. 필요한 부분만 만들어서 대충 썼던 경험이 많았어요. 지금 부트스트랩, 만타인, 팁탭, 그리고 아이콘도 폰트어썸을 쓰는데 이렇게 라이브러리를 적극 활용하는 게 큰 차이점인 것 같아요.  

디자인 시스템을 만들면서 어떤 기준들이 적용되었는지 궁금해요 

율무 : 1차적으로는 웹문서에서 제공하는 기준 규칙들을 대부분 따라갔어요. 저희만의 기준을 세우고 적용하는 게 다음 스텝이라고 생각해요. 

사실 기준을 세우기 위한 시도는 했었어요. 하지만 모든걸 커스텀 하기에는 어려운 상황이었어요. 만타인 자체를 저희에 맞게 모두 바꿀 수 없는 상황이었거든요. 그래서 다음 스텝에서 디테일하게 잡아가면 좋겠다라고 해서 일단 홀딩해두었어요. 

*인프런 기존 사용 모달 정리 작업 1

비케이 : 근데 인프런스러운 레거시(Legacy)가 분명 있잖아요. 예를 들면 버튼을 각지게 할 수도 있지만 각지게 하면 날카로워 보일 수도 있거든요. 저희는 그런 방향은 선택하지 않은 것 같아요. 

인프런이 원래 갖고 있는 친근함이라든지 부드러운 요소들을 살리는 방향으로 선택했어요. 기존에 인프런이 갖고 있는 이미지를 해치지 않는 선에서 작업한다는 기준은 있었다고 생각해요. 

*인프런 기존 사용 모달을 정리 작업 2

엠제이 : 컴포넌트 단위를 쓰거나 컬러, 간격, 둥글기, 폰트 등에 적용할 기준들을 결정할 때도 기존에 어떤 요소들을 썼는지 고려했어요. 또 이렇게 결정하게 된 이유는 지금 사용하는 라이브러리와 전에 쓰던 디자인 시스템이 섞여 있을때 최대한 이질감이 나지 않으면서도 일관성 있는 모습으로 변하길 바랐기 때문이에요.

비케이 : 우리가 사용하는 모달을 쫙 다 모아보기도 했어요. 어떤 형태를 많이 쓰지? 어떤 크기를 쓰고 있더라? 이런 것들을 모으고 평균값들을 봤던 작업이 기억나요.

디자인 시스템을 진행하면서 어려웠거나 아쉬운 부분은 무엇이었나요?

레슬리 : 작업 리소스를 고려하다 보니까 기존 규칙을 웬만하면 따라가자라고 했었어요. 고민했던 포인트가 많았는데 FE와 지금 수정할까 기존 시스템을 따라갈까를 논의했을 때 웬만하면 기존 시스템을 따라가는 쪽으로 결정되는 경우가 많아서 아쉬웠어요. 버전 2에서는 인프랩에게 맞는 디자인 시스템으로 커스텀 됐으면 하는 바람이 있어요.

율무 : 제가 작업하는 대부분의 페이지는 리액트가 아니고 VanillaJS 거든요. 부트스트랩은 지나가는 시스템이라고 생각했어요. 결국은 만타인으로 통합하잖아요. 그래서 부트스트랩 디자인 시스템에 힘을 들이진 않았어요. 

제가 사용하는 디자인 시스템은 부트스트랩이고 실제 페이지에서 만타인을 사용하는 경험이 그렇게 많지 않아서 아쉬워요. 열심히 만들었는데 당장 적용하지 않으면 뭐가 문제인지 알기 어렵거든요. 컴포넌트를 실제로 서비스에 적용해야만 개선 지점을 알 수 있으니까요.   

스댕 :  개발 구현 상태를 피그마와 동일하게 맞추는 부분을 신경썼는데, 모든 컴포넌트를 구현과 완벽하게 맞추기가 어려웠어요. 이 부분이 당황스럽기도 했고요. 개발 구현 상태와 피그마에서의 상태를 100% 일치시키기가 어려운 경우도 있었거든요. 

비케이 : 피그마가 아무래도 완벽한 구현을 해주진 않는 것 같아요. 구현과 피그마 표현과는 확실히 간극이 있더라고요. 동작도 그렇고 모션도 알 수가 없거든요. 그런 건 추가로 설명하는 문서가 필요해요. 이런 부분은 피그마로만 디자인 시스템을 구축하기에는 조금 어렵지 않나 생각해요. 

엠제이 : 지금은 외부 라이브러리에 많이 의존한 형태고 가급적 기본 형태에서 커스텀 하지 않는 방향으로 진행했어요. 컴포넌트에서 커스텀하고 싶은 부분들이 있었는데 제약이 따르는 부분이 생길 때 아쉬워요. 

핸드오프(HandOff)*에 약간 제약이 있어요. 인프런이 사용하는 언어에 맞게 스타일이 작성되면 좋을 거 같아요. 지금은 개발자가 스타일을 참고해서 다시 작성하는 작업이 예상되거든요. 피그마에서 보여주는 속성값과 개발에서 사용하고 있는 작성 방법이 달라서 QA 할 때 다른 점이 발생하기도 하고요. 그런 부분을 해소할 방법을 아직 못 찾았고 디자인 시스템을 사용하면서 개선점을 발견해야 되는데 일부 사용하지 않는 프로젝트들이 있어서 아쉬워요. 
* 디자이너가 완성된 UI를 구현하기 위해 개발자에게 넘기는 과정

ReactJS 로 변환하고 나면 동일한 디자인 시스템을 적용하면서 개선점들이 더 많이 생길거 같아요.


*인프랩 디자인 시스템 Component – Button

디자인 시스템이 업무 효율을 높여주기 때문에 만들잖아요. 실제로 얼마나 높아졌는지 궁금해요. 

율무 : 개인적으로는 도입 초반이고 만타인을 써본 적이 없어서 효율이 높아졌다고 당장 말하기는 어렵지만 디자인 시스템이 디벨롭 되면 확실히 효율은 좋아질 거라고 기대해요. 

비케이 : 저는 에디터 개편 작업할 때 만타인을 썼는데요. 와이어프레임 단계를 거의 안 썼어요. 가져다 쓰면 되니까요. 전에는 와이어프레임 따로 디자인 시안 따로일 때가 있었는데 이번에는 와이어프레임이 필요 없었고 디자인 QA 단계도 축소됐어요. 

레슬리 : 최근에 만타인 디자인 시스템으로 QA까지 한 적이 있는데요. 전에는 디자인 시스템 가이드와 그 외의 가이드가 있었다면 이제 디자인 시스템에 대한 가이드는 아예 필요가 없어졌어요. 

약속을 했고 규칙이 정해져 있으니까요. 그래서 디자인시스템 이외의 부분만 확인하면 돼서 최소한 50%는 줄어들었다고 할 수 있어요. 웬만한 영역은 거의 디자인시스템에서 가져왔기 때문에 일부를 제외하고는 디자인 QA가 없었어요.

비케이 : 아직 초반이라 만들어진 컴포넌트가 없다면 작업이 추가되겠지만 점점 하향 곡선을 그리게 될 테니 확실히 효율이 높아질 것 같아요. 기대가 됩니다.

레슬리 : QA 할 때 체크하지 않아도 되는 부분이 많았고 기능 위주의 QA를 심도있게 할 수 있었어요. 버그나 에러 측면에 집중할 수 있었던 것 같아요. 

엠제이 : 컴포넌트 사용법 등이 일관성 있게 사용되고 있어서 커뮤니케이션 비용이 줄어든 게 아닐까 생각해요. A 페이지의 버튼 크기와 B 페이지의 버튼 크기, A 페이지의 인풋 크기와 B 페이지의 인풋 둥글기 이런 것들이 다르게 사용될 수 있는데, 그런 부분들이 일관성 있게 맞춰지니까요. 그런 부분들이 효율을 높여준다고 생각해요. 


*인프랩 디자인 시스템 Component – Select

디자인 시스템이 만들어지니까 어떤 점이 가장 좋았나요?

비케이 : 인터페이스 자체에 대한 고민은 줄고 플로우나 기능 동작에 대한 집중도가 올라가요. 유의미한 쪽에 많이 집중할 수 있는게 좋은 것 같아요.

레슬리 : 작업 시간을 전과 같다고 했을 때 사용성과 플로우(flow)개선에 비중을 늘려서 작업할 수 있어요. 이전에는 상대적으로 사용성에 대한 작업 시간이 부족했거든요. 그 부분이 확보되어서 좋아요.

율무 : 만들면서 좋았던 점도 있어요. 외부 라이브러리를 사용하니 부트스트랩은 진짜 엄청 오래된 라이브러리잖아요. 파보면 잘 만들어져 있긴 하거든요. 역사가 깊다보니까 파보면서 어떻게 구조를 짜는게 좋구나를 배울 수 있어요. 피그마에서도 베리언트(variants)라는 기능이 있는데 작업에 참고할 수 있었고요. 부트스트랩으로 학습하는 과정이 있었기 때문에 만타인에서도 수월하게 할 수 있었어요.  

각자의 소감을 들려주세요. 

엠제이 : 앞으로 해야 할 일이 많이 남았어요. 디자인한 컴포넌트와 실제 개발에서 사용하는 컴포넌트의 맵핑(Mapping) 작업을 위해 토큰 작업도 진행해야 하고 가이드와 문서화 작업도 해야 해요. 톤앤 보이스 작업 그리고 디자인 원칙을 세우는 작업도 필요하고요.

꾸준히 좋은 라이브러리나 디자인시스템을 참고하며 발전시키고 더 나은 효율에 대해서도 고민하고 싶어요.

율무 : 잘 배웠고 앞으로 계속 만날 거니까 더 잘 만들고 싶어요. 이왕 시작한 거 외부 라이브러리와 상관없이 저희 인프런만의 디자인 시스템으로 어떻게 잘 만들까를 고민하는 내년이 되었으면 해요.

비케이 : 개선할 부분들이 당연히 있고요. 완벽하지 않기 때문에 계속 성장시켜 나갔으면 좋겠어요. 인프런 디자인 시스템을 구축하고 운용하고 개선하는 일련의 작업들은 프로덕트 디자이너로서 사실 좋은 경험이라고 생각하거든요. 그래서 프로덕트 디자인 파트 5명이 함께 양질의 디자인 시스템을 만들어가는 일을 기대하고 있습니다.

스댕 : 디자인 시스템이 제대로 만들어진 건 이번이 처음인 것 같아요. 솔직히 말하면 실감이 나지 않아요. 기대는 되고요.(웃음) 저는 이번에 랠릿이라는 채용서비스의 UX/UI를 담당하게 됐는데, 여기에는 현재 구축하고 있는 디자인 시스템을 사용하고 있지 않아요. 그래서 개인적으로 이 디자인 시스템을 랠릿에 적용시킬때 더 크게 실감할 것 같아요.

레슬리 : 저는 작게나마 만타인 디자인 시스템을 써볼 수 있는 기회가 있어서 효율을 많이 체감했어요. 처음 4개의 디자인 시스템을 관리해야 된다는 말을 들었을 때 막막하고 어디서부터 손대야 하나 걱정했는데 다행히 팀원들이 알아서 각 영역에 대한 리서치도 하고 서로 부족한 부분을 알려주기도 하면서 개선 해나갈 수 있었어요. 돌아보니 그래도 많은 부분이 갖춰진 것 같아요. 

디자인 시스템이 한 번 만들어졌다고 그걸로 끝나는 게 아니라 앞으로 서비스가 계속되는 한 같이 업데이트 되어야 한다고 생각해요. 앞으로는 어떤 디자인을 해도 대응 가능한 최적의 형태가 되면 좋겠어요. 또 새로운 분이 오셔도 납득할 만한 기준을 함께 만들어서 사용성 개선에 좀 더 집중하는 프로덕트 팀이 되었으면 좋겠습니다.

 

배움과 성장의 토대를 만드는 사람들, 
인프랩의 동료가 되어주세요.

 

인프랩 채용 알아보기