[toss] iOS 개발자를 위한 SLASH23 리뷰

toss의 디자인 컨퍼런스 SIMPLICITY23에 이어 개발자 컨퍼런스 SLASH23가 진행됐다.

SLASH23은 토스 개발자들의 기술적 고민과 성취를 공유하는 자리이며, 총 24개 세션으로 구성되어 있다.

 

그중 클라이언트 개발자가 눈여겨 봐야 할 세션은 3가지가 있다.

 

클라이언트 관련 세션 - SLASH23

1. Rally로 3분 만에 애니메이션 완성하기
2. 레고처럼 조립하는 토스 앱
3. 누구나 쓸 수 있는 접근성 높은 토스 만들기

 

하나씩 간단히 정리해 봤다.

나중에 언젠가... 시간이 나면 다른 세션도 정리해보고 싶다. 🙄

---

1. Rally로 3분 만에 애니메이션 완성하기

저번에 포스팅했던 SIMPLICITY23 리뷰에서 

첫 번째로 다뤘던 인터렉션, 꼭 넣어야 해요? 세션과 연결되는 내용이다.

 

사실 대부분의 내용을 SIMPLICITY23에서 다뤘기에 크게 새로운 정보는 없었다.

디자이너 세션을 안 본 분들을 위해 요약하자면,

• 배경 : 제품에 인터렉션을 추가하면서 생겨난 커뮤니케이션 비용을 줄이기 위해
  Andriod/iOS/Web에서 동일한 개발 언어와 로직을 사용하는 Rally라는 애니메이션 라이브러리를 만들게 됐다.
• 작업 방법 : 디자이너가 프레이머로 인터랙션 컴포넌트를 사용해서 Motion을 만들면, 
  프레이머 inspect에서 Rally 코드를 확인할 수 있다.

개발자 관점에서 와닿았던 내용은 이랬다.

 

화면의 여러 UI가 유기적으로 움직이는 애니메이션은 개발 난이도가 높고, 가독성이 낮으므로 유지보수 비용이 증가한다.

애니메이션을 관리하려면 애니메이션을 자유롭게 컨트롤할 수 있어야 한다.

예를 들면 애니메이션의 재생/역재생, 일시정지, 특정 시점으로 이동 등이 간편해야 한다.

이 부분이 대부분의 회사에서 마주하는 가장 큰 허들인 것 같다.

 

애니메이션 다루기 - SLASH23

Rally는 pseudo code 형태로 소통하고, 개발 시에는 각 플랫폼별 언어로 번역해서 사용한다고 한다.

 

Rally 예시 - SLASH23

Rally는 이렇게 구성된다.

• 먼저 Easing (값이 시간에 따라 어떻게 변화할지)을 바탕으로 Rally의 최소 단위인 Motion (어떻게 움직일지)을 만들고,
• 재생의 최소 단위인 Rally를 통해 애니메이션을 적용할 target에 연결한 뒤,
• Timeline을 통해 여러 개의 Rally를 스케줄링하는 구조이다.
• 자주 쓰는 설정값을 모아둔 프리셋도 있다.
• 애니메이션을 컨트롤하기 위한 API (play, backward.play 등)도 정의되어 있다.

 

이러한 Rally의 구성요소는 아래처럼 저번 세션에 더 명확히 정리되어 있다.

Rally 구성요소 - SIMPLICITY23

 

인터렉션 디자인 시스템이 있다는 것만으로 놀라운데, 크로스 플랫폼 inspect 기능까지 있다니 너무 멋지다... 🥹

(근데 하나만 봐야 한다면 설명이 더 짜임새 있는 SIMPLICITY23의 세션을 보는 것을 추천한다.)

 

*SIMPLICITY23의 해당 세션 내용이 궁금하다면?
👉 [toss] SIMPLICITY23 리뷰 > #1. 인터렉션 꼭 넣어야 해요?

---

2. 레고처럼 조립하는 토스 앱

레고라는 단어를 보자마자 'RIBs' 얘기를 하겠구나! 직감했다.

근데 아니었음...

문제상황

앱의 규모가 커지면 모듈 분리 (앱을 여러 모듈로 나누고, 모듈 간의 구조를 설계하는 작업)이 중요하다.

기존에는 아래처럼 기능별 Layer로 분리되어 있었다.

Feature Layer의 모듈은 각자 하위의 Service Layer 모듈만을 의존하게 된다.

기존 - 기능별 Layer로 분리됨

하지만 토스에 여러 기능이 추가되면서 Feature Layer에 많은 모듈이 생기고,

모듈 간의 의존성이 복잡해지는 문제가 발생했다.

빌드 속도가 느려지고, 순환 참조가 자주 발생하기도 했다.

 

예를 들어 홈에서 사용자를 인증하기 위해 홈 Feature가 인증 Feature를 의존하게 되어

동일한 Layer의 모듈 간 의존 관계가 꼬이게 된 것이다.

 

따라서 홈 Feature 및 인증 Feature를 사용하는 홈 인증 Service를 따로 만들고,

두 Feature가 홈 인증 Service를 의존하도록 개선했지만...

또 다시 이로 인해 지나치게 많은 Layer가 생기는 문제가 있었다.

Feature Layer에 여전히 존재하는 의존성 문제

Microfeatures Architecture로의 전환

결론적으로 Tuist에서 제작한 모듈 구조인 Microfeatures Architecture를 도입했다.

모듈의 역할과 상호 관계는 아래와 같다.

Microfeatures Architecture의 구조 / 모듈 간 관계

• Feature : 실제 기능을 구현한 모듈
• Interface : feature 기능 중 외부에 공개할 interface
• Testing : interface 모듈의 Mocking을 제공
• Tests : unit test
• Example : 기능을 테스트할 수 있는 작은 단위의 앱 target (빠르게 일부만 빌드/배포 가능)

전체 코드에 대해 새로운 Architecture로 전환하는 과정에서 작업량에 대한 부담과 수많은 conflict이 걸림돌이 됐다고 한다.

따라서 반복 작업은 Tuist의 Template/Scaffold 기능을 활용했고 (template으로 쉽게 모듈을 생성),

iOS 전체 인원이 전환 작업에 대한 필요성을 공감하고 적극적으로 참여할 수 있도록 했다고 한다.

Microfeatures Architecture의 장점

기자에서 개발자로 커리어를 전환한 과정을 담은 글 '노베이스에서 토스 합격까지'로 유명한

송범근님의 장점 소개가 이어졌다. 흥미진진

 

토스 앱은 거대하지만, 피처를 개발할 때는 마치 작은 앱을 만드는 것처럼 작업이 가능하다고 한다.

각 피처별 Example 앱을 예로 들자면,

첫째, Example 앱을 통해 특정 기능의 결과 케이스를 모두 확인 가능하다.

 

개인적으로 담당한 피처에 대해 스스로 개발자 테스트를 할 때,

Charles의 Map local, Rewrite 기능을 활용해서 모든 성공/실패 케이스를 Mock 데이터를 적용해 확인해야 했는데

이렇게 결과 케이스를 모두를 한눈에 확인 가능하다니 너무 유용할 것 같다..!

 

둘째, Example 앱은 작은 앱 target 형태로 만들어지는데, 빌드 시간이 짧아서 개발 생산성을 높일 수 있다.

예를 들어 송금 Example 앱을 만든다면 

레고를 조립하듯이 송금 Feature/Interface, 인증 Interface/Testing 등 필요한 부분만 가져와서 쓰면 된다.

 

이때 인증 Testing에는 Mock 데이터가 들어있어서

실제 인증 절차를 거치지 않고 가볍게 결과물을 확인 가능하다.

송금 Example 앱의 예시

셋째, Example 앱을 내부 배포할 수 있어서 디자이너, QA와의 협업 효율이 향상됐다고 한다.

 

Example 앱만 봐도 이렇게 많은 장점이 있다니 놀라웠다.

Tuist도 듣기만 하고 실제 써보지 않았는데,

당장 전체 프로젝트를 개선하지는 못하더라도 하나씩 공부하며 부분 적용해 보자는 목표가 생겼다.

---

3. 누구나 쓸 수 있는 접근성 높은 토스 만들기

토스가 모바일 접근성에 진심인 이유는?라는 글로도 문서화되어 있다.

접근성을 신경 쓰게 된 계기

토스의 사용자가 늘어나며 접근성 개선에 대한 사용자의 건의가 지속적으로 발생했는데,

UX를 개선하고, 개발 생산성을 높이기 위해 TDS (toss Design System) 차원에서 대응하기로 결정했다고 한다.

 

웹페이지 메인 - toss

큰 글씨 모드 대응

가장 먼저 작업한 것은 큰 글씨 모드 대응이었다.

 

기존에 개발 난이도를 낮추기 위해 사용했던 numberOfLines = 1을 해제하여 

큰 글씨 모드일 때 버튼의 title text, 목록 항목의 cell title text가 잘리지 않도록 방지했고,

UI 요소를 재배치하여 컨텐츠가 들어갈 공간을 확보했다.

 

numberOfLines 개선 전 -> 후

Tab Bar처럼 공간이 한정되어 있어 Layout 배치 변경이 어렵다면

말 줄임 (truncatingTail) 로직을 유지한 채, 특정 항목을 탭하면 Bottom Sheet를 띄워 추가 정보를 제공하는 방법으로 해결했다고 한다.

 

Bottom Sheet로 해결

또한 가독성을 위해 의도적으로 개행 (줄 바꿈)을 넣고 있는데

1.3배 등 특정 글자 크기에서 개행이 오히려 가독성을 떨어트리는 경우가 발생했다.

이 경우에는 개행 문자 ("\n")를 공백 ("")으로 대체하여 개행이 되지 않게 수정했다고 한다.

 

개행을 공백으로 개선 전 -> 후

스크린 리더 (Voice Over)

그다음은 Voice Over (안드로이드의 Talk Back) 기능이다.

아래의 2가지 개념이 있다.

• 대체 텍스트 : 이미지 등 시각 자료에 대한 추가 정보를 줌
• 초점 : UI를 포커싱함 (Voice Over를 시작하면 Voice로 읽히는 영역이 차례로 하나씩 포커싱됨)

Voice Over 기능을 별도로 구현하지 않는다면,

시스템은 자동으로 위에서 아래, 왼쪽에서 오른쪽 방향으로 초점을 이동시키는데

이때 약관 list에서 아래와 같은 문제가 발생한다.

체크 버튼이 어떤 항목에 대한 것인지, 화살표 버튼이 어떤 동작을 하는 것인지 Voice만으로는 알 수가 없는 것이다.

 

대체 텍스트 및 초점 개선 전 -> 후

 

부트캠프 시절에는 야곰의 가르침을 따라 Accessibility에 대해 심층적으로 공부했었다.

큰 글씨 모드 (Larger Text)에서 StackView axis를 horizontal에서 vertical로 바꾸어 label 배치를 dynamic하게 조정하고,

VoiceOver까지 구현하는 등 실제 프로젝트에 적용해봤었다.

 

하지만 실무에 와서는 전혀 신경쓰지 못하고 있었다...

Accessibility의 중요성은 알지만 비즈니스 임팩트가 큰 작업을 우선시하다보니

VoiceOver는 커녕 Dynamic Font, 다크 모드, 가로 모드 등 기초적인 기능도 포기하고 있었다.

 

그런데 주 1회 배포를 하며, 빠르게 피처를 만드는 토스에서 Accessibility를 챙긴다니 놀라웠다.

---

결론 : 건강하고 빠릿한 조직

Slash의 여러 세션에서 공통적으로 느꼈던 부분인데

토스는 구성원이 문제 의식에 공감한다면 빠르게 실행으로 이어지는 좋은 문화를 가진 것 같다.

이런 조직적인 행동력이 정말 정말 부럽다... 🥹

 

이처럼 똑똑하고 실행력 있는 개발자들의 고민과 문제해결 사례가 궁금하다면

toss의 SLASH23 세션을 가볍게 들어보는 것을 추천한다!

---

번외

왜 컨퍼런스 이름을 Slash로 네이밍했을까 궁금증이 들어서 ChatGPT한테 물어봤다.

답변이 그럴싸했다.

 

SLASH 네이밍의 비밀 - ChatGPT

 

- Reference

• 지난 글
  • [toss] SIMPLICITY23 리뷰 - 프로덕트 디자이너의 고민 엿보기
• toss > SLASH23
• Tuist.io
• toss feed > 토스가 모바일 접근성에 진심인 이유는?
• Blog > '노베이스에서 토스 합격까지'

 

🍎 포스트가 도움이 되었다면, 공감🤍 / 구독🍹 / 공유🔗 / 댓글✏️ 로 응원해주세요. 감사합니다.