안녕하세요. 인프랩의 향로입니다.저희 인프랩 개발팀은 현재 백엔드, 프론트엔드, 모바일 앱, 데브옵스 파트로 나뉘어져 있습니다.각각의 개발 파트가 어떻게 일 하는지, 어떤 사람과 함께 하고 싶어하는지 등을 소개드리려 합니다.세 번째로 모바일 앱 개발 파트를 소개드리겠습니다.인프랩팀이 새롭게 모바일 앱 개발 파트를 구성하게 되었습니다. 코딩 교육 특성상 대부분의 사용자분들께서 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에

올해부터 DEVOCEAN을 통해서 스터디를 진행하고 있습니다!제가 준비한 주제는 React를 활용해서 크로스플랫폼을 플랫폼 어플리캐이션을 만드는 React Native입니다!이번주는 11주차에 진행한 스터디 내용을 다루는 포스팅 입니다!점점 브레이킹할 아이스 없지만, 계속해서 브레이킹중인 아이스브레이킹 시간 입니다.이번주는 자신의 키워드를 모르고, 다른사람의 키워드만 아는 상태로 내 키워드를 맞추는 '양세찬게임'입니다!이번주는 KJH님께서 준비해주셨습니다 :)생각보다 알듯 말듯 모를듯 맞추는 재미가 있었네요 :)아이스브레이킹은 여기까지!이번주는 React이외에 라이브러리를 사용해서 React Native App을 보다 효율적으로 활용하는 방법에 대해서 다룹니다.이때 App의 상태관리를 할 수 있는 Redux에 대해서 알아보도록 하겠습니다Redux는 JavaScript의 상태관리 라이브러리 입니다.현재의 React ContextAPI가 성숙해 지기 전에 자주 사용하던 라이브러리로, React Native뿐만 아니라 기존 React에서도 종종 사용됩니다.Redux는 store에 상태를 관리할 변수들을 모아놓고, 이 상태를 변경할 때는 dispatch와 action을 통해서만 변경할 수 있게 통제합니다.위에서 정의된 액션 생성 함수는 외부에서 state를 변경하기 위해서 사용되며, react의 useState의 set함수와 유사하게 사용된다고 볼 수 있습니다.위와같은 상태관리 변수는 하나가 아니겠죠?그래서 여러개의 Redux 상태관리를 위해서 combinReducers를 사용해서 관리합니다.위에서 말했듯, Redux는 모든 상태변수를 Redux Store에 저장하고, 이 변화에 따라 App의 상태를 관리합니다.rootReducer로 합친 다양한 모듈을 하나의 store로 만들며, 이때 createStore함수를 이용합니다.그리고 store를 react프로젝트에 적용하게 됩니다.이제 Component 내에서 이 값을 사용해야겠죠?이때 useSelector와 useDispatch hook을 사용하게 됩니다Component내에서 dispatch를 통해서 state가 변경될 경우 해당 Component가 refresh되게 되면서 App의 전역 state관리가 가능해집니다.위 내용을 통해서 어떻게 Redux를 사용하는지는 알았습니다. 하지만 State관리를 위해서 준비해야할게 너무 많습니다.이때 Redux Toolkit을 사용하면 하나의 .js파일을 통해서 위 작업들을 통일할 수 있습니다.아래 Redux Toolkit을 사용한 예제코드를 보시겠습니다.여기서 흥미로운점은 불변성을 위해서 state값을 덮어쓰지 않고 일반 수정연산을 하게됩니다이처럼 redux toolkit을 사용하면 불변성 관리를 해당 라이브러리가 해주기 때문에 보다 편리하게 사용이 가능합니다.이런 전역 State의 경우 App의 로그인 관리등에서 사용됩니다.하지만, ContextAPI가 충분히 편리해진 요즘에는 많이 사용되지는 않고, Legacy Code에서 주로 볼 수가 있습니다.이번