안녕하세요. 토스 팀에서 안드로이드 앱을 개발하는 박민수입니다.

토스에서 제품을 개발하는 데 가장 큰 역할을 하고 있는 TDS를 저희 안드로이드 개발자들이 사용하는 방법, TDS를 통해 말 그대로 UI를 쌓는 과정에 대해 소개해 드리려고 합니다.

그 많던 코드는 누가 다 치웠을까요? TDS는 토스 디자인 시스템의 약자입니다.

토스에서 제품을 만들 때 모든 영역에서 공통적으로 사용하는 디자인 시스템으로, 훨씬 효율적인 과정으로 일관된 UI를 구현하기 위해 고안되었습니다.

뷰와 색상, 글꼴 등의 기본적인 스타일을 넘어 인터랙션과 애니메이션까지 같은 코드를 기반으로 제품을 구성하기 때문에 중복된 코드를 최소화하여 코드를 작성하는 절대적인 시간을 절약할 수 있습니다.

토스 안드로이드 프로젝트에서는 이러한 TDS를 별도 모듈로 관리하고 있어 토스의 다른 제품을 개발할 때에도 쉽게 적용이 가능합니다.

이제 구체적으로 TDS를 구성하는 핵심 내용을 소개해 드리려 하는데요.

크게 컬러와 리소스, 스타일, 컴포넌트 3가지 부분으로 나누어 설명 드리려고 합니다.

첫 번째로 색상과 각종 리소스에 관한 이야기를 먼저 드리겠습니다.

사실 이미 많은 팀에서 각자의 룰과 가이드에 맞게 적용하고 계시겠지만, 토스 팀에서는 유동적인 실험과 빠른 대응을 위해 어떤 고민을 했는지 공유하고자 합니다.

우선 저희는 컬러들을 팔레트화하여 사용하고 있습니다.

예를 들어 파란색은 블루라는 이름으로 뒤쪽에 진한 정도를 표시하고, 각각의 디자인 가이드에 대해서 색상 코드를 직접 찍어 보지 않고도 이름으로 커뮤니케이션할 수 있도록 관리합니다.

또 우측에 보시는 대로 데이와 나이트 모드 대응을 위해 같은 이름의 색상을 나이트 리소스로 별도 관리하여 데이, 나이트 각각 대응이 가능하도록 정의하고 있습니다.

컬러를 팔레트로 정리하여 사용하는 방식은 어느 정도 보편화된 방식이지만, 이렇게 규칙화된 팔레트는 단순히 이름을 알아보기 쉽다는 점을 넘어 더 강력한 힘을 발휘할 수 있습니다.

토스 팀에서 개발되는 모든 플랫폼은 같은 TDS 색상 이름을 바라보고 있습니다.

서버로부터 UI를 그리기 위한 색상을 전달받을 때 컬러 헥스 코드가 아닌 TDS 색상 이름을 내려받게 되고, 왜 iOS, 안드로이드 모두 공통된 이름을 기준으로 적절히 색상을 파싱하여 앱에 적용하고 있습니다.

이러한 규칙을 바탕으로 개발자들 사이에서의 커뮤니케이션뿐만 아니라 개발자와 디자이너, PO 사이의 UI 템플릿 커뮤니케이션도 훨씬 간결해질 수 있었고 TDS 팔레트에 업데이트가 있을 때 색상 값을 자연스럽게 갱신 할 수 있었습니다.

TDS 팔레트의 각 색상 값은 원격 서버에 존재하고 빌드 타임에 다운로드받아 리소스를 제너레이트하게 됩니다.

이때 다크 모드 대응을 위해 서버는 각각의 모드에 맞게 사전에 정의된 컬러들을 가지고 있기 때문에 앱이 현재 사용 중인 테마에 적절한 색상을 내려줄 수 있습니다.

서버 리소스를 싱크하는 방식은 현재 색상에 대해서만 우선 적용되어 있지만, 궁극적으로 색상뿐만 아니라 대부분의 리소스를 싱크할 수 있도록 계획하고 있습니다.

토스 제품들의 이미지는 크게 4가지로 구분됩니다.

모든 이미지 리소스는 토스 리소스 센터에 정의되어 있고 경우에 따라 벡터 이미지와 비트맵 이미지를 허용하고 있습니다.

주로 로고와 일러스트 이미지는 원형 그대로를 사용하며 아이콘, 노티 이미지는 TDS에 정의된 이미지 리소스의 틴트를 사용하여 다양한 용도로 활용할 수 있습니다.

각 이미지 리소스는 크게 분류, 형태, 스타일로 나뉜 이름 규칙을 따르고 일부 아이콘 리소스는 TDS 컬러 팔레트의 색상으로 틴트를 적용하여 자유로운 방식으로 강조하고 있습니다.

이렇듯 TDS에서는 규격화된 이름의 이미지와 컬러를 사용하여 효율적으로 리소스를 관리하고 커뮤니케이션할 수 있도록 합니다.

덕분에 디자인을 적용하는 과정에서 프로덕트 디자이너와 불필요한 약속을 하거나 규칙이 파편화되는 일이 현저히 줄어들고 자연스럽게 모든 플랫폼이 같은 모습으로 보일 수 있게 됩니다.

다음은 일종의 컴포넌트화된 각종 스타일에 대한 내용입니다.

TDS에서는 UI에 활용되는 각종 스타일 및 인터랙션 등까지 마치 개별적인 컴포넌트처럼 사용하고 있는데요.

토스 UI에 적용된 작지만 영향력 있는 디테일에 대해 이야기 드리려 합니다.

첫 번째로 예로 들 내용은 커스텀 된 둥근 모서리입니다. TDS에서는 버튼, 바텀 시트 등에서 원의 호로 처리하고 있던 기존의 둥근 모서리를 베지어 곡선을 그려내는 방식으로 구현해요.

토스만의 정체성을 높였습니다. 같은 높이의 뷰에 각 높이 절반의 레디우 스를 적용했을 때 서로 다른 느낌을 보여주는데, 이것은 단순히 TDS에 정의된 컴포넌트뿐만 아니라 앱 내에서 드로어블로도 사용할 수 있게 구현되어 어디서든 일관된 형태를 유지할 수 있도록 합니다.

모든 범위의 UI에 적용되어야 하므로 사일로 개발자들이 일일이 모서리를 잘라내는 것을 신경 쓰지 않도록 해야 했고, 해당 처리를 구현한 별도 커스텀 레이어로 처리하여 적용부의 사용 편리함을 극대화하였습니다.

이 과정에서 캔버스를 클리어 페인트로 직접 깎아내는 방식을 사용하여 성능에도 문제가 없는 컴포넌트로 개발하는 데 노력을 기울였습니다.

그다음 예시는 TDS의 스크롤 뷰입니다. 토스 앱에서는 어떤 뷰가 어떤 위치에 배치되어 있는지에 따라 상단과 하단에 페이딩 엣지를 다르게 적용해야 하는 일이 있는데요.

알아보기 쉽도록 페이딩 엣지가 적용된 영역은 파란색, 그렇지 않은 영역은 붉은색으로 표시해보았습니다.

예시의 이미지와 같이 상단에 검색창이 위치할 경우 스크롤 영역의 상단에만 페이딩 엣지를 적용한다거나 반대로 하단에 버튼이 위치할 경우 스크롤 영역의 하단에만 페이딩 엣지를 적용하는 형태입니다.

이를 위해 스크롤 뷰를 상속받아 각 방향의 페이딩 엣지를 이넘(Enum)으로 받도록 하는 TDS 스크롤 뷰를 구현해 사용하고 있습니다.

구현이 간단하기 때문에 새로운 화면에 이 내용을 적용하기는 어렵지 않았지만 이미 많은 영역에 TDS가 아닌 스크롤 뷰가 쓰이고 있었고 각 사일로에 수정을 일일이 요청하기에는 매우 번거로울 수밖에 없었습니다.

제가 TDS 개발을 맡게 되면서 가장 우선으로 생각했던 것은 무엇보다 기존의 동작하는 코드를 최대한 손대지 않고 문제를 해결하는 것이었고 그래서 커스텀 인플레이터를 사용하게 되었습니다 사일로의 앱 개발자가 과거 스크롤뷰로 구현하였던 레이아웃이 있다면 인플레이트 시점에 TDS 스크롤뷰로 대체될 수 있도록 하였습니다 가장 최소한으로 필요한 내용만 갖추어 인플레이트 될 때 호환성의 문제가 없게끔 개발되었고 해당 뷰에는 스크롤뷰뿐만 아니라 리사이클러뷰, TDS 스크롤뷰 등에도 적용하고 있습니다.

이를 통해 실제로 개발된 영역에 손대지 않고도 대부분의 기능에서 TDS가 요구하는 내용대로 동작할 수 있었고, 빠르게 적용한 덕분에 새롭게 정의된 가이드를 신속하게 전파할 수 있었습니다 그 밖에도 인터랙션과 관련한 내용으로는 대표적으로 TDS가 유저에게 가장 직접적으로 피드백을 주는 방법인 햅틱 피드백이 있습니다.

토스 앱에서는 더욱 명확한 커뮤니케이션을 위해 각 상황에 맞는 햅틱 피드백을 제공하며 확장 함수를 통해 어디서든 쉽게 사용할 수 있습니다 이는 매우 작은 동작임에도 불구하고 유저의 기전과 앱 이벤트가 소통하는 데 큰 역할을 하고 있습니다.

햅틱 피드백의 실제 구현 내용입니다.

사전에 정의된 4가지 타입의 패턴을 이용해 각 상황에 맞는 기기 진동을 발생시켜 유저가 현재 맥락을 더욱 쉽게 이해하기 쉽도록 합니다.

예를 들어 API 요청 및 처리에 실패했다면 이와 같이 실패 맥락을 강력하게 알려주는 패턴으로 유저의 주의를 끌고 그에 맞는 행동을 할 수 있도록 유도할 수 있습니다.

또한 TDS에서는 별도로 정의된 톤 앤 매너, 컬러, 타이포그래피 등의 전환, 노출 애니메이션에서 각 상황에 맞는 스프링 값들과 베지어 곡선으로 정교하게 정의된 인터랙션 툴을 사용하고 있습니다.

앱 전반에 일관성 있게 적용된 애니메이션은 앱 운용의 산만한 느낌을 줄여줄 수 있고, 각 사일로의 개발자들은 TDS 컴포넌트를 적절히 사용하는 것만으로도 자연스럽고 끊김 없는 인터랙션 구성이 가능합니다.

마지막으로 TDS의 이러한 디테일 요소를 담아 구현된 UI 컴포넌트 들에 대해 소개해드리겠습니다.

TDS에는 수많은 컴포넌트들이 있습니다.

단순히 어떤 교회의 스타일을 적용한 수준이 아니라 텍스트, 이미지 등 여러 가지 작은 단위로 쪼개어 구성한 TDS 컴포넌트들을 다시 새롭게 조합하고 연결하여 만들어진 최종 결과물로 보실 수 있습니다.

만일 컴포넌트의 추가적인 요소 혹은 기능이 필요할 경우 디자이너, 개발자 구분 없이 자유롭게 추가 요청을 할 수 있으며, 그 내용은 모든 플랫폼에 적용되므로 각자 필요한 형태로 구현하여 사용할 수 있게 됩니다.

모든 TDS 컴포넌트들은 앱 개발자가 더 이상 커스텀할 필요가 없고 디자인 적용에 필요한 모든 내용을 담고 있습니다.

또한 각 컴포넌트들의 이름과 개별 속성들은 실제 UI 디자인 가이드에 표기와 모두 대응되기 때문에 개발자는 디자이너와의 몇 가지 단어 단위의 커뮤니케이션만으로 완성된 UI로 쉽게 구성할 수 있습니다.

그렇다면 어떻게 UI가 구성될지 단계별로 보겠습니다. 우선 위에서 아래로 쌓는 UI를 위해 리니어 레이아웃을 준비합니다.

처음으로 탑 컴포넌트입니다. 탑 컴포넌트는 주로 화면의 상단에 배치되어 어퍼 텍스트로 텍스트 속성을 통해 타이틀 혹은 세부 설명 문구를 노출합니다.

상하단 텍스트는 각각 1부터 6까지의 사이즈 타입을 적용하게 됩니다.

그다음으로 배치된 검색창 UI인 서치 필드는 아이콘과 힌트 등의 속성을 조합하여 검색이 가능한 내용을 안내함과 동시에 검색어를 입력받는 컴포넌트입니다.

주로 리사이클러 뷰와 함께 사용되고 뷰를 초기화하는 함수를 통해 페이딩 엣지 등의 처리가 이루어집니다.

각 리스트에 표현할 내용을 구현한 리스트 로우입니다. 각 로우의 좌측, 중간, 우측 내용을 가이드에 맞게 보여줄 수 있습니다.

좌측에는 아이콘을 추가할 수 있고, 중간에는 주된 정보가 되는 내용을, 우측에는 꺽쇠 혹은 체크박스 등을 조합하여 용도를 구분합니다.

예시 코드로 편의상 단일 리스트 컴포넌트로 표현하였으나 실제로는 리사이클러 뷰 등과 함께 사용합니다.

하단의 CTA 버튼을 보여주는 픽스드 바텀 CTA 컴포넌트입니다.

CTA는 단일 버튼과 양자택일 버튼들로 구성할 수 있고 부가적인 텍스트 보충도 가능합니다.

예시 코드에서는 단일 버튼을 사용하였고 CTA를 구성할 때 리스너를 연결하여 보통의 버튼처럼 사용할 수 있습니다.

TDS 스크롤 뷰나 TDS 리사이클러 뷰 등과 사용할 때 CTA의 상단 영역에 페이딩 엣지를 보여주게 됩니다.

이 과정에서 보듯이 우측의 화면을 구현하는 데 필요한 TDS 컴포넌트는 단 4가지입니다.

예시 코드에는 구체적인 내용이 생략되어 있지만 각 컴포넌트의 몇 가지 함수나 속성을 적용하여 우측과 동일한 화면을 단지 쌓아가듯이 쉽게 만들어낼 수 있습니다.

이로써 저희는 이전보다 훨씬 빠른 속도로 고품질의 제품을 개발할 수 있게 되었지만 더 나은 형태의 TDS 코드를 작성하고 싶었습니다.

그렇게 TDS 도메인 특화 언어인 TDS DSL을 만들게 되었습니다.

TDS 컴포넌트들은 그 자체로 완성되어 있고 각 컴포넌트에 구현된 함수를 통해 적절한 구현을 할 수 있기 때문에 DSL화하여 가벼운 화면을 간결한 코드로 구성할 수 있도록 하였습니다 이 코드는 좀 전에 보여드린 TDS로 구현한 XML 코드입니다.

각종 레이아웃 프로퍼티들의 작성이 필요하기 때문에 소수의 컴포넌트들로 구성되었음에도 실제 레이아웃을 배치하기 위해 많은 코드를 작성하게 됩니다.

너비와 높이 지정만으로도 같은 형태의 코드가 두 줄씩 추가되고 유동적으로 문구를 교체하는 등의 간단한 수정도 추가하기가 용이하지 않습니다.

그래서 이와 같이 심플한 요소들의 조합으로 이루어진 화면을 TDSL로 구현해 보았습니다.

이전과 같은 구성의 XML을 TDSL로 변경한 코틀린 코드입니다.

간단하고 정적인 UI를 표현하는 데 용이하고 네 번째 라인에서와 같이 로직을 포함한 레이아웃 구성도 가능합니다.

위 코드 역시 생략된 코드가 존재하지만, 실제로는 각 컴포넌트별로 한두 가지 함수 호출을 통해 화면이 구성되기 때문에 불필요한 레이아웃 코드가 사라지게 됩니다.

실제 코드를 통해 비교해 본 모습입니다.

XML로 작성된 코드 역시 TDS 컴포넌트로 구성된 덕분에 작은 단위의 여러분들이 필요하지 않게 되었지만, 여전히 반복적으로 작성해야 하는 코드가 보입니다.

TDS에서는 이렇게 반복해야 하는 내용을 최대한 안으로 숨기고 실제로 UI를 보여주는 데 필요한 내용에 집중할 수 있어 같은 화면 코드라도 보다 읽기 쉽고 간결한 코드로 사용할 수 있습니다.

TDS DSL로 작성된 바텀 시트입니다. 아주 간단한 구성의 바텀 시트를 보여주는 데에도 레이아웃 코드와 바텀 시트 스타일로 구현 코드가 필요했었는데요.

위와 같은 DSL 코드를 통해 바텀 시트 생성부터 노출까지 쉽게 구현할 수 있습니다.

특별한 기능 없이 낮은 복잡도를 갖는 UI들은 로직과 함께 작성하면서도 복잡하지 않아 높은 생산성을 낼 수 있게 되어 아직 완전하지 않은 컨벤션임에도 불구하고 토스 제품에 많이 쓰이고 있습니다.

이제 주제의 물음에 답할 수 있을 것 같습니다. 제품 개발을 위해 수없이 작성한 코드는 누가 다 치웠을까요?

오로지 목표 달성을 위해 불필요한 고민을 하지 않도록 아주 사소하지만 필요한 중복 코드를 작성하면서 낭비되는 시간이 없도록 각종 실험과 이슈 대응에 빠르게 움직일 수 있도록 바로 TDS가 다 치워드렸습니다.

제 발표는 여기까지인데요. 디자인 시스템을 도입하고자 하시는 분들 혹은 토스에서 안드로이드 개발자들이 일하는 방식에 대해 궁금하셨던 분들께 도움이 되셨으면 좋겠습니다.

토스ㅣSLASH 21 - TDS로 UI 쌓기 : 그 많던 코드는 누가 다 치웠을까?

금융의 모든 것, 토스에서 쉽고 간편하게


토스ㅣSLASH 21 - TDS로 UI 쌓기 : 그 많던 코드는 누가 다 치웠을까?

Scripts