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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Scripts