deFign : 네이버페이의 디자인 시스템을 정의하다
안녕하세요. 네이버페이 금융FE, 디자인시스템TF 소속 안재연입니다.
지난 6월 21일, 네이버페이 모바일 5탭이 오픈되었습니다. 네이버 증권과 부동산이 네이버페이 소속으로 변경된 후 네이버페이 하나로, 결제부터 금융까지 이룰 수 있는 첫 걸음을 떼게 되었습니다. 이와 함께 네이버페이의 모든 서비스를 한 눈에 볼 수 있도록 각 서비스 하단에 5탭 컴포넌트가 추가되었습니다.
‘모든 서비스에서 같은 컴포넌트를 보여준다면, 한 곳에서 개발하고 관리하는게 편하지 않을까?’라는 생각부터 출발하여 네이버파이낸셜의 모든 서비스에서 공통으로 사용할 수 있는 디자인 시스템을 설계하게 되었습니다.
이 글의 대상 독자는 디자인 시스템을 도입 예정이시거나, 도입하는 과정에서 방향성으로 고민하시는 분들 혹은 디자인 시스템에 관심을 가지고 계시는 분들입니다.
Design System
디자인 시스템이 무엇인지 생소하신 분들도 있을 것이라 생각합니다. Design은 말 그대로 화면의 UI를 어떻게 설계할 지 고민하는 것이고, System은 하나의 체계를 갖춘다는 의미입니다. 즉, Design System이란 화면의 UI 요소 중 공통 패턴과 주요 컴포넌트를 추출하여, 구성원들이 이를 효율적으로 사용하는 하나의 프로세스를 의미합니다.
네이버페이는 어떻게 디자인 시스템을 도입하게 되었을까요?
초기의 네이버페이는 운영하고 있는 서비스들의 규모가 그렇게 크지 않았기 때문에, 각 서비스에서 개선 요청 사항들을 각각 반영하고 있었습니다.
하지만 운영하는 서비스가 증가하고, 각 서비스의 규모가 커지면서 조금씩 문제 상황이 발생하기 시작했습니다. 동일한 UI임에도 각 서비스에서 UX 향상을 위해 추가한 개선 사항들이 서비스별로 조금씩 다른 동작, 조금씩 다른 코드들을 초래한 것입니다.
저희는 디자인 시스템 도입으로 위와 같은 상황을 개선하고자 했습니다. 사용자가 네이버파이낸셜의 모든 서비스에서 동일한 UI, UX를 경험할 수 있고, 개발자가 공통된 UI를 서비스에 쉽게 적용할 수 있도록 디자인 설계부터 마크업 조직, 개발 조직과 함께 기준을 세워 작업의 생산성 향상을 도모하였습니다.
우리가 만들고 싶은 디자인 시스템
디자인 시스템을 만드는 구성원들과 함께 이야기 해 보았을 때, 우리가 만들고 싶은 디자인 시스템의 키워드는 다음과 같았습니다.
#일관성 #효율성 #커뮤니케이션_기준 #공통_UI_라이브러리 #공통_인터랙션 #유연성 #확장성 #UX_가이드 #UX_Writing_가이드 #스토리북
키워드를 중심으로 대원칙을 설계하고 작업을 시작하게 되었습니다.
대원칙 1. 디자인 변경에 대한 파편화는 가급적 통제한다.
대원칙 2. 디자인 변경사항의 빠른 적용을 위한 구조를 설계한다.
대원칙 3. 각자의 생각과 노력은 하나의 언어로 표현하여 동일한 이해도를 가져간다.
디자인 시스템 작업 과정 살펴보기
디자인 시스템 작업 과정을 간단히 소개하면 다음과 같습니다.
- 컴포넌트 단위로 디자인을 설계하여 Figma에 추가합니다.
- 디자인 시스템 컴포넌트에서 사용하는 수치들은 디자인 토큰으로 추출하여 모든 서비스, 컴포넌트에서 함께 사용합니다.
- 컴포넌트는 디자인, 마크업, FE 조직이 함께 만듭니다.
디자인 토큰 추출하기
모든 서비스, 컴포넌트에서 공통으로 사용하는 디자인 토큰은 자동화하여 추출했습니다.
자동화 추출에는 Figma API와 Figma Plugin을 사용하였습니다.
- Figma API : https://www.figma.com/developers/api
- Figma Plugin : https://www.figma.com/plugin-docs/
개발에서 사용하기 편한대로 추출 형태도 다양화 하였습니다.
컴포넌트 개발하기
각 서비스에서 공통적으로 사용하는 UI는 사용성 검토 후 Figma 컴포넌트로 도출합니다. 디자이너가 컴포넌트와 variant(option)을 정의하면 마크업 개발자와 FE 개발자가 컴포넌트를 리뷰하고, 더 나은 사용성을 위해 variant와 디자인 등을 조정합니다.
이후 마크업과 FE 개발자들은 추출한 디자인 토큰을 활용하여 컴포넌트 개발을 시작합니다. 이때 엣지 케이스 대응, 디바이스 분기, 에러 케이스 대응을 추가하여 최대한 많은 경우를 커버할 수 있도록 개발합니다.
스토리북으로 컴포넌트를 사용하는 개발자들의 생산성 향상
만들어진 컴포넌트와 디자인 토큰은 스토리북을 통해 쉽게 형상을 파악할 수 있도록 하였습니다. 다양한 서비스에서 사용하는 만큼, 각 서비스마다 다른 버전을 사용할 수 있어 버전 별로 스토리북 확인이 가능하도록 기능을 추가해두었습니다.
공통 인터랙션 혹은 hook 사용이 필요한 컴포넌트의 경우 Docs를 보다 구체적으로 작성하였습니다. 사용법과 사용 예시를 모두 첨부하여 Docs만으로도 손쉽게 컴포넌트 적용이 가능합니다.
Footer 컴포넌트 개발기
deFign에 대한 소개에 이어 FE 개발자로 디자인시스템 Footer 컴포넌트를 개발하고 출시하기까지의 과정과 경험을 공유합니다.
1. 디자인 전달
Footer 컴포넌트는 네이버페이 모든 서비스 최하단에 노출되는 컴포넌트입니다. 각 서비스마다 노출되는 정보가 다르기 때문에 디자이너분께서 모든 케이스를 정리해서 figma로 공유해주셨습니다.
2. 초기 인터페이스 고민
처음 전달받았던 Footer 컴포넌트는 FooterQuickMenu 컴포넌트와 FooterInfo 컴포넌트로 구성되어 있었습니다. 서비스 별로 노출할 정보를 기준으로 어떤 정보를 props로 받아야 하는 지, static한 정보로 보여주어야 할 지 고민했습니다.
제가 초기에 생각했던 인터페이스는 다음과 같습니다.
- FooterQuickMenu : 메뉴 종류와 개수는 서비스마다 다르니, 메뉴 List를 props로 받아서 노출하는 형식
// FooterQuickMenu props 예시
const props = [
{
title : '로그아웃',
},
{
title : '면책조항',
tooltip : true, // 메뉴에 툴팁을 노출하는 케이스
tooltipIcon : <TooltipIcon />,
}
]- FooterInfo : 법적 고지도 서비스마다 달라 props로 받기 / 사업자 정보는 동일하기 때문에 static
3. 디자인시스템 팀원들과 함께 인터페이스 의논해보기
제가 고민한 인터페이스가 완벽하지 않을 수 있기 때문에, 팀원들과도 함께 검토해 보았습니다.
팀원들은 Footer에서 노출하는 정보가 각 서비스마다 하나로 고정된다면, 서비스 type만 props로 받고 필요한 정보는 디자인 시스템에서 모두 제공하는 것이 더 사용성이 좋겠다는 의견을 제시해주었습니다. 또 Footer는 사용처에서 굳이 FooterQuickMenu, FooterInfo를 각각 선언해서 사용할 필요가 없으니 Footer 컴포넌트 하나로 사용자에게 제공하는 것이 어떻겠냐는 의견을 주셨습니다.
그리하여, 최종 Footer의 인터페이스를 다음과 같이 정할 수 있었습니다.
<Footer
type='stock' // type으로 각 서비스의 타입 전달
overrideMenu={{ // 기존에 노출되던 메뉴의 title, url 등을 수정할 때 전달
'전체서비스': {
url: 'https://new-url.naver.com'
}
}}
/> Footer 컴포넌트 뿐만이 아니라, 모든 컴포넌트 제작 과정에서 인터페이스를 다 함께 고민하였었는데, 이 과정 덕분에 더 좋아진 사용성을 가진 컴포넌트를 제작할 수 있었던 것 같습니다.
4. 예상치 못했던 예외 케이스의 등장
계획한 대로, 예상한 대로 모든 일이 진행된다면 정말 좋겠지만 그렇지 않은 것이 현실입니다. Footer 컴포넌트를 개발할 때도 예상치 못했던 예외 케이스가 등장하였습니다.
Footer 컴포넌트에서는 각 서비스의 type만 전달받기로 하였는데, 부동산에서만 각각 다른 8개의 Footer가 필요하다는 요청이 추가된 것입니다. 기존의 인터페이스에서 overrideMenu prop을 제공하였지만, 현재 노출되고 있는 메뉴의 title, url 정도만 수정이 가능하고 새로운 메뉴를 추가할 수는 없었기 때문에 overrideMenu 를 활용할 수는 없었습니다.
처음에는 type을 8개를 추가해야 할까 고민하였습니다. 하지만 공통적인 부분만 부동산 type으로 제공하고, 수정이 필요한 menu는 custom해서 사용할 수 있도록 overwriteMenuList prop을 열어주는 방향으로 진행하게 되었습니다.
<Footer
type='realEstate'
overwriteMenuList={[
{
title: isLogin ? FOOTER_QUICK_MENU_TITLE.LOGOUT : FOOTER_QUICK_MENU_TITLE.LOGIN,
href: '#',
onClickLogin: () => {
alert('클릭 로그인');
},
onClickLogout: () => {
alert('클릭 로그아웃');
},
},
{
title: FOOTER_QUICK_MENU_TITLE.ALL_SERVICE,
href: isMobile ? URL.ALL_SERVICES.MOBILE : URL.ALL_SERVICES.PC,
},
FOOTER_QUICK_MENU_ITEM_MAP.realEstate['약관 및 정책'], // Footer에서 기본으로 사용하던 요소는 export 해 두어, 사용처에서 쉽게 재선언이 가능하도록 했습니다.
]}
/>5. 적당히 열리고 적당히 닫힌 인터페이스
overwriteMenuList prop을 추가할 때 부동산 서비스 개발자분께서 ‘overwriteMenuList를 사용하려면 Footer에서 기본으로 사용하는 모든 menu들도 재작성해야하나요?’라는 질문을 해주셨습니다.
서비스별로 공통적으로 사용하는 menu라면 상수로 선언한 후에 export 해 두면, overwriteMenuList를 사용하더라도 각 서비스에서 모든 menu를 재작성할 필요 없이 필요한 것만 import하여 간편하게 사용할 수 있겠다는 생각이 들었습니다. 그래서 추가된 것이 위 예시의 FOOTER_QUICK_MENU_ITEM_MAP 입니다. 원하는 메뉴는 이미 FOOTER_QUICK_MENU_ITEM_MAP 에 선언되어 있으니, 가져다 쓰기만 하면 됩니다.
이처럼, Footer를 만들면서 어떻게 하면 사용처에서 조금 더 쉽게 사용할 수 있을까를 많이 고민하게 되었습니다.
너무 열어준 인터페이스를 제공하면, 디자인 시스템 Footer는 공통된 마크업만 전달할 뿐, 사용처에서는 모든 정보를 직접 선언해서 사용해야 했습니다. 사실상, 이미 각 서비스에서 사용하고 있던 Footer와 별반 다를게 없었죠.
반면 너무 닫힌 인터페이스를 제공하면, 위의 부동산 Footer의 경우처럼 예상치 못한 케이스에 당황하는 사태가 발생하게 됩니다.
그래서 인터페이스를 제공할 때 많은 고민과 대화를 했었습니다. Footer 컴포넌트를 만들면서 느낀 점은, 각 서비스의 개발자 분들과 대화를 하면서 적당히 열림과 적당히 닫힘 사이의 인터페이스를 함께 만들어 나가야 한다는 것이었습니다. 열림과 닫힘 사이 딱 좋음이란 기준은 너무나도 주관적이어서 제가 결정할 수 있는 것이 아니더라구요. 서비스 개발자 분들과 꾸준히 대화를 하면서 어떻게 하면 더 편하게 사용할 수 있을까를 끊임없이 물어보았던 과정이 더 나은 인터페이스를 가능하게 해주었다고 생각합니다.
deFign : 네이버페이의 디자인 시스템을 정의하다.
이런 과정을 거쳐 하나둘씩 만들어진 네이버페이의 디자인 시스템이 바로, deFign입니다. 네이버페이의 디자인 시스템을 정의한다는 의미를 담고 있습니다. (사담이지만, 이름이 정말 마음에 듭니다🥰)
2023년 6월 21일 네이버페이 모바일 5탭 서비스를 오픈에 맞추어 모든 서비스에 디자인 시스템 컴포넌트들이 적용되었습니다. 이제 공통된 컴포넌트는 모두 deFign에서 설계, 개발, 관리됩니다.
deFign의 도입으로 네이버페이의 어떤 서비스를 이용하더라도, 같은 UI와 사용성을 가진 컴포넌트를 마주할 수 있어 사용자 경험은 보다 향상될 것입니다.
또한 각 서비스의 개발자 역시 반복되는 비슷한 코드의 추가, 분기문 추가의 지옥을 벗어나 보다 효율적인 개발 life가 가능해 질 것입니다.
앞으로의 deFign
저희 deFign 팀은 version 1.0.0 오픈에 이어 Phase 2도 준비하고 있습니다. 더 많은 UI의 공통화, 동일한 언어로의 설계를 이루어 많은 디자이너와 개발자의 생산성 향상에 힘 쓸 예정입니다.
이와 함께 통계 시스템을 구축하여, 사용자가 어떻게, 얼마나 디자인 시스템을 사용하는지에 초점을 맞추어 방향을 설계할 계획입니다.
더 발전할 deFign 기대해 주시길 바랍니다!
긴 글 읽어주셔서 감사합니다.
