엔터프라이즈 UI,
직접 만들 것인가 사올 것인가
그리드와 폼을 다시 만드는 데 개발팀의 절반이 묶입니다. 직접 만들 때 실제로 얼마가 드는지, 그 계산서를 펼쳐 봤습니다.

업무용 소프트웨어를 만드는 회사라면 한 번쯤 이런 회고를 해 보셨을 겁니다. 지난 분기에 우리 개발팀은 무엇을 만들었나. 답을 적어 보면 목록의 상당 부분이 그리드, 폼, 필터, 페이지네이션, 레이아웃 셸입니다. 어느 업무 시스템에나 있고, 그래서 어느 회사의 제품도 그것으로 차별화되지 않는 것들입니다.
이 글은 그 시간에 대한 이야기입니다. 엔터프라이즈 UI를 직접 만들 때 실제로 무엇이 청구되는지, 그리고 그 청구서에서 대개 빠져 있는 항목이 무엇인지 짚어 봅니다.
문제는 야심이 아니라 여력이다
소프트웨어 회사에 아이디어가 부족한 경우는 드뭅니다. 만들고 싶은 기능은 늘 백로그에 쌓여 있습니다. 부족한 것은 그것을 실행할 엔지니어링 시간입니다.
Sencha가 2026년에 정리한 시장 조사를 보면 그 압박이 숫자로 드러납니다. 독립 소프트웨어 공급사의 53%가 출시 주기를 앞당기라는 압박을 받고 있고, 41%는 개발자 채용과 유지를 성장의 가장 큰 제약으로 꼽았습니다. 같은 기간 개발 비용은 5년 새 27% 올랐습니다. 일은 늘고, 사람은 구하기 어렵고, 단가는 오르는 삼중고입니다.
기대치도 함께 올라갔습니다. 기업 구매 담당자는 이제 업무 시스템에도 소비자 앱 수준의 사용성을 요구합니다. 분기 단위로 나가던 릴리스가 월 단위로 당겨지고, 멀티테넌시와 화이트라벨 납품은 대부분의 업종에서 계약서의 기본 조항이 됐습니다.
시간은 어디로 새는가
엔터프라이즈 애플리케이션 프로젝트에서 프런트엔드 개발이 전체 엔지니어링 공수의 40~60%를 차지합니다. 여기까지는 예상 범위일 수 있습니다. 문제는 그 안에서 상당 부분이 제품의 가치와 무관한 부품을 만드는 데 쓰인다는 점입니다.
정렬·그룹화·필터링·가상 스크롤이 되는 데이터 그리드, 피벗 테이블, 트리 패널, 검증과 마스킹이 붙은 폼, 차트, 캘린더. 이것들은 어느 업무 시스템에나 필요하지만 어느 것도 그 회사만의 것이 아닙니다. 고객이 돈을 내는 이유는 그 회사의 업무 로직 때문이지 그리드가 잘 굴러가서가 아닙니다.
비용으로 환산하면 이렇습니다. 그리드·차트·폼을 갖춘 기업용 대시보드 하나를 처음부터 만들면 미화 5만 달러부터 시작합니다. 북미 기준 프런트엔드 개발자 단가는 시간당 110달러 선이고, 컴포넌트를 한 줄도 코딩하기 전에 UI 디자인과 UX에만 전체 예산의 15~25%가 들어갑니다.
처음 비용은 청구서의 일부일 뿐이다
여기까지가 대부분의 견적서에 적히는 금액입니다. 그리고 여기서부터가 견적서에 적히지 않는 부분입니다.
직접 만든 컴포넌트는 하나하나가 장기 유지보수 채무가 됩니다. 크롬·파이어폭스·사파리·엣지는 각자의 일정으로 변경을 내놓고, 그때마다 커스텀 컴포넌트는 개별적으로 손봐야 합니다. 웹 접근성 기준(WCAG)이 바뀌면 컴포넌트마다 따로 대응해야 합니다. React나 Angular의 메이저 버전이 올라가면 그 위에 얹어 둔 구현이 깨집니다. 컴포넌트에 물려 둔 서드파티 의존성에서 취약점이 발견되면 그것도 따라가야 합니다.
그리고 운영에 올린 뒤에야 드러나는 문제가 있습니다. 데이터가 특정 형태일 때만 나는 렌더링 오류, 스크롤이 특정 조건에서 튀는 현상, 상태 관리가 꼬이는 경계 상황. 이런 것들은 테스트에서 잘 안 잡히고 고객 환경에서 처음 터집니다.
이 모든 것을 합치면 프런트엔드 팀 여력의 20~30%가 유지보수에 상시로 묶입니다. 새 기능을 만드는 팀이 아니라 이미 만든 것을 지키는 팀이 되는 것입니다.
직접 만들기를 결정할 때의 비교 대상은 대개 초기 개발비 대 라이센스 비용입니다. 그런데 실제로 비교해야 하는 것은 초기 개발비 + 3년치 유지보수 + 재작업 비용 대 라이센스 비용입니다. 앞의 계산으로는 직접 만들기가 늘 싸 보입니다.
고객마다 다른 얼굴을 입혀야 할 때
여러 기업 고객에게 같은 제품을 파는 회사라면 화이트라벨은 선택이 아니라 계약 조건입니다. 고객사마다 로고가 다르고, 색이 다르고, 선호하는 레이아웃이 다릅니다. 그런데 코드베이스는 하나여야 합니다.
테마 체계 없이 이 요구를 받으면 세 가지 일이 순서대로 일어납니다. 먼저 고객사별로 브랜치를 따게 됩니다. 고객이 늘 때마다 테스트와 릴리스 부담이 배수로 늘어납니다. 다음으로 CSS 덮어쓰기가 쌓입니다. 고객별 빌드마다 예외 스타일이 붙고, 그것들이 다음 업그레이드에서 깨집니다. 마지막으로 버그 수정을 공유할 수 없게 됩니다. A 고객에서 고친 것을 B 고객에 그대로 옮길 수 없는 상태가 되면, 그때부터는 한 제품이 아니라 여러 제품을 운영하는 셈입니다.
구조화된 테마 엔진이 있으면 이 문제의 성격이 바뀝니다. 색·타이포그래피·간격·아이콘을 고객사별 테마 파일 한 벌로 통제하고, 특정 컴포넌트만 따로 손봐야 하면 코드를 포크하지 않고 그 컴포넌트만 재정의합니다. 배포물은 하나로 두고 빌드 시점이나 실행 시점에 테마를 고르는 방식입니다. 제품은 하나인데 고객사 수만큼의 브랜드가 나옵니다.
그래서 무엇을 사는 것인가
엔터프라이즈 UI 플랫폼을 도입한다는 것은 컴포넌트 몇 개를 더 얹는 일이 아닙니다. 프런트엔드 계층 전체를 통째로 넘기는 결정입니다. 레이아웃, 데이터 바인딩, 상태 관리, 그리고 140종이 넘는 완성된 컴포넌트가 한 묶음으로 옵니다.
도입하고 나면 팀이 더 이상 만들지 않게 되는 것이 분명합니다. 데이터 그리드, 피벗 테이블과 리포팅, 트리 패널, 검증이 붙은 폼, 차트와 게이지, 캘린더와 일정 관리, 대시보드 레이아웃 셸. 접근성과 브라우저 호환성도 프레임워크가 떠안습니다.
그 자리를 대신 채우는 것은 업무 로직과 도메인 워크플로, 백엔드 연동, 고객별 기능 차별화, 데이터 계층의 성능 최적화입니다. 같은 인원으로 만드는 것의 성격이 바뀝니다.
판단할 때 실제로 비교해야 하는 것
기술 책임자가 이 결정을 검토할 때는 벤더가 제시하는 성능 수치보다 눈에 보이는 비용 항목으로 따지는 편이 낫습니다. 아래는 그 항목들입니다.
| 비교 항목 | 직접 개발 | UI 플랫폼 |
|---|---|---|
| 첫 화면까지 걸리는 시간 | 수 주 ~ 수 개월 | 수 일 |
| 유지보수 방식 | 컴포넌트마다 개별 대응 | 버전 업그레이드로 일괄 |
| 접근성·브라우저 대응 | 직접 수동으로 | 기본 제공 |
| 화이트라벨 | 브랜치·CSS 덮어쓰기 | 테마 파일 교체 |
| 모듈 간 UI 일관성 | 팀·스프린트마다 갈라짐 | 단일 컴포넌트 기준 |
| 기술 부채 | 릴리스마다 누적 | 플랫폼이 떠안음 |
항목별로 보면 결론이 갈릴 수 있지만, 3년을 기준으로 합산하면 방향이 대체로 한쪽으로 기웁니다. 직접 개발은 초기 비용에 유지보수와 재작업이 계속 더해지고, 플랫폼은 라이센스 비용이 고정된 채 업그레이드가 그 부담을 흡수하기 때문입니다.
국내 상황에 대입하면
여기까지는 미국 시장 기준의 이야기입니다. 국내에 옮겨 놓으면 숫자는 달라져도 구조는 그대로이고, 오히려 더 아프게 작용하는 지점이 있습니다.
첫째, 국내 SI·패키지 소프트웨어 회사의 인력 구조는 더 얇습니다. 프런트엔드 전담 인력이 한두 명인 팀이 흔하고, 그 인력이 유지보수에 20~30% 묶이면 신규 개발에 쓸 여력이 사실상 남지 않습니다. 미국 회사가 인원으로 흡수하는 부담을 국내 팀은 그대로 맞습니다.
둘째, 공공·금융 사업에서는 접근성이 선택 사항이 아닙니다. 웹 접근성 인증을 요구하는 사업에서 직접 만든 컴포넌트는 하나하나가 검증 대상이 됩니다. 프레임워크가 ARIA를 기본으로 처리해 주는 것과 컴포넌트마다 따로 맞추는 것은 투입 공수가 비교되지 않습니다.
셋째, 인력이 바뀌는 주기가 짧습니다. 직접 만든 컴포넌트는 만든 사람이 나가면 설명서 없는 자산이 됩니다. 공식 문서와 커뮤니티가 있는 프레임워크는 새로 온 사람이 검색으로 따라잡을 수 있지만, 사내 컴포넌트는 그럴 수 없습니다.
정리하면
- 프런트엔드가 전체 공수의 40~60%를 가져가고, 그 상당 부분이 차별화되지 않는 부품입니다.
- 직접 만든 컴포넌트는 팀 여력의 20~30%를 유지보수로 상시 묶습니다.
- 화이트라벨을 테마 체계 없이 받으면 브랜치·CSS 난립·수정 공유 불가로 이어집니다.
- 비교는 초기 개발비가 아니라 3년 총소유비용으로 해야 합니다.
직접 만드는 것이 늘 틀린 선택은 아닙니다. UI 자체가 제품의 차별점인 회사라면 그것은 핵심 자산이고, 남의 프레임워크에 맡길 이유가 없습니다. 다만 그리드와 폼이 제품의 차별점인 회사는 드뭅니다. 대부분의 업무 시스템에서 고객이 값을 치르는 것은 그 회사가 아는 업무이지 화면 부품이 아닙니다.
지난 분기에 우리 팀이 무엇을 만들었는지 목록을 뽑아 보시기를 권합니다. 그 목록에서 우리만 만들 수 있는 것이 몇 줄이나 되는지가 이 결정의 답에 가깝습니다.
Sencha Ext JS를 비롯한 엔터프라이즈 UI 솔루션의 라이센스 구성과 도입 검토는 국내 총판인 미래웹으로 문의해 주십시오. 화이트라벨이나 제품 임베딩(OEM)처럼 라이센스 구조가 달라지는 경우도 함께 상담해 드립니다.
이 글은 Sencha 백서 How ISVs Accelerate Product Development with Ext JS (2026)의 내용을 바탕으로 미래웹 주식회사가 국내 독자를 위해 재구성한 것입니다. 본문의 통계와 인포그래픽은 Sencha가 발표한 자료이며 저작권은 Sencha / Idera, Inc. 에 있습니다. 「국내 상황에 대입하면」 항목은 원 자료에 없는 미래웹의 해설입니다.
