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

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

토스에서 만드는 모든 제품의 기반이 되는 토스만의 디자인 시스템 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, 그 모든 경험을 위한 디자인 시스템

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


토스

토스 디자인 플랫폼 팀은 사용자 경험(UX)과 개발자 경험(DX)을 혁신하기 위해 토스 디자인 시스템(TDS)을 정의하고 제공하며, 특히 안드로이드 UX 엔지니어는 두 가지 경험 측면을 모두 다룹니다.

최고의 개발 경험을 위해 TDS 코틀린 DSL을 개발하여 레이아웃 구성 코드와 불필요한 코드 작성을 생략하고 비즈니스 로직에 집중하며 실험에 필요한 분기 코드 추가를 용이하게 합니다.

사용자 및 개발자 경험 파편화 문제 해결을 위해 DST(디자인 신택스 트리) 개념을 도입하여 모든 플랫폼이 동일한 스펙으로 화면을 구현하고, DST를 UI 코드로 자동 변환하는 도구를 개발하여 생산성을 높이고 일관된 디자인 시스템 사용을 유도합니다.

토스 박민수 엔지니어는 토스 디자인 플랫폼 팀에서 사용자 경험(UX)과 개발자 경험(DX)을 위해 어떤 고민을 하고 어떤 제품을 만들고 있는지 소개합니다. 이 팀은 **제품 경험의 퀄리티와 개발 생산성에서 혁신적인 임팩트를 내기 위해** 토스 디자인 시스템(TDS)을 정의하고 제공합니다.

UX 엔지니어들은 디자인 시스템 자체를 개발하거나, **디자인 시스템을 더 쉽고 간편하게 사용할 수 있도록** 각 플랫폼에 최적화된 인터페이스를 전달하는 역할을 수행합니다. TDS는 UI 컴포넌트뿐만 아니라 애니메이션 및 인터랙션 스펙까지 정리하여 사용자에게 단순하고 일관적인 경험을 제공합니다.

사용자 경험(UX) 측면의 디자인 시스템

사용자 경험 측면에서 TDS는 익숙한 디자인 시스템 개념을 따릅니다. 디자인된 UI 컴포넌트들을 개발하고, **각 컴포넌트의 기능 명세를 사일로 개발자들에게 코드로 제공**합니다. UI 컴포넌트는 형태, 기능, 고유의 애니메이션 및 인터랙션까지 함께 정의되어 개발자가 별도 고려 없이 모든 제품에서 동일한 동작을 볼 수 있습니다.

이렇게 구성된 디자인 시스템을 실제 코드에서 사용할 때, 개발자는 각 컴포넌트의 명세를 따르기만 해도 **동일한 퀄리티의 결과물을 만들 수** 있습니다. TDS 요소를 레고 블록처럼 쌓아, 모두가 쉽고 간단한 코드로 화면을 구성할 수 있게 합니다.

개발자 경험(DX) 개선: TDS 코틀린 DSL

기존 방식으로는 최고의 개발 경험을 제공하지 못한다고 판단했습니다. **잦은 실험과 검증에 따른 분기 추가가 번거롭고**, 화면 구성에 필요한 불필요한 레이아웃 파라미터나 보일러 플레이트 코드가 중복적으로 작성되었기 때문입니다. 이에 토스 디자인 플랫폼 팀은 **TDS 코틀린 DSL을 개발**했습니다.

DSL을 활용하면 레이어 구성에 필요한 성가신 코드들을 생략하고 **비즈니스 로직에 집중할 수 있는 코드를 만들 수** 있습니다. 또한 DSL 코드 내부에 코틀린 코드를 자연스럽게 작성할 수 있어 실험에 필요한 분기 코드나 간단한 연산 처리를 부담 없이 추가할 수 있게 됩니다. 이는 개발 프로세스에서 엔지니어링 경험과 생산성 향상에 초점을 맞춘 결과입니다.

초기 UX 엔지니어들은 UI 컴포넌트, 인터랙션 애니메이션 등 눈에 보이는 요소를 다루며, 플랫폼에 맞는 UI 스타일과 접근성을 고려해 최고의 사용자 경험을 제공하고자 노력했습니다. **TDS의 UI 요소들이 검증되고 널리 사용된 후에는 개발 경험까지 고민**하기 시작했습니다. 이는 TDS를 쉽게 사용할 수 있도록 GUI를 개발하거나, 특정 컴포넌트를 효과적으로 사용하기 위한 확장 함수를 구성하고 인터페이스를 최적화하는 작업을 포함합니다.

늘어나는 복잡성: 커뮤니케이션 비용 증가와 새로운 고민

두 가지 측면의 노력을 통해 높은 품질의 제품을 높은 생산성으로 개발 및 출시할 수 있었으나, **제품 증가와 메이커 인원 급증으로 인해 가이드 상의 회사 사안이 생겨나고 TDS 유즈케이스의 파편화**가 발생했습니다. 이는 디자인 시스템의 의도와 코드 간의 괴리로 이어져 기존에 비해 커뮤니케이션 비용이 증가하는 문제로 나타났습니다.

이러한 문제 속에서 사용자도 일관된 경험으로 서비스를 사용하고, 개발자도 일관된 경험으로 제품을 만들어 가는 방법에 대해 **새로운 고민을 시작**했습니다. 토스는 쉽고 간편한 금융 서비스를 지향하며, 수많은 메시지(문구, 배너, 푸시, 오류 메시지 등)를 통해 사용자에게 소통합니다.

UX 라이팅 시스템: 보이스톤 메이커

'5천 원 송금이 만료되었습니다'와 같은 문장은 불필요한 한자어, 수동형 표현, 딱딱한 어미 때문에 토스의 간편하고 캐주얼한 느낌과 거리가 있습니다. **명확한 커뮤니케이션과 더불어 전반적인 톤을 맞춰 누구나 쉽게 이해할 수 있는 소통**이 토스의 중요한 과제이자 목표입니다.

토스 디자인 플랫폼 팀은 친근하고 쓰기 쉬운 서비스를 제공하기 위해 이 과정을 시스템화하고 광범위하게 적용할 방법을 모색했으며, 그 결과 **UX 라이팅 툴인 '보이스톤 메이커'를 개발**했습니다. 보이스톤 메이커는 일관성 있는 토스의 보이스 톤을 위해 제품에 사용될 여러 문구를 간결하고 캐주얼하게 작성할 수 있는 규칙을 제공합니다.

보이스톤 메이커는 디자인 가이드 위에 토스의 보이스 톤에 맞지 않는 텍스트를 잡아내고 **대체할 수 있는 단어나 문장을 제시**합니다. 불필요한 한자어, 생략 가능한 단어를 수정/삭제하여 이해하기 쉽게 하고, 너무 긴 문장을 간결하게 고쳐줍니다. 또한 과도한 경어체, 문어체, 명령조 표현을 헤어체로 통일하거나 수동형 문장을 능동형으로 고쳐 친절한 느낌을 줍니다.

이 도구는 디자인 툴에서 디자이너가 제품을 디자인하는 시점에 활용되며, 기존 디자인 화면에서 워딩이 필요한 문구를 확인할 수 있도록 돕습니다. 하지만 수동적인 사용으로 인해 놓치거나 레거시 화면에 대응하지 못하는 경우가 발생하여, **새로운 제품 출시 후 라이팅 이슈가 발견**되곤 했습니다. 이에 더 많은 팀원이 토스 문구에 관심을 가질 방법이 필요했습니다.

이러한 규칙들을 개발자들도 활용할 수 있도록 **린트(Lint)로 만들었습니다**. 토스 코드에 작성된 리터럴 스트링 사이에서 토스 보이스 톤에 맞지 않는 표현들을 체크하여 디자인 이후 개발 단계에서도 보이스 톤을 한 번 더 검사합니다. 린트는 린트 픽스를 제공하고 여러 대체어를 제안하여 적절한 표현으로 교체할 수 있게 돕습니다. XML 코드에서도 동일하게 동작합니다.

개발자들은 문구를 다듬는 별도 과정 없이도 기존 제품을 유지보수하면서 자연스럽게 이슈를 확인하고 능동적으로 대응할 수 있게 되었습니다. 나아가 디자이너나 개발자가 아니더라도 모든 팀원이 앱을 구동하는 동안 보이스톤 메이커를 사용할 수 있도록 **오버레이 형태의 보이스톤 메이커를 개발**했습니다. 이는 실제 UI에 보이는 문구들을 각 제품 테스트 중에 확인할 수 있는 앱 내 도구입니다.

이 오버레이는 화면 구조에 영향을 주지 않기 위해 액티비티 최상위 레이어에 자동으로 얹어지며, 보이스톤 위반 케이스들이 런타임에 화면을 통해 링크되고 **모든 과정은 실시간으로 동작**합니다. 디버그 앱에서는 서버에서 제공하는 보이스톤 규칙을 앱 실행 시 API 싱크하여 항상 최신 상태를 유지합니다.

토스 디자인 시스템의 보이스톤 규칙은 단순히 단어를 대체하는 형태가 아닙니다. 내부 로직에 따라 **제목 텍스트 컴포넌트에는 마침표를 쓰지 않고, 단순 설명 텍스트 컴포넌트에는 마침표를 쓰도록 가이드**합니다. 이처럼 텍스트 컴포넌트의 성격에 따라 더 자연스러운 방향으로 가이드할 수 있도록 컴포넌트별 규칙과 로직을 별도로 관리합니다.

또한 같은 단어라도 문맥에 따라 예외가 적용될 수 있습니다. 예를 들어 한자어 표현이 더 명확한 커뮤니케이션에 도움이 되는 경우, **문장에서 함께 쓰인 단어들과 비교하여 의도한 조건에 맞는 경우 허용**됩니다. 보이스톤 메이커의 규칙이 고도화될수록 토스를 사용하는 수많은 사용자가 더욱 일관되고 간편한 금융 서비스를 경험하게 될 것으로 기대됩니다.

개발자 경험 파편화 문제와 DST 도입

새로운 시도와 노력으로 사용자 경험은 점진적으로 개선되었지만, **개발자 수 증가와 제품 스펙 확장에 따라 개발자 경험의 파편화가 발생**했습니다. 코딩 스타일 차이나 실수 등으로 동일한 동작을 하는 코드가 중복되거나, iOS, 웹, 안드로이드 플랫폼별로 다른 이름의 동일한 스펙이 혼재하는 경우가 많아졌습니다.

이에 토스 디자인 플랫폼 팀은 **DST(디자인 신택스 트리) 개념을 도입**했습니다. DST는 디자인된 화면을 기계가 해석할 수 있는 신택스 트리로 구성하는 것을 의미합니다. 잘 설계된 디자인 시스템을 활용하면 모든 플랫폼이 동일한 스펙의 인터페이스를 사용하게 되어 하나의 디자인 시스템으로 모든 플랫폼이 같은 화면을 구현할 수 있습니다.

디자인을 신택스로 표현하면 팀에서 정리한 룰에 따라 디자인 린트가 가능하며, **디자인 시스템이 의도하는 제품을 더욱 견고하게 개발할 수 있는 효과**를 기대할 수 있습니다. 예를 들어, 리스트 화면을 구성할 때 복잡한 비즈니스 로직이 있더라도 화면 구성을 크게 상단바, 스템, 시트 영역으로 나누어 트리로 만들 수 있습니다.

만들어진 트리는 정의된 설계 구조에 따라 최종적으로 **JSON 형태로 표현되어 각 플랫폼에 제공**되며, 같은 화면을 구성하는 인터페이스로 사용됩니다. 이벤트 핸들링, 상태 관리 스펙 등 서비스 흐름과 동작에 필요한 모든 내용이 DST를 통해 설계된다면, 토스는 DST를 완전하게 설계하여 **서버 드리븐 UI로 서비스를 배포하고 네이티브 앱 업데이트 없이 유연하고 빠르게 검증 및 대응**할 수 있는 비전을 가지고 있습니다.

모든 플랫폼이 같은 언어로 커뮤니케이션하고 DST가 UI로 변환되는 하나의 통로를 거친다면 **개발자들 사이의 유즈케이스 파편화도 자연스럽게 줄어들 것**으로 예상합니다. 이러한 발판으로 DST로 표현된 TDS 컴포넌트를 안드로이드 UI 코드로 변환하는 도구를 개발했습니다.

DST 코드 변환 도구: 생산성 향상

이 도구는 서버 드리븐 UI가 충분히 구성되기 전에 DST를 활용하여 코드를 자동으로 생성함으로써 **제품 생산성에 큰 도움**을 줍니다. 또한 이렇게 만들어진 코드를 기반으로 각 플랫폼에 종속적인 동작을 직접 추가 구현할 수 있도록 돕습니다. 이전에는 디자인 가이드의 속성들을 눈으로 확인하고 IDE에 직접 코드를 작성해야 했으며, 생소한 컴포넌트는 함수 판단이 어려워 불필요한 시간 낭비나 의도치 않은 유즈케이스를 만들곤 했습니다.

프레임워크 디자인 가이드의 예시 화면에서 '탑' 컴포넌트에 대한 DST JSON을 확인할 수 있습니다. 이 JSON에는 '탑' 컴포넌트의 상하단 텍스트 타입과 색상 등 디자인 가이드대로 컴포넌트를 보여주기 위한 **모든 속성이 포함**되어 있습니다. 하지만 토스 안드로이드 개발자는 이 내용을 알 필요 없이, DSD JSON 뷰어의 복사 버튼을 클릭하고 IDE에 붙여 넣기만 하면 됩니다.

복사한 JSON을 안드로이드 스튜디오 상에서 코틀린 코드에 붙여 넣으면 **DSD가 DSD DSL 코드로 변환된 상태로 옮겨집니다**. 개발자는 코드를 더 건드리지 않아도 적절한 컴포넌트를 구성할 수 있습니다. 필요한 임포트 라인들도 코드 상단 임포트 블록에 함께 추가되며, 이미 임포트된 패키지는 생략됩니다. 또한 DSD에 명시된 속성 중 구현상 기본값으로 지정된 속성이라면 이 또한 생략되어 불필요한 코드를 최소화합니다.

DSD DSL을 사용하지 않는 경우에도 XML에서 사용할 수 있습니다. 이 도구는 붙여 넣을 코드에 따라 다른 형태로 변환되기 때문에, 동일한 DSD JSON을 코틀린 코드가 아닌 XML 레이아웃 코드에 붙여 넣으면 XML 코드로 변환됩니다. 이때 **XML 코드가 추가될 위치에 해당하는 페어런트 레이아웃 태그를 감지**하고, TDS 컴포넌트의 성질에 따라 적절한 레이아웃 파라미터가 함께 변환됩니다. 예를 들어, 다른 컴포넌트에 붙여 놓은 상황에서 필요한 컨스트레인트 파라미터가 자동으로 추가됩니다.

DST 코드 변환 도구는 붙여 넣는 코드가 DST 변환에 맞는지 검증하여 오작동을 예방하고, 사람이 반복적으로 처리하는 요소를 최소화하기 위해 임포트, 레이어 파라미터 등의 값을 미리 추가해줍니다. 또한 TDS 컴포넌트의 각종 타입, 컬러와 같은 기본 값들을 최대한 생략함으로써, **UI 코드를 구성하기 위해 직접 조작하거나 추가해야 할 코드 양을 현저히 줄였습니다.**

그 결과 기계적으로 생성된 코드 위에서 개발이 이어지고 **TDS 컴포넌트를 사용하는 방법에 대해 자연스럽게 가이드**할 수 있게 됩니다. 이 도구는 안드로이드 스튜디오 플러그인 형태로 배포되어 필요에 따라 사용 여부를 결정할 수 있고, 개발자들이 개선 사항에 대한 업데이트를 쉽고 빠르게 받을 수 있습니다. 코드를 생성해준다는 점에서 새로운 제품 개발 시 생산성 측면에서 직접적인 도움을 주며, 특히 여러 번 검증해야 하는 제품에서 큰 도움이 됩니다.

UX 엔지니어에서 'X'로: 모든 경험을 위한 디자인 시스템

디자인 플랫폼 팀의 개발자들은 UX 엔지니어로서 TDX 컴포넌트 개발, 명료한 인터랙션, 접근성 고민 등 **최고의 사용자 경험을 위해 노력**해 왔습니다. 이제는 사용자들이 더욱 일관적이고 쉬운 금융 서비스를 경험할 수 있도록 디자인 및 개발 과정에서의 경험에 초점을 맞추고 있습니다.

UX 엔지니어는 모두가 같은 바탕 위에서 세상에서 가장 쉽고 빠르게 제품을 만들 수 있게 되는 모습을 상상하며 더 큰 꿈을 꾸고 있습니다. 그래서 더는 UX 엔지니어가 아닌 **'X(익스피리언스 엔진)'라는 새 이름을 가지고 토스 제품을 만들고, 사용자가 제품을 사용하는 '모두의 모든 경험'을 위한 디자인 시스템을 개발**합니다. 토스가 상상하는 모든 제품을 상상할 수 없는 속도로 만들게 되는 날까지 노력할 것입니다.

토스 디자인 플랫폼 팀이 사용자 경험과 개발자 경험을 혁신하기 위해 어떤 노력을 하고 있는지 설명해주세요.

TDS 코틀린 DSL은 개발자 경험 향상에 어떻게 기여하며, 기존 방식의 어떤 불편함을 해소했나요?

토스의 '보이스톤 메이커'는 어떤 문제를 해결하기 위해 개발되었으며, 디자이너와 개발자 모두에게 어떻게 활용되나요?

DST(디자인 신택스 트리) 개념은 토스 디자인 시스템에서 어떤 역할을 하며, 이를 통해 기대하는 효과는 무엇인가요?

DST 코드 변환 도구가 안드로이드 개발자의 생산성을 어떻게 향상시키는지 구체적인 예를 들어 설명해주세요.

제품 경험 퀄리티 및 개발 생산성 혁신을 목표로, 토스 디자인 시스템(TDS) 정의 및 제공.

UX 엔지니어는 디자인 시스템 자체 개발 및 사용 편의성을 위한 인터페이스 전달 담당.

TDS는 UI 컴포넌트를 넘어 애니메이션, 인터랙션 스펙까지 포함하여 일관된 사용자 경험 제공.

디자인 시스템 접근 방식: 사용자 경험(UX) 및 개발자 경험(DX)

사용자 경험 측면: TDS UI 컴포넌트를 개발하고 기능 명세를 코드로 제공.

UI 컴포넌트는 형태, 기능, 애니메이션, 인터랙션까지 정의되어 모든 제품에서 일관된 동작 보장.

레고 블록처럼 TDS 요소를 배치하여 쉽고 간단하게 화면 구성 가능.

기존 방식의 개발 경험 한계: 실험 분기 추가의 번거로움, 불필요한 레이아웃 파라미터 및 보일러플레이트 코드 중복.

TDS 코틀린 DSL 도입을 통한 개발자 경험 개선

DSL을 통해 레이어 구성 코드 생략, 비즈니스 로직에 집중, 실험 분기 및 연산 처리 용이.

이는 개발 프로세스에서 엔지니어링 경험과 생산성 향상에 초점을 둔 결과.

디자인 플랫폼 팀의 초기 UX 엔지니어링 노력

UI 컴포넌트, 인터랙션, 애니메이션, 접근성을 고려하여 최고의 사용자 경험 제공 노력.

TDS 요소가 검증된 후 개발 경험 개선 시작: GUI 개발, 확장 함수 구성, 인터페이스 최적화를 통한 기능 제공.

UX와 DX 모두 고려한 결과, 높은 품질의 제품을 높은 생산성으로 개발 및 출시.

성장 과정에서 발생한 문제점: UX/DX 파편화

제품 및 인원 증가로 가이드 상의 회사 사안 증가 및 TDS 유즈케이스 파편화 발생.

디자인 시스템 의도와 코드 간 괴리로 커뮤니케이션 비용 증가.

사용자와 개발자 모두에게 일관된 경험 제공을 위한 새로운 고민 시작.

토스의 UX 라이팅 문제점과 개선 필요성

수많은 서비스에서 다양한 메시지(제목, 배너, 푸시, 오류 등) 노출.

'5천 원 송금이 만료되었습니다' 문장의 문제점: 불필요한 한자, 수동형, 딱딱한 어미로 토스 톤과 불일치.

명확하고 쉽게 이해 가능한 톤앤매너의 커뮤니케이션이 중요 목표.

토스 보이스 톤에 맞춰 문장을 변경하여 간결하고 친근하게 의미 전달.

UX 라이팅 툴: 보이스톤 메이커 개발

일관된 토스 보이스 톤을 위해 제품 문구를 간결하고 캐주얼하게 작성할 수 있는 규칙 제공 도구.

디자인 가이드에서 보이스 톤에 맞지 않는 텍스트를 감지하고 대체어 제안.

불필요한 한자어, 생략 가능한 단어 수정/삭제, 문장 길이 간결화.

과도한 경어체/문어체, 명령조를 헤어체로 통일, 수동형 문장을 능동형으로 변경.

디자이너가 디자인 단계에서 활용하여 워딩 필요한 문구 확인.

보이스톤 메이커의 한계점과 개선 노력

디자인 단계에서 수동적 사용으로 누락 문구 및 레거시 화면 대응 미흡.

신규 제품 출시 후 앱 사용 단계에서 라이팅 이슈 발견, 더 많은 팀원의 관심 필요.

개발 단계에서 보이스 톤 검사를 위해 규칙을 린트로 제작하여 코드에 적용.

린트는 틀린 코드뿐 아니라 XML 코드에서도 동작하며, 린트 픽스를 통해 대체어 제안.

개발자들은 유지보수 중 자연스럽게 이슈 확인 및 능동적으로 대응 가능.

모든 팀원이 앱 구동 중 보이스톤 메이커를 사용할 수 있도록 오버레이 형태 개발.

오버레이는 UI에 영향을 주지 않고 실시간으로 보이스 톤 위반 케이스를 화면에 링크.

서버에서 보이스 톤 규칙을 API 싱크하여 항상 최신 상태 유지.

보이스톤 메이커의 고도화된 규칙 관리

컴포넌트별 로직 관리: 제목 텍스트 컴포넌트에는 마침표 금지, 설명 텍스트에는 마침표 사용 등.

문맥에 따른 예외 처리: 한자어가 더 명확한 커뮤니케이션에 도움 되는 경우 허용.

고도화된 규칙을 통해 사용자들에게 일관되고 간편한 금융 서비스 경험 제공 기대.

개발자 경험 파편화 문제와 DST(Design Syntax Tree) 도입

코딩 스타일 차이, 실수 등으로 같은 동작을 하는 코드 중복, 플랫폼별 다른 이름의 같은 스펙 혼재.

DST: 디자인된 화면을 기계가 해석 가능한 신택스 트리로 구성.

하나의 TDS로 모든 플랫폼이 같은 화면 구현, 디자인 린트 가능, 더 견고한 제품 개발.

화면을 트리 구조로 만들고 JSON 형태로 표현하여 각 플랫폼에 제공.

DST를 통해 화면 구성뿐 아니라 이벤트 핸들링, API 호출 등 서비스 흐름까지 설계.

토스 디자인 플랫폼 팀의 비전: DST를 완전 설계하여 서버 드리븐 UI로 배포, 네이티브 앱 업데이트 없이 유연하고 빠른 서비스 검증 및 이슈 대응.

모든 플랫폼이 같은 언어로 소통하고 DST를 통해 UI로 변환되면 유즈케이스 파편화 감소.

DST를 안드로이드 UI 코드로 변환하는 도구 개발

서버 드리븐 UI 구성 전 DST로 코드 자동 생성하여 생산성 향상, 플랫폼 종속적 동작 직접 구현 지원.

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

스크립트