안녕하세요. React Native Framework Team에 속한 Frontend Platform Engineer 강선규입니다. 오늘 소개해 드릴 이야기는 토스에서 만드는 React Native Framework와 그 기능에 관한 이야기에요.토스는 이전 글 토스가 꿈꾸는 React Native 기술의 미래에서 자체적인 React Native 프레임워크를 개발한다고 공개했어요. 이 글을 통해서 해당 프레임워크, Bedrock을 처음 공개해요.Bedrock은 React Native 프레임워크로, 단단한 기반암을 의미하는 이름처럼 프로젝트 개발에 견고한 기초를 제공해요. Bedrock은 안정적이고 신뢰할 수 있는 구조를 바탕으로, 다양한 플랫폼에서 일관된 성능과 사용자 경험을 제공해요. 아직은 토스 내부 및 일부 협력사만 사용할 수 있지만, 추후에 공개를 목표로 오픈소스를 목표로 하고 있어요.기존 React Native 생태계에는 이미 같은 프레임워크가 존재하며, 는 파일 기반 라우팅(File-Based Routing)을 사용해 화면을 정의합니다. Bedrock 역시 이와 유사하게 파일 기반 라우팅을 채택했으며, 이는 v6를 기반으로 합니다.오늘은 토스 자체 React Native 프레임워크 Bedrock가 어떻게 파일 기반 라우팅의 문제를 해결했는지 소개해드릴게요.기존 Bedrock의 파일 기반 라우팅은 을 추상화한 형태로, 폴더에 컴포넌트를 만들고 로 화면을 자동 등록하는 방식이었어요.하지만 이 방식은 화면 간 이동할 때 필요한 파라미터의 타입을 정의하기 어렵다는 문제가 있었어요. 그 결과, 어떤 파라미터가 필요한지 명확하게 알기 힘들었어요.이런 문제 때문에 최근 웹 프론트엔드에서는 처럼 타입 안정성(Type-Safety)을 핵심으로 하는 라우터 프레임워크가 인기를 끌고 있어요.Bedrock도 기존 방식의 한계를 보완하기 위해 tanstack router의 방식에서 영감을 받아 Type-Safe한 파일 기반 라우팅을 도입했어요.이 방식은 co-location 원칙을 적용해서 각 화면의 타입을 같은 위치에서 정의하도록 했어요. 덕분에 더 명확한 개발 경험을 제공할 수 있어요.이 방식에서는 로 파라미터를 검증하고, 그 결과를 자동으로 추론해서 타입으로 활용할 수 있어요. 그래서 라우팅이 더 명확하고 안전해졌어요.기존에는 를 기준으로 페이지가 등록됐지만, 이제는 의 속성을 기준으로 페이지가 등록돼요.또한, 를 활용해 각 화면의 타입을 명확하게 정의할 수 있도록 개선됐어요.화면의 파라미터는 일반적으로 react-navigation의 를 통해 가져올 수 있어요.Bedrock에서는 이를 활용하여 라우팅 로직과 독립적인 를 별도로 정의하고, 해당 훅을 BedrockRoute에 연결하는 방식을 사용했어요.실제 구현은 복잡할 수 있지만, 이해를 돕기 위해 간소화된 코드로 설명할게요.이렇게 만든 는 현재 활성화된 라우트의 파라미터만 가져오며, 아직 타입 안정성은 없어요.이제 위에서 만든 를 BedrockRoute의 반환값에 넣고, 를 통해 타입 추론을

토스 기술 조직의 각 챕터는 라이트닝 토크에서 다양한 주제에 대한 인사이트와 아이디어를 자유롭게 공유합니다. 기록을 통해 생생한 라이트닝 토크 현장을 함께 느껴보세요!프론트엔드 개발을 하면서 좋은 개발 경험이 무엇인지 고민해 보신 적 있으신가요? 요즘 우리는 이미 좋은 환경에서 개발하고 있다고 생각하는데요. 코드 가독성과 일관성을 위한 포맷터와 린터, 복잡한 구현 없이 사용할 수 있는 번들러, 강력한 디버깅 도구들이 모두 우리의 개발 경험에 기여하고 있죠.이번 시간에는 그 중에서도 제가 생각하는 가장 편한 기능을 소개해 보려고 해요. 개발자라면 누구나 한 번쯤 ‘이거 진짜 편하네!’라고 감탄했던 경험이 있을 겁니다. 바로 HMR(Hot Module Replacement)인데요. 코드를 수정하고 저장했을 때, 페이지를 새로고침하지 않아도 변경사항이 즉시 반영되는 기능이죠. 프론트엔드 개발에서는 빠른 피드백 루프가 곧 생산성으로 연결되기 때문에, HMR은 개발자 경험을 혁신하는 핵심 기능 중 하나예요. 웹 개발뿐 아니라 React Native 환경에서도 널리 사용되고 있고요.그럼 먼저 HMR이 어떤 원리로 동작하는지, 그리고 Metro, Webpack, Vite, ESBuild 같은 다양한 번들러가 HMR을 어떻게 지원하는지 살펴볼게요. 그런 뒤, 제가 ESBuild 기반 번들러를 어떻게 만들었는지 그 과정을 소개해 볼게요.HMR은 변경된 코드 조각만 런타임에서 동적으로 교체하는 기능이에요. HMR이 적용되어 있다면 페이지를 새로고침하지 않고도 코드 수정 사항이 즉시 반영돼요. 우리의 일반적인 개발 플로우를 떠올려볼까요?• None 코드를 작성하고 저장한다.• None 페이지를 새로고침하지 않아도 코드가 반영된다.• None 브라우저 또는 React Native 앱에서 즉시 변경된 내용을 확인한다.이 과정에서 가장 큰 장점은 상태를 유지하면서도 코드 변경을 반영할 수 있다는 것입니다. 전체 페이지를 새로고침하면 폼 입력값이나 UI 상태가 초기화되어 불편한데요. HMR을 활용하면 이러한 불편 없이 변경을 확인할 수 있어요.이 HMR 기능은 번들러마다 서로 다른 방식으로 구현되어 있는데요. 대표적인 번들러들의 HMR 구현 방식을 알아볼게요.Metro는 React Native 환경에서 HMR을 지원하는 기본 번들러인데요. 핵심 원리는 모듈을 전역에 등록한 뒤, 변경된 모듈만 교체하는 방식입니다.• None 코드가 변경되면, 해당 모듈의 고유 ID를 찾아 업데이트합니다.• None 전체 앱을 다시 실행할 필요 없이, 변경된 부분만 새로운 코드로 교체됩니다.다음은 Metro의 HMR 지원을 위한 코드 일부예요.Metro는 HMR을 위해 코드를 다음과 같이 변환해요. 라는 함수를 사용해서 각 모듈에 고유한 ID를 부여하고, 이 ID를 이용해 런타임에서 모듈을 참조할 수 있도록 하는 거죠. 중요한 점은 모듈이 런타임에서 교체 가능한 상태로 등록된다는 점입니다. 이 방식 덕분에 React Native 개발 시 빠른 코드 반영이 가능해져요.아래 변환된 코드

프로젝트에 React Native를 도입할 때 크게 두 가지 방식이 있습니다.• None 프로젝트를 처음부터 React Native 로 개발한다.• None 현재 프로젝트에 부분적으로 React Native 를 도입한다.베트남의 토스앱을 개발하던 때는 운영되는 서비스를 잠시 멈추고 React Native로 새로 개발했었습니다. 그 시점에 앱의 기능이 그렇게 많지 않았기 때문에 가능했었습니다. 하지만 한국에서 서비스 하고 있는 토스앱은 그렇지 않았습니다.토스앱은 사실 크로스 플랫폼을 활용하기 위해 React Native를 도입했던 것은 아니었어요. 2021년 코로나가 극심할 때 식당이나 카페등 가게에 출입하기 위해 QR인증을 했는데요. 그때 QR인증을 위해 나라에서 지정한 업체의 SDK를 사용해야 했습니다. 그런데 그 업체가 React Native로 된 SDK를 전달해주었고, 그렇게 토스앱에 React Native가 포함되었습니다.이후 토스 내부에서도 웹서비스의 화면들을 더 빠르게 로드해야 한다는 요구사항과 겹쳐서 React를 다루는 Frontend 개발자들이 앱에 포함되어 있는 React Native를 살려 크로스 플랫폼 도구로 사용하게 되었습니다.토스와 비슷하게 많은 회사들이 각자 다른 이유로 운영 중인 서비스를 크로스 플랫폼으로 확장하고자 React Native를 도입하려고 할 거예요. 이런 경우에 CocoaPods를 사용하지 않고 React Native를 도입하는 방법을 알려드릴게요.React Native와 의존성 관리 도구운영되는 앱에 React Native를 도입하기로 결정했을 때 iOS 개발자의 입장을 생각해봅시다. React Native는 기본적으로 CocoaPods로 설치되도록 되어 있어요. 현재 운영하고 있는 서비스가 CocoaPods를 의존성 관리 도구로 사용하고 있다면, 큰 어려움 없이 React Native를 도입할 수 있습니다.하지만 iOS 개발 환경에는 CocoaPods 외에도 여러 가지의 의존성 관리 도구가 있습니다. 애플의 First Party인 Swift Package Manager 나, Carthage, Rome, 등등이 있습니다. 의존성 관리 도구는 아니지만 프로젝트 설정 관리 도구인 Tuist도 있습니다.그럼 CocoaPods 외에 다른 의존성 관리 도구를 사용하고 있다면 어떻게 React Native를 도입할 수 있을까요? 사용 중인 의존성 관리 도구와 CocoaPods를 함께 사용해야 합니다. CocoaPods를 사용하고 있지 않다면 CocoaPods를 추가하면 되고, CocoaPods를 이미 병행으로 사용하고 있다면 해당 Podfile에 React Native 관련 의존성을 추가하면 됩니다.하지만 이렇게 의존성 관리 도구를 병행하는 것은 좋은 방법이 아닙니다.왜 의존성 관리 도구를 하나만 써야 할까?두 가지 이상의 의존성 관리 도구를 사용한다면 각각의 의존성 관리 도구는 각자가 관리하는 의존성들만 Resolve할 뿐, 서로가 관리하고 있는 의존성을 알 수 없습니다. 즉 CocoaPods에서 A라는

고작 대학생인 내가 스타트업에서 프론트엔드 혼자서 짧은 시간 내에 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로 구현된 부분에 비해 로딩이 더 발생하게 되죠.그럼 사용자 입장에서 웹뷰가 로드되는 동안, 빈 화면을 봐야하는 상황이 됩니다.이에 있어서 피드백을 제공해 주어야하는데, 이는 라이브러리에서