안녕하세요. 토스 인터랙션 팀 리더이자 인터랙션 디자이너 박현주입니다.

안녕하세요. 토스 인터랙션 팀에서 프런트엔드 UX 엔지니어로 일하고 있는 박은식입니다.

이번 세션에서는 크게 두 가지를 설명드리려고 해요. 첫 번째는 저희 인터랙션 팀에서 인터랙션 디자이너와 개발자가 어떻게 소통하는지.

그리고 두 번째로는 인터랙션 디자이너가 없는 제품 팀에 있는 프로덕트 디자이너와 개발자는 인터랙션을 어떻게 개발하는지 이 두 가지 워크플로우를 소개해 드리려고 합니다.

근데 그 전에 간단하게 저희 소개를 먼저 드려 볼까요?

저는 평범한 컴퓨터 공학과 학생이었는데요.

저는 모션을 좋아해 가지고 학생 때 이렇게 개발 라이브러리들에 SVG 로고 모션을 혼자 만들기도 했었어요.

그 4학년 때는 당근에 프런트엔드 코어팀에서 여름방학 인턴도 했었습니다.

근데 저는 정적인 것보다 동적인 거를 좀 더 많이 만들고 싶었어요.

그래서 토스 인터랙션 팀에 입사하게 되었습니다.

요 사진은 이제 저랑 제 동료 개발자분들 여섯 명에서 다 같이 워크숍 갔을 때 찍은 사진인데요.

어, 이제 입수하기 전에 마지막으로 작업을 마무리하고 있는 그런 모습입니다.

연주 님은 토스 오기 전에 어떤 사람이셨나요?

저는 학생 때 시각 디자인을 전공했는데요.

그때도 정적인 화면을 그리는 것보다는 이런 프로토타입 만드는 걸 좋아했어요.

그리고 졸업 후에는 현대 카드의 신입사원으로 입사를 했는데요.

근데도 저는 또 이런 프로토타입 만드는 게 제일 재밌더라고요.

그래서 인터랙션 디자이너 직군이 있는 토스로 왔습니다.

토스의 인터랙션 디자이너로 와서는 이런 작업들을 했어요. 하나씩 짧게 소개드려 볼게요.

토스로 송금 많이 하시잖아요. 근데 유저들이 보내기 전에 받는 사람 이름을 잘 확인하지 않는 문제가 있었어요.

그래서 잘못 보냈다는 착오 송금 문의가 고객센터로 하루에도 수십 건씩 접수가 됐었어요.

근데 이렇다고 매번 송금할 때마다 저렇게 아래에서 바텀시트를 띄워서 뭔가 유저를 가로막는 경험을 주고 싶진 않더라고요.

그래서 받는 사람 이름을 저렇게 모션으로 자연스럽게 강조해 주는 개선안을 만들었어요.

이 개선으로 고객센터에 접수되는 착오 송금 문의가 25% 줄어들었어요.

또 작년에 동의문 화면도 개선을 했었는데요.

이렇게 한 화면에 필수 동의랑 선택 동의가 같이 있는 게 일반적이었어요.

그런데 이런 식으로 필수 동의를 먼저 동의를 하면 그 후에 선택 동의가 나오도록 화면을 두 개로 나누고 동의할 때 둘을 자연스럽게 연결해 주는 인터랙션 작업을 했습니다.

이것도 실험해 보니까 선택률이 50%포인트나 증가했어요. 그래서 더 간결하면서 동의율도 높인 토스의 표준 동의 모듈로 만들 수 있었습니다.

최근 작업도 한번 보여 드리면 토스에서 비밀번호 입력해야 될 때 갑자기 이런 시커먼 화면이 뜨는데요.

이 비밀번호 입력 화면을 더 아름다우면서도 통과율도 높아질 수 있게 개선했어요.

요거는 지금 저희 팀 개발자분들이 열심히 전체 배포를 준비해 주고 계십니다.

마지막으로 어제 오픈한 서비스예요.

이제 토스에서 모바일 신분증을 발급할 수 있어요. 아셨나요, 여러분?

꼭 토스에서 발급해 주세요. 그 저의 신분증을 보면 위변조 방지를 위해서 홀로그램 패턴이 있잖아요.

그래서 그 패턴을 콘셉트로 해서 전체 플로우를 디자인했습니다.

이런 인터랙션 디자인이 실제 앱에 반영되려면 개발을 해야 되잖아요.

근데 인터랙션 개발에 대해서 저희가 가장 많이 받는 질문이 있죠, 맞아요.

바로 이런 거는 다 로띠로 만드나요?

이런 질문인데요. 이 로띠는 그냥 파일만 받아 가지고 그거를 그냥 넣으면 되니까는 이게 개발자 입장에서는 되게 편하고 좋아요.

근데 여기 보시다시피 그 저희 팀 시안은 이 UI의 요소 자체 모션을 적용해야 될 일이 많아 가지고 어 이거를 로띠로 만들 수 없는 경우가 대부분이에요.

또 토스에서는 아무리 인터랙션이 많아도 이런 큰 글씨 모드라던가 이런 다크 모드까지 대응되어야 하거든요.

그래서 저희 인터랙션 팀만의 독특한 개발 방식이 있는데요. 그게 연주 님이 만든 방식이에요.

바로 랠리라는 저희만의 소통 언어를 만들었어요.

저희 인터랙션 디자이너가 이 랠리로 가이드를 어떻게 쓰는지 보여 드릴게요.

아까 이 비밀번호 입력하는 시안이 있었잖아요.

이게 그 시안의 실제 개발 가이드인데요. 왼쪽에는 화면 속의 요소들이 정리되어 있고 오른쪽에는 등장 모션에 대한 설명이 있어요.

근데 이 모션 설명 파트를 보시면 긴 코드 하나만 딱 있죠. 이게 저희가 만든 랠리예요.

저희 인터랙션 팀의 디자이너랑 개발자는 이것만 봐도 모션 스펙을 이해할 수 있어요.

근데 저희 팀은 이 랠리를 굳이 왜 만들었을까요?

사실 저희도 처음부터 이 랠리라는 걸 만들어서 그걸로 가이드를 이렇게 써야지 이렇게 계획했던 건 아니에요.

랠리가 없던 시절에는 레퍼런스 영상만 드리면서 말로 설명드리기도 했었어요.

이런 느낌으로 해 주세요. 이런 식으로 제가 많이 말씀드렸죠.

가이드 이렇게 받으면 개발자는 어떤가요, 현식님?

아니 그게 이게 진짜 그 개발자한테 영상만 보고 이렇게 모션 똑같이 만들어 달라는 거는 어 되게 너무 가혹하더라고요.

이게 어디서부터 어떻게 만들어야 이런 느낌이 날지 그런 게 감도 잘 안 잡히기도 하고요.

맞아요. 또 개발자분이 아무리 비슷하게 만들어 주셔도 뭔가 약간 느낌이 다르잖아요.

그래서 이렇게 레퍼런스 영상만 드리는 건 별로 좋은 방식이 아니었어요.

또 한 샘플 코드를 가이드 대신 드려 보기도 했어요.

제가 이렇게 숫자가 바뀔 때마다 자연스럽게 모션을 넣어서 움직이는 롤링 넘버 컴포넌트의 버전 2를 만들었었는데요.

보시다시피 옵션이 되게 많고 스펙도 복잡한 컴포넌트여 가지고 요런 식으로 직접 코드로 구현해서 전달드렸었어요.

은식 님, 이거 웹을 직접 개발해 주셨잖아요. 이 방식은 어떠셨어요?

어, 저는 솔직히 더 헷갈렸었어요.

이게 아무래도 그 디자이너가 딱 그 모션에 대한 구현에만 집중해서 짠 코드라 가지고 가독성이 좀 많이 떨어지기도 하고 이게 저희는 또 전사적으로 사용되는 컴포넌트인데 그러니만큼 저사양 기계까지 돌아갈 수 있도록 성능적인 것도 고려해야 돼서 사실 거의 다 처음부터 다시 짰던 그런 기억이 있습니다.

그렇죠. 제가 사실 아무리 코딩을 조금 할 줄 아는 디자이너라고 해도 개발자가 짜는 코드랑은 퀄리티가 아예 다르잖아요.

그래서 이렇게 샘플 코드를 드리는 방식도 별로 좋은 방식은 아니었어요.

이런 시행착오 끝에 모션 스펙만 정확하게 전달할 수 있는 소통 언어 랠리를 만들어서 가이드를 쓰게 됐어요.

근데 어 그런 언어 안 만들어도 모션 스펙 그냥 적으면 되는데 이렇게 생각하실 수 있는데요.

토스는 iOS, 안드, 웹, R&D까지 네 개 플랫폼을 다 사용하고 있어요.

그래서 같은 모션 스펙도 플랫폼마다 다르게 해석되는 일이 정말 많더라고요.

이럴 때 저희 랠리가 중요한 역할을 하는데요. 간단한 예시로 설명드려 볼게요.

예를 들어서 제가 방금 보셨나요? 저렇게 버튼이 둥실하는 모션을 만들었어요.

그리고 그걸 이렇게 두 번 둥실둥실 하게 만들고 싶어요.

그러면 개발자분한테 몇 번 반복해 주세요라고 하실 거 같으세요?

저희 손 한번 들어봐 주실 수 있을까요? 한 번 반복이라고 생각하시는 분?

손 어, 별로 없네요. 두 번 반복이라고 하실 분? 어, 엄청 많네요.

아, 저는 한 번 반복해 주세요라고 생각했어요.

왜냐면 반복을 안 하면 한 번 재생하는 거잖아요. 그러면 반복을 한 번 하면 두 번 재생되겠네.

그래서 저는 두 번 재생을 원하니까 한 번 반복해 주세요. 이렇게 가이드에 썼어요.

그랬더니 안드로이드는 제 생각대로 두 번 재생이 됐는데 iOS랑 웹에서는 한 번만 재생하고 끝나는 거예요.

웹은 왜 한 번만 재생하는 건가요?

근데 그게 약간 당연하다고 생각하는데 이게 웹에서 한 번 반복한다는 스펙은 한번 실행한다는 거거든요.

이게 또 프로그래밍적인 개념에서도 이게 반복일 때 한 번 실행되는 것을 반복이라고 부르기도 하고요.

그러니까 결과적으로는 반복이 실행의 개념인 거죠.

저는 저는 아직도 잘 이해 못 하긴 했는데요.

아무튼 플랫폼마다 이렇게 똑같이 한번 반복해 주세요라고 말씀드려도 동작이 다르니까 제가 원하는 대로 정확하게 전달하려면 안드로이드는 한 번, iOS랑 웹은 두 번 반복해 주세요.

이렇게 설명해야 되는 거예요. 이런 커뮤니케이션 비효율이 계속 생기더라고요.

그래서 저희는 아예 룰을 하나 만들었어요.

어떤 거죠? 어, 저희는 앞으로 반복 횟수로는 말하지 말자.

우리는 무조건 재생 횟수로만 말한다. 예요. 그래 가지고 저희가 만든 랠리에서는 리피 카운트라는 용어 대신 플레이 카운트라는 용어를 사용해요.

이게 가이드에 이제 플레이 카운트 2라고 적혀 있으면은이 모두가 혼란 없이 동일하게 이해할 수 있는 거예요.

이렇게 랠리는 모션 스펙을 혼란 없이 소통할 수 있게 하는 역할이에요.

근데 연주님 이런 스펙 통일이 랠리 역할이 전부인가요?

아니죠. 더 중요한 역할이 또 있습니다.

바로 모두가 인터랙션 시안에 같은 구조로 파악할 수 있게 하는 건데요.

예를 들어서 저렇게 이자를 받으면 바텀시트가 뜨는 모션을 개발자한테 설명해야 된다고 생각해 볼게요.

그러면 디자이너는 저 복잡한 모션 시안에 타겟과 모션의 구조로 쪼개서 생각해요.

TMC25 | Design - 인터랙션, 토스에선 어떻게 개발하나요?

토스 챌린저스

토스 인터랙션 팀은 디자이너와 개발자가 모션 스펙을 정확하고 효율적으로 소통하기 위해 '랠리(Rally)'라는 자체 소통 언어와 '랠리 수도 코드', '렐디터(Rally Editor)' 같은 전용 도구를 개발하여 활용합니다.

랠리는 플랫폼 간 모션 스펙 해석의 혼란을 줄이고, 모션의 구조를 통일하여 디자이너와 개발자가 같은 관점으로 시안을 이해하고 구현할 수 있도록 돕습니다.

토스는 자체 디자인 에디터 '데우스(Deus)'를 통해 디자이너가 간단한 모션을 1초 만에 적용하고 실시간으로 프리뷰하며, 개발자는 해당 모션의 랠리 코드를 즉시 확인할 수 있는 프로토타이핑 환경을 제공하여 인터랙션 구현 효율성을 극대화하고 있습니다.

안녕하세요, 토스 인터랙션 팀 리더이자 디자이너 박현주입니다. 토스 인터랙션 팀에서 프런트엔드 UX 엔지니어로 일하는 박은식입니다. 이번 세션에서는 **인터랙션 디자이너와 개발자 간의 소통 방식**, 그리고 **인터랙션 디자이너가 없는 제품 팀에서 프로덕트 디자이너와 개발자가 인터랙션을 개발하는 두 가지 워크플로우**를 소개합니다.

저는 모션을 좋아해서 학생 때부터 SVG 로고 모션을 만들거나 프런트엔드 인턴으로 일했습니다. 정적인 것보다 동적인 것을 만들고 싶어 토스 인터랙션 팀에 합류하게 되었습니다. **토스 합류 전에도 프로토타입 제작을 즐겨 했으며**, 현대카드 디자이너 시절에도 이 분야에 대한 흥미를 이어갔습니다.

토스 인터랙션 디자이너로서 다양한 작업을 수행했습니다. 송금 시 수취인 이름 **확인 문제를 개선하기 위해 모션으로 이름을 강조**하는 방식을 도입했고, 그 결과 고객센터로 접수되는 착오 송금 문의가 25% 감소했습니다.

작년에는 동의문 화면을 개선하여 **필수 동의 후 선택 동의가 나오도록 화면을 분리하고 자연스러운 인터랙션**을 추가했습니다. 이 개선으로 선택 동의율이 50% 포인트 증가했으며, 간결하고 동의율을 높인 토스의 표준 동의 모듈로 자리 잡았습니다.

최근에는 **비밀번호 입력 화면을 더욱 아름답고 통과율이 높은 방향으로 개선**했으며, 모바일 신분증 발급 서비스에서는 위변조 방지 홀로그램 패턴을 콘셉트로 전체 플로우를 디자인했습니다.

랠리(Rally) 개발: 인터랙션 소통 언어

인터랙션 디자인을 실제 앱에 반영하기 위해 개발이 필요합니다. 가장 많이 받는 질문은 '모든 것을 로띠(Lottie)로 만드나요?'인데, **토스 시안은 UI 요소 자체에 모션을 적용해야 하는 경우가 많아 로띠로는 대부분 구현할 수 없습니다**. 또한 큰 글씨 모드나 다크 모드 등 다양한 환경에 대응해야 합니다.

이러한 필요성 때문에 저희 인터랙션 팀은 **'랠리(Rally)'라는 독특한 소통 언어**를 만들었습니다. 랠리를 통해 인터랙션 디자이너가 개발 가이드를 작성하면, 디자이너와 개발자 모두 모션 스펙을 명확하게 이해할 수 있습니다.

랠리 도입 전에는 레퍼런스 영상만 제공하며 "이런 느낌으로 해주세요"라고 설명하는 방식이었습니다. 하지만 개발자는 **영상만으로는 모션을 똑같이 구현하기 어렵고 어디서부터 시작해야 할지 감을 잡기 힘들었습니다**. 또한 디자이너가 원하는 정확한 느낌을 재현하기 어려웠습니다.

샘플 코드를 제공하는 방식도 시도했지만, 디자이너가 모션 구현에만 집중해 작성한 코드는 **가독성이 떨어지고 성능적인 고려가 부족해 재작업이 필요**했습니다. 개발자 수준의 코드 퀄리티와는 차이가 있었기 때문에 이 방식 또한 효과적이지 않았습니다.

랠리의 핵심 기능: 스펙 통일과 구조화

토스는 iOS, Android, 웹, R&D 등 네 가지 플랫폼을 사용하기 때문에 **같은 모션 스펙도 플랫폼마다 다르게 해석되는 문제**가 있었습니다. 예를 들어 '반복 횟수'에 대한 개념이 플랫폼별로 달라 커뮤니케이션 비효율이 발생했습니다.

이러한 혼란을 해결하기 위해 **'반복 횟수' 대신 '재생 횟수(play count)'라는 용어를 랠리에 도입**하여 모든 플랫폼에서 동일하게 모션 스펙을 이해할 수 있도록 했습니다. 랠리는 모션 스펙을 혼란 없이 소통할 수 있도록 돕는 중요한 역할을 합니다.

랠리의 또 다른 중요한 역할은 **모두가 인터랙션 시안을 동일한 구조로 파악**하게 하는 것입니다. 디자이너가 모션을 '타겟과 모션의 구조'로 쪼개서 생각하면, 개발자도 이 구조에 맞춰 랠리 코드를 작성할 수 있도록 설계되었습니다. 각 플랫폼별 랠리 코드는 언어는 다르지만 '타겟에 모션을 붙이는' 기본 구조는 동일합니다.

여러 개의 모션을 하나로 묶기 위해 **'타임라인' 개념을 도입**했습니다. `parallel`, `serial`, `stagger` 같은 옵션을 통해 모션의 동시 재생, 순차 재생, 시간차 재생 등을 제어할 수 있어, 가이드에서도 이 옵션 하나로 모션의 시퀀싱 구조를 모두가 이해할 수 있습니다.

랠리 수도 코드와 렐디터(Rally Editor) 도입

네 개 플랫폼의 랠리 코드를 가이드에 모두 작성하기 어렵고, 디자이너가 모든 플랫폼의 코드를 외우기도 힘든 문제를 해결하기 위해 **'랠리 수도 코드'라는 가상의 공통 언어를 만들었습니다**. 이 수도 코드 하나로 가이드를 작성해도 모두가 이해할 수 있으며, 개발자는 '인스펙터' 도구로 수도 코드를 찍으면 해당 플랫폼의 랠리 코드가 자동으로 생성됩니다.

처음에는 수도 코드를 직접 타이핑했지만, 오타나 공백 오류로 코드 생성이 안 되는 어려움이 있었습니다. 이를 해결하기 위해 **'렐디터(Rally Editor)'라는 자체 툴을 개발**했습니다. 렐디터를 사용하면 디자이너는 코딩 지식 없이도 클릭만으로 스펙을 입력하여 수도 코드를 자동으로 생성하고, 이를 복사하여 개발 가이드를 작성할 수 있습니다.

결과적으로 인터랙션 팀의 워크플로우는 **디자이너가 프로토타입 툴로 프로토타입을 만들고, 렐디터로 수도 코드를 작성하면 개발자가 본인 플랫폼의 랠리 코드젠을 확인하는 방식**으로 정착되었습니다.

제품 팀을 위한 데우스(Deus)와 간편한 모션 워크플로우

토스의 모든 인터랙션 화면이 이 복잡한 과정을 거치는 것은 아닙니다. 60명의 프로덕트 디자이너와 3명의 인터랙션 디자이너라는 인력 불균형 때문에, 제품 팀에서는 **간단한 모션을 빠르고 쉽게 넣을 수 있는 다른 워크플로우가 필요**했습니다. 복잡한 워크플로우는 오히려 비효율적일 수 있었습니다.

이를 위해 **디자이너가 디자인 툴을 바꾸지 않고 바로 모션을 만들고, 개발자가 수도 코드나 가이드 작성 없이 랠리 코드를 생성할 수 있는 환경**을 구축했습니다. 은식 님과 두 분의 개발 어시스턴트가 이 시스템을 개발했습니다.

디자이너는 A 단축키만으로 1초 만에 모션을 적용하고, 페이드나 슬라이드 등 자주 사용되는 모션을 클릭 한 번으로 변경할 수 있습니다. 모션 적용 시 **하단에 프리뷰와 타임라인이 자동으로 나타나 즉시 확인이 가능**하며, 개발자도 이 화면에서 모션을 확인하고 플랫폼별 랠리 코드를 인스펙터에서 볼 수 있습니다.

이 모든 기능은 **토스가 올해 초 출시한 자체 디자인 에디터 '데우스(Deus)' 내에 구현**되어 있습니다. 피그마나 프레이머와 같은 기존 툴은 모션 작업 시 여러 화면 복제, 컴포넌트 분리, 긴 로딩 시간 등으로 번거로움이 있었고, 자체 개선이 어려워 워크플로우 발전에 한계가 있었습니다.

데우스 출시 덕분에 **로딩 없는 자동 프리뷰, 한눈에 볼 수 있는 타임라인 패널, A 키 단축키 하나로 모션을 적용할 수 있는 환경**이 마련되었습니다. 이는 저희 팀이 몇 년 동안 원하던 프로토타이핑 기능의 기반이 되었으며, 최근 오픈한 세 가지 기능만으로도 프로덕트 디자이너와 개발자들로부터 뜨거운 반응을 얻고 있습니다.

처음에는 거대한 프로토타이핑 도구를 만드는 것이 힘들었지만, 오픈 후 다들 좋아하고 동적인 시안을 훨씬 많이 만드는 것을 보며 **힘든 기억들이 미화되고 뿌듯함을 느꼈습니다**.

미래 비전: 더욱 진화된 인터랙션 워크플로우

저희 팀은 이제 막 시작한 기분으로, 앞으로 **더욱 복잡한 프로토타입까지 만들 수 있는 다양한 기능들을 계획**하고 있습니다. 현재는 제품 팀의 간단한 모션만 데우스로 만들 수 있지만, 미래에는 인터랙션 팀도 복잡한 모션을 데우스로 만들고 가이드 작성 없이 바로 개발할 수 있는 날을 꿈꾸고 있습니다.

토스 인터랙션 팀이 이처럼 워크플로우 구축에 진심인 이유는 **토스의 아름다운 인터랙션을 더 많이 만들기 위함**입니다. 정교한 모션 시안을 디자이너의 의도대로 사용자에게 전달하기 위해, 개발자가 인터랙션을 더 정확하고 빠르게 구현할 수 있도록 랠리 소통 언어부터 랠리 수도 코드, 랠리 에디터, 랠리 코드젠, 랠리 프로토타이핑 도구까지 끊임없이 만들어나가고 있습니다.

저희 팀만큼 인터랙션 디자인과 개발에 집착하는 팀은 흔치 않을 것입니다. 언제나 더 멋진 시안과 더 완벽한 구현 방법을 고민하는 **든든한 팀원들 덕분에 이러한 발전이 가능**하다고 생각합니다. 앞으로도 토스 인터랙션 팀이 어디까지 발전하는지 지켜봐 주시면 감사하겠습니다.

토스 인터랙션 팀의 박현주, 박은식 님은 각각 어떤 배경을 가지고 토스 인터랙션 팀에 합류하게 되었나요?

토스 인터랙션 팀은 인터랙션 개발 과정에서 어떤 문제점들을 겪었으며, 이를 해결하기 위해 '랠리'라는 소통 언어를 만들게 된 구체적인 계기는 무엇인가요?

'랠리'는 토스 인터랙션 팀 내에서 어떤 역할을 하며, 이 소통 언어가 디자이너와 개발자 간의 협업에 어떤 긍정적인 영향을 미치고 있나요?

토스 인터랙션 팀의 복잡한 워크플로우와는 별개로, 일반 제품 팀에서 간단한 모션을 빠르고 쉽게 적용할 수 있도록 도입된 '데우스'는 어떤 특징과 장점을 가지고 있나요?

토스 인터랙션 팀이 인터랙션 워크플로우 개선에 이토록 진심인 궁극적인 이유는 무엇이며, 이를 통해 이루고자 하는 목표는 무엇인가요?

토스 인터랙션 팀 소개 및 세션 개요

발표자는 토스 인터랙션 팀 리더 박현주 디자이너와 프런트엔드 UX 엔지니어 박은식.

이번 세션에서는 인터랙션 디자이너와 개발자의 소통 방식, 그리고 인터랙션 디자이너가 없는 팀에서 프로덕트 디자이너와 개발자가 인터랙션을 개발하는 두 가지 워크플로우를 소개함.

박은식 엔지니어의 경력 및 토스 합류 배경

컴퓨터 공학과 출신으로 모션을 좋아하여 개발 라이브러리의 SVG 로고 모션을 제작했음.

당근마켓 프런트엔드 코어팀에서 인턴십을 수행했으며, 동적인 작업에 대한 열정으로 토스 인터랙션 팀에 합류.

박현주 디자이너의 경력 및 토스 합류 배경

시각 디자인 전공자로 정적인 화면보다 프로토타입 제작에 관심이 많았음.

현대카드 신입 디자이너 시절에도 프로토타입 제작을 즐겨 했고, 인터랙션 디자이너 직군이 있는 토스로 이직.

토스 인터랙션 디자이너의 주요 작업 사례

착오 송금 문제 해결: 받는 사람 이름을 모션으로 강조하여 고객센터 문의를 25% 감소시킴.

동의문 화면 개선: 필수 동의 후 선택 동의가 나오도록 화면을 분리하고 자연스러운 인터랙션을 적용하여 선택률 50%p 증가.

비밀번호 입력 화면 개선: 미적인 요소와 통과율을 높이는 방향으로 개선 중.

모바일 신분증 발급 서비스 디자인: 홀로그램 패턴 콘셉트를 적용하여 위변조 방지 기능을 시각적으로 구현.

인터랙션 개발 방식의 고민: Lottie의 한계

자주 받는 질문은 '모든 인터랙션이 Lottie로 만들어지는가?'.

Lottie는 파일만 넣으면 되어 개발자에게는 편리하지만, 토스 시안은 UI 요소 자체에 모션을 적용하는 경우가 많아 Lottie로 구현하기 어려운 경우가 대부분.

큰 글씨 모드나 다크 모드 등 다양한 환경에 대응해야 하므로 Lottie만으로는 한계가 있음.

토스 인터랙션 팀의 독자적인 소통 언어 'Rally' 개발

랠리(Rally)는 인터랙션 디자이너와 개발자가 모션 스펙을 이해할 수 있도록 만든 소통 언어.

비밀번호 입력 시안의 개발 가이드 예시를 통해 랠리 코드의 활용을 보여줌.

Rally 개발 전 소통의 어려움과 시행착오

초기에는 레퍼런스 영상만 제공하고 '이런 느낌으로 해달라'고 설명하여 개발자가 구현하기 어려웠음.

샘플 코드를 제공하기도 했지만, 디자이너가 작성한 코드는 가독성이나 성능 측면에서 부족하여 개발자가 처음부터 다시 짜는 경우가 많았음.

이러한 시행착오 끝에 모션 스펙을 정확하게 전달할 수 있는 랠리를 만들게 됨.

Rally의 필요성: 플랫폼별 스펙 해석 차이 해소

토스는 iOS, Android, Web, R&D 등 4개 플랫폼을 사용하며, 같은 모션 스펙이라도 플랫폼마다 다르게 해석되는 문제가 있었음.

'버튼 둥실거리는 모션을 두 번 재생하고 싶을 때'의 예시를 통해 디자이너와 개발자, 플랫폼별 '반복 횟수' 해석 차이를 설명.

이러한 비효율을 줄이기 위해 '반복 횟수' 대신 '재생 횟수(playCount)' 개념을 사용하기로 규칙을 정하고 랠리에 적용.

랠리는 모션 스펙을 혼란 없이 소통할 수 있게 하는 중요한 역할.

Rally의 두 번째 역할: 인터랙션 시안의 구조 통일

모두가 인터랙션 시안을 '타겟과 모션'의 동일한 구조로 파악할 수 있게 함.

바텀시트 등장 모션 예시 (동전 커지는 모션, 텍스트 올라오는 모션, 버튼 올라오는 모션)를 통해 설명.

iOS 랠리 코드 및 안드로이드/웹 랠리 코드 모두 '타겟에 모션을 붙이는' 기본 구조가 동일하여 같은 관점으로 소통 가능.

여러 모션을 하나로 묶는 '타임라인' 개념 도입 (parallel, serial, stagger 옵션)으로 모션 시퀀싱 구조를 통일.

Rally 수도 코드 및 Rally Editor 개발

4개 플랫폼의 코드를 모두 가이드에 작성하는 어려움 때문에 '랠리 수도 코드(Rally Pseudo Code)'를 만들었음.

서로 다른 언어를 쓰는 외국인들 사이의 공통어(영어)처럼, 랠리 수도 코드는 모든 플랫폼 팀이 이해할 수 있는 공통어 역할.

수도 코드를 개발자가 인스펙터 도구로 찍으면 iOS, Android, 웹 랠리 코드가 자동으로 생성되는 '코드 젠(Code Gen)' 기능 구현.

수도 코드의 수동 타이핑 및 오타 문제 해결을 위해 자체 툴인 '랠리 에디터(렐디터, Ralleditor)' 개발.

렐디터는 디자이너가 클릭만으로 스펙을 입력하면 수도 코드가 실시간으로 자동 생성되어 코딩 지식 없는 디자이너도 사용 가능.

인터랙션 팀의 워크플로우와 제품 팀의 워크플로우 차이

인터랙션 팀 워크플로우: 디자이너가 프로토타입 툴로 프로토타입 생성 → 렐디터로 수도 코드 작성 → 개발자가 플랫폼별 랠리 코드 젠 확인.

제품 팀은 60명의 프로덕트 디자이너와 3명의 인터랙션 디자이너가 있어, 모든 모션을 인터랙션 디자이너가 맡을 수 없음.

간단한 모션은 제품 팀에서 빠르고 쉽게 처리할 수 있는 다른 워크플로우가 필요.

자체 디자인 에디터 '데우스(Deus)'를 통한 제품 팀 워크플로우 개선

디자이너가 디자인 툴을 바꾸지 않고 1초 만에 모션을 만들고, 개발자가 수도 코드/가이드 없이 랠리 코드를 바로 확인할 수 있는 환경 구축.

데우스에서는 A 단축키로 모션 적용, 페이드/슬라이드 등 자주 쓰이는 모션 클릭 한 번으로 변경 가능.

하단에 프리뷰와 타임라인이 자동으로 표시되어 만든 모션을 즉시 확인 가능하며, 개발자는 인스펙트에서 플랫폼별 랠리 코드 확인 가능.

데우스는 토스가 올해 초 출시한 자체 디자인 에디터로, 피그마나 프레이머 같은 외부 툴의 모션 제작 한계를 극복하기 위해 개발.

데우스 출시로 로딩 없는 자동 프리뷰, 타임라인 패널, 단축키를 통한 1초 모션 적용 등 프로토타이핑 기능 기반 마련.

3주 전 오픈한 3가지 기능에 대해 제품 디자이너와 개발자들의 뜨거운 반응을 얻었음.

인터랙션 워크플로우의 미래 비전과 토스 팀의 진심

향후 데우스에서 더 복잡한 프로토타입 제작 기능과 인터랙션 팀도 데우스로 복잡한 모션을 만들고 가이드 없이 개발할 수 있는 날을 꿈꿈.

토스 팀이 인터랙션 워크플로우 구축에 진심인 이유는 '토스의 아름다운 인터랙션을 더 많이 만들기 위함'임.

인터랙션의 정확하고 빠른 구현을 위해 랠리, 랠리 수도 코드, 랠리 에디터, 랠리 코드 젠, 랠리 프로토타이핑 도구까지 끊임없이 개발.

인터랙션 디자인과 개발에 대한 팀의 집착은 더 멋진 시안과 완벽한 구현 방법을 고민하는 팀원들 덕분에 가능.

TMC25 | Design - 인터랙션, 토스에선 어떻게 개발하나요?

스크립트