토스의 디자인 편집기 ‘데우스’, 이렇게 만들었어요! | EP.11

명랑한말-3

상세하고 친절한 답변에 감사드립니다. 토스가 사용자 경험을 위해 얼마나 깊이 고민하고 있는지 느낄 수 있었습니다. 말씀해주신 내용을 바탕으로 PWA에 대해 조금 더 생각해보니 추가적인 궁금증이 생겼습니다. PWA를 지원하지 않는 Android의 WebView나 iOS의 WKWebView 환경에서 동작하는 웹과 Bubblewrap, PWABuilder 등으로 패킹할 때 사용하는 웹은 다소 차이가 있는 것으로 알고 있습니다. 혹시 향후에 관련 내용을 다시 다루실 기회가 있다면 기술 커뮤니티의 이해를 돕기 위해 아래 세 가지 시나리오를 비교 분석해주시면 정말 흥미로울 것 같습니다. 1. CSR이며 React 기반 PWA 웹을 Bubblewrap, PWABuilder 등으로 패키징한 모바일 앱 2. CSR이며 React Native for Web으로 만든 PWA 웹을 위와 동일하게 패키징한 모바일 앱 3. 순수 React Native로 제작된 모바일 앱 토스의 기술 블로그를 통해 항상 많이 배우고 있습니다. 귀한 시간을 내어 소통해주셔서 감사합니다. 만약 React Native가 가장 좋다고 생각이 들면 Deus 디자인 편집기도 React Native로 만들어주셨으면 좋겠습니다. 명랑한말-2

---이어서--- 또한 Deus 디자인 편집기의 최종 결과물이 정확히 무엇인지 불분명합니다. 이 편집기가 React 컴포넌트를 만드는 것인지 아니면 React Native 코드를 생성하는 것인지 명확하지 않습니다. 만약 두 가지 모두를 지원한다면 각기 다른 기술 스택에 대한 방향성이 통일되지 않았다는 인상을 줍니다. 결론적으로 토스의 기술 블로그들을 보면 프론트엔드 기술 스택에 대한 방향성이 하나로 통일되어 있지 않다는 느낌을 받습니다. 서버 엔지니어링 파트에서 Kotlin과 Coroutine을 사용하는 Spring Framework로 방향성을 명확히 한 것처럼 프론트엔드 역시 Deus라는 디자인 편집기가 PWA를 지원하는 React 기반 웹으로 만들어진 앱을 만들 것인지 아니면 React Native 기반의 앱을 만들 것인지 명확한 방향성을 보여주는 것이 필요해 보입니다. 안녕하세요 명랑한말님, 먼저 토스 프론트엔드에 관심을 가지고 댓글 달아주신 점 감사해요. 토스에서 웹뷰 또는 React Native로 성능에 대해 테스트했을 때, 다음 순서대로 성능이 빠르다는 점을 확인했어요. (측정은 LCP 기준이에요.) 1. 클라이언트에 미리 코드를 다운로드하고 바로 실행하는 경우 2. 서버 사이드 렌더링 (SSR) 을 사용하는 경우 3. 접속할 때마다 새로 HTML, CSS, JS를 내려받아 클라이언트 사이드 렌더링 (CSR) 을 사용하는 경우 토스에서는 사용자 경험이 제일 중요하기 때문에, 클라이언트에서 미리 다운로드했던 코드를 실행하는 방향으로 프론트엔드 아키텍처를 짜고 있습니다. WebView와 React Native로 구성한 모바일 서비스를 비교한 내용에 대해서는, 말씀하신 것처럼 PWA 및 서비스 워커를 이용하면 코드를 미리 다운로드받아둘 수 있습니다. 제시해주신 아티클에서는 일반적으로 가장 많이 WebView로 모바일 서비스를 구성할 때 사용하는 아키텍처와 비교했습니다. 또한, 토스에서는 2023년에 PWA 및 서비스 워커를 이용해서 아키텍처를 구성해서 성능이 일부 개선되는 모습을 확인했으나, 과거 아티클에서 언급한 저사양 기기에서 JavaScript 실행 속도가 느리거나, 웹뷰의 캐싱 정책이 예측하기 어려운 문제가 있었고, 그 외로 iOS 및 Android 웹뷰의 이슈들이 있어, 현재는 React Native 기술에 보다 투자를 하고 있는 상태예요. 토스 개발환경에 관심을 가져 주셔서 감사드려요! 명랑한말-1

잘 읽었습니다. 글에서 언급된 내용과 다른 기술 블로그, 그리고 공개된 오픈소스를 종합해 보면 토스 프론트엔드 기술의 방향성에 대해 몇 가지 의문이 생깁니다. 어떤 글에서는 서버 사이드 렌더링(SSR)이 클라이언트 사이드 렌더링(CSR)보다 빠르고 효율적이라고 강조합니다. 반면, 다른 글에서는 클라이언트에 미리 코드를 다운로드해두는 방식이 서버에서 렌더링 후 결과를 보내주는 것보다 빠르다고 이야기합니다. 이는 서로 다른 접근 방식이며 어떤 상황에서 어떤 방식이 더 우월한지에 대한 명확한 기준 제시 없이 상반된 주장이 나오는 것 같아 혼란스럽습니다. https://toss.tech/article/isomorphic-javascript https://toss.tech/article/react-native-2024 특히 React Native의 우수성을 설명하기 위해 WebView에서 동작하는 React 기반 웹과 React Native 기반 앱을 비교한 것은 공정한 비교라고 보기 어렵습니다. Progressive Web Apps (PWA) 기술을 활용하면 React 기반 웹도 React Native 기반 앱과 유사한 사용자 경험을 제공할 수 있습니다. Bubblewrap이나 PWABuilder와 같은 도구들을 통해 웹을 손쉽게 모바일 앱으로 패키징할 수 있고 서비스 워커를 통해 리소스를 미리 캐싱하여 거의 네이티브 앱에 가까운 로딩 속도를 구현할 수 있습니다. 진정한 비교가 되려면 PWA 기술이 적용된 React 기반 웹으로 만들어진 앱, React Native 기반 앱(React Native로 PWA인 웹을 만들며 이 웹으로 만들어진 앱, React Native로 만든 모바일 앱)의 성능을 비교했어야 한다고 생각합니다. https://github.com/GoogleChromeLabs/bubblewrap https://www.pwabuilder.com/ https://github.com/pwa-builder/PWABuilder ---계속--- 명랑한코끼리

너무 흥미로워요 포근한코알라

오.. 데우스 저도 한번 사용해보고 싶네요