고작 대학생인 내가 스타트업에서 프론트엔드 혼자서 짧은 시간 내에 0 to 1을 할 수 있었던 이유현재 한 스타트업에 재직하며 2달 반이라는 짧은 시간 내에 앱 버전 2.0.0을 출시해야 했습니다.회사의 BM이 달려있는 유저앱을 담당하는 프론트엔드 개발자는 저 혼자였고,웹 프론트엔드 개발자로써 프로젝트들을 해왔던 저는 빠른 생산성을 위해 웹뷰로 많은 스크린을 구현하기로 결정했습니다.웹뷰로 구현된 부분은 대략 30개(스크린, 바텀시트 등) 이상입니다.웹뷰로 개발하게 되었을 때의 장점은 아래와 같습니다.• None 앱을 배포하지 않아도 웹뷰를 수정하면 반영 가능 => 앱 스토어 심사가 불필요.• None 앱은 최신 버전이 업데이트되면, 사용자들은 사용하고 있는 앱의 버전을 업데이트 해주어야 최근에 배포된 기능들을 사용할 수 있습니다. 이전 버전에 치명적인 버그가 있다고 했을 때, 사용자가 업데이트를 해주지 않는다면 겉잡을 수 없는 상황이 발생할 수 있습니다. 하지만 버전 체크를 통해 앱스토어 링크로 리다이렉트를 시켜준다면, 문제가 발생하지 않겠지만, 잦은 버전 업데이트는 사용자에게 좋지 않은 사용성으로 다가갈 수 있습니다.• None 혹시나 있을 앱 개발 프레임워크의 변경에도 용이하다. 만약 React Native로 개발된 앱이 회사의 사정으로 인해 Flutter로 마이그레이션을 해야한다고 가정했을 때, 웹뷰로 구현된 부분에서의 변경사항은 크게 X.• None 스타트업 입장에서 개발 인력을 구하기가 비교적 어렵지 않습니다. 왜냐하면 앱 개발을 주 스택으로 갖고 계신 분들 보다는, 웹 개발을 주 스택으로 갖고 계신 분이 더 많기 때문.이외에도 많은 장점과 개발 와중에도 혹은 배포 직전에도 계속해서 변경되는 기획 등 현재 제 상황을 고려한 결과, 웹뷰로 많은 부분을 개발하는 것에 점점 마음이 굳혀지게 되었습니다.하지만 main feature는 아무래도 사용자에게 보다 더 좋은 성능으로 보여줘야 했으므로 React Native 코드로 구현했습니다.2달 반동안 제 모든 리소스를 앱 개발에 몰아넣었고, 그 기간 동안 제가 했던 많은 고민을 통해 나온 하이브리드 앱에서의 웹뷰를 관리하는 방법을 공유하고자 합니다.• None React Native에서 각각의 스크린을 라우팅한 방법 & React Native <-> React (앱 <-> 웹뷰) 간 이벤트 처리 방식라이브러리를 활용해서 각각의 웹뷰 스크린을 render 했습니다.이 라이브러리를 활용하면 제가 웹으로 구현했던 부분을 앱 내에서 웹뷰로써 띄울 수 있으며,해당 웹뷰와 앱 간의 이벤트를 주고받아 특정 데이터 처리, 혹은 다른 스크린으로의 이동 등의 액션을 취할 수 있습니다.props로 source에 객체로 uri에 위와 같이 넘기게 되면 해당 페이지가 render됩니다.하지만 웹뷰 특성상 React Native로 구현된 부분에 비해 로딩이 더 발생하게 되죠.그럼 사용자 입장에서 웹뷰가 로드되는 동안, 빈 화면을 봐야하는 상황이 됩니다.이에 있어서 피드백을 제공해 주어야하는데, 이는 라이브러리에서

안녕하세요. 인프랩의 향로입니다.저희 인프랩 개발팀은 현재 백엔드, 프론트엔드, 모바일 앱, 데브옵스 파트로 나뉘어져 있습니다.각각의 개발 파트가 어떻게 일 하는지, 어떤 사람과 함께 하고 싶어하는지 등을 소개드리려 합니다.세 번째로 모바일 앱 개발 파트를 소개드리겠습니다.인프랩팀이 새롭게 모바일 앱 개발 파트를 구성하게 되었습니다. 코딩 교육 특성상 대부분의 사용자분들께서 PC 웹 브라우저를 주력으로 사용하시다보니 웹 서비스에 집중을 하게 되었습니다.그동안은 웹 프론트엔드 개발자분들이 처음 앱을 출시하고, 웹 서비스를 메인으로 하면서 하면서 앱을 운영해왔는데요. 그러다보니 앱에 대한 여러 불편 사항을 제때 해결하지 못했습니다.그래서 인프런의 앱 서비스를 새롭게 개편하기로 결정하고, 이에 맞춰 React Native 기반의 모바일 앱 개발을 전담할 개발팀을 구성하게 되었습니다.앞서 언급했듯이 인프랩 팀에는 그동안 모바일 앱 전담팀이 없었습니다. 그러다보니 제로에서 시작하는 개발팀에 대한 걱정과 우려로 다음과 같은 궁금증이 생깁니다.• 코드리뷰는 하고 있는걸까? 서비스 기능 개발하기에 바빠서 각개전투 하는건 아닐까?• 테스트 코드를 작성하고 있을까?• 리팩토링 / 생산성 향상 등에 관심이 있을까?• 성장을 위한 피드백 문화가 있을까?• 구성원의 성장을 위해 회사에서는 어떤 지원을 해줄까?개발자의 성장에 있어 가장 중요한건 개인의 노력인데요.그렇다면 회사에서 해줄 수 있는 것은 무엇일까요?제 생각에는 그 사람이 성장할 수 있는 좋은 재료와 환경을 제공해주는 것이 아닐까 싶습니다.인프랩의 모바일 앱 (React Native) 개발 파트를 소개드리려고 합니다.이런 환경이라면 좋은 개발자로 성장할 수 있지 않을까 생각해보는 시간이 되셨으면 합니다.현재 인프랩 모바일 앱 개발 파트는 총 2명의 개발자로 이루어져있습니다.• 모바일 앱 개발자는 프로덕트 조직인 셀 (Cell) 과 프론트엔드 파트 (Part) 에 속합니다.• 셀 (Cell) 에서는 PM, 디자이너와 함께 모여 일하며 셀에서 맡은 제품을 개선하고 문제를 해결하고 있습니다.• 프론트엔드 파트 (Part) 에서는 매주 정기적으로 모여 각 셀에서 발생했던 장애에 대한 공유나 좀 더 일을 잘하기 위한 방법, 기술적인 공유 등을 하는 시간을 가지고 있습니다.• 스프린트 회고, 프로젝트 회고, 분기 회고, 반기 회고 등 다양한 회고를 기반으로 항상 더 나은 방식으로 문제를 해결하기 위한 개선을 진행합니다.인프랩의 모바일 (React Native) 개발자는 다양한 기기/브라우저에 맞춰 사용자를 위한 클라이언트 애플리케이션 개발을 담당합니다.• TypeScript, React Native 를 기반으로 Android / iOS 애플리케이션을 개발하고 배포합니다.• 상황에 맞게 적절한 형태로 IOS, Android 네이티브 구현과 웹앱 구현을 나눠 진행합니다.• 모바일 영상 플레이어, OAuth 를 비롯한 각 서비스에 필요한 기능들을 구현, 개선 합니다.• 요즘은 특히 모바일 영상 플레이어와 영상 보호 기

안녕하세요, 토스 프론트엔드 엔지니어링 헤드 박서진입니다.토스에서는 최고의 사용자 경험이 필요한 곳은 Native, 매일매일 실험으로 제품을 개선하는 제품은 React Native/WebView로 구성하고 있어요.토스 프론트엔드 챕터는 지난 2022년 6월부터 React Native 기술에 투자하고 있는데요. 이번 기술 블로그 아티클에서는 왜 React Native를 고려하고 있는지, 현재 어느 정도까지 사용하고 있는지, 그리고 앞으로의 계획이 어떻게 되는지에 대해서 소개드리려고 합니다.토스는 React Native로 매끄러운 사용자 경험과 높은 개발 생산성을 제공하여, 모바일 서비스를 만드는 새로운 표준을 제시하고자 해요.React Native로 서비스를 개발하면, WebView로 서비스를 만들 때보다 사용자 경험을 크게 개선할 수 있어요. React Native는 기본적으로 파일 시스템에서 JavaScript 파일을 읽어오기 때문에, WebView와 다르게 네트워크로 인한 로딩 속도를 없앨 수 있기 때문이죠.한국처럼 대부분의 사용자가 2020년 이후에 출시한 최신 핸드폰을 쓰는 환경에서는, JavaScript 실행도 매우 빨라요. 토스에서 “매일 방문 미션” 제품을 React Native로 만들었을 때, 1초 이상의 로딩 속도를 감축시킬 수 있었어요.특히 앞으로 모바일 기기 성능 발전과 더불어서 JavaScript 실행 속도는 매년 두 자릿수 퍼센티지로 빨라지고, 로딩 시간은 그만큼 계속 줄어들 것으로 보여요. Hermes 엔진으로 JavaScript를 미리 컴파일하면 초기 로딩 속도를 더 빠르게 할 수도 있답니다. (사진 출처)프론트엔드 개발자의 개발 생산성도 개선할 수 있는데요.먼저, WebView에서 생산성을 깎는 다양한 문제를 근본적으로 해결할 수 있었어요. 토스는 모바일 서비스를 WebView로 만들면서, 여러 제약이 있다는 것을 알게 되었어요. iOS에서는 와 문제가 있었고, Android는 WebView 버전마다 웹 서비스가 다르게 동작하기도 했죠. History도 마음껏 수정하기 어려웠습니다. React Native는 Native 렌더러를 사용하고, 높은 자유도를 제공하기 때문에, 이 문제를 모두 깔끔히 해결할 수 있었어요.또한, 빌드와 배포 속도를 개선할 수 있었어요. 보통 WebView 기반으로 서비스를 만들면 빌드가 느리다는 문제에 맞닥뜨리게 되어요. SSR을 쓰는 경우 서버를 빌드하고 배포하는 시간이 필요하죠. 반면, React Native 기술에서는 배포 단계가 단순해서, 정적인 JavaScript 파일 1개만 빌드하고 업로드하면 돼요. 그래서 배포가 완료되기까지의 시간을 손쉽게 최적화할 수 있죠.마지막으로, 코드의 복잡도도 낮출 수 있었어요. 토스는 100개 넘는 Server-side rendering (SSR) 서비스를 운영하고 있는데요. SSR을 이용하면 기존의 Client-side rendering 접근보다 로딩 속도를 크게 개선하지만, Server와 Client를 넘나드는 Universal한 코드를 작

올해 DEVOCEAN을 통해서 스터디를 진행했습니다.제가 준비한 주제는 React를 활용해서 크로스플랫폼을 플랫폼 어플리캐이션을 만드는 React Native입니다!이번주는 12주차, 마지막주에 진행한 스터디 내용을 다루는 포스팅 입니다!스터디시간에 다들 다음주는 뭐할지 궁금해하던 마지막 아이스브레이킹 입니다.이번시간에는 LJia님께서 준비해주신 마피아게임으로, 마지막 아이스브레이킹을 진행 했습니다.아쉬운 마지막 아이스브레이킹을 뒤로하고, 이번주에 배운 내용을 살펴봅니다.이번주역시 React이외에 라이브러리를 사용해서 React Native App을 보다 효율적으로 활용하는 방법에 대해서 다룹니다.App의 전역 상태관리를 할 수 있는 Recoil에 대해서 알아보도록 하겠습니다Recoil의 경우 atom이라고 하는 method를 통해서 createstate와 비슷한 동작을, useRecoilState를 통해서 useState와 비슷한 인터페이스를 제공합니다.보시면 알겠지만 Recoil은 React Hook과 굉장히 유사한 사용경험을 가지고 있습니다.Recoil을 다른 컴포넌트에서 접근시키기 위해서는 RecoilRoot를 사용합니다.이 패턴 역시 ContextAPI 혹은 Redux와 유사한 것을 볼 수가 있습니다.이때 전역 State는 하나의 값이 아니라, 여러값을 관리하겠죠?이때 Recoil같은 경우 다수의값을 을 선택적으로 접근하게 할 수 있는 라고하는 method를 제공합니다.Redux와 유사하지만, 보시는것처럼 좀더 편리한 인터페이스를 제공하는 것을 볼 수 있습니다.하지만 이미 Context API의 UX 편리해진 시점에서, 크게 사용의 필요성이 느껴지진 않네요.여기까지 React Native를 다루는 기술 책에서 핵심 내용들만 추려보았습니다!이번주는 12주동안 진행한 스터디 + 조별과제의 마지막 시간 입니다.처음에 진행 방법을 조정하는데 어려움이 있던것을 생각하면, 다행히 중도하차인원 없이 모든 스터디원분들이 마지막까지 열심히 달려주셨습니다.1조는 식테크(식물 제테크)를 주제로한 싱그럼 이라는 App으로 과제를 마무리 했습니다.1조의 경우 아이디에이션이 오래 걸렸고, 실제 코드로 구현하기 시작한 시간이 늦은 편 이었습니다.그래서 와이어프래임 수준에서 App을 구현하였습니다.특이사항으로는 공공데이터를 사용해서 App에 적용했고, 이 결과를 모두같이 확인할 수가 있었습니다.자료를 보시면 알겠지만, App의 상세화면 설계는 충분히 되었지만프로젝트의 설계 대비 시간의 부족으로 아쉬움이 남은 프로젝트 입니다.2조의 경우, 득근득근이라는 주제로 운동 루틴을 관리할 수 있는 App 프로젝트를 진행 했습니다.2조의 경우 지난 식단, 운동관리 어플리캐이션에 더불어서 카카오지도 API를 접목해서 주변 헬스장정보를 찾을수 있게 하려했습니다.2조같은 경우 Nested Conext API, Nested Router가 되었을 때 발생한 문제점들에 대해서 공유하는 시간이 있었습니다Nested구조가 될 경우, Hook을 사용해서 router, Context에