디자인시스템으로 백오피스 환골탈태시키기
카테고리
Empty
해당 글은 초기에 사내 백오피스 디자인 시스템을 구축하고 이를 도입하면서 느낀점들, 그리고 결과를 정리하기 위한 글이에요.
입사했을 당시에 사내 백오피스는 "이게 백오피스 서비스라고?" 할 정도로 생각보다 사용감이 많이 좋지 않았다. 또, 콘텐츠나 백오피스 서비스에 기획자, 디자이너가 투입되는 것도 아니다보니.. 개발자의 시선에서 그냥 빠르게 빠르게 만들어진 그런 산출물처럼 느껴졌다.
안랩에 들어와서 제일 먼저 백오피스 서비스를 처음 담당하게 되었는데, 위협 인텔리전스 플랫폼이 앞으로 디벨롭되면서, 백오피스에 많은 기능들이 들어가기 때문에 메뉴 하나하나, 기능 하나하나를 추가하면 되는 일이었다. 사실 그냥 기능이나 메뉴만 추가하면 되긴 하는데 보기 좋은 떡이 먹기 좋다고, 백오피스도 그랬으면 하는 마음이 있었다.
그래서 입사 초부터 지금까지 스스로 KPI 하나를 설정했는데 그게 바로 백오피스 환골탈태이다. 그 당시 내가 바라본 백오피스의 문제점은 다음과 같았다.
•
권한 처리를 서버의 응답을 통해서 제한하고 있음, 권한이 없어도 메뉴가 노출되는 상태
•
레이아웃의 설계 의도를 모르겠고, 관리 시스템으로 사용하기에 조잡한 느낌
•
디자인 시스템이 구축되어있지 않아, 매번 컴포넌트가 각 SFC에서 커스텀되어 사용되고 있음 (재사용성 ↓)
•
그 외 시각적인 레이아웃 구조의 전면 개편이 필요
KPI를 실현시키기 위해 입사 초부터 계획을 세웠는데 백오피스를 환골탈태 시키기 위해 정리한 작업들은 다음과 같다.
•
백오피스 내에 디자인 토큰들을 정의하고, 디자인 시스템을 만들기
•
사용자가 불편한 요소들을 듣고, 이를 적극적으로 해결해보기
•
코드 상의 불필요하게 반복되는 코드들을 추상화하기
•
UI 라이브러리에 의존한 잔존코드들을 디자인 시스템 기반의 컴포넌트로 모두 변경하기
위 과제들은 거의 다 달성을 했고, 이제는 이것들을 활용하고 있는 단계에 도달했다. 각각 어떤 식으로 진행을 했는지 한번 설명을 해보려고 한다.
기존에는 권한 처리를 서버 응답을 통해서 진행했다.
사용자가 접근하지 못하는 메뉴가 있다면, 기존 백오피스 서비스는 무조건 서버를 거쳐 메뉴에 대한 접근 처리를 하고 있었다. 로그인 시에 서버에서 내려주는 권한 목록을 가지고, 각 메뉴에 매핑을 시키면 굳이 메뉴를 노출시키지 않거나, 접근 시에 서버에 데이터를 요청하는 과정 없이 쉽게 클라이언트에서만으로도 처리가 가능하다.
초기 로그인 시, 내려오는 사용자 권한 > Pinia 전역 상태에 저장 →각 메뉴 별 이용가능한 메뉴를 명시하여, Pinia에 저장된 권한과 비교하여 포함되어있다면 노출 진행 (만약, 사용자가 임의로 상태를 변경한 경우에는 서버에서 2차 블락)
위와 같은 로직 처리를 통해 권한 처리를 통해 사용자는 허용된 메뉴만이 레이아웃 상에서 노출되는 것이다.
사용자가 불편한 요소들을 듣고, 이를 반영해보기
사실 프로덕트를 만들면서 이러한 요소들이 제일 고민인 부분이었다. 기존 백오피스의 역사를 팀원분들께 듣고나니 피드백을 들을 자리는 따로 없고, 백오피스를 사용하는 사용자들은 그저 기능만 추가된 상태로 개발자가 만들어놓은 레이아웃 위에서 불편함을 감수하고 사용법을 익혀가는 과정을 겪고 있었다.
그래서 이를 해결하기 위해서 실제 백오피스를 사용하고 있는 사용자들에게 메세지를 보냈고, 일부 백오피스에 대한 피드백을 받을 수 있었다. 많은 에로사항이 있었지만, 그 중 가장 큰 부분은 콘텐츠 작성 시에 발생되는 여러 불편한 요소들이었다.
•
콘텐츠 작성 시 마다 콘텐츠에 따른 위협 메타데이터를 입력하는데, 생각보다 많은 아이템을 셀렉트하는 과정이 오래걸린다.
•
콘텐츠 작성 시에 다국어 지원을 위해 번역 콘텐츠를 올리는데, 번역을 일일히 돌리거나 TW 감수 과정이 오래 걸린다.
•
임시 저장, 에디터 단축 기능 등의 다양한 편의 기능이 있으면 좋겠다.
•
등등.. 생각보다 정말 많았다.
물어보지 않았다면 섭섭할 정도로 무언가 고름처럼 문제점들이 고여가고 있는 듯한 느낌이 들었다. 그래서 위와 같은 에로사항들을 하나하나 파악해서, 어떤 방식으로 백오피스를 사용하는지 배우며 다음과 같이 처리할 수 있었다.
콘텐츠 작성 시 마다 콘텐츠에 따른 위협 메타데이터를 입력하는데, 생각보다 많은 아이템을 셀렉트하는 과정이 오래걸린다.
백오피스에는 정말 많은 보고서 카테고리를 가지고 있다. 그 카테고리 별로 정형화되고 공통적으로 사용하는 위협 메타데이터를 여러 관계자들과 함께 수집하였고 클라이언트에서 사용자가 보고서 카테고리를 선택하면 그 카테고리에 맞는 정형화된 위협 메타데이터를 자동으로 삽입하여 직접 메타데이터를 셀렉트하지 않아도 되는 UX를 제공했다.
콘텐츠 작성 시에 다국어 지원을 위해 번역 콘텐츠를 올리는데, 번역을 일일히 돌리거나 TW 감수 과정이 오래 걸린다.
백오피스에는 국문 콘텐츠가 빠르게 배포되지만, 영문 콘텐츠는 2~3주까지 딜레이되는 현상이 자주 발생했다. 그래서 이 경우에는 AI를 통해 국문 콘텐츠를 영문으로 빠르게 번역하여 배포되는 프로세스가 탑재되었고, 만약 번역된 콘텐츠에서 내용상의 이슈가 있다면 바로바로 수정 및 배포를 하는 프로세스로 수정되면서 국문 콘텐츠와 영문 콘텐츠가 동시에 1:1로 매핑되는 구조로 발전할 수 있었다.
임시 저장, 에디터 단축 기능, 목차 등의 다양한 편의 기능이 있으면 좋겠다.
백오피스의 인증 시스템은 MS 사내 인증 시스템을 사용하고 있기 때문에, 회사 사내 시스템을 왔다갔다 할 때 백오피스의 세션이 끊기는 현상이 가끔있다. 이때 게시글을 작성하다가 세션 초기화로 인해 저장이 안되고 사라지는 경우가 정말 가끔 있는데, 게시글의 소실을 방지하고자 임시 저장 기능을 탑재했다. 입력 이벤트를 디바운스를 통해 서버에 임시 저장하는 로직으로 만약 강제로 창이 닫히는 경우를 위해 로컬스토리지에 임시로 같이 저장하는 방식으로 여러 엣지 케이스를 방지했다.
목차의 경우에는 콘텐츠를 작성 하거나, 콘텐츠를 조회할 때 sticky 하게 사용자에 스크롤을 따라 자동으로 볼 수 있는 환경과 더불어, 백오피스의 내부 에디터는 CKEditor 를 사용하는데, 커스텀 핫키를 설정하여 에디터에서 제공하는 툴 메뉴에 대응되도록 모든 단축키를 설정했다.
그 외
위의 기능들 말고도 정~말 많은 편의 기능들과 여러 불편함을 해소하기 위한 노력들을 정말 많이했다. 그 전에는 사실 백오피스의 이슈가 많이 없었다. 3달에 1~2건 정도 있을까말까했는데.. 요새는 정기패치에 2~3개의 신규 기능이나 에로사항들을 패치하는 과정들을 수시로 진행하고 있다.
코드 상의 불필요하게 반복되는 코드들을 추상화하기
첫 직장은 에디터를 만드는 회사였는데, 오래된 레거시 코드들이 방대한 프로젝트였기 때문에 모듈화가 거의 되어있지 않는 상태였다. 한 파일에는 거의 몇천.. 만줄이 넘어가는 코드들이 정말 많았다. 그래서 그런지 백오피스 코드들을 확인했을 때 놀라지는 않았지만 붙여넣기를 한 파일들이 정말 많았고, SPA라고 보기에는 추상화되지 않는 컴포넌트와 훅(Vue에서는 Composable)이 정말 많았다. 궁극적으로 의사결정의 최종안으로는 컴포넌트들은 디자인 시스템 기반의 인터널 컴포넌트로 추상화를 진행하였다. 그리고 내부 로직들은 훅(Composable)을 통해 추상화하였고, 스크립트는 함수형(Composition) 기반의 스크립트들로 변경을 하였다.
Vue2의 Options API를 Mixin으로 추상화하기
반복되는 코드 구조들이 너무 많다보니, 이 로직들을 어떻게 추상화할 수 있을까 고민을 하였다. 그러다 Vue2에서 제공하는 mixin 구조를 알게 되었고, vue 인스턴스의 내부 상태들을 공유하면서 여러 코드들을 추상화시킬 수 있었다.mixin 을 사용하게 되면
그런데 여기서 문제는, mixin 을 사용하게 되면 내가 원치 않는 코드까지도 같이 코드 베이스를 가져오는 상황이기 때문에, 모듈처럼 원하는 코드만 가져오고 싶었다. Vue2에서는 이를 지원하지 않기 때문에 코드 베이스의 가독성과 효율성을 높이고자, 또 Vue2의 deprecated 소식을 듣고 보안을 위한 메이저 업데이트를 강행하게 된다.
Vue3의 Composition API를 Composable로 추상화하기
Vue3는 좀 신선했다. React가 16과 17을 경게로 클래스 문법과 함수형 문법으로 나누어졌다면 Vue2와 Vue3도 이와 비슷하다. <template/> 문법을 제외하고는 Vue3도 함수형 스크립트로 제공을 하기 때문에 React와 방향성이 흡사하다고 느껴졌다. Vue2의 mixin 에서 일부 코드만을 필요로하지만 추상화한 모든 파일을 가져오는 고질적인 문제도 composable 코드로 해소할 수 있었다.
Vuetify UI 라이브러리에 극 의존되어있는 서비스
Vue2에서 Vue3로 마이그레이션을 진행하면서, Vuetify UI 또한 같이 업그레이드를 해야하는 상황이 발생했다. Vuetify에 모든 유저 인터페이스가 강하게 결합되어있는 서비스이다보니, 실상은 Vue 의 버젼 업그레이드보다 Vuetify의 메이저 업그레이드가 생각보다 버그도 많았고, 시간이 많이 걸렸다.
당시 백오피스에는 디자인 토큰이나, 커스텀 컴포넌트 개념이 거의 없다시피했기 때문에 정말 모든 코드가 예전 MFA 시절 코드로 멈춰있는 듯 했다. 그래서 Vuetify UI를 걷어내면서 자체적으로 유지보수하고, 쉽게 사용할 수 있는 디자인 토큰과 디자인 시스템을 만들고자 했다. 그 자세한 내용은 아래에서 추가로 설명하려고 한다.
디자인 시스템 기반의 컴포넌트로의 변신
위에서 언급했던 것처럼 백오피스에는 기획자도, 디자이너도 존재하지 않는다. 그래서 모든 것을 개발자가 드리븐해야했고, 그 결과로 유저 인터페이스 구조 또한 Vuetify UI 라이브러리 그대로 사용하며 당시 빠른 개발에 초점이 맞춰져있었다.
그 당시 사용에는 어려움이 없었겠지만, 기능이 점차 많아지고 백오피스에서 관리되어야하는 데이터가 많아짐에 따라 기능 구현 난이도도 올라가고 백오피스 개발자 입장에서는 기술 부채를 계속해서 탑처럼 쌓아가는 느낌이 들었다.
그래서 레이아웃을 구성할 때 단 하나의 단일 목표를 하나 세워보았다. 바로 "신기능을 Vuetify 없이 디자인 시스템 기반의 인터널 컴포넌트만으로 진행해보기로" 디자인 시스템 기반의 컴포넌트를 만들기 위해서 정말 다양한 레퍼런스를 확인했던 것 같다. 다행히 당근이나 토스 디자인 시스템 관련 문서들이 일부 노출이 되어있기도 해서 정말 많이 참고를 했다.
사실 혼자 구성하고, 혼자 도입한 영역이라 온전한 디자인시스템이라고는 할 수 없지만, 여러 레퍼런스에서 디자인 토큰들을 추출하고 다이얼로그, 모달 등을 도입하면서 온전히 정의해놓은 컴포넌트들을 손쉽게 가져다 쓸 수 있다는 점에서 스스로 느끼기에는 성공적이었다. 구축을 해놓으니, 이전에는 레이아웃 구성을 위해 Vuetify 컴포넌트 공식 홈페이지에서 어떤 속성 값들이 있는지 확인하는 과정과, 커스텀을 하기 위해 정말 많은 공을 들였다면 현재는 레이아웃 구성을 위해 정말 짧은 시간으로 인터널 컴포넌트만으로 구성을 할 수 있게 되었다.
단일 서비스이면서, 기능 도메인에 종속되어있는 컴포넌트라면 나중에 다른 서비스로 확장되었을 때 컴포넌트들을 다시 구성해야하는 상황이 발생한다. 디자인시스템과 이를 이용한 커스텀 컴포넌트들은 이러한 문제들을 손쉽게 해결할 수 있다. 또, 이러한 컴포넌트들을 구성해놓으면서 동시에 스토리북을 도입하게 되면 컴포넌트 별 테스트와 굳이 직접 해당 컴포넌트를 사용하는 기능에 접속하지 않아도 문서형태로 빠르게 찾을 수 있다. 백오피스에도 스토리북을 도입하였고, 스토리북을 따로 배포하여 사용을 하지는 않지만 로컬 서버에서도 충분히 컴포넌트를 확인하고 도입할 수 있는 환경이 되었다.
어떻게 변화되었을까?
꾸준히 개발을 하면서, 점진적으로 변화를 시켜나가는 과정을 진행했다. 혼자 백오피스 프론트엔드를 전반적으로 맡아 개발을 진행하면서 모든 기능들을 전부 변화시키기에는 신규 기능과 유지보수 이슈 대응을 못했기 때문이다. 블로그 글에 종적을 남기려고 이전 버젼들의 스테이징 환경을 확인해보니 생각보다 많은 변화가 있었다.
입사했을 당시의 백오피스
로그인 화면
홈 ㅡ 대시보드
자사 콘텐츠 목록 화면
자사 콘텐츠 상세화면
디자인 시스템 기반으로 리뉴얼된 백오피스
로그인 화면
홈 ㅡ 대시보드
자사 콘텐츠 목록 화면
입사했을 때의 백오피스와 확연하게 차이가 있고, 아래 텔레그램 채팅 정보 관리 기능의 경우에는 디자인 시스템 기반의 인터널 컴포넌트 만으로 각 컴포넌트 단위들을 빠르게 구현할 수 있었다.
신규 기능으로 추가된 텔레그램 채팅 정보 관리 화면
돌아보며
백오피스를 누가 시켜서 수동적으로 진행하는 것이 아닌, 스스로의 목표로 세우고 진행을 했다는 점에서 과정 자체가 너무 재미있었다. 다만 조금 아쉬운 부분들이 많긴하다. 내가 전문적으로 기획을 하거나, 디자인을 해본 적이 없기 때문에 (디자인은 대외활동에서 배운 적이 있긴하지만) 항상 농담처럼 백오피스에도 기획자나 디자이너가 필요하다고 말을 하곤했다. (사실 농담이 아니거 진담이다)
아쉬운 부분이 있긴하지만, 결과적으로는 만족할만한 결과를 얻을 수 있었다. 추상화된 로직과 컴포넌트들로 개발 시간이 정말 많이 단축될 수 있었고, 코드 라인 수도 효율화되어 많이 가독성이 늘어났다. 작가의 글이 애정이 많이 담긴 것처럼, 개발자에게도 코드에 많은 애정이 담겨야한다고 생각한다. 배달의 민족 사옥 안에 붙어있는 포스터인 "만드는 과정 자체가 수고스러워야, 사용하는 사람들이 편하다고.." 한 것처럼 이 말이 어떤 의미인지 개발을 하면서 점차 느껴가는 것 같다.
