안녕하세요. 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의 반환값에 넣고, 를 통해 타입 추론을

코드 작성에 AI의 도움을 받을 수 있는 가장 유명한 도구 중 하나로, GitHub이 2021년 발표한 GitHub Copilot이 있습니다. 2024년 12월 GitHub Copilot for VS Code 무료 플랜을 제공하기 시작해,제한적(2k/월 코드 어시스트, 50건/월 채팅)이긴 하지만 누구나 활용할 수 있게 되었습니다.그런데 Copilot의 도움을 받으려면 프롬프트로 질의를 작성해야 하며, Copilot이 각자의 환경에 맞춰 답변하게 하려면 매번 프롬프트로 상황을 전달해야 합니다. 이는 매우 귀찮고 불편한 작업일 수 있습니다.이 글에서는 이러한 불편함을 없애고 개인별 환경 또는 프로젝트 환경에서 VS Code Copilot 지침을 만들고 이를 활용하는 방법을 간단한 예시와 함께 소개합니다.커스텀 지침커스텀 지침(custom instruction)을 미리 정의해 두면, Visual Studio Code(이하 VS Code) 내에서 Copilot이 답변할 때 이 지침을 따르도록 설정할 수 있습니다.프로젝트 저장소에 지침서 파일을 저장하면 해당 프로젝트에 참여하는 이들이 모두 동일한 지침에 따라 답변을 얻을 수 있고, VS Code 설정 파일인 settings.json 파일에 개인용 지침을 설정할 수도 있습니다.프로젝트 공통 지침프로젝트 공통 지침을 사용하려면 프로젝트의 .github/copilot-instructions.md 파일에 지침을 작성해 저장소에 푸시합니다.지침서 파일에는 다음과 같이 Copilot 채팅 질의 시 사용자의 질문을 보완하기 위한 컨텍스트 또는 관련 정보를 자연어 형태의 짧은 문장으로 작성합니다.We always write JavaScript with double quotes and tabs for indentation, so when your responses include JavaScript code, please follow those conventions.Our team uses Jira for tracking items of work. 하지만 지침에서 다음과 같이 외부 리소스를 참조하도록 요청하거나 특정 세부 정보 응답을 요청하면 제대로 동작하지 않을 수 있습니다.Always conform to the coding styles defined in styleguide.md in repo my-org/my-repo when generating code.Use @terminal when answering questions about Git.Answer all questions in the style of a friendly colleague, using informal language.Answer all questions in less than 1000 characters, and words of no more than 12 characters. 다음은 지침을 작성하지 않았을 때 Copilot 채팅 질의 답변입니다. 영어로 질의하면 Python 코드와 영어로 답변합니다.이제 다음과 같은 지침을 작성하

안녕하세요. 당근 알림 경험팀에서 프론트엔드 엔지니어로 일하고 있는 딜런(Dylan.lee)이라고 해요.알림 경험팀은 당근 사용자들뿐만 아니라 당근 구성원들의 알림 경험(Notification Experiences)을 책임져요. 사용자가 그동안 받은 알림을 모아볼 수 있는 알림함부터 당근 구성원이 알림을 간편하게 발송할 수 있는 알림 센터까지, 알림과 관련된 다양한 서비스를 만들고 있죠.알림 센터와 같은 서비스를 만들다 보면 필연적으로 인증과 인가를 다루게 돼요. 알림 센터는 다양한 소속의 당근 구성원들이 사용하기 때문에, 민감한 정보는 외부에 노출되지 않도록 소속에 따라 권한을 분리해야 하죠. 또한 마케팅성 알림은 마케팅 팀의 승인이 있는 경우에만 발송할 수 있어야 하고요.이렇게 서비스가 복잡해지고 기능이 고도화될수록 인증과 관련된 코드가 길어지고 복잡해지는 문제가 생겼어요. 이번 글에서는 권한을 선언적으로 관리하며 코드의 복잡성을 효과적으로 개선한 방법을 소개해 드리려고 해요.역할을 기반으로 권한을 관리한다면?알림 센터에서는 사용자에게 발송되는 알림 내용을 템플릿 형태로 관리해요. 이것을 알림 시나리오라고 하는데요. 당근의 모든 구성원은 여기에 접근 권한을 갖고 있지만 외부 협력사는 볼 수 없어야 해요. 이러한 권한은 단순했기 때문에 간단한 분기만으로도 관리할 수 있었어요.const canAccess = (user, entity) => { if (entity === "scenarioPage" && user.company === "daangn") return true; return false;}그러다 권한 정책이 업데이트되었어요. 외부 협력사 직원이더라도 특정 이메일 값을 갖는 사용자라면, 알림 시나리오 페이지에 접근 권한을 가지도록 수정이 필요했어요. 그래서 저는 allow list를 만들어 관리했어요.const allowList = ["john@external.com"];const canAccess = (user, entity) => { if (entity === "scenarioPage" && (user.company === "daangn" || allowList.includes(user.email))) return true; return false;}그러다가 새로운 기능이 추가되었어요. 마케팅성 알림을 발송하기 전에는 마케팅팀에게 리뷰를 요청하고, 마케팅팀이 승인할 때만 발송할 수 있어야 했죠.const allowList = ["john@external.com"];const canAccess = (user, entity) => { if (entity === "scenarioPage" && (user.company === "daangn" || allowList.includes(user.email))) return true; if (entity === "approveButton" && user.team === "marketing") return true; return false;}이번엔 알림 경험팀에 특수한 권한을 부여

토스 기술 조직의 각 챕터는 라이트닝 토크에서 다양한 주제에 대한 인사이트와 아이디어를 자유롭게 공유합니다. 기록을 통해 생생한 라이트닝 토크 현장을 함께 느껴보세요!프론트엔드 개발을 하면서 좋은 개발 경험이 무엇인지 고민해 보신 적 있으신가요? 요즘 우리는 이미 좋은 환경에서 개발하고 있다고 생각하는데요. 코드 가독성과 일관성을 위한 포맷터와 린터, 복잡한 구현 없이 사용할 수 있는 번들러, 강력한 디버깅 도구들이 모두 우리의 개발 경험에 기여하고 있죠.이번 시간에는 그 중에서도 제가 생각하는 가장 편한 기능을 소개해 보려고 해요. 개발자라면 누구나 한 번쯤 ‘이거 진짜 편하네!’라고 감탄했던 경험이 있을 겁니다. 바로 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 개발 시 빠른 코드 반영이 가능해져요.아래 변환된 코드