데이터 중심 React 앱개발시, 하나의 상용 UI 라이브러리 사용이 더 좋은 이유

데이터가 많은 업무 애플리케이션을 React 로 만들면, 컴포넌트 구성이 대개 이렇게 끝납니다. 기본 UI 컴포넌트 한 벌, 쓸 만한 데이터 그리드 하나, 차트 라이브러리 하나, 검증이 복잡한 폼을 위한 것 하나, 그리고 날짜 선택기와 레이아웃 유틸리티.

각 단계의 결정은 모두 옳았습니다. 그때 그 화면에서 가장 좋은 선택을 한 결과입니다. 문제는 결정이 아니라 누적입니다.

숨은 비용 여섯 갈래

• 접착 코드: 서로를 모르는 컴포넌트 사이를 잇는 코드가 계속 늘어납니다. 그리드의 선택 상태를 차트에 넘기고, 폼의 검증 결과를 그리드 셀에 되돌리는 코드입니다
• 시각 불일치: 테마 체계가 갈라져 같은 화면 안에서 버튼 높이와 글꼴 크기가 미묘하게 다릅니다. 디자인 시스템 문서로 덮으려 하면 그 자체가 또 하나의 유지보수 대상이 됩니다
• 업그레이드 지연: React 메이저 버전을 올리는 시점은 가장 느린 라이브러리가 정합니다. 다섯 중 하나가 늦으면 전체가 늦습니다
• 벤더마다 드는 관리 작업: 보안 심사, 라이선스 갱신, SBOM 작성이 벤더 수만큼 반복됩니다
• 지원 떠넘기기: 두 벤더의 컴포넌트 사이에서 터진 버그는 어느 쪽도 자기 문제로 받지 않습니다. 재현 코드를 만들어 양쪽에 각각 제출하는 일이 개발자 몫으로 남습니다
• 지식 파편화: 다섯 벌의 API 를 아는 사람이 팀마다 다르고, 신규 입사자 교육 기간이 길어집니다

원문의 공수 모형

원문은 앱 하나, 연 4명 채용을 가정한 예시 모형을 제시합니다. 다섯 벤더 구성에서 위 여섯 갈래에 들어가는 공수가 연 약 79 엔지니어일, 한 벤더 구성에서는 약 21일로, 차이가 약 58일이라는 계산입니다. 라이선스 금액 차이는 여기에 들어 있지 않습니다.

이 숫자는 예시 가정입니다

원문도 "예시 가정이므로 각자의 숫자로 바꿔 보라" 고 명시하고 있습니다. 앱 수, 화면 수, 이직률, 업그레이드 주기에 따라 결과가 크게 달라집니다. 그대로 인용해 결재 문서에 올릴 숫자가 아니라, 세는 항목의 목록으로 보시는 것이 맞습니다. 중요한 것은 58일이라는 값이 아니라 그 58일이 어디서 나왔는지입니다.

"벤더 하나" 의 기준

브랜드 하나로 묶여 있다고 벤더 하나가 아닙니다. 인수한 제품들을 한 로고 아래 모아 놓은 것은 API 도 테마도 릴리스 주기도 여전히 따로입니다. 실제 기준은 여섯입니다.

• API 가 하나의 체계로 일관되는가
• 테마가 하나로 적용되는가
• 릴리스 주기가 하나인가
• 컴포넌트들이 공용 데이터 계층을 공유하는가
• 데이터 그리드에 충분한 깊이가 있는가
• 지원 계약이 하나로 묶이는가

흔한 반론과 그에 대한 답

• "한 벤더에 종속된다": 지금도 다섯 벤더에 종속되어 있습니다. 종속의 유무가 아니라 개수와 탈출 비용의 문제입니다
• "영역별 1등 제품을 쓰는 게 낫다": 데이터 중심 앱에서 결과를 가르는 것은 그리드입니다. 그리드가 충분히 깊다면 나머지 영역의 1등 여부가 화면 품질을 결정하지 않습니다
• "번들이 커진다": 다섯 벌의 중복 유틸리티와 서로 다른 날짜 라이브러리를 합친 쪽이 대개 더 큽니다
• "디자인 자유도가 줄어든다": 테마 체계가 하나면 실제로는 통제력이 올라갑니다
• "한 곳에 거는 위험": 벤더의 장기 지원 정책과 이전 경로를 계약 단계에서 확인해 줄이는 위험입니다

그래도 다섯 벤더가 나은 경우

원문은 예외를 분명히 적어 둡니다. 다음에 해당하면 통합이 오히려 손해입니다.

• 픽셀 단위 통제가 필요한 디자인 주도 애플리케이션
• 복잡한 컴포넌트가 하나뿐인 앱 (그 하나만 전문 제품을 쓰면 됩니다)
• 고급 지리공간 지도처럼 특수한 기능이 핵심인 앱
• 이미 성숙한 사내 디자인 시스템을 갖춘 팀

정리하면

• 다섯 벤더의 비용은 라이선스가 아니라 접착 코드·업그레이드 지연·관리 반복에서 나옵니다.
• 업그레이드 시점은 가장 느린 라이브러리가 정합니다: 이것이 가장 큰 항목입니다.
• "벤더 하나" 는 브랜드가 아니라 API·테마·릴리스·데이터 계층이 하나라는 뜻입니다.
• 데이터 중심 앱에서는 그리드의 깊이가 판단을 가릅니다.

미래웹이 덧붙입니다

국내 프로젝트에서 이 선택이 걸리는 자리는 대개 그리드입니다. 기본 컴포넌트는 사내 디자인 시스템이나 오픈소스로 충분한데, 수만 행을 다루는 그리드와 피벗·그룹·엑셀 내보내기가 필요해지면 그때부터 전문 제품이 들어옵니다.

그래서 실제 판단은 "다섯이냐 하나냐" 보다 "그리드를 가진 쪽으로 모을 수 있는가" 에 가깝습니다. Ext JS 는 그리드·차트·폼·트리를 한 체계로 갖고 있어 한 벌로 모이는 쪽이고, AG Grid 는 그리드와 차트를 깊게 가진 전문 제품입니다. 두 길 모두 쓸 수 있고, 어느 쪽이 맞는지는 앞서 말한 화면 유형 구성에 따라 갈립니다.

라이선스 쪽 실익도 함께 보셔야 합니다. 벤더를 줄이면 갱신 관리와 보안 심사가 줄지만, 개발자 단위로 과금하는 제품에 인원이 몰리면 단가가 그대로 드러납니다. 실제 절감액은 라이선스 금액과 관리 공수를 함께 세야 나옵니다. 미래웹은 제품별 과금 단위와 대규모 구성 기준을 EULA 원문으로 확인해 드립니다.

구성을 비교하고 계신다면

지금 쓰고 있는 제품 목록과 주요 화면 유형을 알려 주시면, 통합 가능한 조합과 그때의 라이선스 구성을 함께 정리해 드립니다. Sencha Ext JS·AG Grid·GoJS·Froala· FusionCharts 모두 국내 총판으로 공급합니다.

이 글은 Sencha 공식 블로그 게시물 React Component Library for Data-Heavy Apps: Why 1 Vendor Beats 5 (2026년 10월 21일, Team Sencha)을 미래웹 주식회사가 한국어로 옮기고 해설을 덧붙인 것입니다. 원문의 저작권은 Sencha / Idera, Inc. 에 있습니다. 공수 모형의 수치는 원문이 밝힌 예시 가정이며 미래웹이 검증한 값이 아닙니다. "미래웹이 덧붙입니다" 항목은 원문에 없는 미래웹의 견해입니다.