새로운 기능을 개발하다 보면 이런 순간이 찾아와요. 모니터에는 수십 개의 탭이 열려있고, 팀 내부 도구 사용법을 찾아보려는데 문서가 어디 있는지조차 기억나지 않죠. 결국 동료에게 메시지를 보내고 답장을 기다리면서 개발 흐름이 끊기고 맙니다. 익숙한 상황이죠?
토스 프론트엔드 챕터도 비슷한 문제를 경험하고 있었는데요. 이 문제를 조금 다르게 풀어 봤습니다. 문서를 더 잘 써서 방문하게 하는 대신, 문서가 직접 찾아가는 방식으로요.
문서의 경로의존성 깨기
문서의 경로의존성은 사용자가 원하는 정보를 찾기 위해 정해진 경로를 따라가야 하는 제약을 뜻해요. 기존의 기술 문서는 생산자 입장에서 구조화되어 있어서 사용자 입장에서 원하는 정보를 찾으려면 여러 번의 탐색, 혹은 검색이 필요하죠. 이런 문서의 경로의존성을 깨기 위해 먼저 개발자들이 어떻게 일하는지 관찰하고, 인터뷰했어요. 
개발자들이 지식을 얻기 위해 주로 사용하는 방식은 “질문하기”였어요. 옆에 있는 동료에게 물어보거나, 사내 메신저 채널에 질문을 던지는 거죠. 자연스럽고 공감되는 행동이었어요. 그래서 이런 개발자의 행동을 존중하는 방식으로 문서의 형태를 바꿔보기로 했습니다.
질문하기의 가장 큰 장점은 원하는 정보를 즉각적으로 얻을 수 있다는 거예요. 방대한 문서를 검색하고 읽는 것보다 동료에게 직접 물어보는 것이 시간과 노력 면에서 훨씬 효율적이에요. 개발자들이 문서를 더 적극적으로 활용하게 하려면, 이러한 즉각성이 문서에도 필요하다고 생각했어요. 마치 대화하듯이 문서에 질문을 던졌을 때 맥락에 맞는 답변을 바로 받을 수 있다면, 문서는 더욱 강력한 도구가 될 거예요.
그렇게 탄생한 도구가 바로 ‘박씨’에요.
박씨: 질문하면서 문서 읽기
특징: 질문하면 문서 내용을 기반으로 답변해줘요. 일의 흐름이 끊기지 않고 바로바로 정보를 얻을 수 있어요.
위치: IDE(VSCode, Cursor)와 사내 메신저에 있어요.
효과: "문서 찾기"가 아닌 "대화하듯 물어보기”로 지식을 얻을 수 있어요.
재밌는 점: 박씨는 프론트엔드 챕터 헤드 서진님의 페르소나를 따서 만들어 졌어요.


박씨는 LLM이 더 정확하고 신뢰할 수 있는 답변을 만들어내기 위해 개발된 RAG(Retrieval-Augmented Generation) 기반 챗봇이에요. 기존 문서들을 바탕으로 믿을 수 있는 정보를 답변하고, 그 출처를 함께 제공해요. 박씨를 사용하면 문서를 탐색하거나 키워드로 검색할 필요 없이, 궁금한 점을 자연스럽게 물어보면서 필요한 정보를 얻을 수 있어요. 동료에게 물어보는 것보다 더 정확하고, 누구에게나 일관된 답변을 제공한다는 장점이 있죠.
박씨가 좋은 품질의 답변을 하려면 탄탄한 기반 지식이 필요해요. 그래서 저희는 문서의 양과 질을 모두 높이는 것에도 많은 공을 들이고 있어요. 하지만 테크니컬 라이터와 소수의 개발자들만으로는 충분한 문서를 만들기 어려웠어요. 이 시스템이 확장성을 가지려면 누구나 자신의 지식을 쉽게 문서화할 수 있어야 했죠. 그래서 실록봇이라는 문서 자동화 도구를 만들었답니다.
실록봇: 대화를 바로 문서화하기
역할: 사내 메신저 대화 속 중요 정보를 쉽게 문서화해요.
작동방식: 대화 스레드에 실록봇 이모지를 붙이거나 봇을 호출하면 AI가 대화를 분석하고 요약해서  PR을 올려요.
효과: 사람이 시간을 내서 문서를 따로 작성하는 것이 아니라, 실제 문제 해결 과정에서 자연스럽게 그리고 자동으로 기록할 수 있어요.

실록봇은 팀 내에서 오가는 중요한 대화를 요약해서 자동으로 문서화 해줘요. 사실 개발자들은 사내 메신저에서 질문에 답하거나 대화하며 항상 지식을 교류하고 있더라구요. 그런 대화가 메신저에서 일어나기 때문에 빠르게 휘발되고, 반복적으로 같은 질문이 올라오는 게 아쉬웠어요. 실록봇은 메신저에서 일어나는 대화를 요약해서 문서 리포지토리에 PR을 만들어요. 메신저에 남긴 유용한 메시지나 논의 스레드를 최소한의 노력으로 기록할 수 있게 된 것이죠.
예를 들어, 어떤 버그를 해결하기 위해 나눈 대화가 도움이 됐다고 생각한 팀원이 실록봇을 호출해요. 그러면 그 대화는 바로 문서가 되고, 이렇게 만들어진 정보는 박씨가 학습해요. 덕분에 팀원들은 같은 질문을 반복할 필요 없이 실록봇이 모은 정보와 박씨를 사용해 쉽게 해결책을 찾을 수 있어요. 문서를 위한 문서 작성이 아니라, 지식이 공유되는 순간에 자연스럽게 문서가 만들어지는 거예요.
지식이 흐르는 팀
박씨와 실록봇 덕분에 이제 토스 프론트엔드 챕터는 특정 팀원에게 지식이 몰려있거나, 같은 질문이 반복되는 문제가 줄었어요. 필요한 순간에 필요한 정보가 제공되면서 팀 내 지식이 자연스럽게 흐르는 환경이 되었답니다. 그리고 이런 환경이 팀의 생산성과 효율성을 높이고 있어요. 개발자의 행동을 관찰하고, ‘기술 문서’를 정적인 정보 모음이 아니라 개발자의 학습과 문제 해결을 도와주는 시스템으로 접근했던 것이 유효했어요.
테크니컬 라이팅도 함께 진화하고 있는데요. 이전에는 공급자 관점에서 정보를 구조화하고 특정 기능을 효과적으로 설명하는 것에 초점을 맞췄다면, 지금은 개발자가 문서를 잘 사용할 수 있는 시스템을 만드는 데 집중하고 있어요. 결국 테크니컬 라이팅의 본질은 ‘어떻게 문서로 개발자의 문제 해결을 도와줄 수 있을까’이기 때문이에요.
토스 프론트엔드 플랫폼 팀은 지식을 공유하고, 접근하기 좋은 학습 인프라를 만드는 여정에 함께하실 분을 기다리고 있어요. AI 기반 문서화 시스템을 더욱 발전시키고, 코드와 자연스럽게 연결되는 문서 자동화 시스템을 만들고, 사내 메신저를 비롯한 여러 플랫폼과 잘 어우러지는 문서 생태계를 구축하는 일들이 기다리고 있어요.
개발자들이 더 효율적으로 일할 수 있는 환경을 만들어서 개발자 경험을 한 단계 높이는 일에 관심 있으신가요? 그렇다면 Frontend Platform Engineer에 지원해 주세요! 함께 더 나은 개발 문화를 만들어가요.



새로운 기능을 개발하다 보면 이런 순간이 찾아와요. 모니터에는 수십 개의 탭이 열려있고, 팀 내부 도구 사용법을 찾아보려는데 문서가 어디 있는지조차 기억나지 않죠. 결국 동료에게 메시지를 보내고 답장을 기다리면서 개발 흐름이 끊기고 맙니다. 익숙한 상황이죠?
토스 프론트엔드 챕터도 비슷한 문제를 경험하고 있었는데요. 이 

토스 프론트엔드 팀은 이제 문서를 찾아 헤매지 않아요. 문서와 AI로 개발자의 질문에 바로 답변해주는 환경을 만들고 있거든요. 개발에만 온전히 집중할 수 있는 새로운 문서 시스템, 어떻게 만들었는지 알려드려요.

토스 프론트엔드 개발자들이 더 이상 문서를 찾지 않는 이유

다른 회사나 서비스에서 만든 API를 사용해 본 경험이 있으신가요? 복잡한 API를 파악하거나 새로운 업데이트를 적용하려고 할 때 설명이 정확하지 않다면 API를 적용하는 데 어려움을 겪죠. 그래서 API를 외부 개발자에게 제공할 때, 명확하고 쉽게 이해할 수 있는 문서는 필수적이에요.
토스페이먼츠는 최고의 문서 경험을 

MDX, OAS, remark를 활용한 토스페이먼츠의 API 문서 엔지니어링에 대해 소개해요.

더 자유롭고, 빠르고, 정확하게: 토스페이먼츠 API 문서 엔지니어링

지난 콘텐츠에서는 테크니컬 라이터의 역할과 그동안 해왔던 일을 중점적으로 소개해 드렸어요. 이번 콘텐츠에서는 토스의 테크니컬 라이터가 개발자 경험 전반으로 역할을 확장해 온 이야기를 공유해요.
개발자 경험(Developer eXperience)이란?
‘개발자경험’에 대해 들어보신 적 있나요? 이제 친숙한 개념이 된 UX(

토스의 테크니컬 라이터가 하는 일에 이어, 개발자 경험 전반으로 역할을 확장해 온 이야기를 공유해요.

그 많은 개발 문서는 누가 다 만들었을까 (2) 개발자의 학습을 돕는 모든 것

안녕하세요, 저는 토스페이먼츠 테크니컬 라이터 한주연입니다. 지난 3년 동안 토스페이먼츠와 토스 커뮤니티에서 테크니컬 라이터로 일을 해왔는데요. 토스 커뮤니티의 테크니컬 라이터들은 개발자를 위한 문서를 쓰는 것뿐만 아니라, 멋진 개발자 경험을 제공하기 위해 다양한 일을 하고 있답니다. 이번 시리즈에서는 테크니컬 라이터의 

토스 커뮤니티의 테크니컬 라이터들은 개발자를 위한 문서를 쓰는 것뿐만 아니라, 멋진 개발자 경험을 제공하기 위해 다양한 일을 하고 있답니다.

그 많은 개발 문서는 누가 다 만들었을까 (1) 토스페이먼츠 테크니컬 라이터가 하는 일


여러분 토스 혜택탭 들어가보신 적 있나요?
토스 혜택탭에서는 오늘의 행운복권, 버튼 누르기, 미라클 모닝, 예적금 만들기 등 혜택을 받을 수 있는 다양한 유형의 수십가지 서비스들을 제공하고 있어요. 이렇게 다양하고 수많은 혜택 서비스들을 하나의 탭 안에서 제공하다 보니, “이렇게 많은 혜택 서비스들을 어떻게, 잘, 유저에게 보여주지?” 라는 고민이 당연히 따라오게 되는데요. 



30여개의 다양한 혜택 서비스들을 어떻게 카테고라이징할까? 라는 문제 의식에서 먼저 UX리서치를 해보기로 했어요. 



문제
현재 혜택탭에서는 다양한 혜택 서비스들을 리스트 형식으로 제공하고 있어요. 
여러가지 혜택 서비스를 나열하여 제공하다 보니 스크롤을 내리지 않으면 어떤 서비스들이 있는지 한눈에 파악하기 어렵고, 공급자 입장에서도 이 넓은 화면을 경제적으로 쓰고 있는 것 같지 않아서 고민이 있었죠.

그 고민의 해결책 중 하나로 “혜택 서비스들을 카테고라이징해서 제공한다” 측면에서 접근해보고자 했어요. 약 30개의 혜택 서비스를 이용 목적이나 패턴을 고려해서 4가지 카테고리로 나눠 화면에서 제공하는 거죠. 그래서, 그 전에 “우리가 제공할 카테고리가 유효할까?”를 알아보는게 중요하다고 생각해 유저리서치를 시작하게 되었어요.



가설
리서치에서 알아보고 싶은 것은 주요하게 두가지였어요.
우리가 제공하는 4가지 카테고리가 유효할까? 
이 분류가 유저의 생각과 다르다면 유저 입장에서는 혜택 메뉴들을 어떤 카테고리로, 어떻게 분류할까?




설계
알아보고 싶은 부분을 정의한 후, 이 것을 알기위해 어떤 방식으로 어떤 유저를 만날지 구체적으로 계획을 세웠어요.

방식
알아보고 싶은 부분 잘 알아내기 위해 이번 리서치에서 제가 이용한 방식은 ‘카드소팅’인데요. 
카드소팅은 유저가 주어진 정보, 서비스 등을 어떻게 묶고(카테고라이징)하고 분류하는지 알고자 할 때 사용하면 효과적인 방법론이에요. 카드소팅은 분류가 필요한 여러 메뉴를 카드로 만들어 참여자에게 제시하고 참여자가 그 카드들을 직접 분류해보며 이야기 나누는 거죠. 주로 사용하는 방식으로는 열린 카드소팅, 닫힌 카드소팅, 하이브리드 카드소팅이 있어요.
이번 리서치에서는 현재 기획한 카테고리가 유효한지 확인하고, 유저가 생각하는 카테고라이징 방식을 알아보는 게 목적이었어요. 그래서 만들어둔 카테고리에 사용자가 메뉴 카드를 배치하는 ‘닫힌 카드소팅’과 만들어둔 카테고리에 더해 사용자가 직접 카테고리를 추가해 메뉴 카드를 배치할 수 있는 ‘하이브리드 카드소팅’을 혼합한 방식을 선택했어요.

대상
어떤 유저를 만나야할지 고민했을 때, 고려사항은 크게 두가지였어요.
유의미한 혜택 메뉴 카드소팅을 위해, 유저가 토스 혜택 서비스에 대해 어느정도 이해하고 있어야 한다.
혜택 서비스 이용 유저의 연령대 분포 등 인구통계적 조건을 고려해 대상자를 선정해야 한다.
혜택 서비스의 카테고리에 대한 리서치이기 때문에, 한 번도 안 써본 분 보다는, 적어도 개별 서비스에 대해 어느 정도 이해도가 있는 분들이 적합할 거라 생각했어요. 
그럼 혜택 서비스를 많이 써봐서 완벽하게 이해하고 있는 분들만 모셔야 하나? 를 고민했는데요. 고민해봤을 때 일정 기간 이상 지속적으로 혜택탭에서 혜택 서비스를 1~2가지 이상 이용해본 정도면 혜택 서비스를 ‘어느정도 이해’하는데는 지장이 없다고 판단했어요. 
이에 더해 혜택 서비스를 이용하는 연령대 등도 함께 고려하여 최종적으로 리서치 대상을 확정했답니다.
 
설계할 때 한 번 더 고민했던 부분
저희가 제공하는 카테고리의 유효성 뿐만 아니라, 저희가 생각하지 못한 사용자가 생각하는 유효한 카테고리가 있을지도 알아보고 싶었어요. 
여기서 한가지 고민이 있었어요. 바로 토스의 혜택 메뉴들 대부분이 라이브 쇼핑 포인트 받기, 버튼 누르기 포인트 받기, 만보기 포인트 받기 등 ‘포인트 받기’ 로 끝난다는 거였죠. 유저분들이 포인트라는 표현에 집중해서 많은 분들이 ‘포인트’ 카테고리를 만들어서 카테고라이징 할 것 같았거든요. 이렇게될 경우 너무 뻔하고 유의미하지 않은 결과가 나오기에, 이렇게 ‘포인트’ 처럼 표면적인 단어 등 표현에 집중해서 카테고리 생성/분류되기 보다는 서비스 자체를 이해하고 그 기반으로 카드소팅이 진행될 수 있도록 ‘포인트로 카테고리를 만들면 ‘포인트’를 다른 단어로 바꾼다면 무엇일 것 같은지?’, ‘포인트로 묶은 카테고리에서 한번 더 나눠본다면 어떻게 나눌지?’ 등 시나리오를 한번 더 고민해서 짰던 것 같아요.





결과
리서치를 진행한 결과, 현재 기획한 카테고라이징이 유효하지 않으며 전반적으로 개선이 필요하다는 점을 알 수 있었어요.
여러명의 유저분들이 혜택 메뉴 분류에 있어 출석에도 포함되고 실시간에도 포함될 것 같다고 생각하거나, 출석하는 혜택 서비스들 안에 실시간이 포함되어 있다고 생각하는 등 ‘출석’, ‘실시간’ 카테고리의 명칭 이해나 그 위계 구분을 어려워 하시는 점을 발견했어요.
더하여, 4가지 카테고리 메뉴 분류에 있어 우리의 생각과 유저의 생각이 크게 달랐던 부분들도 확인했어요.
예시로 ‘토스 쇼핑 구경하고 포인트 받기’ 서비스의 경우 구경하는 행위를 매번 하는 부분에 있어 ‘출석’카테고리로 제공하는 것을 기획했는데, 대부분의 카드소팅 참여자가 쇼핑은 일상적으로 하는 행위, 소비라는 인식에 있어 ‘생활’ 카테고리로 분류했어요. ‘인터넷 요금 할인 받기’ 서비스의 경우에도 지출하는 요금을 할인 받는 부분에 있어 ‘금융’ 카테고리로 제공하는 것을 기획했는데, 대부분의 카드소팅 참여자가 교통비, 통신비, 공과금과 같이 일상에서 고정적으로 발생하는 지출이라는 인식에서 ‘생활’로 분류했죠. 



이 밖에도 유저가 ‘포인트’ 관련 서비스들을 세분화해서 어떻게 묶는지, 어떤 혜택 서비스끼리 얼마나 자주 카테고라이징 되는지 등 전반적으로 확인함에 있어 더 나은 카테고라이징 방식을 고안하는데 유의미한 인사이트를 얻을 수 있었어요. 



이러한 리서치 결과를 혜택탭을 만드는 팀에 공유드리며 함께 이야기나눴고, 
이 결과를 바탕으로 팀에서는 유저가 명칭 이해나 위계 구분을 어려워했던 ‘출석’은 카테고리 상에서 보류하고, 기획했던 카테고리와 유저의 생각이 비슷했던 ‘금융’, ‘생활’ 카테고리, 그리고 이번 카드소팅 리서치를 통해 새롭게 도출한 ‘쇼핑’ 카테고리를 혜택탭 안에서 어떻게 보여줄 지 고민하며 열심히 혜택탭을 개선하고 계세요!
더 나아가 이번 리서치를 통해 도출한 여러가지 카테고라이징 옵션들을 바탕으로, 이후에 혜택을 어떻게 유저별로 맞춤화해서 제공할지도 고려해보고 있답니다.



이렇게 토스에서는 유저에게 더 편하고 좋은 경험을 제공하기 위해 계속해서 유저리서치를 진행하고 있어요. 기회가 된다면 토스에서 진행한 유저리서치는 또 어떤 것들이 있는지 소개해드리도록 할게요!



적용해보기
여러 메뉴를 카테고라이징해서 제공하는 구조를 만드는데 고민이 있다면 카드소팅을 해볼 수 있어요.
다양한 유형의 다수의 서비스를 카테고라이징해서 제공하는 것을 고민하고 있다면 유저리서치를 통해 유저가 생각하는 카테고라이징을 알아볼 수 있어요. (단, 고민의 앞단인 문제/배경을 고려했을 때 문제를 해결하기 위한 해결책으로 ‘카테고라이징’이 적절한지부터 생각해보면 좋겠죠?)

리서치 설계에 있어, 설계대로 진행했을 때 예상되는 리서치 결과를 꼭 생각해보세요.
결과를 생각해봤을 때, 이미 알고 있는 내용, 뻔한 결과가 나올 것 같다고 예상되는 부분이 있다면 해당 결과/인사이트가 나왔을 때 얼마나 유의미할 지 판단해보고 리서치 진행 여부 자체를 고민해보거나, 어떻게 하면 더 유의미한 결과를 뽑을 수 있을지 꼭 생각해보세요.



여러분 토스 혜택탭 들어가보신 적 있나요?
토스 혜택탭에서는 오늘의 행운복권, 버튼 누르기, 미라클 모닝, 예적금 만들기 등 혜택을 받을 수 있는 다양한 유형의 수십가지 서비스들을 제공하고 있어요. 이렇게 다양하고 수많은 혜택 서비스들을 하나의 탭 안에서 제공하다 보니, “이렇게 많은 혜택 서비스들을 어떻게, 잘, 유저

여러가지 메뉴를 카테고라이징해서 제공하는 것을 고민하고 있을 때 해볼 수 있는 UX리서치 방법을 소개해드릴게요.

메뉴 구조가 고민될 때 해볼 수 있는 UX리서치

안녕하세요, 토스 프론트엔드 엔지니어링 헤드 박서진입니다.
토스에서는 최고의 사용자 경험이 필요한 곳은 Native, 매일매일 실험으로 제품을 개선하는 제품은 React Native/WebView로 구성하고 있어요.
토스 프론트엔드 챕터는 지난 2022년 6월부터 React Native 기술에 투자하고 있는데요. 이번 기술 블로그 아티클에서는 왜 React Native를 고려하고 있는지, 현재 어느 정도까지 사용하고 있는지, 그리고 앞으로의 계획이 어떻게 되는지에 대해서 소개드리려고 합니다.
왜 React Native인가
토스는 React Native로 매끄러운 사용자 경험과 높은 개발 생산성을 제공하여, 모바일 서비스를 만드는 새로운 표준을 제시하고자 해요.


React Native로 서비스를 개발하면, WebView로 서비스를 만들 때보다 사용자 경험을 크게 개선할 수 있어요. React Native는 기본적으로 파일 시스템에서 JavaScript 파일을 읽어오기 때문에, WebView와 다르게 네트워크로 인한 로딩 속도를 없앨 수 있기 때문이죠.
한국처럼 대부분의 사용자가 2020년 이후에 출시한 최신 핸드폰을 쓰는 환경에서는, JavaScript 실행도 매우 빨라요. 토스에서 “매일 방문 미션” 제품을 React Native로 만들었을 때, 1초 이상의 로딩 속도를 감축시킬 수 있었어요. 

특히 앞으로 모바일 기기 성능 발전과 더불어서 JavaScript 실행 속도는 매년 두 자릿수 퍼센티지로 빨라지고, 로딩 시간은 그만큼 계속 줄어들 것으로 보여요. Hermes 엔진으로 JavaScript를 미리 컴파일하면 초기 로딩 속도를 더 빠르게 할 수도 있답니다. (사진 출처)

프론트엔드 개발자의 개발 생산성도 개선할 수 있는데요. 

먼저, WebView에서 생산성을 깎는 다양한 문제를 근본적으로 해결할 수 있었어요. 토스는 모바일 서비스를 WebView로 만들면서, 여러 제약이 있다는 것을 알게 되었어요. iOS에서는 display: fixed와 autoFocus 문제가 있었고, Android는 WebView 버전마다 웹 서비스가 다르게 동작하기도 했죠. History도 마음껏 수정하기 어려웠습니다. React Native는 Native 렌더러를 사용하고, 높은 자유도를 제공하기 때문에, 이 문제를 모두 깔끔히 해결할 수 있었어요.


또한, 빌드와 배포 속도를 개선할 수 있었어요. 보통 WebView 기반으로 서비스를 만들면 빌드가 느리다는 문제에 맞닥뜨리게 되어요. SSR을 쓰는 경우 서버를 빌드하고 배포하는 시간이 필요하죠. 반면, React Native 기술에서는 배포 단계가 단순해서, 정적인 JavaScript 파일 1개만 빌드하고 업로드하면 돼요. 그래서 배포가 완료되기까지의 시간을 손쉽게 최적화할 수 있죠.


마지막으로, 코드의 복잡도도 낮출 수 있었어요. 토스는 100개 넘는 Server-side rendering (SSR) 서비스를 운영하고 있는데요. SSR을 이용하면 기존의 Client-side rendering 접근보다 로딩 속도를 크게 개선하지만, Server와 Client를 넘나드는 Universal한 코드를 작성해야 해요. 두 환경을 모두 고려해야 하기 때문에, 코드의 복잡도가 크게 올라갔죠. 반면, React Native를 이용하면 Client에서 실행되는 경우만 고려하면 되었어요.

토스에서는 사용자 경험과 개발 생산성의 두 가지 가치가 제일 중요한데요. 이렇게 React Native를 이용하면 사용자에게는 더 좋은 경험을 제공하면서도, 개발 생산성도 높일 수 있겠다는 생각이 들었어요.
토스 React Native 기술의 현재
토스 프론트엔드 챕터에서는 지난 1년 6개월간 React Native 화면을 조심스럽게 확대해 나가면서, 실제로 토스에서 가치를 제공하는지 확인했어요.


토스에서 “혜택 탭”은 React Native로 운영된 첫 번째 서비스로서, 토스에서 광고를 보고 앱테크로 돈을 버는 새로운 표준을 제시했습니다. 매출도 크게 증가했죠. 로딩 속도를 1초 이상 감축했고, 자동 동영상 재생과 같이 기존의 WebView에서 어려웠던 부분을 깔끔히 해결할 수 있었습니다.
혜택 탭 외로도, 지난 1년간 토스에서는 React Native 서비스를 다수 신규 런칭했어요. “피드 보고 포인트 받기”, “매일 방문 미션”과 같은 다양한 제품이 개발되어 서비스되고 있죠. 덕분에 지금은 React Native 뷰는 WebView를 이용한 화면보다도 많이 실행되고 있어요.
2024년 토스는 React Native를 서비스를 만들어 나가는 정식 기술 가운데 하나로 사용해보기로 하고, 서비스를 확대해 나가는 단계예요.
React Native 개발환경 자세히 살펴보기
그렇다면 토스에서는 어떻게 React Native 개발환경을 만들어나가고 있을까요?
마이크로 프론트엔드 아키텍처



토스에서는 사일로와 서비스마다 독립적으로 서비스를 운영하는 것이 매우 중요해요. 토스는 DRI 문화를 핵심 원칙으로 삼고 있기 때문에, 사일로에서 자체적으로 빠르게 의사결정을 내려서 배포 주기와 방법을 결정해야 하기 때문이죠. 한 서비스의 변경사항이 다른 서비스에게 영향을 주어서도 안 됩니다.
일반적으로 React Native 애플리케이션은 모놀리식한 단일 파일로 구성되는 경우가 많은데요. 토스에서는 자체적으로 React Native 애플리케이션을 마이크로 프론트엔드 아키텍처로 관리하는 시스템을 만들었습니다.


토스에서는 서비스마다 React Native 뷰가 나누어져 있으며, 각 서비스 화면은 독립적으로 실행되어 다른 화면에 영향을 주지 않습니다. 서비스가 실행될 때, 필요한 JavaScript 파일만 동적으로 로드해서 실행하는 형태예요. 
구체적으로는, 토스에서는 React Native 뷰를 그리기 위해 “Shared 번들” 과 “Service 번들”을 나누어 차례대로 실행합니다. “Shared 번들”은 react-native 라이브러리와 같이, 네이티브 영역과 강하게 연결되어 있어, 모든 서비스가 공통으로 사용하는 코드입니다. 그리고 “Service 번들”은 각 서비스에서 다르게 운영하는 부분만 별도로 분리된 코드에요. 두 코드는 서비스가 실행될 때 순서대로 동적으로 로드돼요. 이로써 사용자들은 서비스를 띄울 때 필요한 만큼만의 작은 JavaScript 코드를 실행하게 됩니다.
이렇게 만들어진 “Shared 번들” 과 “Service 번들” 은 토스의 React Native 플랫폼 팀이 만든 자체적인 어드민을 이용해서 CDN으로 배포돼요. 그리고 서비스 개발자는 간편한 UI로, 1초만에 React Native 화면을 배포하면 되죠.
1~100% 사이에서 일부 사용자들에게 원하는 만큼 카나리 배포를 할 수도 있고, 나만 보는 배포를 쉽게 만들 수도 있답니다.
ESBuild를 이용한 신속한 배포
토스에서는 React Native 번들을 빌드하기 위해 Metro 대신 ESBuild 번들러를 사용하고 있어요. Metro 번들러는 빌드하는 데에 시간이 오래 걸리고, Tree-shaking을 지원하지 않으며, 캐시를 리셋하지 않으면 일관적인 동작을 보장하기 어렵기 때문이었습니다. 
ESBuild를 도입한 이후에, 빌드 시간을 1분 안쪽으로 줄일 수 있었어요. 번들에서 안 쓰는 코드를 Tree-shaking으로 삭제해서, 번들 사이즈도 크게 감축시켰죠.
자세한 내용은 2023년 FEConf에서 “React Native, Metro를 넘어서” 발표에서 확인하실 수 있어요.


React Native의 미래
토스 프론트엔드 챕터는 React Native 기술의 미래가 밝다고 생각해요. 과거 React Native 기술에 대한 인식이 좋지 않았을 때도 있었지만, React Native 커뮤니티가 지속적으로 유의미한 발전을 만들고 있다고 보고 있습니다.
먼저, React Native 애플리케이션은 시간이 갈수록 자연스럽게 빨라지고 있어요. 스마트폰이 JavaScript를 실행하는 속도가 계속 빨라지고 있기 때문이죠. 하나의 예시로, 유명한 채팅 앱인 Discord는 iOS와 Android 모두 React Native로 구성되어 있는데요. 놀라울 정도로 빠른 성능과 아름다운 사용성을 보여주고 있어요. 그 외로 Microsoft가 제공하는 Office 앱이나, Shopify, Amazon 같은 사례도 있답니다. 
최근 Meta에서는 react-strict-dom (RSD) 이라고 하는 오픈소스 프로젝트를 발표했는데요. 하나의 코드베이스로 React와 React Native를 연결하려고 하는 비전을 제시하고 있어요. 마찬가지로 토스에서도 Web과 React Native에서 모두 아름답고 안정적으로 동작하는 “Isomorphic Package” 을 만들어 나가려고 해요.

Meta가 공개한 또다른 오픈소스 프로젝트로는 Static Hermes가 있어요. JavaScript를 바이너리로 컴파일함으로써 실행 속도를 네이티브와 동일한 수준으로 맞추려는 담대한 목표를 가지고 있죠. 
또한, 2024년 React Conf는 Meta와 React Native 전문 오픈소스 회사 Callstack이 협업해서 열리는데요. 아직 자세한 발표 내용이 공개되지는 않았지만, React Native를 주제로 하는 발표가 다수 예정되어 있어요. React Native는 앞으로 React Server Components와 함께 React 커뮤니티의 가장 중심적인 주제 중 하나가 될 것이라고 생각해요.
토스의 React Native Platform Team에서 일하기
토스에는 React Native Platform Team이 있어요. 프론트엔드 플랫폼 개발자 3명과 iOS 개발자 1명으로 구성되어 있고, 지금은 Android 개발자를 찾고 있어요. 
모든 팀원이 각자의 분야에 대한 전문가로 구성되어 있어요. 이근혁님은 React Native를 ESBuild로 빌드하는 react-native-esbuild 프로젝트를 오픈소스화하고 토스에 합류하셨어요. 오진성님은 iOS 분야의 전문가로, Cocoapods 없이 React Native를 앱에 포함하는 구조를 설계하셨죠. 기술적인 배경은 다르지만, 모두가 본인의 주된 개발 언어에 관계없이 주도적이고 열정적으로 프로젝트에 참여하고 있어요.

React Native Platform Team의 특징이라고 한다면, 모두가 전문 분야에 관계없이 JavaScript, iOS, Android 모든 영역을 담당하는 것을 지향한다는 점이에요. 프론트엔드 개발자도 iOS, Android 영역에 기여하고, 네이티브 개발자도 JavaScript 영역에 기여하려고 하죠. 프론트엔드와 네이티브 개발자가 다양한 도메인에 소프트랜딩할 수 있도록, 서로가 서로를 온보딩하고, 매일같이 모여서 짝 프로그래밍을 하는 문화를 가지고 있어요. 모두가 iOS, Android, JavaScript 등 클라이언트 개발 전반에 대한 전문성을 확보하려고 하고 있습니다.
대표적인 예시로, iOS 개발자도 React Native의 TDS(디자인 시스템) 라이브러리에 기여하고 있고, 프론트엔드 개발자도 iOS, Android의 React Native 모듈 유지보수에 참여하여 PR을 올리고 있어요.

React Native는 iOS와 Android, JavaScript 개발환경에 대한 이해가 없으면 다루기 힘든 기술인데요. 토스에는 국내 최고 수준으로 JavaScript, iOS, Android를 다루는 엔지니어들이 모여 있어요. 덕분에 어려운 문제를 맞닥뜨렸다고 하더라도, 각 플랫폼의 전문가와 함께 토론하면서 배워가고, 해결할 수 있죠. 치열하게 고민하며 최고의 개발환경을 만들어 나가는 짜릿함을 느끼고 있어요.
이렇게 토스의 React Native Platform Team은, 쫀득한 사용자 경험과 슬릭한 개발 생산성 모두를 제공하는 개발환경을 주도적으로 만들어 나갈 예정이에요.
무엇보다, 토스의 React Native 플랫폼은 여기에 그치지 않고, 올해 안에 지금까지 만든 React Native 배포 모듈과 AWS 인프라를 오픈소스화하고, 세계적으로 앱을 만들어 나가는 Best Practice를 제시하는 것이 목표예요.

최고의 개발환경에서 React Native 서비스를 만들어 나가고 싶으신가요? Frontend Developer로 합류하시면, 토스의 React Native 개발환경을 경험할 수 있답니다.
React Native Platform Team에서 개발환경을 가꾸어 나가는 여정에 함께하고 싶으신가요? Frontend Platform Engineer나 Android Developer (React Native) 에 지원하시면 팀에 합류하실 수 있어요.

그러면 앞으로 토스가 보여줄 React Native 개발환경을 기대해주세요!


안녕하세요, 토스 프론트엔드 엔지니어링 헤드 박서진입니다.
토스에서는 최고의 사용자 경험이 필요한 곳은 Native, 매일매일 실험으로 제품을 개선하는 제품은 React Native/WebView로 구성하고 있어요.
토스 프론트엔드 챕터는 지난 2022년 6월부터 React Native 기술에 투자하고 있는데요. 이번 기