안녕하세요. 토스 박민수입니다. 토스 디자인 플랫폼 팀의 엔지니어 로서 사용자 경험과 개발자 경험을 위해 어떤 고민을 하고 어떤 제품을 만들고 있는지 소개해 드리려고 합니다.

토스 디자인 플랫폼 팀은 제품 경험 퀄리티와 개발 생산성에서 혁신적인 임팩트를 내기 위해 달리는 팀인데요.

토스에서 만드는 모든 제품의 기반이 되는 토스만의 디자인 시스템 TDS를 정의하고 제공하는 일을 주로 다루고 있습니다.

UX 엔지니어들은 이 팀에 소속돼 디자인 시스템 자체를 개발하거나 디자인 시스템을 더 쉽고 간편하게 사용할 수 있도록 각 플랫폼의 가장 적합한 인터페이스를 전달하는 일을 하고 있습니다.

토스 디자인 시스템은 UI 컴포넌트를 구성하는 묶음을 넘어서 화면에서 보이는 여러 가지 애니메이션 혹은 인터랙션 스펙까지 정리해 사용자에게 최대한 단순하고 일관적인 경험을 제공할 수 있도록 합니다.

이때 안드로이드 UX 엔지니어는 사용자 경험뿐만 아니라 개발자의 경험까지 포함한 두 가지 경험 측면에서 디자인 시스템을 다루게 됩니다.

먼저 사용자 경험 측면의 디자인 시스템은 이미 익숙한 디자인 시스템 개념입니다.

TDS에 디자인된 UI 컴포넌트를 개발하고 각 컴포넌트들의 기능 명세를 사일로 개발자들에게 코드로 제공하게 됩니다.

UI 컴포넌트들은 그 형태와 기능은 물론이고 고유의 애니메이션과 인터랙션까지 함께 정의되기 때문에 개발자가 사용할 때 별도로 고려하지 않아도 모든 제품에서 같은 동작을 볼 수 있습니다.

이렇게 구성된 디자인 시스템을 실제 코드에서 사용할 때 각 컴포넌트의 명세를 그저 따르기만 해도 같은 퀄리티의 결과물이 만들어질 수 있고요.

마치 레고 블록을 쌓듯이 TDS 요소들을 위에서 아래로 배치해서 모두가 쉽고 간단한 코드로 화면을 구성할 수 있습니다.

하지만 이것으로는 최고의 개발 경험을 제공하지는 못했다고 생각했습니다.

모든 제품을 자꾸 빠르게 실험하고 검증하는 토스에서 실험에 따른 분기를 추가하기 너무 번거롭고 여전히 화면을 구성하기 위해 각종 레이아웃 파라미터나 불필요한 보일러 플레이트 코드들까지 중복적으로 작성했기 때문입니다.

그래서 TDS 코틀린 DSL을 만들었습니다.

TDS 컴포넌트들 대부분은 너비를 꽉 채워 내부에서 패딩을 관리하도록 정리되어 있는데요.

DSL로 구성될 경우 레이어 구성에 필요한 성가신 코드들을 생략하고 비즈니스 로직에 집중할 수 있는 코드가 만들어질 뿐만 아니라 DSL 코드 내부에 자연스럽게 코틀린 코드를 작성할 수 있어 실험에 필요한 분기 코드나 간단한 연산 처리를 부담 없이 추가할 수 있게 됩니다.

이건 사용자 경험이 아닌 개발 프로세스에서 엔지니어링 경험과 생산성 향상에 초점을 둔 결과물이라고 볼 수 있습니다.

정리하면 디자인 플랫폼 팀의 UX 엔지니어는 초기에 UI 컴포넌트나 인터랙션 애니메이션과 같이 제품 앞단에서 눈에 보이는 요소들을 다뤘습니다.

각 컴포넌트나 플랫폼에 맞는 UI 스타일을 적용하고 그 과정에서 고려해야 할 접근성 요소까지 고민하면서 최고의 사용자 경험을 위해 노력했고 지속해서 개선해 나가고 있습니다.

그리고 TDS의 각종 UI 요소들이 어느 정도 검증되고 완성되어서 제품에 널리 사용된 후로는 개발 경험까지 고민하기 시작했습니다.

앞에서 보신 것처럼 TDS를 쉽게 사용할 수 있도록 GUI를 개발하거나, 특정 컴포넌트를 더 잘 쓰기 위한 확장 함수를 구성하고 그 사이에서 인터페이스를 최적화하여 너무 과하거나 모자라지 않도록 제품에 딱 맞는 기능을 제공하는 일입니다.

이렇게 두 가지 측면을 모두 고민하고 힘써온 결과 적은 인원과 팀으로도 매우 높은 품질의 제품을 매우 높은 생산성으로 개발하고 출시할 수 있게 됐고 모두가 행복한 것처럼 보였습니다.

하지만 더욱 많은 제품을 출시하게 되고 개발자와 디자이너를 비롯한 메이커 인원이 빠른 속도로 많아지면서 제품에 새로이 발맞추기 위해 가이드 상에 각종 회사 사안이 생겨나고 개발해서의 TDS 유즈케이스 파편화 가 발생했습니다.

결과적으로 디자인 시스템의 의도와 코드의 괴리가 생기는 일이 잦아져 기존의 한정된 제품들에서 사용됐을 때에 비해 커뮤니케이션 비용이 증가했습니다.

이런 문제들이 커지는 상황에서 사용자도 일관된 경험으로 서비스를 사용하고 개발자도 일관된 경험으로 제품을 만들어 가는 방법에 대해 새로운 고민을 시작했습니다.

토스는 무엇보다 쉽고 간편한 금융 서비스를 지향하고 있습니다.

토스에는 수많은 서비스가 존재하고 그 모든 서비스를 사용하는 동안 수많은 메시지를 마주치게 됩니다.

단순히 제목에 보이는 문구, 배너에 보이는 문구 등은 물론 푸시 메시지와 각종 오류 메시지를 포함하면 셀 수 없이 많은 문장을 볼 수 있습니다.

예를 들어 '5천 원 송금이 만료되었습니다'라는 문장이 있습니다.

이 문장은 굳이 사용하지 않아도 되는 한자와 수동형 표현, 딱딱하게 느껴지는 어미 때문에 토스의 간편하고 캐주얼한 느낌과 거리가 있습니다.

명확한 커뮤니케이션이 가장 중요하지만, 전반적인 톤을 맞춰 누구나 쉽게 이해할 수 있는 커뮤니케이션을 하는 것도 토스의 매우 중요한 과제이자 목표인데요.

이 문장을 토스의 보이스 톤에 맞춰 남녀노소 쉽게 받아들일 수 있는 문장으로 바꿔봤습니다.

이를 통해 의미를 해치지 않으면서 훨씬 더 간결하게 커뮤니케이션할 수 있게 됩니다.

저희는 친근하고 쓰기 쉬운 서비스를 제공하기 위해 이 과정을 시스템화하고 광범위하게 거칠 방법을 고민했습니다.

그래서 디자인 플랫폼 팀은 토스의 UX 라이팅 툴인 보이스톤 메이커를 개발했습니다.

보이스톤 메이커는 일관성 있는 토스의 보이스 톤을 위해 제품에 보일 여러 문구를 간결하고 캐주얼하게 쓸 수 있는 규칙을 제공하는 도구입니다.

실제로 보이스 톤 메이커가 프레임워크 상에서 동작하는 모습입니다.

보시는 것처럼 디자인 가이드 위에 토스의 보이스 톤에 맞지 않는 텍스트를 잡아내 대체할 수 있는 단어나 문장을 보여줍니다.

우선 불필요한 한자어 표현이나 생략이 가능한 단어를 체크해서 더욱 이해하기 쉽도록 한결 표현으로 수정 혹은 삭제할 수 있도록 하고 너무 긴 문장이 되지 않도록 간결한 표현으로 고쳐질 수 있습니다.

또 경어체와 문어체를 과도하게 사용하거나 명령조로 작성된 의미를 헤어체로 통일하거나 수동형 문장을 능동형 문장으로 고쳐 더 친절한 느낌의 문장으로 만들어 줍니다.

이는 디자인 툴에서 디자이너가 제품을 디자인하는 시점에 활용되고 기존의 디자인된 화면에서 워딩이 필요한 문구를 확인할 수 있도록 합니다.

하지만 프레이머나 보이스 톤 메이커는 디자인 단계에서 수동적으로 사용되기 때문에 이때 확인하지 못하고 넘어가는 문구나 기존에 출시된 레거시 화면들에 대해 충분히 대응하지 못하는 경우가 생깁니다.

그러다 보니 새로운 제품이 출시된 이후에 실제 앱을 사용하는 단계에서 라이팅 이슈가 발견되고 더 많은 팀원이 토스의 문구에 관심을 가질 방법이 필요했습니다.

그래서 이 규칙들을 개발자들도 활용할 수 있도록 린트로 만들었습니다.

토스의 코드 상에 작성된 리터럴 스트링 사이에서 토스 보이스 톤에 맞지 않는 표현들을 체크해 디자인 이후 개발 단계에서도 보이스 톤을 한 번 더 검사할 수 있도록 합니다.

이렇게 잡아낸 케이스들은 린트 픽스를 보여주고 적절한 표현으로 교체할 수 있도록 여러 가지 대체어를 동시에 제안하고 있습니다.

이 린트는 잡아놓고 틀린 코드뿐만 아니라 XML 코드에서도 동일한 방식으로 동작하게 됩니다.

덕분에 문구를 다듬는 별도 과정이 아니더라도 개발자들의 기존 제품을 유지보수하면서 자연스럽게 이슈를 확인하게 되고, 사일로 내에서 능동적으로 대응할 수 있습니다.

그리고 나아가서 디자이너나 개발자가 아니더라도 모든 팀원이 앱을 구동하는 동안 보이스톤 메이커를 사용할 수 있도록 인에이블 오버레이 형태의 보이스톤 메이커를 개발했습니다.

코드에 적용된 인트로직을 개선해 실제 UI 상에 보이는 문구들도 각 제품을 테스트하면서 확인할 수 있는 앱의 제 도구입니다.

이 오버레이는 화면 구조에 영향을 주지 않기 위해 액티비티 최상위 레이어에 자동으로 얹어지는데, 왼쪽에 보이는 스크린샷처럼 보이스톤 위반 케이스들이 런타임에 화면을 통해 링크되고 이 과정은 모두 실시간으로 동작합니다.

또 개발자용 디버그 앱에서 해당 도구를 활성화한 상태에서는 서버 에서 제공하는 보이스톤 규칙을 앱 실행 시 API 싱크해서 새로운 대체 어 규칙이 있을 때 항상 최신의 상태를 유지하도록 합니다.

토스 메이커의 토스 디자인 시스템 규칙은 단순히 일정한 단어를 가지고 대체어에 대응하는 형태가 아닙니다.

예를 들면 내부 로직에 따라 제목 텍스트로 판단되는 컴포넌트의 마침표가 쓰인 경우 마침표를 쓰지 않도록, 반대로 단순 설명 텍스트로 판단되는 컴포넌트의 마침표가 없는 경우 마침표를 쓰도록 가이드하고 있는데요.

이렇게 어떤 텍스트 컴포넌트인지에 따라 더 자연스러운 방향으로 가이드할 수 있도록 컴포넌트별 규칙과 로직을 별도로 관리하고 있습니다.

또 같은 단어라고 하더라도 어떤 문장에 사용했는지에 따라 예외가 적용될 수 있도록 합니다.

예를 들어 한글 대신 불필요한 한자 표현이 사용됐을 때 오히려 한자어 표현이 더 명확한 커뮤니케이션에 도움이 되는 경우 문장에서 함께 쓰인 단어들과 비교해 단어별로 의도한 조건에 맞는 경우 허용됩니다.

보이스톰 메이커에 단순 단어 규칙, 컴포넌트별 예측 예외 규칙 등이 충분히 고도화된다면 자연스럽게 토스를 사용하는 수많은 사용자가 더욱 일관적이고 간편한 금융 서비스를 경험하게 될 것으로 기대하고 있습니다.

이러한 새로운 시도와 노력을 통해 사용자 경험은 점진적으로 개선되고 있지만, 점점 많아지는 개발자들과 제품 스펙의 확장에 따라 개발자들의 경험에 파편화가 생겼습니다.

보시는 간단한 예시 코드처럼 코딩 스타일 차이 혹은 실수 등 여러 가지 이유로 같은 동작을 하는 코드가 생긴다거나, iOS와 웹, 안드로이드 플랫폼별로 다른 이름의 같은 스펙이 섞여 있는 일이 많아졌습니다.

그래서 저희는 DST라는 개념을 도입했습니다.

DST란 디자인 신택스 트리의 약어로, 디자인된 화면을 기계가 해석할 수 있는 신택스 트리로 구성하는 것을 말합니다.

잘 설계된 디자인 시스템을 활용하면 모든 플랫폼이 같은 스펙의 흰 텍스트 리를 인터페이스를 사용하게 되기 때문에 하나의 디자인 시스템으로 모든 플랫폼이 같은 화면을 구현할 수 있습니다.

또 디자인을 신택스로 표현하면 팀에서 정리한 룰에 따라 디자인 린트가 가능하죠.

디자인 시스템의 의도한 제품을 더 견고하게 개발할 수 있게 되는 효과를 기대할 수 있습니다.

리스트를 보여주는 간단한 화면을 구성한다고 가정해 볼까요? 화면을 그리는데 복잡한 비즈니스 로직이 존재하겠지만 화면의 구성을 크게 나눠보면 간단한 구조입니다.

크게 상단바 영역, 스템 영역, 시트 영역으로 나누고 트리로 만들면 이런 모습이 됩니다.

만들어진 트리는 정의된 설계 구조에 따라 최종적으로 JSON 형태로 표현 하고 이것이 각 플랫폼에 제공돼 같은 화면을 구성하는 인터페이스로 사용하게 됩니다.

간략하게 작성했지만 실제로 동작하는 제품을 형성하기 위해서는 각종 이벤트 핸들링, 상태 관리 스펙이 필요합니다.

단순히 화면을 구성하기 위한 뷰나 UI 레이아웃뿐만 아니라 이벤트 핸들링, API 호출과 같이 서비스 흐름과 동작에 필요한 모든 내용이 DST를 통해 설계된다면 어떨까요?

토스 디자인 플랫폼 팀은 DST를 완전하게 설계해서 토스가 만드는 서비스들을 서버 드리븐 UI로 배포하고 네이티브 앱 업데이트 없이 유연하고 빠르게 서비스를 검증하거나 이슈에 대응할 수 있게 되는 비전을 가지고 있습니다.

이렇게 모든 플랫폼이 같은 언어를 가지고 커뮤니케이션하게 되고 DST가 UI로 변환된 하나의 통로를 거친다면 개발자들 사이에서의 유즈케이스 발현도 자연스럽게 줄어들 거라고 생각합니다.

그 발판으로 DST로 표현된 TDS 컴포넌트를 안드로이드 UI 코드로 변환하는 도구를 개발했습니다.

서버 드립은 UI가 충분히 구성되기 전에 DST를 가지고 코드를 자동으로 생성해 제품 생산성에 큰 도움을 주고 이렇게 만들어진 코드를 기반으로 각 플랫폼에 종속적인 동작을 직접 추가 구현할 수 있도록 돕습니다.

이 도구를 사용하기 전에는 디자인 가이드에 명시된 속성들을 눈으로 확인하고 IDE에 직접 일일이 코드를 작성했습니다.

이 과정에서 생소한 컴포넌트들은 어떤 함수를 사용해야 할지 판단하기 어려워지고 결과적으로 불필요한 시간을 낭비하거나 의도하지 않은 방향으로 컴포넌트를 사용하게 되면서 알맞지 않은 유지 케이스가 만들어졌습니다.

이 화면은 프레임워크 디자인 가이드에 예시 화면입니다.

오른쪽에 '탑'이라는 TVS 컴포넌트에 대한 DST JSON을 확인할 수 있는데, 여기에는 '탑' 컴포넌트의 상 하단 텍스트 타입과 색상 등 디자인 가이드대로 컴포넌트를 보여주기 위한 모든 속성이 포함되어 있습니다.

하지만 토스 안드로이드 개발자는 이 내용을 알 필요가 없습니다.

DSD JSON 뷰어의 복사 버튼을 클릭하고 IDE에 붙여 넣기만 하면 됩니다.

복사한 JSON을 안드로이드 스튜디오 상에서 코틀린 코드에 붙여 넣기만 하면 DSD가 DSD DSL 코드로 변환된 상태로 옮겨집니다.

개발자는 코드를 더 건드리지 않아도 적절한 컴포넌트를 구성하는 데 문제가 없습니다.

이때 필요한 임포트 라인들도 해당 코드 상단 임포트 블록에 함께 추가되는데 이미 필요한 패키지가 임포트되어 있다면 생략됩니다.

그뿐만 아니라 DSD에 명시된 속성에 이미 구현상 기본값으로 지정된 속성이라면 이 또한 생략돼 불필요한 코드가 최대한 포함되지 않도록 합니다.

DSD DSL을 사용하지 않는 경우 XML에서도 사용할 수 있습니다.

이 도구는 붙여 넣을 코드에 따라 다른 형태로 변환되기 때문에 같은 DSD JSON을 코틀린 코드가 아닌 XML 레이아웃 코드에 붙여 넣으면 XML 코드로 변환됩니다.

이때 XML 코드가 추가될 위치에 해당하는 페어런트 레이아웃 태그를 감지하고 붙여 넣어질 TDS 컴포넌트의 성질에 따라 적절한 레이어 파라미터가 함께 변환되는데요.

예시 코드는 타 컴포넌트를 컨 스트레인트 헤어 단에 붙여 놓은 상황에서 필요한 컨스트레인트 파라미터가 자동으로 추가된 모습입니다.

일반적인 버튼처럼 너비를 꽉 채우지 않을 때에는 너비를 에 콘텐츠로 지정하고 컨스트레인트 파라미터도 그에 따라 적절히 추가될 것입니다.

DST 코드 변환 도구는 붙여 넣는 코드가 JS인지 DST를 변환할 JS인지 맞는지 검증해 오작동을 예방하고, 사람이 반복적으로 처리하는 요소를 최소화하기 위해 임포트, 레이어 파라미터 등의 값들을 미리 추가해줍니다.

또한 TDS 컴포넌트의 각종 타입, 컬러와 같은 기본 값들을 최대한 생략하게 되는데, 이 모든 과정을 거쳐 UI 코드를 구성하기 위해 직접 조작하거나 추가해야 할 코드 양이 현저히 줄어들었습니다.

그 결과 기계적으로 생성된 코드 위에서 개발이 이어지고 TDS 컴포넌트를 사용하는 방법에 대해 자연스럽게 가이드할 수 있게 됩니다.

이 도구는 안드로이드 스튜디오 플러그인 형태로 배포돼서 필요에 따라 사용 여부를 결정할 수 있고, 개발자들이 개선 사항에 대한 업데이트를 쉽고 빠르게 받을 수 있습니다.

코드를 생성해 준다는 점에서 새로운 제품을 개발할 때 생산성 측면에서 직접적인 도움을 주었고, 새로운 UI 를 여러 번 검증해야 하는 제품에서 특히 큰 도움이 되고 있습니다.

지금까지 소개해 드린 것처럼 디자인 플랫폼 팀의 개발자들은 UX 엔지니어 라는 이름으로 TDX 컴포넌트를 개발하고 명료한 인터랙션과 접근성을 위한 고민을 하는 등 최고의 사용자 경험을 위해 노력해 왔습니다.

이제는 사용자들이 더욱 일관적이고 쉬운 금융 서비스를 경험할 수 있도록 오히려 디자인 과정과 개발 과정에서의 경험에 초점을 두고 있습니다.

저희 UX 엔지니어는 모두가 같은 바탕 위에서 세상에서 가장 쉽고 빠르게 제품을 만들 수 있게 되는 모습을 상상하며 더 큰 꿈을 품었습니다.

그래서 더는 UX 엔지니어가 아닌 익스피리언스 엔진, 즉 'X'이라는 새 이름을 가지고 토스 제품을 만들고 사용자가 제품을 사용하는 모두의 모든 경험을 위한 디자인 시스템을 개발합니다.

토스가 상생하는 모든 제품을 상상할 수 없는 속도로 만들게 되는 날까지 감사합니다.

토스ㅣSLASH 22 - UX와 DX, 그 모든 경험을 위한 디자인 시스템

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


토스ㅣSLASH 22 - UX와 DX, 그 모든 경험을 위한 디자인 시스템

Scripts