Razorpay: Figma를 통한 디자인 시스템 도입 확대 및 디자인-개발 간 협업 강화

Razorpay는 인도에서 가장 규모가 크고 빠르게 성장하는 금융서비스 기업 중 하나로, 1000만 개의 기업에 서비스를 제공하고 있습니다. 이 Q&A 세션에서 Razorpay의 디자인시스템팀과 이야기를 나누며 다음 사항에 대해 알아보았습니다.

• 디자인 시스템 도입 및 측정에 대한 접근 방식
• 디자인-개발 간의 협업에서 직면한 어려움
• Dev Mode와 비공개 플러그인으로 팀 작업 흐름을 개선한 방법
• Figma가 생산성 및 디자인 시스템 도입에 미친 영향

귀하의 팀과 플랫폼은 어떻게 구성되어 있나요?

Soni: 저희 팀에는 약 70명의 디자이너와 100명의 프론트엔드 개발자가 있습니다. 그 중 디자이너 3명과 엔지니어 5명이 디자인 시스템을 구축하고 있죠.

Kamlesh: Razorpay 플랫폼은 웹(데스크톱 및 모바일 웹) 버전과 iOS 및 Android 앱 버전이 있습니다. 하나의 디자인 시스템을 사용하는데, 동일한 API와 동일한 속성 세트로 크로스 플랫폼에서 작동합니다. 개발자가 웹에서 모바일 앱 개발로 전환하는 경우 웹 코드 정보를 모바일 앱으로 가져올 수 있습니다. 다른 플랫폼에 맞도록 재구축하는 데 시간을 허비하고 싶지 않아서 이러한 접근 방식을 택했습니다.

Razorpay의 디자인 시스템에 대해 알려주세요. 그리고 이 디자인 시스템이 중요한 이유도 설명해 주세요.

Soni: Blade는 Razorpay의 디자인 시스템입니다. 이 기능을 출시하기 전에는 버튼 상태나 텍스트 필드 내 오류 처리 방법과 같은 작은 세부 사항을 놓치기 쉬웠습니다. 각 팀이 모든 것을 직접 코딩하고 맞춤형으로 개발하려다 보니 실수로 중요한 요소를 빠뜨리는 경우가 생기기도 했죠.

그 결과 임시방편적인 반복 개발 작업이 많아졌고 고객 경험에 문제가 생겼습니다. Razorpay 제품처럼 기업들이 자금 관리를 맡기는 경우에 고객 경험은 매우 중요합니다. 원활한 제품 경험이 신뢰를 구축하는 데 도움이 되기 때문이죠.

또한 Razorpay는 다양한 분야의 여러 제품으로 구성된 브랜드이기 때문에 제품 전반의 다양한 사용자 인터페이스에서 일관성을 유지해야 합니다. 디자인 시스템과 공유 언어를 사용하면 처음부터 훨씬 더 민첩하고 유연하게 작업할 수 있습니다. 모든 Blade 사용자가 컴포넌트에 완벽하게 액세스할 수도 있고요.

Kamlesh: 디자인 시스템에서 작업하기 때문에 최종 사용자뿐만 아니라 개발자와 디자이너 모두가 우리의 고객입니다. Blade를 사용하면 모두가 같은 언어를 사용하기 때문에 팀 간의 마찰이 줄어들고 시장 출시 시간이 단축되죠. 디자인에 표시되는 내용이 코드에 그대로 반영될 수 있도록 디자인 시스템을 구축했습니다.

귀하의 팀은 어떤 방식으로 Blade를 도입했나요?

Kamlesh: 도입 과정이 모든 플랫폼에서 가장 어려운 일이었어요. 우리는 간극을 줄이고 도입을 장려하기 위해 다음과 같은 여러 조치를 취했습니다.

• 경영진의 지지 얻기: 디자인 시스템의 시작부터 팀에 대한 자금 지원, 소속 팀의 Blade 도입 독려에 이르기까지 경영진의 지지와 영향력은 디자인 시스템 성숙에 있어 매우 중요합니다.
• 주요 지표 파악: 내부 도구와 스크립트를 사용하여 Blade에 온보딩된 프로젝트 수 또는 디자인 시스템으로 개발된 앱의 비율과 같은 정성적 및 정량적 지표를 추적했어요. 이를 통해 경영진과 저희는 진행 상황을 더 쉽게 파악할 수 있었습니다.
• 적극적인 고객 지원: 고객이 질문을 남기거나 문제를 제기할 수 있는 업무 시간 및 Slack 채널이 있어요. 타당한 문제인 경우, 소비자팀에서 GitHub 이슈를 제기하고 우리 팀에서 이를 분류합니다. 또한 고객 옹호자 그룹을 구성했는데, 여기에는 소비자팀의 디자이너가 포함됩니다. 이들은 컴포넌트에 대한 의사 결정을 돕고 각자 팀 내에서 이를 지지하는 역할을 합니다.
• 조직 내 전도: 새로운 컴포넌트의 경우 시연 동영상으로 알리고 컴포넌트 상태 페이지를 업데이트합니다. 이 두 가지 모두 소비자팀이 디자인 시스템에 이미 존재하는 컴포넌트를 재생성하지 않도록 하는데 도움이 됩니다.

팀의 영향력을 어떻게 측정하고 있나요?

Kamlesh: 우리의 최우선 목표는 팀들이 Figma와 코드를 사용해 최소한의 노력으로 현대적이고 우아한 UI를 제공할 수 있도록 지원하는 것입니다. 이렇게 하면 나머지를 디자인 시스템이 해결하는 동안 팀은 제품 기능 개발에 집중할 수 있죠. 더 높은 수준에서, 새로운 기능은 디자인의 70%, 기존 제품은 디자인의 50% 이상을 Blade를 사용해야 한다는 목표를 설정했습니다. 이 KPI는 디자인팀과 개발팀이 동의한 것으로, 두 팀 모두 함께 이를 달성하기 위해 노력하고 있습니다.

그리고 실제 영향력은 디자인 단계에서 시작된다는 것을 깨달았어요. 디자인이 Blade 디자인 시스템 컴포넌트로 만들어지지 않으면, 개발자도 제품을 Blade로 구현해야 한다는 것을 알아차리지 못해요. 이를 해결하기 위해, 우리는 디자이너가 디자인 시스템에서 얼마나 벗어났는지를 보여주는 Blade Coverage 플러그인을 만들었습니다. 이 플러그인을 사용하면 디자이너는 출시 일정을 더 정확하게 예측할 수 있고, 사용하는 컴포넌트에 대한 피드백을 더 일찍 받아 인수인계 시 발생하는 마찰을 줄일 수 있습니다.

정량적 지표만으로는 디자인 시스템의 채택과 영향을 측정할 수 없기 때문에 내부 설문조사와 포커스 그룹도 활용하는 편이에요. 이를 통해 Blade가 팀이 더 빠르게 제품을 출시하는 데 도움이 되었는지, 팀의 도구 사용과 문서화 그리고 교육 세션 경험은 어땠는지, 디자이너와 개발자 간의 간극을 진정으로 줄이고 있는지 등의 심리를 파악할 수 있죠. 이 모든 것이 매년 추적하는 NPS(순고객추천지수)로 귀결됩니다.

Figma의 비공개 플러그인으로 디자인과 개발 간의 간극 해결

팀에서 Dev Mode를 사용하기 전에는 어떤 방식으로 핸드오프와 개발이 이뤄졌나요?

Kamlesh: 핸드오프 시, 개발자는 각 요소를 검사로 이동하고 그에 따라 속성을 복사해야 합니다. 하지만 Dev Mode를 사용하기 전에 이러한 작업은 바람직하지 않았고 성가신 일이었어요. 개발자는 우연히 올바른 컴포넌트에 도달할 때까지 클릭을 반복하여 컴포넌트를 파악해야 했고, 해당 속성을 확인한 다음 코드에서 동일한 것을 구현해야 했기 때문입니다.

이러한 검사의 비효율성을 해결하기 위해 개발자 중 한 명이 RazorSharp라는 비공개 플러그인을 만들었어요. 부수적인 프로젝트로, 구축하는 데 2~3개월이 소요됐습니다. RazorSharp를 통해 디자인에 해당하는 코드를 자동으로 생성할 수 있었습니다. 개발자는 그 코드를 간단히 복사하여 붙여넣기만 하면 되었죠.

RazorSharp 플러그인이 개발자들의 불편함을 해결하긴 했지만, 전부는 아니었습니다. Dev Mode 이전에는 파일에 대한 편집 권한이 있는 경우에만 Figma의 플러그인을 실행할 수 있었는데, 대부분의 개발자에게는 이 권한이 없었습니다. 즉, 디자이너가 Figma 파일을 건네주면 개발자는 새 파일에 복제하는 추가 단계를 거쳐야만 RazorSharp 플러그인을 실행할 수 있었죠.

Dev Mode를 통한 디자인 시스템 도입 가속화

변수를 포함하여 Dev Mode는 이러한 문제점을 해결하는 데 어떤 도움이 되었나요?

Kamlesh: 검사와 관련된 대부분의 문제가 사라졌어요. Dev Mode가 출시되었을 때, RazorSharp가 Dev Mode 플러그인으로 실행되도록 업데이트했는데, 개발자가 코드 구현을 확인하기 위해 파일을 편집할 필요 없이 플러그인을 사용할 수 있도록 하기 위해서였어요. 이미 기능이 구현되어 있었기 때문에 Dev Mode에서 호환되도록 만드는 데는 이틀밖에 소요되지 않았습니다.

또한 Dev Mode로 각 컴포넌트에 대한 Storybook 링크를 임베드하여 디자인 시스템 사용자가 해당 컴포넌트의 Storybook 코드 플레이그라운드로 쉽게 이동할 수 있도록 했습니다.

현재는 토큰을 변수로 변환하는 작업을 진행 중입니다. 아직 초기 단계이지만, 개발자들이 일하는 방식에서 몇 가지 이점을 발견하기 시작했어요.

디자인에서 코드로 토큰을 복사하는 작업도 이제 원활해졌습니다. 이전에는 토큰 이름에서 슬래시(surface/text/subtle)를 제거해야 했지만, 이제는 개발 친화적인 구조(surface.text.subtle)로 바로 지정할 수 있습니다. 또한 소비자팀에서 지속적으로 요청해 온 간격 토큰도 변수에 매핑되었고요.

별도의 작업 없이 라이트 모드와 다크 모드를 처음부터 다시 디자인하지 않고도 구현할 수 있게 되었어요. 이전에 Figma에서 Blade를 사용할 때 경험한 또 다른 문제는 각 컴포넌트에 대해 여러 모드(라이트/다크)와 여러 테마(결제/뱅킹)를 적용하면서 엄청난 메모리 소비가 발생했다는 점이었습니다. 이로 인해 시스템이 느려져 디자이너들의 작업 효율이 크게 저하되었죠. 그러나 변수를 도입한 이후, Blade를 하나의 테마로 통합할 수 있었고 디자이너들의 생산성이 크게 향상되었습니다.

Saurav: 작업 흐름 개선에 도움이 된 몇 가지 다른 기능도 있습니다. Visual Studio Code 플러그인을 사용해 개발자들이 Figma와 코드 사이를 오가며 맥락을 잃지 않고 코드를 작성할 수 있게 됐어요. 박스 모델을 통해 개발자들은 Figma 안에서 디자인을 코드와 더 가깝게 시각화할 수 있습니다. 또한, 변경 사항 비교와 버전 기록 덕분에 파일이 변경된 시점을 더욱 투명하게 파악할 수도 있죠. 이를 통해 개발자는 파일을 고정하고 작업 범위를 조정하여 막판 변경으로 인해 일정이 지연되는 상황을 방지할 수 있습니다.

생산성 향상 및 디자인 시스템 도입

이러한 변화가 팀에 어떤 영향을 미쳤나요?

Saurav: 디자이너와 개발자를 대상으로 설문조사를 실시한 결과, 80%가 Blade 디자인 시스템을 사용할 때가 사용하지 않았을 때보다 생산성이 높아졌다고 답했어요. Dev Mode는 디자인 시스템을 더 쉽게 이해하고 도입하는 데 중요한 역할을 했습니다.

Kamlesh: 아직 도입 초기 단계라 모든 개발자가 Dev Mode를 사용해 본 건 아니에요. 하지만 Dev Mode를 사용하기 시작한 개발자들은 디자인과 개발자 간의 마찰이 줄어들거나 전반적인 생산성이 향상되는 등 작업 흐름이 개선되는 것을 경험했습니다.

Razorpay가 디자인 시스템을 구축하고 유지 관리하는 방법에 대해 자세히 알고 싶으신가요? GitHub에서 Blade 디자인 시스템을 확인하거나 Razorpay Design 및 엔지니어링 블로그에서 모범 사례를 참조하세요. Razorpay의 디자인 블로그를 방문하거나 GitHub에서 Blade 디자인 시스템을 살펴보세요.

Figma의 코드 생성용 비공개 플러그인을 살펴보고 싶다면 Figma의 개발 문서를 확인하거나 GitHub에서 Figma의 코드 생성 플러그인 샘플을 사용하세요.