여러 React 앱의 UI 컴포넌트 라이브러리를 하나로 표준화하는 방법

규모가 있는 조직에서 React 앱이 열 개를 넘기면, 대개 UI 스택도 그만큼 갈라져 있습니다. 한 팀은 그리드를 A사 제품으로 쓰고, 다른 팀은 B사 것을 쓰고, 세 번째 팀은 직접 만든 컴포넌트를 돌립니다. 각각의 선택에는 그때의 이유가 있었습니다.

문제는 합쳐 놓고 볼 때 드러납니다. 같은 회사 제품인데 화면이 서로 달라 보이고, 같은 기능을 팀마다 다시 만들고, 라이선스 계약이 난립하고, React 메이저 버전을 올릴 때마다 앱 수만큼 업그레이드 작업이 생깁니다. 표준화가 필요한 시점은 보통 이것이 눈에 보이기 한참 전입니다.

표준화는 선언이 아니라 프로그램입니다

"앞으로 이 라이브러리를 씁니다" 라는 공지 한 장으로는 아무것도 바뀌지 않습니다. 오너가 있고, 버전 정책이 있고, 이전 일정이 있고, 성과를 재는 지표가 있어야 비로소 돌아갑니다. 아래 7단계는 그 프로그램을 세우는 순서입니다.

1. 현황 감사: 지금 무엇을 쓰고 있는지부터

모든 저장소의 package.json 을 훑어 UI 의존성을 뽑고, 컴포넌트·그리드·차트·폼· 날짜·레이아웃으로 분류합니다. 자동으로 잡히지 않는 것은 손으로 더합니다. Ext JS 로 만든 기존 앱, 사내에서 직접 만든 컴포넌트, 그리고 이미 맺어 둔 라이선스 계약입니다.

앱마다 화면 수와 사용자 수도 함께 적습니다. 나중에 무엇을 먼저 옮길지 정할 때 이 숫자가 근거가 됩니다. 사용자가 많은 화면이 아니라 손대기 쉬운 화면부터 옮기면 성과가 보이지 않습니다.

2. 요건 정의: 화면 유형으로 자른다

제품 기능 목록으로 비교하면 끝이 없습니다. 실제로 만들어야 하는 화면 유형으로 자르면 다섯 가지로 줄어듭니다.

• 데이터 조회·편집 화면 (목록, 상세, 인라인 편집)
• 대시보드 (집계, 차트, 카드)
• 데이터 입력 화면 (검증이 많은 폼, 다단계 입력)
• 계층 구조 화면 (트리, 조직도, 분류 체계)
• 내비게이션과 애플리케이션 셸

여기에 기능과 무관한 요건을 더합니다. 접근성, 현지화, TypeScript 지원, 지원하는 React 버전 범위, LTS 정책, 그리고 라이선스 조건입니다.

3. 표준 선정: 부가물을 가장 적게 요구하는 것

기준은 "기능이 많은가" 가 아니라 "다섯 유형을 추가 라이브러리 없이 얼마나 덮는가" 입니다. 덮지 못하는 유형이 하나 남을 때마다 벤더가 하나 늘어납니다.

함께 보는 것은 네 가지입니다. 어려운 화면에서의 깊이, API 와 테마가 하나로 묶여 있는지, 대규모 라이선스가 가능한지, 벤더의 장기 지원과 이전 경로가 있는지입니다.

그리고 반드시 짧은 파일럿으로 확인합니다. 두 앱에서 가장 까다로운 화면을 골라 그 라이브러리로 다시 만들어 봅니다. 데모 페이지에서는 전부 잘 돌아갑니다. 우리 화면에서 돌려 봐야 압니다.

4. 내부 패키지로 감싸기

표준을 정했다고 각 앱이 그 라이브러리를 직접 import 하게 두면, 반년 뒤에 버전이 여섯 갈래로 갈라집니다. 사내 패키지 하나(예: @acme/ui)로 감싸고 그것만 쓰게 합니다.

• UIProvider 하나에 버전·툴킷·테마·로케일·RTL·라이선스 키를 모읍니다
• 표준 DataGrid·FormPanel·Chart·AppShell 을 내보냅니다
• ESLint no-restricted-imports 로 바탕 라이브러리의 직접 import 를 막습니다: 이전하는 동안은 경고로 두고, 끝나면 오류로 올립니다

5. 거버넌스: 주인이 있어야 유지됩니다

전담 조직까지는 필요 없습니다. 각 팀에서 한 명씩 모은 소규모 겸임 오너 팀으로 시작합니다. 컴포넌트를 추가할 때는 제안서와 PR 을 거치고, 시맨틱 버저닝과 변경 이력을 지킵니다. 파괴적 변경은 메이저 버전에서만 내고, 폐기 예정 API 는 최소 한 메이저 동안 남깁니다.

문서는 Storybook 으로 둡니다. 그리고 바탕 라이브러리 업그레이드는 각 앱이 따로 하지 않고 공용 패키지에서 한 번에 올려 전 앱에 내려보냅니다. 이것이 표준화의 가장 큰 실익입니다.

6. 물결처럼 이전한다

한 번에 다 바꾸려 하면 기능 개발이 멈추고, 멈춘 동안의 비용을 감당하지 못해 중단됩니다. 순서가 있습니다.

• 새로 만드는 화면부터 표준을 의무화합니다 (증가분 차단)
• 앱 한두 개를 완전히 이전해 파일럿으로 삼습니다
• 트래픽이 많은 그리드와 대시보드를 옮깁니다
• 다른 이유로 손대는 화면을 그때 함께 옮깁니다
• 옛 라이브러리와 그 라이선스를 폐기합니다

이전 단위는 앱이 아니라 화면이어도 됩니다. 한 앱 안에서 구·신 라이브러리가 한동안 공존해도 문제없습니다. Ext JS 로 만든 앱이라면 셸만 React 로 먼저 옮기고, ReExt 로 기존 컴포넌트와 스토어를 그대로 재사용하는 길이 있습니다.

7. 측정: 끝났는지 어떻게 아는가

표준화는 성과가 보이지 않으면 조용히 중단됩니다. 처음부터 재기 시작합니다.

• 앱당 UI 라이브러리 개수
• 표준이 적용된 화면의 비율
• 새 데이터 화면 하나를 만드는 데 걸리는 시간
• 릴리스당 UI 결함 수
• React 메이저 업그레이드에 걸리는 기간
• UI 라이선스 총지출

흔히 빠지는 함정 다섯

• 가장 어려운 화면을 못 덮는 표준: 예외가 하나 생기면 그 뒤로 계속 늘어납니다
• 너무 많이 감춘 래퍼: 바탕 라이브러리의 고급 기능에 닿을 탈출구를 반드시 남깁니다
• 오너 없는 공용 패키지: 직접 import 로 조용히 되돌아갑니다
• 빅뱅 이전: 기능 개발이 멈추고, 멈춘 채로 중단됩니다
• 방치된 레거시 앱: 옛 라이선스를 폐기하지 못해 비용이 그대로 남습니다

정리하면

• 표준화의 실익은 디자인 통일이 아니라 업그레이드 경로가 하나로 줄어드는 것입니다.
• 기준은 기능 수가 아니라 추가 라이브러리를 요구하지 않고 덮는 화면 유형의 수입니다.
• 공용 패키지와 lint 규칙 없이는 반년 뒤에 버전이 다시 갈라집니다.
• 이전은 화면 단위 물결로, 새 화면 의무화부터 시작합니다.

미래웹이 덧붙입니다

국내에서 이 상황을 만나는 자리는 대개 둘입니다. 하나는 사업부마다 SI 업체가 달라 UI 스택이 따라 갈라진 경우이고, 다른 하나는 Ext JS 로 만든 기간계 화면과 새로 쓴 React 화면이 한 시스템 안에 같이 있는 경우입니다.

후자에서는 원문이 말한 "셸만 먼저 React 로" 가 특히 현실적인 선택입니다. 기존 Ext JS 그리드와 스토어를 ReExt 로 React 안에서 그대로 쓰면, 업무 로직을 건드리지 않고도 새 화면과 같은 틀에 올릴 수 있습니다. 전면 재작성과 현상 유지 사이의 선택지로 보시는 것이 맞습니다.

라이선스 쪽에서도 짚을 것이 있습니다. 벤더를 줄이면 계약과 보안 심사가 줄어드는 것은 분명하지만, 같은 수의 개발자를 한 제품에 몰면 그 제품의 개발자 단위 가격이 그대로 드러납니다. 실제 절감액은 "라이선스 비용"만이 아니라 갱신 관리·보안 심사·SBOM 작업에 들어가던 사람의 시간까지 같이 세어야 제대로 나옵니다. 그 계산을 도와드립니다.

표준화를 검토하고 계신다면

어느 제품으로 모을지보다 먼저 정해야 할 것은 현황 감사 범위와 측정 지표입니다. Sencha Ext JS·ReExt·AG Grid 를 포함한 제품 비교와 대규모 라이선스 구성은 국내 총판인 미래웹으로 문의해 주십시오.

이 글은 Sencha 공식 블로그 게시물 How to Standardize on One UI Component Library Across Your React Apps (2026년 10월 21일, Team Sencha)을 미래웹 주식회사가 한국어로 옮기고 해설을 덧붙인 것입니다. 원문의 저작권은 Sencha / Idera, Inc. 에 있습니다. "미래웹이 덧붙입니다" 항목은 원문에 없는 미래웹의 견해입니다. 번역 과정에서 생긴 오류가 있다면 원문을 기준으로 판단해 주십시오.