지금, 툴이 아닌 틀을 바꿔야 할 때

이 글은 디자인플랫폼팀 강수영, 황희영, 이병철, 박연주 님의 인터뷰를 바탕으로 작성되었습니다.

여러분은 지금, 어떤 툴을 이용해 모바일 제품을 디자인하고 계신가요? 

당연했던 비효율을 불편하게 느끼기 시작했다

불과 1년 전, 토스의 프로덕트 디자이너들은 스케치(Sketch), 피그마(Figma) 등을 이용해 제품을 디자인하고, 제플린(Zeplin)을 통해 개발자와 커뮤니케이션했습니다. 물론 (이 글을 보는 디자이너라면 모두 공감할) 불편함은 있었습니다. 예를 들어, 하나의 제품을 만들기 위해 가능한 모든 옵션의 컴포넌트를 만들거나 플로우를 보여주기 위해 화면을 수십 개 그려야 하는 일은 다반사였고요. 텍스트필드에 들어갈 글이 길어지면 수동으로 말줄임표 처리를 해주거나, 디자인 화면에서 1,000원이 넘어가는 금액을 표시할 때 세 자리마다 일일이 콤마를 찍어주는 것은 귀찮지만 당연한 일이었습니다. 

하지만 진짜 문제는 따로 있었습니다. 단순한 글자와 이미지의 나열만으로 디지털 제품의 속성을 제대로 표현할 수 없었던 것입니다. 디자이너가 스케치를 이용해 화면에 들어갈 버튼을 그려도, 그것만 보고 실제 모바일 환경에서 버튼을 누르면 어떤 화면으로 넘어가는지, 어떤 토스트가 나타나는지, 어떤 사운드나 햅틱이 나오는지를 알 수 없었던 거죠. 그러다 보니 디자이너가 상상하는 디자인을 개발자에게 설명해주기 위해서는 수많은 부가작업이 필요했고, 그런 노력에도 실제 개발된 화면은 디자이너가 상상하던 것과 다른 일도 부지기수였습니다. 

디자인이나, 플로우를 설계하는 데 집중하기보다 불편함과 비효율을 개선하는 데 더 많은 시간을 쓰면서 디자인 시스템을 만들던 토스의 디자인플랫폼 팀은 이런 생각을 합니다.

 ‘개발 컴포넌트를 그대로 잡고 위지윅(WYSIWYG)으로 디자인할 수 있는 툴을 만들면 어떨까?’ 그러니까 ‘탭 컴포넌트에 글씨를 쓰면 개발에서 구현되는 것처럼 자동으로 말이 줄여지면 안 되나?’ 같은 생각이 든 겁니다. 

새로운 툴(tool)을 도입하다

여러 가지 기술을 검토한 끝에, 현재 토스에서는 ‘프레이머(Framer)’라는 코드 기반의 툴을 이용해 제품을 디자인합니다. 디자이너가 코드를 알지 못해도, 개발에 구현되는 컴포넌트를 그대로 잡고 디자인할 수 있는 툴이 생긴 겁니다. 덕분에 디자이너는 코드로 구현된 컴포넌트로 화면을 디자인하고, 개발자는 개발 친화적인 환경에서 화면을 해석할 수 있게 되었습니다. 

프레이머에는 개발자와 디자이너의 역할이 확실히 구분되어 있습니다. 디자이너에게는 코드 없이 프로토타입을 만들 수 있는 툴이며, 공동 작업이 가능한 웹 기반의 UI 툴입니다. 개발자는 React 기반의 코드 컴포넌트를 배포하며 관리할 수 있고, Props를 직접 정해서 개발 환경과 똑같은 옵션을 디자인 툴에 구현할 수 있죠. 그렇기 때문에 프레이머를 이용하면 원하는 대로 프로퍼티(property)를 만들 수 있습니다. 기존 툴에서 디자이너의 의도를 글로만 표현할 수밖에 없었다면, 프레이머에서는 자동으로 경고 알림을 줄 수 있기도 하고요.

기존 디자인 툴은 이미지를 그리는 툴이기 때문에, 최종 결과물이 ‘비트맵’이라는 픽셀 단위의 결과일 수밖에 없었습니다. 그런데 프레이머는 픽셀 단위의 이미지가 아닌 실제로 움직이는 컴포넌트 단위로 디자인하기 때문에 개발자가 파싱(해석)을 할 수 있습니다. 이 말은 즉, 개발자가 디자이너의 의도를 추측하거나 일일이 물어가며 개발할 필요 없이 구조화된 디자인을 코드로 바로 옮길 수 있게 되었다는 의미입니다. 그뿐만 아니라 앱에서 코드로 구현할 수 있는 기능은 프레이머에서도 구현할 수 있기 때문에 디자이너도 다양한 생산성 기능을 상상만 하기보다 직접 만들어볼 기회가 생겼죠. 

인터랙션과 UI를 완벽히 합칠 수 있는 툴이기도 합니다. 사실 모바일에서 동작하는 모든 UI 요소는 인터랙티브한 성향을 가지고 있는데요. 기존 디자인 툴에서는 화면을 디자인한 후 프로토타이핑 툴로 옮겨 인터랙션 작업을 따로 해야만 했습니다. 한번 만든 인터랙션을 재사용한다는 개념도 없었고요. 하지만 프레이머의 모든 컴포넌트는 이미 인터랙션이 포함되어 있기 때문에 플로우 안에서 인터랙션을 설계할 수 있고, 변경사항을 빠르게 확인해볼 수도 있습니다. 스크롤, 터치, 피드백, 스와이프, 햅틱 등이 모두 동작하는 상태로 UI를 구성할 수 있게 된 겁니다.

이제 토스의 프로덕트 디자이너는 자신이 그린 화면이 모바일에서 어떻게 보이고 동작하는지를 바로 확인할 수 있습니다. 내가 그린 화면이 다크모드나 미처 챙기지 못한 모바일 기기에서 어떻게 보이는지도 확인할 수 있죠. 하나의 제품을 위해 수십 개의 화면과 수백 개의 컴포넌트를 그려야 하는 노동에서 벗어나, 제품의 플로우를 설계하는 데만 집중할 수도 있게 되었습니다. 프로토타입을 만드는 비율이 크게 늘었고, 그 과정에서 필요 없는 플로우가 빠지거나 사실은 필요했던 플로우가 들어오거나, 로딩을 고려하는 등 디지털 제품을 만드는 데 있어 진짜 필요한 고민을 할 수 있게 된 겁니다. 

혁신을 위한 토스팀의 extra-mile

하지만 단지 툴을 바꿨기 때문에 워크플로우에 변화가 생기고, 생산성이 높아진 것은 아닙니다. 토스팀은 네덜란드에 있는 프레이머 개발팀과 직접 의견을 주고받으며 더 나은 워크플로우를 만들기 위한 노력을 하고 있습니다. 

토스팀만의 자체 Hand-off^* 도구를 만든 것이 대표적인 사례인데요. 프레이머에도 자체 Hand-off 기능이 있지만, 기존에 사용하던 제플린을 대체하기에는 어려움이 있었습니다. 프레이머가 컴포넌트 단위로 선택이 가능하다 보니 컴포넌트 내부 요소에 대한 값은 보기가 어려웠고, hand-off에 표시되는 값도 너무 많아서 개발자가 확인해야 하는 TDS 속성만 따로 보기가 불편했어요. 토스 팀원들로부터 사용하기에 어려움이 있다는 피드백이 들어오자마자, 곧바로 Custom Hand-off를 만드는 작업에 들어갔습니다. 디자인 시스템에 정의된 언어로 속성 이름과 값을 보여주고 컴포넌트 내부의 요소도 선택할 수 있게 했죠.

^*hand-off는 디자인 시안을 개발자에게 전달하는 데 도움을 주는 협업 툴이다.

제플린을 처음부터 다시 만드는 수준의 작업이었어요. 요소 간의 거리를 재거나 겹친 레이어를 선택할 수 있게 하고, css 코드를 확인할 수 있게 하고, 화면 배율을 조정하며 이동할 수 있게 하고… 제플린에서 당연하게 사용했던 기능들도 새로 구현해야 했죠. 그럼에도 더 매끄러운 사용 경험을 만들고 싶은 욕심에 밤새 매달려 작업했고, 프레이머팀과도 긴밀하게 협업한 끝에 2주 만에 첫 버전을 내놓을 수 있었습니다.

토스만의 Hand-off 도구를 만들고 나니, 기존 Hand-off 도구가 제공하는 기능 이상으로 토스 개발자들의 불편함을 개선할 수 있는 가능성이 열렸습니다. 곧바로 개발자의 생산성을 높일 여러 기능을 고민하기 시작했는데요. 디자인 시안에서 TDS 컴포넌트를 쉽게 인지하고 선택할 수 있게 하거나, 놓치기 쉬운 텍스트 스타일을 알아보기 쉽게 만들고, 개발자에게 필요한 정보만 하이라이팅해서 보여주는 작업들을 했습니다. 그중에 요즘 가장 신경 쓰는 건, 개발에 바로 사용할 수 있는 코드를 생성하는 기능입니다. Hand-off 도구를 사용하는 근본적인 목적을 생각해 보면, 결국 디자이너가 디자인한 화면을 개발자가 코드로 옮기기 위한 것이거든요. Hand-off 도구에서 디자인 시안을 코드로 바로 확인할 수 있다면, 애초에 요소를 일일이 선택해가며 간격과 속성값을 확인할 필요도 없어지죠.

이것을 구현하기 위해서는 디자인 시안을 기계가 해석할 수 있는 형태로 표현해야 했습니다. 그래서 TDS를 이용해 만들어진 화면을 기계가 해석할 수 있게 구조적으로 표현하는 DST(Design Syntax Tree)라는 자료구조를 고안했습니다. 프레이머를 통해 디자인된 화면을 실시간으로 해석하여 DST로 표현하고, 이것을 다시 코드로 번역할 수 있게 만든 겁니다.

DST로 디자인을 구조화하여 표현한 덕분에 가능해진 것 중 하나가 ‘TDS Coverage Rate(커버리지 레이트)’ 계산입니다. 토스의 디자인 플랫폼팀에서는 프로덕트 디자이너분들이 TDS(Toss Design System)을 사용하도록 권장하고 있습니다. TDS를 사용하면 토스 사용자에게 통일성 있는 제품 경험을 전달할 수 있고, 디자인과 개발 생산성 모두 3~4배 좋아질 수 있기 때문입니다. 그런데 가끔, 어떠한 니즈에 의해 커스텀해서 쓰실 때가 있는데요. 이때 프레이머에는 커버리지 계산기가 있어 한 화면에서 TDS를 얼마나 썼는지를 확인할 수 있습니다. 덕분에 커스텀한 화면에서 권장하는 커버리지 레이트보다 낮게 나오면, 생산성이 낮아질 수 있다는 것을 화면을 설계할 때 넛지할 수 있는 거죠.

토스팀의 신뢰와 응원도 큰 도움이 되었습니다. 수많은 디자이너와 개발자가 사용하는 툴을 한 번에 바꾼다는 것은 정말 과감한 선택이었는데요. 완벽한 상태로 도입한 게 아니었고, 지금처럼 사용하기 편리하도록 만드는 데 6~7개월 정도 걸렸기 때문에 디자이너와 개발자 모두 불편한 점이 있었을 것으로 예상됩니다. 하지만 ‘이미 다 적응한 툴을 버리고 왜 새로운 것을 쓰는지’ 불만을 말하기보다 디자인 시스템을 만들고자 하는 디자인플랫폼팀의 이니셔티브에 공감해주시고 묵묵하게 기다려주신 덕분에 지금 토스팀이 사용하는 프레이머가 나올 수 있었다고 생각합니다. 

이제, 툴이 아닌 틀을 바꿔야 할 때 

툴이 아닌 틀을 바꾸는 토스팀의 도전은 이제 시작입니다. 저희의 궁극적인 미션은 디지털 제품을 만드는 환경을 바꿈으로써 디지털 제품의 패러다임을 바꿀 수 있는 틀을 만드는 것입니다. 그 과정에서 디자이너가 그림을 그리는 걸 넘어 가치를 디자인하는 환경을 만들 수 있을 테고요. 이를 위해 디자인플랫폼팀에서는 다양한 프로젝트를 준비하고 있습니다.

먼저, 개발자가 디자인 시안을 다시 구현하지 않도록 하게 하는 툴을 만들고 있습니다. 지금은 디자이너가 디자인 툴을 이용해 디자인하면, 개발자가 똑같은 레이아웃을 코드로 구현하는 생각해보면 비효율적인 방식으로 제품을 개발하고 있는데요. 토스만의 custom Hand-off^* 도구를 만든 덕에 디자인을 코드로 옮기는 과정에서 생기는 소통 비용과 반복적인 작업을 극단적으로 최적화할 수 있었어요. 개발자들은 반복적인 UI 작업에서 벗어나, 더 중요한 엔지니어링에 집중할 시간을 확보하게 되었죠. 이 hand-off 도구는 지금 이 순간에도 끊임없이 진화하고 있는데요. 앞으로는 UI 코드를 전혀 작성할 필요가 없는 수준까지 고도화하여 노코드 툴로 발전해나가는 미래를 꿈꾸고 있습니다. 

인터랙션 기능의 고도화도 준비하고 있습니다. TDS 컴포넌트마다 인터랙션을 붙이는 작업을 계속하는 한편, 인터랙션 디자인을 패턴화해 프로덕트 디자이너가 쉽게 인터랙션을 조합해 제품을 만들 수 있도록 ‘인터랙션 컴포넌트’를 구축하고 있는데요. 이 작업이 잘 진행된다면 전체 제품에 일정한 퀄리티의 인터랙션이 입혀질 수 있을 것으로 기대합니다. 

마지막으로 툴을 옮겨왔음에도 여전히 비효율적인 기존의 방식으로 제품을 디자인해야 하는 부분들이 있는데요. 근본적인 변화를 통해 ‘진짜’ 디자인 시스템을 만드는 것이 목표입니다. 디지털 제품을 만드는 환경을 바꿈으로써 디지털 제품의 본질을 바꾸는 것, 지금은 멀게 느껴져도 언젠가는 저희가 발견한 가치를 제대로 실현하는 날이 오지 않을까요? 

Edit 송수아