프로젝트가 커지고 시간이 지날수록 그동안 잘 사용했던 기반 기술이 더 이상 최선의 선택이 아닌 순간이 와요. 이런 기술을 바꾸지 않고 방치하면 개발 측면에서는 빌드 시간 및 복잡도 증가, DX 하락 등 예측하기 어려운 여러 문제가 일어날 수 있어요. 개발 생산성이 떨어지고 제품 운영 및 개선의 발목을 잡기도 하고요.그렇지만 제품을 안정적으로 운영하면서 기반 기술을 마이그레이션하기 또한 쉽지 않은데요. 오늘은 제가 속한 토스의 TUBA 팀에서는 이런 문제를 어떻게 해결했는지 소개드릴게요.TUBA(Toss User Behavior Analyzer)는 2018년에 출시된 토스 임직원용 종합 데이터 솔루션이에요. TUBA에는 A/B 테스트, 메세지, 유저 세그먼트 등 총 22개의 하위 제품이 있어요. PO, PM, 디자이너, 개발자 외에도 Account Manager와 같은 비즈니스 직군, Customer Hero와 같은 고객 응대 직군까지 다양한 임직원이 매일 업무를 위해 사용하는 제품이에요!하지만 오래되고 큰 프로젝트인 만큼 TUBA에 여러 문제가 발생했는데요.첫 번째로는 빌드 속도가 매우 느려졌어요. TUBA는 yarn workspace를 활용해서 아래와 같이 하위 서비스와 공통 모듈을 나누어 관리하고 있는데요.각 패키지가 의 패키지를 사용하고 있어요.문제는 에 있는 공통 코드를 수정하면 전체 프로젝트 코드의 최신화가 필요했어요. 그렇기 때문에 작은 코드 수정이 있어도 하위에 있는 22개의 서비스를 모두 새로 빌드해서 배포해야 됐죠.너무 많은 프로젝트를 동시에 빌드하다보니 메모리 이슈로 빌드가 실패하기 시작했어요. 우선 급한 빌드를 내보내야 하니 동시에 1개만 빌드되도록 변경했는데요. 무려 빌드 타임이 2시간 15분으로 나왔어요.느린 빌드 타임의 원인을 파악해 본 결과, next 12에서 Module Federation과 함께 SSG로 빌드하면 SWC를 적용하더라도 빌드 속도와 메모리 사용량이 이상적으로 높다는 것을 발견했어요.마침 이전부터 next의 필요성에 대해서 팀원들과 논의를 했었는데요. 아래와 같이 의견이 모아져서 next의 장점보다 단점이 더 크다는 결론이 났고, next에서 webpack으로 마이그레이션을 시작했어요.• None TUBA는 내부 임직원 전용 서비스이기 때문에 SSR 등으로 첫 로딩 속도를 줄여도 이점이 크지 않다.• None 대부분의 next 기능을 사용하고 있지 않고, SSG 빌드용 도구처럼 사용되고 있다.하지만 막상 next를 제거하려고 보니 프로젝트 전반적으로 next를 사용하는 코드가 많았고, 무엇보다 공통 코드에서 사용되다 보니 점진적 마이그레이션을 하기 어려웠어요. 그래서 next-polyfill이라는 대체 구현 패키지를 만들어서 next에서 사용하고 있는 인터페이스를 최대한 비슷하게 구현했어요. Next 패키지를 사용하지 않아도 대체 구현 패키지를 통해서 필요한 기능을 코드에 쓸 수 있게 된거죠.위의 가 가장 간결하고 좋은 예시인데요. , 등 TUBA 프로젝트에서 사용하는 모든 컴포넌트 및 hook

안녕하세요. Seller & SD Engineering 팀의 개발자 김민우입니다.  저는 주로 백엔드 개발을 담당하고 있지만, 최근에 프론트엔드 개발, 특히 React로 캘린더 컴포넌트 만들기에 도전했습니다. 이 글에서는 백엔드 개발자의 시각에서 본 프론트엔드 개발의 독특한 점들과 더불어 Props Drilling 문제를 해결한 경험을 공유하고자 합니다. 프론트엔드 개발에 대한 저의 경험은 전문적인 관점이 아닐 수 있지만, 이 분야에 대한 새로운 시각을 제공하려 합니다. 배경 :  저희 팀은 새로 오픈 할 ESM 개편안 중 '통계' 작업을 맡았습니다. 본래는 통계 페이지들의 특성상 상단에는 단순 조건 필터링, 하단에는 해당 조건에 따른 결과(그래프, 테이블 등)로 단순하게 구성하기 때문에 프론트에 대한 리소스가 적을 것을 예상되었습니다. 게다가 어려운 컴포넌트들은 전문 프론트엔드 인력이 있는 팀에서 공통 컴포넌트용 라이브러리를 제공해주셨기 때문에 굳이 프론트 전문 리소스가 해당 프로젝트에서는 배정되지 않았습니다. 그래서 쉬울 줄만 알았던 프론트엔드 작업 총괄을 백엔드 개발자인 제가 맡게 되었습니다. 그러나 문제는 UI/UX 요구 사항의 변화로 기존 공통 컴포넌트 라이브러리의 한계를 마주했습니다.공통컴포넌트 캘린더 통계용 캘린더   인풋 박스의 변경, 모달 내 헤더에 탭 추가, 달력 타이틀 및 하단 헤더의 변화와 같은 요소들이 추가되었고, 이는 단순한 HTML 추가를 넘어서 다른 엘리먼트와의 복잡한 상호작용을 요구했습니다. 월 단위 캘린더   더욱이, '일/주/월' 별로 다르게 표시되고 작동하는 월 단위 캘린더, 그리고 시작점과 종료점을 선택하는 range 모드와 단일 날짜를 선택하는 single 모드를 구현해야 했습니다. 이 모든 요구 사항을 충족하는 6개의 새로운 컴포넌트 개발이 필요했습니다. 하지만 이런 캘린더 구조는 저희 도메인에서만 쓰는 특이한 구조였기 때문에 공통 컴포넌트 라이브러리에 요청해서 해결될 일은 아니었습니다. 라이브러리가 개발 공수 절감의 장점이 있었음에도 불구하고, 필요한 커스터마이징을 할 수 없었기 때문입니다. 백엔드 개발에서처럼 로직을 오버라이딩하거나 확장하는 방식으로는 프론트엔드 컴포넌트를 수정할 수 없었습니다.   결국 캘린더와 같은 복잡한 컴포넌트들은 공통 컴포넌트 라이브러리는 깔끔하게 물거품이 되었습니다. 결과적으로, 복잡한 기능을 가진 새로운 컴포넌트를 직접 개발해야만 하는 상황에 처하게 되었습니다. 일촉즉발의 위기상황. 백엔드 개발자의 통계용 캘린더 컴포넌트 만들기 대작전은 그렇게 시작됩니다... 1. 리액트 단기 속성으로 이해하기 :  서버 랜더링에 익숙한 백엔드 개발자들은 기존 웹 개발 방식을 다음 그림과 같이 알고 있을 겁니다. . 예를 들어, 스프링 부트와 같은 백엔드 프레임워크를 사용할 때, API 요청(@RestController)과 프론트 페이지(@Controller)의 구성 및 요청에 중점을 두고, 동적인 데이터를 HTML에 삽입하는 방식을 활용합니다.다음은 백오피스에서도 자주 쓰이는 U