토스 SLASH 22 DAY-1
미친 생산성을 위한 React Native
인생의 1/3은 침대에 또 1/3은 지하철에 나머지 1/3은 빌드타임에 쏟는다.
느린 배포 속도
- 매우 느린 빌드 속도
- 앱스토어 심사 기간
- 업데이트가 전달되는 시간
개발 리소스 부족
- 같은 기능, 다른 구현 방식
문제 해결을 위한 옵션
- 앱의 모든 Flow를 웹으로 만드는것
- 항상 최신 기능 제공 가능
- 네트워크 환경 의존성
- 성능적인 한계
- Cross Platform 프레임워크를 사용
- Flutter vs. React Native
RN
- RN 동작 구조는 비즈니스 로직과 View를 그리는 로직을 Javascript 하나로 작성
- 앱스토어, 플레이스토어 앱에 포함된 js 파일을 동적으로 허용 -> 굳이 앱 배포를 할필요없음
부분 적용을 가능하게 하는 요소들
- 기존 프로젝트에 적용가능
- 1 React Native Bundle : N 진입점
- React Native와 Native간의 통신
- Bundle을 다운로드 받아 사용
완전히 다시 작성한다면?
- 시간이 더 오래 걸린다
- Cross Platform 이점
RN 적용 후 느낀 장점
CodePush덕분에 유저들이 앱을 업데이트할 필요가 없어졌다 이를 통해 200번이 넘는 배포를 할수 있었다.
토스ㅣSLASH 22 - 미친 생산성을 위한 React Native
잃어버린 유저의 시간을 찾아서 : 100년을 아껴준 SSR 이야기
토스 앱에는 웹으로 구현된 서비스가 많다. 토스에 웹서비스에 진입하면 평균 2.5초 동안 로딩을 보게 된다.
토스의 웹서비스가 콘텐츠를 전달하는 흐름
1.HTML을 요청해서 응답을 받는다.
2.JavaScript 번들을 요청해서 응답을 받는다.
3.React 앱이 들어있는 번들을 실행
4.API 서버로부터 응답을 받는다.
그 후 콘텐츠를 보여준다. 그동안 사용자는 계속 로더를 보면서 기다려야한다.
한 번의 요청을 콘테츠를 보여주는 SSR 아키텍쳐
SSR 이용해서 브라우저에서 HTML를 요청할때 헤더에 유저를 식별하기 위한 토큰을 전달. 프론트엔드 서버에서는 해당 요청이 어떤 유저인지 알 수 있다.
퍼포먼스 모니터링 : Web-Vitals
- LCP(최대 콘텐츠풀 페인트)
- FID(최초 입력 지연)
- CLS(누적 레이아웃 시프트)
로딩성능에 대한 지표 LCP 확인 결과
- 혜택탭 2.5s -> 1.6s
- 내보험 2.5s -> 1.1s
- 신용카드 혜택 추천 1.9s -> 1.1s
- 계좌 만들기 1.7s -> 0.9s
LCP 평균 44% 단축
웹 서비스 방문횟수 285,000,000/월
감소한 LCP 0.9s
아낀 유저의 시간 8.1년/월, 97.6년/연
어떻게 구현했을까?
Next.js 리액트를 위한 서버 사이드 렌더링 프레임워크
토스ㅣSLASH 22 - 잃어버린 유저의 시간을 찾아서 : 100년을 아껴준 SSR 이야기
SLASH 22 - Effective Component 지속 가능한 성장과 컴포넌트
변경을 예측하려 하지말고 대응해야 한다.
컴포넌트는
- Headless 기반의 추상화하기
- 변하는 것 vs 상대적으로 변하지 않은것
- 한가지 역할만 하기
- 또는 한 가지 역할만 하는 컴포넌트의 조합으로 구성하기
- 도메인 분리하기
- 도메인을 포함하는 컴포넌트와 그렇지 않은 컴포넌트 분리하기
컴포넌트를 나누는 행위가 복잡도를 낮추기 위한 것인지 재사하기 위함인지 꼭 분리해야 하는 컴포넌트인지 고민해 볼 필요가있다.
제품을 만들면서 끊임없이 컴포넌트를 만든다. 잘 만든 컴포넌트는 미래의 나에게 큰 도움이 된다. 이미 해결한 문제를 또 해결할 필요가 없기 때문에 함께 일하는 동료에게도 도움이 될 수 있다. 결국 이런 애질리티(Agility)는 비지니스의 기초가 된다. 변경에 유연한 코드는 안정적으로 비지니스를 운영하면서 빠른 속도를 유지하는데 필수적인 요소이기 때문이다.